Application for UIUC Departmental Firewall Approval

Note: This application is for approval of a firewall installed and maintained by an individual department or unit.

If you want to apply for membership in one of the four protection groups of the UIUC campus firewall, see http://www.cites.illinois.edu/firewall/.

Introduction

A departmental or unit firewall may offer some protection to departmental computers from scans and other probes originating from outside the firewall. The level of protection that departmental machines will receive from the firewall is dependent on the firewall's type and configuration. Departments and/or units should work with the CITES Network Design Office (NDO) to define the level of protection required.

Not all types of departmental firewalls are permitted for use with the UIUC network.

• Personal firewalls (which protect only the computer on which they are installed) are permitted and do not require CITES approval or completion of this form.
• Firewalls which protect more than the computer that it is installed on always require CITES approval. Of those firewall types:
  • Transparent types are permitted. Contact the Network Design Office to inform them of your transparent firewall needs and complete the documentation required.
  • Network Address Translation (NAT) types, including PAT types, are permitted. Contact the Network Design Office to inform them of your transparent firewall needs and complete the documentation required.
  • Router types are not permitted.

Summaries of firewall definitions are as follows:

Personal

A personal firewall is intended for protection of only one computer. Personal firewalls do not require CITES approval to be installed.

Transparent

A transparent firewall that protects more than the computer that it is installed on needs CITES approval.

In transparent mode, a firewall filters packets traversing the firewall without modifying any of the source or destination information in the IP packet header. All interfaces behave as though they are part of the same network, with the firewall acting much like a layer 2 switch or bridge. Because there is no routing or network address translation, the IP addresses on the protected network must be valid routable addresses.

Pros:

• No need to reconfigure IP space from currently assigned addresses.
• Easily pulled out of the loop if needed to diagnose network problems.
• The Security group can accurately map problem IP addresses.

Cons:

• Cannot do address translation. If there is a need to mask internal network numbers from the outside world, this firewall mode will not do that.
• The firewall does not appear in a traceroute; it is transparent like a layer 2 switch would be.

NAT (Network Address Translation) mode

A NAT firewall that protects more than the computer that it is installed on needs CITES approval.

In this mode, a firewall acts as a layer 3 device. It may translate two components of the header of an outgoing IP packet traversing the firewall from the trusted side: the source IP address and source port number. There are two primary types of NAT firewalls: one-to-one and one-to-many (also called PAT or port address translation).

In one-to-one NAT, a firewall will map an internal IP address to a unique external IP address. In this case, port number mapping will not be done.

In one-to-many NAT (a. k. a. PAT), a firewall will map an internal IP address to one external IP address and a random port number. So all traffic behind the firewall appears to be coming from one IP address (or a limited range of addresses).

Pros:

• Internal addresses are not revealed to external devices.
• In one-to-many NAT, fewer routable addresses are needed to service hosts.

Cons:

• The Security group cannot pinpoint an offending machine, especially in one-to-many NAT.
• Turning off the one outside IP address in a one-to-many NAT would disable network access for every computer behind the NAT firewall.
• The device is acting as a router; removing it for diagnosing network problems becomes much more difficult.
• Some protocols still have problems with NAT (especially with PAT).

Route mode

Route mode firewalls are not allowed at UIUC.

In route mode, a firewall routes traffic between different interfaces without performing any network address translation. Hosts on the trusted side must have routable addresses. Trusted and untrusted interfaces are on different subnets. This firewall is working at layer 3.

Why route mode firewalls are not allowed at UIUC:

• Removing the firewall for diagnosing network problems becomes difficult because the firewall is acting as the router for the subnet behind the firewall.
• Multiple subnets are needed for connecting a network to the campus. (The external interface of the firewall would need to be on one net, the internal interface on another net, and a third net for the traditional DMZ zone may be needed if the firewall supported it and the unit requested it).

Pre-Approval Steps for Firewall Configuration

Diagrams and documentation provided to CITES Network Design Office

To apply for CITES approval of a departmental firewall, the unit must indicate the type of firewall they'll be using, and provide a diagram of how the firewall fits into the UIUC network. Diagrams will indicate whether the firewall protects a certain group within a departmental network or whether the firewall stands between the entire departmental subnetwork and the rest of the UIUC network. Diagram details should indicate the firewall's mode and any IP address translation involved.

NAT mode: If the firewall is configured in NAT mode, the CITES Network Maintenance group will not troubleshoot the segments behind the firewall until the unit removes the firewall, and (when necessary) reconfigures ALL hosts behind it with IP addresses on the unit's normal subnet.

Transparent mode: Firewalls configured in transparent mode require removal for troubleshooting, but it is not necessary to renumber IP addresses.

Unit documentation: The unit's documentation should include detailed steps for the removal of the firewall when the CITES Network Maintenance group is required to troubleshoot. This information is essential in case the unit's primary network administrator is not available.

(NAT only:) Security logs required

When the firewall is configured in NAT mode, the unit must demonstrate that it can provide logs for security tracking.

Refer to security policies in the Interim Policy on Appropriate Use of Computers and Network Systems. Pertinent information is located in Section 6 ( 6.1, 6.2), and Section 9. Logs need to be carefully, accurately, and securely kept for a period of at least six weeks.

