Безопасность беспроводных сетей О способах обнаружения, взломе и уязвимостей беспроводных сетей разного рода уже сказано и написано много, но о том, как защититься от всех этих вещей, почему-то помалкивают. Все потому, что эта тема была отложена для отдельного материала, который ты читаешь прямо сейчас. Что ж, вперед! Обезопасим свое личное воздушное пространство от набегов вардрайверов. Обеспечение безопасности Wi-Fi-соединений уже давно стало притчей во языцех. Отсутствие проводов окончательно развязало руки охочим до конфиденциальной информации злоумышленникам, среди которых может оказаться не только сосед по локальной сети, развлекающийся ARP-спуфингом, а любой человек с ноутбуком, находящийся в пределах досягаемости беспроводной сети. Призванный спасти несчастных пользователей, протокол авторизации, аутентификации и шифрования WEP совершенно не оправдал надежд, как и его вторая инкарнация WEP2 (в ней, по сути, декларировалось только увеличение длины ключа). Современные средства позволяют сломать 128-битный WEP-ключ за несколько часов присутствия в сети. Стандарт безопасности 802.11i и, в частности, стандарт WPA/WPA2, являющийся подмножеством 802.11i, по ряду причин все еще недостаточно распространены. И на данный момент ситуация складывается таким образом, что для обеспечения безопасности беспроводной сети администратор вынужден прибегать к полумерам и/или к старым проверенным технологиям, которые не разрабатывались специально для Wi-Fi. Именно о них я расскажу в первую очередь, а потом займусь 802.11i. Опасность в воздухе Прежде чем начать строительство круговой обороны, выясним, от чего мы хотим защититься. Для беспроводных сетей основными проблемами безопасности являются: - Мониторинг и перехват трафика; - Подключение к сети неавторизованных клиентов (внедрение подложных пакетов); - DoS-атаки на беспроводную сеть; - Атаки типа Evil Twin - внедрение подложного AP; - Атаки на клиентские машины; - Атаки на AP (в том числе из-за уязвимостей в конфигурации точки доступа). С последними двумя атаками все понятно: нужно своевременно патчить клиентские машины и грамотно настраивать AP, например отключить SNMP либо сменить на отличающуюся от SNMP community string по умолчанию, поставить сложный пароль на доступ к административному интерфейсу AP, своевременно обновлять прошивки и т.п. Многие AP умеют фильтровать доступ по MAC-адресу, и одной из полумер является как раз прописывание легитимных клиентов в ACL точки доступа. Однако такими способами не остановишь опытного взломщика, стремящегося проникнуть сеть, да и от перехвата конфиденциальной информации, летающей по воздуху, не защитишься. Для того чтобы пассивно снифать весь трафик, совершенно не обязательно подключаться к какой-либо сети. Следовательно, нужно какое-то решение, осуществляющее, как минимум, шифрование трафика и авторизацию клиента в сети. И такое решение называется IPSec. Очень понятное и детальное описание этого протокола "в картинках" можно почитать тут: www.unixwiz.net/techtips/iguide-ipsec.html. Нас же интересует практическая сторона вопроса. Старый добрый IPSec Типичная схема подключения беспроводных клиентов в режиме Infrastructure (то есть с точкой доступа) выглядит следующим образом: [client]- ))) ((( -[AP]----[gateway]---- В такой схеме точка доступа играет роль моста между беспроводным и проводным сегментами сети (не путать с bridging mode!), а сама беспроводная сеть выделена в отдельный сегмент и роутится шлюзом в проводную LAN и/или интернет. Можно, конечно, подключить AP непосредственно к проводному сегменту сети, и тогда беспроводные клиенты будут в одной подсети с остальными. Но не рекомендую. Для использования IPSec необходимо настроить соответствующую политику на шлюзе, через который проходит трафик с AP. Если говорить в терминах IPSec, требуется указать правила ассоциации (Security Association), описывающие, что использовать (протокол AH или ESP), алгоритм шифрования (3DES, AES, и т.д.), тип ключа (IKE или прописать вручную) и политики ассоциации (Security Policy), описывающие, как это использовать (транспортный или туннельный режим; требовать использование ipsec или нет). Приведу конкретный пример, когда в качестве шлюза используется FreeBSD с включенной в ядро опцией IPSEC. Пусть для беспроводных клиентов выделена подсеть 192.168.1.1/24 и адрес шлюза - 192.168.1.1. Тогда для конкретного клиента 192.168.1.3 правила на шлюзе буду выглядеть следующим образом: # flush previous SAD & SPD flush; spdflush; # Security Association Database # For ESP add 192.168.1.1 192.168.1.3 esp 1011 -E 3des-cbc "secretpassphrase"; add 192.168.1.3 192.168.1.1 esp 1012 -E 3des-cbc "secretpassphrase"; # Security Policy Database spdadd 192.168.1.3 0.0.0.0/0 any -P in ipsec esp/tunnel/192.168.1.3-192.168.1.1/require spdadd 0.0.0.0/0 192.168.1.3 any -P out ipsec esp/tunnel/192.168.1.1-192.168.1.3/require Это простейший случай, когда не используется никаких методов распределения ключа - парольная фраза вводится вручную. Стоит акцентировать внимание на выборе режима ipsec - туннельный. Этот режим используется для создания безопасного канала (secure hop) между клиентом и шлюзом, при нем шифруется весь IP-пакет, тогда как транспортный режим используется для создания защищенного канала "точка-точка", и в этом случае шифруется только тело IP-пакета. Следует поместить указанный конфиг в файл /etc/ipsec.conf и перечитать настройки ipsec: # setkey -f /etc/ipsec.conf Если в качестве клиентской ОС используется также FreeBSD, то ее настройка будет точно такой же, только в SPD направления пакета - in и out - поменяются местами. Если в качестве клиента используется Windows, настройка ipsec превратится в увлекательный процесс клацанья мышкой: - Start-> Run. Набираем mmc и жмем . - Console-> Add/Remove Snap In. Выбираем Add-> IP Security Policy Management и жмем Add, где выбираем Local Computer, затем Finish и Close. - Выбираем IP Security Policies в Local Machine, нажимаем правую кнопку мыши и выбираем Create IP Security Policy. - Вбиваем какое-нибудь название политики и жмем Next. - Снимаем галочку Activate и еще раз Next. - Снимаем выделение с Edit Properties. Finish. Теперь у нас появилась новая политика. Аллилуйя! Но это еще не все. * Жмем правую кнопку мыши на вкладке IP Security Policies окна Console Root и выбираем Manage IP filter lists and filter actions, затем жмем Add. * Обзываем список фильтров out, затем снова Add. * Выбираем My IP Address как Source, Any IP Address как destination address. Убираем галочку mirrored. * Добавляем второй список, назовем его in, повторяем описанное, за исключением того, что фильтр с Any IP Address выбираем как Source, a My IP Address как destination adress. Теперь нужно применить эти фильтры. - Два раза щелкаем мышью на созданной политике. - Нажимаем Add-> IP Security Rules. - Выбираем The tunnel endpoint is specified и вводим адрес шлюза. Жмем Next. - Выбираем Lan, жмем Next. - Выбираем Use this string to protect the key exchange, вводим секретную фразу, после чего... (правильно!) Next. - Выбираем созданный список фильтров out, клацаем по Next. - Выбираем Require Security, не забывая давить англоязычный эквивалент нашего "Далее". - Затем повторяем то же самое, только вводим адрес клиентского компьютера и список фильтров - in. Прорвавшись сквозь дебри диалогов и мастеров, наконец можно убедиться, что ipsec работает и клиент с сервером установили ассоциации с помощью все той же setkey: # setkey -DP 0.0.0.0/0[any] 192.168.1.3[any] any in ipsec esp/tunnel/192.168.1.1-192.168.1.3/require ah/tunnel/192.168.1.1-192.168.1.3/use created: Sep 15 03:30:21 2005 lastused: Sep 15 03:40:21 2005 lifetime: 0(s) validtime: 0(s) spid=16390 seq=1 pid=5889 refcnt=2 192.168.1.3[any] 0.0.0.0/0[any] any out ipsec esp/tunnel/192.168.1.3-192.168.1.1/require ah/tunnel/192.168.1.3-192.168.1.1/use created: Sep 15 03:30:21 2005 lastused: Sep 15 03:40:22 2005 lifetime: 0(s) validtime: 0(s) spid=16391 seq=0 pid=5889 refcnt=2 # setkey -D 192.168.1.3 192.168.1.1 ah mode=any spi=1235(0x000004d3) reqid=0(0x00000000) A: hmac-md5 6974736e 69636574 6f736d6f 6b656d61 seq=0x00000304 replay=0 flags=0x00000040 state=mature created: Sep 15 03:30:21 2005 current: Sep 15 03:40:21 2005 diff: 600(s) hard: 0(s) soft: 0(s) last: Sep 15 03:39:20 2005 hard: 0(s) soft: 0(s) current: 135688(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 772 hard: 0 soft: 0 sadb_seq=3 pid=5878 refcnt=2 192.168.1.1 192.168.1.3 ah mode=any spi=1234(0x000004d2) reqid=0(0x00000000) A: hmac-md5 6974736e 69636574 6f736d6f 6b656d61 seq=0x00000350 replay=0 flags=0x00000040 state=mature created: Sep 15 03:30:21 2005 current: Sep 15 03:40:21 2005 diff: 600(s) hard: 0(s) soft: 0(s) last: Sep 15 03:39:25 2005 hard: 0(s) soft: 0(s) current: 531216(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 848 hard: 0 soft: 0 sadb_seq=2 pid=5878 refcnt=1 Кроме того, запущенный tcpdump должен показывать исключительно наличие ESP-пакетов. Теперь весь трафик защищен. Разумеется, данный способ построения IPSec довольно примитивен. Если клиентов много, возникнут задачи дублирования политик, к тому же трудно дергать админа каждый раз, когда новый легитимный клиент подключается к сети. В этом случае, по-моему, удобно использовать цифровой X.509-сертификат клиента в качестве авторизационного документа. Останется лишь выдать новому клиенту сертификат по запросу. Подробную статью с построением беспроводного шлюза с использованием OpenBSD и isakmpd на X.509-сертификатах написал Andrushock в одном из недавних номеров "Хакера". IPSec - надежное, проверенное годами решение. С главной задачей, защитой трафика, он справляется на ура. Есть ли у него минусы? При всех плюсах - да, есть. Например, использование ipsec авторизует клиента в сети (но не на AP!), однако никоим образом не авторизует точку доступа для клиента, то есть не решает проблему подложного AP IPSec, но делает ее в известной мере бессмысленной: через AP злоумышленника все равно будут проходить зашифрованные пакеты либо не будут проходить вообще, в зависимости от того, потеряется ли виртуальный канал "клиент-шлюз". 802.11i и WPA Новый стандарт (хотя разве можно назвать новым стандарт, принятый еще в 2004 году?) определяет не только меры по защите трафика в беспроводных сетях. Эта задача целиком отдается протоколу WPA, который, из-за полной несостоятельности WEP, пришлось даже выпустить раньше, отдельно от 802.11i. WPA предполагает использование протоколов авторизации семейства 802.1x, EAP, TKIP и RADIUS. TKIP здесь как бы приходит на смену WEP, выполняя задачи по защите трафика, а EAP и RADIUS осуществляют авторизацию клиента в сети. Важно, что в стандарте 802.11i вместо TKIP используется алгоритм шифрования AES, но выпущенная отдельно версия WPA изначально предусматривала использование TKIP, так как для AES требовалось более мощное оборудование. Если описывать коротко, совместная работа всех протоколов выглядит следующим образом: клиент авторизуется в RADIUS и затем, совместно с точкой доступа, генерирует сессионный ключ для шифрования трафика. Заметно, что разработчики стандарта серьезно подошли к вопросу обеспечения безопасности в корпоративных сетях. Но как быть SOHO-классу? Для пользователей домашних или малых офисных сетей разработан вариант WPA-PSK (Pre-Shared Key), при котором ключ не генерируется, а вводится пользователем, и необходимость использования сервера авторизации отпадает. Эпилог Как любил говорить профессор Преображенский, "Разруха - в головах, а не в клозетах". Сколько бы стандартов ни разрабатывали, какие бы протоколы ни придумывали, всегда найдутся люди, которым слово "безопасность" ни о чем не говорит. WPA? RADIUS? Вы о чем? 30% точек доступа во всем мире работают с заводскими настройками по умолчанию!