Topic: Logwatch - sshd Authentication Failures

[bloodshoteye]

Hi all

Please look at the included snippet from Logwatch Logwatch 7.3.2 These type of entries are a regular occurrence.
SME 7.3 is in gateway mode and has a permanent  Internet interface:

 

--------------------- pam_unix Begin ------------------------

 sshd:
    Authentication Failures:
       unknown (65.254.42.186): 410 Time(s)
       admin (65.254.42.186): 4 Time(s)
       games (65.254.42.186): 2 Time(s)
       mark (65.254.42.186): 2 Time(s)
       public (65.254.42.186): 2 Time(s)
       root (83.3.179.19): 2 Time(s)
       root (ip-86-203-4-72.pool.grokthis.net): 2 Time(s)
       root (laubervilliers-151-12-78-102.w193-252.abo.wanadoo.fr): 2 Time(s)
    Invalid Users:
       Unknown Account: 410 Time(s)
 
 ---------------------- pam_unix End -------------------------

 --------------------- sshd Begin ------------------------

 
 Failed logins from:
    65.254.42.186: 5 times
    72.4.203.86 (ip-86-203-4-72.pool.grokthis.net): 1 time
    83.3.179.19 (gqx19.internetdsl.tpnet.pl): 1 time
    193.252.55.102 (LAubervilliers-151-12-78-102.w193-252.abo.wanadoo.fr): 1 time
 
 Illegal users from:
    65.254.42.186: 205 times
 
 
 Received disconnect:
    11: Bye Bye
: 182 Time(s)
 
 ---------------------- sshd End -------------------------

(... more snipping)

I myself had ssh connections to the server, so that will explain some of the disconnects.
Is there cause for concern, and if so can anything be done about it?

EDIT: I've just realized I have "Allow public access" enabled under the Remote Access panel. Not very secure. I guess the port is open for scanning?

Thanks,

[Franco]

At least change the port to a higher value

[cactus]

At least change the port to a higher value

That will not make it more secure. If you really want to get rid of that you will have to follow this instruction: http://wiki.contribs.org/SSH_Public-Private_Keys

[bloodshoteye]

cactus

That will not make it more secure. If you really want to get rid of that you will have to follow this instruction: http://wiki.contribs.org/SSH_Public-Private_Keys

This is the only way - recall doing this a long time ago elsewhere - thanks for the reminder.

[Franco]

Right, my suggestion is only not to receive these authentication failures (see topic), since these zombies attack the port 22.

[bloodshoteye]

stuntshell

Right, my suggestion is only not to receive these authentication failures (see topic), since these zombies attack the port 22.

One has to enter the redefined port address each time with this approach - not too much of a hassel.

I once used this snippet (obtained here http://wiki.clug.org.za/wiki/Defending_Against_Brute_Force_SSH_Attacks) to good effect on an Kubuntu gateway - I wonder if it can be incorporated into SME via a custom template?

iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --dport ssh -m recent --update --seconds 60 -j DROP
iptables -A INPUT -p tcp --dport ssh --tcp-flags syn,ack,rst syn -m recent --set -j ACCEPT

Pros:

    * If you do this properly, it won't affect you.

Cons:

    * They can still get in one attempt.
          o In my experience this isn't true, because they normally port-scan you first. The port-scan will get them blocked before they have a single login attempt.
    * When they get cleverer, they might add longer delays (unlikely).
    * You are limited to one connection a minute too.
          o This can be mitigated by adding a knock-style random high port number that when syn'ed removes your IP from the temporary black-hole.
          o Or putting in a rule that bypasses any IPs coming from your ISP (or country).
    * This does not work without a patch. ipt_recent doesn't handle jiffie overflow correctly, so it will block all incoming requests for the first five minutes after boot and after jiffie overflows. See https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=415 for more information and a patch.

Minor edit: Just had to come back with a smile as this is my 100th post 
 

[Franco]

...and so am I  800th

[bloodshoteye]

Just had to pass 100...

I've enabled Public/Private keys on various machines and tested that thoroughly.
Then disabled "Allow secure shell access using standard passwords", held my breath and tried a ssh connection, which worked - of course 

Would anyone like respond to my post re custom-template for iptables (above)?

[Franco]

I wouldn't use it, you'll see yourself getting locked out of your system if not done correctly.
I personally don't change the settings for the SSH access, only on the inside network, if I need outside access I use VPN or the ajaxterm contrib http://wiki.contribs.org/Ajaxterm

[pfloor]

Just had to pass 100...

I've enabled Public/Private keys on various machines and tested that thoroughly.
Then disabled "Allow secure shell access using standard passwords", held my breath and tried a ssh connection, which worked - of course 

That will make you server more secure but you will still want to change the port (if you haven't already) or the auth failures in the logs will persist regardless of your authentication method.

[cactus]

That will make you server more secure but you will still want to change the port (if you haven't already) or the auth failures in the logs will persist regardless of your authentication method.

You are not telling me that you believe they are only trying to access your system at the default SSH port, do you? It is a false sense of security as they will most likely discover the new assigned port as well.

[bloodshoteye]

stuntshell

I personally don't change the settings for the SSH access, only on the inside network, if I need outside access I use VPN or the ajaxterm contrib http://wiki.contribs.org/Ajaxterm

I've now enabled both vpn and ajaxterm at a particular client - either is useful, depending on the expertise of the network user.

Go well,

[pfloor]

You are not telling me that you believe they are only trying to access your system at the default SSH port, do you? It is a false sense of security as they will most likely discover the new assigned port as well.

1-I didn't say they only scan port 22 but the (large) majority of ssh hacking attempts do occur on port 22.  Let's do the math, there are some 65,000 ports and a hacker can either spend all his time scanning my IP address up to 65,000 times to try to see IF I have an ssh port open OR he can use the same amount of resources and scan 65,000 IP addresses to see if someone has port 22 open.

2-I also never said it would make the server more secure, you made that assumption.  What I said is if you change the port, it will reduce all that log noise and that was part of the OP's original question.

But since we are on the subject lets make a comparison.

To prove my point about #1 above, early last year I set up a new server, enabled ssh to the public (using keys) for some configurations and accidentaly left it on port 22 for about a week before I discovered my mistake.  In my logs, there were between 500-1000 auth failures per DAY (thank goodness for keys and strong passwords).

I changed the port and ever since (its been over a year now), I have NEVER had another unauthorized attempt, EVER. This is an "odds" game and my odds just got a whole lot better.

Now, does that make my server more secure...You be the judge.  I would say that a 1000/day reduction in hacking attempt is more secure, wouldn't you?

If nothing else, it made my ssh log file tiny and reduced the amount of work my server was doing.

This can be debated forever but as far as I'm concerned, reducing the number of hacking attempts (by hundreds or even thousands per day) is most definitely added security.

There is no perfect solution (other than disabling ssh altogether) but if you must have ssh access to your server then using private/public keys AND changing the port is (in my opinion) better than just one or the other and that's why I suggested that the OP ALSO change the port.  I never suggested that he change the port as the only thing he should be doing.

Changing the port is only one piece of the security puzzle, it's not a fix-all and I never suggested that it was.