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

Легкий способ защитить свой 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 домена.

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

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

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

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

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

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

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

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

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

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

/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:

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

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

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

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

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

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

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

/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.

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

/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:

И на закладке 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 и попробуем открыть один их них. Яндекс открывается, но выглядит довольно непривычно.

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

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

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

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

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

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

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

/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]

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

/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:

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

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

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

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

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

/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:

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

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

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

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

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

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

/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

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

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

Обход блокировок за NAT без белого IP

На написание статьи меня сподвиг интересный Tutorial от Валерия Лутошкина с настройкой BGP и VPS на оборудовании MikroTik с подключением к проекту antifilter. Это решение натолкнуло меня на домашнюю практику с протоколами динамической маршрутизации. Попробовав его реализовать, я понял, что мой домашний провайдер не даёт манёвров для действий и блокирует порт TCP 179 по умолчанию. В дополнение к этому у меня нет белого IP адреса и я за NATом. В общем все прелести рядового пользователя. Текущая статья является у меня первой. Конструктивную критику и пожелания приветствую.

Предыстория

Для решения задачи по обходу блокировок в домашних условиях, я использовал вариант с покупкой VPS в свободной зоне глобальной сети. Установил на VPS CHR. Далее на домашнем MikroTik создал туннель через SSTP и отдельную Wi-Fi сеть со своим сегментом и бриджом. С использованием маркировки, статикой направлял пакеты в туннель до VPS. Netwatch контролировал наличие активного туннеля до VPS и активный маршрут в таблице маршрутизации на случай, если туннель упадёт, чтобы устройства во втором сегменте полностью не потеряли интернет.

Как выглядела настройка роутера MikroTik

Добавлено правило в firewall mangle:

/ip firewall mangle
add action=mark-routing chain=prerouting disabled=yes new-routing-mark=
browser_mark passthrough=yes src-address=192.168.8.128/25

Добавлен маршрут для маркированных пакетов:

/ip route
add disabled=yes dst-address=0.0.0.0/0 gateway=172.15.1.1 routing-table=
browser_mark suppress-hw-offload=no

И всё бы хорошо, но решение было сделано на коленке и переключаться между Wi-Fi сетями не совсем удобно. Хочется сделать так, чтобы роутер сам определял маршрут следования с использованием обычной домашней сети без разделения сегментов. В любом случае, мы должны прийти к динамической маршрутизации, либо использовать способ с автозагрузкой списка РКН через скрипт в Address list. Казалось бы просто, но мне захотелось, чтобы всё было ещё чуть изящнее. Отключаем старую реализацию с разделением сегментов и приступаем к постановке задачи.

Постановка задачи

Имеется инструкция как подключиться по BGP, обозначенная в начале статьи. А что делать если провайдер всё блокирует или вы находитесь за NAT? Всё верно. Можно попробовать поднять BGP сессию на VPS, а чтобы маршруты через туннель долетали до домашнего роутера, доставить их туда одним из протоколов IGP, например, используя OSPFv2, который включается на MikroTik очень легко. Схематично обозначим нашу цель.

Исходные данные

• Нам необходим VPS хостинг на ваш вкус и цвет в свободной зоне интернет. Не привязываюсь к конкретному, так-как у всех разные предпочтения;
• CHR установленный на VPS. С установкой можно ознакомиться в следующих статьях: Пример1, Пример2, Пример3. Настройка может быть индивидуальна для каждого хостинга, но в целом подход одинаков. Можно попробовать поднять на VPS и другой образ системы. Главное чтобы была поддержка работы с BGP и OSPF. Я использую CHR из-за минимального количества выделяемых для него ресурсов. Как следствие, минимальный тарифный план;
• Лицензия CHR. При использовании бесплатной версии скорость на портах CHR будет всего 1 Мбит/сек. Как получить лицензию бесплатно можно ознакомиться здесь. Стоимость самой лицензии на момент написания статьи около 3000 руб.;
• Любой туннель IPIP для связи Home router и VPS. Главное чтобы мы смогли взаимодействовать по порту TCP 89 для OSPF. Подразумевается, что туннель у вас уже настроен. В примере я использую SSTP (на нестандартном порту). Статикой на сервере VPN (в нашем случае это CHR) настроены параметры IP, которые выдаются всего одному клиенту (домашний роутер);
• Предполагается, что между CHR и Home router нет NAT и запрещающих правил для OSPF. Правила фильтрации на роутерах для WAN интерфейсов настроены на необходимом уровне и на CHR нет запрещающих правил для BGP;
• В примере на домашнем роутере и CHR версия прошивки 7.3.1 stable. В целом, всё «взлетит» и на 6-ой версии с небольшим отличием в командах и интерфейсе Winbox.

