Network Architecture
Security Guidelines
May 2005
Revision History
Version
Date
0.1
2/28/05
0.2
4/15/05
Author
Jim Graves
Jim Graves
Comments
Initial draft
Added router and switch config sections
Table of Contents
Chapter 1: Overview ....................................................................................................... 1
1.1
Introduction ......................................................................................................... 1
1.2
Requirements ..................................................................................................... 1
1.3
Scope.................................................................................................................. 2
Chapter 2: Security Principles ....................................................................................... 3
2.1
Guiding Philosophies .......................................................................................... 3
2.1.1
The Principle of Least Privilege ................................................................... 3
2.1.2
Layered Security.......................................................................................... 3
2.1.3
Security is a Process, not a Product............................................................ 4
2.1.4
Functional Segmentation............................................................................. 5
2.1.5
Access to the Network Should Be Controlled.............................................. 6
2.2
Threats................................................................................................................ 6
2.2.1
Modes of Attack........................................................................................... 6
2.2.2
Types of Attack............................................................................................ 7
2.2.3
Risks.......................................................................................................... 10
Chapter 3: Network Design .......................................................................................... 12
3.1
Overall Architecture .......................................................................................... 12
3.1.1
Segmentation and Access Control ............................................................ 12
3.1.2
Switch Port Security .................................................................................. 13
3.2
Architecture Components ................................................................................. 14
3.2.1
Students .................................................................................................... 14
3.2.2
Residence Halls......................................................................................... 15
3.2.3
Faculty and Staff........................................................................................ 17
3.2.4
Public Access ............................................................................................ 18
3.2.5
Libraries..................................................................................................... 19
3.2.6
External Access......................................................................................... 20
3.2.7
Data Center ............................................................................................... 21
3.2.8
Network Core............................................................................................. 22
3.2.9
Out-of-Band Management ......................................................................... 22
3.2.10 Wireless..................................................................................................... 23
Chapter 4: Device Configuration ................................................................................. 24
4.1
Router Security Guidelines ............................................................................... 24
4.1.1
Router Access Control............................................................................... 24
4.1.2
Network Access Control ............................................................................ 26
4.1.3
Routing Protocol Security .......................................................................... 27
4.1.4
Logging and Monitoring ............................................................................. 29
4.1.5
Router Security Checklist .......................................................................... 30
4.2
Switch Configuration Guidelines....................................................................... 31
4.2.1
VLANs and Trunks .................................................................................... 31
4.2.2
Spanning Tree ........................................................................................... 32
4.2.3
Management.............................................................................................. 33
4.2.4
Other Settings............................................................................................ 33
4.2.5
Switch Security Checklist .......................................................................... 34
Appendix A: References............................................................................................... 36
May 24, 2005
DRAFT
Page i of i
Table of Figures
Figure 1: Layered security................................................................................................. 3
Figure 2: Functional segmentation.................................................................................... 5
Figure 3: Login banner message .................................................................................... 26
Figure 4: ACL deny logging entries................................................................................. 27
Figure 5: Blocking "land" attacks..................................................................................... 27
Figure 6: RIP MD5 authentication ................................................................................... 28
Figure 7: EIGRP MD5 authentication.............................................................................. 28
Figure 8: IS-IS MD5 authentication ................................................................................. 28
Figure 9: OSPF MD5 per-interface authentication .......................................................... 29
Figure 10: OSPF per-area MD5 authentication............................................................... 29
Tables of Tables
Table 1: Router services to disable................................................................................. 24
Table 2: Router interface commands .............................................................................. 24
Table 3: Line configuration commands ........................................................................... 25
Table 4: Password protection.......................................................................................... 25
Table 5: Routing protocol authentication commands ...................................................... 29
Table 6: Logging and monitoring commands .................................................................. 30
May 24, 2005
DRAFT
Page ii of ii
Chapter 1: Overview
1.1
Introduction
The Minnesota State Colleges and Universities (MnSCU) system consists of
state universities, community colleges, and technical colleges throughout the
state of Minnesota. The 37 institutions in 70 locations range in size from St.
Cloud State, with nearly 20,000 full-time and part-time students, to 633student Rainy River Community College. Each college or university has its
own CIO and IT infrastructure that’s managed autonomously from other
MnSCU campuses. MnSCU schools also share centralized infrastructure for
many applications, including the Integrated Statewide Record System (ISRS).
MnSCU asked NetSPI to develop guidelines for a secure network architecture at the campuses.
1.2
Requirements
Each MnSCU school has unique requirements, based on its own mission,
philosophy, and constituency.
Services vary by campus. For example, some provide student housing while
others don’t. Most of the large state colleges provide on-campus student
housing; community colleges may or may not do so. Whether housing is
provided doesn’t depend on campus size. For example, Vermillion Community College, with 716 full time students, has on-campus apartment-style
housing.
Similarly, MnSCU institutions have different requirements in how they work
with their stakeholders. Many colleges, especially those in smaller towns,
serve not only their students but also the greater communities of which they
are part. MnSCU campuses frequently serve as community meeting spaces,
and many college facilities such as libraries are open to the general public.
The result of this variety and public service mission is that a network architecture recommendation for MnSCU must meet unique (and sometimes
contradictory) goals:
•
Information Security and Open Access: MnSCU schools handle sensitive information, either individually or through shared systems such as
ISRS. Some of this important information includes student grades, social
security numbers, financial aid records, payroll information, and health records. Schools are often legally compelled to protect this information by
regulations including the Health Insurance Portability and Accountability
Act (HIPAA), the Family Educational Rights and Privacy Act (FERPA), the
Fair Credit Reporting Act (FCRA), and the Gramm-Leach-Bliley Act
(GLB).
At the same time, many of MnSCU’s educational institutions have missions that include openness and service to the community. College
May 24, 2005
DRAFT
Page 1 of 1
libraries are open to the general public, and school facilities are often
used by community groups. Campuses are also frequently used by third
parties for customized training. These uses suggest the need for information systems that are either open to the general public (e.g., library
patrons) or available to guests on a temporary basis.
In short, a state school must provide open access to many of its information systems while protecting vital data.
Uniqueness and General Applicability: As has already been discussed,
MnSCU schools vary greatly in size and services. A useful information network architecture design must be applicable to all campuses. It should meet
the unique needs of each school, but general enough to be relevant to all.
The requirements for a secure network architecture guidelines project can be
summarized as follows:
1.3
•
The reference architecture must conform to security best practices
•
The architecture should provide protection for sensitive information while
providing open access to public resources (e.g., libraries)
•
The architecture should allow for varying implementations according to
individual campus philosophies while maintaining appropriate security in
all proper implementations.
•
The target architecture must be feasible for MnSCU schools to implement, in terms of time and financial resources needed for migration and
management of the architecture.
Scope
This project reviewed current MnSCU school networks with the goal of recommending a framework for secure network architectures.
The
recommendations are based on interviews with campus and MnSCU IT staff.
Included in the scope for this project were:
•
•
Reviewing sample MnSCU campus network architectures, including:
o
infrastructure topologies
o
equipment selection
o
device configurations
Documenting architecture recommendations for all of MnSCU, using the
sample networks as examples.
Items that were out of scope for this project include:
•
Physical security
•
Hands-on testing or network vulnerability testing
•
Implementation of recommendations
May 24, 2005
DRAFT
Page 2 of 2
Chapter 2: Security Principles
2.1
Guiding Philosophies
2.1.1
The Principle of Least Privilege
The principle of least privilege states that a user should have only the privileges needed to do his or her job.
Although this principle assumes a corporate environment, it can be extended
to the academic environment by thinking in terms of roles instead of jobs.
Thus, students should have the minimum access needed for their roles as
students, Internet users should have the minimum privileges they need, and
so forth.
Note that in many cases, what a group of users “need” is a question of policy.
For example, does the general public need access to the library, the Internet,
or other school resources? That’s a policy question. Once that policy has
been established, the network architecture should enforce that level of access.
2.1.2
Layered Security
Layered security (often called “defense-in-depth”) is the concept that security
functions should happen at multiple layers. It’s not enough just to have firewalls, encryption, or application logins—these technologies and others must
be combined to provide effective security.
Intrusion Detection
Policies and Procedures
VPN
Firewalls
ACLs
Application
Proxies
The advantage of layered security is that it helps avoid the “Tootsie Pop” syndrome, where a secured perimeter is merely a hard outer shell surrounding a
soft, chewy center. Instead of focusing on protecting the perimeter, layered
security ensures that appropriate defenses are used at all points of a data
flow.
Figure 1: Layered security
May 24, 2005
DRAFT
Page 3 of 3
This concept is illustrated in Figure 1. Different technologies protect different
layers of the OSI model. Figure 1 doesn’t list all security technologies—just
enough to show a sample of how layered security works.
•
The physical layer is the first level of defense. Traditional security measures such as locks, cameras, walls, and security guards are used to
prevent unauthorized users from gaining access to a building—or to its
LAN.
Although educational institutions do have physical security measures—
cameras and guards (or campus police), for example—many MnSCU
campuses are open to all. It is difficult to control physical access to network data ports in such campus environments.
•
The next layer of defense protects the Data Link layer by preventing unauthorized access or mischief at the switch level. Access to the network
can be controlled by disabling unused ports or using 802.1x authentication, for example. Some VPNs operate at this layer.
•
Firewalls and ACLs are at the next layer of defense. They restrict the network access allowed to various types of network traffic. Some firewalls
include Data Link layer functions, and most are increasingly inspecting
information from higher layers.
•
Intrusion Detection starts at the Network layer and operates all the way
up to the Application layer. IDS may base its decisions on factors including TCP/UDP port numbers, application data contents, and traffic
patterns.
•
Application proxies operate between the Transport and Application layers.
By proxying traffic, they try to ensure that all proxied applications use the
correct protocols.
•
At the top layer are application content inspection services. These include
network anti-virus scanners, web filters, and spam filters. The application
layer also includes many server-based security controls, such as user accounts, application logs, and host-based IDS.
Policies and procedures tie all these layers together.
2.1.3
Security is a Process, not a Product
Another fundamental security principle is that it is a process, not a product.
Technology only provides security if it is used to implement an effective security policy. Firewalls can stop many network attacks—but only if they’re
configured properly. Security patches are useless if they’re not applied to
production systems. Security logs are meaningless if no one looks at them.
Technology solutions are simply tools. True security depends on practices
that keep security considerations involved in all phases of design, development, deployment, and operations.
May 24, 2005
DRAFT
Page 4 of 4
2.1.4
Functional Segmentation
Building on layered security and the principle of least privilege, functional
segmentation suggests a design in which the network is partitioned according
to user or device function. Access to and from each segment is controlled by
access lists or firewalls that allow only appropriate traffic in or out of each
segment.
Figure 2 illustrates this concept with some common network components.
Students, faculty and staff, and network administrators all have different
slices of the “network pizza”. Segments are also devoted to the Internet access infrastructure, wireless networks, and servers. In the center of all this is
a firewall, policing traffic from one segment to another. Each segment may
be further divided according to the needs of a school—faculty segments may
be divided by academic department, for example.
Figure 2: Functional segmentation
Note that this is segmentation from a security perspective, not just a network
perspective. In addition to routed VLANs, this adds policy-based traffic control between each segment.
Segmentation helps avoid the “soft chewy center” problem. Consider servers, for example. Most users within an organization don’t need full unfettered
access to database servers, web content servers, and the like. By restricting
their access to only the what they need, the principle of least privilege is followed. Users can still get at the applications they need, but malicious use of
those servers is harder.
The biggest advantage of a segmented architecture is in preventing the
spread of worms such as Slammer. Without segmentation, Slammer and its
May 24, 2005
DRAFT
Page 5 of 5
ilk can spread through a large network quickly, infecting important servers as
easily as less important systems. With proper segmentation, worms may be
contained to the segments in which they’re introduced. For example, if a student laptop in infected with a worm, that worm should stay within the student
segment and not spread to servers.
2.1.5
Access to the Network Should Be Controlled
Many security threats enter a network from inside. This is especially true at
colleges and universities. Network Access Control (a general principle not to
be confused with Cisco’s NAC) applies the principle of least privilege to the
data link layer: only those users who are allowed to use the network should
be able to connect to it.
Some schools have public-access network segments (e.g., open wireless
LANs or public-access network jacks in a library). In this case, all users are
allowed to use those network segments.
2.2
Threats
In designing and implementing a secure network architecture, it’s important to
bear in mind the threats that are being protected against. Although an indepth taxonomy of security threats and risks is beyond the scope of this
document, a general overview is valuable for setting the context of the network architecture guidelines.
2.2.1
Modes of Attack
There are two primary modes of attack—active and automated.
•
Active Penetration Attacks: This is what people tend to think about first
when they think about computer security threats. The typical concept is
of a hacker who actively tries to break into a system, usually from outside
a network, to gain access to systems for fun or profit.
Hacking is an active attack in that there’s someone making the attack, trying exploits, and doing activities that are primarily on-line and real-time.
Hackers can be external, but in an academic environment it’s just as likely
that they’ll be on the inside of the network.
•
Automated Attacks (Worms, Viruses, Trojans, and Spyware): These
are considered automated attacks in that the author of a worm of virus
doesn’t have to be online (or even awake) for the attack to be made.
Once a worm is released into the wild, the author doesn’t have to do anything to spread it (and, as in the case of the Morris Worm, usually can’t
stop it even if he or she wants to).
Worms and viruses aren’t quite as often considered when designing security, but they should be—they’re far more common (if not more
dangerous) than active penetration attacks.
A successful penetration
attempt may affect a few systems, but an unchecked worm outbreak
May 24, 2005
DRAFT
Page 6 of 6
could bring an entire network to its knees—while possibly creating back
doors for active penetration.
Automated attacks thrive on flat, wide-open networks where internal users are implicitly trusted. Those users may be trustworthy—but they can
also carry worms or viruses into the network.
2.2.2
Types of Attack
Some common attack types are listed below. This list is not meant to be exhaustive, but to give a flavor for the variety of attacks that must be
considered. Attacks include:
•
Remote Code Execution: A remote code execution attack occurs when
an attacker exploits a software vulnerability or insufficient access controls
to run programs that the user does not have privileges to run. Buffer
overflow bugs are the most common sources of remote code execution
vulnerabilities.
Remote code execution can be difficult to prevent through network layer
mechanisms because they often occur within seemingly legitimate network traffic (i.e., on common application ports such as TCP port 80 for
HTML). Signature-based IDS systems can recognize known exploits, but
new (so-called “0-day”) exploits are harder to detect. The best defenses
against code execution attacks are prompt and proactive patch processes, system-level controls that limit application privilege levels, and
network segmentation to limit the impact of a compromised system.
•
Denial of Service: This is a major and well-known type of attack. Many
Denial of Service (DoS) attacks exploit software bugs that crash the affected system. A classic example is the “ping of death”, which exploited a
problem in the way many TCP stacks handled overly large IP ping packets.
Another classic attack is the SYN flood, which sends a large number of
TCP SYN packets to a target. These SYN packets are supposed to be
the first part of the TCP three-way handshake; the server normally responds with a SYN-ACK packet, allocates buffer space for the new TCP
session, then waits for an ACK that verifies the handshake is complete.
In a SYN flood attack, however, the attacking host never responds (and
usually fakes its IP address). The target ends up allocating buffer space
for connections that never finish. Eventually, buffer space for these connections prevents real connections from being established, or uses up all
available memory.
The Distributed Denial of Service (DDoS) attack is a special kind of denial
of service. It uses a large number of “zombie” machines that have been
infected with a virus. When a command is given to those hosts, they all
launch simultaneous attacks against the target. These are either DoS attacks, or else the zombie hosts just use all their available bandwidth to
request services from the target host. The result can be devastating –
May 24, 2005
DRAFT
Page 7 of 7
even a site with a dedicated OC-3 (155 Mb/s) connection will be overwhelmed by ten thousand zombie hosts, all on 500Mb/s to 1Mb/s cable
modem or DSL connections.
DoS is a network-level attack, and some network techniques exist to deal
with them. Firewalls and routers now have mechanisms to thwart SYN
attacks, either by limiting the rate at which SYN packets can flow or by
acknowledging the SYN packets itself. Bug-related DoS attacks can be
prevented by patching the vulnerable software.
DDoS, it’s a bit harder to handle, since the DDoS attack uses up bandwidth. Cisco’s (formerly Riverhead) Guards are one answer. Detectors
located at an internet access point monitor the flow rate. If usage increases past a threshold, the detector uses BGP to direct all traffic for the
affected host to a Guard located at the ISP (who has much more bandwidth available than the ISP’s customer). The Guard then forwards
legitimate traffic to the real system at a safer rate.
•
Worms and Viruses: This may be the most common form of attack, but
isn’t as often thought of when security is designed. Worms and viruses
are automated attacks, programmed to spread themselves as rapidly and
as widely as possible. They vary in the amount of damage they do to a
system, but their rapid spread can lead to DoS-like effects within a network as more and more network resources are devoted to spreading the
worm or virus instead of legitimate traffic.
As with most forms of attack, a layered approach is needed to prevent
worms and viruses. The first layer of defense is to prevent them from entering a network at all. This means firewalls, but it also means controlling
who can connect to the internal network and running network-level virus
scanners. The next layer is at the network level. Segmentation can limit
the spread of a worm or virus to a small section of the network. The third
layer is the application layer—applications need to be patched so that
they aren’t vulnerable to the worm. Software products also exist that try
to prevent any buffer-overflow bug from working (e.g., Cisco’s Security
Agent software).
•
Trojans and Spyware: One of the more common attacks today, trojans
and spyware try to gain control of a remote system or read information on
it.
A trojan (shorthand for “Trojan Horse”) is an attack program disguised as
something else. For example, a program may claim to be a screensaver,
but secretly open a back door that allows the attacker to take control of
the system (or launch DoS attacks on another system).
Spyware is usually installed with other software, and collects information
about the system for sending to someone else (hence, “Spyware”). That
information can be relatively harmless (e.g., web sites visited) or invasive
(e.g., financial information or passwords). Whatever the level of information gathered, the software is unwanted.
May 24, 2005
DRAFT
Page 8 of 8
Trojans and spyware are hard to prevent from a network level. They exist
as content within legitimate applications and rely on user action to install.
E-mail trojans rely on a user to click on attachment, spyware rides along
with seemingly legitimate applications (although those “legitimate” applications are often rather shady themselves, such as file sharing software),
and so forth. The only sure way to mitigate these attacks is to prevent
users from installing software or executing unknown applications. That’s
not always feasible, given the number of ways a user can get software
onto a machine: CD-ROM drives, USB memory drives, floppy disks, FTP,
HTTP, and Java applications are just a few of the ways users can execute code. In the academic environment, where the schools don’t control
users’ machines, it’s even harder.
From a network perspective, the mitigations for Trojans and spyware are
similar to those for viruses and worms: prevent them from entering the
network as best as possible and limiting their spread once on the network. IDS scanners can be helpful. More severe techniques, such as
blocking FTP, HTTP, e-mail attachments, Java applets, or ActiveX applets, are unlikely to be feasible in the academic environment.
•
Password Cracking: Attackers also try to get into systems by cracking
passwords. Password cracking happens in both on-line and off-line
modes. Online password cracking involves repeated password guesses
while trying to log in. Passive cracks can happen when an attacker has a
copy of an encrypted password (e.g., via network sniffing, or the “passwd”
file on Unix hosts that don’t use shadow passwords), or from sniffing
clear-text passwords over the network. Off-line cracking is much more
fruitful, since maximum login counts and account lockouts don’t apply.
The “dictionary attack” is an off-line password cracking method. In this attack, a group passwords are compared to a dictionary of common words
and passwords. If the password is encrypted, the dictionary is encrypted
using the same mechanism. Because many users choose insecure password, a dictionary attack is likely to succeed if it has enough different
passwords to check.
Password cracking is an application-level attack. Its relevance to network
architecture is that network components need to have access lists applied
to control who can connect to them.
•
Traffic sniffing: Traffic sniffing attempts to read interesting information
from network data flows. Information sent “in-the-clear” (i.e., without encryption) can be read by anyone on the network path between the sender
and receiver, and in many cases by people who are only near the network
path (e.g., on the same network hub).
Switches are often thought to prevent traffic sniffing, but there are methods of getting around that. When a switch becomes confused, it reverts
to its childhood and becomes a hub—spewing every packet it sees out of
all its interfaces. Freely available tools such as Ettercap take advantage
May 24, 2005
DRAFT
Page 9 of 9
of this behavior (and other Layer 2 issues) to allow packet sniffing even
on switched networks.
Still, using switches rather than hubs is an important step in preventing
traffic sniffing. Even in switched networks, however, those switches must
be configured to prevent the Layer 2 attacks that can allow packet sniffing.
•
Man-in-the-Middle Attacks: The man-in-the-middle attack is a type of
attack where a third party injects himself or herself into a data flow, either
to read or change information. When a man-in-the-middle attack tries to
take over a TCP session, it’s called session hijacking.
The best defense against man-in-the-middle attacks is good protocol design. A network architecture can minimize risk by enforcing reasonable
idle timeouts on connections.
2.2.3
Risks
“Risk” is the impact of a potential attack to MnSCU’s mission, operations, and
objectives (what in the private sector would be called “business risk”). Types
of risk include:
•
Information Theft: Many attacks can lead to unauthorized access to information. This obviously includes improper access to academic records,
but also includes access to financial records, health records, or even library records. All of these are considered confidential.
Identity theft is a particularly notable type of information theft. If an attacker gets enough information about a single person, the attacker can
get credit cards, withdraw money from checking accounts, or buy products under that person’s name. The financial effects of an identity theft
can be devastating to a victim’s finances and credit rating.
•
Information Modification or Deletion: The next step from reading
grades is changing them. Modifying information requires more access
than reading it, but the damage is far greater—especially if effective audit
and log information is not kept.
•
Theft of Resources: Information technology is almost always a finite resource driven by finite budgets. Unauthorized access prevents legitimate
users from getting full use of this resource, and thus can be called “theft.”
The theft can be so minor that it’s unnoticeable (e.g., one quiet user on a
network of thousands), or so major that it can’t be missed (in the case of
denial-of-service attacks).
•
Third-Party Liability: A significant risk faced by MnSCU lies in the threat
it may pose to other organizations. If a third-party were attacked using
MnSCU’s network, MnSCU could face liability issues leading to possible
financial repercussions, network disruptions (e.g., from listing in black
hole lists), or bad publicity. Common third-party attacks include:
May 24, 2005
DRAFT
Page 10 of 10
o
Spam relaying
o
Student attacks on other organizations
o
Pirated software (“warez”) sites taking over anonymous FTP servers
Due diligence is key to preventing liability issues.
May 24, 2005
DRAFT
Page 11 of 11
Chapter 3: Network Design
3.1
Overall Architecture
The network architecture described in this chapter is a modular design based
on layered security, functional segmentation, and access controls between
modules. These factors and other overall design issues are described in this
section. Individual network modules are discussed in Section 0.
MnSCU’s institutions have varying network environments and requirements.
The architecture described here is modular, so that schools may include components that apply and ignore those that don’t.
Some modules will apply to all schools. It’s hard to call a place a school if it
doesn’t have students or faculty, for example. All networks will also have
some sort of network core and access to MnNET (and, through it, the Internet).
Each campuses may or may not have wireless networks, residence halls, application servers, or public access networks. Schools may also vary in the
amount of segmentation they want to do. Some may want to further subdivide the modules listed here, for example by splitting the faculty and staff
modules by academic department.
The architecture is also policy-driven, in that design choices will depend on
the policies in place at a particular campus. These choices are described
where possible. This document is meant to give guidelines for translating
policy into design, not to dictate policy.
3.1.1
Segmentation and Access Control
As described in section 2.1.4, networks should be segmented into functional
partitions with access controlled between sections.
VLANs can be used to achieve a lot of this segmentation, but not all of it.
Since they’re configuration-based, VLANs are vulnerable to some Layer 2
attacks that break down their logical segmentation and allow traffic to leak
through from one VLAN to another. Physical separation should be used between network zones that have a major difference in possible security. If a
module should not share VLANs with others, that is discussed in the section
for that module.
Access Control Mechanisms
Access control can be done through access lists or with firewalls.
•
May 24, 2005
Access lists are possible with all Layer 3 Cisco equipment. They can
permit or deny traffic by IP header information, including source and destination address, IP protocol number, and TCP or UDP port numbers.
DRAFT
Page 12 of 12
Basic Cisco access lists do not automatically allow return traffic for data
flows (e.g., replies from a server to a host) unless manually configured or
allowed with the “established” key word. Reflexive access lists dynamically create access list entries to allow return traffic.
•
Firewalls permit or deny traffic based on many of the same criteria as
access lists, but also enforce proper behavior at higher levels. Firewalls
maintain connection state and drop traffic that doesn’t fit that state (e.g.,
packets with improper sequence numbers or flag combinations should be
dropped). They should also inspect common application protocols (e.g.,
HTTP, FTP), and have better support for dynamic protocols (like FTP)
than static access lists.
Firewalls are also typically much better at logging and reporting than are
access lists.
Firewalls can be stand-alone or built into network devices. Cisco’s PIX
module for the 6500 series switch is one option for firewalling in the network core. Cisco routers also support Context-Based Access Control
(CBAC), which adds firewall features to router access lists. CBAC can
inspect the data in several protocols, and allow only traffic that conforms
properly to the protocol.
Of course, the more inspection that’s done on a switch or router, the greater
the CPU load will be on that device.
3.1.2
Switch Port Security
Controlling access to the network is fundamental to preventing the spread of
worms, viruses, and other attacks. In the open physical environments of
most schools, switch port security is the best mechanisms to control who can
access the network.
Note that this section doesn’t apply to public access network modules.
The options for controlling switch port access include:
•
Manually enabling switch ports
•
MAC-based port access control
•
802.1x
•
Customized access control methods
•
Cisco Network Admission Control
•
Web-based authentication gateways
None of these options are perfect for an academic environment, and the right
option will vary depending on network module. Manually enabling switch
ports is labor intensive, and it’s hard to stay on top of disabling them when
they’re no longer used. MAC-based switch port access control methods
May 24, 2005
DRAFT
Page 13 of 13
aren’t realistic for situations where different devices frequently connect to the
same ports.
802.1x solves many of these problems—it’s portable, authenticates based on
user identity, and requires much less administrative effort after it’s set up. It
can also be used with Dynamic VLAN assignment to determine a switch
port’s VLAN based on the 802.1x credentials of the user connected to it. But
it’s also new enough that most deployed switches don’t support it yet. However, if network equipment supports 802.1x, it’s highly recommended. Even if
current equipment doesn’t support it, 802.1x should be deployed where appropriate in newly installed switches.
Cisco’s Network Admission Control takes 802.1x further by controlling access
to the network by policy. It integrates with other programs such as anti-virus
or patch management software. Thus, NAC allows access to a network only
after patch levels and virus scans have been checked.
NAC requires even newer hardware than does 802.1x. It also requires a client on the user’s PC. That makes it poorly suited for most schools except in
certain limited cases.
Web-based authentication gateways are a good compromise solution. These
are similar to the gateways often used in hotel Internet access or wireless
hotspots. When a user connects to a network port, they’re only able to get to
the authentication web page. Once authentication is passed, they’re allowed
past the gateway. The advantage of this mechanism is that it doesn’t require
a client on the user’s PC, can usually tie into existing authentication databases (e.g., LDAP or Active Directory), and requires little administrative
overhead other than initial infrastructure and account setup.
3.2
Architecture Components
3.2.1
Students
General Considerations
All schools have students (along with faculty, they’re pretty much part of the
definition of a school). In network architecture terms, the student module includes any campus devices dedicated to student access except residence
halls. These have special considerations, and should have a separate network segment.
The student component includes classrooms and academic computer clusters. Wireless networks may provide access to the student network segment.
All these components may be further subdivisions of the student module.
Student network access can be through school computers (e.g., computer
clusters, computers in classrooms), or through student-controlled systems
(e.g., laptops connected to open classroom data ports).
May 24, 2005
DRAFT
Page 14 of 14
Access Controls
School-managed computers in this zone should require user logins and enforce group policies appropriate to students.
Web-based or 802.1x access control mechanisms should be used to ensure
authenticated access to open switch ports.
Outbound Access To Other Modules
The student network segment needs access to:
•
The Internet
•
Academic Servers
•
o
Faculty servers (e.g., for class web pages)
o
School information systems (schedules, local ISRS information,
school web site, etc.)
Library information systems
Inbound Access From Other Modules
No servers should be hosted in the student network segment. There should
be little need for access to this segment from others.
Other Controls
Student computing facilities should be included in any virus scanning, content
filtering, or web proxy requirements that are compatible with policy.
3.2.2
Residence Halls
General Considerations
Residence halls are a special case of student access. Residence halls (if the
school has them) are where the students live, and where they have the greatest ability to use their own machines however they can. In such an
environment, residence halls represent a greater threat to the rest of the campus (and the world) than the world does to them.
Security in residence halls has all kinds of interesting problems. How can
reasonable patch management procedures be encouraged in a place where
the school doesn’t own the machines? How do schools protect the outside
world from curious, intelligent, and sometimes mischievous students? How
can network traffic be kept stable in the presence of peer-to-peer file sharing
programs, instant messaging, and bandwidth-intensive network games? How
can the answers to these questions provide security, while still allowing students to get their homework done and allow academic freedom?
May 24, 2005
DRAFT
Page 15 of 15
One effective solution is to outsource the whole problem to an external ISP.
Residence halls then become another external network, with specific limited
access to the school’s other information systems.
Access Controls
Most switch port access controls are possible in residence halls.
In the case of manual port activation, the bulk of activations could be expected to happen in the beginning of the academic year. If port activations
can be bundled into other move-in paperwork, it reduces the total overhead
for such a method.
Methods such as NAC or web-based access control can be useful here, especially if integrated into virus detection or patch management features.
Outbound Access To Other Modules
Residence halls will have Internet access as defined by policy. They will also
usually need to access the same systems as internal student systems, including school information systems and privileged library resources (e.g.,
restricted online databases). Residence halls can be given this access by IP
block, or students could be required to use VPN software or application logins
to access this information.
Inbound Access From Other Modules
Inbound access to residence halls will also be determined by policy. Certainly the easiest policy is to deny all inbound access to student computers.
However, some schools may have academic freedom and open access policies that require open access to student machines. An acceptable use policy
should define whether students are allowed to run publicly accessible servers
from their rooms, for example.
Other Controls
Even if student computers can’t be scanned for viruses before letting them on
the network, they should still be monitored for signs of infection.
IDS should be used to watch student computers for signs that they are initiating viruses and attacks. The IDS should be tuned for aggressive session
disconnection when it sees attacks coming from an internal host, and if possible should communicate with switches to disable switch ports in some
circumstances.
Bandwidth rate-limiting should be used on the routers between residence
halls and the network core. This can be further tuned by protocol—for example, to specifically limit peer-to-peer traffic.
May 24, 2005
DRAFT
Page 16 of 16
3.2.3
Faculty and Staff
General Considerations
Faculty and staff are included together in this document because they have
similar (though not identical) computing needs. Both groups need higherlevel access to servers than students. Also, faculty computers need to be
protected from other modules (e.g., students), yet still present a risk of their
own (as a source of viruses and worms, for example).
IT staff should have a subdivision of their own with static IP addresses (these
addresses can still be assigned with DHCP, but with reserved addresses).
That will make it easier to set up ACLs limiting administrative access to network devices or management systems.
Access Controls
Faculty switch ports have a somewhat higher expectation of physical security
than those in the student zone. “Open” faculty switch ports should be in faculty offices. Although faculty offices probably aren’t locked or monitored as
often as they should be, it’s safe to say that if someone were in a faculty office, they’d also have physical access to sensitive non-network information.
School-managed computers in this zone should require user logins and enforce group policies appropriate to faculty or staff. Note that the appropriate
policy may be full access to the local system.
Web-based or 802.1x access control mechanisms could be used to ensure
authenticated access to open switch ports, but are not as essential in this environment as they are for students.
Outbound Access To Other Modules
As with other modules, this will be determined by policy. However, the following outbound access would be typical:
•
Faculty will likely need full access to the Internet.
•
Faculty will also need access to academic information systems
•
Faculty servers can be set up in this segment, or in the server segment.
If the faculty servers are centrally located, this segment should allow access to them.
•
Administrative IT staff need access to the out-of-band management network, the network core, and other infrastructure components in addition to
the normal access.
Inbound Access From Other Modules
This depends on how faculty-generated content is handled. If faculty can set
up their own servers in this zone, then access to those servers must be allowed from the student module, and possibly from the public-access
May 24, 2005
DRAFT
Page 17 of 17
modules. If faculty servers are centrally located, this can be set up to prevent
all inbound access.
Other Controls
3.2.4
Public Access
General Considerations
Some schools have public access network facilities. These facilities are open
to anyone, whether they are affiliated with the school or not. Schools provide
these networks as a service to their communities.
Public access network segments pose a liability risk. If controls are not in
place, people can use these segments to launch attacks on other organizations. If a DoS or spam attack comes from a MnSCU school, the target may
not care that someone else did the actual attack.
The key to protecting a public access network is in preventing the damage it
could do to other networks, either within MnSCU or on the Internet.
Open library systems may have additional requirements for user privacy;
these are discussed in Section 3.2.5.
Access Controls
Useful access controls are not feasible in a public access environment. Voluntary registration could be used, but would not provide any greater access
control.
Outbound Access To Other Modules
If policy requires public access networks, that policy should also define the
resources the public is expected to be able to reach. In general, however, an
on-campus guest user of the network should have the same access as an
anonymous user located on the Internet. Note that there are some exceptions; for example, many online databases provided in libraries are only open
to anonymous users on-site for licensing reasons. Local guest users may
also need access to printers.
Inbound Access From Other Modules
There should be no inbound access into public network segments.
Other Controls
Public access networks should be watched very carefully with IDS, using
more draconian response methods than for the rest of the network. For example, RST could be used to disconnect an attack session, or an offending
user’s switch port could be disabled.
School-owned computers in public segments should be tightly locked down.
Users should not be able to change system settings, install software, or acMay 24, 2005
DRAFT
Page 18 of 18
cess removable storage (CD-ROMs, floppy drives, USB drives, etc.). Publicaccess systems should be automatically re-imaged a regular (preferably
nightly) basis.
This zone should not share a physical switch with other internal zones.
3.2.5
Libraries
General Considerations
Libraries are a unique case. They combine aspects of student, faculty, public
access, and server networks. As information resources in their own right,
libraries have their own policies regarding information access. These policy
requirements are defined by how the library sees itself—as serving the general public, or only the school.
The entire mission of a public library is free and open access. In the Internet
age, this has expanded to include the entire Internet in addition to the traditional books, journals, and other resources inside library walls. Libraries
usually want to provide unfiltered access to the Internet, just as they provide
unfiltered access to books.
Libraries that see themselves as resources for their schools but not the general public may have more restrictive policies. They allow access only to
school staff, faculty, and students, for example, by requiring ID at the door.
Or, they may not require ID to get into the library, but do not provide open
Internet use. These schools may still have open card catalog computers that
don’t have Internet access.
These issues affect security policies as well. For example, the acceptability
of monitoring library user activity or filtering web content depends on library
policy. There are several dimensions to library security policy. Just a few of
the questions are:
•
Should users be authenticated before using library resources?
•
Once authenticated (or allowed open access), what resources should users be able to access?
•
What types of monitoring, if any, is necessary or acceptable in a library
environment?
•
Should library patrons be able to use their own machines, or are libraryprovided systems sufficient?
The questions of library policy—especially as they pertain to Internet access
and web filtering—cannot be discussed adequately within the scope of this
document. As has been stated previously, the purpose of this document is
not to prescribe policy, but to provide guidelines for implementing whatever
policy a school has.
May 24, 2005
DRAFT
Page 19 of 19
Where possible, a library network zone should be subdivided into staff,
server, card catalog, and public access segments to allow for the different
requirements of each.
Access Controls
Switch ports for library-owned computers should be locked to their MAC addresses. If open network jacks are provided, it’s infeasible to lock them
down.
Where policy allows it, system logins should be used to control access to authorized users.
Outbound Access To Other Modules
Libraries need access to:
•
The Internet
•
Campus administrative systems
Library access to the Internet should be as direct as possible, allowing Internet browsing while preventing access to non-publicly accessible portions of
the campus network.
Libraries may choose to restrict outbound browsing to certain services (e.g.,
HTTP and HTTPS).
Inbound Access From Other Modules
External users need access to the library card catalog and other information
servers.
Other Controls
3.2.6
•
Where policy allows, public Internet terminals should be secured as described in Section 3.2.4.
•
Public-access library systems should not share a physical switch with
other internal zones.
External Access
General Considerations
The external access module is the gateway for access to and from networks
outside the campus. This includes:
•
MnNET (and the Internet)
•
Publicly visible servers
•
Third party connections (e.g. private lines to vendors, site-to-site VPNs
with businesses or other schools)
May 24, 2005
DRAFT
Page 20 of 20
•
Remote access VPNs
Each of these should have their own segment.
Access Controls
Switch-level access controls should be straightforward in these segments. All
network ports in these zones should be in a server room or other secure location. Port-level access control mechanisms could be used to provide an extra
layer of security.
Outbound Access To Other Modules
Outbound access will depend on the particular applications. For example,
DNS servers need access to root servers, mail servers need access to send
mail, VPN connections need access to their peers, and so forth.
Inbound Access From Other Modules
Inbound access is also on a per-application basis.
Other Controls
This zone should not share a physical switch with other internal zones or public-access zones DMZ segments may share physical infrastructure with each
other, but should not be on the same switch as internal or external segments.
IDS monitoring should be used extensively within this module.
3.2.7
Data Center
General Considerations
The data center contains back-end servers and databases for a campus.
Access Controls
As with the external access zone, any switch ports in a data center should be
behind physical security mechanisms (e.g., a server room). Port-level access
control mechanisms could be used to provide an extra layer of security.
Outbound Access To Other Modules
Outbound access will depend on application needs.
Inbound Access From Other Modules
Inbound access also depends on application needs, but obviously includes
access to the servers hosted in the segment. Administrators will need more
access than general users.
Other Controls
This is another good location for a well-monitored IDS.
May 24, 2005
DRAFT
Page 21 of 21
3.2.8
Network Core
General Considerations
The network core is the central location for routing and switching traffic between all the other network zones.
Access Controls
Since the core devices connect directly, port-level access is not a concern.
Outbound Access To Other Modules
Most traffic passes through the network core. The core itself may need limited outbound access for routing protocols, but for the most part no
connections should be initiated from within the network core.
Inbound Access From Other Modules
Because of its central role in handling network traffic, direct access to core
network devices should be restricted to network administrators only.
Other Controls
Core network objects should use authentication wherever possible (e.g., in
routing protocols).
3.2.9
Out-of-Band Management
General Considerations
An out-of-band (OOB) network is highly recommended for managing network
devices. It uses separate VLANs to connect to router and switch management interfaces and to terminal servers connected to console ports.
The advantage of an OOB network is that once it’s in place, only users with
access to the out-of-band network can try to connect to network devices.
Depending on how it’s implemented, it can also provide a way for administrators to get at network devices even if the network is overcome with traffic (for
this to work, either the OOB network has to avoid sharing trunk lines with
data VLANs, or a bandwidth reservation policy has to be used to guarantee a
share of bandwidth to the OOB network).
Access Controls
No user ports belong to the OOB network.
Outbound Access To Other Modules
None.
Inbound Access From Other Modules
Only network administrators should be allowed access to the OOB network.
May 24, 2005
DRAFT
Page 22 of 22
Other Controls
3.2.10
Wireless
General Considerations
A wireless network is another medium for the types of segments already described in this section. However, it has its own issues for secure access.
Wireless campus networks can provide access for:
•
Students
•
Faculty and staff
•
Public users
Access for each of these groups should follow their wired-line guidelines. To
distinguish between them, multiple wireless SSIDs should be used (with
Cisco APs), or multiple wireless networks (for APs that don’t support multiple
SSIDs).
Access Controls
Wireless LANs for students, faculty, or staff should use access control. The
main options are:
•
802.1x
•
Wireless gateways (Bluesocket, Vernier, etc.)
•
Remote access VPNs
Public-access wireless LANs can be configured to use preconfigured “guest”
accounts, or to be completely open.
Outbound Access To Other Modules
Wireless LAN users should have the same outbound access as they would
have on the wired LAN, once authentication is completed and secure encryption is used.
Inbound Access From Other Modules
No access into the wireless segments should be allowed.
Other Controls
WEP is not an effective control.
LEAP is better, but is vulnerable to a dictionary attack.
Wireless security mechanisms could fill a document of their own.
May 24, 2005
DRAFT
Page 23 of 23
Chapter 4: Device Configuration
4.1
Router Security Guidelines
4.1.1
Router Access Control
This section describes measures that can be taken to secure the router itself.
Disabling Services
Cisco’s IOS provides many services and options which are either unneeded,
dangerous, or both.
The unneeded services listed in Table 1 should be turned off at the global
configuration level.
Service Name
Command
finger
bootp
HTTP
SNMP (see note)
Small services (echo, chargen, etc.)
no
no
no
no
no
no
no
no
no
CDP
Remote configuration
Source routing
service finger
ip bootp server
ip http server
snmp-server
service tcp-small-servers
service udp-small-servers
cdp run
service config
ip source-route
Table 1: Router services to disable
Note: SNMP may be needed for network management, and CDP is often
used by IP phones. Verify that these protocols are not needed before disabling them.
The commands in Table 2 should be applied at the interface level.
Description
Command
Block Smurf attacks
Mask replies
Proxy arp
no ip directed-broadcast
no ip mask-reply
no ip proxy-arp
Table 2: Router interface commands
Securing Access to the Console, AUX, and VTY Lines.
The console, AUX, and VTY ports provide command-line access to the
router. They should be configured to ensure that only authorized users can
access the router. This is done through passwords and access lists.
Passwords can be managed through static passwords, local user accounts,
or via a RADIUS or TACACS+ server.
May 24, 2005
DRAFT
Page 24 of 24
TACACS+ should be used where possible to permit username and password
authentication instead of a single shared password. It also allows for centralized management of administrator accounts and for command authorization
according to user and group roles. If a TACACS+ or RADIUS server is not
feasible, local authentication can be used to enforce per-user authentication.
The AUX port should be disabled with the “no exec” command if that port is
not used. The AUX port could be used for out-of-band access via a terminal
server, and is sometimes used for analog dial-out, but otherwise it usually
can be disabled.
Table 3 lists commands that can be used to secure access to the console,
AUX, and VTY ports.
Description
Command
Five-minute timeout
Password-based login auth
exec-timeout 5 0
password <password>
login
login authentication <list-name>
Login authorization using
RADIUS/TACACS+
Command shell disabled
Restrict VTY connections by IP
no exec
no access-list 10
access-list 10 permit 192.0.2.0/24
line vty 0 4
access-class 10 in
Table 3: Line configuration commands
Passwords
Two commands can be used to provided password security. The most basic
is the “service password-protection” command, which hides passwords behind a very simple algorithm.
The “enable secret” command uses MD5 encryption to hide the enable password. It should be used instead of “enable password.”
Description
Command
Enable secret
Basic password protection
enable secret <password>
service password-encryption
Table 4: Password protection
Login Banners
Although they don’t prevent access to the router, login banners are still
needed as virtual “no trespassing” signs. A login banner should include the
following topics:
•
May 24, 2005
Router access if for authorized users only. The definition of “authorized
users” might be specified.
DRAFT
Page 25 of 25
•
•
Unauthorized access may be a violation of university policy and/or local,
state, or federal laws.
Access and use of the router may be monitored, and the user consents to
such monitoring.
A router login banner does not need to be as in-depth as a user login banner,
which would go into greater depth on monitoring and use of network data. It
should still cover the basics described above.
Figure 3 shows command to enter this banner on a Cisco router, along with a
sample message.
banner login %
This system is the property of <School>. Access is
permitted only by authorized administrators. Unauthorized
access may be subject to criminal prosecution. Access and
use of this system is subject to monitoring; by connecting
to this system you consent to this monitoring.
%
Figure 3: Login banner message
Generally, a login message should not give information about the device itself
(hardware, OS, etc.), since this might give useful information to a potential
attacker.
4.1.2
Network Access Control
Ingress Filtering
Border routers should be configured to block traffic coming from invalid addresses. This is called ingress filtering, and it can help prevent attacks that
use spoofed addresses.
Ingress filters should be used on any routers that sit between zones of control
(e.g., external routers providing access to MNET and extranet routers) applied inbound to external router interfaces. They should explicitly deny
incoming traffic with source addresses from:
•
•
•
May 24, 2005
RFC 1918 addresses (192.168.0.0/16, 172.16.0.0/20, 10.0.0.0/8), except
those that are used elsewhere in the MnSCU or State of Minnesota networks
Internal network addresses (i.e., if a campus uses 134.28.0.0/16, the ingress filter should block any incoming traffic claiming to be from this
network)
Other reserved or bogus network ranges, including:
o 0.0.0.0/8
o 127.0.0.0/8
o 169.254.0.0/16
o 192.0.2.0/24
o 240.0.0.0/4
DRAFT
Page 26 of 26
Ingress filtering is less useful on internal routers. However, it should be used
on any router interface where address spoofing is likely, such as publicaccess networks and residence halls.
Access Lists
When using access lists:
•
Use the “range” keyword on TCP and UDP deny entries to log full information.
Figure 4 shows lines that should be used at the end of any
traffic-control access list.
access-list 101 deny tcp any range 1 65525 any range 65535 log
access-list 101 deny udp any range 1 65525 any range 65525 log
access-list 101 deny ip any any log
Figure 4: ACL deny logging entries
This will log all dropped traffic, including source and destination addresses of TCP and UDP packets.
•
The “log-input” keyword can be used instead of “log” to add logging of the
source MAC address and receiving interface, which can be useful if a
single access list is applied to multiple interfaces.
•
Block incoming packets with the router address as source. This is sometimes used in “land” attacks, which send packets forged to contain a
router’s IP address as both source and destination.
Figure 5 shows the configuration to protect a router with IP addresses
192.168.1.1 and 10.1.1.1.
interface FastEthernet0/0
ip address 10.1.1.1 255.255.255.0
ip access-group 101 in
!
interface FastEthernet0/1
ip address 192.168.1.1 255.255.255.0
ip access-group 101 in
!
access-list 101 deny ip host 192.168.1.1 any log
access-list 101 deny ip host 10.1.1.1 any log
Figure 5: Blocking "land" attacks
Obviously, great care must be taken to ensure that this access-list is only
applied inbound to an interface, otherwise just about everything will
break.
4.1.3
Routing Protocol Security
When routing protocols are used, some steps should be taken to prevent
tampering with routing tables or updates. These include:
May 24, 2005
DRAFT
Page 27 of 27
Authentication
Use MD5 authentication where possible. Routing protocols that support MD5
authentication include RIP version 2, OSPF, EIGRP, and IS-IS1.
•
RIP version 2, EIGRP, and IS-IS use key chains and per-interface configurations. MD5 keys can be up to 16 bytes long. Figure 6 shows a
sample configuration for RIP, Figure 7 shows the configuration for
EIGRP, and Figure 8 contains the configuration for IS-IS.
interface FastEthernet0/0
ip rip authentication mode md5
ip rip authentication key-chain RIP_KEYS
key chain RIP_KEYS
key 1
key-string RIPv2password
Figure 6: RIP MD5 authentication
interface FastEthernet0/1
ip authentication mode eigrp 100 md5
ip authentication key-chain eigrp 100 EIGRP_KEYS
key chain EIGRP_KEYS
key 1
key-string EIGRPpassword
Figure 7: EIGRP MD5 authentication
interface Ethernet0
isis authentication mode md5
isis authentication key-chain ISIS_KEYS
key chain ISIS_KEYS
key 1
key-string ISISpass
Figure 8: IS-IS MD5 authentication
•
OSPF authentication can be configured either per-interface or per-area.
In either case, the MD5 key is defined per interface. If per-interface authentication is used, all neighbor routers must share the same password.
Area authentication requires all routers in an area to share the same
password.
Figure 9 illustrates per-interface MD5 authentication for OSPF, and
Figure 10 gives an example of per-area authentication..
interface FastEthernet0/0
ip ospf authentication message-digest
ip ospf message-digest-key 1 OSPFpassword
1
IS-IS supports MD5 authentication in IOS 12.3 and T-trains for previous versions. Older IOS
versions only support plain-text IS-IS authentication.
May 24, 2005
DRAFT
Page 28 of 28
Figure 9: OSPF MD5 per-interface authentication
interface FastEthernet0/0
ip ospf message-digest-key 1 OSPFpassword
!
router ospf 1
network 192.168.0.0 0.0.255.255 area 0
area 0 authentication message-digest
Figure 10: OSPF per-area MD5 authentication
Table 5 summarizes the per-interface commands used in routing protocol
MD5 configuration.
Protocol
Interface Commands
RIP v2
ip rip authentication mode md5
ip rip authentication key-chain <label>
ip authentication mode eigrp <area> md5
ip authentication key-chain eigrp <area> <label>
isis authentication mode md5
isis authentication key-chain <label>
ip ospf authentication message-digest
ip ospf message-digest-key <ID> <password>
EIGRP
IS-IS
OSPF
Table 5: Routing protocol authentication commands
Route Filtering
Route filtering can be used to control the route advertisements that are accepted from neighbor routers. Route filters are especially useful on border
routers, where someone else has control of the advertisements sent. They
can also be useful on internal routers, where they limit the impact of misconfigurations.
Route filters should be used judiciously on internal routers. If the route filters
are too strict or too specific, the result can be merely a complicated form of
static routing.
4.1.4
Logging and Monitoring
Proper logging and monitoring of router events and network traffic is vital to a
secure network. Logging and monitoring facilities on Cisco routers include:
•
Console port and VTY messages
•
Local buffered logging
•
Remote logging to a syslog server
•
AAA accounting
Guidelines for logging include the following suggestions:
•
May 24, 2005
Turn on logging. Log to a local buffer and, where possible, to a syslog
server. The log buffer size will depend on the router model and amount
DRAFT
Page 29 of 29
of free memory, but a 15000-byte buffer is usually reasonable on a low
end router, with larger memory sizes possible on high-end routers.
•
Logging should be tagged with timestamps, not uptime values. NTP
should be used so that timestamps are consistent among different network devices.
•
Use harder-to-guess SNMP strings; disable SNMP if not used, or use a
read-only string (not possible if Ciscoworks is used)
•
If SNMP access is enabled, the access list option should be used. This
option keeps SNMP access to the router restricted to addresses defined
in the ACL.
Table 6 lists some commands used in securing logging and monitoring.
Description
Command
Logging buffer size
Buffer log level
Log to syslog server
Syslog facility
Log with timestamps
Read-only SNMP w/ ACL
Read-write SNMP w/ ACL
logging buffered <size>
logging buffered <level>
logging <hostname>
logging <facility>
service timestamps log datetime msec
snmp-server community <string> ro <acl>
snmp-server community <string> rw <acl>
Table 6: Logging and monitoring commands
4.1.5
Router Security Checklist
Unneeded services
finger
bootp
HTTP
SNMP
TCP and UDP small services
CDP
Remote Configuration
Source Routing
Unneeded interface services
Directed-broadcast
Mask replies
Proxy arp
Console, AUX, and VTY port security
May 24, 2005
DRAFT
Page 30 of 30
Set exec mode timeout
Enforce login authentication using single password, RADIUS,
TACACS+, or local user database
Disable AUX port if not used for remote access
Restrict VTY connections by IP
Use enable secret, not enable password
Establish a login banner
Use ingress filtering
Access lists
Use the range keyword to log port information
Block incoming packets with a router IP as source
Authenticate routing protocols with MD5
Filter incoming route advertisements where practical
Logging and monitoring
Enable buffered logging
Log to a syslog server
Tag logs with timestamps
Enable NTP to set the router time
Use hard-to-guess SNMP strings
Restrict SNMP access with ACLs
4.2
Switch Configuration Guidelines
This section contains some guidelines for secure switch configuration. Many
of these recommendations are aimed at preventing layer 2 attacks. These
attacks include VLAN-hopping, MAC flooding, and man-in-the-middle attacks
that could let users snoop traffic they shouldn’t see.
Because two different versions of switch OS are still widely in use (CatOS
and Native IOS), the recommendations here are high-level, without configuration specifics.
4.2.1
VLANs and Trunks
VLAN 1
VLAN 1 has a special purpose in Cisco switches. It’s used for CDP, VTP
(VLAN Trunking Protocol), and PAgP (Port Aggregation Protocol). All ports
are part of VLAN 1 by default.
May 24, 2005
DRAFT
Page 31 of 31
This control plane data should be kept separate from user data. To do this,
choose additional dedicated VLANs for the following purposes:
•
Trunk ports. This VLAN should be used as the “native” VLAN on trunks.
•
Unused ports. These unused ports should also be disabled where possible.
•
Management VLAN. The management VLAN should be used for administrative access to switches, and should be different from VLAN 1 or user
VLANs.
Don’t use VLAN 1 for user, management, or trunk ports where possible.
Trunks
Another category of layer 2 attacks exploit auto-trunking interfaces. If a user
can establish a trunk with the switch, that user could initiate VLAN changes,
pruning, or snoop traffic. To secure trunks:
•
Disable Auto-trunking
•
Set all user ports to non-trunking
•
Disable the VLAN Trunking Protocol (VTP), or use the VTP MD5 digest if
it is needed.
Private VLANs
Private VLANs (PVLANs) are a technology to mitigate layer 2 attacks, especially ARP-based attacks. A device on a PVLAN is able to communicate
directly with its default gateway, but not with other hosts on that VLAN
(unless routed back to them). In essence, each host on a PVLAN gets its
own VLAN without wasting address space. PVLANs mitigate ARP attacks
because the only device to see ARP requests will be the gateway router.
Note that most inter-host communication is disabled when PVLANs are
turned on. That’s not a problem in network segments where no peer-to-peer
communication should be happening, but it means that PVLANs might not be
feasible where both clients and servers reside (e.g., a faculty segment where
faculty host their own web sites).
PVLANs should be used where possible, but they won’t be feasible in all areas of a network.
4.2.2
Spanning Tree
The Spanning Tree Protocol (STP) is used to ensure a loop-free switch topology. It can be exploited by when an attacker uses STP to become the root
bridge, routing all traffic through the attacker’s system.
Two techniques should be used to deal with this issue:
May 24, 2005
DRAFT
Page 32 of 32
4.2.3
•
Enable BPDU Guard. BPDU Guard disables any port using portfast when
a BPDU message is detected on that port. Because portfast should only
be used on non-trunk ports, a BPDU message on that port indicates an
attack.
•
Enable Root Guard. Root guard disables ports that send BPDU root
bridge advertisements.
Management
The methods used for switch management are also important to security.
Properly restricting administrative access to switches keeps attackers from
changing the rest of the security settings described in this chapter.
4.2.4
•
Use SSH. Most other switch administration protocols operate in clear-text
(e.g., Telnet), which allows passwords to be captured.
•
Use an out-of-band (OOB) management VLAN. The OOB VLAN should
only allow access from the network administration VLAN, or to specific
administrator IP addresses.
•
Restrict switch access to authorized IP addresses.
•
Use a dedicated management VLAN (not VLAN 1) as described in Section 4.2.1.
Other Settings
Port Security
Port security restricts the number of MAC addresses that can be used on a
switch port. When the limit is reached, the port can be disabled or alarms
can be sent. This limits the effectiveness of MAC flooding attacks.
Each MAC address a switch sees on a secured port counts against the limit,
and is learned and locked in. Port security can be configured to age out
learned MAC addresses, based either on total time since the MAC was
learned (“absolute” aging) or on idle time (“inactivity” aging). Port security
aging is useful on segments where computers connect and disconnect frequently—users can still connect to ports, but MAC flood attacks are
prevented through the port security.
As general recommendations:
•
Use port security on all switch ports where it can be configured.
•
Mostly static LAN segments should be configured with a low MAC address limit (1-2) and a high aging time
•
More dynamic LAN segments should be configured with a higher MAC
address limit (2-4) and a low aging time.
May 24, 2005
DRAFT
Page 33 of 33
•
Beware of systems that legitimately create virtual MAC addresses on a
single host (e.g., virtual machine type applications).
DHCP Snooping
DHCP snooping can be used to limit the impact of rogue DHCP servers.
When DHCP snooping is used, the switch filters untrusted DHCP messages
and builds a table of valid DHCP assignments.
Ports are labeled as “trusted” or “untrusted.” Trusted interfaces are expected
to generate DHCP replies (e.g. DHCP server ports, uplink ports); untrusted
interfaces are not (e.g., user ports).
DHCP adds some latency to DHCP responses. It may not be feasible in all
networks.
IP Source Guard
If port security, DHCP snooping, and IP source guard are all enabled, a
switch will limit a port to the IP address assigned by the DHCP server.
4.2.5
Switch Security Checklist
Don’t use VLAN 1
Use separate, dedicated VLANs for:
Native trunk ports
Unused ports
Management VLAN
Disable unused ports (when possible)
Trunks
Disable auto-trunking
Set all user ports to non-trunk
Disable VTP or use VTP MD5 digest
Use Private VLANs
Spanning Tree
Enable BPDU Guard
Enable Root Guard
Management
Limit in-band access to SSH
Use Out-of-Band management
Use an access list to restrict access to the switch
Enable port security
May 24, 2005
DRAFT
Page 34 of 34
Enable DHCP snooping (if feasible)
Enable IP Source Guard
May 24, 2005
DRAFT
Page 35 of 35
Appendix A: References
Cisco SAFE Blueprint
http://www.cisco.com/en/US/netsol/ns340/ns394/ns171/ns128/networking_solutions_pac
kage.html
NSA Cisco Router Security Recommendation Guides
http://nsa2.www.conxion.com/cisco/download.htm
Cisco: Improving Security on Cisco Routers
Document ID: 13608
http://www.cisco.com/warp/public/707/21.html
RFC 2267: Network Ingress Filtering: Defeating Denial of Service Attacks which
employ IP Source Address Spoofing
RFC 3330: Special-Use IPv4 Addresses
RFC 3704: Ingress Filtering for Multihomed Networks
Best Practices for Catalyst 4500/4000, 5500/5000, and 6500/6000 Series Switches
Running CatOS Configuration and Management
http://www.cisco.com/warp/public/473/103.html
SAFE Layer 2 Security In-depth Version 2
http://www.cisco.com/en/US/netsol/ns340/ns394/ns171/ns128/networking_solutions_whi
te_paper09186a008014870f.shtml
May 24, 2005
DRAFT
Page 36 of 36