Topic: SSH Log noise

[pblanco]

Hi there, I dont know if any one spot this before, but check my messages log file I found this

ec 17 08:41:16 bblatino sshd(pam_unix)[10728]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=218.1.65.233  user=root
Dec 17 08:41:19 bblatino sshd(pam_unix)[10730]: check pass; user unknown

and there are hundreds of entries like that one. This happend with all the sme servers I installed.

So what is this, I can be sure that IP isnt mine.

any help?
What can  I do?

[thomasch]

Hi there, I dont know if any one spot this before, but check my messages log file I found this

ec 17 08:41:16 bblatino sshd(pam_unix)[10728]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=218.1.65.233  user=root
Dec 17 08:41:19 bblatino sshd(pam_unix)[10730]: check pass; user unknown

and there are hundreds of entries like that one. This happend with all the sme servers I installed.

So what is this, I can be sure that IP isnt mine.

any help?
What can  I do?

It's discussed in this forum before. Next time do a search before starting a new topic.
check this : http://forums.contribs.org/index.php?topic=23567.msg93874#msg93874

[Normando]

pblanco, don't post security issues here!

Please, read above your posting box. He said:

Don't report security issues here - Contact security at contribs dot org

[pfloor]

If you allow SSH access to your server you take the risk of bots (thousands of them) trying to access your server.  Those log entries will be expected if you allow SSH access.  To eliminate the risk you should Totally Disable SSH access to your server.  If you must allow SSH access then you can mitigate the risk as follows:

1-Use VERY STRONG passwords.

2-Set "Allow secure shell access using standard passwords" to "NO" and Use Public/Private keys.  It takes a little time to set up but I can't emphasise how critical this step is.  It requires the client and server to exchange a key and is very secure.  See http://wiki.contribs.org/SSH_Public-Private_Keys

3-Change the port from 22 to something else not in use by the server like 9122.  (This will also stop all the log noise.)

Let's not panic everyone...Topic changed to SSH Log noise

[cactus]

If you allow SSH access to your server you take the risk of bots (thousands of them) trying to access your server.  Those log entries will be expected if you allow SSH access.  To eliminate the risk you should Totally Disable SSH access to your server.  If you must allow SSH access then you can mitigate the risk as follows:

1-Use VERY STRONG passwords.

2-Set "Allow secure shell access using standard passwords" to "NO" and Use Public/Private keys.  It takes a little time to set up but I can't emphasise how critical this step is.  It requires the client and server to exchange a key and is very secure.  See http://wiki.contribs.org/SSH_Public-Private_Keys

3-Change the port from 22 to something else not in use by the server like 9122.  (This will also stop all the log noise.)

Let's not panic everyone...Topic changed to SSH Log noise

That is a start but all above suggested methods are pseudo methods, especially the last one will not make SSH saver, it will only stop some of the noise momentarily as those bots do not stop on scanning port 22...

The best and by far most secure option is to make use of public-private keys when connecting over SSH, there is an excellent howto in the wiki: http://wiki.contribs.org/SSH_Public-Private_Keys

This method makes use a method to compare a public key on the server with a private key on the suer site, as ling as you do not hand-out the private key no one will be able to access your server using SSH.

[pfloor]

That is a start but all above suggested methods are pseudo methods, especially the last one will not make SSH saver, it will only stop some of the noise momentarily as those bots do not stop on scanning port 22...

I beg to differ with you on this point.  I changed my ssh port a year ago (on advice from Shad) and went from hundreds (sometimes even thousands) of failed ssh auth log events per day to ZERO.  Since changing my port I have not had one single ssh log-in attempt (except my own) logged in almost a year.

My (somewhat limited) experience shows me that changing your ssh port does reduce log noise and by reducing (or even eliminating) the number of unwanted log-in attempts makes the server a bit more secure (IMHO).

The best and by far most secure option is to make use of public-private keys when connecting over SSH, there is an excellent howto in the wiki: http://wiki.contribs.org/SSH_Public-Private_Keys

<Paul is scratching his head> Isn't that what I said in #2? I even link to the same how-to.

[cactus]

I beg to differ with you on this point.  I changed my ssh port a year ago (on advice from Shad) and went from hundreds (sometimes even thousands) of failed ssh auth log events per day to ZERO.  Since changing my port I have not had one single ssh log-in attempt (except my own) logged in almost a year.

My (somewhat limited) experience shows me that changing your ssh port does reduce log noise and by reducing (or even eliminating) the number of unwanted log-in attempts makes the server a bit more secure (IMHO).

Before I switched to using private/public keys I received SSH login attempts from a broad range of IP numbers on multiple ports even above the 1024 boundary. IMHO reducing or eliminating log noise does not make your system more secure... it only lowers the risk of being discovered and consequently hacked.

<Paul is scratching his head> Isn't that what I said in #2? I even link to the same how-to.

I am scratching my head as well and wondering if I need to ask a pair of glasses from Santa Glad we agree on the point of private/public keys though... perhaps this might be a good NFR to make the system even more secure.

[bunkobugsy]

Guys, just wondering, how about accepting SSH from local networks only, and VPN-ing in to get local? Would that be unsafe too? (supposed our LAN is safe)

[arnie25]

Guys, just wondering, how about accepting SSH from local networks only, and VPN-ing in to get local? Would that be unsafe too? (supposed our LAN is safe)

No, that would be safe enough.