Как определить Google Bot при обращении к страницам сайта?

http://www.google.com/support/webmasters/bin/answer.py?answer=80553

BGP Blackhole как защита от DDoS

Что это такое: http://m.habrahabr.ru/post/91574/

Отличная подборка статей по защите от DDoS атак

Рекомендую: http://www.antiddos.org/index.php?option=com_content&view=section&layout=blog&id=5&Itemid=48

Пример Python скрипта защиты от DoS / DDoS атак посредством анализа логов

#!/usr/bin/python
# -*- coding: utf-8 -*-

import tailer
import re
import os

ips = {}

for line in tailer.follow(open('/var/log/nginx/access.log')):
m = re.match('^(\d+.\d+.\d+.\d+).*?- 400 0 "-" "-" "-" 0.000--$', line)

if m:
print "Blank DoS request: %s" % line

ip = m.group(1)

print "ban ip: %s" % ip
os.system("ban_ip.sh %s" % ip)

m_bot = re.match("^(\d+.\d+.\d+.\d+).*?GET /someurl/ .*?$", line)

if m_bot:
ip = m_bot.group(1)


if ips.has_key(ip):
ips[ip] = ips[ip] + 1

if ips[ip] > 100:
print "ban ip %s" % ip
os.system("ban_ip.sh %s" % ip)
else:
ips[ip] = 0



print "Bot detected request %s ip: %s" % ( ips[ip], ip )
print line

В данном случае после 100 запросов к someurl бот будет забанен.

Определение DoS/DDoS атак на сервер

Часто меня спрашивают, как узнать - идет ли DoS атака на сервер? С одной стороны это очевидно, но далеко не для всех и далеко не всегда. В этом посте постараюсь собирать все формальные признаки атак, по которым их можно легко определить.

Во-первых, посомтрим число процессов Апача:

ps aux | grep apache | wc -l

Либо в случае ОС CentOS5/RHEL:

ps aux | grep httpd | wc -l

Если их более 20-30, то это уже повод для беспокойства.

Далее обязательно просмотреть глобальные логи Апача на предмет наличия аномалий (например, запросов без указания вихоста):

/var/log/apache2/error.log
/var/log/apache2/access.log

И для CentOS:

/var/log/httpd/error.log
/var/log/httpd/access.log

Далее, стоит просмотреть логи всех сайтов (например, в случае использования панели ISPManager они лежат в папке /var/www/httpd-logs) и обратить особое внимание на самые большие из них.

Если "большой" лог найден, то его стоить проанализировать на предмет аномалий следующим образом:

cat log_type.log | awk '{print $1}' | sort | uniq -c

Эта команда укажет число запросов до сайта с уникальных айпи, вывод ее будет в виде:

14 95.67.xx.xx
21 95.68.xx.xx
25 95.68.xx.xx
15 95.68.xx.xx
15 95.68.xx.xx
1 95.69.xx.xx
15 95.70.xx.xx
1 95.70.xx.xx
21 95.70.xx.xx
24 95.70.xx.xx
22 95.70.xx.xx
15 95.70.xx.xx
17 95.70.xx.xx
1 95.70.xx.xx

Таким образом, если какой-то IP / блок айпи заваливает сайт запросами, это будет видно по резко уходящим в верх значениям запросов для IP злоумышленников.

Если же используется Nginx, то также обязательно просматривать логи:

/var/log/nginx/error.log
/var/log/nginx/access.log

Продолжение следует :)

Защита от DoS/DDoS атак посредством анализа логов (access.log) и фаерволла

cat access.log | awk '{print $1}' | sort | uniq -c | awk '{if($1>50){print $1 " " $2}}' | awk '{print $2}' > /tmp/ips

Также кроме безусловного анализа есть атаки, когда в логе появляются крайне странные записи примерно такого вида:

94.180.27.51 - - [17/Mar/2010:16:28:45 +0300] xxx.net 88.198.45.197 - 400 0 "-" "-" "-" 0.000--
94.180.27.51 - - [17/Mar/2010:16:28:46 +0300] xxx.net 88.198.45.197 - 400 0 "-" "-" "-" 0.000--
94.180.27.51 - - [17/Mar/2010:16:28:46 +0300] xxx.net 88.198.45.197 - 400 0 "-" "-" "-" 0.000--
94.180.27.51 - - [17/Mar/2010:16:28:46 +0300] xx.net 88.198.45.197 - 400 0 "-" "-" "-" 0.000--
94.180.27.51 - - [17/Mar/2010:16:28:46 +0300] xxx.net 88.198.45.197 - 400 0 "-" "-" "-" 0.000--
94.180.27.51 - - [17/Mar/2010:16:28:46 +0300] xxx.net 88.198.45.197 - 400 0 "-" "-" "-" 0.000--

Для них правило будет вот такое:

cat access.log | grep '400 0 "-" "-" "-" 0.000--' | awk '{print $1}' | sort | uniq > /tmp/ips

Теперь узнаем свой IP:

w | grep 'root' | awk '{print $3}'

IP сервера:

ifconfig -a | grep 'inet addr' | tr ':' ' ' | awk '{print $3}'

И удаляем их из списка.

И теперь достаточно одной команды, чтобы всех забанить:

for ip in `cat /tmp/ips`; do iptables -I INPUT -p tcp --dport 80 -s $ip -j DROP ; done

Только будьте аккуратны и себя не забаньте :)

Как определить неизвестный тип атаки на сервер?

Ставим сниффер пакетов:

apt-get install tcpdump -y

Запускаем и смотрим трафик:

tcpdump -i eth0

Защита от распределенной HTTP GET DoS атаки

Кроме разновидности DDoS атак, когда каждый бот открывает большое число потоков до жертвы, есть разновидность, когда каждый бот открывает не боле одного потока, но долбит большим числом соединений с небольшой задержкой между ними.

iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --name http --set
iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --name http --update --seconds 60 --hitcount 20 -j DROP

Кстати, странно то, что некоторые большие значения hitcount / seconds модуль отвергает ошибкой "iptables: Invalid argument".

То есть, каждый клиент может сделать максимум 100 соединений за 10 минут, а все остальные будут отброшены. Как понимаете, нормальный человек такой сделать не в силах, а вот бот как раз :)

Защита Nginx от DoS ботов, не передающих хидер host

За свою практику очень часто сталкивался с ботами, которые долбят сервер по IP не передавая какой-либо конкретный виртуальный хост (host заголовок http запроса).

Nginx разумеется, их обслуживает как честных клиентов, посылая в ответ им 400й код, тратя на это ресурсы. Для того, чтобы сэкономить и эти ресурсы, у Nginx есть специальный код ответа - 444, который делает следующее:

Nginx understands that if you want to send the client the 444 error code (only 400-417 and 500-505 are allowed by RFC) then Nginx should just close the connection to the client. Just dropping the connection and sending an empty TCP reset packet to the client will deny scanner information about the server and _may_ confuse them.

Иными словами, он просто закрывает сокет, никаким образом не затрудняясь на корректный ответ клиенту.

Вот этот сервер необходимо добавить в конфиг файл nginx.conf самым первым.

server {
listen 80;
server_name _; #default
# access_log /var/log/nginx/localhost.access.log;
return 444;
}

И после этого сделать reload Nginx у:

/etc/init.d/nginx reload

источник: https://calomel.org/nginx.html