От серьезной атаки это, конечно, не спасет. Серьезные атаки могут создавать поток на несколько гигабит и засирать раутеры на площадках. Но от всяких пионэров-хакеров помочь вполне может. Нижеприведенная информация не претендует на полноценный рецепт и является лишь отправной точкой для дальнейших самостоятельных поисков. Как говорили старые программисты на Си по поводу отсутствия комментариев в программе: "Умный и так поймет, а дуракам ни к чему". На русский не перевожу в соответствии с тем же принципом. Однако замечу, что метод на основе tarpit вполне рабочий и был недавно на моих глазах успешно использован для уменьшения силы DDOS в 10 раз.
Fortunately, most HTTP-based DoS attacks we have seen have a particular weakness - they are vulnerable to a technique known as "tarpitting". This idea was first proposed by Tom Liston many years ago when the first scanning worms hit the Internet, and was implemented in his program LaBrea (which he no longer offers for download, due to legal concerns - however, the source code can still be found
elsewhere and should work on Linux or BSD-based operating systems). The quickest way to implement tarpitting (if your webserver runs on Linux) is in the Linux netfilter source code. If the tarpit module is compiled for your Linux kernel, the operation becomes as simple as "iptables -A INPUT -s x.x.x.x -p tcp -j TARPIT".
Tarpitting works by taking advantage of TCP/IP's idea of window size and state. In a tarpitted session, we respond to the connection initiation as normal, but we immediately set our TCP window size to just a few bytes in size. By design, the connecting system's TCP/IP stack must not send any more data than will fit in our TCP window before waiting for us to ACK the packets sent. This is to allow connections to deal with packet loss that might occur in a normal session. If the sending system doesn't get an ACK to a packet sent, it will resend the packet at increasingly longer intervals. In our tarpitted session, we simply don't ack any of the post-handshake packets at all, forcing the remote TCP/IP stack to keep trying to send us those same few bytes, but waiting longer each time. With this, bandwidth usage falls off quickly to almost nothing.
It might seem reasonable to simply use iptables -j DROP to not respond to connections at all - this will certainly prevent the webserver from seeing the connection, but because the connection may have a timeout set, it is likely we'll keep seeing connection attempts at a fairly regular rate. Essentially a DROP rule turns our HTTP flood into a SYN flood.
Источник