D EPARTMENTAL F IREWALL G UIDELINES AND P ROCEDURES

University of California, Davis

D EPARTMENTAL F IREWALL G UIDELINES AND P ROCEDURES

Published October 2003; Revised March 2007

Table of Contents
Departmental Firewall Guidelines and Procedures..................................................................................... 1
Introduction ................................................................................................................................................. 3
Benefits and Risks of Having a Departmental Firewall.............................................................................. 3
Choosing A Firewall ................................................................................................................................... 4
Performance and Topology Considerations ................................................................................................ 4
Determine the Location for the Firewall ..................................................................................................... 7
Cost Components ........................................................................................................................................ 7
Memorandum of Understanding for Departmental Firewalls ..................................................................... 7
Coordinate the Installation .......................................................................................................................... 8
Consultation with Desktop Enterprise Solutions (DES) (Optional) ........................................................... 8
Additional Resources .................................................................................................................................. 9
Attachment 1: Memorandum of Understanding (MOU) Regarding the Use of Departmental
Network Firewalls ..................................................................................................................................... 10
Memorandum of Understanding Regarding the Use of Departmental Network Firewalls ...................... 12
Attachment 2: Departmental Firewall Rule Sets ...................................................................................... 14
Suggested Base Rules ............................................................................................................................... 14
Suggested Optional Rules ......................................................................................................................... 14
Egress Filtering ......................................................................................................................................... 16
Ports Related to Microsoft Active Directory, Microsoft Exchange, and Microsoft SQL......................... 18
Online Resources for Program Port Usage ............................................................................................... 20

D EPARTMENTAL F IREWALL G UIDELINES AND P ROCEDURES

I NTRODUCTIO N
This document is intended for a departmental LAN administrator to use in planning a
departmental firewall installation. A departmental firewall is placed between an entire
network segment (for example, all or part of a VLAN) and the rest of the campus network.
This document does not address host-based (individual or personal) firewall programs.
Implementing a firewall has direct implications for many aspects of a departments
computing environment. Before employing a firewall, the departments highest-level
decision makers must understand what those implications are, and will be asked to execute a
memorandum of understanding to that effect. The selection and use of a departmental
firewall are not solely technical decisions.
These guidelines and procedures describe the implications of using a departmental firewall,
typical network architectural alternatives for firewall use, procedures for implementing a
departmental firewall and suggested firewall rules. This document also describes campus
firewall services that are available to departments.

B ENEFITS AND R ISKS OF H AVING A D EPARTMENTAL F IREWALL

Benefits:
Blocks many types of outside attacks from reaching your internal network.
May block many types of malicious attacks from your internal network to the campus
network and/or the Internet community.
Monitors and logs apparent source and origination of such attacks.
Reduces the amount of valuable data lost to assaults.
Reduces the possibility of departmental computers being used as relay points for attacks
on computers outside of the department and outside of the campus.
Reduces the possibility of departmental computers being used as storage points for
unauthorized distribution of copyrighted materials.
Allows for regulation of network traffic between private and public networks.
Risks:
A firewall can be a single point of failure in connectivity between the departmental
computing resources and those outside the firewall.
A firewall can become a performance bottleneck between departmental computing
resources and the outside.
Installing, maintaining, and operating a firewall requires specific technical knowledge
and skill, and may require specialized training.
Firewall operation imposes organizational considerations including after hours support,
vacation coverage, timeliness and priority of response to problems, and change
management.
Administrators can become complacent about system security behind the firewall,
assuming that their network is safe simply by virtue of having the firewall.

D EPARTMENTAL F IREWALL G UIDELINES AND P ROCEDURES

C HOOSING A F IREWALL
There are two basic forms of firewall appliances. The least expensive is based on PC
hardware running a UNIX-like operating system (e.g., Red Hat Linux or OpenBSD)
combined with open source firewall software. This alternative, while low in initial cost,
requires on a fairly high level of expertise and time commitment to build, test, and maintain.
Departments that have in-house technical support staff with the requisite skills and
availability can benefit from open source firewall implementation.
Another approach is to purchase a ready-to-run firewall appliance that consists of
commercial software running on a proprietary hardware platform. This solution offers the
highest level of vendor and warranty support. This alternative is highly beneficial for
departments without in-house technical support, or for whatever reason does not choose the
open source solution. Departments can contract with Desktop Enterprise Solutions to
provide various services associated with the acquisition and maintenance of a commercial
firewall (Email desktop@ucdavis.edu for more information)

