Monday, 19 November 2012

Security Policies - Logging (SRX Traffic Logs)

All logging in Junos is based on syslog, this includes security policy logging. This post will focus on security policy logging (firewall traffic logging). The following diagram outlines the basic lab topology used in the exercises in this post.




Security Log Processing
Security policy logging can be processed by the control plane or the data plane.

Control plane log processing is used by default on the Branch SRX devices. Control plane log processing can be configured on all SRX platforms using the command 'set security log mode event'. In this method the Routing Engine (eventd process) will process security logs. High End / Data Centre SRX devices can easily overwhelm the control plane with log volume. Logging rates can be as high as 40,000 log events/sec per/SPU. Additional parameters can be configured under the [security log] hierarchy such as event-rate, this will set a hard limit on the number of log events that are sent to the control plane. It is recommended that no more than 1000 log events/sec are send to the control plane. Once control plane security log processing is configured log files can be configured under the [system syslog] hierarchy to write security log events to a file. Syslog servers can also be specified so that control plane processed security logs are also forwarded to a external syslog server.
Note: Control plane log processing is the only option if log events need to be forwarded out the fxp0 (management) interface.

Data plane log processing is used by default on the High End / Data Centre SRX devices. Data plane log processing can be configured on all SRX platforms using the command 'set security log mode stream'. Under the [system log mode stream] hierarchy parameters can be specified such as the IP address of the server to forward logs to,  syslog format, and syslog facility/severity.



Security Log Message Types
There are three types of policy traffic logs. Session-create, session-deny and session-close. They are outlined below in detail. The log examples are logs formatted in syslog traditional format.

RT_FLOW_SESSION_CREATE this log message is created when a session is created. The session-init statement must be configured under the security policy to generate this log message. The following information is contained in this security log message;


  • source-address (source IP address)
  • source-port (source TCP/UDP port)
  • destination-address (destination IP address)
  • destination-port (destination TCP/UDP port)
  • serivce-name (application / service name)
  • nat-source-address (NAT source IP address)
  • nat-source-port (NAT source TCP/UDP port)
  • nat-destination-address (NAT destination IP address)
  • nat-destination-port (NAT destination TCP/UDP port)
  • src-nat-rule-name
  • dest-nat-rule-name
  • protocol-id (IP protocol i.e. TCP, UDP, AH)
  • policy-name (security policy name)
  • source-zone-name
  • destination-zone-name
  • session-id-32 (32 bit session identifier)
  • username
  • roles
  • packet-incoming-interface
Example:
Nov 18 09:56:58  INTERNET-ROUTER RT_FLOW: RT_FLOW_SESSION_CREATE: session created 192.168.1.102/58662->8.8.8.8/53 junos-dns-udp 68.144.1.1/55893->8.8.8.8/53 TRUST-INET-ACCESS None 17 OUTBOUND-INTERNET-ACCESS TRUST INTERNET 6316 N/A(N/A) vlan.192



RT_FLOW_SESSION_DENY this log message is create when a session is denied. The session-init statement must be configured under the security policy to generate this log message. The following information is contained in this security log message;


  • source-address (source IP address)
  • source-port (source TCP/UDP port)
  • destination-address (destination IP address)
  • destination-port (destination TCP/UDP port)
  • serivce-name (application / service name)
  • protocol-id (IP protocol i.e. TCP, UDP, AH)
  • icmp-type (ICMP message type. If other protocol, type will = 0)
  • policy-name (security policy name)

Example:
Nov 18 10:24:48  INTERNET-ROUTER RT_FLOW: RT_FLOW_SESSION_DENY: session denied 192.168.1.102/50650->8.8.8.8/53 junos-dns-udp 17(0) DENY-DNS TRUST INTERNET   N/A(N/A) vlan.192



RT_FLOW_SESSION_CLOSE this log message is create when a existing session is closed. The session-close statement must be configured under the security policy to generate this log message. It does not make sense to enable the session-close statement on rules for which the action is deny or drop as these rules will never permit sessions which can be closed. This message type contains the most information out of all three log message types. This security log message contains all of the same information in the RT_FLOW_SESSION_CREATE log plus the following;


  • reason
  • packets-from-client
  • bytes-from-client
  • packets-from-server
  • bytes-from-server
  • elapsed-time
  • application
  • nested-application
Example:
Nov 18 09:56:59  INTERNET-ROUTER RT_FLOW: RT_FLOW_SESSION_CLOSE: session closed unset: 192.168.1.102/58662->8.8.8.8/53 junos-dns-udp 68.144.1.1/55893->8.8.8.8/53 TRUST-INET-ACCESS None 17 OUTBOUND-INTERNET-ACCESS TRUST INTERNET 6316 1(67) 1(83) 1   N/A(N/A) vlan.192



Traditional vs. Structured Syslog
The structured syslog format prepends fields with a title and makes searching and indexing easier. If this structured is not specified the log will be written in the default 'traditional' format. Below is a comparison of the same log file in both formats.

Traditional Example:
Nov 18 09:56:58  INTERNET-ROUTER RT_FLOW: RT_FLOW_SESSION_CREATE: session created 192.168.1.102/58662->8.8.8.8/53 junos-dns-udp 68.144.56.81/55893->8.8.8.8/53 TRUST-INET-ACCESS None 17 OUTBOUND-INTERNET-ACCESS TRUST INTERNET 6316 N/A(N/A) vlan.192

