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

Restart a Junos OS Process

Action

To restart a Junos OS process, use the following Junos OS CLI operational mode command and include the process you wish to restart. For example:

user@host> restart routing

Sample Output

user@host> restart routing Routing protocol daemon started, pid 751 

Meaning

The sample output shows that the routing protocol daemon was restarted and the process identification (PID) was changed from 685 in the previous sample output to 751. 

Options to Restart a Junos OS Process

Option	Description
class-of-service	Restart the class-of-service process, which controls the router’s class-of-service configuration.
gracefully	Restart the software process by sending the equivalent of a UNIX SIGTERM signal.
immediately	Immediately restart the process by sending the equivalent of a UNIX SIGKILL signal.
interface-control	Restart the interface process, which controls the router’s physical interface devices and logical interfaces.
mib-process	Restart the Management Information Base (MIB) II process, which provides the router’s MIB II agent.
network-access-service	Restart the network access process, which provides the router’s Challenge Handshake Authentication Process (CHAP) authentication service.
remote-operations	Restart the remote operations process, which provides the ping and traceroute MIBs.
routing	Restart the routing protocol process, which controls the routing protocols that run on the router and maintains the routing tables.
sampling	Restart the sampling process, which performs packet sampling and cflowd export.
snmp	Restart the Simple Network Management Process (SNMP) process, which provides the router’s SNMP master agent.
soft	Reread and reactivate the configuration without completely restarting the software processes. For example, Border Gateway Protocol (BGP) peers stay up and the routing table stays constant. This option is the equivalent of a UNIX SIGHUP signal; omitting this option is the equivalent of a UNIX SIGTERM (kill) operation.

SRX Getting Started - Install license for Antivirus, Web Filter, IDP, or Antispam

Following steps involved in installing a license for Antivirus, Web Filter (URL Filter), IDP or Antispam on a SRX device.


Problem or Goal:

Install subscription license

Cause:

Solution:
The following features require a subscription license:

• Antivirus
• Web Filter
• IDP
• Antispam

The high memory system option is also required to use these features. UTM is not supported on the low memory version.  For ordering information, refer to the SRX datasheet.  

The instructions for installing the subscription licence via the CLI are documented below.  For J-Web instructions, refer to the Technical Documentation link below.

Install Subscription License

Perform the following steps to activate, install, and verify the subscription license:

1. First, activate your subscription license by entering the authorization code and chassis serial number into the Subscription Registration system. Refer to KB9731 - How do I activate a subscription license for my ScreenOS firewall or SRX Series product for more information. If you still need help, please contact Customer Care for subscription and licensing issues.



2. Then, install the license on the SRX in one of two ways -- automatically or manually:
   a. Automatically: 
   Confirm the SRX device has connectivity to the Internet and DNS configured.  Then run the following command to request the license from the License Management Server and install it:
   
    root> request system license update          
   
   (The output of the command show configuration system license displays the default URL for the License Management Server.)
   
   OR
   b. Manually:
   Licenses can also be loaded manually via JWeb, NSM, or using the CLI. The CLI command is as follows:
   
   root> request system license add terminal
[Type ^D at a new line to end input,
enter blank line between each license key]
Paste the license key and press enter
   Type Ctrl+D
   
   The License key should be added successfully.



3. Verify the license is installed using the command:

root> show system license 
License usage: 
                                 Licenses     Licenses    Licenses    Expiry
  Feature name                       used    installed      needed 
  av_key_kaspersky_engine               0            1           0    2013-03-06 01:00:00 CET
  anti_spam_key_sbl                     1            0           1    25 days
  wf_key_surfcontrol_cpa                1            0           1    25 days
 

• SRX Branch platforms support three different Anti-Virus types. For Antivirus-Express engine and Kaspersky engine look for the feature name "av_key_kaspersky_engine".   For Sophos engine, look for the feature name "av_key_sophos_engine".
Note: Sophos Antivirus is supported from Junos 11.1 onwards. The Antivirus Express feature is not supported on SRX100 and SRX110 platforms.


• SRX Branch platform supports three different Web-Filter (URL Filtering) types. For Integrated Web Filtering look for the feature name "wf_key_surfcontrol_cpa". For Enhanced Web Filtering, look for the feature name "wf_key_websense_ewf ". The Redirect Web filtering feature does not need a license on the SRX.


• For IDP, look for feature 'idp-sig'. 


• For Antispam, look for feature "anti_spam_key_sbl"

NOTE: If running a Chassis Cluster, then the license needs to be installed on both nodes.

Trial licenses are available and valid for 4 weeks; you can only fetch a trial license once per year for each device serial number. Use the command:    request system license update trial

JUNOS : Configuring IPS Features on the SRX

Getting Started with IPS on the SRX

We should perform a few steps before we configure SRX IPS. Here is a list of things to do before configuring the SRX for IPS functionality:

1. Install the license.
   You must install an IDP license before you can download any attack objects. If you are using only custom attack objects, you don’t need to install a license (earlier versions had a bug where they required it), but if you want to download Juniper predefined attack objects, you must have this license. Juniper provides you with the ability to download a 30-day trial license to permit this functionality for a brief period of time to evaluate the functionality. We covered license installation earlier in the book; all you need is the request system license add command either specifying a file, or copying and pasting it into the terminal.
