dst-limit и защита от DoS

[Igor]

Добрый день!
Читал Ваш пост: https://forum.mikrotik.com/viewtopic.php?f=2&t=54607 . Правило работает. Проверял с помощью hping3 и на "живой" технике.
Но возникло недопонимание единицы измерения для параметра dst-limit. Рассмотрю на примере этой строки: add chain=block-ddos dst-limit=50,50,src-and-dst-addresses/10s action=return

Разночтения:

• Если я правильно, то в темы Вы подразумеваете, что разрешены первые 50 подключений и далее не более + 50 подключений за каждые 10 секунд от источника А к цели Б. Т. е. 50 = 50 подключений. Судя по этому единицей измерения являются подключения.

• Здесь: https://wiki.mikrotik.com/wiki/Manual:I ... all/Filter говорится другое. Burst - initial number of packets per flow to match: this number gets recharged by one every time/count, up to this number. Если же судить по этому, то будут разрешены первые 50 пакетов + 50 пакетов каждые 10 секунд от источника к цели Б. Т. е. 50 = 50 пакетов. Судя по этому единицей измерения являются пакеты.

Можете разъяснить ситуацию?

[Chupaka]

Добрый.

Строго говоря, ни первое, ни второе не правильно
Правильно — число обращений к этому правилу файрвола (со скидкой на то, что правило обрабатывает всё же пакеты). Если оно будет обрабатывать все пакеты — то лимит получается в пакетах. У меня же в forward предлагается использовать правило "add chain=forward connection-state=new action=jump jump-target=block-ddos" — т.е. в цепочку block-ddos уйдут на анализ только пакеты, начинающие новое соединение (connection-state=new, каждый первый пакет нового соединения) — поэтому в моём примере получается лимит в количестве соединений.

[Igor]

Понял. Спасибо! Анализировал это правило в отрыве от предыдущего.

[Igor]

С началом понедельника правило начало заносить в черный список много доверенных устройств.
Нашел вариант решения: Указать входящий интерфейс = WAN. За счет этого у меня перестали попадать в бан локальные адреса, которые не заражены, а просто имеют много подключений.

Вариант решения с белым списком не подходит, т.к. по мимо серверов начали попадать в бан и произвольные локальные IP-адреса. В моем случае интерфейс в локальной сети является доверенным. Если я правильно понимаю, то Вы работаете в Интернет-провайдере и у Вас оба интерфейса являются недоверенными. Была ли у Вас такая проблема или у Вас все работает в виде dst-limit=50,50?

[Chupaka]

Как вижу, у нас сейчас где-то dst-limit=24,256,src-and-dst-addresses, где-то вообще dst-limit=16,256,src-and-dst-addresses

Т.е. даём большой (256) burst для всяких серверов с ненастроенным Connection: keep-alive, но если методично и долго долбятся - тогда попадают под блокировку

[Igor]

Спасибо.

[Antares]

Доброго времени.
Примерно с год использую этот метод (слегка заточенный под свои нужды) на шлюзах. На CCR 1036 работает и иногда облегчает жизнь. Сейчас пробую на CHR и ничего не могу понять. dst-limit при любых значениях обрабатывает практически все коннекты, соответственно все адреса благополучно попадают в адресные листы и благополучно блочатся...
Коллеги, никто не сталкивался с таким на каких-нить железках?

[Chupaka]

Connection Tracking включен?

[Antares]

Включен. Стоял на auto, попробовал переключить на yes, картина не изменилась.

[Chupaka]

Т.е. правила те же, но правило с dst-limit не срабатывает, поэтому пакеты идут дальше по правилам? Можно попробовать поставить после него правило для логирования всех соединений, чтобы увидеть, что там в таком количестве лезет...

[Antares]

Вопрос решился переходом на последнюю версию RouterOS для CHR. Спасибо за ответы!

[Antares]

