SSH login attempts

There appears to be some form of automated malware circulating around the internet in the last 2 weeks. It attempts sshd logins using simple username-password combinations. A sample scan looks like:

Jul 19 21:04:33 server sshd[28379]: Illegal user test from XXX.XXX.XXX.XXX
Jul 19 21:04:34 server sshd[28381]: Illegal user guest from XXX.XXX.XXX.XXX
Jul 19 21:04:36 server sshd[28383]: Illegal user admin from XXX.XXX.XXX.XXX
Jul 19 21:04:37 server sshd[28385]: Illegal user admin from XXX.XXX.XXX.XXX
Jul 19 21:04:38 server sshd[28387]: Illegal user user from XXX.XXX.XXX.XXX

Several reports indicate that the malicious code is a scanner designed to identify systems with weak username/passwords. Once a weak system is identified, its IP address is appended to a list for manually exploitation later on. However, the possibility of a unknown exploit has not been ruled-out.

All Linux users are recommended to implement a sensible username and password policy in order to avoid being compromised by this tool. An example of a sensible policy would be at least the use of non-dictionary, alpha-numeric+punctuation characters. Restricting sshd access to only those systems necessary will further reduce the possiblity of compromise. Access restriction can be done using iptables or tcp_wrappers (hosts.allow/deny)

Further information about this tool and failed sshd logins can be found here:
http://lists.netsys.com/pipermail/fu...ly/024612.html
http://dev.gentoo.org/~krispykringle/sshnotes.txt
http://isc.sans.org/diary.php?date=2004-08-04

And perhaps the use of the AllowUsers keyword in /etc/ssh/sshd_config to lock down access to the known few.

It will be even more secure by disabling password authentication completely, and allowing only private key authentication.

Originally posted by Pastorino It will be even more secure by disabling password authentication completely, and allowing only private key authentication.

Except I beat my head against the wall for 2 weeks a few months ago trying to get private key auth working with SSHD.

At any rate, I've been seeing these attempts in my logs for the last few weeks. Just figured it was some stupid skiddie; guess I was right.

Capt_Caveman: it's not a scanner for weak usernames/passwds, it's a ssh bruteforcer with those uid's/passwd's hard-coded.
Kiddies using it can't change the code obviously

I use more of the wikipedia definition of bruteforce, where it's something that attempts a large number of password variations against a single host, like iterating through the entire search-space of all possible alpha-numeric combinations. In essence "one or a few hosts, lots of usernames/passwords".

Of course, you can call them whatever you like

Dunno if this is the right place to ask this, but how can I configure some effective tcp wrappers using etc/hosts.allow and .deny? I'm getting the same ssh login/password spam on my box, and have been getting it for over a month now. I want to block this before it gets a chance to try combinations on my box, so I figured I'd try and disallow any ssh access except from a few specific places.

Here's the way I understand it, but it doesn't work. Someone please enlighten me:

In /etc/hosts.deny:

ALL: ALL

This will block all traffic coming in to the box, except what's provisioned in hosts.allow.

In /etc/hosts.allow:

ALL: LOCAL, .domain.com, 192.168.1

This will only allow local traffic, request from "domain.com", and any requests from your local subnet.

However, this does not work. If I try to ssh into my box from "domain.com", I get a connection refused. What gives?

The syntax should be ok. Maybe there is some problem with the hostname lookup, try using the IP address block of .domain.com instead. Do you see any relevant messages in the system logs about failed SSH attempts?

Originally posted by TruckStuff Except I beat my head against the wall for 2 weeks a few months ago trying to get private key auth working with SSHD. At any rate, I've been seeing these attempts in my logs for the last few weeks. Just figured it was some stupid skiddie; guess I was right.

It's actually very easy.
$ ssh-keygen -t rsa
(Just press enter for all answers)
$ #Put your pub key, usually /home/USER/.ssh/id_rsa.pub, onto the server you're logging on to.

New version of brutessh code is out
http://isc.sans.org/diary.php?date=2...6a32305ebe5d9c

Originally posted by Capt_Caveman There appears to be some form of automated malware circulating around the internet in the last 2 weeks. It attempts sshd logins using simple username-password combinations. A sample scan looks like: Jul 19 21:04:33 server sshd[28379]: Illegal user test from XXX.XXX.XXX.XXX Jul 19 21:04:34 server sshd[28381]: Illegal user guest from XXX.XXX.XXX.XXX Jul 19 21:04:36 server sshd[28383]: Illegal user admin from XXX.XXX.XXX.XXX Jul 19 21:04:37 server sshd[28385]: Illegal user admin from XXX.XXX.XXX.XXX Jul 19 21:04:38 server sshd[28387]: Illegal user user from XXX.XXX.XXX.XXX Several reports indicate that the malicious code is a scanner designed to identify systems with weak username/passwords. Once a weak system is identified, its IP address is appended to a list for manually exploitation later on. However, the possibility of a unknown exploit has not been ruled-out. All Linux users are recommended to implement a sensible username and password policy in order to avoid being compromised by this tool. An example of a sensible policy would be at least the use of non-dictionary, alpha-numeric+punctuation characters. Restricting sshd access to only those systems necessary will further reduce the possiblity of compromise. Access restriction can be done using iptables or tcp_wrappers (hosts.allow/deny) Further information about this tool and failed sshd logins can be found here: http://lists.netsys.com/pipermail/fu...ly/024612.html http://dev.gentoo.org/~krispykringle/sshnotes.txt http://isc.sans.org/diary.php?date=2004-08-04

One way to secure a little bit more a Linux box is by using the chattr command. Usually I keep the passwd. etc., set to +i. this no way no one can add or modify them, no even root.
You can check your file(s) setting with the command "lsattr." e.g lsattr ----i-------- passwd

Raxxal

Usually I keep the passwd. etc., set to +i. this no way no one can add or modify them, even root.

Well root can always chattr -i and make changes.

Does it only scan the default port? I always change sshd to listen to a non-standard non-priv port.

Been seeing this too, I have taken to explicitly blocking the troublesome IP's at firewall level as I use my box as a router - this way I just do a few quick Grep's through the /var/log/secure and then add a couple of rules.

Keeps them from doing anything as the firewall just drops packets from those hosts.

Here is my logwatch output and this is pretty standard every single day!

Failed logins from these:
admin/password from 200.181.46.200: 2 Time(s)
guest/password from 200.181.46.200: 1 Time(s)
guest/password from 200.206.182.38: 1 Time(s)
root/password from 200.181.46.200: 3 Time(s)
test/password from 200.181.46.200: 2 Time(s)
test/password from 200.206.182.38: 1 Time(s)
user/password from 200.181.46.200: 1 Time(s)

**Unmatched Entries**
Illegal user test from 200.181.46.200
User guest not allowed because shell /dev/null is not executable Illegal user admin from 200.181.46.200 Illegal user admin from 200.181.46.200 Illegal user user from 200.181.46.200 Illegal user test from 200.181.46.200 Illegal user test from 200.206.182.38 User guest not allowed because shell /dev/null is not executable

what Im wondering is if there is a way to setup a false file system allow a guest, user, admin, or test login to the system so that when it (the script or person) does login it can be monitored and then traced back to an originating IP?

I would love to start messing with the idiot thats actually doing this.