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 visitor’s feedback and contribution. I will try to update every topic slowly as I don’t have much time to update all in big chunks. For example until I finish this post, it will be updated from time to time. Let’s 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 : 336 10 bps
Output bytes : 336 10 bps
Input packets : 4 0 pps
Output packets : 4 0 pps
Session rate : 2 0 sps
Active sessions : 2
Session deletions: 0
Policy lookups : 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 can’t see it in the session table which makes sense indeed. Packet might have been dropped during screen,routing etc if you don’t 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″ destination-address=”192.168.100.1″ destination-port=”4913″ service-name=”icmp” nat-source-address=”172.30.73.219″ nat-source-port=”1″ nat-destination-address=”192.168.100.1″ nat-destination-port=”4913″ src-nat-rule-name=”None” dst-nat-rule-name=”None” protocol-id=”1″ policy-name=”allow-icmp-traffic” source-zone-name=”INTERNET” destination-zone-name=”INTERNAL” session-id-32=”45720″ username=”N/A” roles=”N/A” packet-incoming-interface=”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 can’t 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 didn’t 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 isn’t 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 doesn’t 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, Next-hop: 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 shouldn’t 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 session-close.
[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-to-untrust 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 doesn’t 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.
Related
Dear Genco,
Really, I and we all appreciate your great contribution for those preparing for JNCIP-SEC exam or want to learn the contents and topics for real world.
Can you please take some time from your precious time and help me advising in building my own LAB. The one which is for Juniper’s JSEC training course?
I have 2 SRX110H-VA and 2 Netscreen-25. I want to build an exact similar lab to that but failing to do so because I don’t have in depth knowledge how that lab has built.
I will really remain thankful to you for this act of kindness.
Regards,
Hi Tanweer,
I must say that during my preparation I had only two SRX210 devices but 2SRX100H is also sufficient as you can run IPS on them along with HA.
As you have netscreen devices this should be sufficient I suppose. What you can do is you can also use GNS3 to use Cisco routers virtually by which you can test compatibility between different vendors. I have a SRX100H as well now as in my opinion it is best to have 3 appliances for real testing. Least but not least don’t forget to stick to the exam objectives at http://www.juniper.net/us/en/training/certification/resources_jncipsec.html
cheers.
Genco.