Running OSPF across a firewall

When I was reading Joe Harris' post detailing how you can run OSPF across a PIX/ASA firewall (not with it, but between the adjacent routers), I wondered why anyone would want to do it. Our security gurus immediately gave me an answer: suppose you have two separate DMZs similar to the following setup:

You definitely don't want to attract traffic to a DMZ if the Internet uplink is down. One of the ways to handle it is to conditionally source the OSPF default route on the outside routers (based on availability of BGP prefixes, for example) and pass it to the inside routers that propagate it to the rest of the network.

The question that remains to be answered is “why wouldn't you run OSPF with the firewall?” If nothing else, if someone breaks into the outside router, he could manipulate the IP routing on the firewall, which is definitely not a good idea (you can't filter routing updates in OSPF like you can in RIP, EIGRP or BGP).

7 comments:

  1. That's crazy, IMHO.
    I think the reason SOME people still don't want to run a routing protocol in the firewall isn't a technical/security one - but a trust issue/political issue/who does what issue.
    We know that in past times (not so long, and still being done) the network guys were in charge of the routers/switches/etc, while the security folks were in charge of the firewall/IDS/VPN devices, etc. And neither group trusted each other - and heck, for sure the security folks wouldn't trust any route they got from the network folks. "Gimme a default to rule them all" - very Tolkien - was SECOPS approach.
    And it isn't a security concern at all. Heck, I've seen BIG customers running RIP on their CHKP firewalls - without even plain text authentication. So don't give me the security excuse ;)
    So let's see the pros and cons of using OSPF on the firewall vs static routes:
    * using OSPF allows the firewall to actually react to network topology changes - both internal _and_ external. Specially relevant in HA scenarios
    * the static routes don't allow for dynamic changes - not to mention they're a PITA to maintain. I've seen more than once people getting "cut off" the Internet 'cause someone changed the Internet facing router, did some addressing changes - but SNAFU, the firewall folks weren't notified, or were, but they didn't apply the change
    * security-wise, running OSPF with MD5 authentication should be good enuf to leave bogus routing updates out. And as you yourself say - if someone was to get control of the router in front of the firewall, all bets are off - no matter if using OSPF or static routing. Heck, if *I* was to get control of that router, I wouldn't mess with the routing at all - I *want* for the traffic to come my way, so I can do something like policy routing, and shoot the traffic I'm interested in down a GRE tunnel to a remote place where I can capture, analyze, on-the-fly modify and reinject.

    It is, IMHO, once again the problem of "not doing the risk assesment right". If anyone actually sat down and DID the risk assesment/value proposition of sticking to the '80s and using static routes vs joining us all in 2007 and doing OSPF . . .

    And on top of that - if the firewall is doing a "default-information originate", it would be better to also have a sinkhole on the internal network doing the same - with a higher metric - so if the default on the firewall was to dissapear because the Internet-facing router went down, traffic wouldn't go to the firewall - but to the sinkhole, where it could be sent to null0 - and everyone's now happy.

    Or if you don't want to transport the traffic all the way to the sinkhole, just to drop it, do the good old "remote triggered blackhole routing" over BGP.
    Come on - there are many ways to skin this particular cat. Sticking to "no routing protocol on the firewall" it only shows whoever says so doesn't know his business.

    ReplyDelete
  2. Ivan, I see some discrepance between your statement "you can't filter routing updates in OSPF" and the docs at http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a00804556f4.html - may you explain it a bit more?

    ReplyDelete
  3. You mean http://tinyurl.com/2ydr9t ?

    ReplyDelete
  4. @anonymous: That's available in IOS, not in PIX/ASA, which is a few releases behind IOS in OSPF functionality.

    @BlueDemon: I guess we agree to disagree :) As you've said, “I think the reason SOME people still don't want to run a routing protocol in the firewall isn't a technical/security one - but a trust issue/political issue/who does what issue.” … and I agree with you completely, but I disagree with the security implications.

    Your statement that “Heck, I've seen BIG customers running RIP on their CHKP firewalls - without even plain text authentication.” is also true, but that does not necessarily imply that what they're doing is secure, only that they feel it's secure enough for them (or haven't been bitten yet). If someone big or important is doing something, that doesn't mean it's a smart thing to do.

    I also mostly agree with your statements about static vs. dynamic routing (I am absolutely not a proponent of static routes, as you probably know :).

    However (and I will not go any deeper), there is a good reason someone a long time (probably hundreds of years) ago started talking about defense in depth. If you link your external router and your firewall, you've just weakened your second line of defense. Whether that's important enough or negligible is a personal opinion (and here's where we differ).

    Other than that, thanks for a great comment ;)

    ReplyDelete
  5. Although this is a nice trick to get OSPF peering to work "across" the PIX/ASA, however this leaves the PIX/ASA in the dark as far as how and when to route/re-route traffic out via different interfaces. Any routing changes on the outside or inside router will not be seen by the PIX/ASA, thus the firewall can potentially blackhole the traffic.

    Cisco had gone great length to implement OSPF and EIGRP on these smart firewalls so we should enable routing protocols to allow the firewall to make smart routing decision when routing change occurs.

    ReplyDelete
  6. Hey, Ivan:

    My comment about RIP was meant as an example of "how to do the right thing the wrong way". I was speechless when I saw that - and I had to take a couple deep breaths - I was about to blurb "this rates about 11 on the 1-to-10 scale of moronic" ;)

    And I spent a couple more mins thinking about this while walking the dog (mind-numbing task if there's such a thing). static routing from the firewall to the internal network, or a static default from the internal network pointing to the firewall brings an interesting concept/idea to the table - whoever is doing that trust s the ARP protocol more than OSPF with MD5 ;)

    Sooner or later, someone (router or firewall) will need to ARP for the other guy MAC - good time then to do some ARP spoofing and redirect traffic.

    yeah, yeah, needs L2 access - I would bet getting said L2 access would be easier than compromising the router/firewall to change routing - all things being equal, and asumming a password != 'cisco' on any device ;)

    ReplyDelete
  7. RV; vr_vp@yahoo.com13 August, 2008 20:50

    I tried running OSPF between 2 routers across a firewall, by establshing a GRE tunnel and running OSPF through it. This takes care of the Hello packets (they have a TTL of 1) also.

    The only hitch is that the firewall must support the pass-through of GRE.

    I was also looking for a solution to run the OSPF across a fiewwall without using a GRE tunnel. One can configure the connected interfaces (with the firewall in between behaving like a router) not to broadcast (in our case multicast) OSPF. But then this stops the Hello packets also.

    Is there any way to sort of unicast the Hello packets across the Firewall? And to increase the TTL of Hello packets to more than 1?

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.