The New College Firewall System

Chris Tromans

New College

chris@corelli.new.ox.ac.uk

http://www.new.ox.ac.uk/~chris/firepres/

SpecificationNew College’s requirements of the system were:

• It contained a mechanism to force the registration of all network users with the IT Officer in the form of a signed agreement to the university and college computing rules. The agreement was to link a user to a particular computer.

• It was able to reliably track IP address allocations so that in the event of a breach of computing rules the offending user could be identified, and if required sufficient evidence would be available to ensure a conviction.

• It prevented users from accessing services forbidden by the university and college computing rules (particularly those that are used for the illegal distribution of copyright material) but allowing full use of any resources required for academic work.

• It prevented intruders from compromising machines on the network to ensure data integrity and prevent the launch of denial of service (DOS) attacks.

Network Scans in the Last 4 WeeksTCP Port No. Attempts Service

21 55 FTP File Transfer

22 5 SSH Remote Login

23 1 Telnet Remote Login

1411 1 Audiofile Computer Audio???

1433 25 Microsoft SQL Server

1524 4Root shell listener for many exploits.

2091 1 Video Conferencing???

8000 1 Web Servers

8080 3 Web Caching

17300 1Trojan W32/Weird-10240 (Kuang2)

These do not include scans blocked at the university firewall and all originate from hosts outside Oxford. Originators are mainly dial-up / DSL clients but also foreign universities appear surprisingly often.

Possible SolutionsTwo techniques of addressing the first two points in the specification are:

• Static IP addresses.Impractical on a network of potentially 560 hosts.

• DHCP only allocating addresses to known (registered) hosts.Insecure since all a user has to do is specify an address for the computer on the correct subnet and registration is

circumvented. No potential exists for users to register online since you need an address to access a web based service which you don’t have because you haven’t registered yet. The IT Officers is therefore

required to enter the information which is a waste of resources. The problem of users having to know their MAC addresses also arises.

The final points in the specification can be addressed using a 3COM SuperStack firewall or some similar product.

The best solution is restriction at the gateway of the network together with an online user registration system. No product existed on the market which could provide this and so the New College Firewall System was born.

The Registration System 1DHCP is used to allocate addresses to hosts whether registered or not (machines with static addresses register in the same way).

Every packet attempting to leave the network is checked using its source MAC address to determine if the packet is from a registered host. If the host is not registered all web requests (to any address) are diverted to the page below:

Attempts to use other services are refused with ICMP Destination Host Unreachable to prevent the user having to wait for a timeout.

The Registration System 2The MAC address of the user’s machine is determined from the ARP table of the firewall and passed into the registration system as a HTTP GET argument thereby removing the need for the user to know their MAC address.

The MAC address is only shown on this page for trouble shooting purposes.

The Registration System 3The system puts each user into a category and only collects the information required for that category. For example the date at which a member of the JCR moves out of their current room is known, however no such date exists for members of the admin staff, so no attempt is made to collect it. The categories are also used in the compiling of statistics of network usage.

The Registration System 4

The form which collects the required information from members of the JCR.

The Registration System 5

The agreement which must be signed and presented to the IT Officer before network access is granted.

The Administration Interface 1On completion of the registration pages the users details are listed in the administration interface.

The Administration Interface 2Allowing a user network access simply involves ticking the authorised box and clicking update. Within a minute the user will have network access.

The Administration Interface 3For each outgoing packet the firewall checks that the IP address of the source machine has not changed since the previous packet. If it has the change is logged. These logs are displayed in the administration interface.

Searches can be made by MAC address to determine which address a machine is using, and by IP address to determine the machine which is using that address.

The Administration Interface 4Access to the administration interface is controlled by username and password. Users can be given superuser rights allowing them to create and modify other users.

A JavaScript MD5 routine is used to prevent password sniffing.

The Administration Interface 5Administrative scripts run daily which rotate IP address logs and remove users whose university cards have expired. When a user is removed an e-mail is sent to the IT Officer informing them that this has taken place so that the paper records can also be disposed of.

System HardwareOrdinary PC Hardware is used. The firewall for the 510 host subnet is a:• Intel Celeron 566 on a Intel i810 Motherboard• 128MB RAM• Intel EtherExpress (UTP connection to central college Switch 3300)• 3COM 3C509B-FX (fibre connection to university backbone)

3COM Switch 3300

Firewall

Media Converters

Fibre to College Staircases

UTP link from EtherExpress

University Networkand the Internet

Fibre link from 3C509B-FX

System TopologyThe client-server topology is used to remove the need for network daemons running on the firewall thereby removing an enormous number of potential paths for intrusion by hackers.

SSL encrypted links are used for client-server communication with certificate validation to ensure the integrity of the server on connection.

Firewall software has minimal trust for server so it is very unlikely that compromise of the server will lead to full compromise of the firewall.

New College run the server software on their general purpose Linux server which also serves amongst other things the college website and a Sophos centralised installation. The consumption of system recourses is very low. The server software can be run on Windows NT/2K/XP.

One server is able to support many firewalls and does not have to be located on the same subnet as the firewall itself.

