Drop в роутере что это такое

Содержание

  1. Action “drop”
  2. Action “fasttrack connection”
  3. Action “Jump”
  4. Action “passtrough”
  5. Action “Reject”
  6. Использование “reject” для ограничения доступа к ресурсам
  7. Action “return”
  8. Action “tarpit”

Продолжаем говорить про Action в Mikrotik ip firewall filter

01. Action “drop”

/ip firewall filter add action=drop

Следующее действие — это действие, связанное с «откидыванием пакета» (drop).

IP/Firewall/New Firewall Rule/Action/drop

Делаем правило Input, протокол icmp, action – drop.

Это правило будет запрещать любые пакеты icmp, которые будут идти на наш роутер.

IP/Firewall/Firewall Rules

Action drop не сообщает почему произошла блокировка, оно просто уничтожает входящие (в данном случае) пакеты.

Terminal/ping 192.168.88.1

Если мы делаем безусловное правило, без указания протокола, то мы запретим любой доступ на наш роутер микротик. Например, я сейчас сделал input без условия и в данном случае я не смогу получить доступ к роутеру используя ip адрес.

IP/Firewall/Firewall Rules/Firewall Rule

Пытаемся подключиться к роутеру и как мы видим, используя айпи адрес, мы не можем получить доступ к роутеру. С чем это связано? Это связано с тем, что мы полностью запретили доступ к роутеру Mikrotik со всех интерфейсов и по всем протоколам.

WinBox/Advanced Mode

Firewall работает на третьем уровне и не работает на втором уровне, поэтому используя mac адрес мы можем управлять нашим роутером.

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

02. Action “fasttrack connection”

Fasttrack connection позволяет использовать ресурсы нашего роутера более производительно.

IP/Firewall/Firewall Rules/File Rule

Эта оптимизация производительности, часто применяемая для домашних пользователей. Корпоративным пользователям эта опция, как правило, вредит и мешает.

О fasttrack мы поговорим позже.

3. Action “Jump”

/ip firewall filter add action=jump

Опция Jump позволяет создавать отдельные цепочки, об отдельных цепочках мы поговорим в отдельном видео. В данном случае я продемонстрирую механику создания отдельной цепочки.
Input – ICMP мы можем сделать jump – ICMP

IP/Firewall/Firewall Rules

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

IP/Firewall/Firewall Rules/New Firewall Rule/General

4. Action “passtrough”

/ip firewall filter add action=passtrough

IP/Firewall/Firewall Rules/Firewall Rule/Action

Действия очень похоже на action – log. Разница лишь в том, что у нас не записывается ничего в лог, но при этом работает счётчик пакетов. Это правило удобно использовать в ситуации, когда нам необходимо найти какое-то правило среди огромного их количества.

Например, нам попался фаерволл с 300 правилами и среди этого количества нам надо найти правило, которые разрешает или запрещает доступ. Что мы делаем? Мы создаём action – passtrough (для icmp в нашем случае) и начинаем его передвигать сверху вниз, пока не начнёт отрабатывать наш счётчик, так же passtrough используется для того, чтобы посчитать те или иные пакеты.

5. Action “Reject”

Reject это правило, которое дропает пакеты и в ответ источнику данных пакетов отправляет icmp сообщение, почему же пакет был дропнут.
Например, reject – мы отвечаем icmp network unreachable.

IP/Firewall/Firewall Rules/Firewall Rule/Action

Проверяем – Destination Net Unreachable.

Terminal/ping 192.168.88.1

Мы можем поменять пакет и написать, что заблокировано администратором (admin prohibited), как мы видим сообщение поменялось.

Terminal/Request Timeout

Так же можем ответить, хост заблокирован, сеть заблокирована и т. д.

IP/Firewall/Firewall Rules/Firewall Rule/Action

Эти все действия полезны для блокировки ресурсов в локальной сети и в дальнейшем полезно для диагностики того, что мы заблокировали. Т. е. если у нас происходит ситуация, что мы запретили с гостевой сети доступ в локальную сеть и написали просто network unreachable, это достаточно плохо диагностируется. Но если мы написали «админ запретил доступ», то тогда мы сразу видим, что у нас есть какой-то определённый пакет и это говорит нам, что не сеть не доступна, а роутер микротик говорит нам, что туда идти нельзя.

6. Использование “reject” для ограничения доступа к ресурсам.

/ip firewall filter add action=reject

Reject часто используется для блокировки доступа к тем или иным ресурсам. Например, если мы заблокировали доступ к нашему роутеру по telnet, по умолчанию телнет использует tcp 23й порт, то мы можем сбрасывать tcp соединение. Порт 23 reject tcp reset.

IP/Firewall/Firewall Rules/Firewall Rule/General

IP/Firewall/Firewall Rules/Firewall Rule/Action

Tcp reset отправляет tcp rst пакет в ответ на tcp.
Проверяем telnet 192.168.88.1

Connection refused

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

В случае с reject соединение сбрасывается очень быстро.

Reject используется для блокировки ресурсов в рамках управляемой сети. Сообщать злоумышленнику, почему мы запретили доступ к нашему роутеру Mikrotik, не требуется, потому что он проигнорирует это сообщение. Для защиты роутеры с внешних сетей достаточно drop. С точки зрения запрета пользователям использование какого-либо ресурса удобно уведомлять их приложения, почему мы заблокировали доступ отправкой tcp rst пакета.

7. Action “return”

Return позволяет вернуться из пользовательской цепочки в исходную. О цепочках мы поговорим в другом видео.

IP/Firewall/Firewall Rules/Firewall Rule/Action

08. Action “tarpit”

/ip firewall filter add action=tarpit

Tarpit – мы отвечаем на tcp syn пакеты tcp aac пакетами с нулевым окном. Разрешаем соединение на tcp порт, поэтому tarpit работает только с tcp, но при этом никакого соединения не происходит.
Tarpit может понадобиться в случае, если какой-нибудь злоумышленник открывает наш сайт и в этом сайте открывает 300 страниц в секунду. Сайту становится очень плохо.
Наши действия: вычисляем адрес злоумышленника. Заблокировать злоумышленника, чтобы он не пытался подключиться к нашему сайту. Но после того, как мы производим блокировку, он меняет адрес, с которого стучался к нам. Отправляем адрес злоумышленника в tarpit и соединение виснет на разрешенном соединении.

Подключаемся:
Terminal/Telnet 192.168.88.1

Идёт подключение, но ничего не происходит.
В случае с tarpit мы попадаем куда-то, но не получаем никаких данных.
Tarpit довольно производительное правило.

На этом осмотр ip-firewall-filter rules action закончен.

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

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

Reject, в свою очередь, отправляет уведомление отправителю, что пакет был отклонен. Результатом этого является отправка ICMP «Destination Unreachable» сообщения обратно отправителю. Такой подход полезен, например, для отслеживания потенциальных атак и логирования действий злоумышленников.

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

Содержание

  1. Преимущества и недостатки функционала в Mikrotik
  2. Различия между drop и reject в Mikrotik
  3. Как выбрать между drop и reject в Mikrotik
  4. Плюсы и минусы функции drop в Mikrotik
  5. Плюсы и минусы функции reject в Mikrotik
  6. Плюсы:
  7. Минусы:
  8. Когда использовать drop в Mikrotik
  9. Когда использовать reject в Mikrotik

Преимущества и недостатки функционала в Mikrotik

Преимущества:

  • Гибкий функционал: Одним из крупнейших преимуществ Mikrotik является его гибкость и масштабируемость. Он предлагает множество функций и настроек для оптимизации работы сети и обеспечения безопасности, таких как маршрутизация, межсетевой экран (firewall), балансировка нагрузки, VPN, кэширование и т. д.
  • Низкая стоимость: Mikrotik предлагает многофункциональное программное обеспечение и аппаратное обеспечение по относительно низкой цене. Это делает его более доступным для небольших и средних предприятий, которым требуются высокопроизводительные сетевые решения.
  • Большое сообщество: Mikrotik имеет большое сообщество пользователей, которые активно обмениваются знаниями и опытом. Это делает поиск решений и получение поддержки от других пользователей гораздо проще.
  • Быстрая интеграция: Mikrotik легко интегрируется с другими компонентами сети (коммутаторами, маршрутизаторами и т. д.) и операционными системами, что позволяет быстро развернуть сеть и настроить ее в соответствии с требованиями.
  • Обновления и поддержка: Компания Mikrotik регулярно выпускает обновления программного обеспечения, которые вносят улучшения и исправления ошибок. Благодаря этому, пользователи могут быть уверены в том, что их сети работают на последних версиях и обеспечены надежной поддержкой.

