Skip to main content
Computing at Cornell • CIT Contact Center (HelpDesk)

Edge Access Control Lists at Cornell University

Daniel Adinolfi, CISSP
Senior Security Engineer, Cornell University IT Security Office

Abstract

In the summer of 2003, Cornell University created a campus-wide service whereby local support providers on campus could request the implementation of access control lists (ACLs) for their individual subnets. These ACLs are called "Edge ACLs", as they are configured on the Cornell network edge and not in its core. Creation of the back-end management tools and training for this service took less than a month, and the service gained significant popularity as soon as it was publicized. Less than six months later, over fifteen percent of Cornell's subnets have customized Edge ACLs applied to them, and more administrators are requesting new Edge ACLs every week.

Management costs for this service have been low. There has been no noticeable increase in load on routing gear because of the additional configuration involved with Edge ACLs. The service has also helped reduce the management costs for local support providers, as they are responding to fewer security incidents on their subnets while still maintaining necessary network services. Also, the demand for a dedicated campus firewall service has been averted, since most local support providers require only basic packet filtering to protect their subnets.

Cornell Overview

Cornell University is home to over 40,000 active network nodes. These systems reside on over 775 subnets, each its own virtual LAN. Approximately 110 of these subnets, comprising some 6000 nodes, are residential subnets (ResNet) for dormitories, Greek houses, and University-affiliated cooperatives. There are dozens of operating systems running on systems connected to the Cornell network, ranging from personal computer operating systems to specialized laboratory systems.

ACLs

Network packet filtering can be a useful part of a defense-in-depth information security architecture. This filtering can be done with dedicated hardware firewalls, host-based software firewalls, or advanced router configuration. Because of the physical architecture of the Cornell network and the difficulty in creating a single ruleset to satisfy every customer requirement, a centralized firewall service is not an option. Instead, Cornell offers a service where access control lists can be placed on individual VLANs. These ACLs are called "Edge ACLs" because they affect networks on the inner edge of the Cornell campus networks. (There are also "border" ACLs, which are configured on routers that connect the campus to the Internet, and "DMZ" ACLs, which are configured on our network core. These are used primarily as part of incident response procedures and are based only on IP addresses.)

Edge ACLs are applied only on a subnet's inbound traffic. (ACLs that regulate traffic leaving a subnet exist but are not part of this service. ACLs for outbound traffic, such as anti-spoofing filters, routing filters, and multicast filters are not part of this service.) Administratively, these ACLs should be considered static and programatic and are not to be applied on an ad hoc basis. (Border and DMZ ACLs can be used on an ad hoc basis.) Instead, local support providers work with the Cornell IT Security Office to formulate rulesets that will afford subnets with the greatest amount of protection without impeding regular operations on the subnet.

