Office of
Information
Technologies

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.   

---

pdf version

Cornell Network Security: Big Red Doors?

Prepared by R. David Vernon

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 Local 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.

Currently, the spirit of the Cornell network is "open"(network services provided by Cornell Information Technologies). 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 (LANs) 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 of Cornell's LAN, CAN and WAN resources (in this paper, "illegal use" is defined as violating Cornell policy and/or local, state, or federal laws).

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 address noted as its source (MAC address is the identification code assigned to the network interface on network clients). 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 LANs based on 802.11b technology are particularly vulnerable.

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 illegal access and control of the system. Limiting 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.

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 LANs located within buildings across the campus. The Cornell network is connected to the Internet with 2 OC3 links (an OC3 has a raw capacity of 155 MB/s, usable capacity will be less).

LAN security at Cornell is not uniform. Cornell’s Campus Area Network in aggregate includes a mix of "shared" Ethernet and switched Ethernet LANs*. 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.
* Switched Ethernet LANs have traditionally been considered more secure than shared Ethernet LANs 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".

The obvious implication is that no one should assume that the transmission of information on campus is secure against "sniffing" (sniffing is the use of a protocol analyzer to capture and interpret data being transmitted on a network). Of course, the locations with locked wire closets and "switched" Ethernet are more secure than those withoutout -- but a communication that leaves these "one off" pockets of relatively secure LANs is not necessarily going to another "relatively" secure LAN.

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 LANs. 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.
• Routed backbone resources can and do implement router rules that limit the scope of spoofing, sniffing and Denial of Service activity on campus (Cornell Routers block spoofing, invalid routing, No Directed Broadcast; in addition short term ACL are used to respond to network attacks in progress).

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.

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 VLANs
• Firewalls

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 and 802.11e.

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 (targeted subject area for a future Information Technology Architecture paper).

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 VLANs

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 (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). 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 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 Local Area Networks, or VLANs. Theoretically VLANS could be combined with client encryption applications and firewalls to create secure virtual LANS within a given network. Of course the concept of creating a myriad of VLANs, 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 (also note that SSH is broadly used today to provide data encryption). Quite possibly PKI affords better utility because it allows authenticated data to be securely sent to locations via networks outside Cornell's control.

Firewalls

More than the other tools noted, firewalls represent a network security enhancement that has been or is being considered by many LAN 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 LANS / 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 (detailed 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).

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, etc. packet (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). 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.

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 LAN.

Traditional Routers as Firewalls

Most Routers have the inherent ability to perform basic IP packet filtering. This is often expressed as "access control lists" (ACLs) configuration. Unique ACLs can be set for each Subnet within a routed network at Cornell. However, complex ACLs impact router performance.

CORNELL NETWORK DESIGN AND FIREWALL DEPLOYMENT 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 VLAN / VPN offerings in conjunction with firewall placement.
• Parallel "secure" and "insecure" network infrastructure.

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.

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 ACL lists for department subnets.
• Installing and maintaining dedicated department LAN firewalls.
• Enabling VLANs 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, IPv6 and SecureDNS.
• Exploring site license agreements for "personal" firewall tools.
• Explore implementation ramification of workstation operating system based VPN applications.
• Exploring the installation of advanced intrusion detection tools (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).
• 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" ACL 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 ACL 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 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.

 

 

Return to Papers Page