Настройка

Для поднятия BGP сессии на VPS используем статью от Валерия Лутошкина. Он достаточно подробно описал процесс. С белым IP адресом на CHR у вас не возникнет «подводных камней» в настройке. По BGP в таблицу маршрутизации прилетит всё что нужно.

Переходим к OSPF. Перед настройкой OSPF обязательно делаем статичным интерфейс на CHR через «SSTP Server Binding». Нужно это для того, чтобы SSTP интерфейс был статичным и не исчезал при отключении клиента (домашнего роутера). В вашем случае это может быть и другой интерфейс.

Далее включаем у CHR протокол OSPF на статическом интерфейсе sstp-in1, который смотрит в сторону Home router. Обратите внимание, что со стороны CHR мы анонсируем маршруты, полученные только по BGP.

/routing ospf instance
add disabled=no name=ospf-instance-1 originate-default=never redistribute=bgp
routing-table=main
/routing ospf area
add disabled=no instance=ospf-instance-1 name=ospf-area-1
/routing ospf interface-template
add area=ospf-area-1 disabled=no instance-id=1 interfaces=sstp-in1

Теперь включаем у Home router протокол OSPF на интерфейсе MT-EXTERNAL, который смотрит в сторону CHR. Обратите внимание, что со стороны Home router мы анонсируем маршруты только со статусом connected. Это необходимо, чтобы наш CHR знал сегменты на домашнем роутере.

/routing ospf instance
add disabled=no name=ospf-instance-1 originate-default=never redistribute=
connected routing-table=main
/routing ospf area
add disabled=no instance=ospf-instance-1 name=ospf-area-1
/routing ospf interface-template
add area=ospf-area-1 disabled=no instance-id=1 interfaces=MT-EXTERNAL

Дополнительные настройки OSPF можно подкрутить по желанию. Ожидаем определения bdr и dr статуса на роутерах. В разделе OSPF=>Neighbors ожидаем конечного статуса «FULL» на CHR и Home Router соответственно. Если с настройкой OSPF возникнут проблемы, возможно поможет статья из wiki MikroTik.

После этого в таблице маршрутизации CHR появятся маршруты до connected сетей домашнего роутера, а на Home router появится несколько десятков тысяч маршрутов в сторону CHR. У меня стоит HAPac2 и он вполне справляется с 11000 тыс. маршрутами и LSA в OSPF. Загрузка CPU и RAM в норме. Для дома это вполне хороший результат.

Финансы

По финансовым расходам у нас получается следующая картина:

• Стоимость лицензии CHR около 3000 руб. либо используем бесплатную версию;
• Стоимость арендной платы за VPS 300 руб./мес. Может чуть больше.

Заключение

Таким образом мы настроили довольно интересную связку. Наш Home router самостоятельно принимает решение куда отправлять пакеты. Вся информация через BGP прилетает на VPS и передаётся на наш домашний роутер по OSPF. Весь процесс максимально автоматизирован, чтобы настроить и комфортно пользоваться глобальной сетью дома. Вместо OSPF можно попробовать запустить другие протоколы IGP.

• IT-инфраструктура
• Сетевые технологии
• Сетевое оборудование

Межсетевой экран:Лженастройки и ошибки при настройке файрвола

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

