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

171–180 of 185 posts

Re: Port knocking

#171

Post by kelnos »

belorn wrote: post #141
kelnos wrote: post #68

Earlier quoted context omitted.

The point is that most login attempts are automated, and the automated scripts just try port 22 and move on if they fail. If you run ssh on port 22, you see in your logs all the failed attempts from the giant sea of automated scanners, and will probably miss the one or two humans who might know something about you specifically (like your username) and are trying a targeted attack. If you put ssh on another port, all…

I would be interested to read about peoples process and procedures from those that regularly read their ssh failed attempts, identify human attackers, and react to that information. My question is basically: Do they exist? How is the work flow and how much time per year do they spend on it? What incident occurred and what value did they derive from the process. Was it cost-effective?

I don't read mine at all (talking about a personal server here[0]), because there's a huge amount of noise. The email alerts for it go to a mail folder that I literally never look at, because it gets hundreds of emails per day.

If I only got an email per week or so, I'd probably not filter them to a folder, and actually look at them.

[0] At work, other people deal with intrusion detection there, and ssh access is gated behind a VPN anyway.

Re: Port knocking

#172

Post by kelnos »

mirages wrote: post #98
kelnos wrote: post #68

Earlier quoted context omitted.

The point is that most login attempts are automated, and the automated scripts just try port 22 and move on if they fail. If you run ssh on port 22, you see in your logs all the failed attempts from the giant sea of automated scanners, and will probably miss the one or two humans who might know something about you specifically (like your username) and are trying a targeted attack. If you put ssh on another port, all…

Actually I'm receiving about 10 attempts per minute on my non-22 ssh port that I've set up

Damn, that's a shame. From what other people say when they advocate non-22, they make me believe it would be a lot less. Oh well.

Re: Port knocking

#173

Post by koheripbal »

simias wrote: post #131
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…

For me changing the default port for SSH achieved much of the same result at an even lower cost IMO. That is, unless you're high profile enough that attackers might want to target your server specifically and you're not just randomly scanned by botnets which won't generally bother looking beyond port 22.

Same with RDP. Hackers don't even bother to scan outside of 3389. My logs are empty.

Re: Port knocking

#174

Post by koheripbal »

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…

There is this idiotic notion that any security measure that cannot stand on its own is "security by obscurity", and therefore useless.

That principle is taught in school and echoed by every junior netsec professional out there.

After almost 20 years of work, I can say that these layered techniques, are invaluable. OF COURSE, the core security has to be bulletproof. But once you've covered that base, there is an enormous value in keeping your assets under the radar.

At the very least, it reduces the number of alerts you need to review by several orders of magnitude. Logs become READABLE.

Re: Port knocking

#175

Post by ape4 »

metalliqaz wrote: post #148
ape4 wrote: post #140

Earlier quoted context omitted.

Put ssh on port 80 and http on port 22 - perfect security ;)

for my internet-facing machines I black-hole everything below 1024 and move SSH to something high but easy enough to remember like 22222

If I was an evil hacker I would look at that port and other variants of 22 like 2200, 2222, etc for people's ssh.

Re: Port knocking

#176

Post by demosito666 »

rmrfstar wrote: post #53
acl777 wrote: post #7

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

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. [1] https://moxie.org/software/knockknock/

This is freaking genius!

Re: Port knocking

#177

Post by juliusdavies »

tptacek wrote: post #165
cheweh wrote: post #144

Earlier quoted context omitted.

Re: sniffing, if I were implementing port knocking I would use the "single packet authorization" variant like in knockknock, which makes sniffing much less useful to an attacker.

At the point where you're installing network cryptography tools to authorize access to your machine, why not just use a real cryptographic tunnel?

I just prepend a secret letter to every possible ssh account on my server ('root' becomes 'jroot') and so that way "ssh root@myserver.com" can never work even if you know my root password. And this way my defense is opaque to attackers passively monitoring my network traffic (the username is encrypted in the ssh protocol).

Oh shit, I just gave away my secret on a public forum...

Ha ha, fooled you! I use a different secret letter in actual practice!

(Or do I?)

p.s. Pretty sure port-knocking offers less protection than this scheme.

Re: Port knocking

#178

Post by tptacek »

juliusdavies wrote: post #177
tptacek wrote: post #165

Earlier quoted context omitted.

At the point where you're installing network cryptography tools to authorize access to your machine, why not just use a real cryptographic tunnel?

I just prepend a secret letter to every possible ssh account on my server ('root' becomes 'jroot') and so that way "ssh root@myserver.com" can never work even if you know my root password. And this way my defense is opaque to attackers passively monitoring my network traffic (the username is encrypted in the ssh protocol). Oh shit, I just gave away my secret on a public forum... Ha ha, fooled you! I use a different s…

This does basically approximate my take on port knocking. :)

Re: Port knocking

#179

Post by jftuga »

I have created a different approach to accomplish the (somewhat) same goal as port knocking here:

https://github.com/jftuga/gofwd

gofwd is a cross-platform TCP port forwarder with Duo 2FA and Geographic IP integration. Its use case is to help protect services when using a VPN is not possible. Before a connection is forwarded, the remote IP address is geographically checked against city, region (state), and/or country. Distance (in miles) can also be used. If this condition is satisfied, a Duo 2FA request can then be sent to a mobile device. The connection is only forwarded after Duo has verified the user.

Thoughts?

Re: Port knocking

#180

Post by fao_ »

gridlockd wrote: post #138
tptacek wrote: post #52

Earlier quoted context omitted.

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 t…

You're telling people not to do a simple thing, instead telling them to do a far more complex thing. You do not give a single argument on why the complex thing is meaningfully safer in practice. If security is equal for all practical purposes in either case, this would be the wrong thing to do, because it is easier to fuck up complex things and it's more expensive to manage them. https://xkcd.com/538/

Not just this, but they're assuming that everyone's server setups are enterprise-grade! People regularly still put raspberry pis and other kinds of low-cost computers on the public internet (William Gibson, for example, hosts hackers.town on a server setup in his (probably metaphorical) basement), and their answer to that is: "Don't do that".
Post reply on HN