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

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

1. Введение

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

Для того, чтобы статья не была слишком громоздкой, разделим её на четыре части. В первой части рассмотрим общие рекомендации по настройке безопасности оборудования MikroTik, организацию безопасности L1 и L2. Во второй части продолжим говорить про L2, а именно про работу протокола Dot1X, рассмотрим безопасность L3. В третьей части покажем реализацию централизованного логирования. В четвёртой части (завершающей) расскажем про вариант настройки полноценной IDS, что в комплексе позволит достаточно широко осветить способы защиты оборудования MikroTik. Приступим к технической части.

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

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

/system package update check-for-updates

Всегда интересно посмотреть, что же производитель там пофиксил. А если дело касается CVE, тогда вдвойне интереснее. Конечно, эксплоитов для каждой решённой проблемы в свободном доступе не найти, а может, их вообще не существует за пределами компании MikroTik. Кроме этого, можно встретить анонс долгожданных настроек, таких как UDP для OpenVPN, который уже есть в 7 (not stable) версии операционной системы.

/system package update download
/system package update install

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

/user print 
Columns: NAME, GROUP, LAST-LOGGED-IN
 #  NAME   GROU  LAST-LOGGED-IN      
;;; system default user
 0  admin  full  aug/02/2021 06:36:04
/user set admin password=verySTRONGpassword!!

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

ssh-keygen -t rsa -b 4096 -f /root/test_user

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

-----BEGIN RSA PRIVATE KEY-----
MIIJKAIBAAKCAgEAqsZIz/….iUo/3a6dz/NasizOQ/DHnOvN3K0CGtfkD6g=
-----END RSA PRIVATE KEY-----

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

ssh-rsa AAAAB….ue/de9l7Zw== root@debian

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

/user ssh-keys import public-key-file=test_user.pub user=admin
/user ssh-keys print 
Flags: R - RSA, D - DSA 
 #   USER                       BITS KEY-OWNER                                                                     
 0 R admin                       4096 root@debian  

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

/ip ssh set always-allow-password-login=no
ssh -i test_user admin@10.0.0.1

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

/ip service set telnet disabled=yes
/ip service set ftp disabled=yes
/ip service set www disabled=yes
/ip service set www-ssl disabled=yes
/ip service set winbox disabled=yes
/ip service set api disabled=yes
/ip service set api-ssl disabled=yes

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

/ip service set ssh port=2223

Поясним. Nmap, на наш взгляд, самый распространённый сетевой сканер. Если ваше устройство кто-то будет сканировать, то велика вероятность, что именно им. Nmap с параметрами по умолчанию сканирует не все 65535 портов, поэтому, указав серверу ssh прослушивать «редкий порт», вы отсеете большое число «любителей» пофлудить сеть. Дополнительно сюда можно прикрутить технологию port knocking:

/ip firewall filter
add action=add-src-to-address-list address-list=LIST1 address-list-timeout=30s chain=input comment="Accept input SSH step 1" dst-port=28 in-interface=WAN protocol=tcp
add action=add-src-to-address-list address-list=LIST2 address-list-timeout=30s chain=input comment="Accept input SSH step 2" dst-port=29 in-interface=WAN protocol=tcp src-address-list=LIST1
add action=add-src-to-address-list address-list=LIST3 address-list-timeout=30s chain=input comment="Accept input SSH step 3" dst-port=30 in-interface=WAN protocol=tcp src-address-list=LIST2
add action=accept chain=input comment="Accept input SSH now" dst-port=22 in-interface=WAN protocol=tcp src-address-list=LIST3
add action=drop chain=input comment="Drop input SSH all" dst-port=22 in-interface=WAN protocol=tcp

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

nmap 192.168.15.9 -p 22
22/tcp filtered ssh

nmap 192.168.15.9 -p 28
28/tcp closed unknown
nmap 192.168.15.9 -p 29
29/tcp closed msg-icp
nmap 192.168.15.9 -p 30
30/tcp closed unknown

nmap 192.168.15.9 -p 22
22/tcp open  ssh

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

/ip service set ssh address=192.168.15.0/24,10.0.0.0/24

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

nmap 192.168.15.9 -p 22
22/tcp open  ssh

ssh admin@192.168.15.9
ssh_exchange_identification: Connection closed by remote host

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

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

/system backup save name=backup dont-encrypt=yes

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

/export file=backup

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

3. Защита L1

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

/interface ethernet disable ether4_LAN

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

/interface wireless security-profiles
add authentication-types=wpa2-eap mode=dynamic-keys name=test radius-mac-mode=as-username-and-password supplicant-identity=""

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

/interface wireless security-profiles
add authentication-types=wpa2-psk disable-pmkid=yes eap-methods="" management-protection=allowed mode=dynamic-keys name=RUVDS supplicant-identity="" wpa2-pre-shared-key=verySTRONGpassword!!

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

/interface wireless access-list
add allow-signal-out-of-range=1d authentication=no comment="Drop signal <= -80" interface=wlan1 signal-range=-120..-80

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

4. Защита L2

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

/tool mac-server set allowed-interface-list=LAN
/tool mac-server mac-winbox set allowed-interface-list=LAN

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



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

/ip neighbor discovery-settings set discover-interface-list=LAN

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

/interface ethernet set [ find default-name=ether1 ] mac-address=BC:EE:AA:BB:CC:A0 name=WAN

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



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

/interface bridge add comment=defconf dhcp-snooping=yes name=bridge
/interface bridge port add bridge=bridge interface=ether2_LAN trusted=yes

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

apt install dsniff
echo '1' > /proc/sys/net/ipv4/ip_forward
arpspoof -i wlan0 -t 192.168.1.3 192.168.1.1
30:b5:c2:15:57:d2 68:7:15:9c:99:9c 0806 42: arp reply 192.168.1.1 is-at 30:b5:c2:15:57:d2

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



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



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

/ip dhcp-server set dhcp_home add-arp=yes

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

/interface bridge set bridge arp=reply-only

Теперь поговорим про настройку технологии port security, VLAN и VLAN security в контексте информационной безопасности. Когда сеть введена в эксплуатацию и известно, кто, где, за что отвечает, тогда можно смело ограничивать соединения по MAC адресам соседних свичей, жёстко закрепив их значения за конкретными портами (подходит для коммутаторов CRS1xx/2xx):

/interface bridge port
add bridge=bridge1 interface=ether6 hw=yes learn=no unknown-unicast-flood=no
add bridge=bridge1 interface=ether7 hw=yes learn=no unknown-unicast-flood=no
/interface ethernet switch unicast-fdb
add mac-address=4C:5E:0C:00:00:01 port=ether6 svl=yes
add mac-address=D4:CA:6D:00:00:02 port=ether7 svl=yes
/interface ethernet switch acl add action=drop src-mac-addr-state=sa-not-found src-ports=ether6,ether7 table=egress

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

/interface ethernet switch port
set ether6 learn-limit=1
set ether7 learn-limit=1

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

/interface ethernet switch port set vlan-mode=secure

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

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