Как стать автором
Обновить

Комментарии 26

ну и для больше комфорта еще и раз в сутки решил перезагружать сервак, опять же через крон

Зачем?!
Написали же: для еще большего комфорта.
Ну до того, как написал свой скрипт, готовые решения не всегда срабатывали и перезагрузка помогала выйти на минуточку из зависания от ддоса и запускать новые вариации скриптов. Ну и здесь, если все-таки система ляжет, то перезагрузка поможет снова запуститься. Мне сложно объяснить зачем это, но вот два логичных объяснения:
1) перезапуск правил iptables, например если айпишник не от ддоса, а просто глюк какой-нить, тогда перезагрузка поможет пользователю на следующий день попасть на сайт.
2) если скрипт блокировки айпишников не смог запуститься через 10 минут, т.к. система уже легла от новой атаки, тогда перезагрузка может оживить сервер
ну и так, для профилактики на одну минутку мона выключать сервер) в 4 часа утра все равно мало кто полезет на сайт ))
НЛО прилетело и опубликовало эту надпись здесь
это скорее старое обычное действие при зависании системы «а вы пробовали выключить и включить?» ;)
а вообще он и не нужен, так уж, для переперестарховки (пере — это не опечатка, а усиление акцента)
А какие на сегодняшний день есть HTTP 1.0 клиенты? Даже links и curl по умолчанию используют 1.1. Можно ли в таких случаях блокировать всех, кто обращается с HTTP 1.0?
На самом деле я не знаю что это )
Но логи соединения именно такие были:
2013/11/26 13:58:15 [error] 737#0: *16080 limiting connections by zone "perip", client: 91.191.234.194, server: mysite.ru, request: "GET / HTTP/1.0", host: "mysite.ru", referrer: "http://mysite.ru/"
2013/11/26 13:58:15 [error] 737#0: *16077 limiting connections by zone "perip", client: 91.191.234.194, server: mysite.ru, request: "GET / HTTP/1.0", host: "mysite.ru", referrer: "http://mysite.ru/"
2013/11/26 13:58:15 [error] 737#0: *16081 limiting connections by zone "perip", client: 91.191.234.194, server: mysite.ru, request: "GET / HTTP/1.0", host: "mysite.ru", referrer: "http://mysite.ru/"
2013/11/26 13:58:15 [error] 737#0: *16038 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 91.191.234.194, server: mysite.ru, request: "GET / HTTP/1.0", upstream: "http://127.0.0.1:3000/", host: "mysite.ru", referrer: "http://mysite.ru/"
2013/11/26 13:58:15 [error] 737#0: *16035 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 91.191.234.194, server: mysite.ru, request: "GET / HTTP/1.0", upstream: "http://127.0.0.1:3000/", host: "mysite.ru", referrer: "http://mysite.ru/"
2013/11/26 13:58:15 [error] 737#0: *16023 connect() failed (110: Connection timed out) while connecting to upstream, client: 91.191.234.194, server: mysite.ru, request: "GET / HTTP/1.0", upstream: "http://127.0.0.1:3000/", host: "mysite.ru", referrer: "http://mysite.ru/"
2013/11/26 13:58:17 [error] 737#0: *16082 limiting connections by zone "perip", client: 91.191.234.194, server: mysite.ru, request: "GET / HTTP/1.0", host: "mysite.ru", referrer: "http://mysite.ru/"
2013/11/26 13:58:19 [error] 737#0: *16051 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 91.191.234.194, server: mysite.ru, request: "GET / HTTP/1.0", upstream: "http://127.0.0.1:3000/", host: "mysite.ru", referrer: "http://mysite.ru/"
2013/11/26 13:58:19 [error] 737#0: *16090 limiting connections by zone "perip", client: 91.191.234.194, server: mysite.ru, request: "GET / HTTP/1.0", host: "mysite.ru", referrer: "http://mysite.ru/"
Под бан попадёт гейт любого провайдера, за которым сидит хотя бы несколько десятков интересующихся вашим сервисом честных пользователей. Низачот, на пересдачу.
Ну тогда просто поднять планку не 20, а 50 или 100 в строке
# создаем DROP правила для 50 самых агрессивных ботов
awk '{if ($1 > 20) {print "/sbin/iptables -I INPUT -p tcp --dport 80 -s " $2 " -j DROP" }}' /tmp/ddos.iplist >> /tmp/iptables_ban.sh
Ну и еще как вариант, скрипт активировать только во время атак, а у меня лично со всего мира редко бывают случаи, когда с одного айпишника идут одновременно больше 10 человек ;)
Критерий оптимальности можно услышать?
Да, конечно, нажми на «Say It» на сайте text-to-speech.imtranslator.net

А вообще отличие от других скриптов — это захват всех айпишников, которые контачат с сервером, без какой-либо дополнительной нагрузки, типа открывания логов ошибок…
При количестве коннектов over 5000 netstat будет тупить от минуты и более.
Правило iptables на каждый IP тоже не вариант. Для этого был придуман ipset.
у мне было 10К соединений и очень быстро работал нетстат
будет 100К и Линукс устанет считать. Фряха не против, линуксу эта нагрузка в часы пик может боком выйти. Пользуйте ss вместо netstat. Считаю им коннекты для заббикса раз в 30сек практически без оверхеда
Буду рад, если внесете исправление ;)
я за наиоптимальнейший способ отражение атаки!
Я извиняюсь, но зачем «awk '{print $5}' | cut -d: -f1», если можно обойтись одним awk или двумя cut?

netstat -ntu | awk '{split($5, a, ":"); print a[2];}'
Ну просто такая запись была общепринятой в инете )
Везде она в таком виде использовалась
Я могу ошибаться, но всякие куки, скрипты редиректов, по-моему, отсеивают роботов поискоиковиков…
Тут можно использовать скрипт, переключающий конфиг nginx под нагрузкой. И плюс у можуля есть вайтлист.
SniFFeR:
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n | grep -v "Ваш IP сервера" > /tmp/ddos.iplist
— с помощью данной команды можно исключить из проверки на количество подключение IP адрес самого сервера
полезная статья — спасибо
немного поправил под себя следующее:

# находим все соединения и записываем их во временный файл ddos.iplist в каталоге tmp
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n > /tmp/ddos.iplist

заменил на
# находим все соединения и записываем их во временный файл ddos.iplist в каталоге tmp
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr > /tmp/ddos.iplist

это чтобы в файле сначала шли IP с большим количеством обращений — просто для наглядности

еще закрывал доступ не просто по 80 порту, а по всем портам и протоколам, так как атака может идти на тот же подбор паролей по SSH или FTP

то есть блокировку выполнял так:
iptables -A INPUT -s 192.230.77.217 -j DROP
iptables -A INPUT -d 192.230.77.217 -j DROP
Дельное замечание! Спасибо!
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории