Possible SYN flooding on port 25. Sending cookies

• Introduction
• The first line of defense -- settings in /etc/sysctl.conf
• Using
   

Introduction

You get a SYN flood when a "flood" of SYNs, which your kernel presumably acknowledges with a SYN-ACK, are not followed by ACKs.

The SYN flood will generally come from a faked IP address because the flooder is not waiting for the SYN-ACK to arrive back so it doesn't matter to him where the SYN-ACK is sent.

Traditionally (i.e. without SYN cookies) TCP connections have to be kept half open after receiving the first SYN because that is the way that TCP connections are established. And there is a limit to how many half open
connections the kernel can maintain at any given time.

If SYN cookies are enabled, then the kernel doesn't track half open connections at all. Instead it knows from the sequence number in the following ACK datagram that the ACK very probably follows a SYN and a SYN-ACK. That way SYN floods are not a problem to it.

In case of sendmail this messages can appears,  if the rate of incoming messages is too high. This has nothing to do with real SYN flood attack, but to IP stack it looks the same and Linux kernel report fake attacks. For example:

Feb 22 10:52:23 susehost kernel: [1874019.797638] possible SYN flooding on port 25. Sending cookies.

 See discussion of Fedora developers (Bug 734991 – Large numbers of TCP Possible SYN flooding on port X. Dropping request).

The first line of defense -- settings in /etc/sysctl.conf

One simple measure to protect against this error is to use settings in /etc/sysctl.conf file commended by Oracle (see Oracle kernel parameters tuning on Linux):

kernel.sem = 250 256000 100 1024
net.ipv4.ip_local_port_range = 1024 65000
net.core.rmem_default = 4194304
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 262144
net.ipv4.tcp_wmem = 262144 262144 262144
net.ipv4.tcp_rmem = 4194304 4194304 4194304
net.ipv4.tcp_max_syn_backlog = 4096

The key variable here net.ipv4.tcp_max_syn_backlog. Default for it is 2048. You can increase it to 4096 or higher, 8192:

sysctl -w net.ipv4.tcp_max_syn_backlog=4096

Frequency of this situation can vary, depending then the overload of your server happens. In our case this was approximately once a day when an avalanche of emails from some sender within the corporation hit the mail server. Typical syslog entries looks like:

Case 1:

Mar 1 10:46:56 mailserv kernel: [2477366.637321] possible SYN flooding on port 25. Sending cookies.
Mar 1 10:53:01 mailserv kernel: [2477730.560799] possible SYN flooding on port 25. Sending cookies.

Feb 11 09:29:01 mailserv kernel: [920398.445655] possible SYN flooding on port 25. Sending cookies.
Feb 11 09:35:05 mailserv kernel: [920761.595188] possible SYN flooding on port 25. Sending cookies.
Feb 11 10:46:58 mailserv kernel: [925067.426773] possible SYN flooding on port 25. Sending cookies.

NEWS CONTENTS

• 20130305 : Hardening the TCP-IP stack to SYN attacks Symantec Connect Community ( Hardening the TCP-IP stack to SYN attacks Symantec Connect Community, Mar 05, 2013 )
• 20130305 : Decreasing total time of handling connection request ( )
• 20130131 : syn flood understanding ( syn flood understanding, Jan 31, 2013 )

Old News ;-)

[Mar 05, 2013] Hardening the TCP-IP stack to SYN attacks Symantec Connect Community

Operating system: Linux

A tcp_max_syn_backlog variable defines how many half-open connections can be kept by the backlog queue. For instance 256 is a total number of half-open connections handled in memory by Linux RedHat 7.3. The TCP/IP stack variables can be configured by sysctl or standard Unix commands. The following example shows how to change the default size of the backlog queue by the sysctl command:

 # sysctl -w net.ipv4.tcp_max_syn_backlog="2048" 

Operating system: Sun Solaris

In Sun Solaris there are two parameters which control the maximum number of connections. The first parameter controls the total number of full connections. The second tcp_conn_req_max_q0 parameter defines how many half-open connections are allowed without the dropping of incoming requests. In Sun Solaris 8, the default value is set to 1024. Using the ndd command we can modify this value.

 # ndd -set /dev/tcp tcp_conn_req_max_q0 2048 

Operating system: HP-UX

In HP-UX, a tcp_syn_rcvd_max TCP/IP stack variable is responsible for control of the maximum number of half-open connections in the SYN RECEIVE state. In HP-UX 11.00 this value is set to 500. We can change this value by using the ndd command, similar to the one used in a Sun Solaris system.

 # ndd -set /dev/tcp tcp_syn_rcvd_max 2048 

Decreasing total time of handling connection request

As we know, SYN flooding/spoofing attacks are simply a series of SYN packets, mostly from forged IP addresses. In the last section we tried to increase the backlog queue. Now that our systems can handle more SYN requests, we should decrease the total time we keep half-open connections in the backlog queue. When a server receives a request, it immediately sends a response with the SYN and ACK flags set, puts this half-open connection into the backlog queue, and then waits for a packet with the ACK flag set from the client. When no response is received from the client, the server retransmits a response packet (with the SYN and ACK flags set) several times (depending on default value in each operating system) by giving the client a chance to send the ACK packet again. It is clear that when the source IP address of client was spoofed, the ACK packet will never arrive. After a few minutes the server removes this half-open connection. We can speed up this time of removing connections in the SYN RECEIVED state from the backlog queue by changing time of first retransmission and by changing the total number of retransmissions.

