[sf-lug] interlopers continued

[Rick Moen]

Quoting John Reilly (jr at inconspicuous.org):

> >If you disagree, let's discuss the specific example of my server,
> >linuxmafia.com ....
> 
> Yes, I've read the wily hacker (years ago)....

Probably quite a few years ago, since the book's title _isn't_ 
"The Wily Hacker".  (That's part of the subtitle.)

> ...and I agree that software should be written & configured so that it
> is secure.  A filtering firewall just gives you an extra line of
> defense.

Let's talk about that "defence".

Before you exit with the above handwave, I'd like to re-descend waaaayyy
down the abstraction ladder to discuss that specific example I had in
mind -- my server.  Or, if you feel somehow uncomfortable talking about
that machine, imagine it's someone else's.  For that matter, if you keep
reading, you'll observe me widening the scope quite a bit, following
that specific example.

Now, let's assume that the owner of the example box (mine or someone
else's) enables only the specific network services he or she wishes to
be reachable from the public.  

So, literally the only points of attack from any remote network location
are the network daemons -- which the owner specifically intends to be
publicly reachable -- and the OS kernel's network stack.

By definition, the only possible (primary, as opposed to traffic
logging, etc.) function of iptables IP/port filtering is to block
incoming, outgoing, or forwarded traffic.  The outgoing traffic is from
authorised users (or, at least, if not, the owner has bigger problems).
There is no forwarded traffic in this case (not a router).  Inbound
traffic is physically possible only to the specific daemons the owner
decided to run, and to make available to the public.  So, the only
physically possible inbound traffic is what the owner specifically
intended to be allowed.

So, please, do tell us, what is the nature of the "defence" you believe
gets added?  What specifically would you filter out, and why?

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.

I can't help noticing that you nowhere talk about a relevant response to
a specific threat model.  Instead, you make a vague handwave about
"defence in depth".  Pardon my frankness, but that's just a little sad.