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

Микротик как попасть с заблокированным фаерволл

  • автор:

Легкий способ защитить свой Mikrotik от атак

upd-2020-03-16. В свете последних событий метод остается актуальным, вырезал из статьи все лишнее, оставил только про honeypot и port-scanners.

Хочу поделиться с сообществом простым и рабочим способом, как при помощи Mikrotik защитить свою сеть и «выглядывающие» из-за него сервисы от внешних атак. А именно всего тремя правилами организовать на Микротике honeypot.

Итак, представим, что у нас небольшой офис, внешний IP за которым стоит RDP сервер, для работы сотрудников по удаленке. Первое правило это конечно сменить порт 3389 на внешнем интерфейсе на другой. Но это ненадолго, спустя пару дней журнал аудита терминального сервера начнет показывать по несколько неудачных авторизаций в секунду от неизвестных клиентов.

Другая ситуация, у Вас за Mikrotik спрятан asterisk, естественно не на 5060 udp порту, и через пару дней также начинается перебор паролей… да да, знаю, fail2ban наше вcё, но над ним еще попыхтеть придется… вот я например недавно поднял его на ubuntu 18.04 и с удивлением обнаружил, что из коробки fail2ban не содержит актуальных настроек для asterisk из той же коробки того же ubuntu дистрибутива… а гуглить быстрые настройки готовых «рецептов» уже не получается, цифры у релизов с годами растут, а статьи с «рецептами» для старых версий уже не работают, а новых почти не появляется… Но что-то я отвлекся…

Итак, что такое honeypot в двух словах — это приманка, в нашем случае какой-либо популярный порт на внешнем IP, любой запрос на этот порт от внешнего клиента отправляет src адрес в черный список. Все.

/ip firewall filter add action=add-src-to-address-list address-list="Honeypot Hacker" \ address-list-timeout=30d0h0m chain=input comment="block honeypot ssh rdp winbox" \ connection-state=new dst-port=22,3389,8291 in-interface=\ ether4-wan protocol=tcp add action=add-src-to-address-list address-list="Honeypot Hacker" \ address-list-timeout=30d0h0m chain=input comment=\ "block honeypot asterisk" connection-state=new dst-port=5060 \ in-interface=ether4-wan protocol=udp /ip firewall raw add action=drop chain=prerouting in-interface=ether4-wan src-address-list=\ "Honeypot Hacker" 

Первое правило на популярных TCP портах 22, 3389, 8291 внешнего интерфейса ether4-wan отправляет IP «гостя» в список «Honeypot Hacker» (порты для ssh, rdp и winbox заблаговременно отключены или изменены на другие). Второе делает то же самое на популярном UDP 5060.

Третье правило на стадии прероутинга дропает пакеты «гостей» чей srs-address попал в «Honeypot Hacker».

Спустя две недели работы моего домашнего Mikrotik список «Honeypot Hacker» включил в себя около полутора тысяч IP адресов любителей «подержать за вымя» мои сетевые ресурсы (дома своя телефония, почта, nextcloud, rdp) Brute-force атаки прекратились, наступило блаженство.

upd-2020-03-16. Код по защите Микротика от сканирования портов, ранее эти правила размещались на Wiki по ссылке wiki.mikrotik.com/wiki/Drop_port_scanners

/ip firewall filter add action=add-src-to-address-list address-list="Hacker Scanners" \ address-list-timeout=30d0h0m chain=input comment="Port Scanners" \ in-interface=ether4-wan protocol=tcp psd=21,3s,3,1 add action=add-src-to-address-list address-list="Hacker Scanners" \ address-list-timeout=30d0h0m chain=input comment="NMAP FIN Stealth scan" \ in-interface=ether4-wan protocol=tcp tcp-flags=\ fin,!syn,!rst,!psh,!ack,!urg add action=add-src-to-address-list address-list="Hacker Scanners" \ address-list-timeout=30d0h0m chain=input comment="SYN/FIN scan" \ in-interface=ether4-wan protocol=tcp tcp-flags=\ fin,syn add action=add-src-to-address-list address-list="Hacker Scanners" \ address-list-timeout=30d0h0m chain=input comment="SYN/RST scan" \ in-interface=ether4-wan protocol=tcp tcp-flags=\ syn,rst add action=add-src-to-address-list address-list="Hacker Scanners" \ address-list-timeout=30d0h0m chain=input comment="FIN/PSH/URG scan" \ in-interface=ether4-wan protocol=tcp tcp-flags=\ fin,psh,urg,!syn,!rst,!ack add action=add-src-to-address-list address-list="Hacker Scanners" \ address-list-timeout=30d0h0m chain=input comment="ALL/ALL scan" \ in-interface=ether4-wan protocol=tcp tcp-flags=\ fin,syn,rst,psh,ack,urg add action=add-src-to-address-list address-list="Hacker Scanners" \ address-list-timeout=30d0h0m chain=input comment="NMAP NULL scan" \ in-interface=ether4-wan protocol=tcp tcp-flags=\ !fin,!syn,!rst,!psh,!ack,!urg /ip firewall raw add action=drop chain=prerouting in-interface=ether4-wan src-address-list="Hacker Scanners" 

На моих устройствах эта настройка работает вместе с вышеописанными honeypot правилами, неплохо их дополняя.

Из наблюдений, до 24.02.2022 в черном списке было от 1 до 5 тысяч адресов, сейчас их около 25 тыс. Выводы делайте сами.

Хочу отметить комментарии:
— habr.com/ru/post/499146/#comment_21549508 про правильный port knocking.
— хорошая идея использовать Intrusion Detector на ПК с открытыми портами: habr.com/ru/post/499146/#comment_21544142

  • mikrotik
  • firewall
  • broute-force
  • настройка роутера

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

Настройка черного и белого списков в роутерах Mikrotik

  • Автор: Уваров А.С.
  • 04.10.2019

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

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

Прежде всего поговорим об особенностях фильтрации в условиях современного интернета. Основной тенденцией последних лет является массовый переход на протокол HTTPS. Что это означает? В отличие от HTTP, который передает данные открытым текстом, HTTPS использует SSL-шифрование и все, что мы можем увидеть для такого соединения — это домен назначения. Какие именно страницы посещает пользователь на указанном домене и какие данные оттуда передаются мы видеть не можем.

Из этого следует, что мы не можем блокировать отдельные страницы, но можем заблокировать домен целиком. Для большинства сценариев этого вполне достаточно. Но здесь нас подстерегает другая неприятность, многие сайты используют CDN (Content Delivery Network, сеть доставки контента), такие как CloudFlare и заблокировав нужный вам сайт вы можете также ограничить доступ к большому количеству сторонних ресурсов. Что из этого может выйти все мы видели во время ковровых блокировок РКН против Телеграм.

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

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

Создаем списки

Для настройки фильтрации нам понадобятся минимум два списка: список доменов и список пользователей. С доменами понятно, это те сайты, к которым мы хотим запретить доступ или, наоборот, разрешить. Создаются такие списки просто: IP — Firewall — Address Lists где добавляем новый адрес, в поле Name вписываем имя листа, если это первая запись, либо выбираем его из выпадающего списка. В поле Address указываем IP-адрес или доменное имя ресурса, при указании доменного имени в список будут внесены все IP-адреса сайта, и они будут обновляться с периодичностью указанной в TTL домена.

mikrotik-black-white-list-001.png

В нашем случае мы добавили домен yandex.ru в список WL (whitelist, белый список). Обратите внимание, что адреса www.example.com и example.com — это разные доменные имена, которые могут иметь разные IP-адреса (в целях балансировки нагрузки) и поэтому следует добавлять оба варианта (или проверять что между ними нет расхождений).

