Community discussions

 
User avatar
mrmut
Member Candidate
Member Candidate
Topic Author
Posts: 142
Joined: Mon May 18, 2009 2:10 pm

Incorrect firewall behavious

Sun Dec 09, 2018 1:02 pm

I have a very weird situation in which 3389 port goes through the routers, even if not forwarded / enabled. I have had to make a specific firewall rule to block the port!

Can you please take a look what I did wrong?
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=accept chain=input comment="L2TP allow only with IPsec" dst-port=1701 in-interface=ether10-WAN ipsec-policy=in,ipsec protocol=udp
add action=drop chain=input comment="Drop L2TP without IPsec" dst-port=1701 in-interface=ether10-WAN protocol=udp
add action=accept chain=input comment="L2TP allow" dst-port=500,4500 in-interface=ether10-WAN protocol=udp
add action=accept chain=input comment="IPSec enable" in-interface=ether10-WAN protocol=ipsec-esp
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=drop chain=input comment="defconf: drop all not coming from LAN" in-interface=ether10-WAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
I HAVE DISABLED THIS; AND THE 3389 STILL GOES THRU add action=accept chain=forward comment="RDP accept and forward to 192.168.10.3" disabled=yes dst-address-list=192.168.10.3 dst-port=3389 in-interface=ether10-WAN protocol=tcp
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
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
add action=drop chain=forward comment="drop unvanted local traffic" connection-nat-state=!dstnat connection-state=new in-interface=ether10-WAN
add action=drop chain=forward in-interface=bridge-local out-interface=bridge-ivana
add action=drop chain=forward in-interface=bridge-ivana out-interface=bridge-local
add action=drop chain=forward in-interface=all-wireless out-interface-list=LAN
add action=drop chain=forward in-interface-list=LAN out-interface=all-wireless
THIS ONE I ADDED TO BLOCK 3389 add action=drop chain=forward comment="explicitly drop 3389 in" disabled=yes dst-port=3389 in-interface=ether10-WAN protocol=tcp
 
2frogs
Long time Member
Long time Member
Posts: 540
Joined: Fri Dec 03, 2010 1:38 am

Re: Incorrect firewall behavious

Sun Dec 09, 2018 3:41 pm

add action=drop chain=forward comment="drop unvanted local traffic" connection-nat-state=!dstnat connection-state=new in-interface=ether10-WAN
This rule allows any DSTNAT rules through the firewall. Remove the connection-nat-state=!dstnat if you only want to specifically allow this traffic with individual rules.
 
User avatar
sebastia
Forum Guru
Forum Guru
Posts: 1795
Joined: Tue Oct 12, 2010 3:23 am
Location: Antwerp, BE

Re: Incorrect firewall behavious

Sun Dec 09, 2018 5:35 pm

Hey

any connection initiated from inside / lan will be allowed by these
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked

This one will drop spoofed traffic. if not dstnated and new from wan
add action=drop chain=forward comment="drop unvanted local traffic" connection-nat-state=!dstnat connection-state=new in-interface=ether10-WAN


Do you have dstnat rule for 3389?
Since it is not dropped by the above: it is dstnatted and is new -> it's not dropped, AND since you don't have general DROP all rule for wan i'ts all allowed.

Summary: you need to drop all other traffic from Wan in forward chain
Last edited by sebastia on Sun Dec 09, 2018 5:39 pm, edited 1 time in total.
 
User avatar
sebastia
Forum Guru
Forum Guru
Posts: 1795
Joined: Tue Oct 12, 2010 3:23 am
Location: Antwerp, BE

Re: Incorrect firewall behavious

Sun Dec 09, 2018 5:37 pm

add action=drop chain=forward comment="drop unvanted local traffic" connection-nat-state=!dstnat connection-state=new in-interface=ether10-WAN
This rule allows any DSTNAT rules through the firewall. Remove the connection-nat-state=!dstnat if you only want to specifically allow this traffic with individual rules.
This rule drops "not explicitly dstnat and new traffic" => spoofed traffic on wan.
 
