Защита Mikrotik от хакерских атак

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

DHCP SNOOPING

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

DHCP Snooping работает по принципу доверенных и недоверенных портов. Все сообщения DHCP на ненадежных портах будут отслеживаться. Цель — проверить, генерируются ли они DHCP-сервером. Ведь если в пользовательском сегменте мы видим сообщения типа DHCPLEASEQUERY, DHCPOFFER и DHCPACK, то это однозначно аномалия и в сети пользователя есть DHCP-сервер. На доверенных портах все сообщения DHCP будут считаться легитимными. Обычно доверенные порты настраиваются на соединениях между коммутаторами и маршрутизаторами, а недоверенные порты настраиваются на портах, к которым подключены конечные станции (например, компьютер, принтер, точки доступа, VoIP).

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

Для отслеживания DHCP можно использовать опцию 82. Это функция протокола DHCP, используемая для информирования DHCP-сервера, с какого порта поступает запрос DHCP. Также передается информация об использовании DHCP-реле. В некоторых конкретных сценариях требуется опция 82, поэтому включите ее при необходимости. На сайте MikroTik есть страница по настройке Snooping, где учтен сценарий использования «опции 82».

Вклю­чаем DHCP Snooping на bridge:

[caster@MikroTikDaymare] > /interface/bridge/set dhcp-snooping=yes <your bridge name>

Наз­нача­ем доверен­ный порт в кон­тек­сте DHCP Snooping:

[caster@MikroTikDaymare] /interface/bridge/port> set trusted=yes interface=<interface> bridge=<your bridge name> numbers=<interface number on bridge>

На этом настройка отслеживания DHCP завершена; Служебные сообщения DHCP, которые обычно используются DHCP-сервером, будут отсекаться на ненадежных портах. Поскольку для атаки требуется, чтобы злоумышленник навязал свой адрес шлюза с помощью сообщения DHCPOFFER, эти настройки помогают полностью предотвратить ее. Однако будьте осторожны с настройками, чтобы не вызвать непреднамеренный DoS.

ДИНАМИЧЕСКАЯ МАРШРУТИЗАЦИЯ

Безопасность протоколов динамической маршрутизации (DRP) имеет особенное значение, потому мельчайшее воздействие на AS частично парализует внутреннюю сеть. Кроме того, на домен динамической маршрутизации вероятны разные атаки, к которым следует подготовиться. Далее мы побеседуем о безопасности протокола Open Shortest Path First (OSPF), поддерживаемого RouterOS.

Пассивные интерфейсы

Настройка пассивных интерфейсов для динамической маршрутизации позволяет маршрутизатору запретить отправку рекламы через отдельные интерфейсы. По умолчанию, без настройки пассивных интерфейсов, он транслирует рекламные объявления на все интерфейсы, подвергая домен маршрутизации крупному риску.

Ни­же параметр passive ука­зыва­ет на пас­сивный интерфейс.

[caster@MikroTikDaymare] /routing/ospf/interface-template> add interfaces=<interface> passive area=backbone

Криптографическая аутентификация

Использование аутентификации в доменах маршрутизации помогает гарантировать, что к ним могут подсоединиться лишь авторизованные маршрутизаторы. Однако аутентификация настраивается с применением паролей. следовательно вам безусловно необходимо убедиться, что эти пароли достаточно надежны. Если злоумышленник заполучит хеш-значение из дампа трафика, он может попробовать взломать пароль, используя грубую силу. А с паролем он может просто подключиться к домену маршрутизации.

Нас­трой­ка ниже исполь­зует SHA-384. Кста­ти говоря, Ettercap смо­жет выдер­нуть любой MD5/SHA-хеш, что принесет ата­кующе­му воз­можность поп­робовать сбру­тить пароль от домена OSPF. Опять же сле­ди за стой­костью пароль­ной фра­зы.

[caster@MikroTikDaymare] /routing/ospf/interface-template> set auth=sha384 auth-key=<auth_key> auth-id=<auth_id> numbers=X

БЕЗОПАСНОСТЬ ДЕРЕВА STP

STP (протокол связующего дерева) — это протокол L2, который оберегает компьютерную сеть от широковещательных штормов, блокируя лишние физические соединения. Дело в том, что кадры Ethernet не имеют поля TTL и широковещательный трафик будет неограниченно протекать по транзитным соединениям, если возникнет петля коммутатора. Протокол действует исключительно на уровне канала передачи данных и использует для связи кадры 802. 3 BPDU. STP естественно включен по умолчанию на управляемых коммутаторах.

впрочем злоумышленник может отослать коммутатору кадр STP BPDU с наименьшим значением приоритета, тем самым перехватив роль корневого коммутатора. данный процесс приводит либо к частичной атаке MITM, либо к DoS.

уберечься от подделки в дереве STP возможно с помощью BPDU Guard. данный механизм блокирует порт, если на него поступает кадр BPDU, который обычно применяется лишь для согласования между коммутаторами в домене STP. особенно отослав BPDU с минимальным значением приоритета, злоумышленник может перехватить роль корневого коммутатора, выполнив тем самым неполную MITM-атаку.

BPDU Guard нас­тра­ивает­ся имен­но на пор­тах, которые находят­ся под мос­том.

[caster@MikroTikDaymare] /interface/bridge/port> set bpdu-guard=yes interface=<interface> bridge=<bridge> numbers=X

Вот и вся нас­трой­ка. BPDU Guard в этом пла­не не дос­тавля­ет хло­пот.

Осторожность при выборе STP Root

Корневым коммутатором STP обычно является коммутатор с наименьшим MAC-адресом. Вам необходимо учитывать этот аспект, поскольку если корневой коммутатор станет старым D-Link, это может повлиять на производительность сети. Также бывают случаи, когда соединения с главными маршрутизаторами FHRP через STP блокируются, и трафик может идти по неоптимальному пути. Настройте корневой коммутатор STP (и корневой вторичный STP) с учетом особенностей инфраструктуры.

БЕЗОПАСНОСТЬ СИСТЕМЫ РЕЗЕРВИРОВАНИЯ VRRP

Безопасность системы горячего резерва VRRP может быть поставлена ​​под угрозу, поскольку злоумышленник может провести спуфинг FHRP Master и атаки MITM. Из-за особенностей работы VRRP здесь невозможно установить приоритет 255, поэтому придется действовать строже. Есть два эффективных способа.

Спо­соб пер­вый — крип­тогра­фичес­кая аутен­тифика­ция. Она защища­ет домен VRRP с помощью спе­циаль­ной пароль­ной фра­зы, не зная которую ата­кующий не про­ведет спу­финг. Опять же нуж­но позабо­тить­ся, что­бы ключ аутен­тифика­ции был устой­чив к брут­форсу. В RouterOS для защиты VRRP исполь­зует­ся про­токол из репер­туара IPSec — AH. Уточ­нив у раз­работ­чиков RouterOS, я узнал, что его реали­зация в RouterOS осно­вана на HMAC-MD5.

[caster@MikroTikDaymare] /interface/vrrp> add interface=<interface> priority=<priority_value> version=2 vrid=<group_id_number> authentication=ah password

Вто­рой спо­соб — филь­тра­ция средс­тва­ми фай­рво­ла. Для VRRPv3 аутен­тифика­ция боль­ше не под­держи­вает­ся, одна­ко с этим нуж­но тоже что‑то делать. С помощью таб­лиц Mangle и Raw мож­но заранее раз­решить VRRP с легитим­ных VRRP-мар­шру­тиза­торов, а затем бло­киро­вать осталь­ные VRRP-пакеты. Этот вари­ант даст наимень­шую наг­рузку на про­цес­сор. Получит­ся, что в раз­реша­емых пра­вилах нет адре­са ата­кующе­го хос­та, поэто­му любые его попыт­ки про­вес­ти ата­ку на домен VRRP будут тщет­ны.

