SSH: Possible Break In Attempt???

Here are another couple of entries: (all are very recent entries)

Feb 18 02:43:31 webbox788 sshd[17629]: Illegal user hitler from 81.219.244.135
Feb 18 02:43:31 webbox788 sshd[17629]: error: Could not get shadow information for NOUSER
Feb 18 02:43:31 webbox788 sshd[17629]: Failed password for illegal user hitler from 81.219.244.135 port 3765 ssh2
Feb 18 02:43:32 webbox788 sshd[17631]: Illegal user albert from 81.219.244.135
Feb 18 02:43:32 webbox788 sshd[17631]: error: Could not get shadow information for NOUSER
Feb 18 02:43:32 webbox788 sshd[17631]: Failed password for illegal user albert from 81.219.244.135 port 3813 ssh2
Feb 18 02:53:59 webbox788 sshd[17706]: Illegal user clamav from 198.181.250.44
Feb 18 02:53:59 webbox788 sshd[17706]: error: Could not get shadow information for NOUSER
Feb 18 02:53:59 webbox788 sshd[17706]: Failed password for illegal user clamav from 198.181.250.44 port 47681 ssh2
Feb 18 02:54:00 webbox788 sshd[17708]: Failed password for sshd from 198.181.250.44 port 47732 ssh2
Feb 18 03:29:26 webbox788 sshd[17973]: Illegal user google from 85.18.136.82
Feb 18 03:29:26 webbox788 sshd[17973]: error: Could not get shadow information for NOUSER
Feb 18 03:29:26 webbox788 sshd[17973]: Failed password for illegal user google from 85.18.136.82 port 19803 ssh2
Feb 18 03:29:27 webbox788 sshd[17975]: Illegal user yahoo from 85.18.136.82
Feb 18 03:29:27 webbox788 sshd[17975]: error: Could not get shadow information for NOUSER
Feb 18 03:29:27 webbox788 sshd[17975]: Failed password for illegal user yahoo from 85.18.136.82 port 35898 ssh2

Hi brettmjohnson,

Thanks for your input. I guess these attempts are a common thing in most servers' logs...?
These log entries just got me thinking of how catastrophical it would be if someone gained unauthorized root access :)
Is there any way a cracker could gain access to the root password (if it wasn't publicly posted somewhere of course :) ?

I read somewhere that one should never log into a system as "root" but rather use "$ su root" after login instead... Would this really make a difference?

<< You can configure SSH to only accept connections from certain ip addresses
<< [or address ranges?] using the /etc/hosts.allow file.
That is handy to know... This would only affect SSH, yes? (not FTP or anything like that)
The only thing is that I'd be afraid of locking myself out being as I don't have a static IP :)

Thanks again!
- Julian.

Hi PsiCop,

Thank you for your input. I am trying to understand exactly what you mean... I would like to secure my systems as best I can... Maybe you can help...?

<< root should only be directly accessible from the console (i.e. physically at the machine).
That would make complete sense. You mean to completely disallow root access via remote SSH? This way how would I be able to administer my servers properly while having no physical access to the servers? For example, I often need to make changes to the HTTPd config files etc.. Would this be possible without root access? Or is it ok to "su" to root after having logged into the system (remotely) and if so, how would this make it more secure?

Also I was wondering: where are the user privilidges set?

Again, many thanks - I greatly appreciate your help...

Thanks to everyone for your comments. I do appreciate it...

Maybe someone could have a look at my config files to see if/how I can improve the system security...
I have /etc/ssh/ssh_config which is empty (commented out) and sshd_config which is posted below:

################################################################

# Package generated configuration file
# See the sshd(8) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 600
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile      %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

# Change to yes to enable tunnelled clear text passwords
PasswordAuthentication yes


# To change Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#AFSTokenPassing no
#KerberosTicketCleanup no

# Kerberos TGT Passing does only work with the AFS kaserver
#KerberosTgtPassing yes

X11Forwarding no
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
KeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

Subsystem      sftp      /usr/lib/sftp-server

UsePAM yes

Hi Tolomir,

Am checking out DenyHosts at the mo :)

If I set
"PermitRootLogin"
to "no" I can still use the su command right???

past -> part

http://denyhosts.sourceforge.net/faq.html  <--- should answer all your questions

Yes, the FAQ page seems pretty useful...
One question about changing the port number....
If I happen to change the port number to a port which is closed or blocked by a firewall would I risk locking myself out?
I mean I can test the port number after changing but was wondering if the current SSH session would be disconnected disallowing me to change it back after restarting the SSH service...

yep, you have to restart the service, so you would be locked out.

if you are unsecure, you could setup another service like telnet or ftp and play with the ports to find out about a firewall.

Of cause, deactivate these after your tests.

Tolomir, I had some trouble installing DenyHosts - the setup script gives an error message -
error: invalid Python installation: unable to open /usr/lib/python2.3/config/Makefile (No such file or directory)


<< Additionally, consider using ssh dsa/rsa keys
Hi dpiniella, I am considering this :) Any tips on how to set it up, create the keys etc. Links to resources would be fine if you know of any...

<< PermitRootLogin no
Have changed it...

