Some firewall vendors are proposing to collapse all Internet edge functions into a single device (border router, firewall, IPS, caching engine, proxy, etc.). A general Internet edge design principle has been the "defense in depth" concept. Is anyone collapsing all Internet edge functions into one device?
Regards,
David
I personally have not seen it done in large environments. Hardware isn't there yet. I've seen it done in small business environments. Not a fan of the idea.
-Hammer-
"I was a normal American nerd"
-Jack Herer
I have seen at quite a few of our customers locations, starting out with a lofty goal of putting everything in a single box (UTM) and turning every single option on.
In ~ 30% of the firms who do so it works out ok (not great, but it works). In the majority, the customer winds up turning features off one by one, and moving those to another system.
Jim
They're proposing that so you buy their device, not renew support on
your existing ones 
Personally we just went through this w/ Palo Alto Networks. We bought
a handful of their all-in-one firewalls simply for their web-filtering
functionality (replacing Bluecoats). They pitched repetitively that
we should replace all of our firewalls with just their box and
collapse it.
I must say, from a support perspective, the concept of "this box does
web filtering, and that box handles the firewall of our public facing
servers" is worth it's weight in gold. Web filtering alone can get
stupid complex if you let it. Do you really want to troubleshoot an
inbound web server issue while trying to sort through rules like "Jeff
is allowed to get to Facebook, Marketing can get to Twitter, HR can
see everything, oh wait here's the DMZ rules....".
Boxes are cheap in an environment where staffing is lean. In SoHo,
and smaller SMBs I could see it being different... we're on the larger
of the "medium business" / small Enterprise side of the fence.
David.
I would argue that collapsing all of your policy evaluation and routing for
a size/zone/area/whatever into one box is actually somewhat detrimental to
stability (and consequently, security to a certain extent).
Cramming every little feature under the sun into one appliance makes for
great glossy brochures and Powerpoint decks, but I just don't think it's
practical.
Take a LAMP hosting operation for example. Which will scale the furthest to
handle the most amount of traffic and stateful sessions: iptables and snort
on each multi-core server, or one massive central box with some interface
hardware and Cavium Octeons.
If built properly, my money's on the distributed setup.
Cheers,
jof
As others have said, this could make sense at the smaller end of the scale (SOHO, branch offices, small shops, etc), but I haven't see an all-in-one box that scales up to the traffic loads or handles things like routing protcools especially well in a large network. The marketing folks will often dance around the issue of throughput dropping as services or modules are turned on, but that's a big problem. I'm perfectly happy having border routers sitting at my borders, doing the routing, and firewalls elsewhere, doing the firewalling 
Another thing to remember is that existing router manufacturers have gotten pretty good (a few exceptions aside) at building pretty stable routing implementations. All-in-one box manufacturers that claim to be able to handle IPv6, BGP, OSPF(v2/v3), etc are basically starting out from scratch and don't have the benefit of the 10+ years of experience that Cisco/Juniper/et al have in building routers.
jms
Yikes... single point of failure. I really dislike the notion that all the security comes down to a single potentially compromisable point. Our security functions like IPS run separate to centralised logging, etc. etc. so that if someone does happen to break in to a particular point there are still further things they need to try to compromise before they can have their wicked way, or whatever it is they want to do.
Sure the economies of a centralised box and the convenience are probably tempting, and it's better than nothing, but I can't picture it actually being an improvement over split out functions.
Paul
To echo what James has already said..
I would say it's possible on the low/medium size enterprise network
market. With that stated 70-80% of the time it's not designed
correctly or a vendor issue pops up causing them to disable the
feature.
Careful planning must be done ahead of time. When looking at the spec
sheets you can't look at the numbers and take them for face value. In
most cases those numbers were achieved when *only* running that
specific feature.
So if a vendor claims 90meg of IPS throughput, 500meg of firewall
throughput and 100meg of UTM. Chances are that 90meg of IPS traffic
will take the box to it's knees. So if you're planning using the data
sheet numbers you've most likely already failed.
Plan carefully, test throughly, and in the end..you still may hit a
bug or unexpected show stopper. I'd rather use the best tool for the
job rather than jam everything into once box so I can share a
chassis...
Just my two cents,
-Tim Eberhard
Hi David. A principle of network firewall design has long been that you want to minimise services (proxy, etc) running there as they can be a vector for attack against the firewall itself.
In the end this is about risk analysis. In most cases I would recommend against loading the firewall with additional functionality, for a variety of reasons. In some cases it may make sense to do so.
This is completely separate to whether servers should even have a firewall or IPS in front of them. That's another (interesting) discussion
Cheers,
Rob
<http://www.nanog.org/meetings/nanog48/presentations/Monday/Kaeo_FilterTrend_ISPSec_N48.pdf>
<http://www.ausnog.net/images/ausnog-05/presentations/7-2-stateofdanger.pdf>
We've been fairly against centralizing functions, even
though marketing scripts suggest it is worth doing.
Not security-related per se, but for smaller PoP's, we'll
collapse P/PE functions into a single box. As others have
mentioned, this makes sense when scale is small.
But on a large scale, we've not been one to buy into multi-
chassis-type arrangements. With boxes getting smaller and
more powerful due to Ethernet being the implicitly agreed-
upon medium, it's still cheaper (and more resilient) to buy
smaller boxes and distribute services than take one large
one and stick them all in there.
I'm hoping the OP can draw a parallel for their own
situation, if this is useful.
Cheers,
Mark.
s/multi-chassis-type/logical routers.
Mark.
1. It's an excellent way to create a single point-of-failure.
2. I prefer, when building defense-in-depth, to build the layers with different
technology running on different operating systems on different architectures.
There's no doubt this adds some complexity and that it requires judicious
design to be scalable, maintainable, and so on. But it raises the bar
for attackers considerably, and it gives defenders a fighting chance of
discovering a breach in one layer before it becomes a breach in all layers.
3. One of the mistakes we all continue to make, whether we have our
paws on integrated appliances or separate systems, is default-permit.
We really need to make sure that the syntactic equivalent of "deny
all from any to any" is the first rule installed in any of these,
and then work from there.
---rsk
p.s. In re Powerpoint, I've long held that the appropriate response to
"I have a PowerPoint presentation..." is for everyone else in the room
to find a strong rope and a sturdy tree, and do what must be done for
the sake of humanity.
"Power corrupts. PowerPoint corrupts absolutely."
As regards avoidance of SPOFs, I also prefer multiple layers in different
technologies &c. A monoculture is horribly vulnerable. I grant that network
hardware isn't exactly Ireland just before the potato famine, but the
parallels are there and applicable in at least some senses.