Go Premium for a chance to win a PS4. Enter to Win

x
?
Solved

SYN Flood Attack

Posted on 2010-08-30
10
Medium Priority
?
2,320 Views
Last Modified: 2013-12-06
HI

I am receiving following messages in /var/log/messages and on the same server is experience the issue of FTP connection.  

How to prevent this syn flood attack effectively:

Error logs:

Aug 29 18:49:18 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 18:54:41 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 18:56:23 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 18:59:09 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 19:00:17 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 19:07:57 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 19:10:45 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 19:13:08 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 19:14:36 localhost kernel: possible SYN flooding on port 25. Sending cookies.
Aug 29 19:16:00 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 19:17:12 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 19:18:38 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 19:20:03 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 19:21:11 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 19:22:25 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 19:24:31 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 19:26:29 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 19:27:43 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 19:29:50 localhost last message repeated 2 times
Aug 29 19:31:11 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 19:33:58 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 19:35:50 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 19:37:08 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 19:38:41 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 19:39:54 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 19:40:57 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 19:43:02 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 19:44:03 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 19:45:48 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 19:47:13 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 19:48:37 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 19:49:48 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 19:50:57 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 19:53:54 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 19:55:49 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 19:57:28 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 19:59:00 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 20:01:29 localhost last message repeated 2 times
Aug 29 20:03:14 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 20:05:32 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 20:06:56 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 20:08:17 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 20:09:20 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 20:10:21 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 20:11:22 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 20:12:49 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 20:14:28 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 20:15:31 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 20:16:50 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 20:18:58 localhost last message repeated 2 times
Aug 29 20:20:00 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 20:21:02 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 20:25:42 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 20:32:37 localhost kernel: possible SYN flooding on port 110. Sending cookies.
Aug 29 21:06:30 localhost kernel: possible SYN flooding on port 80. Sending cookies.
Aug 29 22:30:11 localhost kernel: possible SYN flooding on port 25. Sending cookies.
Aug 30 01:21:07 localhost kernel: possible SYN flooding on port 25. Sending cookies.
Aug 30 05:21:04 localhost kernel: possible SYN flooding on port 25. Sending cookies.
Aug 30 05:22:40 localhost kernel: possible SYN flooding on port 25. Sending cookies.
0
Comment
Question by:ashwanijain
  • 5
  • 4
10 Comments
 
LVL 20

Expert Comment

by:woolnoir
ID: 33556988
It looks like your system 'is' preventing the attack

read this article (http://www.symantec.com/connect/articles/hardening-tcpip-stack-syn-attacks) paying special attention to the linux specifics section.

There are also a few hints further down for additional things you can do to mitigate the attack.
0
 

Author Comment

by:ashwanijain
ID: 33557048
Thanks

What made you determine that kernel is already preventing attacks.  Because during the duration of these logs, this system was not able to make FTP connection to another FTP server.  What could I do to have the FTP work fluently even if such attacks continues ?

Do you thnik putting this server behind IPCOP firewall will benefit.

Regards

Ashu
0
 
LVL 20

Expert Comment

by:woolnoir
ID: 33557056
The ' Sending cookies ' section is one of the preventative actions the kernel can take

RedHat, like other Linux operating systems, has implemented a SYN cookies mechanism which can be enabled in the following way:
 # echo 1 > /proc/sys/net/ipv4/tcp_syncookies

from what i can see, thats what the log shows when that mechanism is in place.
0
Get free NFR key for Veeam Availability Suite 9.5

Veeam is happy to provide a free NFR license (1 year, 2 sockets) to all certified IT Pros. The license allows for the non-production use of Veeam Availability Suite v9.5 in your home lab, without any feature limitations. It works for both VMware and Hyper-V environments

 

Author Comment

by:ashwanijain
ID: 33557154
Thanks you !

IF these attacks were prevented, than why this server failed to make SFTP/FTP connection with other server during the period of these attacks.  ?  

WIll you suggest putting this server behind Firewall (IPCOP) for better performance ?

Regards

Ashwani Jain
0
 
LVL 20

Expert Comment

by:woolnoir
ID: 33557200
Was the other server involved in the attack ? can you see which server the attacks came from - logs, or a FW device ? in general although the linux box protected itself, it may still have impacted the performance, potentially limiting connectivity during the time - it would need to be audited to determine exactly.

As with any internet facing device, putting it behind a 'stateful' FW device will reduce its exposure to an attack, the FW would of filtered the attack before it reached the box, potentially avoiding any connectivity disruption.

If the attacks happen again - try and get something to log ther source, maybe a ethereal packet sniffer or something like that ?
0
 

Author Comment

by:ashwanijain
ID: 33557248
ok, there is one confusion,

what could be the RESULT if SYN FLOOD attack was not prevented, I believe it would made system unavailable on network.  

In our case, SYN FLOOD attack was prevented but still it could not perform well on network and failed to make TCP connections.

So what did the Kernel achieve by preventing the SYN FLOOD attack ?


0
 
LVL 20

Accepted Solution

by:
woolnoir earned 1500 total points
ID: 33557304
check this again http://www.symantec.com/connect/articles/hardening-tcpip-stack-syn-attacks though the first item is one way to protect the machine, there are other ways of enhancing its ability, hardening it even more.. further down the page.
0
 

Author Closing Comment

by:ashwanijain
ID: 33560074
The person hepled quickly and pointed to correct document.  How ever if he could tell steps to harden the linux to avoid SYN FLOOD attacks directly in the ticket instead redirecting to the doc that could be more easier to follow.

Still this was the accureate and timley given solution.
0
 
LVL 24

Expert Comment

by:rfc1180
ID: 33563244
>How ever if he could tell steps to harden
I disagree! Why reinvent the wheel; the document was very easy to follow, no reason to put it in any other way.
0
 

Author Comment

by:ashwanijain
ID: 33565180
THats correct but not excatly in all situations and conditions.  I also googled and found many such documents.  But why I come to Experts-Exchange is that some experts could give solutions based on his own experience.  Understand my issue and provide direct answers/solutions (command and steps) to fix the the issue, but if he again diverting to docs than why to come to experts exchange, I could google around and find such docs.  

Secondly, the document referred by the expert was helpful to understand the issue and fix it, he also helped in clearing up some confusion arising after reading the doc but still that doc did not tell specific command to change values for synack_backlog size and synack_retries.  Changing the values for two entries was the exact solution.  If I could get to know by the Experts that just go and change values for these two variables (also steps to change these) than it could have saved much of my time.

Still I say woolnair helped me a lot by replying quickly to all my queries.
0

Featured Post

WatchGuard Case Study: Museum of Flight

“With limited money and limited staffing, we didn’t have a lot of choices in terms of what we could do to bring efficiency. WatchGuard played a central part in changing that.” To provide strong, secure Wi-Fi access within the museum, Hunter chose to deploy WatchGuard’s AP120 APs.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

If you use Debian 6 Squeeze and you are tired of looking at the childish graphical GDM login screen that is used by default, here's an easy way to change it. If you've already tried to change it you've probably discovered that none of the old met…
BIND is the most widely used Name Server. A Name Server is the one that translates a site name to it's IP address. There is a new bug in BIND (https://kb.isc.org/article/AA-01272), affecting all versions of BIND 9 from BIND 9.1.0 (inclusive) thro…
How to Install VMware Tools in Red Hat Enterprise Linux 6.4 (RHEL 6.4) Step-by-Step Tutorial
If you're a developer or IT admin, you’re probably tasked with managing multiple websites, servers, applications, and levels of security on a daily basis. While this can be extremely time consuming, it can also be frustrating when systems aren't wor…

916 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question