Недостатки:

  • Сложность настройки: Поскольку Mikrotik предоставляет широкий функционал, его настройка может быть сложной для новичков без должного опыта. Некоторые функции требуют знаний сетевых протоколов и администрирования, чтобы быть использованы должным образом.
  • Отсутствие пользовательского интерфейса с графическим интерфейсом: Mikrotik использует командную строку или web-интерфейс для управления и настройки. Для пользователей, привыкших к графическим интерфейсам, это может представлять некоторые сложности.
  • Ограниченная поддержка сторонних приложений: Некоторые пользователи могут столкнуться с ограничениями в доступе к сторонним приложениям или функциям, поскольку Mikrotik не всегда полностью совместим со всем программным обеспечением и оборудованием на рынке.
  • Необходимость в знании сетевых протоколов: Чтобы использовать Mikrotik на полную мощность, необходимо быть знакомым с основами работы сетевых протоколов и технологий. Для новичков это может потребовать дополнительного обучения и времени для изучения.

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

Различия между drop и reject в Mikrotik

В Mikrotik есть две основные команды для блокировки пакетов: drop и reject. Обе команды позволяют отклонять пакеты, но существуют некоторые различия между ними.

  • Команда drop просто удаляет пакет, не отсылая никакого уведомления отправителю о блокировке. При использовании этой команды, отправитель не будет знать, что его пакет был отклонен. Это может привести к некоторым проблемам, например, если отправитель ожидает подтверждение о доставке пакета и не получает его.
  • Команда reject также отклоняет пакет, но отправляет уведомление отправителю о блокировке. Это позволяет отправителю знать, что его пакет не доставлен и принимать соответствующие действия. Использование команды reject может быть полезно в ситуациях, когда вам нужно уведомлять отправителя о блокировке пакета.

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

В общем, выбор между drop и reject зависит от потребностей и требований вашей сети. Необходимо оценить, нужно ли уведомление отправителя о блокировке пакета или нет.

Как выбрать между drop и reject в Mikrotik

При настройке брандмауэра Mikrotik, одним из важных решений является выбор между использованием команды drop или reject для блокировки трафика. Обе команды выполняют одну и ту же функцию — отбрасывание пакетов, но существуют отличия в их поведении.

1. Drop

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

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

  • Простота и быстродействие: команда выполняется быстро, без необходимости отправки дополнительных сетевых пакетов;
  • Сокрытие информации: пакеты, отброшенные командой drop, не сообщают отправителю о том, что они были отброшены.

Недостатки использования команды drop:

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

2. Reject

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

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

  • Информативность: отправитель получает информацию о причинах отбрасывания пакетов;
  • Возможность задать собственное сообщение: при использовании команды reject можно указать пользовательское сообщение, которое будет отправлено отправителю вместе с обратным подтверждением.

Недостатки использования команды reject:

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

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

Плюсы и минусы функции drop в Mikrotik

Функция drop является одним из способов фильтрации трафика в Mikrotik. Принцип работы этой функции заключается в том, что все пакеты, удовлетворяющие определенному условию, будут отбрасываться.

  • Плюсы:
    • Отсутствие ответа — пакеты, отброшенные функцией drop, не вызывают никакого ответа на отправителя. Это может быть полезно, если необходимо скрыть наличие определенного сервиса или порта.
    • Более эффективное использование ресурсов — при использовании функции drop, пакеты просто отбрасываются, что позволяет более эффективно использовать ресурсы Mikrotik, по сравнению с функцией reject, которая требует формирования ответа и отправки его отправителю.
    • Улучшение безопасности — использование drop может помочь в предотвращении атак на вашу сеть, так как отброшенные пакеты не будут вызывать никакой реакции на атакующего.
  • Минусы:
    • Отсутствие обратной связи — в отличие от функции reject, функция drop не предоставляет отправителю никакой информации об отброшенных пакетах. Иногда это может стать проблемой, если необходимо уведомить отправителя о том, что его пакеты были отброшены.
    • Сложности в отладке — при использовании функции drop может быть сложно определить, почему пакеты именно отбрасываются, так как не возникает никаких ошибок или сообщений об отказе. Это может затруднить процессы отладки и настройки сети.

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

Плюсы и минусы функции reject в Mikrotik

Функция reject в Mikrotik используется для отклонения сетевых пакетов, но с отправкой соответствующего сообщения об отклонении обратно отправителю. Несмотря на свои особенности, эта функция имеет как плюсы, так и минусы.

Плюсы:

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

Минусы:

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

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

Когда использовать drop в Mikrotik

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

Вот несколько случаев, когда можно использовать drop в Mikrotik:

  1. Блокировка нежелательного трафика: Drop можно использовать для блокировки пакетов, которые происходят от известных злоумышленников, ботов или IP-адресов с плохой репутацией.
  2. Ограничение нагрузки на сервер: Если на сервер поступает большое количество запросов, которые считаются нежелательными или потенциально опасными, можно использовать drop, чтобы отклонить эти запросы и снизить нагрузку на сервер.
  3. Защита от атак: Drop можно использовать для защиты сети от различных атак, таких как атаки отказа в обслуживании (DDoS) или попытки взлома.
  4. Блокировка портсканов: Если обнаруживается портскан, то есть попытка сканирования открытых портов, можно использовать drop для отклонения этих пакетов.

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

Преимущества использования drop в Mikrotik Недостатки использования drop в Mikrotik
  • Полностью отклоняет нежелательные пакеты
  • Не отправляет ответные пакеты
  • Уменьшает нагрузку на сервер
  • Не предоставляет информации об отклоненных пакетах
  • Может привести к блокировке нежелательных пакетов

Когда использовать reject в Mikrotik

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

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

  • Защита от атак. Reject может использоваться для отклонения пакетов, которые являются частью атаки на сеть или устройство.
  • Отклонение некорректных запросов. Если устройство получает некорректные или неразрешенные запросы, оно может ответить на них с помощью reject, чтобы отправитель понял, что его запрос неверен.
  • Фильтрация трафика. Reject можно использовать для отклонения пакетов от определенных источников или с определенными атрибутами для управления трафиком в сети.

Однако, стоит помнить, что reject не является безусловным отклонением пакетов, и в отличие от команды drop возвращается сообщение отправителю о причине отказа. Это может быть полезно для отладки и анализа проблем в сети.

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

Summary

Sub-menu: /ip firewall filter

The firewall implements packet filtering and thereby provides security functions that are used to manage data flow to, from and through the router. Along with the Network Address Translation it serves as a tool for preventing unauthorized access to directly attached networks and the router itself as well as a filter for outgoing traffic.

Network firewalls keep outside threats away from sensitive data available inside the network. Whenever different networks are joined together, there is always a threat that someone from outside of your network will break into your LAN. Such break-ins may result in private data being stolen and distributed, valuable data being altered or destroyed, or entire hard drives being erased. Firewalls are used as a means of preventing or minimizing the security risks inherent in connecting to other networks. Properly configured firewall plays a key role in efficient and secure network infrastrure deployment.

MikroTik RouterOS has very powerful firewall implementation with features including:

  • stateful packet inspection
  • Layer-7 protocol detection
  • peer-to-peer protocols filtering
  • traffic classification by:
  • source MAC address
  • IP addresses (network or list) and address types (broadcast, local, multicast, unicast)
  • port or port range
  • IP protocols
  • protocol options (ICMP type and code fields, TCP flags, IP options and MSS)
  • interface the packet arrived from or left through
  • internal flow and connection marks
  • DSCP byte
  • packet content
  • rate at which packets arrive and sequence numbers
  • packet size
  • packet arrival time
  • and much more!

Chains

The firewall operates by means of firewall rules. Each rule consists of two parts — the matcher which matches traffic flow against given conditions and the action which defines what to do with the matched packet.

Firewall filtering rules are grouped together in chains. It allows a packet to be matched against one common criterion in one chain, and then passed over for processing against some other common criteria to another chain. For example a packet should be matched against the IP address:port pair. Of course, it could be achieved by adding as many rules with IP address:port match as required to the forward chain, but a better way could be to add one rule that matches traffic from a particular IP address, e.g.: /ip firewall filter add src-address=1.1.1.2/32 jump-target=»mychain» and in case of successfull match passes control over the IP packet to some other chain, id est mychain in this example. Then rules that perform matching against separate ports can be added to mychain chain without specifying the IP addresses.

There are three predefined chains, which cannot be deleted:

  • input — used to process packets entering the router through one of the interfaces with the destination IP address which is one of the router’s addresses. Packets passing through the router are not processed against the rules of the input chain
  • forward — used to process packets passing through the router
  • output — used to process packets originated from the router and leaving it through one of the interfaces. Packets passing through the router are not processed against the rules of the output chain

Packet flow diagrams illustrate how packets are processed in RouterOS.

When processing a chain, rules are taken from the chain in the order they are listed there from top to bottom. If a packet matches the criteria of the rule, then the specified action is performed on it, and no more rules are processed in that chain (the exception is the passthrough action). If a packet has not matched any rule within the built-in chain, then it is accepted.

Properties

