Объезжаем блокировки Роскомнадзора на роутере.⁠⁠

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

Базовая настройка защиты роутера MikroTik: настройка устройства, настройка сетевого экрана, защита от сканирования портов, защита от подбора пароля.

🔔 В статье даны примеры команд в терминале MikroTik. Если при вставке команды в терминал, происходит автоматическая вставка команд (при выполнении вы получаете ошибку bad command name или expected end of command), нажмите сочетание Ctrl+V, чтобы отключить эту возможность.

Зачем мы это делаем?

Есть много причин для лучшей защиты DNS-трафика. Хотя веб-трафик и другие коммуникации могут быть защищены криптографическими протоколами, такими как Transport Layer Security (TLS), но почти весь трафик DNS передаётся незашифрованным. Это означает, что ваш провайдер (или кто-то другой между вами и интернетом) может регистрировать посещаемые сайты даже при работе через сторонний DNS — и использовать эти данных в своих интересах, включая фильтрацию контента и сбор данных в рекламных целях.

Как выглядит типичный обмен данными между устройством и DNS-резолвером

«У нас есть проблема “последней мили” в DNS, — говорил Крикет Лю, главный архитектор DNS в компании Infoblox, которая занимается информационной безопасностью. — Большинство наших механизмов безопасности решают вопросы коммуникаций между серверами. Но есть проблема с суррогатами резолверов на различных операционных системах. В реальности мы не можем их защитить». Проблема особенно заметна в странах, где власти более враждебно относятся к интернету.

В некоторой степени помогает использование DNS, который не ведёт логи. Но это всё равно не мешает злоумышленнику фильтровать запросы по контенту или перехватывать адреса методом пакетного перехвата или глубокой инспекции пакетов. Кроме пассивной прослушки есть угроза более активных атак на ваш DNS-трафик — спуфинг DNS-сервера со стороны провайдера или спецслужб с перенаправлением на собственный сервер для отслеживания или блокировки трафика. Что-то подобное (хотя, по-видимому, не злонамеренно), похоже, происходит со случайным перенаправлением трафика на адрес 1.1.1.1 из сети AT&T, судя по сообщениям на форумах DSLReports.

Наиболее очевидный способ уклонения от слежки — использование VPN. Но хотя VPN скрывают содержимое вашего трафика, для подключения к VPN может потребоваться запрос DNS. И в ходе VPN-сеанса запросы DNS тоже могут иногда направляться веб-браузерами или другим софтом за пределы VPN-тоннеля, создавая «утечки DNS», которые раскрывают посещённые сайты.

Вот где вступают в игру протоколы шифрования DNS: это DNSCrypt (среди прочих, его поддерживает OpenDNS от Cisco), DNS по TLS (поддерживается Сloudflare, Google, Quad9, OpenDNS) и DNS по HTTPS (поддерживается Сloudflare, Google и сервисом блокировки «взрослого» контента CleanBrowsing). Шифрование гарантирует, что трафик не просканируют и не изменят, и что запросы не получит и не обработает поддельный DNS-сервер. Это защищает от атак MiTM и шпионажа. DNS-прокси с одной из этих служб (непосредственно на устройстве или на «сервере» в локальной сети) поможет предотвратить DNS-утечки через VPN, поскольку прокси-сервер всегда будет самым быстрым DNS-сервером среди всех доступных.

Однако эта опция защиты недоступна массовому пользователю. Ни один из этих протоколов нативно не поддерживается ни одним DNS-резолвером, который идёт в комплекте с ОС. Все они требуют установки (и, вероятно, компиляции) клиентского приложения, которое действует как локальный «сервер» DNS, ретранслируя запросы, сделанные браузерами и другими приложениями вверх по течению к безопасному провайдеру DNS по вашему выбору. И хотя две из трёх данных технологий предлагаются на роль стандартов, ни один из проверенных нами вариантов пока не представлен в окончательном виде.

Поэтому если хотите погрузиться в шифрование DNS, то лучше взять для DNS-сервера в домашней сети Raspberry Pi или другое отдельное устройство. Потому что вы наверняка обнаружите, что настройка одного из перечисленных клиентов — это уже достаточно хакерства, чтобы не захотеть повторять процесс заново. Проще запросить настройки DHCP по локальной сети — и указать всем компьютерам на одну успешную установку DNS-сервера. Я много раз повторял себе это во время тестирования, наблюдая падение одного за другим клиентов под Windows и погружение в спячку клиентов под MacOS.