P ERFORMANCE AND T OPOLOGY C ONSIDERATIONS

Two important decisions to make when implementing a departmental firewall hardware are
your departments bandwidth/performance requirements and whether an intermediate
separate network segment (typically referred to as a DMZ). is needed
The performance level must be considered carefully because all of the network traffic that
goes beyond the departments local environment will have to pass through the firewall. Two
standard levels of performance are available: 100 megabits per second (Mbps), and 1 gigabit
per second (Gbps). Both of these performance levels are implemented by connecting a
firewall that is located within departmental space to the campus network via standard
horizontal cabling to the nearest wiring closet (IDF). Note that with a gigabit NAM,
performance will not actually reach one gigabit due to limiting factors in the upstream
network. Full gigabit performance can be provided if necessary, but at a higher cost. A
department can request to have the activity on their VLAN monitored to assess the
performance requirements for the firewall. Monitoring should occur during peak traffic
times if there is much variation over the year. This is especially critical if the services
offered on the VLAN have cyclical deadlines or availability windows.
The need for a formal DMZ is determined by considering whether there are substantial
external services provided via public access servers (Web-based applications, ftp services, or
database access, for instance), combined with the need for a maximally secure private
network environment. A DMZ can be established by installing multiple firewalls on your
network, purchasing a firewall appliance with extra physical ports, or by installing extra
network interface cards into a firewall server. The following topology descriptions present
several ways to integrate a departmental firewall into your network.

D EPARTMENTAL F IREWALL G UIDELINES AND P ROCEDURES

A. Simple Firewall
A simple firewall is the most straightforward firewall arrangement. It requires a firewall
appliance with two or more ports (See Figure 1).
The firewall appliance is placed in departmentally controlled space, and requires two or
more NAMs: one representing the public side of the firewall, and the rest representing the
private VLAN side.
The number of NAMs varies according to the number of separate VLANs your
department or departments are using. Each VLAN will need an individual NAM and
physical Ethernet port on the firewall.
Figure 1

UC Davis / Public
Server 1

1U

Server 2

Workstation 1

Workstation 2

Network Switch

Private VLAN NAM 1

Public NAM
Firewall Appliance
(Rules and Polices)

Private VLAN NAM 2,3,4

(If needed)

B. Firewall with DMZ

This arrangement adds the DMZ feature to the simple firewall arrangement. It requires
either a three-port firewall appliance, or two firewall appliances in series (See Figures 2
and 3).
The firewall appliance and servers that are to be in the DMZ are collocated in
departmentally controlled space. This still requires two NAMs: one representing the
public side of the firewall, and one representing the private side. Networking equipment
and wiring to connect departmental equipment to the firewall DMZ port within the DMZ
room is the responsibility of the department.
As with the simple firewall, a firewall with a DMZ can be implemented at either 100
Mbps, or 1 Gbps. One gigabit would be the choice if more than 100 megabits of
throughput is needed. The monthly rate for gigabit service would apply to both NAMs.

D EPARTMENTAL F IREWALL G UIDELINES AND P ROCEDURES

Figure 2

UC Davis / Public
Workstation 1

Workstation 2

Workstation 1

Server 2

1U

Network Switch

Private VLAN Network

Public VLAN NAM
Firewall Appliance
(Rules and Polices)

Private DMZ Network

1U

Network Switch

Server 1

Server 2

Server 1

Server 2

Figure 3

UC Davis / Public
Workstation 1

Internal Firewall Appliance

Workstation 2

Workstation 1

Server 2

1U

Network Switch

Private VLAN Network

1U

Network Switch

Public VLAN NAM

Private DMZ Network

External Firewall Appliance

1U

Server 1

Network Switch

Server 2

Server 1

Server 2

D EPARTMENTAL F IREWALL G UIDELINES AND P ROCEDURES

D ETERMINE THE L OCATION FOR THE F IREWALL
The optimum location for a departmental firewall is physically secure and has adequate
power conditioning and temperature control. For departments maintaining independent
firewall devices, such firewalls may best be collocated with departmental servers.
Departmental firewalls may not be placed in network wiring closets.

