+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Для провайдеров: как по-настоящему блокировать некорректные пакеты ICMP, TCP, UDP и другие (версия 2021)

Для провайдеров: как ***по-настоящему*** блокировать некорректные пакеты ICMP, TCP, UDP и другие (версия 2021), RouterOS

rextended

Guest

25.03.2014 21:11:00

Поиск по тегу #rextended firewall raw rules Добавлено 2021-07-06: по сравнению с версией 2014 года я добавил много нового. Пока не закончил, добавляю ещё, когда есть время. РАБОТА В ПРОЦЕССЕ. Буду признателен за любые предложения и, конечно, за позитивные комментарии, если такие будут... Спасибо BartoszP, я обновляю правила, когда могу https://forum.mikrotik.com/viewtopic.php?f=9&t=83387#p482224

Если в файрволе поставить одно правило по умолчанию: add action=drop connection-state=invalid, это на самом деле не блокирует никакие вредоносные соединения или пакеты. Правило drop invalid просто сбрасывает любой пакет или соединение, если не найдено соответствия в “connection tracking”. Следующие правила, наоборот, блокируют все поддельные или некорректные пакеты.

Эти правила основаны на том, как TCP и UDP пакеты должны быть оформлены, чтобы соответствовать RFC. Любые комментарии типа «UDP порт 0 используется некоторыми балансировщиками нагрузки» не важны, они не следуют RFC и не используются MikroTik.

boen_robot объясняет подробнее: https://forum.mikrotik.com/viewtopic.php?f=9&t=83387&p=417864#p460244

Эти правила должны быть установлены в “/firewall raw”, чтобы они не мешали работе обычных стандартных правил “/firewall filter”.

Внимание: эти правила не заменяют, а должны использоваться как минимум вместе с дефолтными правилами “/firewall filter”.

/ip firewall raw
add action=drop chain=prerouting comment="TCP invalid combination of flags attack (7 rules)" protocol=tcp tcp-flags=!fin,!syn,!rst,!ack
add action=drop chain=prerouting protocol=tcp tcp-flags=fin,syn
add action=drop chain=prerouting protocol=tcp tcp-flags=fin,rst
add action=drop chain=prerouting protocol=tcp tcp-flags=fin,!ack
add action=drop chain=prerouting protocol=tcp tcp-flags=fin,urg
add action=drop chain=prerouting protocol=tcp tcp-flags=syn,rst
add action=drop chain=prerouting protocol=tcp tcp-flags=rst,urg

add action=drop chain=prerouting comment="TCP Port 0 attack (2 rules)" protocol=tcp src-port=0
add action=drop chain=prerouting dst-port=0 protocol=tcp

add action=drop chain=prerouting comment="UDP Port 0 attack (2 rules)" protocol=udp src-port=0
add action=drop chain=prerouting dst-port=0 protocol=udp

Почему “drop” лучше, чем тратить CPU и создавать бесполезный трафик с “reject”?
Ещё раз спасибо boen_robot за объяснение: https://forum.mikrotik.com/viewtopic.php?f=9&t=83387&p=417380#p467921

SYN-фрагментированная атака
/ip firewall raw
add action=drop chain=prerouting comment="SYN fragmented attack" fragment=yes protocol=tcp tcp-flags=syn

Защищённая зона (против Teardrop Attack и других)
Некоторые виды атак используют фрагментацию IP-пакетов. Но фрагментация пакетов может быть нужна и легитимна. Чтобы создать «защищённые зоны» от фрагментированных IP-атак, можно использовать одно или оба варианта:

Создать список интерфейсов, которые нужно защитить:
/interface list
add name=fragment_protected_interface

/ip firewall raw
add action=drop chain=prerouting comment="Fragment attack Interface Protection" fragment=yes in-interface-list=fragment_protected_interface

Создать список адресов IP, которые нужно защитить:
/ip firewall address-list
add address=2.3.4.5 list=fragment_protected_IP

/ip firewall raw
add action=drop chain=prerouting comment="Fragment attack IP Protection" fragment=yes dst-address-list=fragment_protected_IP

Атаки с IP-опциями
Атаки, использующие редко применяемые (или неправильно используемые) IPv4 флаговые опции.

/ip firewall raw
add action=drop chain=prerouting comment="IP option loose-source-routing" ipv4-options=loose-source-routing
add action=drop chain=prerouting comment="IP option strict-source-routing" ipv4-options=strict-source-routing
add action=drop chain=prerouting comment="IP option record-route" ipv4-options=record-route
add action=drop chain=prerouting comment="IP option router-alert" ipv4-options=router-alert
add action=drop chain=prerouting comment="IP option timestamp" ipv4-options=timestamp
add action=drop chain=prerouting comment="IP options left, except IP Stream used by the IGMP protocol" ipv4-options=any protocol=!igmp

Защита от IP-спуфинга (предотвращение LAND Attack и других)
Все провайдеры должны это делать, и тогда 95% DDoS-атак просто не существовали бы...

В стандартной конфигурации есть два списка интерфейсов — для WAN и LAN:
/interface list
add name=WAN
add name=LAN

