LINUX.ORG.RU
ФорумAdmin

Mayday! Mayday! SYN DDOS


0

1

Идет атака на сервер сином, сервер начинает зависать, kworker грузит проц. Вот логи tcpdump во время атаки:

15:10:16.134852 IP 173.181.212.157.37390 > myip.89: Flags [S], seq 3047489536, win 0, length 0
15:10:16.134854 IP myip.89 > 173.181.212.157.37390: Flags [S.], seq 4283190269, ack 3047489537, win 0, length 0
15:10:16.134855 IP 119.196.211.172.43315 > myip.89: Flags [S], seq 844103680, win 0, length 0
15:10:16.134858 IP myip.89 > 119.196.211.172.43315: Flags [S.], seq 641131557, ack 844103681, win 0, length 0
15:10:16.134858 IP 17.123.43.91.46507 > myip.89: Flags [S], seq 2174025728, win 0, length 0
15:10:16.134861 IP myip.89 > 17.123.43.91.46507: Flags [S.], seq 820203671, ack 2174025729, win 0, length 0
15:10:16.134862 IP 31.90.208.59.64993 > myip.89: Flags [S], seq 3345285120, win 0, length 0
15:10:16.134864 IP myip.89 > 31.90.208.59.64993: Flags [S.], seq 2314162753, ack 3345285121, win 0, length 0
15:10:16.134865 IP 52.161.206.3.28380 > myip.89: Flags [S], seq 2879717376, win 0, length 0
15:10:16.134867 IP myip.89 > 52.161.206.3.28380: Flags [S.], seq 2266352682, ack 2879717377, win 0, length 0
15:10:16.134870 IP 120.74.122.187.12031 > myip.89: Flags [S], seq 1280507904, win 0, length 0
15:10:16.134873 IP myip.89 > 120.74.122.187.12031: Flags [S.], seq 1018383813, ack 1280507905, win 0, length 0
15:10:16.134873 IP 138.222.98.218.13210 > myip.89: Flags [S], seq 2263089152, win 0, length 0
15:10:16.134876 IP myip.89 > 138.222.98.218.13210: Flags [S.], seq 3403129284, ack 2263089153, win 0, length 0
15:10:16.134913 IP 5.255.32.87.34922 > myip.89: Flags [S], seq 3228368896, win 0, length 0
15:10:16.134916 IP myip.89 > 5.255.32.87.34922: Flags [S.], seq 2378954367, ack 3228368897, win 0, length 0
15:10:16.134917 IP 64.143.12.124.50899 > myip.89: Flags [S], seq 2605383680, win 0, length 0
15:10:16.134919 IP myip.89 > 64.143.12.124.50899: Flags [S.], seq 1478185173, ack 2605383681, win 0, length 0
15:10:16.134920 IP 81.184.250.227.5977 > myip.89: Flags [S], seq 1985871872, win 0, length 0
15:10:16.134922 IP myip.89 > 81.184.250.227.5977: Flags [S.], seq 2383571245, ack 1985871873, win 0, length 0
...

Стоит синпрокси

iptables -t raw -A PREROUTING -p tcp -m tcp --syn -j CT --notrack
iptables -A INPUT -p tcp -m tcp -m conntrack --ctstate INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460
iptables -A INPUT -p tcp -m tcp -m conntrack --ctstate INVALID -j DROP

И вот сусктл

net.ipv4.conf.all.secure_redirects = 0
net.ipv4.tcp_orphan_retries = 0
net.netfilter.nf_conntrack_tcp_loose = 0
net.ipv4.netfilter.ip_conntrack_max = 2000000
net.ipv4.icmp_echo_ignore_all = 1
kernel.shmmni = 81928
kernel.shmall = 16777216
kernel.sem = 250 1024000 32 8192
kernel.msgmni = 32768
kernel.msgmax = 65536
kernel.msgmnb = 65536
net.ipv4.conf.all.log_martians = 0
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 20
net.ipv4.netfilter.ip_conntrack_tcp_timeout_last_ack = 30
net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120