If I set "AllowUsers" in sshd_config it will only allow these users to login and I wouldn't need to set "DenyUsers" - would that assumption be correct? It seems this would be the safest setting to enable??

Just installed the python-dev package and was able to install DenyHosts... Thanks!
Just configuring it now and will let you know how I get on...

confusing ...
anything you can do to secure sshd has been answered.
If you want to block connects from unknown IPs, that's a task for your firewall and not for ssh.
Whatelse are you missing?

Hi Tolomir,
I've successfully installed DenyHosts and it seems to be working quite well!! Thanks a lot for the tips!!

Hi ahoffmann!
<< If you want to block connects from unknown IPs, that's a task for your firewall and not for ssh.
Sorry, don't understand what you mean... I thought I should use /etc/hosts.deny ...
<< Whatelse are you missing?
Well, I don't know - that's what I was asking the experts... One question I still had was this one: {http:#15990593}. Another one was about ssh dsa/rsa keys {http:#15990574} but I will post a new question for this...

Another thing I wanted to ask was about "LoginGraceTime 600" <---- I guess the lower this setting the safer???

<< 60 should be reasonable
Thanks!

<< do you have a firewall in front?
I don't think there's a firewall on the system. I'm sure there's an external firewall but I don't have access to this...
Is hosts.deny not just as good to block malicious hosts??

>  It is.
if we were in a Security TA, I'd disagree, but here I'll not give one of my pedantic comments ;-)

Sure, one could DoS a computer directly connected to the internet, but we are talking about break in attempts here, not about complete denial of service (DoS) . So the host.deny file should do it's job well.

http://en.wikipedia.org/wiki/Denial-of-service_attack

Tolomir

Surely this type of attack would be covered by the network and datacenter providers... wouldn't it?

Yep, but a DoS is never easy to get rid of, especially if it's a distributed DoS attack.

But, I guess most sites will never face it, even a DoS needs some coordination and most important a purpose.

But take www.milliondollarhomepage.com he faced a Dos attack and some blackmailing, because there were some that thought there could be easy money to earn: He should pay $10.000 and the DoS would stop, nice offer, wasn't it.

With his account provider no DoS protection was included, so the website was down for a couple of days. Without being so famous, the owner would had never got that additional bandwith and DoS protection for free, so basically one's "webshop" would be down...

Getting too off topic I know ;-)

Tolomir

P.S. I would be interested in some results of your denyhosts installation, especially if those breakin attempts do really go down. I suspect script kiddies in most cases, selecting an IP at random and checking some names, passwords...

<< Getting too off topic I know ;-)
I do think it's all pretty interesting though :)

I think DenyHosts is working quite well actually. Just before I installed it I noticed a lot of attempts from the same IPs in the auth.log (i.e. maybe a couple dozen at once). After I installed it the numbers of break in attempts went down considerably and I've noticed that a new hacker (non-blacklisted host) will have about 10 shots at getting into the system before their IP is refused (it would be great if I could bring this number down a bit more). Am running DenyHosts as daemon...

But it's great that I was able to install it. Thanks for your help!

there is a way to bring that number down -- see http://www.howtoforge.com/preventing_ssh_dictionary_attacks_with_denyhosts tutorial's example cfg for denyhosts -- and change your config file's

# DENY_THRESHOLD_VALID: block each host after the number of failed
# login attempts has exceeded this value.  This value applies to valid
# user login attempts (eg. user accounts that exist in /etc/passwd) except
# for the "root" user
#
DENY_THRESHOLD_VALID = 10

section to whatever you want your threshold to be. 3 to 5 would be what I'd use, but that's just personal preference.

These are my settings:
DENY_THRESHOLD_INVALID = 2
DENY_THRESHOLD_VALID = 3
DENY_THRESHOLD_ROOT = 2

But it probably has something to do with the DAEMON_SLEEP setting being set to 30s...


Just while taking another look at the DenyHosts files I saw these in /usr/share/denyhosts/data/:
hosts-restricted
hosts-root
hosts-valid
offset
suspicious-logins
users-hosts
users-invalid
users-valid

Can anyone tell me what "hosts-valid", "hosts-root" and "users-hosts" are for? I tried looking but couldn't find any answers...

did you re-HUP (or restart) denyhosts after making any changes to your config? if you changed the config while it was running, they won't take effect until you send a HUP signal.

Ya, I only changed the configuration once after installation and then restarted/started the service...

I guess this is prefiltering, the program hast to count connection attempts from suspicious ips, only if the threshhold is exceeded, deny-hosts will be updated

these users files might be a way to disable access if a special user account is used from some host...

Thanks for all your help. I really appreciate it!
-Julian.

I hope I was fair with the points...


BTW:

<< (don't know if debian still uses hosts.deny, many distros don't) will affect services other than ssh -- mail, ftp, http, etc.

Yes, Debian uses hosts.deny and am also able to state which service to deny, i.e.
ALL | SSH | FTP etc.

e.g.
SSH: 123.456.789.10

If anyone is interested...

SSH: Allow/Deny Users [500pts]:      http:/Q_21751841.html

SSH:  dsa/rsa keys:      http:/Q_21751847.html
Secure SSH:     http:/Q_21751849.html