> I have a question regarding managing policies among multiple sets of > firewalls. I don't know what industry standard / best practice is for > managing rules among multiple devices.
My two cents. When there is really no such a standard, things to keep in mind do exist. Here are some mistakes people tend to make (and I managed to recall): 1. Too many firewalls. The old-school (and, let's be honest, promoted by vendors and their partners) security design style recommends to put a separate firewall for everything. Dedicated internal firewall, dedicated external firewall, dedicated VPN aggregator, dedicated this, dedicated that. Just open any shmeeseeaee-security book, and you'll find lots of the figures like that. Sometimes they looks attractive in PowerPoint but it is unmanageable. Rule of thumb: the fewer statefull devices you have in the network (including virtual ones), the more secure you are. Modern firewalls have enough horse-power for almost everything. 2. Putting each VLAN into a dedicated zone. I believe it's the habit of attaching acl/filters to interfaces, that makes people do this. This mistake implies a lot of zones and complete mess in the policies, which is not what security zones were invented for. The lower number of security zones you pack your interfaces into, the closer you are to the 'Can you mother read it?' rule of thumb for policies. Some logic is required though. Don't get me wrong, I don't mean to put everything into a single zone (as well as I don't mean to have no firewall at all). Normally you put something into a separate zone because you want to isolate it _by default_ (!) from the other zones. 3. But not otherwise! Putting few interfaces into a zone does not mean all traffic is permitted between these interfaces. On SRX you even have to write explicit policies to allow intra-zone traffic. So it's usually OK to put all your DMZ vlans into a single zone and allow only, say, "any to dns/ntp/kerberos using application dns/ntp/kerberos" inside it. 4. Putting all IPSec VPNs into a single zone. This makes the VPNs indistinguishable from security point of view. If the remote side is a branch with users of just same trustiness as your local LAN users, it's probably better to put the tunnel interface into the Trust/LAN/however-you-wish-to-call-it zone. if you have a few tunnel to partners (very often mixed with leased channels), put this all into a special zone 'Partners', but don't put there your tunnels to branches. So on. 5. Items 1 and 4 also mean that dedicated device for IPsec is a particularly bad idea. 6. Complicated routing schemes, especially with FBF/PBR, static /32s and other trash. This is hard to scale in the plain routing sense, but when it comes to security, all the design beauty can be broken with a single clumsy step. Add here the fact that security teams are often not experts in complex routing.However business needs sometimes require this anyway. But when your boss asks to extract particular flow and forward it via Paris when it should normally go through Tokyo together with the rest of traffic, tell him the real cost of the solution and ask to seriously think of the benefits and losses. If the trick is really needed, try to use only routing with no additional security constructions. 7. Particularizing policies with very-specific address-objects. Also very effective way to turn your policies into a real nightmare. To have a well-designed network security, first you need well-designed network. Well-organized VLANs, addressing, 802.1X --- all this makes your firewall config much smoother. In the ideal case you should be able to use 'any'or subnet-based address objects for source in all policies, and /32-objects only as destinations in policies permitting connections to your servers. P. S. And yes, security zone names are not worth much. Trust/untrust/dmz or lan/wan/man/internet/DC/server-farm --- all the same. Better pay more attention to your address-book entry names and interface descriptions. -- Pavel _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp