Security policy is set of rules that tells a Junos device what to do with transit traffic between zones and within a zone. SRXs as apposed to Netscreen devices by default don’t allow intra zone traffic.
If the destination of the traffic is the device itself, security policies aren’t applicable. Instead host-inbound-traffic option must be used under zone configuration to control the traffic destined to the device.
Security policies are examined if the traffic destination is other than the incoming interface which also means that even in the same zone policy check is done.
Default Policy
By default, SRX denies all traffic if no policy is matched on incoming packet. If you want to change it to permit;
[edit security policies]
root@host# set default-policy permit-all
Policy Ordering
Policy order is important in decision making. To move up policy WEB above policy FTP use;
host#insert security policies from-zone trust to-zone untrust policy WEB after policy FTP
Sample policy config
[edit security policies]
root@host# show
from-zone trust to-zone untrust {
policy trust-to-untrust {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
As it can be seen, a policy configuration requires a source (from-zone) zone and a destination zone (to-zone) within which several policies can be defined.
Policy match requires to define source-address,destination-address and application or application sets.
BUT, there is a trick thing about addresses in policies. You can set an IP address directly and it should come from an address book as you can see below no option to set an IP.
root@host# set policy trust-to-untrust match source-address ?
Possible completions:
<address> Address from address book
[ Open a set of values
any Any IPv4 or IPv6 address
any-ipv4 Any IPv4 address
any-ipv6 Any IPv6 address
Address Books and address sets
Addresses are configured under the specific zone and tied to it. Address sets are also configured within the address-book configuration.
[edit security zones security-zone trust]
root@host# show
address-book {
address host1 192.168.1.1/32;
address host2 192.168.1.2/32;
address-set hosts {
address host1;
address host2;
}
}
Applications
You can create a custom application named company-portal like below. One thing to note is inactivity-timeout which defines how long the session should be kept in session table if there is no activity.
[edit applications]
root@host# show
application company-portal {
protocol tcp;
destination-port 81;
inactivity-timeout 3600;
}
Policy Actions
There are three actions permit,deny and reject. Reject sends an ICMP unreachable for UDP and TCP reset for TCP traffic as opposed to deny which silently drops the packet.
Counting traffic
You can also display policy related detail with the following command but for counting to be active, you must enable count option in the policy then statement.
root@host# show security policies policy-name trust-to-untrust detail
Policy: trust-to-untrust, action-type: permit, State: enabled, Index: 4, Scope Policy: 0
Policy Type: Configured
Sequence number: 1
From zone: trust, To zone: untrust
Source addresses:
any-ipv4: 0.0.0.0/0
any-ipv6: ::/0
Destination addresses:
any-ipv4: 0.0.0.0/0
any-ipv6: ::/0
Application: any
IP protocol: 0, ALG: 0, Inactivity timeout: 0
Source port range: [0-0]
Destination port range: [0-0]
Per policy TCP Options: SYN check: No, SEQ check: No
Policy statistics:
Input bytes : 0 0 bps
Output bytes : 0 0 bps
Input packets : 0 0 pps
Output packets : 0 0 pps
Session rate : 0 0 sps
Active sessions : 0
Session deletions: 0
Policy lookups : 0
Syslog
Following is a sample config which also sends syslog info to a syslog server via host command
[edit system syslog]
root@host# show
archive size 100k files 3;
user * {
any emergency;
}
host 192.168.2.10 {
user any;
source-address 192.168.2.3;
}
file messages {
any critical;
authorization info;
}
file interactive-commands {
interactive-commands error;
}
To log start and close of sessions use session-close and session-init within a security policy (this is data plane logging )
Monitoring
To display flow sessions
#show security flow session
Packet Tracing
You may also need to troubleshoot a particular flow for example packets coming from 192.168.1.0/24 and destined to 172.16.1.0/24. Here how we can do it via configuration statements;
[edit security flow]
root@host# show
traceoptions {
file engineering.log;
flag basic-datapath;
packet-filter engineering-problem {
source-prefix 192.168.1.0/24;
destination-prefix 172.16.1.0/24;
}
}
Policy Scheduler
You can also schedule a policy so that only within allowed period it can be active. Here is the syntax;
[edit]
root@host# show schedulers
scheduler MYSCHEDULER {
daily {
start-time 09:00:00 stop-time 18:00:00;
}
}
Then you can apply this to a policy
[edit security policies from-zone trust to-zone untrust policy trust-to-untrust]
root@host# show
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
count;
}
scheduler-name MYSCHEDULER;
Policy-rematch
This statement is something important because it determines whether policy changes should be applied to the current sessions or not. If it is set, any change done in policies are applied to already established sessions too. By default, it isn’t set.
#set security policies policy-rematch
Related