Предлагаю несколько усовершенствований (исходя из своего опыта).
1. Добавить
add chain=input connection-state=new action=jump jump-target=block-ddos
поскольку атаковать могут и сам роутер.
2. При необходимости создать адрес-лист, в который включить адреса, создающие большое кол-во легитимных соединений. И исключить этот лист из проверки. То есть, получаем что-то типа такого:
add chain=forward action=jump connection-state=new jump-target=block-ddos src-address-list=!exclude_from_ddos
3. Перенести непосредственно drop в секцию Raw, что исключит все дропающиеся пакеты из трэкинга, соответственно снизится нагрузка на процессор во время атаки.

[Chupaka]

1. Для самого роутера я предпочитаю реализовывать куда более жёсткие правила. Приведённые выше - слегка защищают неопределённый сервис. Для критической инфраструктуры доступ должен быть только из доверенной зоны

2. Можно и так, я для большей ясности и компоновки однотипного рядом перед dst-limit-правилом в цепочке block-ddos просто добавляю action=return для адресов-исключений.

3. Резонно. Просто на момент написания правил таблица Raw в RouterOS ещё не была доступна

[promychev]

Здравствуйте, хотел сообщить по поводу блокировок легитимных пользователей. Мучился я долго пришел к выводу. Есть другой способ, а есть этот же "Первый". в dst-limit надо прописывать dst-limit=32,32 как раз для apache2 сервера. В гайде Chupaka идет DROP адресов не соответствующих dst-limit, но я так же использовал tarpit и разницы почти никакой (только нагрузка на CPU).
Суть не в самой блокировке или тарпите, а в том что именно этот браст защищает от SYN атак как методов torshammer и GOldenEYe не блокируя настоящих пользователей. Остальные брасты как 50 на 50 блокировали даже запросы на check-host.net
Гайд Chupaka написал хороший - молодец, прочел его на форуме EU.
"Второй" способ - надо включить функцию TCP SYNcookie ,но с первым методом он снова блокирует легитимных посетителей.
Правила идут такие :

/ip firewall filter add chain=forward protocol=tcp tcp-flags=syn connection-state=new action=jump jump-target=SYN-Protect comment="SYN Flood protect" disabled=yes
/ip firewall filter add chain=SYN-Protect protocol=tcp tcp-flags=syn limit=400,5 connection-state=new action=accept comment="" disabled=no
/ip firewall filter add chain=SYN-Protect protocol=tcp tcp-flags=syn connection-state=new action=drop comment="" disabled=no

Что бы микротик не блочил уже легитимных подключенных пользователей ( в обоих случаях желательно прописать эти правила )
/ip firewall filter
add chain=forward connection-state=established comment="allow established connections"
add chain=forward connection-state=related comment="allow related connections"
add chain=forward connection-state=invalid action=drop comment="drop invalid connections"

Тестировал я работу Mikrotik OS на VPS сервере, отключит CISCO ASA оборудование что бы проверить оптимальность фильтрации трафика на Mikrotik. Основан на кернел - так что работать очень удобно за исключением Packet Sniffer. Правда не много функционален, но очень удобный.
В общем - самая геморойная защита - это защита http от syn флуда, защита игровых серверов проще ( ограничение по длине или размеру пакета
или тот же Layer7 protocol). Описывайте свой опыт, всегда рад поделиться своим опытом.

[Chupaka]

limit=400,5

здесь надо быть осторожным: это ограничение на общее число пакетов, а не для каждого пользователя

ну и последние модные веяния - это использование таблицы Firewall RAW вместо Firewall Filter, чтобы не беспокоить Connection Tracking

[promychev]

Снова здравствуйте. Провел я несколько тестирований с сервера debian на котором стоял torshammer и GoldenEye L7, запускал атаки по apache2 который роутер защищал и понял то - что во время старта атаки, роутер не успевает обработать все запросы разом, и из-за сервера апач2 он все запросы видит такими (что привыщают наш dst-limit). Так как нормального анализатора пакетов в Mikrotik к сожалению, пришлось все таки с ним работать на скорую руку. Начал замечать что изначально TTL ботов < 63 а TTL нормального посетителя >100, так как бот запрашивает определенный контент. Подумал подумал, ок пусть правила Chupaka видят меня и положительных ботов как "ddoser" и закидывают меня в return. Но в правило дроп, я прописал проверку на бота на скорую руку. Кстати боты torshammer и GoldenEye так же и xml-rpc бьют за каждый запрос 50-51 TTL.
В итоге что получилось.
Chain = forward , dst port = tcp 80-443 , Conection State = new | Аction = jump , jump-Target=block-ddos

