Junos : Multiple products affected by SSL "POODLE" vulnerability

he SSL protocol 3.0 (SSLv3) uses nondeterministic CBC padding, which makes it easier for man-in-the-middle attackers to obtain cleartext data via a padding-oracle attack.  This issue is also known as the "POODLE" vulnerability.

SSL v3 is an older security protocol with known issues, but still exists as a fallback protocol on many devices.

Vulnerable Products

• Junos OS
• Connect Secure (SA / SSL VPN) / Policy Secure (IC / UAC), MAG Series
• ScreenOS
• Junos Space
• STRM/JSA Series
• NSM (server and NSM4000, NSM3000, NSMXpress appliance)
• Standalone IDP
• Firefly Host (vGW Series)
• SBR Carrier.

Products Not Vulnerable

• JunosE
• QFabric Director
• Juniper owned web servers that provide feature support for ScreenOS and SRX (Deep Inspection (DI), AV, and licensing)

Juniper is continuing to investigate our product portfolio for affected software that is not mentioned above. As new information becomes available this document will be updated.

This issue has been assigned CVE-2014-3566.

Solution:

Junos:
OpenSSL has been upgraded to 0.9.8zc (pre-Junos OS 13.3) and 1.0.1j (Junos OS 13.3+), adding support for SSL 3.0 Fallback protection (TLS_FALLBACK_SCSV).

The following software releases have been updated to resolve this specific issue: Junos OS 11.4R13, 12.1X44-D45, 12.1X46-D26, 12.1X47-D20, 12.3R9, 12.3X48-D10, 13.2R7, ​13.3R5, 14.1R4, 14.1X53-D20, 14.2R2, and all subsequent releases.


Connect Secure (SA / SSL VPN) / Policy Secure (IC / UAC), MAG Series:
Please refer to Pulse Secure TSB16540 for details on mitigating risk from this vulnerability.

ScreenOS:
PR 1033963 has been submitted to Development and to resolve this issue in a future release.

Junos Space:
Disable SSLv3 by changing the following files.

/etc/httpd/conf.d/webProxy.conf
/etc/httpd/conf.d/ssl.conf
/etc/httpd/conf.d/webConf/webProxyCertAuth.conf

The following line needs to be updated to remove references to SSLv3:

Original:
SSLProtocol -ALL +SSLv3 +TLSv1

Updated:
SSLProtocol -ALL +TLSv1

Restart httpd by typing 'service httpd restart'.

A future release of Junos Space will disable SSLv3 by default.

STRM/JSA Series:
Enginering is developing a patch to resolve this issue.

NSM (server and NSM3000/NSMXpress appliance):
SSLv3 has been disabled in 2012.2R10 and all subsequent releases.

Standalone IDP:
Modify /etc/httpd/conf/httpd.conf to add -SSLv3 as below and then restart httpd ('service httpd restart').

Old: SSLProtocol all -SSLv2
New: SSLProtocol all -SSLv2 -SSLv3

Firefly Host (vGW Series):
Resolved in upcoming release 6.0R2 of Firefly Host by adding ssl.use-sslv3 = "disable" to configuration.

---

IDP Signature:
Juniper has released signature SSL:AUDIT:SSL-V3-TRAFFIC in Sigpack 2430 to detect SSLv3 traffic.

Workaround:
Junos:
Since SSL is used for remote network configuration and management applications such as J-Web and SSL Service for JUNOScript (XNM-SSL), viable workarounds for this issue in Junos may include:

• Disabling J-Web
• Disable SSL service for JUNOScript and only use Netconf, which makes use of SSH, to make configuration changes
• Limit access to J-Web and XNM-SSL from only trusted networks

On SRX Series services gateways, Junos Pulse also fetches the configuration file via HTTPS.  To guard against downgrade/SSLv3 MITM attacks, an alternative workaround may be used to disable SSLv3 negotiation:

1. From the root shell:
root@junos% vi /jail/var/etc/httpd.conf

Change the default config of "SSLProtocol ALL -SSLV2" to "SSLProtocol TLSv1"

2. Find the process ID (pid) of httpd and kill/restart it:
root@junos% ps auxw | grep httpd
root@junos% kill -9 (pid of httpd) OR kill -HUP (pid of httpd)

*Note: This change will not survive reboots.  Additionally, executing the 'restart web-management' CLI command will restart the httpd-gk process which will regenerate the default httpd.conf file, overwriting manual changes. Refer to KB18162 for more information about this workaround.


ScreenOS:
A temporary workaround for the server side of ScreenOS you can disable the HTTPS web user interface and the WebAuth feature. If you disable the HTTPS user interface you would be required to do configuration management over command line (SSH). The command to disable SSL is the following:  unset ssl enable

