0

Whilst setting up a VPS (specifically the firewall rules), I came across this article on using iptables to mitigate against DDOS attacks. I've seen this article referenced in a few places around the web so I tried implementing the rules as it advises.

Now, everything was fine until I added this rule from the 'Mitigating SYN Floods With Synproxy' section as shown below...

iptables -t raw -A PREROUTING -p tcp -m tcp --syn -j CT --notrack

When I added this rule, I immediately lost the ability to connect to/contact my server (port 80, SSH—although the currently open SSH session remained connected).

I tried to disabling UFW and it seemed to work OK, so I disabled UFW completely and just set up some basic iptables rules (I no longer use UFW).

I tried entering the rules as per the article again and the same thing happened.

If I just add the rule shown above (and no others from the article) then I don't lose my connection, so went through each of the original rules do determine which one was causing the issue and this is what I found...

The first rule in the article...

iptables -t mangle -A PREROUTING -m conntrack --ctstate INVALID -j DROP

... is what seems to be causing the issue when used in conjunction with the rule referenced above (please note I've also added the Kernel rules into sysctl.conf as recommended).

Here are my iptables rules (for the sake of brevity, I have omitted most of the rules from the referenced article, and am just using the rules which seem to be causing the issue).

*raw
:PREROUTING ACCEPT [537:54944]
:OUTPUT ACCEPT [290:34648]
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j CT --notrack
COMMIT
*mangle
:PREROUTING ACCEPT [580:65738]
:INPUT ACCEPT [580:65738]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [372:43208]
:POSTROUTING ACCEPT [372:43208]
-A PREROUTING -m conntrack --ctstate INVALID -j DROP
COMMIT
*filter
:INPUT DROP [15:5300]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [21:4232]
-A INPUT -s 127.0.0.0/8 ! -i lo -j REJECT --reject-with icmp-port-unreachable
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp -m conntrack --ctstate INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460
-A INPUT -m conntrack --ctstate INVALID -j DROP
COMMIT

I've been searching for some clues as to why this is happening for about a week now but have so far had no joy, and would appreciate if someone more conversant than I with iptables could throw some light on this for me or point me in the right direction.

PS I'm using Ubuntu Server 20.04

BungleBonce
  • 101
  • 2
  • To make a long story short, you need to add all three of the rules, and at the same time, not just two of them. – Michael Hampton Jan 31 '21 at 03:02
  • Hi @MichaelHampton, thanks for the comment. I have added all the rules as per the article. I was just pointing out that the problem occurs the moment I add that first of those 3 rules from the 'Synproxy' section—If I then add the other 2, the problem is still evident. (all 3 rules are in the example rules.v4 I showed above... actually 4 including the first rule in the article), but yes I have tried adding all 29 rules from the article and the result is the same. Cheers – BungleBonce Jan 31 '21 at 14:40
  • Hm, after doing some more looking around, I suggest you omit it entirely. The man page says: `The kernels ability to absorb SYNFLOOD was greatly improved starting with Linux 4.4, so this target should not be needed anymore to protect Linux servers.` Such is the hazard of trying to rely on outdated tutorials... – Michael Hampton Jan 31 '21 at 16:23
  • 1
    (rewrote comments): the SYNPROXY rule should happen before a rule shortcuiting it by accepting traffic unconditionally (port 22 and port 80). As SYNPROXY is responsible from transitionning from UNTRACKED or some INVALID (most probably because of the previous UNTRACKED) states to ESTABLISHED, this won't happen else. I'm not sur either if it can be compatible at all with the rule in the mangle table which already drop INVALID states meant to be handled by SYNPROXY. I can't be sure of all this, this probably requires a lot of testing (logs, traces captures...), so I won't make this an answer. – A.B Jan 31 '21 at 17:19

0 Answers0