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.

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

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.

:)

I use apf fw, and bfd....bfd check's for brute force attempts anda add hosts to the deny.hosts of the fw.

I've set up a Honeypot after noticing similiar activity on SSH, using an old Slackware 8, 2.4.18 and a bogus guest/guest account.

The entire thing seems automated, and as soon as the guest logs in, a local root exploit gets used to gain root access..automatism stops there though, as the actual news root pass gets entered manually (yay for script kiddies typoing).

After that, behavior differed...one immediately installed an IRC bot which connected to Undernet (EnergyBot), and started to scan from my machine (but strangely, all the machines he scanned were firewalled...hum..).
Sadly I hadn't my keylogger/outputlogger set up properly, so the log wasn't really usable aside of that info.
Others just changed the root pass, and logged out again.

Those scans aren't really frequent here (one each couple of days or so), and seem to have different origins (a few US, one from Romaina).

Ah yes, the Romanian guy...changed root pass, logged out, didn't return for a while. I then restored an hour-old copy of the system, and -bang-, minutes later he's exploting the thing -again- (using a different root pass), and doesn't even at all seem to notice a certain familiarity with a certain box he exploited before..heh..kiddies.

On further note, it's safe to assume that they logged in from their own private boxes..nmap revealed all ports as firewalled.

Right now I've put the Honeypot on hold...what do you think, is it worth continuing it? Any good ideas on further actions? :)

Ambrosia

All my web servers, personal servers and everyone I know at home are getting hit with these atttemps. These scans are happening for months now. I'm almost willing to bet anyone who runs ssh `cat /var/log/messages | grep test` they will see many attempts from different IPs.

I suggest we all use key logins only and even run ssh on a alternate port if possible. Adding them to hosts.deny or blocking them via iptables in real time is even better.

Geesh... I had one guy "scan" our servers over six THOUSAND times this weekend. What a PITA. I sent a complaint to his hosting company's abuse department... who knows if anything will come of it.

I've had good responses from network abuse teams working for different ISP's. Some even write back and thank you.

I'm used to cleaning out spam from my email but this shit is starting to get out of hand

Looks like the code has been updated to throw more passwords at a server

Look at how many hits I got from one idiot in one attack

failed logins from these:
Administrator/password from 216.189.163.85: 1 Time(s)
accounting/password from 216.189.163.85: 1 Time(s)
adm/password from 216.189.163.85: 1 Time(s)
admin/password from 216.189.163.85: 4 Time(s)
administrator/password from 216.189.163.85: 1 Time(s)
anon/password from 216.189.163.85: 1 Time(s)
apache/password from 216.189.163.85: 1 Time(s)
boss/password from 216.189.163.85: 1 Time(s)
checkfs/password from 216.189.163.85: 1 Time(s)
cisco/password from 216.189.163.85: 6 Time(s)
client/password from 216.189.163.85: 1 Time(s)
cvs/password from 216.189.163.85: 1 Time(s)
debug/password from 216.189.163.85: 1 Time(s)
dni/password from 216.189.163.85: 1 Time(s)
echo/password from 216.189.163.85: 1 Time(s)
fal/password from 216.189.163.85: 1 Time(s)
fax/password from 216.189.163.85: 1 Time(s)
ftp/password from 216.189.163.85: 1 Time(s)
games/password from 216.189.163.85: 1 Time(s)
gnats/password from 216.189.163.85: 1 Time(s)
gopher/password from 216.189.163.85: 1 Time(s)
guest/password from 216.189.163.85: 1 Time(s)
intel/password from 216.189.163.85: 1 Time(s)
kermit/password from 216.189.163.85: 1 Time(s)
login/password from 216.189.163.85: 1 Time(s)
lp/password from 216.189.163.85: 1 Time(s)
lynx/password from 216.189.163.85: 1 Time(s)
mail/password from 216.189.163.85: 1 Time(s)
man/password from 216.189.163.85: 1 Time(s)
manager/password from 216.189.163.85: 1 Time(s)
master/password from 216.189.163.85: 1 Time(s)
monitor/password from 216.189.163.85: 1 Time(s)
mysql/password from 216.189.163.85: 1 Time(s)
netscreen/password from 216.189.163.85: 1 Time(s)
news/password from 216.189.163.85: 1 Time(s)
nobody/password from 216.189.163.85: 1 Time(s)
operator/password from 216.189.163.85: 2 Time(s)
oracle/password from 216.189.163.85: 1 Time(s)
postgres/password from 216.189.163.85: 1 Time(s)
postmaster/password from 216.189.163.85: 1 Time(s)
qsvr/password from 216.189.163.85: 1 Time(s)
root/password from 216.189.163.85: 8 Time(s)
security/password from 216.189.163.85: 1 Time(s)
sync/password from 216.189.163.85: 1 Time(s)
sys/password from 216.189.163.85: 1 Time(s)
sysadmin/password from 216.189.163.85: 2 Time(s)
sysop/password from 216.189.163.85: 1 Time(s)
tech/password from 216.189.163.85: 1 Time(s)
test/password from 216.189.163.85: 6 Time(s)
user/password from 216.189.163.85: 1 Time(s)
uucp/password from 216.189.163.85: 1 Time(s)
www/password from 216.189.163.85: 1 Time(s)