The unit acknowledges that the protection offered by the firewalls is limited to traffic that flows through the firewall. The firewalls can't provide protection from the traffic that enters the network from behind the firewall. Careful attention to the security patches and maintenance of any computer system is still important. The unit should be vigilant about the security precautions used for each machine under its control, whether or not the machine is protected by one or more firewalls.

Multi-VLAN switch required

To implement a firewall setup for a building, it is required that the building has an NDO-approved, multi-VLAN switch. A multi-VLAN switch is the only supported method to provide services such as wireless, O&M, door access, OIR, walkup, and other unit networks.

For buildings that don't contain a multi-VLAN switch, network reconfiguration will be required to properly integrate the firewall into the network in a way that meets the NDO standards. The NDO will recommend an approved multi-VLAN switch, and consult with the network administrator to address the cost, setup, and installation.

Physical location of firewall machine

Background

As network-related threats to campus computers multiply, some UIUC Departments and Colleges have elected to install local firewalls to protect their networks not only from Internet-based threats, but also from other users on campus that are behind the campus firewalls. CITES applauds and encourages these efforts to increase the overall security of campus computing resources and data.

When the first departmental firewalls were installed, the CITES Network Maintenance Group asked that they be installed in the CITES Communications Equipment Rooms (CERs), so that when trouble shooting a network problem, it would be very easy to first recognize that a local firewall was in use and then to bypass it if necessary to isolate the problem. As a result, there are some departmental firewalls in CITES CER’s across campus.

In reaction to the terrorist events of September 11, 2001 and with the possible move to A Voice over IP (VoIP) based telephone service, the desire for physical security of the CITES CER’s has increased. As a result, several years ago with the implementation of the campus standard network reference design, CITES changed its policy on the location of departmental firewalls. The preferred location for a departmental firewall is now in departmentally controlled space, not in a CITES CER.

In the reference design for the Campus Network Upgrade, a departmental firewall connects via copper cabling to the building’s Building Collection (BC) or Building Distribution (BD) switch. Each upgraded building on campus has either a BC or BD device, depending on the configuration of the local networks and where else on campus they appear. Buildings that have not yet been upgraded and may not have a BC or BD device will be dealt with on a case-by-case basis.

Furthermore, departmental firewalls must operate in either transparent mode or in a NAT mode, both of which allow CITES Security to have visibility into the local network and the ability to deal with compromised machines in a granular fashion.

The preference for locating a departmental firewall in departmentally controlled space remains the primary default policy and what is referred here to as Option A. This document attempts to define two alternative options that in some cases may be necessary, due to the physical layout of the building that houses multiple departments or units.

The Problematic Layout

Experience has shown that in some large campus buildings that house multiple departments, it is possible that a given unit’s physical space may not be served by the CITES CER that contains the BC or BD device. In that situation, locating the firewall in departmentally controlled space and connecting it to the BC or BD device is either impossible over copper cabling due to the distance from that space to the BC or BD device, or very impractical due to the expense that would be involved in running fiber optic cable from the BC/BD device directly to the firewall in departmentally controlled space.

Departmental Firewall Physical Location Option B

The preferred way to deal with this problematic layout is to locate the departmental Firewall for Department A in the space of a cooperating Department B that is served by the CITES CER that contains the BC or BD device. This requires a certain level of trust between Department B and the network a personnel of Department A and vice versa, but it is a valid solution to this problem and in fact has been show to work. This solution fits the reference model and can be easily implemented by both CITES and the departments involved.

Departmental Firewall Physical Location Option C

In some cases with the problematic layout, the department seeking to install the firewall does not have direct access to the CITES CER with the BC or BD device may not be in the same college as the other departments(s) in the building, or for whatever reasons may not have a trust relationship with the other unit(s) in their building. That situation could make Option B hard to implement.

In this case, upon the CIO’s receipt of a letter or email from the Academic Dean’s Liaison (ADL) from the college of the department seeking to install the firewall that states that all efforts to implement option B have failed, CITES personnel will install the departmental firewall in the CITES CER containing the BC or BD device and will connect it to that device. CITES personnel will configure the BC or BD device to send the department’s data traffic through the departmental firewall. As in all options, the department will be responsible for purchasing and configuring the firewall itself, and submitting departmental firewall paperwork to the CITES Network Design Office (NDO) for approval prior to firewall purchase and installation. The NDO can assist the department with firewall recommendations. A list of the ADL representatives can be found at: http://www.cites.illinois.edu/projects/netupgrade/deans_liaison.html

Firewalls that are to be located in a CITES CER shall be AC-powered, 19” rack- mountable and shall be no more than 3 rack units high. If the department desires a UPS for the firewall, it will need to provide that as well. Local conditions will dictate whether the UPS should be rack-mountable or not.

Physical access by departmental personnel to a departmental firewall in the CITES CER will be extremely limited. At some point in the future, special training or certification may be required for physical access to the CER housing the BC or BD device.

Option C is only available in buildings where there is sufficient rack space, electrical service and cooling in the CER containing the BC or BD device. The cost of supplementing the rack space, electrical service or cooling to accommodate a departmental firewall in a CITES CER will be the responsibility of the department.

Policy changes may require firewall modifications

When there are changes to the Interim Policy on Appropriate Network Use of Computers and Network Systems that affect the firewall setup, the unit acknowledges that changes to the firewall setup will be required.