Wi-Fi. Linux. Краткий курс

Владимир Попов
2005.12.27

POSIX.ru

7 июня 2007 г

"А оно вам надо?"

Вполне вероятно. Уж очень неуместны бывают сетевые кабеля, когда хочется полистать какой-нибудь online-magazin в шезлонге на балконе... Тем более, что декларируемые 54 Mbit/sec OFTM "выливаются" во вполне приличные 20Mbit/sec. Не говоря уже о тех случаях, когда прокладка кабеля просто не представляется возможной или уж вовсе "лениво" дырявить очередное шлакобетонное перекрытие. С учётом нынешней стоимости оборудования Wi-Fi (~20$ за адаптер и ~70$ за аналог hub-а) ответ во многих случаях очевиден: полюбопытствовать - стоит.

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 с пользой. Не исключено, что для кого-нибудь - уже сейчас.

Wi-Fi. Linux. Краткий курс — 2

Владимир Попов

7 июня 2007 г

     iface eth1 inet dhcp
     wpa-driver wext
     wpa-ssid *your_wpa_essid*
     wpa-ap-scan 1
     wpa-proto WPA
     wpa-pairwise TKIP
     wpa-group TKIP
     wpa-key-mgmt WPA-PSK
     wpa-psk *your_HEX_passcode*

  #!/bin/sh
  /etc/dbus-1/event.d/25NetworkManager stop

  #!/bin/sh
  /etc/dbus-1/event.d/25NetworkManager start

  sudo /etc/dbus-1/event.d/26NetworkManagerDispatcher stop
  sudo /etc/dbus-1/event.d/25NetworkManager stop

  /etc/default/NetworkManager
  /etc/default/NetworkManagerDispatcher