Обеспечение безопасности канального уровня средствами коммутаторов Cisco

Локалка стала доставлять много хлопот? Пользователи получают левые айпишники по DHCP? Красноглазые пионеры балуются спуфингом? Всю сеть время от времени штормит? Пора изучать матчасть и настраивать фирменный коммутатор!

Новое — забытое старое

Как ни банально звучит, но канальный уровень — это краеугольный камень безопасности компьютерной сети. Принципы работы коммутаторов Ethernet, а также протоколы ARP и DHCP, использующие широковещательные рассылки, разработаны много лет назад. В основе этих подходов — доверие участников сетевых взаимодействий друг к другу, что в сегодняшних реалиях неприемлемо. Атаковать узлы и/или нарушить работоспособность локальной сети, построенной на основе неуправляемых свитчей, — проще простого.

С незапамятных времен известны такие атаки, как переполнение таблицы MAC-адресов (CAM-таблицы) коммутатора (MAC-флудинг) и различные способы подмены MAC-адресов (MAC-спуфинг и ARP-спуфинг). Примечательно, что большинство классических атак канального уровня основано не на каких-либо уязвимостях, а на вполне стандартном поведении сетевых стеков современных операционных систем. Так, чтобы вмешаться в ход взаимодействия двух узлов, достаточно отправить одному из них соответствующий ARP-пакет (третья строка дампа трафика):

20:36:04.674993 08:00:27:53:1e:3e > 0a:00:27:00:00:00, ethertype IPv4 (0x0800), length 98: 192.168.56.101 > 192.168.56.1: ICMP echo request, id 801, seq 11, length 64 20:36:04.675033 0a:00:27:00:00:00 > 08:00:27:53:1e:3e, ethertype IPv4 (0x0800), length 98: 192.168.56.1 > 192.168.56.101: ICMP echo reply, id 801, seq 11, length 64  20:36:05.468048 01:01:01:01:01:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Reply 192.168.56.1 is-at 01:01:01:01:01:01, length 28  20:36:05.685509 08:00:27:53:1e:3e > 01:01:01:01:01:01, ethertype IPv4 (0x0800), length 98: 192.168.56.101 > 192.168.56.1: ICMP echo request, id 801, seq 12, length 64

Сегментация сети как метод защиты снимает часть проблем, но порождает другие угрозы. Классикой уже успели стать различные техники, применяемые против виртуальных локальных сетей (VLAN): VLAN-hopping, нелегальный Q-in-Q и подобные. Служебные протоколы (STP, CDP, DTP) также успешно эксплуатируются для получения информации о сети и реализации некоторых видов атак.

Как же противостоять угрозам канального уровня? Это сложный вопрос. Но очевидно, что первый рубеж защиты приходится на уровень доступа к сетевой инфраструктуре. А основной инструмент борьбы со злом — управляемый коммутатор.

Не страшны нам шторма

Для простейшей проверки того, насколько безопасна локальная сеть, достаточно… патчкорда. Им необходимо соединить две ближайшие розетки Ethernet. Если защита не совсем хороша, то созданная таким нехитрым способом петля вызовет лавинный рост широковещательного трафика. Пропускная способность сети резко упадет, а то и вовсе ее работа будет парализована.

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

# conf t

Потом переключимся в режим конфигурирования интерфейса (например, gigabite ethernet 0/1) и введем две команды:

(config)# int gi 0/1  (config-if)# storm-control broadcast level 20.00  (config-if)# storm-control action shutdown

Первая команда устанавливает максимальный уровень широковещательного трафика в 20 процентов от полосы пропускания. Порог можно устанавливать не только в процентах, но и в битах в секунду (bps).

Вторая команда определяет, какое действие должно быть совершено, когда лимит будет достигнут, — отключить порт (shutdown). Если действие не указывать, то свитч будет просто фильтровать трафик, превышающий порог, и не отправлять никаких оповещений. SNMP-трапы и сообщения в Syslog можно включить, если указать action trap.

