Skip to the content of the web site.

Required Services (by) Firewall Working Group

2004/11/01 - 2005/02/15

Security >> Security Working Group >> Firewall Working Group >> Requirements >> Services

Objectives

Our objective is to block ingress routing of all network services/protocols except for those that are required -- the problem therefore is to document services that are required. That is an on-going shared collaborative effort. Here we document the services/protocols that are required -- they should be passed through the campus firewall. This is an on-going effort as requirements will change over time. That change however is incremental and can be managed.

Required Services

There are some services that are clearly required by many systems. There should be no debate about these:

  1. Web servers are found at the "http" (80/tcp) and "https" (443/tcp) ports.
  2. Email services are found a the "smtp" (25/tcp), "smtps" (465/tcp), "submission" (587/tcp), "imap" (143/tcp), "imaps" (993/tcp), "pop3" (110/tcp) and "pop3s" (995/tcp) ports.
  3. For remote system management we require "ssh" (22/tcp) for Unix systems and "ms-rdp" (3389/tcp) for Windows systems.
  4. For interactive key-board login we have users of "telnet" (23/tcp) and "login" (513/tcp) (to mostly Unix machines) but increasingly users are migrating to "ssh" -- at some later date we might be able to move everyone to "ssh" and eliminate these.
  5. For remote file manipulation we still have users of "ftp" (21/tcp) but "ssh" and "ms-rdp" work very well. The "ssh" drag and drop explorer is very nice. And many users of the UW portal rely on that instead (it builds on "ftp" within campus). See notes below on ftp -- it is a problem. At some later date we might be able to eliminate "ftp" -- for the moment it's required.
  6. The "auth" service at 113/tcp -- this is the identd to answer the question "who is that talking to me on port x?". IRC clients often have this but our experience on Resnet suggests that it is not really required.

We are worried about clear text protocols like imap, telnet, ftp, etc. but believe some are required (at least for a while).

We understand that certain routing protocols are required (Doug Payne can advise us) but these would be targetted to a very few systems.

You will note we've focussed on TCP services. For UDP services there are very few on-campus UDP servers used by off campus systems (other than the DNS and perhaps NTP). Cisco reflexive access lists might be the "right" solution if we can't enumerate the "required" services. With Cisco "reflexive access lists" we can allow any UDP traffic that is the result of something locally initiated. But there's a performance hit with dynamic ACL's.

UDP based games, especially on resnet, are problematic -- they often have very intensive netflows and they're never (seldom) required of the University mission. It's not unusual to see one gamer with 5,000 or more UDP netflows (the gateway router only holds 64K netflows).

For ICMP services (there really are very few) we rely on the advice of Doug Payne.

There may be other service ports we've not thought of that you might require -- please let us know so we can update this list.

Notable Additions

There are some notable exceptions. Often these are exceptions that would require, nevertheless, some limits on who could approach the open service.
  1. For the DNS service we require "domain" on ports 53/tcp and 53/udp -- but there are only a very few DNS servers on campus advertised to the world.
  2. The Network Time Protcol "ntp" at 123/udp is required but again only from a very few designated time servers.
  3. For Virtual Private Networking (VPN) we require:
    • For IPSec/VPN traffic through a firewall you require Internet Key Exchange IKE (500/udp) [See RFC 2401]. Required for Mike Herz (and no doubt others in time).
    • For the Point to Point Tunneling Protocol (pptp) we require (1723/tcp,udp). This is the Microsoft VPN implementation. Required by Dennis Herman (and no doubt by others in time).
    The working group has not found a requirement for a general campus wide VPN service.
  4. The Internet Printing Protocl (ipp is 631 tcp/udp) may be required. While we have not seen any netflow data to support this as a requirement we are advised by Marko Dumancic that Environmental Studies uses IPP to provide print services to laptops on and off campus. Mike Patterson of CSCF advises us that this will be required by the School of Computer Science.
  5. For the Usenet news service we require "nntp" (119/tcp) to one machine but there's not much off campus access. We aren't offering "nntps" (563/tcp) or authenticated "nntp". SSH tunneling is an attractive method for providing off-campus access -- see Windows: SSH Tunneling.
  6. We know of some web servers at http-alt(8008/tcp) [e.g. Bill Baer for "esqcamps"]. We're also aware that many sites erect alternate web servers at arbitrary ports and know this will cause problems.
  7. Port 5800/tcp from 2 IP addresses to one server in Civil Engineering for a proprietary application used by a research group (see Mike Herz). More details required.
  8. The Voyager application as used by the Tri-University Group (Waterloo, Guelph and Laurier) exposes several services that need to be available to support staff at the three sites: 
    Pcatsvr         7010/tcp   # Cataloging Server
