Cornell Network Security: Big Red Doors?

Cornell Network Security: Big Red Doors? Prepared by R. David Vernon Introduction As part of the IT Architecture Initiative, the Office of Information Technologies (OIT) is producing a series of papers outlining directions in information technology architecture. In the spirit of RFCs, the papers are intended to facilitate understanding of and open dialogue about information technology trends at Cornell, with the ultimate goal of improving the utilization and interoperability of information technology services throughout Cornell. This paper and the others in this series can be found on the IT Architecture Initiative web site at http:\\www.cit.cornell.edu/oit/papers.html. Synopsis This document outlines key network design elements and targeted architecture at Cornell that generally impacts the secure delivery of information across Cornell s Campus and ocal Area Networks. It includes: Overview of the open philosophy of network services at Cornell. Four common types of attacks on network security. Current network hardware and inherent security risks at Cornell. Options for enhancing network security. Impact on departments and users. Current and recommended CIT service directions. Policy implications. Closing thoughts. Open Networking at Cornell Before any productive debate can begin about what comprises the best data network security services, processes, and tools for Cornell, there must be a clear understanding of the spirit or philosophy of networking at Cornell. For the purposes of this paper, networking refers to the data pipes interconnecting the campus and providing connectivity to the Internet. The focus herein is on the Campus Area Network (CAN) and Wide Area Network (WAN) commons that the larger Cornell community leverages for IP data/voice/video communications to interconnect local area networks. 1

Currently, the spirit of the Cornell network is open 1. This inclusive policy has historically rejected a big brother approach to block unaccepted forms of data communication between known entities. However, it is clearly understood that the open nature of Cornell s CAN and WAN services exposes clients within school and department local area networks (ANs) to greater risks. It is also understood that Cornell s open network policy does not abridge Cornell s obligation to avoid violating the rights of others by illegal use 2 of Cornell s AN, CAN and WAN resources. With a common understanding of the Cornell open yet risky network service, productive solutions can be forged that will mitigate risks while maintaining the value of open communication. Four Common Attacks on Network Security While it is beyond the scope of this paper to discuss all network security risks, the following sections describe four of the most common: Denial of service Spoofing Sniffing Service vulnerability exploitation Denial of Service A denial of service attack is any action that acts to shut down provision of or access to services. A denial of service attack may be simply flooding network connections with erroneous data. Or, it may be a targeted attempt to halt access to specific hosts. A plethora of strategies may be employed including, but not limited to, transmission of malformed packets designed to crash hosts, redirecting packets with false routing information to disrupt data flow, and processes designed to lock communication ports on application servers. Spoofing Spoofing is the act of transmitting data with a forged or stolen IP number or MAC 3 address noted as its source. Spoofing is used to gain access to data intended for others or as a means to launch anonymous Denial of Service attacks. Sniffing Sniffing means eavesdropping on data communications (similar to tapping a phone). Depending on the network design, an individual with little experience and cheap or free software could conceivably see all data transmitted. Sniffing can be used to collect unencrypted password information to gain access to hosts or to gather intelligence on what services are generally vulnerable for denial of service attacks, etc. Sniffing is of growing concern at Cornell in the near-term as many of the pending wireless ANs based on 802.11b technology are particularly vulnerable. 4 Service Vulnerability Exploitation The very nature of open networking allows unfettered access to clients attached. This open access provides an avenue for attempts by hackers to exploit client operating system and applications vulnerabilities to gain 1 Network services provided by Cornell Information Technologies. 2 In this paper, illegal use is defined as violating Cornell policy, local, state, or federal laws. 3 MAC address is the identification code assigned to the network interface on network clients. 4 See: http://www.cit.cornell.edu/oit/wireless.html 2