В командной строке это же действие можно выполнить так:

/ip firewall address-list
add address=yandex.ru list=WL

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

mikrotik-black-white-list-002.png

В данном примере реализовано два списка: WL — белый список и BL — черный список. Обычно в реальной жизни используется что-то одно, в нашем случае создание данных списков обусловлено сугубо учебными целями.

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

Также вспомним, что в руках у нас роутер, т.е. устройство, работающее на сетевом уровне (L3), а значит основные параметры, с которыми он может работать — это адрес источника и адрес назначения. Адрес назначения — это домен, выше мы его уже разобрали. Адрес источника — это как раз пользователь, точнее — сетевое устройство пользователя. В самом простом случае мы можем создать еще один список и добавить туда IP-адреса нужных устройств.

Но на практике адреса раздаются сервером DHCP, это не проблема, создаем резервирование IP-адреса, для чего следует перейти в IP — DHCP-Server — Leases и открыв запись нужного адреса нажать Make Static.

mikrotik-black-white-list-003-1.png

После чего закрываем и снова открываем запись и в поле Address List вводим, если это первая запись, или выбираем имя списка, куда будет добавлен IP-адрес данного компьютера, в нашем случае это список USER.

mikrotik-black-white-list-004-1.png

Либо через командную строку:

/ip dhcp-server lease
add address=192.168.186.199 address-lists=USER mac-address=00:0C:29:B4:D0:05 server=dhcp1

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

Черный список

Начнем с самого простого сценария — черного списка. Сначала настроим вариант, когда такой список применяется ко всем пользователям, кроме членов списка USER. Для этого перейдем в IP — Firewall — Filter Rules и создадим новое правило. На закладке General укажем Chain — forward и In. Interface — bridge1:

mikrotik-black-white-list-005.png

На закладке Advanced указываем Src. Address List — USER и ставим перед ним восклицательный знак (символ инверсии правила), что будет означать кроме входящих в группу. В поле Dst. Address List указываем BL — т.е. наш черный список доменов.

mikrotik-black-white-list-006.png

И наконец на закладке Action указываем действие, обычно везде в интернете указывают drop, хорошо, укажем и мы.

mikrotik-black-white-list-007.png

Данное правило должно располагаться самым первым в цепочке FORWARD, выше FastTrack.

Теперь попробуем посетить запрещенный сайт:

mikrotik-black-white-list-008.png

Страничка не грузится, однако браузер не понимает в чем дело и продолжает попытки ее грузить (т.е. в заголовке вкладки постоянно крутится колесико), это нагружает ресурсы ПК и не вносит ясности пользователю. Так происходит из-за того, что мы просто убиваем пакеты — действие drop, и отправитель не понимает почему нет ответа. Поэтому для внутренних ресурсов лучше использовать действие reject, которое отправляет назад пакет с сообщением что ресурс недоступен.

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

mikrotik-black-white-list-010.png

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

/ip firewall filter
add action=reject chain=forward dst-address-list=BL in-interface=bridge1 reject-with=icmp-network-unreachable src-address-list=!USER

Теперь немного изменим задачу, применим черный список только к группе USER. Для этого немного изменим условия на закладке Advanced, а именно укажем Src. Address List — USER без восклицательного знака, в итоге условие будет читаться как: если источник в группе USER и назначение в группе BL.

mikrotik-black-white-list-011.png

Или в командной строке:

/ip firewall filter
add action=reject chain=forward dst-address-list=BL in-interface=bridge1 reject-with=icmp-network-unreachable src-address-list=USER

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

Белые списки

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

Снова перейдем в IP — Firewall — Filter Rules и создадим новое правило. На закладке General также укажем Chain — forward и In. Interface — bridge1 , на Advanced указываем Src. Address List — !USER и Dst. Address List — !WL:

mikrotik-black-white-list-012.png

И на закладке Action указываем действие reject. Таким образом данное правило будет блокировать все соединения, если адрес отправителя не входит в группу USER и адрес назначения не входит в белый список WL.

Аналогичное действие через консоль:

/ip firewall filter
add action=reject chain=forward dst-address-list=!WL in-interface=bridge1 reject-with=icmp-network-unreachable src-address-list=!USER

Данное правило также следует располагать первым в цепочке FORWARD.

Добавим к разрешенным несколько адресов, в нашем случае yandex.ru и interface31.ru и попробуем открыть один их них. Яндекс открывается, но выглядит довольно непривычно.

mikrotik-black-white-list-013.png

Многие картинки, которые располагаются на иных серверах, включая сервера самого Яндекса, но имеющего другие IP-адреса просто не подгружаются. Хотя никаких фатальных последствий это не несет, как поисковик Яндекс работает. А вот в почту войти уже не получится, для этого придется разрешить как минимум mail.yandex.ru и passport.yandex.ru.

Теперь попробуем открыть наш сайт. А вот тут первый неприятный сюрприз:

mikrotik-black-white-list-014.png

Что это значит? Браузер не может проверить подлинность сертификата, а так как наш сайт использует HSTS, то доступ к нему будет невозможен, потому как подобные действия могут указывать на атаку с понижением степени защиты, чему HSTS должен препятствовать.

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

mikrotik-black-white-list-015.png

В нашем случае оказалось достаточно добавить узел ocsp.int-x3.letsencrypt.org, сайт загрузился, но без комментариев, так как они реализованы на стороннем ресурсе и разрешение доступа к нему не решило проблемы. В этом случае вам придется либо заниматься долгим и кропотливым выяснением необходимых для работы ресурсов и занесением их в белый список, либо отказываться от части функционала сайтов.

Чтобы применить белый список только к участникам группы немного изменим правило: в Adwanced указываем Src. Address List — USER, т.е. без восклицательного знака. Теперь логика правила изменится и будут блокироваться все соединения для группы USER, кроме тех, которые разрешены белым списком.

mikrotik-black-white-list-016.png

Либо в командной строке:

/ip firewall filter
add action=reject chain=forward dst-address-list=!WL in-interface=bridge1 reject-with=icmp-network-unreachable src-address-list=USER

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

Layer 7 protocol

Layer 7 protocol — это методика поиска определенных вхождений в ICMP/TCP/UDP потоках при помощи регулярных выражений. На первый взгляд достаточно интересная возможность, существенно расширяющая степень контроля над проходящим трафиком, но есть один существенный недостаток. Как уже понятно из названия, данный вид фильтрации работает на прикладном (L7) уровне, т.е. полностью обрабатывается CPU и даже при небольшом количестве правил способен создать сильную нагрузку на оборудование, особенно старые (не ARM) модели.

Использовать L7 для блокировки сайтов не рекомендуют сами разработчики Mikrotik, справедливо замечая, что в большинстве случаев это не будет работать так, как задумано, но при этом вы будете впустую растрачивать вычислительные ресурсы роутера. На наш взгляд использовать L7 для задач, связанных с доступом к сайтам вообще бессмысленно. Современный трафик в подавляющем большинстве шифрованный и различного рода конструкции для анализа URL просто не будут работать, а управлять доступом на основе доменного имени вполне можно и на L3 (чем мы занимались выше).

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

Мы не рекомендуем использовать L7 во всех тех случаях, когда задачу можно решить иным образом, применяя его только для решения специфичных задач. Например, выявления и блокировки какого-либо вида трафика.

Поставим для примера следующую задачу: заблокировать возможность установления SSH-соединений для клиентов сети. Решение в лоб — заблокировать исходящие соединения на 22 порт не принесет успеха, так как SSH-сервер может работать на произвольном порту. Поэтому нужно при помощи специальных паттернов определить наличие именно SSH-трафика и каким-то образом его блокировать.

