network architecture - minnesota state - minnesota state ... · table 4: password protection ......

Network Architecture

Security Guidelines

May 2005

Revision History Version Date Author Comments 0.1 2/28/05 Jim Graves Initial draft 0.2 4/15/05 Jim Graves Added router and switch config sections

May 24, 2005 DRAFT Page i of i

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 ii of ii

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 1 of 1

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 633-student Rainy River Community College. Each college or university has its own CIO and IT infrastructure thats 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 architec-ture 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 dont. Most of the large state colleges provide on-campus student housing; community colleges may or may not do so. Whether housing is provided doesnt depend on campus size. For example, Vermillion Commu-nity 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 architec-ture recommendation for MnSCU must meet unique (and sometimes contradictory) goals:

Information Security and Open Access: MnSCU schools handle sensi-tive 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 re-cords. 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 MnSCUs educational institutions have mis-sions that include openness and service to the community. College


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 informa-tion 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 informa-tion 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 net-work 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:

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 imple-ment, in terms of time and financial resources needed for migration and management of the architecture.

1.3 Scope This project reviewed current MnSCU school networks with the goal of rec-ommending 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


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 privi-leges 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? Thats a policy question. Once that policy has been established, the network architecture should enforce that level of ac-cess.

2.1.2 Layered Security Layered security (often called defense-in-depth) is the concept that security functions should happen at multiple layers. Its not enough just to have fire-walls, encryption, or application loginsthese technologies and others must be combined to provide effective security.

The advantage of layered security is that it helps avoid the Tootsie Pop syn-drome, 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.

Polic

ies

and

Proc

edur

es

AC

Ls

Fire

wal

ls

VPN

App

licat

ion

Prox

ies

Intr

usio

n D

etec

tion

Figure 1: Layered security


This concept is illustrated in Figure 1. Different technologies protect different layers of the OSI model. Figure 1 doesnt list all security technologiesjust enough to show a sample of how layered security works.

The physical layer is the first level of defense. Traditional security meas-ures such as locks, cameras, walls, and security guards are used to prevent unauthorized users from gaining access to a buildingor to its LAN.

Although educational institutions do have physical security measurescameras and guards (or campus police), for examplemany MnSCU campuses are open to all. It is difficult to control physical access to net-work data ports in such campus environments.

The next layer of defense protects the Data Link layer by preventing un-authorized access or mischief at the switch level. Access to the network can be controlled by disabling unused ports or using 802.1x authentica-tion, for example. Some VPNs operate at this layer.

Firewalls and ACLs are at the next layer of defense. They restrict the net-work 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 includ-ing 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 ac-counts, 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 secu-rity policy. Firewalls can stop many network attacksbut only if theyre configured properly. Security patches are useless if theyre 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, develop-ment, deployment, and operations.


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 ac-cess 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 schoolfaculty 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 con-trol between each segment.

Segmentation helps avoid the soft chewy center problem. Consider serv-ers, for example. Most users within an organization dont 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 fol-lowed. 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


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 theyre introduced. For example, if a stu-dent 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 Ciscos 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, its important to bear in mind the threats that are being protected against. Although an in-depth taxonomy of security threats and risks is beyond the scope of this document, a general overview is valuable for setting the context of the net-work architecture guidelines.

2.2.1 Modes of Attack There are two primary modes of attackactive 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 theres someone making the attack, try-ing exploits, and doing activities that are primarily on-line and real-time.

Hackers can be external, but in an academic environment its just as likely that theyll 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 doesnt have to be online (or even awake) for the attack to be made. Once a worm is released into the wild, the author doesnt have to do any-thing to spread it (and, as in the case of the Morris Worm, usually cant stop it even if he or she wants to).

Worms and viruses arent quite as often considered when designing se-curity, but they should betheyre 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


could bring an entire network to its kneeswhile possibly creating back doors for active penetration.

Automated attacks thrive on flat, wide-open networks where internal us-ers are implicitly trusted. Those users may be trustworthybut 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 ex-haustive, 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 net-work 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 proc-esses, 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 af-fected system. A classic example is the ping of death, which exploited a problem in the way many TCP stacks handled overly large IP ping pack-ets.

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 re-sponds 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 con-nections 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 at-tacks, or else the zombie hosts just use all their available bandwidth to request services from the target host. The result can be devastating


even a site with a dedicated OC-3 (155 Mb/s) connection will be over-whelmed 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, its a bit harder to handle, since the DDoS attack uses up band-width. Ciscos (formerly Riverhead) Guards are one answer. Detectors located at an internet access point monitor the flow rate. If usage in-creases 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 band-width available than the ISPs 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 isnt 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 net-work 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 en-tering 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 layerapplications need to be patched so that they arent vulnerable to the worm. Software products also exist that try to prevent any buffer-overflow bug from working (e.g., Ciscos 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 informa-tion gathered, the software is unwanted.


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 appli-cations 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. Thats 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 exe-cute code. In the academic environment, where the schools dont control users machines, its 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 net-work. IDS scanners can be helpful. More severe techniques, such as blocking FTP, HTTP, e-mail attachments, Java applets, or ActiveX ap-plets, 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 dont 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 dont apply.

The dictionary attack is an off-line password cracking method. In this at-tack, 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 pass-word, 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 en-cryption) 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 meth-ods of getting around that. When a switch becomes confused, it reverts to its childhood and becomes a hubspewing every packet it sees out of all its interfaces. Freely available tools such as Ettercap take advantage


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 sniff-ing.

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, its called session hijacking.

The best defense against man-in-the-middle attacks is good protocol de-sign. 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 MnSCUs 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 in-formation. This obviously includes improper access to academic records, but also includes access to financial records, health records, or even li-brary records. All of these are considered confidential.

Identity theft is a particularly notable type of information theft. If an at-tacker gets enough information about a single person, the attacker can get credit cards, withdraw money from checking accounts, or buy prod-ucts under that persons name. The financial effects of an identity theft can be devastating to a victims 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 greaterespecially if effective audit and log information is not kept.

Theft of Resources: Information technology is almost always a finite re-source 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 its unnoticeable (e.g., one quiet user on a network of thousands), or so major that it cant 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 MnSCUs 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:


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.


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.

MnSCUs institutions have varying network environments and requirements. The architecture described here is modular, so that schools may include com-ponents that apply and ignore those that dont.

Some modules will apply to all schools. Its hard to call a place a school if it doesnt have students or faculty, for example. All networks will also have some sort of network core and access to MnNET (and, through it, the Inter-net).

Each campuses may or may not have wireless networks, residence halls, ap-plication servers, or public access networks. Schools may also vary in the amount of segmentation they want to do. Some may want to further subdi-vide 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 theyre 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 be-tween 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.

Access lists are possible with all Layer 3 Cisco equipment. They can permit or deny traffic by IP header information, including source and des-tination address, IP protocol number, and TCP or UDP port numbers.


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 dynami-cally 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 doesnt 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. Ciscos PIX module for the 6500 series switch is one option for firewalling in the net-work 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 thats 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 doesnt 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 its hard to stay on top of disabling them when theyre no longer used. MAC-based switch port access control methods


arent realistic for situations where different devices frequently connect to the same ports.

802.1x solves many of these problemsits portable, authenticates based on user identity, and requires much less administrative effort after its set up. It can also be used with Dynamic VLAN assignment to determine a switch ports VLAN based on the 802.1x credentials of the user connected to it. But its also new enough that most deployed switches dont support it yet. How-ever, if network equipment supports 802.1x, its highly recommended. Even if current equipment doesnt support it, 802.1x should be deployed where ap-propriate in newly installed switches.

Ciscos 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 cli-ent on the users 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, theyre only able to get to the authentication web page. Once authentication is passed, theyre allowed past the gateway. The advantage of this mechanism is that it doesnt require a client on the users PC, can usually tie into existing authentication data-bases (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, theyre pretty much part of the definition of a school). In network architecture terms, the student module in-cludes any campus devices dedicated to student access except residence halls. These have special considerations, and should have a separate net-work segment.

The student component includes classrooms and academic computer clus-ters. 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).


Access Controls School-managed computers in this zone should require user logins and en-force 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 great-est ability to use their own machines however they can. In such an environment, residence halls represent a greater threat to the rest of the cam-pus (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 doesnt 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 stu-dents to get their homework done and allow academic freedom?


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 schools 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 ex-pected 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, es-pecially 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, includ-ing 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. Cer-tainly the easiest policy is to deny all inbound access to student computers. However, some schools may have academic freedom and open access poli-cies 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 cant 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 initiat-ing viruses and attacks. The IDS should be tuned for aggressive session disconnection when it sees attacks coming from an internal host, and if pos-sible 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 protocolfor exam-ple, to specifically limit peer-to-peer traffic.


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 higher-level 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 net-work 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 fac-ulty offices. Although faculty offices probably arent locked or monitored as often as they should be, its safe to say that if someone were in a faculty of-fice, theyd also have physical access to sensitive non-network information.

School-managed computers in this zone should require user logins and en-force 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 en-vironment as they are for students.

Outbound Access To Other Modules As with other modules, this will be determined by policy. However, the follow-ing 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 ac-cess to them.

Administrative IT staff need access to the out-of-band management net-work, 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 al-lowed from the student module, and possibly from the public-access


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 organiza-tions. 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. Vol-untary 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 excep-tions; 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 ex-ample, RST could be used to disconnect an attack session, or an offending users 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 ac-


cess removable storage (CD-ROMs, floppy drives, USB drives, etc.). Public-access 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 itselfas serving the gen-eral 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 tradi-tional 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 gen-eral 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 dont 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 us-ers 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 library-provided systems sufficient?

The questions of library policyespecially as they pertain to Internet access and web filteringcannot 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.


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 ad-dresses. If open network jacks are provided, its infeasible to lock them down.

Where policy allows it, system logins should be used to control access to au-thorized 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 Inter-net 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 Where policy allows, public Internet terminals should be secured as de-

scribed in Section 3.2.4.

Public-access library systems should not share a physical switch with other internal zones.

3.2.6 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)


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 loca-tion. 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 pub-lic-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.


3.2.8 Network Core

General Considerations The network core is the central location for routing and switching traffic be-tween 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 lim-ited 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 manage-ment interfaces and to terminal servers connected to console ports.

The advantage of an OOB network is that once its in place, only users with access to the out-of-band network can try to connect to network devices. Depending on how its implemented, it can also provide a way for administra-tors 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.


Other Controls

3.2.10 Wireless

General Considerations A wireless network is another medium for the types of segments already de-scribed 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 dont 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 encryp-tion 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.


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 Ciscos 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 no service finger bootp no ip bootp server HTTP no ip http server SNMP (see note) no snmp-server Small services (echo, chargen, etc.) no service tcp-small-servers

no service udp-small-servers CDP no cdp run Remote configuration no service config Source routing no 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 dis-abling them.

The commands in Table 2 should be applied at the interface level.

Description Command Block Smurf attacks no ip directed-broadcast Mask replies no ip mask-reply Proxy arp 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.


TACACS+ should be used where possible to permit username and password authentication instead of a single shared password. It also allows for central-ized 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 exec-timeout 5 0 Password-based login auth password

login Login authorization using RADIUS/TACACS+

login authentication

Command shell disabled no exec Restrict VTY connections by IP 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 be-hind a very simple algorithm.

The enable secret command uses MD5 encryption to hide the enable pass-word. It should be used instead of enable password.

Description Command Enable secret enable secret Basic password protection service password-encryption

Table 4: Password protection

Login Banners Although they dont prevent access to the router, login banners are still needed as virtual no trespassing signs. A login banner should include the following topics:

Router access if for authorized users only. The definition of authorized users might be specified.


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 . 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 ad-dresses. 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) ap-plied inbound to external router interfaces. They should explicitly deny incoming traffic with source addresses from:

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 net-works

Internal network addresses (i.e., if a campus uses 134.28.0.0/16, the in-gress 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


Ingress filtering is less useful on internal routers. However, it should be used on any router interface where address spoofing is likely, such as public-access networks and residence halls.

Access Lists When using access lists:

Use the range keyword on TCP and UDP deny entries to log full infor-mation. 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 ad-dresses 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 some-times used in land attacks, which send packets forged to contain a routers 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:


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 con-figurations. 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 au-thentication 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.


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 EIGRP ip authentication mode eigrp md5

ip authentication key-chain eigrp IS-IS isis authentication mode md5

isis authentication key-chain OSPF ip ospf authentication message-digest

ip ospf message-digest-key

Table 5: Routing protocol authentication commands

Route Filtering Route filtering can be used to control the route advertisements that are ac-cepted 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 miscon-figurations.

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:

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


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 net-work 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 logging buffered Buffer log level logging buffered Log to syslog server logging Syslog facility logging Log with timestamps service timestamps log datetime msec Read-only SNMP w/ ACL snmp-server community ro Read-write SNMP w/ ACL snmp-server community rw

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


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 shouldnt see.

Because two different versions of switch OS are still widely in use (CatOS and Native IOS), the recommendations here are high-level, without configura-tion specifics.

4.2.1 VLANs and Trunks

VLAN 1 VLAN 1 has a special purpose in Cisco switches. Its used for CDP, VTP (VLAN Trunking Protocol), and PAgP (Port Aggregation Protocol). All ports are part of VLAN 1 by default.


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 possi-ble.

Management VLAN. The management VLAN should be used for admin-istrative access to switches, and should be different from VLAN 1 or user VLANs.

Dont 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, espe-cially 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. Thats 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 wont be feasible in all ar-eas of a network.

4.2.2 Spanning Tree The Spanning Tree Protocol (STP) is used to ensure a loop-free switch to-pology. It can be exploited by when an attacker uses STP to become the root bridge, routing all traffic through the attackers system.

Two techniques should be used to deal with this issue:


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.

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

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 Sec-tion 4.2.1.

4.2.4 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 fre-quentlyusers 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 ad-dress 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.


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 Dont 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


Enable DHCP snooping (if feasible)

Enable IP Source Guard


Appendix A: References Cisco SAFE Blueprint http://www.cisco.com/en/US/netsol/ns340/ns394/ns171/ns128/networking_solutions_package.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_white_paper09186a008014870f.shtml

network architecture - minnesota state - minnesota state ... · table 4: password protection ......

Documents