empty connection-state value in filter rule?
In a filter list, I have several rules that have connection-state="" in them. For example: chain=ssh action=accept connection-state="" \ protocol=tcp dst-port=22 \ log-prefix="" What do people think would be the behaviour? Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160 GPG fingerprint: CF68 0C56 EEE4 CC19 28D4 03B3 BCE0 E800 E31F 7254 Old fingerprint: 887A DA07 4DCC EE76 B413 27D4 C638 4189 6CF0 D556
Hi Karl, My expectation is that the rules will match no traffic at all, because 'connection state' is never blank, unless (perhaps) if connection tracking is disabled - I would need to run some experiments to determine what is the actual case with connection tracking disabled :-} BUT, if that is not the actual result, I will be hardly surprised since it is not uncommon for 'unexpected' functionality like that to change behaviour from version to version ;) What *is* the result you observed, and what would you expect to see? Cheers! Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Karl Auer Sent: Thursday, 7 May 2020 2:50 PM To: MikroTik Public <public@talk.mikrotik.com.au> Subject: [MT-AU Public] empty connection-state value in filter rule?
In a filter list, I have several rules that have
connection-state=""
in them.
For example:
chain=ssh action=accept connection-state="" \ protocol=tcp dst-port=22 \ log-prefix=""
What do people think would be the behaviour?
Regards, K.
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160
GPG fingerprint: CF68 0C56 EEE4 CC19 28D4 03B3 BCE0 E800 E31F 7254 Old fingerprint: 887A DA07 4DCC EE76 B413 27D4 C638 4189 6CF0 D556
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
On Thu, 2020-05-07 at 21:33 +1000, Mike Everest wrote:
My expectation is that the rules will match no traffic at all, because 'connection state' is never blank, unless (perhaps) if connection tracking is disabled - I would need to run some experiments to determine what is the actual case with connection tracking disabled :-} [...] What *is* the result you observed, and what would you expect to see?
These are quite old rules, and RouterOS has been upgraded a couple of times on top of them. I certainly did not create the rules like that. The full set is below and will be immediately recognisable as an ssh repeat offender blacklist. I would have expected to see no blacklisting happening, because no rules would match and the chain would return having had no effect - other than to block addresses that were already in the blacklist. Which would be none after a few weeks as they all timed out). What surprises me greatly is that addresses are being blacklisted exactly as if the rules actually contained 'connection-state="new"'! Here are some samples, the oldest and the newest: 0 D ssh_blacklist 89.189.222.150 1w2d12h46m56s 1 D ssh_blacklist 45.6.240.150 1w4d14h19m12s [...] 1644 D ssh_stage1 79.116.60.233 49s 1645 D ssh_stage1 222.186.30.112 57s Offenders march neatly from stage to stage until they end up on the blacklist. There are no other rules anywhere in the overall ruleset that puts addresses into those lists, so it has to be the rules below that are doing it. What is even more weird is that I have a similar set of rules that test for "established,related" and those rules seem to be working as well, even though they too display as '"connection-state=""'. All these rules look the same when exported, too. I know I shouldn't touch a working system and it's been up for 66 weeks, so a shame to reboot, but I want to upgrade RouterOS (currently it's 6.36 stable), and I plan to put "new" in those rules at the same time. Regards, K. 0 chain=ssh action=drop protocol=tcp src-address-list=ssh_blacklist dst-port=22 log-prefix="" 1 chain=ssh action=add-src-to-address-list connection-state="" protocol=tcp src-address-list=ssh_stage3 address-list=ssh_blacklist address-list-timeout=8w4d dst-port=22 log-prefix="" 2 chain=ssh action=add-src-to-address-list connection-state="" protocol=tcp src-address-list=ssh_stage2 address-list=ssh_stage3 address-list-timeout=1m dst-port=22 log- prefix="" 3 chain=ssh action=add-src-to-address-list connection-state="" protocol=tcp src-address-list=ssh_stage1 address-list=ssh_stage2 address-list-timeout=1m dst-port=22 log- prefix="" 4 chain=ssh action=add-src-to-address-list connection-state="" protocol=tcp address-list=ssh_stage1 address-list-timeout=1> dst-port=22 log-prefix="" 5 chain=ssh action=drop protocol=tcp src-address-list=ssh_blacklist dst-port=22 log-prefix="" 6 chain=ssh action=accept connection-state="" protocol=tcp dst- port=22 log-prefix="" 7 chain=ssh action=return log-prefix="" -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160 GPG fingerprint: CF68 0C56 EEE4 CC19 28D4 03B3 BCE0 E800 E31F 7254 Old fingerprint: 887A DA07 4DCC EE76 B413 27D4 C638 4189 6CF0 D556
Hi Karl, A quick test proves that connection-state="" is the same as connection-state=invalid,established,related,new,untracked So in this case (at least with current longterm version) I presume that the internal implementation of connection-state matching is probably a logical AND against the selected attributes and so "" is same as nothing and therefore matches all packets as if the rule is not even set. {does that statement even make sense? :-} If so, then the resulting behaviour would match your observations, since the rules will match all packets, including 'new' - and your other rules that explicitly relate to 'established' work to maintain valid connections (because it only takes one 'new' input packet to create an established connection) The only downside is that those rules end up matching all packets instead of only 'new' and so you get a bit of cpu overhead.. I would expect it safe just to update those rules - no restart needed anyhow! Cheers, Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Karl Auer Sent: Thursday, 7 May 2020 10:05 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] empty connection-state value in filter rule?
On Thu, 2020-05-07 at 21:33 +1000, Mike Everest wrote:
My expectation is that the rules will match no traffic at all, because 'connection state' is never blank, unless (perhaps) if connection tracking is disabled - I would need to run some experiments to determine what is the actual case with connection tracking disabled :-} [...] What *is* the result you observed, and what would you expect to see?
These are quite old rules, and RouterOS has been upgraded a couple of times on top of them. I certainly did not create the rules like that. The full set is below and will be immediately recognisable as an ssh repeat offender blacklist.
I would have expected to see no blacklisting happening, because no rules would match and the chain would return having had no effect - other than to block addresses that were already in the blacklist. Which would be none after a few weeks as they all timed out).
What surprises me greatly is that addresses are being blacklisted exactly as if the rules actually contained 'connection-state="new"'!
Here are some samples, the oldest and the newest: 0 D ssh_blacklist 89.189.222.150 1w2d12h46m56s 1 D ssh_blacklist 45.6.240.150 1w4d14h19m12s [...] 1644 D ssh_stage1 79.116.60.233 49s 1645 D ssh_stage1 222.186.30.112 57s
Offenders march neatly from stage to stage until they end up on the blacklist. There are no other rules anywhere in the overall ruleset that puts addresses into those lists, so it has to be the rules below that are doing it.
What is even more weird is that I have a similar set of rules that test for "established,related" and those rules seem to be working as well, even though they too display as '"connection-state=""'. All these rules look the same when exported, too.
I know I shouldn't touch a working system and it's been up for 66 weeks, so a shame to reboot, but I want to upgrade RouterOS (currently it's 6.36 stable), and I plan to put "new" in those rules at the same time.
Regards, K.
0 chain=ssh action=drop protocol=tcp src-address-list=ssh_blacklist dst-port=22 log-prefix=""
1 chain=ssh action=add-src-to-address-list connection-state="" protocol=tcp src-address-list=ssh_stage3 address-list=ssh_blacklist address-list-timeout=8w4d dst-port=22 log- prefix=""
2 chain=ssh action=add-src-to-address-list connection-state="" protocol=tcp src-address-list=ssh_stage2 address-list=ssh_stage3 address-list-timeout=1m dst-port=22 log- prefix=""
3 chain=ssh action=add-src-to-address-list connection-state="" protocol=tcp src-address-list=ssh_stage1 address-list=ssh_stage2 address-list-timeout=1m dst-port=22 log- prefix=""
4 chain=ssh action=add-src-to-address-list connection-state="" protocol=tcp address-list=ssh_stage1 address-list-timeout=1> dst-port=22 log-prefix=""
5 chain=ssh action=drop protocol=tcp src-address-list=ssh_blacklist dst-port=22 log-prefix=""
6 chain=ssh action=accept connection-state="" protocol=tcp dst- port=22 log-prefix=""
7 chain=ssh action=return log-prefix=""
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160
GPG fingerprint: CF68 0C56 EEE4 CC19 28D4 03B3 BCE0 E800 E31F 7254 Old fingerprint: 887A DA07 4DCC EE76 B413 27D4 C638 4189 6CF0 D556
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
On Fri, 2020-05-08 at 10:52 +1000, Mike Everest wrote:
A quick test proves that connection-state="" is the same as connection-state=invalid,established,related,new,untracked [...] If so, then the resulting behaviour would match your observations, since the rules will match all packets, including 'new' - and your other rules that explicitly relate to 'established' work to maintain valid connections (because it only takes one 'new' input packet to create an established connection)
I will have to think on that ... if that's the case, why don't all SSH connections end up blocked after four packets? Ah - because my "established" rule is processed before my blacklist rules! OK, makes sense. Thanks! But I think I will still fix up those rules. With a deal more confidence :-) Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160 GPG fingerprint: CF68 0C56 EEE4 CC19 28D4 03B3 BCE0 E800 E31F 7254 Old fingerprint: 887A DA07 4DCC EE76 B413 27D4 C638 4189 6CF0 D556
Yes! That's my guess too ;) Definitely worth fixing the rules - will deliver some cpu relief at the very least ;) Cheers! Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Karl Auer Sent: Friday, 8 May 2020 12:10 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] empty connection-state value in filter rule?
On Fri, 2020-05-08 at 10:52 +1000, Mike Everest wrote:
A quick test proves that connection-state="" is the same as connection-state=invalid,established,related,new,untracked [...] If so, then the resulting behaviour would match your observations, since the rules will match all packets, including 'new' - and your other rules that explicitly relate to 'established' work to maintain valid connections (because it only takes one 'new' input packet to create an established connection)
I will have to think on that ... if that's the case, why don't all SSH connections end up blocked after four packets? Ah - because my "established" rule is processed before my blacklist rules! OK, makes sense.
Thanks! But I think I will still fix up those rules. With a deal more confidence :-)
Regards, K.
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160
GPG fingerprint: CF68 0C56 EEE4 CC19 28D4 03B3 BCE0 E800 E31F 7254 Old fingerprint: 887A DA07 4DCC EE76 B413 27D4 C638 4189 6CF0 D556
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
participants (2)
-
Karl Auer -
Mike Everest