Применение стандарта 802. IX для контроля доступа в локальную вычислительную сеть Текст научной статьи по специальности «Компьютерные и информационные науки»

ПРИМЕНЕНИЕ СТАНДАРТА 802.1X ДЛЯ КОНТРОЛЯ ДОСТУПА В ЛОКАЛЬНУЮ ВЫЧИСЛИТЕЛЬНУЮ СЕТЬ

А.Л. Липатов (ЗАО «Лаборатория противодействия промышленному шпионажу»),

А.Н. Русинов, Е.А. Салмин Научный руководитель - доктор технических наук, профессор А.Г. Коробейников

В статье рассмотрены возможности протокола 802.1x для контроля доступа в локальную вычислительную сеть и примеры реализации данного протокола. Также рассмотрены недостатки протокола и пути их решения.

Введение

Одним из наиболее незащищенных компонентов в локальной вычислительной сети является коммутационная розетка. Любой, имеющий физический доступ к коммутационной розетке, может подключиться в ЛВС и произвести DoS атаку, получить несанкционированный доступ к информационным ресурсам организации, используя многочисленные уязвимости программного обеспечения, либо использовать снифер для прослушивания трафика сети организации. В данной статье рассматриваются имеющиеся решения данной проблемы на базе оборудования и программного обеспечения Cisco и Microsoft. Перечислим их.

Если известно, что коммутационная розетка не будет использоваться, то соответствующий порт на коммутаторе отключается командой shutdown. Если кто-либо захочет использовать розетку, ему необходимо будет обратиться к сетевому администратору для включения соответствующего порта коммутатора. Данное решение связано с увеличением стоимости владения ЛВС, особенно при большом количестве мобильных пользователей. Кроме того, оно не мешает злоумышленнику отключить от работающего порта оборудования и получить доступ в ЛВС.

Другим подходом к решению вышеописанной проблемы является использование функции port security на всех портах коммутатора. При данном подходе происходит регистрация на коммутаторе MAC-адреса устройства, который будет использовать порт. При возникновении трафика от устройств с другим MAC-адресом возможно временное отключение соответствующего порта коммутатора или полная блокировка последующего трафика. Данное решение кажется приемлемым до тех пор, пока вы не начнете прописывать для каждого порта коммутатора соответствующие ему валидные MAC-адреса. Возможно динамическое обучение MAC-адресов на порте коммутатора, однако и в этом случае при перемещении устройства потребуется переконфигурация коммутатора, что нельзя считать масштабируемым подходом.

В настоящее время перспективным решением по контролю доступа в ЛВС является внедрение в проводных и беспроводных сетях протокола 802.1x. Этот подход и будет рассмотрен в статье.

Стандарт 802.1x

Стандарт 802.1x описывает процедуру передачи EAP-сообщений сервером доступа (например, коммутатором или беспроводной точкой доступа) в проводных или беспроводных Ethernet-сетях. При этом стандарт 802.1x напрямую упаковывает EAP и сообщения в Ethernet-кадры, не применяя для их передачи протокол PPP. Это вызвано тем, что использовать протокол PPP во многих случаях не обязательно - например, при подключении Ethernet-рабочей станции, не поддерживающей протокол TCP/IP, или в том случае, когда использование протокола PPP является избыточным.

В стандарте 802.1x определяется три основных элемента:

• аппликант - пользователь, который нуждается в сетевой аутентификации;

• сервер аутентификации - обычно RADIUS-сервер, который производит фактическую аутентификацию;

• аутентификатор - сетевое устройство, находящееся между аппликантом и сервером аутентификации и предоставляющее доступ в сеть, например, точка доступа или Ethernet-коммутатор.

Ключевым моментом здесь является то, что сетевые устройства - аутентификато-ры - могут быть достаточно простыми, поскольку для реализации функций 802.1x в них требуются минимальные аппаратные затраты, в то время как весь интеллект концентрируется в RADIUS-сервере. Такая схема имеет дополнительные выгоды и позволяет организовать тесную интеграцию управления сетевым оборудованием и сетевым ПО, что значительно облегчает управление информационной системой большого предприятия в целом. Протокол передачи EAP-сообщений в стандарте 802.1x называется EAPOL (EAP encapsulation over LAN) и в настоящее время определен для Ethernet ЛВС, а также беспроводных сетей стандартов серии IEEE 802.11 и ЛВС, использующих технологии token ring и FDDI.