Chain = forward , dst port = tcp 80-443 , Conection State = new | Src. address list = ddoser, Dst. address list = ddosed , TTL = less than 63 Аction = drop

Chain = block ddos , dst port = tcp 80-443 , Dst. Limit 10s 50 brust limit by dst.address expire = 50.00 , Аction = return

Chain = block ddos , dst port = tcp 80-443 , Action = add src. address list to = ddoser timeout=00.10.00

Chain = block ddos , dst port = tcp 80-443 , Action = add dst. address list to = ddosed timeout=00.10.00

Если есть у кого идеи по лучше, пишите.

[Chupaka]

Есть подозрение, что TTL у ботов такой маленький потому, что они работают на Linux (default TTL = 63), а вы под "нормальным" понимаете Windows (default TTL = 128). В частности, под признак "TTL ниже 63" попадают мобильные телефоны (как минимум Андроиды и Айоси)

Ну и порт вы явно хотели писать не диапазоном (80-443, куда попадают все 81,82 и прочие 440), а через запятую: "80,443"

[promychev]

Есть подозрение, что TTL у ботов такой маленький потому, что они работают на Linux (default TTL = 63), а вы под "нормальным" понимаете Windows (default TTL = 128). В частности, под признак "TTL ниже 63" попадают мобильные телефоны (как минимум Андроиды и Айоси)

Ну и порт вы явно хотели писать не диапазоном (80-443, куда попадают все 81,82 и прочие 440), а через запятую: "80,443"

Да я заметил что андроиды попадают под блокировку. Но если прописать в цепочке проверку на dst. limit , то думаю после этого проблем быть не должно. Они пройдут проверку на TTL, естественно попадают в список под подозрение - дальше проверяются по Dst. limit.
Единственное что мы с вами обсудили в ЛС, это защита GET/POST для Apache2 сервера.
В общем добавил правила на размер пакетов и на con. limit.
Все работает. Надо будет потом написать полный гайд с вашего позволения. Ну и в добавок могли бы загрузить для пользователей Router OS 5.20 c ключем активации лицензии.
Еще хотелось бы поднять тему для Layer7 protocol и regexp для них (под веб серверы, игровые серверы и всякие приложения)
Еще раз спасибо за форум и его развитие.

[Chupaka]

Ну и в добавок могли бы загрузить для пользователей Router OS 5.20 c ключем активации лицензии.

Спасибо, но распространять старые неактуальные версии у меня рука не поднимется =) А если хочется поиграться - есть бесплатный Cloud Hosted Router, который можно развернуть на многих гипервизорах и VDS'ах. По-моему, ломать RouterOS уже давно не очень актуально

[promychev]

1. Для самого роутера я предпочитаю реализовывать куда более жёсткие правила. Приведённые выше - слегка защищают неопределённый сервис. Для критической инфраструктуры доступ должен быть только из доверенной зоны

2. Можно и так, я для большей ясности и компоновки однотипного рядом перед dst-limit-правилом в цепочке block-ddos просто добавляю action=return для адресов-исключений.

3. Резонно. Просто на момент написания правил таблица Raw в RouterOS ещё не была доступна

Здравствуйте чупака, на сколько я знаю в RAW нет функции connection state = а что означает что нельзя будет написать доп проверку на легитимных пользователей для connection state = new.

[Chupaka]

Да, connection-state в RAW отсутствует. Как вариант - проверять пакеты TCP SYN, начинающие новое TCP-соединение. С UDP - думать отдельно.

С другой стороны, если в RAW делать только drop, а всю логику оставить в том же forward - то там всё это будет. Таким образом, в RAW уничтожаются заведомо вредные пакеты, а уже нормальные и подозрительные идут в Connection Tracking для полноценной обработки.