Pacqsvr         7020/tcp   # Acquisitions Server
Pcircsvr        7030/tcp   # Circulation Server
Prptsvr         7040/tcp   # Reporting Server
Psysadminsvr    7050/tcp   # System Administration Server
Pz3950svr       7090/tcp   # Z39.50 Server
Pzrouter        7091/tcp   # Z39.50 Client Router
Pselfchk        7092/tcp   # Self Check (3M/Checkpoint) Server
UGschk          7093/tcp   # SelfCheck UG
WLUschk         7094/tcp   # SelfCheck WLU
    For more information see Charles Woods.
  9. The Library has a MS/SQL database on port 1433/tcp that is accessed by the Tri-University group. It also has local IPSec firewall rules to protect it from attack by others. See William Oldfield.
  10. Nortel's "Softphone" uses 5000/udp (as client and server) for Voice over IP. It's not clear if this is a wide-area protocol we should accept or if VPN would handle it better.
  11. We've bumped into a few machines where firewalling won't work at all -- they require too many ports at odd locations.
    • Science has a couple of Video over/IP devices for classes shared between here and Guelph. We understand that all ports need to be exposed (or at least all ephemeral ports, it's not clear if UDP/TCP and ICMP are required). There are several of these around campus.
    • Computer Science has a couple of systems involved in the "Planetmesh" project (blast and cloudburst). Documentation for the project says servers should be located outside the firewall (as they require a great many services and security alarms will ring for intensive netflows).
  12. Mike Herz has "subversion" a CVSup like application at ports 3690 tcp/udp on a single server -- we're not aware of any others (REQ -- Are both UDP and TCP services required? Where's the server?)
  13. Paul Martin of Engineering/Management Sciences gave these requirements for the "MOT@distance Online Master's Program":
    • motd.uwaterloo.ca - 129.97.25.153 - main website - port 80 (http), 22 (ssh)
    • motdtutor.uwaterloo.ca - 129.97.25.175 - Motonline mail server - ports 80 (http), 8080 (???), 22 (ssh), 25 (smtp), 143 (imap)
    • mscimedia1.uwaterloo.ca - 129.97.25.27 - Chat and Real Player media server - Ports 80 (http), 8080 (???), 4040 (???), 5050 (???), 7070 (???)
    • mscimedia2.uwaterloo.ca - 129.97.25.42 - Workstation all ports (unacceptable requirement -- to be refined)
    • mediaserver.uwaterloo.ca - 129.97.25.155 - E-Beam Server - ports 80(http), 8080 (???), 1935 (???),
    • mediaserver1.uwaterloo.ca - 129.97.25.10 - Breeze Server - ports 80(http), 8080 (???), 1935 (???)
    • motonline.uwaterloo.ca - 129.97.25.92 - Main course website - ports 80 (http), 8080 (???), 25 (smtp), 143 (imap), 1935 (???), 22 (ssh)
    • motoracle.uwaterloo.ca - 129.97.25.186 - backup storage server - ports 80 (http, 8080 (???), 25 (smtp), 143 (imap), 22 (22)
    Most of the above are already required. The notable exceptions are 1935, 4040, 5050, 7070, 8080 -- we need to document what these are used for.
Some of these exceptions could be handled with an SSH tunnel.

Debateable Services

Thare are some services where there might be some discussion -- if anyone has a requirement we would allow these:

  1. Email services includes "pop2" (109/tcp) --- is anyone still using that version? We don't even offer it on may servers.
  2. The Secure FTP service "sftp" (115/tcp) is an SSL wrapped version ftp service. We prefer SSH.
  3. The Internet Printing Protocol "ipp" at (631/tcp) may be required. It is an alternative to BSD printing
  4. The "rsync" service at (873/tcp) -- is sort of like "rdist", we doubt thatanyone needs off campus access to a UW rsync server.
  5. The "talk" (517/udp) and "ntalk" (518/udp) --- we doubt anyone needs that.
  6. The "Real Time Streaming Protcol" "rtsp" (554/tcp, udp) -- there may be a few.
  7. The Secure Telnet servcie "telnets" at (992/tcp) -- we prefer SSH.
  8. The Pop Password Daemon service "poppassd" at (106/tcp) -- a clear text password changer. Very few servers.

Of course telnet and rlogin could be blocked if people were happy with ssh.

Blocked Services

As a consequence of blocking all except for those services that are required there will be some consquence for those who rely on these services:

  1. Lightweight Directory Access Protocols "ldap/ldaps" at ports (389/tcp and 636/tcp)
  2. Unix "rsh" command requires the "shell" service at (514/tcp) -- the server for the "rsh" commands. We don't think this is terribly contentious but see the note below.
  3. Simple Network Management Protocols "snmp" at (161/tcp/udp) and "snmptrap" at (162/udp) -- we don't we want to expose these to everyone, there are only a few network infrastructure machines that report data to off-campus sytems. [Both blocked at campus gateway effective 14-Dec-2004].
  4. Internet Relay Chat services at "irc" (194/tcp), "ircs" (994/tcp) and "ircd" (6667/tcp) -- we are not aware of any IRC servers on campus using these ports.
  5. Microsoft SQL Server at "ms-sql-s" at (1433/tcp) -- this is attacked far too often. If access is required it should be tunneled. We understand the libraries have a MS/SQL database accessed by TUG members that is well firewalled. We know of MS/SQL servers in other units that have made no attempt to firewall themselves from attack in spite of repeated attacks.
  6. The open source MySQL server at "mysql" (3306/tcp) -- again, this is attacked far too often. If access is required it should be tunneled.
  7. socks(1080/tcp,udp) -- socks proxy server. There may be some.
  8. squid(3128/tcp) -- squid web proxy... do we have any?
  9. webcache(8080/tcp,udp) -- WWW caching service?
  10. quake(26000/tcp,udp) -- gaming port. No quake servers here thank you very much.
The set of services we currently block at the firewall (see UW blocked and reduced-priority protocols) should remain blocked with exceptions made in only very exceptional circumstances.

No doubt there are consequences for other services we have yet to discover.

Traffic Shaping: Network Based Application Recognition

A related, but recent technology, which can affect our use of the network is Cisco's NBAR ( Network Based Application Recognition) traffic shaping. Traffic shaping is an alternative to outright blacklisting of a service as we might do with a firewall. Over the fall-2004 term it was discovered that NBAR traffic shaping had adverse consequence for the Video/IP devices used by Science between UW and Guelph.

NBAR is a Cisco traffic shaping technoology which has been helpful at managing network traffic -- the objective is to put traffic from certain applications in a lower priority queue (so that mission critical applications are served first). It's about quality of service. We want gaming, peer-peer file sharing and other dubious applications to have a lower priority. The ports that NBAR uses to determine P2P in conjunction with other layer-4 information are:

NBAR also classifies packets based on layer-4 and higher information -- e.g. KaZaA on port 80 (http) has a distinctive signature and NBAR can distinguish real web traffic from KaZaA abuse of that port. NBAR is not simple port blocking/queuing. The data content of the network flow is examined. See also Network-Based Application Recognition [CISCO IOS SOFTWARE RELEASES 12.2 T] for more details.

Mission critical applications which use ports shaped by NBAR run the risk that they might be affected by the traffic shaping. For specialized devices, like the Video/IP devices used by Science, the work around is to not NBAR traffic shape them. These devices are an exception to the gateway firewall policies which include NBAR shaping for everyone else.

Note: as of 14-Feb-2005 all peer-peer traffic shaping was removed from the campus gateway -- IST staff report that the overhead involved in maintaining extensive exception lists was not worth the savings in bandwidth.

A Note on FTP Service

For anonymous FTP services we recommend the web -- use HTTP. For authenticated FTP services we can use HTTP, the UW Portal and/or SSH. FTP is a problematic protocol unless you also have "stateful" firewalls (simple Cisco ACL's are not stateful). The problem is the FTP data channel. Here's the problem:

  1. Traditional "active" mode FTP uses a data channel that has the server connect from port 20/tcp to an ephemeral port on the client. That means the FTP client is also a server (for the data channel). That doesn't work well if the client is in a firewalled network (unless the firewall is stateful and can determine that the attempt to open a port on the client is a legitimate consequence of an established FTP session). Most "home" firewalls cannot handle this.

  2. The newer "passive" mode FTP uses a data channel where the client connects to an ephemeral port on the FTP server (that gets around the firewall issues on the client network). However, if the server is on a firewalled network then the firewall has to be stateful to recognize that the attempt to open a port on the server is a legitimate consequence of an FTP session to the client. Cisco ACL routers cannot handle this .... you can allow access to all ports on the FTP server but that seems a dangerous compromise.

Mike Herz is able to support FTP services to one of the machines behind his firewall because his firewall is stateful.

On IST and Engineering "client-only" subnets there is no attempt to handle "active mode" ftp -- users are advised to use "passive" mode. IST has encountered one remote system that does not support "passive" mode -- the work around is to ftp from another system.

Microsoft IE can be configured to use "passive" mode, the Microsoft "ftp" command cannot.

On most, if not all, current Linux systems the "ftp" command will implement passive mode.

On Solaris before version 9 the "ftp" command does not support passive mode. On Solaris 9 and later the "ftp" command does support passive mode.

The version of SSH we use supports FTP tunneling for passive mode FTP. It's awkward to use but works. We believe the FTP version provided with Microsoft Windows does not support passive mode so even tunneling isn't going to help there.

This is a problem area which will require further discussion.

A Note on "shell" Service

We would rather people used SSH rather than the "rsh" command. Especially for anything involving systems outside of our campus.

The Unix "rsh" command has the same problem as the "ftp" command. When a client "rsh" client connects to a "shell" server the server establishes an "error channel" back to the client on a priviledged port (ie. <1024). Again this is an instance where the "client" acts as a server. For this command to work through a firewall the same problem has to be overcome. We are not aware of any firewalls that can handle this probem. And we do not encourage "rsh" commands to/from off-campus.

This is another problem area which will require further discussion.

See Also

Several good sites that document application requirements -- to answer the question what ports are required:

Security >> Security Working Group >> Firewall Working Group >> Requirements >> Services
(ed) Reg Quinton, Information Systems and Technology
2004/11/01 - 2005/02/15