dhcp snooping mikrotik что это

Что такое DHCP Snooping и как это работает?

Что такое DHCP Snooping?

DHCP Snooping — это технология безопасности уровня 2, встроенная в операционную систему работоспособного сетевого коммутатора, которая отбрасывает трафик DHCP, определенный как неприемлемый. DHCP Snooping предотвращает несанкционированные (мошеннические) DHCP-серверы, предлагающие IP-адреса DHCP-клиентам. Функция DHCP Snooping выполняет следующие действия:

Чтобы выяснить, как работает DHCP Snooping, мы должны поймать рабочий механизм DHCP, который обозначает протокол динамической конфигурации хоста. При включенном DHCP сетевое устройство без IP-адреса будет «взаимодействовать» с DHCP-сервером через 4 этапа следующим образом.

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

На этапе подтверждения, будет создана таблица привязки DHCP в соответствии с сообщением DHCP ACK. Он записывает MAC-адрес хоста, арендованный IP-адрес, время аренды, тип привязки, а также номер VLAN и информацию об интерфейсе, связанную с хостом, как показано на рисунке 3. Если последующий пакет DHCP, полученный от ненадежного хоста, не совпадает с информацией, он будет удален.

MAC Адрес	IP Адрес	Аренда(сек)	Тип	VLAN	Интерфейс
Entry 1	e4-54-e8-9d-ab-42	10.32.96.19	2673	dhcp-snooping	10	Eth 1/23
Entry 2
Entry 3
.

Основные типы Атак, предотвращаемые DHCP Snooping

Спуфинговая атака DHCP

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

DHCP Starvation (истощение ресурсов DHCP)

Истощение ресурсов DHCP обычно нацелено на сетевые DHCP-серверы с целью наполнить авторизованный DHCP-сервер сообщениями DHCP REQUEST с использованием поддельных MAC-адресов источника. Сервер DHCP будет отвечать на все запросы, не зная, что это атака с истощением DHCP, назначая доступные IP-адреса, что приводит к истощению пула DHCP.

Как включить отслеживание DHCP?

DHCP Snooping применим только к проводным пользователям. Как функция безопасности уровня доступа, она в основном включена на любом коммутаторе, содержащем порты доступа VLAN, обслуживаемой DHCP. При развертывании DHCP Snooping необходимо настроить доверенные порты (порты, через которые будут проходить допустимые сообщения DHCP-сервера), прежде чем включать DHCP Snooping в VLAN, которую вы хотите защитить. Это может быть реализовано как в интерфейсе CLI, так и в веб-интерфейсе.

Источник

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

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

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

Это вызывает массу проблем, если вдруг в сети появляется чужой DHCP-сервер. Это не обязательно злонамеренные действия, пользователи могут подключить роутер банально не тем портом или настройки устройства могут быть сброшены по умолчанию, что также приведет к включению неавторизованного DHCP.

Давайте рассмотрим следующую схему:

В первый порт коммутатора SW1 у нас подключен DHCP-сервер, поэтому на коммутаторе мы включаем DHCP Snooping и помечаем первый порт как доверенный. В результате остальные узлы, подключенные к портам данного коммутатора, смогут получить адресную информацию только от авторизованного DHCP-сервера, так как DHCP-ответы на остальных портах коммутатор будет отбрасывать.

Но вот в нашей сети появился второй коммутатор SW2, который соединен с SW1 транзитным линком между вторыми портами. Если на втором коммутаторе DHCP Snooping отключен, то подключенные к нему узлы не имеют защиты от подмены DHCP-сервера, если же мы его включим, то нужно будет указать доверенный порт. В данном случае им будет порт транзитного линка под номером два, так как именно на него будут приходить DHCP-ответы.

Если мы не сделаем второй порт первого коммутатора доверенным, то подключенные к нему устройства не смогут взаимодействовать со вторым DHCP-сервером. А теперь подумаем: сделать доверенным порт подключения нового DHCP-сервера мы не забудем, а вот вспомним ли о том, что на транзитном линке доверенный порт только с одной стороны? Вряд-ли. Поэтому хорошим тоном является делать порты доверенными на каждой стороне транзитного соединения.

Также это понадобится вам, если вы используете опцию 82, которая позволяет указать DHCP-серверу в какой порт какого коммутатора присоединен клиент, запрашивающий IP-адрес. Причем данную информацию в пакет запроса добавляют сами коммутаторы.

Коротко итоги: для нормальной работы DHCP Snooping делаем доверенными все транзитные порты, соединяющие между собой коммутаторы, порты доступа, куда подключены конечные участники сети доверенными быть не должны, кроме тех, к которым подключены собственные DHCP-сервера.

DHCP Snooping в RouterOS

DHCP Snooping в Mikrotik реализован в самых общих чертах, но даже это все равно лучше, чем ничего. В RouterOS он реализован на базе сетевого моста (bridge), но при этом имеет ряд оговорок:

Важно! Аппаратно DHCP Snooping поддерживается только устройствами CRS3xx, на устройствах CRS1xx and CRS2xx может быть настроен только с VLAN-фильтрацией. На прочих устройствах поддерживается вместе с hardware offloading, но при этом на мосту не должно быть VLAN-фильтрации.

Что касается виртуальных сред, то в рамках подготовки данной статьи мы использовали RouterOS x86 и RouterOS CHR, в обоих из них DHCP Snooping на мостах работал нормально.

Для того, чтобы включить DHCP Snooping перейдем в Bridge, откроем свойства нужного моста и установим там одноименный флаг, там же, при необходимости, можно включить опцию 82.

В целом DHCP Snooping в RouterOS, с оглядкой на существующие ограничения, представляет собой достаточно эффективный инструмент для защиты от чужих DHCP-серверов в периметре сети.

DHCP Snooping в SwOS

В отличие от RouterOS возможности SwOS более ограничены, но и устройства с SwOS более дешевы, далее мы рассмотрим возможности CSS326-24G, недорогого и популярного управляемого коммутатора от Mikrotik.

Как видим, возможности весьма скромные, DHCP Snooping объединили вместе с PPoE Snooping, предотвращающем появление неавторизованного PPPoE-сервера в сети, но в целом этих настроек вполне достаточно, чтобы обеспечить базовую защиту.

Здесь мы в очередной раз можем убедиться, что Mikrotik не является «Cisco для бедных» или иной сетевой панацеей, но это вполне уверенные лидеры своего ценового сегмента, представляющие достаточно богатые возможности за вполне умеренные деньги.

Дополнительные материалы:

Mikrotik

The Dude

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Источник

Отстрел чужих DHCP-серверов на коммутаторе MikroTik CRS

Итак, подопытный аппарат CRS125-24G-1S установлен на доступе. С некоторых пор изредка на пользовательские устройства стали выпадать посторонние IP-адреса. Естественно возникла задача «найти и обезвредить». В стандартном арсенале RouterOS есть инструмент «DHCP-server Alert», способный вызывать некие действия при обнаружении в сети стороннего DHCP-сервера.

Отлично? Пожалуй. Только инструмент при ближайшем рассмотрении оказался не слишком информативный. Чтобы понять почему, рассмотрим типичную архитектуру маршрутизирующего оборудования MikroTik (картинка из вики):

По сути основная часть устройства делится на две:

1) програмно-конфигурируемый свитч, осуществляющий коммутацию на максимальной скорости;
2) CPU отвечающий за маршрутизацию, фильтрацию а также умеющий осуществлять коммутацию на программном уровне, медленнее и более ресурсоёмко.

IP-сервисы на таком устройстве, само собой висят на верхнем уровне. На Master-интерфейсе восходящем к CPU Routerboard или на программном бридже. Там и живет DHCP-сервер и его служба алертов. Все виденные мною ранее решения имели также два недостатка вытекающие из этой архитектуры:

1) Фильтрация трафика от злодея выполнялась на бридже, через «use ip firewall» и отнимала без того скудные ресурсы CPU;
2) Злодей подключенный к свитчу продолжал неконтролируемо пакостить абонентам на соседних портах этого свича.

Например, абоненты висящие на port2 и port3 всё равно продолжали получать бяку прилетающую со стороны port4. Но всё изменилось, когда у MikroTik появилась линейка CRS — ребята установили более мощный и функциональный свитч-чип, который я и решил попытаться использовать, победить и сохранить ресурсы CPU.

