JUNOS Software for SRX-series Features

Flow and Processing

• Flow-based stateful processing—In addition to packet processing, JUNOS software for SRX-series performs flow-based stateful processing. When a packet enters the device, the system applies any packet-based filter processing associated with the interface to the packet. Next, the system attempts to match the packet against an existing session based on a session's match criteria (source and destination addresses, source and destination ports, and protocol and session tokens derived from the zone and virtual router). If a packet matches an existing session, the system processes it according to the flow's session features, security policies, screens, and other features. If the packet does not match an existing session, the system establishes a new session for the packet based on routing, policy, and other classification information. Before a packet leaves the device, the system applies filters and traffic shaping to it.
• Distributed multithread flow—The SRX-series services gateway is multicore, multichassis hardware with distributed computing engines. The network processing units (NPUs) on the I/O cards and multicore security processing units (SPUs) on the security processing cards comprise the data plane.

  Packets for any given flow usually traverse two NPUs and possibly more than one SPU (in the case of tunnels). Therefore, a distributed flow module is needed that can span multiple computing engines. Note that combo-mode, in which one SPU directs traffic to itself as well as other SPUs on the SPC, is not supported in this release. Instead, the SPU can direct traffic only to other SPUs.

  To configure flow options, use the flow statement at the set security hierarchy. For more information, see the JUNOS Software Security Configuration Guide.

Interfaces and Routing

• Interfaces—Interfaces act as a doorway through which traffic enters and exits a device. Several security-related configuration and runtime attributes are kept in an interface object. Different modules in the data path use these attributes. Many interfaces can share exactly the same security requirements; however, different interfaces can also have different security requirements for inbound and outbound (I/O) data packets.

  Security processing and inbound and outbound (I/O) data packets analysis are separated in JUNOS software and SRX-series service gateways. As a result, the line-card interface on the input/output card (IOC) and the security processors on the services processing card (SPC) are separated by a fabric. The security data plane is simultaneously performing multiprocessing (32-way MT per XLR SPU) and distributed processing (a maximum of 2 SPUs per SPC). For more information, see the JUNOS Software Interfaces and Routing Configuration Guide.

• Routing—SRX-series services gateways support using the Border Gateway Protocol (BGP), the Open Shortest Path First (OSPF) Protocol, and the Routing Information Protocol (RIP) to deliver routing information across networks. To configure the services gateway to use these protocols, use the bgp, ospf, or rip statements (respectively) at the [protocols] hierarchy level. You can also configure the services gateway to use static routes. For more information, see the JUNOS Software Interfaces and Routing Configuration Guide.

  SRX-series services gateways also support the following additional routing functionality:

  • DHCP—JUNOS software for SRX-series supports Dynamic Host Configuration Protocol (DHCP) client, relay, and server functions, enabling the services gateway to provide IP addresses and settings to hosts that are connected to the device’s interfaces. When you configure the SRX-series device as a DHCP server, hosts can connect to the device's interface via subnet or through DHCP relay. To configure DHCP, use the dhcp statement at the [system services] hierarchy level.
  • DNS—JUNOS software for SRX-series incorporates Domain Name System (DNS) support, enabling the services gateway to reference locations by domain name (such as www.juniper.net) in addition to using the routable IP address. To configure DNS, see the JUNOS Software Administration Guide.
  • NTP—JUNOS software for SRX-series incorporates Network Time Protocol (NTP) support, enabling the services gateway to synchronize time and coordinate time distribution in a large, diverse network. To configure NTP, use the ntp statement at the [system] hierarchy level.

  For more information, see the JUNOS Software Administration Guide.

  Note: Release 9.2 of JUNOS software for the SRX-series services gateway does not support packet-based protocols such as MPLS, Connectionless Network Service (CLNS), and IP version 6 (IPv6).

• IPv4—JUNOS software for SRX-series supports processing IPv4 (IP version 4) traffic through an interface. The IPv4 protocol family supports 32-bit addresses and subnets. To enable the IPv4 protocol for an interface, specify inet for the interface family. For example, use edit interfaces ge-0/0/3 unit 0 family inet address 10.10.10.10/24.
• Class of Service (CoS)—The JUNOS software for SRX-series Class of Service (CoS) feature provides a set of mechanisms that you can use to provide differentiated services when best-effort traffic delivery is insufficient. When a network experiences congestion and delay, some packets must be dropped. JUNOS software for SRX-series CoS allows you to classify and then divide traffic into classes and offer various levels of throughput and packet loss when congestion occurs. This allows packet loss to happen according to rules that you configure. Note that CoS policing is not available in this release.

  You can use an SRX-series services gateway to control traffic rate by applying classifiers and shapers. To configure CoS components, use the component you want to configure at the [edit class-of-service] hierarchy level of the configuration. For more information, see the JUNOS Software Interfaces and Routing Configuration Guide.

Chassis Clustering

• Support for chassis clustering—You can connect the chassis of two SRX 5600 services gateways or two SRX 5800 services gateways to provide stateful failover of JUNOS processes and services. Interchassis clustering removes the single point of failure in the network by allowing the services gateway to be configured in a redundant cluster, with one device acting as the primary and the other as a backup. If the primary fails, the backup takes over traffic processing. Clustered services gateways synchronize configuration, kernel, and Packet Forwarding Engine session states across the cluster to facilitate high availability of interfaces and services. JUNOS software for SRX-series includes the following chassis cluster features:
  • Resilient system architecture includes a single control plane for the entire cluster to manage multiple Packet Forwarding Engines.
  • Configuration and dynamic runtime states are synchronized between the services gateways within a cluster.
  • Graceful restart of the routing protocols enables the services gateway to minimize traffic disruption during a failover.
  • Physical interfaces are grouped and monitored to trigger failover to the backup services gateway if the failure parameters cross a configured threshold.

  For more information, see the JUNOS Software Security Configuration Guide.

  Note: In this release of JUNOS software for SRX-series, synchronization of IDP-specific runtime data does not occur across the cluster. As a result, IDP processing is not continued for sessions that fail over. (IDP processing resumes for sessions created after failover.)

  Note: When configuring chassis clusters, you are automatically in configure private mode. As a result, you must commit changes from the top of the hierarchy. For information about the configure private mode, see the JUNOS CLI User Guide.

Note: In SRX-series services gateways, the offline, online, and restart commands are supported only on IOCs and are not supported on SPCs.

Security

• Security zones—Security zones are the building blocks for policies; they are logical entities to which one or more interfaces are bound. Security zones provide a means of distinguishing groups of hosts (user systems and other hosts, such as servers) and their resources from one another in order to apply different security measures to them. From the perspective of security policies, traffic enters into one security zone (to-zone) and goes out on another (from-zone). To configure security zones, use the zones statement at the [security zones] hierarchy level. For more information, see the JUNOS Software Security Configuration Guide.
• Security policies—Security policies can be configured to control traffic flow from one zone to another by defining a certain action on the kinds of traffic that is allowed from specified sources to specified destinations at scheduled times. When packets match a policy, the policy instructs the flow to apply different rules for features. To configure a policy, use the screen statement at the [set security policies] hierarchy level.
• Firewall screens—JUNOS software for SRX-series provides various detection methods and defense mechanisms to combat the following security breaches at all stages of their execution:
  • SYN, UDP, and ICMP flood attacks
  • Network DoS attacks
  • Operating system-specific DoS attacks

  To configure screen options, use the screen statement at the [set security screen] hierarchy level.

• Firewall user authentication—Firewall user authentication enables you to restrict and permit access to protected resources behind a firewall based on a user’s source IP address and other credentials. You may use pass-through authentication or Web authentication to control access to the protected resources. With pass-through authentication, a user from one zone tries to access resources from another zone over an FTP, Telnet, or HTTP connection. With Web authentication, a user tries to connect to an IP address on the device over an HTTP connection. With both methods, the device forwards the user’s credentials to the server of your choice (local, RADIUS, LDAP, or RSA SecurID) to authenticate the user and control subsequent access requests.

  To configure pass-through authentication, use the following statements:

  set security policies from-zone zone-name to-zone zone-name policy policy-name then permit firewall-authentication pass-through

  To configure Web authentication, use the following statements:

  set security policies from-zone zone-name to-zone zone-name policy policy-name then permit firewall-authentication web-authentication

  For more information, see the JUNOS Software Security Configuration Guide.

