New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
About IPTABLES rules for ddos protection
CiprianoOscar
Member, Host Rep
in Help
Hi guys, I'm doing some work on a server and I wanted to apply some iptables rules to avoid DDoS attacks. I still don't understand if iptables can block the attacks, I'll explain what I was going to do.
I have this server that needs to communicate only with another X server, no other type of service needs to be started on this dedicated one, so I was going to block traffic from all ipv4s and whitelist only those I need, that is the X server
Also, I will only need the ssh port (Changed is no longer 22) and will only access it via a static ipv4 (VPN).
Could this work (which I know how to do) help ddos attacks? I state that the server already has excellent anti ddos protection, but I would like to improve more and more
Comments
We did that back in 2012, I can assure netfilter isnt really suitable for ddos protection. Even with our own netfilter hooks back then, we were only able to reach a maximum of 5mpps at 64 byte packetsize per machine. It's even worse whenever conntrack is enabled, the underlying "hashtable" is quite slow. I assume, the Kernel hasnt changed too much, so I still wouldnt expect great performance from the linux kernel / netfilter itself due to the amount of memory copies involved.
If you want to do traffic filtering on the server directly, check out XDP. Other approach might be DPDK or Netmap (we are an heavy user), which bypasses the kernel completely and reads the packets directly from the NIC.
For DDoS protection the best is to use a service like Cloudflare.
I'm glad you state that the server you're on has DDoS protection already as this will be doing 99.99% of the work.
iptables is pretty useful for cleaning up any small amounts of leaking traffic.
As @combahton_it said, conntrack is pretty slow but in this case where your provider's network is already going to do the bulk of the work it should be fine to have a strict iptables ruleset accepting only new connection packets to the ports you needed, established/related connections that your server has initiated for example, and then setting a default policy of DROP.
It's also worth doing this in the PREROUTING chain of the mangle table, as this is the earliest point in the iptables stack that you can make decisions on packets for based on connection state. This is the same concept we use on all of our DDoS protected servers with pretty good results.
Thanks in advance to both of you.
Fortunately my provider has (for what little I have tried) a good anti ddos protection. But there are some methods that are not filtered very well and enter about 1-2Gbit / S (the server has 10Gbit / S), so I was hoping that with this method, we could eliminate this entry.
If you don't need state, you can do it in RAW. That's the earliest possible in iptables.
1-2Gbps is easily manageable by iptables and conntrack, but I would have concern for the packet rate and whether the leaking traffic is starting new connection flows with conntrack or not (I.e, sending SYN packets to your open ports)
Indeed. I would maybe drop all ports that aren't needed in raw, and then applying everything else in mangle.
With some of our servers we drop certain options in the TCP header in raw, and then apply our limiting rules and default policy in mangle.
I do this for most of my machines, but keeping the ssh port as 22. Only 2 IP addresses are able to access it, everything else is logged and dropped. Of course, this still shows up on a port scan as a filtered port.
I've been toying with the idea of sticking a rule in pre-routing that redirects port 22 to something that's unused for all the other hosts, so that an nmap wouldn't mention it at all, but that seems a little riskier somehow. If anyone else has done this, I'd be interested to know about how useful they found it as a strategy.
I'm also starting to play around with having everything closed externally and just a single wireguard UDP port open and have all the servers encrypt everything between each other.
kernel 5.10+ & nftables 0.9.7+ allows ingress filtering before prerouting in nftables (table type netdev) - you can also apply rate limiting on the ingress hook
dropping as many bad packets as possible before they hit conntrack will help