Blocking these IPs
 

I've been using my hosts.allow file to prevent some of the IPs from which I notice many attempts. Today my security email has informed me that a range of IPs, all starting with 207.158.8, have made many attempts. I'd like to block the entire range, which seems to go from 207.158.8.236 to 207.158.8.245. How would I modify the following code to block that entire range?

Also, I've done this for about 14 IPs so far. Is there any reasons that I should know about why not to approach the problem in this manner?

Re: Blocking these IPs
 

whois 207.158.8.236 will give you the CIDR range. Then you can add to your hosts.allow file.

I've been blocking these at the firewall. Any thoughts on if its better to block at the firewall vs. using a hosts.allow as mentioned here?

Also, does anyone have any tips for managing all of these IPs across multiple servers? Its getting to be a pain to add an IP to each of our servers every day.

To limit/end these Script Kiddie playtimes:

1) Make passwords long & strong, stuff like: &^bV{-)wQ17HG*dzQK?X

2) Limit sshd's accessing domains you know you don't need in hosts.deny (sshd can be compiled w/hosts_access support or put in under xinetd/inet with -i option). For example, I know that no one from China should be logging into my sshd, so:

hosts.deny:

3) Add line

to hosts.deny. Surprisingly, this stops alot of them but hasn't stopped any of my legit users. You can combine this rule with #2 above.

4) Make use of the AllowUser, DenyUser tags in sshd_config. Make sure you list exactly who should and who should not
login. IMO, never, ever allow root.

sshd_config:


5) Check into key-only ssh login. If someone doesn't have a valid key, it will be very hard to login with any password!

6) Turn up logging and watch logs carefully. Maybe limit access times too (with xinetd's port times). I completely drop traffic from known trouble networks/domains/netblocks, but this may be too extreme for some people. xinetd can do rate limit as well.

7) You can put sshd on another port, but this shouldn't be needed if all your other defense is in place. Stay up on patches and current security. Most intruders I've seen get local, then use kernel exploits like km3.c (ptrace) or do_brk(), mremap to gain root. Of those that did get root, they usually downloaded IRC stuff (bouncers, bots) and linux viruses OSF, and RST varient #2. The attackers were quite amatureuish, and left behind plenty of evidence, including bash history files, logs, and other records. Once a machine is compromised, they use it to do more. The most advanced tool that I've seen
came as a C source file, so the port could be changed. It had an extensive password list with dictionary type words. More words could be added. RST #2 contains its own backdoor. Rootkits T0rn, and SucKit were popular as well. Many of the tools came from the go.ro domain. In many cases, the admins of the attacking machines didn't know they were compromised. Several expressed gratitude when notified of the attempts, but unfortunately the norm seems to be no response (at least in the cases I've reported myself).

As far as using hosts based access for iptables, I'd say go for both: knock out as much trouble spots as you can with each tool, because they work slightly different. For example, I may not need to allow sshd login from a certain domain, but I do want to be able to send and receive mail with it; so I can't drop it completely. With hosts based access you can give rules to just one daemon, or all.

- jayjwa

(Re-editted for reformating on 10/6)

Has anyone found a script/daemon that would monitor for such activity and then add the offending ip to the hosts.deny or drop chain of iptables in real time? I'm a network admin but not a programmer :(

All the blocking would then be automated and only the offending ip would be locked out as the attempts are made.

Dar