Tell me more ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.
up vote 0 down vote favorite

My server is being attacked (SYN flood attack) and what I see in /var/log/messages is a ton of:

r8169: eth0: link up
r8169: eth0: link up
r8169: eth0: link up

1. What does this mean?

I can't access the server during the attack, but I also can't access it after the flood has stopped, I have to restart the server.

2. Is it possible to avoid this restart? Is it possible to "autoreset" the connection without restarting the server manually?

Additional information: Ubuntu server 10.04 64 bits 8GB RAM, dual core. Firewall: CSF

SYN flood attack against port 80 (apache2) with up to 50-70Mbps traffic

share|improve this question

2 Answers

up vote 1 down vote accepted

have you tried a new driver for the NIC?

It ist very likely that your kernel suffers a bug in the included module for the NIC. Because it is really simple to build a new kernelmodul for your nic I really suggest to try it:

Here is a good tutorial:

http://ubuntuforums.org/showthread.php?t=1022411

I experienced a similar bug with incuded kernel from 10.04 more the once, and got it fixed with the driver from realtek.

share|improve this answer
it's not a random problem, it only happens during (and after) syn flood attack. I haven't had any problems with connectivity before (and I've been using this server for months). And it works fine after a reboot. Are you sure this will solve the problem? What does "link up" means? – TheBronx Jan 7 at 21:32
well, you were right! The eth link up was caused by the driver (and the attacks of course), and seems to be solved since I upgraded ubuntu. Now there is no need to restart after attacks. – TheBronx Feb 11 at 18:19
up vote 1 down vote

Your server should be accessible even after the attack if you have the right measures in place.

Take a look at your /etc/sysctl.conf

And add the following

# TCP SYN Flood Protection
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.tcp_synack_retries = 3

Furthermore are you using local dns or external dns? If it's internal DNS then you might wanna try an external DNS such as 8.8.8.8 8.8.4.4 and see if that happens after.

Seems odd that you would keep getting these attacks, I operate many VPS and hardly ever see them :P

share|improve this answer
syncookies is enabled, tcp_max_syn_backlog = 1024 and tcp_synack_retries is not set. I will change it once the server is accessible again. – TheBronx Jan 7 at 21:07
/etc/sysctl.conf edited (this guide also helped: linuxstuffs.wordpress.com/2009/10/25/drop-syncddos-attack) but I'm being attacked again. internal/external DNS? I don't know, I will check my bind config files, but I haven't changed anything there. – TheBronx Jan 7 at 21:55

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.