Page 1 of 1

fw does not drop winbox mac-telnet

Posted: Tue Jun 30, 2020 12:44 pm
by francolini
Hi all,

I've been testing the firewall feature on the CRS328, and I stuggle to understand the following ruleset:
/ip firewall filter
add action=drop chain=input comment="Block mgmt on eth1" in-interface=ether1
add action=accept chain=input connection-state=established,related,untracked
add action=accept chain=input protocol=icmp
I would expect that the first line would block all incoming traffic on ether1 addressed to the router. ip-connections via Winbox and ping are blocked, but I'm still able to connect using winbox and mac-telnet.

If I enable logging, I can see that the telnet packages are listed by the rule. So the filter is capturing the packages, but still forwards them to the CPU?
The ether1 interface is not part of any bridge configuration

Note: I know there are many alternatives to block mac-telnet, but I'm trying to understand why the above rules don't work, and possible consequences for other protocols.

Re: fw does not drop winbox mac-telnet

Posted: Tue Jun 30, 2020 3:37 pm
by anav
What are you trying to accomplish that is not already done properly in the default ruleset?
Why did you add that extra rule?

Re: fw does not drop winbox mac-telnet  [SOLVED]

Posted: Tue Jun 30, 2020 3:44 pm
by mrz
See packet flow diagram
https://wiki.mikrotik.com/wiki/Manual:Packet_Flow

mac telnet is not layer3 connection, so from in-interface it goes directly to local-in

Re: fw does not drop winbox mac-telnet

Posted: Tue Jun 30, 2020 3:46 pm
by xvo
I would expect that the first line would block all incoming traffic on ether1 addressed to the router. ip-connections via Winbox and ping are blocked, but I'm still able to connect using winbox and mac-telnet.
All incoming ip traffic.
Limit the list of ports, through which mac-winbox and/or mac-telnet connections can happen.

Re: fw does not drop winbox mac-telnet

Posted: Tue Jun 30, 2020 4:04 pm
by francolini
mac telnet is not layer3 connection, so from in-interface it goes directly to local-in
Awesome, thanks for the explaination!

What are you trying to accomplish that is not already done properly in the default ruleset?
Why did you add that extra rule?
Read the first post, last section... Also, the CRS328 did not come with a default ruleset

Re: fw does not drop winbox mac-telnet

Posted: Tue Jun 30, 2020 8:51 pm
by k6ccc
OK, I have never given that any thought because I have never used MAC WinBox. How do you block MAC WinBox - either completely or selectively? Since it's not IP, the IP firewall and ports rules do not apply.

Re: fw does not drop winbox mac-telnet

Posted: Tue Jun 30, 2020 9:10 pm
by anav
OK, I have never given that any thought because I have never used MAC WinBox. How do you block MAC WinBox - either completely or selectively? Since it's not IP, the IP firewall and ports rules do not apply.
I know enough to be dangerous and then some!!!
Go to Tools and to Mac Server and yee shall be enlightened!!

Security for Router The Rule of 4! (from MTUNA manual)
1 - firewall input rules - allow admin only on wan side and block wan
2 - users - change name from admin and strong password
3 - Winbox Settings under iP services
4. -WinMAC settings under Tools.

Re: fw does not drop winbox mac-telnet

Posted: Wed Jul 01, 2020 2:41 am
by k6ccc
Thanks.
I wonder if I had discovered and forgotten about that sometime in the past. When I looked at my router 2, both mac-winbox and mactel interface lists had all interfaces, but when I looked at my newer router 1, only the local LAN was listed for both.

Re: fw does not drop winbox mac-telnet

Posted: Tue Jul 07, 2020 2:30 pm
by francolini
OK, I have never given that any thought because I have never used MAC WinBox. How do you block MAC WinBox - either completely or selectively? Since it's not IP, the IP firewall and ports rules do not apply.
Depending on what connectivity you have on your WAN side, it might not matter much security wise. Neverless, there is seldom a reason to leave any service running on a network where it's not needed.

I guess that CDP, and other l2 protocols falls in the same category. While limited exploitation potential, there is little reason to have those services running on interfaces where they are not needed.