Трафик IP на предприятиях распространяется на все более критичные для бизнеса области, а с ними и на коммутаторы Ethernet. Помимо передачи голоса по IP протокол Internet проникает в сети хранения данных и управление оборудованием. Растущая зависимость от одной надежной и безопасной инфраструктуры ИТ повышает требования к сетевым компонентам, что свойственно как для магистрали, так и для области доступа
Для следующего поколения приложений на базе IP предприятиям необходимы устройства с высоким уровнем готовности, масштабируемая архитектура, целостный подход к управлению. Избыточные защищенные сети гарантируют длительную работу без сбоев, а значит — непрерывность бизнеса. Системы безопасности должны быть дополнены распределенной аутентификацией, автоматическим распределением правил (корпоративные директивы или правила) и динамическим реагированием на несанкционированное проникновение в инфраструктуру через любые точки доступа.
Все перечисленные меры должны быть реализованы непосредственно на коммутаторе доступа, к которому в этой связи предъявляется ряд требований. Для обеспечения высокого уровня защиты необходимы: надежное управление компонентами, авторизация пользователя и — в качестве альтернативы — подключенного системного аппаратного обеспечения (контроль целостности настольных систем), управление правилами (централизованное задание правил на втором—четвертом уровнях модели OSI), а также динамическая реконфигурация сети при возникновении опасности. Для качества услуг (Quality of Service, QoS) требуются распознавание и классификация трафика на втором—четвертом уровнях модели OSI, автоматическое распознавание конвергентных конечных систем, управление очередями (queueing) и пропускной способностью (ограничение и регулирование скорости), буферы (вероятность удаления), а также поддержка подачи питания по Ethernet. Среди наиболее значимых требований управления: автоматическое распознавание подключенных систем по пользователю, телефону, IP/MAC-адресам, коммутатору, порту и виртуальной локальной сети, централизованное управление всеми данными конечных систем, централизованная конфигурация всех необходимых параметров и детализированный мониторинг потоков трафика с учетом приоритетов.
КОММУТАТОР ДОСТУПА КАК ПРИВРАТНИК
Концепция безопасности должна распространяться до границ сети и включать коммутатор доступа (см. Рисунок 1). Подобная система должна быть настолько открытой, чтобы она была применима в гетерогенных средах с продуктами многочисленных производителей и была готова к использованию со всеми средами передачи — в локальной, глобальной и беспроводной сетях, а также в виртуальной частной сети.
Уже сегодня в качестве стандартной опции можно ожидать, что администратор станет управлять коммутаторами посредством простого протокола сетевого управления версии 3 (Simple Network Management Protocol, SNMP), защищенной оболочки версии 2 (Secure Shell, SSH) и протокола защищенных сокетов (Secure Sockets Layer, SSL). Все прочие протоколы теперь неприемлемы. Операционная система коммутаторов сама по себе должна быть укреплена и поддерживать функции для отражения атак по типу «отказ в обслуживании» (Denial of Service, DoS) и «распределенный отказ в обслуживании» (Distributed Denial of Service, DDoS).
РАСПОЗНАВАНИЕ ПОЛЬЗОВАТЕЛЯ
Перед назначением правила пользователя необходимо идентифицировать и аутентифицировать. Аутентификация на базе портов производится в соответствии со стандартом 802.1х, однако говорить о полномасштабной среде 802.1х пока нельзя. Поэтому коммутатор на каждом порту должен одновременно поддерживать различные методы аутентификации — для принтеров, камер наблюдения, внешних персон, посетителей и т. д., в противном случае реализация управления аутентификацией и правилами окажется практически неосуществима. Возможно применение следующих методов:
- аутентификации на базе портов по стандарту 802.1х — посредством цифровых сертификатов, биометрических методов, комбинаций «пользователь/пароль» или одноразового пароля (One Time Password, OTP), протоколов аутентификации EAP-TLS, PEAP, EAP-MD5 или EAP-TTLS при помощи сервера RADIUS;
- аутентификации на базе MAC — с использованием МАС-адреса конечной системы через сервер RADIUS;
- аутентификации на базе Web — посредством перенаправления URL на интегрированный в коммутатор локальный сервер HTTP, а оттуда — на сервер RADIUS;
- автоматического распознавания конвергентной конечной точки (Convergence Endpoint Detection, CEP) — автоматическое распознавание IP-телефонов благодаря Н.323 или регистрационных процедур протокола инициации сеанса (Session Initiation Protocol, SIP); поддержка в зависимости от производителя, например CDPv2 от Cisco (Cisco Discovery Protocol);
- аутентификации по умолчанию — разблокирование базисной функциональности без аутентификации для удаленного включения по локальной сети или т. п.
Рисунок 2. Многопользовательская аутентификация и правила дополняют аутентификацию пользователей на границе сети такой же аутентификацией в ее ядре. |
Аутентификацию оптимально производить прямо на порту коммутатора доступа. Наряду с этим ее можно проводить и «глубже в сети»: посредством так называемой многопользовательской аутентификации и политики (Multi-User Authentication and Policy, MAP), что целесообразно в гетерогенных сетях (см. Рисунок 2). Еще одна возможность аутентификации состоит в назначении правил на основании входящих тегов виртуальной локальной сети 802.1Q. Отображение виртуальной сети на правила выполняют даже простые коммутаторы доступа и точки доступа, где, к примеру, поддерживается только классификация 802.1х по виртуальным сетям согласно RFC3580. Аутентификация должна проходить в полном соответствии со стандартом.
НАЗНАЧЕНИЕ ПРАВИЛ
Необходимые пользователям услуги предоставляются с помощью правил, применение которых позволяет проводить точное разделение пользователей, а также назначение соответствующего качества услуг. При этом должна быть возможность отключения управления правилами, чтобы предотвратить появление централизованных источников ошибок, из-за которых выходит из строя вся сеть. Важное требование — способность коммутирующих компонентов сохранять правила локально и в течение длительного времени. Правила пользователя состоят из назначенных ему виртуальной сети, списков контроля доступа (Access Control List, ACL) и приоритета (QoS), ограничения скорости, а также дополнительной классификации на втором, третьем, четвертом уровнях OSI. Они обеспечивают индивидуальное различение протоколов, подсетей IP, сигнализации дифференцированных услуг и приложения.
Благодаря ACL на втором, третьем, четвертом уровнях администратор, к примеру, может выделить отдельные пользовательские группы в одной подсети без применения виртуальных локальных сетей. Таким образом снижаются административные издержки и улучшается сетевая архитектура, поскольку в этом случае нет необходимости в организации моста через всю сеть для служб VLAN второго уровня, между тем как масштабируемость крупных сетей второго уровня с подобными мостами ограничена. Кроме того, ввиду динамической природы ACL администратор может заменить традиционные статичные списки контроля доступа маршрутизаторов. Тогда отпадает необходимость в администрировании этих ACL при переездах.
ОТРАЖЕНИЕ УГРОЗ
Отражение угроз уже на коммутаторе доступа позволит воспрепятствовать таким опасностям, как, к примеру, распространение «червей». Общепринятых механизмов защиты, в частности центральных брандмауэров, недостаточно. Рациональным является решение, где управление аутентификацией и правилами на коммутаторе объединяется с интеллектом системы обнаружения и защиты от вторжений (Intrusion Detection/Protection Systems, IDS/IPS). Подход должен включать в себя IDS/IPS как на базе сети, так и на базе хоста. Это поможет узнать содержимое пакетов на четвертом и седьмом уровнях OSI вплоть до коммутатора доступа. Таким образом инфраструктура ИТ сможет противостоять даже сложным атакам на уровне приложений, а отдел ИТ — бороться с нападениями в полу- или полностью автоматическом режиме. Решение управления для коммутирующих компонентов должно наряду с интерфейсом конфигурации для отображения событий/сигналов предоставлять статистику о том, когда и где какие-либо события привели к определенным действиям.
ПРЕДПОЧТЕНИЕ ВАЖНОМУ
Коммутаторы с функциональностью только второго уровня не удовлетворяют требованиям конвергентной инфраструктуры. Система управления правилами должна динамически присваивать коммутатору правила для классификации и назначения приоритетов, а также ограничения пропускной способности. Часто одного только назначения приоритетов на уровне виртуальной локальной сети или 802.1р недостаточно, поскольку приложения различаются только по информации обычно начиная с четвертого уровня OSI.
Еще сложнее выглядит ситуация в случае протоколов передачи голоса по IP (Н.323 и SIP), а также прочих протоколов на базе протокола передачи пользовательских дейтаграмм (User Datagram Protocol, UDP) и протокола реального времени (Real Time Protocol, RTP), поскольку определение портов для передачи голоса происходит динамически. Анализу может подвергаться только информация третьего уровня (DiffServ, DiffServ Code Point). Широкое распространение протоколов второго уровня, например 802.1р, сдерживает то, что, в частности, программные телефоны не поддерживают их через адаптер персонального компьютера. Поэтому администратор вынужден использовать DSCP. Однако значение DSCP определяется конечной системой. Чтобы гарантировать получение высокого приоритета именно VoIP, вводится ограничение скорости. Такой подход обеспечивает умеренное время задержки и ее вариации, однако предоставляет лишь ограниченную пропускную способность. При этом намеренная или случайная ошибочная конфигурация на конечной системе, откуда данные передаются с соответствующим классом услуг, не оказывает своего влияния на качество услуг для соединений VoIP.
ОБРАБОТКА ОЧЕРЕДЕЙ
Коммутатор доступа должен конечно же распределять классифицированные пакеты на исходящих портах по различным очередям. Сегодня четыре очереди считаются минимально необходимыми для управления, голоса, видео и важных данных, а также остального трафика. От четырех до 16 очередей можно найти, скорее, на магистрали или в глобальной сети, в случае последней количество очередей бывает и большим. В принципе коммутатору доступа вполне хватает очереди со строгим приоритетом, поддержка же взвешенной справедливой очереди или комбинация строгой и взвешенной оптимальны. Ограничение скорости на входе для каждого порта/приоритета является — как уже упоминалось — обязательным для каждого коммутатора доступа. Однако немаловажную роль на коммутаторе доступа при построении конвергентной сети может играть и регулирование скорости на выходе.
Интеллектуальное управление буферами обеспечивает пропорциональную отбраковку пакетов при перегрузке. Поэтому в ядре сети и в глобальной области в большинстве случаев используются такие механизмы, как случайное раннее распознавание (Random Early Detection, RED) и взвешенное случайное раннее распознавание (Weighted RED, WRED). В области доступа достаточно более простых механизмов. Для питания конечных устройств посредством Power over Ethernet, согласно стандарту 802.3af, коммутатор доступа должен предлагать соответствующую опцию для расширения.
УПРАВЛЕНИЕ
Сетевым управлением часто пренебрегают, однако это один из важнейших компонентов для реализации всех описанных выше функций. Только благодаря единому управлению можно оптимально задействовать все возможности коммутатора доступа. Он должен не только распознавать аутентифицированных пользователей и конвергентные конечные точки, но и динамически изучать MAC- и IP-адреса (обнаружение узлов и псевдонимов), и тогда администратор в состоянии локализовать любого пользователя с учетом любых параметров. В случае ошибки подобный подход экономит время и минимизирует длительность восстановления.
Желательно, чтобы все перечисленные данные отображались в центральной системе сетевого управления. Эффективность управления правилами во многом определяется наличием централизованного управления. При регистрации потоков данных необходимо сохранить прозрачность сети. В качестве стандарта для диагностирования ошибок на коммутаторах доступа приняты удаленный мониторинг (Remote Monitoring, RMON) с четырьмя группами, а также мониторинг коммутаторов (Switch Monitoring, SMON) для виртуальных сетей и статистики назначения приоритетов. Коммутаторы третьего уровня на магистрали должны поддерживать Netflow версий 5 или 8.
Маркус Нишпель — технический специалист немецкого офиса Enterasys. С ним можно связаться по адресу: http://www.enterasys.de.
? AWi Verlag