[sf-lug] interlopers continued

[Rick Moen]

Quoting Alex Kleider (a_kleider at yahoo.com):

> I agree that the above seems a reasonable assumption but in fact before
> these connections got established, I'd never heard of IRC and had not
> been surfing the web at all.

Some of your netstat output seemed -- on initial reading -- to suggest
that a (real, authorised) user was locally using an IRC client.  I'm
starting to get the strong impression that I misread in that particular,
too.

I was (again, perhaps hastily) assuming that's authorised traffic that
was already known to you, or otherwise you would have said something
about it.  (As may be apparent, I read your initial post too quickly,
and responded mostly on the basis of the first two sentences, right up
to your typo:  Your post seemed on first glance ended up looking very
similar to many others where people install a logfile analyser and freak
out at, essentially, portscanning.)

If there is _not_ a local authorised user on the machine who's using
IRC, then you indeed would seem to have a security breach of some sort.
See below, especially as to my explanation of the term "bot".

Do I correctly guess that this is a single-user box you're inquiring
about?  (I'm not sure you said, exactly.)  If so, that again lends
credence to your suggestion that there's a security problem.  I'm
accustomed to mostly multiuser boxes, and so wasn't in your case
initially assuming that you'd necessarily _know_ if a real, authorised
local user was doing IRC.

Security compromises divide into user-level and root-level.  Typically,
the bad guys find a way (various) to either SSH in directly or to
otherwise remotely manipulate files using the privilege levels on your
system characteristic of a non-root regular user.  Then, sometimes, as a
separate step, they find a separate weakness in internal system security
that allows them to escalate privilege to root-user-level.  If and when
they carry out that second step, their usual next step is to install a
"rootkit".  

Popular reporting to the contrary, a rootkit is not an attack tool of
any sort.  It's a toolkit to compile replacements for a dozen or so key
system utilities that are normally useful for monitoring system
activity.  The replacements are "trojaned" (as the expression goes) to 
(1) hide the intruder's own activity from sysadmin view, and sometimes
also (2) give the intruder a means of covertly re-entering the system if
the sysadmin attempts to throw him/her off.

As you might predict, one of the main utilities a rootkit would
ordinarily replace is netstat.  The fact that you see suspicious
activity when using netstat is strong evidence that no rootkit has been
installed, and also argues somewhat more weakly against root
compromise.  (A _competent and careful_ intruder -- or, more likely,
his/her automated scripts -- would immediately follow up a root
compromise with a rootkit installation, but it's likely there are a
large number of intruders, these days, who don't bother to do a
competent job, and make up their losses in volume.)

When a sysadmin _does_ determine (or strongly suspect) that root
compromise has occurred, the only reasonable remedy is one that's clear
and well-studied, but also a bit painful:  You literally yank the power
cable, in order to take down the system without triggering any logic
bombs that might be set to occur during normal shutdown.  You then boot
the system using maintenance media only (e.g., a live CD), to make a
data backup and study the system, to try to learn more about what
happened.  When you're done studying, you reformat all the hard drives,
reload from trusted OS media, study your security profile and lock the 
system down to _try_ to head off what you believe was the avenue of
compromise, then restore data files only (no scripts, no libraries, no
programs, no dotfiles) from your backup set, and rebuild the desired
system configuration by hand, consulting the prior configuration files
for reference but carefully not reusing them directly.  Last, you set
all new passwords for your users and invite them back in after talking
to them about security.

A pair of classic write-ups:
http://www.cert.org/tech_tips/root_compromise.html
http://www.cert.org/tech_tips/intruder_detection_checklist.html

What do you do if, after some careful study, you're pretty sure there
has been no root compromise?  In that case, I suppose you find out which
local user the dodgy activity is running as, track down whatever that
user has, or is doing, that makes that possible, and deep-six whatever
that is.

If you honestly cannot tell, then maybe you would be best off assuming
that the system _is_ root-compromised.


> What is a "bot?"

In this context, "bot" (obviously, from "robot", which goes back to Karl 
Capek's play in the 1930s) refers to a process that runs on a computer
and is remotely controllable over networks, most often for nefarious
purposes.  Computer criminals in recent years have used security
vulnerabilities in commonly used software to deploy bots onto a huge
number of computers owned by anyone and everyone.  Those bots then run
in background and wait for a signal from the person who controls a
"herd" of bots on what might be tens of thousands of -- or, in at least
one documented case, over a million (other people's) computers.   Such a
computer, running under the influence of that sort of bot, is dubbed a
"zombie".

That signal might be to send out some particular type of spam to a large
list of IP addresses.  Or it might be to perform a coordinated mass
traffic attack (a "distributed denial-of-service" or DDoS attack) on
some target host.  Or something else -- pretty much inevitably something
the computer's owner wouldn't want it to do.

See:  http://en.wikipedia.org/wiki/Botnet

The most common signalling channel for those computer criminals to give
commands to the zombie hosts is... IRC.

> identd seems to generate no output.

Um... see the "d" on the end of "identd"?  It stands for "daemon".  In
Unix, a daemon is a program that isn't invoked explicitly, but rather
runs as a background process.  Normally, users don't deal directly with
daemons, and so they tend not to say much to users in return.

Here's another, probably relevant article I wrote quite a few years ago
(1999, I think?):  
http://security.itworld.com/4352/LWD000829hacking/pfindex.html

-- 
Your font is:      Proportional  Monospaced
                                      ^
Matt McIrvin's amazing Font-o-Meter!