The title "Changes sshd port every 30 seconds, using Two Factor Auth to login"
This isn't what the project is about, It was mainly done as a joke for all of the people who say "Changing your port is security by obscurity", and thus the idea came to make a even more insane/silly version of it.
It's using "two factor" to generate the port to connect, not to login, there are loads of ways to authenticate SSH with TOTP tokens, but this is not that.
> a joke for all of the people who say "Changing your port is security by obscurity"
This always tickled me. I don't do it for security; I do it because (on public-facing servers) it keeps the constant stream of doorknob-rattling out of the logs!
Fun project. With my more serious hat on, I think what most people are missing about all these port-knocking schemes -- is that they all boil down to poor key based authentication.
In the case of TOTP, the key is stored in plain text two places: the server and the TOTP client (or similarly, for other port knocking schemes, on the server to calculate the next port, and on the client to do the same).
Contrast this with disabling password login, and using only key-based authentication: Now the secret key is only stored in one place: on the client (although, to be fair, there's a secret key you can steal on the server too, in order to compromise the system).
The way to improve security beyond simply requiring key-based auth, is to move away from trust-on-first-use to using ssh certificates. To improve on that, require certificates and TOTP. It's still somewhat hard to see how the latter really improves on security - perhaps with some kind of dedicated TOTP hw token. I would guess that compromising the TOTP-key stored on a smartphone is probably one of the easiest attack vectors, so it's unclear how much more secure it is, beyond simply using ssh certificates.
Couple of enhancements - there should be port map for ports which not to connect to.
Also - you will have a hell of a time with synchronization, timezone etc.
> as a joke for all of the people who say "Changing your port is security by obscurity"
That's simply not true. Changing the sshd safes you a lot of trouble in risky environments. You prevent services which rely on ssh from failing during automated dos/bf attempts.
Unfortunately people have taken this a little too seriously, I wrote this as a joke/PoC of silly "Security by obscurity" methods, and yet people are for some reason viewing this as a serious solution...
I recognize that this is a joke, in the words of the OP. However I think SPA-type port knocking is completely legitimate, and I second the use of fwknopd. I depend on fwknopd a lot, so if that is not secure idea, I would like someone to point that out to me. NOTE that fwknopd does not depend on expecting a client to connect to a short sequence of different port numbers. That is not what fwknopd does, at least not the latest fwknopd. Instead, fwknopd listens for an encrypted packet on a specified port, which it will not acknowledge. The firewall does not allow the packet through, technically speaking. But fwknopd recognizes the arrival of the packet by scanning logs when the firewall drops the packet and logs the dropped packet. etc. etc. If you know this type of fwknopd deployment and don't think it is a good idea, please comment.
Again, I am not taking the OP seriously, but I do take seriously that people either don't know about fwknopd, or maybe, don't think that is good security (in which case I want to hear from you).
People get their wires crossed about port knocking because it doesn't add much security when I'm trying to find a way to hack you. It does add something when I'm trying randomly to find you to hack.
They make the valid criticism of the first case while you argue the second and somehow the arguments miss in the middle.
It does seem a little silly, the readme does also mention it was written as a joke.
Was looking at ways to decrease logspam from ssh login bots some years ago, port knocking seemed like the most elegant solution. I ended up simply moving ssh away from port 22, the logspam disappeared.
I've used fail2ban in other setups, it also has the advantage of being easy to integrate with other systems such as wordpress, sftp/ftps, nginx, apache.
"I don't understand why this is seen as acceptable, yet port knocking is derided every time it's brought up."
I have been in this business for a long time and I still look very fondly at port-knocking as a thing that genuinely makes things better.
Almost zero complexity added, super stable knockd daemon, and does a single, simple thing very, very well.
I love port knocking, I love using it, I love the idea of it, and I wouldn't build a server without hiding sshd (and others) behind a knock.
All criticism of port knocking (weirdly) assumes that you also disable all other forms of security and that you rely solely on port knocking, which of course is false.
It is true that port knocking adds just a marginal additional amount of security, but it's still additive and it's still a high return on the (very low) complexity and maintenance.
If you chain two sshd and have a certificate on the first and password on the second, the second sshd will have the exact same number of attempts as your current setup.
Nice idea, but tbh I'd prefer if someone rewrote it in (ba)sh scripts. Not everyone likes to install dozens of different language interpreters/runtimes on his systems - Ruby for puppet, perl is these days mainly used by apt-get, Go, NodeJS, some people use PHP, then Java, the Python version hell with people using either 2.7 or 3.x, Mono, bash, zsh, C, C++...
As much as I like flexibility and "the right tool for the right job", we have ended with ridiculously huge install bases - a minimal Debian may very well end up with hundreds of megabytes, it's ridiculous.
Is there a service that wraps/proxies a port with a different or custom protocol? (kind of like SSL for HTTP)
Idea: instead of ssh'ing a server, you would run your custom command which communicates to port XXXX, communicate with a custom protocol and then if validation succeeds, would proxy to SSH (or any other internal port/protocol).
Why? Because as others suggested you could scan all ports very quickly to break this, but if you scan a port and just receive garbage or something only you can understand when opening it, then you could hide it from the outside..
Seems possible (though very time-consuming) if you just use it to protect your hobby/toy machines. As soon as your protocol becomes important enough that it attracts the attention of human hackers and not just bots they can easily reverse-engeneer it.
By the way, I think you could view encrypted connections as a sort of automation of that practice: A crypto algorithm could be seen as a machine that generates "custom protocols" given a key...
<shameless_plug>
Check out fwknop, https://www.cipherdyne.org/fwknop/
It's one solution to this problem. Instead of answering with garbage, it allows for keeping the firewall closed/default drop stance. It's port knocking, but with real cryptography instead of just relying on hitting port numbers, and does it with just a single packet.
</shameless_plug>
Full disclosure: I'm one of the Fwknop devs.
If I suspect you're doing this, I can definitely probe 30k ports silently within a second. How many tries do you think I need to break the last two digits?
The very description of the project says "Take security by obscurity to the next level (You must be insane to run this)", so I'm not sure why you're trying to convince the author here.
Two men walking in the woods enter grizzly country. One stops and swaps his hiking boots for running shoes. The other says, that's stupid, you'll never out run a grizzly bear.
The technical concerns fall under the category of security. The business concerns fall under risk mitigation. These concerns converge as the value of an enterprise's assets rises. Banks and blogs are toward different ends of the spectrum. At the lower end, this sort of measure probably keeps a wordpress site in the middle of the herd when wolves invite themselves to dinner.
a) It's not explicitly said that the ssh password is the last digits from the code. That's the intuition I got as well, but that would be pure craziness. I assume only the port is affected, and you're using your normal authentication scheme (key or password) to login.
b) Straight from the GitHub's README, which was not edited after submission to HN:
>> Beware, currently I would not really recommend running this software, it was only written as a joke.
Rate limiting login attempts is an easy way to prevent some of the high speed password guessing attacks. However, it's hard to limit distributed attacks and many run at a low pace over weeks or months. I personally prefer to avoid using automated response tools like fail2ban. And this is for two reasons:
1) Legitimate users sometimes forget their passwords. I don't want to ban legitimate users from my server, forcing me to manually enable their accounts again (or worse, try to figure out which of the 100/1000 banned IP addresses is theirs).
2) An IP address is not a good identifier for a user. If you have multiple users behind a single IP (for example, a school that runs NAT on 500 student machines) a single user making a few bad guesses can land you in a world of pain. At the same time the majority of the password guessing attempts I see are distributed.
Therefore I don't consider fail2ban (and similar automated response tools) a very good approach to securing a server against brute force attacks. A simple IPTables rules set to cut down on the log spam (which I have on most of my linux servers) is something like this:
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP
It prevents more than 4 connection attempts from a single IP to ssh in any 60 second period. The rest can be handled by ensuring passwords are reasonably strong. On high security servers forcing the users to use public key authentication is another way to stop guessing.
(Uncomplicated Firewall) ufw supports connection rate limiting, which is useful for protecting
against brute-force login attacks. When a limit rule is used, ufw will
normally allow the connection but will deny connections if an IP
address attempts to initiate 6 or more connections within 30 seconds.
See http://www.debian-administration.org/articles/187 for details.
[+] [-] taspeotis|9 years ago|reply
[+] [-] benjojo12|9 years ago|reply
The title "Changes sshd port every 30 seconds, using Two Factor Auth to login"
This isn't what the project is about, It was mainly done as a joke for all of the people who say "Changing your port is security by obscurity", and thus the idea came to make a even more insane/silly version of it.
It's using "two factor" to generate the port to connect, not to login, there are loads of ways to authenticate SSH with TOTP tokens, but this is not that.
[+] [-] niccaluim|9 years ago|reply
This always tickled me. I don't do it for security; I do it because (on public-facing servers) it keeps the constant stream of doorknob-rattling out of the logs!
[+] [-] e12e|9 years ago|reply
In the case of TOTP, the key is stored in plain text two places: the server and the TOTP client (or similarly, for other port knocking schemes, on the server to calculate the next port, and on the client to do the same).
Contrast this with disabling password login, and using only key-based authentication: Now the secret key is only stored in one place: on the client (although, to be fair, there's a secret key you can steal on the server too, in order to compromise the system).
The way to improve security beyond simply requiring key-based auth, is to move away from trust-on-first-use to using ssh certificates. To improve on that, require certificates and TOTP. It's still somewhat hard to see how the latter really improves on security - perhaps with some kind of dedicated TOTP hw token. I would guess that compromising the TOTP-key stored on a smartphone is probably one of the easiest attack vectors, so it's unclear how much more secure it is, beyond simply using ssh certificates.
[+] [-] venomsnake|9 years ago|reply
[+] [-] camperman|9 years ago|reply
[+] [-] evook|9 years ago|reply
That's simply not true. Changing the sshd safes you a lot of trouble in risky environments. You prevent services which rely on ssh from failing during automated dos/bf attempts.
[+] [-] patrickg_zill|9 years ago|reply
[+] [-] benkulbertis|9 years ago|reply
[deleted]
[+] [-] e40|9 years ago|reply
Since installing fwknopd more than a year ago, we have had not a single attempt at sshd. Not one. We had a lot before, and it was annoying as hell.
[+] [-] benjojo12|9 years ago|reply
[+] [-] georgeam|9 years ago|reply
Again, I am not taking the OP seriously, but I do take seriously that people either don't know about fwknopd, or maybe, don't think that is good security (in which case I want to hear from you).
[+] [-] noonespecial|9 years ago|reply
They make the valid criticism of the first case while you argue the second and somehow the arguments miss in the middle.
[+] [-] mclemme|9 years ago|reply
Was looking at ways to decrease logspam from ssh login bots some years ago, port knocking seemed like the most elegant solution. I ended up simply moving ssh away from port 22, the logspam disappeared.
I've used fail2ban in other setups, it also has the advantage of being easy to integrate with other systems such as wordpress, sftp/ftps, nginx, apache.
[+] [-] rsync|9 years ago|reply
I have been in this business for a long time and I still look very fondly at port-knocking as a thing that genuinely makes things better.
Almost zero complexity added, super stable knockd daemon, and does a single, simple thing very, very well.
I love port knocking, I love using it, I love the idea of it, and I wouldn't build a server without hiding sshd (and others) behind a knock.
All criticism of port knocking (weirdly) assumes that you also disable all other forms of security and that you rely solely on port knocking, which of course is false.
It is true that port knocking adds just a marginal additional amount of security, but it's still additive and it's still a high return on the (very low) complexity and maintenance.
[+] [-] belorn|9 years ago|reply
[+] [-] mschuster91|9 years ago|reply
As much as I like flexibility and "the right tool for the right job", we have ended with ridiculously huge install bases - a minimal Debian may very well end up with hundreds of megabytes, it's ridiculous.
Mandatory xkcd: https://xkcd.com/927/
[+] [-] Nullabillity|9 years ago|reply
[+] [-] daraosn|9 years ago|reply
Idea: instead of ssh'ing a server, you would run your custom command which communicates to port XXXX, communicate with a custom protocol and then if validation succeeds, would proxy to SSH (or any other internal port/protocol).
Why? Because as others suggested you could scan all ports very quickly to break this, but if you scan a port and just receive garbage or something only you can understand when opening it, then you could hide it from the outside..
(Just curious)
[+] [-] xg15|9 years ago|reply
By the way, I think you could view encrypted connections as a sort of automation of that practice: A crypto algorithm could be seen as a machine that generates "custom protocols" given a key...
[+] [-] mjec|9 years ago|reply
[+] [-] oneru|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] geocar|9 years ago|reply
If I suspect you're doing this, I can definitely probe 30k ports silently within a second. How many tries do you think I need to break the last two digits?
[+] [-] MichaelBurge|9 years ago|reply
[+] [-] brudgers|9 years ago|reply
The technical concerns fall under the category of security. The business concerns fall under risk mitigation. These concerns converge as the value of an enterprise's assets rises. Banks and blogs are toward different ends of the spectrum. At the lower end, this sort of measure probably keeps a wordpress site in the middle of the herd when wolves invite themselves to dinner.
[+] [-] developer2|9 years ago|reply
b) Straight from the GitHub's README, which was not edited after submission to HN:
>> Beware, currently I would not really recommend running this software, it was only written as a joke.
[+] [-] dexterdog|9 years ago|reply
[+] [-] cperciva|9 years ago|reply
[+] [-] geggam|9 years ago|reply
Log the accepted connections.
Reminds me of Butch Cassidy movie where the old man told them they were silly for worrying about getting robbed before they had the money.
If people cant get in they cant do bad things(tm)
BTW... is there an ansible playbook for portnocking with config management ?
[+] [-] Animats|9 years ago|reply
Still, this stuff is useful just to thin out all the crap coming in from botnets.
[+] [-] dohqu8Zi|9 years ago|reply
[+] [-] cel1ne|9 years ago|reply
[+] [-] sschueller|9 years ago|reply
[+] [-] agrafix|9 years ago|reply
[+] [-] jftuga|9 years ago|reply
http://serverfault.com/a/217066/46738
(accepted answer is pasted below)
Rate limiting login attempts is an easy way to prevent some of the high speed password guessing attacks. However, it's hard to limit distributed attacks and many run at a low pace over weeks or months. I personally prefer to avoid using automated response tools like fail2ban. And this is for two reasons:
1) Legitimate users sometimes forget their passwords. I don't want to ban legitimate users from my server, forcing me to manually enable their accounts again (or worse, try to figure out which of the 100/1000 banned IP addresses is theirs).
2) An IP address is not a good identifier for a user. If you have multiple users behind a single IP (for example, a school that runs NAT on 500 student machines) a single user making a few bad guesses can land you in a world of pain. At the same time the majority of the password guessing attempts I see are distributed.
Therefore I don't consider fail2ban (and similar automated response tools) a very good approach to securing a server against brute force attacks. A simple IPTables rules set to cut down on the log spam (which I have on most of my linux servers) is something like this:
It prevents more than 4 connection attempts from a single IP to ssh in any 60 second period. The rest can be handled by ensuring passwords are reasonably strong. On high security servers forcing the users to use public key authentication is another way to stop guessing.---- (end of answer)
for Ubuntu admins...
http://manpages.ubuntu.com/manpages/xenial/man8/ufw.8.html
(Uncomplicated Firewall) ufw supports connection rate limiting, which is useful for protecting against brute-force login attacks. When a limit rule is used, ufw will normally allow the connection but will deny connections if an IP address attempts to initiate 6 or more connections within 30 seconds. See http://www.debian-administration.org/articles/187 for details.
Typical usage is:
[+] [-] joelhaasnoot|9 years ago|reply
Public key and IP limiting is standard practice, eliminating passwords should be top priority for anyone running SSH servers.