[sf-lug] interlopers: how to defend oneself against.. (continued)

[Rick Moen]

Quoting Alex Kleider (a_kleider at yahoo.com):

> Rick: 
> a couple of specific questions:
> IS EVERY running process an exposure to attack
> or only those that are LISTENNING?

Good question.

As you'll see in my article "Attacking Linux" (cited earlier), one can divide 
security attacks into those possible only from inside and those that 
can be carried out from outside.   Remote attackers can talk only to 
processes that open network sockets -- plus they can talk to the OS's 
network stack, which serves up those sockets.

(I actually already said all this, just the other day, but I don't mind
restating it once in slightly different words, which is what I've just
done, above.)

You used netstat, earlier:  One of the main attractions of that tool
is to show you what's reachable on what network port.  There are other
tools useful for this, too: fuser, lsof come to mind.

> There are many processes for which there is no man entry.
> Am I on the right track here?

I consider those to be bugs, and actually do file bug reports when I
encounter that situation.  The biggest offenders appear to be GNOME
utilities.  (However, don't forget that some utilities omit manpages in
favour of GNU info format.  Also, don't forget that manpages are
absolutely NOT intended as a learning vehicle:  They're a
quick-reference tool for those who already basically know the tools and
just need to look up details.  You need to find tutorials elsewhere, 
including the /usr/share/doc/[packagename] trees.

> Are you going so far as to say that firewalling is totally redundant?

I've already said otherwise repeatedly -- _to you directly_, even.
Please allow me to quote it back:

  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 also believe I was really clear on this in my responses to John
Reilly:  

  Now, one might conjure up different scenarios where some particular
  IP/port filter might make sense.  What all of them have in common is
  relevant response to a specific threat model.  Let's say that one of
  your users is tying up system bandwidth downloading huge amounts of pr0n
  from the Usenet binaries newsgroups, and rather than doing the obvious
  thing of taking him/her behind the woodshed or kicking the user off,
  you prefer to take technical measures.  Let's say you are willing to
  write off all _other_ users' access to NNTP newsgroups.  So, you put in
  place a netfilter rule blocking outbound connections to 119/tcp.
  Problem solved.



> There may be relevance here with regard to the concept of a DMZ: 

Cheswick and Bellovin's book extensively discusses that model.  You can
and should read the first edition for free, rather than just ask _me_
questions.  ;->

The DMZ concept is an instance of "perimeter-oriented security", in 
which you operate a bunch of highly vulnerable machines and do little 
or nothing about their problems.  Instead, you put some sort of security
perimeter-defence gadget with or without a DMZ network (proxy gateway, 
IP/port filtering ruleset, whatever) between your vulnerable machines
and the bad people.  Security people have a term for this:  the "hard
shell and chewy centre" model -- because, once any one machine on the
inside has been successfully attacked, they all fall and you have
catastrophic loss if integrity everywhere.

My own house LAN eschews perimeter seccurity models, in favour of one
where each host gets individually examined to make sure it can stand
public attack, and where none of those hosts trusts any of the others.
Thus, there is little or no risk of common-mode security failure among
them.


> And finally (for now at least :-) if one would like to be able to ssh
> (including scp and sftp) to a home linux computer (one of several,
> including some MS Windows boxes) on a network, is there a specific
> network architecture that you'd recommend?

You should read up on the subject, and make up your own mind, really.