2. Configure network access.
   Before you can download the attack objects, you must have network connectivity to either the Juniper download server or a local server from which the signatures can be downloaded. This typically requires network configuration ...
   
   

   Deploying and Tuning IPS

   Deploying IPS requires a slight learning curve. You could memorize every command and feature by heart, and still have a rocky deployment. The challenge is that every environment is different, just like a fingerprint or DNA. There are different applications, different volumes of the applications, different policies on what is accepted activity, and different resources to protect; all which can make for different goals for the IPS. Although this book can’t tell you exactly what your policy should be, it can certainly help you to build and deploy that policy.
   

   First Steps to Deploying IPS

   Before you get too caught up in the actual deployment do a bit of legwork and map out the policy which you want to deploy. Think of it as brainstorming for your IPS. You should identify the assets you want to protect, and identify the systems and applications and how they interact with others in your network. You may need to contact the application owners beforehand to identify this information. You should also determine your IPD protection goals. This would include the types of threats you want to prevent, and any other factors that might limit the scope of the deployment. (Often this involves management approval so that there aren’t any surprises.)

   Building the Policy

   Once you have identified the assets and the goals of the IPS, and you have gotten all of the necessary approvals, you should be ready to build your IPS policy on the SRX. Remember that if you are using predefined

Need to make a new user's home directory manually on all SRX platforms (including Firefly Perimeter) running with Junos OS release 12.1X47-D10

Alert Type:

PSN - Product Support Notification

 
Product Affected:

All SRX platforms and Firefly Perimeter

 
Alert Description:

Due to an internal build error, if a new user is configured on any of SRX devices (including Firefly Perimeter), which is running with Junos OS 12.1X47-D10. The user's home directory will not be created automatically.

e.g.,

[edit]
root@SRX# set system login user newuser class operator authentication plain-text-password 
New password:
Retype new password:

[edit]
root@SRX# commit and-quit 
commit complete
Exiting configuration mode

root@SRX> file list detail /var/home/ | match newuser    

root@SRX>

If you try to login to the SRX device using the new login username, you can login to the device, but it shows error messages, which cannot change to home directory.

% ssh newuser@172.22.145.106
Password:
--- JUNOS 12.1X47-D10.4 built 2014-08-14 22:48:52 UTC
Could not chdir to home directory /var/home/newuser: No such file or directory
newuser@SRX> 

Solution:
The correction is included in Junos OS 12.1X47-D11 (refer to the download links below), 12.1X47-D15 (scheduled to be released in early December 2014) and above.



Workaround:

1. After creating a new user on the CLI or J-Web, type "start shell" or "start shell user root" in Junos CLI without double quotes
2. Create the user's home directory and change the ownership

% mkdir -p /var/home/(username)

% chown -R -P -f (userid or username):20 /var/home/(username)

e.g.,

root@SRX> start shell 
root@SRX% mkdir -p /var/home/newuser
root@SRX% chown -R -P -f newuser:20 /var/home/newuser
root@SRX% ls -al /var/home/newuser
total 8
drwxr-xr-x   2 newuser  20      512 Oct  8 21:47 .
drwxr-xr-x  34 root     wheel  1024 Oct  8 21:47 ..


OR

root@SRX% chown -R -P -f 2009:20 /var/home/newuser
root@SRX% ls -al /var/home/newuser
total 8
drwxr-xr-x   2 newuser  20      512 Oct  8 21:47 .
drwxr-xr-x  34 root     wheel  1024 Oct  8 21:47 ..

NOTE: The userid's of each login name can be verified from the configuration.

e.g.,

[edit]
root@SRX# show system login user newuser 
uid 2009;   <-- LOOK HERE (uid stands for userid)
class operator;
authentication {
    encrypted-password "$1$FyKeeKqo$XKT8V1udIJbT9f4fpw2Yc."; ## SECRET-DATA
}

SRX tcp-proxy resource exhaustion for ALG/IDP/UTM traffic with client/server communication using TCP keepalives

Product Affected:

All SRX platforms
Junos OS 11.4
Junos OS 12.1
Junos OS 12.1X44

Alert Description:

SRX tcp-proxy resources may reach device limits during processing of ALG/IDP/UTM based traffic if client/server communication use TCP keepalive mechanism, resulting in session setup failure for new ALG/IDP/UTM based traffic.

During SRX processing of ALG/IDP/UTM traffic involving TCP keepalives, upon receipt of server to client TCP keepalive, the SRX will send a TCP keepalive response back to the server on behalf of the client via tcp-proxy.  However the received keepalive is not sent to the client, resulting in client establishment of a new session with server upon client not receiving keepalive packets. The SRX session, and associated tcp-proxy resource, is not freed based upon the continued keepalives from server to client being handled by the tcp-proxy.
The process repeats and results in session build up on SRX and exhaustion of available tcp-proxy resources.  

Locate tcp-proxy resource limit
     SRX Datacenter

1) Open Shell connection
     >start shell

2) Elevate to root level access (as needed)
     % su (enter in root password)

3) Locate tcp-proxy resource limit per SPC
     root@srx5800% srx-cprod.sh -s spu -c "show usp nat cp sys" | grep proxy
  usp_max_tcpproxy_connection = 10240
  usp_max_tcpproxy_connection = 10240
  usp_max_tcpproxy_connection = 10240
  usp_max_tcpproxy_connection = 10240


      SRX Branch-Campus

1) Locate deivce tcp-proxy resource limit
   >request pfe execute target fwdd command "show usp nat cp sys" | match proxy
    GOT: usp_max_tcpproxy_connection = 4096

Verify current tcp-proxy resource usage
     SRX Datacenter

1) Open Shell connection
    >start shell

2) Elevate to root level access (as needed)
    % su (enter in root password)

3) Locate current usage of tcp-proxy
    root@srx5800% srx-cprod.sh -s spu -c "show usp jsf tcpstats" | grep "flow_tcb alloc\|Start SPU" | uniq
   ======== Start SPU4.0, fpc4.pic0, spu ========
   flow_tcb alloc cnt : 0000000000 flow_tcb free cnt : 0000000000
   ======== Start SPU4.1, fpc4.pic1, spu ========
   flow_tcb alloc cnt : 0000012487 flow_tcb free cnt : 0000008741
   ======== Start SPU11.0, fpc11.pic0, spu ========
   flow_tcb alloc cnt : 0000011452 flow_tcb free cnt : 0000007930
   ======== Start SPU11.1, fpc11.pic1, spu ========
   flow_tcb alloc cnt : 0000012874 flow_tcb free cnt : 0000009016

