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.
set security zones security-zone trust interfaces fe-0/0/1.0 set security zones security-zone trust interfaces fe-0/0/2.0 set security zones security-zone trust interfaces vlan.3 set security zones security-zone trust interfaces vlan.100 set security zones security-zone trust interfaces fe-0/0/7.0
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.
set security zones security-zone trust host-inbound-traffic system-services all set security zones security-zone trust host-inbound-traffic protocols all
A quick confirmation of what protocols we allow through.
[edit security zones security-zone trust] [email protected]# show host-inbound-traffic system-services { all; } protocols { all; }
Blast! All is actually an encompassing statement. Not to worry. Here below is a list of what you can choose to allow in individually or as required.
[email protected]> show interfaces fe-0/0/1.0 extensive - output omitted - Security: Zone: trust Allowed host-inbound traffic : bootp bfd bgp dns dvmrp igmp ldp msdp nhrp ospf pgm pim rip router-discovery rsvp sap vrrp dhcp finger ftp tftp ident-reset http https ike netconf ping reverse-telnet reverse-ssh rlogin rpm rsh snmp snmp-trap ssh telnet traceroute xnm-clear-text xnm-ssl lsping ntp sip r2cp
The command below shows the assignment of a majority of my interfaces to the trust security zone.
[email protected]> show security zones Security zone: CiscoInferno Send reset for non-SYN session TCP packets: Off Policy configurable: Yes Interfaces bound: 0 Interfaces: fe-0/0/5.0
Security zone: trust
Send reset for non-SYN session TCP packets: Off
Policy configurable: Yes
Interfaces bound: 5
Interfaces:
fe-0/0/1.0
fe-0/0/2.0
fe-0/0/7.0
vlan.100
vlan.3
Security zone: untrust
Send reset for non-SYN session TCP packets: Off
Policy configurable: Yes
Screen: untrust-screen
Interfaces bound: 2
Interfaces:
fe-0/0/0.0
pt-1/0/0.0
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.