Схема работы протокола EAPOL достаточно проста. Можно выделить следующие основные режимы работы.

1. Аутентификатор посылает запрос на аутентификацию (EAP-Request/Identity) ап-пликанту, как только он определит, что какой-то из его Ethernet-портов перешел в активное состояние (link active), т.е. к нему подключен сетевой адаптер. Таким образом, если отключить клиентскую станцию, которая уже прошла аутентификацию, и снова подключить к сетевому порту, то потребуется пройти аутентификацию еще раз.

2. Аппликант посылает сообщение/ответ (EAPResponse/Identity) аутентификатору, которое затем передается им на сервер аутентификации (RADIUS).

3. Сервер аутентификации в ответ отсылает пакет-запрос (challenge) аутентификатору, который затем переупаковывает его из IP-транспорта в EAPOL и передает аппликанту. В различных схемах аутентификации число таких сообщений может изменяться. В EAP поддерживается как аутентификация клиентской стороны, так и взаимная «сильная» аутентификация клиента и сервера, но только последний вариант считается приемлемым для использования в беспроводных сетях.

4. Аппликант отвечает на запрос соответственно выбранному алгоритму и передает его аутентификатору, который пересылает его на сервер аутентификации.

5. Если аппликант предоставляет правильный ответ на запрос, сервер посылает сообщение об успешной аутентификации аппликанту. В этой ситуации аутенти-фикатор открывает клиенту доступ к ЛВС, который может зависеть от дополнительных параметров, передаваемых ему RADIUS-сервером, например, от номера VLAN или определенного уровня качества обслуживания.

Таким образом, использование сетевой аутентификации позволяет предоставлять пользователю определенный номер ВЛВС или уровень качества обслуживания вне зависимости от точки подключения в корпоративную ЛВС. Это обеспечивает как мобильность пользователей, так и постоянное соблюдение профиля безопасности сети -если даже сетевые кабели будут случайно перепутаны, пользователь не сможет войти в ВЛВС, доступ к которой ему запрещен [1].

Протокол RADIUS

Протокол RADIUS часто используется в различных сетевых устройствах (маршрутизаторы, модемные стойки, коммутаторы и т.д.) для аутентификации пользовате-

лей. Основной причиной этого является то, что сетевые устройства имеют обычно очень ограниченные аппаратные ресурсы и не могут хранить в памяти информацию о большом числе пользователей.

Протокол RADIUS обеспечивает централизованное управление пользователями, что очень важно в целом ряде случаев. Например, Интернет-провайдеры могут иметь десятки и даже сотни тысяч пользователей, и разместить такой объем информации в памяти любого сетевого устройства просто невозможно. При этом число пользователей может постоянно варьироваться в течение суток, дня или часа. Именно поэтому необходимо иметь централизованную базу данных, где хранится информация обо всех пользователях. Следует отметить, что протокол RADIUS поддерживается практически всеми производителями сетевого оборудования, в то время как другие протоколы аутентификации удаленных пользователей не получили массовой поддержки со стороны производителей.

Протокол RADIUS также имеет встроенные механизмы защиты от целого ряда сетевых атак, включая использование сетевых сниферов для получения паролей пользователей. Основными соперниками RADIUS на поле удаленной аутентификации являются протоколы TACACS+ и LDAP. Протокол LDAP изначально не имеет никаких средств защиты от снифинга паролей, и хотя в протоколе TACACS+ (в отличие от RADIUS) шифруется весь трафик, а не только пользовательские пароли, он также не лишен ряда слабых сторон.

Структура сообщения протокола RADIUS представлена на рисунке (RFC 2138), а значения и расшифровка поля Соёе - в таблице под рисунком.

Поле Identifier длиной один байт устанавливается RADIUS-клиентом в ответ на запрос RADIUS-сервера. Поле атрибутов содержит имя пользователя и пароль и также позволяет передавать дополнительные данные о клиенте от RADIUS-сервера сетевым устройствам, к которым непосредственно подключены пользователи.