NSM4000, NSM3000, NSMXpress:
For Apache server listening on port 443:

Edit /etc/httpd/conf.d/ssl.conf and change the SSLProtocol entry to:

SSLProtocol all -SSLv2 -SSLv3

and restart HTTPD services.

For webproxy used to download the NSM client on port 8443:

Edit the /usr/netscreen/GuiSvr/lib/webproxy/conf/server.xml

from:

clientAuth="false" sslProtocol="SSL" keystoreFile="VAR-NSROOT-VAR/GuiSvr/lib/webproxy/conf/.webproxy_keystore"

to:

clientAuth="false" sslProtocols="TLSv1,TLSv1.1,TLSv1.2" keystoreFile="VAR-NSROOT-VAR/GuiSvr/lib/webproxy/conf/.webproxy_keystore"

and resart GuiSvr.

Client Side Mitigation:

The risk of attack from negotiating or being forced to downgrade to SSLv3 can be completely mitigated by disabling SSLv3 support in the browser.

Junos: Firewall filter fails to match on port

The issue only affects routers utilizing Trio-based PFE modules running Junos OS 13.3R3, 14.1R1, and 14.1R2 

When configuring a stateless firewall filter on a system with Trio-based PFE modules (e.g. MX Series), any source or destination port matching condition may fail to match intended packets, causing the filter to not execute the actions specified in the 'then' clause.​​​​ Depending on the intent and design of the interface filter, this match failure may have unexpected impact on the router or follow-on filter clauses. For example, if traffic with a specific destination port was designed to be accepted, a later "reject all" clause may inadvertently discard wanted traffic. Conversely, if certain destination ports are meant to be dropped, malicious traffic may be consumed by the RE or forwarded on to downstream routers.

This issue only affects routers running Junos OS 13.3R3, 14.1R1, and 14.1R2. Additionally, this issue only affects IPv4 traffic. IPv6 port matching filters are unaffected by this issue.


Juniper SIRT is not aware of any malicious exploitation of this vulnerability.

No other Juniper Networks products or platforms are affected by this issue.

The following software releases have been updated to resolve this specific issue: Junos OS 13.3R3-S3​, 13.3R4, 14.1R3, 14.2R1, and all subsequent releases.

This issue is being tracked as PR 1003494 ​and is visible on the Customer Support website.

Note: While the vulnerability does not impact versions of Junos prior to 13.3R3, the actual code modified to resolve the issue existed in earlier releases. For this reason, the prsearch tool will report fixes in Junos OS 12.3R8 and 13.2R6, even though the vulnerability was never exposed in these releases.

KB16765 - "In which releases are vulnerabilities fixed?" describes which release vulnerabilities are fixed as per our End of Engineering and End of Life support policies.

Configure Chassis Cluster (High Availability) on a SRX240 device

Configure SRX240 devices as a Chassis Cluster.

The following topology will be used for the configuration:


Topology notes:  

• Both reths (reth 0.0 and reth 1.0) belong to Redundancy Group 1, the data plane. 
• Redundancy Group 0 is the control plane.
• ge-0/0/2 was selected for the fabric (data) link in this example. For the fabric link, a GE port is recommended.

JUNOS : How to block facebook website on Juniper SRX

Action Plan:
To block “http://www.face.com” for users/subnet using Juniper web-filtering and IDP configuration

Web filtering configuration:
#set security utm custom-objects url-pattern facebook value “http://www.facebook.com”
#set security utm custom-objects custom-url-category facebook value facebook
#set security utm feature-profile web-filtering url-blacklist custom-deny
#set security utm feature-profile web-filtering type juniper-local
#set security utm feature-profile web-filtering juniper-local profile local-engine default permit
#set security utm utm-policy webfiltering web-filtering http-profile local-engine For blocking https

 IDP configuration:
[edit security idp]
# set custom-attack youtube_block recommended-action close-client
# set custom-attack youtube_block severity major;
# set custom-attack youtube_block attack-type signature context ssl-cert-common-name
# set custom-attack youtube_block attack-type signature pattern “.*facebook\.com.*”
# set custom-attack youtube_block attack-type signature direction server-to-client
#set custom-attack youtube_client_block recommended-action close-client
# set custom-attack youtube_client_block severity majo
# set custom-attack youtube_client_block attack-type signature context ssl-client-hello
# set custom-attack youtube_client_block attack-type signature pattern “.*facebook\.com.*”
# set custom-attack youtube_client_block attack-type signature direction client-to-server
#set custom-attack-group yout_blck group-members [ facebook_client_block facebook_block ]
#set idp-policy youtube_blck_policy rulebase-ips rule 1 match from-zone trust to-zone untrust application junos-https attacks custom-attack-groups yout_blck
#set idp-policy youtube_blck_policy rulebase-ips rule 1 then action recommended
#set idp-policy youtube_blck_policy rulebase-ips rule 1 then notification log-attacks severity major

