“Исправляем” wep.

Существует несколько процедур, при помощи которых вы можете улучшить безопасность своей сети. На самом деле все ниже перечисленные пункты необходимы на этапе становления сети, но если у вас они не реализованы, то лучше их сделать - чем быстрее тем лучше.

• Используйте длинные WEP ключи, это затруднит хакеру работу. Если оборудование поддерживает 128-битное шифрование, то конечно используйте его.

• Периодически меняйте ключи.

• Размещайте точки доступа за файрволом, вне локальной сети.

• Используйте VPN для всех протоколов, которые могут передавать важную информацию.

• Используйте несколько техник для шифрования трафика, например IPSec. Вероятно надо будет устанавливать софт на клиентах, установить IPSec сервер в локальной сети, использовать VLAN между точкой доступа и сервером. В таком варианте пользователи сети будут организовывать IPSec туннель к серверу и передавать через него все данные.

Если есть возможность, то нужно менять прошивки на всех сетевых устройствах. Например, разработчики AirSnort (см. предыдущую статью) отмечают, что уже не все точки доступа поддаются взлому и на них невозможно взломать WEP ключ. Это работа производителей - обновления постоянно улучшают свои устройства и чем быстрее вы внедрите эти улучшения в свою сеть тем лучше.

Но это конечно не панацея. WEP использует алгоритм RC-4, который по определению уязвим из-за постоянства ключа. Единственное, что в протоколе помогает бороться с этим и изменять значение ключа - 16-битное значение IV. Оно каждые 65.536 пакетов меняет свое значение, и с точки зрения хакера уже не важно какая прошивка используется в сетевом оборудовании - если значение повторяется, следовательно его можно подобрать и проникнуть внутрь. Апгрейд оборудования не стоит игнорировать, но лучше обратить внимание и на сами алгоритмы защиты сети.

Cтандарт ieee 802.11x

Шагом в развитии методов защиты беспроводных сетей было появление стандарта IEEE 802.11X, совместимого с IEEE 802.11. В новом стандарте были использованы протокол расширенной аутентификации Extensible Authentication Protocol (EAP), протокол защиты транспортного уровня Transport Layer Security (TLS) и сервер доступа RADIUS (Remote Access Dial-in User Server). 

В отличие от протокола WEP, стандарт IEEE 802.11X использует динамические 128-битные ключи, периодически меняющиеся во времени. Секретный ключ пересылается пользователю в зашифрованном виде после прохождения этапа аутентификации. Время действия ключа ограничено временем действующего на данный момент сеанса. После окончания текущего сеанса создается новый секретный ключ и снова высылается пользователю. Взаимная аутентификация и целостность передачи данных реализуется протоколом защиты транспортного уровня TLS. Для шифрования данных, как и в протоколе WEP, используется алгоритм RC4 с некоторыми изменениями.

В указанном стандарте были исправлены недостатки технологий безопасности, применяемых в 802.11, — это возможность взлома WEP и зависимость от технологий производителя.

Группа IEEE (Institute of Electrical and Electronic Engineers — Институт инженеров по электротехнике и электронике) утвердила новый стандарт безопасности беспроводных сетей. Названный 802.11i, он содержит дополнительные возможности безопасности беспроводных сетей, такие, как AES (Advanced Encryption Standard) — улучшенный стандарт криптографии.

За основу взято исправление недостатков технологий безопасности, применяемых в 802.11, в частности, возможность взлома WEP, зависимость от технологий производителя и т. п. В 802.1X применяется тот же алгоритм, что и в WEP, а именно — RC4, но с некоторыми отличиями.

802.1X базируется на:

- EAP (Extensible Authentication Protocol). Протокол расширенной аутентификации. Используется совместно с RADIUS сервером в крупных сетях. - TLS (Transport Layer Security). Протокол, который обеспечивает целостность и шифрование передаваемых данных между сервером и клиентом, их взаимную аутентификацию, предотвращая перехват и подмену сообщений. - RADIUS (Remote Authentication Dial-In User Server). Сервер аутентификации пользователей по логину и паролю.

