Comments 9
Для этго существует механизм SYN cookies. Блокировать источник флуда по IP на уровне фаерволла это так себе идея по двум причинам:
IP адреса источника можно подделать на стороне отправителя. Если вы баните по IP источника SYN сегмента то у скрипткидди появляется отличная возможность, ну например, сделать ваш сервер недоступным для поисковиков или даже для вас самих.
При бокировке по IP на уровне фаерволла все же тратится память на хранение таблицы забаненных IP и тратится время на проверку по этой таблице. Еще fail2ban этот живет отдельным процессом, логи писать/читать - затратно это все. SYN cookies не тратит память, но тратит время на генерацию кукиса, но это не много.
В /etc/sysctl.conf были включены SYN cookies. Это просто одно из решений, мне такой путь показался интересней, с логам и гибче. Правило айпитэбла можно вырубить, а можно перезаписать с DROP.
IP адреса источника можно подделать на стороне отправителя. Если вы баните по IP источника SYN сегмента то у скрипткидди появляется отличная возможность, ну например, сделать ваш сервер недоступным для поисковиков или даже для вас самих.
Справедливости ради, это не такая уж тривиальная задача, ибо на старте такие пакеты будут порезаны оператором. Конечно, у кого-то uRPF может и не настроен, но в целом, кажется, это очень ограниченная в реализации атака.
Пару месяцев назад CloudFlare написали в своем бложике об успешно отраженной супер-пупер атаке на 7.3 терабита в секунду, в которой по часть трафика была со спуфнутых IP. Так что это до сих пор работает.
В 2016 у них же в блоге был анализ спуфнутых адресов. Там помимо всего прочего утверждалось, что до CloudFlare доходят сегменты, якобы посланные с адресов приватных блоков, мультикаст, и даже 127/8, который вот никогда вообще не ожидаешь снаружи, но он там есть.
Спору нет, что работает. Вопрос масштабов. Условные десять лет назад такое было куда проще провернуть. В международных сценариях (случай CF) и через десять лет всегда найдётся вариант влить поддельные src IP. Но я вижу что риск атак, например, с ломаных IoT устройств куда более весом и реален, а в перспективе станет ещё больше. Просто не будет иметь смысла искать оператора, через которого можно лить подозрительный трафик, когда можно устроить настоящий DDoS со "стопитсот" легитимных адресов, которые ещё фиг зафильтруешь.
А ещё можно прикрыться с помощью GEOIP от половины интернета.
В наше время на смену iptables пришёл nftables.
Плюс, раз уж статья преподносится как метод защиты от DDOS, можно ожидать, что блокируемых IP будет много. ОЧЕНЬ много. А большие списки IP лучше блокировать средствами ipset.
Плюс, если принимается решение, что некий IP является источником сетевого флуда, есть смысл резать ему все протоколы, а не только TCP.
Защита при DDOS от метода SYN Flood подручными средствами ОС Linux