Форум OlegON > Компьютеры и Программное обеспечение > Сеть > Сетевое оборудование > MikroTik

Mikrotik. Ограничение по частоте подключений. : MikroTik

28.03.2024 23:23


11.05.2020 11:12
OlegON
 
В свое время я отказался от фильтрации по частоте подключений хотя бы потому, что когда преобладал HTTP, то любой, кто держал несколько страниц этого форума среди сохраненных вкладок браузера, рисковал налететь на бан при запуске этого самого браузера. Суть HTTP - множественные подключения и некоторые, при соответствующем тюнинге Firefox могли без проблем плюнуть в сторону сервера 64 запроса одновременно.

Сейчас ситуация в корне поменялась с приходом HTTPS. Браузеры не только не открывают миллион соединений, но и не спешат закрывать и открывать соединения в принципе. Более того, нормальные поисковики вроде Google и Яндекса, многие другие, даже wget, все они открывают HTTPS-соединение и запрашивают данные через него, не спеша разрывать его между страницами.

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

Пример дан в командах Mikrotik, но я постараюсь пояснить все достаточно, чтобы можно было транслировать их в любой другой Linux. В нем достаточно использовать iptables и ipset для списков адресов.

Для начала отсечем злодеев. Я делаю это в таблице raw, чтобы пакеты в принципе никуда потом не шли и не грузили процессор.
Код:
/ip firewall raw
add action=drop chain=prerouting in-interface=wan src-address-list=banned
add action=drop chain=prerouting dst-address-list=banned
Далее, все пакеты снаружи с новыми соединениями кидаю в отдельную цепочку правил SYN-protect. Обратите внимание, что обязательно надо указать !aсk. Если кто не понял, почитайте про порядок установления соединения. Устанавливающий соединение кидает syn, подтверждающий - syn,ack. Соответственно, если банить только по syn, как предлагает Mikrotik wiki, то будете банить и всех, к кому часто подключаетесь вы сами, поскольку они будут присылать syn,aсk в ответ. Кроме того, я не указываю порт, поскольку у меня нет сервисов, ожидающих частых подключений.
Код:
/ip firewall filter
add action=jump chain=forward comment="SYN-flood protect" connection-state=new dst-address=внутренний_сервера in-interface=wan jump-target=SYN-protect protocol=tcp tcp-flags=syn,!ack
Сама цепочка SYN-protect. Правило простое, если подключения идут не чаще 3 в секунду и с разрешенным разовым ускорением (burst) до 8, то из цепочки возвращаемся. При нарушении этого правила источник добавляется в забаненные на 1 час. Обращаю внимание, что в Mikrotik wiki неоптимально в цепочке проверяются опять флаги и протокол, что лишено смысла, поскольку в цепочку попадают только TCP и syn,!aсk, как указано в правиле входа (см. выше)
Код:
/ip firewall filter
add action=return chain=SYN-protect dst-limit=3,8,src-address/1m
add action=add-src-to-address-list address-list=banned address-list-timeout=1h chain=SYN-protect log=yes
по итогам работы выяснилось, что множество хостов многократно подключаются к серверу и ничего не запрашивают. Т.е. я их не вижу в журналах веб-сервера. Для чего - не знаю, видимо, какие-то сканеры уязвимостей протокола. Сканеры портов теперь тоже налетают на бан. Целая куча липовых "браузеров", которые подставляли правильный юзерагент, но на самом деле вели себя не как браузеры, запрашивая кучей запросов, тоже полетели в корзину, куда им и дорога. По журналу веб-сервера их отличить невозможно, поскольку там нет идентификаторов подключений (оно и хорошо, глазами это не разобрать). Много всяких сканеров уязвимостей и прочего тоже отвалилось. Не все, поскольку многие приспособились работать в одно соединение, чтобы свои ресурсы экономить, но их количество показало, что работа была проделана не зря.

Из того, что кому-то, возможно, потребуется иметь ввиду - налетает обновлятор кеша CloudFlare. Зачем он в HTTP долбится, хотя я указал ему HTTPS - не знаю. Собственно, что это обновлятор кеша - мое предположение. Возиться с белыми списками не стал. Мне не надо. Еще сбивает адреса при подключениях с ооочень плохой связью вроде GPRS на последнем делении по силе сигнала. Там соединения никак не доходят, а потом все повторы вываливаются на сервер. Править не стал, все равно страницу в таких условиях получить почти невозможно.
11.05.2020 19:50
vdm
 
Цитата:
OlegON !ask
Опечатка? Здесь и далее ack должно быть.
11.05.2020 19:58
OlegON
 
Цитата:
vdm Опечатка?
нет, все правильно
Цитата:
OlegON Обратите внимание, что обязательно надо указать !ask. Если кто не понял, почитайте про порядок установления соединения. Устанавливающий соединение кидает syn, подтверждающий - syn,ask. Соответственно, если банить только по syn, как предлагает Mikrotik wiki, то будете банить и всех, к кому часто подключаетесь вы сами, поскольку они будут присылать syn,ask в ответ.
Смотри, от меня идет соединение в гугл, я шлю syn, он не попадает в оценку, поскольку входящий интерфейс другой. Гугл мне подтверждает готовность открыть соединение, присылая в ответ пакет с двумя флагами: syn,ack. Поэтому в правиле я ставлю !ack, т.е. чтобы такие пакеты не анализировались. Иначе, например, всякие FTP и HTTP-сайты поотваливаются, например. Которые ты сам побанишь за то, что они тебе подтверждающие пакеты пришлют.
11.05.2020 20:00
OlegON
 
Блин, ты прав, да, ack, конечно, опечатался... :) В твоем сообщении увидел восклицательный знак только...
Но, в правилах все изначально правильно, там с реального Микротика.
Часовой пояс GMT +3, время: 23:23.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.