### ipv6 settings (no autoconfiguration)
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

### my test values
vm.swappiness = 10
vm.vfs_cache_pressure = 1000
vm.dirty_background_ratio = 10
vm.dirty_ratio = 40
vm.dirty_writeback_centisecs = 15000

kernel.printk = 4 4 1 7 
kernel.panic = 10 
kernel.sysrq = 0 
kernel.shmmax = 4294967296 
kernel.shmall = 4194304 
kernel.msgmnb = 65536 
kernel.msgmax = 65536 
#vm.swappiness = 20 
#vm.dirty_ratio = 80 
#vm.dirty_background_ratio = 5 
fs.file-max = 2097152 
net.core.netdev_max_backlog = 262144 
net.core.rmem_default = 31457280 
net.core.rmem_max = 67108864 
net.core.wmem_default = 31457280 
net.core.wmem_max = 67108864 
net.core.somaxconn = 65535 
net.core.optmem_max = 25165824 
net.ipv4.neigh.default.gc_thresh1 = 4096 
net.ipv4.neigh.default.gc_thresh2 = 8192 
net.ipv4.neigh.default.gc_thresh3 = 16384 
net.ipv4.neigh.default.gc_interval = 5 
net.ipv4.neigh.default.gc_stale_time = 120 
net.netfilter.nf_conntrack_max = 10000000 
net.netfilter.nf_conntrack_tcp_loose = 0 
net.netfilter.nf_conntrack_tcp_timeout_established = 1800 
net.netfilter.nf_conntrack_tcp_timeout_close = 10 
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 10 
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 20 
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 20 
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 20 
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 20 
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 10 
net.ipv4.tcp_slow_start_after_idle = 0 
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.ip_no_pmtu_disc = 1 
net.ipv4.route.flush = 1 
net.ipv4.route.max_size = 8048576 
net.ipv4.icmp_echo_ignore_broadcasts = 1 
net.ipv4.icmp_ignore_bogus_error_responses = 1
# was cubic
net.ipv4.tcp_congestion_control = htcp
net.ipv4.tcp_mem = 65536 131072 262144 
net.ipv4.udp_mem = 65536 131072 262144 
net.ipv4.tcp_rmem = 4096 87380 33554432 
net.ipv4.udp_rmem_min = 16384 
net.ipv4.tcp_wmem = 4096 87380 33554432 
net.ipv4.udp_wmem_min = 16384 
net.ipv4.tcp_max_tw_buckets = 1440000 
net.ipv4.tcp_tw_recycle = 0 
# was 0, lags?
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_max_orphans = 400000 
net.ipv4.tcp_window_scaling = 1 
net.ipv4.tcp_rfc1337 = 1 
net.ipv4.tcp_syncookies = 1 
net.ipv4.tcp_synack_retries = 1 
net.ipv4.tcp_syn_retries = 2 
net.ipv4.tcp_max_syn_backlog = 16384 
net.ipv4.tcp_timestamps = 1 
net.ipv4.tcp_sack = 1 
net.ipv4.tcp_fack = 1 
net.ipv4.tcp_ecn = 2 
net.ipv4.tcp_fin_timeout = 10 
net.ipv4.tcp_keepalive_time = 600 
net.ipv4.tcp_keepalive_intvl = 60 
net.ipv4.tcp_keepalive_probes = 10 
net.ipv4.tcp_no_metrics_save = 1 
net.ipv4.ip_forward = 0 
net.ipv4.conf.all.accept_redirects = 0 
net.ipv4.conf.all.send_redirects = 0 
net.ipv4.conf.all.accept_source_route = 0 
net.ipv4.conf.all.rp_filter = 1