[caster@MikroTikDaymare] /ip/firewall/mangle> add chain=prerouting action=accept protocol=vrrp src-address=<first_vrrp_speaker_ip> in-interface=<interface> log=no log-prefix=""

[caster@MikroTikDaymare] /ip/firewall/mangle> add chain=prerouting action=accept protocol=vrrp src-address=<second_vrrp_speaker_ip> in-interface=<interface> log=no log-prefix=""

[caster@MikroTikDaymare] /ip/firewall/raw> add chain=prerouting action=drop in-interface=<interface> log=no log-prefix="" protocol=vrrp

Проблема псевдобалансировки

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

Ес­ли в тво­ей сети нес­коль­ко устрой­ств с RouterOS и нес­коль­ко сег­ментов VLAN, ты можешь задей­ство­вать все RouterOS в тво­ей сети, нап­ример:

• RouterOS1 будет MASTER за VLAN 120 и VLAN 140, а за VLAN 180 и VLAN 220 он будет BACKUP;
• RouterOS2 будет MASTER за VLAN 180 и VLAN 220, за VLAN 120 и VLAN 140 он будет BACKUP. То есть кон­фигура­ция зер­каль­на RouterOS1.

Этот при­ем называ­ется псев­добалан­сиров­кой. Конеч­но, тут нет того же round robin, но хотя бы все роуте­ры в домене VRRP будут работать. Для MASTER — при­ори­тет 200, для BACKUP — 90. Циф­ры и VLAN ID я взял из головы для симуля­ции такого сце­нария.

Нас­тра­иваем RouterOS1:

[caster@RouterOS1] /interface/vrrp> add interface=vlan120 name=vrrp120 priority=254 vrid=120

[caster@RouterOS1] /interface/vrrp> add interface=vlan140 name=vrrp140 priority=254 vrid=140

[caster@RouterOS1] /interface/vrrp> add interface=vlan180 name=vrrp180 preemption-mode=no priority=90 vrid=180

[caster@RouterOS1] /interface/vrrp> add interface=vlan220 name=vrrp220 preemption-mode=no priority=90 vrid=220

И RouterOS2:

[caster@RouterOS2] /interface/vrrp> add interface=vlan120 name=vrrp120 preemption-mode=no priority=90 vrid=120

[caster@RouterOS2] /interface/vrrp> add interface=vlan140 name=vrrp140 preemption-mode=no priority=90 vrid=140

[caster@RouterOS2] /interface/vrrp> add interface=vlan180 name=vrrp180 priority=254 vrid=180

[caster@RouterOS2] /interface/vrrp> add interface=vlan220 name=vrrp220 priority=254 vrid=220

Та­ким обра­зом воз­ника­ет псев­добалан­сиров­ка. Два RouterOS нас­тро­ены зер­каль­но, они оба готовы к замене вышед­шего из строя MASTER-роуте­ра. При этом задей­ству­ются все мощ­ности внут­ри сег­мента, вто­рос­тепен­ное обо­рудо­вание не будет прос­таивать. Так­же учи­тывай, что в RouterOS PREEMPT-режим вклю­чен по умол­чанию, он поз­воля­ет упав­шему ранее MASTER-роуте­ру вер­нуть себе эту роль, ког­да его заменил один из BACKUP-роуте­ров. Для бэкап‑роуте­ров, соот­ветс­твен­но, PREEMPT вык­люча­ется

БЕЗОПАСНОСТЬ ПАНЕЛИ УПРАВЛЕНИЯ (MGMT)

Защита RMI

MGMT — это спе­циаль­ные интерфей­сы управле­ния, которые поз­воля­ют нас­тра­ивать устрой­ство. В RouterOS для это­го исполь­зуют­ся сле­дующие служ­бы:

• Telnet (TCP/23);
• API (TCP/8728);
• API-SSL (TCP/8729);
• SSH (TCP/22);
• HTTP (TCP/80);
• HTTPS (TCP/443);
• Winbox (TCP/8291).

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