Шаг №1

Кхм. Сколько у нас портов? 24? Ладно. Я иду искать…

Шаг №2

Я пошел другим путем, создав локальную переменную с нормально интерпретируемым именем:

Как известно, настоящий джедай использует силу, а настоящий инженер использует мозг. Поэтому, идея тупо полностью отрубить найденный порт была мною отброшена — а вдруг за этим портом сидит несколько пользователей и/или устройств? К счастью свитч-чип в MikroTik CRS позволяет делать MAC-Based-Vlan. Решение пришло тут же — выделить трафик от злодея по MAC и завернуть в отдельный неиспользуемый Vlan. В итоге, получился компактный скрипт, надежно отключающий от сети чужое устройство с поднятым на нём DHCP-сервером.

Вызов алерта и скрипта у меня прописан следующим образом:

Спасибо, что дочитали до конца. Надеюсь, вам это когда-нибудь пригодится.

Источник

Что такое DHCP Snooping и как это работает?

Howard

Купить FS коммутаторы для развития Вашей сети.

«Почему я не могу подключиться к сети, даже если мой ноутбук получил IP-адрес динамически?» Сталкивались ли вы с этой проблемой в повседневной жизни? Вы сомневались в подлинности IP-адресов? Получены ли они с авторизованного DHCP-сервера? Если нет, как предотвратить это? В этой статье будет введен термин DHCP Snooping, чтобы помочь пользователям избежать использование незаконных IP-адресов.

Что такое DHCP Snooping?

защитить клиентов в сети от получения адреса от неавторизованного DHCP-сервера.

регулировать какие сообщения протокола DHCP отбрасывать, какие перенаправлять и на какие порты.

Для правильной работы DHCP snooping, необходимо указать какие порты коммутатора будут доверенными (trusted), а какие — нет (untrusted, в дальнейшем — ненадёжными):

Ненадёжные (Untrusted) — порты, к которым подключены клиенты. DHCP-ответы, приходящие с этих портов отбрасываются коммутатором. Для ненадёжных портов выполняется ряд проверок сообщений DHCP и создаётся база данных привязки DHCP (DHCP snooping binding database).

Доверенные (Trusted) — порты коммутатора, к которым подключен другой коммутатор или DHCP-сервер. DHCP-пакеты полученные с доверенных портов не отбрасываются.

По умолчанию коммутатор отбрасывает DHCP-пакет, который пришел на ненадёжный порт, если:

Приходит одно из сообщений, которые отправляет DHCP-сервер (DHCPOFFER, DHCPACK, DHCPNAK или DHCPLEASEQUERY);

Приходит сообщение DHCPRELEASE или DHCPDECLINE, в котором содержится MAC-адрес из базы данных привязки DHCP, но информация об интерфейсе в таблице не совпадает с интерфейсом, на котором был получен пакет;

В пришедшем DHCP-пакете не совпадают MAC-адрес указанный в DHCP-запросе и MAC-адрес отправителя;

Приходит DHCP-пакет, в котором есть опция 82.

	MAC Адрес	IP Адрес	Аренда(сек)	Тип	VLAN	Интерфейс
Entry 1	e4-54-e8-9d-ab-42	10.32.96.19	2673	dhcp-snooping	10	Eth 1/23
Entry 2
Entry 3
.

Основные типы Атак, предотвращаемые DHCP Snooping

Спуфинговая атака DHCP

DHCP Starvation (истощение ресурсов DHCP)

Как включить отслеживание DHCP?

Заключение

Хотя DHCP упрощает IP-адресацию, в то же время он вызывает проблемы с безопасностью. Чтобы устранить проблемы, DHCP Snooping, один из механизмов защиты, может предотвратить использование ненадежных адресов DHCP от мошеннического сервера DHCP и может предотвратить атаку истощения ресурсов, которая пытается использовать все существующие адреса DHCP. FS S3900 серии гигабитные стекируемые управляемые коммутаторы могут полностью использовать эту функцию для защиты вашей сети.

Источник

Мой MikroTik – моя цифровая крепость (часть 1)

1. Введение

