Содержание
- Action “drop”
- Action “fasttrack connection”
- Action “Jump”
- Action “passtrough”
- Action “Reject”
- Использование “reject” для ограничения доступа к ресурсам
- Action “return”
- Action “tarpit”
Продолжаем говорить про Action в Mikrotik ip firewall filter
01. Action “drop”
/ip firewall filter add action=drop
Следующее действие — это действие, связанное с «откидыванием пакета» (drop).
Делаем правило Input, протокол icmp, action – drop.
Это правило будет запрещать любые пакеты icmp, которые будут идти на наш роутер.
Action drop не сообщает почему произошла блокировка, оно просто уничтожает входящие (в данном случае) пакеты.
Если мы делаем безусловное правило, без указания протокола, то мы запретим любой доступ на наш роутер микротик. Например, я сейчас сделал input без условия и в данном случае я не смогу получить доступ к роутеру используя ip адрес.
Пытаемся подключиться к роутеру и как мы видим, используя айпи адрес, мы не можем получить доступ к роутеру. С чем это связано? Это связано с тем, что мы полностью запретили доступ к роутеру Mikrotik со всех интерфейсов и по всем протоколам.
Firewall работает на третьем уровне и не работает на втором уровне, поэтому используя mac адрес мы можем управлять нашим роутером.
Возвращаем обратно протокол в нашем правиле, и мы можем продолжить настройку нашего роутера, используя ip адрес для подключения.
02. Action “fasttrack connection”
Fasttrack connection позволяет использовать ресурсы нашего роутера более производительно.
Эта оптимизация производительности, часто применяемая для домашних пользователей. Корпоративным пользователям эта опция, как правило, вредит и мешает.
О fasttrack мы поговорим позже.
3. Action “Jump”
/ip firewall filter add action=jump
Опция Jump позволяет создавать отдельные цепочки, об отдельных цепочках мы поговорим в отдельном видео. В данном случае я продемонстрирую механику создания отдельной цепочки.
Input – ICMP мы можем сделать jump – ICMP
После этого весь трафик, связанный с ICMP будет попадать в отдельную цепочку, которую мы можем выбирать в качестве chain.
4. Action “passtrough”
/ip firewall filter add action=passtrough
Действия очень похоже на action – log. Разница лишь в том, что у нас не записывается ничего в лог, но при этом работает счётчик пакетов. Это правило удобно использовать в ситуации, когда нам необходимо найти какое-то правило среди огромного их количества.
Например, нам попался фаерволл с 300 правилами и среди этого количества нам надо найти правило, которые разрешает или запрещает доступ. Что мы делаем? Мы создаём action – passtrough (для icmp в нашем случае) и начинаем его передвигать сверху вниз, пока не начнёт отрабатывать наш счётчик, так же passtrough используется для того, чтобы посчитать те или иные пакеты.
5. Action “Reject”
Reject это правило, которое дропает пакеты и в ответ источнику данных пакетов отправляет icmp сообщение, почему же пакет был дропнут.
Например, reject – мы отвечаем icmp network unreachable.
Проверяем – Destination Net Unreachable.
Мы можем поменять пакет и написать, что заблокировано администратором (admin prohibited), как мы видим сообщение поменялось.
Так же можем ответить, хост заблокирован, сеть заблокирована и т. д.
Эти все действия полезны для блокировки ресурсов в локальной сети и в дальнейшем полезно для диагностики того, что мы заблокировали. Т. е. если у нас происходит ситуация, что мы запретили с гостевой сети доступ в локальную сеть и написали просто network unreachable, это достаточно плохо диагностируется. Но если мы написали «админ запретил доступ», то тогда мы сразу видим, что у нас есть какой-то определённый пакет и это говорит нам, что не сеть не доступна, а роутер микротик говорит нам, что туда идти нельзя.
6. Использование “reject” для ограничения доступа к ресурсам.
/ip firewall filter add action=reject
Reject часто используется для блокировки доступа к тем или иным ресурсам. Например, если мы заблокировали доступ к нашему роутеру по telnet, по умолчанию телнет использует tcp 23й порт, то мы можем сбрасывать tcp соединение. Порт 23 reject tcp reset.
Tcp reset отправляет tcp rst пакет в ответ на tcp.
Проверяем telnet 192.168.88.1
Если мы сделаем drop, то происходит достаточно долгая процедура попыток соединения и в конечном итоге соединение отвалится по таймауту. Необходимо ожидать пока произойдёт таймаут в приложении телнет и только после этого выдаст ошибку – соединение невозможно.
В случае с reject соединение сбрасывается очень быстро.
Reject используется для блокировки ресурсов в рамках управляемой сети. Сообщать злоумышленнику, почему мы запретили доступ к нашему роутеру Mikrotik, не требуется, потому что он проигнорирует это сообщение. Для защиты роутеры с внешних сетей достаточно drop. С точки зрения запрета пользователям использование какого-либо ресурса удобно уведомлять их приложения, почему мы заблокировали доступ отправкой tcp rst пакета.
7. Action “return”
Return позволяет вернуться из пользовательской цепочки в исходную. О цепочках мы поговорим в другом видео.
08. Action “tarpit”
/ip firewall filter add action=tarpit
Tarpit – мы отвечаем на tcp syn пакеты tcp aac пакетами с нулевым окном. Разрешаем соединение на tcp порт, поэтому tarpit работает только с tcp, но при этом никакого соединения не происходит.
Tarpit может понадобиться в случае, если какой-нибудь злоумышленник открывает наш сайт и в этом сайте открывает 300 страниц в секунду. Сайту становится очень плохо.
Наши действия: вычисляем адрес злоумышленника. Заблокировать злоумышленника, чтобы он не пытался подключиться к нашему сайту. Но после того, как мы производим блокировку, он меняет адрес, с которого стучался к нам. Отправляем адрес злоумышленника в tarpit и соединение виснет на разрешенном соединении.
Подключаемся:
Идёт подключение, но ничего не происходит.
В случае с tarpit мы попадаем куда-то, но не получаем никаких данных.
Tarpit довольно производительное правило.
На этом осмотр ip-firewall-filter rules action закончен.
В настройках маршрутизатора Mikrotik есть два основных способа обработки пакетов: drop и reject. Оба метода позволяют отклонить пакет и не доставить его до оконечного устройства, но есть существенные различия между ними.
Drop используется для тихого отклонения пакета, без отправки уведомления отправителю. Когда маршрутизатор принимает пакет, который должен быть удален, он просто удаляет его и не отправляет никакого уведомления об этом. Такой подход предпочтителен, если вы не хотите, чтобы отправитель знал, что его пакет был отклонен.
Reject, в свою очередь, отправляет уведомление отправителю, что пакет был отклонен. Результатом этого является отправка ICMP «Destination Unreachable» сообщения обратно отправителю. Такой подход полезен, например, для отслеживания потенциальных атак и логирования действий злоумышленников.
Выбор между drop и reject зависит от конкретных потребностей и требований вашей сети. Если вам необходимо просто отклонить пакет без отправки уведомления, используйте drop. Если же вы хотите отправить уведомление и сохранить информацию о попытке подключения, выберите reject. В любом случае, помните о безопасности вашей сети и выбирайте наиболее подходящий метод для решения вашей задачи.
Содержание
- Преимущества и недостатки функционала в Mikrotik
- Различия между drop и reject в Mikrotik
- Как выбрать между drop и reject в Mikrotik
- Плюсы и минусы функции drop в Mikrotik
- Плюсы и минусы функции reject в Mikrotik
- Плюсы:
- Минусы:
- Когда использовать drop в Mikrotik
- Когда использовать 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:
- Блокировка нежелательного трафика: Drop можно использовать для блокировки пакетов, которые происходят от известных злоумышленников, ботов или IP-адресов с плохой репутацией.
- Ограничение нагрузки на сервер: Если на сервер поступает большое количество запросов, которые считаются нежелательными или потенциально опасными, можно использовать drop, чтобы отклонить эти запросы и снизить нагрузку на сервер.
- Защита от атак: Drop можно использовать для защиты сети от различных атак, таких как атаки отказа в обслуживании (DDoS) или попытки взлома.
- Блокировка портсканов: Если обнаруживается портскан, то есть попытка сканирования открытых портов, можно использовать 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:
|
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
|
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:
|
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:
|
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] .
|
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.
|
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.
For example, if router receives Ipsec encapsulated Gre packet, then rule |
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.
|
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 .
|
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
|
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:
|
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
|
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. В конечном счете, идеальный метод блокировки зависит от технических требований и целей вашей сети.
Содержание
- Mikrotik drop или reject: разница и выбор метода блокировки трафика
- Плюсы и минусы метода drop
- Плюсы и минусы метода reject
- Плюсы:
- Минусы:
- Как выбрать правильный метод блокировки трафика
- Рекомендации по использованию метода drop
- Рекомендации по использованию метода reject
- Сравнительный анализ 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:
- Блокировка конкретных IP-адресов: Если вам нужно заблокировать определенные IP-адреса, вы можете создать правило маршрутизации, которое будет отбрасывать все пакеты от этих адресов. Например, вы можете использовать следующую команду:
/ip firewall filter add action=drop chain=forward src-address=192.168.1.100
- Блокировка диапазонов IP-адресов: Если вам нужно заблокировать диапазон IP-адресов, вы можете использовать диапазон CIDR. Например, вы можете использовать следующую команду:
/ip firewall filter add action=drop chain=forward src-address=192.168.1.0/24
- Блокировка определенных портов: Если вам нужно заблокировать определенные порты, вы можете использовать правило маршрутизации с соответствующими портами. Например, вы можете использовать следующую команду для блокировки порта 80:
/ip firewall filter add action=drop chain=forward dst-port=80
- Блокировка трафика на основе протокола: Если вам нужно заблокировать трафик на основе определенного протокола, вы можете использовать правило маршрутизации с соответствующим протоколом. Например, вы можете использовать следующую команду для блокировки протокола 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:
- Используйте reject для блокировки нежелательного трафика. Например, вы можете использовать reject-правила для отказа в доступе к определенным сайтам или сервисам, которые считаются небезопасными или нежелательными.
- Используйте reject с ограниченной активностью. При использовании метода reject необходимо быть внимательным и аккуратным, чтобы избежать блокировки нормального и безопасного трафика. Рекомендуется использовать reject-правила только для ограниченного числа адресов или подсетей, которые действительно не должны быть доступными из вашей сети.
- Мониторинг и анализ. После установки reject-правил рекомендуется внимательно следить за трафиком и производить анализ заблокированных пакетов. Такой подход поможет вам своевременно определить нежелательные или ложные блокировки и внести необходимые постройки в правила.
- Комментарии к правилам. Для всех 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 есть более точные определения, но простыми словами:
Цепочки отвечают за место обработки пакета и последовательность правил.
Таблицы определяют действия, которые можно произвести над пакетом.
Базовые варианты следования пакета
Транзитный
- Пакет из сети приходит на один из интерфейсов роутера
- В цепочке PREROUTING администратор может повлиять на маршрут следования пакета: определить выходной интерфейс (Policy base routing) или перенаправить на другой адрес (dst-nat).
- В соответствии с таблицей маршрутизации для пакета определяется исходящий интерфейс.
- Цепочка FORWARD — основное место фильтрации проходящего трафика.
- Последним пунктом перед выходом в сеть является цепочка POSTROUTING, в которой можно изменить адрес отправителя (src-nat).
- Пакет ушел в сеть.
Входящий
- Пакет из сети пришел на один из интерфейсов роутера
- Попал в цепочку PREROUTING.
- В соответствии с таблицей маршрутизации пакет был отправлен на обработку локальному процессу.
- В цепочке INPUT происходит фильтрация входящего трафика администратором.
- Пакет ушел на обработку локальному процессу.
Исходящий
- Один из процессов роутера сгенерировал ip пакет (новый или ответный — неважно).
- В соответствии с таблицей маршрутизации для пакета определен выходной интерфейс.
- Администратор может фильтровать исходящий трафик, либо изменять маршрут в цепочке OUTPUT.
- Для пакета принимается окончательное решение о выходном интерфейсе.
- Пакет попадает в POSTROUTING, как и проходящий трафик.
- Пакет ушел в сеть.
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
Типичная ситуация, когда вы делайте проброс порта на сервер в локальной сети и извне все работает, а вот внутри локальной сети сервер не доступен по внешнему адресу.
Давайте разберем что происходит:
- Компьютер 192.168.100.10 отправляет запрос на 192.0.2.100
- На роутере отрабатывает DST-NAT и пакет пересылается на 192.168.100.2
- Сервер видит, что к нему на адрес 192.168.100.2 пришел пакет от 192.168.100.10 и отвечает с локального адреса
- Компьютер получает неожиданный пакет от 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), значит оно вам не нужно и просто не используйте данное действие при пробросе портов.
Источник публикации