The Ohio State University

Firewall Questions

What is a firewall, and why do I need one?

A firewall is a "device" that protects one or more computers from the "outside". Generally speaking, there are two types of firewalls - host-based and network-based. They provide essentially the same sorts of functionality, but host-based firewalls are implemented through software on each individual computer you are trying to protect, whereas network-based firewalls are devices that you place on the network to protect a group of computers from computers outside the protected network.

Almost all of the computers on your network are running network services that enable them to perform their various functions. Some of these, such as web or email services, are usually intended for use by everyone on the Internet.

Others, like local file services and a whole herd of other services, are typically used only for local network traffic, and are not intended for use by people outside the local network. A firewall can help restrict access from the outside to just the services that you intend to make available to the outside.

Firewalls are not a silver bullet - they won't magically keep your network secure, and they are not a substitute for other security practices such as installing patches, using anti-virus software, good password practices and so on. To be effective they need to be carefully designed and managed.

Won't it cause problems with... ?

Network Performance? - Not as long as your firewall is designed to handle your maximum bandwidth. Firewalls can be ordered with different network interface speeds. Be sure to select one that is appropriate for your network.

Remote Access? - Remote access should be via a VPN. All firewalls either support VPN or can allow VPN traffic to pass

Printers? - Firewalls do not effect printing.

Specialized Analytical Equipment? - In general, firewalls do not have any effect on specialized analytical equipment. You should contact the manufacturer of the equipment for specific firewall guidelines.

What do you recommend?

Not to sound self-serving, but we developed a firewall based on open-source components that we sell, install and maintain for people at OSU as a cost-recovery service.

For more information, send email to the firewall list at firewalls@osu.edu or call Brian Moeller at 614-247-7136.

There are plenty of good commercial firewalls available also, and you can find consultants who can assist you with network design and firewall configuration.

If you decide to go this route, we highly recommend that you discuss your plans with the Network Security Group to avoid potential problems. In particular, we highly discourage the use of NAT (Network Address Translation) in firewalls, as it causes severe problems with incident response.

What's wrong with firewalls that use Network Address Translation (NAT)?

In a nutshell:

1. NAT-based firewalls make it harder to track activity back to the source. This means that it will take longer to fix security issues and it will take more work.
2. If computers on the private network are compromised, the public address may be blocked at the OSU backbone, resulting in a total network outage for everything behind the NAT.
3. You don't need NAT - we have plenty of address space available at OSU, and there are plenty of firewalls can be used in bridging or routing mode without NAT.
4. Logging the address/port translations isn't always possible and won't completely solve your problems.

Although we do encourage the use of firewalls at the University, we discourage the use of NAT except in certain circumstances. In particular, NAT based firewalls are problematic for anything other than very temporary or very small installations. There are several reasons for saying this.

Before we dive into the reasons, let's look at how NAT works. When you use NAT, you have an internal, protected network that uses what are usually called "private" addresses from special address ranges such as 10.0.0.0/8 or 192.168.0.0/16. When a computer on the internal network needs to communicate with a computer on the external network (the rest of the Internet), the NAT router translates the addresses and port numbers in the packets so that they use a single public address.

The router maintains a list of which external port numbers correspond to which internal addresses and port numbers so that it can translate any replies in the reverse direction and forward them to the internal computers. This means that all traffic from the internal computers will appear to the outside world to come from the single public address that the NAT router is using. This translation feature is what causes the problems for us in the security arena.

Here's an example:

We'll represent the addresses and port numbers in our packets as [source IP, source port, destination IP, destination port] and we'll assume that everything is TCP for simplicity. Furthermore, suppose our NAT network is using the 10.0.0.0/8 address range, our router is using 10.0.0.1 on the internal network and 128.146.222.12 on the external network, and that we have a workstation on the internal network at 10.0.0.123.

When someone on the workstation browses a web page on a web server with address 128.146.2.3, the TCP packets for that request will look like [10.0.0.123, 12345, 128.146.2.3, 80] (12345 is the source port that our workstation is using for this session). The NAT router will translate this before forwarding it to 128.146.2.3, and it will substitute its public address (128.146.222.12) for the private address of the workstation.

It also needs to translate the port number, since some other client on the internal network may be using that same port number for some other transaction with the outside world, so let's say that it substitutes 34345 for 12345 in this case. This gives us a packet that looks like [128.146.222.12, 34345, 128.146.2.3, 80], which goes to the web server. To the external world, this, and all other traffic from the computers on the internal network, appears to be traffic from a single address, 128.146.222.12. The reply from the web server goes back to the NAT router, which translates the public address and port back into the corresponding private address and port, and the packet is forwarded to the workstation.

The fundamental problem is that all of the traffic from the internal network appears to come from a single public address. If one of the internal computers starts to "misbehave" and attack computers on the external network, the only address that will be seen on the outside is that single public address. This makes it very difficult to track "bad" activity back to its source on the internal, private network.

Among other things, this means that it can take much longer to resolve security problems on computers on NAT based networks than it will on networks where each computer uses a "public" address. Where it might take someone a few minutes to identify and "deal with" a compromised computer on a public network, it has at times taken a day or longer for people to track down infected computers on modest sized NAT-based networks at OSU.

Our standard policy for handling compromised computers at OSU is to block access to them at the backbone network. There are several good reasons for doing this, but the primary issue is to help ensure that these compromised computers don't become a bigger problem for the rest of the University than they have to.

Since the only visible address for a NAT-based network is the public address, this is what will be blocked if a computer on the private network is compromised. When we block the public address for the NAT, everything on the NAT will be unable to access the Internet. The longer it takes to find and fix the compromised computer, the greater our incentive for blocking the problem at the backbone. And the longer it takes to find and fix the problem, the longer the block will remain in place.

To overcome the difficulties in tracking activity back to the source, you could log the translation between private addresses and ports to the assigned public addresses and ports. Few NAT routers can create these sorts of logs, and the logs will be very large. Although that makes it easier to track things to the source, it change the impact of having the public address blocked.

Why doesn't the University just put a firewall in at the Internet border?

Good question. There are several reasons.

The first, and probably most important, is that the university is a large and decentralized place, with many diverse groups that have wildly different requirements for access controls (and for freedom from access controls). It would be difficult at best to come up with an effective border firewall without significant changes to the largely decentralized environment that we have. This might not be a bad thing, but it isn't going to happen any time soon. Until it does, any border firewall would necessarily look like swiss cheese and would effectively be so open as to be meaningless.

If we had a border firewall, we would still be recommending that departments install their own firewalls, in essence to protect them from attack from within the University. Since we feel that every department should have its own firewall regardless of the presence or absence of a border firewall, we've been pushing more in the direction of departmental firewalls and we've put little or no effort into creating a better border firewall.

We have recently started blocking more at the border (see "What does the University block at the Internet border?"), but this should not be regarded as an effective substitute for a well-configured departmental firewall.

What does the University block at the Internet border?

We have always blocked:

1. Source-routed packets.
2. Traffic with obviously spoofed source addresses.

Blocks on these services are reviewed quarterly:

1. UDP/69 (TFTP) inbound and outbound
2. UDP/135, TCP/135 inbound
3. UDP/139, TCP/139 inbound
4. UDP/445, TCP/445 inbound

Some ports are blocked for a short time due to the fact that they are commonly being used on campus for various backdoors but there are none at the moment.