Traffic Filters at the University's Internet Borders

OIT filters (blocks) selected traffic as it passes through the OIT-managed borders between the campus network and the Internet.

These filters serve a variety of purposes, for example:

• Some filters are to protect devices on the campus network from receiving categories of traffic considered too dangerous to accept from the Internet. Generally, this is only done for communication protocols that have demonstrated a history of widely exploited security problems so serious that the risks of allowing such traffic outweigh the benefits.

• Some filters are block communication protocols that have little legitimate non-local use, especially if the protocol can be easily abused to degrade network service or to compromise the security of devices.

• If we block a communication protocol inbound from the Internet to the campus, we will usually also block it outbound, even if only to prevent communication that would fail because of their "one-sided" nature.

• We sometimes block traffic coming from selected Internet addresses that have been the sources of past attacks direced at the campus network. Given the large number of such attacks every day, only a tiny fraction of these senders are blocks at any time.

• We block traffic to (or from) some classes of devices on the the campus network that as a matter of policy should not be permitted to communicate with the Internet.

The filtering described here is performed at the border(s) between the campus network and the Internet -- or at least, at those borders managed by OIT. Only traffic crossing these borders are affected by these filters. The filtering described in this document is not done within the campus network; these filters do not affect traffic between two devices attached to the campus network.

For the purposes of this document, devices attached to the network Temporary Visitory Wireless Network Access (TVWNA) are not attached to the campus network; they are on the Internet side of the campus network's border.

For the purposes of this document, devices attached to the network via External Customer Networks are not attached to the campus network; they are on the Internet side of the campus network's border.

Specific Filters

Filters on Traffic Inbound from the Internet to Campus

• We filter traffic from IPv4 source addresses that are assigned to the campus network. Devices outside the campus network should not be transmitting traffic using these IP source addresses.

• We filter traffic from or to IPv4 source addresses 127.0.0.0/8 (loopback). Such traffic should not be transmitted outside a host (i.e. on the actual network).

• We filter traffic from IPv4 source addresses 224.0.0.0/7 (multicast). These addresses are valid only as destination addresses, not source addresses.

• We filter traffic from IPv4 source address 0.0.0.0. This address is valid as a source address only in certain circumstances, none of which are applicable for traffic coming from the Internet.

• We filter traffic from IPv4 addresses 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16. These are all RFC1918 addresses reserved for local use, and are not intended to be routed globally.

• We filter traffic from IPv4 source addresses 140.180.184.0/24. These addresses are leased to clients using Temporary Unregistered Dormnet (TUD) IP Service, which is not intended to provide Internet access.

• We filter IP traffic destined to any the following TCP or UDP ports associated with NetBIOS-over-IP: 135 (epmap), 136 (profile), 137 (netbios-ns), 138 (netbios-dgm), 139 (netbios-ssn), and 445 (microsoft-ds) These are all Microsoft protocols with a long history of serious security problems.

  We make an exception if the traffic is destined to Princeton Plasma Physics Lab IPv4 addresses 192.55.106.0/24 or 198.35.0.0/20, because those are non-University networks that may transit the campus network to reach the Internet.

• We filter IPv4 traffic destined to TCP or UDP port 593 (http-rpc-epmap). This Microsoft protocol has a history of serious security problems.

• We filter IPv4 traffic destined to UDP ports 161 (snmp) or 162 (snmptrap). These protocols are used mostly to monitor and manage network infrastructure, but older versions of these protocols and most implementations of these protocols have minimal security to protect them. There is rarely need for devices on the Internet to monitor or manage campus network infrastructure; when there is such a need, it can often be accomplished via other more secure protocols.

• We filter IP traffic destined to UDP port 67 (bootps). We know of no legitimate need for devices on the Internet to obtain BOOTP or DHCP service from devices on the campus.

• We filter IP traffic destined to UDP or TCP port 111 (sunrpc, aka rpbind, aka portmapper). Historically, applications relying on Sun's rpc-based protocols have provided little security and have a history of being exploited.

• We filter IP traffic destined to UDP or TCP port 2049 (NFS). It is OIT's policy that devices on the Internet may not obtain traditional NFS service from devices on the campus network.

• We may filter traffic from other specific Internet IP source addresses, typically when these have been involved in attacks on the campus network.

• OIT's Security and Data Protection group may operate firewalls or Intrusion Prevention Systems (IPS) that filter traffic they believe to be malicious based upon the traffic pattern or because the traffic contents matches signature of well-known malicious traffic.

• OIT's Security and Data Protection group may operate firewalls or Intrusion Prevention Systems (IPS) that filter traffic from IP addresses they believe have engaged recently in reconnaissance activity. See Quarantined: Why am I not able to access the Internet from my machine?