• Network Address Translation—Network Address Translation (NAT) is a method by which IP addresses in a packet are mapped from one group to another and, optionally, port numbers in the packet are translated into different port numbers. NAT is described in RFC 1631 to solve IP (version 4) address depletion problems. On an SRX-series services gateway, JUNOS software decouples NAT configuration from policy configuration. NAT has its own rules to regulate traffic on the SRX-series services gateway.

  To configure NAT, use the nat statement at the [set security] hierarchy level. For more information, see the JUNOS Software Security Configuration Guide.

  Note: Release 9.2 of JUNOS software for the SRX-series services gateway does not support Static NAT.

IDP

• IDP Policies—Intrusion Detection and Prevention (IDP) policy enables you to selectively enforce various attack detection and prevention techniques on network traffic passing through an IDP-enabled device. It allows you to define policy rules to match a section of traffic based on a zone, network, and application, and then take active or passive preventive actions on that traffic.

  A policy is made up of rulebases, and each rulebase contains a set of rules. You define rule parameters, such as traffic match conditions, action, and logging requirements and then add the rules to rulebases. You can create new IDP policies from scratch or start with a predefined template provided by Juniper Networks. Juniper Networks also provides custom application objects and attack objects that you can configure as match conditions in policies.

  To configure an IDP policy, use the idp-policy statement at the [edit security idp] hierarchy level. For more information, see the JUNOS Software Security Configuration Guide.

  Note: Installing an IDP Signature Database requires a license.

• IDP Signature Database—Signature database is one of the major components of IDP. It contains definitions of different objects—such as attack objects, application signatures objects, and service objects—that are used in defining IDP policy rules. As a response to new vulnerabilities, Juniper Networks periodically provides a file containing attack database updates on the Juniper Web site.

  To protect your network from new threats, you can download signature database updates manually or configure your device to download them automatically at a specified interval. For more information, see the JUNOS Software Security Configuration Guide.

• IDP Application Identification—Juniper Networks provides predefined application signatures that detect TCP and UDP applications running on nonstandard ports. Identifying these applications allows IDP to apply appropriate attack objects to applications running on nonstandard ports. It also improves performance by narrowing the scope of attack signatures for applications without decoders.

  Application signatures are available as part of the security package provided by Juniper Networks. You download predefined application signatures along with the security package updates. Application identification is enabled by default and is automatically turned on when you configure the default application in the IDP policy. For more information, see the JUNOS Software Security Configuration Guide.

• Protocol Detector Engine—The IDP protocol detector engine contains Application Layer protocol decoders or services. You can download the protocol detector updates along with the signature database updates.

  IDP supports 52 protocol decoders or services. Protocol decoders scan protocol headers and message body to identify individual fields in the protocols to determine if data conforms to the RFC. You configure protocol decoders in IDP policy rules to specify the protocol that an attack uses to access your network. For more information, see the JUNOS Software Security Configuration Guide

• IDP Logging—The basic JUNOS system logging continues to function after IDP is enabled. An IDP-enabled device supports basic JUNOS system logging and continues to record events that occur because of routine operations, such as a user login into the configuration database. It records failure and error conditions, such as failure to access a configuration file. In addition to the regular system log messages, IDP generates event logs for attacks. To manage attack log volume and message size, IDP supports log suppression.

  Enabling log suppression ensures that minimal numbers of logs are generated for the same event or attack that occurs multiple times. To configure log suppression, use the suppression statement at the [edit security idp sensor-configuration log] hierarchy level. For more information, see the JUNOS Software Security Configuration Guide.

