5 ms·

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 equiv

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

krastanov 10y ago
But is it not true that a random port helps specifically against DoS attacks?
- jsmthrowaway 10y ago
  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 https://github.com/fail2ban/fail2ban/pull/1410
  - teddyh 10y ago
    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=6617312 https://news.ycombinator.com/item?id=6482192 https://news.ycombinator.com/item?id=6482192 You did it even better than I did, I think.
    - jsmthrowaway 10y ago
      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.
      - teddyh 10y ago
        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 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.
curried_haskell 10y ago
I trust two countermeasures over just one.
- ryanlol 10y ago
  If someone could break 4096 bit ssh keys they could scan every single TCP port on the internet in seconds.
  - jjnoakes 10y ago
    What?
    - mitchty 10y ago
      http://blog.erratasec.com/2013/09/masscan-entire-internet-in-3-minutes.html http://blog.erratasec.com/2013/09/masscan-entire-internet-in... 180 seconds is still seconds. Randomizing ports really doesn't buy much.
    - ryanlol 10y ago
      If they can break SSH keys like that, they'll easily compromise thousands of servers they can use to scale up their attack.
jlmorton 10y ago
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.

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

krastanov 10y ago

But is it not true that a random port helps specifically against DoS attacks?

jsmthrowaway 10y ago
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 https://github.com/fail2ban/fail2ban/pull/1410
- teddyh 10y ago
  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=6617312 https://news.ycombinator.com/item?id=6482192 https://news.ycombinator.com/item?id=6482192 You did it even better than I did, I think.
  - jsmthrowaway 10y ago
    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.
    - teddyh 10y ago
      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 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.

curried_haskell 10y ago

I trust two countermeasures over just one.

ryanlol 10y ago
If someone could break 4096 bit ssh keys they could scan every single TCP port on the internet in seconds.
- jjnoakes 10y ago
  What?
  - mitchty 10y ago
    http://blog.erratasec.com/2013/09/masscan-entire-internet-in-3-minutes.html http://blog.erratasec.com/2013/09/masscan-entire-internet-in... 180 seconds is still seconds. Randomizing ports really doesn't buy much.
  - ryanlol 10y ago
    If they can break SSH keys like that, they'll easily compromise thousands of servers they can use to scale up their attack.

jlmorton 10y ago

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.