Property Description
action (action name; Default: accept) Action to take if packet is matched by the rule:

  • accept — accept the packet. Packet is not passed to next firewall rule.
  • add-dst-to-address-list — add destination address to address list specified by address-list parameter
  • add-src-to-address-list — add source address to address list specified by address-list parameter
  • drop — silently drop the packet
  • fasttrack-connection — process packets from a connection using FastPath by enabling FastTrack for the connection
  • jump — jump to the user defined chain specified by the value of jump-target parameter
  • log — add a message to the system log containing following data: in-interface, out-interface, src-mac, protocol, src-ip:port->dst-ip:port and length of the packet. After packet is matched it is passed to next rule in the list, similar as passthrough
  • passthrough — if packet is matched by the rule, increase counter and go to next rule (useful for statistics)
  • reject — drop the packet and send an ICMP reject message
  • return — passes control back to the chain from where the jump took place
  • tarpit — captures and holds TCP connections (replies with SYN/ACK to the inbound TCP SYN packet)
address-list-timeout (none-dynamic | none-static | time; Default: none-dynamic) Time interval after which the address will be removed from the address list specified by address-list parameter. Used in conjunction with add-dst-to-address-list or add-src-to-address-list actions

  • Value of none-dynamic (00:00:00) will leave the address in the address list till reboot
  • Value of none-static will leave the address in the address list forever and will be included in configuration export/backup
chain (name; Default: ) Specifies to which chain rule will be added. If the input does not match the name of an already defined chain, a new chain will be created.
comment (string; Default: ) Descriptive comment for the rule.
chain (name; Default: ) Specifies to which chain rule will be added. If the input does not match the name of an already defined chain, a new chain will be created.
comment (string; Default: ) Descriptive comment for the rule.
connection-bytes (integer-integer; Default: ) Matches packets only if a given amount of bytes has been transfered through the particular connection. 0 — means infinity, for example connection-bytes=2000000-0 means that the rule matches if more than 2MB has been transfered through the relevant connection
connection-limit (integer,netmask; Default: ) Matches connections per address or address block after given value is reached. Should be used together with connection-state=new and/or with tcp-flags=syn because matcher is very resource intensive.
connection-mark (no-mark | string; Default: ) Matches packets marked via mangle facility with particular connection mark. If no-mark is set, rule will match any unmarked connection.
connection-nat-state (srcnat | dstnat; Default: ) Can match connections that are srcnatted, dstnatted or both. Note that connection-state=related connections connection-nat-state is determined by direction of the first packet. and if connection tracking needs to use dst-nat to deliver this connection to same hosts as main connection it will be in connection-nat-state=dstnat even if there are no dst-nat rules at all.
connection-rate (Integer 0..4294967295; Default: ) Connection Rate is a firewall matcher that allow to capture traffic based on present speed of the connection. Read more >>
connection-state (estabilished | invalid | new | related | untracked; Default: ) Interprets the connection tracking analysis data for a particular packet:

  • established — a packet which belongs to an existing connection
  • invalid — a packet that does not have determined state in connection tracking (usually — severe out-of-order packets, packets with wrong sequence/ack number, or in case of resource overusage on router), for this reason invalid packet will not participate in NAT (as only connection-state=new packets do), and will still contain original source IP address when routed. We strongly suggest to drop all connection-state=invalid packets in firewall filter forward and input chains
  • new — the packet has started a new connection, or otherwise associated with a connection which has not seen packets in both directions.
  • related — a packet which is related to, but not part of an existing connection, such as ICMP errors or a packet which begins FTP data connection
  • untracked — packet which was set to bypass connection tracking in firewall RAW tables.
connection-type (ftp | h323 | irc | pptp | quake3 | sip | tftp; Default: ) Matches packets from related connections based on information from their connection tracking helpers. A relevant connection helper must be enabled under /ip firewall service-port
content (string; Default: ) Match packets that contain specified text
dscp (integer: 0..63; Default: ) Matches DSCP IP header field.
dst-address (IP/netmask | IP range; Default: ) Matches packets which destination is equal to specified IP or falls into specified IP range.
dst-address-list (name; Default: ) Matches destination address of a packet against user-defined address list
dst-address-type (unicast | local | broadcast | multicast; Default: ) Matches destination address type:

  • unicast — IP address used for point to point transmission
  • local — if dst-address is assigned to one of router’s interfaces
  • broadcast — packet is sent to all devices in subnet
  • multicast — packet is forwarded to defined group of devices
dst-limit (integer[/time],integer,dst-address | dst-port | src-address[/time]; Default: ) Matches packets until a given rate is exceeded. Rate is defined as packets per time interval. As opposed to the limit matcher, every flow has it’s own limit. Flow is defined by mode parameter. Parameters are written in following format: count[/time],burst,mode[/expire].

  • count — packet count per time interval per flow to match
  • time — specifies the time interval in which the packet count per flow cannot be exceeded (optional, 1s will be used if not specified)
  • burst — initial number of packets per flow to match: this number gets recharged by one every time/count, up to this number
  • mode — this parameter specifies what unique fields define flow (src-address, dst-address, src-and-dst-address, dst-address-and-port, addresses-and-dst-port)
  • expire — specifies interval after which flow with no packets will be allowed to be deleted (optional)
dst-port (integer[-integer]: 0..65535; Default: ) List of destination port numbers or port number ranges
fragment (yes|no; Default: ) Matches fragmented packets. First (starting) fragment does not count. If connection tracking is enabled there will be no fragments as system automatically assembles every packet
hotspot (auth | from-client | http | local-dst | to-client; Default: ) Matches packets received from HotSpot clients against various HotSpot matchers.

  • auth — matches authenticted HotSpot client packets
  • from-client — matches packets that are coming from the HotSpot client
  • http — matches HTTP requests sent to the HotSpot server
  • local-dst — matches packets that are destined to the HotSpot server
  • to-client — matches packets that are sent to the HotSpot client
icmp-options (integer:integer; Default: ) Matches ICMP type:code fields
in-bridge-port (name; Default: ) Actual interface the packet has entered the router, if incoming interface is bridge. Works only if use-ip-firewall is enabled in bridge settings.
in-bridge-port-list (name; Default: ) Set of interfaces defined in interface list. Works the same as in-bridge-port
in-interface (name; Default: ) Interface the packet has entered the router
in-interface-list (name; Default: ) Set of interfaces defined in interface list. Works the same as in-interface
ingress-priority (integer: 0..63; Default: ) Matches the priority of an ingress packet. Priority may be derived from VLAN, WMM, DSCP or MPLS EXP bit. read more»
ipsec-policy (in | out, ipsec | none; Default: ) Matches the policy used by IpSec. Value is written in following format: direction, policy. Direction is Used to select whether to match the policy used for decapsulation or the policy that will be used for encapsulation.

  • in — valid in the PREROUTING, INPUT and FORWARD chains
  • out — valid in the POSTROUTING, OUTPUT and FORWARD chains
  • ipsec — matches if the packet is subject to IpSec processing;
  • none — matches packet that is not subject to IpSec processing (for example, IpSec transport packet).

For example, if router receives Ipsec encapsulated Gre packet, then rule ipsec-policy=in,ipsec will match Gre packet, but rule ipsec-policy=in,none will match ESP packet.

ipv4-options (any | loose-source-routing | no-record-route | no-router-alert | no-source-routing | no-timestamp | none | record-route | router-alert | strict-source-routing | timestamp; Default: ) Matches IPv4 header options.

  • any — match packet with at least one of the ipv4 options
  • loose-source-routing — match packets with loose source routing option. This option is used to route the internet datagram based on information supplied by the source
  • no-record-route — match packets with no record route option. This option is used to route the internet datagram based on information supplied by the source
  • no-router-alert — match packets with no router alter option
  • no-source-routing — match packets with no source routing option
  • no-timestamp — match packets with no timestamp option
  • record-route — match packets with record route option
  • router-alert — match packets with router alter option
  • strict-source-routing — match packets with strict source routing option
  • timestamp — match packets with timestamp
jump-target (name; Default: ) Name of the target chain to jump to. Applicable only if action=jump
layer7-protocol (name; Default: ) Layer7 filter name defined in layer7 protocol menu.
limit (integer,time,integer; Default: ) Matches packets up to a limited rate (packet rate or bit rate). Rule using this matcher will match until this limit is reached. Parameters are written in following format: count[/time],burst:mode.

  • count — packet or bit count per time interval to match
  • time — specifies the time interval in which the packet or bit count cannot be exceeded (optional, 1s will be used if not specified)
  • burst — initial number of packets or bits to match: this number gets recharged every 10ms so burst should be at least 1/100 of rate per second
  • mode — packet or bit mode