[caster@MikroTikDaymare] /ip/service> set address=<MGMT Subnet Address/24> <protocol_name>

Од­нако даже в адми­нис­тра­тор­ской под­сети есть веро­ятность брут­форса, если один из компь­юте­ров адми­нис­тра­тора будет заражен тро­яном. На этот слу­чай мож­но допол­нитель­но уси­лить защиты сле­дующим обра­зом:

• до­бавить цепоч­ки пра­вил для пре­дот­вра­щения брут­форса в таб­лицы Mangle/Raw;
• ис­поль­зовать толь­ко про­токол SSH и аутен­тифика­цию по клю­чу;
• сме­нить номера пор­тов (это, конеч­но, не пол­ная мера безопас­ности, но может усложнить поиск пор­та управле­ния обо­рудо­вани­ем);
• ес­ли не исполь­зуют­ся API/API-SSL, то их луч­ше вык­лючить, по ним тоже воз­можен брут­форс.

Защита учетных записей на оборудовании

На сво­ем обо­рудо­вании при­дер­живай­ся кон­цепции наимень­ших при­виле­гий, не раз­бра­сывай­ся full-учет­ками на железе и сле­ди, у какого инже­нера какой дос­туп к обо­рудо­ванию и какие воз­можнос­ти для нас­трой­ки. Так­же для опти­миза­ции управле­ния учет­ками мож­но под­нять AAA-сер­вер, где учет­ные записи будут хра­нить­ся цен­тра­лизо­ван­но и ими лег­ко будет управлять.

НАСТРОЙКА ФАЙРВОЛА

Firewall в RouterOS — это под­систе­ма, которая отве­чает за обра­бот­ку и филь­тра­цию всех пакетов. К нас­трой­ке фай­рво­ла, на мой взгляд, дол­жно быть осо­бое отно­шение, потому что от нее зависит и про­изво­дитель­ность устрой­ства, и уро­вень безопас­ности.

Мы не будем здесь подробно обсуждать все возможности межсетевого экрана RouterOS. Их много, и они могут быть чрезвычайно полезными и мощными. Но им посвящено множество статей и справочных материалов.  «Сте­на огня lvl2. Нас­тра­иваем фай­рвол для отра­жения атак на при­мере MikroTik».

Мы же оста­новим­ся толь­ко на важ­ных момен­тах, свя­зан­ных с защитой от прод­винутых атак.

Корректная обработка трафика

В RouterOS маршрутизируется весь трафик: используется концепция «разрешено все, что не запрещено». Трафик обрабатывается сверху вниз по правилам. Рекомендуется устанавливать правила в цепочках INPUT/Forward в начале настроек брандмауэра, которые разрешают установленные/привязанные соединения и запрещают недействительные соединения. Кстати, благодаря механизму Connection Tracking достигается отслеживание соединений по их статусу.

Аккуратная работа с ICMP

Так­же сто­ит раз­решить работу про­токо­ла ICMP и при этом с неболь­шим огра­ниче­нием на чис­ло пакетов в секун­ду, что­бы избе­жать потен­циаль­ного DDoS по про­токо­лу ICMP. Час­то весь тра­фик ICMP бло­киру­ют на внеш­нем перимет­ре, одна­ко это может пов­лиять на работу PMTUD, который помога­ет бороть­ся с избы­точ­ной фраг­мента­цией при нес­тандар­тных зна­чени­ях MTU.

[caster@MikroTikDaymare] /ip/firewall/filter> add chain=input action=accept protocol=icmp in-interface-list=<WAN_Interface> limit=50/5s,2:packet log=no log-prefix=""

TTL Shift

Если ваше оборудование выступает в роли прокси-сервера и вам необходимо скрыть его IP-адрес от трассировки, необходимо сдвинуть TTL в таблице Mangle в цепочке PREROUTING с шагом +1:

