Настройка firewall на mikrotik пошаговая инструкция

Overview

We strongly suggest keeping the default firewall on. Here are a few adjustments to make it more secure. Make sure you configure additional changes when you completely understand the benefit of these particular firewall rules.

To see the default firewall rules through the CLI you can type:

/system default-configuration print

Ipv4 firewall 

Protect the router itself

• work with new connections to decrease load on a router;
• create address-list for IP addresses, that are allowed to access your router;
• enable ICMP access (optionally);
• drop everything else, log=yes might be added to log packets that hit the specific rule;

/ip firewall filter
add action=accept chain=input comment="default configuration" connection-state=established,related
add action=accept chain=input src-address-list=allowed_to_router
add action=accept chain=input protocol=icmp
add action=drop chain=input
/ip firewall address-list
add address=192.168.88.2-192.168.88.254 list=allowed_to_router

Protect the LAN devices

We will create address-list with name «not_in_internet» which we will use for the firewall filter rules:

/ip firewall address-list
add address=0.0.0.0/8 comment=RFC6890 list=not_in_internet
add address=172.16.0.0/12 comment=RFC6890 list=not_in_internet
add address=192.168.0.0/16 comment=RFC6890 list=not_in_internet
add address=10.0.0.0/8 comment=RFC6890 list=not_in_internet
add address=169.254.0.0/16 comment=RFC6890 list=not_in_internet
add address=127.0.0.0/8 comment=RFC6890 list=not_in_internet
add address=224.0.0.0/4 comment=Multicast list=not_in_internet
add address=198.18.0.0/15 comment=RFC6890 list=not_in_internet
add address=192.0.0.0/24 comment=RFC6890 list=not_in_internet
add address=192.0.2.0/24 comment=RFC6890 list=not_in_internet
add address=198.51.100.0/24 comment=RFC6890 list=not_in_internet
add address=203.0.113.0/24 comment=RFC6890 list=not_in_internet
add address=100.64.0.0/10 comment=RFC6890 list=not_in_internet
add address=240.0.0.0/4 comment=RFC6890 list=not_in_internet
add address=192.88.99.0/24 comment="6to4 relay Anycast [RFC 3068]" list=not_in_internet

Brief firewall filter rule explanation:

• packets with connection-state=established,related added to FastTrack for faster data throughput, firewall will work with new connections only;
• drop invalid connection and log them with prefix «invalid»;
• drop attempts to reach not public addresses from your local network, apply address-list=not_in_internet before, «bridge» is local network interface, log=yes attempts with prefix «!public_from_LAN»;
• drop incoming packets that are not NAT`ed, ether1 is public interface, log attempts with «!NAT» prefix;
• jump to ICMP chain to drop unwanted ICMP messages
• drop incoming packets from the Internet, which are not public IP addresses, ether1 is a public interface, log attempts with prefix «!public»;
• drop packets from LAN that does not have LAN IP, 192.168.88.0/24 is local network used subnet;

/ip firewall filter
add action=fasttrack-connection chain=forward comment=FastTrack connection-state=established,related
add action=accept chain=forward comment="Established, Related" connection-state=established,related
add action=drop chain=forward comment="Drop invalid" connection-state=invalid log=yes log-prefix=invalid
add action=drop chain=forward comment="Drop tries to reach not public addresses from LAN" dst-address-list=not_in_internet in-interface=bridge log=yes log-prefix=!public_from_LAN out-interface=!bridge
add action=drop chain=forward comment="Drop incoming packets that are not NAT`ted" connection-nat-state=!dstnat connection-state=new in-interface=ether1 log=yes log-prefix=!NAT
add action=jump chain=forward protocol=icmp jump-target=icmp comment="jump to ICMP filters"
add action=drop chain=forward comment="Drop incoming from internet which is not public IP" in-interface=ether1 log=yes log-prefix=!public src-address-list=not_in_internet
add action=drop chain=forward comment="Drop packets from LAN that do not have LAN IP" in-interface=bridge log=yes log-prefix=LAN_!LAN src-address=!192.168.88.0/24

Allow only needed icmp codes in «icmp» chain:

/ip firewall filter
  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"

IPv6 firewall 

Protect the router itself

Create an address-list from which you allow access to the device:

/ipv6 firewall address-list add address=fd12:672e:6f65:8899::/64 list=allowed

Brief IPv6 firewall filter rule explanation:

• work with new packets, accept established/related packets;
• drop link-local addresses from Internet(public) interface/interface-list;
• accept access to a router from link-local addresses, accept multicast addresses for management purposes, accept your source address-list for router access;
• drop anything else;

/ipv6 firewall filter
add action=accept chain=input comment="allow established and related" connection-state=established,related
add chain=input action=accept protocol=icmpv6 comment="accept ICMPv6"
add chain=input action=accept protocol=udp port=33434-33534 comment="defconf: accept UDP traceroute"
add chain=input action=accept protocol=udp dst-port=546 src-address=fe80::/16 comment="accept DHCPv6-Client prefix delegation."
add action=drop chain=input in-interface=sit1 log=yes log-prefix=dropLL_from_public src-address=fe80::/16
add action=accept chain=input comment="allow allowed addresses" src-address-list=allowed
add action=drop chain=input
/ipv6 firewall address-list
add address=fe80::/16 list=allowed
add address=xxxx::/48 list=allowed
add address=ff02::/16 comment=multicast list=allowed

