Re: [cobalt-users] Hacked?? Telnet Connected But Not Activated?

[flash22@xxxxxxx]

On Thu, 19 Apr 2001, Wayne Sagar wrote:

> If I had not done the netstat when I did, I'd never have known that anyone
> was telneting in.. Here's a question though.. If telnet were turned off...
> and someone atttempted to connect... but did not connect.. in my netstat
> report... I would not see "established" correct.. or would I? 

Are you sure they didn't just figure out your admin password and turn
telnet back on ?

aside from that, they would have probably done something that let them
replace inetd.conf ... telnet is fairly ill behaved if you try to run it
as a user or standaloe after inetd has started...

The only time su postgres makes sense is initial setup when initializing
the database, and when making new database users, i doubt the gui does it
indirectly since it can do most things via the SQL interface...

> Another question.. should postgres ever be seen as a "user" logging in as su? 

did you ask rpm to check telnetd ? and postgress? 
did you run 'last' on the off chance you cought the fellow before he
cleaned it ?

log/secure? for IP's that are unusual?

time/date stamp on /etc/passwd, telnetd ? for that matter, anything in
/etc that should be 'old' ;)

tried su postgres yourself to see if it gets you somewhere without a
password?

bash_history for all the possible *user* accounts?

(unfortunatly the fic xobalt did to prevent them from leaking out to web
pages also means they get deleted on logout for normal users)

chkrootkit to find interesting tools? (ps there is a new version with
lion/adore worm checks now)

One good reason to su to postgres is to add/edit a nice user account
without you seeing it ;)

You are aware that portsentry does *NOTHING* for ports are normally used,
it only watches *unused* ports, and only if you tell it to...

netstat should show 'closing' or fin_wait if the connection was just a
connect attempt that failed, , 'established' means they were actually
connected, tho it doesn't mean they logged in, but if you didn't have
telnet listening they shouldn't have got that far, however if you just
disabled telnet access for users in the gui they can because all it does
is disable shells, not telnet

 > 
> Obviously, probably not.. does this give a clue to where this mess might be
> found? 

You didn't think it was gonna be easy investigating did you ? ;)

If you want to truely be serious about figuring what happened take
elmer@xxxxxxx's advice ;)

or at a minimum check out tools appropriate to the (lengthy and painfull
and timeconsuming job) , eg corners tool kit (has utilities to do things
like locating deleted files , timestamp checking etc)

keep in mind an 'expert' might well spent 30+ hours investigating
completly what happened, assume it will take you somewhat longer ....

 > 
> I hate to take it all down rebuild and have it happen again... and again
> and again.. 

Think of it as job security ;lol , it will happen again, if not by the
same way it did this time, then by some new and clever hack found in the
future....make contingency plans for it...

I mean, think worse case anyhow, if yoy logged in and the hard drive blew
up what would you have to do to fix it? this is not really any worse, just
a little unsettling....you were 'violated' in a fashion, it's unnerving..

gsh

Disclaimer: The spelling of words in this document may not reflect the
current specified spelling in the websters new world dictionary.