How to Configure and Verify Security Policies on SRX Services Gateway

After you’ve configured addresses and services on the SRX, you’re ready to configure the security policy itself. Configuring the addresses and services first allows defined addresses and services to be used in many policies. In that way, if one address or service changes, it must be changed in only one place in order to change it in all policies.

From the SRX perspective, traffic is always arriving from one zone and making its way to another zone. Technically, these zone crossings are called contexts. The context is where the security policies are applied.

You have only two zones (admins and untrust), so there are two intra-zone policy contexts (admins to admins and untrust to untrust) and two inter-zone policy contexts (admins to untrust and untrust to admins). Not all of them will be configured here.

Configure security policies

First, you want to give traffic originating on the admins zone permission to pass to the untrust zone:

[edit]
root# edit security policies from-zone admins to-zone untrust
[edit security policies from-zone amdins to-zone untrust]
root# set policy admins-to-untrust match source-address any destination-address any application any
root# set policy admins-to-untrust then permit
root# show
policy admins-to-untrust {
  match {
   source-address any;
   destination-address any;
   application any;
  }
  then {
   permit;
   }
}

Realistically, the policy will probably count the packets and log the session initiations and closes between the zones.

The second goal, which is to build a security policy to permit certain traffic between hosts in the admins zone is easy enough to do, using your service set:

[edit security policies from-zone admins to-zone admins]
root# set policy intra-zone-traffic match source-address any destination-address
    any application MYSERVICES
root# set policy intra-zone-traffic then permit

The second requirement is now satisfied. No configuration is required for the third point, denying traffic from untrust access to admins. Because “deny” is the default action, the SRX has already taken care of that.

Verify the policies

The easiest way to verify that the policies are working as expected is to test data traffic. You can also inspect the SRX session table:

root# show security flow session
Session ID: 100001782, Policy name: admins-to-untrust/4, Timeout: 1796
 In: 192.168.2.2/4777 → 216.52.233.201/443;tcp, If: ge-0/0/0.0
 Out: 216.52.233.201/443 → 192.168.2.2/4777;tcp, If: ge-0/0/2.0
Session ID: 100001790, Policy name: admins-to-untrust/4, Timeout: 1800
 In: 192.168.2.2/4781 → 216.239.112.126/80;tcp, If: ge-0/0/0.0
 Out: 216.239.112.126/80 → 192.168.2.2/4781;tcp, If: ge-0/0/2.0

In the real world, these policies will perform logging and counting, but remember, these are just examples.

dummies

Source:http://www.dummies.com/how-to/content/how-to-configure-and-verify-security-policies-on-s.html