6 ms·

There are lots of good guides online on how to protect yourself from this (disable password-based auth, or use 2-factor auth, Fail2ban etc.), but there's one pi

by Osmium 13y ago

There are lots of good guides online on how to protect yourself from this (disable password-based auth, or use 2-factor auth, Fail2ban etc.), but there's one piece of advice that crops up a lot that is probably a bad idea, and that's changing the SSH port. This can give (at best) a false sense of security and (at worst) actually reduce security if you choose a port number above 1024, because then malware could pose as SSH without requiring root access and then steal your password once you've entered it. Just thought it was worth mentioning because I recently went through all this myself to try and secure a Raspberry Pi and it was news to me...

erhardm 13y ago
I still think that it's a good idea to change the default port for sshd, even if you don't let root to login and use public key auth and fail2ban. Why? Because this "obscurity" helps keeping false possitives to a reasonable low number, so you can actually see if there's a tageted attack or not. If I see a auth failure "root"-"123456" I instantly know that's not a targeted attack, it will unnecessary fill my log files that will add with time and become a burden to audit my systems, which at some point I either don't do it thoroughly or any at all. SELinux takes care of controling which application could open outbound ports, so if your box is properly configured, there are other ways to reduce the impact if the box is exploited
- andrewcooke 13y ago
  do (can?) auth failures display passwords? if so, is that a good idea? people (ie me) sometimes enter the wrong, but valid password. having that logged somewhere seems like a bad idea.
  - erhardm 13y ago
    If you use public-key it only shows the ip. I don't know if you use password, 2-factor auth or Kerberos it shows any additional information. I would guess that if you enable debugging it will show some identifiable information, I never had to debug it.
  - DavidHogue 13y ago
    The standard sshd does not log failed passwords. A few years ago I was seeing a lot of brute force attempts and I was curious to see the passwords. The only way I could do it was to edit the source code of sshd to add my own logging line and recompile the whole thing.
voidlogic 13y ago
I agree that changing the port is not a great security measure in theory and I think it should be last of a large number of things a person does to secure SSH. BUT- I worked at a company a while back that had fail2ban notify us when by E-mail when it banned people. Changing the SSH ports dropped the bans per 6 month from 80-60 to 1-2. So while its certainly not the only thing you should do, there is something to be said for obscurity (in addition to existing real security of course).
- bradleyland 13y ago
  Not to mention the hardware resources. Prior to changing our SSH port, the fail2ban process was #3-5 in terms of CPU time on many of our boxes. Changing the SSH port puts it out of contention for even the top 10.
  - swinglock 13y ago
    If you must then just limit connections per minute that can be opened per address to the sshd port in the host firewall instead. Sshd should be configured to close the connection after a number of failed logins. Now you get the same effect without a daemon parsing logfiles.
    - bradleyland 13y ago
      I recently added UFW configuration to my provisioning scripts, so we now use UFW's 'limit' rules to do that on the port we use for SSH. We could probably get away with moving it back to the default with this in place.
deleted 13y ago
[deleted]
wglb 13y ago
Changing the port number can boost security if it makes it easier to scan the log for attempts. I think it is a good idea. It is the expectation that this is enough that is the bad idea.
andrewcooke 13y ago
steal your password i had always assumed that the protocol somehow protected your password, but reading the spec at http://www.ietf.org/rfc/rfc4252.txt http://www.ietf.org/rfc/rfc4252.txt that's not the case (and i've pretty much convinced myself it's not possible to do better). learn something new every day... [apart from the reference above, someone else here claims to be logging these things.]
- Osmium 13y ago
  Huh. I hadn't actually thought that the protocol itself could protect you (I only left my comment based on what I'd read elsewhere; I don't know anything about it otherwise). So hypothetically speaking, if the protocol did protect your password from being stolen, what would be the actual threat of a piece of malware specifically pretending to be SSH?
  - sp332 13y ago
    If you use "sudo foo" in the remote shell, and then type your password, it could steal that. Or even if you somehow obfuscated your sudo password, it could change the command presented to sudo, so after you type your password, the new substituted command would be executed. Exaple: you type "sudo less /var/log/messages" but the fake-ssh tells the remote shell that you really typed "sudo email-me-all-your-data". Then the real sudo authenticates you, and executes the command you didn't type.
- Hello71 13y ago
  With "password" authentication method, the password is not transmitted to the remote server. (AFAIK) However, all modern sshds (AFAIK, at least OpenSSH) default to (publickey, keyboard-interactive). As the name says, keyboard-interactive sends your keystrokes, one at a time (bar buffering) to the remote server. This is required, for example, when using PAM, as PAM requires the actual authentication key.
  - deleted 13y ago
    [deleted]
  - 13y ago
Father 13y ago
Additionally you could also use something like fwknop[1]. It opens the ssh port for your ip when you need it and closes it after a preset time has passed. [1]http://www.cipherdyne.org/fwknop/docs/faq.html#fwknop http://www.cipherdyne.org/fwknop/docs/faq.html#fwknop
JshWright 13y ago
Changing the port is still a worthwhile thing to do in many cases. Military tanks aren't painted green because green paint is more bulletproof, they use green because hot pink tanks get shot at more. Changing the port isn't armor, it's camouflage. Camouflage is still a useful thing. Your point about not using a port north of 1024 is solid advice.
antocv 13y ago
> above port 1024 malware... Im using this https://github.com/stealth/sshttp https://github.com/stealth/sshttp to run it on port 443. The other port it actually runs on is firewalled off from outside.