Protect the LAN devices

Enabled IPv6 puts your clients available for public networks, set proper firewall to protect your customers.

• accept established/related and work with new packets;
• drop invalid packets and put prefix for rules;
• accept ICMP packets;
• accept new connection from your clients to the Internet;
• drop everything else.

/ipv6 firewall filter
add action=accept chain=forward comment=established,related connection-state=established,related
add action=drop chain=forward comment=invalid connection-state=invalid log=yes log-prefix=ipv6,invalid
add action=accept chain=forward comment=icmpv6 in-interface=!sit1 protocol=icmpv6
add action=accept chain=forward comment="local network" in-interface=!sit1 src-address-list=allowed
add action=drop chain=forward log-prefix=IPV6

Firewall в MikroTikk – тема, на которую можно написать докторскую диссертацию. Раздел, который находится по пути IP > Firewall, предназначен для контролирования трафика во всех направлениях, относительно самого MikroTik:

• Входящий;
• Проходящий;
• Исходящий;

Самой востребованной функцией этого раздела – является возможность защиты внутренней сети маршрутизатора от атак извне. Так же данная функция с соответствующими правилами, позволяет фильтровать «мусор» из внешней сети, который может значительно нагружать RouterBoard, а это сказывается на производительности. Бывают даже попытки взлома устройства, особенно если у вас есть внешний IP адрес.

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

Для примера – будем настраивать RB750.

Допустим, что интернет мы получаем на 1-й порт устройства. Подключение уже настроено и работает. А теперь непосредственно к самой настройке.

Настройка firewall на mikrotik

Подключаемся к устройству при помощи утилиты Winbox

Переходим в меню интерфейса по пути IP > Firewall

В окне раздела переключаемся на вкладку Filter Rules

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

Все правила в MikroTik работают по иерархии. Если правило под номером 1 запрещает определенное действие, а правило номер 2 разрешает, то действие работать не будет. Чтобы правило №2 заработало – его нужно переместить выше правила №1. Это можно сделать простым перетаскиванием мышью.

Правила №0 и №1. Разрешаем пинговать устройство

Это правило нужно для проверки связи с сетевым устройством в ОС Windows (также она присутствует в консолях и других систем, но имеет немного другой синтаксис) существует команда ping.

Запускается она на разных версиях Windows по-разному, но есть один способ, одинаковый для всех:

• Нажимаем комбинацию клавиш Win+R;
• В окне ввода команд набираем cmd;
• Нажимаем Enter;

Запустится командная строка (черное окно). В ней вводим следующее:

Ping 192.168.5.1 и нажимаем Enter.

*для примера указан IP адрес RB750, у вас он может быть другим

Если в результате вы получили что-то вроде:

Ответ от 192.168.5.1: число байт=32 время<1мс TTL=64

Значит все хорошо, устройство «на связи».

Если получили что-то другое – значит питание устройства отключено или фаервол запрещает устройству отвечать на запросы.

Другие правила firewall на mikrotik

Правила №2 и №3. Разрешаем установленные подключения

*Комментарии к правилам можно написать, выделив нужное и нажав на клавиатуре букву C

В результате появится окно ввода комментария;

После ввода комментария нажимаем OK;

Правила №4 и №5. Разрешаем связанные подключения

Правило №6. Разрешаем подключаться из локальной сети

Адрес вашей сети может отличаться. В нашем случае сеть имеет адрес 192.168.5.0/24

Входной кабель от провайдера подключен на ether1

Правила №7 и №8. Запрещаем ошибочные соединения

Правило №9. Запрещаем все остальные входящие соединения из внешней сети

Правило №10. Разрешаем прохождение трафика из локалки в интернет

Правило №11. Запрещаем все остальные подключения

Вот такой список правил у вас должен получиться

MikroTik настроен, защищен и готов к работе.

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Общие принципы построения брандмауэра

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

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

Любое новое соединение первоначально находится в статусе нового (new) и мы должны принять решение: одобрить его или запретить. Для этой задачи и предназначены создаваемые нами правила, в нормально закрытом брандмауэре мы описываем, какие соединения и по каким критериям следует разрешить. Если же пакет не соответствует ни одному правилу, то мы запрещаем такое соединение.

После того, как соединение было установлено — оно переходит в состояние установлено (established), при этом специальный механизм ядра Connection Tracker отслеживает все проходящие пакеты и сопоставляет их соединениям, поэтому мы можем спокойно оперировать именно состоянием соединения, не задумываясь над техническими тонкостями работы.

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

Очень часто одни соединения, будучи установленными, создают другие, которые называются связанными (related), как пример можно привести хорошо известные FTP или PPTP, которые имеют управляющее соединение и соединение(я) для передачи данных. Они могут использовать динамические порты и поэтому их также следует автоматически разрешать, если мы разрешили основное соединение.

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

