Hi All,
Does anyone have any experience with using firewalls as edge devices
when BGP is concerned?
Specifically the Palo Alto series of devices.
If so please contact me off list.
Thank you.
Thank you,
Gregory S. Croft
nokia/checkpoint has done this for ages. what's the problem you have?
I'm not having problems... Well, not yet anyways. 
Just investigating to see if there is a reason I shouldn't use a
firewall at the edge versus a dedicated router as well as to see if
anyone can share their specific experience with the PAN devices.
Thanks everyone!
Greg
My concern is whether or not consolidating border router and firewall functions in the same device violates, if not explicitly, then the spirit of the "defense in depth" Internet edge design principle. Here is a link to a Department of Homeland Security document where this is discussed (for control systems, but has general application), but not addressed directly: http://www.inl.gov/technicalpublications/Documents/3375141.pdf
The old Checkpoint/Nokia firewalls consolidated routing and firewall functions, but the question is one of layered defenses, such that it seems intuitive that it is inherently more difficult for the bad actor to penetrate network defenses the more devices that have to be penetrated.
In a message written on Wed, Dec 07, 2011 at 10:19:58AM -0800, Holmes,David A wrote:
My concern is whether or not consolidating border router and firewall functions in the same device violates, if not explicitly, then the spirit of the "defense in depth" Internet edge design principle. Here is a link to a Department of Homeland Security document where this is discussed (for control systems, but has general application), but not addressed directly: http://www.inl.gov/technicalpublications/Documents/3375141.pdf
I don't think you're looking at defense in depth in the right way,
and thus your question doesn't quite make sense.
If you look at the attack vector described in the paper you link
it shows what many of us in the ISP world call the "soft gooey
center". As you see the attacker finds a way to bypass the corporate
firewall, and once inside the network there are no further controls
to prevent the attacker from hopping between corporate desktops,
corporate servers, and eventually a SCADA network.
Defense in depth is about internal compartmentalization. The diagram
shows deploying additional firewalls between corporate LAN users
and corporate servers, and then again between corproate servers and
SCADA networks. The idea is even if the attacker is able to bypass
one firewall, they have to pass through a second to get to another
zone.
Even with a defense in depth design with these multiple firewalls
(really, access control points), there is still the question you
ask, should the checkpoint devices be multiple boxes (e.g. firewall
and IDS in separate chassis) or unified boxes (firewall+IDS in a
single box). It's really a totally orthogonal question.
What defense in depth does not allow you to do (from my understanding)
is consolidate these multiple firewall functions into one large
virtual firewall, because then you're back to a single point of
failure/control.
To summarize, "defense in depth" requires access control and
monitoring between different security zones, and that those access
control devices be not shared with devices handling other zones.
The devices themselves can include multiple functions on a single
device without affecting the strategy.
Is stacking functions on one device a good idea? Well, millions of
residential users do it (firewall+ids+ips all in one), and plenty of
corporate users have had trouble scaling all in one devices. Multiple
devices provides greater opportunity to select best in breed, but adds
more failure points and more things to manage and coorolate. Which
tradeoffs are best for you and your network is something that can't be
easily answered with a rule, or by someone else on the Internet.
do you have power or space concerns?
do you want to have a single point of failure?
do you want to have some limitations in what your devices can effectively do?
you probably want to be able to fail the firewall and maintain some
level of access to the site (the router), you may want to fail the
router but still maintain local network services from the router
south.
don't put all your eggs in one basket, unless you only have 1 U of
space and 1 power plug.
You should only use a dedicate router if you want your network to remain available.
;>
Actually, it sometimes seems as if nobody in the industry understands what 'defense in depth' really means, heh.
'Defense in depth' is a military term of art which equates to 'trading space for time in order to facilitate attrition of enemy forces'. It does not have any real relevance to infosec/opsec; unfortunately, its original meaning has been corrupted and so it is widely (and incorrectly) used in place of the more appropriate 'combined arms approach' or 'jointness' or 'mutual support' or 'layered defense' metaphors. Hannibal's tactics at Cannae are generally cited as the canonical (pardon the pun) example of actual military defense in depth.
;>
> I don't think you're looking at defense in depth in the right way,
Actually, it sometimes seems as if nobody in the industry understands
what 'defense in depth' really means, heh.
On a personal note , it is one of my least favorite terms because it is
overused and generally used by people selling things, and defense in depth
means throw eveything and the kitchen sink at the problem instead of
matching threats / risks / vulnerabilities with security controls and
threat mitigation and management.
Defense in depth = blank check , in too many instances
Yes, layers of security are good.
No, a car with mattresses strapped to both ends is not safer to drive.
Cb
'Defense in depth' is a military term of art which equates to 'trading
space for time in order to facilitate attrition of enemy forces'. It does
not have any real relevance to infosec/opsec; unfortunately, its original
meaning has been corrupted and so it is widely (and incorrectly) used in
place of the more appropriate 'combined arms approach' or 'jointness' or
'mutual support' or 'layered defense' metaphors. Hannibal's tactics at
Cannae are generally cited as the canonical (pardon the pun) example of
actual military defense in depth.
It's something that is used all too often as a handy verbal crutch in sales pitches. I'm wondering how long it is before the text below is lifted verbatim and put into some vendors' sales/marketing materials.
"Our security products are truly best-of-breed - we take defense in depth to a whole new level that none of our competitors can match. We have the breadth and depth of knowledge and a proven track record in the security space to exceed our customers' expectations and deliver the optimum user experience. We can leverage the synergies and cohesion that exist across our product line to tailor a set of deliverables to meet virtually any need."
*ducks* 
jms
Roland,
While I understand that the definition has nothing to do with IT Security there is no question that many folks use the phrase to summarize a layered IT security model.
Edge routers with ACLs to filter white noise go to edge L3/4 firewalls to filter their layer go to load balancers to terminate SSL (not really security I know) which go to L7 firewalls to inspect HTTP just to get to the web server. Then you have the whole layered DMZs for the WEBs/APPs/DBs/inside etc. We employ "defense in depth" and everyone is familiar with the concept even if they are using the phrase incorrectly. And our wonderful federal auditors expect it and call it the same thing.
-Hammer-
"I was a normal American nerd"
-Jack Herer
I wouldn't do it. We have 8 x PA-2050s and run into a lot of wierd bugs.... (just doing web filtering)
David
SSL interception was the most painful -- PaloAlto finally confirmed it as a bug in 3.1.9, havnt upgraded yet. it basicall eats ssl traffic sporadically.
had another issue during go-live where a "commit" caused the box to crash (3.1.9)
and anothere during that same week where a malformed ssl packet crashed the dataplane.
all cases involved significant interruptions because most did not trigger ha-related failovers. palo also support was extremely slow in all cases weve had and from that perspective alone i would not put all of my eggs into it. great box for web filtering from a feature perspective, but my bluecoats were much more stabile in their 4 yr life than the first 2weeks on our 2050s
david.
Doing so very successfully with Fortigate devices.
We run redundant solutions for a number of our customers and have always decoupled the routing and firewalling.
I can think of one situation where the customer manages the BGP and firewall failover on their firewalls, it doesn't work too well.
The issue as I see it is that in the event of a device failure if you only have firewalls you need to keep the firewall session states when failing over to the second device, the BGP sessions will not if in an active passive HA setup whereas user traffic states will. If you run in an active active setup, BGP states will remain up however user traffic states will not always be transferred.
If you're only using one firewall then this is not going to be an issue but it depends if the solution you're deploying has only redundant connectivity or redundant equipment as well.
My experience is mainly using Juniper routers and firewalls so not able to comment on the Palo Alto platform.
Decoupling the two functions gives a much better model from an NSP sales perspective as it means you're able to sell failover with no managed equipment / just managed routers / full solution with routers and firewalls.