Jump to content
Калькуляторы

Борьба с TCP Connection DDoS

Доброго времени суток.

Имеется защищенный веб-сервер на базе nginx, который на днях заддосили банальным методом.

В access логах нжинкса ничего нет, но я видел кучу подключений (120000+) на 80 порт, которые уже установились. (Значит подмены IP не было, ибо проходил three way handshake)

В логах системы куча сообщений вида TCP: Too many orphaned sockets и в момент атаки нжинкс съедал весь процессор.

 

Немного продумав схему атаки, я сделал вывод, что атакующий ботнет подключался к порту nginx, но ничего дальше не слал. В настройках нжинкс keepalive_timeout установлен в 5 секунд, то есть банальный телнет на порт - и соединение закроется через 5 секунд неактивности.

Меня удивило то, что веб сервером не отдается ошибка 408 в таком случае.

 

В настройках системы max_orphans установлен в 8192 и orphan_retries установлен в 0.

 

Позже я в nginx'e установил accept_mutex off в секции events {}, а также уменьшил fin_timeout до 5 в настройках системы.

Системой обнаружения атак данная атака не детектировалась вследствии того, что весь трафик де-факто нормален (нечего блочить), ибо все запросы легитимны, просто их очень много.

 

Соответственно прошу совета, как лучше защититься от подобного вида атак.

Ratelimit на dst_port не предлагайте, плз :)

 

Пока что надумал впихнуть haproxy с агрессивными настройками по отношению к таймаутам коннектов, но мне кажется, что это костыль, ибо задачу, должно быть, можно решить другими настройками системы. Почему nginx съедал весь процессор, несмотря на то, что сокеты по идее требовательны к памяти, а не процу (1 сокет забирает 64 кб unswappable памяти, AFAIK)? По ошибке TCP: Too many orphaned sockets в гугле очень мало инфы, и все советы, которые даются в данном случае, уже были приняты. Что крутить: nginx или настройки tcp стека?

 

Спасибо за внимание.

Share this post


Link to post
Share on other sites

slowloris?

 

A kind of, но довольно специфичный. Либо мне забили коннекты быстрее, чем нжинкс закрывал старые, либо...

 

Прочитал эту статью:

http://blog.tsunanet.net/2011/03/out-of-socket-memory.html

 

В системе нет сообщений о том, что Out of socket memory. Только о том, что too many orphans. Крутить max_orphans я не стал, ибо сомневаюсь, что в этом есть большой смысл. В то же время я кое-как пробился в консоль сервера и мог оперировать там, в то время, как на порт веб-сервера вообще было не подключиться, поэтому я склюняюсь к тому, что проблема именно в настройках в nginx.

Share this post


Link to post
Share on other sites

slowloris?

A kind of, но довольно специфичный. Либо мне забили коннекты быстрее, чем нжинкс закрывал старые, либо...

ну, я на scapy делал 3-way handshake и потом выставлял окно в 0. несколько сотен тысяч итераций делают жертве плохо.

Share this post


Link to post
Share on other sites

slowloris?

A kind of, но довольно специфичный. Либо мне забили коннекты быстрее, чем нжинкс закрывал старые, либо...

ну, я на scapy делал 3-way handshake и потом выставлял окно в 0. несколько сотен тысяч итераций делают жертве плохо.

 

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

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

Share this post


Link to post
Share on other sites

А вы их поверху ещё fail2ban-ом. Только использовать надо какой-нибудь ipset.

Share this post


Link to post
Share on other sites

А вы их поверху ещё fail2ban-ом. Только использовать надо какой-нибудь ipset.

Айписет стоит давно, да.

Фейл2бан и подобные высокоуровневые надстройки фтопку, ибо прокси молотит довольно внушительные объемы трафика. Если в айпитейблах какой-нибудь connlimit лишний сразу задерет нагрузку процентов на 40, то какая речь о файл2бан.

 

PS склонился к идее от rage, поскольку slowloris/slowread & sockstress используют методику понижения размера окна до нуля в определенный момент tcp сессии, я просто посредством u32 заблокировал пакеты с winsize 0. Будем тестировать.

Edited by Wheely

Share this post


Link to post
Share on other sites

А вы их поверху ещё fail2ban-ом. Только использовать надо какой-нибудь ipset.

PS склонился к идее от rage, поскольку slowloris/slowread & sockstress используют методику понижения размера окна до нуля в определенный момент tcp сессии, я просто посредством u32 заблокировал пакеты с winsize 0. Будем тестировать.

ну я бы просто рейты на такие пакеты поставил. потому что так можно и tcp сломать :)

Share this post


Link to post
Share on other sites

Изучайте дампы траффика, особенно url запросов.

и дальше сооружайте фильтры.

Share this post


Link to post
Share on other sites

А вы их поверху ещё fail2ban-ом. Только использовать надо какой-нибудь ipset.

PS склонился к идее от rage, поскольку slowloris/slowread & sockstress используют методику понижения размера окна до нуля в определенный момент tcp сессии, я просто посредством u32 заблокировал пакеты с winsize 0. Будем тестировать.

ну я бы просто рейты на такие пакеты поставил. потому что так можно и tcp сломать :)

 

Не люблю я рейты, честно. Если ситуация не такая, что без них вообще никак - никогда не использую. Ибо счетчики рейтов берут информацию с clocksource, а это даже в состоянии покоя будет отжирать честь процессора. Особенно это касается таймеров в ipset.

 

Каким образом я сломаю тцп подобным образом? SYN пакеты с initial winsize 0 никогда не посылаются, а ack с нулевым окном - собственно и есть нарушение логики tcp сессий.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this