Port knocking is well established. There are lots of examples in the forums and Wikis.
"IF this, THEN IF ALSO that, THEN ALLOW ...".

But. If we want the knocks to be able to be simple (TCP SYN, so it could be triggered by a web browser), then we run a modest risk of a bad guy's high-intensity port scan triggering our Knock, to wit:
Bad guy fast TCP port scans us, luckily in the same sequence as our Port Knock (i.e. we require ports 7000 and then 6000 in that order, and bad guy happens to scan in descending order, or happens to scan TWICE in ascending order). That could successfully "knock".

So I'd like to add an intermediate anti-accidental-knock filter rule.
It might look something like this:

;;; default configuration: allow already established connections to continue
chain=input action=accept connection-state=established,related log=no log-prefix=""

;;; port knocking step 1 - knock TCP on port 7000
chain=input action=add-src-to-address-list protocol=tcp address-list=KnockKnock:7000 address-list-timeout=1m dst-port=7000 log=no

;;; port knocking step 2 - knock TCP on port 6000 - get added to KnockedSuccessfully list
chain=input action=add-src-to-address-list protocol=tcp src-address-list=KnockKnock:7000 address-list=KnockedSuccessfully address-list-timeout=1m dst-port=6000 log=yes

;;; port knocking intermediate block - if ON the KnockKnock:7000 list and NOT already on the KnockedSuccessfully list and touch any OTHER port then temporarily blacklist
chain=input action=add-src-to-address-list protocol=tcp src-address-list=KnockKnock:7000,!KnockedSuccessfully address-list=BadKnocks address-list-timeout=1m dst-port=!7000,6000 log=yes

;;; and finally the necessary allow-if-knocked-successfully rule
chain=input action=accept src-address-list=KnockedSuccessfully,!BadKnocks log=yes

This does not seem to be working, I suspect because what I'm trying to do with the compound matches isn't the right syntax: What I want these lines to do is to match packets from IP addresses which ARE on the src-address-list KnockKnock:7000 AND are NOT on the src-address-list KnockedSuccessfully in the first example, and to match packets from IP addresses which ARE on the src-address-list KnockedSuccessfully AND are NOT on the src-address-list BadKnocks in the second case;
and to match any dst-port which is NEITHER 7000 nor 6000 in the third case.

The MikroTik (RB951Ui-2HnD, RouterOS and firmware 6.43.14) accepts the /ip firewall filter ... command entries, but apparently they don't mean what I want them to.

What I see is IP addresses being added to the KnockKnock:7000 address-list, but neither do properly knocked connection requests get through, nor does anything ever end up on either the BadKnocks or KnockedSuccessfully address-lists.
(If I take out the whole idea of BadKnocks, then a typical knock configuration, TCP:7000 followed by TCP:6000, works just fine on my MikroTik router).

So, what's the right syntax to specify "on this src-address-list but not on this other src-address-list" and "not either of these two dst-ports"?

thanks,
Jay

There's only src-address-list=<list name>, it doesn't allow to do any operations with different lists. You'd have to make the thing with more rules, e.g.: It's not exactly pretty and it does some strange things, like the final correct knock will also put the address on knockerror list and so will allowed connection to port 22 (used in this example as protected service).

Thanks very much for this Sob,
I'm guessing that the third knock port (5000) is added just for purposes of demonstration, not that it's required in order to make the two-step knock order 7000,6000 function; right?

I see what you mean about it being a bit ugly, since a rule meant to detect "port this but not port that" (after the first rule) cannot distinguish between good (if after the earlier knock sequence) and bad (otherwise), but nonetheless can be used to ultimately allow what we want (at the cost of more complicated log entries and more, larger, not-entirely-black lists).

I think we need to ask MikroTik as a Feature Request to add a powerful Knocking language, or to enable /ip firewall filter rules to include compound on-these-lists_and_not-on-these-other-lists syntax.

regards,
Jay

I would think to do it different. If they are doing a huge port scan, then maybe a rule where

if dst-port = 5999,6001,6999,7001 then add to list portscanner
then on your portknocking do src-address-list!=portscanner

This should cover scanners going up and down the list, and covers you for hitting 7000 and 6000. It would be very rare for a false positive to hit inbetween that perfectly.

Hi joegoldman, Interesting idea!
I'm play devil's advocate and trying to think whether this could have unintended consequences (accidentally block legitimate traffic).
Since the only incoming connections should be either VPN or knocked, any legitimate occurrence of all-ports-except-a-very-small-number should always be preceded by a successful knock and be in an 'established' state, which would be permitted by a rule earlier in the execution order of the filter rules.
So, I think it looks good.
Anyone see anything we're missing in this?
thanks!
-Jay

