В нашем блоге на Хабре мы пишем не только о развитии нашего облачного проекта 1cloud, но и рассказываем о том, как решать те или иные технологические задачи. Летом 2015 года в блоге проекта NGINX появился материал о том, как с его помощью можно противостоять DDoS-атакам. Заметка показалась нам интересной, поэтому мы приводим здесь ее основные моменты.Читать полностью »
Команда Cloudfare на днях обнаружила необычную DDoS-атаку. Для проведения этой атаки злоумышленники использовали мобильную рекламу, благодаря чему удалось сгенеррировать DDoS с мощностью до 275000 HTTP-запросов в секунду. Атака была обнаружена достаточно быстро благодаря тому, что злоумышленники для ее проведения использовали клиентский сайт сервиса.
Данный тип флуда уже был известен как Layer 7 HTTP-флуд, при этом специалисты считали, что организовать подобную атаку весьма непросто. Тем не менее, неизвестным (пока) злоумышленникам это удалось благодаря внедрению соответствующего JavaSript в рекламу. Так удалось получить постоянный и очень сильный поток трафика, который направлялся на целевой сайт. Всего был зафиксировано более 4,5 миллионов запросов за сутки.
Вы даже не представляете, какие драмы могут разворачиваться в такой мирной, казалось бы, отрасли, как торговля пиццей. В одной из них довелось поучаствовать и нам, как облачному провайдеру: в декабре 2013 года «Империя пиццы» — один из клиентов Cloud4Y и крупнейшая сеть доставки пиццы в Москве и Московской области, начала интенсивную экспансию на новые территории, на которых уже присутствовали другие игроки.
И у пиццы есть тёмная сторона
Все бы ничего, но имперская ценовая политика в сфере предоставления услуг быстрого питания для его конкурентов имела демпинговый характер. Началась война на всех фронтах, и вскоре в ход пошли DDoS-атаки.
Читать полностью »
В моем случае, в качестве frontend сервера, стоит nginx и формат access-лога имеет вид:
log_format main '$remote_addr — $remote_user [$time_local] "$host" "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" -> $upstream_response_time';
Что на выходе дает что-то вроде такой строки:
188.142.8.61 — - [14/Sep/2014:22:51:03 +0400] «www.mysite.ru» «GET / HTTP/1.1» 200 519 «6wwro6rq35muk.ru/» «Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.191602; .NET CLR 3.5.191602; .NET CLR 3.0.191602» "-" -> 0.003
1. tail -f /var/log/nginx/nginx.access.log | cut -d ' ' -f 1 | logtop
Позволяет получить общую картину: распределение уникальных IP, с которых идут запросы, кол-во запросов с одного IP и т.д.
Самое ценное — что все это работает в режиме реального времени и можно мониторить ситуацию, внося какие-либо изменения в конфигурацию (например просто забанить ТОП 20 самых активных IP через iptables или временно ограничить географию запросов в nginx через GeoIP http://nginx.org/ru/docs/http/ngx_http_geoip_module.html).
Читать полностью »
Знаете ли Вы, что по данным исследований, проведённых Arbor Networks, Verisign Inc. и некоторыми другими компаниями:
Каким бывает DDoS, можно ли с ним бороться и как можно предостеречься? Об этом я вкратце поведаю в данной статье.
Недавно REG.RU совместно с компанией DDoS Guard представил бесплатную 
автоматическую защиту от DDoS-атак. Защита срабатывает автоматически и способна выдержать атаку со скоростью более 100 Гбит/с, что позволяет избежать отключения серверов и сайтов, а, следовательно, потери клиентов и прибыли.
Проблема борьбы с DDoS-атаками встает перед всеми хостинг-провайдерами без исключения. Классические методы борьбы предполагают временную недоступность атакованного сайта, однако REG.RU и DDoS Guard смогли найти пути решения этой проблемы. Но обо всем по порядку.
Читать полностью »
DDoS-ом сейчас никого не удивишь — его используют многие, от военных организаций до обычных школьников, которые решили «подвесить» бложек своего одноклассника. До недавнего времени DDoS-или по большей части отдельные сайты (даже Хабр не избежал этой участи).
Но с недавнего времени ддосить стали не только отдельно взятые ресурсы, но и целые дата-центры, причем не самые мелкие. Согласно отчету Worldwide Security Report от Arbor Network, большинство представителей сервис-провайдеров считают DDoS одной из наиболее опасных угроз для бизнеса.
Доброго времени суток!
Совсем недавно столкнулся с такой проблемой, как DDoS. Сразу скажу, я вообще ни разу не линуксойд, но зато чуточку программист, так что все что ниже, основано чисто на логике, а не на фактах, плюс переписанное с некоторыми добавками от уже известного.
Перекопав полчища статей и опробовав множество вариантов, ничто так и не помогло. Взяв за основу статьи Простой и эффективный метод отразить http DDoS от 50мбит с помощью nginx и iptables и (D)DoS Deflate решил написать свой скрипт. Ну вернее не решил, а методом тыка и исправлений он получился сам.
Должен заметить, что статья от Алексея Кузьмина не идеальна, т.к. в логах nginx`a не достаточно копаться, да и обработка логов может потребовать много ресурсов. А именно в моем случае создавались логи более 50 Гиг, плюс запросы шли не «GET / HTTP/1.1», а «GET / HTTP/1.0», плюс, как оказалось, мой сервер сам от себя получал редиректы (127.0.0.1), которые не отображались в логах, которые отображались в запросе
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n
Сегодня ночью в СМИ появилась информация о DDOS атаки на сайт Министерства Внутренних Дел Украины. Когда я вчера пытался зайти на сайт МВД — он отдавал 503 ошибку. Сейчас загружается через раз.Читать полностью »
Уважаемые хабро-читатели, прежде чем перейти к сути хочу сразу сказать, что автор не является каким бы то ни было хакером или зловредным программером, исследующим со свечкой каждый темный угол драйвера или чего-либо другого программного, поэтому если об этой уязвимости уже известно, то не судите строго, а лучше посоветуйте патч.
Итак, в процессе отладки стека протоколов для сетей MANET, где тестировалось модифицированное ТСР-соединение радиосети с компьютером через Ethernet-шлюз, было случайно выявлено, что путем некорректного закрытия соединения клиентом на стороне сервера возможно удерживание ресурсов сокета бесконечно долго!
Началось всё с этого:
На скрин-шоте представлено ТСР-соединение между клиентом 192.168.0.108 (Ethernet шлюз) и сервером 192.168.0.187 (OS Windows Vista).
Как видно, при неправильном указании номера последовательности в пакете FIN ACK клиента, Windows сервер не закрыл сокет и не освободил ресурсы. Попытка соединиться еще раз с того же порта клиента (source port 40400) на порт сервера (destination port 31000) оказалась неуспешной. Сервер упорно требовал ACK в ответ на новый SYN от клиента.
Сначала, я решил что это просто какой-то баг на стороне стека MANET (помимо, конечно же, неправильного seqno в FIN ACK), но проанализировав поток по номерам sequence / acknowledgement и повторив этот же эксперимент для других портов оказалось, что таки да, Windows…
Пример другого порта сервера (30000):
Потом, перегрузив комп и повторили все еще раз. На этот раз соединение закрывал клиент, а сервер слушал порт 32000.
Результат тот же.
Читать полностью »