How to Manage Multiple Security Policies on SRX Services Gateway
If the SRX could only assign interfaces to zones and allow certain services in and out, there wouldn't be much to it. But the SRX is much more powerful. After you have zones and interfaces set up, you can tap into the real power of the SRX: the security policies themselves.
Without security policies, all the SRX could do is create interface zones and screen out certain services. Security policies allow you to configure the details of what is and is not allowed through the SRX.
Multiple security policies
Large SRXs can have hundreds or even thousands of policies, because policies become more and more complex as they try and do too much. So, you can have multiple policies that are applied to traffic, all based on source and destination zone. The policies are applied one after another until an action is determined. The final default, of course, is to deny the traffic and discard the packet.
The exception to the default deny rule is traffic on the fxp0 management interface, which makes management of the SRX possible at all times (even when configurations go haywire), and allowing this traffic is a small risk because outside user traffic never appears on this interface.
All SRX security policies follow an IF-THEN-ELSE algorithm. IF traffic X matches some rule, THEN action Y is performed, ELSE the default deny (drop) is applied.
The IF part of the policy examines five aspects of packets to test for a match:
The predefined or configured source zone of the traffic inspected
The predefined or configured destination zone where the traffic is headed
The source IP address, or address book contents, of the traffic
The destination address, or address book contents, where the traffic is headed
The predefined or configured application or service to be allowed or denied
When an incoming packet matches all five default or configured parameters in the IF portion of the policy, one of these actions is applied:
Deny: The packet is silently dropped.
Reject: The packet is dropped, and a TCP-Rest is sent to the originator.
Permit: The packet is allowed to pass.
Log: The SRX creates a log entry for the packet.
Count: The packet is counted as part of the SRX accounting process.
When an action is applied to a packet, the policy chain is terminated. So policy order counts! Generally, you configure the most specific rules at the top of the chain and more generic policies at the bottom. Otherwise, one policy might mask the intended effect of another.
Now, add an example policy to the security zones you’ve already configured. Here’s what you want the policy to do:
Permit any traffic from any hosts in the admins zone to any destination in the untrust zone.
Permit certain traffic from any hosts in the admins zone to any other host in the same zone.
Deny any traffic from the untrust zone to the admins zone.