Мой Mikrotik — Моя Цифровая Крепость (Часть 1)



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

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

угрозы безопасности.



1. Введение

В комментариях, опубликованных ранее статьи один из пользователи спросил: «Можно ли добавить раздел о том, как защитить свой Микротик, чтобы его управление не уходило в сторонуЭ» Один из пользователей в ответ на это написал следующее: «Есть два универсальных принципа для любого сетевого устройства — администрирование только из внутреннего интерфейса (снаружи всё закрыто) и регулярное обновление прошивки» (исходное написание сохранено) ).

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

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

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

В первой части мы рассмотрим общие рекомендации по настройке безопасности оборудования MikroTik, организации L1 и L2 безопасности.

Во второй части мы продолжим говорить о L2, а именно о работе протокола.

Dot1X , рассмотрите безопасность L3. В третьей части мы покажем реализацию централизованного журналирования.

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



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

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

/system package update check-for-updates

Всегда интересно посмотреть, что там исправил производитель.

И если дело дойдет до CVE , то это вдвойне интересно.

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



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



/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 без ввода пароля (а администратора можно заменить на другого).

Давайте сгенерируем пару ключей 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 [email protected]

Важно отметить, что если есть пользователь, для которого не был импортирован публичный ключ, то, несмотря на вышеуказанную настройку, 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-серверу прослушивать «редкий порт», вы отсеете большое количество «дилетантов» для флуда по сети.

Дополнительно сюда можно прикрепить технологию стук в порт :

/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-адрес сможет установить сеанс SSH в течение 30 секунд, в противном случае удалите:

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



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

Следует отметить, что если вы укажете Knock-порты примерно в таком порядке: 21, 80, 443 и переместите порт прослушивания SSH на 8080 (все четыре включены в список по умолчанию для сканирования nmap), то ваш секретный порт 8080 будет определить при первом сканировании.

Если вы действительно хотите использовать технологию выбивания портов, то выбирайте порты в порядке убывания, а сами значения портов должны «не сканироваться» nmap: ни в режиме топ-100, ни в режиме топ-1000. Кроме того, вы можете ограничить IP-адреса, с которых доступны протоколы управления, для диапазона доверенных:

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

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

nmap 192.168.15.9 -p 22 22/tcp open ssh ssh [email protected] ssh_exchange_identification: Connection closed by remote host

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

Если это невозможно, попробуйте отправить трафик через зашифрованные VPN-туннели.

Но даже внутри таких подключений лучше использовать защищенные протоколы, поскольку сеть VPN может выходить далеко за пределы подконтрольного вам периметра.

Если возможно, не используйте протоколы папа , http (в том числе при реализации API), FTP , смтп и т. д. Всегда используйте их безопасные аналоги: глава , mschap2 , https , смтпс .

Делать регулярное резервное копирование конфигурации ваших устройств.

RouterOS имеет два типа резервного копирования: двоичный *.

backup.

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

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

rsc

/export file=backup

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

Второй, наоборот, может обрабатываться вручную построчно контролируемым образом (до получения требуемого результата), однако может содержать конфиденциальную информацию (если вы не /export с учетом скрытия ), поэтому мы рекомендуем вам обеспечить безопасное хранение файлов резервных копий такого типа.

Ставить ли в планировщике задач обычный бэкап или нет, каждый решает сам.

Главное не запутаться во всех резервных копиях и не передать их на удаленный сервер по открытому интернет-каналу по 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 с неразборчивым по словарю паролем, который вы держите в секрете от третьих лиц, и отключенным ПМКИД :

/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-пинг только для внутренней сети.

Второй ограничивает L2-соединение через сервис Winbox:

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

RouterOS поддерживает такие протоколы, как CDP , ЛЛДП И МНДП .

Чтобы не транслировать пакеты указанных протоколов во все стороны, ограничиваем их работу:

/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), фактически раздающие разные сетевые настройки:

Мой MikroTik — моя цифровая крепость (часть 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-таблица будет переполнена, а клиент может начать передавать свой трафик не туда, что в первом и втором случае создает хорошую почву для МИТМ .

Попробуем реализовать описанные действия на практике:

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



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

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

На скриншоте видно, что с помощью описанных выше шагов мы организовали MITM для хоста 192.168.1.3 и перехватили его HTTP-запросы:

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

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

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

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

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

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

/interface bridge set bridge arp=reply-only

Теперь поговорим о настройке технологии безопасность порта , ВЛАН И Безопасность VLAN в контексте информационной безопасности.

Когда сеть введена в эксплуатацию и известно, кто за что и где отвечает, то можно смело ограничивать подключения по МАК адреса соседних свитчей, жестко присваивая их значения конкретным портам (подходит для свитчей 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, то в случае несанкционированного доступа к роутеру или свитчу устройства во всех этих подсетях могут быть скомпрометированы.

Здесь все ясно.

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

/interface ethernet switch port set vlan-mode=secure



5. Вывод

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

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

Дальше будет интереснее.

P/S Часть 1. Настройка оборудования и вопросы безопасности уровней L1 и L2 Часть 2. Настройка протокола Dot1X и работа Межсетевого экрана Часть 3. Варианты реализации централизованного журналирования Часть 4. Развертывание IDS и ее интеграция в инфраструктуру RouterOS

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

Теги: #информационная безопасность #Сетевые технологии #безопасность данных #безопасность данных #ruvds_articles #ruvds_articles #mikrotik #routeros #routeros

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.