2004/11/09 - 2004/11/10

Security >> Security Working Group >> Firewall Working Group >> FAQ

This is a collection of frequently asked questions -- our intention is to clarify:

1. Q: What are we doing?

   A: We're establishing firewall rules to block all inbound network traffic (ingress rules) for services which are not required. Anything that is required will be allowed.

   We're not, at this stage, reviewing the current egress rules.

2. Q: Why are we doing this?

   A: The internet is a hostile environment. We see attacks every day on many different services. We see compromises and back doors installed at odd port numbers. We expend a lot of energy chasing problems that could have been blocked at the front door. An ingress rule to block all but what is required will help to secure our systems.

   We're not reviewing the current egress rules at this stage because we believe a refined ingress rule set is the first step of several.

3. Q: How will this affect me?

   A: The answer is "it depends".

   For most users an ingress firewall should have no affect -- most systems don't offer services. Most systems are "clients" not "servers". If your work station on campus is Windows XP/SP2 then you already have a firewall and you've already experienced the environment. If you've already installed a firewall on your system (like ICF on Windows XP, or Zonealarm, or etc.) then you've experienced the environment. If your machine is located within a firewalled network (like resnet and many other client-only networks implemented around campus) then you've experienced the environment. If your working environment is similar to those of others who are working in these secured environments then you should have a similar experience.

   For those who are providing the many services we already know about we'll make sure that those services aren't interrupted -- you shouldn't notice any difference.

   For those who are providing novel services that we have not documented those services may be interrupted if you don't let us know about the services you required.

4. Q: But I don't want any firewall in my way!

   A: If a firewall has no adverse impact then objections on "principal" alone are not compelling.

   If you have an application that's required and a firewall gets in the way then exceptions can be made. If you believe that there should be no firewall in your way, don't be surprised if your network manager, or those further along in the chain of responsibility, are unwilling to compromise the security of their networks without substantial proof that the firewall is in your way. If it is you may have to relocate your system to a location outside the campus firewall.

5. Q: Won't this be a terrible inconvenience?

   A: For most users the firewall is not an inconvenience -- it's a security enhancement. For some user there will indeed be some inconveniences -- on balance we believe the added security for all is well worth modest inconveniences to some.

   For research projects requiring network resources you ought to document your requirements and have them approved before proceeding too far. One usually tests in a local controlled environment before testing over long haul networks. Inadequate preparation can have an adverse on a production network.

6. Q: What are the "required" services?

   A: The firewall working group produced a list of Required Services -- that's a pretty good measure of the type of services that will be required. But that's only a start. There may well be services you require that aren't on that list.

7. Q: How do I determine the services that I offer?

   A: To determine the services offered by a system try the "netstat" command:

   Microsoft Windows XP [Version 5.1.2600]
   (C) Copyright 1985-2001 Microsoft Corp.
   
   N:\> netstat -a
   
   Active Connections
   
     Proto  Local Address          Foreign Address        State
     TCP    ISTPC104:epmap         ISTPC104.ads.uwaterloo.ca:0  LISTENING
     TCP    ISTPC104:microsoft-ds  ISTPC104.ads.uwaterloo.ca:0  LISTENING
     TCP    ISTPC104:6000          ISTPC104.ads.uwaterloo.ca:0  LISTENING
     TCP    ISTPC104:1038          ISTPC104.ads.uwaterloo.ca:0  LISTENING
     TCP    ISTPC104:1311          localhost:6000         ESTABLISHED
    ....etc.
     UDP    ISTPC104:177           *:*
     UDP    ISTPC104:microsoft-ds  *:*
     UDP    ISTPC104:isakmp        *:*
     UDP    ISTPC104:1025          *:*
    ....etc.
   

   There are two kinds of services we're interested -- the "TCP" services in the "LISTENING" mode and all of the UDP services. In the example this Windows XP/SP2 work station offers quite a few services.

   However, there's quite a difference between services "offered" and services "required". As you probably know Windows XP/SP2 comes with a firewall so that all of the services offered are protected. Nobody can access those services.

8. Q: How do I determine the services I require?

   A: That can be difficult if you don't have a good understanding of the applications you're running. While you can run "netstat" periodically to see if anyone connects to the service you offer that's not a reliable marker that the application is required -- attackers will often scan all services on a machine.

   For well known services (like those for email, for the web and other common services) are easy ... after all they're well known.

   For novel services unique to your system carefully conducted experiments may be the only way to determine what's required and what's not. If the application documentation doesn't detail the services you need to expose to the world then you'll need to figure out what's required. You should conduct those experiments now before the firewall is configured to control access to your system. If you need assistance, we can help.

9. Q: What do I do when the service I require is blocked?

   A: Talk to those responsible for your network (your CNAG representative is often a good place to start). They can enter firewall exceptions to allow your service to continue. They can show you technologies you can use to get around the firewall -- SSH tunneling and VPN solutions.

10. Q: What is SSH tunneling?

    A: SSH tunneling is a trick that allows a user outside of the firewall to tunnel traffic over an SSH connection to a service within the firewall. SSH traffic is allowed through the firewall. SSH tunnels are an appropriate technology if the users outside the firewall have accounts on machines within the firewall. SSH supports TCP tunnels -- it cannot tunnel UDP services. SSH tunnels can be awkward as there's an effort required to configure each tunnel.

    SSH tunnels are a good way to secure access to services -- only authenticated users can erect SSH tunnels.

    SSH is available on all popular systems and most Unix systems on campus will support inbound SSH tunnels.

11. Q: What is a VPN?

    A: Virtual Private Networking (VPN) is a technology that lets a system outside of the firewall establish a "virtual" interface on the campus network. Again, this requires that the user outside of the firewall have an account -- this time on a VPN gateway system inside the firewall. VPN traffic is allowed through the firewall. This nice thing about a VPN is your system, even though it's physically outside of the firewall, is virtually on the campus network. VPN's support both TCP and UDP services and one VPN connection can support any number of services with no extra configuration effort.

    VPN's are a good way to secure access to services -- only authenticated users can establish a VPN.

    There are some VPN gateway systems on campus and IST will deploy a VPN solution for the campus at large.

....this is a draft document, a work in progress.