C OST C OMPONENTS
The basic cost elements involved in setting up a firewall are:
The firewall itself: Firewall appliances vary widely in cost. At the low end, an Open Source
product on a PC platform may cost as little as $1,000. Commercial firewall appliances offer
midrange ($2,500 to $5,000) solutions for average traffic levels. At the high end, a
commercial firewall appliance is likely to cost much more. Be sure to include recurring
hardware and software maintenance costs in planning for the firewall life cycle. The campus
has a blanket agreement for purchasing Netscreen firewall appliances.
Horizontal wiring and NAM activation: At least two NAMs, both either 100 Mbps or 1 Gbps,
will be needed for a simple firewall topology. If the selected physical location already has
enough unused NAMs for the installation, the only costs for the physical connectivity will be
activation and monthly fees. The standard rates apply to the installation of NAMs and ports
for firewall use. Horizontal wiring installation costs about $460 per NAM, where needed,
plus access and activation fees that are based on the connection speed (see
http://cr.ucdavis.edu/rates/rates.cfm for current rates).

M EMORANDUM OF U NDERSTANDING FOR D EPARTMENTAL F IREWALLS

All campus units that deploy network firewalls should complete and submit a firewall
Memorandum of Understanding (MOU) (Attachment 1). Communications Resources (CR)
is responsible for the security of the campus network. When a security issue arises from a
network port, CR staff may be forced to shut down the port to protect the rest of the network;
if the port is connected to an unregistered firewall, all of the systems behind the firewall lose
their network connectivity without notice. In order to inform CR of the existence of your
firewall and prevent possible catastrophic connectivity loss, execute the firewall MOU
between your Dean, Vice Chancellor, or Vice Provost and the Vice Provost, Information and
Educational Technology. This agreement ensures the campus unit and IET organization
understand their respective responsibilities with regard to firewall use, and provides a
mechanism for contacting the departmental LAN administrator in case of a network
emergency. A copy of the approved MOU will be forwarded by the Vice Provost,
Information and Educational Technology to Communications Resources (CR).

D EPARTMENTAL F IREWALL G UIDELINES AND P ROCEDURES

C OORDINATE THE I NSTALLATION
After you complete and submit the firewall MOU, these steps remain:
Submit a Departmental Firewall Configuration Registration Form, located at
http://security.ucdavis.edu/firewall_form.cfm. This creates a record of the specific
address range of the campus network that is behind your firewall.
Order/build the firewall. Order this well in advance. The purchase lead-time will vary
based on Material Managements workload and vendor responsiveness. It is not
uncommon for this step to take one or two months. Ordering from the campus
blanket agreement may reduce your waiting time.
Receive the firewall appliance, if it is purchased.
Set up the hardware, create the policy rule sets, and test the firewall.
Train department staff for firewall support.
Coordinate the cutover with the NOC.

C ONSULTATION WITH D ESKTOP E NTERPRISE S OLUTIO NS (DES)

(O P TIO N AL )
DES offers support services for the implementation of departmental firewalls. These
services are billed to you through DES at the rate of $72 dollars an hour.
For more information about the DES group please visit http://desktop.ucdavis.edu
On an hourly basis, DES consultants can work with the department to:
Determine best physical location for the firewall.
Assess need for horizontal cabling and/or NAM installation and activation
Arrange for traffic level monitoring to determine appropriate performance level for
the firewall
Coordinate with the NOC for wiring and NAM work, and for cutover
Other services that DES group offers are Managed turnkey and Equipment sparing
services. The Managed Turnkey service benefits departments that have little to no IT staff
on hand. DES takes care of care of everything that is related to the firewall implementation
and support. The Equipment Sparing service allows a department that is managing a
Netscreen firewall to have access to a spare in case of hardware failure. The DES group can
have a spare firewall to your department within four hours. More information about the
firewall services offered by Desktop Enterprise Solutions can be found at
http://desktop.ucdavis.edu/fw_options.html
Campus units should be aware that factors such as external mandates for firewall use, current
NOC priorities, and network performance issues will affect both CR and DESs priority and
delivery of department firewall implementation support. If the campus unit needs additional
NAM installations, the lead-time is typically ten working days and longer if conduit or
asbestos cleanup is needed.

D EPARTMENTAL F IREWALL G UIDELINES AND P ROCEDURES

A DDITIONAL R ESOURCES
Firewalls and Internet Security: Repelling the Wily Hacker, William R. Cheswick
and Steven M. Bellovin, Second Edition, February 2003
Internet Firewalls: Frequently Asked Questions, Matt Curtin and Marcus J. Ranum,
December 2000, http://www.ranum.com/pubs/fwfaq/
Inside Network Perimeter Security: The Definitive Guide to Firewalls, Virtual Private
Networks (VPNs), Routers, and Intrusion Detection Systems, Stephen Northcutt,
Lenny Zeltser, Scott Winters, Karen Fredrick, Ronald W. Ritchey, Que, 1st edition
(June 28, 2002).
Building Internet Firewalls, 2nd Edition, Elizabeth D. Zwicky, Simon Cooper, and D.
Brent Chapman, O'Reilly & Associates, Inc.June 2000
Firewall Mailing List, http://www.isc.org/services/public/lists/firewalls.html
Online Firewall Buyers Guide, ICSA Labs, TruSecure Corporation,
http://www.icsalabs.com/html/communities/firewalls/buyers_guide/index.shtml
Juniper Network Solutions, http://www.juniper.net
UC Davis Security Group, http://security.ucdavis.edu
OpenBSD firewall resources http://insecure.ucdavis.edu/OpenBSD (developed &
maintained by Adam Getchell)