В роутерах Mikrotik существует еще один тип соединения — неотслеживаемое (untracked), такие соединения не отслеживаются Connection Tracker, что позволяет существенно снизить нагрузку на устройство. Для чего это может быть нужно? Допустим, в фильтруемом вами трафике есть значительная доля принадлежащая доверенным узлам, для которых можно четко прописать критерии, в этом случае можно пометить их неотслеживаемыми и добавить их одобрение в самое первое правило, к уже установленным и связанным.

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

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

Ну и завершающим правилом в цепочке должно стоять запрещающее, отсекающее все соединения, которые не попали под разрешающие правила и не являются уже установленными или связанными с ними.

Конфигурация брандмауэра по умолчанию

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

Все правила сгруппированы в две цепочки: input — для входящего трафика самого роутера и forward — для транзитного, между интерфейсами роутера. Сразу напомним, что у роутеров Mikrtoik нет жестко заданных «внешних» и «внутренних» интерфейсов, и вообще все эти понятия находятся исключительно у нас в голове, согласно логическому плану сети.

В конфигурации по умолчанию также присутствует два списка интерфейсов: WAN — куда включен порт, настроенный как внешний, обычно ether1 и LAN, в состав которого входит мост, объединяющий оставшиеся порты. и эти списки активно применяются в правилах.

Самих правил немного, всего 11 штук: 5 для input и 6 для forward.

Рассмотрим их подробнее. Правило с нулевым номером в расчет не берем, это пустышка для вывода счетчиков Fasttrack. Начнем с первых двух, это классическая связка, о которой мы говорили выше: разрешаем established, related и untracked для всех входящих соединений, без привязки к интерфейсам. Затем запрещаем invalid, вполне очевидно, что далее пройдут только пакеты соединений в состоянии new.

/ip firewall filter
add chain=input action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untracked"
add chain=input action=drop connection-state=invalid comment="defconf: drop invalid"

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

add chain=input action=accept protocol=icmp comment="defconf: accept ICMP"

Следующее правило весьма специфично, оно разрешает входящие на петлевой интерфейс, точнее адрес 127.0.0.1, поскольку интерфейс петли явно в RouterOS не доступен, а также снабжено комментарием, что это для CAPsMAN. Его смысл станет понятен чуть ниже.

add chain=input action=accept dst-address=127.0.0.1 comment="defconf: accept to local loopback (for CAPsMAN)"

И завершает цепочку input блокирующее правило:

add chain=input action=drop in-interface-list=!LAN comment="defconf: drop all not coming from LAN"

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

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

А где же здесь размещать свои собственные правила? А вот здесь:

/ip firewall filter
add chain=input action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untracked"
add chain=input action=drop connection-state=invalid comment="defconf: drop invalid"
add chain=input action=accept protocol=icmp comment="defconf: accept ICMP"
<собственные правила>
add chain=input action=accept dst-address=127.0.0.1 comment="defconf: accept to local loopback (for CAPsMAN)"
add chain=input action=drop in-interface-list=!LAN comment="defconf: drop all not coming from LAN"

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

add chain=forward action=accept ipsec-policy=in,ipsec comment="defconf: accept in ipsec policy"
add chain=forward action=accept ipsec-policy=out,ipsec comment="defconf: accept out ipsec policy"

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

Правильное использование Fast Path и FastTrack в Mikrotik

Если коротко, то Fasttrack значительно снижает нагрузку на оборудование, но фактически пускает трафик в обход брандмауэра. Но так как фильтровать established и related нам не надо, то почему бы и не пустить их коротким путем?

add chain=forward action=fasttrack-connection connection-state=established,related comment="defconf: fasttrack"

Далее та же самая классика: разрешаем established, related и untracked, запрещаем invalid. Для всех направлений без разбора.

add chain=forward action=accept connection-state=established,related,untracked comment="defconf: accept established,related, untracked"
add chain=forward action=drop connection-state=invalid comment="defconf: drop invalid"

Ну и, наконец, запрещающее правило, оно тоже интересно:

add chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN comment="defconf: drop all from WAN not DSTNATed"

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

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

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

Куда добавлять собственные правила? Да вот сюда:

add chain=forward action=accept connection-state=established,related,untracked comment="defconf: accept established,related, untracked"
add chain=forward action=drop connection-state=invalid comment="defconf: drop invalid"
<собственные правила>
add chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN comment="defconf: drop all from WAN not DSTNATed"

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

Собственная конфигурация брандмауэра

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

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

Правил в нашем варианте меньше, всего 9, из них 4 для input и 5 для forward.

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

/ip firewall filter
add action=accept chain=input connection-state=established,related in-interface-list=WAN comment="accept established,related"
add action=drop chain=input connection-state=invalid in-interface-list=WAN comment="drop invalid"
add action=accept chain=input in-interface-list=WAN protocol=icmp comment="accept ICMP"
<собственные правила>
add action=drop chain=input in-interface-list=WAN comment="drop all from WAN"

