Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 28
Буквально на днях обнаружил, что в актуальной версии GNS3 есть шаблон Mikrotik CHR (bugfix-ветка и более старые версии).
Очень рекомендую для тестирования и написания конфигураций (у не лицензированной версии есть ограничения).
Очень рекомендую для тестирования и написания конфигураций (у не лицензированной версии есть ограничения).
Люблю Mikrotik
А не будет ли так, что при DDOS роутер ляжет раньше именно благодаря дополнительным правилам firewall — типа «более 15 новых соединений в секунду». CPU же никакой на домашних роутерах. Кому нибудь помогли хоть раз эти фильтры, что везде публицируют на форумах? Или только сердце/ЧСВ греют счетчики и забаненные IP :) Не лучше будет доступ к сервисам ограничить по IP или вообще отключить?
Тут главная цель атаки — исчерпание лимита соединений самого роутера (SYN flood атака). От такой атаки может спасти, но проверить мне пока нечем ;)
Для защиты CPU Firewall's rule переносят из «Filter Rules» в «Raw»
Да, вариант дропать неугодных в RAW лучше по производительности, но целиком перенести правила не выйдет, в RAW нет отслеживания connection-state=new.
Вариант с блокировкой в RAW:
Вариант с блокировкой в RAW:
/ip firewall filter
add action=jump chain=forward connection-state=new in-interface-list=ISP jump-target=anti-DDoS
add action=jump chain=input connection-state=new in-interface-list=ISP jump-target=anti-DDoS
add action=return chain=anti-DDoS dst-limit=15,15,src-address/10s
add action=add-src-to-address-list address-list=BAN-DDoS address-list-timeout=1d chain=anti-DDoS
/ip firewall raw
add action=drop chain=prerouting in-interface-list=ISP src-address-list=BAN-DDoS
/ip firewall filter
add action=jump chain=input connection-state=new dst-port=22,8291 in-interface-list=ISP jump-target=anti-BruteForce-3 protocol=tcp
add action=return chain=anti-BruteForce-3 dst-limit=4/1m,1,src-address/1m40s
add action=add-src-to-address-list address-list=BAN-BruteForce-3 address-list-timeout=1d chain=anti-BruteForce-3
/ip firewall raw
add action=drop chain=prerouting in-interface-list=ISP src-address-list=BAN-BruteForce-3
В том и отличие Mikrotik — наличие ресурсов за вменяемые деньги. Хотя понятно, в случае качественной атаки их не хватит, но хотя бы от «пионеров» защищаться хватает.
Для защиты роутера я поступаю проще: отсекаю всё входящее извне доверенной сети, кроме 1 порта. Когда надо стучусь в этот порт — создается на минуту запись адреса с которого можно зайти на роутер. Дальше есть эта минута чтоб зайти.
Еще полезно добавить низкоприоритетные blackhole-маршруты для RFC 1918 сетей:
Если в локалке используется адресация из этого диапазона (скажем, 10.50.50.0/24), то она перекроет, как с более точной маской, и с меньшей дистанцией, указанное выше, но для остального трафика подсети 10/8 отлично сработает.
/ip route add distance=249 dst-address=10.0.0.0/8 type=blackhole
...(то же для остальных RFC 1918 сетей)...Если в локалке используется адресация из этого диапазона (скажем, 10.50.50.0/24), то она перекроет, как с более точной маской, и с меньшей дистанцией, указанное выше, но для остального трафика подсети 10/8 отлично сработает.
Элегантно. При таком решении не очень то и нужно делать правила в Firewall, хотя от проблемы «серых» адресов не поможет. Все равно придется «вырубать» диапазон для провайдера.
А зачем «для провайдера» трафик фильтровать? Трафик этих сетей в его сторону полетел бы только по маршруту по умолчанию, т.е. по маршруту с маской /0. /8 в приведенном выше варианте blackhole-маршрута перебьет /0. Если же провайдер вам передает какие-то маршруты по DHCP, скажем, для установления связи с ним, то они будут более специфическими, чем /8 — так что на подсеть провайдера трафик убиваться в blackhole не будет.
Или я вас не понимаю?
Или я вас не понимаю?
Встречал такую ситуацию (BeeLine+L2TP):
10.1.1.0/24 — сеть в которой вам выдали адрес в сети провайдера (соответственно и шлюз по умолчанию).
10.2.2.0/24 — сеть L2TP серверов.
В варианте без «вырубки» диапазона, L2TP сервера станут недоступны. Или придется давать до них маршруты руками.
Как не крути, решение в такой ситуации будет не самым изящным при любом раскладе.
10.1.1.0/24 — сеть в которой вам выдали адрес в сети провайдера (соответственно и шлюз по умолчанию).
10.2.2.0/24 — сеть L2TP серверов.
В варианте без «вырубки» диапазона, L2TP сервера станут недоступны. Или придется давать до них маршруты руками.
Как не крути, решение в такой ситуации будет не самым изящным при любом раскладе.
Почему? В момент подключения к провайдеру у вас в таблице будет:
- 10.0.0.0/8 (249) -> bh
- 10.1.1.0/24 (1) -> выданный вам gw
- 10.2.2.0/24 (1) -> сервера
явно по маске и приоритетам сети /24 будут доступны, а остальное в 10/8 — нет. Когда вы подключитесь по l2tp, у вас таблица станет такой примерно:
- 10.0.0.0/8 (249) -> bh
- 10.1.1.0/24 (1) -> выданный вам gw
- 10.2.2.0/24 (1) -> сервера
- 0.0.0.0/0 (1) -> выданный вам gw
что на практике означает, что трафик на /24 подсети полетит на них, трафик на 10/8 умрет, а остальное, кроме 10/8 — полетит на шлюз (т.к. /0 менее специфичная маска, чем /8).
Во всех этих построениях дистанцию 249 можно и не указывать, оставить ее равной 1, но так более наглядно и с таблице заметнее.
А откуда у вас взялся маршрут до 10.2.2.0/24? Вы его должны прописать сами, тогда все заработает. Иначе, весь трафик до 10.2.2.0/24 будет завернут и BH.
Ах, вы об этом. Но это уже настройки под конкретного оператора. Я видел подобные подключения, где вот этот маршрут получался через DHCP, а дальше все как написано:
1. Клиент по dhcp получает адрес из сети 10.10.0.0/16, и сразу адрес ДНС серверов, которые умеют ресолвить адрес l2tp сервера вида «server.local» (грубо говоря).
2. В настройках l2tp соединения прописан именно сервер с именем server.local — и на нем авторизация пройдет, только если по dhcp получил все же настройки.
3. А уж из соединения по l2tp получает маршрут на 0.0.0.0/0.
Но если даже и не так, все равно вы как раньше, так и сейчас должны прописать маршрут (10.2.2.0/24 в вашем примере), bh тут не причем.
1. Клиент по dhcp получает адрес из сети 10.10.0.0/16, и сразу адрес ДНС серверов, которые умеют ресолвить адрес l2tp сервера вида «server.local» (грубо говоря).
2. В настройках l2tp соединения прописан именно сервер с именем server.local — и на нем авторизация пройдет, только если по dhcp получил все же настройки.
3. А уж из соединения по l2tp получает маршрут на 0.0.0.0/0.
Но если даже и не так, все равно вы как раньше, так и сейчас должны прописать маршрут (10.2.2.0/24 в вашем примере), bh тут не причем.
Ну да, решение само по себе красивое, но в определенных ситуациях не покрывает все случаи.
Так оно и не перекрывает ничего, кроме подчистки забытого. Если бы не делать маршруты в bh, в вашем случае вы же все равно должны маршрут до подсети провайдера прописать, правильно? bh добавляет к этому спокойствие, что вы не будете мусорить в WAN приватным трафиком (который, вообще говоря, провайдер и так отфильтрует, или хотя бы должен отфильтровать).
Учитывая, что правила файрволла для input обычно нормально-закрытые, есть ли необходимость в правилах блока RFC1918, если в конце концов весь трафик зарежется каким нибудь drop input from wan?
Это разные вещи.
Правила маршрутизации по RFC1918 блокируют трафик «серых» подсетей, не позволяя им уйти по дефолтному маршруту. Это снижает нагрузку на интерфейс.
Нормально-закрытые — это запретить всё, кроме established&related? В таком случае пакет, ушедший на аплинковый порт даже с адресом назначения из RFC1918, сможет вернуться назад, попав в established. Мы можем только надеяться, что провайдер самостоятельно зафильтрует такой трафик со своей стороны. Но что ему мешает осознанно или по ошибке настроить свою маршрутизацию таким образом, чтобы все пакеты с адресом назначения RFC1918 возвращались обратно по адресу источника? Получим усиление трафика в TTL число раз.
А также есть ещё очень много неявных сценариев, вероятность которых весьма мала, но лучше пресекать сразу на корню. Короче, не следует без нужды «срать» мусорными пакетами в сторону своего провайдера.
Правила маршрутизации по RFC1918 блокируют трафик «серых» подсетей, не позволяя им уйти по дефолтному маршруту. Это снижает нагрузку на интерфейс.
Нормально-закрытые — это запретить всё, кроме established&related? В таком случае пакет, ушедший на аплинковый порт даже с адресом назначения из RFC1918, сможет вернуться назад, попав в established. Мы можем только надеяться, что провайдер самостоятельно зафильтрует такой трафик со своей стороны. Но что ему мешает осознанно или по ошибке настроить свою маршрутизацию таким образом, чтобы все пакеты с адресом назначения RFC1918 возвращались обратно по адресу источника? Получим усиление трафика в TTL число раз.
А также есть ещё очень много неявных сценариев, вероятность которых весьма мала, но лучше пресекать сразу на корню. Короче, не следует без нужды «срать» мусорными пакетами в сторону своего провайдера.
«Нормально-закрытые» — запрещено всё, что не разрешено.
«Нормально открытые» — разрешено всё, что не запрещено.
Соответственно, если в нормально-закрытом файрволле есть правило, скажем,
то как минимум правило
Про возврат с established немного не понял. Ведь статус получают только успешные соединения, а тут налицо дроп — соединению не с чем устанавливаться. Значит оно не получит established и не пройдёт.
«Нормально открытые» — разрешено всё, что не запрещено.
Соответственно, если в нормально-закрытом файрволле есть правило, скажем,
add action=drop chain=input in-interface-list=!LANто как минимум правило
add action=drop chain=input comment="Drop RFC 1918" in-interface-list=WAN src-address-list="RFC 1918"Про возврат с established немного не понял. Ведь статус получают только успешные соединения, а тут налицо дроп — соединению не с чем устанавливаться. Значит оно не получит established и не пройдёт.
А, в этом вы правы. Правило-«пустышка» может использоваться, например, для сбора статистики, но таким лучше не злоупотреблять, т.к. большое количество правил нагружает процессор.
Изначально подумал, что вы спрашиваете про необходимость маршрутизации подсетей из RFC в blackhole. Весь комментарий выше про это.
>> Про возврат с established немного не понял. Ведь статус получают только успешные соединения, а тут налицо дроп — соединению не с чем устанавливаться.
Дроп будет, если первый пакет придет из вне. Если первый пакет сгенерирует сам роутер или устройство из LAN портов, то сразу создается поток, который отрабатывается по established, как правило по дефолту разрешенным файерволом более приоритетным правилом.
Изначально подумал, что вы спрашиваете про необходимость маршрутизации подсетей из RFC в blackhole. Весь комментарий выше про это.
>> Про возврат с established немного не понял. Ведь статус получают только успешные соединения, а тут налицо дроп — соединению не с чем устанавливаться.
Дроп будет, если первый пакет придет из вне. Если первый пакет сгенерирует сам роутер или устройство из LAN портов, то сразу создается поток, который отрабатывается по established, как правило по дефолту разрешенным файерволом более приоритетным правилом.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Mikrotik RoS, полезные мелочи