[Gllug] compromised?

[James de Lurker]

Leigh Mason wrote:

> Hi all
> 
> I'm using Red hat 7.1 with the 2.2.16 kernel. A periodic check of
> /var/log/messages has revealed:
> 
> syslogd 1.3-3: restart
> syslogd 1.3-3: restart
> syslogd 1.3-3: restart
> syslogd 1.3-3: restart
> syslogd 1.3-3: restart
> syslogd 1.3-3: restart

> Could this mean the machine has been compromised in some way!?
   Suspicious, but not necessarily a hacked box. Something gone bad, 
certainly. You didn't state the frequency of these restarts.


> I'm only running a handful of services, such as
> sshd, identd, xinetd and apache 1.3.27.

    What version of sshd is the key. My advice is, *whatever* version you
run, even if it has the latest security patches all applied, compile it
from known good source, and use some high unprivaleged port, not 22.
Firewalled or no. Oh - and make the software LIE or be unspecific about
what version it is ( a simple telnet connection to port 22 and a couple
of CRs will persuade a target system to yield too much information than
can be good for it ).

    There is a bloody clever backdoor possibility (reverse forward) with
ssh that will fool many a close inspector of an operating box.

    Close scruitiny of passwd / shadow / group / gshadow files ( you do
keep backups and reference copies for diffing, I trust? )

    Scruitiny of inetd / xinetd configuration files for backdoors.

    cron / crontab / anacron stuff that *you* didn't do...


> I've googled around and various sources suggest running a utility
> called 'chkrootkit', is this a reliable way to detect any signs of
> intrusion? Can anyone suggest what my next step should be?

If you really believe that the box has been compromised, follow the
forensic procedures that were well described in the first of the honeynet
challenges, a couple of years ago. They recommended a number of toolkits
and procedures. Case studies on the top 6 forensic winners: read them!

First step is to take all the usual binaries for examining processes and
active services / ports from a known good pristine installation (with
signatures), preferably introduced to the quarantined system on some
kind of read only media, like CDR.

Tripwire (siggen) , md5sum, lsof ps netstat ls are all your friends
( ls -alqFit --fulltime complete listings squirreled away can often
greatly assist in file recovery and filesystem weirdness correction )

rpm checking all the installed file md5s against installation binary rpms
is tedious, but may show up dodgy binaries without too much pain.

Start from a rescue situation, single user, mount the target drives RO
and make signature / inode listings. Browse contents, safe in the
knowledge that nothing is going to change in this snapshot view. Keep a
complete set of reference partition images before making any changes,
or permitting any R/W activity at all.

That was just a quick first thought. Any more to add to the list folks?

-- 

   -- James

 From and Reply To are INVALID.

All public postings use munged headers[1]- To contact me off list:
   1) Remove "M U N G I E j u m p" ONLY: leave that "nospam" in there!
   2) change "hotmail" 2 "myrealbox" after the @



-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug