JTAC recommended versions of Junos software

TAC recommended versions of Junos software are listed to assist with determining which version of software to download and install.
This article applies to the following devices:

• SRX Series

Problem or Goal:

For customers planning an upgrade or initial installation, JTAC recommends the Junos software versions in this article. These versions are selected using input from Juniper Engineering, customers, and analysis of field usage data.

Exceptions to this include:

• JTAC has specifically recommended that customers use a version of Junos software that is different from what is listed.
• You require specific features that are available only in another version of Junos software. In this case, be sure to download the latest maintenance release.
• Your currently installed version of Junos is working well.
• If you use NSM, refer to the NSM & Junos Compatibility Matrix to make sure the recommended Junos software version can be managed by NSM.

Solution:
To download Junos Software, go to the Junos Platforms - Download Software site.
The JTAC Recommended Junos Releases are in the tables below.

SRX Series Services Gateways

Platform	JTAC Recommended Junos Software by Platform	Release Type	Last Updated
vSRX	Junos 15.1X49-D15.4	Standard	04 Sep 2015
SRX100B/H	Junos 12.1X46-D40.2	Standard	18 Nov 2015
SRX100H2	Junos 12.1X46-D40.2	Standard	18 Nov 2015
SRX110H	Junos 12.1X46-D40.2	Standard	18 Nov 2015
SRX110H2	Junos 12.1X46-D40.2	Standard	18 Nov 2015
SRX210B/H/BE/HE	Junos 12.1X46-D40.2	Standard	18 Nov 2015
SRX210H2	Junos 12.1X46-D40.2	Standard	18 Nov 2015
SRX220H	Junos 12.1X46-D40.2	Standard	18 Nov 2015
SRX220H2	Junos 12.1X46-D40.2	Standard	18 Nov 2015
SRX240B/H/B2/H2	Junos 12.1X46-D40.2	Standard	18 Nov 2015
SRX550	Junos 12.1X46-D40.2	Standard	18 Nov 2015
SRX650	Junos 12.1X46-D40.2	Standard	18 Nov 2015
SRX1400	Junos 12.1X46-D40.2	Standard	18 Nov 2015
SRX3400	Junos 12.1X46-D40.2	Standard	18 Nov 2015
SRX3600	Junos 12.1X46-D40.2	Standard	18 Nov 2015
SRX5400	Junos 12.1X46-D40.2 (*1)	Standard	18 Nov 2015
SRX5400 w/RE-1800X4	Junos 12.1X47-D20.7	Standard	11 May 2015
SRX5400 w/IOC3	Junos 15.1X49-D10.1	Standard	04 Sep 2015
SRX5600	Junos 12.1X46-D40.2 (*1)	Standard	18 Nov 2015
SRX5600 w/RE-1800X4	Junos 12.1X47-D20.7	Standard	11 May 2015
SRX5600 w/IOC3	Junos 15.1X49-D10.1	Standard	04 Sep 2015
SRX5800	Junos 12.1X46-D40.2 (*1)	Standard	18 Nov 2015
SRX5800 w/RE-1800X4	Junos 12.1X47-D20.7	Standard	11 May 2015
SRX5800 w/IOC3	Junos 15.1X49-D10.1	Standard	04 Sep 2015

Notes:

1. KB29651 - Unable to upgrade from Junos OS 12.1X46 to subsequent releases of Junos OS on SRX5400/5600/5800 platforms due to "The /cf filesystem is low on free disk space" on SRX5k RE-13-20

ScreenOS 6.3.0r20 has been removed from the Juniper Support Download website

Product Affected:

SSG-5 (&Wireless,ADSL, ISDN, V92), SSG-20 (& Wireless), SSG-140, SSG300M-series, SSG 500/500M Series, ISG-1000, ISG-1000-IDP, ISG-2000, ISG-2000-IDP, NS-5000-MGT2/SPM2, NS-5000-MGT3/SPM3

 
Alert Description:

Reports of problems, after an upgrade, where SSH management, or msrpc traffic could cause the device to core dump.  Due to the severity of this issue, it is necessary to remove 6.3.0r20 from the software download website.

 
Solution:

The repaired version of ScreenOS is 6.3.0R21, and is now currently available.  

Out of Cycle Security Bulletin: ScreenOS: Multiple Security issues with ScreenOS

During an internal code review, two security issues were identified.

Administrative Access (CVE-2015-7755) allows unauthorized remote administrative access to the device. Exploitation of this vulnerability can lead to complete compromise of the affected device.

This issue only affects ScreenOS 6.3.0r17 through 6.3.0r20.  No other Juniper products or versions of ScreenOS are affected by this issue.

Upon exploitation of this vulnerability, the log file would contain an entry that ‘system’ had logged on followed by password authentication for a username.

Example:

Normal login by user username1:
2015-12-17 09:00:00 system warn 00515 Admin user username1 has logged on via SSH from …..
2015-12-17 09:00:00 system warn 00528 SSH: Password authentication successful for admin user ‘username1’ at host …