D EPARTMENTAL F IREWALL G UIDELINES AND P ROCEDURES

A TTACHMENT 1: M EMORANDUM OF U NDERSTANDING (MOU)

R EGARDING THE U SE OF D EPARTMENTAL N ETWORK F IREWALLS
Employing a departmental network firewall offers supplemental security to departmental
computing resources and data repositories. The use of a departmental network firewall
complements but does not replace rigorous maintenance and security practices on departmental
computers by the campus unit technical staff. In addition, the use of a departmental network
firewall imposes a set of responsibilities and risks to the departmental computing environment.
Proper and complete preparation for implementing a firewall, along with rigorous and timely
configuration and maintenance of the firewall device mitigate many of the risks inherent in the
application of a firewall device. Other risks are, to a large degree, unavoidable. The department
must acknowledge and accept those risks before proceeding with the use of a firewall.
The department must accept the ultimate responsibility for the use of a firewall, the selection of
the firewall itself, and the operation and maintenance of the firewall. Desktop Enterprise
Solutions is available to assist departments when possible, on a recharge basis.
Specific technical issues are addressed in this memorandum of understanding.

10

D EPARTMENTAL F IREWALL G UIDELINES AND P ROCEDURES

(This page intentionally blank)

11

D EPARTMENTAL F IREWALL G UIDELINES AND P ROCEDURES

R E G A RD IN G

M EM O RAN DUM O F U N D ER S TA ND IN G
TH E U S E O F D EP AR TM E N TA L N ET WO RK F IR E W AL L S

Single Point of Failure

A departmental firewall, by nature, stands between departmental resources and the rest of the campus
network and the Internet in general. This creates a single point of failure for departmental computer
connectivity. Should the firewall become inoperative for any reason, all connectivity between the
departments computers and external resources will be lost until the firewall is restored to proper
functionality or the firewall is bypassed. It is the departments responsibility to have a spare firewall unit
or adequate components on hand to affect timely repair. An entire configured spare unit is strongly
recommended.
Firewall Performance
A network firewall is uniquely positioned in a departmental network to become a serious impediment to
performance. Ensuring the firewall has adequate performance capacity is solely the departments
responsibility. Desktop Enterprise Solutions (DES) is available to assist in ascertaining the level of
performance needed, on a recharge basis.
Rule Sets
The department is solely responsible for the accuracy, functionality, and security provided by the rule set
that is implemented via the departmental firewall. There are basic suggested rule sets available, but these
suggested rule sets must be customized to meet the departments specific needs. It is strongly
recommended that departments put operational procedures in place to ensure a backup copy of both the
current and the next most recent rule sets are available for emergency restoration purposes.
Maintenance and Upgrades
Firewall devices must be maintained at the most current revision in order to be effective. This is true to a
much higher degree than with most other computing resources. The department is solely responsible for
maintaining and upgrading the firewall hardware, software, and configuration.
Network Operations Center (NOC) Response Times for Trouble Assistance and Emergency
Reconfiguration of the Campus Network
DES will provide assistance to campus units who have engaged their services in troubleshooting
problems with a firewall, and will act as their agent when working with the NOC to troubleshoot
problems. Those who do not engage DES services will need to consult with the NOC directly. Any time
the NOCs resources are employed, whether directly, or through DES, the ability to provide
troubleshooting service is balanced against campus operational needs such as response to network
outages. In an emergency, it may be possible to reconfigure the campus network to bypass the firewall.
The NOC is not responsible for any security issues raised by an emergency bypass of the firewall. This
bypass may not be possible during normal business hours without placing other departments
connectivity at risk. Therefore, whether to do so will be at the NOCs discretion consultation with DES
or the customer as appropriate. The NOC staff will make their best effort to respond to notification of a
problem within 30 minutes during normal business hours, and one hour outside of normal business hours.
The complexity of the firewall environment will affect service restoration. Troubleshooting and
emergency reconfiguration services will be recharged on a time and materials basis. Wherever possible,
non-emergency requests should be requested at least 24 hours in advance.

