On Oct 9, 2006, at 11:40 AM, Steven M. Bellovin wrote:
[ ... ]
> In any event, my machine effectively does do 'default deny', in  
> that it
> returns a TCP RST or an ICMP Port Unreachable for packets addressed to
> services that aren't running.

If you were running with no services listening, the behavior of your  
machine would be identical to "default deny", agreed.

However, as you've noted, once you start having services listening,  
especially on dynamically allocated random ports (ala portmap)  
without a firewall, your client machine no longer is doing "default  
deny".  Whereas, if you set up a firewall to block all ports but the  
specific ones permitted, adding new services which listen on  
additional other ports would not make a difference.

>>> Who said anything about routing, firewalls, or NAT?  Not I.
>>
>> You stated that you had a multihomed machine which you wanted to use
>> for filesharing but over only one interface.  You also stated "An
>> obvious approach is to use pf or ipf....", which certainly appears to
>> mean that you did say something something about using firewalls.
>
> The purpose of a firewall is two-fold: to protect machines that can't
> protect themselves, and to provide protection at scale.

I would say that the purpose of a firewall is to implement the  
network's security policy at a "chokepoint" through which all network  
traffic must pass.

I would agree that a firewall is intended to protect machines or  
services which cannot easily be protected themselves, and that it is  
much easier to configure, test, audit, and maintain a single firewall  
than to maintain host-based protection on a bunch of clients,  
especially as the number of client hosts grows.

> I have a small number of similar machines, so scale isn't the  
> issue.  The question is
> whether or not the machine can protect itself.  We've already  
> established,
> I think, that most of the services I mentioned have no access  
> control, let
> alone a more sophisticated way of ignoring packets from unwanted  
> sources.
> I was contemplating using pf or ipf -- as I frequently do -- for host
> security.  For example, my preferred IM client (psi) listens on  
> port 8010
> for file transfer.  That's not a service I need or want, but  
> there's no
> way to disable it that I've found.  Instead, I use a packet filter to
> block it.  That's a lot harder to do with RPC services, for reasons we
> both understand.

If you explicitly list port 8010 in the local machines' firewall  
rules to block that one port in particular, note that your host  
security is using a "default permit" model, rather than "default deny".

>>> The situation is more like this.  I have several machines A, B,  
>>> and C
>>> that are exposed to the Internet.  They also need to share files  
>>> among
>>> themselves via NFS, on a separate LAN.  I want to make sure that  
>>> nasty
>>> packets don't get to the NFS-related services on these machines.
>>
>> I would not want to run NFS filesharing on an machine directly
>> connected to the Internet without having a firewall in the way.
>
> Ah -- but why?  I agree that one shouldn't run NFS without *something*
> blocking those services.  Must it be an external box?  Or does  
> NetBSD have
> the ability to do it itself?

I believe that NetBSD's firewalls could be used to control access to  
NFS on one interface, if you were using a "default deny" host policy  
and only listed a handful of permitted ports.

I also believe that firewalls should be dedicated to that role and  
should not offer unrelated services like filesharing, because the  
compromise of a firewall is more dangerous to the network than the  
compromise of an individual host, and because the vulnerability of  
any system, including firewalls, becomes much greater as more  
services and open ports are added to that system.

>>> I could, I suppose, create machine D, which is only on the back end
>>> LAN; it could be the common file server.  For various reasons,  
>>> that's not an
>>> ideal solution, though I may resort to it.
>>
>> That's probably the best solution in terms of security, however.
>
> It may be the best answer today.  I'm still looking for a better  
> answer for tomorrow...

Implementing NFSv4 and SecureRPC in NetBSD, perhaps...?

>>> It also leaves open the question of keeping fake responses away
>>> from the NFS clients on A, B, and C.
>>
>> Use a firewall to block IP loose and strict source routing, as well
>> as the (presumably) RFC-1918 subnet being used for your LAN, so that
>> traffic on your internal LAN cannot be spoofed from outside.
>>
> Presumably, setting net.inet.ip.forwsrcrt=0 will accomplish that.   
> There's
> also net.inet.ip.checkinterface.

Yes, presumably...although I'm not completely sure whether things  
like using fragmented packets might be able to get around the  
checking done by that sysctl.  If packet reassembly is done by NetBSD  
before checking for the forwarding via source-routing, all is well,  
otherwise that option may not provide effective security.

> We seem to be talking past each other, and the tone has turned a bit
> unpleasant.  Let's both calm down and assume that each of us knows  
> what
> we're talking about.

It would be a pleasure to have a polite and reasonable discussion  
about this problem-domain that you've brought up, and I would be  
happy to assume that you know what you're talking about.  On the  
other hand, I can only respond to what you've said, not what you  
might have thought or might have intended to say.

-- 
-Chuck