Сообщество DNSCrypt пыталось сделать доступный инструмент для тех, кто не обладает навыками работы в командной строке, выпустив программы DNSCloak (слева) под iOS и Simple DNSCrypt (справа) под Windows

Как использовать DNS over HTTPS (DoH) в iOS 14

Почему важно защитить DNS-трафик?

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

Насколько шифрование DNS улучшает ситуацию? Использование защищенных протоколов позволяет обезопасить ваши DNS-запросы и DNS-ответы.

Если вы не доверяете сети, к которой подключены, то вы можете отправлять запросы на надежный DNS-сервер.

Зачем так мучиться?

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

Тем не менее, важно отметить, что одно лишь шифрование DNS не скроет ваши действия в интернете. Если на сервере хостятся несколько сайтов, то расширение TLS под названием Server Name Indicator (SNI), используемое в соединениях HTTPS, всё равно может показать открытым текстом название сайта, на который вы зашли. Для полной конфиденциальности всё равно нужно использовать VPN (или Tor) для такой инкапсуляции трафика, чтобы провайдер или какая-либо другая шпионящая сторона не могла вытянуть метаданные из пакетов. Но ни один из перечисленных сервисов не работает с Tor. И если против вас работает правительственное агентство, то ни в чём нельзя быть уверенным.

Другая проблема в том, что, хотя прекрасные ребята из сообщества DNSCrypt проделали большую работу, но такая приватность по-прежнему слишком сложна для обычных людей. Хотя некоторые из этих DNS-клиентов для шифрования оказалось относительно легко настроить, но ни один из них нельзя назвать гарантированно простым для нормальных пользователей. Чтобы эти услуги стали действительно полезными, их следует плотнее интегрировать в железо и софт, который покупают люди — домашние маршрутизаторы, операционные системы для персональных компьютеров и мобильных устройств.

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

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

Соседи

Настроим обнаружение устройства используя Neighbor Discovery только для внутренних интерфейсов или разрешенных интерфейсов.

Разрешаем обнаружение только с интерфейсов перечисленных в списке InternalInterfaces.

[IP] -> [Neighbor] -> [Discovery Settings] -> [interface=InternalInterfaces]

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

Как настроить AdGuard DNS в iOS 14

Настройка профиля

Первоначально нужно настроить профиль DNS с поддержкой DNS over HTTPS (DoH) в iOS 14. Рассмотрим на настройку на примере профилей, доступных для всех конфигураций AdGuard DNS и Comss.one DNS. Можно настроить все профили и переключаться между ними по необходимости.

Просто откройте одну из следующих страниц в Safari на мобильном устройстве iOS:

AdGuard DNS

• Профиль AdGuard DNS – блокировка рекламы, отслеживания, вредоносных сайтов и фишинга.
• Профиль AdGuard DNS Семейная защита – выполняет те же защитные функции, что и профиль AdGuard DNS и дополнительно блокирует сайты для взрослых, включает безопасный поиск в поисковиках и режим YouTube Kids.
• Нефильтрующий профиль AdGuard DNS – без фильтрации контента и блокировок. Подходит, если вам нужен быстрый DNS-сервер без регистрации активности.

Comss.one DNS

• Профиль Comss.one DNS – блокировка рекламы, отслеживания, вредоносных и фишинговых сайтов (основные серверы).
• Профиль Comss.one DNS Восток – блокировка рекламы, отслеживания, вредоносных и фишинговых сайтов серверы для Сибири и Дальнего Востока.

Как установить DNS over HTTPS (DoH) в iOS 14

После загрузки профиля перейдите в секцию Настройки. Там будет вкладка Профиль загружен.

Выберите эту опцию, просмотрите данные профиля и нажмите Установить.

Как протестировать DNS over HTTPS (DoH) в iOS 14

Управлять профилями DNS можно в разделе Настройки > VPN и сеть > DNS. Вы можете переключаться между доступными профилями.

Чтобы проверить работу AdGuard DNS , перейдите на тестовую страницу AdGuard и убедитесь, что AdGuard DNS обнаружен.

Проверить работу Comss.one DNS можно с помощью сервиса DNS Leak Test (нажмите кнопку Extended test). Убедитесь, что все найденные DNS-серверы относятся к Comss.one DNS.

Если вы используете приложения AdGuard VPN или Adguard для iOS, то в приоритетном порядке будет использоваться настроенный в них DNS-сервер.

