media Formel4 wrote:

88.111.75.8

As you can see: They've got not much in common...

I'm still not sure that they aren't spoofed. During the last hours I blocked more than 6000 IPs and per minute the count raises by 30 - 40...

What firewall is in front of that host? I'd try to setup a reverse-proxy infront of it, together with an OpenBSD packetfilter. The key to fending-off a DDoS-attacks is to have more resources than the attacker - both bandwidth and raw processing power. If you don't have these resources, you can also just go home and wait till it's over because with so many zombies, the attacker can just flood you "conventionally" until your upstream provider is fed-up enough with it so that he just disconnects your system.... cheers, Rainer

As I said - its a root server. Nothing in front but the pure internet...

Why not have a firewall in front of it? Root server or no, something that can manage the connections to the box with relatively low connection timeouts?

On Thu, Oct 27, 2005 at 11:59:54PM +0200, b@rry wrote:

...

As I said - its a root server. Nothing in front but the pure internet...

Why not have a firewall in front of it? Root server or no, something that can manage the connections to the box with relatively low connection

timeouts?

Maybe just maybe, because a firewall isn't going to do a THING against a DDOS attack? And for the other person who said call the ISP so they can "set the router to block the packets"..... Lol, if it was hat easy Yahoo, Microsoft and SCO wouldn't have been taken down.

Hi all, first of all thanks for all your suggestions. Today (day 3 of the Attack) we decided to switch IPs - which was not the best choice at all. Right after changing the nameservers too, we had to find out that the DDos now splitted up. We faced now two DDoS Attacks. One was still whacking the old IP (on which we set up a honeypot for further investigations), while the second one attacked the new IP, simply following the DNS change. Due to customer complains we decided to ask our upstream provider to close every IP traffic to the new IP number but the one coming from local peerings, which decreased the attack to a value the server can handle easy. Sure, it is no longer available for the whole internet, but due to the fact that the content is mainly interesting for local surfer it is not such a big loss. The attack is still going on and we counted >18.000 IP numbers in the meantime, coming from all over the world. Right now scanners are tracing all that kind of traffic, which is an interesting new step in DDoS attacks because it is beyond SYN-flooding. The attacker uses definetly spoofed IP numbers because many of them are not routable - but it doesn't seem to be a compromised router, because in that case it must have been the one closest to our network. And that one is still in service while the attack was reduced (not stopped) by closing a lot of transit traffic. So still the one question is left open: How can the attacker instantiate an ESTABLISHED connection while using spoofed IPs? When I get some more informations out of our trackings, I will inform you... Thanks, Ralf Koch Roland Kuhn schrieb:

Hi!

On 27 Oct 2005, at 21:42, media Formel4 wrote:

...

I do have the ressources - but I'm running out of options how to use them to fight back the attackers.

The list of blocked IPs reached 10.000 in the meantime...

I'd recommend writing a small connection proxy program which listens on port 80, takes the connections and forwards only the requests which come in to the apache (running on a different port). You'd run into the 1024 filedescriptor limit, but then you can always reap the oldest 'empty' connection as soon as you reach 1000. Should work as long as the rate of these empty connection openings is not in the kHz range ;-)

But, alas, no time to code it up right now. :-(

Ciao, Roland

-- TU Muenchen, Physik-Department E18, James-Franck-Str. 85747 Garching Telefon 089/289-12592; Telefax 089/289-12570 -- A mouse is a device used to point at the xterm you want to type in. Kim Alm on a.s.r. -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GS/CS/M/MU d-(++) s:+ a-> C+++ UL++++ P-(+) L+++ E(+) W+ !N K- w--- M + !V Y+ PGP++ t+(++) 5 R+ tv-- b+ DI++ e+++>++++ h---- y+++ ------END GEEK CODE BLOCK------

On Saturday 29 October 2005 02:02, media Formel4 wrote:

So still the one question is left open: How can the attacker instantiate an ESTABLISHED connection while using spoofed IPs?

Essentially, you can't. However, as someone has already mentioned, you could brute-force the sequence number expected for a SYNACK "cookie" by sending them blindly after the first SYN. There is a way to stop these from creating an established connection, but you'll need to write a program that actually detects these attempts and deletes the connection. This can be done in linux, but it may take a day or two to develop, if you're familiar with netfilter. The idea is that if you receive a SYN, send a SYNACK, and then wait for the reply and you actually receive a reply from that IP that is somehow invalid before receiving the valid one, you just delete the conntrack entry as if the first SYN packet was never received. This will result in sending a single RST after other packets coming in for the same connection (which you may want to rate limit) and it won't bug apache about an open tcp socket, which is exactly what you need. However, your machine will still get loaded because of all the traffic causing all the state changes in IP stack, and there is a very real possibility that these IP addresses are not spoofed, but actually just machines that have been compromised a while ago and were just waiting to start flooding some IP with junk requests. Check with tcpdump if you are actually receiving lots of ack packets that you should not be seeing. -- Jure Koren, n.i.