4) For each SPC Subtract 'flow_tcb free cnt' from 'flow_tcb alloc cnt'
    fpc4.pic0           0 -      0  =      0  
    fpc4.pic1    12487 - 8741  = 3746 in use
    fpc11.pic0   11452 - 7930  = 3522 in use
    fpc11.pic1   12874 - 9016  = 3858 in use

      SRX Branch-Campus

1) Open Shell connection
  >start shell

2) Elevate to root level access (as needed)
    % su (enter in root password)

3) Locate current usage of tcp-proxy
    root@PN-STL-RTR1% cprod -A fwdd -c show usp jsf tcpstats | grep "flow_tcb alloc" | uniq
  flow_tcb alloc cnt : 0000000015 flow_tcb free cnt : 0000000012

4)Subtract 'flow_tcb free cnt' from 'flow_tcb alloc cnt'
    15 - 12 = 3 in use

Solution:
The following software releases have enhanced SRX handling of tcp-keepalive processing.
    Junos OS 12.1X45
    Junos OS 12.1X46
    Junos OS 12.1X47 and higher versions


SRX enhancement enables tcp-proxy ability to learn TCP keepalive parameters from client and server allowing SRX tcp-proxy to send TCP keepalive to both client and server as well as allowing closing of SRX session and associated tcp-proxy resource upon no response for 16 tcp-proxy keepalives.


WorkAround
Prior to reaching resource limit, close SRX sessions associated with client/server communication using TCP keepalives and freeing SRX tcp-proxy resource.

          SRX Clusters:
               Failover data redundancy groups (RG1+) to peer node
                 (triggers tcp-proxy to send packets to both client/server causing client to issue RST and closing of associated SRX session)

                       >request chassis cluster failover redundancy-group <#> node <#>

                 or

               Manually clear sessions for client/server communication that use tcp-keepalive
                      >clear security flow session source-prefix <x.x.x.x> destination-prefix <y.y.y.y>


          Standalone SRX:
               Manually clear sessions for client/server communication that use tcp-keepalive
                       >clear security flow session source-prefix <x.x.x.x> destination-prefix <y.y.y.y>

Junos Dates & Milestones

Product	FRS Date	End of Engineering	End of Support
Junos 14.1	06/13/2014	06/13/2016	12/13/2016
Junos 13.31	01/22/2014	01/22/2017	07/22/2017
Junos 13.2	08/29/2013	08/29/2015	02/29/2016
Junos 13.1	03/15/2013	03/15/2015	09/15/2015
Junos 12.3X544	07/18/2014	07/18/2016	01/18/2017
Junos 12.3X524	08/23/2013	08/23/2015	02/23/2016
Junos 12.3X514	03/15/2013	03/15/2015	09/15/2015
Junos 12.31	01/31/2013	01/31/2016	07/31/2016
Junos 12.2	09/05/2012	09/05/2014	03/05/2015
Junos 12.1X472	08/18/2014	08/18/2016	02/18/2017
Junos 12.1X46123	12/30/2013	12/30/2016	06/30/2017
Junos 12.1X452	07/17/2013	07/17/2014	01/17/2015
Junos 12.1X4412	01/18/2013	01/18/2016	07/18/2016
Junos 12.1	03/28/2012	03/28/2014	09/28/2014
Junos 11.41	12/21/2011	12/21/2014	06/21/2015
Junos 11.3	08/15/2011	07/15/2012	03/15/2013
Junos 11.2	08/03/2011	06/15/2012	02/15/2013
Junos 11.1	03/29/2011	11/15/2011	05/15/2012
Junos 10.41	12/08/2010	12/08/2013	06/08/2014
Junos 10.3	08/15/2010	08/03/2011	12/21/2011
Junos 10.2	05/28/2010	05/15/2011	11/15/2011
Junos 10.1	02/15/2010	11/15/2010	05/15/2011
Junos 10.01	11/04/2009	11/15/2012	05/15/2013
Junos 9.6	08/06/2009	05/06/2010	11/06/2010
Junos 9.5	04/14/2009	02/15/2010	08/15/2010
Junos 9.4	02/11/2009	11/11/2009	05/11/2010
Junos 9.31	11/14/2008	11/15/2011	05/15/2012
Junos 9.2	08/12/2008	05/12/2009	11/12/2009
Junos 9.1	04/28/2008	01/28/2009	07/28/2009
Junos 9.0	02/15/2008	11/15/2008	05/15/2009
Junos 8.51	11/16/2007	11/16/2010	05/16/2011
Junos 8.4	08/09/2007	05/09/2008	11/09/2008
Junos 8.3	04/18/2007	01/18/2008	07/18/2008
Junos 8.2	02/15/2007	11/15/2007	05/15/2008
Junos 8.11	11/06/2006	11/06/2009	05/06/2010
Junos 8.0	08/15/2006	05/15/2007	11/15/2007
Junos 7.6	05/15/2006	02/15/2007	08/15/2007
Junos 7.5	02/08/2006	11/08/2006	05/08/2007
Junos 7.4	11/15/2005	08/15/2006	02/15/2007
Junos 7.3	08/16/2005	05/16/2006	11/16/2006
Junos 7.2	05/14/2005	02/14/2006	08/14/2006
Junos 7.1	02/14/2005	11/14/2005	05/14/2006
Junos 7.0	11/15/2004	08/15/2005	02/15/2006
Junos 6.4	08/12/2004	05/12/2005	11/12/2005
Junos 6.3	05/15/2004	02/15/2005	08/15/2005
Junos 6.2	02/15/2004	11/15/2004	05/15/2005
Junos 6.1	11/15/2003	08/15/2004	02/15/2005
Junos 6.0	08/15/2003	05/15/2004	11/15/2004
Junos 5.7	05/15/2003	02/15/2004	08/15/2004
Junos 5.6	02/15/2003	11/15/2003	05/15/2004
Junos 5.5	11/15/2002	08/15/2003	02/15/2004
Junos 5.4	08/12/2002	05/15/2003	11/15/2003
Junos 5.3	05/12/2002	02/15/2003	08/15/2003
Junos 5.2	02/12/2002	11/12/2002	05/15/2003
Junos 5.1	11/07/2001	08/12/2002	02/15/2003
Junos 5.0	08/17/2001	05/15/2002	11/15/2002
Junos 4.4	04/30/2001	02/12/2002	08/15/2002
Junos 4.3	01/31/2001	11/12/2001	05/15/2002
Junos 4.2	10/16/2000	08/13/2001	02/15/2002
Junos 4.1	08/15/2000	05/14/2001	11/15/2001
Junos 4.0	03/31/2000	02/12/2001	08/15/2001

