802.11?
С учётом продекларированной "краткости", остановимся лишь на
стандартном, в настоящее время, 802.11g (54 Mbit/sec OFTM), добавив
лишь, что адаптеры 802.11g в абсолютном большинстве случаев
поддерживают и 802.11b (11 Mbit/sec). При обсуждении защиты не удастся
также обойти вниманием 802.11х, но об этом - ниже.
А почему, собственно, - Linux? К сожалению, реализация что поддержки
устройств, что протоколов обеспечения безопасности выполнена в
благородном *-nix семействе по-разному. Не пытаясь, в соответствии с
рекомендациями К. Пруткова "объять необъятное", придётся ограничиться
Linux. Тем более, что можно констатировать: в Linux поддержка
адаптеров, для которых и не для всех-то версий m$win находятся
драйвера, решена довольно успешно.
И почему - кратко? В соответствии с вышеупомянутыми рекомендациями К.
Пруткова. В затронутой теме отдельного разговора заслуживают, как
минимум: использование NDIS-драйверов под Linux, технические аспекты
Wi-Fi, создание ip-туннелей, вопросы аутентификации и шифрования... Но,
поскольку необъятное объять всё-таки не представляется возможным, то
лучше быть кратким.
Кроме того, я вообще не сторонник конкретных рецептов: слишком
неэффективно, принимая во внимание разнообразие систем на базе Linux,
не говоря уже о nix-ах "вообще". Не нужно себя обманывать: в каждом
конкретном случае самому разбираться всё равно придётся. Да и так ли
это плохо?
"Что есть сие?"
Для простоты и всё той же краткости будем считать, что Wi-Fi - тот же
Ethernet, только без кабелей. Хотя, справедливости ради, стоило бы
вспомнить, что первые устройства разрабатывались не как "расширение",
а, скорее, как альтернатива последнего. Но, это - дела минувшие, а
нынче адаптер с точки зрения ОС представляется как сетевой, к которому
приложимы все обычные средства управления и конфигурирования "a la"
ifconfig и т.д.
При ближайшем рассмотрении, однако, различия всё-таки обнаруживаются.
Так, для соединения адаптеров Ethernet нужен, как минимум
"кросс-кабель", а лучше - hub. То, что с Wi-Fi кабель не нужен -
разумеется, но, оказывается, вместе с ним пропадает и ограничение
"только два - или hub". Несколько Wi-Fi адаптеров легко могут общаться
между собой. У них это называется "Ad-Hoc". Отметим этот режим как
"вариант", но зададимся вопросом: а зачем тогда нужен упомянутый выше
аналог hub-а? Причин несколько, и чисто физические (большая пропускная
способность и лучшая, как правило, реализация радио-тракта) при этом не
главные. Важнее то, что Access Point (AP - для краткости. Именно так
называется этот самый аналог hub-а) - ключевой участник организации
защиты сети. Режим с AP называется "Infrastructure" и имеет средства
защиты, отсутствующие для режима Ad-Hoc. К тому же, хорошо бы иметь
возможность объединить нашу сеть Wi-Fi с какой-нибудь локальной. Опять
же: AP представляется для этого более подходящим устройством, чем IBM
PC с парой сетевых карт, одна из которых - Wi-Fi.
Сложив всё необходимое для работы AP в одну коробочку, производитель
задумался: а не назначить ли её ещё и роутером/файрволом "по
совместительству"? Ведь, практически, всё необходимое уже внутри... Так
появились Wi-Fi роутеры, которые, помимо функций AP, имеют порт для
подключения модема кабельного, ADSL и прочих в этом роде,
обеспечивающих соединение с Сетью. Если учесть, что такой роутер,
практически, не дороже обычной AP, то решение имеет хорошие
маркетинговые перспективы. Знакомимся поближе...
Включаем.
"Монтаж" PCI-, USB- или PCMCI- адаптера опускаю: по-моему, такая
информация унижает читателя. Теперь нужно обеспечить поддержку данного
устройства. В Linux, как известно, это достигается загрузкой
соответствующего модуля. Как правило: даже нескольких, но "затребовав"
с помощью modprobe нужный, можно быть уверенным в загрузке и всех, ему
необходимых. Это не совсем так для PCMCI и USB: тут кое о чём нужно
позаботиться самому... Однако, о чём это я? RTFM, поскольку сейчас речь
о Wi-Fi.
Один из вариантов получения нужного "драйвера" я всё же упомяну -
ndiswrapper. Вспомним, что производитель, как правило, снабжает свой
адаптер нужным драйвером и мы даже оплачиваем его при покупке. Драйвер
этот, как правило, для m$win, и уж, наверняка, в виде двоичного файла.
Обидно, но делать нечего. Кроме как попытаться использовать этот
драйвер. Для меня это второй известный случай успешного использования
проприетарного ПО, презентуемого в двоичном виде, под Linux (первый -
кодеки в mplayer). Итак:
берём ndiswrapper с http://ndiswrapper.sourceforge.net;
make; make install;
инсталлируем NDIS (win) драйвер командой:
ndiswrapper -i filename.inf
где filename.inf - inf-файл из состава драйвера;
если в ответ на ndiswrapper -l вы получите что-то вроде: Installed ndis drivers:
driver_name driver present, hardware present
- примите поздравления;
позаботьтесь о том, чтобы модуль ndiswrapper был загружен (а
используете вы для этого rc.modules, modules.conf или нечто из
/etc/hotplug - ваше дело). В команде загрузки модуля в качестве
параметра if_name=desired_name можно указать имя сетевого интерфейса,
"появляющегося" после загрузки модуля. Если ничего не указывать, имя
будет - wlan0;
позаботьтесь о том, чтобы этот новый интерфейс конфигурировался при
старте: вообще-то это делается командой ifconfig, но мало ли, какими
конфигурационными файлами и программами настройки завуалировал этот
факт мейнтейнер вашего дистрибутива...
Собственно - всё. Модуль может быть и другим, разумеется, если вы,
например, - счастливый обладатель адаптера, поддерживаемого ядром
Linux, но цель прежняя - получить сетевой интерфейс, идентифицируемый
(следовательно: и - конфигурируемый) стандартными средствами
Соединяемся.
Итак, сетевой интерфейс имеем. Опять, однако, придётся вспомнить, что
это "не совсем ethernet". Или: ethernet, но "радио". На следующем этапе
потребуются утилиты Жана Турилеса (Jean Tourrilhes), известные как
"Wireless Tools". Их немного, а нам, для начала, хватит и вовсе двух:
iwlist и iwconfig. Запускаем:
iwlist wlan0 scan
и, если в доступном эфире адаптером обнаруживаются сигналы Wi-Fi, то на
экране можно будет прочесть достаточно подробный протокол. Источником
сигнала может быть только AP или другой адаптер, разумеется. С AP,
обычно, прилагается утилита конфигурации, которой можно воспользоваться
, "достучавшись" до AP через сетевой интерфейс или последовательный
порт (уж какой у данной AP есть). А вообще-то, какой-то сигнал AP
выдаст в эфир по включению и без настройки - и достаточно для начала.
Ну, а если решитесь сразу настраивать AP, то совет только один: не надо
сразу включать средства защиты. Никакие.
В отсутствие AP сигнал нам может подать только другой адаптер
(очевидно, что в отсутвие AP, адаптеров у вас должно быть два, как
минимум). Только вот адаптер-то по умолчанию выдавать ничего не будет.
Переходим к другой утилите - iwconfig. Вообще-то iwconfig - нормальная
консольная утилита, первым параметром ожидающая имя интерфейса, а
последующими - команду с параметрами. Команд этих сравнительно немного
и с их помощью можно сделать всё необходимое (нужно только не забыть,
что большая часть команд выполняют настройку адаптера, включает же его,
фактически, только одна - essid. Получается: именно она должна быть
последней в последовательности действий).
Привычнее, однако, настройка Wi-Fi выглядела бы при загрузке: как это
вам уже, надеюсь, удалось для драйвера адаптера и сетевого интерфейса.
Трудности здесь обычные: проистекающие от разнообразия дистрибутивов.
Для начала стоит выяснить: а нет ли в вашем дистрибутиве этих самых
"Wireless Tools"? Поскольку, если есть, то, вероятнее всего, мейнтейнер
уже включил в пакет файлы настройки и скрипты, нужные для настройки и
включения Wi-Fi. Если нет, то (спасибо Жану) придётся почитать
DISTRIBUTION.TXT, являющийся частью source-пакета. Сложного там ничего
нет: всё сводится к определению нескольких параметров в качестве
переменных среды и последовательному запуску iwconfig. Параметры все
описаны (man iwconfig), а на настоящем этапе потребуются совсем не
многие:
ESSID (extended network name) - самый главный
параметр. Имя сети. Разумеется ESSID у устройств, связь между которыми
нужно установить, должен быть одинаковым - будь то AP или адаптер;
MODE (Operation mode). При наличии AP - "Managed", в
отсутствие - "Ad-Hoc". В моде "Managed" адаптер, не обнаружив при
старте сети с ESSID, таким же, как его собственный, выключается. В моде
"Ad-Hoc" - работает постоянно: изображает из себя AP;
CHANNEL - номер канала. Также один для всех клиентов
создаваемой сети. Если iwlist сообщил вам о наличии в эфире нескольких
сетей, занимающих, соответсвенно, несколько каналов, я думаю, вы
догадаетесь выбрать для своей - незанятый;
RATE можно оставить "auto", в надежде, что будет
выбрана максимальная скорость (что практически всегда соответствует
действительности);
К остальным параметрам, включая вскоре потребующийся нам "Encryption key", вернёмся чуть позднее.
iwconfig без параметров всегда покажет состояние интерфейсов Wi-Fi.
После выключения настроенного адаптера (аппаратно ли, из-за
"пропадания" AP в режиме Infrastructure) заново включить его можно
командой:
iwconfig wlan0 essid your_essid
где wlan0 - имя сетевого интерфейса, а your_essid - имя вашей сети.
Пока - всё. Итого, на данном этапе имеем:
интерфейс wlan0, появившийся после загрузки драйвера;
его сетевые настройки, выполненные обычным способом (dhcpcd, ifconfig, route и т.д.);
его специфические Wi-Fi настройки, выполненные iwconfig. Поскольку эти
настройки уже включают в себя данные об обнаруженной нами в эфире с
помощью iwlist сети, то результатом, трёх вышеперечисленных пунктов
должен быть, как минимум, успешный ping до AP или другого адаптера.
Надеюсь, так оно и есть. Ну, а есть ping - получите и всё остальное. В
соответствии с наличием в вашей сети сетевых сервисов и настроек
маршрутизации. К Wi-Fi это отношения уже не имеет.
Защищаемся
Способы защиты передаваемой информации стали неотъемлемой частью
стандарта 802.11 по вполне очевидной причине: в иллюзию защищённости
кабеля ethernet пользовател поверит намного охотнее, чем в защищённость
данных, передаваемых через эфир. Правильно, в общем-то. Хотя более
незащищённой сети, чем сегмент ethernet, охватывающий жилой дом или
бизнес-центр, просто не бывает: не нужно быть хакером, чтобы знать о
существовании у ethernet-адаптера "promiscuous mode", а ПО перехвата и
парсинга пакетов даже писать не придётся: "бери - не хочу". Ещё один,
достойный сожаления, пример - домашний компьютер, подключённый к
Интернет со всеми мыслимыми и немыслимыми клиентами (в терминологии
m$win), запущенными сервисами и открытыми на этом соединениипортами. Да
мало ли ещё опасностей, намного более неожиданных, чем "перехват"
пакета Wi-Fi, ожидает неискушённого пользователя в мире ip?... Ну, да
это его проблемы. Вернёмся к 802.11.
Поскольку инженеры из IEEE, разрабатывая протокол, ориентировались
всё-таки не на "самоделкиных", расставляющих hub-ы в открытых
помещениях и не на win'98, нежданно-негаданно подключенную к Интернет,
то о защите они были обязаны задумываться с самого начала. Однако:
недостаточно, как вскоре выяснилось. Так называемый WEP (wired
equivalent privacy), использующий алгоритм шифрованиф RC4 при длине
ключа 40/104 бит очень скоро стал материалом для хрестоматийного
примера взлома защиты. Wi-Fi Alliance опять бросился дорабатывать
протокол (работа закончена в июле 2004-го), параллельно предлагая
временные альтернативы, такие как WPA (Wi-Fi Protected Access).
Проблема заключается в том, что новый стандарт должен стать правилом
для множества производителей, поставляющих аппаратуру Wi-Fi.
Перепрошивка потребуется десяткам миллионов уже существующих устройств,
а тем, для которых перепрошивка невозможна, просто потребуется замена.
По-моему, ребята немного "влипли"...
Что же, откажемся от таких привлекательные возможностей, пока
производители не защитят Wi-Fi должным образом? Не думаю. Во-первых,
возможность взлома ещё не означает его высокой вероятности. И PGP можно
взломать, только для этого нужны довольно приличные вычислительные
мощности. И то, что "легко" для ФБР, окажется "не по зубам" соседскому
"хакеру". Нужно только прикинуть, кому может понадобиться ваша сеть и
для чего. Так что, предлагаю оценить арсенал средств защиты и решить,
что стоит использовать, а что - нет. Итак, имеем:
вышеупомянутый WEP, поддерживаемый всеми устройствами Wi-Fi. Хоть его и
"ломают в порядке демонстрации", а использовать - нужно. Особенно, если
это единственно доступный аппаратно реализованный способ шифрования (а
для Ad-Hoc это так и есть). Разумеется, предпочтительнее 104 битный
ключ, почаще меняйте его, не держите канал включённым без нужды - и,
вероятнее всего, что с прецедентом взлома столкнуться вам придётся не
скоро.
При работе с iwconfig ключ шифрования помещается обычно в переменную
KEY ("Encryption key"). Ключ выражается обычно в HEX-символах,
выражению в ascii предшествует префикс s:. Если ключей несколько, то
все они перечисляются в одной переменной, разделяемые пробелами,
номерами ключа (в квадратных скобках) и ключевым словом key;
при использовании AP, запретите ей передавать essid широковещательными
посылками. Не Бог весть какая защита, но случайно оказавшийся в зоне
приёма адаптер автоматически в сеть, по крайней мере, уже не войдёт;
при наличии такой возможности - включите в AP контроль MAC-адресов:
пусть она обслуживает только "своих". Конечно, MAC можно "выудить" из
перехваченного пакета и подставить в свой... будет кто-то из ваших
соседей этим будет заниматься? Вам - решать...
WPA, тот самый продукт группы I (Security), занимавшейся
усовершенствованием механизмов защиты в рамках 802.11. Наверное, не
бывает ничего окончательно совершенного, но на настоящий момент
считается, что аутентификация в сочетании с алгоритмом шифрования AES
(это, правда, уже WPA2), обеспечивают достаточную защиту Wi-Fi. Если
оставаться в рамках продекларированной краткости, то необходимым
минимумом знаний по этому поводу будет только то, что WPA - компромисс
между существующим оборудованием и усовершенствованными алгоритмами
защиты. И компромисс этот состоит в том, аппаратура по-прежнему
использует RC4-шифрование, только вот ключ к каждому пакету
генерируется свой. Ключ этот может генерироваться внешним сервером
аутентификации (RADIUS, как правило. Проприетарный сервер. Версия его
входит в M$ IIS, если не ошибаюсь), или - самими субъектами обмена. В
соответсвии с этим IEEE 802.1X определяет "WPA-Enterprise"(WPA with
EAP) и "WPA-Personal"(WPA-PSK) режимы. Лучшее известное мне описание
работы WPA читайте в составе wpa_supplicant. Последний, кстати,
реализовани и для m$win;
последняя группа средств защиты хоть и не связана с Wi-Fi
непосредственно, но расценивается многими как наиболее перспективная.
Речь идёт о защите ip пакетов вне зависимости от среды передачи. Ну, в
самом деле: какая вам разница, осуществляется передача в эфире,
посредством витой пары или оптоволоконного кабеля, если последние
физически вами всё равно не контролируются? Вполне естественно
раздельно рассматривать аутентификацию, шифрование и собственно
транспорт. Оставив, таким образом, "в ведении" Wi-Fi только голый
TCP/IP - с единственно обрабатываемым портом к какому-нубудь хорошо
защищённому сервису, предоставим последнему и аутентификацию, и
шифрование в рамках сеанса. Что будет толку от взлома WEP, если его
результатом станет лишь приглашение аутентифицироваться, да ещё и
зашифрованное, свят-свят... Угадываются всякие туннели, VPN-ы и т.п.
Выбор достаточно широк.
проприетарные pptp и L2PT. Сервера отношения к Linux не имеют, но почему бы и не быть их клиентами?
Vtune
CIPE
SecurePoint & VPN - если вам требуется законченное решение в виде iso-образа, мегабайт эдак на двести с лишним.
Наверняка существуют и ещё. Почему бы нет, если под Linux возможно
создание виртуальных туннелей хоть для фреймов ethernet, хоть для
ip-пакетов. "Твори, выдумывай, пробуй". Вот только необходимость иметь
хотя бы клиентов для m$win, ограничивает это разнообразие. Что ни
говори, а при обсуждении вопросов коммуникаций, игнорировать
существование win-хостов глупо...
Короче: выбрать есть из чего. И выбрать - нужно. Даже при полном
пренебрежении к вопросам защиты не стоит всё-таки уподобляться
оператору кабельных сетей, который вместо прокладки кабеля предлагает
применить Wi-Fi (за "не слабые", кстати, $200). И только месяц спустя
вы обнаруживаете, что к установленной на лестничной площадке AP ЛЮБОЙ
Wi-Fi клиент подключается АВТОМАТИЧЕСКИ. Оператору-то всё равно: трафик
оплатит подписавший договор, а вам?
Практикум
Ну, и несколько примеров...
Пара компьютеров в квартире с периодической потребностью в обмене по http, ftp, smb.
Мода - Ad-Hoc. Защита - WEP. В дополнение можно защитить сервисы (https
для http, запрет anonimous + хорошие пароли для ftp, исключительно
парольный доступ к smb-ресурам).
Та же пара, но один из хостов имеет выход в Интернет, что означает, как правило, потребность в почти постоянном соединении.
Поскольку в Ad-Hoc помимо WEP и защищаться-то особенно нечем, то лучше
на компьютере, имеющем выход в Интернет, запустить vpn-сервер: pptp,
если это ХР, CIPE или VTun, если это Linux. Таким образом, в
сравнительно "открытом" режиме (WEP, кстати, стоит оставить) происходит
только открытие сеанса связи с vpn-сервером. Далее трафик шифруется по
правилам созданного туннеля.
Несколько компьютеров в квартире и одно ADSL или кабельное подключение к Интернет.
Infrastructure вместо Ad-Hoc, разумеется. AP с функциями роутера. WEP,
запрещение трансляции essid, контроль MAC-адресов - как минимум.
WPA-PSK - очень желательно. Хотя для этого и потребуется позаботиться о
наличии wpa_supplicant на всех хостах. Независимо от ОС.
Удалённое подразделение.
AP в основном офисе, клиенты - в удалённом подразделении. WEP,
запрещение трансляции essid, контроль MAC-адресов, WPA-PSK. Вариант:
создание туннеля между одним из компьютеров основного офиса и одним из
компьютеров подразделения. В этом случае можно попытаться обойтись без
AP, защищённость хороша настолько, насколько защищён туннель.
Существенным недостатком становится обязательное включение упомянутой
пары компьютеров для обеспечения связи между офисом и подразделением и
необходимость создания кабельной сети в подразделении. Ещё вариант:
связь между подсетями офиса и подразделения обеспечивает пара AP в
режиме WDS (Wireless Distribution System). Если считать защищённость
уровня WPA-PSK достаточной и смириться с необходимостью монтажа
ethernet-сегмента в подразделении, получается довольно экономично.
Wi-Fi, как альтернатива ethernet для ЛВС.
Теоретически - возможно, если хватит пропускной способности: 20Мбит всё
же меньше 100-та, а с увеличением количества хостов полоса пропускания
сети ещё уменьшится... Очевидно, в данном случае уже не обойтись без
выделенного севера идентификации, Не уверен также, что
администрирование такой сети будет простым: скорее, забот
администратору прибавится. Предпочтительнее выглядит простая Wi-Fi
сеть, но жёстко контролируемый доступ к ресурсам: эффективные механизмы
идентификации, шифрование создаваемых между клиентами и сервером
туннелей... Принимая во внимание опыт предоставления сервисов в
Интернет, такая реализация представляется лично мне более жизненной.
Поживём - увидим.
Приведенные примеры - лишь иллюстрация того факта, что имеется довольно
много способов применить Wi-Fi с пользой. Не исключено, что для
кого-нибудь - уже сейчас.
Другие материалы по теме
|