Чтобы в этом примере коммутатор автоматически восстанавливал порт, скажем, через 5 минут (равно 300 секунд) после отключения, нужно в глобальной конфигурации дать такие команды:

# errdisable recovery cause storm-control  # errdisable recovery interval 300

Можно в broadcast level указать два порога. Тогда при достижении первого порт будет отключаться, при падении broadcast-трафика до уровня второго — включаться:

(config-if)# storm-control broadcast level 20.00 5.00

У коммутаторов Cisco есть также штатное средство обнаружения петель, основанное на периодической отправке keepalive-сообщений. Эта опция обычно включена по умолчанию, и в случае срабатывания порт отключается. Для механизма keepalive можно также настроить автоматическое включение интерфейса:

# errdisable recovery cause loopback

Другие статьи в выпуске:

Хакер #172. Спецвыпуск о Raspberry Pi!

• Содержание выпуска
• Подписка на «Хакер»-60%

STP под прицелом

Еще одним средством борьбы с петлями в сети является протокол STP. Кроме того, STP позволяет обеспечить дублирование линий передачи и, соответственно, отказоустойчивость. Все это хорошо, но излишняя толерантность конфигурации коммутатора приводит к плачевным последствиям: злоумышленник может манипулировать приоритетами с помощью параметров BPDU-пакетов.

Чтобы пресечь это зло на корню, делаем следующее. Во-первых, чтобы все работало быстрее, устанавливаем режим portfast на портах, к которым подключены рабочие станции:

# int range fa 0/1 - 48  (config-if-range)# spanning-tree portfast

И в глобальной конфигурации настраиваем portfast-порты так, чтобы при появлении BPDU-пакета порт отключался (там их не должно быть в принципе):

# spanning-tree portfast bpduguard default

Во-вторых, защищаем Root Bridge. Для этого на магистральном интерфейсе выполняем команду:

(config-if)# spanning-tree guard root

Защищаем DHCP

Использование в большой (или плохо контролируемой) сети DHCP-сервера для настройки протокола IP на узлах — это постоянный источник проблем для системного администратора. По иронии часто эти проблемы связаны не со злоумышленной активностью, а с деятельностью нерадивых пользователей. Почти классический пример — самовольное подключение к сети устройства с включенным DHCP-сервером, который наперегонки с легитимным сервером начинает раздавать IP-адреса рабочим станциям. Чей DHCP-ответ дойдет до клиента, того и адрес он себе поставит.

Функция коммутатора, которая предназначена для защиты от DHCP-атак, называется DHCP snooping. Ее основу составляет классификация всех портов на доверенные (trust) и ненадежные (untrust). Принципиальная разница в том, что с первых транслируются ответы DHCP-сервера, а со вторых — нет.

Итак, большую часть вопросов можно снять, включив DHCP snooping на коммутаторе и объявив доверенным тот порт, к которому подключен DHCP-сервер. Для этого нужно в режиме глобальной конфигурации выполнить следующие команды (вторая команда указывает, для каких VLAN включается опция защиты DHCP):

# ip dhcp snoofing  # ip dhcp-snooping vlan 2

А в настройках порта, к которому подключен DHCP-сервер, указать:

(config-if)# ip dhcp snooping trust

Ненадежные порты настраивать не надо: они таковыми считаются по умолчанию.

Кстати, в качестве бонуса сразу после активизации DHCP snooping включается проверка MAC-адреса источника на untrust-портах (verify mac-address): если адреса в заголовке кадра и DHCP-сообщении не совпадают, то кадр отбрасывается. Еще можно ограничить количество DHCP-сообщений (в секунду) для данного порта:

(config-if)# ip dhcp snooping limit rate 100

Технология Port Security