Подскажите как отбить :(

Вот подробнее лог:

15:42:16.595652 IP (tos 0x0, ttl 247, id 64828, offset 0, flags [none], proto TCP (6), length 40)
    222.87.212.224.49873 > ip: Flags [S], cksum 0x1fd5 (correct), seq 2664955904, win 0, length 0
15:42:16.595654 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    ip > 222.87.212.224.49873: Flags [S.], cksum 0x0735 (correct), seq 2693756927, ack 2664955905, win 0, length 0
15:42:16.595655 IP (tos 0x0, ttl 247, id 29569, offset 0, flags [none], proto TCP (6), length 40)
    39.140.50.179.6314 > ip: Flags [S], cksum 0x49a2 (correct), seq 2016149504, win 0, length 0
15:42:16.595657 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    ip > 39.140.50.179.6314: Flags [S.], cksum 0xc00b (correct), seq 3778652235, ack 2016149505, win 0, length 0
15:42:16.595669 IP (tos 0x0, ttl 247, id 14023, offset 0, flags [none], proto TCP (6), length 40)
    173.183.222.43.59587 > ip: Flags [S], cksum 0xc533 (correct), seq 4208721920, win 0, length 0
15:42:16.595672 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    ip > 173.183.222.43.59587: Flags [S.], cksum 0x9f38 (correct), seq 3097128271, ack 4208721921, win 0, length 0
15:42:16.595681 IP (tos 0x0, ttl 247, id 23226, offset 0, flags [none], proto TCP (6), length 40)
    198.68.8.199.35702 > ip: Flags [S], cksum 0x60ad (correct), seq 2038956032, win 0, length 0
15:42:16.595683 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    ip > 198.68.8.199.35702: Flags [S.], cksum 0x839c (correct), seq 1555005520, ack 2038956033, win 0, length 0
15:42:16.595703 IP (tos 0x0, ttl 247, id 63992, offset 0, flags [none], proto TCP (6), length 40)
    207.60.204.193.10341 > ip: Flags [S], cksum 0xf8c5 (correct), seq 2005794816, win 0, length 0
15:42:16.595705 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    ip > 207.60.204.193.10341: Flags [S.], cksum 0x9d81 (correct), seq 1218646672, ack 2005794817, win 0, length 0
15:42:16.595722 IP (tos 0x0, ttl 247, id 3961, offset 0, flags [none], proto TCP (6), length 40)
    176.208.118.139.35967 > ip: Flags [S], cksum 0x49f7 (correct), seq 920977408, win 0, length 0
15:42:16.595725 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    ip > 176.208.118.139.35967: Flags [S.], cksum 0xbed4 (correct), seq 2213414691, ack 920977409, win 0, length 0
15:42:16.595726 IP (tos 0x0, ttl 247, id 18429, offset 0, flags [none], proto TCP (6), length 40)
    186.176.231.225.58544 > ip: Flags [S], cksum 0xc4e9 (correct), seq 3901358080, win 0, length 0
15:42:16.595728 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    ip > 186.176.231.225.58544: Flags [S.], cksum 0x27d5 (correct), seq 202084600, ack 3901358081, win 0, length 0
15:42:16.595734 IP (tos 0x0, ttl 247, id 22718, offset 0, flags [none], proto TCP (6), length 40)
    77.248.39.61.30588 > ip: Flags [S], cksum 0x44fb (correct), seq 51052544, win 0, length 0
15:42:16.595737 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    ip > 77.248.39.61.30588: Flags [S.], cksum 0x2c83 (correct), seq 2518843972, ack 51052545, win 0, length 0
15:42:16.595771 IP (tos 0x0, ttl 247, id 47474, offset 0, flags [none], proto TCP (6), length 40)
    218.134.252.239.29257 > ip: Flags [S], cksum 0xbfd6 (correct), seq 723582976, win 0, length 0
15:42:16.595774 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    ip > 218.134.252.239.29257: Flags [S.], cksum 0xb0d9 (correct), seq 3149746990, ack 723582977, win 0, length 0

Примерная мощность 300kpps

andrey10
() автор топика

Подскажите как отбить :(

попробуй скастовать шамана

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

Помогает, сервер перестает отвечать на пакеты. Но отключение синпрокси не решение. До этого меня бомбили без синпрокси другими методами, сервер вообще беспросветно зависал на 10 минут.

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

Я не настоящий сварщик, но если атака идёт на неиспользуемый порт, то в чем проблема дропать только эти пакеты? Всё равно на 89 порт ничего хорошего не придет, работает за ним прокси или нет.

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

Тип атаки мгновенно сменится и будут бомбить настоящие порты. В таком случае сервер без синпрокси от 300kpps падает мгновенно.

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

Ясно. Я тут некомпетентен. Желаю удачи в бою.

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

не заметил.. Ну если на сервере карточки сетевые не мультитредовые (и хороший cpu) - то тупить от большого числа синов все равно будет. Только резать трафик на апстриме.

anonymous
()

Просить ISP/датацентр о помощи и слать им эти данные. Покупать услуги против DDoS. Бывают еще умные дорогие сетевушки, могущие дропать пакеты по данным заголовка, но это достаточно дорого.

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

С тарпитом у меня сеть ляжет, синпрокси включен, Qrator это вообще сервис по защите. Меня интересует можно ли отбить такую атаку локальными силами?

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

неужели так сложно забить канал? сколько гигабит у тебя? почему не хочешь за cloudflare спрятаться?

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

Подскажите хоть на какие настройки сервера или фаервола смотреть, чтобы ослабить атаку.

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

Короче, парни, толку от вас никакого :))) Написал скрипт, который банит по TTL (как видите по логам, он однаковый). Пока помогает.. Если какой-то челик хочет что-то дельное посоветовать - пожалуйста, буду рад выслушать.