log-prefix (string; Default: ) Adds specified text at the beginning of every log message. Applicable if action=log
nth (integer,integer; Default: ) Matches every nth packet. Read more >>
out-bridge-port (name; Default: ) Actual interface the packet is leaving the router, if outgoing interface is bridge. Works only if use-ip-firewall is enabled in bridge settings.
out-bridge-port-list (name; Default: ) Set of interfaces defined in interface list. Works the same as out-bridge-port
out-interface (; Default: ) Interface the packet is leaving the router
out-interface-list (name; Default: ) Set of interfaces defined in interface list. Works the same as out-interface
packet-mark (no-mark | string; Default: ) Matches packets marked via mangle facility with particular packet mark. If no-mark is set, rule will match any unmarked packet.
packet-size (integer[-integer]:0..65535; Default: ) Matches packets of specified size or size range in bytes.
per-connection-classifier (ValuesToHash:Denominator/Remainder; Default: ) PCC matcher allows to divide traffic into equal streams with ability to keep packets with specific set of options in one particular stream. Read more >>
port (integer[-integer]: 0..65535; Default: ) Matches if any (source or destination) port matches the specified list of ports or port ranges. Applicable only if protocol is TCP or UDP
priority (integer: 0..63; Default:) Matches packet’s priority after a new priority has been set. Priority may be derived from VLAN, WMM, DSCP, MPLS EXP bit or from priority that has been set using the set-priority action. Read more >>
protocol (name or protocol ID; Default: tcp) Matches particular IP protocol specified by protocol name or number
psd (integer,time,integer,integer; Default: ) Attempts to detect TCP and UDP scans. Parameters are in following format WeightThreshold, DelayThreshold, LowPortWeight, HighPortWeight

  • WeightThreshold — total weight of the latest TCP/UDP packets with different destination ports coming from the same host to be treated as port scan sequence
  • DelayThreshold — delay for the packets with different destination ports coming from the same host to be treated as possible port scan subsequence
  • LowPortWeight — weight of the packets with privileged (<1024) destination port
  • HighPortWeight — weight of the packet with non-priviliged destination port
random (integer: 1..99; Default: ) Matches packets randomly with given probability.
reject-with (icmp-admin-prohibited | icmp-net-prohibited | icmp-protocol-unreachable | icmp-host-prohibited | icmp-network-unreachable | tcp-reset | icmp-host-unreachable | icmp-port-unreachable; Default: icmp-network-unreachable) Specifies ICMP error to be sent back if packet is rejected. Applicable if action=reject
routing-table (string; Default: ) Matches packets which destination address is resolved in specific a routing table. More details can be found in the Routing Table Matcher page
routing-mark (string; Default: ) Matches packets marked by mangle facility with particular routing mark
src-address (Ip/Netmaks, Ip range; Default: ) Matches packets which source is equal to specified IP or falls into specified IP range.
src-address-list (name; Default: ) Matches source address of a packet against user-defined address list
src-address-type (unicast | local | broadcast | multicast; Default: )

Matches source address type:

  • unicast — IP address used for point to point transmission
  • local — if address is assigned to one of router’s interfaces
  • broadcast — packet is sent to all devices in subnet
  • multicast — packet is forwarded to defined group of devices
src-port (integer[-integer]: 0..65535; Default: ) List of source ports and ranges of source ports. Applicable only if protocol is TCP or UDP.
src-mac-address (MAC address; Default: ) Matches source MAC address of the packet
tcp-flags (ack | cwr | ece | fin | psh | rst | syn | urg; Default: ) Matches specified TCP flags

  • ack — acknowledging data
  • cwr — congestion window reduced
  • ece — ECN-echo flag (explicit congestion notification)
  • fin — close connection
  • psh — push function
  • rst — drop connection
  • syn — new connection
  • urg — urgent data
tcp-mss (integer[-integer]: 0..65535; Default: ) Matches TCP MSS value of an IP packet
time (time-time,sat | fri | thu | wed | tue | mon | sun; Default: ) Allows to create filter based on the packets’ arrival time and date or, for locally generated packets, departure time and date
tls-host (string; Default: ) Allows to match https traffic based on TLS SNI hostname. Accepts GLOB syntax for wildcard matching. Note that matcher will not be able to match hostname if TLS handshake frame is fragmented into multiple TCP segments (packets).
ttl (integer: 0..255; Default: ) Matches packets TTL value

Stats

/ip firewall filter print stats will show additional read-only properties

Property Description
bytes (integer) Total amount of bytes matched by the rule
packets (integer) Total amount of packets matched by the rule

By default print is equivalent to print static and shows only static rules.

[admin@dzeltenais_burkaans] /ip firewall mangle> print stats
Flags: X - disabled, I - invalid, D - dynamic 
 #   CHAIN              ACTION                  BYTES           PACKETS        
 0   prerouting         mark-routing            17478158        127631         
 1   prerouting         mark-routing            782505          4506           

To print also dynamic rules use print all.

[admin@dzeltenais_burkaans] /ip firewall mangle> print all stats
Flags: X - disabled, I - invalid, D - dynamic 
 #   CHAIN              ACTION                  BYTES           PACKETS        
 0   prerouting         mark-routing            17478158        127631         
 1   prerouting         mark-routing            782505          4506           
 2 D forward            change-mss              0               0              
 3 D forward            change-mss              0               0              
 4 D forward            change-mss              0               0              
 5 D forward            change-mss              129372          2031  

Or to print only dynamic rules use print dynamic

[admin@dzeltenais_burkaans] /ip firewall mangle> print stats dynamic 
Flags: X - disabled, I - invalid, D - dynamic 
 #   CHAIN              ACTION                  BYTES           PACKETS        
 0 D forward            change-mss              0               0              
 1 D forward            change-mss              0               0              
 2 D forward            change-mss              0               0              
 3 D forward            change-mss              132444          2079 

Menu specific commands

Property Description
reset-counters (id) Reset statistics counters for specified firewall rules.
reset-counters-all () Reset statistics counters for all firewall rules.

Basic examples

CLI Disctinctive

There is a bit different interpretation in each section with the similar configuration.

For example, with the following configuration line you will match packets where tcp-flags does not have SYN, but has ACK flags:

/ip firewall filter add chain=forward protocol=tcp tcp-flags=!syn,ack

But with this configuration you will match all connections which state is not NEW or RELATED.

/ip firewall filter add action=accept chain=forward connection-state=!new,related

Both configure similarly.

Router protection

Lets say our private network is 192.168.0.0/24 and public (WAN) interface is ether1. We will set up firewall to allow connections to router itself only from our local network and drop the rest. Also we will allow ICMP protocol on any interface so that anyone can ping your router from internet.

/ip firewall filter
add chain=input connection-state=invalid action=drop \
	comment="Drop Invalid connections"  
add chain=input connection-state=established action=accept \
	comment="Allow Established connections"  
add chain=input protocol=icmp action=accept \
	comment="Allow ICMP" 
add chain=input src-address=192.168.0.0/24 action=accept \
	in-interface=!ether1 
add chain=input action=drop comment="Drop everything else"  

Customer protection

To protect the customer’s network, we should check all traffic which goes through the router and block unwanted. For icmp, tcp, udp traffic we will create chains, where will be dropped all unwanted packets:

/ip firewall filter
add chain=forward protocol=tcp connection-state=invalid \
 	action=drop comment="drop invalid connections"  
add chain=forward connection-state=established action=accept \ 
 	comment="allow already established connections"  
add chain=forward connection-state=related action=accept \
 	comment="allow related connections"  

Block «bogon» IP addresses

add chain=forward src-address=0.0.0.0/8 action=drop  
add chain=forward dst-address=0.0.0.0/8 action=drop  
add chain=forward src-address=127.0.0.0/8 action=drop 
add chain=forward dst-address=127.0.0.0/8 action=drop 
add chain=forward src-address=224.0.0.0/3 action=drop 
add chain=forward dst-address=224.0.0.0/3 action=drop 

Make jumps to new chains:

add chain=forward protocol=tcp action=jump jump-target=tcp  
add chain=forward protocol=udp action=jump jump-target=udp  
add chain=forward protocol=icmp action=jump jump-target=icmp 

Create tcp chain and deny some tcp ports in it:

add chain=tcp protocol=tcp dst-port=69 action=drop \
 	comment="deny TFTP" 
add chain=tcp protocol=tcp dst-port=111 action=drop \
 	comment="deny RPC portmapper"  
add chain=tcp protocol=tcp dst-port=135 action=drop \
 	comment="deny RPC portmapper"  
add chain=tcp protocol=tcp dst-port=137-139 action=drop \
 	comment="deny NBT"  
add chain=tcp protocol=tcp dst-port=445 action=drop \
 	comment="deny cifs"  
add chain=tcp protocol=tcp dst-port=2049 action=drop comment="deny NFS"  
add chain=tcp protocol=tcp dst-port=12345-12346 action=drop comment="deny NetBus"  
add chain=tcp protocol=tcp dst-port=20034 action=drop comment="deny NetBus"  
add chain=tcp protocol=tcp dst-port=3133 action=drop comment="deny BackOriffice"  
add chain=tcp protocol=tcp dst-port=67-68 action=drop comment="deny DHCP" 

Deny udp ports in udp chain:

add chain=udp protocol=udp dst-port=69 action=drop comment="deny TFTP"  
add chain=udp protocol=udp dst-port=111 action=drop comment="deny PRC portmapper"  
add chain=udp protocol=udp dst-port=135 action=drop comment="deny PRC portmapper"  
add chain=udp protocol=udp dst-port=137-139 action=drop comment="deny NBT"  
add chain=udp protocol=udp dst-port=2049 action=drop comment="deny NFS"  
add chain=udp protocol=udp dst-port=3133 action=drop comment="deny BackOriffice"  

Allow only needed icmp codes in icmp chain:

add chain=icmp protocol=icmp icmp-options=0:0 action=accept \
 	comment="echo reply"  
add chain=icmp protocol=icmp icmp-options=3:0 action=accept \
 	comment="net unreachable"  
add chain=icmp protocol=icmp icmp-options=3:1 action=accept \
 	comment="host unreachable"
add chain=icmp protocol=icmp icmp-options=3:4 action=accept \
 	comment="host unreachable fragmentation required"  
add chain=icmp protocol=icmp icmp-options=8:0 action=accept \
 	comment="allow echo request"  
add chain=icmp protocol=icmp icmp-options=11:0 action=accept \
 	comment="allow time exceed"  
add chain=icmp protocol=icmp icmp-options=12:0 action=accept \ 
 	comment="allow parameter bad"  
add chain=icmp action=drop comment="deny all other types"  

other ICMP codes are found here.

Brute force protection

Bruteforce_login_prevention_(FTP_&_SSH)

This simple firewall filter rule will limit ether1 outgoing traffic to 100Mbps.

В мире современных сетевых технологий безопасность играет ключевую роль. В сети MikroTik, одного из самых популярных решений для управления сетью, есть несколько методов блокировки трафика: drop и reject. Но как выбрать правильный метод для вашей сети?

Метод drop просто отбрасывает пакеты, не отправляя никаких ответов. Это может быть полезно, если вы хотите, чтобы отправитель пакета не знал о блокировке и продолжал отправлять запросы. Однако, в некоторых случаях, отказ в обработке запроса может быть полезным, и именно в этом случае метод reject приходит на помощь.

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

Итак, как выбрать правильный метод блокировки трафика для вашей сети? Все зависит от ваших конкретных потребностей и ситуации. Если вы хотите, чтобы отправитель не знал о блокировке и продолжал отправлять запросы, выберите метод drop. Если вам нужно предоставить информацию об отказе в обработке запроса, выберите метод reject. В конечном счете, идеальный метод блокировки зависит от технических требований и целей вашей сети.

Содержание

  1. Mikrotik drop или reject: разница и выбор метода блокировки трафика
  2. Плюсы и минусы метода drop
  3. Плюсы и минусы метода reject
  4. Плюсы:
  5. Минусы:
  6. Как выбрать правильный метод блокировки трафика
  7. Рекомендации по использованию метода drop
  8. Рекомендации по использованию метода reject
  9. Сравнительный анализ drop и reject: какой метод лучше

Mikrotik drop или reject: разница и выбор метода блокировки трафика

Когда речь идет о блокировке трафика на устройствах Mikrotik, часто возникает вопрос о выборе между использованием команды drop или reject. Оба метода предназначены для отмены передачи данных, но существуют различия между ними, которые важно учитывать при выборе наиболее подходящего варианта.

Drop — это метод, при котором пакеты данных просто отбрасываются без отправки какого-либо уведомления об этом отправителю. Этот метод предпочтительнее использовать, когда необходимо избежать регистрации активности или присутствия на сети. Например, если вы хотите исключить определенный IP-адрес из доступа к вашей сети, но не желаете обнаруживать свои действия, метод drop подойдет для этой цели. Команда для блокировки трафика с помощью drop выглядит следующим образом: /ip firewall filter add action=drop chain=forward src-address=IP-ADRESS.

Reject — это метод, при котором пакеты данных также отбрасываются, но отправителю возвращается уведомление об отмене передачи. Тем самым, достигается более явная и понятная информация на стороне отправителя. Метод reject может быть полезен, если вы хотите информировать отправителя о наличии блокировки или просмотреть журналы для отслеживания таких попыток доступа. Команда для блокировки трафика с помощью reject выглядит так: /ip firewall filter add action=reject chain=forward reject-with=icmp-network-unreachable src-address=IP-ADDRESS.

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

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

Плюсы и минусы метода drop

Плюсы:

  • При использовании метода drop трафик теряется и не уходит обратно отправителю. Это может быть полезно в случаях, когда требуется полное блокирование доступа к определенным ресурсам или для защиты от вредоносного трафика.
  • Трафик, проходящий через правило drop, не вызывает никаких ответов от MikroTik. Это позволяет сэкономить ресурсы системы, поскольку она не тратит время на формирование и отправку ответов.
  • Метод drop легко настраивается и позволяет блокировать трафик на основе различных параметров, таких как IP-адрес, порты, протоколы и другие.

Минусы:

  • При использовании метода drop нет явной обратной связи отправителю о блокировке его трафика. Это может привести к неоправданному использованию ресурсов отправителя, пока он пытается установить соединение, которое никогда не будет установлено.
  • Использование метода drop может быть менее гибким по сравнению с методом reject при необходимости настроить определенные параметры блокировки или ограничить доступ к конкретным ресурсам.
  • При использовании метода drop может быть сложно отследить заблокированный трафик, поскольку он просто исчезает без каких-либо уведомлений или логирования.

Плюсы и минусы метода reject

Метод reject представляет собой один из способов блокировки трафика на Mikrotik. Рассмотрим основные плюсы и минусы этого метода.

Плюсы:

  • Прозрачность: при использовании метода reject пользователи не замечают, что их трафик блокируется. Они могут продолжать попытки подключения, не зная о блокировке;
  • Отправка соответствующих ICMP-сообщений: при блокировке трафика методом reject Mikrotik отправляет ICMP сообщение «пункт назначения недоступен». Это помогает быстро обнаружить и исправить проблемы с подключением.

Минусы:

  • Нагрузка на сеть: при использовании метода reject Mikrotik отправляет ICMP сообщения в ответ на каждый запрос. Это может привести к увеличению нагрузки на сеть и снижению производительности роутера;
  • Затраты ресурсов: отправка ICMP сообщений требует дополнительных ресурсов процессора и памяти роутера. При большом количестве блокировок это может оказаться критичным;
  • Возможность обхода блокировки: некоторые программы и приложения могут обойти блокировку методом reject, игнорируя ICMP-сообщения и продолжая попытки подключения.

Метод reject имеет свои плюсы и минусы, поэтому выбор между методами drop и reject должен основываться на конкретных требованиях и условиях сети.

Как выбрать правильный метод блокировки трафика

При использовании сетевого оборудования Mikrotik возникает необходимость контролировать и ограничивать трафик, направляемый через сеть. Один из способов достичь этой цели — это использование методов блокировки трафика, таких как «drop» и «reject». Однако, важно выбрать правильный метод в зависимости от конкретной ситуации и требований сети.

Метод «drop» просто отбрасывает пакеты трафика, не отправляя никакого ответа отправителю. Это значит, что отправитель трафика не получит никакого уведомления о том, что его трафик блокируется. Этот метод наиболее полезен, когда не требуется отправлять ответ, например, при блокировке нежелательных адресов или простых атак на сеть.

Метод «reject» отклоняет пакеты трафика и отправляет отправителю ответ о блокировке. Это позволяет отправителю узнать, что его трафик был блокирован и принять соответствующие меры. Метод «reject» более подходит для случаев, когда необходимо предоставить информацию отправителю об ошибке и возможности коррекции.

Чтобы выбрать правильный метод блокировки трафика, следует учитывать следующие факторы:

  • Цель блокировки: если вам нужно просто отбросить пакеты трафика, не предоставляя никакой обратной связи, то метод «drop» является более подходящим выбором. Если же вам нужно дать отправителю информацию о блокировке, то используйте метод «reject».
  • Тип трафика: некоторые типы трафика могут требовать отправки ответа об ошибке для корректной обработки. Например, для протокола DNS может быть полезно использовать метод «reject», чтобы отправитель мог попробовать другие DNS-серверы.
  • Политика безопасности: в зависимости от политики безопасности и требований сети, вам может быть полезно использовать один метод или комбинацию обоих методов для достижения желаемого уровня защиты.

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

Рекомендации по использованию метода drop

Метод drop в Mikrotik является простым и эффективным способом блокировки трафика на маршрутизаторе. Он позволяет отказываться от обработки пакетов и просто отбрасывать их, не отправляя никаких уведомлений об отправке или отказе.

