JNCIP SEC 1 Advanced Security Policy

I have finally decided to start my study for JNCIP-SEC exam. To be honest, exam is just a
driving force. What I would like to achieve is to get knowledge because of which I am not only
going to share my studies related to exam but I will try to go deeper as much as I can on every
specific topic because of which I am planing to test more than an exam asks.
I am also learning and so I do appreciate visitors feedback and contribution. I will try to update
every topic slowly as I dont have much time to update all in big chunks. For example until I
finish this post, it will be updated from time to time. Lets get started

[Analyzing Traffic Flows]

Figure1
I will use the topology above throughout this post. Just assume JUNOS1 and JUNOS2 devices
are two physical devices, all routing configuration is in place and JUNOS2 has a default allow
policy. (To be honest, in my setup R2 is a linux machine just to test policies, so be careful)
ICMP test scenario:
R1> ping 192.168.100.1
PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
^C

 192.168.100.1 ping statistics

7 packets transmitted, 0 received, 100% packet loss, time 6048ms

We cannot receive any icmp reply to our icmp echos we sent from R1 because default policy is
deny-all in JUNOS-1.
Lets assign interfaces to zones and create policies on JUNOS1
[edit security zones]
root@JUNOS1# show
security-zone INTERNET {
address-book {
address R1 172.30.73.219/32;
}
interfaces {
ge-0/0/0.0;
}
}
security-zone INTERNAL {
address-book {
address JUNOS2 192.168.100.1/32;
}
interfaces {
lt-0/0/0.0;
}
}
[edit security policies]
root@JUNOS1# show
from-zone INTERNET to-zone INTERNAL {
policy allow-icmp-traffic {

match {
source-address R1;
destination-address JUNOS2;
application junos-ping;
}
then {
permit;
}
}
}

Now try to ping once again;

R1>ping 192.168.100.1 -c 2
PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
64 bytes from 192.168.100.1: icmp_req=1 ttl=63 time=3.45 ms
64 bytes from 192.168.100.1: icmp_req=2 ttl=63 time=3.59 ms

Bingo! we receive replies to our 2 icmp packets. As you can also see we only set policy in one
direction, the reverse direction is handled by flow daemon.
Ok but we also want to see some counters for which we must enable count option:
[edit]
root@JUNOS1#set security policies from-zone INTERNET to-zone INTERNAL
policy allow-icmp-traffic then count

After committing, send 2 icmp packets more and check how the policy output looks like;
root@JUNOS1> show security policies policy-name allow-icmp-traffic detail
Policy: allow-icmp-traffic, action-type: permit, State: enabled, Index: 4, Scope
Policy: 0
Policy Type: Configured
Sequence number: 1

From zone: INTERNET, To zone: INTERNAL

Source addresses:
R1: 172.30.73.219/32
Destination addresses:
JUNOS2: 192.168.100.1/32
Application: junos-ping
IP protocol: 1, ALG: 0, Inactivity timeout: 60
ICMP Information: type=255, code=0
Per policy TCP Options: SYN check: No, SEQ check: No
Policy statistics:
Input bytes

Output bytes

336
:

Input packets :

336
4

Output packets :
Session rate

Active sessions :

4
2

10 bps
0 pps
0 pps
0 sps

Session deletions:
Policy lookups :

10 bps

0
2

Can you see the new counters? Lets look at sessions:

root@JUNOS1> show security flow session destination-prefix 192.168.100.1
Session ID: 26960, Policy name: allow-icmp-traffic/4, Timeout: 2, Valid
In: 172.30.73.219/1 > 192.168.100.1/6854;icmp, If: ge-0/0/0.0, Pkts: 1, Bytes: 84
Out: 192.168.100.1/6854 > 172.30.73.219/1;icmp, If: lt-0/0/0.0, Pkts: 1, Bytes: 84
Session ID: 26962, Policy name: allow-icmp-traffic/4, Timeout: 4, Valid
In: 172.30.73.219/2 > 192.168.100.1/6854;icmp, If: ge-0/0/0.0, Pkts: 1, Bytes: 84
Out: 192.168.100.1/6854 > 172.30.73.219/2;icmp, If: lt-0/0/0.0, Pkts: 1, Bytes: 84