12

D EPARTMENTAL F IREWALL G UIDELINES AND P ROCEDURES

Vulnerability Identification
Periodically, the campus may conduct scans of the campus network to identify insecure computers that
could negatively affect the availability of network services or integrity of other computers. Department
firewalls may prevent campus scanning tools from inspecting computers protected by the firewall. In
such cases, campus units must specifically permit the campus scanning utilities to pass through the
department firewall or assume the responsibility for identifying vulnerable or compromised computers.
Unrestricted hostile network traffic emanating from a firewall protected network could lead the NOC to
take protective actions, up to and including disconnection of the department firewall from the UC Davis
network. In such an extreme case, all department devices protected by the firewall will lose network
connectivity until the problem is resolved.
Communication
Departmental end users are expected, if DES services have been engaged, to communicate with DES via
the departmental LAN administrator. Individual end users that report trouble directly will be referred to
the Departmental LAN Administrator. Departments are expected to make this policy known to their end
users.
The department is expected to have a primary and backup contact within the department for trouble
referrals and for other communications regarding firewall implementation. It is preferred that those
contacts be available after hours; otherwise situations may require the departmental network be shut off
from outside connectivity for the sake of preserving campus network integrity. NOC staff will make
their best effort to contact both the designated people before proceeding with an emergency port
shutdown. CR is not responsible for enabling the firewall service should the department support contacts
be inaccessible. Please designate your primary and backup contacts below.

_________________________________
Primary Contact Name

__________
Phone

__________________________
Email

_________________________________
Backup Contact Name

__________
Phone

__________________________
Email

Approved by:
__________________________________

________________________________

Department Chairperson or Unit Director

Date

__________________________________
Requesting Campus Organization

__________________________________

_______________________________

Dean/Vice Chancellor/Vice Provost

__________________________________

Date

________________________________

Vice Provost
Information and Educational Technology

Date

13

D EPARTMENTAL F IREWALL G UIDELINES AND P ROCEDURES

A TTACHMENT 2: D EPARTMENTAL F IREWALL R ULE S ETS
Assumptions: A stateful firewall will be used to protect an entire VLAN. Firewall logs will be
reviewed on a regular basis to identify security issues and configuration adjustments. The campus
units LAN administrator has scanned the VLAN to identify existing services that need to be
considered during firewall configuration and that require firewall rules in addition to the base rules
stated below.
General Firewall Policy: Deny all inbound traffic unless explicitly authorized. Traffic from internal
VLAN users is generally unrestricted. All deny rules are logged.

S UGGESTED B ASE R ULES

Deny all inbound traffic with network addresses matching internal VLAN addresses Inbound
traffic should not originate from network addresses matching internal VLAN addresses.
Normalize all inbound and outbound traffic (e.g., scrub in all) This rule will ensure inbound and
outbound traffic is defragmented.
Allow ICMP packets from any external address This rule permits acceptance of network
maintenance traffic (Destination Unreachable, Echo and Time Exceeded) from any external address.
The rule could be abused if the VLAN is sent excessive amounts of ICMP traffic. Under such
circumstances, more restrictive controls should be considered. Further isolation could be achieved
by limiting this traffic to only campus network addresses or from the campus Network Operations
Center for diagnostic purposes. Alternatively, some firewall implementations allow for throttling of
ICMP traffic, which is an effective way of allowing ICMP control communication but discouraging
excessive use of ICMP. Throttling traffic levels may be preferable to defining specific firewall rules
for ICMP functions.
Allow RIP UDP traffic from router to VLAN hosts This rule should only be used if the
department has hosts that require default route advertisements.

S UGGESTED O PTIONAL R ULES