Где брать паттерны? Опытные пользователи могут запустить сетевой сканер (tcpdump, Wireshark) и проанализировать доступное содержимое пакетов и на основании полученной информации составить регулярное выражение. Либо воспользоваться сайтом l7-filter.sourceforge.net, однако большая часть паттернов оттуда работать не будет. Во-первых, сайт достаточно старый, последний раз обновлялся в 2009 году, во-вторых, очень многие протоколы перестали использоваться в открытом виде, а используют SSL-шифрование. В этом случае вы просто увидите SSL-поток, блокировать который бессмысленно, так как вы заблокируете практически весь интернет.

Для решения нашей задачи сначала перейдем в IP — Firewall — Layer 7 protocol и создадим новый фильтр: в поле Name напишем произвольное имя, в нашем случае SSH, а в поле Regexp внесем регулярное выражение паттерна:

^ssh-[12]\.[0-9]

mikrotik-black-white-list-017.png

Также можно выполнить команду в терминале:

/ip firewall layer7-protocol
add name=SSH regexp="^ssh-[12]\\.[0-9]"

Что делать дальше? Самое очевидное решение — использовать данный фильтр в правилах брандмауэра является примером того, как делать не надо. В этом случае через L7 фильтр будет проходить каждый пакет, что вызовет сильную нагрузку на CPU роутера.

Поэтому мы пойдем другим путем и на основании L7 фильтра будем маркировать соединения, которых гораздо меньше, чем пакетов. Перейдем в IP — Firewall — Mangle и создадим новое правило: на закладке General выставляем Chain — prerouting, Protocol — tcp и Сonnection Mark — no mark:

mikrotik-black-white-list-018-1.png

На закладке Advanced указываем использование созданного нами фильтра Layer 7 Protocol — SSH:

mikrotik-black-white-list-019.png

В Action указываем действие mark-connection, задаем марку соединения New Connection Mark — SSH-CONN и обязательно ставим флаг Passthrough для прохождения пакета далее по цепочке:

mikrotik-black-white-list-020.png

Затем добавим еще одно правило: General — Chain — prerouting, Protocol — tcp и Connection Mark — SSH-CONN:

mikrotik-black-white-list-021.png

А в действиях добавим mark packet, New Packet Mark — SSH-PCK и снимем флаг Passthrough:

mikrotik-black-white-list-022.png

Все тоже самое быстро делается в командной строке:

/ip firewall mangle
add action=mark-connection chain=prerouting connection-mark=no-mark layer7-protocol=SSH new-connection-mark=SSH-CONN passthrough=yes protocol=tcp
add action=mark-packet chain=prerouting connection-mark=SSH-CONN new-packet-mark=SSH-PCK passthrough=no protocol=tcp

Многие читатели не работают с брандмауэром дальше таблицы Filter, поэтому что, что мы сейчас сделали в Mangle может показаться им какой-то особой магией. Коротко поясним наши действия. Первое правило проверяет все немаркированные соединения и те из них, которые сосуществуют фильтру L7, т.е. SSH-соединения получают метку SSH-CONN и продолжают движение по цепочке. Следующее правило проверяет соединения и все пакеты соединений, промаркированных как SSH-CONN снабжает меткой SSH-PCK.

Таким образом мы пометили все пакеты, относящиеся к SSH-соединениям, но L7 фильтр мы используем только для соединений, не нагружая роутер проверкой каждого пакета. Теперь запретим транзит таких пакетов, для этого вернемся в IP — Firewall — Filter Rules и создадим правило, на закладке General которого укажем: Chain — forward, Рrotocol — tcp, In Interface — bridge1 и Packet Mark — SSH-PCK:

mikrotik-black-white-list-023.png

На закладке Action ставим действие drop. То же самое в консоли:

/ip firewall filter
add action=drop chain=forward in-interface=bridge1 packet-mark=SSH-PCK protocol=tcp

Ставим это правило также в начало цепочки FORWARD и если вы все сделали правильно, то установить SSH-соединение из вашей сети больше никому не удастся.

mikrotik-black-white-list-024.png

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

Фильтрация по MAC-адресам

Наши читатели с завидным постоянством спрашивают нас как можно организовать фильтрацию по MAC-адресам. Мы уже говорили и повторим еще раз, что считаем такую фильтрацию не самым оптимальным способом, потому что для идентификации следует использовать более высокоуровневые параметры: пользователя или IP-адрес. Но если сильно хочется, то почему бы и нет.

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

В тоже время MAC-адрес нам нужен для одной единственной цели — идентифицировать пользователя, что мы также можем сделать и по IP-адресу, для этого нам нужно будет преобразовать MAC в IP, который уже можно добавить в один из списков и использовать представленные нами выше правила. В этом нам снова поможет таблица Mangle.

Откроем IP — Firewall — Mangle и добавим правило, на закладке General укажем Chain — prerouting, In Interface — bridge1, на Advanced в поле Src. MAC Address укажем MAC-адрес нужного устройства.

mikrotik-black-white-list-025.png

И на закладке Action добавим действие add src to address list, где в поле Address List укажем требуемый список пользователей, в нашем случае USER, а в поле Timeout укажите требуемое время жизни записи, это нужно для того, чтобы запись обновилась при смене обладателем MAC IP-адреса. На скриншоте мы, в тестовых целях, использовали 5 секунд, в реальной жизни руководствуйтесь здравым смыслом и выбирайте более высокие значения.

mikrotik-black-white-list-026.png

Это же правило в командной строке:

/ip firewall mangle
add action=add-src-to-address-list address-list=USER address-list-timeout=5s chain=prerouting in-interface=bridge1 src-mac-address=00:0C:29:B9:FF:2E

Теперь первый пришедший с данного устройства пакет добавит его IP-адрес в указанный нами список, тем самым связав его с текущим MAC на время указанное в Timeout. Для каждого следующего устройства необходимо создать подобное правило, также не забывайте снабжать каждое из них комментарием, чтобы впоследствии вам и вашим коллегам было понятно о каком именно устройстве идет речь.

Заключение

Как видим возможности RouterOS позволяют решать достаточно сложные задачи используя даже недорогие роутеры. Но следует понимать ограничения всех вышеперечисленных методов, осознавая их достоинства и недостатки. А также соотносить свои требования с возможностями оборудования. Если понимать и принимать во внимание эти факторы, то фильтрация по спискам на Mikrotik будет эффективным инструментом в руках администратора. В противном случае вы получите только разочарование и иные негативные последствия. Поэтому пожелаем вам благоразумия и напомним: хороший администратор выбирает для каждой задачи наиболее подходящий инструмент, что является признаком профессионализма. А фанатизм еще никого до добра не доводил.

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

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