TIP: The red colored number 4 is the policy index number, ge-0/0/0.0 is input, lt-0/0/0.0 is
output interface
TIP: One point to mention here is what you see here is what is accepted by flow services
module. If a packet is denied, you cant see it in the session table which makes sense indeed.
Packet might have been dropped during screen,routing etc if you dont see it here.
I was wondering how I can see default sessions timeouts for tcp/udp and I saw the answer here in
juniper forum according to which;
root@JUNOS1> start shell user root
root@JUNOS1% vty fwdd
BSD platform (OCTEON processor, 416MB memory, 8192KB flash)
FLOWD_OCTEON(JUNOS1 vty)# show usp app-def tcp
tcp port=0, appl_name=junos-tcp-any, service type=0, alg id=0, timeout=1800
tcp port=21, appl_name=junos-ftp, service type=1, alg id=1, timeout=1800
tcp port=22, appl_name=junos-ssh, service type=22, alg id=0, timeout=1800
tcp port=23, appl_name=junos-telnet, service type=10, alg id=0, timeout=1800
tcp port=25, appl_name=junos-smtp, service type=7, alg id=0, timeout=1800
tcp port=43, appl_name=junos-whois, service type=46, alg id=0, timeout=1800
tcp port=49, appl_name=junos-tacacs, service type=0, alg id=0, timeout=1800
tcp port=53, appl_name=junos-dns-tcp, service type=16, alg id=16, timeout=1800
tcp port=65, appl_name=junos-tacacs-ds, service type=0, alg id=0, timeout=1800
tcp port=70, appl_name=junos-gopher, service type=39, alg id=0, timeout=1800
tcp port=79, appl_name=junos-finger, service type=17, alg id=0, timeout=1800
tcp port=80, appl_name=junos-http, service type=6, alg id=0, timeout=1800

To see default application configuration

[edit]
root@JUNOS1# show groups junos-defaults applications

To clear policy statistics;

root@JUNOS1> clear security policies statistics

To see session summary;
root@JUNOS1> show security flow session summary
Unicast-sessions: 1
Multicast-sessions: 0
Failed-sessions: 0
Sessions-in-use: 3
Valid sessions: 1
Pending sessions: 0
Invalidated sessions: 2
Sessions in other states: 0
Maximum-sessions: 98304

What should we do if we want to get session initiation logs (be careful this generates extra load
on the device, only for short time testing):
[edit security policies from-zone INTERNET to-zone INTERNAL]
root@JUNOS1# set policy allow-icmp-traffic then log session-init

After committing config, I tried to look for my session log via;

>show log messages | match session-init
or
>show log messages | match RT_FLOW_SESSION
you know what? I got nothing. Then I have realized that my syslog configuration is like below;
file default-log-messages {
any any;
structured-data;
}

Because of this config, I run the same command for default-log-messages file and I
got the following output. Bingo!

<14>1 2011-07-30T00:48:32.320Z JUNOS1 RT_FLOW RT_FLOW_SESSION_CREATE

[junos@2636.1.1.1.2.58 source-address=172.30.73.219 source-port=1 destinationaddress=192.168.100.1 destination-port=4913 service-name=icmp nat-sourceaddress=172.30.73.219 nat-source-port=1 nat-destination-address=192.168.100.1 natdestination-port=4913 src-nat-rule-name=None dst-nat-rule-name=None protocolid=1 policy-name=allow-icmp-traffic source-zone-name=INTERNET destination-zonename=INTERNAL session-id-32=45720 username=N/A roles=N/A packet-incominginterface=ge-0/0/0.0] session created 172.30.73.219/1->192.168.100.1/4913 icmp
172.30.73.219/1->192.168.100.1/4913 None None 1 allow-icmp-traffic INTERNET INTERNAL
45720 N/A(N/A) ge-0/0/0.0
New task is configuring a policy allowing transit SSH traffic and playing with session:
[edit security policies from-zone INTERNET to-zone INTERNAL policy allow-ssh]
root@JUNOS1# show
match {
source-address any;
destination-address any;
application junos-ssh;
}
then {
permit;
}

After connecting from R1 to 192.168.100.1 via SSH, we get the following session;
root@JUNOS1> show security flow session application ssh
Session ID: 46431, Policy name: allow-ssh/6, Timeout: 1780, Valid
In: 172.30.73.219/34961 > 192.168.100.1/22;tcp, If: ge-0/0/0.0, Pkts: 11, Bytes:
1963
Out: 192.168.100.1/22 > 172.30.73.219/34961;tcp, If: lt-0/0/0.0, Pkts: 10, Bytes:
2281
Total sessions: 1

We can say that there is 1780 secs left for this session to timeout. As soon as you generate some
ssh traffic, it will again start counting down from 1800 secs which is default TCP inactivity
timeout. What if we want to lower this timeout?
Create a new application called my-ssh, and replace previously configured junos-ssh
by my-ssh:
[edit applications]
root@JUNOS1# show
application my-ssh {
protocol tcp;
destination-port 22;
inactivity-timeout 600;
}

