Showing posts with label DDoS. Show all posts
Showing posts with label DDoS. Show all posts
Monday, 16 May 2011
Thursday, 3 June 2010
BGP Blackhole как защита от DDoS
Что это такое: http://m.habrahabr.ru/post/91574/
Friday, 26 March 2010
Wednesday, 17 March 2010
Пример 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 бот будет забанен.
Monday, 25 January 2010
Определение DoS/DDoS атак на сервер
Часто меня спрашивают, как узнать - идет ли DoS атака на сервер? С одной стороны это очевидно, но далеко не для всех и далеко не всегда. В этом посте постараюсь собирать все формальные признаки атак, по которым их можно легко определить.
Во-первых, посомтрим число процессов Апача:
Либо в случае ОС CentOS5/RHEL:
Если их более 20-30, то это уже повод для беспокойства.
Далее обязательно просмотреть глобальные логи Апача на предмет наличия аномалий (например, запросов без указания вихоста):
И для CentOS:
Далее, стоит просмотреть логи всех сайтов (например, в случае использования панели ISPManager они лежат в папке /var/www/httpd-logs) и обратить особое внимание на самые большие из них.
Если "большой" лог найден, то его стоить проанализировать на предмет аномалий следующим образом:
Эта команда укажет число запросов до сайта с уникальных айпи, вывод ее будет в виде:
Таким образом, если какой-то IP / блок айпи заваливает сайт запросами, это будет видно по резко уходящим в верх значениям запросов для IP злоумышленников.
Если же используется Nginx, то также обязательно просматривать логи:
Продолжение следует :)
Во-первых, посомтрим число процессов Апача:
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
Продолжение следует :)
Saturday, 16 January 2010
Защита от 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
Только будьте аккуратны и себя не забаньте :)
Tuesday, 12 January 2010
Как определить неизвестный тип атаки на сервер?
Ставим сниффер пакетов:
Запускаем и смотрим трафик:
apt-get install tcpdump -y
Запускаем и смотрим трафик:
tcpdump -i eth0
Thursday, 7 January 2010
Защита от распределенной HTTP GET DoS атаки
Кроме разновидности DDoS атак, когда каждый бот открывает большое число потоков до жертвы, есть разновидность, когда каждый бот открывает не боле одного потока, но долбит большим числом соединений с небольшой задержкой между ними.
Кстати, странно то, что некоторые большие значения hitcount / seconds модуль отвергает ошибкой "iptables: Invalid argument".
То есть, каждый клиент может сделать максимум 100 соединений за 10 минут, а все остальные будут отброшены. Как понимаете, нормальный человек такой сделать не в силах, а вот бот как раз :)
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.conf самым первым.
И после этого сделать reload Nginx у:
источник: https://calomel.org/nginx.html
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
Subscribe to:
Posts
(
Atom
)