В комментариях опубликованной ранее статьи один из пользователей спросил: «А можно добавить раздел про то, как нужно защитить свой, микротик чтобы управление им не ушло на сторону?». Один из пользователей написал на это следующее: «Универсальных принципов для любого сетевого устройства два – администрирование только с внутреннего интерфейса (снаружи закрыто все) и регулярно обновлять прошивку» (сохранена авторская орфография). А мы сразу поняли, что одним коротким ответом здесь не обойтись, и этот вопрос заслуживает полноценного отдельного рассмотрения с учётом широких возможностей операционной системы RouterOS, а также сопрягаемых с ней opensource решений, комплексно завершающих проблемный вопрос информационной безопасности. Кроме непосредственно настройки безопасности доступа до маршрутизатора, необходимо использовать его как полноценный барьер для разноуровневых атак, которые могут быть нацелены на защищаемую сеть. Технологий реализации этого достаточно много, поэтому разделим применяемые возможности на логические уровни и представим предметные рекомендации по администрированию сетей на базе оборудования MikroTik.

2. Общие рекомендации

Первое, что мы всегда делаем с железкой — это обновляем прошивку:

Далее смотрим, сколько создано пользователей, лишних удаляем. Ставим пароли, соответствующие политике информационной безопасности компании, если такая есть, если нет, тогда просто посильнее:

Если паранойя зашкаливает, тогда используем SSH вход без ввода пароля (и пользователя admin можно заменить на другого). Сгенерим пару RSA ключей, размер укажем 4096 бит, что уж мелочиться:

На выходе будет закрытый ключ test_user:

И открытый ключ test_user.pub:

Привяжем открытый ключ к пользователю RouterOS:

Добавляем хардкор, запретив логиниться по паролю:

Важно отметить, что если есть пользователь, для которого не импортирован публичный ключ, то, несмотря на вышепоказанную настройку, RouterOS сохраняет возможность логиниться под ним с помощью пароля. С учётными записями разобрались, далее выключаем серверы различных протоколов управления, в том числе небезопасные, разумеется, есть ли они вам не нужны:

Можно поменять прослушиваемый порт для SSH сервера. Особенно на значение, не входящее в сканируемые по умолчанию nmap-ом, но мы в этом защиты не видим, скорее маскировка:

Сканируем роутер и видим, что всё работает корректно. Сервер SSH будет недоступен, пока на роутер не пройдут попытки установления соединения на 28 порт, затем в течение 30 секунд на 29 порт, затем в течение 30 секунд на 30 порт. Если последовательность обращений верна и временные лимиты соблюдены, то IP адрес источника сможет в течение 30 секунд установить SSH сессию, а иначе drop:

Необходимо отметить, что если вы укажете порты стука примерно в таком порядке: 21, 80, 443, а прослушиваемый SSH порт перенесете на значение 8080 (все четыре входят в список по умолчанию для сканирования nmap), то ваш секретный порт 8080 определится при первом же сканировании. Если вы действительно хотите использовать технологию port knocking, то выбирайте порты в порядке уменьшения, а сами значения портов на «не сканируемые» nmap-ом: ни в режиме top 100, ни в режиме top 1000. Кроме этого, можно ограничить IP адреса, с которых доступны протоколы управления, на диапазон доверенных:

Таким образом, несмотря на то, что 22 порт готов принимать TCP соединение, однако с не доверенных IP адресов оно будет сброшено SSH сервером:

Как общие рекомендации, лучше не использовать протоколы, не имеющие шифрования для передачи защищаемой информации. Если такой возможности нет, тогда старайтесь пускать трафик по шифрованным VPN туннелям. Но лучше даже внутри таких соединений использовать безопасные протоколы, ведь VPN сеть может уходить далеко за пределы периметра, контролируемого вами. Если есть возможность, не используйте протоколы pap, http (в том числе при реализации API), ftp, smtp и т.д. Всегда используйте их безопасные аналоги: chap, mschap2, https, smtps.

Делайте регулярные резервные копии конфигураций ваших устройств. В RouterOS есть два типа backup: бинарный *.backup

и текстовый конфигурационный файл *.rsc

