LINUX.ORG.RU
ФорумAdmin

висят CLOSE_WAIT, похоже на умную DoS-атаку


0

1

конфигурация: linux, apache, mpm_peruser.

корч старый, тем не менее нагрузку в обычном режиме держит отлично, однако в отдельные моменты происходит странное - в нетстате появляется огромное количество соединений в статусе CLOSE_WAIT, причем в 3-4 раза большее, чем при нормальных пиках нагрузки. при этом форкается огромное количество апачей, под сотню наверное и они сжирают весь проц, хотя похоже что ничего в этом состоянии они уже не отдают.

http://upload.wikimedia.org/wikipedia/commons/a/a2/Tcp_state_diagram_fixed.svg

вот тут диаграммка, на ней видно что такое состояние возникает если открыть соединение, начать что-то делать а потом просто исчезнуть. в этом случае сервак предлагает уже не существующему в моем случае клиенту закрыть соединение и ждет ответа. если ответа нет - он его закрывает сам по таймауту. я правильно понял?

что до апача, то если возникает такая ситуация, то он висит долго и не отвисает пока его не перезагрузят руками. почему он со временем не освобождает пул - сказать трудно, но это факт. пока проблема временно решена перезапуском апача по крону каждые 10 минут.

в этой ситуации я вижу два направления деятельности:

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

второе - есть идея покрутить net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60 - помоему это оно. какие могут быть побочки?

кстати снова набежали, пойду понаблюдаю.


в этот раз пробил whois'ом по айпишникам - там по большей части не китай, хотя он тоже есть. есть и финляндия, и голландия, и подольск и даже гугл. и есть adsl.by, кстати, где, насколько мне известно, живет человек, которого я с осторожностью подозреваю в этих атаках. но это так, параноя и ничего на самом деле не значит и не исключает.

подрезал net.netfilter.nf_conntrack_tcp_timeout_close_wait до 5 секунд, держу руку на пульсе.

n0153
() автор топика
Ответ на: комментарий от n0153

не помогло. уменьшил до одной секунды.

кстати интересная деталь - netstat отображает PID процесса к которому относится соединение, так вот это не мультиплексор, а юзерский воркер. не понимаю, каким образом мультиплексор передает уже установленное соединение воркеру?

вот тут написано про то как он работает, но не слишком подробно: http://www.peruser.org/trac/peruser/wiki/PeruserUnderTheHood

n0153
() автор топика
Ответ на: комментарий от n0153

Эм.. Не уверен в том, что говорю, но все же. у iptables есть действие TARPIT, которое подвешивает соденинение, устанавливая размер tcp окна в 0. Вроде бы похоже на то, что тут происходит..
http://ru.wikipedia.org/wiki/Iptables
- Там посмотри про «правильное использование TARPIT», может что поможет..

PATRI0T
()
Ответ на: комментарий от n0153

Установленное соединение можно передавать через unix-socket (sendmsg SCM_RIGHTS). Или может быть pre-fork, когда создаётся сокет, переводится в состояние listen и делается fork(), а приём соединения осущетсвляет один из потомков.

mky ★★★★★
()

>при этом форкается огромное количество апачей, под сотню наверное и они сжирают весь проц
предложу очевидное - фронтэндом поставить nginx

fr_butch
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.