Ниже приведены некоторые рекомендации по использованию метода drop в Mikrotik:

  1. Блокировка конкретных IP-адресов: Если вам нужно заблокировать определенные IP-адреса, вы можете создать правило маршрутизации, которое будет отбрасывать все пакеты от этих адресов. Например, вы можете использовать следующую команду:
    /ip firewall filter add action=drop chain=forward src-address=192.168.1.100
  2. Блокировка диапазонов IP-адресов: Если вам нужно заблокировать диапазон IP-адресов, вы можете использовать диапазон CIDR. Например, вы можете использовать следующую команду:
    /ip firewall filter add action=drop chain=forward src-address=192.168.1.0/24
  3. Блокировка определенных портов: Если вам нужно заблокировать определенные порты, вы можете использовать правило маршрутизации с соответствующими портами. Например, вы можете использовать следующую команду для блокировки порта 80:
    /ip firewall filter add action=drop chain=forward dst-port=80
  4. Блокировка трафика на основе протокола: Если вам нужно заблокировать трафик на основе определенного протокола, вы можете использовать правило маршрутизации с соответствующим протоколом. Например, вы можете использовать следующую команду для блокировки протокола ICMP:
    /ip firewall filter add action=drop chain=forward protocol=icmp

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

Не забудьте сохранить свои настройки после добавления правил маршрутизации. Для сохранения настроек введите команду:

/export file=firewall_rules.rsc

В результате будет создан файл «firewall_rules.rsc», содержащий все правила маршрутизации. Этот файл можно использовать для восстановления настроек в будущем.

Рекомендации по использованию метода reject

Метод reject является одним из вариантов блокировки трафика в Mikrotik. Он позволяет отбрасывать пакеты на early stage, то есть еще до того, как они проходят обработку определенным сервисом на маршрутизаторе.

Вот несколько рекомендаций по использованию метода reject:

  1. Используйте reject для блокировки нежелательного трафика. Например, вы можете использовать reject-правила для отказа в доступе к определенным сайтам или сервисам, которые считаются небезопасными или нежелательными.
  2. Используйте reject с ограниченной активностью. При использовании метода reject необходимо быть внимательным и аккуратным, чтобы избежать блокировки нормального и безопасного трафика. Рекомендуется использовать reject-правила только для ограниченного числа адресов или подсетей, которые действительно не должны быть доступными из вашей сети.
  3. Мониторинг и анализ. После установки reject-правил рекомендуется внимательно следить за трафиком и производить анализ заблокированных пакетов. Такой подход поможет вам своевременно определить нежелательные или ложные блокировки и внести необходимые постройки в правила.
  4. Комментарии к правилам. Для всех reject-правил рекомендуется добавлять комментарии, которые описывают причины и цель блокировки. Это поможет вам и другим администраторам легче понять и поддерживать правила в будущем.

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

Сравнительный анализ drop и reject: какой метод лучше

В маршрутизаторах Mikrotik можно использовать два метода блокировки трафика — drop (отбрасывание) и reject (отклонение). Каждый из этих методов имеет свои особенности, и выбор между ними зависит от целей и требований администратора сети.

Drop

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

Преимущества метода drop включают:

  • Эффективность в использовании ресурсов сети. Пакеты, отбрасываемые методом drop, просто игнорируются, что позволяет сэкономить пропускную способность сети.
  • Отсутствие нагрузки на отправителя. Поскольку отправитель не получает никаких уведомлений о том, что его пакеты были отброшены, нет необходимости отправлять дополнительные пакеты для управления подобной информацией.

Недостатки метода drop:

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

Reject

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

Преимущества метода reject:

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

Недостатки метода reject включают:

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

Таким образом, выбор между методами drop и reject зависит от конкретных требований и ситуации. Если эффективность использования ресурсов важна и отсутствие обратной связи не является критическим, можно использовать метод drop. Если же обратная связь с отправителем и обнаружение атак являются приоритетами, то метод reject будет более предпочтительным.

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

Предисловие

Для кого эта статья

Если вы умеете работать с iptables, то дерзайте и настраивайте firewall, для вас в этой статье не будет ничего нового (ну разве что в таблице NAT используются цепочки с другими именами). Если вы впервые видите firewall в RouterOS и хотите получить готовый скрипт для конфигурации, то вы его здесь не найдете. Материал нацелен на тех, кто хочет получить базовое представление о том как работает firewall и что происходит с ip пакетом на разных этапах его обработки. Более глубокое понимание прейдет с опытом и решением повседневных и необычных задач с использованием пакетного фильтра.

Теоретическая часть

Что такое Layer3 Firewall

Предположим, что у вас есть роутер с выходом в интернет и двумя bridge интерфейсами: bridge-lan(ether2-ether5) и bridge-dmz(ether6-ether10).

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

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

Packet Flow Diagram

Полный путь трафика описан в Packet Flow Diagram, есть несколько официальных(v5, v6) версий, их необходимо знать и использовать в повседневной работе, но для понимания работы пакетного фильтра они перегружены, поэтому я буду объяснять на облегченном варианте.

Input/Output Interface — это любой (физический или виртуальный) Layer 3 интерфейс роутера. Пакет который идет из локальной сети в интернет попадает на input interface, а уходит с output interface. Пакет из интернета в локальную сеть, также попадает на input interface, а уходит с output interface. Packet Flow всегда читается в одном направлении input -> output.

Особенности терминологии

Изучая packet flow для iptables, можно встретить описания через «цепочки в таблицах» либо «таблицы в цепочках». На схеме представлены таблицы в цепочках, при добавлении правил в firewall все будет наоборот.

Но на самом деле пакет перемещается между блоками [цепочка+таблицы], например если вы сделайте accept в блоке [prerouting+mangle] транзитный пакет все-равно будет обработан в [forward+mangle]. Это важно помнить в сложных конфигурациях с pbr и queues.

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

Базовые варианты следования пакета

Транзитный

  1. Пакет из сети приходит на один из интерфейсов роутера
  2. В цепочке PREROUTING администратор может повлиять на маршрут следования пакета: определить выходной интерфейс (Policy base routing) или перенаправить на другой адрес (dst-nat).
  3. В соответствии с таблицей маршрутизации для пакета определяется исходящий интерфейс.
  4. Цепочка FORWARD — основное место фильтрации проходящего трафика.
  5. Последним пунктом перед выходом в сеть является цепочка POSTROUTING, в которой можно изменить адрес отправителя (src-nat).
  6. Пакет ушел в сеть.

Входящий

  1. Пакет из сети пришел на один из интерфейсов роутера
  2. Попал в цепочку PREROUTING.
  3. В соответствии с таблицей маршрутизации пакет был отправлен на обработку локальному процессу.
  4. В цепочке INPUT происходит фильтрация входящего трафика администратором.
  5. Пакет ушел на обработку локальному процессу.

Исходящий

  1. Один из процессов роутера сгенерировал ip пакет (новый или ответный — неважно).
  2. В соответствии с таблицей маршрутизации для пакета определен выходной интерфейс.
  3. Администратор может фильтровать исходящий трафик, либо изменять маршрут в цепочке OUTPUT.
  4. Для пакета принимается окончательное решение о выходном интерфейсе.
  5. Пакет попадает в POSTROUTING, как и проходящий трафик.
  6. Пакет ушел в сеть.

Connection Tracker

Для начала необходимо понять, что представляет из себя stateful и stateless пакетные фильтры.

Пример. Компьютер 192.168.100.10 открывает tcp соединение с сервером 192.0.2.10. На стороне клиента используется динамический порт 49149, на стороне сервера 80. Еще до получения контента клиент и сервер должны обменяться пакетами для установки tcp сессии.

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

В stateful маршрутизатор анализирует пакеты и получив tcp syn от 192.168.100.10:49149 для 192.0.2.10:80 считает это началом нового (new) соединения. Все дальнейшие пакеты (в любом направлении) между 192.168.100.10:49149 и 192.0.2.10:80 будут считаться частью установленного (established) соединения, до закрытия tcp сессии или истечения таймеров.

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

Connection tracker делит пакеты на несколько типов:

new — пакет открывающий соединение, например syn для tcp или первый пакет в udp потоке.
established — пакет относящийся к известному соединению.
related — пакет относящийся к дополнительному соединению в мультипротоколе (sip, pptp, ftp, …).
invalid — пакет от неизвестного соединения.
untracked — пакет не отслеживаемый connection tracker.

Конфигурация Connection tracker

enabled=yes — включен.
enabled=no — отключен.
enabed=auto — отключен, пока в firewall не появится правило использующее возможности conntrack. Используется по умолчанию.

Остальные параметры являются различными таймерами и обычно не требуют тюнинга.

Администратор может просматривать и удалять соединения, например так выглядит соединение с NAT:

Использование conntrack сказывается на производительности и потреблении ресурсов (особенно при большом числе соединений), но отключить его в большинстве конфигураций не получится, т.к. у вас останется stateless firewall без NAT.

Список функций зависящих от connection tracker:

TTL

 Time To Live — поле в заголовке IP пакета определяющее число маршрутизаторов через которые может пройти пакет прежде чем будет уничтожен, защищает от бесконечной пересылки пакетов при петлях маршрутизации.

При пересылке (forwarding) роутер уменьшает значение TTL на 1 отбрасывает, если TTL=0. При этом пакет с TTL=1 попадет локальному процессу роутера.

