Hacker News Reader

Comment by fluffle | Hacker News Reader

Hi. Err... had to create a HN account to reply, whyrusleeping on #go-nuts told me this was here.

Feel free to file issues on github and consider that the "source of truth" for my code, and please ignore my site. I don't have time to throw together a web presence, too busy at work ;-)

View on HN

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? Certainly did here.

Welp, 221.192.143.73/24 is going in the firewall config.

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

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.

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.

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?

Does the file exist?

I've never heard of dropboxd doing anything like that. My inclination would be to nuke the box.

It doesn't, by the time I log in. It's a freshly installed server, too...

you should blog about this... create a unique user and write about it.

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.

Mostly harmless, but not always. This was a rather large humdinger on the part of Debian:

http://www.debian.org/security/2008/dsa-1571

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.

It's already impossible to brute force a password if it's of a decent length

Your statement is absolutely false. Any password of any length can be brute forced.

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.

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

Good it was helpful. Have a look at ipset. It is easy to use and very powerful. According to one of the sources China is appr. 5000 IP sub-nets only. one ipset can block up to 65000+. One of the sources for IP is MaxiMind - they shall have a free set of fresh IPs.

Reply on news.ycombinator.com