Rulesets can be based on IP address, IP protocol, TCP port, UDP port, or ICMP message type. There are some complexity limits enforced on the ACLs to reduce size and maintain manageability. For example, rules which block large, disparate network spaces are discouraged. Network administrators have asked to "block ResNet" (Cornell's residential networks) to their subnets but allow all other traffic. This would be impractical, since there are over 110 ResNet subnets on-campus spread over Cornell's three class-B subnets, meaning the ruleset would be at least 110 lines long. Also, the network numbering for ResNet changes each semester as new networks are created and older networks are changed. Because this creates significant management overhead, such requests would be denied and less complex rulesets would be developed.

Process

Edge ACL requests are sent to the Cornell IT Security Office via email. These email requests are entered into CIT's Vantive case tracking system and other network management databases. These Vantive cases are used to document the entire process from ACL creation to implementation.

The Security Office will then work with the local support providers responsible for the subnets in question to create an appropriate ruleset. During this part of the process, every effort is made to ensure the local support providers understand what they are doing to their subnet's traffic and how it could affect their users' workflow. Once the ruleset is formulated, it is applied to the router, and the documentation for the configuration change is completed.

Local support providers should expect a one-to-two business day wait for additions and changes to occur. If there is an urgent problem caused by the Edge ACLs, Cornell's Network Operation Center (NOC) is available at any time to remove the Edge ACL by request. The NOC cannot make changes to the ruleset. They can only remove it from the VLAN interface. All changes must still be done through the Security Office.

Demographics

As of this writing, there are approximately 140 departmental subnets with Edge ACLs applied. Most rulesets are blocking only Windows Networking (NetBIOS, RPC/DCOM, etc.) from off-campus. Some rulesets are far more restrictive, allowing only certain TCP and UDP ports to specific IP addresses on which a known service is offered. Each ruleset is custom-made based on the requirements set down by the local support providers responsible for the subnet in question. On ResNet, Windows Networking from the Internet is being blocked for all 110 ResNet subnets.

Benefits

Cornell's Edge ACL service offers a number of benefits for Cornell networks:

  • Customized packet filtering for individual networks gives network administrators increased control of the type of traffic that can enter their networks from without. Most network administrators rely on CIT to provide network services and maintain network equipment and configurations. The Edge ACL service enables network administrators control that they would previously have only had by building their own network infrastructure.
  • Campus-wide services are only affected by traffic rules if the local support providers allow. Network administrators can make policy decisions that only affect the workflow of their own networks. Policy decisions for one network would not affect policy decisions made on other networks.
  • There is no need for a change in architecture. Cornell uses subnet-based VLANs. Each router interface on the network edge services only one subnet at a time. ACLs are applied directly to individual subnets.
  • There is no need to purchase new hardware. The infrastructure needed to support Edge ACLs already exists within Cornell's Cisco routers. Also, ACL configuration can be directly and easily ported to upgraded hardware in the future.
  • Network Operations Staff are already familiar with the hardware operating system on which the Edge ACLs are configured (Cisco IOS). Very little additional training is needed.
  • Edge ACLs offer an additional level to a defense-in-depth security architecture. The ACLs compliment host-level security policies and procedures.
  • After initial set-up, management costs for individual network administrators are low. The administrator can rely on CIT to maintain the routing hardware and software configuration on that hardware, as well as backups of the configurations for disaster recovery. Requests for changes to existing ACLs can be made via email to the Security Office.
  • Since the introduction of this service, the number of systems compromised per day has decreased. For example, the ACLs on ResNet were implemented during July 2003. Historically, the majority of DMCA complaints that the University has received involved systems that were compromised through Windows Networking. The number of DMCA complaints involving ResNet systems during September 2003 has reduced by two-thirds compared to the number received during September 2002.

Shortcomings

There are some shortcomings with Cornell's Edge ACL service:

  • Since implementation is not automated, human intervention is required to change or add configurations. When describing the service to customers, the expectation of one-to-two business day delay on additions or changes needs to be set.
  • No logging is available to netadmins to aid in debugging. Logging is disabled by default but can be enabled and processed for short periods of time by Cornell's network engineering team. There is currently no facility for long-term log processing or analysis of ACL logs.
  • Edge ACLs do not satisfy all filtering requirements. Since UDP state cannot be tracked, ACLs cannot block UDP without affecting UDP-based services, such as DNS or NTP. Also, there is no application awareness within the Cisco routers. For example, non-passive FTP requires the opening of a data port back to the client, which will be blocked unless explicitly allowed. Without application awareness, certain applications my fail for end users or services protected by the ACL.
  • There is no automated error checking or optimization algorithms for complex ACLs. The logic of the rulesets must be checked by Security Office staff by hand. Fortunately, complex ACLs are rare.
  • There is a steep learning curve for some network administrators. Many network administrators do not have a background in network protocols such as IP, TCP, or UDP. Without this understanding, the effect of specific ACL rules may be missed until after the failure of a particular application.

Project Future

CIT hopes to add a number of features to its Edge ACL service in the near future. One enhancement will be to give network administrators the ability to add, view, and modify ACLs for their own networks through a web interface. Authentication, authorization and audit components would ensure network administrators would only have access to subnets for which they are responsible. Then, changes could be scheduled or implemented immediately.

Templates could be made available to assist less experienced network administrators in deciding what ruleset to apply to their subnets. Also, the Security Office would like to expand its consulting services to offer network administrators additional technical expertise for designing and implementing more complex rulesets.