The following rules are offered as a guide and should only be considered by units that offer the
particular services on the protected VLAN. Management and support staff must evaluate the use of
the following firewall rules and determine whether the rule imposes a serious risk to the security of
the protected resources behind the firewall.
Additional security measures must be used for resources shared through the firewall to ensure only
authorized access and use. These additional measures include account management, regular
operating system and application maintenance, removal of unnecessary services/processes, access
control measures, and activation/inspection of event logs (Reference: SANS Step-by-Step Guides).
Cyber-Safety Requires: All campus devices must use encrypted authentication mechanisms unless
an exception has been approved by a senior administrative official. Unencrypted authentication
14

D EPARTMENTAL F IREWALL G UIDELINES AND P ROCEDURES

mechanisms are only as secure as the network upon which they are used. Any network traffic may be
surreptitiously monitored, rendering unencrypted authentication mechanisms vulnerable to
compromise.
More Information on Cyber-Safety can be found at http://security.ucdavis.edu/cybersafety.cfm.
Allow Web traffic (TCP 80/443) from any external address to internal Web server Permits
access to the specific IP address(es) of internal Web servers via HTTP and HTTPS. Additional
security measures must be considered for Web servers as many security exploits use TCP port 80.
Allow traffic (TCP 21) to internal FTP server If FTP services are provided to external users, this
rule permits access to the FTP server. As a reminder, when using FTP services, user account and
password information is transmitted in clear text. Use of passive FTP (PASV) will negotiate a
random data port versus use of TCP port 20. Please refer the above Cyber-Safety requirement.
Allow traffic (TCP 22) to internal SSH/SFTP server Use of encrypted SSH is preferred over
insecure FTP/Telnet services. This rule permits use of SSH to access internal SSH hosts.
Allow traffic (TCP 25) to internal SMTP server Permits external SMTP users and servers access
to internal SMTP mail server. This rule presumes the campus unit is operating an SMTP server.
Allow DNS (UDP 53) to internal DNS server If the unit runs internal DNS servers this rule is
recommended. The rule is needed if a Windows Active Directory server is hosted on the internal
network. TCP 53 must be permitted for zone transfer capability. However, this permission should
not be applied by default.
Allow traffic (UDP 67/68) for client access to DHCP server This rule permits DHCP clients to
negotiate a lease with DHCP server.
Allow traffic (TCP 110) to internal POP server Permits external POP users access to the internal
POP server. This rule presumes the campus unit is operating a POP server. It is strongly
recommended that POP authentication traffic be conducted over a secure transport, such as TLS/SSL
(TCP 995). Please refer the above Cyber-Safety requirement.
Allow NTP traffic (TCP 123) to specific internal host address(es) This rule permits time
synchronization which may be needed by selected internal hosts. This rule is also required to
support external client authentication to the internal Active Directory services.
Allow traffic (TCP 143) to internal IMAP server This rule permits external IMAP clients to
access an internal IMAP server. It is strongly recommended that IMAP authentication traffic be
conducted over a secure transport, such as TLS/SSL (TCP 993). Please refer the above Cyber-Safety
requirement.
Allow inbound traffic (TCP 515 from 169.237.104.59 and 169.237.104.65) for BANNER
spooler/printing to specific internal printer address This rule permits transcript printing.

15

D EPARTMENTAL F IREWALL G UIDELINES AND P ROCEDURES

Allow inbound traffic (TCP 515 & 9100 from 128.48.175.6, 128.48.96.57, 128.48.96.51) for PPS
spooler/printing to specific internal network printer address This rule will permit printing
payroll/personnel reports. If the unit uses Remote Printer Manager (PC) or Intersolv (Mac) for PPS
printing to a non-network printer, the firewall rule must permit TCP515 traffic to the host with the
direct connected printer.
Allow access to MS SQL Server (TCP/UDP 1433 and 1434) to specific host address This rule
permits inbound traffic to communicate with an MS SQL Server residing on the protected VLAN.
Allow access to Microsoft Resources Consult Microsofts TechNet and Knowledge Base resources
to verify firewall configuration requirements for Microsoft Exchange, Microsoft SQL Server, and
shared Microsoft network resources. Some firewall rules are determined by version. Shared
resources must be properly secured or the VLAN hosts could be vulnerable to security compromises.
See References section for additional information.
Allow traffic (TCP/UDP 135, 137, 138 139/445) for external access to specific shared resources
This rule permits external clients to access shared Microsoft resources behind the firewall. Filters at
the campus network border, between the residential computing network and the campus network,
modem pools and wireless network prevent inbound and outbound netbios traffic.
Allow access (TCP 4899) to specific internal hosts using Famatech RADMIN remote
administration application This rule permits external administrators to communicate with hosts
running the RADMIN utility.
Allow access (TCP 5641 and UDP 5642) from external clients running pcAnywhere to specific
host addresses This rule permits remote control of computing hosts behind the firewall using
Symantecs PCAnywhere product.
Increase UDP timeout from default 2 minutes to 45 minutes This rule is suggested to bypass AFS
time restrictions.

