attachment

deferred cloning, leave for investigation

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1274427

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/

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/891

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.