Chapter 2. Firewall Configuration and Management
2.0. Introduction
This chapter will build on Chapter 1 and move on to describing how to manage the movement of data onto and off of the firewall. We will also describe some best practice approaches to control access to and manage ScreenOS in your environment.
2.1. Use TFTP to Transfer Information to and from the Firewall
Problem
You are troubleshooting an issue and need to save captured data currently on the firewall to a file, back up the current configuration, and then upload a new version of code, all with the Trivial File Transfer Protocol (TFTP).
Solution
Use the "redirect to TFTP” capability in the CLI to copy the information to your TFTP server:
top-ssg140-> get log event > tftp 10.251.7.113 eventlog.txt
redirect to 10.251.7.113,eventlog.txt
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
tftp transferred records = 15
tftp success!
top-ssg140->Then, back up the existing configuration:
top-ssg140-> save config to tftp 10.251.7.113
borderfw1_config_021107_1215.txt
Read the current config.
Save configurations (3918 bytes) to borderfw1_config_021107_1215.txt
on TFTP server 10.251.7.113.
!!!!!!!!!!!!!!!!!!!
tftp transferred records = 8
tftp success!!
TFTP Succeeded
top-ssg140->Lastly, copy the new version of the ScreenOS software to your firewall and save it:
top-ssg140-> save software from tftp 10.251.7.113 ssg140.6.0.0r1.0
to flash
Load software from 10.251.7.113/ssg140.6.0.0r1.0 .
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
...
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
tftp received octets = 11141120
tftp success!
TFTP Succeeded
top-ssg140->Discussion
One of the challenges with a real-time, in-memory operating system such as ScreenOS (with no additional onboard hard drive for storage) is that you need to carefully manage the available buffers. This is especially true when troubleshooting because ScreenOS will overwrite space when the particular buffer fills up.
Here are some examples of some of these limits from an SSG140 device:
top-ssg140->get sys-cfg | inc " log"dlog session log pool number: 512 event log entry number: 1024 packet log entry number: 512 traffic log entry number: 4096 top-ssg140->get sys-cfg | inc dbufdbuf number: 524288 top-ssg140->
As you can see, finite buffers are defined for numbers of entries or amounts of dedicated memory. During normal operation with appropriate log settings, the logs will be sent off to the NetScreen Security Manager (NSM), or a syslog server, before the buffer wraps around and overwriting begins. However, when troubleshooting, it’s easy to exceed these numbers and start to overwrite before you can capture the data you want. The “redirect to TFTP” function can be useful for capturing this data before overwriting begins.
You can use TFTP to upload and download a variety of information to and from the firewall, including the following:
Here, we demonstrated how to copy data (a log event file) from the firewall to TFTP server 10.251.7.113. We did this using a redirect (indicated by the >). Remember that when performing a redirect, you are really taking a snapshot of the data that is there. It is common to use a script to do continuous TFTPs when troubleshooting over time.
The second step of the copying process illustrates a best practice, which is to copy the current firewall configuration to a file on the TFTP server. The final step involves using TFTP to download a new ScreenOS software version to the firewall.
TFTP is inherently an insecure form of file transfer. Common problems with TFTP concern routing on the firewall and configuration of the TFTP server, which are beyond the scope of this book; however, an example was discussed on the Juniper Support site Knowledge Base at the time of this book’s printing (see http://kb.juniper.net/KB5210). A more secure file transfer option is to use SCP, which we discuss in the next recipe.
2.2. Use SCP to Securely Transfer Information to and from the Firewall
Problem
You want to use Secure Copy (SCP) to save the firewall configuration and then upload a new version of the ScreenOS software.
Solution
First, enable the Secure Shell (SSH) server on the firewall:
top-ssg140-> set ssh enableNext, enable the SCP server:
top-ssg140-> set scp enableTransfer the file to the firewall:
ddelcourt@ddelcourt-lt2 ~/borderfw1$ scp [email protected]:ns_sys_config ./borderfw1_config_021107_1230.txt[email protected]'s password:<password>ns_sys_config 100% 3835 3.8KB/s 00:00 ddelcourt@ddelcourt-lt2 ~/borderfw1$ lsborderfw1_config_021107_1230.txt
Finally, copy the software image to the firewall:
$ scp /tftpboot/ssg140.6.0.0r1.0 [email protected]:image[email protected]'s password:<password>ssg140.6.0.0r1.0 100% 10880KB 63.2KB/s 02:48
Discussion
SCP is really SFTP over an encrypted SSH session. It is inherently more secure than TFTP, and you could even use it to transfer information across the public Internet if required. You can manipulate any file listed under the get file command, including the ScreenOS image that is hidden in this listing.
We begin by enabling the SSH server functionality on the firewall with the set ssh enable command. Use the get ssh command to check that the expected version of SSH is running:
top-ssg140-> get ssh
SSH V2 is active
SSH is enabled
SSH is ready for connections
Maximum sessions: 8
Active sessions: 0
Admin Ip Addr Vsys Auth Method Service
--------- --------------- -------- ----------- -------
top-ssg140->In ScreenOS 5.1 and later, the default version of SSH will be version 2. If you require that version 1 be used, refer to the Juniper Support site Knowledge Base article at http://kb.juniper.net/KB6713.
get ssh and get scp will show you whether SSH is enabled:
top-ssg140->get sshSSH V2 is active SSH is NOT enabled SSH is NOT ready for connections Maximum sessions: 8 Active sessions: 0 top-ssg140->get scpSCP is NOT enabled SCP is NOT ready top-ssg140->
Next, enable the SCP server (a commonly overlooked step):
top-ssg140->set scp enabletop-ssg140->get scpSCP is enabled SCP is ready top-ssg140->
Transferring information via SCP is different than with TFTP; you need to know the specific file you are trying to upload or download. You can find a list of the files that can be manipulated by typing get file from the CLI:
top-ssg140-> get file
flash:/envar.rec 112
flash:/dnstb.rec 1
flash:/dhcpservl.txt 68
flash:/ns_sys_config 1183
flash:/$lkg$.cfg 1210
flash:/license.key 730
flash:/expire.rec 24
flash:/attacks.sig 198833
top-ssg140->In the case of the ScreenOS configuration file, you would be looking for ns_sys_config. From the SCP client side, enter the following:
ddelcourt@ddelcourt-lt2 ~/borderfw1$ scp [email protected]:ns_sys_config ./borderfw1_config_021107_1230.txt[email protected]'s password:<password>ns_sys_config 100% 3835 3.8KB/s 00:00 ddelcourt@ddelcourt-lt2 ~/borderfw1$ lsborderfw1_config_021107_1230.txt
You can monitor progress on the firewall as well:
top-ssg140-> get ssh
SSH V2 is active
SSH is enabled
SSH is ready for connections
Maximum sessions: 8
Active sessions: 1
Admin Ip Addr Vsys Auth Method Service
---------- --------------- ---------- ----------- --------
netscreen 10.251.7.116 Root password scp
top-ssg140->Lastly, upgrade the firewall to the recommended version of code. From the SCP client side, enter the following:
$ scp /tftpboot/ns200.5.4.0r1.0 [email protected]:image[email protected]'s password:<password>ssg140.6.0.0r1.0 100% 10880KB 63.2KB/s 02:48
You can verify results from the firewall in the event log:
top-ssg140-> get log event
Total event entries = 67
Date Time Module Level Type Description
2007-02-11 12:37:26 system notif 00026 SCP: Admin user 'netscreen'
transferred file 'image' to
device from host 10.251.7.116.
2007-02-11 12:34:16 system warn 00528 SSH: Password authentication
successful for admin user
'netscreen' at host
10.251.7.116.2.3. Use the Dedicated MGT Interface to Manage the Firewall
Problem
The firewall must be connected to a dedicated sideband, or out-of-band management network, via the onboard management interface (applicable only to platforms with a dedicated MGT port).
Solution
Configure all user traffic security zones to be in the untrust-vr:
isg1000->set zone trust vr untrust-vrisg1000->set zone untrust vr untrust-vr
Configure IP addressing on the interfaces:
isg1000->set interface e1/1 routeisg1000->set interface e1/1 zone trustisg1000->set interface e1/1 ip 10.251.7.99/29isg1000->set interface e1/2 zone untrustisg1000->set interface e1/2 ip 10.10.10.254/24isg1000->set interface mgt ip 10.20.20.1/28
Configure routing in the trust-vr for the MGT interface:
isg1000-> set vr trust route 0.0.0.0/0 interface mgt gateway
10.20.20.14Configure routing in the untrust-vr for user traffic:
isg1000->set vr untrust route 0.0.0.0/0 interface e1/2 gateway 64.2.31.249isg1000->set vr untrust route 10.100.0.0/16 interface e3 gateway 10.100.1.1
Discussion
The issue at hand is how to configure the firewall to use the onboard MGT interface connected to a dedicated sideband or out-of-band management network. Another way to solve this problem is to ensure that every management host that the firewall will ever need to communicate with is on the same local IP network subnet as the MGT interface IP. If this is the case, and no routes need to be added, specific or default, for the MGT interface to communicate with the systems required (such as syslog, NSM, the Network Time Protocol [NTP], etc.), nothing more needs to be done.
However, this is not the case in the vast majority of networks, as common services are often on separate network segments to be accessed by users and servers as well as the network devices.
Using this as the basis for discussion, it is important to understand how the MGT interface works and differs from other interfaces on the firewall. The dedicated MGT interface behaves like a “host” interface—in other words, traffic terminates on this interface, and cannot be routed through the firewall to any other interface and vice versa. The MGT interface is in the MGT functional zone, as described in Recipe 1.1, and this zone is in the trust-vr. You cannot change this mapping. If all the zones, and therefore all the interfaces, are in the same Virtual Router (VR), it means they share the same routing table.
isg1000-> get route
IPv4 Dest-Routes for <untrust-vr> (0 entries)
---------------------------------------------------------------------
H: Host C: Connected S: Static A: Auto-Exported
I: Imported R: RIP P: Permanent D: Auto-Discovered
N: NHRP
iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
E2: OSPF external type 2 trailing B: backup route
IPv4 Dest-Routes for <trust-vr> (11 entries)
------------------------------------------------------------------
ID IP-Prefix Interface Gateway P Pref Mtr Vsys
------------------------------------------------------------------
* 7 0.0.0.0/0 eth1/2 64.2.31.249 S 20 1 Root
* 8 10.15.0.0/29 eth1/1 10.251.7.97 S 20 1 Root
* 5 10.20.20.0/28 mgt 0.0.0.0 C 0 0 Root
* 6 10.20.20.1/32 mgt 0.0.0.0 H 0 0 Root
* 10 137.237.51.0/29 eth1/1 10.251.7.97 S 20 1 Root
* 11 137.237.51.32/28 eth1/1 10.251.7.97 S 20 1 Root
* 1 10.251.7.96/27 eth1/1 0.0.0.0 C 0 0 Root
* 2 10.251.7.99/32 eth1/1 0.0.0.0 H 0 0 Root
* 9 11.1.255.48/29 eth1/1 10.251.7.97 S 20 1 Root
* 4 64.2.31.254/29 eth1/2 0.0.0.0 H 0 0 Root
* 3 64.2.31.248/29 eth1/2 0.0.0.0 C 0 0 Root
isg1000->Because the MGT interface behaves like a host, it must have routing to allow it to connect to services on other parts of the network. Generally, you can accomplish this by setting a default route, just like a PC has, or via explicit routes. Either way, this route information will be different from the route information required for other data for-warding interfaces.
isg1000->set route 0.0.0.0/0 interface mgt gateway 10.20.20.14isg1000->get routeIPv4 Dest-Routes for <untrust-vr> (0 entries) --------------------------------------------------------------------- H: Host C: Connected S: Static A: Auto-Exported I: Imported R: RIP P: Permanent D: Auto-Discovered N: NHRP iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1 E2: OSPF external type 2 trailing B: backup route IPv4 Det-Routes for <trust-vr> (12 entries) ------------------------------------------------------------------- ID IP-Prefix Interface Gateway P Pref Mtr Vsys -----------------------------------------------------------------* 7 0.0.0.0/0 eth1/2 64.2.31.249 S 20 1 Root* 8 10.15.0.0/29 eth1/1 10.251.7.97 S 20 1 Root * 5 10.20.20.0/28 mgt 0.0.0.0 C 0 0 Root * 6 10.20.20.1/32 mgt 0.0.0.0 H 0 0 Root * 10 137.237.51.0/29 eth1/1 10.251.7.97 S 20 1 Root * 11 137.237.51.32/28 eth1/1 10.251.7.97 S 20 1 Root * 1 10.251.7.96/27 eth1/1 0.0.0.0 C 0 0 Root * 2 10.251.7.99/32 eth1/1 0.0.0.0 H 0 0 Root * 9 11.1.255.48/29 eth1/1 10.251.7.97 S 20 1 Root * 4 64.2.31.254/29 eth1/2 0.0.0.0 H 0 0 Root * 3 64.2.31.248/29 eth1/2 0.0.0.0 C 0 0 Root* 12 0.0.0.0/0 mgt 10.20.20.14 S 20 1 Rootisg1000->
You can see that there are now multiple default routes, and the firewall will need to choose one when making forwarding decisions for interfaces in the trust-vr. Which one will it use?
isg1000-> get vr trust route 0.0.0.0
Dest for 0.0.0.0
---------------------------------------------------------------------
trust-vr : => 0.0.0.0/0 (id=7) via 64.2.31.249 (vr: trust-vr)
Interface ethernet1/2 , metric 1
trust-vr : => 0.0.0.0/0 (id=12) via 10.20.20.14 (vr: trust-vr)
Interface mgt , metric 1ScreenOS will use the one that is listed first in the Forwarding Information Base (FIB). You can verify this by looking up the route ID (seen in parentheses in the output):
isg1000-> get route id 7
route in trust-vr:
------------------------------------------------
id: 7
IP address/mask: 0.0.0.0/0
next hop (gateway): 64.2.31.249
preference: 20
metric: 1
outgoing interface: ethernet1/2
vsys name/id: Root/0
tag: 0
flag: 24000040/00100001
type: static
Redistributed to:
status: active (for 47 seconds)
its next entry in FIB:
id: 12
IP address/mask: 0.0.0.0/0
next hop (gateway): 10.20.20.14
preference: 20
metric: 1
outgoing interface: mgt
vsys name/id: Root/0
tag: 0
flag: 24000040/00100001
type: static
Redistributed to:
status: active (for 49 seconds)
isg1000->In this case, the route with an id of 7 is listed first (it’s not always going to be the lowest route ID), so it will be chosen. The result of this configuration is that user traffic going through interface ethernet1/2 will be fine; however, management traffic will not be able to get off the 10.20.20.0/28 network.
The best practice solution is to put all the user traffic zones in a different VR. The good news is that ScreenOS provides two VRs, with no additional licensing, on all platforms. You really should do this during the initial architecture design phase to ensure that the zones are bound correctly, before building the IP configuration and routing associated with the interface.
Remember that no detail is too small to consider, and although having an out-of-band or sideband management network solves some security concerns, it can also create complexity in the configuration of the network devices that will connect to it for management access.
2.4. Control Access to the Firewall
Problem
Users in different parts of the enterprise, or distributed NOC/SOC centers, must manage the firewall, and they must be able to access common services.
Solution
Determine the interface(s) that will accept management traffic, and then configure the management protocols to be accepted:
top-ssg140->set interface e0/0 manage pingtop-ssg140->set interface e0/0 manage sshtop-ssg140->set interface e0/2 manage pingtop-ssg140->set interface e0/0 manage-ip 10.251.7.100
Next, determine how the firewall will reach management services:
top-ssg140->set syslog src-interface e0/0top-ssg140->set ntp server src-interface e0/0top-ssg140->set snmp host public 10.251.7.113/32 src-interface e0/0top-ssg140->set tftp source-interface e0/0top-ssg140->set nsmgmt server primary 10.251.7.113 src-interface e0/0
Now, define which network host(s) and/or address(es) can access the firewall:
top-ssg140->set admin manager-ip 10.100.41.0/24top-ssg140->set admin manager-ip 10.100.100.200/32top-ssg140->set admin manager-ip 10.100.100.201/32top-ssg140->set admin manager-ip 10.100.29.3/32top-ssg140->set admin manager-ip 10.251.7.96/27top-ssg140->set admin manager-ip 192.168.30.0/24
Change the root admin account, and configure individual admins:
top-ssg140->set admin name <root_adminname> password <password>top-ssg140->set admin user name <adminname> password <password> privilege alltop-ssg140->set admin user name <adminname> password <password> privilege read-only
Finally, configure the login banner:
top-ssg140-> set admin auth banner <string>Discussion
Although it is certainly a best practice to lock down management access to the fire-wall, it is easy to overlook all the functions that you can control and fine-tune within ScreenOS. Securing the firewall requires a holistic approach, as described earlier, and each additional knob turned or tuning performed provides another layer of protection against unauthorized users accessing the firewall. A basic primer of these layers of control includes the following:
Which hosts can manage the firewall? (Answer:
manager-ip)Who can manage the firewall? (Answer: admins and privileged users)
Which services/protocols can be accessed? (Answer:
set int, etc.)<interface>manage [ping|telnet|SSH|SNMP|ssl|web]Which IP on the firewall will be reachable? (Answer:
set int)<interface>manage-ip a.b.c.d
Most administrators will control what protocols should be enabled, but they may not realize that there are different settings on the interface depending on whether it is associated with a predefined or a custom security zone. This fact is the foundation for access to the firewall, and one must consider where management traffic will be coming from (because it is generally best to manage to the closest interface as opposed to through the firewall) as well as why it should be allowed on that interface:
top-ssg140->get int e0/0Interface ethernet0/0: description ethernet0/0 number 0, if_info 0, if_index 0, mode route link up, phy-link up/full-duplex vsys Root, zone Trust, vr trust-vr dhcp client disabled PPPoE disabled admin mtu 0, operating mtu 1500, default mtu 1500 ip 10.251.7.99/27 mac 0017.cb47.9400 manage ip 10.251.7.100, mac 0017.cb47.9400 route-deny disable pmtu-v4 disabledping enabled, telnet enabled, SSH enabled, SNMP enabled web enabled, ident-reset disabled, SSL enabledDNS Proxy disabled, webauth disabled, webauth-ip 0.0.0.0 OSPF disabled BGP disabled RIP disabled RIPng disabled mtrace disabled PIM: not configured IGMP not configured NHRP disabled bandwidth: physical 100000kbps, configured egress [gbw 0kbps mbw 0kbps] configured ingress mbw 0kbps, current bw 0kbps total allocated gbw 0kbps DHCP-Relay disabled at interface level DHCP-server disabled Number of SW session: 56063, hw sess err cnt 0 top-ssg140-> top-ssg140->get int e0/2Interface ethernet0/2: description ethernet0/2 number 9, if_info 7272, if_index 0, mode route link down, phy-link down vsys Root, zone Untrust, vr trust-vr dhcp client disabled PPPoE disabled admin mtu 0, operating mtu 1500, default mtu 1500 *ip 64.12.100.5/29 mac 0017.cb47.9409 *manage ip 64.12.100.5/29, mac 0017.cb47.9409 pmtu-v4 disabledping disabled, telnet disabled, SSH disabled, SNMP disabled web disabled, ident-reset disabled, SSL disabledDNS Proxy disabled, webauth disabled, webauth-ip 0.0.0.0 OSPF disabled BGP disabled RIP disabled RIPng disabled mtrace disabled PIM: not configured IGMP not configured NHRP disabled bandwidth: physical 0kbps, configured egress [gbw 0kbps mbw 0kbps] configured ingress mbw 0kbps, current bw 0kbps total allocated gbw 0kbps Number of SW session: 56063, hw sess err cnt 0 top-ssg140-> top-ssg140->get int e0/6Interface ethernet0/6: description ethernet0/6 number 10, if_info 8080, if_index 0, mode route link down, phy-link down vsys Root, zone WebServers, vr trust-vr dhcp client disabled PPPoE disabled admin mtu 0, operating mtu 1500, default mtu 1500 *ip 0.0.0.0/0 mac 0017.cb47.940a *manage ip 0.0.0.0, mac 0017.cb47.940a pmtu-v4 disabledping disabled, telnet disabled, SSH disabled, SNMP disabled web disabled, ident-reset disabled, SSL disabledDNS Proxy disabled, webauth disabled, webauth-ip 0.0.0.0 OSPF disabled BGP disabled RIP disabled RIPng disabled mtrace disabled PIM: not configured IGMP not configured NHRP disabled bandwidth: physical 0kbps, configured egress [gbw 0kbps mbw 0kbps] configured ingress mbw 0kbps, current bw 0kbps total allocated gbw 0kbps Number of SW session: 56063, hw sess err cnt 0 top-ssg140->
As you can see, there are differences between the manageability of the firewall to interfaces in the default Trust and Untrust security zones, and that a custom-defined security zone defaults to a closed state just like Untrust. This means that it may actually take some unset or set commands to get the security posture required. Setting the manage-ip is the final step.
Next, determine how traffic sourced by the firewall will behave. By default, ScreenOS will use the routing table to determine where to send the data. However, ScreenOS does provide flexibility as to the interface from which to source for most of the management traffic. This allows for more granular management traffic control. If setting the source interface makes the management traffic flow through the firewall, it is subject to a policy check like any other traffic:
top-ssg140->get policyTotal regular policies 4, Default deny. ID From To Src-address Dst-address Service Action ... 1 Untrust Trust Any Any PING Deny ... 4 Untrust Trust Any Any PING Permit ... 2 Untrust Trust Any Any ANY Permit ... 3 Trust Untrust Any Any ANY Permit ... top-ssg140->ping 10.251.7.113 from e0/2Type escape sequence to abort Sending 5, 100-byte ICMP Echos to 10.251.7.113, timeout is 1 seconds from ethernet0/2 ..... Success Rate is 0 percent (0/5) top-ssg140->set policy id 1 disablepolicy id = 1 top-ssg140->ping 10.251.7.113 from e0/2Type escape sequence to abort Sending 5, 100-byte ICMP Echos to 10.251.7.113, timeout is 1 seconds from ethernet0/2 !!!!! Success Rate is 100 percent (5/5), round-trip time min/avg/max=1/2/6 ms top-ssg140->
It should be noted that if the “default-vr” setting is changed, it can have an impact on traffic sourced by the firewall.
The manager-ip setting provides very good protection, as the firewall will not process management requests from hosts or networks not on the list. ScreenOS provides the administrator with up to six host/network definitions for the entire system. Some customers go to great lengths to set up bastion or jump servers from which all communication to the firewall must originate, outside the NSM, and provide the firewall admin teams with flexibility, as they are generally on the move and not always coming from their desk IP addresses.
This, coupled with strict administrator account definition, can provide tight access control. It is recommended that you use either SecurID or the Remote Access Dial-In User Service (RADIUS) to manage the user accounts, as they will provide stronger password authentication options. In addition, it is a best practice to monitor failed login attempts; if the limit is exceeded, the syslog server or other log management system can generate an alert to notify the administrator of a potential intrusion attempt.
Lastly, the banner is not very common unless you are working in the financial or government sector. This does not provide any physical security, but it can lay the groundwork for providing the would-be-unauthorized user with a message letting him know his possible attempts to access the system are not welcome and may be tracked for legal action. There are many schools of thought here, and it is always prudent to work with legal counsel to ensure that the proposed language is defensible and appropriate. For more information about this see http://www.cybercrime.gov/s&sappendix2002.htm or http://ciac.llnl.gov/ciac/bulletins/j-043.shtml.
By default, ScreenOS is closed to management traffic unless it is destined for an interface in the Trust security zone. This can lead to a false sense of security as it has been proven that internal trusted personnel can do as much damage as someone from the outside. As a security device on the network that is depended upon to provide protection from unwanted users and applications, it is equally important to protect the firewall from unwanted access attempts. A layered approach is the best way to accomplish this using the many features within ScreenOS to keep tightening the loop.
Ultimately, as with any solution, this will be only as strong as the weakest link. If all measures are taken and the access method allowed is Telnet, or the password is a simple dictionary word, it would not take the average intruder very long to find a way in with the readily available attack tools on the Internet today (e.g., see Security Power Tools by Bryan Burns et al. [O’Reilly]).
2.5. Manage Multiple ScreenOS Images for Remotely Managed Firewalls
Problem
Remotely managed firewalls require a backup image to ensure an operational state in case of running image corruption.
Solution
During the boot sequence, press any key when prompted to “run loader”:
Hit any key to run loader Serial Number [0185122006000285]: READ ONLY HW Version Number [1010]: READ ONLY Self MAC Address [0017-cb47-9400]: READ ONLY Boot File Name [ssg140.6.0.0r1.0]:ssg140.5.4.0r4.0Self IP Address [192.168.1.1]:10.251.7.99TFTP IP Address [192.168.1.1]:10.251.7.113Save loader config (56 bytes)... Done The configured TFTP server is connected to port 0 Loading file "ssg140.5.4.0r4.0"... r Receiving data block ... #20384 Loaded Successfully! (size = 10,441,842 bytes) Ignore image authentication!
Upon the prompt to save to flash, enter m for multiple image support:
Save to on-board flash disk? (y/[n]/m) m Yes!Enter a filename that conforms to the DOS 8.3 naming convention standard:
Please input multiple system image file name [ssg14054.0]: 140540.r4
Saving system image to on-board flash disk...
Done! (size = 10,441,842 bytes)Enter n when prompted to run the downloaded image:
Run downloaded system image? ([y]/n) nRepeat this process for both images desired to be saved to flash memory. Then, set the boot order via the command line, and save the configuration:
bottom-ssg140->set envar boot=flash:/140600.R1;140540.R4bottom-ssg140->saveSave System Configuration ... Done
Discussion
This recipe leverages the onboard flash memory, which on the SSG140 used here is 64 MB. To verify that all the steps are followed, you must examine the filesystem on the flash memory:
bottom-ssg140-> get file
flash:/$NSBOOT$.BIN 11141120
flash:/burnin_log1 40960
flash:/burnin_log0 40960
flash:/crash.dmp 131072
flash:/envar.rec 125
flash:/ns_sys_config 1433
flash:/prngseed.bin 32
flash:/images/
bottom-ssg140->Not all the files are shown here. The $NSBOOT$.BIN is the active image that is in memory. The ns_sys_config file is the active ScreenOS configuration file that is in memory. To see everything written to flash memory, you must use a hidden command structure:
bottom-ssg140->exec vfs ls flash:/$NSBOOT$.BIN 11,141,120 golerd.rec 0 node_secret.ace 0 syscert.cfg 1,167 certfile.cfg 1,324 certfile.dsc 252 burnin_log1 40,960 burnin_log0 40,960 crash.dmp 131,072 envar.rec 93 ns_sys_config 1,479 prngseed.bin 32 images/140600.R1 11,141,120 140540.R4 10,441,8424,294,967,295 bytes free (4,294,967,295 total) on disk
This exposes the images that were saved during the boot cycles, with the naming structure defined. Upon the next reboot, the image that was selected to boot first will be loaded; if it becomes corrupt, the second image will attempt to load.
bottom-ssg140->get envardefault_image=ssg140.6.0.0r1.0 last_reset=2000-07-05 19:24:01 by netscreen shdsl_pic_mode=0boot=flash:/140600.R1;140540.R4bottom-ssg140-> bottom-ssg140->resetSystem reset, are you sure? y/[n]yIn reset ... Loading system image "/140600.R1" from on-board flash disk... Done! (size = 11,141,120 bytes) Ignore image authentication! Start loading... ................................................................. ................................................................. ................................................................. ................................................................. ................................................................. ................................................................. ................................................................. ................................................................. ................................................................. ....... Done. Juniper Networks, Inc Security Services Gateway System Software Copyright, 1996-2006 min_pfn = 13000, max_pfn = 1c000, mem_size = 1c000000 bootmap_size = 3800 Version 6.0.0r1.0 ... bottom-ssg140->get systemProduct Name: SSG-140 Serial Number: 0185122006000285, Control Number: ffffffff Hardware Version: 1010(0)-(00), FPGA checksum: 00000000, VLAN1 IP (0.0.0.0)Software Version: 6.0.0r1.0, Type: Firewall+VPN
This practice is very useful in testing environments where multiple versions of code must be run to verify feature functionality, the presence or disappearance of bugs, and general performance testing.
2.6. Manage the USB Port on SSG
Problem
The firewall cannot access a TFTP server as described in Recipe 2.1 and the image or configuration file must be pulled from a Universal Serial Bus (USB) memory stick.
Solution
First, ensure that the correct image is on the USB stick:
ddelcourt@ddelcourt-lt /cygdrive/g$ lsCustomer Recycled Dept Stuff Tools Misc md5sum.exe ssg140.5.4.0r4.0ssg140.6.0.0r1.0ddelcourt@ddelcourt-lt /cygdrive/g
Safely remove the USB stick from the PC/system and insert it into the USB slot on the SSG, and then verify that ScreenOS recognizes it and can list the files:
bottom-ssg140-> LEXAR MEDIA JUMPDRIVE, rev 2.00/30.00, addr 2, SCSI over Bulk-Only Mount usb device. Please wait... usb device (usb) ready. bottom-ssg140->get fileflash:/$NSBOOT$.BIN 11141120 flash:/burnin_log1 40960 flash:/burnin_log0 40960 flash:/crash.dmp 131072 flash:/envar.rec 125 flash:/ns_sys_config 1433 flash:/prngseed.bin 32 flash:/images/ USB flash device : usb:/.Trashes/usb:/ssg140.6.0.0r1.0 11141120usb:/ssg140.5.4.0r4.0 10485760 usb:/Customer/ usb:/Misc/ usb:/Tools/ usb:/Dept Stuff/ usb:/md5sum.exe 34816 usb:/Recycled/ bottom-ssg140->
Save the desired version of ScreenOS to flash memory:
bottom-ssg140->save software from usb ssg140.6.0.0r1.0 to flashIt will replace current image file with usb image ssg140.6.0.0r1.0. Do you want to continue... y/[n]yLoad image from usb to flash: ssg140.6.0.0r1.0. Read .................................. Save to flash. It may take a few minutes ... platform = 24, cpu = 12, version = 18 update new flash image (02555050,11141120) platform = 24, cpu = 12, version = 18 offset = 20, address = 5800000, size = 11032611 date = 1483, sw_version = 30008000, cksum = 55fe2c90 Program flash (11141120 bytes) ... ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++done bottom-ssg140->
Safely remove the USB stick from the firewall and reset the system:
bottom-ssg140->exec usb-device stopThe "USB Mass Storage Device"can now be safely removed from system bottom-ssg140->resetSystem reset, are you sure? y/[n]yIn reset ...
Monitor the boot process to ensure that the proper image was loaded and to find anything in the configuration that does not load due to the new image (this is more likely to occur when downgrading the image):
Juniper Networks SSG-140 Boot Loader Version 3.2.3 (Checksum:
ECD688CB)
Copyright (c) 1997-2006 Juniper Networks, Inc.
Total physical memory: 512MB
Test - Pass
Initialization - Done
...
bootmap_size = 3800
Version 6.0.0r1.0
Load Manufacture Information ... Done
...Discussion
The USB port is new to ScreenOS platforms and is a more convenient way to man-age data to and from the firewall than the older Compact Flash method. You can use the USB port to save any file from flash memory, and it is extremely useful when capturing the crash.dmp file for the Juniper Technical Assistance Center (JTAC) as well as when used with the process described here to manage the ScreenOS image.