1

I'm getting these quite frequently in my /var/log/secure.log:

Nov  5 10:50:49 www sshd[775]: reverse mapping checking getaddrinfo for 124.107.32.54.pldt.net [124.107.32.54] failed - POSSIBLE BREAK-IN ATTEMPT!
Nov  5 10:50:49 www sshd[775]: Invalid user weber from 124.107.32.54
Nov  5 10:51:18 www sshd[802]: Invalid user weblogic from 66.178.48.196
Nov  5 10:51:56 www sshd[826]: reverse mapping checking getaddrinfo for gw-baneasa-v422.comtelnetworks.eu [193.230.208.98] failed - POSSIBLE BREAK-IN ATTEMPT!
Nov  5 10:51:56 www sshd[826]: Invalid user webmail from 193.230.208.98
Nov  5 10:52:22 www sshd[860]: Invalid user webmail from 150.214.102.129
Nov  5 10:53:29 www sshd[905]: Invalid user webmaster from 195.205.203.6
Nov  5 10:53:57 www sshd[928]: Invalid user webmaster from 86.101.90.21
Nov  5 10:54:29 www sshd[943]: Invalid user webservd from 151.118.130.225

I've disabled all forms of SSH authentication except for publickey so I don't think they'll find a way in. But should I be more worried about this?

  • Is there a way I can prevent this from happening or is my website just now becoming popular?
  • Can I setup a firewall on the server to block failed login attempts? The attack appears to be distributed; each attempt is coming from a different IP.
1
  • I don't believe you're actually getting a brute force attempt. From the looks of it, you just have an automated "default user/pass" hitting you.
    – sclarson
    Nov 5, 2009 at 21:44

8 Answers 8

3

A nice alternative to moving your SSH port is to use something like Blockhosts. It's a python script that scans your log files (usually /var/log/auth.log) for these kinds of things, and puts dynamic entries into /etc/hosts.allow to block people doing brute force scanning. I use it to good effect on my SSH and vsftpd installs to blacklist people after 5 incorrect passwords in a row.

1
  • I hadn't ran across that before. I'll definitely mark that as a utility I should look into.
    – sclarson
    Nov 5, 2009 at 21:41
2

As already pointed out it is only an automated scan, it tries a dictionary attach against a well known (to the attacker of course) kind of target.

As a noisy reduction technique you can change the SSHD port on your server, you can achieve this goal in a very simple way following the instruction I gave to an other question on SF.

NOTE: This approach has nothing to do with real security (as everyone knows that security through obscurity is not security at all), but can help in keep script kiddies away, and your syslog will thank you :)

EDIT:

  • An alternative implementation of the blacklisting approach can be achieved using real time public SSH Brute Force Black Lists, such as sshbl.org.

  • An alternative for local BL approach is instead the good BFD (Brute Force Detection)

2

You may also want to consider using fail2ban.

1

Restricting your authentication method to publickey is a great start. Using a log scanner Denyhosts or Blockhosts (as Graeme said) will help protect against repeated attempts from the same address. Denyhosts has an optional shared database which lets you block addresses other people have seen.

Along with restricting the authentication method, the best solution I've found is to move SSH to a different port. Scans seem to be focused on port 22. After moving away from that port the attempts on each of my servers has dropped to nil.

1
  • Moving SSH to another port is a very good idea.
    – Huntrods
    Nov 5, 2009 at 21:09
0

If you have ssh turned on that will make your machine look like an interesting target, as it is most likely a server and therefore worthwhile to hack into from the point of view of the hacker.

You can do security by obscurity and move your ssh port. You can do this on the machine with this hint http://www.macosxhints.com/article.php?story=20050707140439980 which does work on 10.5 also. I have not done it on 10.6, but I know of no reason why it wouldn't work there as well.

You could also do this on a firewall to translate an external request for a different port to forward to 22 on this machine. This is just a different method of security by obscurity.

You can disable ssh from the outside and use a VPN only to get in. From a security standpoint this is the strongest choice.

In any event, be sure you have a strong password. If you have a strong password they won't get in, but left on the default port there is the potential for a mini denial of service attack by overwhelming the machine with authentication requests, or at least a bit of a loss of performance.

You'll notice that they are pretty much just trying all sorts of logins alphabetically. Another layer of security is to have a non standard login name. You can bet they are going to try admin and root for example.

I also like to disable the older, less secure ssh1 protocol: http://www.macosxhints.com/article.php?story=2005021023215253

7
  • In response to sparks answer above: Security by obscurity is perfectly valid in addition to good practices. Moving the port has completely put a stop to this issue on my home machine. Limiting the firewall to specific IPs may not be feasible for the OP if he desires the ability to make an emergency remote connection from anywhere (like their phone) or does not have the budget or inclination to set up a VPN.
    – ridogi
    Nov 5, 2009 at 19:45
  • note that changing the ssh port in the way given by the article you cite is a very very tricky way. See my answer for an explanation.
    – drAlberT
    Nov 5, 2009 at 19:55
  • It is quick - you only have to edit 2 files. I haven't run into a single problem from doing this.
    – ridogi
    Nov 5, 2009 at 20:07
  • /etc/services is a system and standard file. It shows "standard ports associated to standard services", so changing the port of a given service could break an app that would rely on a milestone file adding a custom service name to one file mentioning those being standard is ugly too. Why do not modify one, the right one, file instead? ;)
    – drAlberT
    Nov 5, 2009 at 20:24
  • I'll give your solution a shot as I'm interested to learn it. The solution in the link I sent doesn't change the ssh port in that file, it just lists a new custom port, which sshd is then directed to via the same file you are modifying. What scenario does your solution deal with better than the one from the link I posted? An OS update that modifies /etc/services?
    – ridogi
    Nov 5, 2009 at 21:28
0

You have port 22 exposed to the world. You can either use the OSX firewall features built in to narrow the IPs which can access your machine, or you can place some sort of firewall device/server in front of your network and require people to connect to that(typically via VPN) before connecting to your server(s).

I personally would not bother changing the port of SSH. Security by obscurity is a myth. Port scanners can easily find out what type of service is running on a non-standard port and making environments non-standard can cause issues with vendors or more annoyingly add even more things to make sure all newly hired people know to do. It just adds more things to document and ensure are standardized.

1
  • Not to mention, most company networks I've seen block most outbound ports for users except for a few common ones like 22, 80 and 443. Switching to another port (unless you chose 80 or 443 ;) might make it impossible to connect from many limited networks in the world... Nov 6, 2009 at 12:58
0

Don't worry about it. It's an automated scan, you just won the coin toss this time.

0

Is good to know, I think Blockhosts is a better alternative for SSH

Daniela, Baneasa

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .