xandr0s

SYN_RECV - это состояние tcp-соединения во время three-handshake, означающее что сервер принял пакет с установленным флагом SYN (запрос на соединение), отправил SYN/SYN-ACK клиенту и ожидает от клиента пакет с флагом ACK.

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

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

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

Если говорить обобщенно, то в Вашем случае, я думаю, проблему можно решить с помощью модуля recent в iptables. Уверен, его функционала Вам будет достаточно. Сможете обойтись несколькими правилами. Алгоритм следует применить примерно такой:

1. Сначала разрешаете входящий tcp-трафик по соединениям в состояниях ESTABLISHED и RELATED (модуль conntrack).

iptables -I INPUT 1 -p tcp -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

2. Открываете нужные порты, разрешая пропуск пакетов по этим правилам только в случаях если:
- установлен флаг SYN (опция --syn);
- соединение находится в состоянии NEW (модуль conntrack);
- не превышен лимит соединений с одного ip-адреса (модуль recent).
Примерно так:

iptables -A INPUT -p tcp -m multiport --dports 80,443 --syn -m conntrack --ctstate NEW -m recent --name webtraffic --update --seconds 5 --hitcount 16 -j DROP

iptables -A INPUT -p tcp -m multiport --dports 80,443 --syn -m conntrack --ctstate NEW -j ACCEPT

Первое правило будет применено только к пакетам с установленным флагом SYN, которые приходят с отдельно взятого IP-адреса со скоростью более 16 пакетов в течение 5 секунд. Этим правилом будет отброшен флуд.

Второе правило пропустит пакеты, не подошедшие под предыдущее правило (легитимный трафик).

Разумеется, все нужно адаптировать под Ваши условия и нагрузку. Подробности по модулям смотрите в man iptables-extensions. Настоятельно рекомендую ознакомиться с описанием модуля recent для лучшего понимания.

3. Дропаете весь остальной tcp-трафик либо отдельным правилом, либо политикой по-умолчанию.

Также, дабы легитимных пользователей не откидывало при попытке подключения, Вы можете увеличить очередь SYN-пакетов в sysctl, в соответствии с имеющимися системными ресурсами. За это отвечает параметр net.ipv4.tcp_max_syn_backlog, и уменьшить таймаут для соединений в состоянии SYN_RECV, за что отвечает параметр net.netfilter.nf_conntrack_tcp_timeout_syn_recv.
Рекомендуемые параметры индивидуальны для каждой системы. У меня используются такие:

net.ipv4.tcp_max_syn_backlog = 262144
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 20

Еще

kern.ipc.nmbclusters=400000
kern.ipc.maxsockbuf=83886080

У меня вот:

21502/10887/32389 mbufs in use (current/cache/total)
20464/7831/28295/400000 mbuf clusters in use (current/cache/total/max)
20464/7823 mbuf+clusters out of packet secondary zone in use (current/cache)
0/0/0/253036 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/74973 9k jumbo clusters in use (current/cache/total/max)
0/0/0/42172 16k jumbo clusters in use (current/cache/total/max)
92607K/36767K/129374K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters delayed (4k/9k/16k)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/0/0 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
0 calls to protocol drain routines

Ничего не будет содержаться в ответе. Т.к. $geoip_country_code вернет false, то nginx просто не передаст заголовок, в котором нет значения.

Вот тут человек из-за этого голову чуть не сломал: serverfault.com/questions/463971/httpgeoipmodule-geoip-country-code-is-blank :)

Две аварии у них forum.nag.ru/forum/index.php?showtopic=53151&view=findpost&p=882380

Возможность существует, мы так восьмёрку ставили — отправляли им скан лицензии.