LinuxQuestions.org
Go Job Hunting at the LQ Job Marketplace
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Closed Thread
 
Search this Thread
Old 08-09-2004, 01:00 PM   #1
Capt_Caveman
Senior Member
 
Registered: Mar 2003
Distribution: Fedora
Posts: 3,658

Rep: Reputation: 57
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
 
Old 08-09-2004, 11:11 PM   #2
ppuru
Senior Member
 
Registered: Mar 2003
Location: Beautiful BC
Distribution: RedHat & clones, Slackware, SuSE, OpenBSD
Posts: 1,791

Rep: Reputation: 47
And perhaps the use of the AllowUsers keyword in /etc/ssh/sshd_config to lock down access to the known few.
 
Old 08-11-2004, 08:42 AM   #3
Pastorino
Member
 
Registered: Jul 2004
Distribution: RHEL 6.2
Posts: 35

Rep: Reputation: 15
It will be even more secure by disabling password authentication completely, and allowing only private key authentication.
 
Old 08-22-2004, 10:10 PM   #4
ppuru
Senior Member
 
Registered: Mar 2003
Location: Beautiful BC
Distribution: RedHat & clones, Slackware, SuSE, OpenBSD
Posts: 1,791

Rep: Reputation: 47
New version of brutessh code is out
http://isc.sans.org/diary.php?date=2...6a32305ebe5d9c
 
Old 09-02-2004, 09:35 AM   #5
adjman
LQ Newbie
 
Registered: Sep 2004
Location: Duncton, UK
Distribution: Lubuntu
Posts: 6

Rep: Reputation: 0
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.

 
Old 09-14-2004, 08:21 AM   #6
crackito
LQ Newbie
 
Registered: Sep 2004
Location: Portugal
Posts: 1

Rep: Reputation: 0
I use apf fw, and bfd....bfd check's for brute force attempts anda add hosts to the deny.hosts of the fw.
 
Old 09-15-2004, 03:57 AM   #7
Ambrosia
LQ Newbie
 
Registered: Aug 2004
Location: Germany
Distribution: Debian Sid
Posts: 17

Rep: Reputation: 1
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

Last edited by Ambrosia; 09-15-2004 at 04:05 AM.
 
1 members found this post helpful.
Old 09-25-2004, 10:09 PM   #8
micxz
Senior Member
 
Registered: Sep 2002
Location: CA
Distribution: openSuSE, Cent OS, Slackware
Posts: 1,131

Rep: Reputation: 75
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.
 
Old 09-27-2004, 11:33 AM   #9
TruckStuff
Member
 
Registered: Apr 2002
Posts: 498

Rep: Reputation: 30
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.
 
Old 09-27-2004, 03:11 PM   #10
micxz
Senior Member
 
Registered: Sep 2002
Location: CA
Distribution: openSuSE, Cent OS, Slackware
Posts: 1,131

Rep: Reputation: 75
I've had good responses from network abuse teams working for different ISP's. Some even write back and thank you.
 
Old 09-28-2004, 02:56 AM   #11
dannyk1
Member
 
Registered: Aug 2004
Location: Geelong, Vic Australia
Distribution: Gentoo, Ubuntu,and sometimes something from billy gates (when Im desperate)
Posts: 179

Rep: Reputation: 31
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)
 
Old 09-28-2004, 07:19 AM   #12
craig34
LQ Newbie
 
Registered: Sep 2004
Distribution: FreeBSD
Posts: 8

Rep: Reputation: 0
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?

Code:
ALL : 207.158.8.236 : deny
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?
 
Old 09-29-2004, 09:01 PM   #13
TruckStuff
Member
 
Registered: Apr 2002
Posts: 498

Rep: Reputation: 30
Re: Blocking these IPs

Quote:
Originally posted by craig34
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?

Code:
ALL : 207.158.8.236 : deny
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?
whois 207.158.8.236 will give you the CIDR range. Then you can add
Code:
ALL:  207.158.0.0/18 : deny
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.
 
Old 10-04-2004, 06:05 AM   #14
jayjwa
Member
 
Registered: Jul 2003
Location: NY
Distribution: None (src & compile)
Posts: 253

Rep: Reputation: 36
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:

Code:
sshd: .cn, .cn.net, .cn.com, .jp, .jp.com
3) Add line

Code:
sshd: UNKNOWN
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:

Code:
# Explicitly set who can and who can not login by way of ssh
AllowGroups users
AllowUsers tom joe harry

# Everything that isn't above
DenyGroups root bin daemon sys adm tty disk lp mem kmem wheel floppy mail news  uucp man games slocate utmp smmsp mysql rpc sshd shadow ftp nogroup console xcdwrite

DenyUsers root bin daemon adm lp sync shutdown halt mail news uucp operator games ftp smmsp mysql rpc sshd nobody test guest user admin apache www wwwrun httpd irc

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)

Last edited by jayjwa; 10-06-2004 at 09:38 AM.
 
1 members found this post helpful.
Old 10-30-2004, 03:17 PM   #15
dmoorhouse
LQ Newbie
 
Registered: Sep 2004
Location: Whitehorse Yukon
Distribution: debian, Fedora, Ubuntu, more...
Posts: 9

Rep: Reputation: 0
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
 
  


Closed Thread

Tags
ssh


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
SSH login attempts Capt_Caveman Linux - Security 225 11-07-2009 09:55 AM
SSH tricks -- any way to block failed attempts by IP address tensigh Linux - Security 10 06-06-2008 03:46 PM
ssh login attempts from localhost?! sovietpower Linux - Security 2 05-29-2005 01:19 AM
SSH login attempts - how to get rid of the automated malware? alexberk Linux - Security 1 05-24-2005 04:57 AM
/var/log/messages shows failed login attempts... plan9 Linux - Security 8 08-08-2004 12:52 PM


All times are GMT -5. The time now is 01:21 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration