Re: OSPF *on* Check Point FW-1
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
RE: OSPF *on* Check Point FW-1
Thanx for the thoughtful response. It appears that we've got a good group of people on the list. I would still venture that in most implementations, firewalls provide a superset of a router's functionality, because they look at packets, determine source/destination, and send the data on their merry way (within the context of a security policy, of course). In addition, a firewall can perform NAT. I look at my firewalls as routers with a cool GUI alternative to router ACLs, and a kick-ass L3+ state table. You know, similar to the argument that Unix is DOS on steroids (OK, OK, belay my last!). =8O I also stand behind my assertion that it's the firewall's *obligation* (whether or not you take advantage of it) to be able to communicate routes about which it *solely* has knowledge (sorry if the manufacturers cringe while facing that responsibility!). In my case, I have VPN gear and frame relay routers hanging off a second DMZ. Many of you probably are using your firewalls to terminate VPN tunnels. Aside from the easy cases, such as single-user aggressive-mode clients to whom you dole out IPs from a well-known pool (you probably have statics already in place in your internal routing environment), wouldn't you like to know when a branch office comes up? What about when the same branch decides to pop up on a different gateway? I'll venture that no one will fault me for wanting to firewall all of these types of connections, yet no one seems to think that the internal network needs to know how to reach hosts at the end of these connections? Perhaps I'm the only one trying to leave static-ville... Ideally, resources accessed by those connection types would be isolated, but that's simply not feasible for some resources (eg. a 2nd instance of our SAP environment would be *very* expensive to provide, and my sanity would be further questioned, but I digress...). BTW, how can *I* own my very own Phillips hammer? Dave Row CCNA, MCSE, CCSA Senior Network Analyst -Original Message- From: Brian Ford [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 12, 2002 4:09 PM To: Dave Row Cc: [EMAIL PROTECTED] Subject: Re: OSPF *on* Check Point FW-1 Dave, I've been monitoring/researching threads re: OSPF neighbors separated by a firewall. I've worked and worked on this, and have given up on the notion (BTW, it boils down to hellos [both multicast and unicast] being sent with a TTL of 1, *not* simply opening the right ports/protocols). Too many people that have never touched a sniffer keep commenting on this OSPF issue. Good stuff. I'd agree with your assessment. 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). Your words imply that you view Firewalls as the only security mechanism or policy enforcement point in your network. That could be (in your case). Tunneling is a viable option for lots of scenarios. Policy enforcement and route pruning can be done elsewhere (on devices other than Firewalls). 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 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 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. A Firewall is not necessarily a router (But boy if it was you'd make lots of folks where I work happy). It's a policy enforcement point between two networks and a packet forwarder. It's not necessarily a router as not all forwarders perform all routing functions. I'm certain several Firewall manufacturers are cringing at your assertion that Firewalls have an obligation to participate in enterprise routing. I believe that much of the bad thing tag comes from the fact that in many environments security policies are enforced differently at different sites. Do you want every computer in a branch to know about all the routes to other branches as well as the entire HQ network? Well, maybe you do and maybe your security policies are up to securing that data. Now, I'm now trying to locate an OSPF product that can be installed *on* the firewall. Good luck. If you are ever looking for a hammer that also has a Phillips head screw driver built in; let me know. I know a place where you can buy those. Liberty for All, Brian At 12:01 PM 6/12/2002 -0700, [EMAIL PROTECTED] wrote: Message: 1 From: Dave Row [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: OSPF
Re: OSPF *on* Check Point FW-1
Dave, I've been monitoring/researching threads re: OSPF neighbors separated by a firewall. I've worked and worked on this, and have given up on the notion (BTW, it boils down to hellos [both multicast and unicast] being sent with a TTL of 1, *not* simply opening the right ports/protocols). Too many people that have never touched a sniffer keep commenting on this OSPF issue. Good stuff. I'd agree with your assessment. 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). Your words imply that you view Firewalls as the only security mechanism or policy enforcement point in your network. That could be (in your case). Tunneling is a viable option for lots of scenarios. Policy enforcement and route pruning can be done elsewhere (on devices other than Firewalls). 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 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 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. A Firewall is not necessarily a router (But boy if it was you'd make lots of folks where I work happy). It's a policy enforcement point between two networks and a packet forwarder. It's not necessarily a router as not all forwarders perform all routing functions. I'm certain several Firewall manufacturers are cringing at your assertion that Firewalls have an obligation to participate in enterprise routing. I believe that much of the bad thing tag comes from the fact that in many environments security policies are enforced differently at different sites. Do you want every computer in a branch to know about all the routes to other branches as well as the entire HQ network? Well, maybe you do and maybe your security policies are up to securing that data. Now, I'm now trying to locate an OSPF product that can be installed *on* the firewall. Good luck. If you are ever looking for a hammer that also has a Phillips head screw driver built in; let me know. I know a place where you can buy those. Liberty for All, Brian At 12:01 PM 6/12/2002 -0700, [EMAIL PROTECTED] wrote: Message: 1 From: Dave Row [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: OSPF *on* Check Point FW-1 Date: Wed, 12 Jun 2002 11:06:43 -0400 Howdy, folks. I've been monitoring/researching threads re: OSPF neighbors separated by a firewall. I've worked and worked on this, and have given up on the notion (BTW, it boils down to hellos [both multicast and unicast] being sent with a TTL of 1, *not* simply opening the right ports/protocols). Too many people that have never touched a sniffer keep commenting on this OSPF issue. Onward... 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). 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 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 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. 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). 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. Dave Row CCNA, MCSE, CCSA Senior Network Analyst ___ Firewalls mailing list [EMAIL PROTECTED] For Account Management
RE: OSPF *on* Check Point FW-1
Dave, W2K Server comes with an optional routing package that includes OSPF. For NT you can install the Routing and RAS package which also includes OSPF: http://www.microsoft.com/ntserver/nts/downloads/winfeatures/rras/rrasdown.a sp I played around with the RR package in a lab some time ago and it was functional, YMMV. HTH, Kent - Howdy, folks. I've been monitoring/researching threads re: OSPF neighbors separated by a firewall. I've worked and worked on this, and have given up on the notion (BTW, it boils down to hellos [both multicast and unicast] being sent with a TTL of 1, *not* simply opening the right ports/protocols). Too many people that have never touched a sniffer keep commenting on this OSPF issue. Onward... 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). 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 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 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. 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). 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. Dave Row CCNA, MCSE, CCSA Senior Network Analyst -- Firewalls mailing list - [ [EMAIL PROTECTED] ] To unsubscribe: http://www.isc.org/services/public/lists/firewalls.html