В чем отличие DNS over HTTPS (DoH) от приложения AdGuard

По сравнению с приложением AdGuard, у AdGuard DNS и Comss.one DNS есть несколько недостатков. Так вы не видите, какие именно запросы совершают установленные на устройстве приложения. Вы также не сможете использовать DNS-фильтрацию и вручную задавать, какие серверы нужно заблокировать, а какие разрешить.

В любом случае, DNS с поддержкой DNS over HTTPS (DoH) предоставляет простой способ. чтобы начать использовать защищенные DNS-протоколы. Еще одно преимущество данного метода заключается в нативной поддержке в iOS. В следующей версии Adguard для iOS будет добавлена возможность настройки DNS-серверов с помощью механизма ОС.

Шифруемся

Для полноты картины в исторической перспективе начнём обзор с самой первой технологии шифрования DNS — DNSCrypt. Впервые представленный в 2008 году на BSD Unix, инструмент DNSCrypt изначально предназначался для защиты не от прослушки, а от DNS-спуфинга. Тем не менее, его можно использовать как часть системы обеспечения конфиденциальности — особенно в сочетании с DNS-сервером без логов. Как отметил разработчик DNSCrypt Фрэнк Денис, гораздо больше серверов поддерживают DNSCrypt, чем любой другой вид шифрования DNS.

«DNSCrypt — это немного больше, чем просто протокол, — говорит Фрэнк Денис. — Сейчас сообщество и активные проекты характеризуют его гораздо лучше, чем мой изначальный протокол, разработанный в выходные». Сообщество DNSCrypt создало простые в использовании клиенты, такие как Simple DNSCrypt для Windows и клиент для Apple iOS под названием DNS Cloak, что делает шифрование DNS доступнее для нетехнических людей. Другие активисты подняли независимую сеть приватных DNS-серверов на основе протокола, помогающего пользователям уклониться от использования корпоративных DNS-систем.

«DNSCrypt — это не подключение к серверам конкретной компании, — сказал Денис. — Мы призываем всех поднимать собственные сервера. Сделать это очень дёшево и легко. Теперь, когда у нас есть безопасные резолверы, я пытаюсь решить задачу фильтрации контента с учётом конфиденциальности».

Для тех, кто хочет запустить DNS-сервер с поддержкой DNSCrypt для всей своей сети, лучшим клиентом будет DNSCrypt Proxy 2. Старая версия DNSCrypt Proxy по-прежнему доступна как пакет для большинства основных дистрибутивов Linux, но лучше загрузить бинарник новой версии непосредственно с официального репозитория на GitHub. Есть версии для Windows, MacOS, BSD и Android.

Для своего тестирования DNSCrypt я использовал OpenDNS от Cisco в качестве удалённого DNS-сервиса. При первых запросах производительность DNSCrypt оказалась немного хуже, чем у обычного DNS, но затем DNSCrypt Proxy кэширует результаты. Самые медленные запросы обрабатывались в районе 200 мс, в то время как средние — примерно за 30 мс. (У вас результаты могут отличаться в зависимости от провайдера, рекурсии при поиске домена и других факторов). В целом, я не заметил замедления скорости при просмотре веб-страниц.

Основное преимущество DNSCrypt в том, что он похож на «обычный» DNS. Хорошо это или плохо, но он передаёт UDP-трафик по порту 443 — тот же порт используется для безопасных веб-соединений. Это даёт относительно быстрый резолвинг адресов и снижает вероятность блокировки на файрволе провайдера. Чтобы ещё больше снизить вероятность блокировки, можно изменить конфигурацию клиента и передавать запросы по TCP/IP (как показало тестирование, это минимально влияет на время отклика). Так шифрованный DNS-трафик для большинства сетевых фильтров похож на трафик HTTPS — по крайней мере, с виду.

Показан трафик DNSCrypt и локальный трафик DNSCrypt Proxy. Снифер Wireshark говорит, что это трафик HTTPS, потому что я форсировал использование TCP. Если пустить его по UDP, то Wireshark увидит трафик Chrome QUIC

С точки зрения разработчика немного сложно работать с DNSCrypt. «DNSCrypt не особенно хорошо документирован, и не так много его реализаций», — говорит Крикет Лю из Infoblox. На самом деле мы смогли найти только единственный клиент в активной разработке — это DNSCrypt Proxy, а OpenDNS прекратил поддерживать его разработку.

