This information is historical -- the CS departmental firewall no longer exists (trg, 2014-2-28)

---

Tutorial 9: Netscreen firewall procedures

Roadmap for this tutorial: How to do stuff to the Netscreens, including route-point management and policy management. See "Network Firewall" for background descriptive information.

Firewall access

• DC firewall FQDN: dc-csfw1.uwaterloo.ca
• MC firewall FQDN: to be determined
• Credentials: see the password cardfile in the key vault
• Access: the web interface is preferred for policy management, but the CLI is required for network interface management. See Tutorial 2 for details. The GUI is required for firmware management. Note that there are browser dependencies that cause many OS-platform/browser combinations to fail when doing updates. In particular, https with anything other than IE6 seems to fail when saving a configuration change -- however viewing configurations seems to work.

Basic configuration information

Most information can be found using a web browser and the Netscreen GUI at https://dc-csfw1.uwaterloo.ca/. Instructions on using the CLI for basic configuration information are in Network tutorial 2.

Policy management

Policy components

Firewall policies (rules) are based on:

• a source and a destination pair, each consisting of a firewall zone and an address specification in that zone. See "Firewall zones" for up-to-date zone definitions.
• a service (protocol) and
• an action (permit or deny).

To modify an existing policy, you may need to modify one or more of the address or service components. And to define a new policy, the addresses and service (protocol) must first be defined to the firewall. These policy components are managed with the object management tools in the GUI (it is possible to do this with the CLI, but not recommended).

Address objects

For address management there are two significant sub-categories

• List (of singleton items)
• Groups (of items in the List).

Each of these is managed on a per-zone basis. So, for example, a desktop workstation "scspc123.cs.uwaterloo.ca" would be defined (usually) in zone 4. There is nothing to prevent an address from being defined in multiple zones, but it is of questionable value. If you are moving objects from one zone to another, take care to remove it from the obsolete zone.

The term "singleton" is a bit of a misnomer, since an "address object" can consist of a network range of addresses (e.g. an entire /24 subnet). If you do this, please make the name and comments meaningful.

When defining an object, make the name a short meaningful one. In the absence of anything else, we tend to use the inventory system hostname, e.g. "scspc123.cs" for the name, and use the FQDN for the actual address of the object, eg "scspc123.cs.uwaterloo.ca". In the comment field, for workstations assigned to grad students, it is very helpful to mention the supervisor's name (similarly for research-project machines -- mention the project name and supervisor). Unless there is good reason to do so, please do not use an IP address for the object address -- it makes end-of-use management more difficult.

Service objects

There are three categories of services:

• Predefined: "built-in" to the firmware
• Custom: services we define
• Groups: sets of predefined and custom services.

"Custom" versus "groups" is a bit of a fine art, since the custom services can entail multiple protocols. Where possible, we try to limit the range of custom protocols to just the TCP and UDP variants of a given port number. For example IPP is UDP and TCP port 631, and this is defined as a single custom service. However, some services are known to use a few ports in concert, and these are suitable as a single custom service (example: VMWare Server management is TCP ports 8222, 8333 and 902).

We prefer to use service groups for higher-level collections of related services, eg the "printing protocols" group contains the "hp jetdirect", "IPP" and "lpr" services (each of which may consist of one or more ports and protocols).

The practice of creating a "special" service which is random assortment of services customized for a particular workstation is deprecated. Instead, use the "multiple service" capability of policy creation in this circumstance. However, if a particular set of services is likely to be used in more than one policy, a group service is appropriate.

Services are global to the entire firewall and are not zone-specific.

Adding new policies

Make sure you read the preamble to http://www.cs.uwaterloo.ca/cscf/policies/firewall before making any policy changes.

Policy planning

It's essential that you consider traffic between zones when adding policies to the firewall. For example, if you want to allow VNC to a workstation in zone 5", you need to think about from what zones the traffic might originate. Typical scenarios are from Untrust, zone 1, zone 4 and zone 5 for grad/staff workstation policies (denying from the teaching environment). Thus to allow VNC into a zone 5 workstation would require several new policies, one for each of the potential source zones (for example: "Untrust -> Zone5", "Zone5 -> Zone2", "Zone1 -> Zone5" etc.).

Creating the policy for a single source/destination pair

• display the policy page and select the appropriate source and destination zones
• press "New" at the upper-right corner of the page
• fill out the form:
  • name: give the rule a name. Some indication is ownership/responsible person is preferred.
  • source: an address, group or "any"
  • destination: an address or group. "any" is possible but not typical.
  • service: using multiple services here is acceptable if the set is customized for a particular source or destination. The former practice of creating a "special" group for every workstation is deprecated. However, if a particular set of services is likely to be used in more than one policy, a group service is appropriate.
• save your new policy

For the sources and destinations, use of "multiples" is acceptable if the collection of addresses is not likely to be reused in more than one policy.

A good example of service and address groups is the "zone 5 world webservers" set. There is an address group of systems that are permitted to be used as webservers accessible from off campus. And there is a service group of related "web" services that web-servers typically require. With these two groups defined, allowing a workstation to become a web-server is simply a mater of adding the new workstation address object to the address group -- there are existing policies already defined that allow access for each of the necessary zone combinations. All you need to do is add the address to the group.

Modifying existing policies

The first thing you will need to do is locate the policy that needs to be changed. As policies are organized by source and destination zone, you'll need to find the relevant zones: both "Current VLAN assignments" (sorted by IP address range) or "Firewall zones" can be helpful in this task.

• select the appropriate source and destination zones. Pay attention to the "list nn per page" filter.
• find the policy in the list, click "edit" in the Configure column
• make the changes and "save"

Removing an existing route-point

To remove a route-point, its routing configuration must first be deleted. Unfortunately the GUI interface is incapable of doing this (nb the error diagnostic it gives is not useful), so you must use the CLI. The following assumes that the route-point has been set up with virtual interface redundancy failover -- the inactive interface is de-configured first, followed by the active interface.

In the following example, "redundant2.x:1" is the inactive interface, and "redundant2.x" is the active interface. You can determine which is which from looking at the "State" and "VSD" columns in the output to a `get interface` command (VSD=1 means active). Note that it doesn't matter too much if you get this wrong -- the Netscreen won't let you do things it doesn't like. If you get errors about "VSI existing" or some such, just try working on the other interface instead.

To begin, remove the routing protocols:

   unset interface "redundant2.x:1" protocol rip enable
   unset interface "redundant2.x:1" protocol rip 
   unset interface "redundant2.x:1" 

   unset interface "redundant2.x" protocol rip 
   unset interface "redundant2.x" route
   unset interface "redundant2.x" ip manageable
   unset interface "redundant2.x" ip
   unset interface "redundant2.x" manage ping

Now, the firewall access-list information for the trust zone must be dismantled. You must inspect the access lists, determine the appropriate information and then unset it.

   get vrouter trust-vr access-list

Look for the access-list that contains the interface you are removing. It will be identified by a number; call it al . Then

   get vrouter trust-vr route-map

and look for the route-map entry that contains the access list al ; call it re . Now, you can remove the access list and the route-map that contains it:

unset vrouter trust-vr access-list al
unset vrouter trust-vr route-map "rtmap1" re

The identifiers al and re are independent -- they may turn out to be the same number but that is just a coincidence.

Next,

   get vrouter untrust-vr access-list

and then remove the IP network from the access-list for the untrust zone:

unset vrouter untrust-vr access-list list# a.b.c.d/nn seq#

where list# and seq# are determined from inspecting the output of the command, and a.b.c.d/nn is the IP network number and size for interface "redundant2.x".

Finally, you can remove the active interface from the security zone, and the interface itself:

   unset interface "redundant2.x" zone
   unset interface "redundant2.x"

Setting up routing

Note: This information is, as of the time of writing (2010-6-1) intended to be descriptive, not prescriptive. It is based on a single-device setup and was determined by inspection of the current devices configuration in combination with the now-obsolete information in http://www.cs.uwaterloo.ca/cscf/internal/networks/ns_new_subnet.shtml.

Preliminary information: you will need to know:

1. IP network specification: name, starting address and size
2. into which zone you want to put the network

Once you have this information, go to the "creating a new vlan" tutorial.

Firmware management

Obtaining and installing new firmware

Note: this process will cause an automatic reboot of the device, so issue the appropriate user notifications before beginning.

• http://www.juniper.net/customers/support/
• login as trg@uwaterloo.ca (Juniper doesn't allow generic accounts), password on file in the value (edge switch password)
• navigate to Download Software--ScreenOS
• download the desired image and store locally; get the documents if you want
• log into the web management console of the device and use the GUI to load the new firmware
  • this is the only way to apply firmware updates -- the CLI cannot be used
  • if the device is not network accessible, connect a laptop to the management network interface (see "Connecting to the management network") and access the GUI that way.
• the device will reboot automatically once the load is complete.

Dave's notes on what he wants to see documented somehow

Some of this is an operational SOP as opposed to an instructional tutorial, but it needs to be written down somewhere:

  Tutorial 1.
    1.1) methods of accessing
         serial console
           - cables/D-Kit adaptor
         web,
         ssh,
    1.2) Display configurations (running and stored)
         "get config"
         - greping  the config for a specific display
           "get config | include "string"
           - what regular expressions ("wild" cards)
             work with "include" statement.

  Tutorial 2.
     2.1)  Backup Netscreen
              - to laptop Linux and Windows
              - to central server
              - Document were central repository of configs will
                live.
                - ask Guoxiang if somewhere on backup.cs
                  makes sense?
              - validating backup file

     2.2) restoring to alternate config space
          - includes how to temporarily booting with
            alternate config.

     2.3) Reset Netscreen to Factory defaults.
          - confirm we're at factory defaults
          - what happens to account/password settings.

     2.4) restoring a saved config from unknown device state.


Tutorial 3.) (Maybe Tutorial 2 and 3 should be reversed or just move
              tutorial 2 to the end of the Tutorial set).

  3.1) How to get firmware Upgrades from Juniper.
  3.2) Install new firmware and reset device to factory defaults.
  3.3) Setting up LACP
       - Trunk 1: port one on NIC one LACP'd to port one on NIC 2.
       - Trunk 2: port two on NIC one LACP'd to port two on NIC 2.
  3.4) Setup /30 point-to-point VLan connection for Trunk 1.
  3.5) Join the Netscreen (Management port?) to OSPF area 4.
  3.6) Demonstrate connectivity to the Netscreen over the network.

  3.7 (bonus section)
       3.7.1) Connect Trunk 2 as second /30 point-to-point
              connection from Netscreen to a differect switch.
       3.7.2) Prove that the double path to the Management IP is
              dealt with by OSPF
       3.7.9) Disconnect this second connection for now.


Tutorial 4.)
  4.1) Setup security zones to mirror current setup.
  4.2) Setup a currently unused test 172.19.?? vlan in each security
       zone.
  4.3) Setup a PC that has Ubuntu server (THAT HAD ALL POSSIBLE
       SERVICES SELECTED DURING THE INSTALL) on the vlan.
  4.4) nmap the PC from your laptop:
         on the local vlan.
         on a current firewalled vlan.
         on a unfirewalled vlan
         on a vlan outside of our OSPF area (non-DC wireless).
  4.5) reconnect the second link.
       4.5.1) What Vlan trunking needs to be done?
       4.5.2) Using a continuous "ping" check what happens
              as you disconnect Trunk 1 or Trunk 2.
              How many pings are dropped?

 Tutorial 5.)
  4.1) Setup a test VLan on old Netscreen implementation
       routed by RIP.
  4.2) Move PC to that VLan and check how traffic is routed to it.
  4.3) Add OSPF routing for test VLan on new Netscreen (not touching
       the RIP routing setup in 4.1.
  4.4) Confirm that OSPF routing has higher priority than RIP
       routing, ie what does traceroute to the host show now?
  4.5) What route is advertised to the OSPF backbone?
  4.6) Does removing the RIP setup on the old Netscreen
       implementation have any affect now that the new Netscreen
       setup is providing OSPF routing?