1. Лженастройки. Как правило, такие правила никак не влияют на работоспособность сети. Только замусоривают конфигурацию и этим затрудняют ее дальнейший анализ. Иногда могут и навредить. Основной признак этой категории — использование каких-то замысловатых параметров. Иногда такие правила называют «фуфломицином».
2. Правила пустышки. Как правило ничего не делают. Ни хуже, ни лучше. Разве, что потребляют ресурсы процессора на обработку бессмысленных правил. Принципиальное отличие от лженастроек это отсутствие использования замысловатых параметров. Такие правила очень хорошо описываются определением «масло масляное».
3. Ошибки. Название говорит само за себя. Условно можно разбить на подкатегории:
   • Результат, который дают такие настройки не соответствует тому, что изначально ожидалось.
   • Отсутствие понимания того как должен быть настроен файрвол. В результате получается то, что хотели получить изначально, но могут быть проблемы или уязвимости.

Лженастройки

Эту категорию лженастроек я характеризую так: «Эта статья в Интернет выглядит умной. Я тоже хочу внедрить у себя такое». Администраторы берут какие-то настройки и абсолютно не понимая, что это, зачем это и с чем это едят копируют настройки к себе. Чаще всего встречаются следующие чудо-настройки.

BOGON

Описание

Эта настройка находится в топе по популярности среди всевозможных лженастроек файервола. Выглядит она следующим образом: вначале делается список адресов с названием «BOGON» и после этого в файерволе этот самый «BOGON» запрещают для входящего интерфейса.

Через консоль это выглядит примерно так:

/ip firewall address list add address=0.0.0.0/8 list=BOGON add address=10.0.0.0/8 list=BOGON add address=100.64.0.0/10 list=BOGON add address=127.0.0.0/8 list=BOGON add address=169.254.0.0/16 list=BOGON add address=172.16.0.0/12 list=BOGON add address=192.0.0.0/12 list=BOGON add address=192.0.2.0/24 list=BOGON add address=192.168.0.0/16 list=BOGON add address=198.18.0.0/15 list=BOGON add address=198.51.100.0/24 list=BOGON add address=203.0.113.0/24 list=BOGON add address=217.67.177.164 list=BOGON add address=224.0.0.0/3 list=BOGON /ip firewall filter add action=drop chain=input in-interface=WAN src-address-list=BOGON

Развенчание мифа

Прежде всего определимся, что такое «BOGON». BOGON — это IP-адреса, которые не должны встречаться в таблицах маршрутизации в Интернет. Этим термином описываются частные и зарезервированные диапазоны адресов. Список этих сетей описывается в RFC 1918, RFC 5735 и RFC 6598. Обратите внимание, что речь идет именно про таблицы маршрутизации устройств у Интернет-провайдеров, а не про все подряд таблицы маршрутизации. Такие адреса часто могут использоваться при DDoS атаках в качестве IP-адреса источника. Помимо просто BOGON есть еще и FULLBOGON про которые почему-то забывают.

У таких сетей есть один очень важный нюанс, который я еще ни разу не встречал что бы учитывали: Ни BOGON, ни FULLBOGON списки не являются статическими. Диапазоны IP-адресов могут, как добавляться, так и убираться из этих списков. Поэтому BOGON-список актуальный сегодня завтра может оказаться неактуальным и файервол начнет блокировать легитимный трафик.

Здесь я люблю задавать вопрос. Почему Вы решили заблокировать сеть 192.0.2.0/24, но при этом не стали блокировать 192.0. 3 .0/24 или 192.0. 4 .0/24 или 192.0. 5 .0/24? На этот вопрос обычно не могут ответить. Более знающие ссылаются на rfc1166 в котором говорится, что сеть 192.0.2.0/24 зарезервирована для «TEST-NET-1», которая может быть использована в документации или в примерах. На встречный вопрос: «Чем не устраивает нормально закрытый файервол?» как правило ответить уже не могут, т. к. нормальной закрытый файрвол скорее всего уже используется и с этим вопросом приходит понимание, что такое правило это «масло маслянное».