Интересный выбор криптографии в DNSCrypt может напугать некоторых разработчиков. Протокол использует Curve25519 (RFC 8032), X25519 (RFC 8031) и Chacha20Poly1305 (RFC 7539). Одна реализация алгоритма X24419 в криптографических библиотеках Pyca Python помечена как «криптографически опасная», потому что с ней очень легко ошибиться в настройках. Но основной используемый криптографический алгоритм Curve25519, является «одной из самых простых эллиптических кривых для безопасного использования», — сказал Денис.

Разработчик говорит, что DNSCrypt никогда не считался стандартом IETF, потому что был создан добровольцами без корпоративной «крыши». Представление его в качестве стандарта «потребовало бы времени, а также защиты на заседаниях IETF», — сказал он. «Я не могу себе этого позволить, как и другие разработчики, которые работают над ним в свободное время. Практически все ратифицированные спецификации, связанные с DNS, фактически написаны людьми из одних и тех же нескольких компаний, из года в год. Если ваш бизнес не связан с DNS, то действительно тяжело получить право голоса».

Интерфейсы

Объединим внутренние (доверенные) и внешние (недоверенные) интерфейсы в списки, для удобства дальнейшего управления.

Список «Внутренние интерфейсы»

Помещаем в этот список интерфейсы локальной сети, VPN подключения и т.д.

[Interfaces] -> [Interfaces] -> [Interface List] -> [Lists] -> [+] -> [Name=InternalInterfaces, Comment="Trusted network interfaces (internal, clients vpn, etc)."]

/interface list add name=InternalInterfaces comment="Trusted network interfaces (internal, clients vpn, etc)."

Список «Внешние интерфейсы»

Помещаем в этот список внешние интерфейсы (интернет и т.д.).

[Interfaces] -> [Interfaces] -> [Interface List] -> [Lists] -> [+] -> [Name=ExternalInterfaces, Comment="Untrusted network interfaces (internet, external etc)."]

/interface list add name=ExternalInterfaces comment="Untrusted network interfaces (internet, external etc)."

Особенности работы файрвола

Для базового понимания работы файрвола, необходимо ознакомиться с понятиями цепочки (chain), состояния соединения (connection state), условия и действия (action).

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

• input входящий трафик предназначенный для маршрутизатора. Например, когда вы подключаетесь к маршрутизатору при помощи приложения winbox, трафик как раз попадает в эту цепочку.
• output Исходящий трафик. Трафик, создаваемый самим маршрутизатором. Например, если вы выполните команду ping непосредственно с самого маршрутизатора, трафик попадет в эту цепочку.
• forward Трафик, идущий через маршрутизатор. Например, если компьютер из локальной сети, установил соединение с внешним сайтом, данный трафик попадает в цепочку forward.

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

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

Состояние соединения (connection state)

Каждое из сетевых соединений MikroTik относит к одному из 4 состояний:

• New – Новое соединение. Пакет, открывающий новое соединение, никак не связанное с уже имеющимися сетевыми соединениями, обрабатываемыми в данный момент маршрутизатором.
• Established – Существующее соединение. Пакет относится у уже установленному соединению, обрабатываемому в данный момент маршрутизатором.
• Related – Связанное соединение. Пакет, который связан с существующим соединением, но не является его частью. Например, пакет, который начинает соединение передачи данных в FTP-сессии (он будет связан с управляющим соединением FTP), или пакет ICMP, содержащий ошибку, отправляемый в ответ на другое соединение.
• Invalid – Маршрутизатор не может соотнести пакет ни с одним из вышеперечисленных состояний соединения.

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

1. Обрабатывать новые соединения (connection state = new), принимая решение об пропуске или блокировке трафика.
2. Всегда пропускать соединения в состоянии established и related, так как решение о пропуске этого трафика было принято на этапе обработки нового соединения.
3. Всегда блокировать трафик, для которого состояние соединения равно invalid, потому что этот трафик не относится ни к одному из соединений и фактически является паразитным.

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

1. Пакет будет соответствовать заданному условию. При этом сработает соответствующее правило, в котором это условие было задано, после чего обработка пакета будет завершена.
2. Закончатся все условия и пакет не будет признан соответствующим ни одному из них. При этом, по умолчанию он будет пропущен дальше.

Исходя из п.2, нельзя не отметить, что есть две стратегии построения фильтра пакетов:

