•
Closing
thought
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 that providing local, campus and
Internet connectivity.
Currently,
the spirit of the Cornell network is "open (1)." This
inclusive policy has historically rejected a "big brother" approach
to unilaterally block "unaccepted" forms of data communication between
entities. However, it is clearly understood that the open nature of
Cornell's Backbone 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 (2)
of Cornell's LAN, Backbone and WAN resources.
With a
common understanding of the Cornell "open " network service, productive
solutions can be forged that will mitigate risks while maintaining the
value of open communication.
Attacks
on Networks and Network Attached Resources
Although
it is beyond the scope of this paper to discuss all network security
risks, it important to set the security context at Cornell. Data obtained
from the Cornell Information Technology Network Operations Center (NOC)
between Jan. 1, 2001 and Sept. 30, 2001 breaks down the total percentage
of "network incidents" as follows:
- Scan/Probe
equals ~95.78%
- SPAM
equals ~.36%
- Open
Mail Relay equals ~1.43%
- Percentage
of System Compromise equals ~1.3%
- Denial
of Service Attacks equals ~.33%
- Other
equals ~.36%
As can
be inferred from the above - most of the incidents recorded by the NOC
are not security breaches of the network itself, but rather devices
connected to the network. Clearly, the "casing" and exploitation of
computers and computer services attached to Cornell's "open" network
is the primary security issues addressed by the NOC today. However it
is important to look broadly at network architecture issues noting the
larger spectrum of possible network vulnerabilities. For the purposes
of this paper this larger view includes
- Service
and Client Vulnerability Exploitation
- Denial
of Service
- Spoofing
- Sniffing
Service
and Client Vulnerability Exploitation
It is difficult
to draw a hard distinction between what is a "network security" issue
versus a network server / client issue. 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. Examples may include "Port Scanning" to determine services
that may be vulnerable to attack and in many cases - complete system
compromise. 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.,
Mail Relays, DHCP servers, DNS servers and even Network firewalls are
by definition network clients! Although 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. (3)
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.
To provide
authentication through "digital signatures" across the Internet, support
is growing for an authentication service known as Public Key Infrastructure
(PKI). Like Kerberos, PKI uses a trusted service to get irrefutable
knowledge about a network user. But unlike Kerberos, PKI uses the open
and operationally efficient exchange of a "public" key.
Spoofing
Spoofing
is the act of transmitting data with a forged or stolen IP number or
MAC (4) 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.
At Cornell the use of routers to segment the network limits eavesdropping
to information within a given subnet. 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. (5)
The above
common network attacks described above are against university policy,
and many state and federal laws.
Network
Hardware and Risks
Cornell's
data network is composed 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. (6) The Cornell
network is connected to the Internet with 2 OC3 (7)
links.
LAN security
at Cornell is not uniform. Cornell's Campus Area Network in aggregate
includes a mix of "shared" Ethernet and switched Ethernet (8)
LANs. A mix of secure and insecure wire termination points 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" 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 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.
- Routed
backbone resources can and do implement router rules that limit the
scope of spoofing, sniffing and Denial of Service activity on campus.
At this time, Cornell Routers block: spoofing, invalid routing, No
Directed Broadcast, in addition short term ACL are used to respond
to network attacks in progress.
- Ongoing
policing of network resources by network operations and security personnel.
- There
is an active project to replace all existing shared Ethernet hardware
with switched Ethernet hardware. (10)
- A
pilot study is underway to review the costs of replacing the insecure
twisted pair wire plant with a secure wire plant. Increased security
is primarily derived by securing wire termination points in campus
phone closets. (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 poorly engineered tools will often 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
- Encryption,
via Virtual Private Networks (VPNs ) or alternative encryption resources
combined with Virtual Local Area Networks (VLANs)
- Advanced
Network Authentication
- Firewalls
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. (13) 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 (14) 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. (15)
Quite possibly PKI affords better utility because it allows authenticated
data to be securely sent to locations via networks outside Cornell's
control.
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 requires users to provide authentication to the physical network
before they can send or receive data. There are developing standards
for network port-based authentication, which are 802.1x (16)
and 802.11e. (17)
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. (18)
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 and that the required protocols are mature and ready
for implementation. This general area is sure to also stimulate interesting
policy dialog‹as one might easily envision limiting access to sensitive
institutional information (student records and the like) to network
locations with network-based and application-based authentication abilities.
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 / Backbones.
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.
Network
Address Translation (NAT) & Port Address Translation (PAT)
NAT and
PAT devices are often used as limited firewalls, or a service that is
provided by firewall products. NAT is a means to support multiple internal
"IP" devices with a multiple_advertised IP address. PAT is a means to
associate multiple internal IP numbers with a single external number._The
nature of NAT and PAT allows network administrators to obscure the visibility
of clients on a given LAN. (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" (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.
Recommended
Service Directions
It's evident
that there is a rapidly growing demand for improved network security
services at Cornell. To date, Cornell 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 Cornell 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/PAT 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, Cornell might consider offering enhanced
network security services. These may include
- Providing
advanced firewall services within a central machine room for secure
server hosting.
- 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 the developing 802.1X
and 802.11e
- Providing
custom router ACL lists for department subnets.
- Installing
and maintaining dedicated department LAN firewalls.
- 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.
Action
Items
At the
risk of being overly prescriptive, the above list of potential service
areas can logically be refined as many recommendations are of questionable
value.
The assumption
that Cornell could deploy a single central firewall to protect all campus
ports is probably not feasible. While limited controls to protect all
Cornellians from universally understood threats (spoofing and so forth)
do make sense, to assume there is a much larger list of universal rules
that all at Cornell would agree to simply is not realistic.
Another
direction that may require more capital resources than Cornell is willing
to apply at this time is the central acquisition and maintenance of
hardware firewalls for each department on campus. A "hardened" machine
room service plus custom Access Control Lists (ACL's) may well offer
equivalent utility for less money. This is not to imply that there is
never utility for hardware firewalls, only that their operational costs
are high when compared to the ACL and "hardened" machine room alternatives.
There remains
active debate over the value of enabling VPN's and VLANS across the
campus backbone. Realistically, the value of these is to safeguard the
transmission of data across insecure networks - therefore the use of
a VPN, or VLANS combine with encryption tools for data transmission,
on the relatively secure centrally controlled campus backbone, may offer
little additional value. Regardless, client to server based encryption
software, such as SSH, or evolving Public Key Infrastructure encryption
schemes can provide equivalent or superior safeguards.
Given the
above arguments, the potential list of services may be better expressed
as follows:
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 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.
Nevertheless,
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 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 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.
Endnotes
(1)
Cornell network services, like those of all our peer institutions, have
evolved from higher education and defense Internet Protocol (IP) networks
that comprised the original "Internet" and that were historically open
access."
(2)
In this paper, illegal use is defined as violating Cornell policy, local,
state, or federal laws.
(3)
For more information about client security and general security information,
see www.cit.cornell.edu/security/
(4)
MAC address is the identification code assigned to the network interface
on network clients.
(5)
See: www.cit.cornell.edu/oit/wireless.html
(6)
See 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.
(8)
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.
(9)
Sniffing is the use of a protocol analyzer to capture and interpret
data being transmitted on a network.
(10)
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.
(11)
See: TIE2001.com
(12)
Detailed review of client configuration issues is beyond the scope of
this paper. For additional information about client security at Cornell,
see www.cit.cornell.edu/security/
(13)
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.
(14)
See: www1.ietf.org/ids.by.wg/l2tpext.html
(15)
See: www.pkiforum.org/ and middleware.internet2.edu/pkilabs/
Also note that SSH is broadly used today to provide data encryption.
(16)
grouper.ieee.org/groups/802/1/pages/802.1x.html
(17)
grouper.ieee.org/groups/802/11/
(18)
Contact Mark Mara <mam1@cornell.edu>
for additional information on CIT developments in this area.
(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.
(21)
www1.ietf.org/ids.by.wg/nat.html
(22)
As noted earlier, Cornell routers now have basic ACL list to limit IP
spoofing, etc. Additional default filters could be explored.
(23)
See: www.ietf.org/html.charters/ipsec-charter.html
(24)
www.ietf.org/html.charters/dnsext-charter.html
(25)
www.microsoft.com/TechNet/win2000/win2ksrv/technote/msppna.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.
(27)
See: www.ietf.org/html.charters/ipsec-charter.html
(28)
www.ietf.org/html.charters/dnsext-charter.html
(29)
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.
Last
modified: November 13, 2001
Return
to Papers Page