System Software 1The firewall runs a minimal installation of Redhat Linux 7.2 using a 2.4 series kernel. The ARP proxy facility in the Linux kernel is used to prevent any configuration changes being required to machines on the network (including the university router since the firewall would need a entry in its routing table otherwise). The default gateway on all hosts remains the university router allowing the firewall to be inserted/removed transparently. The Netfilter/Iptables firewalling subsystem provides all packet filtering functionality and includes stateful inspection for enhanced security. The software that identifies packets as being from registered or unregistered machines, and logs IP address allocations, is implemented in C and acts as a userspace packet filter using the Netfilter ip_queue module. As it stands in the kernel, this module provides a mechanism for passing packets to userspace, and then receiving those packets back into kernel space with a verdict specifying whether they should be passed or dropped.

System Software 2A kernel patch was written as part of this system which extends the functionality of this module to allow the nf_mark field of each packet to be set from userspace. This is used to mark packets as being from either registered or unregistered machines. On return to kernel space these packets are identified using the nf_mark field, and if they originate from unregistered hosts the Netfilter packet mangling framework (in particular the redirect target) is used to display the registration pages to the user. The details of registered machines are held in a MySQL database on the support server. The userspace packet filter running on the firewall maintains a cache of the machines in the database. A custom application written in Java runs on the server allowing communication via the secure socket layer (SSL) between the software on the firewall and the database on the server.

PerformanceNo impact on network performance in terms of both latency and throughput have been experienced on either of the New College subnets (510 hosts on the main site and 255 hosts in the annexe).

During testing 12MB/sec was seen with approximately 50% of the CPU resource in use (this was seen whilst transferring a 600MB ISO image between two Linux machines using Chris Evans’ VSFTPD on 100MBit/sec switched ethernet).

Packet Filtering Policy 1A packet filtering policy for a college network is difficult to write due to the wide diversity of users present. Fortunately the Netfilter framework uses the powerful technique of “chains” which allow for considerable flexibility.

It was found that different rules were required for ordinary users depending on traffic source and destination.

Traffic to and from hosts in the university is by default allowed to pass. This was decided due to the large range of services offered by departments that many students need to use. However several items are blocked:

• Incoming connections to Microsoft network shares. This is due to the large number of viruses using this technique to spread (outgoing connections are allowed).

• Incoming HTTP, FTP, Telnet and SSH (exemptions available on user request) due to the large number of exploits that exist in these areas.

• Incoming SNMP to protect manageable printers, switches and hubs.

Packet Filtering Policy 2Traffic to and from hosts outside the university is dropped by default. No incoming connections of any kind are allowed to normal hosts (thereby removing any possibility of users running servers). Outbound connections are allowed on the following ports:

Port(s) Service Port(s) Service

21 TCP FTP 143 TCP IMAP

22 TCP SSH 210 TCP NISO Z39.50 database

23 TCP Telnet 443 TCP HTTPS

43 TCP WHOIS 554 & 7070 TCP

6670-7170 UDP

RealPlayer

80 TCP HTTP 993 TCP Secure IMAP

110 TCP POP 995 TCP Secure POP

119 TCP News 11371 TCP PGP Keyserver

Web Based Admin of Filtering RulesThe filtering rules are currently specified in a shell script as a collection of iptables commands. These are read from the support server each day in the early hours of the morning and applied to the firewall. A rollback facility has been implemented so that if a syntax error is found in the script the previous days settings are restored.

Although the shell script provides much flexibility it is lacking in ease of use.

Development has therefore started on a web based administration interface for the filtering rules in the same style as that for controlling registered and unregistered machines. This is due to be completed in the next month or two and will include the ability to make real time changes to the system.

Restriction by Physical LocationIt became apparent after the installation of the system that the college library required a different set of restrictions to the rest of the college. This is currently implemented by placing the library computers on a small subnet within the college’s main subnet and allowing different restrictions to that block of IP addresses. This gives problems since static IP addresses are required for those machines and the possibility of abuse of these addresses by network users other than the library staff exists.

Over the summer we will be extending the system to use the 802.1Q VLAN protocol supported by 3COM Switch 1100 and 3300 to place the library on its own virtual network whilst still sharing the same physical fibres with everybody else (switch ports are assigned to a particular VLAN). Up to 16 virtual networks are supported on our hardware. The Linux kernel supports 802.1Q and traffic from each VLAN will appear to be coming in on separate ethernet interfaces. Separate filtering rules can then be specified for each interface. Restrictions can therefore be set by physical location (i.e. which port on which switch the machine is connected to) with misuse of addresses being made impossible by the switches.

Virus Checking Outgoing E-MailCredit for this idea goes to Alastair Johnson from Trinity since I pinched it from a posting he made to ox.general.

Viruses have caused the college many problems this year and despite much pestering users will not install Sophos on their computers (we provide a centralised installation). Scanning all incoming mail for viruses is difficult due to the wide variety of techniques used to access it. However outgoing mail that is likely to be virus infected is sent via SMTP (i.e. from Outlook Express).

Using the packet mangling and NAT features in Netfilter it is possible to redirect all SMTP connections to a local college SMTP server. This will require no changes in the configuration of the users computer. The SMTP server uses software such as AMaViS to scan all mail. If a virus is found delivery of the message is stopped and both the user sending the message and the IT Officer are e-mailed to inform them of the situation. The virus infection can then be dealt with promptly and hopefully without data loss.

We are currently experimenting with this technique.

That’s All Folks…Thank you for listening!

If you have any questions or are interested in adopting the system I can be contacted on:

chris@corelli.new.ox.ac.uk

This presentation is available at:

http://www.new.ox.ac.uk/~chris/firepres/

Any questions now?