• IDP DiffServ Marking—Configuring Differentiated Services Code Point (DSCP) values in IDP policies provides a method of associating class-of-service (CoS) values—thus different levels of reliability—for different types of traffic on the network. DSCP is an integer value encoded in the 6-bit field defined in IP packet headers. It is used to enforce CoS distinctions. CoS allows you to override the default packet-forwarding behavior and assign service levels to specific traffic flows.

  You can configure the DSCP value as an action in an IDP policy rule. Based on the DSCP value, behavior aggregate classifiers set the forwarding class and loss priority for the traffic, determining the forwarding treatment the traffic receives. For more information, see the JUNOS Software Security Configuration Guide.

• IDP J-Web Support—You can configure IDP policies and request security package updates by using Quick Configuration pages in the J-Web user interface. You can also display IDP status and memory usage in the J-Web monitoring pages. For more information, see the JUNOS Software Security Configuration Guide and the JUNOS Software Administration Guide.

J-Web

J-Web User Interface—A graphical user interface enables you to configure, monitor, troubleshoot, and manage the SRX-series devices through an Internet browser. The J-Web interface includes Quick Configuration pages to perform basic configuration of the devices and monitoring tools to view system health, routes, and statistics. The J-Web interface provides diagnostic tools (such as ping and traceroute) and file utilities to manage configuration files, licenses, and temporary files on the device. The J-Web interface also includes a Chassis View, which provides a graphical, dynamic view of the SRX-series of devices. For more information, see the J-Web Interface User Guide.

Management and Administration

Note: NSM-Aragorn (2008.1) supports Viking via forward support.

• Chassis management—JUNOS software for SRX-series provides the ability to monitor and manage select chassis components. This includes monitoring chassis clusters, component temperature and cooling systems, chassis firmware, and chassis location. The CLI also provides commands for bringing most chassis components online and offline.

  To bring chassis components online and offline, use the chassis statement at the [request] hierarchy level. For more information, see the JUNOS Software Security Configuration Guide.

• Packet tracing infrastructure—The JUNOS software for SRX-series trace function provides a tool for applications to write security and security flow debugging information to a file. The information that appears in this file is based on configured criteria. This criteria includes source port, destination port, protocol, interface, and string matching. Use this information to analyze security application issues. The trace function operates in a distributed manner, with each thread writing to its own trace buffer. These trace buffers are then collected at one point, sorted, and written to trace files. Trace messages are delivered using the InterProcess Communications (IPC) protocol.

  To configure traceoptions, use the traceoptions statement at the [set security] hierarchy level. For more information, see the JUNOS Software Security Configuration Guide.

• SPU monitoring—The JUNOS software for SRX-series provides a new JUNOS software-based security device that uses multiple processors to process traffic. SPU monitoring allows for:
  • CPU utilization per SPU in percentage
  • Memory utilization per SPU in percentage

  These metrics provide information that can be used to prevent unexpected outages and look for trends for capacity planning. To monitor the Flexible PIC Concentrator (FPC) card by using the SPU unit’s CPU and memory utilization, use the show security monitoring fpc statement. For more information, see the JUNOS Software Security Configuration Guide.

• System logging—JUNOS software for SRX-series generates separate system log messages (also called syslog messages) to record events that occur on the system’s data and control planes.

  The data plane logs primarily include a list of security events that the system has handled directly inside the data plane. Because the system has already handled these events, it does not send them on to the Routing Engine. Instead, the system streams the logs directly to external log servers, bypassing the Routing Engine. To view the data plane logs, use the log statement at the [security] hierarchy level.

  The control plane logs, on the other hand, include a list of actionable events. The system sends this list of control plane events on to the eventd process on the Routing Engine, which then handles the events using JUNOS event policies and/or by generating system log messages. You can choose to send control plane logs to a file, user terminal, routing platform console, or remote machine.

  To generate control plane logs, use the syslog statement at the [system] hierarchy level. For more information, see the JUNOS Software Administration Guide.

  Note: In SRX-series devices, data plane logs and control plane logs have to be configured separately.