[sf-lug] interlopers: how to defend oneself against.. (continued)
rick at linuxmafia.com
Tue Jul 24 14:45:42 PDT 2007
Quoting Alex Kleider (a_kleider at yahoo.com):
> a couple of specific questions:
> IS EVERY running process an exposure to attack
> or only those that are LISTENNING?
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
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
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.
> 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_
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
> 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.
More information about the sf-lug