Compromised login by user username2:
2015-12-17 09:00:00 system warn 00515 Admin user system has logged on via SSH from …..
2015-12-17 09:00:00 system warn 00528 SSH: Password authentication successful for admin user ‘username2’ at host …

Note that a skilled attacker would likely remove these entries from the local log file, thus effectively eliminating any reliable signature that the device had been compromised.

This issue has been assigned CVE-2015-7755.


VPN Decryption (CVE-2015-7756) may allow a knowledgeable attacker who can monitor VPN traffic to decrypt that traffic. It is independent of the first issue.

This issue affects ScreenOS 6.2.0r15 through 6.2.0r18 and 6.3.0r12 through 6.3.0r20. No other Juniper products or versions of ScreenOS are affected by this issue.

There is no way to detect that this vulnerability was exploited.

This issue has been assigned CVE-2015-7756.


Juniper SIRT is not aware of any malicious exploitation of these vulnerabilities, however the password needed for the administrative access has been revealed publicly.

No other Juniper Networks products or platforms are affected by these issues.

Juniper has issued a statement about these vulnerabilities at: http://forums.juniper.net/t5/Security-Incident-Response/bg-p/SIRT

Solution:

The following software releases have been updated to resolve these specific issues: ScreenOS 6.2.0r19, 6.3.0r21, and all subsequent releases.

Additionally, earlier affected releases of ScreenOS 6.3.0 have been respun to resolve these issues. Fixes are included in: 6.3.0r12b, 6.3.0r13b, 6.3.0r14b, 6.3.0r15b, 6.3.0r16b, 6.3.0r17b, 6.3.0r18b, 6.3.0r19b.

All affected software releases on http://www.juniper.net/support/downloads/screenos.html have been updated with these fixes.

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.

Workaround:

The Juniper SIRT strongly recommends upgrading to a fixed release (in Solution section above) to resolve these critical vulnerabilities.

CVE-2015-7755 (unauthorized access) Mitigation
Restricting management access to only trusted management networks and hosts will help mitigate this issue. The attack can only be executed from a location where a legitimate management login would be permitted.

CVE-2015-7756 (VPN decryption) Mitigation
No workaround or detection exists for the VPN decryption vulnerability.

Security Best Current Practice (BCP)
In addition to the recommendations listed above, it is good security practice to limit the exploitable attack surface of critical infrastructure networking equipment. Use access lists or firewall filters to limit management access to the device only from trusted, internal, administrative networks or hosts.

Implementation:
How to obtain fixed software:
ScreenOS software releases are available at http://www.juniper.net/support/downloads/screenos.html

Secure Development Life Cycle

Six practices for improving product security

Juniper Secure Development Life Cycle (SDL) is a process for developing products that are secure and resilient. Juniper’s SDL program is made up of six core practices.

Practice #1: Secure Coding Training

Secure Coding training is the first step in implementing the Secure Development Life Cycle. All software developers at Juniper are required to take this training, which is foundational for building more resilient software. Training is provided in multiple coding languages, with developers taking the appropriate course.

Secure Coding training covers fundamental concepts related to secure coding, secure design, secure testing, and privacy.

Juniper believes that everyone involved in software development is responsible for the security of software products. This includes managers, program managers, testers, and IT personnel. With this in mind, secure development lifecycle training is available to all employees 24 hours a day, 7 days a week, and it offers a range of additional training covering secure coding fundamentals.

Practice #2: Security Considerations in Design

SDL Practice 2 defines the security-related steps that Juniper engineers and product managers must undertake in the planning phase of product development. During this phase, engineers and product managers are required to formally address security risks in Juniper planning documents like functional specifications and product requirements documents.

Practice #3: Threat Modeling

Threat modeling evaluates potential threats to a product. Threat modeling determines risks from those threats and sets the boundaries for a range of appropriate mitigations.

Threat models help developers define product attack surfaces, meaning the breadth and depth of exposure to compromise. For example, a weak password can be exploited by a brute force attack, or the use of a predictable TCP/IP ephemeral port may allow an attacker to mount a TCP reset attack.

Threat modeling builds a framework for deeper security evaluation by identifying and enumerating issues.

Practice #4: Penetration Testing

Once a product’s security posture has been defined, Juniper’s SDL calls for the evaluation and validation of the security risks through penetration testing. Penetration testing is a security evaluation methodology in which ethical hackers mimic real-world attacks to identify methods for circumventing the security features of an application, system, or network. It involves launching real attacks on test systems, using tools and techniques commonly used by adversaries.

Penetration testing makes use of the threat model to devise a penetration test plan based on enumerated attack surfaces and threats.

Practice #5: Release Security Review

The release security review is the examination of a product’s security posture prior to its release with the goal of identifying and evaluating remaining security risks and the findings from all parts of the SDL. The result should be a big picture of the security posture of not just the software release, but the people, systems, and processes that produced it and have to support it over its lifecycle.

Practice #6: Incident Response Plan

Products released with no known vulnerabilities can become subject to threats over time. The incident response plan outlines how Juniper responds to potential product vulnerabilities and how these threats and mitigations are communicated to customers.

