Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Perimeter Security

    Overview

    The Juniper Networks SRX3600 is deployed in this solution as the edge firewall and provides perimeter security for the virtualized data center network residing between the edge router and core switch. The SRX3600 is configured in active/backup chassis cluster mode. Active/backup high availability is the most common type of high availability firewall deployment and consists of two firewall members of a cluster, one of which actively provides routing, firewall, NAT, VPN, and security services, along with maintaining control of the chassis cluster. In case of chassis cluster failover, the backup firewall will become the active firewall and the active firewall will become the backup.

    Configuring Chassis Clustering

    Configuring chassis cluster requires a minimum of two devices. Here, we are using SRX3600, which has similar hardware and Junos OS software version. Since we only have a single cluster, the solution uses only cluster-id 1 SRX 3600-1 acting as node 0. SRX 3600-2 is configured as node 1. These commands are the only commands where it matters which chassis member you apply them to because the setting is stored in the NVRAM rather than in the configuration itself. The command will also cause the cluster member to reboot, which is common to all current versions of Junos OS.

    To configure chassis clustering, you must first configure the cluster-id and node ID on each cluster member as shown in the following steps:

    1. Configure SRX 3600-1.
      set chassis cluster cluster-id 1 node 0 reboot
    2. Configure SRX 3600-2.
      set chassis cluster cluster-id 1 node 1 reboot

      Note: This set of commands must be run as an operational command and not in configuration mode.

      Control port configuration: Once the chassis members have rebooted, the SRX3600 uses two designated, labeled ports as control ports.

    Configure Chassis Clustering Data Fabric

    Once the SRX3600s are configured as a chassis cluster and control ports have been assigned, the fabric (data) ports of the cluster must be configured. These fabric ports are used to pass real-time objects (RTOs) in Active/Passive mode. RTOs are messages that the nodes use to synchronize information between chassis members of a chassis cluster.

    To configure the data fabric, you must configure two fabric interfaces (one on each chassis) as shown in the following steps. These interfaces are connected to each other to form the fabric link.

    1. Configure SRX 3600-1.
      set interfaces fab0 fabric-options member-interfaces ge-5/0/15
    2. Configure SRX 3600-2.
      set interfaces fab1 fabric-options member-interfaces ge-18/0/15

    Configuring Chassis Clustering Groups

    Since the SRX cluster configuration is held within a single common configuration, we need a way to assign some elements of the configuration to a specific member only. This is done in Junos OS with the node-specific configuration method called groups. The last command uses the node variable to define how the groups are applied to the nodes (each node will recognize its number and accept the configuration accordingly).We also configure out-of-band management on the fxp0 interface of the SRX with separate IP addresses for the individual control planes of the cluster. Node-specific configuration is covered in the next configuration example.

    To configure chassis clustering groups, including the host name, backup-router, and interface addressing, follow these steps:

    1. Configure SRX 3600-1.
      set groups node0 system host-name vdc-edge-fw01-n0set groups node0 system backup-router 10.94.47.62set groups node0 interfaces fxp0 unit 0 family inet address 10.94.47.33/27
    2. Configure SRX 3600-2.
      set groups node1 system host-name vdc-edge-fw01-n1set groups node1 system backup-router 10.94.47.62set groups node1 interfaces fxp0 unit 0 family inet address 10.94.47.34/27
    3. Configure apply groups
      set groups nodeset apply-groups "${node}"

    Configuring Chassis Clustering Redundancy Groups

    The next step in configuring chassis clustering is to configure redundancy groups. Redundancy Group 0 is always for the control plane, while redundancy group 1+ is always for the data plane ports. Because active/backup mode allows only one chassis member to be active at a time, we only define Redundancy Groups 0 and 1. We must also configure how many redundant Ethernet groups we will have active on the device (so that the system can allocate the appropriate resources for it). This is similar to aggregated Ethernet.

    We will also need to define which device has priority (in JSRP, high priority is preferred) for the control plane, as well as which device is preferred to be active for the data plane. Remember that the control plane can be active on a different chassis than the data plane in active/passive (there isn’t anything wrong with this from a technical standpoint, but many administrators prefer having both the control plane and data plane active on the same chassis member).

    To configure redundancy groups and priority, see the following example:

    1. Configure redundancy groups and priority.
      set chassis cluster reth-count 2set chassis cluster redundancy-group 0 node 0 priority 129set chassis cluster redundancy-group 0 node 1 priority 128set chassis cluster redundancy-group 1 node 0 priority 129set chassis cluster redundancy-group 1 node 1 priority 128

    Configuring Chassis Clustering Data Interfaces

    The next step in chassis cluster configuration is to define the actual data interfaces on the platform so that in the event of a data plane failover, the other chassis member will be able to take over the connection seamlessly. This configuration involves defining the membership information of the member interfaces to the RETH interface, defining which redundancy group the RETH interface will be a member of (in Active/Passive it will always be 1,) and finally defining the RETH interface information, such as the IP address of the interface.

    Note: Redundant Ethernet interface LAGs are configured toward the edge firewall and core switch.

    To configure redundant data interfaces on the chassis cluster, follow these steps:

    1. Configure redundant Ethernet LAG interface reth0 toward core switches used as the trust interface.
      [edit] set interfaces reth0 description "Trust Zone toward POD"set interfaces reth0 vlan-taggingset interfaces reth0 redundant-ether-options redundancy-group 1set interfaces reth0 redundant-ether-options minimum-links 1set interfaces reth0 redundant-ether-options lacp activeset interfaces reth0 redundant-ether-options lacp periodic fastset interfaces reth0 unit 0 vlan-id 10set interfaces reth0 unit 0 family inet address 192.168.25.3/24
    2. Configure member links for the reth0 from node 0. (Once the chassis cluster is configured, everything can be configured from the primary node as the cluster behaves as a single, physical chassis.)
      [edit]set interfaces xe-3/0/0 gigether-options redundant-parent reth0set interfaces xe-3/0/1 gigether-options redundant-parent reth0set interfaces xe-4/0/0 gigether-options redundant-parent reth0set interfaces xe-4/0/1 gigether-options redundant-parent reth0
      ….
      set interfaces xe-16/0/0 gigether-options redundant-parent reth0set interfaces xe-16/0/1 gigether-options redundant-parent reth0set interfaces xe-17/0/0 gigether-options redundant-parent reth0set interfaces xe-17/0/1 gigether-options redundant-parent reth0
    3. Configure redundant Ethernet LAG interface reth1 toward edge routers used as the untrust interface.
      [edit]set interfaces reth1 description "Untrust Zone toward Edge-routers"set interfaces reth1 vlan-taggingset interfaces reth1 redundant-ether-options redundancy-group 1set interfaces reth1 redundant-ether-options minimum-links 1set interfaces reth1 redundant-ether-options lacp activeset interfaces reth1 redundant-ether-options lacp periodic fastset interfaces reth1 unit 0 vlan-id 11set interfaces reth1 unit 0 family inet address 192.168.26.3/24set interfaces reth1 unit 0 family inet address 10.94.127.30/27
    4. Configure redundant member links for reth0 (can be done from node0).
      [edit]set interfaces xe-1/0/0 gigether-options redundant-parent reth1set interfaces xe-1/0/1 gigether-options redundant-parent reth1set interfaces xe-2/0/0 gigether-options redundant-parent reth1set interfaces xe-2/0/1 gigether-options redundant-parent reth1
      ….
      set interfaces xe-14/0/0 gigether-options redundant-parent reth1set interfaces xe-14/0/1 gigether-options redundant-parent reth1set interfaces xe-15/0/0 gigether-options redundant-parent reth1set interfaces xe-15/0/1 gigether-options redundant-parent reth1

    Configuring Chassis Clustering – Security Zones and Security Policy

    Once chassis clustering is completely configured, the RETH interfaces should be assigned to the appropriate security zones and virtual routers. Going forward, the configuration will reference RETH interfaces instead of individual member interfaces. For this example, we are simply going to leave the RETH0 and RETH1 interfaces in the default virtual router inet.0, which does not require any additional configuration. Additional configuration of the perimeter security includes the following steps:

    • Zone and address book configuration
    • Security policy configuration

    To configure security on the SRX chassis cluster, follow these steps:

    1. Configure security zones and address books.
      [edit]set security zones functional-zone management host-inbound-traffic system-services sshset security zones functional-zone management host-inbound-traffic system-services httpsset security zones functional-zone management host-inbound-traffic protocols allset security zones security-zone untrust address-book address TVM-Client-Subnet 10.10.0.0/16set security zones security-zone untrust address-book address TrafficGenerator-External 10.40.0.0/16
      set security zones security-zone untrust host-inbound-traffic protocols allset security zones security-zone untrust interfaces reth1.0 host-inbound-traffic system-services allset security zones security-zone untrust interfaces reth1.0 host-inbound-traffic protocols all
      set security zones security-zone trust address-book address SA-server1 10.94.63.24/32set security zones security-zone trust address-book address SP-Server 10.94.127.180/32set security zones security-zone trust address-book address Exchange-Server 10.94.127.181/32set security zones security-zone trust address-book address MediaWiki-Server 10.94.127.182/32set security zones security-zone trust address-book address TVM-Server-Subnet 10.20.127.0/24set security zones security-zone trust address-book address TrafficGenerator-Internal-502 10.30.0.0/16set security zones security-zone trust address-book address TrafficGenerator-Internal-503 10.30.0.0/16set security zones security-zone trust address-book address TrafficGenerator-Internal-504 10.30.0.0/16set security zones security-zone trust address-book address TrafficGenerator-Internal-501 10.30.0.0/16set security zones security-zone trust address-book address TrafficGenerator-Internal-505 10.30.0.0/16
      set security zones security-zone trust host-inbound-traffic protocols allset security zones security-zone trust interfaces reth0.0 host-inbound-traffic system-services allset security zones security-zone trust interfaces reth0.0 host-inbound-traffic protocols all
    2. Configure outbound security policy for traffic sourcing from the trust zone (reth0) to the untrust zone (reth1).
      [edit]set security policies from-zone trust to-zone untrust policy Internet-access match source-address anyset security policies from-zone trust to-zone untrust policy Internet-access match destination-address anyset security policies from-zone trust to-zone untrust policy Internet-access match application junos-httpset security policies from-zone trust to-zone untrust policy Internet-access match application junos-httpsset security policies from-zone trust to-zone untrust policy Internet-access match application junos-http-extset security policies from-zone trust to-zone untrust policy Internet-access match application junos-ntpset security policies from-zone trust to-zone untrust policy Internet-access match application junos-dns-udpset security policies from-zone trust to-zone untrust policy Internet-access match application ICMPset security policies from-zone trust to-zone untrust policy Internet-access then permit
    3. Configure inbound security policies for traffic sourcing from the untrust zone (reth1) to the trust zone (reth0).
      [edit]set security policies from-zone untrust to-zone trust policy remote-access match source-address anyset security policies from-zone untrust to-zone trust policy remote-access match destination-address SA-server1set security policies from-zone untrust to-zone trust policy remote-access match application junos-httpsset security policies from-zone untrust to-zone trust policy remote-access then permit
      set security policies from-zone untrust to-zone trust policy Exchange-Access match source-address anyset security policies from-zone untrust to-zone trust policy Exchange-Access match destination-address Exchange-Serverset security policies from-zone untrust to-zone trust policy Exchange-Access match application junos-imapset security policies from-zone untrust to-zone trust policy Exchange-Access match application junos-pop3set security policies from-zone untrust to-zone trust policy Exchange-Access match application junos-ms-rpc-msexchangeset security policies from-zone untrust to-zone trust policy Exchange-Access match application junos-httpset security policies from-zone untrust to-zone trust policy Exchange-Access match application junos-httpsset security policies from-zone untrust to-zone trust policy Exchange-Access match application junos-http-extset security policies from-zone untrust to-zone trust policy Exchange-Access match application junos-ms-rpc-msexchange-directory-nspset security policies from-zone untrust to-zone trust policy Exchange-Access match application junos-ms-rpc-msexchange-directory-rfrset security policies from-zone untrust to-zone trust policy Exchange-Access match application junos-ms-rpc-msexchange-info-storeset security policies from-zone untrust to-zone trust policy Exchange-Access match application Exchangeset security policies from-zone untrust to-zone trust policy Exchange-Access match application junos-smtpset security policies from-zone untrust to-zone trust policy Exchange-Access then permitset security policies from-zone untrust to-zone trust policy MediaWiki-Access match source-address anyset security policies from-zone untrust to-zone trust policy MediaWiki-Access match destination-address MediaWiki-Serverset security policies from-zone untrust to-zone trust policy MediaWiki-Access match application junos-httpset security policies from-zone untrust to-zone trust policy MediaWiki-Access match application junos-httpsset security policies from-zone untrust to-zone trust policy MediaWiki-Access match application junos-http-extset security policies from-zone untrust to-zone trust policy MediaWiki-Access then permitset security policies from-zone untrust to-zone trust policy SharePoint-Access match source-address anyset security policies from-zone untrust to-zone trust policy SharePoint-Access match destination-address SP-Serverset security policies from-zone untrust to-zone trust policy SharePoint-Access match application junos-httpset security policies from-zone untrust to-zone trust policy SharePoint-Access match application junos-httpsset security policies from-zone untrust to-zone trust policy SharePoint-Access match application junos-http-extset security policies from-zone untrust to-zone trust policy SharePoint-Access match application SharePointset security policies from-zone untrust to-zone trust policy SharePoint-Access then permitset security policies from-zone untrust to-zone trust policy ICMP-allow match source-address anyset security policies from-zone untrust to-zone trust policy ICMP-allow match destination-address anyset security policies from-zone untrust to-zone trust policy ICMP-allow match application ICMPset security policies from-zone untrust to-zone trust policy ICMP-allow then permit

    Verification

    The following verification commands (with sample output) can be used to confirm that the SRX chassis cluster is configured properly.

    Results

    1. Verify chassis cluster configuration.
      root@vdc-edge-fw01-n0> show chassis cluster status
      Cluster ID: 1 
      Node                  Priority          Status    Preempt  Manual failover
      
      Redundancy group: 0 , Failover count: 1
          node0                   129         primary        no       no  
          node1                   128         secondary      no       no  
      
      Redundancy group: 1 , Failover count: 1
          node0                   129         primary        no       no  
          node1                   128         secondary      no       no  
      

    Configuring Network Address Translation

    Network Address Translation (NAT) is a method for modifying or translating network address information in packet headers. Either or both source and destination addresses in a packet can be translated. NAT can include the translation of port numbers as well as IP addresses. In this solution, we are using Source and Destination NAT.

    Configure Source NAT

    Source NAT is the translation of the source IP address of a packet leaving the Juniper Networks device. Source NAT is used to allow hosts with private IP addresses to access a public network. Here, we have defined translation of the original source IP address to an IP address from a user-defined address pool with Port Address Translation. The association between the original source IP address to the translated source IP address is dynamic. The configuration uses a source network (172.16.0.0/16) which is translated to the public pool address range (10.94.127.1 to 10.94.127.10). Proxy ARP is a required element of the solution for the address range 10.94.127.1/32 to 10.94.127.11/32 on interface reth1.0. Proxy ARP allows the Juniper Networks security device to respond to ARP requests received on the interface for the translated addresses (rather than only responding to ARP requests destined for the IP address of the firewall’s logical interfaces).

    Source NAT configuration is outlined in the following configuration example.

    To configure source NAT on the SRX chassis cluster, follow these steps:

    1. Configure the source NAT pool.
      [edit]set security nat source pool public-pool address 10.94.127.1/32 to 10.94.127.10/32
    2. Configure the source NAT rule set.
      [edit]set security nat source rule-set Internet-access from zone trustset security nat source rule-set Internet-access to zone untrustset security nat source rule-set Internet-access rule datacenter match source-address 172.16.0.0/16set security nat source rule-set Internet-access rule datacenter match destination-address 0.0.0.0/0set security nat source rule-set Internet-access rule datacenter then source-nat pool public-pool
    3. Configure proxy ARP on the outbound NAT interface (reth1, or untrust, in this example).
      [edit]set security nat proxy-arp interface reth1.0 address 10.94.127.1/32 to 10.94.127.10/32

    Configure Destination NAT

    Destination NAT is the translation of the destination IP address of a packet entering the Juniper Networks device. Destination NAT is used to redirect traffic destined to a virtual host (identified by the original destination IP address) to the real host (identified by the translated destination IP address). Destination NAT allows connections to be initiated only for incoming network connections—for example, from the Internet to a private network. The following configuration parameters were used in the below example:

    1. Destination NAT pool dst-nat-SA-pool1 contains the IP address 10.94.63.24/32. This device is a Juniper Networks SA Series SSL VPN Appliance (Remote Access Server). This device can also be provisioned as a virtual appliance.
    2. Destination NAT rule set SA with rule SA-rule1 to match packets received to destination IP address 10.94.127.33/32. For matching packets, the destination address is translated to the address in the dst-nat-pool-1 pool.
    3. Proxy ARP for the address 10.94.127.33/32 on interface reth1.0. This allows the Juniper Networks security device to respond to ARP requests received on the interface for that address.
    4. Security policies to permit traffic from the untrust zone to the translated destination IP address in the trust zone.

    Note: When destination NAT is performed, the destination IP address is translated according to configured destination NAT rules and then security policies are applied.

    To configure destination NAT on the SRX chassis cluster, follow these steps:

    1. Configure the destination NAT pool.
      [edit]set security nat destination pool dst-nat-SA-pool1 address 10.94.63.24/32
    2. Configure the destination NAT rule set.
      [edit]set security nat destination rule-set SA from zone untrustset security nat destination rule-set SA rule SA-rule1 match destination-address 10.94.127.33/32set security nat destination rule-set SA rule SA-rule1 then destination-nat pool dst-nat-SA-pool1
    3. Configure the proxy ARP on the inbound NAT interface.
      [edit] set security nat proxy-arp interface reth1.0 address 10.94.127.33/32

    Verification

    The following verification commands (with sample output) can be used to confirm that the NAT is configured properly.


    Results

    1. Verify the source NAT pool creation.
      root@vdc-edge-fw01-n1> show security nat source pool all
      node0:
      --------------------------------------------------------------------------
      Total pools: 1
       
      Pool name          : public-pool
      Pool id            : 4
      Routing instance   : default
      Host address base  : 0.0.0.0
      Port               : [1024, 63487] 
      port overloading   : 1
      Total addresses    : 10
      Translation hits   : 0
      Address range                        Single Ports   Twin Ports 
              10.94.127.1 - 10.94.127.10       12             0    
      
      node1:
      --------------------------------------------------------------------------
      Total pools: 1
       
      Pool name          : public-pool
      Pool id            : 4
      Routing instance   : default
      Host address base  : 0.0.0.0
      Port               : [1024, 63487]      
      port overloading   : 1
      Total addresses    : 10
      Translation hits   : 25470
      Address range                        Single Ports   Twin Ports 
              10.94.127.1 - 10.94.127.10       15             0    
      
    2. Verify the source NAT rule set configuration.
      root@vdc-edge-fw01-n1> show security nat source
      node0:
      --------------------------------------------------------------------------
      Total port number usage for port translation pool: 645120
      Maximum port number for port translation pool: 268435456
      Total pools: 1
      Pool                 Address                  Routing              PAT  Total 
      Name                 Range                    Instance                  Address
      public-pool          10.94.127.1-10.94.127.10 default              yes  10   
      
      Total rules: 1
      Rule name          Rule set       From              To                   Action
      datacenter         Internet-access trust            untrust              public-pool
      
      node1:
      --------------------------------------------------------------------------
      Total port number usage for port translation pool: 645120
      Maximum port number for port translation pool: 268435456
      Total pools: 1
      Pool                 Address                  Routing              PAT  Total 
      Name                 Range                    Instance                  Address
      public-pool          10.94.127.1-10.94.127.10 default              yes  10   
                                              
      Total rules: 1
      Rule name          Rule set       From              To                   Action
      datacenter         Internet-access trust            untrust              public-pool
      
    3. Verify source NAT rules, match conditions, actions, and rule order .
      root@vdc-edge-fw01-n1> show security nat source rule all
      node0:
      --------------------------------------------------------------------------
      Total rules: 1
      Total referenced IPv4/IPv6 ip-prefixes: 2/0
       
      source NAT rule: datacenter           Rule-set: Internet-access 
        Rule-Id                    : 1  
        Rule position              : 1
        From zone                  : trust
        To zone                    : untrust
        Match
          Source addresses         : 172.16.0.0      - 172.16.255.255
          Destination addresses    : 0.0.0.0         - 255.255.255.255
          Destination port         : 0               - 0
        Action                        : public-pool 
          Persistent NAT type         : N/A              
          Persistent NAT mapping type : address-port-mapping 
          Inactivity timeout          : 0
          Max session number          : 0 
        Translation hits           : 0
      
      node1:
      --------------------------------------------------------------------------
      Total rules: 1                          
      Total referenced IPv4/IPv6 ip-prefixes: 2/0
      
      source NAT rule: datacenter Rule-set: Internet-access Rule-Id : 1 Rule position : 1 From zone : trust To zone : untrust Match Source addresses : 172.16.0.0 - 172.16.255.255 Destination addresses : 0.0.0.0 - 255.255.255.255 Destination port : 0 - 0 Action : public-pool Persistent NAT type : N/A Persistent NAT mapping type : address-port-mapping Inactivity timeout : 0 Max session number : 0 Translation hits : 25621 {primary:node1}

    Configuring Intrusion Detection and Prevention

    The Junos OS 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. An IDP policy defines how your device handles the network traffic. It allows you to enforce various attack detection and prevention techniques on traffic traversing your network.

    A policy is made up of rulebases, and each rulebase is comprised of a set of rules. You define rule parameters, such as traffic match conditions, action, and logging requirements, and then add the rules to rule bases. After you create an IDP policy by adding rules in one or more rulebases, you can select that policy to be the active policy on your device. Junos OS allows you to configure multiple IDP policies, but a device can have only one active IDP policy at a time. You can install the same IDP policy on multiple devices, or you can install a unique IDP policy on each device in your network. A single policy can contain only one instance of any type of rulebase.

    For transit traffic to pass through IDP inspection, you configure a security policy and enable IDP application services on all traffic that you want to inspect. Security policies contain rules defining the types of traffic permitted on the network and how the traffic is treated inside the network. Enabling IDP in a security policy directs traffic that matches the specified criteria to be checked against the IDP rulebases.

    Note: The action set in the security policy action must be permit. You cannot enable IDP for traffic that the device denies or rejects.

    To install and configure IDP on the SRX chassis cluster, follow these steps:

    Install an IDP license to enable IDP signature updates. In order to download and use the predefined attack signatures in a policy, the IDP license must be installed. If you are using only custom signatures, you do not need an IDP license. Once your license file is purchased and available, install the license using the Junos OS terminal.

    1. root@vdc-edge-fw01-n1> request system license add terminal
      [Type ^D at a new line to end input,
       enter blank line between each license key]
      Serial No :              AB0813AA0021
      Model :                  SRX3600
      Features :               SRX3600-APPSEC-A-1 0
      Issue Date :             17-Dec-2013
      Expiration Date :        16-Dec-2014
      License Id :             JUNOS466173
      License Key : 
      JUNOS466173 aeaqea qmifbd aobrgn aucmbq giyqqb qcdw7l
                  rqbea4 ujbpu2 q4esq2 sucbpr wrroiw w5kgvv
                  35oxsq ne4ynp ljbecm c5ug52 3s6cbj ldpuqj
                  xny
      
      
    2. Once you install the license, check for feature “idp-sig”.
      root@vdc-edge-fw01-n0> show system license
      License usage: 
                                       Licenses     Licenses    Licenses    Expiry
        Feature name                       used    installed      needed 
        idp-sig                               1            1           0    2014-12-15 16:00:00 PST
        appid-sig                             0            2           0    2014-12-15 16:00:00 PST
        logical-system                        1            1           0    permanent
      
      Licenses installed: License identifier: JUNOS466166 License version: 2 Valid for device: AB0813AA0014 Features: idp-sig - IDP Signature date-based, 2013-12-16 16:00:00 PST - 2014-12-15 16:00:00 PST License identifier: JUNOS466167 License version: 2 Valid for device: AB0813AA0014 Features: appid-sig - APPID Signature date-based, 2013-12-16 16:00:00 PST - 2014-12-15 16:00:00 PST
      License identifier: JUNOS466168 License version: 2 Valid for device: AB0813AA0014 Features: appid-sig - APPID Signature date-based, 2013-12-16 16:00:00 PST - 2014-12-15 16:00:00 PST

      Note: If configuring a firewall cluster, a firewall clustering license is required on both nodes of the cluster. The license is device specific.

    3. Download and install the signature database. After the IDP license is installed, the iDP signature database can be downloaded and installed by performing the following steps:
      • Make sure the device has the necessary configuration for connectivity to the Internet. A name server must be configured.
      • Configure the signature database URL.
      set security idp security-package url https://services.netscreen.com/cgi-bin/index.cgi
    4. Verify the version of the signature database in the Signature DB server. Look for “successfully retrieved”. In this example, the version in the server is 2327.
      root@vdc-edge-fw01-n0> request security idp security-package download check-server
      node0:
      --------------------------------------------------------------------------
      Successfully retrieved from(https://services.netscreen.com/cgi-bin/index.cgi).
      Version info:2345(Detector=12.6.140140207, Templates=2345)
      
      {primary:node0}
      
    5. Download the signature database (operational command, not configuration command).
      root@vdc-edge-fw01-n0> request security idp security-package download
      node0:
      --------------------------------------------------------------------------
      Will be processed in async mode. Check the status using the status checking CLI
      
      {primary:node0}
      root@vdc-edge-fw01-n0> request security idp security-package download status 
      node0:
      --------------------------------------------------------------------------
      In progress:platforms.xml.gz                            100 % 250 Bytes/ 250 Bytes
      
      {primary:node0}
      root@vdc-edge-fw01-n0> request security idp security-package download status    
      node0:
      --------------------------------------------------------------------------
      Done;Successfully downloaded from(https://services.netscreen.com/cgi-bin/index.cgi)
      and synchronized to backup.
      Version info:2345(Wed Feb 12 19:13:53 2014 UTC, Detector=12.6.140140207)
      
      {primary:node0}
      
    6. Verify the progress of the IDP signature download.
      root@vdc-edge-fw01-n0> request security idp security-package download status
      node0:
      --------------------------------------------------------------------------
      In progress:platforms.xml.gz                            100 % 250 Bytes/ 250 Bytes
      
      {primary:node0}
      root@vdc-edge-fw01-n0> request security idp security-package download status    
      node0:
      --------------------------------------------------------------------------
      Done;Successfully downloaded from(https://services.netscreen.com/cgi-bin/index.cgi)
      and synchronized to backup.
      Version info:2345(Wed Feb 12 19:13:53 2014 UTC, Detector=12.6.140140207)
      
    7. Install the IDP database.
      request security idp security-package install
    8. Monitor the status of the install command.
      root@vdc-edge-fw01-n0> request security idp security-package install status
      node0:
      --------------------------------------------------------------------------
      In progress:Updating with new attack or detector for existing running policy...
      
      node1:
      --------------------------------------------------------------------------
      Done;Attack DB update : successful - [UpdateNumber=2345,ExportDate=Wed Feb 12 19:13:53 2014 UTC,Detector=12.6.140140207]
           Updating control-plane with new detector : successful
           Updating data-plane with new attack or detector : successful
            (The last known good detector link has been updated with the new detector)
      
    9. Once the security policy is configured and the action is set to “permit”, enable IDP under “application services”. This redirects traffic that matches the security policy to the IDP service for inspection. Below is an example of traffic flowing from the trust to the untrust Internet-access security policy.
      root@vdc-edge-fw01-n0# show security policies from-zone trust to-zone untrust policy Internet-access | display set
      set security policies from-zone trust to-zone untrust policy Internet-access match source-address anyset security policies from-zone trust to-zone untrust policy Internet-access match destination-address anyset security policies from-zone trust to-zone untrust policy Internet-access match application junos-httpset security policies from-zone trust to-zone untrust policy Internet-access match application junos-httpsset security policies from-zone trust to-zone untrust policy Internet-access match application junos-http-extset security policies from-zone trust to-zone untrust policy Internet-access match application junos-ntpset security policies from-zone trust to-zone untrust policy Internet-access match application junos-dns-udpset security policies from-zone trust to-zone untrust policy Internet-access match application ICMPset security policies from-zone trust to-zone untrust policy Internet-access then permit application-services idp
    10. Enable IDP for inbound traffic (flowing from the untrust security zone to the trust security zone). Once IDP is enabled in a security policy, the IDP policy should be activated, monitored for effectiveness, and tuned. The command used to activate the IDP policy in this example is:
      set security idp active-policy HTTP-inspection

      Note: There can be only one active IDP policy. The active IDP policy can be applied to multiple rules.

    11. The following display set configuration shows a complete policy called HTTP-inspection on the perimeter firewall. In this example, two rules are created. The R1 rule is from the trust security zone to the untrust security zone. The R2 rule monitors traffic from the untrust security zone to the trust security zone. The IDP rulebase is configured to match Web-based attacks. Finally, the policy is activated as shown in Step 10 using the command set security idp active-policy HTTP-inspection.
      root@vdc-edge-fw01-n0# show security idp | display set
      set security idp idp-policy HTTP-inspection rulebase-ips rule R1 match from-zone trustset security idp idp-policy HTTP-inspection rulebase-ips rule R1 match source-address anyset security idp idp-policy HTTP-inspection rulebase-ips rule R1 match to-zone untrustset security idp idp-policy HTTP-inspection rulebase-ips rule R1 match destination-address anyset security idp idp-policy HTTP-inspection rulebase-ips rule R1 match application defaultset security idp idp-policy HTTP-inspection rulebase-ips rule R1 match attacks predefined-attack-groups "Critical - HTTP"set security idp idp-policy HTTP-inspection rulebase-ips rule R1 match attacks predefined-attack-groups "Major - HTTP"set security idp idp-policy HTTP-inspection rulebase-ips rule R1 then action drop-connectionset security idp idp-policy HTTP-inspection rulebase-ips rule R1 then notification log-attacksset security idp idp-policy HTTP-inspection rulebase-ips rule R1 then severity criticalset security idp idp-policy HTTP-inspection rulebase-ips rule R2 match from-zone untrustset security idp idp-policy HTTP-inspection rulebase-ips rule R2 match source-address anyset security idp idp-policy HTTP-inspection rulebase-ips rule R2 match to-zone trustset security idp idp-policy HTTP-inspection rulebase-ips rule R2 match destination-address anyset security idp idp-policy HTTP-inspection rulebase-ips rule R2 match application defaultset security idp idp-policy HTTP-inspection rulebase-ips rule R2 match attacks predefined-attack-groups "Critical - HTTP"set security idp idp-policy HTTP-inspection rulebase-ips rule R2 match attacks predefined-attack-groups "Major - HTTP"set security idp idp-policy HTTP-inspection rulebase-ips rule R2 then action drop-connectionset security idp idp-policy HTTP-inspection rulebase-ips rule R2 then notification log-attacksset security idp idp-policy HTTP-inspection rulebase-ips rule R2 then severity criticalset security idp active-policy HTTP-inspectionset security idp security-package url https://services.netscreen.com/cgi-bin/index.cgi

    Verification

    The following verification commands (with sample output) can be used to confirm that IDP is configured and working properly.


    Results

    1. The show security idp status command output verifies that IDP is configured and running.
      root@vdc-edge-fw01-n1> show security idp status
      node0:
      --------------------------------------------------------------------------
      State of IDP: Default,  Up since: 2014-02-10 19:51:58 PST (3d 23:29 ago)
      
      Packets/second: 1               Peak: 4658 @ 2014-02-13 22:34:57 PST
      KBits/second  : 1               Peak: 1459 @ 2014-02-13 22:34:57 PST
      Latency (microseconds): [min: 0] [max: 0] [avg: 0]
      
      Packet Statistics:
       [ICMP: 0] [TCP: 146727] [UDP: 523] [Other: 0]
      
      Flow Statistics:
        ICMP: [Current: 0] [Max: 42 @ 2014-02-13 09:14:29 PST]
        TCP: [Current: 2] [Max: 48 @ 2014-02-12 12:31:09 PST]
        UDP: [Current: 0] [Max: 30 @ 2014-02-12 06:00:33 PST]
        Other: [Current: 0] [Max: 0 @ 2014-02-10 19:51:58 PST]
      
      Session Statistics:
       [ICMP: 0] [TCP: 1] [UDP: 0] [Other: 0]
      
      Number of SSL Sessions : 0
      
      
        Policy Name : HTTP-inspection
        Running Detector Version : 12.6.140140207
      
      Forwarding process mode : regular  
      
      node1:
      
      --------------------------------------------------------------------------
      State of IDP: Default,  Up since: 2014-02-11 10:40:32 PST (3d 08:40 ago)
      
      Packets/second: 0               Peak: 0 @ 2014-02-11 10:40:32 PST
      KBits/second  : 0               Peak: 0 @ 2014-02-11 10:40:32 PST
      Latency (microseconds): [min: 0] [max: 0] [avg: 0]
      
      Packet Statistics:
       [ICMP: 0] [TCP: 0] [UDP: 0] [Other: 0]
      
      Flow Statistics:
        ICMP: [Current: 0] [Max: 0 @ 2014-02-11 10:40:32 PST]
        TCP: [Current: 0] [Max: 0 @ 2014-02-11 10:40:32 PST]
        UDP: [Current: 0] [Max: 0 @ 2014-02-11 10:40:32 PST]
        Other: [Current: 0] [Max: 0 @ 2014-02-11 10:40:32 PST]
      
      Session Statistics:
       [ICMP: 0] [TCP: 0] [UDP: 0] [Other: 0]
      
      Number of SSL Sessions : 0
      
      
        Policy Name : HTTP-inspection
        Running Detector Version : 12.6.140140207
      
    2. Verify that the IDP attack table is configured and running on the primary node.
      root@vdc-edge-fw01-n1> show security idp attack table
      node0:
      --------------------------------------------------------------------------
      
      node1:
      --------------------------------------------------------------------------
      
      {primary:node1}
      
    3. Verify that the IDP application statistics are incrementing based on the configured IDP rule set. (output is truncated to show the relevant packet counter on node1.)
      root@vdc-edge-fw01-n1> show security idp application-statistics
      node0:
      --------------------------------------------------------------------------
      IDP applications:
      
        application type                                                 packet count
      DNS                                                                     0
      HTTP                                                                    0
      LDAP                                                                    0
      SSL                                                                     0
      MSRPC                                                                   0
      MSSQL                                                                   0
      MYSQL                                                                   0
      BGP                                                                     0
      
      node1:
      --------------------------------------------------------------------------
      IDP applications:
      
        application type                                                 packet count
      DNS                                                                     36
      HTTP                                                                    4147
      LDAP                                                                    0
      SSL                                                                     747
      MSRPC                                                                   0
      MSSQL                                                                   0
      MYSQL                                                                   0
      
      

    Published: 2015-04-20