5 ms·

Lots of questionable advice here (/dev/shm, fail2ban, PermitRootLogin no, "sysctl hardening") with little explanation and glaring omissions (SSH-port left uncha

by moe 14y ago

Lots of questionable advice here (/dev/shm, fail2ban, PermitRootLogin no, "sysctl hardening") with little explanation and glaring omissions (SSH-port left unchanged, no check for listening services, no pointer to an iptables-wrapper). None of the bullets seems immediately harmful security-wise, but many of them have the potential to break legitimate applications or lock you out of your host. If you intend to follow this guide then make sure you fully understand each step before applying it.

iuguy 14y ago
To be fair, the value of changing SSH ports versus using only public key authentication is somewhat debatable. The pros always come down to eliminating noise from automated attacks. The cons always come down to having to specify a non-standard port to clients. If you only support public key based authentication, then I'd argue there's little to gain by moving ports.
- pekk 14y ago
  Doesn't reducing log noise from automated attacks improve your ability to see significant events in the log? And why would it be hard to use a non-standard port?
  - count 14y ago
    It did, and probably still does to a lesser extent. It doesn't cost any real time or effort to scan most port ranges these days - especially with EC2 and other big cloud vendors and super fast multi-gigabit network connections.
- moe 14y ago
  the value of changing SSH ports versus using only public key authentication is somewhat debatable. No, there never was a debate. The two changes address different concerns and you should always do both. You turn off password authentication to prevent targeted brute force attacks, keyloggers and (more common) accidents such as typing your password into the shell. You change the SSH-port to improve your odds in case of a vulnerability in the SSH-daemon itself (sweep-scans tend to probe only the default port).
  - druiid 14y ago
    I would say that is incorrect. A well versed attacker is going to have absolutely no issue finding your 'new' SSH port. Why do you think this is a security measure? As for shared keys... they also have their drawbacks. Someone can forget their shared key in the wrong place and suddenly you have an extremely easy entry-point into perhaps EVERY single server in an environment. Use shared keys like you would salt, sparingly and with lots of care and knowledge of how to use it.
    - moe 14y ago
      attacker is going to have absolutely no issue finding your 'new' SSH port. As I wrote in my initial comment: It's not about targeted attacks, it's about evading netblock scans. Use shared keys like you would salt, sparingly and with lots of care and knowledge of how to use it. Bullshit. Use one password-protected keypair for each critical zone (work, personal, etc.). Keep it on your main machine and do not copy it to "places". Also don't spread FUD on public forums about the most secure ssh auth-option (short of multi-factor).
      - druiid 14y ago
        Excuse me, what? FUD? I wasn't spreading FUD, I was saying that people overuse shared keys and end up putting themselves in situations where they are open to easy exploitation if they don't use them right. People will generate a key and the put it on their dev machine, backup machines and similar all which are generally less secure than production devices. Someone figures out a way in and boom. How is this FUD? It happens in real-world usage when people don't take the time to consider how they should be properly using shared keys.
        moe 14y ago
        people overuse shared keys This is not a drawback of key-based authentication versus passwords because you have the exact same problem with passwords. If you want to explain proper key-management then explain it. But don't make it sound as if key-auth was some esoteric option that should be carefully considered versus password auth. Key auth should always be the default and password auth should always be disabled, exceptions to this rule are very rare.

by moe 14y ago

iuguy 14y ago

To be fair, the value of changing SSH ports versus using only public key authentication is somewhat debatable. The pros always come down to eliminating noise from automated attacks. The cons always come down to having to specify a non-standard port to clients. If you only support public key based authentication, then I'd argue there's little to gain by moving ports.

pekk 14y ago
Doesn't reducing log noise from automated attacks improve your ability to see significant events in the log? And why would it be hard to use a non-standard port?
- count 14y ago
  It did, and probably still does to a lesser extent. It doesn't cost any real time or effort to scan most port ranges these days - especially with EC2 and other big cloud vendors and super fast multi-gigabit network connections.
moe 14y ago
the value of changing SSH ports versus using only public key authentication is somewhat debatable. No, there never was a debate. The two changes address different concerns and you should always do both. You turn off password authentication to prevent targeted brute force attacks, keyloggers and (more common) accidents such as typing your password into the shell. You change the SSH-port to improve your odds in case of a vulnerability in the SSH-daemon itself (sweep-scans tend to probe only the default port).
- druiid 14y ago
  I would say that is incorrect. A well versed attacker is going to have absolutely no issue finding your 'new' SSH port. Why do you think this is a security measure? As for shared keys... they also have their drawbacks. Someone can forget their shared key in the wrong place and suddenly you have an extremely easy entry-point into perhaps EVERY single server in an environment. Use shared keys like you would salt, sparingly and with lots of care and knowledge of how to use it.
  - moe 14y ago
    attacker is going to have absolutely no issue finding your 'new' SSH port. As I wrote in my initial comment: It's not about targeted attacks, it's about evading netblock scans. Use shared keys like you would salt, sparingly and with lots of care and knowledge of how to use it. Bullshit. Use one password-protected keypair for each critical zone (work, personal, etc.). Keep it on your main machine and do not copy it to "places". Also don't spread FUD on public forums about the most secure ssh auth-option (short of multi-factor).
    - druiid 14y ago
      Excuse me, what? FUD? I wasn't spreading FUD, I was saying that people overuse shared keys and end up putting themselves in situations where they are open to easy exploitation if they don't use them right. People will generate a key and the put it on their dev machine, backup machines and similar all which are generally less secure than production devices. Someone figures out a way in and boom. How is this FUD? It happens in real-world usage when people don't take the time to consider how they should be properly using shared keys.
      - moe 14y ago
        people overuse shared keys This is not a drawback of key-based authentication versus passwords because you have the exact same problem with passwords. If you want to explain proper key-management then explain it. But don't make it sound as if key-auth was some esoteric option that should be carefully considered versus password auth. Key auth should always be the default and password auth should always be disabled, exceptions to this rule are very rare.