Port knocking is literally the computer security equivalent of an ADT home security sticker in your front window.
Port knocking
51–60 of 185 posts
Re: Port knocking
#52Port knocking was somewhat silly when it was introduced ~20 years ago --- at most, on a reasonably designed network, it was saving you from your own misconfigurations, but at least in 2005 it was reasonable to imagine a highly diverse network of machines that people logged into using multiple protocols, where those misconfigurations were likely. In 2020, it's gone past "silly" and is now a design smell, in the same w…
If you're exposing a developer instance to the network and it has port knocking deployed, why does it matter? The discoverability of such a service is basically zero. What are the chances of the cracker finding the exact combination of ports to knock on, and then the exact key to use? If they're able to do that then they are a dedicated attacker and they're mitm'ing a presumably encrypted connection on your network,…
The premise of your comment is that you're deploying dev instances on routable IP addresses on networks without default-closed filtering, in a configuration where it's theoretically possible that people could directly get a remote shell into that machine.
Don't do that.
In AWS (for example), have a dev VPC, and a WireGuard forwarder on it (or, if you're doing things 2010-style, an SSH bastion). If the machine needs to expose 443 directly to the Internet, give it an EIP; have the VPC prevent traffic to anything but 443 (and WireGuard).
What, in that architecture, would port knocking even be accomplishing? Keeping the wrong developer off your machine?
As for how attackers would break port knocking: if you believe attackers can't passively watch traffic, either directly or through redirection, I have good news for you about how much money you need to spend on encrypting traffic!
Re: Port knocking
#53I've been in this business for a long, long time and have come across all manner of innovations regarding network security. Port knocking (which I think I learned about first at defcon ... perhaps 18 years ago ?) stands out as one of the very few things that made my network(s) substantially safer at nearly zero cost. I love, and continue to love, both the idea and the implementation. Pay no attention to the nay-sayer…
any tips or where one would get best practice for configuring/setting up/using knockd? I wrote up how having a server on the internet is scary now ( http://redgreenrepeat.com/2020/03/20/why-you-should-secure-y... ) and how to protect it ( http://redgreenrepeat.com/2020/04/10/how-to-secure-your-serv... ) One thing I didn't get into more was port knocking/knockd as there were not many resources for it. I'd love to lear…
Moxie actually published a nice lighweight port knocking daemon that:
* Does not bind to sockets
* Is not written in C
* Prevents replay attacks
* The only code that runs as root is just tailing kern.log and is like 15 lines
It probably needs to roll from SHA1 to SHA256 and Python2 to Python3, but otherwise seems sound.
Re: Port knocking
#54Earlier quoted context omitted.
i prefer knowing that nothing is happening rather than filtering things i dont like. also, lots of people sing the praises of fail2ban, which needs to watch log files to operate, but you can get most of its utility by simply rate-limiting using iptables' session tracking without any additional mechanisms. https://selivan.github.io/2018/07/07/limit-new-connections-f...
I can tell you right now what's happening and compress all those log records into a single record: Every exposed 22/tcp on the Internet is being continuously exposed to automated SSH scanners running from thousands of points on the Internet. There is nothing you can reasonably do to prevent it (the sources are so diverse you couldn't even realistically block a determined scanner), and, if you've turned off password a…
> the sources are so diverse you couldn't even realistically block a determined scanner
thankfully, i dont have properties which attract determined scanners. and i imagine that's true for 99% of public ip addresses, too.
Re: Port knocking
#55Earlier quoted context omitted.
any tips or where one would get best practice for configuring/setting up/using knockd? I wrote up how having a server on the internet is scary now ( http://redgreenrepeat.com/2020/03/20/why-you-should-secure-y... ) and how to protect it ( http://redgreenrepeat.com/2020/04/10/how-to-secure-your-serv... ) One thing I didn't get into more was port knocking/knockd as there were not many resources for it. I'd love to lear…
vpn + port knocking should be good enough but I am not sure how to implement it in an efficient way (I currently only use a VPN) https://www.howtogeek.com/105693/how-to-knock-into-your-netw...
Does this have any advantages over using plain wireguard? WG operates purely over UDP and doesn't respond unless you send it packets with an authorized key, so it's essentially the VPN and port knocking all in one.
Re: Port knocking
#56Port knocking was somewhat silly when it was introduced ~20 years ago --- at most, on a reasonably designed network, it was saving you from your own misconfigurations, but at least in 2005 it was reasonable to imagine a highly diverse network of machines that people logged into using multiple protocols, where those misconfigurations were likely. In 2020, it's gone past "silly" and is now a design smell, in the same w…
I use port knocking and I don’t take it seriously. Anyone using it in a serious setup is batshit. However, for fun home projects where users install that giant php based file sharing program, or that IoT camera, why not? They don’t have automated intrusion prevention, etc. They can’t understand the code to determine it’s quality, etc.
When the next 0day hits… will it be enough to protect them, yes. After all, they’re not a target and the automated attacks won’t affect them.
Re: Port knocking
#57Earlier quoted context omitted.
I can tell you right now what's happening and compress all those log records into a single record: Every exposed 22/tcp on the Internet is being continuously exposed to automated SSH scanners running from thousands of points on the Internet. There is nothing you can reasonably do to prevent it (the sources are so diverse you couldn't even realistically block a determined scanner), and, if you've turned off password a…
> the sources are so diverse you couldn't even realistically block a determined scanner thankfully, i dont have properties which attract determined scanners. and i imagine that's true for 99% of public ip addresses, too.
So then, of course, there isn't even a theoretical reason why you'd want to pay attention to SSH probes.
Re: Port knocking
#58Earlier quoted context omitted.
i prefer knowing that nothing is happening rather than filtering things i dont like. also, lots of people sing the praises of fail2ban, which needs to watch log files to operate, but you can get most of its utility by simply rate-limiting using iptables' session tracking without any additional mechanisms. https://selivan.github.io/2018/07/07/limit-new-connections-f...
I can tell you right now what's happening and compress all those log records into a single record: Every exposed 22/tcp on the Internet is being continuously exposed to automated SSH scanners running from thousands of points on the Internet. There is nothing you can reasonably do to prevent it (the sources are so diverse you couldn't even realistically block a determined scanner), and, if you've turned off password a…
From a systems-administration standpoint, it's nice to be able to easily sift out the random bots and drive-bys from the more personal probes that maybe have a human at the other end.
There are myriad bits and bobs of software and services that promise to do anomaly detection in logs, but an easier approach for now is to just move ssh off 22. It affords basically zero extra real security but makes any subsequent login attempts more worthwhile to look at.
Re: Port knocking
#59Earlier quoted context omitted.
from personal experience, simply moving ssh off of port 22 cuts your drive-by log noise by 99.9%, which makes auditing clean logs much much easier. failed login attempts with ssh on 22: hundreds per week, after: 0. i imagine with knockd it would go negative.
> moving ssh off of port 22 cuts your drive-by log noise I didn't know logs made me unsafe! I'm turning off all logging immediately.
The point is that 99% of all access attempts are done by simple skiddies or people simply crawling the internet with masscan or similar.
Re: Port knocking
#60Earlier quoted context omitted.
I can tell you right now what's happening and compress all those log records into a single record: Every exposed 22/tcp on the Internet is being continuously exposed to automated SSH scanners running from thousands of points on the Internet. There is nothing you can reasonably do to prevent it (the sources are so diverse you couldn't even realistically block a determined scanner), and, if you've turned off password a…
From a systems-administration standpoint, it's nice to be able to easily sift out the random bots and drive-bys from the more personal probes that maybe have a human at the other end. There are myriad bits and bobs of software and services that promise to do anomaly detection in logs, but an easier approach for now is to just move ssh off 22. It affords basically zero extra real security but makes any subsequent logi…
Let me gently challenge you: you've moved SSH to 7163/tcp. You see a pattern of login attempts. Now what, and why?