Пусть есть коммутатор Cisco 2960, на борту которого 48 портов FastEthernet. К портам подключены розетки. Требуется реализовать политику, согласно которой к розетке можно подключить только один компьютер, создав препятствие к стихийному возникновению сетей на основе нелегальных SOHO-коммутаторов, а также пресечь попытки MAC-флудинга свитча.

В документации сказано, что технология Port Security позволяет регулировать входной трафик устройства Cisco путем ограничения (и идентификации) активных MAC-адресов на порту. А это, по сути, и требуется в данном случае.

Конечно, ограничение количества MAC-адресов — мера условная, и ее можно обойти, например с помощью SOHO-роутера с настроенной трансляцией сетевых адресов. Но во-первых, мы рассматриваем проблему в разрезе канального уровня. Во-вторых, SOHO-роутер дороже SOHO-коммутатора. А в-третьих, от попыток флудинга Port Security таки защищает.

В режиме конфигурирования укажем диапазон настраиваемых портов:

# int range fa 0/1 - 48

И непосредственно настройка портов (они уже находятся в access mode):

(config-if-range)# switchport port-security  (config-if-range)# switchport port-security violation protect  (config-if-range)# switchport port-security maximum 1  (config-if-range)# switchport port-security mac-address sticky

Первая строка — включаем Port Security. Вторая — определяем действие при нарушении политики безопасности. Третья задает количество разрешенных на порту MAC’ов (по умолчанию 1). Четвертая включает добавление обнаруженных на порту MAС’ов в running-config (если сохранить в startup-config, то будет действительно и после перезагрузки).

Режим protect — самый «гуманный» из возможных способов реакции на превышение допустимого количества MAC’ов. Трафик maximum адресов, «засветившихся» раньше других на этом порту, будет разрешен. Кадры от «лишних» источников будут отбрасываться. Режим restrict — то же, что и protect, но отправляется SNMP-трап, и делается запись в syslog (а еще счетчик инцидентов тикает).

Есть еще режим shutdown (по умолчанию) — если количество MAC’ов больше maximum, то порт отключается (error-disabled). Здесь опять будет полезным настроить автоматическое включения порта через заданное время после инцидента (errdisable recovery cause psecure-violation), чтобы каждый раз не писать «no shutdown» вручную.

С помощью Port Security можно создавать что-то вроде ACL канального уровня. Пусть, например, требуется разрешить доступ к порту только данным трем компьютерам. Решение заключается в выставлении maximum в 3 и указании всех трех MAC-адресов с помощью параметра mac-address:

interface FastEthernet0/3 switchport mode access switchport port-security switchport port-security maximum 3 switchport port-security violation protect switchport port-security mac-address 0000.0100.c26d switchport port-security mac-address 0000.0100.f0dd switchport port-security mac-address 0000.0100.f178  !

ACL на всю катушку

В старых коммутаторах 2950 работа с листами контроля доступа (IP и MAC) была возможна только на улучшенных версиях прошивок. У свитчей 2960 эта опция стала частью базового ПО (LAN Base). На этих устройствах на физические интерфейсы можно добавлять следующие виды входящих (in) ACL:

1. Стандартные IP ACL на основе IP-адреса источника (номера 1–99 и 1300–1999).
2. Расширенные IP ACL на основе IP-адресов источника и получателя, а также опционально на типе протокола (100–199 и 2000–2699).
3. Расширенные MAC ACL на основе MAC-адресов источника и получателя, а также опционально на типе протокола.

Если номеров будет мало, можно использовать символьные имена (MAC-списки у 2960 только именованные).

В работе с ACL два этапа: создание списка в режиме глобальной конфигурации и применение списка с данным номером (именем) к интерфейсу. Так, для привязки IP-адреса к интерфейсу сначала создадим ACL номер 5 с одной записью:

# access-list 5 permit host 192.168.1.5

Действие по умолчанию в списке — запрет всего (deny any). Поэтому явно его указывать нет необходимости.

А затем применим ACL к интерфейсу, на котором «висит» 5-й адрес:

