Pull to refresh

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.
Буду рад, если кто-то улучшит эти варианты. Я не админ, но мне и моим знакомым этого хватает, можно понять это ддос или просто завёлся какой-то краулер, который парсит мой сайты в 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 слушают несколько процессов(нитей)? Но к какому пойдёт следующий коннект?
wc -l не обязателен, у grep есть ключ "-с", который подсчитывает количество полученных строк.
т.е. netstat -na | grep -c ":80\ "
Сам раньше тоже везде считал с помощью wc -l :)
> На какой домен чаще всего идут запросы: tcpdump -npi eth0 port domain

Правда? А вообще-то то же самое записывается как 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'у:

#!/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; }
Я не супер-спец, но разве это не забанит Internet Explorer?
Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0)
Верно, забанит, но в нашем случае клиенты — не обычные браузеры. Вместо Trident подставьте нужную маску.
А fail2ban не пробовали? Настраивается легко и обладает довольно-таки большим функционалом (пару лет назад все было гораздо хуже у него, если мне память не изменяет).
причем его можно настроить на конкретный url, используя в паре с nginx'овским ngx_http_limit_req_module. Недавно так отсек уйму нежелательно трафика. Причем бан гибкий на нужное время, с нужными условиями.
Ради тренеровки (и на будущее) напишите себе скрипт, читающий netstat и блокирующий в iptables айпишники, которые имеют более 50 конектов. Как бонус ведёт лог этих блокировок и через час, например, разблокирует айпишники.
Полагаю, что DDoSом обычно называют атаку как минимум с сотни машин, и в этом случает 10 строчек logtop'а будет маловато. Нормальный же DDoS задействует десятки тысяч машин, и логи читать обычно уже поздно — входящий канал на 100 мбит переполняется одними SYN запросами (даже если они, вдруг, не поддельные)
Для владельцев одного-двух арендованых серверов с каналом 100Мбит/1Гбит проще воспользоваться CloudFlare, чем держать злой файрволл с неизбежными ложными срабатываниями
Замечу, что уже закончившие школу ддосеры осуществляют атаку с правильными юзерагентами (часто рандом по списку), и отличить их от легитимных пользователей по заголовкам запроса невозможно
По поводу рандомных юзерагентов — Вы совершенно правы. Все так и есть.

Все юзерагенты «правильные» и рандомно выбранные по списку. Мало того, в $http_referer каждый раз указывается уникальный сгенерированный сайт (правда фейковый, вроде 6wwro6rq35muk.ru).

Для таких случаев использую доступ по ключу, сгенерированному с солью от IP, который ставится в cookie + если cookie отключены — каждый раз к запросу добавляется уникальный для IP параметр &key= через переадресацию.

Причем там тоже есть свои особенности. Сейчас боты уже научились парсить ответные заголовки (редирект и Cookie) и использовать вытащенную по regexp информацию (тот же уникальный key). Поэтому приходится изголяться. Например установку cookie и переадресацию делать в подключаемом через <script src="..." js-файле чтобы страница не содержала уникального ключа.

Возможно оформлю свои наблюдения в виде отдельной статьи.
а как посоветуете бороться со спаммерами, которые спамят через php-шный 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 трафика.
UFO landed and left these words here
Only those users with full accounts are able to leave comments. Log in, please.