Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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?
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.
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?