Another technique of protection against SYN attacks is switching off some TCP parameters that are always negotiated during the three-way handshake process. Some of these parameters are automatically turned off by mechanisms described in the first section (SynAttackProtect and Syncookies).

Now, I will describe TCP/IP stack variables which allow a decrease in the time half-open connections are kept in the backlog queue.

... ... ...

Operating system: Linux RedHat

A tcp_synack_retries variable is responsible for controlling the number of retransmissions in Linux operating system. Its default value is set to 5 for most Linux operating systems, which causes the half-open connection to be removed after 3 minutes. In the below table there are calculations for other values.

Value	Time of retransmission	Total time to keep half-open connections in the backlog queue
1	in 3rd second	9 seconds
2	in 3rd and 9th second	21 seconds
3	in 3rd , 9th and 21st second	45 seconds

Operating system: Sun Solaris

In this operating system it is impossible to turn off retransmissions of packets directly using the ndd command. Moreover, in Sun Solaris there are parameters which are non-configurable by ndd and which control the number of retransmissions (at least 3) and total time of packet retransmissions (at least 3 minutes). More information about these parameters can be found in the "Solaris 2.x - Tuning Your TCP/IP stack and More" document.

Operating system: HP-UX

For HP-UX, the time spent handling half-open connections in the backlog queue is controlled by the tcp_ip_abort_cinterval parameter. By using the ndd command we can define how long a HP-UX operating system will be waiting for the ACK packet. We can control how many retransmissions will be performed indirectly by changing this value. Have a look at the table below.

Value	Time of retransmission	Total time to keep half-open connections in the backlog queue
1000	-	1 second
5000	in 2nd second	5 seconds
10000	in 2nd and 5th second	10 seconds
60000	In 2nd, 5th, 11th, 23rd and 47th second	1 minute

We can change the time of a first retransmission by modifying tcp_rexmit_interval_initial. Intervals of subsequent retransmissions are controlled by two parameters: tcp_rexmit_interval and tcp_rexmit_interval_min. These three variables are the same as in a Sun Solaris operating system.

Summary

The methods of hardening the TCP/IP stack that are presented in this article make servers more resistant to SYN flooding and SYN spoofing - Denial of Service attacks. A modification of your default TCP/IP stack settings is also recommended during the process of securing of the operating system.

---

Mariusz Burdach is a computer security consultant who specializes in vulnerability assessment, intrusion detection and computer forensics. During the last few years he has worked as a consultant in the European Network Security Institute where he conducted penetration tests, vulnerability assessments and security audits for Internet banks, government and financial institutions in Poland. He is co-author of the Solaris Security Administrator's Guide, a step-by-step guide to securing SUN's Solaris operating system. Comments on this article are appreciated, send them to [email protected].

[Jan 31, 2013] syn flood understanding

Hi folks Ii've got an understanding problem.

# dmesg
yields lots of
"possible SYN flooding on port 25 sending cookies."

Right here goes...

I run qmail and can set the incomming concurrency value e.g. 100 to start up to 100 processes listening on port 25.

Is the syn flood:-
1. More emails trying to make a tcp connection but failing to find a process to handle the data?

or

2. More than the kernel's default number of tcp SYN packets coming in per second ? What is that default?

or

3. Assuming that the kernel sends a tcp SYN-ACK immediately on receiving a SYN packet and assuming that many will be faked IP's, is the SYN flood report based on the time it takes to receive the ACK packet from any genuine IP's ? (Since a SYN-ACK sent to an IP which didn't request one will be dropped - or is that the purpose of these kernel cookies?)

All of the websites I've found which suggest an iptables

ruleset use the --limit.. as in
# iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j
ACCEPT

I guess this will affect genuine and spoofed IP attempted connections.

Is there anyway of setting a snesible time for the final ACK of the tcp handshake? (assuming that a genuine connection request will respond quickly and a faked IP won't respond at all)

Sorry for so many questions, feel free to answer any parts you can.

Thanks

=====

You get a SYN flood when a "flood" of SYNs, which your kernel presumably
acknowledges with a SYN-ACK, are not followed by ACKs.

The SYN flood will generally come from a faked IP address because the
flooder is not waiting for the SYN-ACK to arrive back so it doesn't
matter to him where the SYN-ACK is sent.

Traditionally (i.e. without SYN cookies) TCP connections have to be kept
half open after receiving the first SYN because that is the way that TCP
connections are established. And there is a limit to how many half open
connections the kernel can maintain at any given time.

If SYN cookies are enabled, then the kernel doesn't track half open
connections at all. Instead it knows from the sequence number in the
following ACK datagram that the ACK very probably follows a SYN and a
SYN-ACK. That way SYN floods are not a problem to it.

Robert

need help! possible SYN flooding on port 80 - Web Hosting Talk

Log into your box and do this

# sysctl -w net.ipv4.tcp_syncookies=1

Then add this to your /etc/sysctl.conf file

net.ipv4.tcp_syncookies=1

To make sure is enabled

# cat /proc/sys/net/ipv4/tcp_syncookies

will retrun 1 for enabled, 0 for disabled.

If you are having any issues that are affecting the server, ie apache going down due to this, there are some other options that you can take, but if it's not actually causing a problem like that then you migh not need to do anything else.

Have someone tweak your apache for you maybe as well, to avoid any situations that could easily be avoided.

Recommended Links

Softpanorama Recommended

Top articles

Sites

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019