* keith@topaz5.worldonline.co.uk wrote on Mon, Aug 25, 2003 at 22:04 +0000:
My idea was to keep a count of ALL packets coming to the server, and if there is an excessive amount of packets that are coming from one source IP, in a very short period of time, then this would probably indicate a SYN flood attack.
Yep, but SYN flooding works just too good with spoofed addresses :)
With this information, it would then be possible to tell the server to block ALL future packets from the identified SYN flood source IP address, for an hour or more.
Yeah, but I don't think that this would happen often; I guess most attacks are from random source or such.
(Even though the source IP is faked, this will stop Apache responding with SYN/ACK packets, which could in turn foil a SYN flood attack on someone elses machine).
Do you really mean Apache, as a user land software? I guess apache works on TCP sockets; for TCP socket the handshake is transparent. How to notice a SYN flood attack from userland? Maybe installing some raw socket for sniffing or such? mmm... not clean and straightforward. Installing a kernel module? Complex. So what is your way of handling that?
After the pre-configured time-out, connections from the blocked IP address would be allowed again.
So you are right, this would work like the limit module in IPTables, but will also give alot more information, which Apache could then act upon.
Which information? Sorry, I see no benefits for a userland software here. Because of the random pattern you have no choice to decide if a new SYN packet is part of an attack or a client handshake. With limitation of SYN, you jsut reduce the damage of the SYN flood - but it keeps a DOS.
The idea is to build Syn flood attack prevention into Apache, so that the server will identify such attacks, and automatically block them, for a certain period of time, depending on the cofiguration directives allowed by the modifications done to the server.
I guess this would be very linux-specific, wouldn't it? How you would start realizing this?
PS Would anyone like a copy of httpd.conf that I have reworked, and divided into 4 main include files?
I don't understand... You ask, if someone whats the configuration example with the added SYN flood option that you want to start to implement?
# The configuration directives have been regrouped into four basic sections:
I don't recommend changing the config files that are inside the RPM because it could make updates more complex I think. Well, my first servers always were self-compiled but this isn't necessary because SuSE makes great packages in almost any case. At least in 8.2, there is some way of dynamically include another file which would be the customers main file. In my case it includes anything specific (somewhat around 10-100 files, depending on number of vhosts and such). Well, I do not need a config option to recreate a config file with increased MaxServers or such and I don't think that SuSE 8.2 mechanism is the best possible, but usable for many cases. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.