Comments 21
Моя подборка, лет 5 назад откуда-то скопировал, часто выручают и логи не требуются:
Cколько коннектов на 80 порт: netstat -na | grep ":80\ " | wc -l
На какой домен чаще всего идут запросы: tcpdump -npi eth0 port domain
С какого ip сколько запросов netstat -ntu | awk '{print $5}'| cut -d: -f1 | sort | uniq -c | sort -nr | more
Нагрузка на канал ftop -i eth0 -B
> Cколько коннектов на 80 порт: netstat -na | grep ":80\ " | wc -l
Тут, наверное, еще и греп по ESTABLISHED нужно. А вообще, есть штуки вроде apachetop или HttpStubStatusModule.
Тут, наверное, еще и греп по ESTABLISHED нужно. А вообще, есть штуки вроде apachetop или HttpStubStatusModule.
Буду рад, если кто-то улучшит эти варианты. Я не админ, но мне и моим знакомым этого хватает, можно понять это ддос или просто завёлся какой-то краулер, который парсит мой сайты в 30 потоков.
jnettop в коллекцию тогда.
Помогает смотреть в реальном времени что происходит на сервере с каналом, как и чем он забивается и что куда идёт.
Помогает смотреть в реальном времени что происходит на сервере с каналом, как и чем он забивается и что куда идёт.
Cколько коннектов на 80 порт: netstat -na | grep ":80\ " | wc -l
Если DDoS будет более-менее успешным, вы сервак добьёте этой операцией. Вот тут я приводил пример на ~40к соединениях. В таких случаях
ss даёт фору.
Спасибо за «наводочку» с ss — как говорится век живи — век учись.
А не могли бы Вы разъяснить вот этот вывод (так сказать для более глубокого понимания):
tcp LISTEN 0 128 :::80
users:((«apache2»,26387,4),(«apache2»,10686,4),(«apache2»,10685,4),(«apache2»,10684,4),(«apache2»,10683,4),(«apache2»,10677,4),(«apache2»,10365,4),(«apache2»,10364,4),(«apache2»,10363,4),(«apache2»,10362,4),(«apache2»,10361,4))
это означает, что порт 80 слушают несколько процессов(нитей)? Но к какому пойдёт следующий коннект?
А не могли бы Вы разъяснить вот этот вывод (так сказать для более глубокого понимания):
tcp LISTEN 0 128 :::80
users:((«apache2»,26387,4),(«apache2»,10686,4),(«apache2»,10685,4),(«apache2»,10684,4),(«apache2»,10683,4),(«apache2»,10677,4),(«apache2»,10365,4),(«apache2»,10364,4),(«apache2»,10363,4),(«apache2»,10362,4),(«apache2»,10361,4))
это означает, что порт 80 слушают несколько процессов(нитей)? Но к какому пойдёт следующий коннект?
wc -l не обязателен, у grep есть ключ "-с", который подсчитывает количество полученных строк.
т.е. netstat -na | grep -c ":80\ "
Сам раньше тоже везде считал с помощью wc -l :)
т.е. netstat -na | grep -c ":80\ "
Сам раньше тоже везде считал с помощью wc -l :)
> На какой домен чаще всего идут запросы: tcpdump -npi eth0 port domain
Правда? А вообще-то то же самое записывается как
(Это называется script kiddies.)
Правда? А вообще-то то же самое записывается как
port 53 и всего лишь показывает DNS трафик.(Это называется script kiddies.)
Спасибо за наводку про logtop, актуально. Кстати, одного нашего клиента тоже последние две недели атакуют с юзер-агентом «Trident/4.0; SLCC2; .NET CLR 2.0.191602; .NET CLR 3.5.191602; .NET CLR 3.0.191602» и разными его вариациями.
Делюсь своим скриптом, добавляющим правила в iptables по подсетям /24 по этому user-agent'у:
Делюсь своим скриптом, добавляющим правила в iptables по подсетям /24 по этому user-agent'у:
#!/bin/bash
while [ 1 ]; do
cat /var/log/nginx/nginx_access.log | grep "Trident" | awk '{print $1}'| awk -F"." '{print $1"."$2"."$3".0/24"}' | sort | uniq -c | sort -nr > /root/trident.list
cat /dev/null > /root/iptables_trident_ban.sh
awk '{print "IP=" $2 "\nRULE=\"iptables -I INPUT 1 -p tcp --dport 80 -s " $2 " -j DROP\"\nif iptables-save | grep -- \"$IP\" ; then echo \"skip\"; else `$RULE`; fi" }' /root/trident.list | head -n 500 >> /root/iptables_trident_ban.sh
bash /root/iptables_trident_ban.sh
cat /dev/null > /var/log/nginx/nginx_access.log
[ ! -f /var/run/nginx.pid ] || kill -USR1 `cat /var/run/nginx.pid`
done
Кстати, довольно эффективно работает проверка по U-A в nginx (при правильной настройке самого nginx):
if ($http_user_agent ~* "Trident") {
return 403;
}
А fail2ban не пробовали? Настраивается легко и обладает довольно-таки большим функционалом (пару лет назад все было гораздо хуже у него, если мне память не изменяет).
Ради тренеровки (и на будущее) напишите себе скрипт, читающий netstat и блокирующий в iptables айпишники, которые имеют более 50 конектов. Как бонус ведёт лог этих блокировок и через час, например, разблокирует айпишники.
Полагаю, что DDoSом обычно называют атаку как минимум с сотни машин, и в этом случает 10 строчек logtop'а будет маловато. Нормальный же DDoS задействует десятки тысяч машин, и логи читать обычно уже поздно — входящий канал на 100 мбит переполняется одними SYN запросами (даже если они, вдруг, не поддельные)
Для владельцев одного-двух арендованых серверов с каналом 100Мбит/1Гбит проще воспользоваться CloudFlare, чем держать злой файрволл с неизбежными ложными срабатываниями
Замечу, что уже закончившие школу ддосеры осуществляют атаку с правильными юзерагентами (часто рандом по списку), и отличить их от легитимных пользователей по заголовкам запроса невозможно
Для владельцев одного-двух арендованых серверов с каналом 100Мбит/1Гбит проще воспользоваться CloudFlare, чем держать злой файрволл с неизбежными ложными срабатываниями
Замечу, что уже закончившие школу ддосеры осуществляют атаку с правильными юзерагентами (часто рандом по списку), и отличить их от легитимных пользователей по заголовкам запроса невозможно
По поводу рандомных юзерагентов — Вы совершенно правы. Все так и есть.
Все юзерагенты «правильные» и рандомно выбранные по списку. Мало того, в $http_referer каждый раз указывается уникальный сгенерированный сайт (правда фейковый, вроде 6wwro6rq35muk.ru).
Для таких случаев использую доступ по ключу, сгенерированному с солью от IP, который ставится в cookie + если cookie отключены — каждый раз к запросу добавляется уникальный для IP параметр &key= через переадресацию.
Причем там тоже есть свои особенности. Сейчас боты уже научились парсить ответные заголовки (редирект и Cookie) и использовать вытащенную по regexp информацию (тот же уникальный key). Поэтому приходится изголяться. Например установку cookie и переадресацию делать в подключаемом через <script src="..." js-файле чтобы страница не содержала уникального ключа.
Возможно оформлю свои наблюдения в виде отдельной статьи.
Все юзерагенты «правильные» и рандомно выбранные по списку. Мало того, в $http_referer каждый раз указывается уникальный сгенерированный сайт (правда фейковый, вроде 6wwro6rq35muk.ru).
Для таких случаев использую доступ по ключу, сгенерированному с солью от IP, который ставится в cookie + если cookie отключены — каждый раз к запросу добавляется уникальный для IP параметр &key= через переадресацию.
Причем там тоже есть свои особенности. Сейчас боты уже научились парсить ответные заголовки (редирект и Cookie) и использовать вытащенную по regexp информацию (тот же уникальный key). Поэтому приходится изголяться. Например установку cookie и переадресацию делать в подключаемом через <script src="..." js-файле чтобы страница не содержала уникального ключа.
Возможно оформлю свои наблюдения в виде отдельной статьи.
а как посоветуете бороться со спаммерами, которые спамят через php-шный mail()?
в свое время для >=php5.3 я начал использовать лог вызовов
потом, посредством ротации, я получаю на почту количество писем (вызовов mail()) каждым из скриптов
в свое время для >=php5.3 я начал использовать лог вызовов
mail.add_x_header = On
mail.log = /var/log/sendmail-php.log
потом, посредством ротации, я получаю на почту количество писем (вызовов mail()) каждым из скриптов
cat /var/log/sendmail-php.log | egrep -o '\/.+\.php'| sort | uniq -c | mail -s "sendmail-php log" my.mail.fetcher@domain.com
Не так давно писал пост на подобную тему — фаервол на lua_nginx. Это требует больше телодвижений по настройке, но результат сильно умнее разбора логов + перемалывает 10Г входящего http трафика.
Sign up to leave a comment.
Пара полезных команд, которые могут пригодиться при DDoS и не только