JUNOS for SRX-Series Services Gateways Product Overview

Application Layer Gateways (ALGs)

• FTP ALG

  JUNOS software for SRX-series devices provides File Transfer Protocol (FTP) support for services and applications that transfer data using FTP, allowing legitimate FTP traffic to go through the device while blocking out malicious FTP packets. The FTP ALG monitors PORT, PASV, and 229 commands. It performs Network Address Translation (NAT) of the IP or port in the message and gate opening on the device as necessary.

  To configure the FTP ALG, use the edit security alg ftp statement at the [edit security alg] hierarchy level. For more information, see the JUNOS Software Security Configuration Guide.

• TFTP ALG

  JUNOS software for SRX-series devices provides Trivial File Transfer Protocol (TFTP) support for services and applications that transfer data using TFTP, allowing legitimate TFTP traffic to go through the device while blocking out malicious TFTP packets. The TFTP ALG processes the TFTP packets that initiate the request and opens a pinhole to allow return packets from the reverse direction to the port that sends the request.

  To configure TFTP ALG, use the edit security alg tftp statement at the [edit security alg] hierarchy level. For more information, see the JUNOS Software Security Configuration Guide.

Chassis Clustering

• Chassis clustering—You can connect a pair of the same kind of supported SRX-series devices into a cluster to provide stateful failover of JUNOS processes and services. Interchassis clustering removes the single point of failure in the network by allowing the devices to be configured in a redundant cluster, with one device acting as the primary device and the other as a backup. If the primary device fails, the backup takes over traffic processing. Clustered devices synchronize configuration, kernel, and Packet Forwarding Engine session states across the cluster to facilitate high availability of interfaces and services. JUNOS software 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 devices, 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.

Flow and Processing

• Combo-mode SPU—The central point (CP) in the architecture has two basic flow functionalities: load balancing and traffic identification. However, the central point functionalities and normal flow processing are embedded in a single Services Processing Unit (SPU), and this shared SPU is operating in combination, or combo mode. In combo mode, the number of threads is divided among the central point and the flow services, based on the number of SPUs in the system.

  Note: This feature is applicable only for SRX 3400, SRX 3600, SRX 5600, and SRX 5800 devices.

• Flow-based stateful processing—In addition to packet processing, JUNOS software for SRX-series devices 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) and multicore Services Processing Units (SPUs) on the Services Processing Cards (SPCs) comprise the data plane.

  Packets for any given flow could 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: This feature is applicable only for SRX 3400, SRX 3600, SRX 5600, and SRX 5800 devices.

  To configure flow options, use the flow statement at the [set security] hierarchy level. 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 devices. 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 (SRX 5600 and SRX 5800 devices distribute the processing over a maximum of 2 SPUs per SPC). For more information, see the JUNOS Software Interfaces and Routing Configuration Guide for Security Devices.

• Routing—SRX-series devices 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 for Security Devices.

  SRX-series devices 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.
  • 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 for Security Devices.

  Note: This release of JUNOS software for the SRX-series devices does not support packet-based protocols such as MPLS, Connectionless Network Service (CLNS), and IP version 6 (IPV6).

• IPv4—JUNOS software for SRX-series devices 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 devices 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. 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 devices 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 for Security Devices.

• Network interfaces—SRX 3400 and SRX 3600 devices support a Switch Fabric Board (SFB) and Common Form-factor Module (CFM) slots.

  The following table lists CFM slots on SRX 3400 and SRX 3600 devices:

  Table 2: CFM Slots on SRX 3400 and SRX 3600 Devices

  CFM Type	SRX 3400 Devices	SRX 3600 Devices
  I/O Cards (IOC)	Slots—1 through 4	Slots—1 through 6
  Services Processing Cards (SPC)	Slots—any	Slots—any
  Network Processing Cards (NPC)	Slots—5 through 7	Slots—10 through 12

  The unique name of each network interface identifies its type and location and indicates whether it is a physical interface or an optional logical unit created on a physical interface. The name of each network interface has the following format to identify the physical device that corresponds to a single physical network connector:

  type-slot/pic/port

  For the SRX 3400 and 3600 devices:

  • The Switch Fabric Board (SFB) is always slot 0.
  • The PIC number is always 0. Only one PIC can be installed in a slot.
  • The designated port numbers are described in the following format:
    • For the SFB built-in copper Gigabit Ethernet ports, this number begins at 0 and increases from top to bottom, left to right, to a maximum of 7. For the SFB built-in fiber Gigabit Ethernet ports, this number begins at 8 and increases from left to right to a maximum of 11.
    • For 16-port Gigabit Ethernet IOCs, this number begins at 0 and increases to a maximum of 15.
    • For 2-port 10-Gigabit Ethernet IOCs, this number is 0 or 1.

  Note: This feature is applicable only for SRX 3400 and SRX 3600 devices.

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 policy 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.

• IPsec VPN—A virtual private network (VPN) provides a means for securely communicating among remote computers across a public wide area network (WAN) such as the Internet. Using the JUNOS Software VPN feature, you can secure traffic from your local area network (LAN) to remote users (end-to-site VPN) or between two separate LANs (site-to-site VPN). JUNOS Software uses IP security (IPsec) to secure the VPN traffic at the IP layer, authenticating and encrypting traffic by using phased tunnel negotiations. 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 devices, JUNOS software decouples NAT configuration from policy configuration. NAT has its own rules to regulate traffic on the SRX-series devices.

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