Pre-12.1 Releases (other than EEOL Releases):
EOE date: The earlier of (i) the date eighteen (18) months from first general availability or (ii) two (2) subsequent releases of such software.
EOL/EOS date: The earlier of (i) the date twelve (12) months after the EOE date or (ii) two (2) subsequent releases of such software.
Release 12.1 and following (other than EEOL Releases):
EOE date: The date twenty four (24) months after the first general availability date.
EOL/EOS date: The date six (6) months after the EOE date.

Shell command injection vulnerability in Bash

Bash or the Bourne again shell has vulnerabilities in the way it handles environment variables when it is invoked. Under some scenarios, network based remote attackers can inject shell script that can be executed on a system. This is also known as "ShellShock".

Products vulnerable to remote exploitation risks:

• Junos Space is vulnerable in all versions.
• JSA Series (STRM) devices are vulnerable in all versions.
• NSM Appliances (NSM3000 and NSMExpress) are vulnerable in all versions.

Products with bash, but NOT affected by remote exploitation risks:

Our current assessment shows there is no risk of remote code execution on these products even though the products include bash. Scenarios required for known remote exploitation vectors do not exist on these products. As a precaution, bash in these products will be upgraded.

• SSL VPN
• UAC
• CTPView
• QFabric
• DDOS Secure
• JWAS
• vGW
• SRC
• Junos Pulse Endpoint Profiler

Products NOT affected:

• Junos OS is not vulnerable.
• ScreenOS is not vulnerable.
• JunosE is not vulnerable.
• ADC is not vulnerable.
• SRX-IDP is not vulnerable.
• ISG-IDP is not vulnerable.
• WX is not vulnerable.
• MFC is not vulnerable.

JUNOS : Verifying Junos OS License Installation

Verify that the expected licenses are installed and active on the router or switch.

 

user@host> show system license

License usage: 
                   Licenses     Licenses    Licenses    Expiry
  Feature name         used    installed      needed 
  subscriber-acct         0            1           0    permanent
  subscriber-auth         0            1           0    permanent
  subscriber-addr         0            1           0    permanent
  subscriber-vlan         0            1           0    permanent
  subscriber-ip           0            1           0    permanent
  scale-subscriber        0         1000           0    permanent
  scale-l2tp              0         1000           0    permanent
  scale-mobile-ip         0         1000           0    permanent

Licenses installed: 
  License identifier: E000185416
  License version: 2
  Features:
    subscriber-acct  - Per Subscriber Radius Accounting
      permanent
    subscriber-auth  - Per Subscriber Radius Authentication
      permanent
    subscriber-addr  - Address Pool Assignment
      permanent
    subscriber-vlan  - Dynamic Auto-sensed Vlan
      permanent
    subscriber-ip    - Dynamic and Static IP
      permanent

Meaning

The output shows a list of the license usage and a list of the licenses installed on the router or switch. Verify the following information:

• Each license is present. Licenses are listed in ascending alphanumeric order by license ID.
• The state of each license is permanent.

Junos Benefit

Junos operating system is a reliable, high-performance network operating system for routing, switching, and security. It reduces the time necessary to deploy new services and decreases network operation costs. Junos offers secure programming interfaces and the Junos SDK for developing applications that can unlock more value from the network.

Running Junos in a network improves the reliability, performance, and security of existing applications. It automates network operations on a streamlined system, allowing more time to focus on deploying new applications and services. And it's scalable both up and down—providing a consistent, reliable, stable system for developers and operators. Which, in turn, means a more cost-effective solution for your business.
 
SDN  
Path Computation Client (PCC): PCC is an SDN technology available on the MX Router Series. PCC enables network programmability to allow IT managers to dynamically create optimal paths including slices, overlays or virtual paths, to optimize on-demand bandwidth requirements.
 
Fusion
With Junos Fusion, service providers can reduce network complexity and operational costs by collapsing underlying network elements into a single, logical point of control from Juniper Networks® Junos routing platforms. Junos Fusion is fully interoperable with third-party solutions and is extensible to SDN control.


One Operating System reduces time and effort to plan, deploy, and operate network infrastructure.
 
One Release Train provides stable delivery of new functionality in a steady, time-tested cadence.
 
Modular Software Architecture provides highly available and scalable software that keeps up with changing needs.

How to Update the New Image Authentication Key and Upgrade Boot Loader/ScreenOS Firmware

As of August 18, 2014, all Boot Loaders and ScreenOS Firmwares downloaded from the Juniper Networks Software Download Site are signed with the New Image Authentication Certificate.

ScreenOS includes the ability to determine the authenticity of binary images provided by Juniper Networks. An image (also known as “firmware”) authentication signature has been incorporated into each ScreenOS build since version 2.6.1r1. When the ScreenOS authentication certificate (also known as “image key” or “imagekey.cer”) has been loaded beforehand onto a Juniper Networks firewall or VPN device (ISG Series, NetScreen Series, and SSG Series), each time the device is rebooted, ScreenOS will validate the authenticity of the image saved in flash. If the validation fails, the device will not load the image. The same logic is applied to ScreenOS firmware upgrade/downgrade. If the image cannot be validated by the installed image key, the upgrade/downgrade will fail.

