Как уменьшить влияние SYN-flood?

Question

[Алексей Калинин]

Имеется проблема со входящим SYN-flood. Вывод "netstat -n --tcp | grep SYN_RECV | wc -l" = 512 Когда количество SYN падает - сервер по сети начинает отвечать. Какие методы борьбы рассмотреть?

Answer 1

[Alex Chistyakov]

Включить syn cookies, для начала:
sysctl net.ipv4.tcp_syncookies=1
Постойте, постойте...
512 соединений в состоянии SYN_RECV - для Вас это флуд?
Что у Вас за сервер такой?

Upd.: Посмотрите в dmesg - у Вас conntrack table не переполняется, случайно?
Обычно большое количество соединений (когда это действительно большое количество соединений, 65K и выше) забивает conntrack table - и вот тогда начинаются симптомы, похожие на описанные Вами. Либо я не понял фразы "сервер по сети начинает отвечать".

Comments

[Алексей Калинин]

В нормальном состоянии до 10 доходит. На 80 порт прилетает до 3000 соединений в секунду, смотрю по tcpdump -n dst port 80 явное превышение разумных пределов. syncookies включен, особого облегчения не принесло. Железо: ntel(R) Xeon(R) CPU E3-1270 v3 @ 3.50GHz, 32 ddr3, 1 gbit lan. В данный момент железо почти простаивает. Запросы на 80 порт не доходят до nginx, а пропадают где то раньше.

[Владимир]

sysctl.conf
# Уменьшение времени удержания «полуоткрытых» соединений
net.ipv4.tcp_synack_retries=1

#Увеличение очереди «полуоткрытых» tcp-соединений
net.ipv4.tcp_max_syn_backlog=2048

# increase TCP max buffer size
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

# increase Linux autotuning TCP buffer limits
# min, default, and max number of bytes to use
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

[Alex Chistyakov]

Окей, ситуация ясна, лечение обычное: 1) установите ipset, 2) создайте в ipset хэш размером тысяч на 200 адресов, 2.5) создайте в iptables правило, отправляющее адреса из данного хэша в DROP, 3) определите шаблон поведения атакующих (видимо, Вы его уже определили - они ничего, кроме SYN не шлют?), 4) собирайте их IP адреса через netstat и добавляйте в хэш ipset. 15 минут - и Вы в порядке.
Я всегда так делаю, и горя не знаю.

[Алексей Калинин]

Окей, спасибо.

[Алексей Калинин]

Conntrack:
net.netfilter.nf_conntrack_max = 655350
net.netfilter.nf_conntrack_count = 124456

[Alex Chistyakov]

@Kaliha На всякий случай, вот плейбук от Ansible, в котором все эти шаги описаны: https://gist.github.com/alexclear/898993ed9f8f8f990f7d

[Alex Chistyakov]

@Kaliha Да, count у Вас высоковат, но не критически высоковат, у меня вот на одном из ресурсов сейчас:
net.netfilter.nf_conntrack_count = 158162
Так-то главное, чтобы в максимум не упиралось.

[Алексей Калинин]

Согласен что не критично, при учете что это сервер хостинга в нормальной ситуации имею 5-6 тысяч. Поэтому и обратился за помощью в детекции узкого места.

[Alex Chistyakov]

@Kaliha Ага, стало быть, это все-таки аномалия. Кстати, если предположить, что Вас атакуют с одних и тех же адресов (а это ведь так и есть), Вы можете сортировать их по количеству соединений. Сразу будет видно хулиганов.

[Алексей Калинин]

Количество адресов достаточно велико (было) и банить их скриптом несколько рискованно, ведь можно забанить google, yandex etc....

Answer 2

[Владимир]

заюзать SYNPROXY
Homemade DDoS Protection Using IPTables' „SYNPROXY“

Comments

[Alex Chistyakov]

Но, коллега, 512 соединений - это ж разве флуд? "Что за фигню нам с Вами здесь показывают?"

[Владимир]

может любитель полудохлых виртуалок по 10 коп. за штуку

[Алексей Калинин]

Окей, жду указаний куда еще посмотреть.