• Static NAT—Static Network Address Translation (NAT) defines a one-to-one static mapping from one IP subnet to another IP subnet. To configure static NAT, use the static statement at the [edit security nat] hierarchy level. For more information, see the JUNOS Software Security Configuration Guide.

Intrusion Detection and Prevention (IDP)

• 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.

• IDP custom attacks and groups—JUNOS CLI support is available for creating IDP custom attacks and groups. You can use the JUNOS configuration statements to configure the required fields. For more information, see the JUNOS Software CLI Reference.
• 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 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 for Security Devices.
• 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 session-limit threshold-crossing event—The number of IDP sessions per SPU is typically 128K, except on 4G SPUs in non-combo mode, where it is set to 256K. These numbers can be found in the IDP documentation. When the number of IDP sessions exceeds the allowed limit, log messages are generated indicating that the number of IDP sessions exceeded the limit. When the number of IDP sessions drops to fewer than 5120 from the allowed high-water mark, another log message will be sent indicating that IDP sessions have dropped below the allowed limit.
• 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.

• IDP 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 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 SSL Inspection—Secure Sockets Layer (SSL) is a protocol suite that consists of different versions, ciphers, and key exchange methods. SSLv2, SSLv3, and TLS protocols are supported. Combined with the Application Identification feature, the SSL Inspection feature enables SRX-series devices to inspect HTTP traffic encrypted in SSL on any TCP/UDP port. SSL inspection is disabled by default and can be enabled by using the configuration CLI. To display all installed keys and associated servers, use the show security idp ssl-inspection key command. This feature is supported on SRX 3400, SRX 3600, SRX 5600, and SRX 5800 devices. For more information, see the JUNOS Software Security Configuration 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.
• J-Web Chassis View—The Chassis View allows the dynamic display of line cards, link states, errors, individual Physical Interface Cards (PICs), Flexible PIC Concentrators (FPCs), fans, power supplies, and so on. It also helps you view the current status of the services gateway.

  The Chassis View appears on the Dashboard page by default when you log in to the services gateway.

  Note: The Chassis View option can be enabled or disabled in the Dashboard Preference dialog box. To access the Dashboard Preference dialog box, click the icon on the upper-right corner of the Dashboard page and select Chassis View from the Dashboard Preference dialog box. You can also enable Chassis View by clearing the Internet Explorer cookies.

  Note: To use the Chassis View, a recent version of Adobe Flash that supports ActionScript and AJAX (version 9 must be installed).

  For more details about how to use the J-Web Chassis View, see the JUNOS Software Administration Guide.

Management and Administration

• Chassis management—JUNOS software for SRX-series devices 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.

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

  The chassis control daemon (chassisd) comprises the following major components:

  • Switch Control Board (SCB)
  • Routing Engine (RE)
  • Network Processing Card (NPC)
  • Services Processing Card (SPC)
  • Input/Output Card (IOC)
  • Power Module (PWM)
  • Front Panel Display (FPD)
  • Fan Tray
  • Map Table fru

    To view chassis details, use the show chassis statement.

    Note: This feature is applicable only for SRX 3400, and SRX 3600 devices.

• System logging—JUNOS software for SRX-series devices 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.

  Note: In SRX-series, data plane logs and control plane logs have to be configured separately only for SRX 3400, SRX 3600, SRX 5600, and SRX 5800.

  For all other SRX-series devices, the system sends this list of control plane events and the security events that the system has handled directly inside the data plane on to the eventd process on the Routing Engine, which then handles the events by 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 and security event generated within the data plane, use the syslog statement at the [system] hierarchy level. For more information, see the JUNOS Software Administration Guide for Security Devices.

• Packet tracing—The JUNOS software for SRX-series devices 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. These criteria include 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 trace options, use the traceoptions statement at the [set security] hierarchy level. For more information, see the JUNOS Software Security Configuration Guide.

• Services Processing Unit (SPU) monitoring—JUNOS software for SRX-series devices 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.

• Simple Network Management Protocol (SNMP)—JUNOS software for SRX-series devices supports SNMP, which is part of the Internet protocol suite that is used to monitor network-attached devices for conditions that warrant administrative attention. SNMP enables the monitoring of network devices from a central location.

  The SNMP agent exchanges network management information with SNMP manager software running on a network management system (NMS), or host. The agent responds to requests for information and actions from the manager. The agent also controls access to the agent’s Management Information Base (MIB), the collection of objects that can be viewed or changed by the SNMP manager. The SNMP manager collects information on network connectivity, activity, and events by polling managed devices.

  A MIB is a hierarchy of information used to define managed objects in a network device. The MIB structure is based on a tree structure, which defines a grouping of objects into related sets. Each object in the MIB is associated with an object identifier (OID), which names the object. The “leaf” in the tree structure is the actual managed object instance, which represents a resource, event, or activity that occurs in your network device. MIBs are either standard or enterprise-specific. Standard MIBs are created by the Internet Engineering Task Force (IETF) and documented in various RFCs. Depending on the vendor, many standard MIBs are delivered with the Network Management System (NMS) software. You can also download the standard MIBs from the IETF Web site, http://www.ietf.org, and compile them into your NMS, if necessary.

  Enterprise-specific MIBs are developed and supported by a specific equipment manufacturer. If your network contains devices that have enterprise-specific MIBs, you must obtain them from the manufacturer and compile them into your network management software. For a list of Juniper Networks enterprise-specific supported MIBs, see “Juniper Networks Enterprise-Specific MIBs” in the JUNOS Network Management Configuration Guide.