Комментарии 26
ну и для больше комфорта еще и раз в сутки решил перезагружать сервак, опять же через крон
Зачем?!
Написали же: для еще большего комфорта.
Ну до того, как написал свой скрипт, готовые решения не всегда срабатывали и перезагрузка помогала выйти на минуточку из зависания от ддоса и запускать новые вариации скриптов. Ну и здесь, если все-таки система ляжет, то перезагрузка поможет снова запуститься. Мне сложно объяснить зачем это, но вот два логичных объяснения:
1) перезапуск правил iptables, например если айпишник не от ддоса, а просто глюк какой-нить, тогда перезагрузка поможет пользователю на следующий день попасть на сайт.
2) если скрипт блокировки айпишников не смог запуститься через 10 минут, т.к. система уже легла от новой атаки, тогда перезагрузка может оживить сервер
ну и так, для профилактики на одну минутку мона выключать сервер) в 4 часа утра все равно мало кто полезет на сайт ))
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К соединений и очень быстро работал нетстат
Буду рад, если внесете исправление ;)
я за наиоптимальнейший способ отражение атаки!
я за наиоптимальнейший способ отражение атаки!
Я извиняюсь, но зачем «awk '{print $5}' | cut -d: -f1», если можно обойтись одним awk или двумя cut?
netstat -ntu | awk '{split($5, a, ":"); print a[2];}'
Смотрели в сторону github.com/kyprizel/testcookie-nginx-module?
Я могу ошибаться, но всякие куки, скрипты редиректов, по-моему, отсеивают роботов поискоиковиков…
Тут можно использовать скрипт, переключающий конфиг nginx под нагрузкой. И плюс у можуля есть вайтлист.
Кстати, а где взять полный список сетей поисковиков?
Я собирал через www.robtex.com/as/as15169.html#bgp и www.robtex.com/as/as13238.html#bgp
Я собирал через www.robtex.com/as/as15169.html#bgp и www.robtex.com/as/as13238.html#bgp
SniFFeR:
— с помощью данной команды можно исключить из проверки на количество подключение IP адрес самого сервераnetstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n | grep -v "Ваш IP сервера" > /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
немного поправил под себя следующее:
# находим все соединения и записываем их во временный файл 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
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Оптимальная защита от DDoS с помощью netstat и iptables