Computing & Networking Services Computing & Networking Services Phone 416 978-4597 255 Huron Street, Room 345 Fax 416 971-2085 Toronto, Ontario, M5S 3J1 email @utoronto.ca The Open Source Firewall Pilot Project Recommendations Monday, March 04, 2002 Table of Contents Introduction 4 Executive Overview 4 Needs Identification 5 Security Perspective 5 Service Perspective 6 Evaluation 7 Goals 7 Evaluation Scope 7 Evaluation Methodology 7 Deployment 8 Operations 9 Effectiveness 11 Recommendations 12 Recommendation 1: Departmental needs assessment 12 Recommendation 2: Simple UofT Configuration 12 Recommendation 3: Firewall Friendly Network Demarcation Device 13 Recommendation 4: Custom Configuration Support 13 Appendix A 14 Evaluation Team Members 14 Appendix B 15 Technical Description 15 Appendix C 16 Glossary of terms and acronyms 16 Section 1 Introduction Executive Overview A firewall is one of the tools used to secure a computer network. A firewall can prevent unwanted access to departmental systems while preventing local systems from attacking systems on other networks (on the other side of the firewall). Unfortunately, firewalls (like other security systems) require on-going monitoring of their performance to ensure that they do not unnecessarily restrict access to important computer resources while preventing unwanted access. The open source firewall developed by CNS is based on a widely accepted technique called packet filtering. Each packet going through the firewall is evaluated against rules set by the administrator and is either passed along or rejected. The firewall logs its activities to help the administrator understand whether there has been an attempted attack. To reduce administrative costs this firewall can be administered locally (from the console) or remotely (using a secure connection). It can also be configured to watch a particular computer for new rules. No firewall can prevent malicious people from exploiting known vulnerabilities in software (as buffer overflow exploits and worms do). This firewall is no different. What it does is to ensure that the traffic entering and leaving the secured LAN is talking to the correct applications on the correct computers. A crucial point about this firewall is that it uses a low-level approach to configuration; the administrator must analyze his or her needs at the level of ports and packet types in order to choose the required permissions. This is a two-edged sword: it results in a relatively inexpensive product but it requires a certain amount of expertise to administer. Commercially available products can simplify some configuration task by allowed the administrator to simply choose from a set of applications to be allowed/disallowed but these products typically cost many thousands of dollars. Adding this functionality to the CNS developed firewall would be hugely expensive, We are recommending that CNS act as a supplier of the technical expertise for deploying and managing this firewall to the University of Toronto's computing community. We are also recommending that CNS provide a service to assist departments in performing security evaluations of their networks. Needs Identification Security Perspective Current Practice: Departments routinely maintain sensitive and confidential information on Internet connected computers. Departments routinely deploy business systems that are critical for the day-to-day operations of the unit on Internet connected computers. The built-in security features of typical departmental computers are inadequate to protect them from mischief and malice when connected to the Internet. The Threats: Theft or corruption of important data. The consequences of compromised data can range from a loss of staff and student productivity, to public embarrassment (and liability). Denial of service. All computer systems have vulnerabilities that can be exploited to cause the computer to work poorly or not at all. Software is widely available on the Internet that exploits these vulnerabilities, and these programs are routinely directed at University computers. How a firewall helps: Any requests from non-trusted hosts can be rejected; this technique can be used to provide a simple level of confidentiality, and it can be used to prevent Denial of Service attacks, and other known intrusion techniques. Often it is necessary to allow traffic (e.g. SMTP, IMAP) from non-trusted hosts. In these cases, the firewall will not prevent certain types of attacks; for instance, it won't protect against viruses in e-mail, nor will it stop attacks which use buffer overruns. Service Perspective Successful firewall deployment and operation requires a very precise set of technical networking skills and a concerted effort to remain current on the "state of the art". This is necessary because of the technical complexity of the problem, the sophistication of the attacks being crafted, and the evolving nature of attacks. Departments' capacities to deploy and operate firewalls vary through the university. Departments with firewalls Departments with firewalls have engaged in a self-assessment, which determined the need to protect their systems. As the complexity of the problem and the sophistication of the threats increases, many of these departments are experiencing unacceptable costs in terms of providing the level of technical support within their own organization or via a commercial service provider. Organizations experiencing this are interested in avenues that consolidate security support (thereby reducing individual costs). Departments without firewalls In many areas of the university, some departments with the competence to deploy firewalls have not done so, perhaps based on a perception that: Their systems and data are not a risk. Firewalls unacceptably compromise academic freedom. Installing/maintaining a firewall would be too great an additional workload. These perceptions may be quite accurate, in that they are based on a thorough understanding of the values and risks to the department, and because most system administrators review their environment periodically, with a view to responding to the increasingly hostile attacks that come from the Internet. In departments without the competence to deploy firewalls there is often: A lack of awareness of the risk their systems are exposed to A lack of expertise to carry a project forward The perception that the cost of commercial firewall products is too much Evaluation Goals 1.Evaluate the suitability of the CNS-configured open source firewall for use by university departments. 2.Prepare recommendations on the best way departments can deploy and support this open source firewall. Evaluation Scope This evaluation and recommendations are limited to an assessment of the open source firewall developed by CNS. A comparison with other firewall technology or products is not within the evaluation scope. This evaluation assumes the firewall is the sole access point to the protected network (e.g. there is no dial in capacity on the protected LAN). Evaluation Methodology The evaluation consisted of four major activities: Simcoe Hall Firewall Pilot Project School of Continuing Studies Pilot Project Demonstrations at the Faculty of Dentistry and CNS offices Open Source Firewall Evaluation Group Simcoe Hall Firewall Pilot Project CNS staff installed an open source firewall using the default Simple UofT Configuration on the Simcoe Hall network. School of Continuing Studies Pilot Project CNS staff installed an open source firewall using a highly restricted configuration to protect the production SCS registration server. Demonstrations CNS staff demonstrated the installation and operation of the open source firewall to the Open Source Firewall Evaluation Group. Open Source Firewall Evaluation Group Appendix A lists the members of the group. This group consulted with CNS staff and made recommendations on how CNS could best support an open source firewall. Deployment Hardware Requirements At a minimum, the firewall machine should be equivalent to a Pentium II, with 64 Mb of RAM, a 5Gb hard drive, and 2 PCI NICs; in addition, the hardware must be supported by FreeBSD (see http://www.freebsd.org/relnotes/4-STABLE/hardware/i386/). Required processor speed will be dependent on IP traffic. Required hard drive capacity will be dependent on the desired degree of log retention. Host Setup A step-by-step Installation Guide is provided with the distribution package; this covers the installation of both FreeBSD and the firewall software itself. The firewall software installation has an option that allows the creation of a second firewall machine as a hot spare. The installation can usually be accomplished in less than two hours. There was general agreement in the evaluation group that the installation would pose few problems, because of the straightforwardness of the process itself, and because of the completeness of the Installation Guide. The default filtering rules allow all traffic to pass between the "inside" and the "outside". All access to the firewall itself is blocked, except for SSH access through a port, and via hosts, chosen during the install; this SSH connection is used for remote administration. Operations Administrative Functions There are several classes of function available: System configuration and control, rebooting, etc.) System summary, IP settings, date and time Reboot, shutdown, exit Group management (i.e. Groups of IP nos.) Show, edit, add, delete groups Permissions and rules (see Creating new filter rules) Show, add, delete permissions Update rules (after changing permissions) Show rules Importing rules (see Creating new filter rules) Add, delete, view URLs for normal rules Add, delete, view URLs for emergency rules Logs and mail management Review or watch current or archived log (complete) Review or watch current or archived (denials only) Manage email addresses (for recipients of notifications) Send log or archive to recipients (entire or summary) View log summary Maintenance Save configuration to remote site, floppy, or locally Restore configuration from remote site, floppy, or locally Configure ports for sshd, snmpd Manage maintenance list (tracking) Administrative Interface The interface consists of a set of text menus; these have built-in help, activated by entering either an empty response or question mark. Remote Administration The firewall can be configured to accept SSH connections from specific hosts, so that an administrator can log in and make changes. Logs, Alerts, Reporting All traffic is logged; log entries for outbound traffic can be marked selectively, using the RECORD permission. Logs are rolled and compressed daily, and logs and/or summaries can be emailed to specified addresses. Creating new filter rules The Administrative interface is used to define permissions which control traffic flow, based on IP address (or group of IPs) and port number; there are four types of permission, each of which is a macro which expands to a set of IP firewall rules. The defined rules may be modified (presumably to handle temporary situations) by downloading (importing) another set of rules from a specified URL. These can be normal rules, which augment those already defined, or emergency rules, which replace them. The syntax and semantics of the permissions is beyond the scope of this report; in fact, there was a consensus that it would be difficult for an inexperienced administrator to fashion a set of permissions that would achieve a particular desired effect without assistance. It should also be pointed out that the approach used in configuring this firewall is a low-level one. For instance, one cannot just pick from a set of applications to be allowed; one must know which ports and packet types an application uses, and establish permissions based on them. Effectiveness Failure recovery If a second machine has been configured as a hot spare, it will automatically take over if the primary fails, and become the primary; when the old primary is re-started, it becomes the hot spare. Rule changes made on the primary are automatically mirrored on the hot spare. This facility was felt to be a valuable and convenient feature. If there is no hot spare and the primary fails, connectivity between inside and outside can only be restored by bypassing the firewall. Performance Throughput The effective performance can be measured by testing with the firewall in and out of the network path. No quantitative measures of this sort have been made to date; however, a comparison of the throughput of several workstations, only one of which was behind a firewall, showed no apparent differences. The pilot projects showed that the firewall is transparent to users. Security Firewalls using this technology have been in use, here and around the world, for years. They have stopped known attacks and prevented unauthorized probing of the secured network. No strenuous deliberate attacks have been carried out against this firewall; however, the regular sweeps have disclosed no vulnerabilities. By way of example: The installation of the firewall on the Simcoe Hall network eliminated attacks (LPR and others) which had previously been experienced While some 60 servers on campus were infected by the Code Red Worm, both the Simcoe Hall network and the CANS network (also behind one of these firewalls) were unaffected, even though the servers there did not have the protective patch applied Section 2 Recommendations Recommendation 1: Departmental needs assessment A firewall is not a silver bullet solution for departmental security needs. It does not protect against virus attacks for example. One of the clear recommendations many departmental system administrators made was that CNS provides a service that would help departments to assess their security requirements, develop a comprehensive policy, and deploy the technology. It is recommended that while the technical issues cross many disciplines, CNS should offer a single organization point of contact to co-ordinate the work. The assessment process should consider such issues as: 1.What assets are you trying to protect and how important are those assets to the day-to-day operation of your department/division? (e.g. user data, servers) 2.What internal activities are you trying to prohibit/limit and what kind of impact will it have on the usefulness of your department's networks? (e.g. stop a user from implementing an unauthorized ftp server) 3.How important is a firewall in your organization? (e.g. How much capital/operating budget/time is your organization willing to spend to protect its network assets?) It is recommended that departmental self-assessment continue to be the mechanism by which the decision to deploy a firewall is made. CNS's role should be limited to providing advice and assistance when requested. Recommendation 2: Simple UofT Configuration CNS prepared a simple firewall configuration that was tested and found to be effective in the Simcoe Hall network. This configuration has the following features. 1.All inbound traffic from UofT networks is accepted. 2.All unrequested inbound traffic from non UofT networks is rejected 3.All outbound traffic from the departmental network is accepted. Deployment In testing (with compatible hardware) it took less than 4 hours to establish this configuration. It is recommended that CNS provide a service by which this simple firewall configuration is installed on compatible hardware (provided by the department). Operations During testing, CNS collected log information from the firewall and advised the departmental system administrator when significant events occurred. CNS spent about 10 minutes per firewall a month providing this service. It is recommended that CNS provide a service to departments, monitoring and advising departmental system administrators on the operation of a default configured firewall. Recommendation 3: Firewall Friendly Network Demarcation Device A typical situation is for departments to use the ethernet ports on the switch that serves as the CNS network demarcation point. When connecting the firewall, these ports need to be abandoned since the firewall must sit between the network demarcation point and the local network. It is recommended that CNS identify and support a network demarcation device that allows departments to maintain their existing switch inventory. Recommendation 4: Custom Configuration Support The technology used in the open source firewall is applicable to many departmental situations; however the simple configuration used at Simcoe Hall will not always be suitable. 1. Perimeter Firewall. In certain situations the simple configuration may need to be restricted to specific UofT addresses and/or include specific non-UofT addresses. There may also need to be support for network applications that are not currently recognized by the rule set. 2. Server Network Segment. For departments operating critical servers it may be necessary to configure a highly restricted firewall limited to specific IP address and specific applications. In any situation such as these, in which additional permissions must be defined, proper configuration of the firewall will require reasonably extensive knowledge of the IP protocol, including how applications and services use ports; familiarity with DNS will also be important. Departments not having people with such skills would benefit from drawing on CNS's technical expertise to create the additional configuration. It is recommended that CNS have a mandate to provide custom configuration and management services, and to recover the costs for delivering these services. Appendix A Appendix A Evaluation Team Members Name Department e-mail Address Brad Armstrong UTCNS brad.armstrong@utoronto.ca Ferucio Ciobanu UTM ferucio@utm.utoronto.ca Harpreet Dhariwal APSC harpreet@ecf.utoronto.ca Peter Eden UTCNS peter.eden@utoronto.ca Al Fogels Medicine al.fogels@utoronto.ca Ab Gehani FIS gehani@fis.utoronto.ca Jeremy Graham Hart House j.graham@utoronto.ca Bruce Huang Geography huangb@cirque.geog.utoronto.ca Erik Ivanenko F&S erik.ivanenko@utoronto.ca Steve Jones UTCNS steve.jones@utoronto.ca Paul Kern UTCNS pkern@cns.utoronto.ca James Lu Pharmacy/Nursing james.lu@utoronto.ca Asif Majid SCS asif.majid@utoronto.ca Michael Mares Medicine (Teaching Labs) m.mares@utoronto.ca Nebojsa Marusic F&S neso.marusic@utoronto.ca Sue McGlashan UTM smcglash@utm.utoronto.ca Gian Medves Law gian.medves@utoronto.ca Greg Mount Dentistry greg.mount@utoronto.ca Gord Russell UTCNS gord.russell@utoronto.ca Sujee Sabanathan Speech Pathology sujee.sabanathan@utoronto.ca Jun Shen Career Centre j.shen@utoronto.ca Evan Sidoriak APSC evan@jpint.utoronto.ca Chris Sparks New College c.sparks@utoronto.ca Ian Thomas UTCNS ian.thomas@utoronto.ca Do Anh Vu UTM advu@utm.utoronto.ca Andrew Wang UTM ajwang@utm.utoronto.ca Hugh Zhao Astronomy zhao@astro.utoronto.ca Appendix B Appendix B The Open Source Firewall Technical Description uses vanilla FreeBSD-4.3 [1] configured as a filtering ethernet bridge (the kernel configuration includes the IPFIREWALL and BRIDGE options) uses FreeBSD's IPFW for packet filtering (IPFW is the native FreeBSD equivalent of ipfilter or ipchains; it has most of the same basic features) has UCD's SNMP to allow for remote monitoring (this is a convenience option) has sshd to allow for remote shell (listens on a port other than 22/tcp) uses the old UofT zmailer (smtpserver disabled) for mailing reports and digests uses ntpd to synchronize with campus clocks custom startup and monitoring scripts allow for parallel hot-spare systems; hot-spare granularity is 1 minute (it depends on cron to run the scripts) uses a custom admin interface, a screen menu built on top of scripts, which are designed to try to make it easjier for those not familiar with FreeBSD basic assumptions of the admin interface : there are 2 interfaces, one on the "inside" and one on the "outside" all packets from systems "inside" can pass to the "outside" [2] an administrator would be mostly concerned with packets from "outside". some base IPFW rules are not controlled via the admin interface (to make it less likely to be "locked out" of the firewall) [1] plus a minor syslogging patch [2] except for systems or rules marked as "ignored" Appendix C Appendix C Glossary Glossary of terms and acronyms Buffer overflow A buffer overflow occurs when a program or process tries to store more data in a buffer (temporary data storage area) than it was intended to hold. This overflowed data could be an executable program or instructions understood & executed by the attacked computer. DNS Domain Name System: a hierarchical system of organizing the internet into human understandable names (e.g. cns.utoronto.ca) and providing a way to convert those names into IP numbers. IMAP Internet Message Access Protocol: used to query email servers for new email. IP Internet Protocol: handles moving data between computers. IP numbers are uniquely assigned to each device on the internet (e.g. 128.100.103.1). LAN Local Area Network: the computers and devices sharing a common connection to another network. NIC Network Interface Card (aka ethernet card) PCI Peripheral Component Interconnect: interface used to attach peripheral devices (e.g. a network card) to a computer's motherboard. Port An address used by a particular TCP aware application (e.g. DNS servers communicate on port 53). SMTP Simple Mail Transmission Protocol: used to send email. SNMP Simple Network Management Protocol is used to manage and monitor network devices. SSH Secure Socket Shell: a way to encrypt communication between two computers (usually UNIX machines). TCP Transmission Control Protocol: a connection-oriented protocol, it splits & reassembles communication packets. URL Uniform Resource Locator or the internet path (e.g. http://www.utoronto.ca/wts). Worm A self-contained program that can propogate itself from one computer to another.