Комментарии 26
А что стало с юношей?
если его вычислили, и ddos в России не преступление…
наверное все закончилось народным судом.
наверное все закончилось народным судом.
да ничем не закончилось, кому он нужен, гадкий хулиган
к тому же я и ресурс — уже давно совсем не в России
к тому же я и ресурс — уже давно совсем не в России
Каким-то непонятным языком оперируете. Что за «армия ботов»? Какой стоял сервер конкретно? Какая шла атака? Какая конфигурация оборудования/веб-сервера? Предположу, что вашу беду можно было решить просто правильно настроив сервер.
статья собственно о решении, а не о проблеме
сервер nginx+php-fpm+mysql
армия ботов — откуда я знаю, какие там боты
в банлисте было от 2 до 5 тысяч IP-адресов
боты достаточно примитивные — все долбили один и тот же захардкоженный запрос простоянно
иногда запрос менялся
количество запросов в пике было до 1000 в секунду, то есть просто забивали все соединения, до 50 тысяч ESTABLISHED в netstat
всякие твики в tcp/ip параметрах не особо помогали
как-то в общем так
а блокировка на уровне IP работает отлично, особенно ipset — могучая штука, поначалу пробовали использовать iptables… не надо даже и пробовать было
изначально мы посмотрели на fail2ban, откуда и название, но он показался уж очень громоздким
архитектура задумывалась достаточно гибкая, чтобы перенастроить на автоматическую блокировку IP-адресов по любым доступным наблюдению критериям
сервер nginx+php-fpm+mysql
армия ботов — откуда я знаю, какие там боты
в банлисте было от 2 до 5 тысяч IP-адресов
боты достаточно примитивные — все долбили один и тот же захардкоженный запрос простоянно
иногда запрос менялся
количество запросов в пике было до 1000 в секунду, то есть просто забивали все соединения, до 50 тысяч ESTABLISHED в netstat
всякие твики в tcp/ip параметрах не особо помогали
как-то в общем так
а блокировка на уровне IP работает отлично, особенно ipset — могучая штука, поначалу пробовали использовать iptables… не надо даже и пробовать было
изначально мы посмотрели на fail2ban, откуда и название, но он показался уж очень громоздким
архитектура задумывалась достаточно гибкая, чтобы перенастроить на автоматическую блокировку IP-адресов по любым доступным наблюдению критериям
Тоесть вы не завели fail2ban на защиту от ddos, и сравнит производительность решений не удастся?
НЛО прилетело и опубликовало эту надпись здесь
Добавлять каждый IP-адрес отдельным правилом в iptables — вам ядро не жалко? Вот откуда столько неграмотных людей, которые даже теорию и мануалы не почитав, рвутся писать свои кривоскрипты?
Способ дурацкий, так как автор пишет «до 50 000 established в netstat» — апач не потянет такой нагрузки, тем более на среднем сервере с 200-300 мегабайтами ОЗУ — он и 500 established не потянет.
Способ дурацкий, так как автор пишет «до 50 000 established в netstat» — апач не потянет такой нагрузки, тем более на среднем сервере с 200-300 мегабайтами ОЗУ — он и 500 established не потянет.
во-первых была важна не частота запросов с одного айти, а частота _одинаковых_ запросов, при этом _игнорируя_ статический контент
это в т.ч. форум, с кучей статического контента
одна страница вполне может дать 50 хитов
если просто считать запросы с айпи (что умеет разумеется, и nginx — это давало неприемлемое количество false alarm-ов
во-вторых, iptables на тысяче правил в iptables уже начинает мрачнейше тормозить, ipset тянет десятки тысяч
в-третьих, вы всерьёз рекомендуете апач для высоконагруженных сайтов??
при наличии гораздо более эффективного nginx?
далее к бенчмарку
это в т.ч. форум, с кучей статического контента
одна страница вполне может дать 50 хитов
если просто считать запросы с айпи (что умеет разумеется, и nginx — это давало неприемлемое количество false alarm-ов
во-вторых, iptables на тысяче правил в iptables уже начинает мрачнейше тормозить, ipset тянет десятки тысяч
в-третьих, вы всерьёз рекомендуете апач для высоконагруженных сайтов??
при наличии гораздо более эффективного nginx?
далее к бенчмарку
Всё хорошо, только как я понял, это всё решается более простыми способами.
Более того, это решается вообще без софта с помощью консоли.
Я вот вот сейчас под ддос атакой. Так отбиваю:
запускается раз в 10 минут.
И никакого mongodb… и никакого ip_set… и блин, ни чихает ни кашляет. :)
Более того, это решается вообще без софта с помощью консоли.
Я вот вот сейчас под ддос атакой. Так отбиваю:
#!/bin/bash
PATH=/sbin:/usr/sbin:$PATH
date=`date +"%Y%m%d%H%M"`
iptables -t raw -L PREROUTING -vnxZ | perl -ne 'split/ +/;print "$_[8]\n" if $_[1] ne "0";' | xargs -I {} iptables -t raw -D PREROUTING -s {} -j DROP
log_dir=/var/lib/vservers/perfccc/var/www/logs/typofront/
cd ${log_dir}
pid=`cat /var/lib/vservers/perfccc/var/run/nginx.pid`
mv ${log_dir}/typofront.access.log ${log_dir}/typofront.access.${date}.log
/usr/sbin/vkill -s USR1 ${pid}
grep "GET /experts/extrasensy/index.html HTTP" ${log_dir}/typofront.access.${date}.log | cut -d ' ' -f 1 | sort | uniq -dc | sort -nr | perl -ne 'split /\s+/; print "$_[2]\n" if ($_[1]>30);' | xargs -I {} iptables -t raw -I PREROUTING -s {} -j DROP
/bin/gzip ${log_dir}/typofront.access.${date}.log
запускается раз в 10 минут.
И никакого mongodb… и никакого ip_set… и блин, ни чихает ни кашляет. :)
насчёт -t raw -I PREROUTING спасибо всем сообщившим (вам тоже) — буду знать, полезно
(я же ведь на самом деле не настоящийсварщик админ… )
хотя ipset мне всё же очень понравился, вариантами сетов и скоростью работы, которая по определению (поиск по хеш-таблице) будет _существенно_ быстрее, чем перебор нескольких тысяч правил iptables, хоть бы и на -t raw
по поводу вашего решения
на самом деле, log2ban — это в принципе примерно одно и то же, но
1. с возможностью авторазбанивания (для этого нужна база данных)
2. с гибкой логикой по поводу того, какие запросы игнорировать
3. с гибким определением того, какие запросы считать идентичными (см. ниже *)
4. с анализом логов в реальном времени (10 минут это слишком много — в данной конкретной атаке каждую минуту появлялись новые боты взамен заблокированных), а не в момент ротации
5. с читаемым кодом :)) (ничего личного, на перле я тоже раньше много писал)
*) то есть, скажем, в тот момент, когда боты вдруг поумнеют и начнут слать не один и тот же запрос а, скажем, с какими-то вариациями — в log2ban есть конкретная изолированная функция, куда можно добавить сколь угодно нелинейную логику для анализа
(я же ведь на самом деле не настоящий
хотя ipset мне всё же очень понравился, вариантами сетов и скоростью работы, которая по определению (поиск по хеш-таблице) будет _существенно_ быстрее, чем перебор нескольких тысяч правил iptables, хоть бы и на -t raw
по поводу вашего решения
на самом деле, log2ban — это в принципе примерно одно и то же, но
1. с возможностью авторазбанивания (для этого нужна база данных)
2. с гибкой логикой по поводу того, какие запросы игнорировать
3. с гибким определением того, какие запросы считать идентичными (см. ниже *)
4. с анализом логов в реальном времени (10 минут это слишком много — в данной конкретной атаке каждую минуту появлялись новые боты взамен заблокированных), а не в момент ротации
5. с читаемым кодом :)) (ничего личного, на перле я тоже раньше много писал)
*) то есть, скажем, в тот момент, когда боты вдруг поумнеют и начнут слать не один и тот же запрос а, скажем, с какими-то вариациями — в log2ban есть конкретная изолированная функция, куда можно добавить сколь угодно нелинейную логику для анализа
1) у меня авторазбиниваются боты, от которых в течение 10 минут ни слуху ни духу — то есть отвалившиеся. куда еще автоматичнее?
2) у меня в момент пика стояло 2 минуты, а не 10, просто сейчас атака затихла, и я снизил до 10, при необходимости легко повышается.
3) универсальным решение всё равно не считается — универсальное решение должно еще уметь фильтровать последовательности, то есть по каждому ip надо вести стейтмашину, а если учесть, что некоторые боты за NATом и начинают переплетаться — то еще сложнее. а так, это не сложнее простой регулярки, которая у меня и есть.
2) у меня в момент пика стояло 2 минуты, а не 10, просто сейчас атака затихла, и я снизил до 10, при необходимости легко повышается.
3) универсальным решение всё равно не считается — универсальное решение должно еще уметь фильтровать последовательности, то есть по каждому ip надо вести стейтмашину, а если учесть, что некоторые боты за NATом и начинают переплетаться — то еще сложнее. а так, это не сложнее простой регулярки, которая у меня и есть.
мм, ну если вы бота забанили правилом в iptables, то от него же не будет ни слуху ни духу непосредственно с момента введения этого правила? или я где-то опять торможу?
man iptables:
-Z, --zero [chain [rulenum]]
Zero the packet and byte counters in all chains, or only the given chain, or only the given rule in a chain. It is
legal to specify the -L, --list (list) option as well, to see the counters immediately before they are cleared. (See
above.)
-x, --exact
Expand numbers. Display the exact value of the packet and byte counters, instead of only the rounded number in K's
(multiples of 1000) M's (multiples of 1000K) or G's (multiples of 1000M). This option is only relevant for the -L
command.
Кстати, по теме:
советую просто воспользоваться tail -F
# !! Don't forget to add restart of log2ban.py on log rotation !!
#
ECHO_LOG_COMMAND = "tail -f /var/log/nginx/access.log" # shell command
советую просто воспользоваться tail -F
Совет: Если вы под ддосом, рекомендую сделать iptables -t raw -I PREROUTING -p tcp --dport 80 -j CT --notrack
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Практический эпизод борьбы с DDoS