> On Sun, 27 May 2001, Robert Davies wrote:
> > OpenBSD actually has a very interesting possibility for firewalling,
which
> > even Linux 2.4 can't match yet, that is to do packet filtering whilst
> > transparent bridging. A firewall which does not have an IP address you
can
> > connect to, and it's existent is even hidden from you, makes attacking
that
> > box problematic to say the least. Obviously an extra ethernet
interface, or
> > a serial connection to the machine is used for management purposes.
>
> No, quite right, 2.4.x can't do it yet. But 2.2 can - I've just spent a
> sometimes frustrating but in the end very satisfying couple of weeks
> developing a kickstart system for a transparent bridging firewall.
That sounds very nice, presumably you had to use the bridging patches,
rather than a standard kernel?
Personally I prefer to run with standard distro kernel, whenever possible,
as then updating after security fixes is less problematic, patches take much
longer to be updated after clashes, with new kernel releases.
> that it's only an IP firewall so random things like IPX and AppleTalk
> (commonly spat out by printer interface cards) still make it through, thus
> rendering the internal network not entirely silent.
Now this may be why BSD based solutions was regarded as superior in the
discussions I saw of this. Note for pedants, it actually breaks the IP spec
to do this kind of thing, but as TTL is actually defined in seconds not
hops, you could argue a case for bending the rules (besides you save on
updating header checksums :) ). Surely though if you don't route IPX or
Appletalk, you don't really mind when you have this kind of setup :
Internet Router <----> Internet Lan segment <-----> Transparent Packet
Filter <--------> Protected Lan Segment
Both Internet and Protected segments use the same network number. You could
surely simply throw away any IPX or Appletalk packets, using the protocol
field in ethernet standard (I realise that 802.3 screwed up this simple view
of Ethernet framing and IPX uses it, but lets keep that complication out the
picture).
> Still, as most exploits (and almost all the stuff you want to hide) these
> days are IP based, it works very well indeed.
Unless you share a Lan with Win boxes, I believe M$ admitted their whole
netbios protocol was broken in the last year, and claimed it was impossible
to fix.
> The bridge code developers are currently working on the 2.4 kernel tree
> with a little but growing success. Someone made a patch work last week
> against the 2.4 tree but it won't support NAT yet, although in itself
> that's started quite a discussion about "why on earth would you want a
> bridge to do NAT anyway?"...
Hopefully they'll work to get it included in 2.5 development, as a standard
kernel feature, and then back port when the code is stable. Are there
disadvantages of this approach in normal IP use, or can't they get their
patches past Linus?
> http://bridge.sourceforge.net is the place to look, if it's up. A lot of
> sourceforge's pages seem to have disappeared for some reason.
It may be back, amanda.sourceforge.net was down the other week, but back
now, I think sourceforge relocated, or changed some of their servers, I saw
some explanation somewhere or other on the site.
> PS the way to do remote management safely is to have a single IP address
> allowed to connect to the box, using RFC1918 address space. Then
> (obviously) keep that machine nailed down :)
Actually you should run a seperate segment to be absolutely sure, and not
have IP running on the bridging interfaces, otherwise you risk an exploit of
some defect of the kernel IP stack. Similarly if you have a box which auto
starts an HTTPS server, it's best done over a serial line connection on a
non-networked host. Way paranoid to be sure ;)
Rob
--------------------------------------------------------------------
http://www.lug.org.uk http://www.linuxportal.co.uk
http://www.linuxjob.co.uk http://www.linuxshop.co.uk
--------------------------------------------------------------------
This archive was generated by hypermail 2.1.3 : Thu 22 Nov 2001 - 13:13:20 GMT