Skip to content Skip to navigation

Default Deny

Network Default Deny Firewall Policy

Overview

This is a firewall policy that blocks inbound connections to computers on LASSP public subnets initiated by systems off campus. It does not block responses coming back from off campus to connections initiated by computers on LASSP public subnets.

Examples of things that are not blocked.

  • Anything originating on your on campus system
    • Security update downloads.
    • Web browsing.
    • Editing web pages hosted on external web servers – Media3, Pantheon, Wix, etc.
    • Zoom and the like.
    • Connecting to a server via ssh
    • Code42 backups
  • Certain types of external connections to applications on your computer. In general, anything that is designed to work through a NAT style router/firewall. These services have a local client that initiates contact to an off campus server, and that server then communicates through the established connection to start the session. Specific examples include, but are not limited to:
    • Skype, RingCentral
    • TeamViewer
    • Slack, Microsoft Teams, and similar

Examples of things that will be blocked from off campus computers by default.

  • Microsoft Remote Desktop (RDP) – this is already blocked from off campus.
  • Web servers running on the campus computer, either deliberately or as a component of certain software.
  • Secure Shell or ssh as a server. This includes Apple macOS remote login. (More below.)
  • VNC – virtual network computing – a method for viewing a computer screen remotely with multiple different implementations.
  • Random software that listens for outside connections.
    • This may include default services for the OS. LASSP already blocks a few services that were listening on older versions of Windows by default.
    • Anecdote: At one point, a famous network backup program client listened to the world on port 10000, unbeknownst to most. Then a bug was discovered that allowed any client to be compromised if it could be seen by a hacker. (We currently block port 10000 still, even though the software is long gone.)

Note that malevolent actors are continuously trying user and password combinations against available ssh and RDP servers to gain access by brute force. This happens to the point where system logs fill up and general network slowdown can be seen. There are some local mitigations that can be used, but this requires active, semi-complex setup on the local computer.

CU VPN Usage and Limitations

Cornell runs CU VPN. See:

https://it.cornell.edu/cuvpn

This uses a Cornell configuration of the Cisco AnyConnect Secure Mobility Client. It runs on Windows, mac OS, Linux, and even iOS, Android, iPad OS and perhaps more. It gives your networked device a virtual network adapter that is “on-campus”, and it routes all network traffic to Cornell through that virtual adapter. All the traffic over that virtual network adapter travels through your real network adapter via a secure encrypted tunnel to the VPN server on campus where it is decrypted and sent on to the desired on campus host. Note that traffic from your device to anywhere outside of Cornell does not travel through the CU VPN.

Use of the CU VPN requires a NetID and password as well as DUO two factor authentication. If you need to open on campus servers to people off campus with a Sponsored NetID or a Guest ID, contact lassp-it@cornell.edu.

CU VPN sessions end after 10 hours. You can start a new 10 hour session after authenticating again.

Firewall Modifications

If you think you need different firewall rules for a particular computer on a particular IP address, feel free to contact lassp-it. In general, there are two classes of modification - more protection or less protection with an exception

More protection

The use of 10 space as a security measure will probably be discontinued at some point. This is because a complex proxy service must be maintained that allows hosts on 10 space to get off campus for security patches. But, the proxy server isn't suited to, say, LabView authentication and updates. It makes more sense to block most off campus connections for certain data taking computers with the firewall, but still allow them to get to security patches and specific off campus services like software publishers that require a network check in periodically.

Less Protection with an Exception

I can imagine a few scenarios where the CU VPN timeout might cause a problem. If a particular piece of equipment or program allows remote monitoring of a device or software on a particular port, there may be cases where one has a home system checking it automatically 24/7. In this case, one might want to open that port on that IP to your home IP or even to the world depending on the situation. However, there are probably better solutions for these scenarios. For example, have that host/port monitored by another on-campus system and have that system generate an email or other alert if a problem is detected. If you think you need an exception, please contact me.