Мы точно также разрешаем установленные и связанные, запрещаем invalid, разрешаем ICMP. Можно заметить, что у нас нет untracked, это сознательное решение, если мы будем использовать неотслеживаемые соединения — то всегда можем добавить этот параметр, но сделаем это осознанно. Собственные правила мы можем добавлять выше запрещающего весь остальной трафик с внешних интерфейсов.

Также следует отметить несколько иную политику блокировки остального трафика. Стандартная конфигурация подходит достаточно радикально, запрещая все, кроме LAN. Мы же используем более мягкий подход, и блокируем только внешние сети — WAN. Это позволяет сделать конфигурацию проще и не прописывать дополнительные правила для того же CAPsMAN, при этом мы помним, что администратор знает какие сети являются внутренними, а какие нет и контролирует актуальность списков.

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

А вот к Fasttrack у нас подход другой. В стандартной конфигурации он включен для всех established и related, вне зависимости от направления. Это здорово разгружает роутер, но со временем у вас неизбежно появятся туннели, VPN, прочие сети и Fasttrack будет там чаще мешать, чем помогать, порой приводя к неожиданным результатам. Поэтому четко указываем, что применяем коротки путь только для соединений из локальной сети наружу и извне в локальную сеть. Часто можно даже отойти от использования списков и просто указать интерфейсы.

add action=fasttrack-connection chain=forward connection-state=established,related in-interface-list=WAN out-interface-list=LAN comment="fasttrack" 
add action=fasttrack-connection chain=forward connection-state=established,related in-interface-list=LAN out-interface-list=WAN

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

Ну и дальше все тоже самое. Разрешаем established и related, запрещаем invalid и обязательно указываем, что это именно для внешних сетей, ниже запрещаем все остальное, также для внешних интерфейсов.

add action=accept chain=forward connection-state=established,related in-interface-list=WAN comment="accept established,related"
add action=drop chain=forward connection-state=invalid in-interface-list=WAN comment="drop invalid"
<собственные правила>
add action=drop chain=forward in-interface-list=WAN comment="drop all from WAN"

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

Но если вы используете роутер дома и самый широкий набор приложений пробрасывает порты при помощи UPnP, то последнее правило действительно будет удобнее заменить на:

add action=drop chain=forward connection-nat-state=!dstnat in-interface-list=WAN comment="drop all from WAN"

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Маршрутизаторы Mikrotik включают линейку сетевого оборудования на платформе RouterBoard. Ее различные варианты применяют для решения разнообразных задач – от оснащения простой точки доступа с поддержкой Wi-Fi до мощных аппаратов со встроенным брандмауэром и QoS. Везде используется операционная система RouterOS, разработанная той же латвийской компанией, что выпускает сами устройства Микротик.

Программная платформа стала настолько популярной, что отчасти перекочевала на компьютеры с поддержкой архитектуры x86. Чуть позже была разработана версия системы для облачных сервисов (версия Cloud Hosted Router). В этом материале мы рассмотрим, как настроить брандмауэр, задать необходимые параметры для защиты от хакерских атак. Ведь это основа безопасности офисной сети и приоритетное направление работы системных администраторов. 

Разработчики платформы RouterBoard предусмотрели ряд заводских настроек, применяемых уже при первом включении сетевого устройства. Но распространяется правило не на все решения, облачные системы CHR необходимо настраивать «с нуля». Поэтому их нужно вносить сразу, еще до начала эксплуатации. Об установке и базовой настройке Mikrotik CHR мы уже писали в блоге cloud.timeweb.com, поэтому сейчас сразу перейдем к настройкам файрвола.

Теория настройки файрвола

Сразу уточним, что в здесь мы рассмотрим настройку облачного варианта RouterOS CHR при помощи командной строки (CLI). При работе с WinBox и WebFig алгоритм будет таким же. 

Итак, начнем рассмотрение базовых понятий по настройке Mikrotik. Одно из основных здесь – «цепочка». На новых устройствах установлено 3 единицы, но пользователю доступны функции создания собственных.

Варианты:

1. INPUT – входящий трафик, поступающий на устройство через Mikrotik Firewall.
2. OUTPUT – исходящий трафик, передаваемый внешним клиентам из памяти оборудования.
3. FORWARD – сквозной трафик, который передается от клиента клиенту, но через Mikrotik.

Файрвол – это решение для фильтрации пакетов данных по определенным правилам. Первый вид цепочки предназначен для обработки поступающей информации, например, из интернета, страниц сайтов, которые открывает пользователь, из облачных хранилищ, откуда тот скачивает файлы. Все, что передается обратно, будет обработано по правилам, заданным цепочкой Output (это позволяет применить разные настройки на оба вида трафика).

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

При настройке Микротика также придется столкнуться со статусами соединения. Каждое из них можно разделить на 4 условные категории:

1. New – это только что созданное соединение, исходящее, входящее или сквозное.
2. Established – коннект установлен, оборудование готово к передаче пакетов информации.
3. Related – обращение осуществляется к одному из ранее созданных соединений, когда нужно изменить его назначение в служебных целях.
4. Invalid – ошибочное обращение, когда маршрутизатор «не может понять» формат или иные критерии входящего соединения.

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

Теперь перейдем к практике

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

[admin@MikroTik] > ip firewall filter print 

Результат:

Flags: X - disabled, I - invalid, D – dynamic

Если ранее настройка еще не производилась, результат будет в виде подсказки про флаги, которыми можно управлять ситуацией. Все предлагаемые варианты команд отображаются путем нажатия кнопки со знаком вопроса <?> (с учетом раскладки клавиатуры).

Следующий шаг – переход в раздел настройки фильтрации, для этого есть команда:

[admin@MikroTik] > ip firewall filter 
[admin@MikroTik] /ip firewall filter>

Результат:

[admin@MikroTik] /ip firewall filter>

Теперь активируем парочку правил:

add action=accept chain=input comment="default configuration" connection-state=established,related

Рассмотрим составляющие последней команды:

• add action=accept – ставится задача принять пакеты;
• chain=input – будет применяться набор правил, соответствующий входящему трафику Input;
• сomment=«default configuration» – поле для любых комментариев от пользователя, в этом случае внесена информация о том, что конфигурация будет применяться «по умолчанию»;
• connection-state=established,related – устанавливаем полный список статусов, которые будут учитываться при приеме соединений.

Несмотря на довольно длинную строку, приведенный пример команды довольно прост по значению. Ее назначение укладывается во фразу: «Принимать входящие пакеты с подтвержденным статусом Established и Related». Все остальные блоки данных будут отклонены автоматически, пока владелец не изменит настройки фильтров. Теперь рассмотрим следующее правило, рекомендуемое при настройке Mikrotik RouterBoard.

Внесите в окне консоли команду:

add action=accept chain=input src-address-list=allowed_to_router

В приведенном примере наиболее интересен критерий src-address-list=allowed_to_router. Благодаря ему системный администратор может указать перечень разрешенных IP-адресов хостов, с которых допускается принимать пакеты данных. Перечень Mikrotik Address List вносят в файл с названием allowed_to_router, его можно редактировать в процессе эксплуатации сетевого оборудования. При необходимости создается любое количество списков под разными именами.

Такая функция пригодится нам в дальнейшем, когда перейдем к рассмотрению создания перечня допустимых IP-адресов. Также сразу отметим, что последовательность обработки правил создает некоторые ограничения в их применении. Так, рекомендуется разрешающие прописывать в самое начало цепочки (например, внесение в настройки Mikrotik списка IP-адресов). Соответственно, все запрещающие должны вноситься в конец цепочки.

Подобный подход оправдан – операционная система работает только с теми пакетами, которые при настройке были разрешены для приема-отправки. Это снижает нагрузку на аппаратную платформу и риски перегрузки системы за счет отказа от обработки «никому не нужной» информации. Если нет входящих соединений с нужными характеристиками, линия вообще будет свободной. Настройка RouterOS позволяет запретить даже ответ на команду PING.

Рассмотрим пример команды, которая позволяет включить реагирование на такой запрос с хостов. Запрет устанавливают только в случаях, когда есть необходимость скрыть, что на конкретном IP-адресе имеется действующее устройство. Если этого не требуется, при базовой настройке Mikrotik режим определения пинга активируют. Конечно, инструменты провайдера обычно предоставляют информацию о доступности хоста, но иногда предпочитают работать «по старинке».

Команда включения ответа на запрос PING:

add action=accept chain=input protocol=icmp

Если все-таки понадобится заблокировать режим, значение action нужно заменить на drop. Тогда маршрутизатор прекратит принимать извне и обрабатывать ICMP-пакеты. Выглядеть команда будет следующим образом:

add action=drop chain=input protocol=icmp

Рекомендуется еще отсечь пакеты, оставшиеся после ранее внесенных фильтров. Это называется дропнуть данные. Процедуру нужно назначать на самый «хвост» правил в цепочке Input, чтобы она не повлияла на разрешительные команды. Выглядит это так:

add action=drop chain=input

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

[admin@MikroTik] /ip firewall filter> print Flags: X - disabled, I - invalid, D - dynamic 0 ;;; default configuration chain=input action=accept connection-state=established,related 1 chain=input action=accept src-address-list=allowed_to_router 2 chain=input action=accept protocol=icmp 3 chain=input action=drop

На «человеческом языке» работа маршрутизатора будет организована следующим образом:

1. Извне на сетевое устройство приходит ICMP-пакет. Прибор сначала определяет, было ли соединение активно (пусть это будет правилом 0). Если хост пингуют в первый раз, то его статус будет New. Правило не применится, потому что текущее состояние не соответствует ни Established, ни Related.
2. Следующим шагом (правило 1) маршрутизатор сверяет IP-адрес обращающегося хоста со списком allowed_to_router. Если изначально перечень не был сформирован, например, нет информации, какие адреса будут у клиентов сервиса, правило не срабатывает. Оно нужно для тех случаев, когда речь идет о конкретном перечне рабочих мест с фиксированным IP-адресом.
3. Теперь о правиле 2. Если системный администратор принудительно включил реагирование на PING, маршрутизатор получит сигнал Accept (принять и обработать ICMP-пакет согласно протоколу). После обработки запроса сетевое оборудование отправляет эхо-ответ. На этом процедура реагирования завершается.