Идем дальше. Допустим, каким-то образом мы получили динамические «BOGON» и «FULLBOGON» списки, которые всегда будут находиться в актуальном состоянии. Может быть тогда блокирование этих самых БОГОНОВ будет иметь смысл? Возможно тогда и будет иметь, но куда проще настроить файервол правильно так, чтобы не требовалось создавать дополнительные правила. Для этого нам достаточно настроить файервол в нормально закрытом режиме и заблокировать invalid-трафик.

/ip firewall filter add action=accept chain=input connection-state=established,related #правило №1 в цепочке input add action=drop chain=input connection-state=invalid #правило №2 в цепочке input . add action=drop chain=input #последнее правило в цепочке input # для последнего правила часто дополнительно указывают входящим WAN-интерфейс, но это зависит от конкретных настроек, которые хочет задать администратор сети

Правило, блокирующее invalid-трафик обязательно должно идти вторым сразу за правилом, которое разрешает established и related трафик. Если сделать, например, так:

/ip firewall filter add action=accept chain=input connection-state=established,related add action=accept chain=input protocol=icmp add action=drop chain=input connection-state=invalid

то мы рискуем получить уязвимость в виде возможности посылать на нас нелегитимный ICMP-трафик. И произойдет это следующим образом:

1. Первый вредоносный пакет у которого в качестве источника будет указан адрес из любой сети, в т. ч. и из BOGON, будет обработан на втором правиле, которое разрешает ICMP-трафик. Простым языком: кто-то будет слать якобы ответ на ping-запросы, которые на самом деле не отправлялись.
2. Все дальнейшие пакеты будут обработаны самым первым правилом, которое разрешает established & related трафик.
3. До правила блокирующего invalid трафик дело уже не дойдет. А именно оно должно было бы остановить атаку не зависимо от того откуда идет атака из BOGON сети или из какой-то другой.

Резюме

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

Блокировка TCP-соединений по флагам

Эта лженастройка имеет много разных вариаций. В общих чертах она выглядит как попытка заблокировать что-то на основании флага TCP-соединения с помощью опции «tcp-flag». У этой лженастройки файрвола на MikroTik много разных вариаций. Обычно их объединяет то, что есть несколько правил в которых обязательно будет встречаться что-то на подобие:

. protocol=tcp tcp-flags=fin,syn . protocol=tcp tcp-flags=fin,psh,urg,!syn,!rst,!ack . protocol=tcp tcp-flags=fin,syn,rst,psh,ack,urg

Правила пустышки

В основной своей массе эти правила сводятся к одному: разрешению того, что и так не запрещено.

Описание

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

/ip firewall filter add action=accept chain=input protocol=icmp add action=accept chain=input dst-port=161 protocol=udp src-address-list=zabbix add action=accept chain=input dst-port=8291 protocol=tcp add action=accept chain=input port=500,1701,4500 protocol=udp add action=accept chain=input protocol=ipsec-esp . Далее нет ни одного запрещающего правила 

Развенчание мифа

С пакетом, который попадает в файервол с таким набором правил происходит одно из двух:

1. Пакет попадает под действие одного из правил и оказывается разрешенным.
2. Пакет не попадает под действие ни одного из правил и так как нет запрещающего правила, то пакет оказывается разрешенным.

Т. е. в любом случае пакет оказывается разрешенным.

Резюме

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

Ошибки

Использование нормально открытого файервола

Описание

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

/ip firewall filter add action=drop chain=input dst-port=53 protocol=tcp add action=drop chain=input dst-port=53 protocol=udp add action=drop chain=input dst-port=22 protocol=tcp add action=drop chain=input dst-port=80 protocol=tcp add action=drop chain=input . add action=drop chain=input . add action=drop chain=input . add action=drop chain=input . . Прочие запрещающие правила

Проблема