Первый рекомендуется откатывать только на полностью идентичных устройствах, и не подлежит редактированию (при откате восстанавливается точный образ операционной системы). Второй же, наоборот, можно ~~вручную контролируемо построчно~~ обрабатывать (до получения необходимо результата), однако он может содержать чувствительную информацию (если не делать /export hide-sensitive), поэтому рекомендуем обезопасить хранение такого рода backup файлов. Ставить ли регулярный backup в планировщик заданий, или нет, тут уже каждый решает сам. Главное — не запутаться во всех резервных копиях и не передавать их на удалённый сервер по открытому интернет каналу посредством ftp.

3. Защита L1

Писать правила про установку сетевого оборудования в серверных помещениях, в защищённых телекоммуникационных ящиках, сейфах и т.д. мы не будем, это не тема статьи. Для защиты L1 на оборудовании MikroTik будет достаточно программно отключить не используемые сетевые интерфейсы:

Сюда же пойдёт организация безопасности беспроводных соединений. В идеале, конечно, следует настроить WPA2-Enterprise (подробно о настройке RADIUS сервера мы напишем во второй части статьи), так как реальных угроз безопасности таких сетей пока не известно:

Если такой вариант вам не подходит, тогда используйте WPA2-PSK со словарно неподбираемым паролем, который держите в тайне от третьих лиц, и отключённый PMKID:

Ещё можно запретить подключаться к точке доступа с низким уровнем сигнала, т.е. физически удалённым пользователям, которые, можно предположить, находятся за контролируемым периметром и не легитимны:

На этом свои рекомендации по поводу L1 безопасности остановим и перейдём к более интересным вещам.

4. Защита L2

Для начала ограничим работающие сервисы уровня L2:

Первый скрипт позволяет осуществлять mac-ping только для внутренней сети. Второй ограничивает L2 подключение посредством службы Winbox:

RouterOS поддерживает работу таких протоколов, как CDP, LLDP и MNDP. Чтобы не осуществлять широковещательную рассылку пакетов указанных протоколов во все стороны, ограничиваем их работу:

Чтобы со стороны провайдера не догадывались, что у вас стоит роутер MikroTik, можно сменить MAC адрес WAN интерфейса, но это скорее баловство:

Если в вашем L2 сегменте появится второй или более незаконный DHCP сервер, то это может здорово навредить работе всей сети. Так в примере видно, что работают две указанные службы (192.168.1.1 и 192.168.3.1), раздавая по факту разные сетевые настройки:

Для защиты от такого рода атак (ведь хакер может назначить и своё устройство в качестве шлюза) существует технология «DHCP snooping». После её активации бридж пропускает DHCP пакеты только в доверенную сторону:

Защита оконечных устройств выходит за рамки данной статьи, но декларируем, что многие антивирусы справляются с этой задачей, детектируя манипуляции с ARP пакетами. На скрине видно, что действиями выше мы организовали MITM для хоста 192.168.1.3 и перехватили его HTTP запросы:

В следующем примере показаны ложные записи ARP таблицы маршрутизатора, а ведь так намеренно можно заполнить весь имеющейся пул и втупить работу легитимного DHCP сервера:

Для защиты от таких действий в RouterOS необходимо, первым делом, настроить DHCP сервер, что позволит активировать функцию заполнения ARP таблицы, либо в результате его работы, либо в ручном режиме:

После этого настраиваем бридж, переводя маршрутизатор в режим только ответа на ARP запросы (если у вас работает hotspot, то от этой идеи придётся отказаться, так как он перестанет нормально функционировать), таким образом, сторонние манипуляции будут бессильны:

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

Если ваш маршрутизатор гоняет пакеты для логически разделённых сетей, в том числе с точки зрения безопасности, то их следует разнести по различным VLAN. Важно понимать, что если через ваше устройство проходят несколько VLAN, то в случае несанкционированного доступа к роутеру или коммутатору, могут быть скомпрометированы устройства во всех этих подсетях. Здесь всё понятно. Дополнительно можно указать устройству проверять tag трафика и дропать пакеты, у которых VLAN ID не найден в его таблице VLAN:

5. Заключение

На этой ~~админской~~ ноте прервём наши рассуждения, которые отображают подходы, применяемые нами в построении реальных сетей и обеспечении их информационной безопасности. Никакие ноухау статья не раскрывает, но в определённой мере систематизирует имеющиеся возможности и показывает их практическое применение. Дальше будет интереснее…

Источник