Subject: Re: Firewall code for 1.0
To: Terry Moore <tmm@mcci.com>
From: Simon J. Gerraty <sjg@zen.void.oz.au>
List: port-i386
Date: 06/25/1995 22:44:58
> We're about to get an Internet feed installed, and the issue of firewalls
> has naturally arisen.  Not being made of money, and being partial to
> NetBSD, I'd like to use a NetBSD/x86 system to do this.  Due to time 

Funny you should ask...

gate.quick.com.au is a NetBSD (-current) firewall (that's _not_ an
invitation :-). 

I'm using Danny Boulet's ipfirewall stuff to filter out address
spoofing and connections to things like portmap,nfs etc.

Coupled to that, my kernel has a couple of trivial mods that:

drop source routed packets (this one has been mentioned by several
folk already...)

drop packets addressed to an interface other than the one they arrived
on (unless it was a loopback interface).

I run separate DNS on inside and outside (thanks to telstra.com.au),
the external DNS contains only the address of my ppp interface so no
one has any excuse for trying to connect to any other...

I've also _hacked_ inetd so that I can give it a list of addresses to
bind to eg. rc.local runs inetd -a 127.0.0.1,eth_addr
and my ip-up script run by ppp runs inetd -a ppp_addr /etc/inetd.ppp
which offers only ftp, telnet (which passes -s to login to require
S/Key) as well as my encrypting stelnet and it runs smap (from TIS
fwtk) on port 25.

Apart from this, zen (alias gate) is pretty open.

Of course firewalls I've built for others are _much_ more restrictive
and I'd usually recommend a separate filtering router but like you, I
can't afford it for myself.

I have the TIS fwtk providing proxies for my other machines, but all
users have accounts on gate anyway... I mainly use the TIS auth server
and smap/smapd to protect sendmail.

While the inetd patches are not something I'm proud of (30 minutes
work one afternoon :-) and I'd be reluctant to pass them around, the
idea of being able to run multiple inetd's is useful.  If someone
feels like doing it properly, I'd be interested...

But, don't do the inetd trick without the kernel patch. Even if you do
have a good filtering router to protect you from bad guys, its bogus
to have something like inetd _think_ it can offer different services
to different interfaces unless the kernel can promise to deliver only
to addresses of interface used.

--sjg