Определяем один или несколько списков IP-адресов, используемых на локальной стороне сети (может включать и публичные IP):
/ip firewall address-list
add address=192.168.88.0/24 list=IP_used_on_LAN

Мы не ожидаем входящие внутренние IP с WAN или с LAN, которые не включены в IP_used_on_LAN

/ip firewall raw
add action=drop chain=prerouting comment="IP Spoofing protection from WAN" in-interface-list=WAN src-address-list=IP_used_on_LAN
add action=drop chain=prerouting comment="IP Spoofing protection from LAN" in-interface-list=LAN src-address-list=!IP_used_on_LAN \
src-address=!0.0.0.0 dst-address=!255.255.255.255

src-address=!0.0.0.0 и dst-address=!255.255.255.255 нужны, чтобы не блокировать сервисы в LAN, например DHCP-сервер (src 0.0.0.0 → dst 255.255.255.255).

Неиспользуемые протоколы
Удалить неприсвоенные протоколы сложно, потому что в поле protocol можно указать только одно число, а не диапазон.

Протоколы с номерами от 144 до 255 не назначены https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

Но на практике не все эти 144 протокола используются, или в 95% случаев — только ICMP (1), TCP (6) и UDP (17).

Нельзя поставить правило типа drop protocol=144-255, потому что это не поддерживается, поэтому принимаем все нужные протоколы и сбрасываем остальные. Эти правила должны идти В КОНЦЕ!!!

/ip firewall raw
add action=accept chain=prerouting protocol=icmp
add action=accept chain=prerouting protocol=igmp
add action=accept chain=prerouting protocol=tcp
add action=accept chain=prerouting protocol=udp
add action=accept chain=prerouting protocol=gre
add action=log chain=prerouting log-prefix="Not TCP protocol" protocol=!tcp
add action=drop chain=prerouting comment="Unused protocol protection" disabled=yes protocol=!tcp

Последнее правило отключено специально — сначала добавьте все используемые протоколы (например, 47 GRE для pptp, EoIP и т.п.) и только потом включайте его.

Новые TCP-соединения без SYN
Новое TCP-соединение должно начинаться с пакета с флагом SYN.

Если в первом пакете нет SYN — это точно атака или сканирование...

Каждое из правил должно идти первым в /ip firewall filter в соответствующей цепочке input и forward. В raw это не работает, потому что там нужен connection-tracking.

/ip firewall filter
add action=drop chain=input connection-state=new protocol=tcp tcp-flags=!syn comment="TCP non SYN scan attack input"
add action=drop chain=forward connection-state=new protocol=tcp tcp-flags=!syn comment="TCP non SYN scan attack forward"

Если кто-то найдёт баг — пожалуйста, сообщите. Спасибо.

donkeyKong

Guest

03.06.2023 08:19:00

Спасибо за эти полезные правила. Пользуясь Wireguard, я поймал довольно много сброшенных пакетов из-за правила "UDP drop port zero", хотя трафик вроде бы валидный:
01:13:56 firewall, info UDP port 0 prerouting: in:(unknown 1) out:(unknown 0), connection-state:new proto UDP, 127.0.0.1:13131->127.0.0.1:0, len 176
Вместо этого я использую такое правило:
add action=drop chain=prerouting protocol=udp port=0 src-address=!127.0.0.1 dst-address=!127.0.0.1

hagoyi

Guest

18.06.2023 09:36:00

Эта правило делает то же самое, что использование STRICT TCP tracking, как ты писал в этом посте? Другими словами, нужно ли мне добавлять правило «TCP non SYN scan attack», если я уже использую STRICT tracking? /ip firewall connection tracking
set loose-tcp-tracking=no

rextended Guest	#4 0 18.06.2023 15:41:00 Это касается «SYN-сканирования атаки», а не (случайного) возобновления NAT-сессии после перезагрузки роутера…

anav

Guest

18.06.2023 15:49:00

Вау, щипает себя, я не использую ни одну из этих техник, а всё равно как-то справляюсь! Мне повезло? Или за углом меня ждёт катастрофа? Может, я рискую удачей? Или эти меры предназначены для определённых случаев: разных типов использования (дом, малый офис или крупная компания)? Насколько это применимо?

rextended Guest	#6 0 18.06.2023 15:53:00 Это должен делать провайдер, а не конечный пользователь. Вся тема была ориентирована на провайдера, но я особо её не поддерживаю...

anav

Guest

18.06.2023 16:40:00

Хорошо, понял, это больше для организаций, которые управляют интернет-провайдерами, например, тех, кто запускает серверы PPPOE для множества клиентов и т.д. Не слышал, чтобы в крупных компаниях использовали MT для вышестоящих (пограничных) маршрутизаторов.

rextended Guest	#8 0 18.06.2023 19:23:00 Вся моя периферийная инфраструктура построена на MikroTik (все на версии v6.48.7, кроме одного на 7.10).

hagoyi Guest	#9 0 19.06.2023 08:38:00 Понимаю. Но если STRICT будет проверять каждый новый пакет на флаг SYN, он бы отбрасывал те же плохие пакеты, что и это правило «SYN scan attack», правильно?

ankostis Guest	#10 0 18.10.2023 12:37:00 В качестве предупреждения для других: я попробовал этот первый блок кода и сразу же был заблокирован в роутере — пришлось делать жесткую перезагрузку и восстанавливать из резервной копии!

rextended

Guest

#11

18.10.2023 12:44:00

Ни одна из этих команд, даже если применить их по отдельности или случайным образом, не может заблокировать winbox, webfig, ssh, telnet и так далее… Это ужасная привычка — копировать и вставлять, не понимая, что делаешь. С 25 марта 2014 года ты единственный пользователь, который был автоматически заблокирован, и это однозначно твоя вина. Особенно если ты пользовался Блокнотом в Windows 11.

anav

Guest

#12

18.10.2023 13:06:00

Тогда автор поста либо потрясающий бета-тестер, либо обладает особым набором навыков, который чаще всего называют "вечно ошибающимся"! Проверь свою почту. PS. Всё ещё думаю, что название этой темы должно быть «Провайдеры → Как на самом деле блокировать недопустимые ICMP, TCP, UDP пакеты и другие (версия 2021)».

DarkNate

Guest

#13

18.10.2023 16:28:00

Я надеялся, что rextended уберёт этот ICMP-ший момент, потому что это плохая идея класть это в продакшн или даже для домашнего пользователя. В RouterOS по умолчанию есть ограничение на скорость ICMP, то же самое во всех ОС от сетевых вендоров и в чистом Linux-ядре. Это ломает PMTUD и просто глупо. Я видел крупные сети, которые так делают, а потом звонят мне и спрашивают: «Почему у нас в сети медленные или нестабильные TCP-передачи?» Ответ: «Потому что вы научились этому из какого-то случайного поста на форуме MikroTik». На самом деле стоит сбрасывать только те типы ICMP, которые IANA признала устаревшими.

rextended

Guest

#14

18.10.2023 16:56:00

Да, но там ясно сказано: Внимание: эти два правила могут нарушить Path MTU Discovery (PMTUD), используйте их только если ваше устройство чувствительно к атакам «Большой ICMP» или «Ping of Death». Если сомневаетесь, вообще не применяйте!!! Спасибо, добавлено в будущем обновлении. ICMP полностью убрали, чтобы избежать проблем. В Италии есть пословица: Мать дураков всегда беременна.

DarkNate Guest	#15 0 18.10.2023 17:08:00 Это всё равно приведёт к срыву jumbo-пакетов. Удалите оба этих правила тоже. add action=drop chain=prerouting comment="ICMP large packet attack" packet-size=1601-65535 protocol=icmp add action=drop chain=prerouting comment="ICMP fragmentation attack" fragment=yes protocol=icmp

rextended Guest	#16 0 18.10.2023 17:11:00 Упс, случайно ушёл, удалил.

jspool Guest	#17 0 18.10.2023 17:44:00 IP-спуфинг (предотвращение LAND-атаки и других) Если провайдер использует OSPF, BGP, BFD, VRRP на каком-либо из этих интерфейсов, им нужно будет убедиться, что правила не мешают работе этих протоколов.

rextended Guest	#18 0 18.10.2023 18:57:00 Помни, что если обувь со шнурками — обязательно завязывай их. Любая ошибка в настройках влияет на всё. Если не понимаешь, что делаешь, результат будет таким же.

yudh24

Guest

#19

19.10.2023 07:23:00

Я не понял на данном этапе:

/ip firewall raw add action=drop chain=prerouting comment="TCP invalid combination of flags attack (7 rules)" protocol=tcp tcp-flags=!fin,!syn,!rst,!ack
add action=drop chain=prerouting protocol=tcp tcp-flags=fin,syn
add action=drop chain=prerouting protocol=tcp tcp-flags=fin,rst
add action=drop chain=prerouting protocol=tcp tcp-flags=fin,!ack
add action=drop chain=prerouting protocol=tcp tcp-flags=fin,urg
add action=drop chain=prerouting protocol=tcp tcp-flags=syn,rst
add action=drop chain=prerouting protocol=tcp tcp-flags=rst,urg
add action=drop chain=prerouting comment="TCP Port 0 attack (2 rules)" protocol=tcp src-port=0
add action=drop chain=prerouting dst-port=0 protocol=tcp
add action=drop chain=prerouting comment="UDP Port 0 attack (2 rules)" protocol=udp src-port=0
add action=drop chain=prerouting dst-port=0 protocol=udp

С 2-й по 7-ю запись — это то же самое, что если я создам такое правило?
/ip firewall raw add action=drop chain=prerouting protocol=tcp tcp-flags=fin,syn,rst,!ack,urg

Или, может, tcp-flags не читаются с логикой "ИЛИ"?

rextended Guest	#20 0 19.10.2023 13:46:00 → Для провайдера: У меня советы именно по блокировке нежелательного трафика у самого источника, а не уроки о том, как работает TCP/IP… НЕТ. Прежде чем делать какие-то выводы, лучше сначала разобраться, для чего они нужны, как устанавливаются TCP-флаги и как файервол сопоставляет правило.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры