Transcript The New College Firewall System

The New College Firewall
System
Chris Tromans
New College
[email protected]
http://www.new.ox.ac.uk/~chris/firepres/
Specification
New 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 Weeks
TCP 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
4
Root shell listener for many
exploits.
2091
1
Video Conferencing???
8000
1
Web Servers
8080
3
Web Caching
17300
1
Trojan 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 Solutions
Two 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 1
DHCP 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 2
The 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 3
The 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 1
On completion of the registration pages the users details are listed in the
administration interface.
The Administration Interface 2
Allowing 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 3
For 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 4
Access 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 5
Administrative scripts run daily which rotate IP address logs and remove
users whose university cards have expired. When a user is removed an email is sent to the IT Officer informing them that this has taken place so that
the paper records can also be disposed of.
System Hardware
Ordinary 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)
Firewall
UTP link from
EtherExpress
3COM Switch 3300
Media Converters
Fibre to College Staircases
Fibre link from
3C509B-FX
University Network
and the Internet
System Topology
The 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 1
The 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 2
A 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.
Performance
No 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 1
A 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 2
Traffic 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 Rules
The 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 Location
It 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-Mail
Credit 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:
[email protected]
This presentation is available at:
http://www.new.ox.ac.uk/~chris/firepres/
Any questions now?