Wouldn’t it be possible, to have some iptables rules, like those I’m currently using for my web-server:?.. as long as general INPUT is DROP
iptables -A INPUT -p tcp --syn -m limit --limit 2/s --limit-burst 30 -j ACCEPT
iptables -A INPUT -p tcp --tcp-flags ALL NONE -m limit --limit 1/h -j ACCEPT
iptables -A INPUT -p tcp --tcp-flags ALL ALL -m limit --limit 1/h -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
Reviving a two-year-old thread might be considered a little faux pas, but that doesn’t render your question invalid. I’ve relocated it to a separate topic to avoid resurrecting past discussions.
In essence, envision iptables as a sturdy brick wall. If I were to approach it with a hammer, it might hold up reasonably well. Depending on its construction, it might even withstand a sledgehammer. However, if a barrage of ballistic missiles is unleashed upon it, the wall stands little chance, irrespective of its construction.
It’s crucial to recognize that iptables is a piece of software, and every operation it performs incurs a cost in terms of CPU and memory. The objective of a DDoS attack is to escalate this cost to an unsustainable level. Hence, it’s advisable to keep your firewall distinct from your server to prevent your security resources from being consumed by your Minecraft binary.
Even if voipms were entirely locked down, a determined attacker could employ a larger botnet to exhaust resources. Each dropped packet in your rules represents a nibble at your resources. However, the challenge lies in the fact that such services, like voipms, cannot be completely secured because they function as ITSPs, requiring people to connect to them. They lack the luxury of erecting absolute walls, making connection attacks against legitimate services a notable attack vector. Moreover, these services operate higher up in the stack, and the resources needed to reject or ignore a connection are more substantial.
To sum it up, firewall rules do matter, but they can be circumvented. The moment you introduce openings due to business necessities, the circumvention becomes more rapid. This complexity also leads you down additional paths, such as session border controllers, highlighting that security is seldom a straightforward solution akin to a hammer meeting a nail.
Side note the cost:
Netscout’s researchers analyzed 19 DDos-for-hire groups that claim to have successfully launched over 10 million attacks in total.
Many service providers often offer flexible payment plans based on the attack configuration, duration, and power measured in bandwidth and throughput.
Some offer free tests, while others charge a nominal fee of $5 over a five-day trial. A full attack that includes 100 concurrent attacks, no daily limits, and a committed 1 million packets per second (Mpps) cost a mere $6,500.
One DDoS-for-hire service provider claims to offer a 1 Tbps attack size using 150,000 bots for $2,499. Report’s authors note, however, they are yet to observe such an attack range actually developed by the group in real life.
I don’t understand how the anti-ddos rule helps. It seems to do the opposite. It means you only have to hit the victim with 30 hits in the first second and then you can keep them down with only two a second, which doesn’t even require a distributed attack.
Any idea how to improve the rule? And to keep in mind: Standard iptables general config within the pbx-distro is saying: INPUT ACCEPT and not INPUT DROP. Therefore rule anyway needs to be reverted maybe by a “!” somewhere in the amendment line…
Finally yes, this might not really help against hard attacks, but possibly for less professional ones. Other cases might need ISP’s help anyway.
Just mentioning that all of those intrusions were perpetrated against port 5060/UDP, using a less obvious transport will need different solutions but can only result in a ‘less busy’ firewall
In my point of view, if the DDOS traffic already reached your server/machine… there is not much you can do to stop or mitigate the huge amount.
Using a service like CloudFlare can help with that.
Problem here is: If you start using CloudFlare today… your source IP’s will be hidden.
But if an attacker checks a DNS history archive, they will find your source IP’s anyway, and can attack your IP directly instead of using your FQDN.
Maybe @dicko or @jfinstrom have any thoughts about this? 
We pass all connections through haproxy, ip based ones are silently dropped, only URL based ones are passed through after successful strict SNI checking.
Hi @dicko , Good one… stupid question: Does haproxy support UDP traffic? (it seems not?)
So you probably use TCP for all your traffic?
it’s a no-brainer, if >99% of all attacks are directed against UDP/5060, take a step sideways, so in my case yes, TLS/HTTPS for transport and different domains for admin,UCP,provisioning,SSH,phones etc. The backends are all on 127.0.0.1 using HTTP or TCP, certs are handled by haproxy and acme.sh
Move to IPv6 and you will likely not see a single stray packet hitting your interface.
Anecdotal and purely my experience a proper DDoS is hell to stop and sometimes requires physically pulling the plug. I have been on the receiving end of attacks where we had to get L3 involved to kill it. If you caught someone’s ire and they have the resources you will have a bad time no matter what you do.
I’m not sure if my comment was really understood. The iptables rule suggested actually facilitates an attack, as it means that the system stops handling traffic (service is denied) at a very low attack rate.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.