[Leaplist] Server break-in attempt through NAGIOS user

[John Simpson]

On 2007-09-07, at 2048, David Simmons wrote:
>
>> Three quick points:
>> 1) I use the sshd_config "AllowUsers" option to define which users  
>> can log
>> in via ssh. None of the "common/typical" users are in this list.  
>> I'll log
>> in as on a non-common account and then su to the standard account  
>> if needed.
>
> Have been thinking about
> this....what the Nagios account was doing was SSHing OUT to attempt  
> ssh
> connections with a bunch of other machines.....so while sshD_config  
> has a
> 'AllowUser' config option...that wouldn't have really helped?

if the attacker couldn't have logged INTO the nagios account to begin  
with, yes- it most definitely would have helped.

> [root at www4 opt]# ls -la /usr/bin/ssh
> -rwxr-xr-x 1 root root 292520 Mar 21 15:42 /usr/bin/ssh
>
> Ah-ha!  so what
> I should probably do is a 'chmod 700'.....is there a reason that  
> any user
> should have r_x access to ssh OUT??

that depends on your users. do they ever need to ssh or scp out from  
your machine?

if nothing else, you may want to create a new group "sshusers", do  
"chgrp sshusers /usr/bin/ssh", and do "chmod 750 /usr/bin/ssh". then,  
only root and any users that you manually add to the "sshusers" group  
will be able to ssh outbound.

the same thing applies to gcc... you may want to create a "gccusers"  
group and secure the "gcc", "g++", and other compiler binaries in the  
same manner. most "root kits" involve downloading and compiling some  
kind of software as soon as the attacker gains access to the machine-  
if they can't run the compiler, they can't build the program to get  
root. most of the people doing this crap are "script kiddies" anyway.  
they're running a script which downloads a tarball from some FTP  
server somewhere, expands it, and tries to compile it. if the compile  
doesn't work, usually they call it a loss and move on to some other  
machine rather than manually downloading binaries- because binaries  
for one type of system may or may not work on some other system.

i've also seen more secure setups involving filesystems other than "/ 
usr" and "/" mounted with the "noexec" flag, so that the kernel will  
refuse to run programs from those filesystems. and of course SELINUX  
can accomplish pretty much the same thing, although with more  
granularity about which binaries are and are not allowed to be executed.

i even remember reading somewhere about somebody patching the "ld"  
program once, so it ignored the LD_PRELOAD variable and the /etc/ 
ld.so.preload file. the "preload" mechanism is used by some rootkits  
to "hide" certain files, directories, processes, and sockets from any  
process which looks for them- whether the binary has been changed or  
not.

>> 2)  I use the sshd_config "Port" option to something other than  
>> port 22.
>> This significantly reduced the number of ssh script attacks that I  
>> was
>> seeing. Obviously someone can still find the  port if their  
>> interested,
>> but let's not make it too easy.

i do the same thing on every machine i administer which is directly  
on the internet.

>> 3) Finally, I use the hosts.allow "sshd" option to specify what IP
>> addresses can connect via ssh.

i've done this on some machines, but not all... i never know when  
i'll be at a client's office and need to access something on my own  
server, for example.

> Yes....good ideas -
> but not helpful to prevent this type of account....poor passwords I
> believe are/were the real culprit?!?!

that would be my guess, but without having actually seen the attack  
as it happened, or possibly conducting a forensic exam of the  
machine, there's no way for me to say for sure.

my "rule of thumb" has always been that when i find evidence of a  
compromise, i get a new hard drive, do a fresh OS install, and then  
move just the data from the old disk to the new disk, examining  
anything unusual i may find along the way. (then i format the old  
drive and re-use it for something else.)

----------------------------------------------------------------
| John M. Simpson    ---   KG4ZOW   ---    Programmer At Large |
| http://www.jms1.net/                         <jms1 at jms1.net> |
----------------------------------------------------------------
| http://video.google.com/videoplay?docid=-1656880303867390173 |
----------------------------------------------------------------


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.leap-cf.org/pipermail/leaplist/attachments/20070908/a0a72eb0/PGP.bin