andrey10
() автор топика

1) Если сервер для сайтов - закрыть лишние порты, закрыть лишние протоколы (udp, если не нужен) и делать настройку на уровне веб-сервера (разумеется nginx) + частичный фильтр на уровне фаерволла

2) Расширять канал, если маленький

А вообще, мало подробностей

Что за железо вообще и какой канал?

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

Автор упомянул в след. сообщениях, что его атакуют и другими способами.

Он не упомянул, что конкретно размещается на сервере. Я предложил наиболее простое решение: закрыть все лишнее, фильтровать только самое важное

Хотите грамотный ответ - умейте грамотно формировать задачу. Никакой информации о железе, канале и размещаемом приложении не написано.

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

Скастуй Shaman007. У многих здесь скора не хватает.

Shaman007 Вас просят :)

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

Теперь атакующий рандомит ttl. Снова проблемы...

Канал сервера 1гбит, мощность атаки - 100-200 мбит (300kpps). Я уже дал информацию о самом нужном. Порт несуществующий, linux, проц, память, диск не грузятся при атаке. Могу вот сетевушку дать.

        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Link partner advertised link modes:  10baseT/Full
                                             100baseT/Full
                                             1000baseT/Full
        Link partner advertised pause frame use: Symmetric
        Link partner advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00000033 (51)
                               drv probe ifdown ifup
        Link detected: yes

driver: r8169
version: 2.3LK-NAPI
firmware-version:
bus-info: 0000:02:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no

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

волшебных программных таблеток от твоей проблемы нет все равно. почему ты не хочешь обратиться к сетевикам дц?

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

Конечно есть, но потом тебе забьют канал целиком и приплыли. Пиши заявление в полицию пока, пусть разбираются.

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

Короче, парни, толку от вас никакого :))) Написал скрипт..

Толк будет когда ты поймешь, что если пакет пришел тебе на сетевую, то ОН УЖЕ ПРИШЕЛ.

Поэтому дальнейшие твои потуги

Меня интересует можно ли отбить такую атаку локальными силами?

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

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

UDP весь заблокирован на уровне ДЦ, доходят до сервера только TCP. Если справиться с сином, то думаю, что ддосер разочаруется.

Когда я блочу полностью порт через iptables, то он тоже на сетевуху приходит, но сервер не отвечает на син и ддос не чувствуется. Мне кажется, что проблема в сетевухе, когда она шлет ответные SYNACK. Как мне точно определить, что проблема в сетевухе?

# ethtool -S eth0
NIC statistics:
     tx_packets: 110856752
     rx_packets: 144159399
     tx_errors: 0
     rx_errors: 0
     rx_missed: 0
     align_errors: 0
     tx_single_collisions: 0
     tx_multi_collisions: 0
     unicast: 144159397
     broadcast: 2
     multicast: 0
     tx_aborted: 0
     tx_underrun: 0

Ничего не говорит...

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

Когда тупит в сетевую карту - то в топе можно увидит irq. Потому что обычная карта генерит прерывание на каждый пакет. Из-за большого числа ппс втупливает вся система. Драйвера некоторых интеловских карт умеею делать прерывание на очередь. Что уже очень уменьшает нагрузку. Более крутые карты - умеют несколько таких очередей размазывать по ядрам.

anonymous
()

Ой, сколько же толковых предложений от ребят, вот лучше так:

Вриант номер рас, православный

# разрешаем входящий tcp-трафик по соединениям в состояниях ESTABLISHED и RELATED
iptables -I INPUT 1 -p tcp -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# открываем порты, разрешая пропуск пакетов по этим правилам только если: установлен флаг SYN, соединение в состоянии NEW, не превышен лимит с одного ip-адреса
iptables -A INPUT -p tcp -m multiport --dports 21,22,80,443,3306 --syn -m conntrack --ctstate NEW -m recent --name webtraffic --update --seconds 5 --hitcount 16 -j DROP
iptables -A INPUT -p tcp -m multiport --dports 21,22,80,443,3306 --syn -m conntrack --ctstate NEW -j ACCEPT

Вариант два, с переподвыповертом:

git clone https://github.com/WoozyMasta/ddos-deflate.git && cd ddos-deflate
./install.sh
Загляни в конфиг /etc/ddos/ddos.conf и запускай службу ddos

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

Если справиться с сином, то думаю, что ддосер разочаруется.

ИМХО, он тогда может просто полностью забить гигабитный канал.

Я правильно понял, что как только вы перестаёте слать synack, меняются параметры атаки (TTL, порт)? Мне не понятно, зачем атаковать пустые порты, если у сервера порты, которые он должен слушать.

Примерная мощность 300kpps

Это по счётчикам сетёвки или по данным провайдера?

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

Написал скрипт, который банит по TTL (как видите по логам, он однаковый). Пока помогает.. Если какой-то челик хочет что-то дельное посоветовать - пожалуйста, буду рад выслушать.

Я хотя бы по теме треда ответ дал.

Какой кошмар ты человеку предлагаешь!

И что кошмарного в netstat? Раз в n времени смотрим syn_recv (или что там тебе нужно) и кто превысил лимит, того шлем в баню?

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

Почему атакуют пустые порты мне неизвестно, но факт. Да, если блокирую полностью порт (выключаю synproxy), то переключаются на «живые» порты. Я думаю, если была бы возможность забить канал, то давно бы уже забили. Видимо трафика на TCP не хватает, а амплификация на сервер не работает (весь UDP блочится на верхних уровнях ДЦ).

Атаку измеряю по данным RX сетевухи. Кстати, в момент атаки TX достигает 100kpps (когда сервер отвечает).

Сейчас атаки случаются реже, но всё же сервер страдает. Подытожу всю тему в нескольких словах:

При включенном iptables synproxy сервер валится SYNом на несуществующий порт в связи со спецификацией работы synproxy.

При выключенном synproxy и закрытом порте (на который идет атака), ддосер (автоматически) переключается на существующие открытые порты.

При включенном synproxy сервер держится, подлагивает, но держится. При выключенном - сразу умирает на несколько минут. Никакие правила iptables тут не спасут, при таком PPS сама обработка пакетов будет ложить сервер.

С «решений» от WoozyMasta посмеялся :)

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

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

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

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

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

Имитировал исхзодящие 70kpps и получил такие же лаги. Скажите, если сервер ложится при 70kpps исходящих - это нормально или нет? Стоит мне дергать хостера?

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