[j-nsp] Firewall best practices

[Brent Jones]

On Mon, Jun 11, 2012 at 8:14 PM, Ben Dale <bdale at comlinx.com.au> wrote:

> Hi Wayne,
>
> Thanks for this - that's actually a really good solution I hadn't even
> considered - I can take it a step further and use wildcards on the zone to
> solve my multiple address-book on a single zone request:
>
> set groups HQ-UNTRUST-HOSTS security zones security-zone <*> address-book
> address U-HOST1 200.1.1.1/32
> set groups HQ-UNTRUST-HOSTS security zones security-zone <*> address-book
> address U-HOST2 200.1.1.2/32
> set groups HQ-UNTRUST-HOSTS security zones security-zone <*> address-book
> address U-HOST3 200.1.1.3/32
>
> set groups HQ-DMZ-HOSTS security zones security-zone <*> address-book
> address D-HOST1 100.1.1.1/32
> set groups HQ-DMZ-HOSTS security zones security-zone <*> address-book
> address D-HOST2 100.1.1.2/32
> set groups HQ-DMZ-HOSTS security zones security-zone <*> address-book
> address D-HOST3 100.1.1.3/32
>
> set security zones security-zone WAN apply-groups [HQ-UNTRUST-HOSTS
> HQ-DMZ-HOSTS]
>
> Neat!
>
> On 12/06/2012, at 12:49 PM, Wayne Tucker wrote:
>
> > On Mon, Jun 11, 2012 at 5:04 PM, Ben Dale <bdale at comlinx.com.au> wrote:
> > What would really help though is if Junos allowed multiple address-books
> to be bound to a single zone - that way, SRXs buried deeper in your network
> would have access to all address-book entries on a single upstream zone
> with very little configuration management.  I'm sure this concept would
> make tools like Space and NSM easier to use as well - Juniper SRX PLMs are
> you listening out there?  SAVE US!
> >
> >
> > It takes some getting used to, but this can be accomplished through
> configuration groups:
> >
> > Here's a vanilla address book on a Junos 10.4 box:
> >
> > # show security zones security-zone trust address-book
> > address ironman 192.168.0.16/32;
> > address knife 192.168.0.8/32;
> >
> > Create a couple of groups and apply them:
> >
> > # set groups group1 security zones security-zone trust address-book
> address address1 192.168.0.1/32
> > # set groups group2 security zones security-zone trust address-book
> address address2 192.168.0.1/32
> > # set apply-groups [ group1 group2 ]
> >
> > And now the address book contains the additional entries:
> >
> > # show security zones security-zone trust address-book | display
> inheritance
> > address ironman 192.168.0.16/32;
> > address knife 192.168.0.8/32;
> > address inet6:sandman 2001:470:ea7c:0:221:6aff:fe66:bdcc/128;
> > ##
> > ## 'address1' was inherited from group 'group1'
> > ## '192.168.0.1/32' was inherited from group 'group1'
> > ##
> > address address1 192.168.0.1/32;
> > ##
> > ## 'address2' was inherited from group 'group2'
> > ## '192.168.0.1/32' was inherited from group 'group2'
> > ##
> > address address2 192.168.0.1/32;
> >
> > An added bonus of having the address book (or almost other
> configuration) in a group is that you can use "load replace" (or the
> equivalent in the XML API) to keep it consistent when you distribute it
> around.  Add a few more layers and you could have a fully fledged system
> for managing any configuration bits on a device.
> >
> > :w
> >
> >
> >
>
>
Yup, this is a good way to go. I manage a dozen or so SRXs with apply
groups configured this way (apply group for address groups, security zones
inherit those groups).
Makes configs pretty easy to read, and as noted above, load replace is a
great tool via Rancid jlogin or via XML.

> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



-- 
Brent Jones
brent at brentrjones.com