Атака на tcp LAST_ACK

netwind, вот я вижу вы уже начали понимать на счёт лога, атака не на HTTP, а на TCP стек. При SYN флуде такой же эффект, в логах ничего не будет, так как tcp не прошёл все стадии завершения подключения, и тем не менее для nginx это ещё подключение. Всего то 2к ботов было, когда отфильтровал всех кто занял более 100 подключений, всё заработало, а через часик начали другой тип атаки, уже по HTTP на сайт клиента, ну ничего, сайт его всё равно открывался, хоть и через раз, а на сервер это не повлияло, там уже срабатывал другой тип защиты по анализу логов.

PS. хотя может я что-то путаю, ведь LAST_ACK это завершение подключения, после ESTABLISHED.

Но факт что в логах нет ничего и 80й порт в большой очереди.

фильтровать и банить, варианты зависят от ОС и инструментов и знаний.

Dimanych, ну как же не прошли все стадии подключения?

если nginx не хватало обработчиков, значит соединение полностью установлено и ngnix должен сделать об этом запись, но уже после завершения этого соединения. Видимо, вы nginx останавливали (убивали) тем самым препятствуя записи в логи.

может у вас запись логов так настроена чтобы не писать их или вы смотрите в логи от виртуального хоста, а не глобальные.

Чесно сказать не понимаю почему так, среди большого числа LAST_ACK, припоминаю, были также и ESTABLISHED около 10тыс.

Лог включен для всех вирт. хостов, есть один общий лог, лог отключается только когда идёт проксирование к апачу, и тогда в этот общий лог пишет сам апач.

Апач вообще не ощущал запросов, т.е. они до него и не доходили. Ситуация непонятная. Хотя в лог ведь пишется после завершения соединения, а они в состоянии LAST_ASK. Может поэтому?

Dimanych, трафик не захватил - сам себе злобный буратин. Теперь остается теоретизировать на пустом месте. В следующий раз используй tcpdump -w, скачивай файл и выкладывай - будет предметный разговор.

согласно этой картинке LAST_ACK это самое последнее состояние ожидания пакета от клиента ( ждем "recv ACK" как там подписано на стрелочке уходящей в CLOSED ). Так что

1. бот либо умышленно "забыл" про соединение,

2. либо твой сервер не получает финальное подтверждение от бота, поскольку бот забанен на уровне пакетного фильтра.

Ресурсов на соединение в LAST_ACK не так уж много расходуется. Второе мне кажется более вероятным.

Eсли понизить net.ipv4.tcp_fin_timeout, то таких состояний будет меньше. Но так ли важно сохранить их маленькими при небольших атаках? Были ли в dmesg ошибки "out of socket memory" ?

Помню случаи когда вроде бы верная "оптимизация стека для ddos" выливалась в страннейшие проблемы при нормальной работе сервера. сброс к настройкам по умолчанию все исправил. Я понимаю, что возможно было разобраться что именно от чего зависит, но мне это нерентабельно.

А я еще помню те времена, когда четвертая фря ложилась от подобной атаки - все забивал time_wait2.

Ещё одна атака, теперь более ясная, но от неё ещё хуже))

Атака идёт на сайт, он известен, на сервере mpm-itk с ограничением

MaxClientsVhost 10.

При атаке запросы проксируются апачу и он после рестарта за секунду набирает 256 клиентов которые висят в системе ничего не делая под пользователем root. Система не нагружена.

В error_log:

[Wed Jun 22 14:28:17 2011] [warn] MaxClientsVhost reached for website.ru, refusing client.

[Wed Jun 22 14:28:18 2011] [error] server reached MaxClients setting, consider raising the MaxClients setting

В статусе апача который всёже загружается через пару минут:

и т.д.

В нетстате как я подозреваю проблема в SYN, потому что nginx делает запрос апачу и много таких подключений:

netstat -na|grep SYN_SENT|wc -l

4453

netstat -na|grep ESTAB|wc -l

16178

cat /proc/sys/net/ipv4/tcp_syncookies

1

syncookies включены

В конфиге апача

Почему апач не блокирует новые подключения к сайту сразу, чего он ждёт, почему процессы висят, что за статус такой ..reading..

Кто-нибудь в курсе подобной проблемы?

напоминает то, о чем я писал тут .

Я успокоился на мысли, что это просто следствие высокой нагрузки от ddos, а не отдельный феномен. Либо какой-нибудь очередной прикол тухлого Centos.

На этот раз у тебя есть шанс не забыть захватить трафик и тогда мы подробно рассмотрим, что именно там происходит.

Новая информация,

после перезапуска апача через несколько секунд работы в логи ничего не пишет указанное время, Timeout 30, после видимо происходит сброс подключений и в логи начинает писать, опять же всего несколько секунд, а потом опять таймаут.

И так я попробовал Timeout 5, и действительно, апач начал обрабатывать запросы и писать в лог, но на сколько мне ихвесно 5 секунд очень маленький таймаут и многие нормальные подключения будут недорабатываться.

Так как состояние reading, а для этой дерективы и данного случая это время приёма GET запроса, я делаю вывод что nginx отправляет не полный заголовок запроса GET и апач продолжает ждать.

В чём фокус? nginx отправляет часть заголовка GET до того как он его сам полностью получит? Почему то думал что именно nginx должен защищать от подобного рода проблемы.

Я тоже так считал, но мне уже поздно ловить эту проблему.

Можешь сделать tcpdump -i any port <какой там у тебя для апача> -s 65000 -w file.cap ? через пару минут создастся файл, его можно изучать с помощью wireshark и найти ответы на многие вопросы.