Filter drop not blocking established connections?

RouterOS General
1

Given the filter:

/ip firewall filter
add action=drop chain=forward comment="Drop traffic" disabled=no src-address-list=blackholed

Should I expect established TCP connections routing through this device to have their packets dropped by the router when the IP of the remote host is added to the address list after the connection is established? Does the router check TCP connections against the filter only when the initial connection is established or for every packet of the connection that flows through the router?

I ask because I’m seeing entries in mail logs showing that brute forcing remote peers are continuing to be able to get authentication requests through to a mail host for a few minutes after the remote host is blackholed in an intermediate router. However, all the remote sessions are from a handful of ports, suggesting that the remote host is running multiple authentication attempts through a single established socket.

The address is definitely getting added to the appropriate address list, as I can verify that after the fact, and while the IP is being added multiple times my script is simply finding the IP listed and updating the comment on the appropriate address-list ID entry as opposed to adding the IP and comment from scratch.

If this is indeed intended behavior, what would I need to do to have the filter rule drop traffic established sessions that start matching against the rule after they were established? What kind of performance hits & tradeoffs would I be looking at for that behavior versus simply checking a connection’s legitimacy at the time of establishment?

2

the drop rule should be above your established/related accept rules. every packet flows thru the firewall filter chains, its just not in the right order if its not dropping it.

3

There are no accept rules whatsoever. The device in question has only two filters, though connection tracking is enabled:

/ip firewall filter
add action=drop chain=forward comment="Drop foo" disabled=no dst-address-list=foo dst-port=1027 
add action=drop chain=forward comment="Blackhole" disabled=no src-address-list=blackhole
/ip firewall connection tracking
set enabled=yes generic-timeout=10m icmp-timeout=10s tcp-close-timeout=10s tcp-close-wait-timeout=10s tcp-established-timeout=1d tcp-fin-wait-timeout=10s \
    tcp-last-ack-timeout=10s tcp-syn-received-timeout=5s tcp-syn-sent-timeout=5s tcp-syncookie=no tcp-time-wait-timeout=10s udp-stream-timeout=3m \
    udp-timeout=10s

The only other stuff in /ip firewall export is the default service-port settings and the configured address lists.

4

Bump – does anyone have some ideas as to why the traffic is not being blocked? Should I be disabling conntracking entirely in order to block the traffic when address list entries are added after the fact?

5

your rules are not matching for some reason. post an example of traffic that is getting thru. also, your not on a bridge interface are you? the firewall is enabled no matter what, and the default action is accept, and every packet flows thru it.

6

They have to be matching; as they stop traffic for other addresses in the address list and stop traffic eventually (This is a brute forcing block) from the addresses reusing a socket. Once the rule is in place, no new socket connections show up in the logs, so the router is dropping the traffic.

And no, it’s not a bridge interface. The router in question is only using three ethernet interfaces.

7

I haven’t been able to duplicate the behavior in the lab; so yeah, it kills established connections just fine.