E GRESS F ILTERING
One area of Cyber Security compliance that is difficult to define and implement is egress
filtering. We are working with the campus community to define and refine this issue further, but
for now here are a few guidelines, that can be easily integrated into your existing firewall.
Only allow source addresses from the IP network numbers you assign to trusted segments
behind your firewall(s), including DMZ networks. This includes primary and secondary
network numbers, and subnets that are routed to the Internet through your firewall
(including addresses reserved for VPN clients).
Apply appropriate subnet masks to trusted networks, i.e., masks that are sufficiently long
to identify only that fragment of the IP network number that you are using. For example, if
you are using an RFC 1918 Private Address from the Class B number 172.16.0.0, and only
assigning numbers from 172.16.1.x, use 255.255.255.0 (or /24), not 255.255.0.0 (or /16) as
your subnet mask.
16

D EPARTMENTAL F IREWALL G UIDELINES AND P ROCEDURES

Block broadcasts from traversing the firewall's interfaces. While most broadcasts will not
pass across LAN segments, take measures to ensure this is especially true for Internetbound packets - or packets destined for any untrusted segment.
Prevent traffic from any RFC 1918 private addresses from being forwarded over your
Internet access circuit. While ISPs block incoming traffic containing private addresses,
you're forcing your ISP to process traffic you ought to block
Block outbound traffic from VLAN workgroups or entire network segments that have no
business establishing client connections to Internet servers.
If you have internal servers that have no business establishing client connections to
Internet servers, block all outbound traffic from such systems. An example might be an
intranet server that relies entirely on internally provided services (DNS, mail, time, etc.)
and uses no applications that require Internet access.
Additional Resources:

VLAN Routing Firewall Rules: http://insecure.ucdavis.edu/openbsd/vlan-routing-firewallrules/

General Egress information: http://hhi.corecom.com/egresstrafficfiltering.htm

17

D EPARTMENTAL F IREWALL G UIDELINES AND P ROCEDURES

A TTACHMENT 3: S TANDARD P ORTS

C OMMON UC D AVIS N ETWORK S ERVICES & A SSOCIATED P ORTS
Ports

Application

IP Addresses / Hosts of Inbound Traffic

TCP 515

BANNER spooler/printing

169.237.104.59; 169.237.104.65

TCP 515; TCP 9100

PPS Printing

128.48.175.6; 128.48.96.57; 128.48.96.51

UDP 7001

AFS Client

TCP 139

AFS Proxy

afs1.ucdavis.edu; afs2.ucdavis.edu;
afs3.ucdavis.edu; afs4.ucdavis.edu
sydney.ucdavis.edu; sarajevo.ucdavis.edu

TCP 1521

Database Servers

fis-tp.ucdavis.edu; fis-test.ucdavis.edu

TCP 1522

Oracle Name Resolution

oranames1.ucdavis.edu; oranames2.ucdavis.edu

TCP 7166; TCP 32774

Uniface License Monitor

unfclic1.ucdavis.edu; unfclic2.ucdavis.edu;
unfclic3.ucdavis.edu

DaFIS Related Ports

P O R TS R E LA T E D

TO

M IC RO S O F T A C T IV E D I R EC TO RY , M I C RO S O F T E X CH A N G E ,
AN D M I CRO SO F T SQL

Ports

Microsoft Active Directory Server

135 tcp/udp

Remote Procedure Call (RPC) Endpoint Mapper

137 tcp/udp

NetBIOS Name Service

138 udp

NetBIOS Datagram Service

139 tcp

NetBIOS Session Service

1024 65535 tcp

RPC Dynamic Assignment

445 tcp/udp

Server Message Block (SMB) over IP (Microsoft DS)

389 tcp

Lightweight Directory Access Protocol (LDAP)

389 udp

LDAP ping

636 tcp

LDAP over SSL

3268 tcp

Global Catalog LDAP

3269 tcp

Global Catalog LDAP over SSL

88 tcp/udp

Kerberos

53 tcp/udp

Domain Name Service

1512 tcp/udp

Windows Internet Naming Service (WINS) Resolution

42 tcp/udp

WINS Replication

Ports

Microsoft SQL Server

