Для чего используется broadcast storm control
Защита от штормов и петель на коммутаторах SNR
В рамках данной статьи мы рассмотрим функционал для защиты от петель и различных видов штормов на коммутаторах SNR.
Loopback-detection
Настройка Loopback-detection
Для включения функционала необходимо в режиме конфигурирования порта задать VLAN, для которых будет проверяться наличие петли, а также действие при ее обнаружении:
В глобальном режиме можно настроить время восстановления после отключения порта по причине петли:
По умолчанию коммутатор отправляет 2 LBD-пакета в каждый specified-vlan в промежуток interval-time. Данные значения можно изменить. Значение interval-time меняется также в глобальном режиме. Сначала указывается интервал отправки LBD-пакетов при обнаружении петли, затем, в случае, если петля отсутствует:
Количество отправляемых копий LBD-пакетов можно задать в режиме конфигурирования порта:
Также в глобальном режиме можно включить отправку SNMP Trap-сообщений при обнаружении петли:
При обнаружении петли за каким-либо портом отправляется SNMP Trap с OID 1.3.6.1.4.1.40418.7.101.112.1.
Storm-control
Для ограничения широковещательного трафика в сети можно воспользоваться функционалом Storm-control, который отбрасывает входящий трафик, превышающий установленный лимит. Функционал полностью аппаратный и выполняется на уровне ASIC без участия CPU, поэтому логирование отсутствует.
Настройка Storm-control
Также можно настроить протоколы, на пакеты которых функционал реагировать не будет. Данная настройка также производится в глобальном режиме:
Пороговое значение для каждого типа трафика настраивается отдельно для каждого порта в режиме его конфигурирования:
Rate-violation
Расширенные возможности для ограничения широковещательного трафика в сети имеет Rate-violation, который также отбрасывает входящий трафик, превышающий установленный лимит. В отличие от Storm-control, данный функционал задействует ресурсы CPU и является софтовым. При превышении порога действие записывается в лог, отправляется соответствующий SNMP Trap.
Настройка Rate-violation
Все настройки Rate-violation применяются в режиме конфигурирования порта.
Пороговое значение задается для выбранного типа трафика и может быть задано только в pps:
В качестве действия при превышении порога широковещательным трафиком может быть выбрано либо отключение порта, либо блокировка всего трафика на порте. При отключении порта также может быть выбрано время восстановления, после которого порт будет включен обратно:
Flood-control
Кроме ограничения входящего широковещательного трафика, на коммутаторах SNR существует возможность ограничить исходящий широковещательный трафик. Для этого используется Flood-control. Механизм, как и Storm-control, является аппаратным и полностью ограничивает передачу определенного типа широковещательного трафика в выбранный порт.
Настройка Flood-control
Что роняет Ethernet-сеть
Являясь относительно простым, протокол Ethernet позволяет снизить стоимость сетевого оборудования и одновременно обладает достаточной гибкостью, постоянно развиваясь и удовлетворяя требованиям современных сетевых приложений. Однако неправильно выбранное на этапе проектирования оборудование или архитектура будут неспособны удовлетворить поставленным задачам, а легкомысленный подход к настройке коммутаторов может привести к полному отказу сети. Очевидно, что при построении систем безопасности это совершенно неприемлемо.
Общие проблемы
Для начала рассмотрим общие проблемы построения Ethernet-сетей, о которых должен знать каждый. Атакже способы избежать их.
Для решения применяем всем известную технологию VLAN. Разделение сети на VLAN особенно необходимо в тех сетях, где присутствует трафик систем безопасности. Это не только значительно снижает риск несанкционированного доступа к оборудованию, но и предотвращает нежелательное распространение широковещательных пакетов или трафика multicast. Если системы безопасности подключены к коммутаторам локальной сети предприятия, то отсутствие VLAN (плоская сеть) фактически позволит любым пользователям получать потоки видео с камер наблюдения или прослушивать сообщения по громкоговорящей спецсвязи.
Разбиение сети на VLAN должно быть тщательно продумано еще на этапе проектирования Какие конкретно узлы следует изолировать друг от друга и каким образом будет осуществляться обмен трафика между ними, решается отдельно для каждого конкретного случая.
Широковещательный шторм
Проблема возникновения широковещательного шторма известна практически любому сетевому инженеру или системному администратору. Суть ее заключается в том, что в сети распространяется огромное количество широковещательных (или multicast) пакетов, перегружающих каналы и ресурсы сетевого оборудования, что в итоге приводит к сбою в работе сети. Чаще всего причиной шторма является коммутационная петля, которая может быть организована случайно или злонамеренно. В более редких случаях причиной может являться неисправное или неправильно настроенное оборудование, подключаемое к сети.
Эффективная проработка архитектуры сети на стадии проектирования позволит избежать возникновения широковещательного шторма Можно использовать совместно настройки VLAN, STP и Broadcast Storm Control:
Настройки STP
Существует заблуждение, что STP сам по себе достаточен для того, чтобы избежать возникновения шторма. Рассмотрим простой пример (рис. 1).
Предположим, к нашей сети подключается сеть сторонней организации, которая состоит из нескольких простейших неуправляемых коммутаторов. Как только в такой сети возникнет коммутационная петля, широковещательный шторм будет беспрепятственно попадать в нашу сеть. Даже несмотря на то что у нас применяется STP, эта петля не будет обнаружена нашими коммутаторами, поскольку используется только одно соединение между сетями. STP блокирует трафик только тогда, когда будет обнаружен альтернативный путь прохождения кадров через разные порты. Соответственно в таких случаях обязательно нужно использовать Broadcast Storm Control.
Рассмотрим простейшую схему: 2 хоста обмениваются друг с другом трафиком через 2 коммутатора, включенных последовательно. Оба хоста имеют скорость подключения к коммутаторам 1 Гбит/с. Между коммутаторами используется агрегированный канал из двух соединений 100 Мбит/с. Предположим, один хост пытается передать другому данные с максимальной скоростью. Максимальная пропускная способность агрегированного канала между коммутаторами при этом все равно не будет превышать 100 Мбит/с, поскольку трафик будет передаваться только через одно из физических соединений. При детальном изучении принципа работы данной технологии можно увидеть, что распределение трафика между физическими каналами происходит статически и зависит от IP- и МАС-адресов в заголовках передаваемых пакетов. То есть для каждой пары хостов трафик всегда будет передаваться только через один из каналов. Этот факт нужно обязательно учитывать при проектировании сетей.
Согласование скорости и дуплекса
Часто при подключении сетевых устройств по витой паре специалисты вручную устанавливают режимы скорости и дуплекса на портах, будучи уверенными, что «так будет лучше» Такой подход действительно был актуален более десяти лет назад, когда после появления технологии автоматического согласования (Auto Negotiation) сетевое оборудование разных производителей часто не могло «договориться» между собой, в результате чего производительность сети резко снижалась, и администраторы сети действительно были вынуждены устанавливать скорость и дуплекс вручную. Сейчас такой подход, скорее, является еще одним заблуждением, поскольку со временем технология автоматического согласования претерпела изменения, и производители сетевого оборудования уже давно придерживаются единого стандарта. На сегодня с этим может быть связана распространенная проблема: когда на порту оборудования скорость и дуплекс настроены вручную, а на другом конце канала оборудование использует автоматическое согласование, может наблюдаться снижение скорости передаваемого трафика, сопровождаемое потерями кадров. Это связано с тем, что если порт, на котором настроено автоматическое согласование, не получает информации о режимах скорости и дуплекса от своего «соседа», то он самостоятельно сможет определить скорость передачи, но при этом всегда будет использовать полудуплексный режим. Соответственно, если с противоположной стороны вручную установлен полнодуплексный режим, то на данном соединении постоянно будут возникать коллизии, приводящие к потере скорости передачи данных. Так что, если в сети используется относительно новое оборудование, лучше оставить автоматическое согласование, которое, как правило, настроено по умолчанию, и успешно работает.
Проблемы передачи multicast
IP multicast является одной из ключевых технологий при построении сетей для систем безопасности. При этом необходимость использования multicast накладывает дополнительные требования к архитектуре сети в целом, поскольку используются специальные протоколы, а оборудование должно обладать соответствующей функциональностью. Рассмотрим далее особенности, которые следует учитывать при использовании IP multicast в сетях Ethernet, и какие проблемы могут быть сними связаны.
Адресация
По аналогии с IP-протоколом, кадры Ethernet определяются как multicast по МАС-адресу назначения, указанному в заголовке. Причем МАС-адрес формируется в соответствии с используемым IP-адресом multicast, и здесь важно помнить, что из IP-адреса в МАС-адрес копируется только часть битов. В результате каждому МАС-адресу формата multicast соответствуют 32 адреса IP multicast, и при использовании нескольких потоков с разными IP-адресами и единым для них МАС-адресом может возникнуть ситуация, когда сетевое оборудование, принимающее хотя бы один из потоков, будет вынуждено также производить обработку пакетов и для остальных потоков, которые к нему попадают.
IGMP snooping
Практически во всех современных моделях управляемых коммутаторов Ethernet есть возможность контролировать распространение потоков multicast с помощью функции отслеживания пакетов IGMP (IGMP snooping). В этом случае коммутатор отслеживает передаваемые хостами и маршрутизаторами внутри сети пакеты IGMP и отправляет потоки для каждой из групп multicast только в те порты, через которые были получены соответствующие запросы IGMP report от хостов или пакеты IGMP query от маршрутизаторов.
Но с использованием IGMP snooping также может быть связана распространенная проблема. Предположим, что источники и приемники потоков multicast находятся в одном широковещательном домене (VLAN) и соединены через цепочку коммутаторов с включенным IGMP snooping. Если в этом домене отсутствует маршрутизатор, который рассылал бы пакеты IGMP query, то на портах, через которые коммутаторы соединены между собой, передача потоков будет блокироваться. Для решения этой проблемы на коммутаторах существует настройка IGMP querier, которая позволяет коммутаторам самим рассылать пакеты IGMP query и таким образом разблокировать порты для передачи потоков (рис. 2).
Сеть системы безопасности должна быть безопасной!
Как и любые другие широко используемые стандартные протоколы, Ethernet предоставляет злоумышленникам множество способов реализовать свои коварные планы. Инженеры, проектирующие сеть для систем безопасности, должны уделить особое внимание тому, чтобы и сетевое оборудование, и оборудование самих систем безопасности было защищено от сетевых вторжений. Для этого в коммутаторах производители предусматривают различные возможности по защите от несанкционированного доступа и перехвата данных. Отметим наиболее часто используемые функции обеспечения сетевой безопасности в коммутаторах Ethernet.
Еще одной мерой по защите от сетевых угроз является привязка IP-адреса к МАС-адресу, а также отслеживание нелегитимных пакетов протоколов ARP (ARP inspection) и DHCP (DHCP snooping). Данные настройки позволят предотвратить подмену МАС-адреса в пакетах ARP и DHCP внутри сети и таким образом защититься от перехвата данных злоумышленником.
Выбор оборудования
Наличие разнообразных функций и настроек зависит от конкретных моделей коммутаторов, поэтому при выборе оборудования следует внимательно изучить их возможности.
Кроме перечисленных функций следует уделить внимание возможностям QoS для маркировки и приоритезации кадров. Это особенно важно в сетях систем безопасности, поскольку перегрузка каналов не будет влиять на потоки реального времени и другой приоритетный трафик. Следует также внимательно изучить показатели производительности и ресурсов коммутаторов. Например, обладая достаточной функциональностью, выбранная модель коммутатора может при этом не поддерживать необходимое количество VLAN. Кроме того, нужно учитывать и общую пропускную способность коммутатора, которая на недорогих моделях может быть значительно меньше суммарной максимальной пропускной способности всех портов.
storm-control
Posted on 6 августа, 2016
storm-control
storm-control в каждую секунду измеряет количество бродкастов и, все что свыше, дропает. Порт при этом продолжает работать для пересылки всего остального трафика.
Важно:
Как результат в случае высокого значения broadcast storm-contorl можете получить перегрузку ЦПУ коммутатора, в случае низкого значения можете иметь проблемы с работой DHCP и ARP.
storm-control broadcast level 30 10
1 число порог срабатывания
2 число порог возврата
storm-control action
можно задать чтобы порт блокировался после достижение порогового значения. Либо отсылать trap.
далее порт можно будет поднять либо вручную. Что в некоторых случаях совсем неприемлемо.
Автоподнятие порта в случае блокировки.
Switch(config)#errdisable recovery interval 120
120 — время через которое будет предпринята попытка поднятия порта.
Но иногда и такое неприемлемо. По этому не включаем данную функцию.
Switch(config)#no storm-control action shutdown
Порт все равно будет блокировать (дропать) трафик если порог BroadCast Storm превысит указанный порог (Upper ).
Защита от штормов и петель на коммутаторах SNR
В рамках данной статьи мы рассмотрим функционал для защиты от петель и различных видов штормов на коммутаторах SNR.
Loopback-detection
Для включения функционала необходимо в режиме конфигурирования порта задать VLAN, для которых будет проверяться наличие петли, а также действие при ее обнаружении:
loopback-detection control
loopback-detection specified-vlan
Важно! Настройка двух первых пунктов является обязательным условием. При отсутствии любого из них функционал работать не будет.
В глобальном режиме можно настроить время восстановления после отключения порта по причине петли:
loopback-detection control-recovery timeout
Дефолтное значение 0 (порт не будет включен повторно).
По умолчанию коммутатор отправляет 2 LBD-пакета в каждый specified-vlan в промежуток interval-time. Данные значения можно изменить. Значение interval-time меняется также в глобальном режиме. Сначала указывается интервал отправки LBD-пакетов при обнаружении петли, затем, в случае, если петля отсутствует:
loopback-detection interval-time
Количество отправляемых копий LBD-пакетов можно задать в режиме конфигурирования порта:
loopback-detection send packet number
Также в глобальном режиме можно включить отправку SNMP trap-сообщений при обнаружении петли:
loopback-detection trap enable
При обнаружении петли за каким-либо портом отправляется snmp-trap с OID 1.3.6.1.4.1.40418.7.101.112.1
Storm-control
Для ограничения широковещательного трафика в сети можно воспользоваться функционалом Storm-control, который отбрасывает входящий трафик, превышающий установленный лимит. Функционал полностью аппаратный и выполняется на уровне ASIC без участия CPU, поэтому логирование отсутствует.
Также можно настроить протоколы, на пакеты которых функционал реагировать не будет. Данная настройка также производится в глобальном режиме:
storm-control bypass
Пороговое значение для каждого типа трафика настраивается отдельно для каждого порта в режиме его конфигурирования:
Rate-violation
Расширенные возможности для ограничения широковещательного трафика в сети имеет Rate-violation, который также отбрасывает входящий трафик, превышающий установленный лимит. В отличие от Storm-control, данный функционал задействует ресурсы CPU и является софтовым. При превышении порога действие записывается в лог, отправляется соответствующий snmp-trap.
Все настройки Rate-violation применяются в режиме конфигурирования порта.
Пороговое значение задается для выбранного типа трафика и может быть задано только в pps:
В качестве действия при превышении порога широковещательным трафиком может быть выбрано либо отключение порта, либо блокировка всего трафика на порте. При отключении порта также может быть выбрано время восстановления, после которого порт будет включен обратно:
rate-violation control
Flood-control
Кроме ограничения входящего широковещательного трафика, на коммутаторах SNR существует возможность ограничить исходящий широковещательный трафик. Для этого используется Flood-control. Механизм, как и Storm-control, является аппаратным и полностью ограничивает передачу определенного типа широковещательного трафика в выбранный порт.
Защита внутри периметра
Содержание статьи
Обеспечение безопасности канального уровня средствами коммутаторов Cisco
Локалка стала доставлять много хлопот? Пользователи получают левые айпишники по DHCP? Красноглазые пионеры балуются спуфингом? Всю сеть время от времени штормит? Пора изучать матчасть и настраивать фирменный коммутатор!
Новое — забытое старое
Как ни банально звучит, но канальный уровень — это краеугольный камень безопасности компьютерной сети. Принципы работы коммутаторов Ethernet, а также протоколы ARP и DHCP, использующие широковещательные рассылки, разработаны много лет назад. В основе этих подходов — доверие участников сетевых взаимодействий друг к другу, что в сегодняшних реалиях неприемлемо. Атаковать узлы и/или нарушить работоспособность локальной сети, построенной на основе неуправляемых свитчей, — проще простого.
С незапамятных времен известны такие атаки, как переполнение таблицы MAC-адресов (CAM-таблицы) коммутатора (MAC-флудинг) и различные способы подмены MAC-адресов (MAC-спуфинг и ARP-спуфинг). Примечательно, что большинство классических атак канального уровня основано не на каких-либо уязвимостях, а на вполне стандартном поведении сетевых стеков современных операционных систем. Так, чтобы вмешаться в ход взаимодействия двух узлов, достаточно отправить одному из них соответствующий ARP-пакет (третья строка дампа трафика):
Сегментация сети как метод защиты снимает часть проблем, но порождает другие угрозы. Классикой уже успели стать различные техники, применяемые против виртуальных локальных сетей (VLAN): VLAN-hopping, нелегальный Q-in-Q и подобные. Служебные протоколы (STP, CDP, DTP) также успешно эксплуатируются для получения информации о сети и реализации некоторых видов атак.
Как же противостоять угрозам канального уровня? Это сложный вопрос. Но очевидно, что первый рубеж защиты приходится на уровень доступа к сетевой инфраструктуре. А основной инструмент борьбы со злом — управляемый коммутатор.
Не страшны нам шторма
Для простейшей проверки того, насколько безопасна локальная сеть, достаточно… патчкорда. Им необходимо соединить две ближайшие розетки Ethernet. Если защита не совсем хороша, то созданная таким нехитрым способом петля вызовет лавинный рост широковещательного трафика. Пропускная способность сети резко упадет, а то и вовсе ее работа будет парализована.
Между тем коммутаторы Cisco позволяют эффективно контролировать широковещательный (broadcast), многоадресный (multicast) или одноадресный (unicast) трафик. Например, используя консоль, настроим устройство для борьбы с широковещательным штормом. Сначала войдем в режим конфигурирования:
Потом переключимся в режим конфигурирования интерфейса (например, gigabite ethernet 0/1) и введем две команды:
Первая команда устанавливает максимальный уровень широковещательного трафика в 20 процентов от полосы пропускания. Порог можно устанавливать не только в процентах, но и в битах в секунду (bps).
Вторая команда определяет, какое действие должно быть совершено, когда лимит будет достигнут, — отключить порт (shutdown). Если действие не указывать, то свитч будет просто фильтровать трафик, превышающий порог, и не отправлять никаких оповещений. SNMP-трапы и сообщения в Syslog можно включить, если указать action trap.
Чтобы в этом примере коммутатор автоматически восстанавливал порт, скажем, через 5 минут (равно 300 секунд) после отключения, нужно в глобальной конфигурации дать такие команды:
Можно в broadcast level указать два порога. Тогда при достижении первого порт будет отключаться, при падении broadcast-трафика до уровня второго — включаться:
У коммутаторов Cisco есть также штатное средство обнаружения петель, основанное на периодической отправке keepalive-сообщений. Эта опция обычно включена по умолчанию, и в случае срабатывания порт отключается. Для механизма keepalive можно также настроить автоматическое включение интерфейса:
У коммутаторов Cisco есть веб-интерфейс
Хакер #172. Спецвыпуск о Raspberry Pi!
Не консолью единой сильна Cisco
Использование интерфейса командной строки для управления коммутатором — чаще дело привычки, чем необходимость. Большинство рутинных операций в небольшой сети можно автоматизировать с помощью бесплатной фирменной утилиты Network Assistant (CNA, bit.ly/rrPPx). Она доступна для Windows и OS X. Максимальное количество управляемых устройств (коммутаторов, маршрутизаторов, беспроводных точек доступа) — 40. Ее интуитивный графический интерфейс позволяет решать основные задачи настройки, инвентаризации, оповещения о событиях, управления файлами и программным обеспечением оборудования.
STP под прицелом
Еще одним средством борьбы с петлями в сети является протокол STP. Кроме того, STP позволяет обеспечить дублирование линий передачи и, соответственно, отказоустойчивость. Все это хорошо, но излишняя толерантность конфигурации коммутатора приводит к плачевным последствиям: злоумышленник может манипулировать приоритетами с помощью параметров BPDU-пакетов.
Чтобы пресечь это зло на корню, делаем следующее. Во-первых, чтобы все работало быстрее, устанавливаем режим portfast на портах, к которым подключены рабочие станции:
И в глобальной конфигурации настраиваем portfast-порты так, чтобы при появлении BPDU-пакета порт отключался (там их не должно быть в принципе):
Во-вторых, защищаем Root Bridge. Для этого на магистральном интерфейсе выполняем команду:
Защищаем консоль коммутатора
Для ограничения доступа к администрированию сетевые интерфейсы устройств можно разместить в отдельном VLAN, «отгороженном» от остальной сети межсетевым экраном. В коммутаторах Cisco управляющий VLAN задается установкой IP-адреса на соответствующий VLAN-интерфейс.
Туда-сюда-туда
В консоли для выполнения команды show часто приходится выходить из режима конфигурирования, а потом снова набирать «conf t» и так далее. Чтобы сэкономить время, используй do, например: «do show ip route».
Защищаем DHCP
Использование в большой (или плохо контролируемой) сети DHCP-сервера для настройки протокола IP на узлах — это постоянный источник проблем для системного администратора. По иронии часто эти проблемы связаны не со злоумышленной активностью, а с деятельностью нерадивых пользователей. Почти классический пример — самовольное подключение к сети устройства с включенным DHCP-сервером, который наперегонки с легитимным сервером начинает раздавать IP-адреса рабочим станциям. Чей DHCP-ответ дойдет до клиента, того и адрес он себе поставит.
Функция коммутатора, которая предназначена для защиты от DHCP-атак, называется DHCP snooping. Ее основу составляет классификация всех портов на доверенные (trust) и ненадежные (untrust). Принципиальная разница в том, что с первых транслируются ответы DHCP-сервера, а со вторых — нет.
Итак, большую часть вопросов можно снять, включив DHCP snooping на коммутаторе и объявив доверенным тот порт, к которому подключен DHCP-сервер. Для этого нужно в режиме глобальной конфигурации выполнить следующие команды (вторая команда указывает, для каких VLAN включается опция защиты DHCP):
А в настройках порта, к которому подключен DHCP-сервер, указать:
Ненадежные порты настраивать не надо: они таковыми считаются по умолчанию.
Кстати, в качестве бонуса сразу после активизации DHCP snooping включается проверка MAC-адреса источника на untrust-портах (verify mac-address): если адреса в заголовке кадра и DHCP-сообщении не совпадают, то кадр отбрасывается. Еще можно ограничить количество DHCP-сообщений (в секунду) для данного порта:
Технология Port Security
Пусть есть коммутатор Cisco 2960, на борту которого 48 портов FastEthernet. К портам подключены розетки. Требуется реализовать политику, согласно которой к розетке можно подключить только один компьютер, создав препятствие к стихийному возникновению сетей на основе нелегальных SOHO-коммутаторов, а также пресечь попытки MAC-флудинга свитча.
В документации сказано, что технология Port Security позволяет регулировать входной трафик устройства Cisco путем ограничения (и идентификации) активных MAC-адресов на порту. А это, по сути, и требуется в данном случае.
Конечно, ограничение количества MAC-адресов — мера условная, и ее можно обойти, например с помощью SOHO-роутера с настроенной трансляцией сетевых адресов. Но во-первых, мы рассматриваем проблему в разрезе канального уровня. Во-вторых, SOHO-роутер дороже SOHO-коммутатора. А в-третьих, от попыток флудинга Port Security таки защищает.
В режиме конфигурирования укажем диапазон настраиваемых портов:
И непосредственно настройка портов (они уже находятся в access mode):
Первая строка — включаем 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:
Настройка Port Security на интерфейсе в CNA
ACL на всю катушку
В старых коммутаторах 2950 работа с листами контроля доступа (IP и MAC) была возможна только на улучшенных версиях прошивок. У свитчей 2960 эта опция стала частью базового ПО (LAN Base). На этих устройствах на физические интерфейсы можно добавлять следующие виды входящих (in) ACL:
Если номеров будет мало, можно использовать символьные имена (MAC-списки у 2960 только именованные).
В работе с ACL два этапа: создание списка в режиме глобальной конфигурации и применение списка с данным номером (именем) к интерфейсу. Так, для привязки IP-адреса к интерфейсу сначала создадим ACL номер 5 с одной записью:
Действие по умолчанию в списке — запрет всего (deny any). Поэтому явно его указывать нет необходимости.
А затем применим ACL к интерфейсу, на котором «висит» 5-й адрес:
Для обозначения диапазона адресов в ACL у Cisco используется инверсная маска (wildcard mask). После ключевого слова eq в ACL для протокола TCP можно указать порт назначения. Например, запрещаем доступ из «первой» подсети в «нулевую» по протоколу Telnet:
С помощью именованных MAC ACL можно фильтровать не-IP-трафик (в том числе и на основе физических адресов). Например, так выглядит лист контроля доступа, запрещающий протокол netbios:
Чтобы применить его на интерфейсе:
Управление широковещательными штормами в CNA 
Создание ACL в CNA
Переходим на личности…
Персонифицированный доступ к ресурсам сети является трендом, который сложно игнорировать. Во-первых, в Лету канули те времена, когда рабочие места сотрудников были стационарными и можно было легко идентифицировать конкретного пользователя по 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. Примерно так:
Далее нужно включить 802.1X в настройках соответствующих портов:
Можно также поиграться с VLAN’ами. Для порта dot1X можно установить пользовательский VLAN. В него рабочая станция помещается после успешной аутентификации. Он прописан в настройках порта, как обычно:
Есть также гостевой VLAN. В него помещаются клиенты, не поддерживающие 802.1X:
А еще есть Restricted VLAN. Туда попадает клиент, не прошедший аутентификацию:
При практическом внедрении 802.1X в корпоративную сеть придется учесть множество моментов: выбор программного обеспечения для аутентификации, настройка протокола IP на рабочих станциях, различные сценарии работы пользователей в сети, согласование групповых политик и так далее. В общем, это тема для отдельного разговора.
Разделяй и властвуй
Используя TFTP, в устройство можно заливать конфиг не только целиком, но и частями (настройки интерфейсов, ACL и прочее). Разложи эти куски по отдельным файлам и добавь в начале каждого команду no (no interface. no access-list. ), чтобы предварительно удалить старый фрагмент конфигурации.
Заключение
Хороший коммутатор может дать немало для безопасности локальной сети. Еще больше может сделать хороший специалист, который сумеет настроить этот коммутатор.
VLAN Hopping по умолчанию
Одна из особенностей конфигурации по умолчанию у коммутаторов Cisco состоит в том, что на всех портах включен протокол DTP (switchport mode dynamic desirable). Он позволяет автоматически устанавливать тегированное транковое соединение, если вторая сторона его поддерживает. Это, конечно, удобно, но если на том конце патчкорда окажется злоумышленник — ему не составит труда «вытянуть» доступные VLAN’ы локальной сети. Поэтому для устройств, доставаемых из коробки, лучше сразу выключить все неиспользуемые порты (shutdown) или принудительно установить режим доступа (switchport mode access) для них. В последнем случае желательно назначать таким портам какой-нибудь незадействованный (гостевой) VLAN (switchport access vlan 13) или считать VLAN 1 гостевым.
Режем VLAN’ы
В настройках транка (switchport mode trunk) можно указать, какие VLAN’ы на нем запрещены/разрешены. Например, чтобы разрешить только заданные сети: «switchport trunk allowed vlan 2,999». Чтобы запретить: «switchport trunk pruning vlan 5».