I have a virtual environment and I am making a SYN flood attack to a Ubuntu Server's port 53 using Kali 2020.
I realized that a countermeasure for this attack is to limit or block the responses to the SYN packets, which are the SYN,ACK.
But how can I do this with iptables?
What else should be done to prevent that kind of attacks?
Blocking the SYN,ACK response is not the right way to go about SYN flooding. Every TCP 3-way-handshake starts with a SYN. If you block the SYN,ACK response, no client will be able to successfully connect to your server anymore.
I recommend reading up on SYN flooding and prevention techniques in this Hakin9 article. The key mechanism, if you want to solve it with an iptables rule set, is limiting the rate of SYN requests from a single IP. The following is a suitable configuration, although you could of course have false positives, if a get a lot of legitimate requests from a single IP address (e.g. if there is a large network behind a NAT).
# iptables -A INPUT -p tcp -m state --state NEW -m recent --update --seconds 60 --hitcount 20 -j DROP
# iptables -A INPUT -p tcp -m state --state NEW -m recent --set -j ACCEPT
Rate-limiting is a sensible measure.
When building your own iptables rules, you should also log dropped/rejected packets so that you can debug and investigate. Use the --limit option so as not flood your logs. This will help you tune settings and also verify that the rules actually work as intended.
Suggestion: install CSF+LFD.
This is a Fail2ban-like tool that comes with a number of prebuilt iptables rules and it will also protect against brute-force attacks on SSH, SMTP etc by blocking attackers using iptables. It will also thwart port scanning attempts by temporarily blocking the source IP address.
However, if you become the target of a large scale attack your server will suffer nonetheless and may crawl to a halt. DDOS attacks are not rare and do not always target the big companies, it's also the small sites. Like those that have competitors. That's why companies like Cloudflare have become popular.
Since you mention port 53, that means you have a DNS server or resolver listening. Then you should take care that your server does not become an unwitting accomplice in reflection attacks.
For example I have a server that also acts as a resolver but port 53 is not publicly exposed to the Internet - it is bound to an IP address in a private range (172.20.x.x) on the tun0 interface, so that only VPN clients can see it and use it.
One of the most obvious ways to improve your security posture is to reduce your attack surface, that means expose a few ports as possible and restrict access whenever possible, for example by whitelisting IP address ranges when applicable. If you don't need that DNS service, then shut it down or don't expose it. Otherwise make sure it does not get abused.
It would also be a good idea to use a port scanner like nmap against your server and check every port 1-65535 from inside your company and also from the outside, and see which ports are showing up as open. Many services are exposed unnecessarily, only because the sysadmin did not bother to check and come up with adequate firewall rules. For example port 3306 (mysql) does not have to be exposed, most of the time. Nor does SQL Server (1433) or Oracle (1521). Usually those ports should not be visible beyond your LAN.
If you indeed have remote clients that need to connect to your server, you should whitelist their (static) IP addresses. A VPN tunnel can be a solution too.
--> NB: do the test before installing CSF+LFD or a similar tool, because they will obviously interfere with your reconnaissance efforts. Or stop the service temporarily.
One more thing: if your server has public IPv6 addresses, then you should also do the port scanning test in IPv6, because iptables does IPv4 only. The IPv6 counterpart is ip6tables. What you have to do is duplicate your IPv4 rules to IPv6, more or less. I say more or less because there are differences between the two protocols.