Mikrotik
  1. Оборудование MikroTik класса SOHO. Общий обзор и сравнение возможностей
  2. Производительность младших моделей Mikrotik hEX и hAP. Экспресс-тестирование
  3. Базовая настройка роутера MikroTik
  4. Расширенная настройка DNS и DHCP в роутерах Mikrotik
  5. Автоматическое резервное копирование настроек Mikrotik на FTP
  6. Проброс портов и Hairpin NAT в роутерах Mikrotik
  7. Настройка IPTV в роутерах Mikrotik на примере Ростелеком
  8. Настройка VPN-подключения в роутерах Mikrotik
  9. Настройка черного и белого списков в роутерах Mikrotik
  10. Настройка выборочного доступа к сайтам через VPN на роутерах Mikrotik
  11. Настройка OpenVPN-сервера на роутерах Mikrotik
  12. Безопасный режим в Mikrotik или как всегда оставаться на связи
  13. Настройка Proxy ARP для VPN-подключений на роутерах Mikrotik
  14. Настраиваем Port Knocking в Mikrotik
  15. Резервирование каналов в Mikrotik при помощи рекурсивной маршрутизации
  16. Настраиваем родительский контроль на роутерах Mikrotik
  17. Настраиваем IKEv2 VPN-сервер на роутерах Mikrotik с аутентификацией по сертификатам
  18. Расширенная настройка Wi-Fi на роутерах Mikrotik. Режим точки доступа
  19. Mikrotik CHR — виртуальный облачный роутер
  20. Настройка контроллера CAPsMAN (бесшовный Wi-Fi роуминг) на Mikrotik
  21. Настройка VPN-подключения на роутерах Mikrotik если подсети клиента и офиса совпадают
  22. Настраиваем использование DNS over HTTPS (DoH) на роутерах Mikrotik
  23. Настройка PPTP или L2TP VPN-сервера на роутерах Mikrotik
  24. Установка Mikrotik CHR на виртуальную машину Proxmox
  25. Защита RDP от перебора паролей при помощи оборудования Mikrotik
  26. Настройка SSTP VPN-сервера на роутерах Mikrotik
  27. Настройка выборочного доступа к сайтам через VPN с автоматическим получением маршрутов по BGP на роутерах Mikrotik
  28. Особенности эксплуатации CA на роутерах Mikrotik: резервное копирование, экспорт и импорт сертификатов
  29. Настройка туннелей GRE и IPIP на роутерах Mikrotik
  30. Правильное использование Fast Path и FastTrack в Mikrotik
  31. DHCP Snooping — настройка защиты от неавторизованных DHCP-серверов на оборудовании Mikrotik
  32. Работа оборудования Mikrotik в режиме беспроводной станции (клиента)
  33. Используем режим ARP reply-only для повышения безопасности сети на оборудовании Mikrotik
The Dude
  1. The Dude. Установка и быстрое начало работы
  2. Централизованное управление обновлением RouterOS при помощи The Dude
  3. Централизованный сбор логов Mikrotik на сервер The Dude

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

Поддержи проект!

Подпишись на наш Telegram-канал

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

Настройка Firewall в Mikrotik

RouterOS — сетевая ОС, изначально предназначенная для устройств RouterBoard латвийской компании Mikrotik, но в дальнейшем перекочевавшая на x86 и в облака (версия Cloud Hosted Router). В этой статье поговорим о том, как грамотно настроить межсетевой экран в этой ОС. Безопасность периметра локальной сети — одна из приоритетных задач любого системного администратора и в компании Mikrotik […]

Изображение записи

RouterOS — сетевая ОС, изначально предназначенная для устройств RouterBoard латвийской компании Mikrotik, но в дальнейшем перекочевавшая на x86 и в облака (версия Cloud Hosted Router). В этой статье поговорим о том, как грамотно настроить межсетевой экран в этой ОС.

Безопасность периметра локальной сети — одна из приоритетных задач любого системного администратора и в компании Mikrotik это прекрасно понимают. Так что как только вы включили устройство на RouterBoard с настройками по умолчанию — там уже будет некоторое количество преднастроенных правил. В случае Mikrotik CHR — по умолчанию правил не будет, но Mikrotik настоятельно рекомендует их настроить.

Сразу оговоримся, что в рамках этой статьи мы будет пользоваться исключительно интерфейсом командной строки (CLI) и облачной версией RouterOS CHR. Логика настройки точно такая же, как и при использовании WinBox или WebFig, но предпочтительнее изначально пользоваться CLI.

Немного теории: настройка firewall

Одним из базовых понятий настройки файервола Mikrotik является цепочка (chain). По умолчанию их 3, но есть возможность и создания собственных цепочек:

  1. Цепочка INPUT — входящий трафик, приходящий на маршрутизатор.
  2. Цепочка OUTPUT — исходящий трафик, создаваемый маршрутизатором.
  3. Цепочка FORWARD — трафик, проходящий сквозь через маршрутизатор.

Если к нам должен прийти какой-либо трафик извне, например, из интернета, то мы его будем обрабатывать цепочкой INPUT. Чтобы обработать правилами трафик, уходящий наружу (например, в тот же интернет), задействуем цепочку OUTPUT. Если же наш маршрутизатор не находится на границе сети, а служит промежуточным узлом между сетями, то тогда для обработки трафика применяем цепочку FORWARD.

Причем тут странное название «‎цепочка‎‎»‎? Все элементарно. Все создаваемые правила обработки действуют не вместе, а строго по очереди одно за другим. Точно также, как формируется цепь — одно звено следует за другим. Именно поэтому списки правил стали именовать «‎цепочками»‎.

Теперь коснемся статусов соединения. Каждое соединение условно можно разделить на 4 категории:

  1. New — исходя из названия ясно, что это новое соединение, а не одно из существующих.
  2. Established — соединение установлено, по нему можно передавать пакеты данных.
  3. Related — соединение, которое относится уже к какому-либо из существующих, но используемое в иных целях. Пока не будем заострять на этом внимание, чтобы не усложнять.
  4. Invalid — некорректное соединение, то есть маршрутизатор понятия не имеет, что это за соединение и как его обрабатывать.

И сразу к практике: фильтрация

Открываем консольный интерфейс и посмотрим на существующие правила:

[admin@MikroTik] > ip firewall filter print Flags: X - disabled, I - invalid, D - dynamic

Пока что правил нет, отображается только «‎легенда»‎ про флаги. Переходим в раздел настройки фильтров:

[admin@MikroTik] > ip firewall filter [admin@MikroTik] /ip firewall filter>

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

Теперь создадим несколько правил и расскажем для чего они нужны:

add action=accept chain=input comment="default configuration" connection-state=established,related

Эту команду можно читать прямо дословно. Разберем прямо по пунктам:

  1. add action=accept — принимать пакеты.
  2. chain=input — правило будет работать в цепочке входящего трафика.
  3. comment=»default configuration» — это просто комментарий-напоминалка, в нашем случае указываем, что это конфигурация по умолчанию, но можно вообще этот параметр не указывать.
  4. connection-state=established,related — указываем какие статусы соединения будем принимать.

Таким образом эта длинная команда всего лишь превращается во вполне логичную фразу «‎Принимать извне все пакеты со статусом соединения Established и Related»‎. Это правило позволяет четко указать маршрутизатору что если из внешней сети прилетают соединения с указанными статусами, то их следует принять.

Теперь переходим к следующему правилу, рекомендуемому Mikrotik:

add action=accept chain=input src-address-list=allowed_to_router

Тут мы заострим внимание только на параметре src-address-list=allowed_to_router. При обработке трафика мы можем формировать различные списки IP-адресов. Каждый список будет иметь имя. Так что дословный «‎перевод»‎ этого правила всего лишь «‎Принять пакеты, если IP-адрес с которого обращаются, есть в списке allowed_to_router. Нам это правило пригодится для дальнейшего формирования списка разрешенных IP-адресов.

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

Теперь следующее правило, оно достаточно спорное. Мы разрешим маршрутизатору отвечать на команду ping, приходящую извне. С одной стороны — это потенциально раскрывает то, что на нашем IP-адресе есть действующее устройство, а с другой это часто требуется для организации мониторинга. У нас в Selectel, к примеру есть услуга «‎Мониторинг состояния сервисов»‎, которая позволяет отслеживать доступность любого хоста из разных стран мира. Если вам нужно, отключить ping, то в action надо прописать не accept, а drop.

add action=accept chain=input protocol=icmp

