[SunHELP] Problem with Inetd

[Phil Stracchino]

On Fri, Apr 02, 2004 at 11:30:49AM +0530, Charu Kamath wrote:
> Thanks for replying.
> The intruder is form our own organisation, though he used a common username
> hence could not trace the real culprit.I have the logs for the same.
> Mar 28 11:30:09 dnsblr.estel.net.in in.telnetd[28330]: connect from a.b.c.d
> blr       pts/3        a.b.c.d   Sun Mar 28 11:30 - 11:35  (00:05)
> 
> So u see just when he logged out from my machine.The logs have come to a
> halt.
> I already have TCP wrappers in place.And unfortunately have to permit access
> to a.b.c.d which is the primary server.
> 
> can i just add an entry manually in my /etc/services file for dtspc. I
> already have thestatement for dtspc daemon in /etc/inetd.conf

If you weren't running dtspcd before, starting it now isn't going to
make life any better.  In particular, if you were getting along without
it before, there's no reason to start it now, and in particular, doing
so without first making sure the vulnerability in CERT CA-2001-31
(Buffer Overflow in CDE Subprocess Control Service) is patched would not
be the brightest thing you could possibly do at this point.

I reiterate: Services on the machine which only root should be able to
affect are not operating as they should.  Logging from the machine,
which only root should be able to disable, is not working.  You have no
logs of the intrusion attempt beyond the apparently-failed dtspcd
exploit attempt.  You do not know that the attacker did not achieve
root.  You do not know that the machine is not compromised (in fact,
the evidence rather suggests that it is).  You know that the connection
came from one of your own machines, and you do not know that machine is
not also compromised.  Assuming logs on the machine a.b.c.d above are
intact, they should show you who was logged in at that time and from
where, and you should be able to determine who had access to that
machine at that time.  If they're not intact, you should assume that
machine has been compromised.

You have two possible situations here:  (1) someone in your organization
is breaking into your own machines, for possibly nefarious purposes, and
is leaving them in conditions in which they are not performing their
intended function.  Or (2) someone outside your organization has
compromised at least one machine, possibly multiple machines, at your
organization and is using them to attack and compromise other machines
at your organization (and possibly elsewhere).

Either way, you have a serious problem that you cannot fix by just
restarting the services and covering up the damage.  You need to
ascertain which machines have been compromised, you need to isolate
them, you need to replace all suspect binaries (or preferably just
reinstall the systems), and you need to secure them properly so it
doesn't happen again.  Starting dtspcd, or restarting syslogd, is not
going to achieve any of these things.



-- 
 .*********  Fight Back!  It may not be just YOUR life at risk.  *********.
 : phil stracchino : unix ronin : renaissance man : mystic zen biker geek :
 :  alaric at caerllewys.net|phil-stracchino at earthlink.net|phil at novylen.net  :
 :   2000 CBR929RR, 1991 VFR750F3 (foully murdered), 1986 VF500F (sold)   :
 :    Linux Now!   ...Because friends don't let friends use Microsoft.    :