This practice builds on Juniper’s industry-respected Juniper Networks Security Incident Response Team (Juniper SIRT) framework for responding to security issues. In responding to security incidents, the plan relies on existing SIRT tools, best practices, processes, and relationships.

JTAC Recommended Junos Software Versions

SRX Series Services Gateways

Platform	JTAC Recommended Junos Software by Platform	Release Type	Last Updated
vSRX	Junos 15.1X49-D15.4	Standard	04 Sep 2015
SRX100B/H	Junos 12.1X46-D40.2	Standard	18 Nov 2015
SRX100H2	Junos 12.1X46-D40.2	Standard	18 Nov 2015
SRX110H	Junos 12.1X46-D40.2	Standard	18 Nov 2015
SRX110H2	Junos 12.1X46-D40.2	Standard	18 Nov 2015
SRX210B/H/BE/HE	Junos 12.1X46-D40.2	Standard	18 Nov 2015
SRX210H2	Junos 12.1X46-D40.2	Standard	18 Nov 2015
SRX220H	Junos 12.1X46-D40.2	Standard	18 Nov 2015
SRX220H2	Junos 12.1X46-D40.2	Standard	18 Nov 2015
SRX240B/H/B2/H2	Junos 12.1X46-D40.2	Standard	18 Nov 2015
SRX550	Junos 12.1X46-D40.2	Standard	18 Nov 2015
SRX650	Junos 12.1X46-D40.2	Standard	18 Nov 2015
SRX1400	Junos 12.1X46-D40.2	Standard	18 Nov 2015
SRX3400	Junos 12.1X46-D40.2	Standard	18 Nov 2015
SRX3600	Junos 12.1X46-D40.2	Standard	18 Nov 2015
SRX5400	Junos 12.1X46-D40.2 (*1)	Standard	18 Nov 2015
SRX5400 w/RE-1800X4	Junos 12.1X47-D20.7	Standard	11 May 2015
SRX5400 w/IOC3	Junos 15.1X49-D10.1	Standard	04 Sep 2015
SRX5600	Junos 12.1X46-D40.2 (*1)	Standard	18 Nov 2015
SRX5600 w/RE-1800X4	Junos 12.1X47-D20.7	Standard	11 May 2015
SRX5600 w/IOC3	Junos 15.1X49-D10.1	Standard	04 Sep 2015
SRX5800	Junos 12.1X46-D40.2 (*1)	Standard	18 Nov 2015
SRX5800 w/RE-1800X4	Junos 12.1X47-D20.7	Standard	11 May 2015
SRX5800 w/IOC3	Junos 15.1X49-D10.1	Standard	04 Sep 2015

Hardware End of Life Announcement - SRX100, SRX210, SRX240 and SRX650

End of Life for the SRX-series products listed in the attached document. This EOL announcement is effective immediately with a Last Order Date (LOD) of May 1, 2016. On the last order date, the products are removed from the pricelist and are no longer orderable.

How to Configure SRX Security Zones with Junos

You cannot manage the SRX Services Gateway as you would a router. The SRX is a locked-down device. You can’t even ping an interface on the SRX initially, even if it has a valid IP address. The SRX uses the concept of nested security zones. Zones are a critical concept in SRX configuration. No traffic goes in or out unless the security zones are configured properly on the SRX interfaces.
To configure a security zone, you need to associate the interface with a security zone, and then the security zones need to be bound with a routing instance (if there are multiple routing instances).
It sounds complicated, but it’s not. First, you configure the zones and then you associate the interfaces with the zones. Here, we're assuming that you’re using only one routing instance. You can configure a zone with more than one interface. However, each interface can belong to only one zone.
Now, establish two security zones for a simple SRX configuration. One zone is for a local LAN called admins (administration) on interface ge-0/0/0.0, and the other zone is for two links to the Internet called untrust with interfaces ge-0/0/1.0 and ge-0/0/2.0:

root# edit security zones
[edit security zones]
root# set security zone admins
root# set security zone untrust
root# set security zone admins interfaces ge-0/0/0.0
root# set security zone untrust interfaces ge-0/0/1.0
root# set security zone untrust interfaces ge-0/0/2.0

Always configure zones from the perspective of the SRX you are configuring. Many other zones may be on the LAN (trust, accounting, and so on). But this SRX only links to admins and untrust.

Now you can add services to the zones you just configured. Assume that inbound ssh, ftp, and ping traffic is permitted from the untrusted zone.
This is just an example. Before you enable any services at all on your SRX, make sure you truly need them. FTP in particular is often considered risky because FTP has no real security, and you just punched a big hole for it in your security zone.

[edit security zones]
root# set security zone untrust host-inbound-traffic ssh
root# set security zone untrust host-inbound-traffic ftp
root# set security zone untrust host-inbound-traffic ping

Your configuration now looks like this:

[edit security]
zones {
  security-zone untrust {
   host-inbound-traffic {
     system-services {
      ssh;
      ftp;
      ping;
     }
   }   
   interfaces {
     ge-0/0/1.0;
     ge-0/0/2.0; 
   }
  }
  security-zone admins {
   interfaces {
     ge-0/0/0.0;
     }
   }