Logging Policy and TCPDUMP (SRX)

How can we know if our policies are being hit or if traffic is getting to the firewall?

* SETUP

The policy in question for all the below work is just the default trust to untrust policy on the SRX. The source IP on trust is 192.168.56.50 and the destination on IP on untrust is 172.20.123.2

blogger@LEFTY> show configuration security policies from-zone trust to-zone untrust
policy trust-to-untrust {
    match {
        source-address any;
        destination-address any;
        application any;
    }
    then {
        permit;
    }
}

* LOGGING

First lets look at logging. Lets add logging to the policy. If your going to have logging you must choose session-init or session-close or both. From my perspective session-init is way more useful as if you have very long lasting sessions you may never know that you got a policy hit. Sure you might want to know when a session ends but at the very least you would want to know when and if your policy even got hit so make sure you at least use session-init.

DHCP server (SRX)

Just a quick one today about setting up an SRX as a DHCP server.
First you need to define the DHCP parameters..

                   dhcp {
            router {
                192.168.1.1;
            }
            pool 192.168.1.0/24 {
                address-range low 192.168.1.2 high 192.168.1.254;
                default-lease-time 3600;
                domain-name blogger.net.au;
                name-server {
                    192.168.1.1;
                }
            }
        }

Login timeout (SRX and Olive) - updated

Juniper states that by default there is no idle-timout. That applies for my olive and my SRXs.
Indeed when I do check out the cli parameters on the olive after login I see..

user@olive-core> show cli
CLI complete-on-space set to on
CLI idle-timeout disabled
CLI restart-on-upgrade set to on
CLI screen-length set to 51
CLI screen-width set to 136
CLI terminal is 'vt100'
CLI is operating in enhanced mode
CLI timestamp disabled
CLI working directory is '/var/home/user'

And indeed I can confirm that my ssh session to olive-core never times out.

That's fine for the lab but in the real world corporate environment not so good. So what do we do to fix that? Define a login class.

NTP

It is very simple to setup NTP. In summary here is the 3 steps.

1) Set the timezone

2) Set the time via CLI to get an immediate update

3) Sync up with an NTP source for persistent time sync.

Below is the steps fleshed out.

Load hierarchical config

You can, if you want, load hierarchical config directly under the edit prompt if you have such a piece of config. For example you just want to copy a section of config you already have working from one device to another or maybe you want to copy a piece of config you have seen.

Here we copy a user definition into another device using the load merge command.
Also note the use of the "relative" keyword as we are not loading at the top of the hierarchy

Logging (Olive - Firewall)

Now we can login to the olive, control the login through a firewall filter and see hits on the filter. But that only gives us a packet and byte count. It doesn't tell us when the counts happened or where they were sourced from. For that we need logging.

An easy way to do this is to use the action "log" on the term..

user@olive-core> show configuration firewall
filter ACCESS-CNTRL {
    term TELNET-BLOCK {
        from {
            destination-port telnet;
        }
        then {
            count COUNTER-TELNET-BLOCK;
            log;
            discard;
        }
    }
    term PERMIT-ALL {
        from {
            source-address {
                0.0.0.0/0;
            }
        }
        then {
            count COUNTER-PERMIT-ALL;
            accept;
        }
    }
}

To see the log..(And there must be hits against the term to see the kind of output below)

Access (Olive)

All you need to access the device, an Olive on VirtualBox in this case, is this config.

system {
      services {
        ssh;
        telnet;
    }

This config would allow ssh and telnet access to all interfaces.
Note: Root will not authenticate with telnet.

Now suppose you would like to block access on one or more interfaces.
You need a firewall filter.