[j-nsp] Firewall best practices

[Pavel Lunin]

> 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