Плюс к этому стоит добавить новую организацию работы клиентов сети. После того, как пользователь прошёл этап аутентификации, ему высылается секретный ключ в зашифрованном виде на определённое незначительное время — время действующего на данный момент сеанса. По завершении этого сеанса генерируется новый ключ и опять высылается пользователю. Протокол защиты транспортного уровня TLS обеспечивает взаимную аутентификацию и целостность передачи данных. Все ключи являются 128-разрядными по умолчанию.

IEEE 802.11x определяет три основных компонента в сетевом окружении:

• Саппликант.

• Сервер аутентификации (authentication server) -- объект, обеспечивающий службы аутентификации. В стандарте четко не определено, что должно выступать в качестве сервера аутентификации, но, как правило, им является сервер RADIUS (Remote Access Dial In User Service).

• Аутентификатор (authenticator) -- объект на конце сегмента "точка--точка" локальной вычислительной сети, который способствует аутентификации объектов. Другими словами -- это устройство-посредник, располагаемое между сервером аутентификации и саппликантом. Обычно его роль выполняет беспроводная точка доступа.

Аутентификация в 802.1x включает несколько шагов. Конкретная схема обмена EAP-кадрами зависит от выбранного способа аутентификации.

В одном из простейших вариантов (OTP -- One Time Password) данный процесс выглядит следующим образом (рис. 2):

1. Рис. 2. Схема аутентификации пользователя в соответствии со стандартом 801.1x

   Саппликант инициирует соединение с аутентификатором (как правило, в соответствии со стандартом это может делать и аутентификатор).

2. Аутентификатор требует идентификационную информацию о саппликанте.

3. Саппликант отсылает идентификационную информацию аутентификатору, который отправляет ее серверу аутентификации.

4. Сервер аутентификации запрашивает у аутентификатора информацию, подтверждающую подлинность саппликанта. Аутентификатор пересылает запрос саппликанту.

5. Саппликант передает информацию, подтверждающую его подлинность, аутентификатору. Аутентификатор отправляет ее серверу аутентификации.

6. Сервер аутентификации проверяет информацию о подлинности саппликанта и в случае успешной аутентификации посылает специальное сообщение аутентификатору, который открывает порт для доступа саппликанту и отправляет ему сообщение о завершении процесса аутентификации.

Temporal Key Integrity Protocol (TKIP) -- второй протокол, предусмотренный спецификацией WPA. TKIP предназначен для решения основных проблем WEP в области шифрования данных. Для совместимости с существующим аппаратным обеспечением TKIP использует тот же алгоритм шифрования, что и WEP -- RC4. TKIP подразумевает несколько способов повышения защищенности беспроводных сетей: динамические ключи, измененный метод генерации ключей, более надежный механизм проверки целостности сообщений, увеличенный по длине вектор инициализации, нумерация пакетов. В отличие от WEP, где для контроля целостности передаваемых данных использовалась CRC-32, TKIP применяет так называемый Message Integrity Code (MIC), обеспечивающий криптографическую контрольную сумму от нескольких полей (адрес источника, адрес назначения и поля данных). Так как классические MIC-алгоритмы (например, HMAC-MD5 или HMAC-SHA1) для существующего беспроводного оборудования являлись очень "тяжелыми" и требовали больших вычислительных затрат, то специально для использования в беспроводных сетях Нильсом Фергюсоном (Niels Ferguson) был разработан алгоритм Michael. Для шифрования он применяет 64-битный ключ и выполняет действия над 32-битными блоками данных. MIC включается в зашифрованную часть фрейма между полем данных и полем ICV.

Рис. 3. Структура пакета при использовании протокола TKIP