# int gi 0/1  config-if)# ip access-group 5 in

Для обозначения диапазона адресов в ACL у Cisco используется инверсная маска (wildcard mask). После ключевого слова eq в ACL для протокола TCP можно указать порт назначения. Например, запрещаем доступ из «первой» подсети в «нулевую» по протоколу Telnet:

# access-list 102 deny tcp 192.168.1.0 0.0.0.255 192.168.0.0 0.0.0.255 eq telnet  # access-list 102 permit tcp any any

С помощью именованных MAC ACL можно фильтровать не-IP-трафик (в том числе и на основе физических адресов). Например, так выглядит лист контроля доступа, запрещающий протокол netbios:

# mac access-list extended killnbs  (config-ext-macl)# deny any any netbios  (config-ext-macl)# permit any an

Чтобы применить его на интерфейсе:

# int gi 0/2  (config-if)# mac access-group killnbs in

Переходим на личности…

Персонифицированный доступ к ресурсам сети является трендом, который сложно игнорировать. Во-первых, в Лету канули те времена, когда рабочие места сотрудников были стационарными и можно было легко идентифицировать конкретного пользователя по IP- или MAC-адресу сетевой карты его компьютера. С распространением мобильных систем отслеживать эти технические характеристики стало накладно. Впрочем, концепция BYOD (Bring Your Own Device) для проводных сетей не успела принять таких угрожающих масштабов, так как беспроводные гаджеты быстро вытесняют устройства с Ethernet-адаптерами.

Во-вторых, более сложные схемы идентификации (сертификаты, логины и пароли) предпочтительнее в плане безопасности, чем IP- или MAC-адреса, манипулировать которыми не составляет никакого труда.

IEEE 802.1X (dot1X) — это давно известная технология, которая предназначена для аутентификации и авторизации на канальном уровне. Пользователь и/или рабочая станция, подключившись к сетевой розетке, не сможет передавать никакой трафик (кроме сообщений 802.1X), пока не пройдет процедуру аутентификации. А благодаря авторизации пользователь может автоматически помещаться в тот VLAN, который определен политиками безопасности, независимо от точки подключения. К этому VLAN можно привязать листы контроля доступа, политики QoS и тому подобное, то есть персонифицировать сетевой доступ по полной программе.

Собрать стенд для тестирования 802.1X несложно. Во-первых, нужен RADIUS-сервер. Он будет обрабатывать запросы на аутентификацию, поступающие от коммутатора с поддержкой 802.1X (это во-вторых). В-третьих — клиент 802.1X на рабочей станции, который сможет передать необходимые параметры коммутатору. В этой схеме свитч выступает как посредник между RADIUS-сервером и рабочей станцией в процессе аутентификации, а также обеспечивает контроль доступа к порту и непосредственно авторизацию.

Настройки 802.1X на коммутаторе зависят от версии iOS. В глобальной конфигурации нужно настроить RADIUS-сервер, модели аутентификации/авторизации и активировать dot1X. Примерно так:

# radius-server host 192.168.1.3  # radius-server key radiuskey  # aaa new-model  # aaa authentication dot1x default group radius  # aaa authorization network default group radius  # dot1x system-auth-control

Далее нужно включить 802.1X в настройках соответствующих портов:

(config-if)# dot1x port-control auto

Можно также поиграться с VLAN’ами. Для порта dot1X можно установить пользовательский VLAN. В него рабочая станция помещается после успешной аутентификации. Он прописан в настройках порта, как обычно:

switchport access vlan <vlan-id>

Есть также гостевой VLAN. В него помещаются клиенты, не поддерживающие 802.1X:

dot1x guest-vlan <vlan-id>

А еще есть Restricted VLAN. Туда попадает клиент, не прошедший аутентификацию:

dot1x auth-fail vlan <vlan-id>

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

Заключение

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

Андрей Бражук, www.nets4geeks.com