Validating the authenticity of an image enhances security and stability. When this feature is enabled, ScreenOS rejects illegitimate or damaged images before they will be booted onto the device, forcing the system administrator to save an authentic software image in the device before it will boot, and thereby protecting the device against unsafe and potentially unstable software.


Solution:

Validating the Image Authentication Certificate

It is important to ensure the integrity of the image key itself before you load it on the Juniper Networks security device. You can confirm the image key’s integrity by comparing the checksum of the imagekey.cer certificate file to the value below. A tool such as md5sum, sha1sum, and sha256sum for Unix/Linux can be used.

New Image Key (download)

$ md5sum imagekey.cer 
99def4b80b75ed65aad52a5fc3ed1131  imagekey.cer

$ sha1sum imagekey.cer 
06c3c15b88de548b18814d4389d18a20f65a5845  imagekey.cer

$ sha256sum imagekey.cer 
02b107f0679bc5d5aa0ab49be52043bb31f2a010a980573c53dc3fc815e1d7f3  imagekey.cer

Old Image Key (download)

$ md5sum imagekey.cer 
ccfcd027e20c9cc38b5d8dac17c7199f  imagekey.cer

$ sha1sum imagekey.cer 
2af0d97abbb58821650445cd517050fd0cfa2684  imagekey.cer

$ sha256sum imagekey.cer 
bab2f722cbba13a73d9af4c17af9c34d62ac71b4c9e8bbb9bac5df1fdceb0261  imagekey.cer

Validating the Boot Loader and the ScreenOS Firmware

There are no code or contents changes on the newly released boot loaders and ScreenOS firmwares, these files are signed with the new image key only. Therefore, the version numbers are same as before.

In order to distinguish whether the device is running with old ScreenOS firmware that is signed with the old image key, you can check the non-zero values of the image key using hidden CLI exec pki test skey command. Refer to 2. Checking the Installed Image Key. Also you can refer to KB29296 - ScreenOS and Boot Loader Checksum Values Signed by Old and New Image Key.

Finally when you feel confident about the integrity of the new image key and know that the currently running ScreenOS firmware is signed by the old image key, you can follow the below steps to install the new image key, and boot loader/ScreenOS firmware that are signed with the new image key.

1. Saving the Configuration

Before you proceed the following steps, please make sure to backup the configuration, you can do it through either the WebUI and the CLI.

On the WebUI, navigate to Configuration > Update > Config File > click "Save to File"


On the CLI, type save config to tftp <IP address of TFTP server> <config filename>

For example,

SSG550-> save config to tftp 172.22.152.251 ssg550_config_backup 
Read the current config.
 Save configurations (3064 bytes) to ssg550_config_backup on TFTP server 172.22.152.251.
!!!!!!!!!!!!!!
tftp transferred records = 6
tftp success!

TFTP Succeeded

2. Checking the Installed Image Key

If an image key is already installed, you will see output similar to the below (non-zero values). If the output shows all zero (0), then there is no installed image key.

NOTE: The device cannot store more than one image key. When you install the new image key, it overwrites the previous key. The installation status of the image key can be checked through hidden CLI exec pki test skey command only.

SSG550-> exec pki test skey

(snip)

KEY1  N/A len =432
 308201ac02010002818100fd7f53811d75122952df4a9c2eece4e7f611b7523cef4400c31e3f80b651     magic1 = f7e9294b magic2=0
 
KEY2  N/A len =432
 308201ac02010002818100fd7f53811d75122952df4a9c2eece4e7f611b7523cef4400c31e3f80b651     magic1 = f7e9294b magic2=0
 
KEY3  N/A len =432
 308201ac02010002818100fd7f53811d75122952df4a9c2eece4e7f611b7523cef4400c31e3f80b651     magic1 = f7e9294b magic2=0

NOTE: The above non-zero values are indicating the old image key (308201ac ....). If you wish to update the image key to the new key, then go to next step 3. Updating the Image Key. The new image key’s values are starting with (308201ad ....) from left to right direction. If the new image key is installed already, then go to step 4. Upgrading ScreenOS.

The following example shows that an image key is not installed (all zero values).

SSG550-> exec pki test skey 

(snip)

KEY1  N/A len =0
 0000000000000000000000000000000000000000000000000000000000000000000000000000000000     magic1 = f7e9294b magic2=dead1234
 
KEY2  N/A len =0
 0000000000000000000000000000000000000000000000000000000000000000000000000000000000     magic1 = f7e9294b magic2=dead1234
 
KEY3  N/A len =0
 0000000000000000000000000000000000000000000000000000000000000000000000000000000000     magic1 = f7e9294b magic2=dead1234

NOTE: If no image key is installed and you do not want to authenticate the boot loader (for ISG Series and NetScreen Series only) and ScreenOS in future, skip Step 3. Updating the Image Key.

3. Updating the Image Key

If a WebUI access or a TFTP server is available, you can install the new image key through the WebUI or the CLI.

On the WebUI :

1. Download the new image key (imagekey.cer) 
   • New Image Key (download)
2. Save it to accessible local storage
3. Login to the device.
4. Navigate to ''Configuration > Update > ScreenOS/Keys'' using the navigation tree on the left side of the screen
5. Select the ''Image Signature Key Update'' radio button and click Browse
6. Navigate to the location where you saved the image key and click Open
7. Click Apply

On the CLI :

1. Download the new image key (imagekey.cer)
   • New Image Key (download)
2. Save it to TFTP server
3. Make a console, Telnet, or SSH connection to the Juniper Networks security device
4. Login to the device
5. Type save image-key tftp (IP address of tftp server) imagekey.cer command

For example,

SSG550-> save image-key tftp 172.22.152.251 new/imagekey.cer
Load file  from TFTP 172.22.152.251 (file: new/imagekey.cer).
!!!!!
tftp received octets = 863
tftp success!
Done

