DEPARTMENTAL FIREWALL GUIDELINES AND PROCEDURES

University of California, Davis

DEPARTMENTAL FIREWALL GUIDELINES AND PROCEDURES

2

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

DEPARTMENTAL FIREWALL GUIDELINES AND PROCEDURES

3

INTRODUCTION

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 department’s

computing environment. Before employing a firewall, the department’s 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.

BENEFITS AND RISKS OF HAVING A DEPARTMENTAL FIREWALL

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.

DEPARTMENTAL FIREWALL GUIDELINES AND PROCEDURES

4

CHOOSING A FIREWALL

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)

PERFORMANCE AND TOPOLOGY CONSIDERATIONS

Two important decisions to make when implementing a departmental firewall hardware are

your department’s 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 department’s 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.

DEPARTMENTAL FIREWALL GUIDELINES AND PROCEDURES

5

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

Firewall Appliance

(Rules and Polices)

Public NAMPrivate VLAN NAM 1

Private VLAN NAM 2,3,4

(If needed)

Workstation 1 Workstation 2Server 1 Server 2

1 U Network Switch

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.

DEPARTMENTAL FIREWALL GUIDELINES AND PROCEDURES

6

Figure 2

UC Davis / Public

Firewall Appliance

(Rules and Polices)

Public VLAN NAMPrivate VLAN Network

Private DMZ Network

Workstation 1

1 U Network Switch

1 U Network Switch

Server 1 Server 2 Server 1 Server 2

Workstation 1 Workstation 2 Server 2

Figure 3

UC Davis / Public

External Firewall Appliance

Public VLAN NAM

Private VLAN Network

Private DMZ Network

Workstation 1

1 U Network Switch

1 U Network Switch

Server 1 Server 2 Server 1 Server 2

Workstation 1 Workstation 2 Server 2

Internal Firewall Appliance

1 U Network Switch

DEPARTMENTAL FIREWALL GUIDELINES AND PROCEDURES

7

DETERMINE THE LOCATION FOR THE FIREWALL

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.

COST COMPONENTS

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).

MEMORANDUM OF UNDERSTANDING FOR DEPARTMENTAL FIREWALLS

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).

DEPARTMENTAL FIREWALL GUIDELINES AND PROCEDURES

8

COORDINATE THE INSTALLATION

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 Management’s 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.

CONSULTATION WITH DESKTOP ENTERPRISE SOLUTIONS (DES) (OPTIONAL)

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 DES’s 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.

DEPARTMENTAL FIREWALL GUIDELINES AND PROCEDURES

9

ADDITIONAL RESOURCES

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)

DEPARTMENTAL FIREWALL GUIDELINES AND PROCEDURES

10

ATTACHMENT 1: MEMORANDUM OF UNDERSTANDING (MOU)

REGARDING THE USE OF DEPARTMENTAL NETWORK FIREWALLS

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.

DEPARTMENTAL FIREWALL GUIDELINES AND PROCEDURES

11

(This page intentionally blank)

DEPARTMENTAL FIREWALL GUIDELINES AND PROCEDURES

12

MEMORANDUM OF UNDERSTANDING

REGARDING THE USE OF DEPARTMENTAL NETWORK FIREWALLS

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

department’s computers and external resources will be lost until the firewall is restored to proper

functionality or the firewall is bypassed. It is the department’s 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 department’s

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 department’s 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 NOC’s 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 NOC’s 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.

DEPARTMENTAL FIREWALL GUIDELINES AND PROCEDURES

13

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 Date

Information and Educational Technology

DEPARTMENTAL FIREWALL GUIDELINES AND PROCEDURES

14

ATTACHMENT 2: DEPARTMENTAL FIREWALL RULE SETS

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

unit’s 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.

SUGGESTED BASE RULES

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.

SUGGESTED OPTIONAL RULES

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

DEPARTMENTAL FIREWALL GUIDELINES AND PROCEDURES

15

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.

DEPARTMENTAL FIREWALL GUIDELINES AND PROCEDURES

16

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 Microsoft’s 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

Symantec’s PCAnywhere product.

Increase UDP timeout from default 2 minutes to 45 minutes – This rule is suggested to bypass AFS

time restrictions.

EGRESS FILTERING

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.

DEPARTMENTAL FIREWALL GUIDELINES AND PROCEDURES

17

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 Internet-

bound 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-firewall-

rules/

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

DEPARTMENTAL FIREWALL GUIDELINES AND PROCEDURES

18

ATTACHMENT 3: STANDARD PORTS

COMMON UC DAVIS NETWORK SERVICES & ASSOCIATED PORTS

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

DaFIS Related Ports

UDP 7001 AFS Client afs1.ucdavis.edu; afs2.ucdavis.edu; afs3.ucdavis.edu; afs4.ucdavis.edu

TCP 139 AFS Proxy 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

PORTS RELATED TO MICROSOFT ACTIVE DIRECTORY , MICROSOFT EXCHANGE ,

AND MICROSOFT 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

DEPARTMENTAL FIREWALL GUIDELINES AND PROCEDURES

19

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

COMMON NETWORK SERVICES & ASSOCIATED PORTS

Ports Applications

21/TCP,UDP FTP - control (command) port

22/TCP,UDP 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 POP3 (Post Office Protocol version 3) - used for retrieving E-mails

119/TCP 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)

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

DEPARTMENTAL FIREWALL GUIDELINES AND PROCEDURES

20

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 MySQL Database system

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

5003/tcp Filemaker Filemaker Pro

5190/tcp AOL and AOL Instant Messenger

ONLINE RESOURCES FOR PROGRAM PORT USAGE

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