illegal access and control of the system. imiting access to hosts or host services, in order to protect the integrity of a host is the primary reason users elect to install firewalls. Simply put, you can have a world class "secure" network - but if your host is vulnerable the secure network provided little value. In addition it should be noted that many basic network services, i.e., DHCP servers, DNS servers and even Network firewalls are by definition network clients! While a detailed review of client security is beyond the scope of this paper, it is important to understand client vulnerability is one of the main issues driving demand for more restrictive network infrastructures 5. Current Network Hardware and Inherent Risks at Cornell Cornell s data network is comprised of a central backbone service supporting hundreds of local area networks. The core backbone is made up of redundant 1,000 MB Ethernet over fiber-interconnected Cisco routers. In turn, the backbone supports a mix of Category 3/5 twisted-pair copper-based shared 10 Mb, switched 10 Mb and switched 100 Mb Ethernet ANs located within buildings across the campus. 6 The Cornell network is connected to the Internet with 2 OC3 7 links. 5 For more information about client security, and general security information see: http://www.cit.cornell.edu/security/ 6 See http://www.cit.cornell.edu/oit/cornell_network_futures.pdf 7 An OC3 has a raw capacity of 155 MB/s, usable capacity will be less. 3

4

AN security at Cornell is not uniform. Cornell s Campus Area Network in aggregate includes a mix of shared Ethernet and switched Ethernet 8 ANs. A mix of secure and insecure structured twisted pair wire plants are installed in buildings. These variations mean that the security of the network depends on the particular combination of hardware and media encountered by a given communication and the secure or insecure state of the hosts along the way, The obvious implication is that no one should assume that the transmission of information on campus is secure against sniffing. 9 Of course, the locations with locked wire closets and switched Ethernet are more secure than those without but a communication that leaves these one off pockets of relatively secure ANs is not necessarily going to another relatively secure AN. Though the mantra of secure network design is: you re only as secure as your weakest link there is some solace in knowing that Cornell s CAN backbone is physically secure when compared to many campus ANs. Access to backbone router hardware and the fiber that interconnects them is limited vigilantly. This fact greatly reduces the probability of illegal access to information. A number of initiatives and rules are already in place to mitigate the remaining risks. There is an active project to replace all existing shared Ethernet hardware with switched Ethernet hardware. A pilot study is underway to review the costs of replacing the insecure twisted pair wire plant with a secure wire plant. 10 Routed backbone resources can and do implement router rules that limit the scope of spoofing, sniffing and Denial of Service activity on campus. 11 But even if we end up with a relatively secure network plant it is not currently designed to limit access to connected clients. Since it is obvious that clients and servers on the Cornell network are often direct targets for attack, any notion of broader network security must, while exploring network security enhancement tools, work to secure the client as well. 12 Options for Enhancing Network Security Before discussing the options available to enhance network security at Cornell, it s important to note that many of these tools will restrict the open nature of network communication that currently exists. It is unfortunate but true that increased security often equates to diminished access. In addition to enhancing the hardware infrastructure of the campus network, there are systems available to help reduce the chance of network clients being attacked or compromised. These systems include: Advanced Network Authentication Encryption, combined with VPNs and VANs Firewalls 8 Switched Ethernet ANs have traditionally been considered more secure than shared Ethernet ANs because Ethernet switches do not by default broadcast data to all connected hosts. However, it is important to note that switched networks can be easily tricked into broadcasting data to unintended recipients. For further information, try an Internet search using the terms: Sniffing or ARP redirect. 9 Sniffing is the use of a protocol analyzer to capture and interpret data being transmitted on a network. 10 See: http://tie2001.com 11 Cornell Routers block spoofing, invalid routing, No Directed Broadcast, in addition short term AC are used to respond to network attacks in progress. 12 Detailed review of client configuration issues is beyond the scope of this paper. For additional information about client security at Cornell see: http://www.cit.cornell.edu/security/ 5