TFTP Succeeded

If the image key is installed successfully, you will see output similar to the below (non-zero values). If the output shows all zero (0), then the image key is not installed.

SSG550-> exec pki test skey

(snip)

KEY1  N/A len =433
 308201ad02010002818100fd7f53811d75122952df4a9c2eece4e7f611b7523cef4400c31e3f80b651     magic1 = f7e9294b magic2=0
 
KEY2  N/A len =433
 308201ad02010002818100fd7f53811d75122952df4a9c2eece4e7f611b7523cef4400c31e3f80b651     magic1 = f7e9294b magic2=0
 
KEY3  N/A len =433
 308201ad02010002818100fd7f53811d75122952df4a9c2eece4e7f611b7523cef4400c31e3f80b651     magic1 = f7e9294b magic2=0

If only a CLI access is available without TFTP server, you cannot install the new image key, then delete the installed old image key using CLI delete crypto auth-key command and go to next step 4. Upgrading ScreenOS.
The following example shows that no image key is available after deleting the image key.

SSG550-> delete crypto auth-key 
SSG550-> exec pki test skey 

(snip)

KEY1  N/A len =0
 0000000000000000000000000000000000000000000000000000000000000000000000000000000000     magic1 = f7e9294b magic2=0
 
KEY2  N/A len =0
 0000000000000000000000000000000000000000000000000000000000000000000000000000000000     magic1 = f7e9294b magic2=0
 
KEY3  N/A len =0
 0000000000000000000000000000000000000000000000000000000000000000000000000000000000     magic1 = f7e9294b magic2=0

NOTE: Please do not execute CLI delete crypto file command. It will delete all crypto files in the device that might be used for other services.

NOTE: You cannot delete image key through WebUI.

4. Upgrading ScreenOS

On ISG1000/2000, NS5200/NS5400 (boot loader upgrade is required) :

You must have a console connection and a TFTP server that can be reachable through the ‘mgt’ interface because the device will prompt you to install a boot loader if it cannot authenticate the installed boot loader using the new image key.
While the device boots up, it checks the integrity of installed boot loader and ScreenOS firmware.


NOTE: If the old image key is deleted using CLI delete crypto auth-key command, the device skips integrity check of the boot loader and ScreenOS firmware while boots up. You will see Ignore image authentication! message on the console while the device boots up.


On the CLI :

1. Download the ScreenOS firmware signed with the new image key from the ScreenOS Download site
2. Save it to TFTP server
3. Login to the device through the console port
4. Type save software from tftp (IP address of TFTP server) (ScreenOS image filename) to flash command

For example,

ns5200-> save software from tftp 172.22.152.251 new/ns5000.6.3.0-M2A.r17.0 to flash 
Load software from TFTP 172.22.152.251 (file: new/ns5000.6.3.0-M2A.r17.0).
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
(snip)
tftp received octets = 13541072
tftp success!

TFTP Succeeded
Save to flash. It may take a few minutes ...platform = 15, cpu = 16, version = 18
 update new flash image (04243150,13541072)
platform = 15, cpu = 16, version = 18
offset = 20, address = 4000000, size = 13540994
date = 71c0efb8, sw_version = 71c0efbc, cksum = c491f61c
Image authenticated!
Program flash (13541072 bytes) ...
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++done
Done

5. Reboot the device, type reset command and install the boot loader that is singed with the new image key

NOTE: While the device boots up, it will generate the following messages on the console to guide you to install the boot loader that is signed by the new image key.

OS Loader File Name []: (type boot loader file name)
Self IP Address []: (TFTP client (device) IP address)
TFTP IP Address []: (TFTP server IP address)

For example,

ns5200-> reset
System reset, are you sure? y/[n] y
In reset ...


Juniper Networks NS-5000-II BootROM Version 1.0.0 (Checksum: FE499CCD)
Copyright (c) 1998-2004 Juniper Networks, Inc.

Total physical memory: 2048MB
    Test - Pass
    Initialization................ Done

Hit key 'X' and 'A' sequentially to update OS Loader....

Loading OS Loader from on-board flash memory... ++++
Done!

********Invalid DSA signature <- The installed boot loader (OS Loader) cannot be authenticated using the new image key

********Bogus image - not authenticated


OS Loader File Name [new/ns5000.6.3.0-M2A.r17.0]: new/Load5000v104.d  <- Boot loader file signed with the new image key
Self IP Address [172.19.50.252]: 172.22.152.49
TFTP IP Address [172.19.50.129]: 172.22.152.251

Save loader config (56 bytes)... Done

Loading file "new/Load5000v104.d"...
(snip)
Loaded successfully! (size = 447,576 bytes)

Image authenticated!  <- Boot loader is authenticated using the new image key

Program OS Loader to on-board flash memory... ++++
Done!

Start loading...
....................
Done.


Juniper Networks NS-5000-II OS Loader Version 1.0.4

Initialize FBTL 0.. Done

Hit any key to load new firmware
Hit any key to load new firmware
Hit any key to load new firmware
Hit any key to load new firmware

Loading default system image from on-board flash disk...
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Done! (size = 13,631,488 bytes)

Image authenticated! <- ScreenOS firmware is authenticated using the new image key

Start loading...
(snip)
Done.
Configuring Imperial FPGA... Done



Juniper Networks, Inc
NS-5000 System Software
Copyright, 1997-2008

Version 6.3.0r17.0
(snip)

NOTE: After the device boots up successfully, you can check the version of the installed boot loader through the CLI get system command, look for the value of “OS Loader Version”.

ns5200-> get system
Product Name: NetScreen-5200-II
Serial Number: 0040012001000011, Control Number: 00000000
Hardware Version: 3010(0)-(04), FPGA checksum: 00000000, VLAN1 IP (0.0.0.0)
Software Version: 6.3.0r17.0, Type: Firewall+VPN
BOOT ROM Version: 1.0.0
OS Loader Version: 1.0.4

