Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Port knocking

en.wikipedia.org

Post reply on HN
Print view View original

71–80 of 185 posts

Re: Port knocking

#71

Post by rogerdonut »

x3blah wrote: post #26

One can use "port knocking" for more than remotely opening ports. It is a crude form of messaging in its own right, that can be based on some pre-determined code, like Morse code. The "secret knock" need not open any ports. It can be simply a message to the person (or program) reading the logs, to be translated according to the pre-determined code. Actions might be taken in response to the message, or not. It is poss…

Good idea. You can also do it based on a sequence of ports accessed as well without headers/values which would allow you to forward directly to a tcp based service. You can track which ports are accessed and verify the sequence using stick-tables.

Here's an example of what that would look like:

https://gist.github.com/dcorbett-haproxy/ec7059cbfccf12c8f41...

Re: Port knocking

#72

Post by wave100 »

taliesinb wrote: post #12

I implemented a physical port-knocking daemon, once. I lived in a block of flats — you needed an expensive fob to open the outer gate, and it didn’t even work reliably. I lost my fob. So I took my intercom apart and wired a band pass filter circuit between the buzzer input and actuator output. If you pressed my buzzer with the right steady pattern, it would automatically let you in. It worked great and I didn’t buy a…

I'd have gone the overly complicated route - throw a relay in there and tie it to something that detects whether or not your phone is connected to your WiFi network. Automatically disable it when you're already home!

Re: Port knocking

#73

Post by thaumaturgy »

tptacek wrote: post #69
thaumaturgy wrote: post #64

Earlier quoted context omitted.

Sure. Direct answer: search logs across all services and nodes on the network for activity from that source or netrange. See if it's targeting particular usernames, especially anything that shouldn't be guessable. Treat it first as a source of information: did I screw something up somewhere? Have we had an incident I don't know about? If it looks like nothingburger, ignore it and get on with the day. Broader answer a…

I guess that's fair. But: if you buy into this idea, there's a much, much better thing to do: look into Canarytokens. Canarytokens, unlike port knocking, are criminally underused. Really, you should do something similar for your off-port SSH service; don't actually _run_ SSH there, just run a stateless unprivileged service that spoofs a bit of SSH protocol and generates loud alerts. The networks I'm describing aren't…

Cool, thanks. I found https://blog.thinkst.com/p/canarytokensorg-quick-free-detect...; is there a better writeup you have offhand? https://github.com/cowrie/cowrie has been on my todo list for a while too, but more as a toy than a serious thing.

> The networks I'm describing aren't "ideal" or "highly secured". I am describing table stakes. While I was at Latacora, most of the clients we engaged with were already at this level of maturity when we joined up.

