Connection state в MikroTik назначается пакету относительно записи connection tracking. Firewall различает new, established, related, invalid и untracked и использует эти состояния для ранней обработки трафика.
Правило drop invalid обычно полезно, но при асимметричной маршрутизации корректные пакеты могут выглядеть invalid. Перед применением проверьте обратный путь и особенности вашей топологии.
new — инициирующий пакет нового соединения
established — пакет, принадлежащий уже установленному соединению
related — пакет, связанный с существующим соединением, но инициирующий новое
invalid — пакет, который не удалось корректно классифицировать
UNTRACKED: когда пакет не попадает в таблицу соединений
Состояние untracked присваивается пакетам, которые не проходят через connection tracker. Это происходит в двух случаях:
Connection tracking отключен глобально – тогда все пакеты помечаются как untracked.
В цепочке raw фаервола применено правило action=notrack, которое явно исключает определённый трафик из отслеживания.
Важно: пакеты в состоянии untrackedне подвергаются NAT и не могут фильтроваться по параметрам, зависящим от соединения (connection-*). Однако все остальные правила фаервола к ним применяются.
Использование notrack — это распространённый метод оптимизации производительности MikroTik, особенно в сетях с высокой нагрузкой (например, при передаче большого объема backup-трафика или трафика между доверенными зонами). Это снижает загрузку CPU, поскольку connection tracking — ресурсоёмкая операция.
ESTABLISHED: пакеты уже установленных соединений
Состояние established присваивается пакетам, входящим в уже существующее соединение. Для TCP/UDP соединения проверяются пять параметров («пять кортежей»):
IP-адрес источника и назначения
Порты источника и назначения
Протокол
Для других протоколов (например, ICMP или GRE) проверяются только три параметра: два IP-адреса и тип протокола.
Рекомендация: правило с connection-state=establishedстоит размещать в начале цепочек, чтобы ускорить обработку и снизить нагрузку на роутер. В большинстве случаев такой трафик безопасен и должен быть разрешён.
NEW: начало нового соединения
Пакет с состоянием new — это первый пакет в новом соединении, на основании которого connection tracker создаёт запись в таблице.
Особенности по протоколам:
TCP: пакет считается new, только если он содержит флаг SYN и не содержит других флагов (например, ACK). Именно такой пакет инициирует TCP-сессию.
ICMP: new — это всегда Echo Request (Type=8, Code=0). Ответ (Echo Reply) будет established.
GRE: используется, например, в PPTP-туннелях. Connection tracker сопоставляет GRE-пакеты по Call ID, ассоциируя их с управляющим TCP-соединением PPTP.
Пример практического применения: Разрешить инициацию соединений только из VLAN 100 (управляющая сеть) в VLAN 200 (серверная), но не наоборот:
Такой подход — основа асимметричной сетевой безопасности, часто используемой на курсах по MikroTik.
INVALID: когда пакет «не вписывается» в логику соединений
Состояние invalid присваивается пакетам, которые:
Приходят без предшествующего new, но выглядят как часть соединения (например, TCP-пакет с флагом ACK, при этом самого соединения нет в таблице).
Не могут быть обработаны из-за переполнения таблицы соединений (например, нехватка памяти в RouterOS).
Являются артефактами асимметричной маршрутизации (например, в BGP-сетях).
Обычно такие пакеты следует блокировать. Однако в редких случаях (например, устаревшие приложения вроде IIS + 1С) может потребоваться разрешить invalid-трафик для корректного завершения соединений.
RELATED: «дочерние» соединения
Состояние related — одно из самых сложных для понимания. Оно применяется, когда пакет связан с существующим соединением, но формально является началом нового.
Примеры:
ICMP-ошибки (например, «Destination Unreachable»): внутри ICMP-пакета содержится заголовок оригинального IP-пакета. Connection tracker распознаёт, к какому соединению он относится, и помечает ICMP как related.
Протоколы с динамическими портами: некоторые протоколы устанавливают управляющее соединение, а затем инициируют дополнительные сессии на других портах. Чтобы фаервол мог корректно отслеживать такие «вторичные» соединения, используются специальные модули, известные как NAT helpers или ALG (Application Layer Gateway). В MikroTik RouterOS эти функции реализованы через раздел /ip/firewall/service-port. Каждая запись в этом разделе (например, name="ftp", name="sip" и т.д.) активирует встроенный conntrack-модуль, который анализирует управляющий трафик и помогает ядру отслеживать связанные потоки данных, помечая их как related. Например, FTP в активном режиме: клиент подключается к порту 21, а сервер инициирует отдельное TCP-соединение к клиенту на динамический порт данных. Запись name="ftp" в /ip/firewall/service-port включает соответствующий NAT helper, и RouterOS заранее знает о таком соединении, помечая его как related. Аналогично работают и другие встроенные помощники — для TFTP (порт 69), SIP (порты 5060/5061), H.323, PPTP, UDPlite, DCCP, SCTP, а также (в некоторых версиях) IRC и RTSP. Все они реализованы как ALG-модули и управляются именно через /ip/firewall/service-port.
Поэтому правило connection-state=relatedрекомендуется размещать сразу после или вместе с established, иначе такие пакеты будут отброшены фаерволом.
Список NAT helpers (conntrack ALG-модулей) из MikroTik RouterOS и соответствующие файлы исходного кода в официальном репозитории ядра Linux (kernel.org):
Понимание состояний соединений — ключевой навык для эффективной настройки MikroTik. Это позволяет строить безопасные, производительные и гибкие сетевые политики. Особенно важно это для тех, кто проходит курсы по MikroTik или самостоятельно осваивает продвинутую настройку сетевого оборудования.
Заключение
Изучение работы connection-state помогает не только правильно фильтровать трафик, но и оптимизировать производительность роутера, избегать ошибок NAT и устранять сложные сетевые проблемы.
Если вы хотите освоить такие темы на практике — присоединяйтесь к курсам по MikroTik, где разбираются не только базовые, но и продвинутые сценарии настройки, включая безопасность, производительность и отказоустойчивость сетей.
Как проверить результат
Откройте одно TCP-соединение и найдите его в connection table.
Сверьте счётчики established/related и invalid rules.
Проверьте поведение при асимметричном пути или временно исключите такой трафик из теста.
Команды в статье меняют сетевую конфигурацию. Перед работой сохраните экспорт, подготовьте способ восстановления доступа и применяйте изменения сначала в тестовой среде.
Firewall MikroTik во второй части дополняет базовую схему правилами для локального трафика, FastTrack и RAW. Эти механизмы влияют на connection tracking, очереди, IPsec и диагностику.
Не включайте FastTrack без проверки исключений: обработанный им трафик может обходить firewall, mangle, Simple Queue и IPsec. Изменения RAW применяйте только после понимания, какой трафик исключается из conntrack.
MikroTik Firewall Filter
В первой части у нас получилась примерно следующая конфигурация.
Главной особенностью нашего фаервола заключается в том, что вам нет необходимости помнить в каком порядке расставлять правила для открытия нужных портов на маршрутизаторе, вы всегда работает ТОЛЬКО с одной цепочкой ISP-Input-Allow.
Теперь настала часть обсудить как мы будем настраивать фаервол для остального трафика, а его может быть много и с разных сторон прилетать.
Interface List
Создадим отдельный лист, где перечислим все наши локальные интерфейсы, в которых находятся наши пользователи, только не стоит добавлять все интерфейсы, а только те, где действительно есть и ходит трафик. В моём случае это 5 интерфейсов ether5.2ether5.3ether5.4ether5.5, ether5.6 я таким образом именую vlan интерфейсы, но в вашем случае могут быть разные bridge-ы и просто интерфейсы.
/interface list add name=Local
/interface list member
add list=Local interface=ether5.2
add list=Local interface=ether5.3
add list=Local interface=ether5.4
add list=Local interface=ether5.5
add list=Local interface=ether5.6
Ещё раз, не стоит добавлять все интерфейсы, даже которые гипотетически вы будете использовать в будущем для внутренних сетей, добавляйте всегда по мере необходимости.
Отлично теперь у нас есть лист с которым мы будем работать.
Firewall Filter
И так начнём с простого, займёмся безопасностью.
Firewall Filter Local input
Начнём мы с банального, это перенаправим весь входящий трафик в листе Local в кастомную цепочку! Поместим это правило в самый верх.
А вы не заметили, что мы начали создавать по сути одинаковые правила, для разных интерфейсов, мне кажется или это “перебор”?! А вам?
Мне лично не кажется это перебором, всё зависит от ситуации, но в большинстве случаев я лучше сделаю больше правил и всегда будут знать, какой трафик проходит по каким цепочкам.
Настройка MikroTik
Закажи настройку MikroTik непосредственно сейчас, поможем в поиске решения по любому кейсу связанному с MikroTik.
Предоставляю гарантию две недели на свою работу, оплата постфактум, работаю как с юридическими, так и физическими лицами.
Собственно на данном этапе мы разрешили пакеты, которые связаны с уже установленными соединениями и пакеты которые идут мимо connection-tracker, untracked, с ними мы разберёмся позже.
Так как мы настраиваем цепочку input мы работаем с пакетами которые идут непосредственно на сам маршрутизатор.
Далее необходимо понимать, что я не могу описать все возможные сценарии и решить именно ваш кейс, но смысл примерно следующий.
У нас будет цепочка куда перенаправим все оставшиеся пакеты, а как вы наверное помните из первой части это только new пакеты, так как только они остались терминирующему принципу. В такой цепочке мы разрешим пакеты которые необходимо разрешать для всех интерфейсов локальной сети.
В имени цепочки мы явно, указали, то что это весь трафик для локальных интерфейсов. А теперь рассмотрим когда и какой трафик необходимо разрешать.
По-хорошему разрешать пинговать маршрутизатор надо, как минимум будет работать traceroute да и некоторые приложения любят долбить маршрутизатор, тем самым проверять наличия связи с ним.
add chain=Local-Input-All protocol=icmp
Если ваш маршрутизатор выступает в роли dns сервера для всех сетей, то почему бы и не разрешить его.
Вопрос управления и доступа к самуму маршрутизатору, всегда стоит остро.
Нам необходимо более выборочно поступить к настройкам фаервол, допустим нам надо разрешить управление Mikrotik для его дальнейшей настройки только с интерфейса ether5.3 это наш некий management.
А теперь нам надо заблокировать весь оставшийся трафик, но уже не в цепочке Local-Input-All, а в Local-Input. Так когда трафик закончится обрабатываться в цепочке Local-Input-All он вернётся в цепочку Local-Input.
add chain=Local-Input action=drop
Всё, теперь у нас есть конфигурация, которая разрешает с любого локального интерфейса доступ к dns и icmp, а также с интерфейса ether5.3 соединение непосредственно с ssh и winbox.
И если вам надо, что-то разрешить, то вы работаете только с цепочкой Local-Input-All, всё что не будет явно разрешено, будет запрещено.
Firewall Filter Local Forward
А теперь поговорим непосредственно про проходящий трафик, а именно трафик из локальных сетей. Ещё раз напомню что у нас пять интерфейсов vlan ether5.2, ether5.3, ether5.4, ether5.5 и ether5.6.
ether5.2 — сеть, где находятся компьютеры пользователей.
ether5.3 — management vlan, сеть где находятся различные управляющие IP интерфейсы оборудования принадлежащий сетевой инфраструктуре.
ether5.4 — VoIP здесь находятся телефонные аппараты.
ether5.5 — серверная сеть, сюда входят все сервера, в том числе сервер телефонии PBX, файловая помойка и etc…
ether5.6 — гостевой wifi.
Прежде чем начать нам необходимо выбрать концепцию либо стиль, каким образом будет строиться общий подход к формированию правил и на какой параметр мы будем ориентироваться в первую очередь. Очень часто я вижу предложения “делать как получится”, что в дальнейшем приводит к раздуванию объема правил в фаервола и дальнейшим неудобством его контроля.
Конечно всё зависит от задачи и поставленного ТЗ, но так как мы с вами работаем без ТЗ =), то делать будет по-простому, а именно ориентироваться в наших правилах, на пакет которые пришёл с определённого интерфейса.
Как видите мы для каждого логического IP интерфейса создали правило которое смотрит в свою собственную цепочку.
Создадим последним правилом драпающим все пакеты
add chain=forward action=drop
Теперь у нас фаервол имеет концепцию Нормально закрытый фаервол, всё что не разрешено то запрещено и надо будет помнить так как при добавлении VPN-ов или новых интерфейсов у вас будет всё с них запрещено.
Также необходимо добавить ещё два правила, ПЕРЕД нашими forward, а именно:
Эти правила необходимы для того, чтобы уменьшить количество трафика (pps) на правила в кастомных цепочках, ну и также облегчить удобство настройки. Эти правила должны быть всегда перед правилами forward/jump
У нас нормально закрытый фаервол, это значит запрещено всё, что не разрешено, отсюда следует, что мы разрешили только трафик из гостевого wifi который уходит в интерфейс провайдера, т.е… в интернет. Всё на этом настройка цепочки закачена, всё остальное будет запрещено.
Продолжим с цепочкой VoIP
Предположим, что у нас настроен provision для телефонов, а также у нас есть несколько важныхнужный серверов.
Обратите внимание на TFTP и SIP, нам не надо разрешать related порты, например такие, как RTP 10000-20000 (в большинстве случаев), так как NAT хелперы мы не отключали. Привет, всем (у кого горит) любителям хелперов =))), а если серьёзно, то вы должны выбрать для себя, то как будет строиться ваш подход, либо вы отключаете хелпер и настраиваете “всё и вся” либо вы возлагаете часть работы на хелпер, решать только вам, оба кейса “имеет место быть”.
Это конечно не входит в данную статью, но помните один важный нюанс, потеря данных аутентификации к SIP серверу может привести к прямым потерям, в виде счёта от вашего провайдера, отсюда надо помнить такую вещь! Не пренебрегайте настройками безопасностей в локальной сети, как показывает практика чаще всего из локальной сети разрешено всё! Установите на вашу PBX системы как минимум fail2ban и естественно не забудьте его настроить.
management vlan
Сеть в которой находить различное оборудование, необходимо минимум настроек
Обратите внимание, в большинстве случаев трафика в интернет будет больше, поэтому правило разрешающее выход в интернет первое по порядку.
Так же мы разрешаем во всех направлениях БЕЗ ограничения трафик с некого листа PCadmins в котором вы перечислите IP адреса или доменные имена компьютеров администраторов, с них разрешён любой трафик. В идеале конечно, выделить отдельную сеть под такие задачи, но что имеем то и имеем.
Серверная сеть
Конечно здесь всё индивидуально и под конкретную задачу. Я попробую сделать собирательный образ
Команды в статье меняют сетевую конфигурацию. Перед работой сохраните экспорт, подготовьте способ восстановления доступа и применяйте изменения сначала в тестовой среде.
Настройка Firewall MikroTik начинается с модели трафика: какие интерфейсы относятся к интернету, кто управляет маршрутизатором и какие входящие соединения разрешены. Статья строит отдельные цепочки для input и forward.
Команда очистки filter rules может немедленно изменить защиту и доступ. Выполняйте работу в Safe Mode или через резервный канал, добавьте разрешение управления до финального drop и подготовьте восстановление.
MikroTik Firewall Filter
Хочу признаться мне не очень нравиться дефолтный конфиг Firewall, но я прекрасно понимаю, что тем кто его придумал, была задача найти условно общую конфигурацию которая бы подходила к большинству и покрывала решение зада большинства, но мы не большинство, и будем “лепить” свой конфиг.
Естественно чистим конфигурацию или просто очищаем полностью Filter Firewall-а.
/ip firewall filter remove [find]
В первую очередь мы должны защитить наш маршрутизатор от условных проблем, атак или злоумышленников из сети интернет.
Interface List ISP
В моём случае для примера у меня три провайдера ether1, ether2, ether3 и поверх ether3 запущен PPPoE туннель для получения доступа к интернету.
Создадим лист интерфейсов в котором перечисляем все интерфейсы подключенные к сетям провайдеров. Причём неважно один или два или десять у вас таковых интерфейсов.
/interface list add name=ISP
Как вы его назовёте, не имеет значения, главное чтобы вам был понятен смысл имени и наверное очень важно, то чтобы было понятно любому другому человеку который взглянет на ваши настройки. Ведь согласитесь если вы его назовёте “Bla-bla-bla” смысл для любого человека будет непонятен, хотя возможно для вас он и будет иметь сакральный смысл.
Я предпочитаю называть данный лист ISP, что обозначает Internet Service Provider.
Соответственно добавляем в данный лист все интерфейсы провайдеров.
/interface list member
add list=ISP interface=ether1
add list=ISP interface=ether2
add list=ISP interface=ether3
add list=ISP interface=ether3.PPPoE
Обратите вниманию я добавил ether3 и PPPoE интерфейс которые поднят через него же. По поводу наименование PPPoE туннеля не удивляйтесь у меня есть привычка использовать в наименовании интерфейсов точку в случае если данные интерфейс является sub интерфейсом другого интерфейса. К примеру если у меня будет vlan 100 на первом интерфейсе его имя будет ether1.100.
Настройка MikroTik
Закажи настройку MikroTik непосредственно сейчас, поможем в поиске решения по любому кейсу связанному с MikroTik.
Предоставляю гарантию две недели на свою работу, оплата постфактум, работаю как с юридическими, так и физическими лицами.
На данный момент мы закончили с настройкой листа ISP и может приступить непосредственно к настройке Firewall.
Firewall Filter
Начнём непосредственно настраивать наш filter.
Firewall Filter Input
Первым делом мы будем настраивать трафик, который пришёл на маршрутизатор, и является потенциально опасным для маршрутизатора.
Все дальнейшие правила мы делаем в разделе фильтра, я не буду указывать в приведённых примерах.
/ip firewall filter
Самым первым правилом отправляем весь трафик с интерфейсов провайдеров в кастомную цепочку (custom chain) с помощью jump.
Обратите внимание, что я не указываю ни интерфейсы, ни список интерфейсов, нам нет необходимости этого делать, так как самое первое правило отправило в данную цепочку только трафик которые приходит с интерфейсов провайдеров перечисленных в листе ISP.
Следующее правило разрешаем related, это пакеты, которые создали вторичное соединение, такие пакеты помечаются когда на основании какого либо payload создаются новые соединения, например если вы используете NAT-helper ftp или SIP. Также related в некоторых случаях это ICMP ответ маршрутизатора.
Мы часто используем возможность снижение нагрузки на connection-tracker с помощью исключения пакетов с помощью raw untracked, также используется для обхода NAT в случае когда необходимо исключить процедуру изменения заголовка пакета.
Кто-то из вас скажет, “Стоп-стоп, но ведь мы можем все эти три последние правила описать одним, просто перечислив состояния через запятую!!! Зачем создавать три правила?!” Да можем, но моя задача, во-первых, показать вам все правила наглядно, а во вторых у нас появляется возможность видеть количество трафика и нагрузку pps по каждому конкретному типу пакетов, и в случае необходимости изменить порядок для оптимизации.
Настала пора создать наше первое запрещающее правило, мы должны запретить пакеты с состоянием invalid, таким состоянием помечаются пакеты в нескольких случаях:
Если на вашем маршрутизаторе закончится память и connection-tracker не сможет создать запись для соединения, но это редкий случай.
Если пакет принадлежит к одному из протоколов GRE, ICMP или TCP, то RouterOS умеет понимать по-содержимому пакетов данные протоколов должен являться данный пакет частью существующего соединения или нет. Если по признакам он является частью соединения, но соединения нет в connection-tracker, то такой пакет помечается как invalid. Пример на маршрутизатор пришёл один пакет TCP с флагами syn и ack, т.е. Какой-то хост “по идеи” ответил на посылку syn пакета, но если соединения нет, то нам такой пакет не нужен. Также это простая защита от TCP RST Flood.
Как вы наверное знаете в RouterOS с включенным connection-tracker существует пять состояний пакетов, четыре из которых мы описали, а так как правила в firewall терминирующие, т.е после срабатывания правила пакет прекращает обработку в filter. У нас остаётся всего один тип пакетов это new это те самые пакеты которые создают соединения, другими словами когда кто-то инициализирует соединение к маршрутизатору такой пакет имеет состояние new. Но так как мы описали четыре состояния, нет смысла указывать состояние, так как подразумевается по остаточному принципу, что в следующем правиле и так будут только new.
Мне часто приходится настраивать RouterOS под проекты, и зачастую я подготавливаю оборудование так, чтобы с ним было комфортно работать заказчику, так как со временем у заказчика могут появиться дополнительные кейсы, и чтобы было однотипность в настройках мы поступаем следующим образом.
Выносим все разрешающие правила в отдельную цепочку например с именем ISP-Input-Allow. В таком случае нет необходимости думать в каком месте по порядку разместить правила, чтобы они были правильно расположены относительно всех других правил.
Следующим правилом мы запрещаем все остальные пакеты, которые дошли до следующего правила. Будьте аккуратны, возможно если вы подключены через провайдера к маршрутизатору, вы не сможете подключиться к маршрутизатору в случае разрыва соединения.
add chain=ISP-Input action=drop
Ну вот пожалуй с каркасом закончили, теперь нам необходимо разрешить какой-то трафик на сам маршрутизатор.
Для закрепления результата представим, что у нас поднят на RouterOS l2tp сервер и мы хотим иметь возможность подключаться по ssh, а также маршрутизатор должен отвечать на запросы icmp.
Мы будем использовать кастомную цепочку ISP-Input-Allow и порядок правил в нём не важен, а также неважно расположение правил в этой цепочке относительно всех других правил, хоть в разнобой, хоть в конце, хоть в начале. Это не принципиально. Наверное всё-таки для удобства желательно расположить их по порядку и в одном месте. Но это только для тех кто использует winbox для настроек, а для тех кто используется CLI или как-то оркестратор типа ansible, как раз проявляется удобство в том, что вам не надо думать о прядке правил.
Если пакет которых поступает в данную цепочку дойдёт до конца её, то он перейдёт на следующее правило после которого он попал в данную цепочку.
Вот таким образом у вас должен выглядеть filter в winbox.
Я отформатировал вывод убрав отображение некоторых столбцов.
А теперь давайте посмотрим как будут работать данные правила, при поступлении рафика в цепочку INPUT.
Первый пример HOST 5.5.5.5 хочет установить соединение с SSH MikroTik с адресом 2.2.2.2.
Хост 5.5.5.5 отправляет syn пакет для установления соединения с ssh сервером на MikroTik
Такой пакет первым же правилом попадает под jump и отправляется к custom chain ISP-Input
Далее маршрутизатор находит все правила в кастомной цепочке ISP-Input перебирать соответствию пакета для правила
В первых 4 правилах в цепочке ISP-Input он не найдёт соответствия, а вот в пятом правиле сделает jump на ещё одну цепочку. Соответственно выберет все правила из новой цепочке ISP-Input-Allow
И будет снова сверять по порядку, соответствия пакета правилу.
Как только найдено терминирующее правило, а в нашем случае это accept, маршрутизатор заканчивает обработку данного пакета в filter firewall и отправляет пакет в Local Process.
SSH сервер ответит пакетом TCP c флагами syn,ack после получения такого пакета клиент отправит пакет с флагом ACK и такой пакет уже будет обрабатываться как established.
Но первым же правилом в цепочке ISP-input у нас есть разрешающее терминирующее правило для пакетов с состоянием established. Такой пакет сразу отправиться в Local Process.
А теперь давайте попробуем разобраться, что будет если хост отправит пакет на порт Winbox TCP 8291, который мы явно не запрещали.
Начало будет одинаковое
Когда пакет будет проверяться соответствиям правилам в цепочке ISP-Input-Allow, для него не найдётся, не одного подходящего правила.
В этом случае произойдёт автоматически return, и обработка выйдет из цепочки ISP-Input-Allow и продолжит обрабатываться в цепочке ISP-Input а у нас есть правило, которое отбрасывает все пакеты DROP всё, такой пакет не когда, не попадёт в Local Process.
Т.е если в custom chain не найдено соответствие, не с одним правилом, то обработка такого пакета возвращается и продолжает обработку по порядку со следующего правила места входа.
Для удобства восприятия поставил слева номера, чтобы был понятен порядок обработки
И ещё раз порядок правил имеет значения только для каждой отдельной цепочки, а не относительно всех цепочек.
Firewall Filter Input Brute-force
В данном разделе мы рассмотрим настройку защиты от перебора паролей по протоколу SSH в сетях с использованием RouterOS.
Изменение порта SSH
Практика показывает, что даже самое простое изменение порта SSH-сервера может сделать вас менее уязвимыми перед большинством сканеров, хотя, конечно, не перед всеми. В локальной сети за маршрутизатором мы можем оставить стандартный порт 22, а с внешней стороны сети изменить его, например, на порт 1024 с использованием простого перенаправления (redirect).
Эти правила позволяют блокировать адреса, с которых выполняются подозрительные попытки входа, а также ввести тайм-ауты для автоматического разблокирования адресов после определенного времени.
Такая конфигурация поможет усилить безопасность вашего SSH-сервера и снизить риск успешных атак перебора паролей.
На этом этапе мы закончили работу с трафиком Input и переходим к Forward.
Firewall Filter Forward
Естественно нам необходимо защитить трафик, который проходит со стороны провайдеров через маршрутизатор.
Многие наверное скажут, а зачем его защищать, ведь трафик нельзя отправить через маршрутизатор, для этого необходимо адрес маршрутизатора прописать как шлюз, что в свою очередь говорит о том, что маршрутизатор должен находится в Connected сети.
Вот вам маленькая история.
Мне провайдер выдаёт внутренней адрес из сети /22 и со всеми соседями я нахожусь в одном Broadcast домене. Получилось так, что пропустил платёж и мне провайдер на шлюзе зарезал интернет, но он не отключил порт на коммутаторе, и мне всё также была доступна внутренняя сеть. Запустил LLDP на интерфейсе провайдера и увидел что со мной в одной сети находятся как минимум пять маршрутизаторов MikroTik. И логика была у меня такая:
По умолчания в RouterOS на первом порту отключен LLDP, а если я вижу это значит что-либо конфигурации была сброшена либо используется порт не ether1. Соответственно возможно, что на нём неправильно настроен firewall.
Так и получилось я на своём маршрутизаторе прописал адрес MikroTik первого из списка и у меня появился интернет, да с другого IP адреса, но этого достаточно. Сразу скажу, что на всех пяти MikroTik-ах которые я видел, и кстати до сих пор я наблюдаю в сети данные MikroTik c таким образом настроенным Firewall, что я в любой момент могу получить доступ в интернет через них.
Вот именно от таких ситуаций нам необходимо защититься.
И опять же мы будем использовать custom цепочку.
Первым правилом мы отправляем весь проходящий forward трафик с интерфейсов провайдеров в цепочку ISP-Forward.
Единственно, что необходимо уточнить, это то что в случае если вы используете BGP или асинхронную маршрутизацию. То вам необходимо разрешать трафик invalid. Но в большинстве случаев это не так.
Далее вы помните, что по типу исключения у нас остаётся только пакеты, которые имеют состояние new, и если подумать то такие пакеты могут проходить через маршрутизатор со стороны провайдера только если они попадают под процедуру изменения адреса назначения.
Поэтому нам необходимо разрешить пакеты new которые попадают под dst NAT.
И последний правилом мы закрываем доступ из вне всем отвальным пакетам.
add chain=ISP-Forward action=drop
Собственно всё.
Давайте взглянем на наши правила.
Соответственно, если вам необходимо разрешить подключаться к маршрутизатору, будь то по VPN или ещё как-то, вы всегда можете добавить правило в цепочку ISP-Input-Allow и не думать о порядке правил.
Обновление от 25.03.2024
Как оказалось, множество пользователей, которые используют данный подход при конфигурировании фаервола, да и я сам для себя выработал как стандарт в настройке фаервола.
Иногда не хватает несколько правил, которые мне приходится часто добавлять в конфиг вручную.
ipsec
Мне часто приходится настраивать ipsec, поэтому приходится подтягивать настройки фаервола под него.
Начнем с НАТ-а исключим весь будущий и текущий трафик из обработки NAT-ом, данные правила должны находиться перед всеми правилами изменения заголовка. Эти правила необходимы для того, чтобы трафик, который попадает под ipsec, был исключен из обработки NAT-ом.
Я пересмотрел подход с Brute и решил добавить туда же winbox, а это значит, что необходимо переименовать цепочку из SSH-Brute-force в Brute-force и создать правило для winbox.
Так же необходимо уменьшить время нахождения в промежуточных листах, так как 1 минута это очень большой временной промежуток. Сократим его в два раза, до 30 секунд.
Итог (С учетом обновления 25.03.2024)
Я приведу итоговый результат немного отформатированный.
Команды в статье меняют сетевую конфигурацию. Перед работой сохраните экспорт, подготовьте способ восстановления доступа и применяйте изменения сначала в тестовой среде.
