Blogroll

Minister of Firewall Zone Planning

Control your traffic. Make sure no one passes GO!

Like Cisco, Juniper offer their equivalent to security levels. Known as zones, the SRX family can classify common interfaces and apply hierarchical policies that allow stable scalability. This post is designed to introduce Cisco people to the Juniper equivalent, and new comers to the concept. Lets begin.

Residential, Commercial , or Industrial?

First off it is important to understand that there are two types of zones. User-defined and System-defined. System-defined zones cannot be modified. There is one zone in this group and it is called Null. It cannot be changed or configured. This zone denies traffic to and from it and by default interfaces are placed into this zone. The other type of zones are user-defined. They fall into two sub-categories.

User Defined

Security

Functional

Security zones are what most people are used to. Logical partitions or grouping of interfaces. Think like I do here – DMZ-A, Outside, Inside, trust, untrust, Corporate. What ever the example, you see what picture I am trying to paint. By defining zones we can then control how traffic moves between each zone. I know a great case where I know I do not need FTP into my mail-dmz. One of the protocols I deny from entering this zone is FTP and telnet. By using a zone and controlling with security policy statements I can easily and in a scalable way define traffic flows.

Functional zones are something that doesn’t behave the same way as security zones. Traffic doesn’t transit the zone. The use case for a functional zone would be to assign an entire interface to becoming a dedicated management port.

An upcoming blog will explain Security Policies in which between zones we can control and allow traffic. In the mean time here is some configs and verification to sink your teeth into.

The commands used to create and assign interfaces to different zones. Note that I have assigned logical interfaces and VLAN SVIs all to the same zone. It is important to know that also if a zone doesn’t exist when you are referencing it is created automatically. Be warned and check your spelling.

We now need to allow system services in as well as protocols. Due to the fact that this zone I am making is trusted I am choosing to allow everything. This is my Bastion of packet safety. Remember that host inbound traffic allows traffic to access loopback0 of the SRX, so traffic that terminates, not transits. Example of this would be a PC in zone untrusted and a PC in a trusted zone. If all host inbound traffic protocols were blocked into the trusted zone, a SSH session could take place between PC to PC but not from PC to an interface on the SRX in the trusted zone. Don’t worry if that flys over your head because we will lab this in the next post.

Congratulations. You have created some zones and assigned interfaces to it. It is important to determine the restrictions you place on your zones as you do not want all services and protocols in a production environment. Now we have created zones, we need to define security policies to get the flows going. In this next blog to follow we will test host inbound traffic to see what it does to our protocols in the lab and the blog after that will be security policies. You’re not out of the woods yet but I am here to help you get you there.