Bug 1274427
| Summary: | How to harder SYN attack against ldap server 389-ds? | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Noriko Hosoi <nhosoi> |
| Component: | 389-ds-base | Assignee: | Noriko Hosoi <nhosoi> |
| Status: | CLOSED NOTABUG | QA Contact: | Viktor Ashirov <vashirov> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.0 | CC: | nkinder, rmeggins |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-10-22 23:47:52 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. It is not an issue of DS, for more details, see this comment by William Brown: https://fedorahosted.org/389/ticket/47554#comment:11 |
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?