1. Нормально открытый файрвол. Данный тип настройки можно определить как «Все разрешено, что не запрещено». При этом мы запрещаем прохождение только некоторых типов трафика. Если пакет не соответствует этим типам – он будет пропущен. Обычно данный тип файрвола характерен для мест, где не предъявляется высоких требований к безопасности пользователей, а трафик может быть самым разнообразным и не поддающимся жесткой квалификации. Такая настройка характерна для операторов связи (Интернет-провайдеров), открытых точек доступа, домашних маршрутизаторов.
2. Нормально закрытый файрвол. Данный тип настройки можно определить как «Все запрещено, что не разрешено». При этом разрешается прохождение только определенных типов трафика, а последним правилом в файрволе стоит правило, запрещающее прохождение любого типа трафика. Такой тип настройки файрвола характерен для корпоративного использования, где существуют жесткие требования к безопасности.

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

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

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

обозначает что адрес источника любой, кроме 192.168.0.0/24 . Также обратите внимание, что если поле не заполнено, оно должно быть серым. Если вы передумали заполнять поле, чтобы его исключить и сделать серым – нажмите стрелку «вверх», справа от поля.

На этой закладке собраны расширенные опции выбора пакета.

Эта закладка продолжает список расширенных опций, не поместившихся на закладку Advanced.

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

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

Как спрятать DNS-запросы от любопытных глаз провайдера

Настройка 1.1.1.1 от Cloudflare и других DNS-сервисов по-прежнему требует навыков работы в командной строке

Шифрование трафика между вашим устройством и DNS-сервисом помешает посторонним лицам отслеживать трафик или подменить адрес

Смерть сетевого нейтралитета и ослабление правил для интернет-провайдеров по обработке сетевого трафика вызвали немало опасений по поводу конфиденциальности. У провайдеров (и других посторонних лиц, которые наблюдают за проходящим трафиком) уже давно есть инструмент, позволяющий легко отслеживать поведение людей в интернете: это их серверы доменных имен (DNS). Даже если они до сих пор не монетизировали эти данные (или не подменяли трафик), то наверняка скоро начнут.

DNS — это телефонный справочник Сети, выдающий фактический сетевой адрес IP, связанный с хостингом и доменными именами сайтов и других интернет-служб. Например, он превращает arstechnica.com в 50.31.169.131. Ваш интернет-провайдер предлагает DNS в пакете услуг, но он также может журналировать DNS-трафик — по сути, записывать историю ваших действий в интернете.

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

Как работает DNS

DNS по HTTPS

Запросы отправляются как HTTP POST или GET с телом в формате сообщения DNS (датаграммы из обычных DNS-запросов) или как запрос HTTP GET в формате JSON (если вы не против небольшого оверхеда). И здесь нет никаких проблем с управлением сертификатами. Как и при обычном веб-трафике HTTPS, для подключения через DoH не требуется аутентификация, а сертификат проверяется центром сертификации.

Фиксация DNS-транзакции через DoH. Видно только HTTPS, TLS и ничего больше

В результате, хотя на спецификациях RFC для DoH ещё не просохли чернила, уже готов к работе целый ряд клиентов DNS по HTTPS. Правда, некоторые из них заточены под конкретных провайдеров DNS. Потеря производительности во многом зависит от сервера и от качества конкретного клиента.

Это можно исправить одним из трёх способов. Первый вариант: установить устройство с локальным хостом ( 127.0.0.1 для IPv4 и ::1 для IPv6) как основной DNS-сервер в сетевой конфигурации, а затем добавить 1.1.1.1 в качестве дополнительного резолвера. Это рабочий вариант, но он не идеален с точки зрения приватности и производительности. Лучше добавить URL сервера из командной строки при загрузке:

Во время проверки обработки стандартных запросов службой dns.google.com я наткнулся на альтернативу дефолтному адресу 8.8.8.8 от Google (172.217.8.14, если знаете). Я добавил его в Dingo из командной строки:

Это сократило время отклика примерно на 20%, то есть примерно до того показателя, как у Argo.

Я не Бэтмен, но моя модель угроз всё равно немного сложнее, чем у большинства людей

Действия при фильтрации пакетов

Действия задаются на закладке Action сформированного правила.

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

Добавить адрес назначения пакета в именованный список адресов (address list).

• Address-List – Имя списка адресов. Выбирается из списка или задается новое.
• Timeout – Время, которое данный адрес будет присутствовать. По истечении заданного времени адрес будет удален из списка.

