Community discussions

 
libove
newbie
Topic Author
Posts: 42
Joined: Tue Aug 14, 2012 5:18 pm

Port Knocking, avoid scan-caused false positives?

Fri Apr 12, 2019 1:46 pm

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:
src-address-list=KnockKnock:7000,!KnockedSuccessfully
src-address-list=KnockedSuccessfully,!BadKnocks
dst-port=!7000,6000
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
 
Sob
Forum Guru
Forum Guru
Posts: 4635
Joined: Mon Apr 20, 2009 9:11 pm

Re: Port Knocking, avoid scan-caused false positives?

Mon Apr 22, 2019 5:47 am

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.:
/ip firewall mangle
add action=accept chain=prerouting log=yes log-prefix="knock blacklist" src-address-list=knockerror
add action=add-src-to-address-list address-list=knockerror address-list-timeout=2m chain=prerouting dst-port=!5000 \
    log=yes log-prefix="knock3 error" protocol=tcp src-address-list=knock2
add action=add-src-to-address-list address-list=knocked address-list-timeout=1m chain=prerouting dst-port=5000 log=\
    yes log-prefix="knock3 ok" protocol=tcp src-address-list=knock2
add action=add-src-to-address-list address-list=knockerror address-list-timeout=2m chain=prerouting dst-port=!6000 \
    log=yes log-prefix="knock2 error" protocol=tcp src-address-list=knock1
add action=add-src-to-address-list address-list=knock2 address-list-timeout=1m chain=prerouting dst-port=6000 log=yes \
    log-prefix="knock2 ok" protocol=tcp src-address-list=knock1
add action=add-src-to-address-list address-list=knock1 address-list-timeout=1m chain=prerouting dst-port=7000 log=yes \
    log-prefix="knock1 ok" protocol=tcp
/ip firewall filter
add action=accept chain=input dst-port=22 log=yes log-prefix=allowed protocol=tcp src-address-list=knocked
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).
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply.
 
libove
newbie
Topic Author
Posts: 42
Joined: Tue Aug 14, 2012 5:18 pm

Re: Port Knocking, avoid scan-caused false positives?

Mon Apr 22, 2019 10:50 am

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
 
joegoldman
Member
Member
Posts: 491
Joined: Mon May 27, 2013 2:05 am

Re: Port Knocking, avoid scan-caused false positives?

Mon Apr 22, 2019 11:26 am

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.
 
libove
newbie
Topic Author
Posts: 42
Joined: Tue Aug 14, 2012 5:18 pm

Re: Port Knocking, avoid scan-caused false positives?

Mon Apr 22, 2019 2:25 pm

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.
 
Sob
Forum Guru
Forum Guru
Posts: 4635
Joined: Mon Apr 20, 2009 9:11 pm

Re: Port Knocking, avoid scan-caused false positives?

Mon Apr 22, 2019 10:25 pm

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.
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply.
 
libove
newbie
Topic Author
Posts: 42
Joined: Tue Aug 14, 2012 5:18 pm

Re: Port Knocking, avoid scan-caused false positives?

Mon Apr 22, 2019 11:48 pm

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.
 
Sob
Forum Guru
Forum Guru
Posts: 4635
Joined: Mon Apr 20, 2009 9:11 pm

Re: Port Knocking, avoid scan-caused false positives?

Tue Apr 23, 2019 12:43 am

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.
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply.
 
User avatar
k6ccc
Member
Member
Posts: 479
Joined: Fri May 13, 2016 12:01 am
Location: Glendora, CA, USA (near Los Angeles)

Re: Port Knocking, avoid scan-caused false positives?

Tue Apr 23, 2019 7:10 am

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.
RB750Gr3, RB750r2, CRS326-24G-2S (in SwitchOS), CSS326-24G-2S, CSS106-5G-1S, RB260GS
Not sure if I beat them in submission, or they beat me into submission


Jim
 
User avatar
Jotne
Forum Guru
Forum Guru
Posts: 1302
Joined: Sat Dec 24, 2016 11:17 am
Location: jo.overland at gmail.com

Re: Port Knocking, avoid scan-caused false positives?

Tue Apr 23, 2019 9:49 am

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.
blocked.jpg
You do not have the required permissions to view the files attached to this post.
 
How to use Splunk to monitor your MikroTik Router

MikroTik->Splunk
 
 
libove
newbie
Topic Author
Posts: 42
Joined: Tue Aug 14, 2012 5:18 pm

Re: Port Knocking, avoid scan-caused false positives?

Tue Apr 23, 2019 10:14 am

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
 
anav
Forum Guru
Forum Guru
Posts: 2967
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Port Knocking, avoid scan-caused false positives?

Tue Apr 23, 2019 4:52 pm

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'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
mkx
Forum Guru
Forum Guru
Posts: 2941
Joined: Thu Mar 03, 2016 10:23 pm

Re: Port Knocking, avoid scan-caused false positives?

Tue Apr 23, 2019 6:11 pm

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.
BR,
Metod
 
Sob
Forum Guru
Forum Guru
Posts: 4635
Joined: Mon Apr 20, 2009 9:11 pm

Re: Port Knocking, avoid scan-caused false positives?

Tue Apr 23, 2019 6:30 pm

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.
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply.
 
anav
Forum Guru
Forum Guru
Posts: 2967
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Port Knocking, avoid scan-caused false positives?

Tue Apr 23, 2019 7:38 pm

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'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
anav
Forum Guru
Forum Guru
Posts: 2967
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Port Knocking, avoid scan-caused false positives?

Tue Apr 23, 2019 7:39 pm

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.
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
mkx
Forum Guru
Forum Guru
Posts: 2941
Joined: Thu Mar 03, 2016 10:23 pm

Re: Port Knocking, avoid scan-caused false positives?

Tue Apr 23, 2019 8:40 pm

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.
BR,
Metod
 
Sob
Forum Guru
Forum Guru
Posts: 4635
Joined: Mon Apr 20, 2009 9:11 pm

Re: Port Knocking, avoid scan-caused false positives?

Tue Apr 23, 2019 10:01 pm

@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.
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply.

Who is online

Users browsing this forum: No registered users and 84 guests