• We may filter traffic destined to to other specific campus IP addresses under special circumstances. The customer responsible for the campus IP address is normally notified of such filters.

Filters on Traffic Outbound from Campus to the Internet

• We filter traffic from IPv4 source addresses other than those assigned to the campus network. Devices on the campus network should not transmit traffic to the Internet using IP source addresses other than those assigned to the campus network.

• We filter traffic from IPv4 addresses 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16. These are all RFC1918 addresses reserved for local use (and indeed are used locally on the campus network); they are not intended to be routed globally.

• We filter traffic to IPv4 destination addresses 140.180.184.0/24. These addresses are leased to clients using Temporary Unregistered Dormnet (TUD) IP Service, which is not intended to provide Internet access.

• We filter traffic to IPv4 destination addresses for customer devices registered in the Princeton University Host Database with an ENTRY-TYPE of BRIDGE or HUB. Such devices are normally not permitted Internet access.

• We filter IP traffic destined to any of the following TCP or UDP ports associated with Microsoft NetBIOS-over-IP: 135 (epmap), 136 (profile), 137 (netbios-ns), 138 (netbios-dgm), 139 (netbios-ssn), and 445 (microsoft-ds).

  This is in part because we have blocked such traffic inbound to campus; we found that allowing (only) the outbound traffic would result in frequent "one-way" conversations that generated confusing communication failures without providing any useful functionality.

  Disallowing the useless outbound traffic also sharply reduces the number of complaints from the Internet the University must handle due to on-campus devices attempting to attack Internet devices via these protocols.

  We make an exception if the traffic is from Princeton Plasma Physical Lab IPv4 addresses 192.55.106.0/24 or 198.35.0.0/20, as there is no block for these addresses in the inbound direction.

• We filter IPv4 traffic destined to TCP or UDP port 593 (http-rpc-epmap). This Microsoft protocol has a history of serious security problems.

• We filter IP traffic destined to UDP ports 161 (snmp) or 162 (snmptrap). These protocols are used mostly to monitor and manage network infrastructure, but older versions of these protocols and most implementations of these protocols have minimal security to protect them. There is rarely need for devices on the campus to monitor or manage devices on the Internet; when there is such a need, it can often be accomplished via other more secure protocols.

• OIT's Security and Data Protection group may operate firewalls or Intrusion Prevention Systems (IPS) that filter traffic they believe to be malicious based upon the traffic pattern or because the traffic contents matches signature of well-known malicious traffic.

• OIT's Security and Data Protection group may operate firewalls or Intrusion Prevention Systems (IPS) that filter traffic from IP addresses they believe have engaged recently in reconnaissance activity. See Quarantined: Why am I not able to access the Internet from my machine?

• OIT's Security and Data Protection group may operate firewalls or Intrusion Prevention Systems (IPS) that selectively filters IP traffic destined to TCP port 25 (SMTP). An Individual who operates a legitimate mail server attached to the campus network should contact the OIT Support and Operations Center to request that the OIT Static IP Address presently assigned to that mail server be granted an exception to this block.

Caveats

Traffic that passes between the campus and the Internet without crossing OIT-managed borders may bypass these filters.

Traffic that is encapsulated inside other traffic at the time it crosses the network's Internet borders will bypass these filters. Such encapsulation is often called a "tunnel". When you connect to OIT VPN Services, your device constructs a tunnel between itself (somewhere on the Internet) and the OIT VPN Servers located on the campus network. The data that passes through the tunnel is not subject to the filters above as it crosses the campus Internet borders. This is the intended behavior; one purpose of OIT VPN Service is to extend campus network services to your device when it is off-campus. In particular, off-campus customers who wish to use software that rely on the Microsoft protocols filtered above are often instructed to use OIT VPN Services.

The list of filters above may not be inclusive. For example, we have not listed the many Internet addresses blocked from reaching the campus network due to attacks from those addresses; that list is constantly changing. Not have we listed the IP addresses blocked by the firewalls or Intrusion Protection Systems (IPS) operated by OIT's Security and Data Protection group; these lists are also constantly changing.

The traffic we filter may change with little or no notice. Sometimes we must install a new filter rapidly to combat an immediate threat.

There is no guarantee that the filters above may be in place at all times. Failures in the filtering equipment, maintenance, and changes in policy can result in filters leaking or being deactivated temporarily or permanently. Therefore, OIT makes no guarantee that the filters documented above will always be present or effective. If you are implementing a security solution for devices attached to the campus network, you must not base your solution on an assumption that the filters above will always be present or effective.