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.