802.1x на страже беспроводных LAN

Недостаточная безопасность беспроводных технологий передачи данных стала едва ли не основным препятствием на пути их проникновения в крупные корпоративные сети. За три года после своего появления на свет протокол Wired Equivalent Protocol (WEP) оказался до такой степени дискредитированным, что реализованные в нем средства аутентификации и шифрования трафика перестали восприниматься как удовлетворяющие строгим критериям защиты данных. Полное фиаско, которое потерпел WEP, заставило производителей обратить свои взоры на стандарт IEEE 802.1x, который позволяет обезопасить как проводные, так и беспроводные локальные сети. Однако до последнего времени основным камнем преткновения для внедрения 802.1x оставалась проблема взаимодействия разработок разных фирм.

Решив организовать первое открытое тестирование на совместимость продуктов, соответствующих стандарту 802.1x, сотрудники редакции Network World и компании iLabs задались целью проверить, насколько слаженно функционируют различные части беспроводной сети с точки зрения спецификаций информационной безопасности. В испытаниях приняли участие пять клиентских программ, разработанных Cisco Systems, Funk Software, Hewlett-Packard, Meetinghouse Data Communications и Microsoft, шесть точек доступа для сетей 802.11b производства 3Com, Cisco, Enterasys Networks, Karlnet, Symbol Technologies и Wind River Systems, два коммутатора проводных сетей (они поддерживали стандарт 802.1x и в ходе тестирования отвечали за процедуры аутентификации) от Cisco и Hewlett-Packard, а также пять серверов аутентификации фирм Funk, Hewlett-Packard, Interlink Electronics, Microsoft и Secure Computing, которые обрабатывали клиентские запросы на аутентификацию по протоколу 802.1x с использованием технологии Remote Authentication Dial-in User Service (RADIUS).

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

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

Как «приготовить блюдо» 802.1x?

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

Клиентскому ПО предстоит «общаться» с центром аутентификации. В роли последнего может выступать беспроводная точка доступа либо коммутатор локальных сетей, оснащенный средствами поддержки 802.1x.

Сама процедура аутентификации выполняется на сервере аутентификации. Обычно это сервер RADIUS, дополненный средствами поддержки Extensible Authentication Protocol (EAP). С технической точки зрения в установке выделенного сервера RADIUS особой необходимости нет: в небольшой сети его функции можно возложить на беспроводную точку доступа. Но как только речь заходит о беспроводной сети корпоративного масштаба, без специального сервера аутентификации не обойтись, ведь только его присутствие обеспечивает централизованное управление процедурами аутентификации и требуемый уровень масштабируемости.

Наконец, работа сервера аутентификации предполагает постоянное взаимодействие с базой данных, содержащей служебную информацию о сетевых пользователях. Такая БД может представлять собой простой список регистрационных имен пользователей и их паролей, каталог, основанный на протоколе LDAP (Lightweight Directory Access Protocol), или полноценную базу данных, которая поддерживает запросы на языке SQL. Иногда для целей аутентификации используются цифровые сертификаты, выдаваемые сервером PKI (Public Key Infrastructure).

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

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

Клиентское ПО

Выбор клиентских программных средств, поддерживающих стандарт 802.1x, на сегодняшний день крайне ограничен. Если вы перешли на Windows XP или на .Net-версию Windows CE, считайте, что вам повезло: в эти операционные системы средства 802.1x встроены изначально. С другими платформами дело обстоит гораздо сложнее.

Компании Funk Software и Meetinghouse предлагают клиентское ПО для ОС, предшествовавших Windows XP. Кроме того, в арсенале Meetinghouse — клиентская часть под Linux, поставляемая бесплатно. Программу-клиент 802.1x с общедоступным кодом под Linux написала также группа Open1x, организованная в Университете шт. Мэриленд. Ожидается, что в будущем ее же силами будет создана версия под Unix BSD.