Для обеспечения целостности данных в протоколе TKIP, помимо механизма MIC, предусмотрена еще одна функция, отсутствовавшая в WEP, -- нумерация пакетов. В качестве номера используется IV, который теперь называется TKIP Sequence Counter (TSC) и имеет длину 48 бит, в отличие от 24 бит в WEP (рис. 3). Увеличение длины IV до 48 бит позволяет избежать коллизии векторов и гарантирует, что они не повторятся на протяжении более тысячи лет.
Основным и самым важным отличием TKIP от WEP является механизм управления ключами, позволяющий периодически изменять ключи и производить обмен ими между всеми участниками сетевого взаимодействия: саппликантом, аутентификатором и сервером аутентификации. В процессе работы и аутентификации на разных этапах взаимодействия и для различных целей генерируются специализированные ключи.

При аутентификации с помощью протокола IEEE 802.1x на основе заранее предопределенной информации, известной саппликанту и серверу аутентификации (например, сертификат, имя пользователя, пароль и т. д. -- зависит от способа аутентификации), генерируется мастер-ключ (Master Key -- MK), посредством которого они производят взаимную аутентификацию. Далее на основании МК саппликант и сервер аутентификации генерируют парный МК (Pairwise Master Key -- PMK), а затем сервер аутентификации передает (не копирует) его аутентификатору. Получение аутентификатором PMK является последним этапом в процессе EAP-аутентификации, после чего сервер аутентификации посылает аутентификатору пакет "ответ/принято" (RADIUS/Accept), а аутентификатор саппликанту -- "успешно" (EAP/Success). PMK не используется для операции непосредственного шифрования и дешифрования данных, он применяется для генерации целой группы ключей.

После получения саппликантом и аутентификатором PMK они производят взаимную аутентификацию и генерацию парного временного ключа (Pairwise Transient Key -- PTK). Генерация PTK происходит в четыре этапа:

1. В первом сообщении аутентификатор посылает саппликанту случайные данные, называемые nonce. Саппликант объединяет nonce аутентификатора (Anonce) со своим собственным (Snonce) и применяет эти данные для генерации PTK. Далее саппликант подсчитывает значение Message Integrity Check (MIC) от тела второго сообщения и первых 128 бит ключа PTK.

2. Во втором сообщении саппликант посылает Snonce и MIC аутентификатору, который также генерирует PTK и затем использует его для проверки значения MIC, полученного во втором сообщении.

3. Если ошибок не обнаружено, аутентификатор отправляет саппликанту сообщение о применении PTK.

4. В четвертом сообщении саппликант подтверждает аутентификатору использование данного ключа.

PTK является составным. Биты с 0 по 127 представляют собой ключ подтверждения ключа (Key Confirmation Key -- KCK), применяемого для шифрования нового сессионного ключа (PMK) при его следующей смене. Биты со 128 по 255 отводятся для ключа шифрования ключа (Key Encryption Key -- KEK), который используется для распространения группового временного ключа (Group Transient Key -- GTK). Биты с 256-го и выше могут иметь специфическую структуру, зависящую от метода шифрования, и представляют собой временный ключ (Temporal Key -- TK), применяемый для шифрования данных. GTK -- это ключ, используемый для шифрования группового (multicast) и широковещательного (broadcast) трафика. Он генерируется из группового МК (Group Master Key -- GMK), который, в свою очередь, является производным MK. Распространение GTK происходит в два этапа, в отличие от четырех в случае с PTK, так как его доставка выполняется через безопасное соединение после того, как переданы все парные ключи, и аутентификация в данном случае не требуется. При отключении одного из клиентов от сети осуществляются генерация нового ключа GTK и его распространение оставшимся клиентам.

Рис. 4. Процесс формирования пакетного ключа

TK также может быть составным, и его часть или он полностью вместе с MAC-адресом источника (Transmitter Address -- TA) и вектором инициализации (IV) являются входными данными для двухфазовой функции микширования, генерирующей пакетные ключи (Per-packet Key -- PK) длиной 128 бит (рис. 4). Введение в функцию микширования такого параметра, как TA, позволяет избежать атак с использованием подставных объектов. Для домашнего применения и небольших офисов, где, как правило, отсутствует сервер аутентификации, спецификация WPA предусматривает режим использования общего ключа (Pre-Shared Key -- PSK). В этом случае PMK вводится вручную на саппликанте и аутентификаторе. В остальном процедура генерации ключей прежняя.