Приведем в пример еще один способ обслуживания. Например, когда на сетевое оборудование был отправлен UDP-пакет с неизвестного источника. В таком случае маршрутизатор отреагирует на обращение так:

1. Правило 0. Статус коннекта не соответствует Established и Related, поэтому оно работать не будет.
2. Правило 1. Перечень IP allowed_to_router еще не заполняли, поэтому оно тоже не сработает из-за невозможности идентификации обратившегося IP.
3. Правило 2. Как и предыдущие, оно не применяется, потому что формат не соответствует ICMP.

Все, система подошла к краю цепочки Input. Здесь пакет «поджидает» правило, предназначенное для того, чтобы дропать данные, не соответствующие установленным правилам. В нашем примере из-за отсутствия возможностей для срабатывания правила chain=input action=drop оно работает всегда. И это приводит к отказу приема UDP-пакета независимо от отправителя. Мы разобрали, что именно значит дропнуть «левые» пакеты.

Теперь, когда понятна логика работы брандмауэра в Mikrotik RouterOS, можно приступать к другим настройкам. Например, создадим перечень допустимых адресов. Поэтому перейдем в «Главное меню», выбрав символ </> и утвердив операцию кликом на Enter. Теперь через консоль Mikrotik проверим, какие списки с IP уже существуют (возможно, ранее оборудование уже настраивалось).

Команда:

[admin@MikroTik] > ip firewall address-list 
[admin@MikroTik] /ip firewall address-list> print 
Flags: X - disabled, D - dynamic 
# LIST ADDRESS CREATION-TIME TIMEOUT

Если маршрутизатор новый, список будет пустым. Теперь нужно составить перечень актуальных IP в рабочей сети. Пусть это будет диапазон 192.168.88.0/24, исключение будет составлять 192.168.88.4 (на нем «висит» маршрутизатор). Указанную подсеть Mikrotik использует «по умолчанию», чтобы раздавать IP-адреса внутри локальной сети (офисной, домашней).

Теперь добавим указанный диапазон:

add address=192.168.88.0-192.168.88.254 list=allowed_to_router

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

[admin@MikroTik] /ip firewall address-list> 
print Flags: X - disabled, D - dynamic 
# LIST ADDRESS CREATION-TIME TIMEOUT 
0 allowed_to_router 192.168.88.2-192.168.88.254 feb/05/2021 13:01:55

Если все нормально, при обработке цепочки Input на этапе отработки правила 1 система уже начнет отрабатывать входящие пакеты. При идентификации адреса отправителя как входящего в «список доверия» правило применится, и пакеты будут передаваться дальше к заданному адресату.

Разделение адресов локального сегмента и интернета

Создание перечня IP-адресов – это основополагающий принцип настройки брандмауэра Микротик. Такой подход позволяет изначально отсеять обращения с «чужих» хостов. При администрировании рекомендуется придерживаться общепринятых стандартов, чтобы внутри системы бесперебойно работали разработки любой компании, например нормы, принятые инженерным советом интернета (IETF, Internet Engineering Task Force).

Названное международное сообщество работает с конца 80-х годов и практикует развитие протоколов и архитектур, используемых внутри глобальной сети. Результаты деятельности IEFT публикуются в виде информационных документов RFC (Request for Comments). В них содержится подробное описание стандартов, спецификаций. На сегодняшний день их принято несколько тысяч (на английском языке). Нас интересует RFC6890.

В нем имеется инструкция, как разделить IP-адреса на две группы – локальный сегмент и внешний, относящийся к узлам, расположенным в интернете. Такой подход значительно повышает уровень безопасности благодаря возможности применения разных правил к внутренним и внешним хостам. Для этого понадобится сформировать два перечня адресов, позволяющих разделить их на «из интернета» и «не из интернета».

Перечень команд:

add address=0.0.0.0/8 comment=RFC6890 list=not_in_internet
add address=172.16.0.0/12 comment=RFC6890 list=not_in_internet
add address=192.168.0.0/16 comment=RFC6890 list=not_in_internet
add address=10.0.0.0/8 comment=RFC6890 list=not_in_internet
add address=169.254.0.0/16 comment=RFC6890 list=not_in_internet
add address=127.0.0.0/8 comment=RFC6890 list=not_in_internet
add address=198.18.0.0/15 comment=RFC6890 list=not_in_internet
add address=192.0.0.0/24 comment=RFC6890 list=not_in_internet
add address=192.0.2.0/24 comment=RFC6890 list=not_in_internet
add address=198.51.100.0/24 comment=RFC6890 list=not_in_internet
add address=203.0.113.0/24 comment=RFC6890 list=not_in_internet
add address=100.64.0.0/10 comment=RFC6890 list=not_in_internet
add address=240.0.0.0/4 comment=RFC6890 list=not_in_internet