Корпорация Cisco в качестве промежуточного шага на пути к обеспечению полной поддержки спецификаций 802.1x в своих продуктах разработала нестандартную версию процедуры аутентификации, получившую название Lightweight EAP (LEAP). В настоящее время средства LEAP встроены в драйверы радиоадаптеров этой фирмы, относящихся к семействам Aironet, а также в ее точки доступа. Поддержка LEAP доступна для большинства Windows-платформ, Macintosh и Linux.

Сетевые администраторы, остановившие свой выбор на этом промежуточном решении Cisco, вряд ли столкнутся с какими-то проблемами несовместимости. Во всяком случае, в ходе тестирования оборудование Cisco со средствами LEAP и устройства, непосредственно поддерживающие стандарт 802.1x, успешно взаимодействовали с одним и тем же сервером RADIUS.

Другой немаловажный аспект, который следует принять во внимание при выборе клиентских средств 802.1x, связан с их способностью поддерживать тот метод аутентификации, который реализован в вашей беспроводной среде. Хотя протоколом EAP предусмотрено более десяти различных методов аутентификации, широкое распространение получили только четыре. Помимо уже упоминавшейся процедуры LEAP компании Cisco, к ним относятся:

• Message Digest 5 (MD5) — процедура односторонней аутентификации клиента сетевым сервером, основанная на применении паролей;
• Transport Layer Security (TLS) — процедура взаимной аутентификации, которая предполагает использование цифровых сертификатов, выданных PKI;
• Tunneled TLS (TTLS) — метод, сочетающий в себе применение сертификатов и других средств идентификации, например паролей или маркеров.

В процессе тестирования применялись все четыре названных метода. Несмотря на то что протокол LEAP не обеспечивает максимального уровня защиты, он поддерживает наибольшее число платформ — правда, при условии, что вы решитесь закупить радиокарты Aironet для своих настольных и портативных компьютеров.

С точки зрения установки и настройки конфигурации простейшим является метод MD5, однако он обеспечивает и самый низкий уровень сетевой безопасности. Действие данного метода распространяется только на клиента, «полномочия» же самой сети не проверяются. В результате она оказывается открытой для внешних атак, основанных на модификации данных в процессе их передачи. Целесообразность применения продуктов, использующих только метод MD5, оказывается под большим вопросом, вот почему при всей своей простоте он поддерживается далеко не всяким клиентским приложением сетевой защиты и сервером аутентификации. Атака на сеть, в которой задействован метод аутентификации MD5, — не такое уж простое дело (она не может быть предпринята дистанционно), однако, в сущности, злоумышленнику достаточно оказаться к клиенту ближе, чем точка доступа.

К сожалению, при выборе любого метода, более совершенного, чем MD5, требуется установка сервера PKI для генерации цифровых сертификатов. В процессе тестирования мы воспользовались средствами выдачи сертификатов, встроенными в операционную систему Windows 2000 Server.

Метод TLS предполагает использование сертификатов как на сервере аутентификации, так и на станции-клиенте. По сути дела, это тот же самый протокол, который используется Web-серверами при операциях с URL-указателями, а также с почтовыми сервисами, основанными на протоколах SMTP, POP и IMAP. Если в вашей сети уже имеется сервер, поддерживающий PKI, методу TLS практически нет альтернативы. К его достоинствам следует отнести стандартизованность и применение только «устоявшихся» сетевых протоколов. В процессе тестирования мы проверяли работу средств TLS для различных клиентских приложений и даже для последней модели принтера компании Hewlett-Packard, рассчитанного на работу в беспроводной сети и поддерживающего спецификации 802.1x. Все конфигурации оказались полностью работоспособными.

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

Единственная проблема, связанная с TTLS, состоит в том, что формально этот метод имеет статус предложения, направленного в консорциум IETF. Нет никакой гарантии, что когда-либо он будет стандартизован. На сегодняшний день поддержку TTLS реализовали только компании Funk Software и Meetinghouse. Приятная же новость такова: при работе с методами TLS и TTLS мы не столкнулись с какими-либо случаями несовместимости продуктов.

