Защищаем сеть L2 коммутаторами

[@JDima]

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

>Дело в том, что размер таблицы MAC-адресов у любого коммутатора ограничен. При переполнении старые адреса удаляются, заменяясь новыми (FIFO)
Нет.

Алгоритм таков. При получении пакета проверяется наличие smac в CAM таблице. Если присутствует, то обнуляется счетчик. Если отсутствует, то проверяется наличие свободной банки. Если банка есть, то записываем, иначе пропускаем этот шаг и ничего не делаем. Таким образом, если легитимный хост шлет пакеты чаще чем по одному за aging time, то его не вытеснят.

>Поэтому даже если порт настроен в режиме access/auto при получении запроса на согласование его состояние может измениться на trunk/auto.
Обычно принято говорить «switchport mode access». Это исключает согласование в транк.
Switchport noneg — другое. Это значит, что свитч не будет слать DTP. И если режим порта dynamic, то включить noneg не получится.

>Еще один возможный вектор атаки VLAN hopping – использование native VLAN и добавление второго тега
Атака сугубо теоретическая. На современных каталистах (как минимум) не должна работать.

[@Avtandilko]

Спасибо за уточнения.
По поводу port-security — как минимум для небольших сетей с редкими миграциями сотрудников не самый плохой вариант, хотя бы из-за того, что разом решает несколько проблем.

[@Avtandilko]

del

[@RicoX]

Неоднократно встречал в домосетях и мелких провайдерах на «мыльницах», когда с помощью второй проблемы борются с первой, даже инструмент специальный есть dhcdrop, так что иногда второй вид атаки это «фича а не бага». А вообще общеизвестные это инструменты, вы бы еще loopback detect описали. Все векторы атаки, кроме (VLAN hopping) решаются связкой opt82+DHCP-Snoop, а сам hopping на современном железе не воспроизвести.

[@blind_oracle]

По поводу подмены мака — какой-то «рекомендованный» способ так себе — у каталистов есть ip verify source, который будет сравнивать мак и ip отправителя с записью в таблице dhcp snooping для данного порта и отбросит все пакеты, не подходящие под этот критерий.

[@FFunk]

Traffic segmentation и запрет общения клиентов между собой на l2 — ещё один способ защиты от описанных атак. Правда не во всех случаях применим, но тем не менее…

[@blind_oracle]

switchport protected? Да, полезная фича, дополнительно позволяет от вирусов всяких, которые между клиентами ползают, защищаться.

[@rdntw]

мне одному кажется что вместо DNS-сервера должен быть DHCP?

[@Avtandilko]

не кажется)

[@derwin]

> Шифрование трафика – в таком случае хоть все кадры и будут рассылаться широковещательно…
Таблицы маков — это L2, а шифрование — это аж L6. Как эти вещи связаны? Как шифрование траффика поможет защититься от перезаполнения таблиц маков??
Кстати, коммутаторы хранят не совсем таблицу. Хранится хэш по паре мак-порт. так поиск работает быстрее

[@blind_oracle]

Таблицы маков — это L2, а шифрование — это аж L6.

Откройте для себя шифрование на уровне L2 — MACSec.

Кстати, коммутаторы хранят не совсем таблицу. Хранится хэш по паре мак-порт. так поиск работает быстрее

Понятное дело, что они не перебором ищут :) Но и таблицу тоже хранят, из которой строится хеш.

[@JDima]

Думаю, имелось в виду, что при шифровании на L6-L7 атаки на низлежащих уровнях могут привести к отказу в обслуживании, но не к перехвату трафика или MITM.

О существовании реализаций macsec на участке между свитчем и клиентом мне слышать не доводилось.

[@blind_oracle]

О существовании реализаций macsec на участке между свитчем и клиентом мне слышать не доводилось.

Так эта, максек это как раз оно же. А для шифрования свитч-свитч у цыски есть вариация на тему под названием, вроде, TrustSec.

[@derwin]

Открыл, спасибо.
А разве MACSec доступен в РФ? там ж вроде лицензия ФСБ требуется.

[@blind_oracle]

В теории, конечно, наверное, да :)
Но на практике проблем особых нет, ограничения чисто программные и несложно в большинстве случаев обходятся.

[@derwin]

рекомендую рассмотреть(странно что Вы сами это не упомянули):
1) для DHCP использовать DHCP relay + opt.82
2) ddos protection, acl, arp spoofing pervention, loopdetect, filted netbios/extnetbios
3) кстати, почему нет фильтрации мультикастов? /злобный смех/