Comments 11
Вопрос, а что делать когда DHCP сервер на этом маке выключили и машинке нужен будет доступ в сеть, он ведь по прежнему будет изолирован от общей сети и данные ситуации в ручную разрешать придется?
Безусловно вручную. Такой вариант предполагает возможность некоей «профилактической работы» с пользователем-вредителем. Это минимальные издержки по сравнению с тем, что вредитель если его вовремя не остановить, может оставить без связи несколько десятков человек.
В общем-то, ничто не мешает написать еще один скрипт, который будет убирать маки из $stubvid при исчезновении их из массива алертера.
В общем-то, ничто не мешает написать еще один скрипт, который будет убирать маки из $stubvid при исчезновении их из массива алертера.
Мы некогда писали скриптик для сети общежития (сеть была полностью построена на неуправляемых свичах), который «выжирал» из чужого сервера весь диапазон раздаваемых адресов. Работало надежно)
Я так понимаю Ваш скрипт справится если злодей напрямую воткнут порт свитча. А если перед ним тупой свитч?
Если перед ним тупой свитч, трафик злодея микротик равно отрубит. Точнее не пропустит через себя. Но те, кто подключен к тому же тупому свитчу и общаются со злодеем напрямую будут видеть чужой DHCP.
В любом случае — тупой свитч, это беда, там уже не важно, что стоит выше — cisco, huawei, d-link или mikrotik.
В любом случае — тупой свитч, это беда, там уже не важно, что стоит выше — cisco, huawei, d-link или mikrotik.
Непонятно, помешает ли такая блокировка получить ложный адрес первому клиенту. Похоже, что ответ первому клиенту проскочит до того, как ложный DHCP-сервер будет изолирован в его собственном VLAN.
Правильное решение — запрет доставлять DHCP-запросы во все порты, кроме тех, на которых находится законный DHCP-сервер. Правда, для него требуется, чтобы эту функцию имели все свичи, к которым подсоединены все потенциальные ложные DHCP-серверы.
Правильное решение — запрет доставлять DHCP-запросы во все порты, кроме тех, на которых находится законный DHCP-сервер. Правда, для него требуется, чтобы эту функцию имели все свичи, к которым подсоединены все потенциальные ложные DHCP-серверы.
Между появлением DHCP-сервера в сети и срабатыванием алерта действительно есть небольшой временной лаг. По моим сведениям, алертер микротика срабатывает на DHCPOFFER, то есть до завершения процедуры выдачи адреса DHCP — до прохождения DHCPREQUEST, DHCPACK (именно из DHCPOFFER берется IP-адрес DHCP-сервера). По идее чужой DHCP должен быть изолирован на этой стадии, но временные издержки на запуск и исполнение скрипта, действительно могут дать интервал для одного клиента.
Скрипт делался как решение на случай «вообще нет DHCPsnooping'а». У людей вон, вообще грустно — тупые свитчи на выносах стоят.
Скрипт делался как решение на случай «вообще нет DHCPsnooping'а». У людей вон, вообще грустно — тупые свитчи на выносах стоят.
А просто блокировать на этом порту 67 udp нельзя? Зачем такие сложности? Я так делал на древней управляшке D-Link где тоже не было DHCP Snooping =)
Чтобы блокировать UDP 67 (L3+L4) нужно порт(ы) выводить в софтварный бридж и использовать для фильтрации CPU. Это сильно снизит пропускную способность. Люди сделавшие фильтр на CPU, потом ноют «фиговый свитч, что-то гигабит не прокачивается».
Моё решение сохраняет ресурсы процессора, перекладывая задачу на аппаратный свитч-чип.
Моё решение сохраняет ресурсы процессора, перекладывая задачу на аппаратный свитч-чип.
Sign up to leave a comment.
Отстрел чужих DHCP-серверов на коммутаторе MikroTik CRS