июня 16 2008 10:00 дп

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

«А оно вам надо?»

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

Источник http://citkit.ru





Комментариев нет »


No Responses to “Wi-Fi. Linux. Краткий курс”

  1. mentorr on 30 Июн 2008 at 11:14 #

    Приличная статья, здорово.
    “А оно вам надо?” — безусловно, щас на wi-fi дома сижу, удобно очень с ноутом. Не зная как я раньше с проводами таскался.

  2. Stepanoff on 30 Июн 2008 at 13:22 #

    да, вайвай реально удобная вещь 🙂

Trackback URI | Comments RSS

Leave a Reply

You must be logged in to post a comment.


« | »



Server load average: 0.01, 0.02, 0.00
Server uptime: 47 days, 4:04
Your IP is: 54.234.247.118.