What firewalls are and how to use them effectively.
A firewall controls access to the network ports on your machine at a low level so that intruders have less chance to breach a service. They also allow you to grant access to particular IP numbers or ranges. For example, if you want to use a web or file server so you can access your home machine from work, you can set the firewall to block access to the ports used by those services from all machines on the internet except the ones you use. To machines not granted access, the port apparently doesn’t exist, so there is nothing there to attack.
Is my cable modem a Firewall?
In a sense, yes. Most folks have a wireless access point that contains a switch for wired connections, and acts as a Network Address Translation router. These devices use private addresses to allow multiple computers to share a single ip number on the outbound side. The machines behind such a device are not reachable from the outside unless port forwarding is enabled.
Simple firewalls just look at the packet for IP source and destination addresses, protocol, and ports, so you have to identify what ports you need to open for your software to work. This kind is a little trickier to configure since you need to know which ports to open and which to close.
Application firewalls also look for what applications are involved in the conversation (most of the windows software falls into this category). This type of firewall software generally has a learning mode, in which the first time a port is used, the firewall software prompts you to allow or deny that use, with an opportunity to build a rule for future reference. This kind is pretty easy to configure, although you should take care to not get in the habit of allowing everything (which defeats the purpose, really). This kind generally prompts for outgoing and well as incoming connections, so they have the additional advantage of helping detect activity by viruses or “spyware”.
In general, outgoing connections and incoming packet resulting from outgoing connections should be allowed. Windows users have a bit more to worry about in this area since they are more prone to viruses which often install software that trys to propogate the virus further via outbound connections, but use of anti-virus and anti-spyware software should mitigate this risk.
So it’s really only new incoming connections that you need to worry much about (these are connections initiating by remote machines trying to start a conversation with your machine). If you’re running a service on your machine that you want others to be able to use, you’ll need to make sure that service is accessible. In general, you’ll need to consider the following when configuring your system:
- What ports does this service require to function?
- Which ip numbers or range or numbers do you want to open this service to?
- Does this service rely on UDP, TCP, or perhaps both?
As an example, if you’re running a web service that you want anyone on the internet to access, you’d open port 80 for inbound connections to the entire internet. This would mean, of course, that anyone could have a go at breaching your system through your web server. But if you only need that webservice so that you can check your online calendar (for example), you could limit access to the service to a particular network range or even individual machines that you use.
A quick note on ports
How ports are used is often confusing. Generally speaking, servers will listen on a specific well known or registered port. Clients may start a connection from a particular port, or randomly choose one of the dynamic ports. And once a network conversation is started, services may stay put on a pair of ports, or may “walk” through a range of port numbers.
There are about 65k of ports, broken into three ranges:
- 1-1023 are “well-known” ports. Use of these ports should be restricted by the OS on the local machine to the root or other priviledged accounts (but should is a big word). Consequently, breaches on these ports are generally considered more dangerous for most operating systems.
- 1024-49151 are registered ports. Programmers are supposed to register these ports with the IANA for use with client-server software.
- 49152-65535 are dynamically assigned ports. This range is a free for all zone used by any program.
As a general guideline, the lower the port number, the more closely it should be guarded.
Check the firewall’s logs regularly
This is especially helpful when you are setting up the firewall. Most firewalls log blocked connections, so when you make a configuration change, you can try to use the services affected by that change and then check the log if things don’t work as expected.
But you should also review the firewalls logs regularly just to get a feel for what kind of activity your machine is experiencing.
Take advantage of scanning software and services
There are a number of software packages and on line service you can use to check out your system. Some programs such as netstat can be used to look for ports locally (although some trojan horses can hide their use of a port!), others can be used to scan a machine remotely (but you want to take care with these–on some networks, scanning ports is considered a security breach in and of itself, so check with your network admin). Do NOT use this kind of software to scan more than one machine at a time, this kind of usage not only consumes lots of bandwidth, but is also very suspicious–poking around your house is one thing, but scoping out the neighbors is questionable at best.
- Nmap: This unix program is used by both forces of light and dark, it’s an excellent CLI port scanner. See also this nmap guide.
On line services will scan your system for you. Do be aware that some of these sites are also selling services, and using the free scans as advertizing. Also, some of these sites are a bit, shall we say, histrionic in their characterization of potential problems.
- Gibson Research: This is a good place to start. Steve’s Shields Up service scans for the most commonly used ports. It’s not comprehensive, but it’s fast and free.
Sniffers are another good resource, if a bit more technical. A sniffer shows lists of individual packets, not just connections, so you can step through connections, packet by packet, to see how your software is using ports.
- TCP dump: this one’s venerable, and there are front ends available such as MacSniffer
- Wireshark: the defacto standard in sniffing software.
Gee, this is all pretty vague
Yeap. There’s a lot of variation in how the individual software packages are configured, and it’s impossible to predict exactly what your needs for access and security might be. Although pretty much every operating system comes with a minimal firewall these days, it’s worth going to a little extra effort. For example, Windows XP, OS X, and Redhat all just open a port when you enable a service, and that’s not the real power of a firewall–the real power is in opening a port to a limited range of network addresses.
Ok, so I’ve got a firewall, what now?
This is one way you might approach configuring a firewall–there are others, and what is described here might not be appropriate for your needs.
Putting it all together
- With the firewall off, or before you install it, go to http://www.grc.com/ and use Shields Up to scan your system. This will tell you what a scan of your system looks like without any security measures in place. Don’t worry too much about it if you fail the tests even with a firewall, Steve’s rules for passing are pretty strict.
- If your system has a default firewall (pretty much all of them do), try that first.
- Now repeat your scan at grc. If the firewall is working, you’ll see that all ports are now reported to be in stealth mode. Also check the firewall’s logs, there you should be able to see a list of the connections that were denied.
- Try to use your computer the way you normally do–use your favorite programs, test moving files, and so on. If your firewall is application oriented, you will likely receive numerous notices from the firewall noting that various applications are requesting access to outbound ports. Take your time, and examine each proposed rule. Generally it is ok to accept outbound connections, but you want to make sure you’re not enabling any spyware or virus software to open connections to the internet.
- Also test your ability to use file servers (assuming you use a file server). For example, if you AFS, you may find that you need to enable inbound connections on ports 7000-7007, but you should only need to do this for the AFS servers you used (you should be able to find a list of these servers in the local CellServDB file). For other types of file services, you might consider enabling a range of ports. For example, CS affiliates might enable access to their home machine to addresses in the cs.unc.edu–this would allow any cs machine to attempt a connection.
- If something doesn’t work, check the firewall’s logs to see what was blocked (it’s helpful in this case to clear the log, then try what isn’t working again, so that most if not all log entries are from the failed connection). This should give you an idea of what rules are blocking the connection.
- If you can’t figure it out from the firewall’s logs, you might try a sniffer program. First disable the firewall, then activate the sniffer, and try the program that doesn’t work through the firewall. The sniffer should catch all packets that were involved in establishing the connection. Each packet will have information on what port was used for that packet, what protocol was used (generally UDP or TCP), and what IP numbers were used as source and destination.
Refining your filters
- The most pwerful use of a filewall is to restrict trafffic to a service to a particular range of network addresses. For example, there’s not much reason for a workstation at unc to allow ssh from anywhere, it’s probably pretty to restrict it to unc.edu addresses. So you can limit access to port 22 to 22.214.171.124/16, 126.96.36.199/16, and 188.8.131.52/16. (if you don’t understanding this notation, 184.108.40.206/16 is means all number from 220.127.116.11 through 18.104.22.168. For help on understanding subnet ranges and mapping them out, see this online subnet calculator.
- If you want to refine ICMP filters see http://www.iana.org/assignments/icmp-parameters for a listing of icmp types.