|
|
|
|
|
|
by LinuxBender
697 days ago
|
|
|
This looks interesting, I might try attacking my own nodes with it. Out of curiosity have you done anything to make the packets more "real looking" than hping3? I ask because dropping floods from hping3 can be done with a single iptables rule as they do not set options in the header that would make the syn packets appear to be legit. MSS being the most obvious Have you also tried taking the reverse challenge a.k.a. blue team and defend against your own tool? What methods would you use if someone were using this against servers you wanted to stay up? e.g. CDN? IP stack hardening? eBPF rules? |
|
|
Although hping3 does not let you specify TCP options, it still lets you append them as raw data. Despite that, only one application that I tested actually sent TCP (+options) back to its server. However, this specific server still ACK'ed my packets and proceeded normally, even if I did not send these so-called options. In any case, it will be easy to just append the options as raw data at the end of the packet buffer, for targets that actually discriminate based on options.
None of the real-world applications that I tested used fragmentation, and they all tagged their packets with "DF" (do not fragment); due to that, I did not really look into how fragmentation would affect this.
The reason I specifically included CIDR support, something that both nping and hping3 lack in their source IP parameter, was that ISPs or mid-route routers could block "nonsense" traffic (e.g., a source IP outside of the ISP or even country's allocated range) coming from a client; this is called "egress filtering." However, in a DHCP-assigned scenario, you still have thousands of IP addresses in your subnet/range to spoof, which should not get caught by this filtering. Ultimately, because the source IP would be coming from an entire range of addresses, firewalls (and CDNs) will have a harder time detecting a pattern as to block it.
As for defending against TCP SYN flooding in general, you could use "SYN Cookies" (https://en.wikipedia.org/wiki/SYN_cookies) as to expand less resources in keeping connections open. Unfortunately, in a residential ISP scenario where you only have one "real" IP address, your spoofed source IP would be chosen from a range of otherwise-legitimate addresses; those addresses (upon unexpectedly receiving SYN-ACK from your targeted server) would usually respond back to the original server with a RST packet as to terminate the connection, making it so that your "half-open" connections (the goal of SYN flooding) do not get to last as long. Lastly, this tool only really lets you flood packets as quickly as possible; if you have (or rent) multiple datacenter-grade bandwidth, powerful x86_64 CPUs, and lots of "real" IP addresses at your disposal, there would be little that your target could actually do to prevent you from DDoS'ing them. At that point, in the worst-case scenario, they could go "scorched earth" and reject all traffic from entire countries' ranges (saving their CPU/memory usage), but your packets would still continue getting routed there, and you could still saturate their download line.
As for how this could be made faster (without just throwing more cores and computational power at it), the entire overhead is on the Linux Kernel's "sendto()" side; perhaps writing a kernel module to communicate directly with the underlying NIC is the way to go.