LINUX.ORG.RU
ФорумAdmin

UDP ddos

 ,


4

3

На сервер debian приходит udp ~100-600mbps входящий в связи с этим идут потери пакетов, увеличиваются задержки и прочие радости. В iptables добавлено

INPUT -p udp -j DROP

По последним счетчикам навалило 301K\734M(пакетов\трафика) за пару минут. Иногда доходило до 160Gb, в обычное время UDP кроме как от dns сервера нет.
Растет overruns:
flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
ether 0c:c4:7a:0c:70:8c  txqueuelen 1000  (Ethernet)
RX packets 157283928333  bytes 38784725568569 (35.2 TiB)
RX errors 0  dropped 0  overruns 13182248  frame 0
TX packets 269997924596  bytes 355284328974259 (323.1 TiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0



ethtool -S eno1 | grep err
rx_crc_errors: 0
rx_missed_errors: 0
tx_aborted_errors: 0
tx_carrier_errors: 0
tx_window_errors: 0
tx_deferred_ok: 0
rx_long_length_errors: 0
rx_short_length_errors: 0
rx_align_errors: 0
rx_errors: 0
tx_errors: 0
rx_length_errors: 0
rx_over_errors: 0
rx_frame_errors: 0
rx_fifo_errors: 13182248
tx_fifo_errors: 0
tx_heartbeat_errors: 0
rx_queue_0_csum_err: 5051
rx_queue_1_csum_err: 5119
rx_queue_2_csum_err: 4784
rx_queue_3_csum_err: 6293
rx_queue_4_csum_err: 4666
rx_queue_5_csum_err: 3269
rx_queue_6_csum_err: 4681
rx_queue_7_csum_err: 5341

tcpdump пишет
UDP, bad length 3010 > 1472

На сервере 1gpbs unlim, весь канал не забивается, но дропы идут огромные 60-70%, хотя iptables блочит весь UDP. Куда смотреть?

★★★

Куда смотреть?

Никуда. Писать провайдеру, пусть закрывает и сам дальше тоже участвует - без него никак в большинстве случаев: у UDP src ip левый может быть, особенно, если это именно DoS, а не что-то где-то глюкануло. Провайдер может посмотреть, с какого его канала летит и сдать дальше проблему. src ip, кстати, постоянный, или меняется? Если постоянный, можно попробовать написать владельцу ip, но, как я уже написал, он может быть не при чём.

AS ★★★★★ ()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от AS

Но ведь трафик то мизерный относительно, иногда даже 30mbps идет, а канал вешается. Захватить трафик полностью пока не получается, по ssh не зайти ) Вот сейчас за пару минут overruns вырос с 13 182 248 до 36 320 832 . Провайдеру писал, предлагает купить дос защиту, бесплатно ничего блочить не желает

gobot ★★★ ()
Ответ на: комментарий от AS

Ещё вот что заметил в syslog

kernel: [12357838.453088] TCP: request_sock_TCP: Possible SYN flooding on port 80. Sending cookies.  Check SNMP counters.

gobot ★★★ ()
Ответ на: комментарий от gobot

Предлагаю добавить как минимум такое:

-A INPUT -m state --state INVALID -j DROP
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW      -j DROP

Ну раз провайдер ССЗБ накройте трафик маршрутизацией в черную дыру:

sudo tcpdump -v -n -c 20000 -w ddos.log -i en1 (dst port 25)
tcpdump -nr ddos.log |awk '{print $3}' |grep -oE '[0-9]{1,}\.[0-9]{1,}\.[0-9]{1,}\.[0-9]{1,}' |sort |uniq -c |sort -rn

# Только первые 5 строк:
tcpdump -nr ddos.log |awk '{print $3}' |grep -oE '[0-9]{1,}\.[0-9]{1,}\.[0-9]{1,}\.[0-9]{1,}' |sort |uniq -c |sort -rn | head -5

# А теперь только ip адреса и в файл ips.txt:
tcpdump -nr ddos.log |awk '{print $3}' |grep -oE '[0-9]{1,}\.[0-9]{1,}\.[0-9]{1,}\.[0-9]{1,}' |sort |uniq |sort -rn | head -5 > ips.txt

# Скрипт блокировки:
#!/bin/bash
BLOCKDB="ips.txt"
IPS=$(grep -Ev "^#" $BLOCKDB)
for i in $IPS
do
ip route add blackhole $i

Dimarius ()
Ответ на: комментарий от gobot

Так, наверное, дело в количестве пакетов, а не в их размере? Там пейлоад какой?

Deleted ()

Блокировать в raw, а не в filter. Иначе оно в conntrack попадает , а это приличный тормоз в случае флуда.

iptables -t raw -A PREROUTING -p udp -j DROP

