Fail2ban issue

Doesn't surprise me. Those are probably automated brute-force attacks – in other words, people from those two IP addresses have their computers in auto-pilot trying to guess your root password. That sort of thing happens all the time, and they usually target any machine they can find which exposes ssh to the public.

One thing you can do is change the port ssh runs on. Since most attackers normally expect ssh on port 22, and since many are too lazy to run nmap (or similar) to identify what services are actually running on your open ports, that will greatly reduce log spam. You can even set it to something like 8080, which many corporate/institutional firewalls allow (it's a common alternate port for web browsing), and use as a means of proxying stuff that you need that may be blocked (careful doing that! many places will take issue).

You might want to see if you can do an rDNS lookup (Google can help you find a lookup service). The reason being that those IP addresses could belong to legitimate networks that got hacked. If they appear legit, it wouldn't hurt sending them an email to alert them so they can deal with it accordingly.

@jgjh151:

Logwatch email mentioned this:

pam_unix
sshd: 
  Authentication Failures: 
     root (185.9.159.140): 480 Time(s) 
     root (219.235.126.174): 35 Time(s) 
  Invalid Users: 
     Unknown Account: 3 Time(s) 

With fail2ban, should 480 failures ever happen? Should 35 failures even happen?

Perhaps the attempts were spread out through the day? I'm not sure how the fail2ban threshold is set, but OSSEC will recognize and block those attacks after a few attempts. If the IP is the same, the repeat offenders option will add to the block time if they come back.

Sednet's often repeated turbo guide to SSH:

Setup SSH to use keypairs and disable all password authentication. Then you are immune to password guessing attempts. The only time you should use password authentication on an Internet connected machine is as a second authentication method should you use OpenSSH 6.2 double authentication. Most likely you will never do that.

Setup verbose logging so you log the key fingerprint of connections.

Enable privilege separation.

Disable everything you don't use, like kerberos and host based authentication.

Every so often check your authorized_keys files only contain correct and current keys.

Force keys to a source IP if practical.

Use forced commands with keys if practical.

Disable tunneling and X forwarding on keys where this isn't needed.

Moving the SSH port will reduce log spam but it has no security implications.

Use a strong passphrase and change your keypair if there is any doubt about it being leaked.

If you want to rate limit SSH connections do it with iptables. Kernel level network filtering has far lower overhead than fail2ban and is less likely to go wrong. Fail2ban might make some sense if it's protecting a web framework with suspected security issues but it really doesn't make much sense protecting an uberparanoid service like SSH.

What Sednet said.

Plus, the best way (along with only accepting certs instead of passwords) is to use IPTABLES and ONLY allow trusted IP's to connect to your not-TCP22 SSH port.

But….but…Skippy - what if I'm skiing on the Alps or surfing Big Sur and a clients site goes down?

Really? How often has that happened? How often will it? Besides, how often will your random IP based smart phone be able to save the day? If you just have to have that type of connection - then setup a VPN to YOUR home base, and then vpn into your system which can then SSH into your protected hosts. If you really need secure anywhere access to your public hosts - don't use SSH use a VPN.

@vonskippy:

But….but…Skippy - what if I'm skiing on the Alps or surfing Big Sur and a clients site goes down?

Really? How often has that happened?

It's happened plenty to me.

There was that time I was happily eating soft shell crab in a restaurant in Hong Kong. So what do management do? Ruin my day by calling me instead of engaging their brains and solving a dead simple issue themselves.

Or that time I was having my birthday dinner at the best restaurant in town and got the call because the active directory servers went down. All of them. Hundreds worldwide.

Or that time I was paged every 10 minutes all night with blank messages, then got moaned at the next day because I didn't fix something nobody told me about.

If you are personally expected to look after some systems it's always worth having some way into them with you. Smartphones work great but laptops are easier for serious typing. Bouncing connections though another system is fine as long as it's tested before you need it.

Thanks everyone. Password authentication has been disabled. Now I have to look into implementing some of these tips.

X forwarding and the ssh port are set in the same sshd_config you used to disable password authentication. Some distros include a command call chkconfig that you can use to disable services at boot time (though you'll still need to stop them manually if you don't want to reboot).

As for the other tips, those more experienced than me will need to help.

Logwatch has this today. If fail2bam is working, this should not be happening right?
> SSHD

Illegal users from:

undef: 750 times

190.82.84.203 (mail.elmostrador.cl): 747 times

I put in a rate limit of 3 connecitons per minute in iptables to avoid this…I'll check logs tomorrow.

Still seeing this even with fail2ban and iptables rate limiting:

SSHD

Illegal users from: 
  undef: 215 times 
  61.155.177.58: 190 times 

and

SSHD

Received disconnect: 
  11: Bye Bye [preauth] : 704 Time(s) 

What do your actual logs say? logwatch eliminates the vast majority of useful information.

@jgjh151:

Still seeing this even with fail2ban and iptables rate limiting:

SSHD

Received disconnect:

11: Bye Bye [preauth] : 704 Time(s)

Did you start fail2ban? Are you getting any log entries in /var/log/fail2ban? The linode instructions don't mention starting up the service, but it needs doing. There's presumably a right way to start it, but I just rebooted and that knocked down the many hundreds of login attempts per day to almost nothing.

@allyn:

Did you start fail2ban? Are you getting any log entries in /var/log/fail2ban? The linode instructions don't mention starting up the service, but it needs doing. There's presumably a right way to start it, but I just rebooted and that knocked down the many hundreds of login attempts per day to almost nothing.

Pretty sure it is running, just restarted it to confirm…

Checked the fail2ban log and see some items like this after restarting the service for each section in my local conf[ (ssh, postfix, dovecot, nginx…):

iptables -F fail2ban-default
iptables -X fail2ban-default returned 100
2013-08-10 09:48:26,797 fail2ban.jail   : INFO   Jail 'ssh' stopped
2013-08-10 09:48:27,053 fail2ban.actions.action: ERROR  iptables -D INPUT -p tcp -m multiport --dports http,https -j fail2ban

Are you, perchance, using the recent 3.9 kernels that Linode offers to you by default and some old-ish distro like Debian 6?

One of my servers went down for a bit because after a reboot it picked up a new kernel, which refused to cooperate with older iptables binaries.

In my case, the rule to "drop all other packets" was accepted, but the two preceding rules to allow specific kinds of data through did not. Might be that your rule to redirect to fail2ban also isn't applied anymore.

@rsk:

Are you, perchance, using the recent 3.9 kernels that Linode offers to you by default and some old-ish distro like Debian 6?

One of my servers went down for a bit because after a reboot it picked up a new kernel, which refused to cooperate with older iptables binaries.

In my case, the rule to "drop all other packets" was accepted, but the two preceding rules to allow specific kinds of data through did not. Might be that your rule to redirect to fail2ban also isn't applied anymore.

Debian 7.1 (Linux 3.9.3-x86_64-linode33)

Fail2ban has been installed before these dates, "Failed password" count in va/log/auth.log

    957 Jul 7
    369 Jul 8
    121 Jul 9
    641 Jul 10
    694 Jul 11
   3897 Jul 12
   3583 Jul 13
   3718 Jul 14
   3981 Jul 15
   3383 Jul 16
   2420 Jul 17
    530 Jul 18
     10 Jul 19
   1319 Jul 20
    304 Jul 21
     50 Jul 22
   5417 Jul 23
    161 Jul 24
    268 Jul 25
     45 Jul 26
     12 Jul 27
     43 Jul 28

I'd be somewhat (but not totally) surprised if Debian 7's iptables are too old for the new netfilter interface too, but if you could post the dump of iptables -L -v -n to see if there are fail2ban blocks listed, it might help eliminate a possibility.