I would think to do it different. If they are doing a huge port scan, then maybe a rule where

if dst-port = 5999,6001,6999,7001 then add to list portscanner
then on your portknocking do src-address-list!=portscanner

This should cover scanners going up and down the list, and covers you for hitting 7000 and 6000. It would be very rare for a false positive to hit inbetween that perfectly.

Yes, third port is to make the example more interesting, and to hint on some problems that would come if you wanted even more.

And about your feature request, I think it's wrong approach. Whole traditional port knocking is genius idea, but yet at the same time, it's rather dumb protection against dumb robots.

As long as it's static, there's not much difference between packet to one port, your packets to two ports, or some crazy twenty packets long sequence with mixed tcp, udp, icmp, etc. It will stop dumb robots, but that's it. It's like hiding your door key. You can simply put it under the rock. Or you can come up with crazy scheme where under the rock will be a hook used to fish another key from pond, it will unlock a fridge with sausage, which will be used to lure the dog away and the real door key will be in dogs house. It's no doubt safer than just door key under the rock, but once someone sees you do it, they can repeat it themeselves.

If MikroTik should add some support for port knocking, it should be some variant of Single Packet Authorization, which actually adds another layer of security, because packets are signed, not replayable, etc.

Until then, simple port knocking is probably good enough. Even your original problem, just use short timeouts and it will almost go away. If you simply need to connect to SSH, WinBox or VPN, you don't need to open ports for too long, few seconds is enough for every step (first knock, second knock and finally the connection to service). Accidentally getting access this way is highly unlikely.

You raise a really good point. It depends on who/ what kind of attacks we're protecting against.
My initial request would be for something that would stop a common port scan from detecting that there is e.g. an SSH or HTTPS port open on the MikroTik.
And it would indeed do that. It would make the port scan return a false-negative, which is exactly what we want port scanners to see about us - "nothing to see here, move along".

Now, why would we go to effort to do that?

Port scanning like this is done to find potential targets. The port scanning is automated, and the follow-up testing of the potential targets is generally automated, too.
Mostly, these are script kiddies, or low-hanging-fruit organized crime. They're looking for easy targets, and they're easily deterred.

However, some few port scanners would flag the sequence:
1. "Port 22 found" (accidentally, we know, because their port scan triggered our knock), followed by
2. " .. but the follow-up testing of the found Port 22 looked different" (that is, our port scan got an SSH banner, but the follow up some minutes/ hours later got a closed port there).
Having flagged it we may have just made ourselves _more_ interesting to these call-them-intermediate level attackers.

It's definitely a small segment that we're defending against, but it might be an important segment - those smart enough to notice when we'd prefer to have gone completely unnoticed.

What we're NOT trying to defend against here are what I think you refer to when you remarked "but once someone sees you do it, they can repeat it themselves".
You're right, but only for a very, very small segment of attackers - those who are already targeting you and have significant resources which they're willing to spend against you. Nation states, and organized crime targeting already known/suspected high value targets.

It's one thing to do a general port scan and even to do automated follow-up on the potential targets that the scan found.
It's entirely another to target a site (probably having to compromise other systems to get into a place to do the monitoring) and monitor communications to be able to notice potential knock patterns in order to be able to repeat them. Those, our knocks aren't going to help against (nor much else that we can do; that's a whole higher level security problem).

And, you're also correct in saying that Single Packet Authorization is a more complete security solution. It also is a harder to implement solution. Knocking is fairly easy, and I'm looking for fairly easy ways to improve the security value of knocking.

So, although my feature request is only for a feature that would be beneficial against a small but I think important (non-targeted at first, but willing-to-become-interested, more than script-kiddie attackers, but not nation states who are already targeting) segment, I do suspect that that segment does exist, and assuming that it wouldn't be difficult or expensive for MikroTik to include it, I still think it would be a nice belt-and-suspenders feature for the normal security-conscious user to have in their defensive arsenal.

many thanks to all,
-Jay

Yes, third port is to make the example more interesting, and to hint on some problems that would come if you wanted even more.

And about your feature request, I think it's wrong approach. Whole traditional port knocking is genius idea, but yet at the same time, it's rather dumb protection against dumb robots.

As long as it's static, there's not much difference between packet to one port, your packets to two ports, or some crazy twenty packets long sequence with mixed tcp, udp, icmp, etc. It will stop dumb robots, but that's it. It's like hiding your door key. You can simply put it under the rock. Or you can come up with crazy scheme where under the rock will be a hook used to fish another key from pond, it will unlock a fridge with sausage, which will be used to lure the dog away and the real door key will be in dogs house. It's no doubt safer than just door key under the rock, but once someone sees you do it, they can repeat it themselves.

If MikroTik should add some support for port knocking, it should be some variant of Single Packet Authorization, which actually adds another layer of security, because packets are signed, not replayable, etc.

Until then, simple port knocking is probably good enough. Even your original problem, just use short timeouts and it will almost go away. If you simply need to connect to SSH, WinBox or VPN, you don't need to open ports for too long, few seconds is enough for every step (first knock, second knock and finally the connection to service). Accidentally getting access this way is highly unlikely.

It's also possible that we're overthinking it. For basic level protection against bots, even changing service port helps a lot. Move e.g. ssh from port 22 to 23726 and you'll get only small fraction of hits. It's not real solution, but it shows that they go for easy targets and don't bother with anything complicated. I have simple port knocking with three ports and not even with filtering of wrong ones (like in this thread). There are few hits for first one and that's it.

Why not just a set of firewall rules to catch port scanners. Those are well documented and work well. If the port scanner triggers, then the port knock never sees the triggers.

I du use a flowing combination.
1. Any who tries to use a non open port will be blocked for 24 hours.
2. Service that needs to be open, if you start 5 session within 5 min you get blocked.
3. Port knocking if needed.

Its very strict, and yes I have blocked my self out. But since I have whitlisted my work, I can connect to it, then go back to my MT and removed my blocked IP.

This gives an average of 1500 blocked IP in my logs at any time.

Thanks k6ccc and Jotne, also very good points.
First blocking scans, before even checking for knocks (with maybe a too-talky limit on allowed services) does seem more complete and simpler to implement than my more complex knock idea.
cheers,
Jay

It's also possible that we're overthinking it. For basic level protection against bots, even changing service port helps a lot. Move e.g. ssh from port 22 to 23726 and you'll get only small fraction of hits. It's not real solution, but it shows that they go for easy targets and don't bother with anything complicated. I have simple port knocking with three ports and not even with filtering of wrong ones (like in this thread). There are few hits for first one and that's it.

@Sob I'm literally sobbing, its so sad that you still are using port knocking. Has not friend Sindy showed you how to setup a VPN yet?
I must come to your rescue!! I have a full proof IKEv2 setup that works for my iphone and the MT app. I only charge $400 an hour!

I must come to your rescue!! I have a full proof IKEv2 setup that works for my iphone and the MT app. I only charge $400 an hour!

As long as travel expenses are on you, you're welcome to come here and set me a VPN in 6 minutes (it's fool proof, n'est ce pas?)

Sometimes I can't help myself not to think that @Sob's observation

It's also possible that we're overthinking it.

applies to you perfectly.

Not so fast dear @anav! You have that nice & secure IKEv2 VPN with certificate, right? What will you do when you happen to be somewhere out and you won't have it with you? All I need is any computer where I will use regular web browser to tickle my three tcp ports and I will be able to connect to whatever service I have protected with this. In fact, even VPN can be this protected service. Because if it's something that I need only from time to time, it doesn't have to be always accessible to whole world, for any robots to play with.

Not so fast dear @anav! You have that nice & secure IKEv2 VPN with certificate, right? What will you do when you happen to be somewhere out and you won't have it with you? All I need is any computer where I will use regular web browser to tickle my three tcp ports and I will be able to connect to whatever service I have protected with this. In fact, even VPN can be this protected service. Because if it's something that I need only from time to time, it doesn't have to be always accessible to whole world, for any robots to play with.

Last time I checked my phone is a computer LOL. But how do you see your monitor when its strapped on your back. I get it that you have a special belt so that you can have your keyboard and mousepad sticking out in front of you while walking......... Just not sure what orifice the MOBO is in? ;-0

I must come to your rescue!! I have a full proof IKEv2 setup that works for my iphone and the MT app. I only charge $400 an hour!

As long as travel expenses are on you, you're welcome to come here and set me a VPN in 6 minutes (it's fool proof, n'est ce pas?)

Sometimes I can't help myself not to think that @Sob's observation

It's also possible that we're overthinking it.

applies to you perfectly.

MKX where that may be?? I don't recall but perhaps i can visit as long as I am not supporting T dollars.

MKX where that may be??

I was thinking hard how to explain it to a Bluenose ... but then it came to me: maybe, just maybe, this particular Canadian follows some team sport of North America (I'd hardly expect the same from some random Hering-choker) ... so you might have heard about one of these two guys: Anže Kopitar (he's reportedly known amongst NHL followers) or Luka Dončić (did stir some interest before NBA All star game). Do these names ring the bell? Guess what, they both come from my country.

@anav: What if someone steals your phone? You don't have the whole certificate in your head (which of course is easily solvable by using another type of VPN that needs only username and password and you can remember that). But let's wrap this, we went wrong way, it starts to look like VPN against port knocking battle, which is nonsense. Those are two completely different things.