Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Механика DDoS           Крижановский Александр              ak@natsys-lab.com10/23/12
«Механика»●   Чем в среднем отличается DdoS от flash crowd (не исчерпывающее    описание и без специальных случаев)●   Про...
Нормальный HTTP трафик●   Запросы достаточно большие за счет Cookie и URL (~1KB, часто    больше)●   Ответ — Web-страница ...
HTTP DDoS трафик●   Запросы часто сильно меньше (десятки или сотни байт)●   Ответов сервера сильно меньше, чем получаемых ...
Nginx, netstat, grep, fail2ban и др.●   Посмотреть netstatом соединения и добавить правила в Iptables●   Погрепать access....
Обработка лимита (Nginx)epoll_wait(12, {{EPOLLIN, ....}}, 512, 500) = 1recvfrom(3, "GET / HTTP/1.1rnHost: ....", 1024, 0, ...
Горячая точка (Nginx, без логов)samples   %         image name           symbol name496099     1.5719   nginx             ...
Nginx и DDoS●   Логировать запросы от ботов дорого●   Парсить логи тоже дорого●   Вместо логирования лимитов – простой мод...
Обработка пакетов●   Параллельность: MSI-X, irq round-    robin●   RPS (Receive Packet Steering)    позволяет «разбрасыват...
User space vs Kernel●   Более 15 context switch●   Kernel/userspace копирования запросов и ответов●   Zero-copy network IO...
Kernel HTTP-акселераторы●   Первая половина 2000x: TUX (Linux), OpenKETA (FreeBSD), khttpd    (Linux) и комерческие прокет...
L7 DDoS-mitigation HTTP-акселератор:               специальный случай●   Нужно минимизировать накладные расходы на обработ...
Спасибо!ak@natsys-lab.com
Upcoming SlideShare
Loading in …5
×

Механика DDoS (Александр Крижановский)

1,358 views

Published on

  • Be the first to comment

Механика DDoS (Александр Крижановский)

  1. 1. Механика DDoS Крижановский Александр ak@natsys-lab.com10/23/12
  2. 2. «Механика»● Чем в среднем отличается DdoS от flash crowd (не исчерпывающее описание и без специальных случаев)● Процессы, происходящие с HTTP-акселератором под DdoS● Как не надо и как лучше отражать HTTP DDoS● Пример — Nginx, но говорим «в целом»
  3. 3. Нормальный HTTP трафик● Запросы достаточно большие за счет Cookie и URL (~1KB, часто больше)● Ответ — Web-страница (десятки килобайт), считанная из файла● Сотни или тысячи Keep-Alive соединений (к одному HTTP- акселератору), каждое из которых генерирует умеренное число запросов
  4. 4. HTTP DDoS трафик● Запросы часто сильно меньше (десятки или сотни байт)● Ответов сервера сильно меньше, чем получаемых запросов● Десятки или сотни тысяч соединений ● много запросов в каждом соединении ● или постоянная переустановка соединений с каждого хоста
  5. 5. Nginx, netstat, grep, fail2ban и др.● Посмотреть netstatом соединения и добавить правила в Iptables● Погрепать access.log и/или error.log и добавить правила в ipset● Fail2ban● Лимитирование на сервере (limit zone для Nginx)● Iptables connlimit и hashlimit=> HTTP-акселератор + FirewallЧтение логов – не самая быстрая операция, особенно в условияхвысокой нагрузки
  6. 6. Обработка лимита (Nginx)epoll_wait(12, {{EPOLLIN, ....}}, 512, 500) = 1recvfrom(3, "GET / HTTP/1.1rnHost: ....", 1024, 0, NULL, NULL) = 327// parse HTTPwrite(11, “...limiting requests, excess...", 176) = 176writev(3, [{"HTTP/1.1 503 Service Temporarily Una....", 200}], 1) = 200sendfile(3, 7, [0], 383) = 383recvfrom(3, 0xa1bac0, 1024, 0, 0, 0) = -1 EAGAINepoll_wait(12, {{EPOLLIN, ....}}, 512, 500) = 1recvfrom(3, "", 1024, 0, NULL, NULL) = 0close(3) = 0
  7. 7. Горячая точка (Nginx, без логов)samples % image name symbol name496099 1.5719 nginx ngx_vslprintf325148 1.0303 nginx ngx_http_parse_header_line219699 0.6961 vmlinux cfq_set_request202023 0.6401 libc-2.12.so memcpy183268 0.5807 libpthread-2.12.so recv162710 0.5156 nginx ngx_linux_sendfile_chain157504 0.4990 nginx ngx_http_limit_req_handler
  8. 8. Nginx и DDoS● Логировать запросы от ботов дорого● Парсить логи тоже дорого● Вместо логирования лимитов – простой модуль, добавляющий правило в netfilter
  9. 9. Обработка пакетов● Параллельность: MSI-X, irq round- robin● RPS (Receive Packet Steering) позволяет «разбрасывать» пакеты по softirq на разных ядрах если MSI-X недостаточно (или железо вообще не может параллелить прерывания)● RFS (Receive Flow Steering) позволяет отправлять пакеты на CPU прикладного процесса● Улучшают параллельность, но ухудшают кэширование
  10. 10. User space vs Kernel● Более 15 context switch● Kernel/userspace копирования запросов и ответов● Zero-copy network IO (splice(2)) не работает в общем случае на чтение из сокета● Проблема с очередями сокетов все равно остается (парсить HTTP нужно синхронно в skb)
  11. 11. Kernel HTTP-акселераторы● Первая половина 2000x: TUX (Linux), OpenKETA (FreeBSD), khttpd (Linux) и комерческие прокеты=> Основное узкое место, которое может решить kernel-based HTTP-сервер – копирование на отправке файла – решается в user spaceчерез sendfile().
  12. 12. L7 DDoS-mitigation HTTP-акселератор: специальный случай● Нужно минимизировать накладные расходы на обработку запросов от ботов● Более тесная интеграция с Netfilter● Возможность держать до 1 млн. Cоединений: ● Обработка TCP in-order данных сразу, не откладывая в очередь (лучше cache hit, меньше расход памяти) ● Per-connection и per-host resource management/QoS ● Желательно блокировать не по IP, а содержимому HTTP запроса
  13. 13. Спасибо!ak@natsys-lab.com

×