Для прохождения аутентификации на сервере клиент создает запрос доступа (Access-Request) и передает его RADIUS-серверу, поле атрибутов данного сообщения должно включать как минимум имя пользователя и пароль. Поле идентификации запроса доступа также создается клиентом. Этот процесс не регламентируется в самом протоколе RADIUS, но обычно поле реализуется как простой счетчик, который увеличивается на 1 при каждом новом запросе. Запрос доступа содержит 16-байтное поле запроса аутентификатора (Request Authenticator), которое генерируется случайным образом. Данное сообщение в целом не защищено, шифруются только поля атрибутов, содержащие имя пользователя и пароль. Для этого клиент и сервер имеют общий секрет. Общий секрет совместно с полем запроса аутентификатора используется для вычисления 16-байтного значения (с помощью хэш-функции MD5), которое затем объединяется с паролем пользователя.

После получения сообщения запроса доступа RADIUS-сервер проверяет, обладает ли он общим секретом с клиентом, и если нет, то сообщение просто сбрасывается без уведомления клиента. Поскольку сервер также обладает общим секретом с клиентом, он может вычислить незашифрованное имя и пароль клиента (через процедуру, обратную описанной выше). Затем имя и пароль сверяются с пользовательской базой данных.

В случае успешной проверки имени и пароля пользователя сервер создает сообщение разрешения доступа и передает его пользователю, в обратном случае он получает сообщение об отказе в доступе. Оба сообщения имеют одинаковые номера идентификаторов, равные номеру идентификатора в запросе доступа клиента. Поле ответа аутентификатора (Response Authenticator) вычисляется с помощью применения хэш-функции MD5 над полями запроса аутентификатора и полями пакета разрешения доступа. Когда клиент получает сообщение-ответ от сервера, он проверяет, отсылал ли ра-

нее запрос с номером идентификатора, который указан в сообщении, и если нет, то оно просто сбрасывается. Далее клиент декодирует поле ответа аутентификатора с помощью процедуры, обратной вышеописанной, и сравнивает полученный результат с полем аутентификатора в поле запроса. Это гарантирует взаимную проверку клиента и сервера и делает практически невозможными хакерские атаки, основанные на подмене сервера [2].

Существующие недостатки в протоколе 802.1x и возможные пути их решения

