Firewall rules to secure CHR

ramirez · Thu Jun 10, 2021 10:29 am

Based on a previous post and the help from Sindy: viewtopic.php?f=2&t=175285#p859705, I have managed to run a CHR on a remote dedicated server (Through Vmware).

The setup is as follows, Windows physical NIC : public IP 23.23.23.90 / gateway: 23.23.23.1 .

Went on and connected CHR’s ethernet 1 to Vmware’s : Network connection: Bridged (Automatic) and powered on the CHR, went to IP/address and gave 23.23.23.91/24 (assigned to me by the provider, have 6 in total) and in IP/routes dst. Address = 0.0.0.0 , gateway 23.23.23.1

The CHR, as expected has access to Internet and can be ping-ed from the Internet.

What would be a good set of firewall rules to secure it from attacks since there is no NAT (nor ISP modem or other firewall) involved while allowing at the same time L2TP/IPsec connections?
In other MT’s behind NAT and ISP modems, I have rules like the ones bellow but am unsure if they are enough to offer good/dissent protection.

/ip firewall filter
add action=accept chain=input dst-port=500,1701,4500 protocol=udp
add action=accept chain=input protocol=ipsec-esp
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid log=yes

Thank you in advance!

viewtopic.php?f=2&t=175285#p859705

mkx · Thu Jun 10, 2021 6:17 pm

A pretty safe approach when constructing firewall rules is to have ultimate rule in both input and forward chan which drops everything not accepted by previous rules. Your setup only drops invalid packets which doesn't really protect your router (or network behind that router). Remember: implicit last rule is to accept packet. It's much easier to create safe rule set with "drop all" as last rule since it's easy to notice that some legitimate traffic is getting dropped (due to forgotten accept rule) ... OTOH it's hard to spot any missing drop rule ... until after it's too late.

ramirez · Fri Jun 11, 2021 10:17 am

Thank you MKX,

So if I understand it correctly create at the end two rules one for input and one for forward in this way ? : add action=drop chain=input and add action=drop chain=forward or after action=drop chain=input comment="defconf: drop invalid" connection-state=invalid and action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid log=yes respectively?

And then have them appear in logs to see if any legitimate traffic is blocked ?

mkx · Fri Jun 11, 2021 10:16 pm

Something like that. If you need to add some accept rules later, push them just below the "drop invalid" rules and above the new "drop all" ones.

I wouldn't log all hits of "drop all rules", there might be many entries due to bots scanning the network. A missing accept rule will be very obvious because something won't work.

ramirez · Mon Jun 14, 2021 9:52 am

Thank you, so either will work (right after the drop invalid in input and forward, or last two rules drop ), correct?

Firewall rules to secure CHR

Firewall rules to secure CHR

Re: Firewall rules to secure CHR

Re: Firewall rules to secure CHR

Re: Firewall rules to secure CHR

Re: Firewall rules to secure CHR

Who is online