UDP ddos

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

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

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

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

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

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

-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

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

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

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

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

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

Possible SYN flooding

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

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

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

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

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

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

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

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

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

Захватил трафик в момент атаки, уже на 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

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

Вот инфа(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

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

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

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

Я не вижу SYN подключений, только ACK.
Вот скрин https://prnt.sc/l04b5i

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

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

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

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

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

-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 минут

nping --tcp -p 80 --flags ACK --ack 0  --rate 999999999 -c 999999999 -H -N --data-length 0 --win=60000  ip

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

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

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

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

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

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

Держите полный набор - https://skeletor.org.ua/?p=1742

Под себя настройте необходимое.

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

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

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

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

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

Установка

net.netfilter.nf_conntrack_tcp_loose = 0

  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

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

   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

У меня в закладках сохранена статья https://habr.com/company/odnoklassniki/blog/266005/. Там п.3 как раз про это, но там народ с 10Г сетевушкой парился.

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

Из-за этого растет 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)

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

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