Structured Example:
<14>1 2012-11-18T09:56:58.806-07:00 INTERNET-ROUTER RT_FLOW - RT_FLOW_SESSION_CREATE [junos@2636.1.1.1.2.41 source-address="192.168.1.102" source-port="58662" destination-address="8.8.8.8" destination-port="53" service-name="junos-dns-udp" nat-source-address="68.144.56.81" nat-source-port="55893" nat-destination-address="8.8.8.8" nat-destination-port="53" src-nat-rule-name="TRUST-INET-ACCESS" dst-nat-rule-name="None" protocol-id="17" policy-name="OUTBOUND-INTERNET-ACCESS" source-zone-name="TRUST" destination-zone-name="INTERNET" session-id-32="6316" username="N/A" roles="N/A" packet-incoming-interface="vlan.192"] session created 192.168.1.102/58662->8.8.8.8/53 junos-dns-udp 68.144.56.81/55893->8.8.8.8/53 TRUST-INET-ACCESS None 17 OUTBOUND-INTERNET-ACCESS TRUST INTERNET 6316 N/A(N/A) vlan.192



Configure Local Logging (Control Plane Processing)
This example will demonstrate a configuration where logs are processed by the control plane and stored on the local SRX device.

1. Configure log mode to be event (High End / Data Centre SRX devices)
This step only needs to be configured on the High End / Data Centre SRX devices as this is the default mode on all Branch SRX devices. The screenshot below outlines the command to enable event mode for security logging.

2. Configure event-rate limiting (High End / Data Centre SRX device best practices)
Setting event-rate limits are not as important on the Branch SRX devices. It is important to do for High End / Data Centre SRX devices as they can easily overwhelm the control plane. The screenshot below outlines the configuration to set a maximum log rate of 1000 events / second.

3. Configure Syslog Files
A syslog file must be created as a location for the security log events to be written to. The facility is set to user and the level is set to info. The match statement is used to only write relevant messages, in this case only security log messages always contain the statement 'RT_FLOW' and this is used to match security logs. The max files size is also set along with the statement 'world readable' which means all users have permissions to read this file. The last statement sets the logs to be written in structured syslog format. The screenshot below outlines the configuration steps to create the syslog file.
Note:  I have used the example above because this is the default syslog file created if users enable logging within the J-Web interface. A match statement of RT_FLOW_SESSION could also be used as found in many examples. Also traditional syslog format could be used.

4. Enable logging under desired Security Policies
Security policy logs are generated from security policies that have logging configured/enabled. Two logging options can be configured under a security policy session-init and session-close.
Session-init creates a log event on session initiation. If the action is permit a session-create log message will be generated. If the action is deny a session-deny log message will be generated.
Session-close creates a log event on session tear-down, a session-close log message will be generated.
The screenshot below outlines the configuration of logging on an existing policy of 'OUTBOUND-INTERNET-ACCESS.




Configure Remote Logging (Control Plane Processing)
This example will demonstrate a configuration where logs are processed by the control plane and stored on a remote syslog server. It should be noted that this example could be used with the example above example (control plane local logging) simultaneously as they are both using control plane log processing.

1. Configure log mode to be event (High End / Data Centre SRX devices)
This step is the same as in the previous example. Please reference the step#1 in the exercise above for details/screenshot.

2. Configure event-rate limiting (High End / Data Centre SRX device best practices)
This step is the same as in the previous example. Please reference the step#2 in the exercise above for details/screenshot.

3. Configure External Syslog Servers

4. Enable logging under desired Security Policies
This step is the same as in the previous example. Please reference the step#4 in the exercise above for details/screenshot.



Configure Remote Logging (Data Plane Processing)
This example will demonstrate a configuration where logs are processed by the data plane and stored on a remote syslog server.

1. Configure log mode to be stream.
This step will configure security policy logs to be processed by the data plane. The screenshot below outlines the command.

2. Configure server target under security log stream.
The commands below outline the configuration to send security logs from the data plane to an external syslog server (192.168.1.2).

3. Enable logging under desired Security Policies
This step is the same as in both previous examples. Please reference the step#4 in the exercises above for details/screenshot.



Viewing Logs
1. View logs from local file on SRX (CLI)
The log file can be viewed by the CLI by executing the command 'show log policy_sessions'. Keep in mind one log entry is quite long due to the format of 'structured' syslog.

The example below outlines how to use the '|' (pipe) extension to match on certain criteria. In this case the IP address of 192.168.1.102.

This example takes the above command one step further and counts the log entries. This could be used to see if traffic logs to/from the IP address 192.168.1.102 are increasing.


2. View logs from local file on SRX (J-Web)
The security policy logs can also be viewed in J-Web under Monitor --> Events and Alarms --> Security Events. As you can see by the screenshot below there are also fields that can be populated to search for specific logs.




Conclusions
Control plane processing is the most flexible as multiple local log files can be created and log events can also be sent to syslog servers simultaneously. The downside to control plane logging is it can be a burden on the control plane resources.

In high traffic installations that leverage High End / Data Centre SRX devices control plane log processing can simply be unfeasible. In these cases data plane log processing is needed. Log message types are the same regardless of control plane vs. data plane processing.

Structured syslog format logging events can be parsed easily, however if most of the events will be viewed in the CLI traditional formatted syslog messages will take less space to view on the command line.

This concludes the posts on Security Policy. The next posts will focus on Unified Threat Management (UTM) topics.


3 comments:

  1. Does this mean that I cannot use local files without event logging?

    I have stream mode on my 550's and nothing is logged locally with or without a match statement.

    ReplyDelete
  2. In stream mode the logs are forwarded directly to an external logging server. If you want to view/store logs locally on the SRX you will need to configure event mode.
    Stefan

    ReplyDelete
  3. This post is AWESOME, I found it very useful, thanks SO MUCH =D

    ReplyDelete