Chapter 3 - Policies

Security policies.

The first thing in policies is the context.

The Security Context.
Is basically the description of from-zone to-zone that the data is flowing.

For example.
If data goes from the internet  to the Servers.
The context is said to be.
from-zone INTERNET  to-zone SERVERS.

Now when data goes the opposite way.
The context becomes.
from-zone  SERVERS    to-zone INTERNET.

So from-zone PC to-zone SERVERS   is   another context.

Now, on a "context" you will apply policies.
Let's create a policy.

set security policies       from-zone INTERNET     to-zone SERVERS      policy   block_ping
That was easy, we define the context. from X to Y    and give it a name "block_ping".

Now inside the policy we need to put security rules.
The rules will follow a simple   IF something  THEN do
If
"webusers"    source-address
try to reach      "databaseServers"      destination-address
using protocol   "http"                     application
then
take an action    like "deny"

Let's try this.


from-zone INTERNET to-zone INTERNAL {                   #this is our context

policy deny_ping {                                                         # name of the policy

        match {                                                                  #match = IF
            source-address any;                                             #I used any
            destination-address any;
            application junos-icmp;                                        # junos has a list of ready applications
        }
        then {                                                                     # this is a programming statement IF-->THEN
            deny;                                                                # the action. In this case deny.



let's try another example.

okay,
The first context is   INTERNET to LAN.
as you can see you can create MANY policies under the context.
The SRX will go one by one and process them.
Once it hits a match to the traffic, then it will take that action.
So in this case.
policy 1 says    icmp allow
policy 2 says   telnet allow
policy 3 is the default policy at the bottom of every context which is deny all.

so if I was trying to open a web service.
policy 1 would skip me
policy 2 would skip me
policy 3 would block me and my connection would be terminated. (bye bye).

Now
let's look at the second one.
policy 1 blocks web traffic
policy 2 allows all traffic
policy 3 denies all traffic.
So in effect because the order of processing is 1 2 3 .
Policy 1 The LAN users cannot surf (deny)
Policy 2   the LAN users can get Email and do other things.
Policy 3  is the default deny.

So LAN users can do everything but surf on port 80 (http)

This is what it looks like on the SRX.

from-zone INTERNET to-zone LAN{

    policy ALLOW_HTTP_IN {

        match {

            source-address ANY_ANY;

            destination-address ANY_ANY;

            application junos-icmp;

        }

        then {

            permit ;

        }

    }

    policy ALLOW_TELNET {

        match {

            source-address ANY_ANY;

            destination-address any;

            application junos-telnet;

        }

        then {

            permit

            }

        }

    }

    policy deny_ping {

        match {

            source-address any;

            destination-address any;

            application junos-icmp;

        }

        then {

            deny;

There are MANY questions on the policies for the exam.
So I would practice reading policies.

So in this case.
Context   INTERNET to LAN

allow ICMP

allow telnet

deny ICMP

now even though there is no final any any any  deny  like I drew above.
There is an implicit deny at the end of every context. All firewalls have an implicit
deny at the end.

Some improvements.
If you notice we used a lot of   any in the above statements.
source-address any.
Now let's say I want to say,

well  if the source-address comes from199.199.199.0/24 which is our trusted Alaska office.
Then for him you can permit!!!!

We do this by creating addresses.

set security zone security-zone INTERNET address-book address Alaska_office 199.199.199.0/24

root@srx101# show security zones security-zone INTERNET

address-book {

    address Alaska_office 199.199.199.0/24;

}

This is another example.
Here I marked an address range.

root@srx101# show security zones security-zone INTERNET

address-book {

    address Europe {

        range-address 11.11.11.0 {

            to {

                16.16.16.0;

so from 11 .11.11.0  to 16.16.16.0  will be called Europe

I'll map it out.

So we have two addresses.
Alaska and Europe.
They both go in the Address book which is on the zone INTERNET

Now let's say I want to split the SERVERS zone into sub divisions.
So I can create three addresses.
WEB, DB, MAIL. These addresses will be on the address book which is on the zone SERVERS.

So now when I use the context.
set security policy from-zone INTERNET to-zone SERVERS          source-address Alaska (notice the use of address book that is on the INTERNET zone)

set security policy from-zone INTERNET to-zone SERVERS          destination-address MAIL_SRV  (notice the use of address book that is on the SERVERS zone)

set security policy from-zone INTERNET to-zone SERVERS          application junos-icmp (random application)

Now you can make a much more granular policy.
remember an address can belong only to ONE zone.

Well,
What happens if you have a custom application that runs on a custom port etc.
Junos gives you the default applications.

   junos-bootpc         [applications application <*>]

  junos-icmp         [applications application <*>]

  junos-telnet        [applications application <*>]

Well, under the [applications]
you can create a custom application.

This is an example.

root@srx101# show applications

application Saar_WEB {                              #name of application I created

    protocol tcp;                                          #protocol

    source-port 9000;                                   #port

    destination-port 99;                             #port

Now you can reference this application all over the SRX configuration.
The application is NOT tied down to a zone.
You can create it once and reference it all over.

You can also create a group of applications.
For example.
things_to_block
then include under it several applications.

this is called an application-set

application-set things_to_block {

    application junos-ping;

    application junos-telnet;

    application junos-finger;

Now instead of typing many lines, I simply reference an applications set.

I'll save you the example.
You can also do an Address-set  for the servers call it  Server_farm = DB+Mail+Web
then reference the address-set.

So Summary.

set applications       allows you to create applications.

set security zone security-zone  INTERNET address-book      allows you to create addresses on the zone

Now.
Schedulers

set scheduler    work_hours          daily  start-time 08:00:00   stop-time 17:00:00;

Ok the above is the schedule   8 to 5pm

I'll show you an example

So from 8-5 web is blocked.
If there is NO scheduler set up , then the policy is ACTIVE.

You get 4 scheduler questions or more.
So play with this.

You can re-use the Scheduler all over the SRX as it is not under another tree.

Summary.

set applications       allows you to create applications.

set security zone security-zone  INTERNET address-book      allows you to create addresses on the zone

set schedulers scheduler          will allow you to create a schedule which you can apply on the policy.

Logging.

Log from the SRX to a Syslog server.

set system syslog host 10.210.210.130    ANY   ANY

so, we set this in the system.

under [syslog]

the HOST we will be sending this to  =  syslog server     10.210.210.130

The  ANY   ANY refer to WHAT we will be sending.

the first is facilities. 

the second ANY is for the severity level.
For example I might want only the Emergency ones

This is the best I can come up with.

root@srx101# show system syslog

host 10.0.8.8 {

    any critical;

}

file traffic-log {

    any any;

    match RT_FLOW_SESSION;

}

so any critical messages will be sent to the 10.0.8.8

      any  messages that have RT_FLOW_SESSION      send them to a local file called    traffic-log

e voila.
Logging.

You can show a log
you can also clear a log.

Last thing.
If you want to work with an NSM you have to use structured-data and a specific filename.
The command is .

file default-log-messages  {

                                 any any;

                                structured-data;
              }

In order to fill in the traffic-log we created.
We can mark a policy to write to the log the
session-init   CPU intensive
session-close      not so CPU intensive.
or both.

The commands look like this.

from-zone INTERNAL to-zone INTERNET {

    policy ALLW-PING {

        match {

            source-address LAN;

            destination-address any;

            application [ junos-ping junos-telnet junos-http ];

        }

        then {

            permit;

            log {

                session-init;                                                   #log init and close. You can read the data in the traffic-log

                session-close;

            }

        }

set security policies policy-rematch enable

I found this table.
So by default this command is DISABLED.
Which mean only when you delete a policy will the session be dropped.
In all other cases the sessions keep going.

So for example.
If I go and change a policy to deny. it won't make an impact on the current flows.
I would have to reset the flows for the deny to have an impact.
Or..... I can use the policy-rematch command.


Questions.
How to reorder a policy
Use INSERT    before or after

What is the default action for every policy  
It is DENY. The last one is always DENY.

What is the purpuse of a scheduler
It is to apply a time limit on when the policy is active.

What are the Policy components.
1. Policy Context -  from-zone to-zone
2. Policy  name      -    policy block_something
3. matching conditions -     source-address, destination-address,  application
4. the action to take -    then
5. extras    -   like application-services (utm)  ,  count,   log  session-init