Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1274427 - How to harder SYN attack against ldap server 389-ds?
Summary: How to harder SYN attack against ldap server 389-ds?
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-10-22 17:00 UTC by Noriko Hosoi
Modified: 2020-09-13 20:48 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-10-22 23:47:52 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 891 0 None None None 2020-09-13 20:48:39 UTC

Description Noriko Hosoi 2015-10-22 17:00:54 UTC
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?

Comment 1 Noriko Hosoi 2015-10-22 18:31:46 UTC
Marcelo gave us this info about hping3.

On 10/22/2015 11:18 AM, Marcelo Leitner wrote:
> You may use hping3 tool for that. It's packaged in EPEL. With it you can
> generate nearly any kind of (syn) flood you want. Like:
>
> # hping3 -p 389 -S <server ip>
> will send a syn at every second to the server
> it will use a random src port by default, so it's like just a peer doing
> multiple requests by also like multiple clients behind a NAT.
> I don't think you will need, but you may also use --tcp-timestamp . With
> it, it will be more like multiple clients behind a NAT.
>
> # hping3 --rand-source -p 389 -S <server ip>
> same, but with random source. Really random, so use with care as the
> target system will probably generate replies to random dests and may
> flood some link that you're not actually willing to.
>
> # hping3 -a <spoof src addr> -p 389 -S <server ip>
> use this spoofed src. So you can simulate a couple of servers, like in
> the BZ description
>
> # hping3 -a <spoof src addr> -c <count> -p 389 -S <server ip>
> send <count> packets
>
> and you can also control the rate:
> --flood switch will just send as fast as possible
> there is also -i, --fast and --faster
>
> The tool is very fast. It can cope with the rate you need. But if you
> really need multiple src addresses, you can use a host with 2 or 3
> addresses on it, it's still enough to simulate that traffic pattern.

Comment 2 Noriko Hosoi 2015-10-22 23:47:52 UTC
It is not an issue of DS, for more details, see this comment by William Brown:
https://fedorahosted.org/389/ticket/47554#comment:11


Note You need to log in before you can comment on or make changes to this bug.