Тут все просто — эта команда разрешает принимать извне и обрабатывать ICMP-пакеты. И завершающая команда:

add action=drop chain=input

Этим в финале цепочки INPUT мы будем отбрасывать (дропать) все оставшиеся пакеты, не подпадающие под правила выше. Посмотрим как у нас сформировались правила:

[admin@MikroTik] /ip firewall filter> print Flags: X - disabled, I - invalid, D - dynamic 0 ;;; default configuration chain=input action=accept connection-state=established,related 1 chain=input action=accept src-address-list=allowed_to_router 2 chain=input action=accept protocol=icmp 3 chain=input action=drop

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

  1. Прилетел снаружи ICMP-пакет. Машрутизатор смотрит в правило номер 0 — есть ли уже установившееся соединение. Если нас пингуют впервые, то статус соединение будет New, а не Established или Related. Так что правило не срабатывает.
  2. Смотрим дальше — есть ли IP-адрес с которого пришел пакет в списке allowed_to_router. Поскольку мы этот список еще не формировали, то его еще не существует и, следовательно, правило также не срабатывает.
  3. Наконец доходим до правила 2, которое однозначно говорит маршрутизатору, что следует принять (Accept) и обработать по протоколу ICMP данный пакет. Маршрутизатор отвечает на ICMP-пакет соответствующим эхо-ответом. До четвертого правила пакет уже не добирается, т.к. процедура обработки фактически завершена.

Рассмотрим еще один случай. На этот раз к нам на маршрутизатор извне прилетел некий неизвестный UDP-пакет с данными. Как будет действовать маршрутизатор:

  1. Смотрим правило 0. Существующего Established или Related соединения у нас нет, поэтому правило не срабатывает.
  2. Правило 1 — смотрим в список разрешенных адресов allowed_to_router, но там пусто. Еще одно правило не сработало.
  3. Дошли до правила 2 — является ли пришедший пакет ICMP-пакетом. Нет, не является, так что правило не срабатывает.
  4. И вот мы дошли до конца цепочки INPUT, где нас поджидает «‎правило-вышибала”. Поскольку у правила chain=input action=drop нет условий для срабатывания, то оно по умолчанию срабатывает всегда и наш неизвестный UDP-пакет дропается и перестает существовать.

Надеемся, что столь подробный разбор логики немного прояснил как именно работает файервол в Mikrotik RouterOS, поэтому приступим к дальнейшей настройке. Сформируем список разрешенных адресов. Для этого вернемся в главное меню, нажав символ / и подтвердив нажатием клавиши Enter. Теперь перейдем в раздел консольного интерфейса Mikrotik – ip firewall и посмотрим какие адресные списки у нас существуют:

[admin@MikroTik] > ip firewall address-list [admin@MikroTik] /ip firewall address-list> print Flags: X - disabled, D - dynamic # LIST ADDRESS CREATION-TIME TIMEOUT

Как видим, список пока пустой. Добавим туда адреса из стандартной локальной подсети 192.168.88.0/24 за исключением 192.168.88.1 (адрес маршрутизатора). Эта подсеть обычно используется по умолчанию на устройствах Mikrotik и именно ее чаще всего используют для раздачи адресов в локальной сети. Выполним добавление:

add address=192.168.88.2-192.168.88.254 list=allowed_to_router

Команда максимально проста для понимания мы говорим, что нам нужно добавить адреса 192.168.88.2-192.168.88.254 в список с именем allowed_to_router. Подразумевается то, что если списка с таким именем не существует, то при выполнении команды он будет создан. Проверим:

[admin@MikroTik] /ip firewall address-list> print Flags: X - disabled, D - dynamic # LIST ADDRESS CREATION-TIME TIMEOUT 0 allowed_to_router 192.168.88.2-192.168.88.254 feb/05/2021 13:01:55

Теперь, когда файервол в цепочке INPUT дойдет до правила номер 1, то в случае поступления данных с IP-адресом отправителя из диапазона 192.168.88.2-192.168.88.254 — правило сработает и маршрутизатор будет знать, что данные следует принять. Этим мы будем пользоваться для обращений к маршрутизатору из локальной сети.

Разделяем и властвуем

Списки адресов — крайне полезная штука при настройке файервола. Тут важно следовать стандартам, разработанным такой крутой организацией, как IETF (Internet Engineering Task Force) — Инженерный совет Интернета. Это международное сообщество с конца 80-х годов занимается развитием протоколов и архитектуры интернета.

Результаты работы IEFT публикуются в виде RFC (Request for Comments) — информационных документов, содержащих в себе детальное описание спецификаций и стандартов. Этих документов уже создано несколько тысяч, все они представлены на английском языке. Один из них поможет нам корректно сформировать списки адресов, а именно RFC6890.

Наша задача при настройке файервола четко разделить адреса, относящиеся к локальному сегменту и адреса глобальной сети интернет. Именно их мы возьмем из RFC и пропишем в нашем маршрутизаторе списком с названием not_in_internet. В дальнейшем это поможет нам сформировать правила в которых будут абстракции «‎это адрес из интернета»‎ и «‎это адрес не из интернета»‎.

Поочередно выполняем команды, создавая и дополняя список not_in_internet, помимо всего прочего указывая в комментарии номер RFC, которым мы руководствовались:

add address=0.0.0.0/8 comment=RFC6890 list=not_in_internet
add address=172.16.0.0/12 comment=RFC6890 list=not_in_internet
add address=192.168.0.0/16 comment=RFC6890 list=not_in_internet
add address=10.0.0.0/8 comment=RFC6890 list=not_in_internet
add address=169.254.0.0/16 comment=RFC6890 list=not_in_internet
add address=127.0.0.0/8 comment=RFC6890 list=not_in_internet
add address=198.18.0.0/15 comment=RFC6890 list=not_in_internet
add address=192.0.0.0/24 comment=RFC6890 list=not_in_internet
add address=192.0.2.0/24 comment=RFC6890 list=not_in_internet
add address=198.51.100.0/24 comment=RFC6890 list=not_in_internet
add address=203.0.113.0/24 comment=RFC6890 list=not_in_internet
add address=100.64.0.0/10 comment=RFC6890 list=not_in_internet
add address=240.0.0.0/4 comment=RFC6890 list=not_in_internet

Есть еще две важные подсети, которые тоже стоит добавить в этот список. Первая подсеть — это 224.0.0.0/4. Эта подсеть зарезервирована для технологии многоадресного вещания (мультикаст) и это зафиксировано в соответствующем RFC2780. Вторая подсеть специфична для переходного механизма 6to4, позволяющего передавать IPv6 трафик через IPv4 сети. Этот механизм реализован в подсети 192.88.99.0/24, что также зафиксировано в отдельном RFC3068.

add address=224.0.0.0/4 comment=Multicast_RFC2780 list=not_in_internet
add address=192.88.99.0/24 comment="6to4_RFC 3068" list=not_in_internet

Теперь, когда мы все сделали «‎по фен-шую»‎, у нас есть список всех адресов, которые будут опознаваться как локальные, т.е. пришедшие не из интернета. Проверим:

[admin@MikroTik] /ip firewall address-list> print Flags: X - disabled, D - dynamic # LIST ADDRESS CREATION-TIME TIMEOUT 0 allowed_to_router 192.168.88.2-192.168.88.254 feb/05/2021 13:01:55 1 ;;; RFC6890 not_in_internet 0.0.0.0/8 feb/05/2021 13:43:03 2 ;;; RFC6890 not_in_internet 172.16.0.0/12 feb/05/2021 13:43:03 3 ;;; RFC6890 not_in_internet 192.168.0.0/16 feb/05/2021 13:43:03 4 ;;; RFC6890 not_in_internet 10.0.0.0/8 feb/05/2021 13:43:03 5 ;;; RFC6890 not_in_internet 169.254.0.0/16 feb/05/2021 13:43:03 6 ;;; RFC6890 not_in_internet 127.0.0.0/8 feb/05/2021 13:43:03 7 ;;; RFC6890 not_in_internet 198.18.0.0/15 feb/05/2021 13:43:03 8 ;;; RFC6890 not_in_internet 192.0.0.0/24 feb/05/2021 13:43:03 9 ;;; RFC6890 not_in_internet 192.0.2.0/24 feb/05/2021 13:43:03 10 ;;; RFC6890 not_in_internet 198.51.100.0/24 feb/05/2021 13:43:03 11 ;;; RFC6890 not_in_internet 203.0.113.0/24 feb/05/2021 13:43:03 12 ;;; RFC6890 not_in_internet 100.64.0.0/10 feb/05/2021 13:43:03 13 ;;; RFC6890 not_in_internet 240.0.0.0/4 feb/05/2021 13:43:03 14 ;;; Multicast_RFC2780 not_in_internet 224.0.0.0/4 feb/05/2021 13:43:12 15 ;;; 6to4_RFC3068 not_in_internet 192.88.99.0/24 feb/05/2021 13:43:12 

Теперь, используя эти листы, создадим еще правила уже в цепочке FORWARD, которые защитят устройства в локальной сети от различных посягательств. Возвращаемся в раздел с правилами:

/ip firewall filter

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

add action=fasttrack-connection chain=forward comment=FastTrack connection-state=established,related

Обрабатываем установленные соединения в цепочке Forward:

add action=accept chain=forward comment="Established, Related" connection-state=established,related

Отбрасываем «‎битые»‎ соединения:

add action=drop chain=forward comment="Drop invalid" connection-state=invalid log=yes log-prefix=invalid

Отбрасываем пакеты, исходящие из локальной сети к частным IP-адресам и фиксируем срабатывание правила в логах:

add action=drop chain=forward comment="Drop tries to reach not public addresses from LAN" dst-address-list=not_in_internet in-interface=bridge1 log=yes log-prefix=!public_from_LAN out-interface=!bridge1

Отбрасываем входящие пакеты, которые не подходят для NAT и фиксируем срабатывание:

add action=drop chain=forward comment="Drop incoming packets that are not NATted" connection-nat-state=!dstnat connection-state=new in-interface=ether1 log=yes log-prefix=!NAT

Отбрасывать пакеты из сети интернет, пришедшие не с публичных IP-адресов и заносить информацию в лог:

add action=drop chain=forward comment="Drop incoming from internet which is not public IP" in-interface=ether1 log=yes log-prefix=!public src-address-list=not_in_internet

Отбрасывать пакеты из локальной сети, не имеющие IP-адресов этой локальной сети, и также отправляем сообщение в лог:

add action=drop chain=forward comment="Drop packets from LAN that do not have LAN IP" in-interface=bridge1 log=yes log-prefix=LAN_!LAN src-address=!192.168.88.0/24

Защита от атак перебором

Брутфорс-атаки давно стали повседневностью. Десятки тысяч ботов регулярно сканируют весь интернет в поисках открытых портов SSH и затем начинают весьма активно «‎стучаться»‎ на внешний интерфейс и перебирать пароли в попытке захватить контроль над подключенным устройством. У тех, кто контролирует эти сети есть весьма обширные словари паролей, использующие как дефолтные реквизиты доступа большинства устройств.

Но даже если вы задали сложный пароль — это еще не гарантирует безопасности. Длительная атака перебором способна сломать этот барьер защиты, поэтому проще всего пресекать попытки злоумышленников сразу, как только замечен процесс перебора. Настройка правил firewall у устройств Mikrotik достаточно тривиальна:

Вначале создадим правило firewall по которому все входящие соединения с IP-адресов, находящихся в списке ssh_blacklist будут сбрасываться:

add chain=input protocol=tcp dst-port=22 src-address-list=ssh_blacklist action=drop comment="Drop SSH brutforce" disabled=no

Теперь сформируем сам список ssh_blacklist. Любой имеет право на ошибку, поэтому если легитимный пользователь три раза ошибся во вводе пароля — это нормально. Так что позволим пользователю сделать 3 ошибки с интервалом в 1 минуту. Большее количество будет свидетельствовать о переборе паролей и IP-адрес атакующего будет попадать в черный список и включается блокировка на 10 дней.

Так что нам потребуется создать еще три списка IP-адресов. Первый назовем ssh_stage1. Как только создается новое соединение на порт SSH мы вносим IP-адрес источника в список. При этом задаем удаление через 1 минуту. Это гарантирует нам то, что если соединение прошло успешно — IP-адрес будет удален из списка.

add chain=input protocol=tcp dst-port=22 connection-state=new action=add-src-to-address-list address-list=ssh_stage1 address-list-timeout=1m comment="Stage1" disabled=no

Если даже пользователь ошибся, то ничего страшного, однако если он попробует в течение этой минуты еще раз подключиться, то его адрес мы закидываем во второй список ssh_stage2 из первого списка ssh_stage1.

add chain=input protocol=tcp dst-port=22 connection-state=new src-address-list=ssh_stage1 action=add-src-to-address-list address-list=ssh_stage2 address-list-timeout=1m comment="Stage2" disabled=no

Если пользователь ошибется второй раз, то закидываем IP-адрес источника из списка ssh_stage2 в список ssh_stage3.

add chain=input protocol=tcp dst-port=22 connection-state=new src-address-list=ssh_stage2 action=add-src-to-address-list address-list=ssh_stage3 address-list-timeout=1m comment="" disabled=no

Третья ошибочная попытка приводит к копированию IP из списка ssh_stage3 в список ssh_blacklist и все входящие соединения с этого IP будут заблокированы сроком на 10 дней.

add chain=input protocol=tcp dst-port=22 connection-state=new src-address-list=ssh_stage3 action=add-src-to-address-list address-list=ssh_blacklist address-list-timeout=10d comment="" disabled=no

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

NAT: базовая настройка и проброс портов

Технология трансляции сетевых адресов (NAT — Network Address Translation) используется во многих случаях. Чаще всего с ней можно встретиться при организации широкополосного доступа к сети интернет. Смысл технологии в том, чтобы дать возможность выходить в сеть множеству устройств, используя всего лишь один внешний IP-адрес.

Все устройства в этом случае будут иметь локальные IP-адреса, например, 192.168.XXX.XXX. Когда устройство запрашивает какой-либо внешний ресурс, то маршрутизатор точно знает от какого адреса в локальной сети пришел запрос и соответственно знает куда направлять обратный поток данных. Но если из внешней сети придет какой-либо запрос, то маршрутизатор его отбросит, поскольку не знает какому устройству в локальной сети его направить.

Решением проблемы является так называемый проброс портов (Port Forwarding). Создавая правило проброса портов мы даем маршрутизатору указания какому устройству перенаправить запрос извне. На логическом уровне подобный запрос может выглядеть как «‎Если на порт XXX придет TCP-запрос, то перенаправь его на локальный адрес 192.168.XXX.XXX на порт YYY»‎. Давайте посмотрим 2 способа как нам настроить NAT на Mikrotik.

Способ 1. Когда выходной IP-адрес может меняться

Изначально Mikrotik ничего о нашем намерении использовать NAT не знает. Для начала укажем, что хотим все пакеты, пришедшие из локальной сети выводились во внешнюю сеть через общий IP-адрес:

ip firewall nat add chain=srcnat out-interface=ether1 action=masquerade

где ether1 — интерфейс, смотрящий в интернет. Также можно задать не один выходной интерфейс, а сразу несколько, заранее сформировав список out-interface-list.

Этот способ наиболее простой и удобный для пользователей с динамическим IP-адресом.

Способ 2. Когда выходной IP-адрес статический и не меняется

Теперь еще один вариант организации NAT. Рассмотрим пример:

ip firewall nat add chain=srcnat out-interface=ether1 action=src-nat to-addresses=XXX.XXX.XXX.XXX

где XXX.XXX.XXX.XXX — статический IP-адрес, а ether1 — выходной интерфейс.

Теперь переходим к пробросу портов. Для примера предположим, что у нас в локальной сети 192.168.88.0/24 есть небольшой сервер по адресу 192.168.88.10 с поднятым SSH. Нам нужно подключаться к серверу удаленно, используя номер порта 1122. Для этого выполним проброс портов, созданием правила:

ip firewall nat add chain=dstnat in-interface=ether1 protocol=tcp dst-port=1122 action=dst-nat to-addresses=192.168.88.10 to-ports=22

Почему мы взяли такой странный номер порта 1122? Все просто — чтобы затруднить злоумышленникам нахождение номера порта и последующего перебора реквизитов. Таким образом, мы создали правило, однозначно позволяющее маршрутизатору понять, что все TCP-пакеты, пришедшие на порт 1122 следует переадресовывать на локальный адрес 192.168.88.10 на порт 22.

Вместо заключения

Мы рассмотрели основные команды для выстраивания базовой защиты для устройств на базе RouterBoard, а также облачной версии Mikrotik CHR и взглянули на то, как можно парой команд настроить NAT. Разумеется, для каждого неиспользуемого сервиса можно закрыть доступ извне, исходя из используемых портов, протоколов и типа трафика.

Угроз безопасности с каждым днем становится все больше и каждая из них заслуживает внимания и адекватного ответа.

Микротик как попасть с заблокированным фаерволл

Обнаружена блокировка рекламы: Наш сайт существует благодаря показу онлайн-рекламы нашим посетителям. Пожалуйста, подумайте о поддержке нас, отключив блокировщик рекламы на нашем веб-сайте.

Скрипт блокировки ip-адресов, с которых пытаются подобрать пользователей роутера

Здесь выкладываем скрипты

Правила форума
Уважаемые Пользователи форума, обратите внимание!
Ни при каких обстоятельствах, Администрация форума, не несёт ответственности за какой-либо, прямой или косвенный, ущерб причиненный в результате использования материалов, взятых на этом Сайте или на любом другом сайте, на который имеется гиперссылка с данного Сайта. Возникновение неисправностей, потерю программ или данных в Ваших устройствах, даже если Администрация будет явно поставлена в известность о возможности такого ущерба.
Просим Вас быть предельно осторожными и внимательными, в использовании материалов раздела. Учитывать не только Ваши пожелания, но и границы возможностей вашего оборудования.

  • Перейти на страницу:

Ruslan.Berezko Сообщения: 3 Зарегистрирован: 23 ноя 2020, 13:02

Добрый! у меня вот такие ошибки валятся в логе при работе скрипта

>>> Script error. Not found string ‘login failure for user’ in log.
>>> Script error. Not found string ‘login failure for user’ in log.
>>> Script error. Not found string ‘login failure for user’ in log.
>>> Script error. Not found string ‘login failure for user’ in log.
>>> Script error. Not found string ‘login failure for user’ in log.
>>> Script error. Not found string ‘TCP connection established from’ in log.
>>> Script error. Not found string ‘TCP connection established from’ in log.
>>> Script error. Not found string ‘TCP connection established from’ in log. эта строчка из-за того что я добавил в скрипт свою запись

# ———— Stage 6 — search for TCP connection established from ————
foreach dangerString in=[ /log find message~»TCP connection established from»; ] do= do :local stringTemp ([ /log get $dangerString message ]);
:local dangerIP ([ :pick $stringTemp ([ :find $stringTemp «from» ] + 5) ([ :len $stringTemp ]) ]);
if ([ /ip firewall address-list find list=»BlockDangerAddress» address=$dangerIP ] = «» ) do= <
/ip firewall address-list add address=$dangerIP list=»BlockDangerAddress» timeout=14d;
:log warning («>>> Added in black list IP «.$dangerIP.» (not TCP connection established from)»);
>
> on-error=< :log warning ">>> Script error. Not found string ‘TCP connection established from’ in log.»; >
>

drpioneer Сообщения: 120 Зарегистрирован: 30 май 2013, 10:20

Добрый день.
Чуть ранее я уже описывал причину появления подобных сообщений.
Такие сообщения выводятся когда нужная запись в LOG-файле изначально была обнаружена, но при попытке её обработать вдруг выясняется, что её нет.
Вероятно имеют место быть какие-то проблемы с LOG-файлом.

Denisov Сообщения: 3 Зарегистрирован: 13 авг 2018, 23:06

drpioneer, привет! Я тоже столкнулся с такой информацией в логах «denied winbox/dude connect from . «. И благодаря твоему скрипту, мне удалось заблокировать многие адреса. Спасибо тебе огромное, огромный тебе RESPECT. Но, могу ли внести некоторые замечания в скрипт. Смотри, когда подключил твой скрипт, который благополучно отработал свою задачу, скрипт стал блокировать адреса, скажем так «которые не нужно» на основе лога. То есть, если я, при входе на микротик со своего адреса, пытался зайти и набрал пароль не верно, то мои действия микротик записал в log, а скрипт тем временем отработал, и мой адрес забанил.
1) Можно ли в скрипт внести условия проверки адреса с названием «White List» или «NoDangerAddress». То есть, сказать скрипту, прежде чем заблокировать адрес, проверить его в списке «White List» или «NoDangerAddress», если адрес есть, этот адрес пропустить, если его нет — заблокировать.
2) Можно ли, чтобы все заблокированные IP адреса, чтобы сохранялись в Address Lists — DropDangerAddress. Чтобы, можно было зайти в этот список, найти IP адресс заблокированный, удалить его оттуда или перенести в белый список. Было бы ОЧЕНЬ удобно. А не вычищать через «Firewall->>Filters ->> Reset All Counters»
P.S. Возможно, я что-то на форуме пропустил и не заметил соообшения. Поправьте меня, если такое уже есть.

Virtue Сообщения: 141 Зарегистрирован: 07 мар 2014, 10:17
29 дек 2020, 12:24

1) Можно ли в скрипт внести условия проверки адреса с названием «White List» или «NoDangerAddress». То есть, сказать скрипту, прежде чем заблокировать адрес, проверить его в списке «White List» или «NoDangerAddress», если адрес есть, этот адрес пропустить, если его нет — заблокировать.
2) Можно ли, чтобы все заблокированные IP адреса, чтобы сохранялись в Address Lists — DropDangerAddress. Чтобы, можно было зайти в этот список, найти IP адресс заблокированный, удалить его оттуда или перенести в белый список. Было бы ОЧЕНЬ удобно. А не вычищать через «Firewall->>Filters ->> Reset All Counters»

Здравствуйте. В вашем случае будет удобно:

1. добавить адрес в белый лист с помощью команды:

/ip firewall address-list add address=ВАШ АДРЕС list="White List"

2. в правилах фаервола добавить разрешающее правило:

/ip firewall filter add chain=input comment="White List" src-address-list="White List"

3. Не забудте поднять это правило выше запрещающего..

