Our 389-ds ldap server had been "attack" by the SYN flood by our 3 new ldap clients at a far-away remote site. It seems the line-quality, the vpn tunnel, many hops, delay, DF-bit ...were the reason why the data packets didn't come completely through. The clients keeping sending the SYN and then flood the 389 port on the ldap server (notice port 636 is still OK)
We need to disable ldap on the new clients and restart ("kill -9") the slapd to fix the incident. For more info, pls see the bottom at the ticket https://fedorahosted.org/389/ticket/47542
Following to this incident I have 2 questions:
1) Is there a way the ldap server can handle it? harder such kind of situation? (don´t break down, but just reject those SYN?)
2) can 389-ds set the DF (defragment bit) bit depending on the enviroment? (if the OS has DF=1, does the 389-ds obey this rule or does it do something else?)
see attachment, it is from the tcpdump, showing DF is set on the ldap server.
Don't Fragment bit: http://www.ietf.org/rfc/rfc2923.txt
According to the rfc document, it is the router who warns (using icmp) the source (host) if the packet is too large (otherwise nothing get through)
Does 389-ds using the DF bit? or does it leaved the DF bit to the OS TCP stack?
deferred cloning, leave for investigation
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1274427
Summary: This isn't a DS problem, it's an OS tuning issue. Look at net.ipv4.tcp_max_syn_backlog in sysctl.conf
When a TCP connection is opened to a linux system, the sequence is
| ---- SYN ----> |
| <-- SYN + ACK -|
| ---- ACK ----> |
| ---- DATA ---> |
In linux the full handshake SYN through to final ACK is taken care of by the kernel. Only when the final ACK is complete is a socket opened into the process.
So by the nature of this attack, because the server is only carrying out:
| ---- SYN ----> |
| <-- SYN + ACK -|
The socket is never opened on the DS instance. A syn attack is really just an attempt to overload the linux kernel tcp handshake mechanism. And it's extremely effective. You can carry this out pretty easily with:
hping3 -S -p 389 --flood <target>
I did this against a box to prove a point, and you can see the contents of the access log are:
However, if the handshake were completed, say by a simple utility like netcat, you see this in the logs:
[23/Oct/2015:08:45:14 +1000] conn=19 fd=92 slot=92 connection from 192.168.122.1 to 192.168.122.211
[23/Oct/2015:08:45:14 +1000] conn=19 op=-1 fd=92 closed error 104 (Connection reset by peer) - TCP connection reset by peer.
Linux has some protections against this style of attack, which you can read about  . By default the advice is 0, some of these values are already set:
[root@master ~]# cat /proc/sys/net/ipv4/tcp_syncookies
[root@master ~]# cat /proc/sys/net/ipv4/tcp_synack_retries
But you can see the synbacklog is low
They advise 2048, but I set it to 4096 when I worked at sites with high traffic volumes. Up to you, but really you are just "delaying the flood".
The second article in  is more involved with iptables, and may be harder to implement if you are running firewalld also.
The summary is that DS code is not affected by a SYN flood attack, and that to defend you need to tune you os. Like most DoS attacks, these are attacks that you can "slow the inevitable" but eventually a determined attacker will still take you down. If in your case, you are trying to prevent issues with clients that are unable to complete the handshake due to packet loss, you may see improvement by tuning as per these documents.
Metadata Update from @nhosoi:
- Issue assigned to firstyear
- Issue set to the milestone: 220.127.116.11
to comment on this ticket.