Стандарт 802.1х является идеальным фундаментом для обеспечения безопасности беспроводных сетей, что уже неоднократно было продемонстрировано в материалах конференций и документации на веб-узле корпорации Майкрософт (http://www.microsoft.com/wifi(EN)). Но развертывание 802.1х без каких-либо дополнительных действий по защите проводных сетей от вредоносных компьютеров имеет серьезные недостатки. Одним из таких недостатков является сложность работы с устройствами, не поддерживающими этот стандарт. Другой недостаток - отсутствие управляемости: групповая политика AD предусматривает несколько объектов для управления 802.1х в беспроводных сетях, а для проводных интерфейсов таких объектов групповой политики не существует, как не существует и опубликованных интерфейсов прикладных программ (API) для управления клиентскими компьютерами в проводных сетях 802.1х. Отсутствие таких объектов групповой политики для проводных сетей 802.1х в Windows 2000 и Windows XP обусловлено рядом причин архитектурного свойства. Ввиду отсутствия централизованного управления крупномасштабное развертывание 802.1х в среде Windows в настоящий момент неосуществимо и повлечет большие расходы на поддержку.

Наконец, в протоколе есть одно чрезвычайно важное слабое место: проверка подлинности производится только при установлении подключения (в некоторых реализациях предусмотрена периодическая повторная проверка, но она не снижает риск атаки, описываемой ниже). После того, как подлинность просителя проверена и порт коммутатора открыт, дальнейший обмен данными между просителем и коммутатором осуществляется без проверки подлинности. Это создает ситуацию, в которой злоумышленник может подключиться к сети. (Хотелось бы поблагодарить Святослава Пидгорного, опытного специалиста по безопасности корпорации Майкрософт, который указал на эту уязвимость).

Подготовка этой атаки требует физического доступа к сети, поэтому в некоторых отношениях она является эзотерической. Атакующему требуется отключить компьютер (который мы будем называть «жертвой») от порта коммутатора сети, защищенной протоколом 802.1х, подключить к порту концентратор, подключить «жертву» к концентратору, а затем к тому же концентратору подключить атакующий компьютер (который мы будем называть «тенью»). Это тривиальная задача, если атакующий физически находится на вашей территории и имеет доступ к вашим разъемам Ethernet. Как вариант, атакующий может подключить к концентратору неконтролируемую точку беспроводного доступа, а затем произвести атаку с автостоянки вашего предприятия. (Разумеется, атакующий попытается скрыть свое присутствие, отключив трансляцию SSID этой точки доступа.)

Кратковременное отключение «жертвы» от сети не помешает успеху атаки. Когда компьютер-«жертва» снова подключится к сети, он снова успешно пройдет проверку подлинности на коммутаторе. Теперь наличие на пути коммутатора не будет играть роли, поскольку в основе своей коммутатор - всего лишь удлинитель с несколькими портами. Электрическое соединение «жертвы» с коммутатором по-прежнему присутствует. Концентраторы невидимы для протокола 802.1х.

Проделав все вышеописанное, атакующий настраивает MAC-адрес и IP-адрес своего компьютера так, чтобы они совпадали с адресами компьютера-«жертвы». Быстро определить эти адреса поможет анализ пакетов. Атакующий также настраивает на своем компьютере брандмауэр, который игнорирует весь входящий трафик, не являющийся ответом на инициированные им запросы.

Теперь рассмотрим принцип работы этой атаки. После успешной проверки подлинности компьютера-«жертвы» и открытия порта коммутатора атакующий получает доступ к ресурсам в защищенной сети. Это происходит из-за отсутствия попакетной проверки подлинности трафика после того, как порт был открыт. Поскольку компью-тер-«тень» имеет те же MAC- и IP-адреса, что и компьютер-«жертва», с точки зрения коммутатора они представляют собой один компьютер, подключенный к порту. Итак, отсутствие последующей попакетной проверки подлинности в 802.1х создает условия для только что описанной атаки. Протокол 802.1х обеспечивает проверку подлинности только для самого подключения, предполагая, что весь трафик, идущий через это подключение, является санкционированным.

Обратим внимание, что обмен данными возможен только по протоколам без сохранения состояния - например, ICMP или UDP. Таким образом, атакующий может посылать тестовые запросы командой ping на компьютеры в сети и получить временный IP-адрес от DHCP-сервера (тот же IP-адрес, что и у «жертвы»), однако он не может вести обмен данными в сети по протоколу TCP: компьютер-«жертва» будет сбрасывать любые подключения, инициированные «тенью». Вот как это происходит.

• Компьютер-«тень» посылает пакет SYN на сервер в защищенной сети.

• Сервер возвращает пакет ACK-SYN, который принимается как «тенью», так и «жертвой».

• Компьютер-«жертва» не ожидает этого пакета ACK-SYN, поэтому отвечает серверу пакетом RST. В это время «тень» отвечает серверу пакетом ACK.

• Если пакет RST «жертвы» достигает сервера первым, сервер закрывает подключение и не обрабатывает пакет ACK от «тени». Если же первым приходит пакет ACK, посланный «тенью», то соединение устанавливается, но тотчас же разрывается приходящим вслед пакетом RST от «жертвы».

У этого правила есть одно интересное исключение. Если на компьютере-«жертве» работает межсетевой экран, отбрасывающий входящие пакеты ACK-SYN, на которые не было запроса (а большинство межсетевых экранов настроено именно так), то «жертва» не обработает принятый на шаге 2 пакет ACK-SYN, а, следовательно, и не отправит на сервер пакет RST. Оставшаяся часть описанного выше процесса выполнена не будет, и компьютер-«тень» сможет получить полный доступ в защищенную сеть. Это единственный известный авторам случай, когда наличие индивидуального межсетевого экрана на компьютере может уменьшить безопасность остальной части сети! Разумеется, это не является поводом для отказа от развертывания межсетевых экранов; выгоды от их использования значительно перевешивают вероятность фактической реализации этой атаки.

Вышеописанная ситуация возможна вследствие того, что протокол 802.1x проверяет вализность прохождения только первого пакета, но не проверяет каждый пакет в отдельности. В случае повышенных требований к информационной безопасности ЛВС, возможно, стоит рассмотреть вариант одновременного развертывания 802.1х и IPsec. Так, протокол AH обеспечивает аутентификацию каждого пакета.

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

передаче фрейма (CRC). Но что если CRC будет представлять функцию не только от содержимого фрейма, но и от ключа, согласованного при отработке протокола 802.1x? В результате мы получаем проверку каждого фрейма коммутатором на отсутствие ошибок и на валидность отправителя, при этом, если реализовать данную функцию ап-паратно, не произойдет увеличения задержки и нагрузки на коммутатор при прохождении фрейма через коммутатор. Существующие реализации протокола 802.1x поддерживают периодическую реаутентификацию аппликанта. При этом можно менять и ключ, используемый при расчете CRC, что обеспечивает стойкость к взлому ключа злоумышленником.

Также следует подчеркнуть, что имеющиеся решения для внедрения протокола 802.1x реализуют только проверку подлинности компьютера/пользователя. Между тем компьютер, имеющий валидные аутентификационные данные, также может представлять угрозу для ЛВС, например, в случае устаревшей антивирусной базы данных, отсутствия обновлений безопасности программного обеспечения, установленного нелицензионного программного обеспечения. Теоретически на базе протокола 802.1x можно реализовать проверку любого рода. Для этого необходимо внести изменения в программное обеспечение сервера аутентификации и аппликанта.

Конфигурация 802.1x на коммутаторе

Следующие коммутаторы Cisco могут быть использованы в качестве аутентификатора:

• Catalyst 6500/6000;

• Catalyst 5500/5000;

• Catalyst 4500/4000;

• Catalyst 3750/3550;

• Catalyst 2950;

со следующими установленными операционными системами:

• CAT 6.2 или выше;

• Cisco IOS 12.1(6) EA2 или выше.

При конфигурации контроля доступа на коммутаторе прежде всего необходимо указать IP адрес сервера RADIUS:

Switch#conf t

Switch (config)#aaa new-model

Switch (config)#radius-server host 192.168.100.100 Switch (config)#radius-server key 123qweASD

Далее необходимо включить процесс аутентификации 802.1x. В результате коммутатор становится аутентификатором. Для конфигурации коммутатора в качестве ау-тентификатора необходимо ввести следующие команды:

Switch (config)#aaa authentication dot1x default group radius

Последним шагом является конфигурация портов коммутатора. Порт коммутатора может быть в трех режимах:

• force-authorized - режим по умолчанию. В данном режиме порт всегда авторизован. Этот режим используется, если вы не хотите использовать 802.1x на определенном порту (например, при подключении к маршрутизатору или коммутатору);

• auto - нормальный режим для 802.1x. Порт в режиме авто посылает EAP пакеты серверу аутентификации и не переходит в авторизованное состояние без получения положительного ответа от сервера аутентификации;

• force-unauthorized - в данном режиме порт не перейдет в авторизованное состояние, даже если пользователь представит валидные учетные данные.

Для конфигурации режима функционирования порта коммутатора необходимо использовать следующие команды:

Switch#conf t

Switch (config)#interface fastethernet mod/port

Switch (config-if)#dot1x port-control [auto | force-authorized | force-unauthorized]

После конфигурации коммутатора в режиме auto пользователи, подключенные к данному порту, не смогут передавать трафик через порт до тех пор, пока не будут авторизованы сервером аутентификации.

Важным моментом в данной схеме является то, что при использовании RADIUS-сервера появляется возможность назначать номер VLAN в зависимости от аутентификации пользователя [3].

Заключение

В настоящее время протокол 802.1x только начинает внедряться в проводных локальных вычислительных сетях, и внедрение это никак нельзя назвать массовым. Данный факт связан во многом с пренебрежением решениями по информационной безопасности в организациях, тем более, если соответствующие решения связаны с начальными расходами и увеличением стоимости владения сетевой инфраструктурой. Также к причинам медленного внедрения данного протокола можно отнести и его недостатки, а также то, что его теоретические возможности использованы не полностью. В статье выдвинут ряд предложений по усовершенствованию прокола, которые требуют внесения изменений в имеющееся программное и аппаратное обеспечение, в связи с чем в рамках статьи предложения были обозначены, но не реализованы.

Литература

1. 802.1X - Port Based Network Access Control. Institute of Electrical and Electronics Engineers, Inc. (http://www.ieee802.org/1/pages/802.1x.html).

2. RFC3580. IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines. Author: P. Congdon, B. Aboba, A. Smith, G. Zorn, J. Roese.

3. Catalyst 3750 Switch Software Configuration Guide, 12.2(25)SEE (http://www.cisco.com/en/US/products/hw/switches/ps5023/products_installation_and_co nfiguration_guides_list.html).