Логично было бы предположить, что выбор конкретной модели адаптера для установки в устройства беспроводной сети не должен иметь решающего значения. По сути дела, так оно и оказалось. Для работы клиентских приложений, поддерживающих стандарт 802.1x, в среде Windows 2000 нам пришлось установить самые последние версии NDIS-драйверов радиокарт, поскольку некоторые из определений объектов сети 802.11, на которых базируется стандарт 802.1x, были включены в состав Windows Developer Kit лишь после появления спецификации NDIS Version 5.0. Из шести протестированных радиоадаптеров у пяти драйверы уже содержали необходимые обновления.

Аутентификаторы

Сетевые ресурсы с таким многообещающим названием в действительности выполняют одну простую функцию: извлекают из пакетов 802.1x информацию, относящуюся к протоколу EAP, и запаковывают ее в пакеты RADIUS для пересылки на сервер аутентификации. По этой причине мы ожидали, что любой аутентификатор, поддерживающий стандарт 802.1x, в процессе тестирования будет работать безукоризненно. Оказалось же, что некоторые аутентификаторы только принимали EAP-пакеты, а затем блокировали выполнение процедур аутентификации.

При выборе того или иного аутентификатора (другими словами, определенной беспроводной точки доступа) стоит удостовериться в том, что он поддерживает не только сам стандарт 802.1x, но и применяемый метод аутентификации (MD5, TLS, TTLS и т. д.).

Нам удалось понаблюдать за работой аутентификаторов, которые были реализованы в коммутаторах для корпоративных сетей производства Cisco и Hewlett-Packard со встроенными средствами поддержки 802.1x. Тестирование этих моделей, предназначенных для традиционных проводных сетей, не выявило никаких проблем. Мы даже прибегли к применению некоторых дополнительных схем (например, к коммутации виртуальных локальных сетей на основе идентификаторов пользователей) с целью оценить функциональный диапазон технологии 802.1x, выходящий за рамки простой аутентификации.

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

В то же время использование WEP-ключей поддерживается далеко не каждым методом аутентификации. Для некоторых комбинаций «точка доступа/сетевой адаптер/клиентское ПО» мы обнаружили определенную несогласованность при попытке настроить конфигурацию протокола WEP и процедуры генерации WEP-ключей. Надо ли говорить, что синхронизация клиента и аутентификатора имеет решающее значение для достижения высокого уровня безопасности сети в целом, ведь аутентификация без последующего шифрования данных по протоколу WEP лишена всякого смысла.

Серверы аутентификации

Помимо четырех RADIUS-серверов компаний Funk, Hewlett-Packard, Interlink Electronics и Microsoft, совместимых со стандартом 802.1x, в нашем распоряжении оказался сервер Premier Access фирмы Secure Computing. Сам по себе он не поддерживает протокола EAP, а требует для этой цели наличия дополнительного продукта, например, производства Funk или Interlink.

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

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

При выборе сервера аутентификации стоит получить от производителей самую свежую информацию о возможностях предлагаемых ими продуктов, поскольку сегодня они развиваются гораздо динамичнее остальных компонентов, формирующих инфраструктуру 802.1x в беспроводной сети. Возможно, какие-то изменения проявятся уже в ходе следующего этапа тестирования продуктов 802.1x, которое запланировано на август — время проведения выставки Networld+Interop 2002 в Атланте (шт. Джорджия, США).

Только факты

Цель тестирования: проверка возможностей защиты беспроводной сети и способности разных продуктов, поддерживающих стандарт 802.1x, взаимодействовать друг с другом.

Число протестированных продуктов: 40.

Основной результат: выбор продуктов, которым предстоит совместно функционировать в беспроводной сети, определяется применяемым методом аутентификации.