6 ms·

Just move your SSH off the port 22, hide it behind another instance and/or use fail2ban. 99% of problems with SSH scans/attacks sorted

by radimm 15y ago

yock 15y ago
Or just disable password-based authentication. These "attacks" are little more than log spam and are meant to prey on systems that host novice users with weakpasswords. Require PKI and the log spam goes away.
- radimm 15y ago
  sure, I hope nobody is using password based authentication for SSH anyway :)
  - pbhjpbhj 15y ago
    Is there an active exploit? Or are you just saying that this is the weakest form of auth for SSH?
    - bwarp 15y ago
      password is the weakest form of authentication on open systems i.e. ones which you have to hand over to monkey grade users. If you have a reasonable password policy yourself, I very much doubt it will cause you any problems. I've been attacked by these for 10 years, probably totalling millions of attempts and I have a user name in their databases but due to a sensible password, nothing has got in. I tend to use PKI and keyboard interactive logins though.
  - mike-cardwell 15y ago
    And I hope nobody is using key based authentication for SSH without storing the private part of their SSH key on an external smart card only, which is unlocked by an external hardware pin pad. I was being pedantic of course. Password based SSH authentication is fine for 99% of the cases, as long as they use a "secure" password and don't leak it by writing it down or reusing it elsewhere.
    - rwmj 15y ago
      No .. but it would damn cool if such hardware existed. Does it?
      - seabee 15y ago
        Not to my knowledge, but similar approaches have existed for a long time now e.g. RSA SecurID [0]. One day I'm going to set up my Yubikey to perform a similar purpose, but my motivation levels correlate with my paranoia :) [0] http://www.rsa.com/node.aspx?id=1156 http://www.rsa.com/node.aspx?id=1156
        mike-cardwell 15y ago
        I have a yubikey myself. The smart card method is much better though. When using a smart card, it is impossible even for the owner (who knows the access pin) to read the actual key. The crypto operations involved in the authentication take place on the card it's self. The smart card is protected by a pin, and will wipe it's self if the pin is entered incorrectly too many times. You can even use a smart card reader with a hardware pin pad built in so neither soft nor hard keyloggers can intercept it.
        rdl 15y ago
        The weak point is you still don't know what you're signing, who or what you're authenticating, etc. if you don't have a trusted display and do the entire transaction on trusted hardware. (your host may be compromised, and could show arbitrary data, proxy connections, etc.) Protecting the key does go a long way, but even with a secure passphrase input and smartcard key operations, there is risk. The ideal, IMO, would be some secondary hardware with a limited, secure OS which lets you put specific limits on how the key is used, showing a hash or identifying details of each transaction on the secure display, prompting you to verify each. E.g. to send a payment, the amount and payee (and date/sequence number) are shown on the secure display to verify before authorizing.
      - mike-cardwell 15y ago
SomeOtherGuy 15y ago
Or do none of those things and 100% of the above problems are still solved anyways.
roqetman 15y ago
I agree - I did this a long time ago; while it's fun to go through logs sometimes, I prefer to weed-out the general bombardment. My hits dropped from about 90 a day to 0 (after 6 months).
nvarsj 15y ago
Or better yet, don't run SSH at all. Leave it to the pros. I had an experience about a year ago on one of my home servers that convinced me of this. It was a Debian machine that I kept religiously up to date (daily cronjob and manual checking). It only had an external SSH port, I used log2ban, and disabled all logins except for one non-root user. I got the common ssh brute force spam. Then one day I happened to be checking logs, and noticed rootkit logs in the /root directory. My server had been hacked! Fortunately whoever had broken in had completely botched it and left traces all over the system. It looked like they had given up at some point, despite having root access. I later discovered that the attacker had used a 0-day openssh exploit that had been released that very morning. For that time period of 24-48 hours between release and fix, my server had been hacked. I only wonder how many other servers were hacked by skilled people that didn't leave evidence behind. So morale of the story - you can't secure anything that is publicly facing on the internet. And if you really need to do it, it requires constant vigilance, DMZs, and all that other stuff that is not worth it unless you're being paid.
- hackermom 15y ago
  In your specific case, this wouldn't have happened if your SSHd had listened to something else than port 22.
  - Florin_Andrei 15y ago
    s/wouldn't have happened/would've been much less likely/
- fjarlq 15y ago
  What exploit was it specifically?
sehugg 15y ago
You could also set up your security group such that incoming 22 is denied by default, and open it up to individual IPs on-demand using a script like this: MYIP=`curl http://automation.whatismyip.com/n09230945.asp` ec2-authorize $SECGROUP -P tcp -p 22 -s $MYIP/32

