Назад | Перейти на главную страницу

проблемы с имитацией TCP SYN флуда

Я пытаюсь смоделировать поток TCP SYN для настройки веб-сервера (планирую развернуть на AWS).

Я настраиваю «целевую» виртуальную машину, отключил iptables и запустил hping (hping -p 80 -i u1000 -c 1000 -S destaddr) с пары локальных «исходных» машин (фильтруя RST в цепочке OUTPUT из них).

Я ожидал увидеть 1000 записей SYN_RECV в выводе netstat целевого сервера, но я вижу только 256 макс (256 на каждую «исходную» машину). Кажется, я достиг некоторого предела «целевой» машины и не могу найти, где она находится. tcp_max_syn_backlog увеличен до 8096.

Есть идеи, где установлен этот предел?

Хорошо, я задал тот же вопрос на webhostingtalk, и хотя прямого ответа не получил, это помогло расширить кругозор :)

По сути, я игнорировал ограничения на уровне приложения (веб-сервера). Но эти милые джентльмены из Нидерландов копнули глубже и разместили здесь свои очень важные выводы:

http://blog.dubbelboer.com/2012/04/09/syn-cookies.html

В основном веб-сервер (я использовал nginx) передает константу (ограничение ожидания прослушивания) для функции прослушивания, она определяется здесь:

https://github.com/git-mirror/nginx/...x_config.h#L97

определить NGX_LISTEN_BACKLOG 511

Так что ограничения ядра еще даже не действуют.

Константа Nginx скомпилирована, поэтому я быстро проверил apache - к счастью, он настраивается:

http://httpd.apache.org/docs/2.0/mod...#listenbacklog

Поэтому я установил его на 8k и получил то, что мне нужно (ну, 2 пакета потеряно:

источник:
hping -S -c 20000 -i u20 -p 80 цель

цель:
netstat -nta | grep SYN_RECV | туалет 8192 49152 729088

Наконец, мой исходный предел в 256 подключений был на самом деле связан с тем, что я изначально отправлял запросы на порт 22 (и sshd, очевидно, имеет невыполнение TCP-соединения, установленное на 256).