Выполнить их нужно поочередно. В большинстве случаев рекомендуется внести в перечень подсеть 224.0.0.0/4. Ее резервируют для многоадресного вещания (мультикаст), подробная информация об этом поддиапазоне содержится в документе RFC2780. Второй диапазон 192.88.99.0/24 рассчитан на передачу трафика IPv6 через сети IPv4 (спецификация согласно документу RFC3068). Вносим такие изменения командой:

add address=224.0.0.0/4 comment=Multicast_RFC2780 list=not_in_internet
add address=192.88.99.0/24 comment="6to4_RFC 3068" list=not_in_internet

Теперь нужно проверить, сохранились ли внесенные изменения настроек:

[admin@MikroTik] /ip firewall address-list> print 
Flags: X - disabled, D - dynamic 
# LIST ADDRESS CREATION-TIME TIMEOUT 
0 allowed_to_router 192.168.88.2-192.168.88.254 feb/05/2021 13:01:55 
1 ;;; RFC6890 not_in_internet 0.0.0.0/8 feb/05/2021 13:43:03 
2 ;;; RFC6890 not_in_internet 172.16.0.0/12 feb/05/2021 13:43:03 
3 ;;; RFC6890 not_in_internet 192.168.0.0/16 feb/05/2021 13:43:03 
4 ;;; RFC6890 not_in_internet 10.0.0.0/8 feb/05/2021 13:43:03 
5 ;;; RFC6890 not_in_internet 169.254.0.0/16 feb/05/2021 13:43:03 
6 ;;; RFC6890 not_in_internet 127.0.0.0/8 feb/05/2021 13:43:03 
7 ;;; RFC6890 not_in_internet 198.18.0.0/15 feb/05/2021 13:43:03 
8 ;;; RFC6890 not_in_internet 192.0.0.0/24 feb/05/2021 13:43:03 
9 ;;; RFC6890 not_in_internet 192.0.2.0/24 feb/05/2021 13:43:03 
10 ;;; RFC6890 not_in_internet 198.51.100.0/24 feb/05/2021 13:43:03 
11 ;;; RFC6890 not_in_internet 203.0.113.0/24 feb/05/2021 13:43:03 
12 ;;; RFC6890 not_in_internet 100.64.0.0/10 feb/05/2021 13:43:03 
13 ;;; RFC6890 not_in_internet 240.0.0.0/4 feb/05/2021 13:43:03 
14 ;;; Multicast_RFC2780 not_in_internet 224.0.0.0/4 feb/05/2021 13:43:12 
15 ;;; 6to4_RFC3068 not_in_internet 192.88.99.0/24 feb/05/2021 13:43:12

Следующим шагом создадим аналогичные правила, рассчитанные на цепочку Forward. Шаг создаст дополнительный уровень защиты рабочих мест, подключенных к локальной сети, от посягательств извне. Для этого вернемся в раздел с правилами:

/ip firewall filter

Первое, что желательно сделать – чтобы брандмауэр не срабатывал на уже установленные коннекты (это создает бесполезную нагрузку на аппаратную платформу). Выполняется задача командой:

add action=fasttrack-connection chain=forward comment=FastTrack connection-state=established,related

Следом нужно обработать активные соединения согласно алгоритмам цепочки Forward:

add action=accept chain=forward comment="Established, Related" connection-state=established,related

Рекомендуется сразу отбросить «битые» соединения:

add action=drop chain=forward comment="Drop invalid" connection-state=invalid log=yes log-prefix=invalid

Затем желательно включить игнорирование пакетов, исходящих из локальной сети к частным IP-адресам. И активировать запись происходящего в лог-файле:

add action=drop chain=forward comment="Drop tries to reach not public addresses from LAN" dst-address-list=not_in_internet in-interface=bridge1 log=yes log-prefix=!public_from_LAN out-interface=!bridge1

Также нужно отфильтровать пакеты, приходящие не с публичных IP-адресов, и внести попытки в указанный лог:

add action=drop chain=forward comment="Drop incoming from internet which is not public IP" in-interface=ether1 log=yes log-prefix=!public src-address-list=not_in_internet

Защита от атак типа Brute Force (метод перебора)

В дополнение к фильтрации по IP-адресу желательно включить защиту от атак типа брутфорс. На сегодняшний день существует десятки тысяч ботов, систематически сканирующих сеть на предмет открытых портов Mikrotik, включая каналы SSH. Если происходит обнаружение подобного уязвимого места, бот начинает перебирать пароли с учетом популярных вариантов. Цель одна – захватить контроль над устройством и использовать его для спама.

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

Первоначально нужно создать правило брандмауэра, при выполнении которого любые входящие соединения с IP-адресов из «черного списка» (ssh_blacklist) будут сбрасываться:

add chain=input protocol=tcp dst-port=22 src-address-list=ssh_blacklist action=drop comment="Drop SSH brutforce" disabled=no

Такой подход оправдан на случай, если «внутренний» пользователь действительно ошибся более 3 раз при вводе пароля, который банально забыл за время отпуска или больничного. Чтобы отсеять случаи «человеческого фактора», вносим возможность трех ошибок с интервалов 1 минуту. Более частые попытки явно означают начало атаки методом перебора. Если такое обнаружено, IP-адрес будет помещен в «черный список» и заблокирован на 10 дней.

Чтобы автоматизировать процесс контроля, создадим три дополнительных списка IP-адресов. Один назовем ssh_stage1. В него будут попадать все новые соединения, адресованные к порту SSH. Его система удалит через 1 минуту, это гарантирует удаление адреса из списка, если соединение было осуществлено успешно.

add chain=input protocol=tcp dst-port=22 connection-state=new action=add-src-to-address-list address-list=ssh_stage1 address-list-timeout=1m comment="Stage1" disabled=no

Вторую попытку нужно фиксировать в списке ssh_stage2, это гарантированно дает понять системе, что речь идет именно о дубле:

add chain=input protocol=tcp dst-port=22 connection-state=new src-address-list=ssh_stage1 action=add-src-to-address-list address-list=ssh_stage2 address-list-timeout=1m comment="Stage2" disabled=no

При повторной ошибке IP-адрес перекидывается в список ssh_stage3. 

add chain=input protocol=tcp dst-port=22 connection-state=new src-address-list=ssh_stage2 action=add-src-to-address-list address-list=ssh_stage3 address-list-timeout=1m comment="" disabled=no

Если на третьей попытке опять зафиксирована ошибка доступа, адрес переносится в ssh_blacklist, чтобы обеспечить гарантированную блокировку на 10 дней.

add chain=input protocol=tcp dst-port=22 connection-state=new src-address-list=ssh_stage3 action=add-src-to-address-list address-list=ssh_blacklist address-list-timeout=10d comment="" disabled=no

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

Базовая настройка NAT

Рассмотрим еще один распространенный вариант настроек. Он связан с NAT или Network Address Translation, технологией трансляции сетевых адресов. Ее применяют, когда необходимо обеспечить доступ к широкополосной сети всего с одним внешним IP-адресом. Например, в офисном помещении или многоквартирном доме.

Внутри сети рабочие места или сетевое оборудование будет иметь локальные IP-адреса из подсети 192.168.XXX.XXX. Маршрутизатор точно «знает», с какого устройства поступил запрос на доступ к внешнему ресурсу и куда отправить «обратные» пакеты данных. Но при запросе извне он отклонит его, потому что нет условий, позволяющих точно определить запрашивающий компьютер внутри офисной сети.

Решение на Mikrotik есть – это Port Forwarding, или «проброс портов». Эта методика позволяет обеспечить перенаправление внешнего запроса на нужное рабочее место. На уровне логики работа выглядит так: если порт XXXX получает TCP-запрос, маршрутизатор должен задать адрес 192.168.XXX.XXX на порт YYYY, куда требуется перенаправить его. Существует 2 способа настройки NAT на Mikrotik:

Вариант 1. Выходной IP-адрес может измениться

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

ip firewall nat add chain=srcnat out-interface=ether1 action=masquerade

В этой команде ether1 – это интерфейс, видимый в интернете извне. Есть возможность составить целый перечень out_interface_list. Он подходит для офисных сетей, где используется динамический IP-адрес.

Вариант 2. Исходящий IP-адрес всегда постоянный

В другом случае, когда некоему офису выделен статический IP-адрес, понадобится команда:

ip firewall nat add chain=srcnat out-interface=ether1 action=src-nat to-addresses=XXX.XXX.XXX.XXX

Здесь XXX.XXX.XXX.XXX – это выделенный статический IP-адрес, а ether1 – выходной интерфейс, к которому предстоит сделать проброс портов. Например, возьмем сервер с IP 192.168.88.19, куда открыт удаленный доступ через порт 1122, расположенный в подсети 192.168.88.0/24. Проброс портов осуществим командой:

ip firewall nat add chain=dstnat in-interface=ether1 protocol=tcp dst-port=1122 action=dst-nat to-addresses=192.168.88.10 to-ports=22

Сразу уточним, что порт 1122 выбран специально. Нестандартные цифры сложнее атаковать извне, потому что боты чаще организуют их на стандартные порты. После применения указанных настроек маршрутизатор будет направлять TCP-пакеты, поступающие на порт 1122, на «местный» адрес 192.168.88.10 (через порт 22).

Заключение

В статье мы привели пример базовых возможностей создания основ защиты на базе RouterBoard (платформы, применяемой в устройствах Mikrotik). Предложенные команды актуальны в облачном варианте Микротика – CHR. На практике желательно изучить вопрос поглубже, чтобы закрыть все вероятные «дыры» и ограничить локальную сеть от доступа извне. И одновременно обеспечить работу необходимых портов, протоколов, поддержку нужных типов трафика.