Записки IT специалиста
Межсетевой экран, он же брандмауэр или файрвол — важнейшая служба вашего роутера, отвечающая как за его безопасность, так и за безопасность всей сети. Мы до сих пор не рассматривали базовую настройку брандмауэра в отрыве от общей настройки роутера, но как показала практика, многие администраторы откровенно плавают в этом вопросе и имеют некорректно или не оптимально настроенные системы. Как минимум это выливается в повышенную нагрузку на оборудование, а в самом плохом варианте ставит под угрозу безопасность всей сети. Поэтому давайте отдельно разберемся в этом вопросе.
Научиться настраивать 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 мы писали в нашей статье:
Если коротко, то 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
- Оборудование MikroTik класса SOHO. Общий обзор и сравнение возможностей
- Производительность младших моделей Mikrotik hEX и hAP. Экспресс-тестирование
- Базовая настройка роутера MikroTik
- Расширенная настройка DNS и DHCP в роутерах Mikrotik
- Автоматическое резервное копирование настроек Mikrotik на FTP
- Проброс портов и Hairpin NAT в роутерах Mikrotik
- Настройка IPTV в роутерах Mikrotik на примере Ростелеком
- Настройка VPN-подключения в роутерах Mikrotik
- Настройка черного и белого списков в роутерах Mikrotik
- Настройка выборочного доступа к сайтам через VPN на роутерах Mikrotik
- Настройка OpenVPN-сервера на роутерах Mikrotik
- Безопасный режим в Mikrotik или как всегда оставаться на связи
- Настройка Proxy ARP для VPN-подключений на роутерах Mikrotik
- Настраиваем Port Knocking в Mikrotik
- Резервирование каналов в Mikrotik при помощи рекурсивной маршрутизации
- Настраиваем родительский контроль на роутерах Mikrotik
- Настраиваем IKEv2 VPN-сервер на роутерах Mikrotik с аутентификацией по сертификатам
- Расширенная настройка Wi-Fi на роутерах Mikrotik. Режим точки доступа
- Mikrotik CHR — виртуальный облачный роутер
- Настройка контроллера CAPsMAN (бесшовный Wi-Fi роуминг) на Mikrotik
- Настройка VPN-подключения на роутерах Mikrotik если подсети клиента и офиса совпадают
- Настраиваем использование DNS over HTTPS (DoH) на роутерах Mikrotik
- Настройка PPTP или L2TP VPN-сервера на роутерах Mikrotik
- Установка Mikrotik CHR на виртуальную машину Proxmox
- Защита RDP от перебора паролей при помощи оборудования Mikrotik
- Настройка SSTP VPN-сервера на роутерах Mikrotik
- Настройка выборочного доступа к сайтам через VPN с автоматическим получением маршрутов по BGP на роутерах Mikrotik
- Особенности эксплуатации CA на роутерах Mikrotik: резервное копирование, экспорт и импорт сертификатов
- Настройка туннелей GRE и IPIP на роутерах Mikrotik
- Правильное использование Fast Path и FastTrack в Mikrotik
- DHCP Snooping — настройка защиты от неавторизованных DHCP-серверов на оборудовании Mikrotik
- Работа оборудования Mikrotik в режиме беспроводной станции (клиента)
- Используем режим ARP reply-only для повышения безопасности сети на оборудовании Mikrotik
The Dude
- The Dude. Установка и быстрое начало работы
- Централизованное управление обновлением RouterOS при помощи The Dude
- Централизованный сбор логов Mikrotik на сервер The Dude
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал:
Drop all not coming from lan что это
Sun Sep 23, 2018 5:08 am
Hi! I had to disable «defconf: drop all not coming from LAN» otherwise my local CAPs Manager would not work. Am I missing something? I actually don’t quite understand the need for this rule. Isn’t it best hinged on WAN?
/ip firewall filter add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp add action=drop chain=input comment="defconf: drop all not coming from LAN" disabled=yes in-interface-list=!LAN add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN add action=accept chain=input comment="default configuration" protocol=icmp add action=accept chain=input comment="default configuration" connection-state=established,related add action=drop chain=input comment="default configuration" in-interface=unifi add action=fasttrack-connection chain=forward comment="default configuration" connection-state=established,related add action=drop chain=forward comment="default configuration" connection-nat-state=!dstnat connection-state=new in-interface=unifi add action=accept chain=forward comment="default configuration" connection-state=established,related add action=drop chain=forward comment="default configuration" connection-state=invalid /ip firewall nat add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN add action=masquerade chain=srcnat comment="default configuration" out-interface=unifihttps://wiki.mikrotik.com/wiki/Manual:I . all/Filter didn’t really help me (search for «drop all not coming»). You would expect to see some mapping to the RouterOS’s defconf wouldn’t you? Be nice if there was a function to double check WAN input is sane. I’ve had a compromise before when I accidentally allowed access to a default admin/nopasswd routerboard.
Trainer
Posts: 1777 Joined: Tue Jul 19, 2016 6:45 pm Location: Vancouver, BC, Canada
Re: defconf: drop all not coming from LAN really needed?
Sun Sep 23, 2018 5:59 am
I actually don’t quite understand the need for this rule. Isn’t it best hinged on WAN?
Great question! Yes, it is theoretically best hinged on WAN instead of not-LAN — *however* — the main reason this was not done is that many RouterOS novices who configure PPPoE (very commonly needed as a method to connect to the Internet, accomplished by adding a new PPPoE client interface) are completely unaware that they also need to manually add their PPPoE interface to the «WAN» interface list to secure their router properly. If they failed to add the PPPoE interface to the WAN interface list, and the rule that you refer to was blocking admin login from WAN instead of not-LAN, then hackers on the Internet would easily be able to get into their router if it had a weak password or a security vulnerability. By using not-LAN instead of WAN as the matching criteria for this rule, MikroTik ensures that, even if the user doesn’t know (or forgets) to add the pppoe-out1 interface to the «WAN» interface list, their router will not be wide open for hackers to take control of.
Don’t disable the rule, otherwise you are allowing login to your device from any IP anywhere for admin purposes (unless of course this device is completely protected by a firewall on a different device, in which case you don’t really need any firewall rules). Either reconfigure the rule for WAN instead of not-LAN (and if you have a PPPoE interface, make sure that you add it to the «WAN» interface list), *or* add whatever interface your CAPSMAN/CAPS communication takes place on to the «LAN» interface list, in which case it will not be blocked.
(BTW, as an aside I am sorry for your bad experience on the unofficial MikroTik IRC chat room. Not all advanced users have equal patience with novices. I frequent the IRC chat that you visited before and youtube’d about, but was not around when you were trying to figure things out.)
Firewall в Mikrotik
У микротик нет понятия внешней и внутренней сети. В нем есть различные интерфейсы, и мы можем строить правила сетевой безопасности относительно этих интерфейсов.
Относительно входящих (in interface) и исходящих (out interface) интерфейсов.
Всё это находится в разделе IP — Firewall – Filter, на что мы сейчас и посмотрим.
Если мы берем SOHO (small office home office) устройство, которое предназначено для домашнего использования, то в его конфигурации по умолчанию мы увидим стандартный Firewall. Он защищает нашу сеть достаточно хорошо от внешних угроз при условии, что у нас есть внешняя сеть. Также мы можем посмотреть на наш стандартный Firewall, выполнив команду (В левой колонке необходимо нажать «New Terminal»):
/system default-configuration print И здесь мы можем посмотреть наш стандартный Firewall.
/ip firewall
Если вы по какой-то причине удалите эти правила из раздела IP Firewall, то вы можете вернуться к ним в любой момент выполнив команду:
/system default-configuration printСкопировав необходимый блок в вашу текущую конфигурацию. Либо же скопировав из приведенного выше кода.
Также хотелось бы сказать, что Firewall по умолчанию в микротике является Stateful Firewall, то есть фаерволом с полным отслеживанием состояния соединений.
Это значит, что нам не понадобиться писать правила одновременно для входящих и исходящих пакетов. Нам достаточно будет одного разрешающего правила и правило, учитывающего состояние пакетов.
На этом базовый осмотр Firewall в Mikrotik закончен. В следующих видео мы продолжим работу с Firewall.
Настройка Firewall в Mikrotik
В базовой конфигурации роутера Mikrotik по умолчанию присутствуют стандартные правила для брандмауэра. Рядовому пользователю зачастую хватает этих правил для работы в интернете. В этом случае никаких дополнительных настроек не надо. Но если вы решите изменить правила или добавить новые, читайте нашу статью.
Базовые правила Firewall
Для начала перечислим стандартные правила, которые есть в роутере по умолчанию. Вы можете экспортировать правила Firewall в Mikrotik с помощью команды:
>> ip firewall export file=rules
Итак, базовые правила:
/ip firewall filter add action=accept chain=input comment=»defconf: accept established,related,untracked» connection-state=established,related,untracked
add action=drop chain=input comment=»defconf: drop invalid» connection-state=invalid
add action=accept chain=input comment=»defconf: accept ICMP» protocol=icmp
add action=drop chain=input comment=»defconf: drop all not coming from LAN» in-interface-list=!LAN
add action=accept chain=forward comment=»defconf: accept in ipsec policy» ipsec-policy=in,ipsec
add action=accept chain=forward comment=»defconf: accept out ipsec policy» ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment=»defconf: fasttrack» connection-state=established,related
add action=accept chain=forward comment=»defconf: accept established,related, untracked» connection-state=established,related,untracked
add action=drop chain=forward comment=»defconf: drop invalid» connection-state=invalid
add action=drop chain=forward comment=»defconf: drop all from WAN not DSTNATed» connection-nat-state=!dstnat connection-state=new in-interface-list=WAN /ip firewall nat
add action=masquerade chain=srcnat comment=»defconf: masquerade» ipsec-policy=out,none out-interface-list=WAN
Что делают эти команды? Отключают входящие и транзитные соединения не из локальной сети, разрешают протокол icmp, ipsec, разрешают установленные соединения.
Базовая настройка безопасности
Межсетевой экран даёт возможность регулировать доступ к шлюзу и ресурсам, расположенным за ним. Прежде, чем переходить к настройкам, определитесь, действительно ли это нужно и для чего вы это делаете.
Станьте нашим партнёром и получайте доход
до 40% от каждого клиентаСтать партнёром
Safe Mode
Данную опцию у Mikrotik можно использовать, чтобы дистанционно и при этом безопасно настроить Firewall. Чтобы сделать это, нажмите соответствующую кнопку.
После выполнения настроек, вручную отключите опцию нажатием той же кнопки. Если вы завершите работу в этом режиме некорректно, настройки не сохранятся. Имейте это в виду, если прервётся соединение – настройки придётся выполнять заново.
Как располагать правила в Firewall
Передаваемые по сети пакеты двигаются по цепочке правил в направлении сверху вниз. Если текущий пакет подпадает под какое-либо правило, он останавливается на этом этапе и не будет двигаться дальше. По этой причине в первую очередь стоит прописывать правила, которые касаются как можно большего объёма трафика. Это позволит снизить нагрузку на устройство. Например, одним из первых правил можно разрешить пакеты уже установленных или связанных соединений, ранее разрешённых другим правилом. Заново прогонять такие данные через все правила не требуется.
Цепочки правил в Mikrotik:
1. Input – пакеты, которые были отправлены на роутер.
2. Forward –пакеты, которые проходят через маршрутизатор.
3. Output — пакеты, посланные с маршрутизатора.
Готовые правила для настройки
Для начала есть смысл отбросить все недействительные (Invalid) пакеты. Это полностью мусорные данные, которые только создают лишнюю нагрузку.
add action=drop chain=input comment=»drop invalid» connection-state=invalid
Теперь делаем разрешение для icmp трафика, это позволит пинговать роутер
add action=accept chain=input comment=»accept ICMP» protocol=icmp
Если, наоборот, требуется этот трафик заблокировать, в action=accept впишите drop.
Последним правилом в цепи input будет блокировка все запросов, которые поступают не из локальной сети.
add action=drop chain=input comment=»drop all not from lan» in-interface=!bridge1-lan
Теперь перейдём к настройке для цепочки Forward.
add action=accept chain=forward comment=»accept established,related» connection-state=established,related add action=drop chain=forward comment=»drop invalid» connection-state=invalid
Следующим шагом запретим пакеты, поступающие из внешней сети через интерфейс ether1-wan.
add action=drop chain=forward comment=»drop all from WAN to LAN» connection-nat-state=!dstnat connection-state=new in-interface=ether1-wan
Если вы настраиваете Mikrotik с нуля, то у вас не будет выхода во внешнюю сеть. Чтобы его получить, следует настроить NAT.
Настройка NAT
Перейдите в раздел IP и далее в Firewall. Там находится нужная нам вкладка NAT. Добавьте следующее правило:
/ip firewall nat
add action=src-nat chain=srcnat out-interface=ether1-wan to-addresses=[Ввести IP адрес]
Это для случая, если IP постоянный. Если он динамический, тогда используем masquerade:
add action=masquerade chain=srcnat out-interface=ether1-wan
Проброс портов
Чтобы сделать проброс порта rdp через Mikrotik:
add action=dst-nat chain=dstnat dst-port=[Номер порта] in-interface=ether1-wan protocol=tcp to-addresses=[IP адрес] to-ports=[Номер порта]
Не стоит делать доступ к rdp открытым для всей внешней сети. По возможности настройте ограничение доступа по ip. Если этого нельзя сделать, используйте доступ по vpn.
Чтобы отключить файрвол, нужно просто убрать все правила, присутствующие в списке. Это будет означать, что файрвол пропустит все пакеты.
В статье описаны более общие правила. Вы можете добавлять свои, используя ту же логику.