[sf-lug] Interlopers/intrusion/linux security (continuation of "interlopers"

[Rick Moen]

Quoting Alex Kleider (a_kleider at yahoo.com):

> If I had sensitive data on my computer I would shut it down as you
> suggest but unless you strongly advise to the contrary, I'm inclined to
> wait and see what happens in the hopes of learning more about all of
> this. They still haven't come back: by the way- if you look back at the
> netstat results you'll see that there were many, 6 or 7, intruders (or
> perhaps more accurately stated: "intrusions.")

Yes, that could be interesting.  The downside risk is, of course, that
any time unknown remote strangers have free rein on your Internet machine
(either root-level or, to a degree, ordinary privilege), you never know 
when they might start doing something criminal and/or reprehensible with
your machine that appears to be coming from you.  However, this risk needs 
to be seen in perspective:  Literally millions of Aunt Tillie-types out 
there are currently running MS-Windows desktop boxes on broadband that they 
don't know are being used by the Russian Mafia to extort money from Internet 
casinos (http://www.igamingnews.com/index.cfm?page=artlisting&tid=4716) or 
are being used as passthrough servers for kiddie porn -- and nobody is 
seeking to prosecute Aunt Tillie.
 
In that context, I feel almost like a fossil in stressing that it's
unsafe and questionable ethics to permit bad guys to use your machine to
attack other people on the Internet:  Millions of clueless Windows users
do it every day, after all.  Suffice it to say that, when faced with what
_seemed_ like root compromise (see footnote), I didn't hesitate to
yank the plug without delay.

> Again thank you Rick for the input you've taken the time to provide.
> I've been reading a lot about security and am reading about
> firewalling/iptables: 

My personal and long-considered view:  Port/IP filtering is mostly a
really _bad_ substitute for not running vulnerable network-facing
software in the first place.  It's not real "hardening", but rather 
a magic talisman wielded by people so they don't have to think about
real hardening.

It's created a situation where, e.g., port 80 is an absolute _sewer_ of
potentially dangerous data, because it's one of the few that damned near
everyone let through their magic-talisman firewalls, and therefore is a
particular focus of attack.[1]

You can fool around with iptables all year long, and never succeed in
blocking a single bit of those attacks.

I realise it's standard advice to deal with Internet security by
deploying port/IP-blocking.  The standard advice is basically rubbish.
Intelligent things _can_ be done with iptables, but it's not the place
to start, and most of what I see done with those rulesets is the
province of gadget freaks, and does nothing for security.

> I thought that you had suggested identd as a method of getting info to
> help with fact finding. I must have gotten mixed up with something
> else.

What I was saying is that it's very common for genuine IRC servers to
probe back to the IPs of logged-in IRC users on the ident/auth port, to
"verify" that there's a real user on the client machine, as opposed to
an instance of an IRC infobot.  (The latter is an entirely different
usage of the term "bot" in an entirely different context, and should not
be confused with references to zombie "bot" processes.)  

That is, it's the policy of many IRC networks -- or was when last I
checked -- that you as a user must be vettable using ident/auth
callbacks, or will be subject to restrictions, because the network
operators seek to restrict the number and activity levels of infobots
logged onto their IRC channels.

Therefore, it would be common for an incoming identd connection to exist
at some time when a real, authorised local user is using IRC.

> I've installed and run nmap and it has given me some interesting
> results , some surprises and some things I don't understand.

Please note that there are multiple modes in which nmap can run, doing
some quite different things.  Here are some example ways to run it:

# nmap -vv -sT -sR -O -I -oN nmap-tcp.log -n 10.0.1.3
# nmap -vv -sU -sR -O -n -oN nmap-udp.log -n 10.0.1.3
# nmap -vv -sA -sR -O -n -oN nmap-ack.log -n 10.0.1.3

You can look up what those do.  ;->

[1] As Asheesh says, many recent security exploits have been attacks
against badly written Web apps.  In February 2005, I was caught napping
by exactly such an app:  I made the foolish assumption of thinking that,
if Debian packaged the AWstats utility, it must be safely configured for
deployment on my public-facing Web site, and didn't realise my error
until a few months later when my site front page was suddenly "defaced"
(replaced) by some kiddie in Brazil.  

On the spur of the moment, I overreacted and assumed root compromise:  
I completely rebuilt the server, on that assumption, which on reflection 
was almost certainly incorrect.  Details here:
http://linuxmafia.com/news.html

More about the threat against badly written Web apps in this essay:
http://linuxmafia.com/~rick/faq/index.php?page=virus#virus5  Note in
particular my analysis of "Lupper".

Web apps are a particular threat because (1) most sysadmins deploy them
outside their distros' package systems, meaning they receive zero
semiautomated updates unlike the rest of the system, (2) they are public
facing, and (3) many are utterly inept and devoid of any attempt at
input-validation, having been written by naive and/or novice
programmers, often but not always in PHP.

-- 
Cheers,                      I have a mind like a steel trap.
Rick Moen                    Rusty, and illegal in thirty-seven states.
rick at linuxmafia.com