After commit for new requests here is the following session output;
root@JUNOS1# run show security flow session application ssh
Session ID: 47948, Policy name: allow-ssh/6, Timeout: 598, Valid
In: 172.30.73.219/40595 > 192.168.100.1/22;tcp, If: ge-0/0/0.0, Pkts: 11, Bytes:
1963
Out: 192.168.100.1/22 > 172.30.73.219/40595;tcp, If: lt-0/0/0.0, Pkts: 10, Bytes:
2281

As you can see timeout has decreased to 600.

ALG Configuration

Application Layer Gateway feature does what cant be done via stateful firewall mechanisms and
provides extra layer of inspection. The simplest example given is FTP in most of the
documentations. I will present two examples here e.g FTP and DNS
Here is my new setup for ALG test.
FTP ALG:
INTERNET (172.30.72.244 [ge-0/0/0.0]) SRX ( 10.2.2.1 [ge-0/0/2.0] ) (10.2.2.1) Linux
PC

Check which ALGs are enabled:

root@host> show security alg status
ALG Status :
DNS

: Enabled

FTP

: Enabled

H323

: Enabled

MGCP

: Enabled

MSRPC

: Enabled

PPTP

: Enabled

RSH

: Enabled

RTSP

: Enabled

SCCP

: Enabled

SIP

: Enabled

SQL

: Enabled

SUNRPC : Enabled
TALK

: Enabled

TFTP

: Enabled

IKE-ESP : Disabled

Create a policy allowing only ftp

[edit]
root@host# show security policies
from-zone trust to-zone untrust {
policy trust-to-untrust {
match {
source-address any;
destination-address any;

application junos-ftp;
}
then {
permit;
}
}
}

Generate some traffic and look at the session table;

[edit system]
root@host# run show security flow session
Session ID: 4805, Policy name: trust-to-untrust/5, Timeout: 1800, Valid
Resource information : FTP ALG, 1, 0
In: 10.2.2.2/50768 > 144.122.144.177/21;tcp, If: ge-0/0/2.0, Pkts: 53, Bytes:
2468
Out: 144.122.144.177/21 > 172.30.72.244/62145;tcp, If: ge-0/0/0.0, Pkts: 42,
Bytes: 3195
Session ID: 6148, Policy name: trust-to-untrust/5, Timeout: 2, Valid
Resource information : FTP ALG, 1, 2
In: 144.122.144.177/20 > 172.30.72.244/14602;tcp, If: ge-0/0/0.0, Pkts: 5, Bytes:
1449
Out: 10.2.2.2/35919 > 144.122.144.177/20;tcp, If: ge-0/0/2.0, Pkts: 3, Bytes: 164
Total sessions: 2

What can we see her is: we allowed ftp traffic to untrust network via polict but although we
didnt specifically allow traffic from 144.122.144.177:20 to 10.2.2.2:35919 ALG inspects the
traffic and let the packets pass. As you can see timeout is also very small. I must remind you that
this pattern can be seen if you are using active mode FTP in which remote FTP server initiates
connection back to client. If passive mode is used, client initiates the connection for data channel
again for which you see the following session flow;
[edit]

root@host# run show security flow session

Session ID: 10166, Policy name: trust-to-untrust/5, Timeout: 1800, Valid
Resource information : FTP ALG, 1, 0
In: 10.2.2.2/46120 > 144.122.144.177/21;tcp, If: ge-0/0/2.0, Pkts: 17, Bytes: 804
Out: 144.122.144.177/21 > 172.30.72.244/64163;tcp, If: ge-0/0/0.0, Pkts: 15,
Bytes: 1223
Session ID: 10207, Policy name: trust-to-untrust/5, Timeout: 2, Valid
Resource information : FTP ALG, 1, 2
In: 10.2.2.2/35690 > 144.122.144.177/65532;tcp, If: ge-0/0/2.0, Pkts: 4, Bytes:
216
Out: 144.122.144.177/65532 > 172.30.72.244/56680;tcp, If: ge-0/0/0.0, Pkts: 4,
Bytes: 745
Total sessions: 2

As it can be seen in passive mode FTP, client initiates the data channel connection and
connection is allowed by ALG.
DNS ALG:
When you look at default UDP session timeout value, you can see that is 60
seconds. However session timeout below is very low as it can be seen. DNS ALG
monitors DNS traffic and as far as I can see if DNS response is return it sets session
timeout so low to quickly close down the session. If response isnt received it sets
session timeout 60 secs. I think this is how it works.
[edit]
root@host# run show security flow session
Session ID: 13181, Policy name: trust-to-untrust/5, Timeout: 2, Valid
In: 10.2.2.2/56923 > 8.8.8.8/53;udp, If: ge-0/0/2.0, Pkts: 1, Bytes: 60
Out: 8.8.8.8/53 > 172.30.72.244/55772;udp, If: ge-0/0/0.0, Pkts: 1, Bytes: 160
Total sessions: 1
Policy Troubleshooting