Добавить адрес источника пакета в именованный список адресов (address list).

• Address-List – Имя списка адресов. Выбирается из списка или задается новое.
• Timeout – Время, которое данный адрес будет присутствовать. По истечении заданного времени адрес будет удален из списка.

Обратите внимание, что динамические списки адресов являются очень мощным инструментом. Так как мы можем учитывать списки адресов в правилах выбора пакета на закладке Advanced, фактически, таким образом мы можем динамически менять правила фильтрации трафика.

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

Перейти на собственную цепочку (chain) обработки пакетов.

Опция – наименование цепочки.

Занести информацию о пакете в Log-файл маршрутизатора. При этом пакет будет передан на следующее правило. Данная опция часто используется при отладке.

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

Запретить прохождение пакета и отправить отправляющему узлу ICMP-сообщение об ошибке.

Опция – вид сообщения.

Досрочно прервать обработку собственной цепочки (chain) и вернуться на следующее правило за правилом с Action=jump, которое передало пакет в эту цепочку.

Очень интересная опция. Может использоваться только с протоколом TCP. Суть в том, что маршрутизатор дает разрешение на создание соединения, при этом выставляя нулевое окно передачи (т.е. скорость соединения = 0). Позволяет «завесить» атакующий хост на этом соединении.

Сервисы

Отключить неиспользуемые сервисы

Отключаем сервисы MikroTik, которые не планируем использовать.

[IP] -> [Services]

• api, порт 8728 — если не используем API доступ, отключаем;
• api-ssl, порт 8729 — если не используем API доступ с сертификатом, отключаем;
• ftp, порт 21 — если не используем FTP доступ, отключаем;
• ssh, порт 22 — если не используем SSH доступ, отключаем;
• telnet, порт 23 — если не используем Telnet доступ, отключаем;
• www, порт 80 — если не используем доступ через Web браузер (http), отключаем;
• www-ssl, порт 443 — если не используем доступ через Web браузер (https), отключаем.

Изменить порт Winbox

Измените номер порта Winbox по умолчанию — 8291, на другой, свободный номер порта — Port (в примере порт 30122).

[IP] -> [Services] -> [winbox: port=Port]

При изменении порта, следите чтобы не назначить Winbox порт используемый другой службой, список — здесь.

Межсетевой экран

Настраиваем ограничения доступа к роутеру и устройствам сети с помощью межсетевого экрана MikroTik.

⚠️ Перед добавлением ограничивающих правил — включите Безопасный режим MikroTik!

Разрешить установленные и связанные соединения

Правило «Trusted» — разрешаем уже установленные и связанные подключения, для снижения нагрузки на центральный процессор роутера.

[IP] -> [Firewall] -> [Filter Rules] -> [+] -> [General: Chain=input, Connection state=established,related; Action: Action=accept; Comment="Rule #0 "Trusted": allow established, related connections."]

/ip firewall filter add action=accept chain=input connection-state=established,related comment="Rule #0 \"Trusted\": allow established, related connections."

Отбросить недействительные пакеты

Правило «Drop Invalid Packet» — отбрасывает недействительные пакеты.

[IP] -> [Firewall] -> [Filter Rules] -> [+] -> [General: Chain=input, Connection state=invalid; Action: Action=drop; Comment="Chain: Input. Rule #1 "Drop Invalid Packet": drop packets connection state: invalid."]

/ip firewall filter add chain=input action=drop connection-state=invalid comment="Chain: Input. Rule #1 \"Drop Invalid Packet\": drop packets connection state: invalid." 

Разрешить ICMP

Правило «ICMP» — разрешает ICMP трафик на устройство.

[IP] -> [Firewall] -> [Filter Rules] -> [+] -> [General: Chain=input, Protocol=icmp; Action: Action=accept; Comment="Chain: Input. Rule #3 "ICMP": accept icmp packets."]

/ip firewall filter add chain=input protocol=icmp action=accept comment="Chain: Input. Rule #3 \"ICMP\": accept icmp packets."

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

Создать список

Создаем список BlackList, в который будем помещать IP адреса, которым по какой-то причине запрещен доступ к MikroTik или защищаемым устройствам.

[IP] -> [Firewall] -> [Address Lists] -> [Name: BlackList, Comment="Deny access to the router and local network, from IP addresses from this list."]

/ip firewall address-list add list=BlackList comment="Deny access to the router and local network, from IP addresses from this list."

Создать правило