Just move your SSH off the port 22, hide it behind another instance and/or use fail2ban. 99% of problems with SSH scans/attacks sorted

by radimm 15y ago

Just move your SSH off the port 22, hide it behind another instance and/or use fail2ban. 99% of problems with SSH scans/attacks sorted

yock 15y ago

Or just disable password-based authentication. These "attacks" are little more than log spam and are meant to prey on systems that host novice users with weakpasswords. Require PKI and the log spam goes away.

radimm 15y ago
sure, I hope nobody is using password based authentication for SSH anyway :)
- pbhjpbhj 15y ago
  Is there an active exploit? Or are you just saying that this is the weakest form of auth for SSH?
  - bwarp 15y ago
    password is the weakest form of authentication on open systems i.e. ones which you have to hand over to monkey grade users. If you have a reasonable password policy yourself, I very much doubt it will cause you any problems. I've been attacked by these for 10 years, probably totalling millions of attempts and I have a user name in their databases but due to a sensible password, nothing has got in. I tend to use PKI and keyboard interactive logins though.
- mike-cardwell 15y ago
  And I hope nobody is using key based authentication for SSH without storing the private part of their SSH key on an external smart card only, which is unlocked by an external hardware pin pad. I was being pedantic of course. Password based SSH authentication is fine for 99% of the cases, as long as they use a "secure" password and don't leak it by writing it down or reusing it elsewhere.
  - rwmj 15y ago
    No .. but it would damn cool if such hardware existed. Does it?
    - seabee 15y ago
      Not to my knowledge, but similar approaches have existed for a long time now e.g. RSA SecurID [0]. One day I'm going to set up my Yubikey to perform a similar purpose, but my motivation levels correlate with my paranoia :) [0] http://www.rsa.com/node.aspx?id=1156 http://www.rsa.com/node.aspx?id=1156
      - mike-cardwell 15y ago
        I have a yubikey myself. The smart card method is much better though. When using a smart card, it is impossible even for the owner (who knows the access pin) to read the actual key. The crypto operations involved in the authentication take place on the card it's self. The smart card is protected by a pin, and will wipe it's self if the pin is entered incorrectly too many times. You can even use a smart card reader with a hardware pin pad built in so neither soft nor hard keyloggers can intercept it.
        rdl 15y ago
        The weak point is you still don't know what you're signing, who or what you're authenticating, etc. if you don't have a trusted display and do the entire transaction on trusted hardware. (your host may be compromised, and could show arbitrary data, proxy connections, etc.) Protecting the key does go a long way, but even with a secure passphrase input and smartcard key operations, there is risk. The ideal, IMO, would be some secondary hardware with a limited, secure OS which lets you put specific limits on how the key is used, showing a hash or identifying details of each transaction on the secure display, prompting you to verify each. E.g. to send a payment, the amount and payee (and date/sequence number) are shown on the secure display to verify before authorizing.
    - mike-cardwell 15y ago

SomeOtherGuy 15y ago

Or do none of those things and 100% of the above problems are still solved anyways.

roqetman 15y ago

I agree - I did this a long time ago; while it's fun to go through logs sometimes, I prefer to weed-out the general bombardment. My hits dropped from about 90 a day to 0 (after 6 months).

nvarsj 15y ago

Or better yet, don't run SSH at all. Leave it to the pros. I had an experience about a year ago on one of my home servers that convinced me of this. It was a Debian machine that I kept religiously up to date (daily cronjob and manual checking). It only had an external SSH port, I used log2ban, and disabled all logins except for one non-root user. I got the common ssh brute force spam. Then one day I happened to be checking logs, and noticed rootkit logs in the /root directory. My server had been hacked! Fortunately whoever had broken in had completely botched it and left traces all over the system. It looked like they had given up at some point, despite having root access. I later discovered that the attacker had used a 0-day openssh exploit that had been released that very morning. For that time period of 24-48 hours between release and fix, my server had been hacked. I only wonder how many other servers were hacked by skilled people that didn't leave evidence behind. So morale of the story - you can't secure anything that is publicly facing on the internet. And if you really need to do it, it requires constant vigilance, DMZs, and all that other stuff that is not worth it unless you're being paid.

hackermom 15y ago
In your specific case, this wouldn't have happened if your SSHd had listened to something else than port 22.
- Florin_Andrei 15y ago
  s/wouldn't have happened/would've been much less likely/
fjarlq 15y ago
What exploit was it specifically?

sehugg 15y ago

You could also set up your security group such that incoming 22 is denied by default, and open it up to individual IPs on-demand using a script like this: MYIP=`curl http://automation.whatismyip.com/n09230945.asp` ec2-authorize $SECGROUP -P tcp -p 22 -s $MYIP/32