(snip)

On SSG 20/140/320M/350M/520/520M/550/550M :

It is not required to update the current boot loader because the integrity check of the boot loader is only done during the installation of a boot loader. During boot-up of the device there is no integrity check done for the boot loader using the image key. Therefore the existing boot loader on the SSG device will keep working correctly after updating the image key on the device.


NOTE: If the old image key is deleted using CLI delete crypto auth-key command, the device skips the integrity check of the ScreenOS firmware while the device boots up. You will see the Ignore image authentication! message on the console while the device boots up.


On the WebUI :

1. Download the ScreenOS firmware signed with the new image key from the ScreenOS Download site
2. Save it to accessible local storage.
3. Login to the device.
4. Navigate to ''Configuration > Update > ScreenOS/Keys'' using the navigation tree on the left side of the screen.
5. Select the ''Firmware Update (ScreenOS)'' radio button and click Browse.
6. Navigate to the location where you saved the new image key and click Open.
7. Click Apply.

NOTE: If the device has the old image key and you try to install a ScreenOS firmware image that is signed by the new image key, the installation process will stop because the ScreenOS firmware cannot be authenticated using the old image key. You will see a pop-up window displaying “Firmware update failed”. In this case, you need to either install the new image key prior to installing the new ScreenOS firmware or delete the image key (refer to the above step 3. Updating the Image Key).


On the CLI :

1. Download the ScreenOS firmware signed with the new image key from the ScreenOS Download site
2. Save it to accessible local storage.
3. Login to the device
4. Type save software from tftp (IP address of TFTP server) (ScreenOS image filename) to flash command

SSG550-> save software from tftp 172.22.152.251 new/ssg500.6.3.0r17.0 to flash 
Load software from TFTP 172.22.152.251 (file: new/ssg500.6.3.0r17.0).
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
(snip)

tftp received octets = 11627247
tftp success!

TFTP Succeeded
Save to flash. It may take a few minutes ...platform = 23, cpu = 11, version = 2
 update new flash image (02572fd0,11627247)
platform = 23, cpu = 11, version = 2
offset = 20, address = 0, size = 11627169
date = 9422, sw_version = 808031, cksum = 954806c3
Program flash (11627247 bytes) ...

(snip)

5. After successful ScreenOS firmware installation, type reset command to reboot the device

NOTE: If the ScreenOS firmware is not successfully authenticated by the new image key during installation, the error messages “Invalid image!!!” and “Bogus image - not authenticated!!!” will be displayed. When the upgrade went successfully, on the next reboot the device will show ''Image authenticated!''on the console.

SSG550-> reset
System reset, are you sure? y/[n] y
In reset ...

(snip)

ScreenOS Saipanloader V1.0.7
Built Mar 19 2009/15:54:12
watchdog_probe, 1132 bus/dev/fn = 0/248 ich = 2640
boot_drive = 80
start1 = 0768, start2 = 3840

Hit 'X' and 'A' to upgrade bootloadermounting FAT16 partition
file size = 112
size = 112, sizeof(nvram_rec) = 112

Hit any key to load new firmware
Hit any key to load new firmware
Hit any key to load new firmware
Hit any key to load new firmware/$nsboot$.bin 
file size = 11627247

hdr->magic_number = 81ba16ee, hdr->platform_type = 1700, hdr->cpu_type = 11

Image authenticated! 

(snip)

NOTE: If the device has the old image key and you try to install ScreenOS firmware that is signed with the new image key, the installation process will stop because the ScreenOS firmware cannot be authenticated using the old image key. You will see output similar to the below. In this case, you need to either install the new image key prior to installing the ScreenOS firmware or delete the image key (refer to the above step 3. Updating the Image Key).

SSG550-> save software from tftp 172.22.152.251 new/ssg500.6.3.0r17.0 to flash 
Load software from TFTP 172.22.152.251 (file: new/ssg500.6.3.0r17.0).
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
(snip)
tftp received octets = 11627247
tftp success!

TFTP Succeeded
Save to flash. It may take a few minutes ...platform = 23, cpu = 11, version = 2
 update new flash image (02572fd0,11627247)
platform = 23, cpu = 11, version = 2
offset = 20, address = 0, size = 11627169
date = 9422, sw_version = 808031, cksum = 954806c3
********Invalid image!!! ********Bogus image - not authenticated!!!

(snip)

NOTE: If you would like to update the boot loader that is signed with the new image key on SSG Series, you must have a console connection and a TFTP server that can be reachable through the pre-assigned interface(s) in the boot loader mode (mostly ‘eth0/0’ interface) and manually interrupt the boot sequence by holding ‘Shift key’ and hit 'X' and ‘A’ sequentially when the “Hit 'X' and 'A' to upgrade bootloader” message is shown on the console.

After installing the new image key, type CLI reset command to reboot the device. Then keep the ‘Shift key’ down and hit 'X' and ‘A’ sequentially.

SSG550-> reset
System reset, are you sure? y/[n] y
In reset ...

(snip)

ScreenOS Saipanloader V1.0.7
Built Mar 19 2009/15:54:12
watchdog_probe, 1132 bus/dev/fn = 0/248 ich = 2640
boot_drive = 80
start1 = 0768, start2 = 3840

Hit 'X' and 'A' to upgrade bootloader   <- Hold ‘Shift key’ and hit ‘X’ and ‘A’ in sequence
Loader File Name:new/Loadssg500v107.d   <- Bootloader filename signed with the new image key
Self IP Address :172.22.152.35          <- TFTP client IP address
TFTP IP Address :172.22.152.251         <- TFTP server IP address
IP MASK :255.255.255.0
Gateway IP Address :172.22.152.1


Saipan motherboard proto 3 or later detected
Probing...[Ethernet0/0 and Ethernet0/1]

Initiating hardware and waiting for link up ...


Initiating hardware and waiting for link up ...
self_ip = 172.22.152.35, tftp_server_ip = 172.22.152.251
ip = 172.22.152.35 mask = 255.255.255.0 gw = 172.22.152.1 svr = 172.22.152.251
network_ready = 1
new/Loadssg500v107.d


121078 bytes downloaded from tftp server
old img size = 121032, new img size = 121032, load = 121078, sig = 46
S
Image authenticated!    <- Bootloader is authenticated using the new image key
mounting FAT12 partition
file /boot2 size was 121079, new size is 121078
getting sector information
boot1 size = 512
boot2 size = 512
boot1_sector = 807, boot2_sector = 1051
offset = 512
[1052][1053][1054][1055][1056][1057][1058][1059][1060][1061][1062][1063][1064][1065][1066][1067][1068][1069][1070][1071][1072][1073][1074][1075][1076][1077][1078][1079][1080][1081][1082][1083][1084][1085][1086][1087][1088][1089][1090][1091][1092][1093][1094][1095][1096][1097][1098][1099][1100][1101][1102][1103][1104][1105][1106][1107][1108][1109][1110][1111][1112][1113][1114][1115][1116][1117][1118][1119][1120][1121][1122][1123][1124][1125][1126][1127][1128][1129][1130][1131][1132][1133][1134][1135][1136][1137][1138][1139][1140][1141][1142][1143][1144][1145][1146][1147][1148][1149][1150][1151][1152][1153][1154][1155][1156][1157][1158][1159][1160][1161][1162][1163][1164][1165][1166][1167][1168][1169][1170][1171][1172][1173][1174][1175][1176][1177][1178][1179][1180][1181][1182][1183][1184][1185][1186][1187][1188][1189][1190][1191][1192][1193][1194][1195][1196][1197][1198][1199][1200][1201][1202][1203][1204][1205][1206][1207][1208][1209][1210][1211][1212][1213][1214][1215][1216][1217][1218][1219][1220][1221][1222][1223][1224][1225][1226][1227][1228][1229][1230][1231][1232][1233][1234][1235][1236][1237][1238][1239][1240][1241][1242][1243][1244][1245][1246][1247][1248][1249][1250][1251][1252][1253][1254][1255][1256][1257][1258][1259][1260][1261][1262][1263][1264][1265][1266][1267][1268][1269][1270][1271][1272][1273][1274][1275][1276][1277][1278][1279][1280][1281][1282][1283][1284][1285][1286][1287][1288][1289][1290]
write boot2's start sector back at sector 1051
write mbr back at sector 0
mounting FAT16 partition
file size = 112
size = 112, sizeof(nvram_rec) = 112
system rebooting...  <- After successful bootloader installation, the device will automatically try to reboot

(snip)

********Invalid DSA signature  <- But if the previously installed ScreenOS firmware is signed with the old image key, the new image key cannot authenticate the ScreenOS firmware, then the device prompt to you install a ScreenOS firmware signed with the new image key

********Bogus image - not authenticated
mounting FAT16 partition
file size = 112
Serial Number []: READ ONLYc) = 112
BOM Version Number []: READ ONLY
Self MAC Address [0000-0000-0000]: READ ONLYip = 1.1.1.1 svr = 1.1.1.2
self_ip_buf = 1.1.1.1, tftp_ip_buf = 1.1.1.2


Firmware File Name [old/ssg500.6.3.0r17.0]: new/ssg500.6.3.0r17.0  <- Type the ScreenOS firmware filename signed with the new image key
Self IP Address [1.1.1.1]: 172.22.152.35   <- TFTP client IP address
TFTP IP Address [1.1.1.2]: 172.22.152.251  <- TFTP server IP address
IP MASK [255.255.255.0]:
Gateway IP Address [172.22.152.251]:

Save loader config (112 bytes)... Done

Saipan motherboard proto 3 or later detected
Probing...[Ethernet0/0 and Ethernet0/1]

Initiating hardware and waiting for link up ...
self_ip = 172.22.152.35, tftp_server_ip = 172.22.152.251
ip = 172.22.152.35 mask = 255.255.255.0 gw = 172.22.152.251 svr = 172.22.152.251
network_ready = 1
new/ssg500.6.3.0r17.0
offset = 0, maxposition = 11627247
11627247 bytes downloaded from tftp server

hdr->magic_number = 81ba16ee, hdr->platform_type = 1700, hdr->cpu_type = 11

Image authenticated!  ← ScreenOS is authenticated

Save to on-board flash disk? (y/[n]/m) No  <- You should press ‘n’ key 
Run downloaded system image? ([y]/n) Yes   <- You should press ‘y’ key

(snip)

System change state to Active(1)

login:

Junos software release 14.1R2

Product Affected:

All Juniper Networks routing and switching platforms running Junos Operating System software

SSG-5 and SSG -20 EOL and Replacement Model

What are the key dates?

Mile Stone	Dates
EOL Announcement	July 08, 2014
Last Order Date	Jan 08, 2015
End of Support	Jan 08, 2020

  

What products in Juniper replace SSG-5 and SSG-20?

	SSG-5	SRX100
CPU	Intel 1 Core 533Mhz	Cavium 2 Core 500Mhz
RAM	256MB	2GB
On-board Ports	7xFE	8xFE
Firewall IMIX Performance	90 Mbps	200 Mbps
IPSec VPN Performance	40 Mbps	65Mbps
Wireless	Optional	via AX411
Backup Interface	Serial / V.92 / ISDN	3G / 4G (via CX111)

	SSG-20	SRX210
CPU	Intel 1 Core 533Mhz	Cavium 2 Core 600Mhz
RAM	256MB	2GB
On-board Ports	5xFE	2xGE + 6xFE
Firewall IMIX Performance	90 Mbps	250 Mbps
IPSec VPN Performance	40 Mbps	85Mbps
Wireless	Optional	via AX411
Backup Interface	2	1