[caster@MikroTikDaymare] /ip/firewall/mangle> add chain=prerouting action=change-ttl new-ttl=increment:1 passthrough=yes in-interface=<internal_interface_for_ttl_shift> log=no log-prefix=""

Риск DNS-флуда

Убедитесь, что порт протокола DNS не открыт для потенциальной DDoS-атаки. DDoS-атака на MikroTik обычно осуществляется через DNS. Часто бывает, что в настройках DNS на MikroTik стоит галочка «Разрешить удаленные запросы», что позволяет RouterOS быть DNS-сервером. Обычно это касается внутренней инфраструктуры, но порт может также выступать на внешний интерфейс, выходящий в Интернет.

Drop All Other

В конце списка правил межсетевого экрана всегда должен быть запрет Drop All Other для внешнего интерфейса RouterOS (того, что обращен к Интернету; RouterOS не различает внутренние и внешние интерфейсы). Он будет запрещать все несанкционированные подключения к маршрутизатору, но убедитесь, что все необходимые правила для ваших протоколов находятся на переднем плане, чтобы последнее правило не нарушало сетевое подключение. Правило «Удалить все остальные» должно находиться в конце списка правил любого брандмауэра.

[caster@MikroTikDaymare] /ip/firewall/filter> add chain=input action=drop in-interface=<WAN_Interface> log=no log-prefix=""

БЕЗОПАСНОСТЬ WINBOX НА L2

Winbox может работать на уровне L2, то есть сетевой инженер может получить доступ к RouterOS без необходимости проходить через сетевой уровень. За это отвечает MAC Winbox Server и позволяет подключаться к Winbox без IP-адресации.

По умол­чанию MAC Winbox Server дос­тупен на всех интерфей­сах, и это нехоро­шо. Для повыше­ния безопас­ности рекомен­дует­ся раз­решить исполь­зовать его толь­ко на опре­делен­ных интерфей­сах.

Пример: MAC Winbox Server включаю только на листе внутренней LAN, где расположен LAN-мост для работы внутри сети.

НЕИСПОЛЬЗУЕМЫЕ ИНТЕРФЕЙСЫ

Одно из главных правил хорошего тона — отключать неиспользуемые интерфейсы. Это снижает вероятность несанкционированных подключений. Этому правилу очень просто следовать:

[caster@MikroTikDaymare] /interface/ethernet> set etherX disabled=yes

DISCOVERY-ПРОТОКОЛЫ

Discovery-про­токо­лы (DP) уяз­вимы к двум offensive-век­торам:

• Information Gathering — ата­кующий может извлечь чувс­тви­тель­ную информа­цию про­тив обо­рудо­вания, рас­сыла­юще­го DP в свои пор­ты;
• Neighbor Table Overflow — ата­кующий может выпол­нить перепол­нение таб­лицы соседей в кон­тек­сте про­токо­лов CDP/LLDP, что перег­ружа­ет про­цес­сор устрой­ства, а это при­водит к DoS. Ата­ка осно­вана на соз­дании лож­ных DP-кад­ров и мас­совой рас­сылке с при­целом на порт RouterOS.

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

[caster@MikroTikDaymare] > /ip/neighbor/discovery-settings/set discover-interface-list=<your interface list> protocol=cdp,lldp,mndp

ВЫВОДЫ

На этом моя статья под­ходит к кон­цу. Это не пол­ный ману­ал по безопас­ности MikroTik, одна­ко я ста­рал­ся акценти­ровать вни­мание на кри­тичес­ких механиз­мах безопас­ности, к которым дол­жно быть осо­бое отно­шение в кор­поратив­ных сетях. Имен­но невер­ные нас­трой­ки безопас­ности внут­ри сети соз­дают боль­шее чис­ло проб­лем. Полагаю, так про­исхо­дит из‑за халат­ности сетевых инже­неров. Оно и понят­но: сети, быва­ет, не меня­ются десяти­лети­ями, и об отсутс­твии нуж­ных нас­тро­ек прос­то забыва­ют.