Probably troubleshooting doesnt fit in this category but I would like to add a
troubleshooting section for policy topic as it is crucial.
Lets generate traffic for which we know that there is no policy and our packets will
be dropped. We still have the policy which allow only DNS UDP traffic. What will
happen if we targer 80. port? Lets troubleshoot:
Configure Debug Filter:
[edit security flow]
root@host# show
traceoptions {
file www-debug.log;
flag basic-datapath;
packet-filter www {
destination-port 80;
}
}
Display debug log:
root@host> show log www-debug.log | trim 41
traceflag 0x0
<10.2.2.2/56151->74.125.224.112/80;6> matched filter www:
packet [60] ipid = 3433, @43e9b79c
- flow_process_pkt: (thd 9): flow_ctxt type 13, common flag 0x0, mbuf
0x43e9b580, rtbl_idx = 0
flow process pak fast ifl 73 in_ifp ge-0/0/2.0
ge-0/0/2.0:10.2.2.2/56151->74.125.224.112/80, tcp, flag 2 syn
find flow: table 0x5d3e0248, hash 14748(0xffff), sa 10.2.2.2, da 74.125.224.112, sp
56151, dp 80, proto 6, tok 7
no session found, start first path. in_tunnel 0, from_cp_flag 0
self ip check: not for self (address=4a7de070)

flow_first_create_session
flow_first_in_dst_nat: in <ge-0/0/2.0>, out <N/A> dst_adr 74.125.224.112, sp
56151, dp 80
chose interface ge-0/0/2.0 as incoming nat if.
flow_first_rule_dst_xlate: DST no-xlate: 0.0.0.0(0) to 74.125.224.112(80)
flow_first_routing: call flow_route_lookup(): src_ip 10.2.2.2, x_dst_ip 74.125.224.112,
in ifp ge-0/0/2.0, out ifp N/A sp 56151, dp 80, ip_proto 6, tos 10
Doing DESTINATION addr route-lookup
routed (x_dst_ip 74.125.224.112) from trust (ge-0/0/2.0 in 0) to ge-0/0/0.0, Nexthop: 172.30.72.1
policy search from zone trust-> zone untrust (0x0,0xdb570050,0x50)
app 6, timeout 1800s, curr ageout 20s
packet dropped, denied by policy
packet dropped, policy deny.
flow find session returns error.
For those who have screenos background I am sure interpretation of this log is very
easy as most of the lines are similar.
Remember FIRST PATH flow of a packet. Packet follows this path and a matching
policy is searched for 80. port from trust to untrust zones however no matching
policy is found and packet is dropped. You can see that there is no even source
address translation because SOURCE NAT is done after policy check.
SYSLOG SERVER
Ok maybe I shouldnt add syslog server setup here but I must explain for myself as
well how to send srx logs and traffic logs to syslog server.
Our syslog server is at 10.2.2.2
[edit]
root@host# show system syslog
user * {
any emergency;

}
host 10.2.2.2 {
any any;
}
The configuration about will enable us all system logs (cli logs etc) to be sent to
syslog server but what if we want to send traffic logs too.
Configure logging for session-init as below, it can also be configured for sessionclose.
[edit security policies from-zone trust to-zone untrust]
root@host# show
policy trust-to-untrust {
match {
source-address any;
destination-address any;
application junos-dns-udp;
}
then {
permit;
log {
session-init;
}
}
}
In default configuration you will see following type of log in syslog:
<78>Aug 1 17:37:01 cron[36511]: (root) CMD (newsyslog)<14>Aug 1 17:37:04
RT_FLOW: RT_FLOW_SESSION_CREATE: session created 10.2.2.2/42928->8.8.8.8/53
junos-dns-udp 172.30.72.244/16453->8.8.8.8/53 source-nat-rule None 17 trust-tountrust trust untrust 24842

If you are looking for NSM related syslogs check following KBs at juniper site:
KB16448 : Syslog for NSM
KB21050: For stream logging from data plane

FAQ
1) Is there any intra zone policy command in SRX?
SRX doesnt have any simple command which allows intra-zone traffic but trust zone comes
with a default allow any any
default configuration. If you have interfaces in different interfaces and want to allow traffic, you
must explicitly set a policy.