Системное администрирование статьи, руководства, инструкции по установке, настройке и администрированию информационных систем 
Сегодня хочу поподробнее раскрыть тему защиты роутеров популярной латвийской марки. Речь пойдет о базовой настройке Firewall в Mikrotik для обеспечения безопасности и удобства. Статья на эту тему была написана уже давно, но я решил ее полностью переделать и актуализировать.
Содержание:
Данная статья является частью единого цикла статьей про Mikrotik.
Введение
Долгое время у меня была опубликована статья про простую настройку файрвола на микротик. Там были перечислены базовые правила для ограничения доступа к роутеру, и тем не менее, статья собрала более 200 тыс. просмотров.
Некоторое время назад я обновил и актуализировал статью про базовую настройку mikrotik. В комментариях многие люди пеняли мне на то, что я совсем не уделил внимание настройке фаервола. Мне не захотелось мешать все в кучу, поэтому я пишу отдельную подробную статью на эту тему, а в настройке роутера оставлю ссылку на нее.
Итак, будем считать, что вы уже настроили роутер примерно так же, как я описал в своей статье. Есть локальная сеть, которая будет выходить в интернет через микротик. И есть сам микротик, который хочется защитить, ограничив доступ для всего лишнего, разрешив только то, что нам нужно.
| 192.168.88.1 | локальный адрес микротика |
| bridge | название бриджа, в который объединены все интерфейсы для локальной сети |
| ether1 | интерфейс для внешнего подключения WAN |
| 192.168.88.0/24 | локальная сеть, которую обслуживает микротик |
Default firewall в Mikrotik
Если вы используете дефолтную конфигурацию роутера, то она по-умолчанию имеет стандартные правила firewall. Привожу список стандартных правил (rules) с комментариями. Напоминаю, что экспорт правил 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, разрешены установленные соединения. Все. Ну и настроен NAT через WAN интерфейс.
Во многих случаях данных правил по-умолчанию может быть достаточно обычному пользователю, который просто настроил маршрутизатор дома для выхода в интернет. Берите на вооружение, если вам от маршрутизатора больше ничего не надо.
Firewall и базовая настройка безопасности
Давайте теперь немного порассуждаем, зачем нужен файрвол и какие вопросы он решает. Причем не только в контексте микротика, а вообще. Сейчас каждый доморощенный админ рассказывает, как важно всегда настраивать firewall, иногда даже не понимая, для чего он нужен. Лично я не сторонник создания лишних сущностей, поэтому там где межсетевой экран не нужен, я его не настраиваю.
Сетевой экран позволяет настраивать доступ как к самому шлюзу, так и к ресурсам за ним. Допустим, у вас не запущено никаких сервисов на роутере, и нет никакого доступа извне в локальную сеть. У вас есть какая-то служба на шлюзе, с помощью которой к нему подключаются и управляют (ssh, winbox, http и т.д.), причем ограничение доступа к этой службе настраивать не планируется. Вопрос — зачем вам в таком случае настраивать фаервол? Что он будет ограничивать и какие правила туда писать? В таком случае вам будет достаточно отключить все сервисы на роутере, которые слушают подключения из вне и все.
На самом деле такой кейс очень популярный дома или в мелких организациях, где нет постоянного админа. Просто настроен какой-то роутер, поднят NAT и все. Я понимаю, что не правильно не настраивать ограничения на доступ к управлению, но я рассказываю, как часто бывает. То есть firewall должен решать конкретную задачу по ограничению доступа к ресурсам, а не существовать просто так, чтобы был.
Еще популярны случаи, когда настроена куча правил, а в конце все равно стоит accept для всех подключений. Такие ляпы я сам иногда делал, когда отлаживал где-то работу сервиса и забывал потом вернуть обратно ограничения. Фаервол вроде настроен, но реально его нет. Если отключить — ничего не изменится.
К чему я все это написал? К тому, что прежде чем настраивать firewall, надо определиться с тем, для чего мы это делаем. Какие разрешения или ограничения и для кого мы будем вводить. После этого можно переходить к настройке.
Я рекомендую первым правилом при любой настройке firewall ставить разрешение на подключение к управлению устройством. Этим вы подстрахуете себя, если где-то дальше ошибетесь и заблокируете доступ к устройству в одном из правил.
Идем в раздел IP -> Firewall. Первая вкладка Filter Rules то, что нам надо. Если делаете настройку firewall с нуля, то там должно быть пусто. Добавляем новое правило.
По идее, надо еще заглянуть во вкладку action, но в данном случае не обязательно, так как там по-умолчанию и так выставляется нужное нам значение accept.
Дальше разрешаем уже установленные и связанные входящие соединения. Для этого создаем следующее правило.
Не забывайте писать комментарии для всех правил. Так вам проще самим будет. Через пол года уже позабудете сами, что настраивали и зачем. Не говоря уже о том, что кто-то другой будет разбираться в ваших правилах.
Теперь сделаем запрещающее правило, которое будет блокировать все входящие соединения через WAN интерфейс. В моем случае ether1.
Данными правилами мы заблокировали все входящие соединения из интернета и оставили доступ из локальной сети. Далее создадим минимальный набор правил для транзитных соединений из цепочки forward.
Первым правилом в фаерволе микротик для транзитного трафика будет правило с использованием фирменной технологии Fasttrack. Подробно о том, что это такое читайте в официальной wiki по ссылке. Если кратко, то данная технология экономит ресурсы процессора, за счет упрощенной обработки пакетов, к которым не надо применять дополнительных правил фаервола, ставить его в очереди и т.д. Это подойдет для большинства пользователей, у которых микротик это просто шлюз в интернет с небольшим набором простых правил в firewall. При этом транзитный трафик никак дополнительно не обрабатывается и не фильтруется.
Возьмем примеры этих правил из дефолтной конфигурации файрвола. Добавляем 2 новых правил для цепочки forward. В первом action выбираем fasttrack connection, во втором accept для established и related подключений.
Дальше по примеру дефолтной конфигурации, запретим и все invalid подключения.
В завершении запретим все подключения из WAN в LAN.
Подведем краткий итог того, что получилось. Вот самый простой, минимальный набор правил firewall в mikrotik для базового случая:
Запрещены все входящие подключения, в том числе ответы на пинги. Включена технология fasttrack для соединений из локальной сети. При этом из локальной сети разрешены абсолютно все подключения, без ограничений. То есть это пример типовой безопасной конфигурации для микротик в роли обычного шлюза в интернет для небольшого офиса или дома.
Но если firewall оставить как есть в таком виде, то раздачи интернета для локальной сети не будет. Для этого надо настроить NAT. Это сделать не сложно, рассказываю как.
Настройка NAT в микротик
Для того, чтобы пользователи локальной сети, которую обслуживает роутер на микротике, смогли получить доступ в интернет, настроим на mikrotik NAT. Для этого идем в раздел IP -> Firewall, вкладка NAT и добавляем простое правило.
Действие указываем masquerade.
Все, NAT настроен, пользователи могут выходить в интернет.
Проброс портов
Покажу на простом примере, как при настроенном NAT и включенном фаерволе выполнить проброс порта в mikrotik для доступа к службе в локальной сети. Пробросить порт можно в той же вкладке NAT в настройках Firewall.
Для примера выполним проброс порта rdp из интернета через микротик. Извне будет открыт порт 41221, а проброс будет идти на локальный адрес 192.168.88.10 и порт 3389.
Я настоятельно не рекомендую открывать доступ к rdp порту для всего интернета. Лично имел печальный опыт в такой ситуации. Обязательно настройте ограничение доступа по ip к этому порту, если такое возможно. Если невозможно, то не пробрасывайте порт, а сделайте доступ по vpn. Ограничение по ip делается просто. Добавляем еще один параметр в правило проброса порта.
Если используется список ip адресов, который будет меняться, проще сразу в правиле проброса указать на список, а потом править уже сам список. Для этого его надо создать. Создать список ip можно на вкладке Address List. Добавим список:
Возвращаемся в правило проброса порта, переходим на вкладку Advanced и добавляем указанный список в Src. Adress List
Теперь для изменения списка доступа к проброшенному порту не надо трогать само правило. Достаточно отредактировать список.
Помимо настройки непосредственно проброса, надо разрешить трафик цепочки forward с WAN интерфейса к адресу в локальной сети, куда пробрасываем соединение. В разрешающем правиле надо указать конечный порт 3389. Вот как это выглядит.
На вкладке action просто указываем accept. После этого можно проверять работу проброшенного порта. Все должно быть в порядке.
Защита подключения через winbox
Расскажу отдельно о том, как защитить подключение по winbox с помощью firewall. В микротиках время от времени находят критические уязвимости. Единственным способом надежно от них защититься — ограничить доступ к winbox с помощью фаервола.
В приведенном выше списке правил для фаервола заблокированы все внешние подключения полностью. Это самый безопасный вариант настроек. Иногда нужен доступ к удаленному управлению. Самое безопасное в этом случае настроить vpn сервер на микротике и подключаться через vpn. Не всегда это уместно. Ограничение доступа по ip, если такое подходит, будет не менее безопасно.
Для начала создадим список IP, которым будет разрешено подключаться удаленно к winbox.
Добавляем правило в Firewall. Оно должно быть выше правила, где блокируются все входящие соединения.
В вкладке Advanced указываем список:
В разделе action ставим accept. Итоговый список правил должен быть таким.
Так мы обезопасили удаленный доступ через winbox. Считаю это самым простым и безопасным способом защиты микротика. Если есть возможность органичений по ip, всегда используйте. Это универсальный способ, годный для любого случая и системы, не только в отношении микротика.
В современном мире ИТ постоянно находят уязвимости. Невозможно всегда оперативно ставить обновления. Зачастую, эти обновления могут либо нарушить работу системы, либо содержать другие уязвимости. Только ограничение доступа к службам и системам позволяет более ли менее надежно защититься и спать спокойно, не торопясь обновляться со всех ног при обнаружении очередной критической уязвмости.
Как на микротике отключить файрвол
Для того, чтобы полностью отключить Firewall на микротике, достаточно просто отключить или удалить все правила в списке. По-умолчанию, в mikrotik используются разрешающие правила. Все, что не запрещено — разрешено. То есть если у вас нет ни одного активного правила, можно считать, что файрвол отключен, так как он пропускает все соединения без ограничений.
Вот пример отключенного фаервола на микротике :)
Итоговый список правил, настроенный по этой статье, получился вот такой:
/ip firewall address-list add address=77.88.0.81 list=rdp_access add address=77.88.8.8 list=rdp_access add address=8.8.8.8 list=rdp_access add address=1.1.1.1 list=winbox_remote add address=2.2.2.2 list=winbox_remote /ip firewall filter add action=accept chain=input comment="local accept" in-interface=bridge add action=accept chain=input comment="established and related accept" connection-state=established,related add action=accept chain=input comment=winbox_accept dst-port=8291 in-interface=ether1 protocol=tcp src-address-list=winbox_remote add action=drop chain=input comment="all input block" in-interface=ether1 add action=fasttrack-connection chain=forward comment=fasttrack connection-state=established,related add action=accept chain=forward comment="established and related accept" connection-state=established,related add action=drop chain=forward comment="drop invalid" connection-state=invalid add action=drop chain=forward comment="drop WAN -> LAN" in-interface=ether1 out-interface=bridge /ip firewall nat add action=masquerade chain=srcnat out-interface=ether1 add action=dst-nat chain=dstnat dst-port=41221 in-interface=ether1 protocol=tcp src-address-list=rdp_access to-addresses=192.168.88.10 to-ports=3389
Заключение
На этом все по базовой настройке firewall на mikrotik. Постарался показать максимально подробно базовый набор правил фаервола для обеспечения безопасности и защиты локальной сети и самого роутера.
Мой список правил не сильно отличается от дефолтного. Привел его последовательно по правилу, чтобы просто объяснить логику, как нужно рассуждать и действовать при добавлении правил. В качестве самостоятельной работы предлагаю добавить правило, разрешающее отвечать на пинги. Если самостоятельно не получилось сделать, напишите в комментарии, я приведу рабочий пример.
Тема эта обширная, наверняка у кого-то есть замечания и свои советы по предложенной настройке. Тут нет универсальных правил. Firewall в микротике основан на линуксовых iptalbes, а это безграничное поле для творчества :)
Напоминаю, что данная статья является частью единого цикла статьей про Mikrotik.
Онлайн курсы по Mikrotik
Если у вас есть желание научиться работать с роутерами микротик и стать специалистом в этой области, рекомендую пройти курсы по программе, основанной на информации из официального курса MikroTik Certified Network Associate. Помимо официальной программы, в курсах будут лабораторные работы, в которых вы на практике сможете проверить и закрепить полученные знания. Все подробности на сайте . Стоимость обучения весьма демократична, хорошая возможность получить новые знания в актуальной на сегодняшний день предметной области. Особенности курсов:- Знания, ориентированные на практику;
- Реальные ситуации и задачи;
- Лучшее из международных программ.
В самом начале статьи нужно описать зачем нужна кнопка «safe mode». Это критически важная информация! Вот прям закриншотить и написать «пред настройкой нажмите эту кнопку!». Из десятка мануалов в инете я только в одном встретил описание этой кнопки.
Спасибо за труд! Возник вопрос: что делает 6 правило? сразу за фасттрек. Если мне фасттрек не нужен и форварда нет — нужно ли 6? Спасибо.
Это правило автоматом пропускает все установленные соединения цепочки forward. Чтобы они установились, они и так уже прошли по всем правилам, так что гонять их еще раз нет смысла. Проще их сразу разрешать отдельным правилом. Если у вас forward трафика нет, правило не нужно. Но скорее всего этот трафик у вас есть. Без него особо нет смысла и в самом микротике.
добрый день. Я правильно понимаю, что правило фаервола «В завершении запретим все подключения из WAN в LAN» в итоге блокирует проброс портов и wan в bridge тоже? У меня так и произошло.
Да, все верно. Для проброса надо отдельные правила с forward делать, открывая только то, что нужно.
Доброго времени суток. В статье описано, как разрешить доступ по апи. Скажите пожалуйста люди знающие есть ли возможность разрешить доступ к микрону или в сеть по маку, чтобы я, допустим, мог зайти на микрот с телефона с динамическим апи, указав мак телефона?
Нужно понимать, что микротик увидит ваш мак, только если у него есть такая возможность. Вы должны напрямую подключаться к нему, минуя другие свитчи и роутеры. А вообще, вопрос интересный. У меня никогда не было такой задачи, так что не знаю, можно ли это сделать. Если разберетесь в вопросе, поделитесь информацией.
Я в этом вообще чайник.
Из информации с других источников и от Вас понял, что микрот видит мак устройств только в ЛС, а значит мне такой вариант не подходит.
Если не брать в расчет фильтрацию по маку, как тогда, имея «белый» апи, сделать так, чтобы микрот фильтровал всех, кроме конкретного устройства учитывая тот факт, что устройство будет пытаться подключиться к роутеру с динамического апи?
Никак без посторонних средств. Через интернет вы никак не ограничите доступ, кроме ip адреса. Можно купить vpn со статическим ip, настроить его на телефоне и подключаться к микротику через vpn. А на самом микротике настроить доступ только с этого ip.
Есть еще возможность динамически открывать доступ к какому-то ip при пинге пакетами определенного размера. Забыл, как это средство называется. Вы ставите размер пакета определенного размера, пингуете им сервер. Он видит этот пакет и открывает на время доступ с ip, с которого идут пинги.
разрешить доступ к микрону или в сеть по маку — мне как то казалось что маки на 2 уровне модели, а она ограничивается шлюзами. и исходя из этого либо подключение к единому широковещательному домену либо же будут использоваться ИП адреса (TCP\IP). если исключить «магию» с бриджеванием туннелей, но по сути те же яйца..
а про диаграмму есть, как мне кажется, более понятные — https://www.qtraining.ru/trainings_files/docs/MikroTik_PacketFlow_Routing24.jpg
А зачем разрешать в первом правиле локальный трафик, если мы его нигде не запрещаем?
Думаю стандартные правила фейрвол Микротик оптимальнее, так-как они сначала обрабатывают самый распространенный трафик (forward), а потом отсеивают весь остальной. Но стандартные правила не запрещают транзитный (forward) трафик из WAN в LAN, поэтому это правило нужно дописать вручную.
В итоге набор должен быть таким: https://imgur.com/a/60TkmWO
add action=fasttrack-connection chain=forward connection-state=established,related
add action=accept chain=forward connection-state=established,related
add action=accept chain=forward dst-address=192.168.1.100 dst-port=21 in-interface-list=WAN protocol=tcp
add action=accept chain=forward dst-address=192.168.1.100 dst-port=55536-55836 in-interface-list=WAN protocol=tcp
add action=drop chain=forward connection-state=invalid
add action=drop chain=forward connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
add action=drop chain=forward in-interface-list=!LAN
add action=accept chain=input connection-state=established
add action=accept chain=input connection-state=related
add action=drop chain=input in-interface-list=!LAN
Напишите пожалуста правило разрешающее отвечать на пинги
День добрый!
Купил в контору RB1100AHx4, это мой первый Mikrotik. Мне поставили задачу: 7 внешних ip одного провайдера (один шлюз на все ip адреса и все они висят на одном интерфейсе, ether1) должны раздавать интернет строго в свой vlan. Все перегуглил, понятного мне ничего не нашел. С одним ip нет никаких проблем, быстро разобрался и пошла раздача интернета пользователям по vlan2, а вот как дальше с остальными ip да другие vlan2… ((( Если что-то и попадается близкое к моей теме, то только на скриптах, но в них я вообще полный ноль.
Ладно, даже если каждый внешний ip будет на отдельном интерфейсе, ether2, ether3 и т.д. — то как заставить их раздавать инет строго в свой vlan? То есть, vlan2 должен получать интернет только из 178.12.34.45! Так же и остальные vlan
Подскажите на пальцах, если это возможно, в графическом интерфейсе, как это можно реализовать. Если нельзя, то хотя бы какую-нибудь альтернативу.
Заранее благодарен!
Если совсем не разбираетесь в сетях, то можно поступить проще. Провод от провайдера воткните в свитч, из этого свитча по одному проводу в отдельные порты Микротика. А дальше уже настраивайте спокойно vlan’ы каждый на своем интерфейсе. Вполне рабочий и удобный вариант. Я делал так в свое время, когда была похожая задача. Я тоже не сообразил, как развести по разным ip сети, при условии, что все ip адреса приходят по одному проводу в один интерфейс. Если все же решите изначальную задачу без свитча, то поделитесь решением.
Вот и в этом у меня проблема: как спокойно?
Ведь надо не только по vlan раскидать интернет, но и чтобы у vlan2 был один ip, vlan3 другой и так далее
внешний ip
Один внешний ip адрес я раскидал спокойно на все vlan. Если с каждого vlan зайти на ip.ru — у всех будет один и тот же ip адрес. А надо, чтобы у каждого был свой (((
Кажется, что надо добавить в Routes list второй внешний ip — толку нет, он висит неактивным. Работает первый добавленный ip. Кого первым внешним завёл — того и тапочки?
Решение оказалось на радость очень простым и удобным:
add action=src-nat chain=srcnat out-interface=ether1 src-address=192.168.10.0/24 to-addresses=154.66.43.4
add action=src-nat chain=srcnat out-interface=ether1 src-address=192.168.20.0/24 to-addresses=154.66.43.6
add action=src-nat chain=srcnat out-interface=ether1 src-address=192.168.50.0/24 to-addresses=154.66.43.8
И не надо отдельной настройки маршрутизации в Route! Никаких заморочек с маркировкой в Mangle!
Подсказал это мне гуру в Микротике, администратор Илья Князев с сайта spw.ru
Спасибо, что поделились. Я не знал, что можно так просто сделать через настройки src-nat. Думал, как раз нужно как-то маркировать пакеты.
в каком именно месте firewall из статьи нужно правильно разместить правила блокировки по доменному адресу из примера https://serveradmin.ru/blokirovka-
sayta-v-mikrotik/ , или есть другой способ. …мне нужно запретить 8 доменных и 4 ип адреса чтобы не упдатился SMASUNG TV
Перед разрешающими правилами forward для доступа из локалки в интернет. Они могут быть разными, но смысл в том, что перед разрешающим правилом ставим выше запрещающие для отдельных адресов.
Прошу прощения, но разве при настройке проброса портов, помимо правила в NAT не надо добавлять соответствующее разрешающее правило в firewall?
У меня без него не заработало. Более того, rdp не заработал при наличии правила input, как было написано в одной статье, а только когда указал forward.
(да, само собой, что открывать rdp наружу это моветон, даже через другой внешний порт, и я всегда сам работаю через vpn, но понадобилось иногда открывать на короткое время именно rdp)
Все правильно, разрешающее правило forward, где входящий интерфейс WAN, а Dst. Address — внутренний адрес сервиса в локалке, куда прокидывается порт, должно быть, чтобы заработал проброс. Я упустил этот момент. Цепочка input тут ни при чем.
Добрый день. Спасибо за написание данной статьи. Я новичок, прочитав вашу статью я сделал вот такие исправления в своем firewall. Правильно ли я сделал, последовательность правильная?
/ip firewall filter
add action=drop chain=input comment=»Drop access to DNS from WAN-list-WANs» \
dst-port=53 in-interface-list=WANs protocol=tcp
add action=drop chain=input comment=list-WANs dst-port=53 in-interface-list=\
WANs protocol=udp
add action=accept chain=input comment=»Allow PING (ICMP)» protocol=icmp
add action=accept chain=input in-interface-list=BRIDGEs
add action=accept chain=input comment=»defconf: accept established,related» \
connection-state=established,related
add action=drop chain=input comment=»defconf: drop all from WAN-list-WANs» \
in-interface-list=WANs
add action=fasttrack-connection chain=forward comment=»defconf: fasttrack» \
connection-state=established,related routing-mark=main
add action=accept chain=forward comment=»defconf: accept established,related» \
connection-state=established,related
add action=drop chain=forward comment=»defconf: drop invalid» \
connection-state=invalid
add action=drop chain=forward comment=»drop WAN->LAN» in-interface-list=WANs \
out-interface-list=BRIDGEs
add action=drop chain=forward comment=\
«defconf: drop all from WAN not DSTNATed-list-WANs» \
connection-nat-state=!dstnat connection-state=new in-interface-list=WANs
Добрый день. Возьмите себе на заметку одно важное правило: сначала accept, затем только drop. вот небольшой пример:
/ip firewall filter
add action=drop chain=input connection-state=invalid in-interface-list=ISP
add action=accept chain=input connection-state=established,related,untracked in-interface-list=ISP
add action=accept chain=input in-interface-list=ISP protocol=icmp
add action=accept chain=input connection-nat-state=dstnat dst-port=22 in-interface-list=ISP protocol=tcp
add action=accept chain=input dst-port=8291 in-interface-list=ISP protocol=tcp
add action=accept chain=input dst-port=1723 in-interface-list=ISP protocol=tcp
add action=drop chain=input in-interface-list=ISP
Всего 8 правил, нечего лишнего нет.
Как можно оптимизировать настройки фильтра, для уменьшения нагрузки на процессор?
Конечное бросается в глаза первое правило которое отбрасывает invalid пакеты, но ведь такого трафика единицы, и уж точно меньше чем пакетов в установленных соединениях.
Необходимо поменять местами первое и второе правило, тем самым под самое первое правило будет попадать абсолютное большинство пакетов, и под следующие правила пакеты естественно не попадут так как accept правила терминирующее, 99% всего трафика на маршрутизаторе это established.
Просто представьте себе такую ситуацию, к вам на маршрутизатор приходит 2000PPS и 99% данных пакетов, это пакеты которые принадлежат уже установленным соединениям. Если оставить как есть, то маршрутизатор в секунду будет проверять 2000 пакетов и сработает только 20 раз (1%), далее 1980 пакетов попадут во второе правило и только после это трафик попадёт в сокет на маршрутизатора. В итоге 3980 операций сравнения в секунду.
Если же поменять правила местами, то в первое правило попадёт 1980 пакетов и сразу будет отправлен в сокет маршрутизатора, и во второе отправиться уже только 20 пакетов (1%) В итоге 2020 операций сравнения в секунду.
/ip firewall filter
add action=accept chain=input connection-state=established,related,untracked in-interface-list=ISP
add action=drop chain=input connection-state=invalid in-interface-list=ISP
add action=accept chain=input in-interface-list=ISP protocol=icmp
add action=accept chain=input connection-nat-state=dstnat dst-port=22 in-interface-list=ISP protocol=tcp
add action=accept chain=input dst-port=8291 in-interface-list=ISP protocol=tcp
add action=accept chain=input dst-port=1723 in-interface-list=ISP protocol=tcp
add action=drop chain=input in-interface-list=ISP
Экономия существенная.
Друг, жму руку. Очень крутое и понятное объяснение. В голове отложилось сказанное. Обычно, когда ваяешь правила, не всегда обращаешь внимание на нюансы, где какое должно быть. Но различия принципиальные.
К вопросу о дальних поездках — выручить может режим safe mode. В случае обрыва соединения внесённые изменения будут отменены. Подобная опция есть ещё в Cisco и вероятно других сетевых устройствах.
Защитить rdp и другие службы можно настройкой некого подобия защиты от перебора или port-knocking.
Спасибо за дополнение. Уже когда написал статью, подумал, что зря не написал про safe mode. Изначально забыл про него и не внес в план статьи. Потом уже не стал переделывать. Надо отдельным пунктом описать этот механизм.
Спасибо за pdf статью, теперь ее можно почитать на досуге с планшета!
Прекратите использовать netmap для проброса портов! Это трансляция сеть-в-сеть, она нужна для другого и в конфигурации с пробросом только увеличивает нагрузку на CPU.
И вообще статья очень слабая, на новогодних выходных на хабре был хороший разбор этой темы, включая правильное использование netmap, кому интересно найдете сами.
P.S. А блин, чего я парюсь тут 2 рекламных ссылки все понятно с автором.
Могли бы и привести ссылку на статью. Я не поленился, поискал. Вот она — https://habr.com/ru/post/435070/
Я ее не читал, но сейчас посмотрел. Статья действительно очень полезная. Набор базовых правил для обычной локалки почти такой же как у меня, только по-умолчанию весь forward трафик блокируется, который не разрешен явно, но при этом вся локалка все равно разрешена. То есть по сути рекомендации те же самые.
Про netmap я понял. Меня в свое время ввела в заблуждение другая статья, где упоминался netmap, я ее тоже нашел — https://habr.com/ru/post/182166/ Прочитал много лет назад и отложилось. Я поправлю статью.
Есть оффициальный вики микротика, советую использовать только её, при всём уважении к хабру. Также, пожалуйста, дополните, что для отключения фаервола правила можно задизейблить, а не удалять. При дизейбле конфиг с правилами сохранится, но правила будут отключены, это удобно при траблшутинге.
Официальную документацию я почти всегда читаю к настраиваемым продуктам. Даже тут на нее ссылку привел. Не будучи большим специалистом по сетям, для меня не очевидно по описанию из wiki, что netmap является чем-то недопустимым при пробросе портов. По факту у меня дома такой проброс настроен много лет и никаких проблем я не испытывал. И знать не знал, что это что-то невероятное для такого случая, по мнению местных комментаторов.
на вики есть описание экшенов, не совсем внимательно читали значит з)
На всякий случай вот эта ссылка
https://wiki.mikrotik.com/wiki/Manual:IP/Firewall/NAT#Port_mapping.2Fforwarding
Спасибо, уже посмотрел вчера.
Суть не в наборе базовых правил. Чувак заморочился и описал как пакет идет по firewall, что делает nat, где и как отрадатывает coontack и прочее.
Почему опять netmap-то? Ну почему? Ведь есть же dst-nat.
Можете в двух словах объяснить, в чем разница? Я всегда использую netmap, просто потому, что когда то давно это увидел. Дальше просто по привычке копирую. И самое главное, что в этом плохого, что надо поменять.
Разница в том, что это разные инструменты для разных целей, обрабытываются по-разному. При более сложной настройке можно схватить граблей плюс нагрузка на ЦПУ слегка выше. Понимаю, что в soho разницы скорее всего видно не будет, но ведь у вас это скопируют — как пить дать и понесут дальше :)
Так микротик выше чем в SOHO не используют.
Интересное заблуждение, но спорить не буду )
Не знаю насколько успешно, но некоторые провайдеры тоже используют. Я наблюдал лично.
Я даже работал в саппорте такого провайдера, и в свое время наша компания была клиентом аналогичного провайдера — прямо у нас в коммутационном шкафу они поселили свой микротик от которого запитали всех клиентов в здании. Иногда интернет пропадал, не часто, но стабильные простои раз в месяц-три по разным причинам. Я бы таких провайдеров назвал SOHO-ISP :)
Вот на днях я в одном из своих офисов выкинул RB951G-2HnD, потому что он перестал справляться с нагрузкой…
В сильном ентерпрайсе с требованиями к надежности сети обычно юзают Juniper и CISCO
При чем тут надежность? Если железка не тянет нагрузку, то она просто не в том месте трудится. С надежностью как раз у Микротик проблем нет. В этом плане к ним у меня никаких претензий.
Net-map используется для подмены всей подсети, с подменой 1:1 то есть мы можем поменять 88.0/24 net-map 89.0/24. На сколько я знаю то особо нет разницы что использовать для одного ip, но правило хорошего тона и все таки нужно использовать инструменты по назначению.
Заметил маленькое удобство netmap в сравнении с dst-nat. Для последнего нужно дополнительно разрешающее правило forward делать, а для netmap нет.