Changes sshd port every 30 seconds, using Two Factor Auth to login(github.com)
github.com
Changes sshd port every 30 seconds, using Two Factor Auth to login
https://github.com/benjojo/totp-ssh-fluxer
75 comments
Previous discussion: https://news.ycombinator.com/item?id=11750003
Hi, Author of this here!
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.
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!
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!
Failed auths are generally boring and rarely worth looking at. Look at the successes instead.
I just use DenyHosts. A few rattling attempts, and the IP won't be able to make another auth attempt again.
It's very very very rarely the same IP.
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.
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.
Just an observation: 30 seconds should be enough to brute force all ports. It's possible to split the range of the ports by using multiple hosts to perform the scan in case 30 seconds don't be enough.
The obvious next step is ipv6 address hopping in a /64 dedicated to the machine in question I guess...
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.
Aren't you worried that systemd won't silently kill the background process? :)
I know that you are probably joking, but you'd launch such a thing from a unit file. Hence, no silent killing.
How would that even be possible?
He's referring to https://news.ycombinator.com/item?id=11782364
A new change in systemd made it so that nohup'd processes are killed by systemd after you log out.
I'm not really linux-savvy, but if it's true and it does what I think it does, it's really stupid. A lot of my scripts rely on nohup to send something to background, and I often logout after running the script, so this would break my whole workflow.
Does that mean that something like "wget URL &" would be killed if I log out of SSH?
Why would they change that? Isn't that exactly why you would ever nohup a process?
> 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.
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.
It's weird that you trust randomizing the port over a range of [0, 65536) over the trust you have for the cryptographic strength of a 4096-bit RSA key (or equivalent).
While making the port number based on a TOTP token is clearly just for fun, it's not unusual to not entirely trust public key authentication. This is an additional security step.
Once public key authentication is allowed, the mechanism is only as secure as the private key. There is no way to require a password on private keys, and in any event it could be captured with a keylogger. The concern is not the cryptographic strength of the key, it's end-user security.
While randomizing the port is not security, no one would say 2FA is not required because we can trust RSA.
Once public key authentication is allowed, the mechanism is only as secure as the private key. There is no way to require a password on private keys, and in any event it could be captured with a keylogger. The concern is not the cryptographic strength of the key, it's end-user security.
While randomizing the port is not security, no one would say 2FA is not required because we can trust RSA.
I trust two countermeasures over just one.
If someone could break 4096 bit ssh keys they could scan every single TCP port on the internet in seconds.
What?
http://blog.erratasec.com/2013/09/masscan-entire-internet-in...
180 seconds is still seconds. Randomizing ports really doesn't buy much.
180 seconds is still seconds. Randomizing ports really doesn't buy much.
If they can break SSH keys like that, they'll easily compromise thousands of servers they can use to scale up their attack.
But is it not true that a random port helps specifically against DoS attacks?
What on earth does a port have to do with a denial of service? Let's play this out, Mr. Spock:
- I have some kind of SSH-specific DoS and will simply enumerate ports until I find SSH, which readily identifies itself right off the bat by nature of the protocol. (No config for that.) Result: DoS successful.
- You deploy fail2ban because someone told you to do so because it makes you "safer." Now I can DoS you in three ways since I know (a) there's a Python regex running on your log and (b) naughty addresses will add a netfilter rule, gradually slowing down each packet as it traverses INPUT. What's that, Lassie? A /16 fell down the SSH port while I inundated fail2ban with failures? (Why do you think fail2ban doesn't have IPv6 support yet? I'm just waiting for [0] since solving the problem is intractable, despite what is common consensus in that community. Oh, you're flattening prefixes? How cute. Watch me find the corner cases in your flattening algorithm since I have several googols of v6 addresses to play with.) Result: DoS successful.
- I grow bored of your mildly annoying countermeasures and simply fire up a reflection attack that targets you with several gigabit/sec of traffic behind the aft nacelle, not caring where your SSH lives. Result: Vastly more probable DoS super successful once your hosting provider null routes you. Add cron to watch for your return. Repeat. Follow you to the new IP when you try that because I will invariably find it (probably when you get back on IRC). Walk over your cold server's corpse while you panic and email CloudFlare who can't help, and you can't afford who can. The end.
Now, shall we begin?
There is a lot of shitty shaman wisdom, some making an appearance in this thread, around the SSH port and logging and yadda yadda that actually makes things less safe for a lot of people who don't know better. Most people move SSH from 22 to something like 2200, forgetting that <1024 requires root so now they're one sshd listener crash or restart race away from a local user intercepting SSH with a malicious binary. Oops.
Correct, and only correct, answer: leave sshd on 22 and get your squishy services off the public Internet or rotate the logs faster. You are a sysadmin with grep and awk. Deal with failures in your log. They are there for a reason, especially if you are exposing sshd to the Internet, and pulling netfilter in or moving ports around is silly TSA-level security theater.
This is all promulgated by those "do these ten things first when you install Ubuntu" guides which capitalize on folks not knowing any better to identify (often faulty) opinion. If you followed one lately it's probably steered you wrong, much like those Learn Sushi Preparation in 24 Hours books. Take the time to understand the problem if you're going to operate services on the Internet and get away from guides. (And yes, I am indicting you for writing one, iff yours includes anything discussed in this comment. Sorry.)
Knocking is the only truly plausible, though still silly, security idea here but even that betrays itself in an nmap by nature of TCP. Also, hope you don't forget your knock when your machine is on fire. (You will.)
It's too bad I'm on the right side of ethical these days or I'd patch all the common SSH scanners to try every port so people will stop doing stuff like this. Some already do.
[0]: https://github.com/fail2ban/fail2ban/pull/1410
- I have some kind of SSH-specific DoS and will simply enumerate ports until I find SSH, which readily identifies itself right off the bat by nature of the protocol. (No config for that.) Result: DoS successful.
- You deploy fail2ban because someone told you to do so because it makes you "safer." Now I can DoS you in three ways since I know (a) there's a Python regex running on your log and (b) naughty addresses will add a netfilter rule, gradually slowing down each packet as it traverses INPUT. What's that, Lassie? A /16 fell down the SSH port while I inundated fail2ban with failures? (Why do you think fail2ban doesn't have IPv6 support yet? I'm just waiting for [0] since solving the problem is intractable, despite what is common consensus in that community. Oh, you're flattening prefixes? How cute. Watch me find the corner cases in your flattening algorithm since I have several googols of v6 addresses to play with.) Result: DoS successful.
- I grow bored of your mildly annoying countermeasures and simply fire up a reflection attack that targets you with several gigabit/sec of traffic behind the aft nacelle, not caring where your SSH lives. Result: Vastly more probable DoS super successful once your hosting provider null routes you. Add cron to watch for your return. Repeat. Follow you to the new IP when you try that because I will invariably find it (probably when you get back on IRC). Walk over your cold server's corpse while you panic and email CloudFlare who can't help, and you can't afford who can. The end.
Now, shall we begin?
There is a lot of shitty shaman wisdom, some making an appearance in this thread, around the SSH port and logging and yadda yadda that actually makes things less safe for a lot of people who don't know better. Most people move SSH from 22 to something like 2200, forgetting that <1024 requires root so now they're one sshd listener crash or restart race away from a local user intercepting SSH with a malicious binary. Oops.
Correct, and only correct, answer: leave sshd on 22 and get your squishy services off the public Internet or rotate the logs faster. You are a sysadmin with grep and awk. Deal with failures in your log. They are there for a reason, especially if you are exposing sshd to the Internet, and pulling netfilter in or moving ports around is silly TSA-level security theater.
This is all promulgated by those "do these ten things first when you install Ubuntu" guides which capitalize on folks not knowing any better to identify (often faulty) opinion. If you followed one lately it's probably steered you wrong, much like those Learn Sushi Preparation in 24 Hours books. Take the time to understand the problem if you're going to operate services on the Internet and get away from guides. (And yes, I am indicting you for writing one, iff yours includes anything discussed in this comment. Sorry.)
Knocking is the only truly plausible, though still silly, security idea here but even that betrays itself in an nmap by nature of TCP. Also, hope you don't forget your knock when your machine is on fire. (You will.)
It's too bad I'm on the right side of ethical these days or I'd patch all the common SSH scanners to try every port so people will stop doing stuff like this. Some already do.
[0]: https://github.com/fail2ban/fail2ban/pull/1410
Thank you for saving at least me from having to argue this viewpoint again, as I have done in the past:
https://news.ycombinator.com/item?id=6617312
https://news.ycombinator.com/item?id=6482192
You did it even better than I did, I think.
https://news.ycombinator.com/item?id=6617312
https://news.ycombinator.com/item?id=6482192
You did it even better than I did, I think.
It's weird that even right-thinking engineers will vehemently argue against just being a lemming on any number of issues, but all it takes is a few "move SSH port to clean up your logs and install fail2ban" guides and here we are.
This really hits people who dabble in operations with a personal server or something. It's probably a failure of operations folks like me to properly reach developers and other groups who simply toy with our dark arts in the pursuit of getting something done. Operating on the Internet is capital H Hazardous, and simply buying a guide wholesale without understanding it even more so.
I am identifying a need.
This really hits people who dabble in operations with a personal server or something. It's probably a failure of operations folks like me to properly reach developers and other groups who simply toy with our dark arts in the pursuit of getting something done. Operating on the Internet is capital H Hazardous, and simply buying a guide wholesale without understanding it even more so.
I am identifying a need.
The problem is that people get unnerved by the log entries showing unsuccessful logins. They get a knee-jerk reaction and the first thing they think of (which will work) is to change the SSH port. What should have stopped them is the feeling that they are now disobeying the internet standards, and the standardized ports are probably standardized for a reason. It’s the same reason anyone should feel a mental pain when considering any quick-and-dirty method of fixing a problem – it is dirty, and will have repercussions.
(The same phenomenon, knee-jerk reactions, could be seen starting in the mid-90s when everybody and their dog had a Solution™ to the e-mail spam problem, leading to canned rebuttals like this: http://craphound.com/spamsolutions.txt)
The proper solution for SSH is probably for the OpenSSH authors to change OpenSSH to no longer log unsuccessful logins (at least by default). If there’s a successful login, the log entry might add how many previous unsuccesful logins there had been within the previous few minutes, but I see no reason at all to log unsuccessful login attempts anymore. The current logging defaults were normal for its time when the code was written, when the internet was very different, but today they are simply scaring people for no reason.
(The same phenomenon, knee-jerk reactions, could be seen starting in the mid-90s when everybody and their dog had a Solution™ to the e-mail spam problem, leading to canned rebuttals like this: http://craphound.com/spamsolutions.txt)
The proper solution for SSH is probably for the OpenSSH authors to change OpenSSH to no longer log unsuccessful logins (at least by default). If there’s a successful login, the log entry might add how many previous unsuccesful logins there had been within the previous few minutes, but I see no reason at all to log unsuccessful login attempts anymore. The current logging defaults were normal for its time when the code was written, when the internet was very different, but today they are simply scaring people for no reason.
Hmmm ... wouldn't it be possible to use a distrubuted portscanner to find the current port? Or simply DDOS the switch that the box is attached to? Or the router? Or another downstream connection point?
While I love the ingenuity of the OP's software, I'd have to agree with their own assessment on the Github page "Beware, currently I would not really recommend running this software, it was only written as a joke."
While I love the ingenuity of the OP's software, I'd have to agree with their own assessment on the Github page "Beware, currently I would not really recommend running this software, it was only written as a joke."
Needing distributed port scanner adds a huge barrier to entry over that needed for a simple ssh brute force script. Not to mention that once you find the port you have at most 30s to brute force it before it moves again...
Not so huge.
So ultimately, this offers about the same protection against a dedicated attacker that just hosting it on a non-standard port does, with the disadvantage of any clock drift making it much harder to access your own machine.
nc -z <host ip> 0-65535
So ultimately, this offers about the same protection against a dedicated attacker that just hosting it on a non-standard port does, with the disadvantage of any clock drift making it much harder to access your own machine.
I would install it, but there is not the usual "wget https:// ... | bash" setup...
I don't understand why this is seen as acceptable, yet port knocking is derided every time it's brought up.
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.
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.
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).
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).
Correct me if I am wrong here, but would the following changes to SSH give you the same result:
Change protocol from TCP to UPD and port from 22 to 62201.
Remove greeting.
If first message is not the correct password, do not send a reply.
If everyone used this, do you think SSH would become more secure and eliminate password scanners? Personally I think that if ssh took in a fwknopd patch and used that as default, any benefit you see now would disappear. I also suspect that logging every UDP package to 62201 would be a bad idea, probably worse than logging every failed attempt on TCP port 22.
Change protocol from TCP to UPD and port from 22 to 62201.
Remove greeting.
If first message is not the correct password, do not send a reply.
If everyone used this, do you think SSH would become more secure and eliminate password scanners? Personally I think that if ssh took in a fwknopd patch and used that as default, any benefit you see now would disappear. I also suspect that logging every UDP package to 62201 would be a bad idea, probably worse than logging every failed attempt on TCP port 22.
Ssh does a fingerprint verification and establishes a secure channel before it does the password exchange. Avoiding replay attacks can be a challeng as well. Putting strong authentication in a single packet is deceptively nontrivial. It can be done, but at that point you'd be reimplementing Fwknopd. Additionally, Fwknop can protect more than just ssh, and do fancy things like providing access to a machine without a public IP address.
Disclaimer: I'm one of the Fwknop devs. =)
Disclaimer: I'm one of the Fwknop devs. =)
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.
They make the valid criticism of the first case while you argue the second and somehow the arguments miss in the middle.
If you do not have the ability to eavesdrop on the network between my client and my server, then port knocking is essentially unhackable. Port knocking only fails when the malicious party can monitor the network traffic. This is a valid concern, and I would never say that port knocking by itself is all the security one needs. It does however completely block all regular "outsiders" from ever being able to even open a connection to sshd.
If I require 5 ports to be hit in sequence, and blacklist IPs that hit unknown ports, it is extremely unlikely you will ever connect. Now if someone on my local network, at my ISP, or at my hosting provider sniffs my traffic to determine a static knocking sequence... good for them. They're the one unauthorized person who can connect to sshd, without a valid ssh key to authenticate with.
It's a reality that most businesses are not going to invest in setting up a network that cannot be accessed from the internet at large. For such setups, a little bit of obscurity via something like port knocking to prevent every single port scanner in existence from discovering your sshd server must be better than nothing at all.
If I require 5 ports to be hit in sequence, and blacklist IPs that hit unknown ports, it is extremely unlikely you will ever connect. Now if someone on my local network, at my ISP, or at my hosting provider sniffs my traffic to determine a static knocking sequence... good for them. They're the one unauthorized person who can connect to sshd, without a valid ssh key to authenticate with.
It's a reality that most businesses are not going to invest in setting up a network that cannot be accessed from the internet at large. For such setups, a little bit of obscurity via something like port knocking to prevent every single port scanner in existence from discovering your sshd server must be better than nothing at all.
> blacklist IPs that hit unknown ports
so what happens when someone hits an unknown port on your system from every IP on the internet?
so what happens when someone hits an unknown port on your system from every IP on the internet?
You reject all packets from "bad IPs" for a period of time. 5 minutes, 30 minutes, whatever. If you're in a position to spoof IPs and you manage to spoof one I need to connect from (or I make a mistake and get myself blacklisted), it's a temporary inconvenience.
That, and having out-of-band access to the server always helps. ;)
That, and having out-of-band access to the server always helps. ;)
How does that not add security? If you use a secret token or some authenticated website for opening the port how can an attacker easily circumvent this?
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.
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.
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.
Mandatory xkcd: https://xkcd.com/927/
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/
I dislike Go as well, but it does compile to a static binary, so you shouldn't need to install any runtime at all.
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..
(Just curious)
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)
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...
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...
There is an existing solution to give you this protection, it's called port knocking.
<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.
[deleted]
This is a very bad idea.
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?
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.
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.
> The other says, that's stupid, you'll never out run a grizzly bear.
(For those who don't know the punchline of this is "I don't have to outrun the bear I just have to outrun you")
(For those who don't know the punchline of this is "I don't have to outrun the bear I just have to outrun you")
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.
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.
I didn't think he meant getting the password which won't do you any good without the private key. I thought he meant getting the last 2 digits so you could start recording a pattern and eventually determine the 2FA key.
Can't a scan like that be detected by a simple firewall?
A far more secure approach: http://www.daemonology.net/blog/2012-08-30-protecting-sshd-u...
All of these port knocking folks who talk about logs getting full.... quit logging the rejected connections.
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 ?
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 ?
Reminds me of "port knocking", a similar form of security through obscurity.
Still, this stuff is useful just to thin out all the crap coming in from botnets.
Still, this stuff is useful just to thin out all the crap coming in from botnets.
So, this is http://shimmer.sourceforge.net/ rewritten in go?
I just set the port to something > 10000 and configure it to use public key authentication only.
Isn't it safer to keep the ssh port below 1024 so that another user other than root can't start a listener on that port?
They can only do that if the ssh daemon isn't already listening on the port, i.e. it has crashed or is not running.
Yeah, me too! I would not call this security by obscurity because it actually helps making the auth logfile more readable ;-)
This is also an interesting idea:
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:
---- (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:
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:
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
---- (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:
ufw limit ssh/tcp> On high security servers forcing the users to use public key authentication is another way to stop guessing.
Public key and IP limiting is standard practice, eliminating passwords should be top priority for anyone running SSH servers.
Public key and IP limiting is standard practice, eliminating passwords should be top priority for anyone running SSH servers.