-1

I'm having a problem stopping a DDOS attack on a dedicated server. I have tried a lot of things (mod_evasive, apf, ddos deflate, bfd...). The attack is very big and from a lot of differents IPs, and the firewalls and protections don't detect it.

I've made a system that only allows certains IP's and drops all another connections (a whitelist) with iptables, dropping all inputs. I know it works properly and if I do a ping there is no response, like expected. I've read something about DROP and REJECT but i don't understand it very well.

The problem/question is that when the attack starts, it continues causing lag on the server, even with the whitelist active. Why does this happens?
Iptables save
P.D. I have a script in python that adds the ips of a .php to the list if they aren't already in it
I think the attack is to the port 25565 (a game server)

Community
  • 1
user2351607
  • 13
  • 4

1 Answers1

1

DROP vs REJECT

I've read something about DROP and REJECT but i don't understand it very well.

The difference between DROP and REJECT is, that DROP, well, simply drops the packet, that is acting like it didn't arrive in the first place, whereas REJECT drops the packet and sends a reason, why the packet has been rejected, back to the source. The reason is user-defined and can be either a ICMP message or a TCP reset.

Which one to use can not be answered in general and there are many discussion, like this one, around this issue. REJECT is easier to debug, because you know that the firewall dropped a packet. Network or routing problems can be precluded this way.

My personal opinion is that it depends on the reason, why you do not want to ACCEPT a packet. If it clearly a bogus packet, like for example a packet with a spoofed IP address, arriving on your internal network, you should LOG and DROP the packet, but in other cases, like closing unused ports, I would use REJECT with some rate-limiting, because DROP would lead to timeouts.

In case of a DDoS attack, I would definitely use DROP, as REJECT will cause additional load on your machine and this amplifying the attack even more.

Possible reasons for performance problems

Now back to your main problem: Why are there still performance problems, even though you used iptables. Well that's hard to answer, as there are many potential reasons:

  1. The attack is simply to big. Even though you're filtering the bad packets, they are still arriving on your network link and filling buffers. If the bandwidth of the attacker is big enough to fully utilize your network links capacity, there is nothing you can do. You should contact your service provider. They maybe able to filter out the attack traffic at intermediate node or do something else, like in the recent spamhaus.org attack, distributing attack traffic via multicast.

  2. The number of iptables rules could be too big. You said, you're adding a rule for every hosts in the whitelist. If there are many hosts, each packet has to be matched against each host's IP address. You could try to group several hosts, if they are in the same subnet and match against the subnet instead.

    iptables -A INPUT -s 1.2.3.0/24 -j ACCEPT

This would allow all hosts from 1.2.3.0 to 1.2.3.255. Or you could use ipset for this. It's goals

If you want to

  • store multiple IP addresses or port numbers and match against the collection by iptables at one swoop;
  • dynamically update iptables rules against IP addresses or ports without performance penalty; express complex IP address and ports based rulesets with one single iptables rule and benefit from the speed of IP sets

seem to match your use case very well.

Community
  • 1
Sebastian Schrader
  • 520
  • 3
  • 11