Создадим правило «BlackList» отклоняющее запросы от IP адресов из списка BlackList.

Для экономии ресурсов центрального процессора, запрещающее правило разместим в таблице Prerouting.

[IP] -> [Firewall] -> [Raw] -> [+] -> [General: Chain=prerouting; Advanced: Src. Address List=BlackList ; Action: drop; Comment="Rule #10 "BlackList": reject the connection with a device from the Blacklist."]

/ip firewall raw add chain=prerouting src-address-list=BlackList action=drop comment="Rule #10 \"BlackList\": reject the connection with a device from the Blacklist." 

⚠️ Правила размещенные в Prerouting выполняются до разделения трафика на цепочки Input и Forward!

На скриншоте видно дополнительные правила:

Блокировка сканеров портов

Правило превентивной блокировки — блокируем ботов/пользователей сканирующих порты устройств в интернете, для поиска уязвимостей. Составим список не используемых портов нашим роутером, внесем в BlackList IP адреса устройств, кто пытается обратиться к указанным портам.

Для защиты от сканеров, которые целенаправленно ищут устройства MikroTik — добавим в список неиспользуемые порты (сервисы MikroTik) и стандартный порт Winbox 8291 (который мы сменили по рекомендации). Добавим популярные уязвимые порты роутеров (если злоумышленник проверяет на роутере данные порты, полностью заблокируем ему доступ).

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

TCP порты ловушки

Создать правило

Помещаем IP адрес недоверенного устройства в BlackList, на 10 часов:

/ip firewall filter add action=add-src-to-address-list address-list=BlackList address-list-timeout=10h chain=input protocol=tcp connection-state=new dst-port=20-25,80,110,161,443,445,3128,3306,3333,3389,7547,8291,8080-8082 comment="Rule #1 \"Block TCP port scanning\": add a device scanning an unused port to BlackList." 

🚯 За 10 часов в BlackList находится около 500 IP адресов выполняющих попытки сканировать «уязвимые порты» роутера MikroTik.

Разрешим порт Winbox

Правило «Winbox» — разрешаем подключение на порт Winbox (в примере — 30122).

[IP] -> [Firewall] -> [Filter Rules] -> [+] -> [General: Chain=input, Protocol=tcp, Dst. Port=30122; Action: Action=accept; Comment="Chain: Input. Rule #10 "Winbox": accept Winbox port connections."]

/ip firewall filter add chain=input protocol=tcp dst-port=30122 action=accept comment="Chain: Input. Rule #10 \"Winbox\": accept Winbox port connections."

Сбрасываем неразрешенные соединения

Правило «Drop all» — отбросим все соединения, которые не были разрешены раньше и не входят в список доверенных (внутренних) интерфейсов (InternalInterfaces).

[IP] -> [Firewall] -> [Filter Rules] -> [+] -> [General: Chain=input, In. Interface List=[!]InternalInterfaces; Action: Action=drop; Comment="Chain: Input. Rule #15 "Drop All": drop_all packets that do not meet the early conditions, except from trusted interfaces."]

/ip firewall filter add action=drop chain=input in-interface-list=!InternalInterfaces comment="Chain: Input. Rule #15 \"Drop All\": drop_all packets that do not meet the early conditions, except from trusted interfaces."

Поместите правило на последнюю позицию в правилах Firewall Filter Rules.

Блокируем Bruteforce

Правило «Bruteforce» — поместим IP адрес устройства в BlackList, при повторной неудачной попытке авторизации на устройстве.

Помещаем IP адрес устройства в BlackList, на 70 минут.

[IP] -> [Firewall] -> [Raw] -> [+] -> [General: Chain=output; Advanced: Content="invalid user name or password"; Action: Action=add-dst-to-address-list; Address List=BlackList, Timeout=01:10:00; Comment="Rule #15 "Bruteforce": add a device performing unsuccessful authorization to BlackList."]

/ip firewall raw add chain=output content="invalid user name or password" action=add-dst-to-address-list address-list=BlackList address-list-timeout=1h10m comment="Rule #15 \"Bruteforce\": add a device performing unsuccessful authorization to BlackList."

🟢 Защита MikroTik — базовая настройка безопасности, обсуждалось в этой статье. Я надеюсь, что теперь вы смогли настроить сервисы роутера и правила файрволла, улучшив защиту роутера MikroTik и устройств локальной сети. Однако, если вы столкнетесь с каким-то проблемами при настройке, не стесняйтесь написать в комментариях. Я постараюсь помочь.