How to create and use a custom application on SRX

There are three basic steps to creating a custom application and applying it to a security policy:

1. Create address book entries for the source and destination addresses.
2. Create the custom application if no pre-defined applications encompass the protocol or ports needed.
3. Create a security policy to permit the traffic using the custom application. 

For this example we will configure a policy to permit a custom application using TCP port 1500 from "local-net" 192.168.10.0/24 to "remote-net" 192.168.20.0/24.

1. Create the address book entries for the source and destination addresses

From J-Web:

1. Go to Configuration >Security > Policy Elements.


2. To add an address book entry for each zone, click on Address Books.


3. Click on the zone for which you would like to add an address book entry (example: zone trust).


4. If address book entry required does not exist, then click Add....


5. In the Address Name field specify a name (example: local- net).
   
   Note: The name must be a string beginning with a letter and consisting of letters, numbers, dashes and underscores.


6. In IP Address/Prefix, enter the IP address/subnet mask (example: 192.168.10.0/24). or
   in DNS Name, specify a fully qualified domain name. 
   
   Note: The J Series or SRX Series device must have a working DNS server configured to resolve the domain name.


7. Click OK.


8. Repeat steps 3-7 for zone untrust, Address Book entry remote-net. Click OK again to return to the Security Policies screen.
   

From CLI:

set security zones security-zone trust address-book address local-net 192.168.10.0/24
set security zones security-zone untrust address-book address remote-net 192.168.20.0/24


2. Create a custom application

From J-Web:

1. From Configuration > Security > Policy Elements screen, click on Applications.


2. Select Custom-Applications tab.


3. Click Add...


4. Specify Application Name (example: tcp1500), then click (plus box) for Configure top level options.


5. Click on Match IP protocol, pull down, and choose tcp.


6. Enter 1500 in the free-form field for Destination port (not the pull-down field). Click OK. 
   
   Note: Since the application can use any source port, it is not necessary to also specify a source port for the application.


7. Click OK again to return to the Security Policies screen.

From CLI:

set applications application tcp1500 protocol tcp
set applications application tcp1500 destination-port 1500

Note: If allowing all applications to traverse the Policy, then no custom application is needed since the pre-defined application “any” already exists, which allows all ports.

3. Create a security policy to permit the traffic, using the custom application

From J-Web:

1. From Configuration > Security > Policy screen, click Apply Policy.


2. In Zone Direction, select From Zone trust and To Zone untrust.


3. Click Add a Policy.


4. Specify Policy Name (example: policy-tr-unt), then click (plus box) for Match Criteria.


5. Select Source Address Book local-net object on the right side and click (left arrow) to add to the Matched list.


6. Select Destination Address Book remote-net object and click (left arrow) to add to the Matched list.


7. Select Application tcp1500 and click (left arrow) to add to the Matched list. 


8. For Policy Action, select Permit from the pull-down menu.


9. Click OK to commit changes.  Then click OK again to return to main policy configuration screen.

From CLI:

set security policies from-zone trust to-zone untrust policy policy-tr-unt match source-address local-net
set security policies from-zone trust to-zone untrust policy policy-tr-unt match destination-address remote-net
set security policies from-zone trust to-zone untrust policy policy-tr-unt match application tcp1500
set security policies from-zone trust to-zone untrust policy policy-tr-unt then permit


The ordering of policies is important.  J Series or SRX Series devices will perform policy lookup from top to bottom until a match is found.  At that point no further policy lookup occurs.  Therefore if a deny all policy exists, then be sure that the policy created is above the deny all policy.  If not, then the policy will never be reached.  To re-arrange policy order, use the Move up or down option in the Security Policies screen in J-Web or the insert command in CLI. 

Examples:

Here are two custom applications created for TCP ports 5000 and 5001:

applications {
    application tcp_port_5000 {
        protocol tcp;
        destination-port 5000;
    }
    application tcp_port_5001 {
        protocol tcp;
        destination-port 5001;
    }
}

A security policy to and from the desired security zones is created. Below, we can see the custom application used:

[security policies]
from-zone inside to-zone outside {
    policy telnet_100 {
        match {
            source-address any;
            destination-address host_public;
            application tcp_port_5000;
        }
        then {
            permit
        }
    }
    policy telnet_101 {
        match {
            source-address any;
            destination-address host_public;
            application tcp_port_5001;
        }
        then {
            permit
        }
    }
}

Junos Software Installation/Upgrade

Software Installation Preparation

Read the Release Notes, as they document new features, changes in default behavior, known limitations, and issues.

