On Wed, 12 Jun 2002, Dave Row wrote:
> For security reasons, I don't like the idea of tunneling OSPF through the
> firewall (via GRE or whatever), because there's no way for the firewall to
> apply policy to the tunnel traffic (if the tunnel were maliciously used to
> pass non-OSPF traffic, the firewall would be oblivious).
You can firewall at the tunnel endpoint to some extent as well.
> Many contributors out there seem to feel that passing routing info across a
> firewall is a "bad thing." A firewall *is* a router (and by virtue, it has
$nitpick: Firewalls don't *have* to be routers, bridge mode firewalls
exist.
> an obligation to participate in enterprise routing), but let's consider
> real-life needs, such as bringing B2B connections through your firewall (a
> "good thing"). If I have frame and VPN routers sitting on an isolated leg
I'm not sure that's always a "good thing"- I tend to prefer mutually
exclusive demarcs with shared resources and replication mechanisms to
tunneling external traffic into the network core.
> of the firewall, I *certainly* need to know about those routes as they pop
> up and down (static = "bad thing"). Although I do not terminate VPN
> connections *on* my firewalls, the firewall should be able to inject those
> routes into your routing environment, as well.
I'm not sure this follows- unless you terminate such routes redundantly in
different physical locations, the routes should all go out the firewall,
and having static routes to the firewall makes that easy (indication of
link/route state doesn't *need* to be done inband.) Dynamic routing adds
an attackable layer to your infrastructure, and needs locking down pretty
tightly (I prefer BGP4 to OSPF for this, mostly because I feel it gives
more control- but I still wouldn't cross iBGP/eBGP groups on the firewall
itself.)
> Now, I'm now trying to locate an OSPF product that can be installed *on* the
> firewall. The Nokia implementation natively supports several routing
> protocols, but I'm running v4.1 SP5 on NT Enterprise. I'm not concerned
> about the security implications, because it's easy enough to block OSPF
> on/from interfaces, hosts, nets, etc. GateD *sounded* cool, until I learned
> that it's only available on Unix (comments withheld, so please point your
> flame throwers elsewhere).
I wouldn't run something like Gated on my best competitor's
firewal infrastructure. Given the complexities of OSPF, I'm pretty sure
that would go on the same list- compromise of routing infrastructure is
increasingly common, so relying on that to do protection around the
firewall in a complex environment is dicey.
> So, does anyone out there have a recommendation for (or any successes with)
> an OSPF module that can be installed under NT/2000? Much appreciated.
Before I did that, I'd consider simpler solutions, like a client that
watched the routing table on the router and re-fed the route into the
infrastructure when it changed with its new location (assuming again that
there were two different places the route had to go depending on link
state.) That would give a lot more control over implementation without
introducing complex protocols and configuration issues to the equation.
There's also no reason you couldn't set up bridges/routers to bump the TTL
up on hello and LSA packets if you want to pass it through the firewall. I
expect that'd be fairly trivial code to write if it's not easily done with
something like netfilter/ipchains/pf/ipfw/ipfilter (heck you could just
set the stacks on the bridges/routers to increment *every* TTL, place a
bridge-mode kernel on a floppy and pop in a box on each side of the
firewall. The Linux Router Project kernel would probably be a good place
to start for proof of concept- I'd expect something like chaging:
if (iph->ttl <= 1)
goto too_many_hops;
to:
iph->ttl += 2;
(Assuming routing rather than bridging)
in net/ipv4/ip_forward.c on a 2.4.x kernel (or the appropriate stuff in a
2.2 kernel if that's what LRP uses) would produce the appropriate
results[1].
Lastly, you could probably try to compile ospfd (www.ospf.org) under
CygWin (or indeed Gated) if you're stuck on running such a beast on the
firewall itself.
Paul
[1] Quick glance only- so checking more carefully is appropriate, don't
forget multicast routing, appropriate service nuking is necessary in
anything sharing layer 2 with a firewall.
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
--
Firewalls mailing list - [ [EMAIL PROTECTED] ]
To unsubscribe: http://www.isc.org/services/public/lists/firewalls.html