by Osmium 13y ago

erhardm 13y ago

I still think that it's a good idea to change the default port for sshd, even if you don't let root to login and use public key auth and fail2ban. Why? Because this "obscurity" helps keeping false possitives to a reasonable low number, so you can actually see if there's a tageted attack or not. If I see a auth failure "root"-"123456" I instantly know that's not a targeted attack, it will unnecessary fill my log files that will add with time and become a burden to audit my systems, which at some point I either don't do it thoroughly or any at all. SELinux takes care of controling which application could open outbound ports, so if your box is properly configured, there are other ways to reduce the impact if the box is exploited

andrewcooke 13y ago
do (can?) auth failures display passwords? if so, is that a good idea? people (ie me) sometimes enter the wrong, but valid password. having that logged somewhere seems like a bad idea.
- erhardm 13y ago
  If you use public-key it only shows the ip. I don't know if you use password, 2-factor auth or Kerberos it shows any additional information. I would guess that if you enable debugging it will show some identifiable information, I never had to debug it.
- DavidHogue 13y ago
  The standard sshd does not log failed passwords. A few years ago I was seeing a lot of brute force attempts and I was curious to see the passwords. The only way I could do it was to edit the source code of sshd to add my own logging line and recompile the whole thing.

voidlogic 13y ago

I agree that changing the port is not a great security measure in theory and I think it should be last of a large number of things a person does to secure SSH. BUT- I worked at a company a while back that had fail2ban notify us when by E-mail when it banned people. Changing the SSH ports dropped the bans per 6 month from 80-60 to 1-2. So while its certainly not the only thing you should do, there is something to be said for obscurity (in addition to existing real security of course).

bradleyland 13y ago
Not to mention the hardware resources. Prior to changing our SSH port, the fail2ban process was #3-5 in terms of CPU time on many of our boxes. Changing the SSH port puts it out of contention for even the top 10.
- swinglock 13y ago
  If you must then just limit connections per minute that can be opened per address to the sshd port in the host firewall instead. Sshd should be configured to close the connection after a number of failed logins. Now you get the same effect without a daemon parsing logfiles.
  - bradleyland 13y ago
    I recently added UFW configuration to my provisioning scripts, so we now use UFW's 'limit' rules to do that on the port we use for SSH. We could probably get away with moving it back to the default with this in place.

deleted 13y ago

[deleted]

wglb 13y ago

Changing the port number can boost security if it makes it easier to scan the log for attempts. I think it is a good idea. It is the expectation that this is enough that is the bad idea.

andrewcooke 13y ago

steal your password i had always assumed that the protocol somehow protected your password, but reading the spec at http://www.ietf.org/rfc/rfc4252.txt http://www.ietf.org/rfc/rfc4252.txt that's not the case (and i've pretty much convinced myself it's not possible to do better). learn something new every day... [apart from the reference above, someone else here claims to be logging these things.]

Osmium 13y ago
Huh. I hadn't actually thought that the protocol itself could protect you (I only left my comment based on what I'd read elsewhere; I don't know anything about it otherwise). So hypothetically speaking, if the protocol did protect your password from being stolen, what would be the actual threat of a piece of malware specifically pretending to be SSH?
- sp332 13y ago
  If you use "sudo foo" in the remote shell, and then type your password, it could steal that. Or even if you somehow obfuscated your sudo password, it could change the command presented to sudo, so after you type your password, the new substituted command would be executed. Exaple: you type "sudo less /var/log/messages" but the fake-ssh tells the remote shell that you really typed "sudo email-me-all-your-data". Then the real sudo authenticates you, and executes the command you didn't type.
Hello71 13y ago
With "password" authentication method, the password is not transmitted to the remote server. (AFAIK) However, all modern sshds (AFAIK, at least OpenSSH) default to (publickey, keyboard-interactive). As the name says, keyboard-interactive sends your keystrokes, one at a time (bar buffering) to the remote server. This is required, for example, when using PAM, as PAM requires the actual authentication key.
- deleted 13y ago
  [deleted]
- 13y ago

Father 13y ago

Additionally you could also use something like fwknop[1]. It opens the ssh port for your ip when you need it and closes it after a preset time has passed. [1]http://www.cipherdyne.org/fwknop/docs/faq.html#fwknop http://www.cipherdyne.org/fwknop/docs/faq.html#fwknop

JshWright 13y ago

Changing the port is still a worthwhile thing to do in many cases. Military tanks aren't painted green because green paint is more bulletproof, they use green because hot pink tanks get shot at more. Changing the port isn't armor, it's camouflage. Camouflage is still a useful thing. Your point about not using a port north of 1024 is solid advice.

antocv 13y ago

> above port 1024 malware... Im using this https://github.com/stealth/sshttp https://github.com/stealth/sshttp to run it on port 443. The other port it actually runs on is firewalled off from outside.