SYNPROXY connections fail on IPFire

Security
1

I am attempting to use SYNPROXY to protect my mail server from an ongoing SYN Flood attack. The mail server is on my green network for which I have generated this port forwarding rule:

A NAT_DESTINATION -d a.b.c.d/32 -p tcp -m tcp --dport 25 -j DNAT --to-destination 192.168.X,X

To enable SYNPROXY I use the following:

sysctl -w net/netfilter/nf_conntrack_tcp_loose=0
echo 2500000 > /sys/module/nf_conntrack/parameters/hashsize
sysctl -w net/netfilter/nf_conntrack_max=2000000

iptables -t raw -I PREROUTING -p tcp -m tcp --syn -j CT --notrack
iptables -I INPUT -p tcp -m tcp -m conntrack --ctstate INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

This works OK when applied to the mail server but when applied to IPFire all connections on port 25 are dropped.

From what I can find out the problem is the NAT modules and Conntrack tracking table need to be kept synchronised with a rule similar to:

iptables -t nat -A PREROUTING -p tcp -o eth1 -j DNAT –to 192.168.X.X:25

but I’m not sure how this should be applied to IPFire.

Would appreciate some help here since my knowledge of iptables is rather limited.

In future releases would it be possible to add an option in IPFire to enable SYSPROXY in Firewall Options?

Rob
IPFire 2.23 (i586) - Core Update 136

2

Hey Rob,

I am generally interested in this, but I do not follow entirely where this is going wrong.

So you want IPFire to not forward those TCP connections just yet, but rather have it establish it first and then forward it to the internal mail server. Makes sense.

Did you run these commands exactly like this? IPFire has many things in those INPUT/PREROUTING chains which should always be processed first.

The last command is just a port forwarding rule (or half of it).

3

Continuing the discussion from SYNPROXY connections fail on IPFire:

Hi Michael,

In my (ongoing) SYN Flood attack my server is being sent SYN packets with a spoofed source address which obviously don’t get the SYN-ACK reply because they are being sent from a foreign address. I have been getting up to 70,000 of these per day and have managed to block them with iptables so far but now the spoofed address are from /17 net blocks and the block list has become unmanageable.

I have enabled SYNPROXY on my debian server which is blocking the unreplied connection attempts at the server but since I am port forwarding from my firewall the connections are still being made to IPFire first. If I can enable synproxy in IPFire the bogus connections should be rejected at the firewall.

The details for enabling synproxy on debian are here:
https://www.dbsysnet.com/2019/02/homemade-ddos-protection-using-iptables-synproxy

but this failed to forward any genuine smtp packets through the firewall when I applied the above commands to IPFire although I did confirm that synproxy was enabled OK.

I am pretty sure that the problem is caused by a conntrack / nat conflict as advised here:

but I am not sure how the rules in this article should be applied to IPFire.
I am fairly confident that if suitable INPUT/PREROUTING can be applied it should work OK.

If you have any ideas, I would be more than happy to test them here.

Thank you

Rob

4

Hi all,
IPFires firewall WUI do have the “Rate-Limit new Connections” which is also outlined as useful in the wiki --> https://wiki.ipfire.org/configuration/firewall/rules for Syn-Flood attacks. May “Concurrent-Connections” can also serves some protection ?

Did you seen or tested this ?

Best,

Erik

5

I have Rate-Limit new Connections set to 2 per second but at last count I still had over 100 “SYN” SMTP connections to IPFire. It’s a difficult setting to get right because I don’t want to prejudice legitimate mail.
I need an automated way of blocking connections and have had some success with FAIL2BAN running on the server but that is only really effective when they are targetting specific IPs but it isn’t very useful when they are cycling IPs around a netblock . I have also had some success with ‘Banish’ which I ported over from IPCop and can block netblocks with iptables but entries need to be manually added.

SYNPROXY running on the server is doing a good job of rejecting the flood from the server but would be much better if I could get it to work on IPFire.

Regards
Rob

6

Would your employer be able to sponsor some work to add this to IPFire?

7

Sadly there is only me as I am a retired engineer :frowning_face:

Rob

8

Ah okay. That would have helped us to prioritise this topic.

From what it looks like, the IPFire kernel has everything we need enabled, but it will be slightly tricky to get it into the firewall scripts and avoid any interference with other things.

9

That was my impression and as I said above it looks like synproxy is working OK when enabled, it looks like just not playing very nice with port forwarding.
I would be very pleased if I can help in any way if I can.

Incidently synproxy is an option from the gui in pfSense although I have never used it.
Rob

10

If it is of any help I found this shell script on GitHub which may be of use.

Rob

11

Yes, that pretty much sums it up what has to be done. However, IPFire has a hundred other features here which mark packets for NAT and other things and we need to take care of them.

It is not super-major work, but it will be at least half a day and of course needs to be added to the UI.

1 Like
12

https://patchwork.ipfire.org/project/ipfire/list/?series=4260

1 Like
13

Thank you for this Michael, although for me I have been somewhat overtaken by events. I had some good results from fail2ban on my mail server with a “SYNPROXY” jail which detected the synflood packets and added an iptables rule to the CUSTOMFORWARD chain which blocked the incoming address.

Although my fail2ban jail is still active I haven’t detected and ‘hits’ since the end of 2021. This maybe due to other blocking techniques (eg ipblocklist) introduced since then.

The addition of SYNPROXY to ipfire will be a very useful addition to protect from DoS attacks.

Thank you for adding this.

Rob

1 Like
14

How to do this in my ip fire… my server also under attack

15

At the bottom of the firewall rule setup page in “additional settings” There is a check box.

16

I think you need to be running at least CU 187 so upgrade if necessary with Pakfire.
I’ve not used the IPFire version of Synproxy as I ran a version on my server.

1 Like
17

Hi,

please see www.ipfire.org - IPFire Against The Bad Guys - Denial-of-Service Protection Of Up To Hundreds Of Gigabit/s for a general explanation of this feature, and which types of attacks it is able to secure your network against.

Thanks, and best regards,
Peter MĂźller

2 Likes
18

Ipfire only protect TCP and to bad for UDP

19

How do you mean that? You can both define rules for TCP and UDP protocols.

20

Hi,

as explained in the blog post I linked above, the SYN flood protection only works on TCP, because UDP is an entirely different protocol that just doesn’t work the way TCP does.

As this thread is on the SYN flood protection feature, please open a new thread for discussing your scenario, so this thread will stay focused.

Thanks, and best regards,
Peter MĂźller

1 Like