|(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix
|TCP/IP Network Troubleshooting
|Network Troubleshooting Tools
|bnx2: eth0 NIC Copper Link is Down
|TCP Performance Tuning
|Linux Troubleshooting Tips
|Admin Horror Stories
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).
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:
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.Case 2:
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.
Operating system: Linux
tcp_max_syn_backlogvariable 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
sysctlor standard Unix commands. The following example shows how to change the default size of the backlog queue by the
sysctlcommand:# 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_q0parameter 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
nddcommand 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_maxTCP/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
nddcommand, similar to the one used in a Sun Solaris system.# ndd -set /dev/tcp tcp_syn_rcvd_max 2048
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 (
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
tcp_synack_retriesvariable 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_cintervalparameter. 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_min. These three variables are the same as in a Sun Solaris operating system.
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].
Hi folks Ii've got an understanding problem.
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?
2. More than the kernel's default number of tcp SYN packets coming in per second ? What is that default?
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
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.
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.
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
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.
Google matched content
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
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
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
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
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
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to to buy a cup of coffee for authors of this site
Last modified: March 12, 2019