В последующем, если в списке заблокированных адресов BlockDangerAddress вы увидите адрес, который блокировать не нужно, просто добавьте его командой, указанной в пункте 1

Denisov Сообщения: 3 Зарегистрирован: 13 авг 2018, 23:06
Virtue, благодарю огромное. Я попробую и напишу о результатах.
Denisov Сообщения: 3 Зарегистрирован: 13 авг 2018, 23:06
29 дек 2020, 18:17
Virtue, благодарю огромное. Я попробую и напишу о результатах.

Изображение

Парни Virtue и dpioneer! Сделал по Вашему совету. Поставил правила «White List» выше запрещающих правил в Firewall ->>Filter. Занес все адреса, также в «White List» в Address Lists , запустил скрипт, скрипт отработал свою задачу и меня не выбросило из сессии. Также, проверив, вышел из сессии и попытался зайти. Зашел, все отлично! Хотя, мой туннельный адрес и внешний адрес висят в обработке BlockDangerAddress заблокированных. Парни, ОГРОМНЫЙ Вам RESPECT
Но, парни, хочу Вас спросить: Ну вот, предположим, забыл или не вспомнил внести IP адрес в White List и кому-то из админов нужно зайти на микротик, а его адрес заблокирован. Как можно было, вытащить IP из заблокированного «Черного списка». Было бы круто, видеть, какие адреса висят в черном списке. Благодарю Вас!

Virtue Сообщения: 141 Зарегистрирован: 07 мар 2014, 10:17
Пожалуйста
30 дек 2020, 11:01
Как можно было, вытащить IP из заблокированного «Черного списка»

Вы имеете ввиду кто должен вытаскивать из блэклиста? Вы? или тот, кого уже забанили?
Если речь про вас,то тут все просто, смотрите в IP-Firewall-Address Lists — DropDangerAddress, упорядочиваете адреса по колонке Timeout и смотрите какой адрес был забанен последним (его тайм будет самым большим, скорее всего это и будет нужный адрес, его и вытаскиваем)
Ну а если же тот, кого забанили, должен сам себя вытащить из блэклиста, то тут приходят в голову 2 варианта:
1. Тот админ, которого забанили, должен сменить у себя адрес (например использовать альтернативный доступ в интернет, либо применить VPN), после этого у него появляется еще одна попытка аторизации с нового адреса.
2. Вы можете добавить проброс с нестандартного порта (правило NAT), а в фаерфоле разрешить соединения на данный нестандартный порт.

drpioneer Сообщения: 120 Зарегистрирован: 30 май 2013, 10:20

Подправил скрипт на предмет корректного вывода служебной информации в LOG-файл.
Ранее, при стечении некоторых событий, выведенная в LOG-файл информация становилась источником новых неверных сообщений в LOG-файле 🙂

 # Script for blocking dangerous addresses that tried to connect to the router by drPioneer # https://forummikrotik.ru/viewtopic.php?t=4781&start=20 # tested on ROS 6.48 # updated 2021/01/16 # ----------- Stage 1 - search for a device login attempt ----------- foreach routerUser in=[ /user find disabled=no; ] do=< do < foreach dangerString in=[ /log find message~"login failure for user"; ] do=< do < :local stringTemp ([ /log get $dangerString message ]); :local dangerUser ([ :pick $stringTemp ([ :find $stringTemp "user" ] + 5) ([ :find $stringTemp "from" ] - 1) ]); :local dangerIP ([ :pick $stringTemp ([ :find $stringTemp "from" ] + 5) ([ :find $stringTemp "via" ] - 1) ]); :local dangerVia ([ :pick $stringTemp ([ :find $stringTemp "via" ]) ([ :find $stringTemp "via" ] + 20)]); if ($routerUser != $dangerUser) do=< if ([ /ip firewall address-list find list="BlockDangerAddress" address=$dangerIP ] = "" ) do=< /ip firewall address-list add address=$dangerIP list="BlockDangerAddress" timeout=14d; :log warning (">>> Added in black list IP ".$dangerIP." (wrong router user '".$dangerUser."' ".$dangerVia.")"); > > > on-error=< :log warning ">>> Script error. Not found string 'Login failure for user' in log."; > > > on-error=< :log warning ">>> Script error. Not found active router user."; > > # ----------- Stage 2 - search for an attempt to enter through IPSec password ----------- foreach dangerString in=[ /log find message~"parsing packet failed, possible cause: wrong password"; ] do=< do < :local stringTemp ([ /log get $dangerString message ]); :local dangerIP ([ :pick $stringTemp 0 ([ :find $stringTemp "parsing" ] - 1) ]); if ([ /ip firewall address-list find list="BlockDangerAddress" address=$dangerIP ] = "" ) do=< /ip firewall address-list add address=$dangerIP list="BlockDangerAddress" timeout=14d; :log warning (">>> Added in black list IP ".$dangerIP." (wrong IPSec password)"); > > on-error=< :log warning ">>> Script error. Not found string 'Parsing packet failed, possible cause: wrong password' in log."; > > # ----------- Stage 3 - search for an attempt to enter through IPSec proposal ----------- foreach dangerString in=[ /log find message~"failed to get valid proposal"; ] do=< do < :local stringTemp ([ /log get $dangerString message ]); :local dangerIP ([ :pick $stringTemp 0 ([ :find $stringTemp "failed" ] - 1) ]); if ([ /ip firewall address-list find list="BlockDangerAddress" address=$dangerIP ] = "" ) do=< /ip firewall address-list add address=$dangerIP list="BlockDangerAddress" timeout=14d; :log warning (">>> Added in black list IP ".$dangerIP." (wrong IPSec proposal)"); > > on-error=< :log warning ">>> Script error. Not found string 'Failed to get valid proposal' in log."; > > # ----------- Stage 4 - search for an attempt to enter through L2TP ----------- foreach dangerString in=[ /log find message~"user" message~"authentication failed"; ] do=< do < :local stringTemp ([ /log get $dangerString message ]); :local dangerUser ([ :pick $stringTemp ([ :find $stringTemp "user" ] + 5) ([ :find $stringTemp "authentication" ] - 1) ]); :local dangerIP ([ :pick $stringTemp ([ :find $stringTemp "" ]) ]); if ([ /ip firewall address-list find list="BlockDangerAddress" address=$dangerIP ] = "" ) do=< /ip firewall address-list add address=$dangerIP list="BlockDangerAddress" timeout=14d; :log warning (">>> Added in black list IP ".$dangerIP." (wrong L2TP user '".$dangerUser."')"); > > on-error=< :log warning ">>> Script error. Not found string 'User' & 'Authentication failed' in log."; > > # ----------- Stage 5 - search for login attempts via WinBox ----------- foreach dangerString in=[ /log find message~"denied winbox/dude connect from"; ] do=< do < :local stringTemp ([ /log get $dangerString message ]); :local dangerIP ([ :pick $stringTemp ([ :find $stringTemp "from" ] + 5) ([ :len $stringTemp ]) ]); if ([ /ip firewall address-list find list="BlockDangerAddress" address=$dangerIP ] = "" ) do=< /ip firewall address-list add address=$dangerIP list="BlockDangerAddress" timeout=14d; :log warning (">>> Added in black list IP ".$dangerIP." (not allowed WinBox user IP-address)"); > > on-error=< :log warning ">>> Script error. Not found string 'Denied winbox/dude connect from' in log."; > > 

Улучшения кода только приветствуются.

Хочется добавить, что в моем случае, накиданные в фаервол правила для защиты WinBox-порта от перебора по вот этой статье с указанием помимо 8291 еще и 8728 порта, отсеивают бОльшую часть желающих подоить роутер уже на этом этапе .

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *