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

Атака отказа в обслуживании с заполнением буфера

Я начал наблюдать этот странный эффект, напоминающий атаку отказа в обслуживании на сервер Linux. Эффект состоит в том, что сеть становится, по крайней мере, частично, непригодной для использования, почти так же, как при традиционной DOS-атаке или DDOS-атаке.

Вот обрезанный netstat дамп во время "атаки" (при условии, что это так):

Proto Recv-Q Send-Q Local Address  Foreign Address       State       PID
tcp        1      0 1.2.3.1:80     50.128.251.184:1768   CLOSE_WAIT  18482/httpd         
tcp        0      1 1.2.3.4:80     71.75.22.31:52323     LAST_ACK    -                   
tcp        0  18980 1.2.3.4:80     98.180.31.210:60499   ESTABLISHED 18016/nginx: worker 
tcp        0  11709 1.2.3.4:80     98.180.31.210:60498   ESTABLISHED 18016/nginx: worker 
tcp        0  55743 1.2.3.4:80     71.75.22.31:52239     LAST_ACK    -                   
tcp        0      0 1.2.3.5:80     75.190.139.103:58265  ESTABLISHED 16808/httpd         
tcp        0  32814 1.2.3.4:80     71.75.22.31:52279     LAST_ACK    -                   
tcp        0  48029 1.2.3.4:80     71.75.22.31:52284     LAST_ACK    -                   
tcp        1  33581 1.2.3.4:80     71.75.22.31:52285     LAST_ACK    -                   
tcp        0  23582 1.2.3.4:80     71.75.22.31:52283     LAST_ACK    -                   
tcp        0    684 1.2.3.5:80     123.125.71.31:57865   FIN_WAIT1   -                   
tcp        0  37621 1.2.3.4:80     71.75.22.31:52218     LAST_ACK    -                   
tcp        0  18980 1.2.3.4:80     174.106.209.104:39937 ESTABLISHED 18016/nginx: worker 
tcp        0      0 1.2.3.1:80     95.140.125.125:60078  ESTABLISHED 18377/httpd         
tcp        0      0 1.2.3.2:39509  2.2.3.1:3306          ESTABLISHED 18379/httpd         
tcp        0    174 1.2.3.2:33029  2.2.3.1:3306          ESTABLISHED 18482/httpd         
tcp        0  44538 1.2.3.4:80     72.230.205.217:58271  FIN_WAIT1   -                   
tcp        0  64812 1.2.3.2:80     184.35.67.238:49173   ESTABLISHED 1251/httpd          
tcp        1      0 1.2.3.1:80     174.96.155.77:59167   CLOSE_WAIT  18379/httpd         
tcp        0      1 1.2.3.4:80     174.110.137.71:61496  FIN_WAIT1   -                   
tcp        1  31751 1.2.3.4:80     99.25.112.12:55747    CLOSING     -                   
tcp        0  33396 1.2.3.4:80     99.25.112.12:55764    ESTABLISHED 18016/nginx: worker 

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

Кто-нибудь распознает эту схему атаки и знает, как ей противостоять?

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

Не уверены, что вы защищаете, но нужно ли вам получать много подключений из Интернета в целом? Моя первая попытка противодействия будет заключаться в том, чтобы вы могли ограничить количество устанавливаемых соединений - до разумного порога на (хост / сетевой диапазон / и т. Д.).