Firewall filter rule ignored?

RouterOS General
1

Hi there

I have someone trying to bruteforce my ssh port from the same IP, there’s a few minutes between each attempt, so they never make it to the ssh blacklist. I decided to just make a rule to drop any connection from their IP:

add action=drop chain=input src-address=<offending-ip>

But when I ssh into the router, I still see this:

nov/18/2021 13:58:18 system,error,critical login failure for user adm1n_MKT from <offending-ip> via ssh
nov/18/2021 14:14:04 system,error,critical login failure for user admin from <offending-ip> via ssh
nov/18/2021 14:29:49 system,error,critical login failure for user adm1n_MKT from <offending-ip> via ssh
nov/18/2021 14:45:39 system,error,critical login failure for user admin from <offending-ip> via ssh
nov/18/2021 15:01:27 system,error,critical login failure for user adm1n_MKT from <offending-ip> via ssh

I moved the rule i added to a position in the filter higher than the ssh specific rules. What did i misunderstand here?

2

Why are you allowing folks to SSH into your router from the internet??.
USE VPN to access the router.

OR
Are these all internal lan users attempting to do so??

THe only SSH I allow is for the admin to have backup access to the router in case winbox doesnt work.
That is only from a very limited LANIP ip pool in a firewall address list.

3

Can you post the complete output of
/ip firewall filter export
and obfuscate any public addresses you eventually don’t want to reveal?

Normally, your rule should indeed prevent the attacker’s packets from reaching the ssh service.

Also, what is your RouterOS version?

4 



add action=accept chain=input dst-port=<ssh-port> protocol=tcp
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="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
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=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="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
add action=drop chain=input src-address=<offending-ip>
add action=drop chain=input comment="drop ssh brute forcers" dst-port=<ssh-port> protocol=tcp src-address-list=ssh_blacklist
add action=add-src-to-address-list address-list=ssh_blacklist address-list-timeout=1w3d chain=input connection-state=new dst-port=<ssh-port> protocol=tcp src-address-list=ssh_stage3
add action=add-src-to-address-list address-list=ssh_stage3 address-list-timeout=1m chain=input connection-state=new dst-port=<ssh-port> protocol=tcp src-address-list=ssh_stage2
add action=add-src-to-address-list address-list=ssh_stage2 address-list-timeout=1m chain=input connection-state=new dst-port=<ssh-port> protocol=tcp src-address-list=ssh_stage1
add action=add-src-to-address-list address-list=ssh_stage1 address-list-timeout=1m chain=input connection-state=new dst-port=<ssh-port> protocol=tcp



RouterOS 6.48.3

5

Pardon me, but the very first rule in chain input says:

action=accept chain=input dst-port= protocol=tcp

So why are you surprised that it shadows the action=drop chain=input src-address= one far later in the list?

6

Basically, I would not put any rules above the default rules myself.
But why is your permit SSH rule WIDE FRIGGEN OPEN.
Did you mean SSH to be open to the internet and the LAN

If its for the internet, suggesting use VPN for access instead.
If its for LAN users or the admin

then
add chain=input action=accept in-interface-list=LAN dst-port=xxxx protocol=tcp src-address-list=authorizedaccess

Where authorized access is a list of IPs allowed to use SSH (statically set by DHCP leases).

As to the question, as Sindy aptly noted, the router processes the rules in order.
Thus since EVERY SSH query to the router (either wan or lan) is accepted, the packet will NOT be subjected to any further firewall rules and will just flow.
Therefore the second shadow rule is never used.

I would suggest that your limited understanding of basic firewall rules suggest there is no way in heck you should be contemplating opening up SSH to the world.

7

Also a suggestion. This makes no difference to the router, but it makes easier for us humans to read. Move firewalls rules around so that each chain is together. In other words, all the input rules, then all the forward rules, then whatever other chains you may have. Much easier than having to go through the whole list to find that one more rule in the chain.

8

I was always under the impression that it did make a difference to the router what order the packets were in in terms of if the majority of packets were to have to go through the forward chain, and you had the forward chain last, more cpu cycles would have to be used to go through the input and output chain rules before a packet even hit the forward chain rules. The fewer rules a packet has to be evaluated against, the faster it can transit the router, and the fewer cpu cycles are required to process it.

For a router handling mostly forward traffic, having the RELATED,ESTABLISHED rule for the forward chain as the first rule evaluated makes a significant difference than if it is one of the last, with a whole bunch of input chain rules ahead of it.

If I’m wrong, I’m open to being educated, but I’ve always had the forward chain first, then input, then output on my routers because I understood this to be true.

(I do agree with keeping all rules for each chain together though)

9

How I understood:
Rules are evaluated top to bottom (disregarding jumps for sake of clarity).
So it’s indeed logical to put the most heavy used ones on top.
For personal clarity you can keep the related ones together.
Some reordering might be needed though if your device gets to its limits.

Raw rules are even better then regular rules. MUCH faster if you can drop some stuff there already (which then logically would make sense in Winbox to have that tab to the left of the normal rules but that’s another discussion, I guess).

10

Forwarding chain traffic doesn’t go through input or output rules, and similar for other traffic. That is just pointless. Think of it as 3 separate lists, even though the export jumbles stuff up together.

The fewer rules a packet has to be evaluated against, the faster it can transit the router, and the fewer cpu cycles are required to process it.

That’s true, within a chain.

For a router handling mostly forward traffic, having the RELATED,ESTABLISHED rule for the forward chain as the first rule evaluated makes a significant difference than if it is one of the last, with a whole bunch of input chain rules ahead of it.

If I’m wrong, I’m open to being educated

I’m afraid you are.

11

Cool, every day is a school day, learned something new today.
Thanks very much!

12

As stated separate lists, order is important WITHIN a list.
Input chain, to and fro the router (wan to router, lan to router)
Forward chain, through the router (wan to lan, lan to wan, lan to lan)

13

It is easy to confuse as the syntax item=value is the same for all the parameters of a rule, but there are actually 4 distinct categories of them:

  • the match conditions (such as dst-address, protocol, …)
  • the action to take
  • the parameters of an action (such as jump-target, to-ports, to-addresses)
  • the chain to which the rule belongs, which is not a match condition as gents above have explained
14

Remember that you can create any chain that you want and jump to them. So if you have a group of rules that won’t really get much traffic, you can put those into a separate chain and put just one rule in the input or forward chain (as appropriate) that jumps to the added chain. For example, I have some rather convoluted port knocking so in my Input chain is this rule (no, those are not the actual ports involved):

add action=jump chain=input comment=\
    "Long Port Knock traffic jumps to L-Knock chain" dst-port=\
    12345,23456,34567,45678,56789 in-interface-list=WAN jump-target=L-Knock \
    protocol=tcp

Now the eight rules in the L-Knock chain do not need to be processed every time any packet goes through the input chain.