SYN Flood Attack
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.
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.
ASKER
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
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
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_syn
from what i can see, thats what the log shows when that mechanism is in place.
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_syn
from what i can see, thats what the log shows when that mechanism is in place.
ASKER
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
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
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 ?
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 ?
ASKER
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 ?
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 ?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.
Still this was the accureate and timley given solution.
>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.
I disagree! Why reinvent the wheel; the document was very easy to follow, no reason to put it in any other way.
ASKER
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.
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.
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.