2frogs
Long time Member
Long time Member
Posts: 540
Joined: Fri Dec 03, 2010 1:38 am

Re: Incorrect firewall behavious

Sun Dec 09, 2018 6:08 pm

/ip firewall add action=drop chain=forward comment="drop unvanted local traffic" connection-nat-state=!dstnat connection-state=new in-interface=ether10-WAN
This is the default drop rule! Any connection coming from WAN would first be New and therefore dropped, unless it is a connection in NAT that is DST-NAT and then it is allowed. Any following packets in the connection would be captured by the Estalished/Related forward rule as they are no longer NEW. This has nothing to do with spoofing.
 
User avatar
sebastia
Forum Guru
Forum Guru
Posts: 1795
Joined: Tue Oct 12, 2010 3:23 am
Location: Antwerp, BE

Re: Incorrect firewall behavious

Sun Dec 09, 2018 7:00 pm

Hey

We are talking here about the "forward" chain...

Options for new connection from wan
If dst-nat-ed => goes to forward chain
if not dst-nat-ed => goes to input chain, as it will carry ip of the router itself UNLESS

it is spoofed and carries dst ip of internal network => then it will go into FORWARD chain and is not dst-nat-ed
 
anav
Forum Guru
Forum Guru
Posts: 3134
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Incorrect firewall behavious

Sun Dec 09, 2018 7:27 pm

I would advise keep it simple!
Only allow what you want and then have a drop everything else rule at the end of both input and forward chains.

So one in general has
INPUT CHAIN
allow rules
drop everything else

FORWARD CHAIN
allow rules
drop everything else

Of course people throw in drop invalid traffic and other things but if you have a drop everything else rule they will all be caught.
Then it becomes CPU efficiency question. Do you want to drop traffic early so its not checked against all the other allow rules.

By not keeping it simple the OP has created a mess.
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
2frogs
Long time Member
Long time Member
Posts: 540
Joined: Fri Dec 03, 2010 1:38 am

Re: Incorrect firewall behavious

Sun Dec 09, 2018 8:45 pm

@sebastia

You have miss understood the problem of the OP! He has a forward rule to explicitly allow the dst-nat port. And the problem he is having is when that rule was disabled, he is still able to reach the port. The answer is what I provided. The default drop rule is allowing this traffic.
 
User avatar
sebastia
Forum Guru
Forum Guru
Posts: 1795
Joined: Tue Oct 12, 2010 3:23 am
Location: Antwerp, BE

Re: Incorrect firewall behavious

Sun Dec 09, 2018 10:02 pm

Hey, nothing personal, and I can be incorrect too.

Just that in my opinion the explanation given was incorrect and hence I wanted to clarify it.
 
anav
Forum Guru
Forum Guru
Posts: 3134
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Incorrect firewall behavious

Sun Dec 09, 2018 10:58 pm

In terms of keeping it simple,
There should typically be one allow dstnat rules in the firewalls section of the rules.
add action=accept chain=forward comment=\
"Allow Port Forwarding-To a Server" connection-nat-state=dstnat

Then in IP NAT rules, put in the appropriate Destination Nat Rules (not in Firewall section).
No need for destination address in a DSTNAT Rule usually and if the to port is same as destination port then it can be left out at the end of the rule.

Thus this.......
I HAVE DISABLED THIS; AND THE 3389 STILL GOES THRU
add action=accept chain=forward comment="RDP accept and forward to 192.168.10.3" disabled=yes dst-address-list=192.168.10.3 dst-port=3389 in-interface=ether10-WAN protocol=tcp

Should be in the proper place!
/ip firewall nat
add action=dst-nat chain=dstnat comment=RDP forward dst-port=\
3389 in-interface=ether10-WAN log=yes protocol=tcp \
to-address=192.168.10.3

With a drop all else in the forward chain, the op should not have any further issues.
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
User avatar
mrmut
Member Candidate
Member Candidate
Topic Author
Posts: 142
Joined: Mon May 18, 2009 2:10 pm

Re: Incorrect firewall behavious

Mon Dec 10, 2018 2:20 pm

I needed some time to digest all answers, thanks all I appreciate it.

In essence, what 2frogs says in his first post seems OK.

However, from other comments it seems that I do bulk of things wrong, regardless if they work or not. I will try to rework the rules, and post back to see if I finally got it right.

I have to wait till evening for that, not to break something (have people on server).
 
User avatar
CZFan
Forum Guru
Forum Guru
Posts: 1444
Joined: Sun Oct 09, 2016 8:25 pm
Location: South Africa, Randburg
Contact:

Re: Incorrect firewall behavious

Mon Dec 10, 2018 3:16 pm

...
Of course people throw in drop invalid traffic and other things but if you have a drop everything else rule they will all be caught.
....
My personal opinion the above is debatable, the last I checked part of the reason for dropping invalid was due to reasons that the packet might not be NATed due to router being busy or whatever, and these will still be allowed by your forward accept rules coming from the LAN as example and might never reach the drop all rule
MTCNA, MTCTCE, MTCRE & MTCINE
 
anav
Forum Guru
Forum Guru
Posts: 3134
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Incorrect firewall behavious

Mon Dec 10, 2018 4:29 pm

Well CZFAN, I do have that one on my router as well, as it doesnt do any harm to leave it and if it catches a few things, I'm happy.
Its a very basic rule and doesnt muck up anything else.
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
User avatar
mrmut
Member Candidate
Member Candidate
Topic Author
Posts: 142
Joined: Mon May 18, 2009 2:10 pm

Re: Incorrect firewall behavious

Mon Dec 10, 2018 11:37 pm

OK, so I put some elbow grease in it, and reworked the rules.

The ipsec/l2tp rules are from: https://github.com/Onoro/Mikrotik/ (However I don't use the bruteforce scripting, only ruleset. I had issues witht he scripts, they are too rigid, especially when normal connections start triggering the bruteforce limit.)

I also have simple ruleset to block traffic between two separate bridges/networks.

The port forwarding rules are set under /ip firewall nat as suggested. I tried turning it off and on again, and it worked. ;-)


/ip firewall filter
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=input comment="L2TP allow only with IPsec" dst-port=1701 in-interface=ether10-WAN ipsec-policy=in,ipsec protocol=udp
add action=drop chain=input comment="Drop L2TP without IPsec" dst-port=1701 in-interface=ether10-WAN protocol=udp
add action=accept chain=input comment="L2TP allow" dst-port=500,4500 in-interface=ether10-WAN protocol=udp
add action=accept chain=input comment="IPSec enable" in-interface=ether10-WAN protocol=ipsec-esp

add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface=!bridge


add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked

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="PORT FORWARDING" connection-nat-state=dstnat

add action=reject comment="block bridge-2 - bridge-1" chain=forward in-interface=bridge-1 out-interface=bridge-2
add action=reject comment="block bridge-1 - bridge-2" chain=forward in-interface=bridge-2 out-interface=bridge-1
add action=reject comment="block wifi - lan" chain=forward in-interface=all-wireless out-interface-list=LAN
add action=reject comment="block lan - wifi" chain=forward in-interface-list=LAN out-interface=all-wireless

add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf:  drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface=ether10-WAN




/ip firewall nat
add action=masquerade chain=srcnat ipsec-policy=out,none out-interface=ether10-WAN
add action=dst-nat chain=dstnat comment="RDP forward to server" dst-port=3389 in-interface=ether10-WAN log=yes protocol=tcp to-address=192.168.10.3
add action=dst-nat chain=dstnat comment="RDP forward to workstation" dst-port=65001 in-interface=ether10-WAN log=yes protocol=tcp to-address=192.168.10.101



Any further suggestions appreciated.

I will also add some rules to block outgoing traffic from the server, except specific ports, to prevent anything bad going out (it is flimsy server) . viewtopic.php?f=2&t=142557&p=702380#p702380
/ip firewall filter
add action=accept chain=forward protocol=tcp dst-ports=80,443, ... ? src-address=ip
add action=reject chain=forward src-address=ip

Who is online

Users browsing this forum: Google [Bot] and 84 guests