#47554 How to harder SYN attack against ldap server 389-ds?
Closed: Fixed None Opened 5 years ago by van12.

hi

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

Hi,

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

{{{
Client Server
| ---- 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:

{{{
Client Server
| ---- SYN ----> |
| |
| <-- SYN + ACK -|
| |
| Nothing
}}}

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 [0] [1]. By default the advice is 0, some of these values are already set:

{{{
[root@master ~]# cat /proc/sys/net/ipv4/tcp_syncookies
1
[root@master ~]# cat /proc/sys/net/ipv4/tcp_synack_retries
5
}}}

But you can see the synbacklog is low
{{{
cat /proc/sys/net/ipv4/tcp_max_syn_backlog
128
}}}

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 [1] 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.

Thanks!

[0] https://www.ndchost.com/wiki/server-administration/hardening-tcpip-syn-flood

[1] http://rhelblog.redhat.com/2014/04/11/mitigate-tcp-syn-flood-attacks-with-red-hat-enterprise-linux-7-beta/

Metadata Update from @nhosoi:
- Issue assigned to firstyear
- Issue set to the milestone: 1.3.5.0

2 years ago

Login to comment on this ticket.

Metadata
Attachments 1
Attached 5 years ago View Comment