1433 tcp/udp

Microsoft SQL Server

1434 tcp/udp

Microsoft SQL Monitor

18

D EPARTMENTAL F IREWALL G UIDELINES AND P ROCEDURES

Ports

Microsoft Exchange Server

135 139 tcp/udp

Microsoft Exchange System Attendant

25 tcp

Simple Mail Transfer Protocol (SMTP)

691 tcp

Microsoft Exchange Routing Engine

80 & 443 (SSL) tcp

World Wide Web Publishing Service (IIS Admin Service)

2883 udp

Microsoft Exchange Active Sync (IIS Admin Service)

110 & 995 (SSL) tcp

Microsoft Exchange POP3 (IIS Admin Service)

143 & 993 (SSL) tcp

Microsoft Exchange IMAP4 (IIS Admin Service)

119 & 563 (SSL) tcp

Network News Transfer Protocol (NNTP) (IIS Admin Service)

379 & 389 tcp

Microsoft Active Directory Connector

C OMMON N ETWO RK S ERVICES & A SSOCIATED P ORTS

Ports

Applications

21/TCP,UDP
22/TCP,UDP

FTP - control (command) port

SSH (Secure Shell) - used for secure logins, file transfers (scp, sftp) and port
forwarding

23/TCP,UDP

Telnet protocol - unencrypted text communications

25/TCP,UDP

SMTP - used for sending E-mails

37/TCP,UDP

TIME protocol

53/TCP,UDP

DNS (Domain Name Server)

80/TCP

HTTP (HyperText Transfer Protocol) - used for transferring web pages

88/TCP

Kerberos - authenticating agent

110/TCP
119/TCP

POP3 (Post Office Protocol version 3) - used for retrieving E-mails

NNTP (Network News Transfer Protocol) - used for retrieving newsgroups
messages

123/UDP

NTP (Network Time Protocol) - used for time synchronization

137/TCP,UDP

NetBIOS NetBIOS Name Service

138/TCP,UDP

NetBIOS NetBIOS Datagram Service

139/TCP,UDP

NetBIOS NetBIOS Session Service

143/TCP,UDP

IMAP4 (Internet Message Access Protocol 4) - used for retrieving E-mails

161/TCP,UDP

SNMP (Simple Network Management Protocol)

194/TCP

IRC (Internet Relay Chat)

201/TCP,UDP

AppleTalk Routing Maintenance

389/TCP,UDP

LDAP (Lightweight Directory Access Protocol)

401/TCP,UDP

UPS Uninterruptible Power Supply

443/TCP,UDP

HTTPS - HTTP Protocol over TLS/SSL (encrypted transmission)

Microsoft-DS (Active Directory, Windows shares, Sasser-worm, Agobot,
Zobotworm)

445/TCP

19

D EPARTMENTAL F IREWALL G UIDELINES AND P ROCEDURES

445/UDP

Microsoft-DS SMB file sharing

464/TCP,UDP

Kerberos Change/Set password

500/TCP,UDP

Isakmp, IKE-Internet Key Exchange

515/TCP

LPD Printer protocol - used in LPD printer servers

691/TCP

MS Exchange Routing

989/TCP,UDP

FTP Protocol ( data) over TLS/SSL

990/TCP,UDP

FTP Protocol (control) over TLS/SSL

992/TCP,UDP

Telnet protocol over TLS/SSL

993/TCP

IMAP4 over SSL (encrypted transmission)

995/TCP

POP3 over SSL (encrypted transmission)

1194/udp

OpenVPN

1214/tcp

Kazaa

1352/tcp

IBM Lotus Notes/Domino RPC

1433/tcp

Microsoft SQL database system

1434/tcp,udp

Microsoft SQL Monitor

1494/tcp

Citrix MetaFrame ICA Client

1723/tcp

Microsoft PPTP VPN

1723/udp

Microsoft PPTP VPN

1863/tcp

MSN Messenger

2967/udp

Symantec AntiVirus Corporate Edition

3306/tcp
3389/tcp

MySQL Database system

Microsoft Terminal Server (RDP) officially registered as Windows Based Terminal
(WBT)

5003/tcp

Filemaker Filemaker Pro

5190/tcp

AOL and AOL Instant Messenger

O NLINE R ESOURCES FOR P RO GRAM P ORT U SAGE

http://www.iana.org/assignments/port-numbers
http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
http://www.neohapsis.com/neolabs/neo-ports/neo-ports.html

20