Продолжение-окончание статьи: Пример 7: Атака на провайдера 30-31 мая 2007 года петербургский провайдер Infobox подвергся массированной DDoS-атаке - до 2 Гб в секунду. Атака велась с десятков тысяч адресов, расположенных по всему миру, в том числе из России, Кореи, ОАЭ, Китая. Атаке подвергались DNS сервера. В результате большая часть каналов оказалась перегружена. Cайт, размещенные у провайдера серверы и почтовые ящики были полностью или частично недоступны. Техподдержка сообщила: "Мы стараемся минимизировать ущерб, наносимый атакой, но это достаточно проблематично и может вызывать неудобства для части клиентов (блокировка доступа из сетей крупных провайдеров)". По словам генерального директора "Инфобокса" Алексея Бахтиарова, атака велась с десятков тысяч адресов, расположенных по всему миру". Источник: securitylab.ru, 03.07.07 Для атак такого типа разработаны сложные системы анализа поведения трафика в сети провайдера. Основная сложность информационных потоков в сети любого провайдера: их огромное количество. Человеку не под силу проанализировать такое количество разных соединений в секунду и тут мы вынуждены полагаться на искусственный интеллект систем анализа аномалий. По сути в момент начала приведенной выше DDoS атаки сеть провайдера должна была прекратить принимать запросы от новых IP адресов и пускать в свою сеть только запросы с IP адресов которые приходили ранее при нормальном функционировании системы. Текущие клиенты бы даже не заметили DDoS атаки. Но для этого надо было собирать ежедневно этот белый список. А для этого в сети должна была функционировать система анализа поведения сети, которая бы отличила своих клиентов от нежелательных. Я конечно описываю реакцию системы анализа аномалий достаточно упрощенно. На самом деле в искусственном интеллекте таких систем кроются разработки институтов, годы практического изучения DDoS атак и результаты диссертаций. Программисты уже написали программы которые легко играют в шахматы, что было достаточно непросто - надо было обыграть человека. Точно также защита от DDoS - сложная программа требующая высокой концентрации последних достижений в области анализа трафика, чтобы в автоматическом режиме среагировать на атаку. Методы атаки могут меняться атакующими раз в полчаса и система должна это отследить и предпринять соответствующие меры. Производители таких сложных систем анализа трафика обычно рассказывают какие именно принципы заложены в механизмы защиты только при личной встрече. В этой статье мне тоже не хватит места для их подробного изложения. Попробую лишь раскрыть основные принципы работы. Принцип работы систем защит от DDoS атак Система защиты от DDoS атак базируется на уже имеющихся в сети маршрутизаторах и добавляет в сеть свои два компонента: устройство для блокирования DDoS атаки. В английском языке это устройство называют mitigator. В связи с отсутствием аналогичных статей по данной теме я введу русский термин: буду называть его блокиратор; устройство со встроенным искусственным интеллектом для обнаружения DDoS атаки и перенаправления атаки на блокиратор, буду называть его детектор. Надо заметить, что в задачу блокиратора входит не только блокирование трафика, но и его замедление. После обнаружения DDoS атаки на какую-то сеть анализатор трафика вставляет в таблицы динамической маршрутизации (при помощи BGP или OSPF) запись, которая говорит, что маршрут в атакуемую сеть лежит через этот блокиратор. В результате весь трафик атаки начинает проходить через блокиратор, что дает возможность заблокировать трафик атаки, а легитимный трафик передать в защищаемую сеть. Передача в защищаемую сеть осуществляется любым доступным способом, например при помощи инкапсуляции трафика внутри GRE. После завершения атаки, таблица маршрутизации перенастраивается, чтобы трафик проходил через конечный маршрутизатор, связанный с этой сетью. Более подробно работу рассмотрим на конкретном примере: связка детекторов Arbor SP + с блокиратором Arbor TMS. SP здесь в названии означает Service Provider, а TMS - Threat Management System. Надо заметить, что детекторы Arbor SP часто используются совместно с блокираторами других компаний, например, они совместно работают с Cisco Guard и CloudShield CS-2000. Принцип работы Arbor Threat Management System Arbor TMS выполняет защиту от DDoS атак различных типов. Основным достоинством защиты на базе Arbor TMS является блокирование атак с случайных поддельных IP адресов всего Интернета на все адреса из атакуемой сети, имеющих своей целью переполнение канала. Для обнаружения DoS атаки используется детекторы Arbor SP. Устройства Arbor SP собирают информацию со всех маршрутизаторов и свитчей провайдера о трафике и анализируют его. Сбор информации собирается по любому протоколу сообщения о потоках, например при помощи Cisco NetFlow. Для перенаправления трафика атакуемой сети через устройство Arbor TMS используется протокол BGP. Управление устройством TMS осуществляется через Arbor SP контроллер, который не только управляет, но и собирает flow потоки от маршрутизаторов. Контроллер поддерживает до 5 маршрутизаторов. Каждые новые 5 маршрутизаторов обслуживаются дополнительным коллектором, который собирает flow потоки и передает в контроллер. Для передачи отфильтрованного хорошего трафика обратно в канал используется инкапсуляция GRE или MPLS. При обнаружении DoS атаки коллекторами Arbor SP по протоколу BGP добавляется подходящее устройство TMS как следующий маршрутизатор для атакуемой сети и таким образом трафик автоматически перенаправляется на фильтрующее устройство всеми маршрутизаторами. Существует несколько этапов работы связки Arbor SP+TMS. Обнаружение.Детектор Arbor SP понимает, что началась DDoS атака. Активация защиты. Детектор дает необходимую информацию TMS для его работы. Перенастройка маршрутизации. TMS дает маршутизаторам информацию по протоколу BGP о том какие сети он будет фильтровать. Маршрутизаторы начинают посылать ему трафик предназначенный только для этих сетей. Трафик для других сетей передается так же. Фильтрация. TMS получает трафик и удаляет из него вредоносные пакеты. Перенаправление. TMS перенаправляет полезный трафик клиенту провайдера. Для этого на маршрутизатор к которому подключен клиент передаются пакеты, инкапсулированные внутри GRE. Какие именно защитные механизмы реализованы в Arbor TMS в открытом доступе я не нашел, поэтому рассматриваю эту информацию как конфиденциальную.Пример 8: Эксперт США: Хакерские атаки на Эстонию исходили "не из Кремля" Об этом заявил старший инженер по вопросам безопасности известной американской компании Arbor Networks Хосе Назарио. По его словам, атаки шли с огромного числа компьютеров по всему миру, в том числе из США и Вьетнама. "Ни один из источников, анализ которых мы провели по всему миру, не показывает явную линию из Москвы в Таллин. Вместо этого в Эстонию все шло со всего мира", - сказал Назарио в интервью специализированному журналу IT PRO, посвященному информационным технологиям. По словам Назарио, хакерские атаки, из-за которых в конце апреля некоторое время был блокирован доступ, в частности, на сайты президента Эстонии, МИД, парламента и других ведомств, были глобальными и не исходили из одной страны. Они не были также результатом согласованных усилий какого-либо правительственного ведомства, сказал эксперт. Исследование Arbor Networks показало, что нападения на эстонские интернет-сайты были организованы с использованием гигантских сетей, работающих в автоматическом режиме компьютеров, число которых могло достигать 1 миллиона. Выводы Не всегда провайдеру выгодно защищать вас от DoS атак, поскольку если трафик идет к вам, то вы платите за него, а если провайдер его заблокировал у себя, то за этот трафик платит он. Поэтому подписывая договор оговорите позицию провайдера по блокировке трафика в случае DoS, DDoS и DRDoS атак на вас. Провайдеры могут использовать различные решения для защиты от DDoS атак. Спросите вашего провайдера есть ли они у него вообще и если есть, то какие. Не забудьте про оповещение самих себя об атаках на ваш сервер. Это может быть какая-то автоматизированная система, это может быть собственная дежурная смена, а может быть мониторинг безопасности дежурной сменой специализированной компании. Не стоит экономить на консультантах по информационной безопасности. Для сложных проблем уже найдены хорошие решения как в медицине и технике, так и в области ИБ. Частично материалы статьи взяты тут - www.cyberguru.ru
Подскажите плиз по iptables? правило - Code: A INPUT -p tcp -m tcp --dport 80 -m string --string "GET" --algo kmp -m recent --set --name httpddos --rsource НЕ отрабатывает. В таблицу записывается. Все ок. но iptables -vL INPUT Code: 0 0 tcp -- any any anywhere anywhere tcp dpt:http STRING match "GET" ALGO name kmp TO 65535 recent: SET name: httpddos side: source Пакеты не попадают. по инету читаю, у всех так работает. Заранее спасибо
Оперативная реакция на DDoS-атаки Один из ресурсов, за которым я присматриваю, вдруг стал неожиданно популярным как у хороших пользователей, так и у плохих. Мощное, в общем-то, железо перестало справляться с нагрузкой. Софт на сервере самый обычный — Linux,Nginx,PHP-FPM(+APC),MySQL, версии — самые последние. На сайтах крутится Drupal и phpBB. Оптимизация на уровне софта (memcached, индексы в базе, где их не хватало) чуть помогла, но кардинально проблему не решила. А проблема — большое количество запросов, к статике, динамике и особенно базе. Поставил следующие лимиты в Nginx: на соединения Code: limit_conn_zone $binary_remote_addr zone=perip:10m; limit_conn perip 100; и скорость запросов на динамику (fastcgi_pass на php-fpm) Code: limit_req_zone $binary_remote_addr zone=dynamic:10m rate=2r/s; limit_req zone=dynamic burst=10 nodelay; Сильно полегчало, по логам видно, что в первую зону никто не попадает, зато вторая отрабатывает по полной. Но плохиши продолжали долбить, и захотелось их отбрасывать раньше — на уровне фаервола, и надолго. Сначала сам парсил логи, и особо настырных добавлял через iptables в баню. Потом парсил уже по крону каждые 5 минут. Пробовал fail2ban. Когда понял, что плохишей стало очень много, перенёс их в ipset ip hash. Почти всё хорошо стало, но есть неприятные моменты: — парсинг/сортировка логов тоже приличное (процессорное) время отнимает — сервер тупит, если началась новая волна между соседними разборками (логов) Нужно было придумать как быстро добавлять нарушителей в черный список. Сначала была идея написать/дописать модуль к Nginx + демон, который будет ipset-ы обновлять. Можно и без демона, но тогда придётся запускать Nginx от рута, что не есть красиво. Написать это реально, но понял, что нет столько времени. Ничего похожего не нашёл (может плохо искал?), и придумал вот такой алгоритм. При привышении лимита, Nginx выбрасывает 503-юю ошибку Service Temporarily Unavailable. Вот я решил на неё и прицепиться! Для каждого location создаём свою страничку с ошибкой Code: error_page 503 =429 @blacklist; И соответствующий именованный location Code: location @blacklist { fastcgi_pass localhost:1234; fastcgi_param SCRIPT_FILENAME /data/web/cgi/blacklist.sh; include fastcgi_params; } Дальше интересней. Нам нужна поддержка CGI-скриптов. Ставим, настраиваем, запускаем spawn-fcgi и fcgiwrap. У меня уже было готовое для collectd. Сам CGI-скрипт Code: #!/bin/bash BAN_TIME=5 DB_NAME="web_black_list" SQLITE_DB="/data/web/cgi/${DB_NAME}.sqlite3" CREATE_TABLE_SQL="\ CREATE TABLE $DB_NAME (\ ip varchar(16) NOT NULL PRIMARY KEY,\ added DATETIME NOT NULL DEFAULT (DATETIME()),\ updated DATETIME NOT NULL DEFAULT (DATETIME()),\ counter INTEGER NOT NULL DEFAULT 0 )" ADD_ENTRY_SQL="INSERT OR IGNORE INTO $DB_NAME (ip) VALUES (\"$REMOTE_ADDR\")" UPD_ENTRY_SQL="UPDATE $DB_NAME SET updated=DATETIME(), counter=(counter+1) WHERE ip=\"$REMOTE_ADDR\"" SQLITE_CMD="/usr/bin/sqlite3 $SQLITE_DB" IPSET_CMD="/usr/sbin/ipset" $IPSET_CMD add $DB_NAME $REMOTE_ADDR > /dev/null 2>&1 if [ ! -f $SQLITE_DB ]; then $SQLITE_CMD "$CREATE_TABLE_SQL" fi $SQLITE_CMD "$ADD_ENTRY_SQL" $SQLITE_CMD "$UPD_ENTRY_SQL" echo "Content-type: text/html" echo "" echo "<html>" echo "<head><title>429 Too Many Requests</title></head>" echo "<body bgcolor=\"white\">" echo "<center><h1>429 Too Many Requests</h1></center>" echo "<center><small><p>Your address ($REMOTE_ADDR) is blacklisted for $BAN_TIME minutes</p></small></center>" echo "<hr><center>$SERVER_SOFTWARE</center>" echo "</body>" echo "</html>" Собственно всё очевидно, кроме, разве что, SQLite. Я его добавил пока просто для статистики, но в принципе можно использовать и для удаления устаревших плохишей из черного списка. Время 5 минут пока тоже не используется. Черный список создавался вот так Code: ipset create web_black_list hash:ip Правило в iptables у каждого может быть своё, в зависимости от конфигурации и фантазии. У одного хостера видел услугу управляемого фаервола. Заменив в скрипте ipset add не небольшую curl-сессию, можно фильтровать плохишей на внешнем фаерволе, разгрузив свой канал и сетевой интерфейс. З.Ы.: Улыбнуло сообщение одного «хакера» на форуме, как быстро он положил сервер. Он и не догадывался, что это сервер положил на него. 9.04.2013 http://habrahabr.ru/post/176119/
