Filter Drop - сильно грузит процессор

alterak · 25 июн 2018, 08:20

Привет, всем...
Mikrotik RB951G, фильтр настроен по такой схеме:

Правило

В данном провиле обрубаем ВСЁ, что не разрешено.
Это все конечно хорошо, но последнее время участились атаки... либо порты сканируют, любо на определенный открытый порт... при этом загрузка процессора доходит до 100% и соответственно вешаются все порты.
Если атакуют единичный порт, то можно добавить в Raw Prerouting - тогда загрузка сразу спадает, но как быть когда подобное происходит сразу на кучу портов? Как обрубить подобные атаки прям на входе в Raw. Посоветуйте решение?

25 июн 2018, 10:44

У меня вечер уже, и я мож не увидел замыленным глазом, но:
1) а зачем разрешать пинг (ЯВНО), если Вы его нигде и не закрываете?
То есть в данном случая я вижу, что правило с пингом - лишнее, оно описывает то,
что итак уже открыто по-умолчанию.

2) Посмотрите и попробуйте проанализировать какие именно атаки вешают Ваш роутер?
По каким портам чаще бьют?
Я прекрасно понимаю, что любую железку можно заДДоСить, но в целом, странно что весь роутер вешается?
2.1) надеюсь Вы обновили роутер, там были уязвимости, как бы Вы не попали в число возможных претендентов?

3) А все правила файрвола активны, вернее так спрошу: у всех правил файрвола счётчик срабатываний не нулевой?
То есть хочу сделать акцент на порядок правил, на сработку тех или иных праивл, может даже концепцию файрвола
проверить/пересмотреть?

И лично от меня совет: (другие коллеги могут его не поддержать), я всё же для сбережения ресурсов роутеров,
особенно не мощных, первым правилом "убиваю" инвалидные пакеты на интерфейсе(ах). Зачем обслуживать
пакет, и дальше, через 2-15 правил его так или иначе убивать, "файс контроль" должен быть при входе

(это я думаю тоже +5-15% даёт выигрыша (экономия ресурсов CPU)

alterak · 25 июн 2018, 11:54

Vlad-2 писал(а): ↑25 июн 2018, 10:44 1) а зачем разрешать пинг (ЯВНО), если Вы его нигде и не закрываете?

Если убрать правило, то пинги не проходят, а открыл для себя, временно.

Vlad-2 писал(а): ↑25 июн 2018, 10:44 2) Посмотрите и попробуйте проанализировать какие именно атаки вешают Ваш роутер?
По каким портам чаще бьют?

Вчера пытался проанализировать, но это нереально просто... загрузка под 100%, винбокс в локальной сети просто вылетает при такой загрузке. Но пока было несколько рабочих секунд, в Tools->Torch увидел более 6000 подключений, а количество сканируемых портов просто не сосчитать-)
А роутер конечно же обновлен до последней стабильной прошивки.

Vlad-2 писал(а): ↑25 июн 2018, 10:44 3) А все правила файрвола активны, вернее так спрошу: у всех правил файрвола счётчик срабатываний не нулевой?

Сбрасывал счетчик специально, что бы посмотреть в каком правиле сильно летят пакеты... вот в этом, которое блокирует)

Вешает микрот именно блокирующий фильтр, поэтому и хотелось бы что бы все блокировки обрубались сразу на входе "Prerouting".

25 июн 2018, 12:57

1) связь с провайдером/адрес провайдерский/подключение точно на первом порту?
Нету случайно рррое или l2tp ?

2) про пинг странно

3) а Вы увидели на какие порты Вас атаковали?
Всё таки большая/основная масса должна быть идти на 1-10 портов одних и тех же, не успели посмотреть?
Или тем же Torch или в таблице Connections.

3.1) Кстати, о таблице Connections - зайдите туда (напоминаю, это в IP-Firewall-Connections)
там будет на панели одна единственная кнопка Tracking
и там будет такой параметр как "TCP Established Timeout"
обычно равен 1 дню, поставьте в Вашем случаи, хотя бы временно 1-2 час(а), и в Вашем случаи
проще и быстрее будет роутер перезагрузить(для обновления таблицы Connections).
Роутеру апосля будет полегче, пока Вы не решите тему с атаками.

4) Позвоните провайдеру, уточните у него, что/кто Вас атакует? Может провайдер
со своей стороны увидит какую-ту закономерность.
Да и когда идёт ДДоС на хость (много и долго), провайдеры или звонят/уточняют или отключают
обычно.

-- NB --
Я склоняюсь (и могу ошибаться, но погадать охота) что Вы:
а) перемудрили с файрволом (ситуация с тем же пингом)?
б) файрвол Вас не защищает
в) атака идёт на 53 порт(ы) + ещё что-то.

algerka · 25 июн 2018, 13:10

Vlad-2 писал(а): ↑25 июн 2018, 10:44 И лично от меня совет: (другие коллеги могут его не поддержать), я всё же для сбережения ресурсов роутеров,
особенно не мощных, первым правилом "убиваю" инвалидные пакеты на интерфейсе(ах). Зачем обслуживать
пакет, и дальше, через 2-15 правил его так или иначе убивать, "файс контроль" должен быть при входе
(это я думаю тоже +5-15% даёт выигрыша (экономия ресурсов CPU)

Сомневаюсь что кол-во invalid пакетов у вас превышает кол-во established & related.

algerka · 25 июн 2018, 13:18

alterak писал(а): ↑25 июн 2018, 11:54 Вчера пытался проанализировать, но это нереально просто... загрузка под 100%, винбокс в локальной сети просто вылетает при такой загрузке. Но пока было несколько рабочих секунд, в Tools->Torch увидел более 6000 подключений, а количество сканируемых портов просто не сосчитать-)

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

alterak · 25 июн 2018, 13:37

Vlad-2 писал(а): ↑25 июн 2018, 12:57 1) связь с провайдером/адрес провайдерский/подключение точно на первом порту?
Нету случайно рррое или l2tp ?

Это Ростелеком, на 1-м порту PPPoE.

Vlad-2 писал(а): ↑25 июн 2018, 12:57 3) а Вы увидели на какие порты Вас атаковали?
Всё таки большая/основная масса должна быть идти на 1-10 портов одних и тех же, не успели посмотреть?

6657, 9583 - это то, что успел увидеть и добавить в Raw Prerouting, после этого загрузка упала с 100 до 80% и хоть интернет зашевелился немного-). Времени не было в тот момент сильно капаться.

Vlad-2 писал(а): ↑25 июн 2018, 12:57 3.1) Кстати, о таблице Connections - зайдите туда (напоминаю, это в IP-Firewall-Connections)
там будет на панели одна единственная кнопка Tracking
и там будет такой параметр как "TCP Established Timeout"
обычно равен 1 дню, поставьте в Вашем случаи, хотя бы временно 1-2 час(а)

Спасибо, попробую сделать.

Vlad-2 писал(а): ↑25 июн 2018, 12:57 Я склоняюсь (и могу ошибаться, но погадать охота) что Вы:
а) перемудрили с файрволом (ситуация с тем же пингом)?
б) файрвол Вас не защищает
в) атака идёт на 53 порт(ы) + ещё что-то.

а) Да правила по сути своей простые, там особо и не намудришь
б) Мысль такая была-), нужно заново все мутить однако...
в) 53 порт у меня дропается правилом. С ним давно проблем нет.

algerka писал(а): ↑25 июн 2018, 13:18 есть подозрение что тот кусочек конфига который вы показали отличается от того что у вас на маршрутизаторе, иначе от куда 6000 подключений ?
Ну, или, как вариант это трафик с локалки.

У меня один в один! Только после родственных соединений добавлено дополнительное правило, разрешающие определенные порты forward.
Более 6000 соединений... А что тут удивительного? Микротик их обрабатывает и обрубает, а поскольку он их обрабатывает, поэтому и грузит процессор.

Правда было сброшено, поэтому всего 4.338.236 пакетов надропалось. А вообще трафик просто летел с сумасшедшей скоростью-(

Тут как бы ничего необычного, тупо атака по портам, которую не выдерживает железка... Просто за NAT стоит сервер с разными сервисами и портами, итого открыто около 20 нужных портов. Специально проверял, по этим портам пакеты почти не летят. Вешало только то, что приходило на Input и дропалось!

25 июн 2018, 13:40

alterak писал(а): ↑25 июн 2018, 13:37 Это Ростелеком, на 1-м порту PPPoE.

И ????
РРРоЕ это отдельный рабочий действующий виртуальный интерфейс,
на нём адрес даётся, так в файрволе к нему правила применять надо
а не к порту1 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Я выше и сказал - перемудрили!

alterak · 25 июн 2018, 13:52

Vlad-2 писал(а): ↑25 июн 2018, 13:40 И ????
РРРоЕ это отдельный рабочий действующий виртуальный интерфейс,
на нём адрес даётся, так в файрволе к нему правила применять надо
а не к порту1 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Я выше и сказал - перемудрили!

PPPoE конечно отдельный интерфейс, все правила к нему и применяются, а не к 1-му порту

25 июн 2018, 13:59

alterak писал(а): ↑25 июн 2018, 13:52 PPPoE конечно отдельный интерфейс, все правила к нему и применяются, а не к 1-му порту

Ну в Вашем первом сообщении, в Ваших примерах всё запрещающее приводилось
к по отношению к 1-му порту, а это значит для меня и для файрвола,
что трафик он будет закрывать на 1м порту, но рррое - это как я сказал
отдельный интерфейс, и запрещающие правила надо делать
на этот интерфейс.
порт1 для Вас представьте что его нет, это просто "физика" у Ростелекома.
Сделайте защиту на нужный интерфейс!

Filter Drop - сильно грузит процессор

Вход • Регистрация