Обновление

В оборудовании MikroTik (как и в оборудовании других сетевых вендоров) периодически находят уязвимости — своевременное выполнение обновлений необходимая мера для обеспечения безопасности устройства.

[System] -> [Packages] -> [Check for updates] -> [Check for updates]

Если обновление версии будет найдено, выполните обновление устройства.

🔗 Скрипт Проверка обновления RouterOS, пришлет уведомление о выходе новой версии прошивки.

Пользователи

[System] -> [Users]

Не используйте простые имена пользователя, пароль должен соответствовать требованиям безопасности.

Если доступ к устройству имеют несколько пользователей, вы можете более подробно задать права выбранному пользователю. Создайте новую группу и определите права пользователей этой группы.

[System] -> [Users] -> [Groups] -> [+]

Скрещивание с TLS

У DNS по TLS (Transport Layer Security) несколько преимуществ перед DNSCrypt. Во-первых, это предлагаемый стандарт IETF. Также он довольно просто работает по своей сути — принимает запросы стандартного формата DNS и инкапсулирует их в зашифрованный TCP-трафик. Кроме шифрования на основе TLS, это по существу то же самое, что и отправка DNS по TCP/IP вместо UDP.

Существует несколько рабочих клиентов для DNS по TLS. Самый лучший вариант, который я нашел, называется Stubby, он разработан в рамках проекта DNS Privacy Project. Stubby распространяется в составе пакета Linux, но есть также версия для MacOS (устанавливается с помощью Homebrew) и версия для Windows, хотя работа над последней ещё не завершена.

Хотя мне удалось стабильно запускать Stubby на Debian после сражения с некоторыми зависимостями, этот клиент регулярно падал в Windows 10 и имеет тенденцию зависать на MacOS. Если вы ищете хорошее руководство по установке Stubby на Linux, то лучшая найденная мной документация — это пост Фрэнка Сантосо на Reddit. Он также написал shell скрипт для установки на Raspberry Pi.

Клиенты DNS по TLS при подключении к серверу DNS осуществляют аутентификацию с помощью простой инфраструктуры открытых ключей (Simple Public Key Infrastructure, SPKI). SPKI использует локальный криптографический хэш сертификата провайдера, обычно на алгоритме SHA256. В Stubby этот хэш хранится как часть описания сервера в файле конфигурации YAML, как показано ниже:

После установления TCP-соединения клиента с сервером через порт 853 сервер представляет свой сертификат, а клиент сверяет его с хэшем. Если всё в порядке, то клиент и сервер производят рукопожатие TLS, обмениваются ключами и запускают зашифрованный сеанс связи. С этого момента данные в зашифрованной сессии следуют тем же правилам, что и в DNS по TCP.

После успешного запуска Stubby я изменил сетевые настройки сети DNS, чтобы направлять запросы на 127.0.0.1 (localhost). Сниффер Wireshark хорошо показывает этот момент переключения, когда трафик DNS становится невидимым.

Переключаемся с обычного трафика DNS на шифрование TLS

Частично замедление работы происходит на стороне сервера из-за лишнего использования TCP. Обычно DNS работает по быстрому протоколу UDP: отправил и забыл, в то время как сообщение TCP требует согласования соединения и проверки получения пакета. Основанная на UDP версия DNS по TLS под названием DNS over Datagram Transport Layer Security (DTLS) сейчас в экспериментальной разработке — она может увеличить производительность протокола.

Здесь тоже имеется проблема с управлением сертификатами. Если провайдер удалит сертификат и начнёт использовать новый, то в настоящее время нет чистого способа обновления данных SPKI на клиентах, кроме вырезания старого и вставки нового сертификата в файл конфигурации. Прежде чем с этим разберутся, было бы полезно использовать какую-то схему управления ключами. И поскольку сервис работает на редком порту 853, то с высокой вероятностью DNS по TLS могут заблокировать на файрволе.

Но это не проблема для лидера нашего хит-парада — DNS по HTTPS. Он проходит через большинство файрволов, словно тех не существует.

Заключение

В этой части мы разобрались с основными опциями файрвола. Обратите внимание, что условия выбора пакетов одинаковы для всего файрвола и будут нам требоваться в дальнейшем при изучении NAT и расширенной обработки трафика (Mangle). А вот названия цепочек и действия там будут совершенно другими.

Технический директор Илья Князев