В приведенном выше примере для цепочки Input используется нормально открытый файервол и блокируется то, что по мнению администратора представляет риск. Действительно держать 53-ий порт (DNS) открытым для Интернета это очень большой риск попасть на атаку типа «DNS Resolve» и получить загрузку процессора службой DNS под 100%.
Проблема в том, что при использовании нормально открытого файервола администратор устанет запрещать. Даже, если предположить, что администратор на 100% знает все, что надо запретить, то такую схему лучше не использовать потому, что значительно увеличится количество правил, через которые будет проходит пакет. А чем большее количество правил будет пройдено пакетом, тем выше будет нагрузка на процессор устройства.

Решение

Сделать файервол нормально закрытым. Т. в нем должно быть запрещено все кроме того, что разрешено и будет небольшой «белый» список доступных сервисов. Например, так:

/ip firewall filter add action=accept chain=input connection-state=established,related #правило №1 в цепочке input add action=drop chain=input connection-state=invalid #правило №2 в цепочке input add action=accept chain=input protocol=icmp add action=accept chain=input dst-port=8291 protocol=tcp add action=accept chain=input port=500,1701,4500 protocol=udp add action=accept chain=input protocol=ipsec-esp add action=drop chain=input in-interface=WAN #последнее правило в цепочке input 

Правила комментариями, которые выделены #синим цветом , должны идти именно в этом порядке.

1. Первое правило снижает нагрузку на процессор, т. к. 99% трафика будет проходить через него.
2. Второе правило блокирует invalid трафик. Что будет если его поместить хотя бы на одну позицию ниже описано в этой статье выше.
3. Последнее правило блокирует все, что явным образом не разрешено правилами, расположенными между вторым и последним правилом.

Неверный порядок правил

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

Пример №1
Пример ситуации, когда блокирующее правило не сработает:

/ip firewall filter . add action=accept chain=input protocol=tcp . add action=drop chain=input dst-port=22 .

В этой ситуации правило, которое блокирует SSH-трафик (22-ой порт TCP) не сработает потому, что выше есть правило, которое разрешает любой TCP-трафик.

Пример №2
Еще один пример ситуации, когда блокирующее правило не сработает:

/ip firewall filter . add action=accept chain=forward dst-address=192.168.15.0/24 . add action=drop chain=forward in-interface=Guest out-interface=LAN .

Если рассматривать эту конфигурацию в отрыве от остальных настроек, то кажется, что трафик из «Guest» в «LAN» должен быть заблокирован, но если посмотреть конфигурацию целиком, то можно обнаружить, что сеть 192.168.15.0/24 принадлежит интерфейсу LAN:

/ip address add address=192.168.15.254/24 interface=LAN network=192.168.15.0

Таким образом мы получаем, что у нас есть разрешающее правило выше запрещающего.

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

/ip firewall filter . add action=drop chain=forward in-interface=DMZ out-interface=LAN . add action=accept chain=forward dst-port=80,443 protocol=tcp

В этом примере есть правило, которое разрешает TCP-трафик с портом назначения 80 и 443. Если рассматривать правило отдельно от остальных, то можно предположить, что из DMZ можно будет попасть в LAN с таким видом трафика. Но по факту это сделать не получится, т. к. выше есть запрещающее правило, которое блокирует любой трафик из DMZ в LAN.

Некорректное использование FastTrack

Многие читали про то, что с помощью FastTrack можно в разы увеличить производительность маршрутизатора. Как правило эту возможность используют в таком виде:

/ip firewall filter add chain=forward action=fasttrack-connection connection-state=established,related

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

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

FastTrack можно и нужно использовать, но не для всего подряд, а точечно выделяя какой-то конкретный вид трафика и пропуская этот выделенный трафик через FastTrack.

Полезные материалы по MikroTik

Углубленный курс "Администрирование сетевых устройств MikroTik" Онлайн-курс по MikroTik с дипломом государственного образца РФ. Много лабораторных работ с проверкой официальным тренером MikroTik. С нуля и до уровня MTCNA. 

На Telegram-канале Mikrotik сэнсей можно получить доступ к закрытой информации от официального тренера MikroTik. Подписывайтесь