Некторые операторы связи используют трюки с TTL для пресечения использования роутеров. Все эти ограничения прекрасно обходятся увеличением значения ttl в таблице mangle.

NAT

Network Address Translation — технология изменения адресов в заголовке ip пакета. Как и в linux, NAT является частью пакетного фильтра. NAT работает на основе connection tracker.

Изначально NAT был разработан как быстрое решение проблемы исчерпания IPv4 адресов, для локальных сетей было предложено использовать подсеть из диапазонов: 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16 и транслировать их в один(или несколько) маршрутизируемых адресов. На самом деле есть еще несколько служебных подсетей, которые можно использовать в частных сетях и роутеру в принципе все-равно что и как NAT’ить, но рекомендуется следовать стандартам.

NAT обрабатывает только: tcp, udp, icmp и некоторых мультипротоколов из [IP]->[Firewall]->[Service Port]. Обрабатывается только первый (connection-state=new) пакет в соединении, оставшиеся обрабатываются автоматически без участия таблицы NAT. Это можно отследить по изменению счетчиков в правилах.

В заголовке пакета присутствует Source и Destenation address, соответственно и NAT делится на Source и Destenation NAT.

Source NAT — подмена адреса отправителя, присутствует на подавляющем большинстве домашних и корпоративных роутеров в мире.

Позволяет множеству устройств с «серыми» адресами в локальной сети общаться с интернетом используя один (или несколько) реальных адресов.

Возвращаясь к Packet Flow смотрим, что SRC-NAT находится в Postrouting, после принятия решения о маршрутизации пакета.

Ответный пакет проходит неявный DST-NAT в котором адрес получателя меняется на локальный.

Destenation NAT — подмена адреса получателя.

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

По Packet Flow работа DST-NAT происходит до принятия решения о маршрутизации в Prerouting, присутствует неявный SRC-NAT для ответного трафика.

NAT является довольно мощным инструментом управления трафиком, но применять его стоит в последнюю очередь (когда остальные инструменты не могут помочь).

Цепочки(chains) базовые и пользовательские

Цепочки состоят из правил и форсируют логику обработки пакета.
Есть несколько базовых цепочек, отображенных на packet flow:
Prerouting(dstnat) — обработка пакета до принятия решения о маршрутизации
Input — обработка пакетов предназначеных локальным процессам маршрутизатора
Output — обработка пакетов пакетов сгенерированных локальными процессами маршрутизатора
Forward — Обработка проходящего трафика
Postrouting(srcnat) — Обработка трафика готового к передаче на интерфейс

Все как в iptables, но цепочки в nat переименованы. С чем это связано (скорее всего с hotspot или аппаратной разгрузкой nat) мне неизвестно, но в корне ничего не меняет.

Пакет проходит правила в цепочке последовательно, если он подходим по всем условиям, то к пакету применяется действие. Если действие является терминирующим и не отбрасывает пакет, то он передается в следующий блок packet flow.

У всех цепочек базовых есть действие по умолчанию (если пакет не подошел ни под одно из правил) — accept.

Пользовательские цепочки необходимы для уменьшения количества правил которые проходит каждый пакет и для построения сложных правил обработки трафика. У всех пользовательских цепочек есть действие по умолчанию — return.

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

 

Условия в правилах

 Цепочки состоят из правил, каждое правило состоит из условий и действия. Условий достаточно много, но далеко не все вы будете использовать в реальных конфигурациях. Большинству условий можно поставить префикс «не» (знак «!»). Для совпадением с правилом, пакет должен подходить под все указанные условия.

 Некоторые из условий:

Условие Описание
src-address Адрес источника
dst-address Адрес получателя
src-address-list Адрес источника присутствует в списке
dst-address-list Адрес получателя присутствует в списке
protocol Протокол транспортного уровня
src-port Порт источника
dst-port Порт получателя
port Порт источника или получателя
in-interface Интерфес на который пришел пакет
out-interface Интерфейс с которого пакет будет отправлен в сеть
in-interface-list Интерфес на который пришел пакет присутствует в списке
out-interface-list Интерфейс с которого пакет будет отправлен в сеть присутствует в списке
layer7-protocol Анализ содержимого первых 10 пакетов в соединениий
content Поиск заданной строки в пакете
tls-host Поиск хоста в заголовке tls
ipsec-policy Проверить подпадает пакет под политику ipsec или нет
packet-size размер пакета в байтах
src-mac-address mac адрес источника пакета
connection-mark Метка соединения
packet-mark Метка пакета
routing-mark Маршрутная метка пакета
connection-state Состояние пакета в соединении
tcp-flags Флаги tcp пакета
icmp-options Опции icmp пакета
random Правило срабатывает(при совпадении остальных условий) с заданной вероятностью
time Можно указать рабочее время правила, к сожалению без конктеризации даты
ttl Значение поля ttl в пакете
dscp Значение поля DSCP(ToS) в пакете
—//— —//—
place-before Консольная опция(не условие), позволяет добавить правило перед указанным
disabled Консольная опция(не условие), позволяет отключить правило

Примечания
В качестве src.(dst.) address можно указывать: одиночный ip, диапазон адресов через дефис, либо подсеть.
Списки адресов необходимы для объединения под одним именем нескольких несвязанных ip. В отличии от ipset в netfilter, записи в списках MikroTik могут удаляться через заданный промежуток времени. Просмотреть списки и внести изменения можно в [IP]->[Firewall]->[Address Lists].
В качестве номера порта(port, src-port, dst-port) можно указывать одиночный порт, несколько портов через запятую, либо диапазон портов через дефис.

На последнем MUM в МСК была неплохая презентация на тему влияния различных условий на скорость обработки пакетов (там же вы узнаете как использовать таблицу raw для снижения нагрузки на роутер), кому интересно: запись и презентация.

Действия в таблицах

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

Filter — таблица фильтрации трафика, одно из двух мест, где можно отбросить пакет.

NAT — таблица модификации ip адресов и портов(tpc, udp) в заголовке ip пакета.

Mangle — таблица для модификации других полей ip пакета и установки различных меток.

Существует три типа внутренних меток пакетов: connection, packet, route. Сетки существуют только в пределах роутера и не уходят в сеть. Пакет может иметь по одной метке каждого типа, при последовательном прохождении нескольких mark-* правил метки перезаписываются.
Маршрутные метки можно ставить только в цепочках prerouting и output, остальные в любых цепочках.

Хорошей практикой считается сначала маркировать соединение (connection), а потом пакет (packet) либо маршрут (route). Проверка наличия метки происходит быстрее чем полей пакета. На практике, это не всегда так и в сложных очередях или pbr дополнительная маркировка соединения не приносит пользы.

RAW — таблица позволяющая пакетам обходить механизм трекинга соединений (connection tracker). Используется для противодействия DoS и снижения нагрузки на cpu (например исключением multicast трафика). Позволяет отбросить пакет.

Терминирующие действия завершают обработку пакета в цепочке и передают следующему блоку в packet flow, либо отбрасывают.

Действия:

Таблица Действие Описание Терминирующее?
Все accept Прекратить обработку пакета и передать в следующий блок Pakcet flow Да
Все log Записать в log информацию о пакете.В современных версиях можно добавить log к любому другому действию Нет
Все passtrough Посчитать число пакетов. Используется для отладки Нет
Все add src to address list и add dst to address list Добавить source (destenation) адрес из пакета в заданный список Нет
Все jump Перейти в пользовательскую цепочку Да
Все return Вернуться в родительскую цепочку. В базовых цепочках работает как accept Да
Filter и Raw drop Остановить движение пакета по packet flow и отбросить Да
Filter и Prerouting fasttrack Пометить пакет для быстрого прохождения packet flow Да
Filter reject Аналогично drop, но отправителю пакетов отправляется уведомление(tcp или icmp) о отброшенном пакете Да
Filter trapit Эмулировать наличие открытого порта. Используется для защиты от DoS, ввода в заблуждение и(иногда) отладке Да
NAT src-nat Подмена адреса отправителя на указанный Да
NAT masquerade Частный случай src-nat, подменяет адрес отправителя на один из адресов с интерфейса, используется на динамических(dhcp, vpn) интерфейсах. Не рекомендуется использовать при наличии нескольких ip на интерфейсе Да
NAT same Частный случай src-nat. Подменяет адрес отправителя на адрес из заданного диапазона Да
NAT dst-nat Подменяет адрес получателя на указанный Да
NAT redirect Частный случай dst-nat, подменяет адрес получателя на адрес интерфейса роутера на который пришел пакет Да
NAT netmap Не замена dst-nat. Применяется при трансляции сеть-в-сеть, смотрите примеры Да
Mangle mark connection Метка соединения Нет
Mangle mark packet Метка пакета, применяется в очередях Нет
Mangle mark routing Метка маршрута, применяется в Policy base routing Нет
Mangle change ttl Изменить ttl Нет
Mangle change dcsp(tos) Изменить dcsp, в десятичном виде Нет
Mangle change mss Изменить mss в tcp syn Нет
Mangle clear df Очистить флаг do not fragmet Нет
Mangle strip ipv4 options Очистить дополнительные опции ipv4 Нет
Mangle set priority Установить приоритет для CoS Нет
Mangle route Задать gateway для пакета. Простая версия PBR Нет
Mangle sniff tzsp Инкапсулировать пакеты в udp и отправить на указанный ip Нет
Mangle sniff pc Аналог tzsp, но с другим типом инкапсуляции. В wiki если примеры использования с calea Нет
Mangle passtrough По умолчанию большинство правил в mangle не останавливает прохождение пакета, можно изменить это поведение установить passtrough=no Нет
Raw notrack Не отслеживать пакет в connection tracker Да