Только про dns не забудь :)

overrun говорит о том, что ты не успеваешь обрабатывать пакеты :(

vel ★★★★★ ()
Ответ на: комментарий от gobot

Possible SYN flooding

Известный с конца прошлого века способ завалить Win9x и NT. Вероятно, проснулось какое-то древнее зло. :-)

AS ★★★★★ ()

iptables не поможет. Затык идет скорее всего на уровне драйвера сетевой карты.

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

zaz ★★★★ ()

Я бы попробовал обновиться до распоследней 4.14.72

За последний месяц или два, там много чего исправляли.

«UDP, bad length 3010 > 1472» imho этот пакет ядро не получит, т.к. e1000e умеет проверять КС udp.

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

Мониторинг pps для входящих пакетов какой максимум показывает ?

vel ★★★★★ ()
Ответ на: комментарий от vel

В raw добавлял, все равно overrun растет. Не пойму почему не успевает обрабатывать

gobot ★★★ ()
Ответ на: комментарий от Dimarius

Захватил трафик в момент атаки, уже на 80 порт tcp идет, вот такого характера
Бесконечные ACK -> RST(сервер сбрасывает соединение?)
http://prntscr.com/l04b5i

-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW      -j DROP

Вот это я не совсем понял что делает. Новые пакеты с флагами «FIN,SYN,RST,ACK SYN» дропает?

gobot ★★★ ()
Ответ на: комментарий от zaz

А как понять маленькие или нет? В tcpdump length смотреть?

gobot ★★★ ()
Ответ на: комментарий от zaz

Вот инфа(pcapinfos) захваченного трафика в момент доса, 10 минут

File encapsulation:  Ethernet
File timestamp precision:  microseconds (6)
Packet size limit:   file hdr: 262144 bytes
Number of packets:   37 M
File size:           3991 MB
Data size:           3393 MB
Capture duration:    635.796572 seconds
First packet time:   2018-09-29 16:49:59.530655
Last packet time:    2018-09-29 17:00:35.327227
Data byte rate:      5337 kBps
Data bit rate:       42 Mbps
Average packet size: 90,69 bytes
Average packet rate: 58 kpackets/s


Average packet rate: 58 kpackets/s как понимаю это 58 000 пакетов в сек.

gobot ★★★ ()
Ответ на: комментарий от gobot

58 kpps c syn-flood - это повод задуматься о включении SYNPROXY

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

В «man iptables-extensions» есть пример. на хабре есть с пояснениями всех 6-и пунктов.

vel ★★★★★ ()
Ответ на: комментарий от gobot

Блин! Это же вырви глаз! А несколько строк tcpdump -nr file.pcap нельзя было запостить сюда? Адреса можно было заменить на xxxxxx.

SYNPROXY - это борьба с попытками левых коннектов. ACK-flood это частный случай.

в любом случае п.2 и 6 в ссылке на хабре в твоем случае должны быть полезны.

vel ★★★★★ ()
Ответ на: комментарий от gobot

Новые соединения разрешаем только с пакета с установленным SYN и сброшенными FIN, RST, ACK, иначе дропаем.

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

На одном сервере помогло

-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW      -j DROP

iptables -nvL INPUT
83M 3320M DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:!0x17/0x02 state NEW
за 5 минут


на другом сервере счетчик также растет вплоть до 1178M\49G, но эффекта не дает, пакеты продолжают теряться, overruns растет

Сделал тест: с 3 других серверов запустил
nping --tcp -p 80 --flags ACK --ack 0  --rate 999999999 -c 999999999 -H -N --data-length 0 --win=60000  ip

PPS возрос до 1800-2000kpps(нормальное значение ~300kpps). Канал падает, также пропадают пакеты, растет overruns. Проц не загружен...

gobot ★★★ ()
Ответ на: комментарий от gobot

Проверь «sysctl net.netfilter.nf_conntrack_tcp_loose»

Там должен быть 0.

А сколько там в «sysctl net.netfilter.nf_conntrack_max» ?

Если заканичиваются conntrack, то новых коннектов не будет.

vel ★★★★★ ()
Последнее исправление: vel (всего исправлений: 1)
Ответ на: комментарий от vel

net.netfilter.nf_conntrack_tcp_loose = 1

net.netfilter.nf_conntrack_max = 1048576

Установил
sysctl -w net/netfilter/nf_conntrack_tcp_loose=0

Если заканичиваются conntrack, то новых коннектов не будет

Смотреть кол-во conntrack тут?
cat /proc/net/nf_conntrack | wc -l
406

Вроде не переполняется

gobot ★★★ ()
Ответ на: комментарий от gobot

То, что conntrack «пустой» - это хорошо и проблема не в нем.

PPS возрос до 1800-2000kpps(нормальное значение ~300kpps). Канал падает, также пропадают пакеты, растет overruns. Проц не загружен...

А вот это странно. Ты уверен, что простаивают все ядра ? Нет ли одного перегруженного ядра ?

А что за сетевая карта ? Машина однопроцессорная ?

Просто пока для борьбы с rx_fifo_errors было только увеличение числа буферов приема на максимум (ethtool -G ethX rx 2048 (или 4096)) и изменение InterruptThrottleRate=3000 ( для интеловских драйверов типа e1000e)

vel ★★★★★ ()
Ответ на: комментарий от vel

Установка

net.netfilter.nf_conntrack_tcp_loose = 0

действительно помогает разгрузить проц и повысить PPS.

Не понимаю, бывает иногда 1 ядро нагружено на 100%, а иногда все работают равномерно при загрузке 50 000 - 100 000 пакетов в сек.
Иногда бывает так
  CPU0   CPU1   CPU2   CPU3   CPU4   CPU5   CPU6   CPU7

   896    914    927    779    805    831    878    897   eno1-TxRx-7
   269    258    258    261    258    261    260    271   interrupts
    86     85     86     55     87     85     86     86   interrupts



А иногда так
  CPU0   CPU1   CPU2   CPU3   CPU4   CPU5   CPU6   CPU7

    82     86     76     61     58     50     38     41   eno1-TxRx-3
   830    858    877    906    910    916    938    931   eno1-TxRx-7
   260    264    261    260    280    264    261    259   interrupts
    87     86     87     86     79     82     73     87   interrupts


Это с net/netfilter/nf_conntrack_tcp_loose=1 для наглядности
Ядро работает то 6 то 1 то 8 не понятно по каким причинам

После
rss-ladder eno1
- distribute interrupts of eno1 (-TxRx-) on socket 0
  - eno1: queue eno1-TxRx-0 (irq 29) bound to CPU0
  - eno1: queue eno1-TxRx-1 (irq 30) bound to CPU1
  - eno1: queue eno1-TxRx-2 (irq 31) bound to CPU2
  - eno1: queue eno1-TxRx-3 (irq 32) bound to CPU3
  - eno1: queue eno1-TxRx-4 (irq 33) bound to CPU4
  - eno1: queue eno1-TxRx-5 (irq 34) bound to CPU5
  - eno1: queue eno1-TxRx-6 (irq 35) bound to CPU6
  - eno1: queue eno1-TxRx-7 (irq 36) bound to CPU7

Работать стали 3-4 ядра одновременно(смотрю через htop, срин http://prntscr.com/l1jvo9)
   CPU0   CPU1   CPU2   CPU3    CPU4   CPU5   CPU6   CPU7

  17843      0      0      0       0      0      0      0   eno1-TxRx-0
      0    309      0      0       0      0      0      0   eno1-TxRx-1
      0      0   7754      0       0      0      0      0   eno1-TxRx-2
      0      0      0      0   17317      0      0      0   eno1-TxRx-4
      0      0      0      0       0   4165      0      0   eno1-TxRx-5
      0      0      0      0       0      0     81      0   eno1-TxRx-6
    263     47    260     62     268    266     33     44   interrupts
     87     31     88     34      86     84     18     23   interrupts


Почему не все равномерно ядра работают?

gobot ★★★ ()
Ответ на: комментарий от vel

Экспериментальным путем выяснил, что если запросы посылать с 1 адреса, то грузится 1 ядро(вся очередь по этому признаку идет на случайное ядро), каждый новый адрес попадает на новое случайное ядро. Например, если запросы делать одновременно с 4 машин(больше проверить нет возможности), то будут работать 4 ядра. Почему так не знаю, хотя лучше бы конечно чтобы все ядра работали равномерно

gobot ★★★ ()
Ответ на: комментарий от vel

Из-за этого растет overruns(он
же rx_fifo_errors, /sys/class/net/eno1/statistics/rx_fifo_errors), т.е. бывает что одно из ядер нагружено на 100% это на 8 ядерном Atom C2750@2.40GH при PPS > 100000. Хотя на 8 ядерном Xeon E3-1270 v6 @ 3.80GHz такой проблемы уже нет даже при PPS > 300 000

Удивляет одно, что Atom в дефолтной конфигурации debian можно вывести из строя всего одной VPS, без всяких ботнетов.

А так в общем помогло nf_conntrack_tcp_loose и iptables(в частности использование ipsec)

Спасибо за помощь!

gobot ★★★ ()
Ответ на: комментарий от gobot

Если 100% загрузки ядра дает interrupt, то бороться с этим сложнее, а вот если это softirq, то включение rps должно спасать ситуацию.

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