5 ms·

Out of interest, has anyone else who's had their personal server mentioned on HN's frontpage noticed an uptick in SSH scans from those lovely folks in the PRC?

• rhizome 14y ago
  Unless you're a service provider who supplies SSH access to generic customers, there's no reason to continue running sshd on port 22. Use some other port and your random scans will drop by ~100%.
  • zokier 14y ago
    Those scans/bruteforce attempts are mostly harmless anyways, so there is very little benefit in changing the port. Has there been yet a single drive-by 0day attack against opensshd, because that's essentially the only thing the port change would help against.
    • rhizome 14y ago
      The benefit in changing the port is that if you do reporting/logging of these things, the potentially-harmful scans aren't hidden under a morass of benign dictionary attacks.
      • StavrosK 14y ago
        This is unrelated, but I keep getting emails from my home server every two weeks or so that someone made three incorrect sudo attempt to run "sudo sh /tmp/somefile". There's nobody logged in via SSH, I have key-only author anyway, and the user who's trying to do this is apparently me. It doesn't originate in a console, and the only thing running as me is the Dropbox daemon. Anyone have any idea what's going on, and if I should be worried?
        • jlgreco 14y ago
          Does the file exist? I've never heard of dropboxd doing anything like that. My inclination would be to nuke the box.
          • StavrosK 14y ago
            It doesn't, by the time I log in. It's a freshly installed server, too...
        • batgaijin 14y ago
          you should blog about this... create a unique user and write about it.
      • fluffle 14y ago
        Dictionary attacks are by definition not benign. If a compromised host is sending any packets your way, it's best to drop them on the floor where they belong. Then, if for any reason, the person controlling that other host happens to e.g. run portscans to find other services or point nessus / metasploit your way, they are going to have a much harder time of doing so.
    • diakritikal 14y ago
      Mostly harmless, but not always. This was a rather large humdinger on the part of Debian: http://www.debian.org/security/2008/dsa-1571 http://www.debian.org/security/2008/dsa-1571
• oofabz 14y ago
  Install fail2ban to protect against these scans. With its default settings, it will ban an IP for ten minutes if it fails to login six times. That doesn't inconvenience real users but it makes it impractical to brute-force a password. It's probably available from your distribution's package repository.
  • charliesome 14y ago
    It's already impossible to brute force a password if it's of a decent length
    • dsl 14y ago
      Your statement is absolutely false. Any password of any length can be brute forced.
• daemon13 14y ago
  There are several ways to deal with it. Basic: 1. SSH - security related - modify sshd config - no password auth, only key based, no root login, other than that the default sshd config for Ubuntu 12.04 is pretty ok. PermitRootLogin no If you do not use IPv6, you can disable sshd to use it. #ListenAddress :: ListenAddress 0.0.0.0 2. SSH - ease of maintenance related - change default port from 22 to smth else. This will not help against targeted attacks, but this will reduce the noise in the logs and will allow better visibility of attack attempts. #Port 22 Port 63777 (or whatever) Don't forget to reload ssh for changes to take effect and check with netstat what's running where. If you are concerned with getting locked out you can do this: 2.1. enable sshd to listen on multiple ports simultaneously Port 22 Port 63777 (or whatever) 2.2. Login through Port 63777, and only then disable Port 22. 3. The PRC thing - fail2ban and hosts is simple but not the best tools for the job. 3.1. You can disable access to your site for all China (or any other country for this matter) using ipset. Much better speed and ease of maintenance, it's even better then using iptables itself [ipset is iptables module], one set can contain/block up to 65000+ IPs. 3.2. If you want smth more targeted, then consider either sshguard or psad. They can be configured to block inline and dynamically add rules [perm/temp] to iptables. Edit: forgot to mention another cute recipe. see below If you are on AWS and are using security groups (you should), after you are done on the server, you can go to the security group in AWS Mgt Console and remove ingress for ssh ports. Now your server is accessible only on 80/443 and ssh is NOT accessible to anyone. Later, when you need to access the server - enable ingress for the ssh ports, do your job and disable again.
  • fluffle 14y ago
    Thanks to all, and especially this post, for detailed security recommendations. I hope they convince others that security is important and not to be taken lightly. I don't really think that security-by-obscurity alone is a good enough solution. I already disable both root logins and passwords on my shell, and have something that tails logs to firewall IPs that are doing nasty things that show up in my logs. It's cute that you assume I'm running Linux though ;-) I ended up firewalling the entire /14 that /24 was assigned from, because, well, China bothers me...
    • 14y ago