Если найдутся желающие, могу написать подробнее про FastTrack и FastPath, но чудес от этих технологий ждать не стоит.

Пара слов про DPI

Существует несколько возможностей заглядывать в пакет чуть глубже заголовка транспортного уровня:
content — производит поиск заданной строки в пакете.
layer7-protocol — буферезирует первые 10 пакетов (или 2KiB) из соединения и производит поиск по regexp в буферезированных данных. Большое число layer7 правил существенно влияют на производительность.
tls-host — адрес имени хоста в заголовке TLS/SNI соединения HTTPS.

Примеры

Не копируйте примеры бездумно, лучше возбмите устройство и постарайтесь написать конфигурацию самостоятельно (или переписать примеры, но вникнуть что делает каждое из правил). Если не знаете как дополнить правила: в дефолтной и минимальной домашней конфигурациях нет доступа на роутер с wan интерфейса, добавьте его с фильтрацией по списку адресов.

Дефолтный Firewall RouterOS

Достаточно защищенная конфигурация, но местами сильно замороченая:

/ip firewall filter
#Разрешает входящий трафик от уже установленных(established, related) соединений и неотслеживаемые(untracked) пакеты
add action=accept chain=input connection-state=established,related,untracked

#Отбрасываем входящие пакеты от неизвестных(invalid) соединений
add action=drop chain=input connection-state=invalid

#Разрешаем входящий icmp трафик
add action=accept chain=input protocol=icmp

#Отбрасываем все входящие пакеты пришеджие не с интерфейсов локальной сети
add action=drop chain=input in-interface-list=!LAN

#Для правильной работы ipsec в туннельном режиме
add action=accept chain=forward ipsec-policy=in,ipsec
add action=accept chain=forward ipsec-policy=out,ipsec

#Маркируем для быстрого прохождения транзитные пакеты от уже установленных соединений
add action=fasttrack-connection chain=forward connection-state=established,related

#Разрешаем транзитные пакеты от уже установленных соединений
add action=accept chain=forward connection-state=established,related,untracked

#Отбрасываем неизвестные транзитные пакеты
add action=drop chain=forward connection-state=invalid

#Отбрасываем транзитные пакеты со стороны wan интерфейсов, которы не относятся к dstnat (вспоминаем, что для ответных пакетов в src-nat присходит неявный dst-nat)
add action=drop chain=forward connection-nat-state=!dstnat connection-state=new in-interface-list=WAN

/ip firewall nat
#Source NAT для пакетов не относящихся к ipsec, уходящих с интерфесов из списка WAN
add action=masquerade chain=srcnat ipsec-policy=out,none out-interface-list=WAN

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

Минимальный «домашний» firewall

 Самый простой, что удалось придумать. Да в нем не разрешен untracked трафик (но на этапе базового изучения firewall он вам всеравно не нужен) и будут проблемы с туннельным ipsec (опять-же, если вы умеете настраивать ipsec, то сами знаете что необходимо сделать).

/ip firewall filter
#Разрешает входящий трафик от уже установленных(established, related) соединений
add chain=input connection-state=established,related action=accept

#Разрешаем входящий icmp трафик
add chain=input connection-state=new protocol=icmp action=accept

#Разрешаем входящий трафик из локальной сети
add chain=input connection-state=new in-interface-list=LAN action=accept

#Отбрасываем весь оставшийся входящий трафик
add chain=input action=drop

#Разрешаем транзитные пакеты от уже установленных соединений
add chain=forward connection-state=established,related action=accept

#Разрешаем транзитные пакеты из локальной сети в сеть интернет
add chain=forward connection-state=new in-interface-list=LAN action=accept

#Отбрасываем весь оставшийся транзитный трафик
add chain=forward action=drop

/ip firewall nat
#Source NAT для пакетов уходящих с интерфесов из списка WAN
add chain=srcnat out-interface-list=WAN action=masquerade 

Пример с DMZ

 На «домашних» роутерах аббревиатурой DMZ любят обзывать компьютер в локальной подсети для которого проброшены все порты из внешней сети.

На самом деле это не так и один из вариантов DMZ — отделение ресурса на который необходимо предоставить доступ из сети интернет и может быть проведена успешная атака (web server с cms в которых постоянно находят дыры — хорошая цель для взломщика). В случае взлома, злоумышленник не сможет повлиять на участников локальной сети.

#Проброс порта
/ip firewall nat
add chain=dstnat dst-port=80,443 action=dst-nat to-address=192.168.200.2

/ip firewall filter
#Разрешаем ответный и icmp входящий трафик
add chain=input connection-state=established,related action=accept
add chain=input protocol=icmp connection-state=new action=accept

#Разрешаем входящий трафик из локальной сети
add chain=input in-interface=ether2-lan action=accept

#Отбрасываем оставшийся входящий трафик
add chain=input action=drop

#Разрешаем ответный транзитный трафик
add chain=forward connection-state=established,related action=accept

#Разрешаем пользователям из локальной сети создавать транзитные соединения
add chain=forward in-interface=ether2-lan connection-state=new action=accept

#Разрешаем транзитные соединения на web сервер
add chain=forward out-interface=ether3-dmz dst-address=192.168.200.2 dst-port=80,443 connection-state=new action=accept

#Отбрасываем оставшийся транзитныйтрафик
add chain=forward action=drop

HairPin NAT

/ip firewall nat
add chain=dstnat dst-port=80 action=dst-nat to-address=192.168.100.2

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

Давайте разберем что происходит:

  1. Компьютер 192.168.100.10 отправляет запрос на 192.0.2.100
  2. На роутере отрабатывает DST-NAT и пакет пересылается на 192.168.100.2
  3. Сервер видит, что к нему на адрес 192.168.100.2 пришел пакет от 192.168.100.10 и отвечает с локального адреса
  4. Компьютер получает неожиданный пакет от 192.168.100.2 и отбрасывает его.

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

/ip firewall nat
#Правило проброса
add chain=dstnat dst-port=80 action=dst-nat to-address=192.168.100.2

#Новое правило, для пользователей из локальной сети
add chain=srcnat src-address=192.168.100.0/24 dst-address=192.168.100.2 action=masquerade

На практике такую схему используют не часто, но как пример отладки firewall мне очень нравится.

Правильное использование netmap

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

Есть два роутера соединенные VPN каналом. Роутеры обслуживают подсети с одинаковой адресацией. Необходимо сделать доступ между подсетями.

Без дополнительной адресации тут не обойтись.

Пользователи из левой подсети будут стучаться в правую через подсеть 192.168.102.0/24
Пользователи из правой подсети будут стучаться в левую через подсеть 192.168.101.0/24

Конфигурация на MikroTik 1.

#Без правила роутинга не обойтись
/ip route
add distance=1 dst-address=192.168.102.0/24 gateway

/ip firewall nat
#В исходящих пакетах будем менять адрес источника
add action=netmap chain=srcnat dst-address=192.168.102.0/24 out-interface=ipip src-address=192.168.100.0/24 to-address=192.168.101.0/24

#Во входящих пакетах будем менять адрес получателя
add action=netmap chain=dstnat dst-address=192.168.101.0/24 in-interface=ipip src-address=192.168.102.0/24 to-address=192.168.100.0/24

Конфигурация MikroTik2 практически аналогична:

/ip route
add distance=1 dst-address=192.168.101.0/24 gateway=10.10.10.1

/ip firewall nat
add action=netmap chain=srcnat dst-address=192.168.101.0/24 out-interface=ipip src-address=192.168.100.0/24 to-address=192.168.102.0/24
add action=netmap chain=dstnat dst-address=192.168.102.0/24 in-interface=ipip src-address=192.168.101.0/24 to-address=192.168.100.0/24

Есть более сложные конфигурации с использованием netmap, например если у вас множество подключений к удаленным точкам с пересекающимеся подсетями и нет возможности изменить настройки на удаленном оборудовании, но это уже advanced routing.

Если вы ничего не поняли (про netmap), значит оно вам не нужно и просто не используйте данное действие при пробросе портов.

Источник публикации

  • Draytek vigorfly 200 настройка роутера
  • Dns яндекс как настроить роутер
  • Draytek vigor 2920vn настройка роутера
  • Dsl роутер d link dsl 2500u настройка ростелеком
  • Dns что ввести в роутер