Комментарии 24
Всё чётко и по делу, но я бы всё таки фильтр в цепочке подкрутил немного.
Тот вариант который вы предлагаете
/ip firewall filter add action=drop chain=forward \
connection-nat-state=!dstnat connection-state=new in-interface-list=WANВ таком случае, если злоумышленник сможет отправить пакет на ваш маршрутизатор с адресом назначения вашей внутренней сети.(т.е он находиться с маршрутизатором в connected сети), он сможет организовать rst flood атаку на ваши внутренние ресурсы.
Так как пакет rst будет помечен как invalid, из за того что connection-tracker отслеживает на данный момент три протокола tcp,icmp,gre и замечательно пройдёт ваш файрвол. В итоге такой пакет дойдёт до внутренних хостов.
Всё же не стоит пренебрегать дропом invalid пакетов.
А эти минимальные правила фильтра, по сути, не спасают ни от какой дидос атаки. Я их привел для того, чтобы начинающий админ получил минимально достаточную безопасность с минимумом «побочных эффектов». ) А уж если админ знает об rst, то, убежден, он сможет, к примеру, настроить свой gre-тунель так, чтобы при наличии в фильтре дропа инвалидов туннель заработал. )
Определение состояния пакета относительно соединения в любой случае делается в цепочке prerouting и отменить данное поведение можно только двумя способами либо отключить connection-tracker или для определённого трафика использовать action=notrack.
На момент выхода пакета из цепочки prerouting у него уже стоит флаг в соответствии с состоянием соединения.
/ip address add interface=ether5 address=172.16.1.0/23 comment=«LAN2 IP»
Похоже что опечатка 172.16.1.0/23
В начале вы писали, что настройка будет через winbox, но в итоге оказалось что примеры конфигурации сделаны для CLI, за это отдельное спасибо.
add address=192.88.99.0/24 comment=«6to4 Relay Anycast» list=BOGONS
это вполне себе маршрутизируемые адреса, зачем их блокировать?
Однако согласен, можно не блокировать. На работоспособность в целом это не повлияет.
Да и мультикаст в сторону провайдера тоже не всегда стоит блокировать
add address=224.0.0.0/4 comment=Multicast list=BOGONS
а это?
Насколько я понимаю блокировка не валидного трафика и нормально закрытый фаерволл (запрещено все что не разрешено) должны перекрыть потребность в отдельном списке содержащем динамически изменяемый набор подсетей для bogon.
При чем после разрешения самым первым правилом established и related нужно сразу вторым блокировать invalid, и только потом разрешать icmp и все остальное, что не обходит, чтобы не нарваться на атаку через него (в том числе и не валидным). Последним — правило блокирующее все остальное.
Для примера: вам отправляют нелегетимный icmp запрос, он обрабатывается и разрешается вторым правилом. Далее — вас атакуют уже по установившемуся соединению ибо обрабатывать его будет самое первое правило фаерволла которым вы разрешили все established и related.
Хм, богон? Извините, но пожалуйста раскройте шире причину использования данного списка.
www.team-cymru.com/bogon-reference.html
Насколько я понимаю блокировка не валидного трафика и нормально закрытый фаерволл (запрещено все что не разрешено) должны перекрыть потребность в отдельном списке содержащем динамически изменяемый набор подсетей для bogon.
Фильтр фаервола не имеет никакого отношения к списку BOGON. Его предназначение описано в статье. Список не так часто изменяется. Однако, если хотите, есть ресурсы и скрипты, которые позволяют следить за его актуальностью автоматически. Автоматизация данного момента выходит за рамки статьи и, по мнению автора, не является критичной для работы мультиван.
По остальному — попробуйте при том фильре файрволла на input, что предлагается в статье, отправить
нелегетимный icmp запрос
Кроме того, в шапке написано, о чем статья — о мультиван. Защита от дидос атак в ней не заявлена.)
Тезис настройки фаервола в статье тоже описан. Безусловно, можно вносить любые изменения и дополнения в настройки, по желанию пользователя. Просто нужно отдавать себе отчет в том, что делается, какие дает плюсы и какие минусы. Любое ограничение — это компромисс между удобством, скоростью и безопасностью.
Единственная понятная статья в Рунете на эту тему и работающая для ROS 7.
Я пытаюсь через нее решить свою проблему, но не решил.
Суть в том, что на единственный физический интерфейс роутера приходит один кабель.
И в этом кабеле доступ к трем разным ISP (три разных статических белых подсети /29, первый адрес из каждой подсети - ее шлюз по умолчанию).
Поясню. Где-то очень далеко кабели от 3х ISP воткнули в тупой свитч, из свитча вышел 1 кабель и пошел ко мне в микрот.
За микротом 3 разных независимых офиса. Каждый из которых должен использовать только строго своего ISP.
По сути - как связать 3 провайдера с тремя потребителями 1:1 по одному Ethernet-проводу?
Либо разбить на 3 виртуальных сети, либо воткнуть свичт перед Микротиком, снова разбив на 3 линка. Делал такое, но давно уже.
Подскажите, как хотя примерно делать первый вариант?
Если на стороне офисов есть управляемые свитчи/роутеры с поддержкой влан - прокинуть сети вланами.
Если нет - дальше распределить подсетями.
Например, добавьте подсети на входной интерфейс, а потом распределите на выходные (можно маршруты пробросить). Может потребоваться бридж разорвать (и/или создать новые). И отсечь перенаправления между сетями.
Особенно это полезно, если вам не нужен доступ из одной подсети в другую.
Можно ещё и DHCP заставить разные настройки выдавать.
Сейчас нет времени и возможности проверить снова, на своём оборудовании, но если не хотите эксперементировать на живом железе, можете прокинуть линк в виртуалку с Микротиком и потестить на ней.
Прошу прощения, что не могу сейчас дать исчерпывающий ответ на ваш вопрос.
Однако, если до начала августа не разберётесь, могу вместе с вами "посидеть" и поразбираться, если не уеду в командировку.
Не стоит ли исключить BOGON-сети из NAT?
Публикации
Мультиван и маршрутизация на Mikrotik RouterOS