Mitigate DDOS attacks in Linux with iptables

[FlipFlop™]

Thanks to Neolo for the info on this, here's how to use iptables in Linux to protect against DDOS attacks, assuming bots are NMDC-based only:

Code: [Select]

#FLEXHUB
-A INPUT -p tcp --tcp-flags ALL PSH,ACK -m multiport --dports HUB_PORTS -m string --algo bm --string "$Key" --to 150 -m limit --limit 2/second --limit-burst 2 -j ACCEPT
-A INPUT -p tcp --tcp-flags ALL PSH,ACK -m multiport --dports HUB_PORTS  -m string --algo bm --string "$Key" --to 150 -j REJECT --reject-with tcp-reset
-A INPUT -p tcp -m multiport -m connlimit --dports HUB_PORTS  --connlimit-above 1 -j DROP
Ofcourse replace HUB_PORTS with the ports your hub uses. Ports should be comma separated without spaces ex. --dports 411,444,555

[Hamachi]

What about ADC hubs ?

[FlipFlop™]

The ADC protocol has a mechanism that should prevent clients in a hub from being abused for DDOS.
IE: this is to prevent the clients in the hub from becoming the SOURCE of an attack.

The mentioned iptables setting will protect both NMDC and ADC hubs, or any other services running on the specified ports.

[Neolo]

Rule above does not protects ADC side as well as other services.
Rule tested on hub with users count around 200. If your hub much larger, limit/sec and burst values should be increased.

For ADC, just put "HSUP" instead of "$key" or make a separate rule set.
Rule based on deep packet inspection by matching string, which sends to hub only at the beginning of client entrance. To do not overload a system, we are inspecting only first 150 (bytes I guess, this value was set experimentally).

NOTE: Do not use -j DROP method at the first two lines of rule, bot's reconnects should be rejected immediately, otherwise it will create a queue until default timeout, where all instances of that bot will pass, but with a little delay.
NOTE2: "connlimit" means to allow only one client per IP. Useful against SYN-attack DoS (not DDoS).

[FlipFlop™]

I disagree: The rules protect attacks coming from NMDC hubs/clients, and will protect any service running on the mentioned HUB_PORTS, if you're running an NMDC or ADC/S hub on it doesn't matter.

You could indeed make a rule for HSUP but the ADC protocol already has protection to prevent clients from joining a DDOS attack, so an ADC based attack is less likely.

[Neolo]

STEP 2 protection:

For this step, your main chat should be globally locked and Reg profile is configured to pass through this lock.
DDoS bots are easily bypassing "only reg MC" by putting !regme (+regme) command at the beginning of their spam messages.
So let's try to mitigate this on a system level as well (until FlexHub owners will code something else maybe).

Code: [Select]

-A INPUT -p tcp -m state --state ESTABLISHED -m string --algo kmp --string "regme" --to 150 -m multiport --dports HUB_PORTS -m limit --limit 2/hour --limit-burst 2 -j ACCEPT
-A INPUT -p tcp -m state --state ESTABLISHED -m string --algo kmp --string "regme" --to 150 -m multiport --dports HUB_PORTS -j REJECT --reject-with tcp-reset

This should allow only 2 regs per one hour. It's safe to modify it according your needs.

[Neolo]

I disagree: The rules protect attacks coming from NMDC hubs/clients, and will protect any service running on the mentioned HUB_PORTS, if you're running an NMDC or ADC/S hub on it doesn't matter.

You could indeed make a rule for HSUP but the ADC protocol already has protection to prevent clients from joining a DDOS attack, so an ADC based attack is less likely.

Nope, look carefully, none of TCP packets will match these rules without containing "$key" string. As soon as $key sent by client only, rule will apply to incoming packet only. All other packets from hub and client are ignored.
For example, it won't protect Apache or MySQL, until you'll put "$key" on your HTML page.
String can be chosen more complicated if so.
3RD rule "connlimit" - yes, it will protect any service on these ports.

[FlipFlop™]

I think you misunderstood, if you specify port 80 as HUB_PORTS it will protect Apache (running on port 80) from NMDC based DDOS attacks. But ofcourse it will not protect from other types of attacks, and I didn't say it would.

[Neolo]

I think you misunderstood, if you specify port 80 as HUB_PORTS it will protect Apache (running on port 80) from NMDC based DDOS attacks. But ofcourse it will not protect from other types of attacks, and I didn't say it would.

But nobody will use NMDC ddos on your Apache =). That's senseless.

[FlipFlop™]

DDOS is DDOS, you can take down a hub, website, or entire server with it if done 'properly' and with enough bots/users.

[Neolo]

Here is STEP 1 alternative method without using -m string.

Code: [Select]

-A INPUT -p tcp -m state --state NEW -m multiport --dports HUB_PORTS -m limit --limit 1/second --limit-burst 1 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m multiport --dports HUB_PORTS  -j REJECT --reject-with tcp-reset

Deep inspection is not required when client logs in, in this case it's equal to state NEW.
But, as discussed above, it will affect any packets of any service under provided ports.

UDP: This method with state NEW is not reliable and need to be tested.

[Neolo]

Recently I found another wave of weird bots are quietly connecting to my hub (NMDC) with dynamic nicknames, shares and IP addresses and sitting there.
Only one thing is bounds them is description "34". So it's easy to create a pattern record and filter them out using hub.
But it send in respond about forbidden pattern found, so to do not tell to unwanted visitors about how we are filtering them, I will use my favorite iptables, again

Code: [Select]

#UNWANTED DESCR FILTER
-N stage2
-A INPUT -p tcp --tcp-flags ALL PSH,ACK -m multiport --dports HUB_PORTS -m string --algo bm --string "$MyINFO" --to 150 -j stage2
-A stage2 -p tcp -m string --algo bm --string "34<" --to 150 -j REJECT --reject-with tcp-reset
According to NMDC specification "$MyINFO $ALL <nick> <description>$ $<connection><flag>$<e-mail>$<sharesize>$|", we can catch that description like "34<", because after it follows client's tag, which begins with "<". Now those flooders will be just disconnected without explanations why. -j DROP method can be used to decrease server load by responding each tcp packet.

This an example of usage. Rules can be rewritten for any purpose of silent filtration.

[newborn]

Thats some leet stuff with iptables you're doing there man. I never knew about that capability, thank you for broadening my horizons!