Network Authentication Clients on the Cornell campus network are vulnerable to some degree simply because of the large number of anonymous people with potential access to network. One possibility for mitigating the risk is to develop a network port-based authentication service. Network port-based authentication is a process that forces users to provide authentication to the physical network before they can send or receive data. There are developing standards for network port-based authentication, these are: 802.1x 13 and 802.11e. 14 The pragmatic value of port-based authentication may be limited because Cornell s network is open to a world that doesn t require an authentication system. Therefore, we would only know who was using the network if they were coming from a Cornell port / wireless hub. But this idea should not be simply dismissed. Wireless networking does afford a new ease of sniffing (eavesdropping) and the notion of limiting access to our wireless space to only legitimate members of the Cornell community via a port-based authentication system is intriguing. In addition, an application-based authentication system could be made the core service of a larger network authentication scheme for Cornell. CIT is currently exploring these possibilities. 15 Having such a system in place, as long as it did not burden the Cornell user with an overly officious and prohibitively cumbersome process, may be seen as a valuable service by the Cornell community at large. Of course, this assumes all members of a community that controls given parts of the network would agree to provide hardware capable of supporting port-based authentication. This general area is sure to also stimulate interesting policy dialog as one might easily envision limiting access to sensitive institutional information (student records, etc.) to network locations with network-based and application-based authentication abilities. Encryption, VPNs and VANs Network hardware and software is available that encrypts point-to-point data streams. The value of encryption is that it eliminates the ability to interpret data illegally accessed on an insecure network or compromised host. 16 In turn, encryption tools are often combined with the Virtual network forging ability of many types of network hardware. The most common of these is known as a "Virtual Private Network" or VPN. VPNs are used to tunnel 17 communications through the open routed IP networks. VPN tunneling tools can be part of a firewall services suite or client software. Most often, encrypted VPNs are used to secure information that traverses public and insecure networks to remote sites whose hardware is owned and controlled by the same entity. In addition to VPN services, many network switches and routers in use today allow the creation of Virtual ocal Area Networks, or VANs. Theoretically VANS could be combined with client encryption applications and firewalls to create secure virtual ANS within a given network. Of course the concept of creating a myriad of VANs, and/or VPNs combined with encryption solutions for Cornell at large implies significant hardware and support costs. In addition, it should be noted that there are a number of application-based encryption and authentication suites that can provide equal data protection. One of important note under active consideration by many national organizations is PKI. 18 Quite possibly PKI affords better utility because it allows authenticated data to be securely sent to locations via networks outside Cornell's control. 13 http://www.manta.ieee.org/groups/802/1/pages/802.1x.html 14 http://grouper.ieee.org/groups/802/11/ 15 Targeted subject area for a future Information Technology Architecture paper. 16 It should be noted that encrypting data streams offers little value if the clients sending information store unencrypted copies, and in turn, that host becomes compromised. 17 See: http://www1.ietf.org/ids.by.wg/l2tpext.html 18 See: http://www.pkiforum.org/ http://middleware.internet2.edu/pkilabs/ Also note that SSH is broadly used today to provide data encryption. 6

Firewalls More than the other tools noted, firewalls represent a network security enhancement that has been or is being considered by many AN administrators for deployment at Cornell. Firewalls are tools to limit access to hosts and hosts services that are connected to the Internet. Firewalls can protect single systems, or multiple systems connected to ANS / CANS. The driving concept is: for certain users, limiting access to hosts to enable greater host security outweighs the "cost" of reduced "open" network access. There are many types of firewalls in use today, and because their deployment at Cornell is increasing, a high level review is included here. 19 The following topics are briefly discussed: Router or Bridge enabled IP Address and Port Packet Filtering IP Address and Port Packet Filtering + Content Filtering IP Address and Port Packet Filtering + Content Filtering + Stateful Inspection Proxy/Application Gateway Network Address Translation (NAT) Devices Traditional Routers as Firewalls IP Address and Port Packet Filtering: This class of firewall inspects the IP headers of a network packet to decide how to treat that packet. Packets can be dropped or rejected depending on source or destination address, as well as source and destination ports. IP Address and Port Packet Filtering + Content Filtering In addition to inspecting IP headers, content filtering firewalls can inspect and block based on data patterns within a TCP, UDP 20, etc. packet. Because the whole IP packet is searched this process requires much more processing power. Generally, the more complex the inspection rules, the more CPU intensive and expensive the process becomes. IP Address and Port Packet Filtering + Content Filtering + Stateful Inspection This type of firewall performs a validation test on the transaction characteristics of given protocols and maintains a database of legitimate active communications once established. Proxy/Application Gateway A proxy server or application gateway is a service that terminates a session at the firewall (proxy) and then establishes a new connection at the receiving end of the communication. For each service, a subset of "allowed commands for a given application, such as FTP or Telnet, can be specified and all other communication attempts can be blocked. Because proxy servers are application specific they are only available for limited services and are often high in cost. 19 Detail outline of firewall types is well beyond the scope of this paper. There are several books published on firewalls, one to consider is: Building Internet Firewalls from O Reilly press. 20 UDP = User Datagram Protocol. UDP is often used as a low overhead and therefore fast transport of data as an alternative to TCP on low error rate modern IP networks. 7

Network Address Translation (NAT) NAT devices are often used as limited firewalls, or NAT is often a service that is provided by firewall products. NAT is a means to support multiple internal IP devices with a single advertised IP address. The nature of NAT allows network administrators to obscure the visibility of clients on a given AN. 21 Traditional Routers as Firewalls Most Routers have the inherent ability to perform basic IP packet filtering. This is often expressed as access control lists (ACs) configuration. Unique ACs can be set for each Subnet within a routed network at Cornell. However, complex ACs impact router performance. CORNE NETWORK DESIGN AND FIREWA DEPOYMENT ISSUES Firewall utility and impact is directly affected by network design, services, and firewall placement within the network. The following conceptual models are not intended to prescribe the best, correct, or only solutions, they are presented to stimulate broader discussion on how Cornell might envision new network service offerings, these include: Traditional firewall deployment at Cornell. Custom VAN / VPN offerings in conjunction with firewall placement. Parallel secure and insecure network infrastructure. 21 http://www1.ietf.org/ids.by.wg/nat.html 8

Traditional Firewall Deployment at Cornell AN A DEFAUT CAMPUS AC FITER 22 WAN F I R E W A CAN F I R E W A SECURE AN B ADDITIONA FIREWA FITER RUES AND PROCESSES AS DEMANDED BY SUBNET Note: imited local firewall services could be provided by custom AC configuration by subnet. Or more advanced services could be provided by locally deployed firewall hardware. 22 As noted earlier, Cornell routers now have basic AC list to limit IP spoofing, etc. Additional default filters could be explored. 9

Custom VAN / VPN Offerings in Conjunction with Firewall Placement AN A WAN F I R E W A CAN F I R E W A Secure VAN / VPN AN B Note: VAN / VPN could span multiple physical networks or parse a single network into secure and unsecured regions. In addition VPN hardware is often used to encrypt all data flowing between ports on a given VPN. VAN support requires network hardware that supports multiple concurrent VAN configurations. Not all locations at Cornell have this equipment installed at this time and there are limits to the maximum number of VANS supportable. Traditionally VANS are not used to provide encrypted services and assume client encryption of data streams. The pending core and edge upgrade will extend the potential for VAN deployment at Cornell. 10

Parallel Secure and Insecure Network Infrastructure ADVANCED FIREWA SERVICES Secure AN A F I R E W A Secure CAN Insecure AN A WAN F I R E W A Insecure CAN Secure AN B DEFAUT CAMPUS AC FITER Insecure AN B Note: Parallel services assume a large constituency at Cornell would desire a predetermined suite of universal restrictions applied to a campus-wide network service. For example, one data jack per office face plate would allow access to the open campus network, while another data jack on the faceplate would allow access only to the restricted campus network. Options to explore include non-routable network behind a campus firewall / NAT service, secure VAN, and parallel hardware deployment. Generally the assumption that Cornell could place a single central firewall to protect all campus ports is probably not feasible. While limited controls to protect us from universally understood threats (spoofing, etc.) do make sense, to assume there is a much larger list of universal rules that all at Cornell would agree to simply is not a realistic view. 11

