Медленный поток SYN: предотвращение усиления SYN?

Веб -сервер (linux), которым я управляю (на VPS) для веб-сайта с низким объемом, только что подвергся примерно 5 запросам SYN в секунду на порт 80, при этом никакой другой трафик не поступает с удаленного хоста. Это было скорее капельницей, чем наводнением, но это продолжалось примерно час после того, как я впервые это заметил. Я не знаю, была ли это атака усиления или нет.

У меня нет желания быть частью такого рода вещей, и в любом случае, все эти полуоткрытые соединения, засоряющие netstat, раздражали, даже если не было никакого реального вреда. (SYN-куки включены, ссылка была далека от насыщения, и Apache справлялся, хотя я думаю, что использование памяти возросло, а ответы немного медленнее, чем обычно.)

Итак, этот я "смягчил", вручную заблокировав поддельный / фактический исходящий IP-адрес, а затем следил за ним с помощью tcpdump, как я и знал, что они сдались. Я бы хотел автоматическое решение...

Так как это общедоступный веб-сервер, существуют ПРЕДПОЛАГАЕМЫЕ соединения! А на некоторых страницах много картинок /CSS-файлов и т. Д. Поэтому я полностью ожидаю, что подлинные пользователи будут намного превышать 5 "атакующих" запросов в секунду, и поэтому такие вещи, как

iptables -A INPUT -m состояние -state NEW -m limit -limit 4/second --limit-burst 20 ....

только поймает подлинных пользователей, но едва поймает атаку, если вообще.

Помимо чего-то грубого, такого как сценарий, который подсчитывает записи SYN_RCVD в выходных данных netstat очень часто и затем подает результаты в журнал для ответа fail2ban, существует ли эффективное решение для отбрасывания пакетов, если кумулятивное общее количество полуоткрытых соединений из данный IP превышает некоторое число? Я ничего не вижу в iptables, но, может быть, я что-то упустил.

РЕДАКТИРОВАТЬ: Забыл сказать, VPS на основе openVZ (построен на RHEL6), поэтому ядро, с которым я придерживаюсь, на данный момент составляет 2.6.32. Ответы, которые работают на ядрах, которые древние, были бы великолепны!

РЕДАКТИРОВАТЬ 2: Тайм-ауты Conntrack, как требуется:

net.netfilter.nf_conntrack_generic_timeout = 120
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 30
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 15
net.netfilter.nf_conntrack_tcp_timeout_established = 86400
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 30
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 15
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 10
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 30
net.netfilter.nf_conntrack_tcp_timeout_close = 5
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 60
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 60
net.netfilter.nf_conntrack_udp_timeout = 10
net.netfilter.nf_conntrack_udp_timeout_stream = 60
net.netfilter.nf_conntrack_icmpv6_timeout = 30
net.netfilter.nf_conntrack_icmp_timeout = 10
net.netfilter.nf_conntrack_events_retry_timeout = 15
net.ipv6.nf_conntrack_frag6_timeout = 4194

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