Сегодня ночью какие-то идиоты пытались DDoS-ить сайт. Не придумали ничего умнее, чем слать много запросов страничек с полусотни компьютеров. Ну это зафильтровалось, естессна. Заодно была возможность потестировать, какие конфигурации скриптов веселее работают.
Пока остановился на комбинации iptables hashlimit + recent. По идее надо бы вместо recent привернуть ipset, но там непонятно, как систить устаревшие записи. У меня пока конечный автомат получился вот такой (это не все правила, только кусок для примера):
iptables -A fw-input -m recent --rcheck --seconds 250 --rttl -j DROP
iptables -A fw-input -m recent --update --seconds 300 --rttl -j DROP
iptables -A fw-input -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A fw-input -p tcp --dport 80 -m state --state NEW -m hashlimit --hashlimit-name blackhole --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 100 -j blackhole
iptables -A blackhole -m recent --set -j DROP
Логика простая - если с какого-то IP поступает слишком много коннектов, то ставим флажок, и для этого этого адреса начинаем прибивать вообще все пакеты, чтобы разорвать установленные соединения тоже.
Но надо модуль recent перегрузить, потому что по умолчанию там только 100 записей вмещается. Идеально было бы как-то напрямую проверять состояние таблицы hashlimit при фильтрации установившихся соединений, но это я еще не додумал.
а я думал, чего за хре…ночью была! на форум не мог зайти!)
Попробуй “-j REJECT --reject-with icmp-host-prohibited” заместо DROP, у меня намного эффективней работает.
Благодаря этому похоже теперь новый рекорд посещаемости сегодня был в 02,39 в 5566 человек, а до этого в районе 1200 было.
Попробуй “-j REJECT --reject-with icmp-host-prohibited” заместо DROP, у меня намного эффективней работает.
А почему? По идее на tcp-флуде лишний траффик.
дроп просто проглатывает трафик и все, но доставляет, а так циска сверху говорит, rc-design - не … не знаю …
Какая разница что ответят, если пакеты все равно мне на интерфейс попадут? Атакующая сторона ведь не прекратит попытки новые соединения делать. А доступа к BGP и т.п. чтобы траффиком рулить, у меня нет.
А ты сравни как пингуется с забаненного IP твой хост при DROP и REJECT
Это не избавляет магическим образом от забивки канала исходящими ICMP-пакетами. Ну выглядеть будет иначе, толку-то…
Второй выглядит так, как будто хост не существует, таблица маршрутизации на время кэшируется и атакующая сторона просто долбит свой кэш 2-3 сек, а не шлет тебе запросы на соединения
На спуфинге-то не сработает, а проблем создаст вагон. Я ж не под конкретную атаку тюню.
Хотя у меня там проверка TTL стоит, чтобы фильтровать спуфинг. Надо подумать. А где почитать про кеширование таблиц роутинга на клиентах и как надолго там фейк застрянет?
{"assets_hash":"a8b26fa7f6e768b07a72c8c9aadb9422","page_data":{"users":{"39c21abc3df9550077797d18":{"_id":"39c21abc3df9550077797d18","hid":349,"name":"Vitaly","nick":"Vitaly","avatar_id":null,"css":""},"45de1b963df9550077786085":{"_id":"45de1b963df9550077786085","hid":20864,"name":"andres24","nick":"andres24","avatar_id":null,"css":""},"48fce88e3df95500777765c0":{"_id":"48fce88e3df95500777765c0","hid":39664,"name":"fff-z","nick":"fff-z","avatar_id":null,"css":""},"4b9603423df95500777637a7":{"_id":"4b9603423df95500777637a7","hid":62450,"name":"evgenyl","nick":"evgenyl","avatar_id":null,"css":""}},"settings":{"blogs_can_create":false,"blogs_mod_can_delete":false,"blogs_mod_can_hard_delete":false,"blogs_mod_can_add_infractions":false,"can_report_abuse":false,"can_vote":false,"can_see_ip":false,"blogs_edit_comments_max_time":30,"blogs_show_ignored":false,"blogs_reply_old_comment_threshold":30,"votes_add_max_time":168},"entry":{"_id":"4d4bd2a9997073007710185b","hid":11098,"title":"Ахтунк! Сайт опасносте!","html":"<p>Колхознеке отаке! Пыщь-пыщь!</p>\n<p>Сегодня ночью какие-то идиоты пытались DDoS-ить сайт. Не придумали ничего умнее, чем слать много запросов страничек с полусотни компьютеров. Ну это зафильтровалось, естессна. Заодно была возможность потестировать, какие конфигурации скриптов веселее работают.</p>\n<p>Пока остановился на комбинации iptables hashlimit + recent. По идее надо бы вместо recent привернуть ipset, но там непонятно, как систить устаревшие записи. У меня пока конечный автомат получился вот такой (это не все правила, только кусок для примера):</p>\n<p>iptables -A fw-input -m recent --rcheck --seconds 250 --rttl -j DROP<br>\niptables -A fw-input -m recent --update --seconds 300 --rttl -j DROP<br>\niptables -A fw-input -m state --state RELATED,ESTABLISHED -j ACCEPT<br>\niptables -A fw-input -p tcp --dport 80 -m state --state NEW -m hashlimit --hashlimit-name blackhole --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 100 -j blackhole<br>\niptables -A blackhole -m recent --set -j DROP</p>\n<!--cut-->\n<p>Логика простая - если с какого-то IP поступает слишком много коннектов, то ставим флажок, и для этого этого адреса начинаем прибивать вообще все пакеты, чтобы разорвать установленные соединения тоже.</p>\n<p>Но надо модуль recent перегрузить, потому что по умолчанию там только 100 записей вмещается. Идеально было бы как-то напрямую проверять состояние таблицы hashlimit при фильтрации установившихся соединений, но это я еще не додумал.</p>\n","user":"39c21abc3df9550077797d18","ts":"2011-02-04T10:19:21.000Z","st":1,"cache":{"comment_count":10,"last_comment":"4d4eced59970730077169498","last_comment_hid":10,"last_ts":"2011-02-06T16:39:49.000Z","last_user":"39c21abc3df9550077797d18"},"views":1211,"bookmarks":0,"votes":0},"subscription":null},"locale":"en-US","user_id":"000000000000000000000000","user_hid":0,"user_name":"","user_nick":"","user_avatar":null,"is_member":false,"settings":{"can_access_acp":false,"can_use_dialogs":false,"hide_heavy_content":false},"unread_dialogs":false,"footer":{"rules":{"to":"common.rules"},"contacts":{"to":"rco-nodeca.contacts"}},"navbar":{"tracker":{"to":"users.tracker","autoselect":false,"priority":10},"forum":{"to":"forum.index"},"blogs":{"to":"blogs.index"},"clubs":{"to":"clubs.index"},"market":{"to":"market.index.buy"}},"recaptcha":{"public_key":"6LcyTs0dAAAAADW_1wxPfl0IHuXxBG7vMSSX26Z4"},"layout":"common.layout"}