Recommended Service Directions It s evident that there is a rapidly growing demand for improved network services at Cornell. To date, CIT has not offered enhanced network security / firewall placement as a campus service. This has caused many departments to seek and deploy their own solutions. However, there is a growing belief that campus would benefit if CIT provided enhanced network security services for departments in need. Some of the driving reasons behind this new service desire are: Many departments do not have the expertise to deploy firewall services. Uncoordinated firewall and NAT device deployment have the potential to fracture delivery of network service at Cornell. For example, it might block access to administrative services or future services such as video conferencing and multicasting. There is potential for cost savings with a unified deployment of security tools. It might reduce the number of eyes on data collected, or data able to be collected by installed firewalls. To respond to this growing service need, CIT might consider offering enhanced network security services including, but not limited to: Providing custom router AC lists for department subnets. Installing and maintaining dedicated department AN firewalls. Enabling VANs and or VPNs to support creative firewall placement and to provide encrypted pipes between locations throughout the Cornell camps. Providing enhanced network authentication tools, such as 802.1X and 802.11n Exploring deployment of general network associated security enhancements, such as IPsec 23, IPv6 and SecureDNS. 24 Exploring site license agreements for personal firewall tools. Explore implementation ramification of workstation operating system based VPN applications. 25 Exploring the installation of advanced intrusion detection tools. 26 Publish best practices firewall configuration guides. There is sure to be a fair amount of debate as to what represents the best suite of secure network services to offer. And it is important to note that enabling these services are not without costs. For example, the notion of providing custom AC lists or firewall configurations for over 700 subnets is a daunting prospect. Not only would these create an administrative challenge that would require new staffing, router AC lists impact the performance of the routers, thus degrading the larger backbone capacity. Another concern that any central IT organization needs to bear in mind when exploring firewall tools is to make sure that the cost of these tools is appropriately placed upon those who require protection. Capitalizing a large, central network security tool suite that is billed to all through raised network rates may be perceived as unfair to users who are well-served by an open internet connection. This is not to say that 23 See: http://www.ietf.org/html.charters/ipsec-charter.html 24 http://www.ietf.org/html.charters/dnsext-charter.html 25 http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windows2000serv/ deploy/confeat/sectech.asp 26 Firewalls are systems to block unwanted communications. Intrusion detection tools are systems that monitor data flow and provide network administrators real time information that an attack is in progress or pending. 12

there are NO security expenses that should be perceived as part of the common good, only that a balanced approach may be best received by the Cornell community. Balancing the Issues To some degree Cornell is faced with a catch-22 when addressing network security. On one side there is a long history and valid mandate for Cornell s central IT organization (CIT) to provide open networking to all at Cornell. Indeed, the concept that the central IT organization would unilaterally determine and enforce who could talk to whom, and how these entities would communicate might raise hackles throughout Cornell. However, this open ethos has now fostered an equally unsettling specter: the potential for a fractured collection of networks each firewalled off with esoteric rules. Each department might have tools that not only control what data is allowed, but also have the ability to log and look at all data that flows through their respective firewalls. These statements are not meant to infer a direction; they are simple facts. Clearly there is a legitimate need for departments and individuals to install enhanced network security tools. However, the bottom line is that Cornell is a community of schools and departments that share information, and all have the same collective rights to assured levels of privacy. And one would hope that at an institution as great as Cornell, all should expect a network infrastructure capable of predictable and rich end-to-end services. So what should the Cornell community do? The art is to find the balance. Paramount in the quest to find this artful balance is the process of engaging the users of network resource at Cornell to assure that the final solution is one that meets their divers needs! The final forging of this balance is clearly beyond the scope of this paper, but there are apparent issues and directions to pursue. Minimally, these include: Reaffirm nature of networking services that Cornell believes is critical to meet its teaching and research mission though open dialogue. Define Policy (privacy, maintenance of logs, etc.) and configuration standards for firewall installation and operation regardless of owner. Define and encourage CIT services that enable the mission and policy. Closing Thoughts Many might decree it a quixotic quest to attempt to holistically forge a secure network infrastructure at Cornell. This perspective may well be correct, thus placing the true burden solely on secure clients that encrypt all data transfers. However, it is a mistake to simply dismiss the trends and fail to coordinate the solutions at hand. The bottom line is that Cornell is going to see a growing demand for and deployment of network security tools. This will be driven not only by Cornell s perceived security needs, but also by national pressures that will be placed on open networks like Cornell s to limit use of those networks as a launching point for attacks across the Internet. Unfortunately, left unchecked, these new security tools begin to fundamentally limit the richness of network services at Cornell. So the question now is not if but how to best enable improved security in a way that does not diminish the greater good of open networking at Cornell. OIT believes one effective means to meet this goal is to offer a sensible and valued range of network security resources. But it is also evident that new services provided by CIT are not the only prerequisite. In addition, all at Cornell must strive for and participate in the forging of a uniform approach to evolving network security paradigms. 13