One of the most valuable things you do here is describe things that you believe are table stakes to people and organizations that have never heard of them. Companies like Latacora tend to self-select for clients that are at least aware that security should be a sensible line item in their quarterly budget. There are many many more organizations for whom moving ssh or even port knocking amount to a real improvement to their infrastructure. :-(

Re: Port knocking

#74

Post by acidictadpole »

WrtCdEvrydy wrote: post #47
leeoniya wrote: post #42

Earlier 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.

I wonder if it would be interesting to load a ssh honeypot that would feed from the logs so it would add the logins and then just dump the ip + input to a file. Honeypot could basically run in a some sort of isolation layer (like Sandboxie or jails) and then self-destruct after the automated script is gone... and then you slam the door on that user/ip combo for good. I can't help but think this would be interesting..…

One of my university courses offered an opportunity for a project like this and I did it with some classmates.

We started by altering the ssh daemon to disallow all logins over this ssh daemon and to log all the usernames and passwords attempted. After a week we gathered thousands of attempts to brute force into the honeypot. Interestingly enough, the passwords used were a combination of the very commonly used ones but also ones that were clearly from other popped boxes.

After a week or so of this we altered the ssh daemon again. This time it would log all attempts but also grant access on the 3rd attempt no matter what the credentials were. The few bots that managed to get in all tried to install various rootkits on the machine, all of which where targeted at a different distro of Linux than we were using so it mostly just busted up our shells output.

It was a long time ago but a great experience.

Re: Port knocking

#75

Post by nominated1 »

thaumaturgy wrote: post #70
nominated1 wrote: post #30

I too am a fan of port knocking. I don’t use knockd, just iptables. I found the Arch Wiki most helpful. You’ll need to figure out which chain works for your setup but it’s pretty straightforward. https://wiki.archlinux.org/index.php/Port_knocking#Port_knoc... Here’s my example for a VPN running on OpenWrt. If you experience any race conditions with iptables you can pepper each rule with something like “-w 5” This ope…

FWIW I worked with a guy who insisted on doing it this way and it was extremely twitchy. Problems included various operating systems and network tools knocking in ways that iptables hates but a knock daemon will handle (e.g. sending two requests per port); making iptables rules unnecessarily complex and hard to audit and eventually conflicting with other things that interacted with iptables; and, once, accidentally g…

Interesting. The only issue I’ve had was ensuring knocks were received in order. DDNS being the worst culprit. Ensuring an adequate delay between knocks solved my problems. However, I use this for home (friends and family only) nothing serious.

If I were to use a daemon I’d go with an SPA, like fwknop. The lack of an iOS client is the only reason I still use port knocking.

Re: Port knocking

#76

Post by hunter2_ »

leeoniya wrote: post #67
tptacek wrote: post #57

Earlier quoted context omitted.

So then, of course, there isn't even a theoretical reason why you'd want to pay attention to SSH probes.

i mean, you're in the security industry, where targeted attacks are the default assumption. the overwhelming majority of web properties are not valuable enough to get this kind of attention. even if security through obscurity is not real protection from targeted attacks, it is at minimum significant noise reduction, and quite possibly a reasonable barrier against drive-bys which assume default configurations. i'm sur…

The whole "obscurity isn't security" thing is a super interesting topic. Suppose you have a static file on a public web server and you want to control access to the file... confidentiality. Many people would agree that if you come up with a long string, don't disclose it to untrusted parties, and use it as a basic auth password, then you have secured the file to some extent. And many people would claim that if you take that same undisclosed string, and make it a path segment (parent directory) for the file, then you have merely obscured the file, or perhaps secured it to a far lesser extent. The former makes it "not available to the public" while the latter makes it "available to the public, they just don't know where to look."

I call BS. These are pretty much the same thing* which is to say: an adversary trying to get the file needs to know something that they don't know, and can't reasonably guess/discover any time soon. Did you secure it or obscure it? Whatever you call it, you require a "something you know" factor.

*Obviously, there's the fact that other parts of the stack -- browser history, access logs, rate limiting, etc. -- actually treat a password payload with the respect it deserves and assume there's nothing sensitive about a URI path... kindly pretend my example doesn't have this flaw.

Re: Port knocking

#77

Post by cycomanic »

WrtCdEvrydy wrote: post #47
leeoniya wrote: post #42

Earlier 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.

I wonder if it would be interesting to load a ssh honeypot that would feed from the logs so it would add the logins and then just dump the ip + input to a file. Honeypot could basically run in a some sort of isolation layer (like Sandboxie or jails) and then self-destruct after the automated script is gone... and then you slam the door on that user/ip combo for good. I can't help but think this would be interesting..…

You don't even need a honeypot, simply ban ip addresses for some time after X failed login attempts.

Re: Port knocking

#78

Post by tptacek »

thaumaturgy wrote: post #73
tptacek wrote: post #69

Earlier quoted context omitted.

I guess that's fair. But: if you buy into this idea, there's a much, much better thing to do: look into Canarytokens. Canarytokens, unlike port knocking, are criminally underused. Really, you should do something similar for your off-port SSH service; don't actually _run_ SSH there, just run a stateless unprivileged service that spoofs a bit of SSH protocol and generates loud alerts. The networks I'm describing aren't…

Cool, thanks. I found https://blog.thinkst.com/p/canarytokensorg-quick-free-detect... ; is there a better writeup you have offhand? https://github.com/cowrie/cowrie has been on my todo list for a while too, but more as a toy than a serious thing. > The networks I'm describing aren't "ideal" or "highly secured". I am describing table stakes. While I was at Latacora, most of the clients we engaged with were already at…

There's:

https://canary.tools/help/canarytokens

But the concept is really simple: come with any kind of thing you'd want to tripwire --- the AWS key is particularly slick --- and put it somewhere in your infra, then wait for alerts.

Re: Port knocking

#79

Post by matheusmoreira »

rsync wrote: post #5

I'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…

What do you think about single packet authorization?

Re: Port knocking

#80

Post by [deleted] »

tptacek wrote: post #46
leeoniya wrote: post #42

Earlier 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.

Wouldn't a reasonable rebuttal be that the log filtering rule that discards these failed login attempts would accomplish the same security goal, with less mechanism?

[deleted]
Post reply on HN