Set up your connection to the SRX to log your session during the installation and through the reboot, as the transcript can provide valuable information if an issue happens and JTAC needs to review it.

Confirm there are no uncommitted changes present because candidate changes are usually lost on a reboot.  Enter the command: 
                           user@srx# top 
              user@srx# show | compare

If the command contains configuration information that you want to keep, then perform a commit.
Backup your configuration, by logging your session while performing the following command.  Keep it in a safe place.     

user@srx> show configuration | no-more

If you want to backup the current Junos and configuration onto media (such as a USB/CF) so that it can be put back into the SRX if the SRX does not boot up and allow the SRX to boot up







request system snapshot media usb                                                 

If you are going to do a J-Web installation or copy the Junos software image to the SRX, then check the flash size and purge unused files:

Check current Flash size:
show system storage | match cf

Purge logfiles:
request system storage cleanup      

If Flashsize is still lower than the size of your image, then try the following:

• Clear files from the /var/log directory.  Clear or remove any traceoptions files and clear any log files which are not needed.  Note that you will loose all contents of the log file after a clear is done.
  

  clear log <log-filename>

• Purge software backup.  Note that if you delete the backup software, you will not be able to rollback using the "request system software rollback" command.
  

  request system software delete-backup

• Locate directories on the flash with large amount of data
  

  show system directory-usage /cf          

• To save space browse directories and erase files manually:  Be careful with which file you choose to delete.
  

  file list /var/tmp
file delete /var/tmp/xyz

  
  

  Install Software via CLI

  Follow these steps to copy the software to the SRX device and then perform the software installation via the CLI:
  
• Copy software to SRX via SCP or FTP to /var/tmp: 
  

  For example:
  user@srx>  scp  junos-srxsme-11.4R4.4-domestic.tgz  user@srx:/var/tmp/junos-srxsme-11.4R4.4-domestic.tgz
  
  OR
  
  user@srx>  ftp <ip address of local ftp server>  (and login)
user@srx>  lcd /var/tmp
user@srx>  bin
user@srx>  get junos-srxsme-11.4R4.4-domestic.tgz
user@srx>  bye

• Install software with the commands below. 

  For example:
  From the local file in /var/tmp
  user@srx>  request system software add no-copy /var/tmp/junos-srxsme-11.4R4.4-domestic.tgz
user@srx>  request system reboot

  Install Software via CLI

  Follow these steps to install the software via the CLI from a USB stick:
  
• Download the Junos upgrade file to the USB stick. 
  
• Locate the USB device ID that Junos is associating to the USB stick:
  

  user@srx> start shell
user@srx% ls /dev/
  

• Insert the USB device into the USB slot.  For example, slot 0 would return the following:
  

  root# umass0: USB USBFlashDrive, rev 2.00/1.00, addr 2
da0 at umass-sim0 bus 0 target 0 lun 0
da0: <USB USBFlashDrive 0100> Removable Direct Access SCSI-0 device
da0: 1.000MB/s transfers
da0: 980MB (2007040 512 byte sectors: 64H 32S/T 980C)

  Run the following command
  
  user@srx% ls /dev/
  
  Locate difference in outputs to locate drive label. (It will usually be da#s1, i.e. da0s1)
  

• Create a mount directory:
  

  user@srx% mkdir /tmp/usb

• Mount the USB to the directory:
  

  user@srx% mount -t msdosfs /dev/<drivelabel, e.g. #da0s1> /tmp/usb

  Example:
  user@srx% mount -t msdosfs /dev/da0s1 /tmp/usb (there is a space between the label name and /tmp)
  
  Verify that the USB is mounted to the device:
  root@% pwd
/cf/root
root@% cd /var/tmp/usb/
root@% pwd
/cf/var/tmp/usb
root@% ls
junos-jsr-11.4R5.7-export.tgz


• Exit shell and install the software:
  

  user@srx% exit
user@srx> request system software add /tmp/usb/<upgrade filename> no-validate no-copy

• Upon completion, reboot the SRX:
  

  user@srx> request system reboot

• 
  

VPN Monitoring -

When you enable VPN monitoring for a specific tunnel, the security device sends ICMP echo requests (or “pings”) through the tunnel at specified intervals (configured in seconds) to monitor network connectivity through the tunnel.
When Optimized is selected, the VPN monitoring behavior changes as follows:

• The J Series or SRX Series device accepts incoming traffic through the VPN tunnel as a substitute for ICMP echo replies.
• If there is both incoming and outgoing traffic through the VPN tunnel, the J Series or SRX Series device suppresses VPN monitoring pings.

 If you enable VPN monitoring optimization, be aware that VPN monitoring can no longer provide accurate SNMP statistics.
 Configure via CLI:

set security ipsec vpn <vpn-name> vpn-monitor optimized