University of Insecurity

University information security is always very interesting. Because of the need to provide an academic environment that encourages information sharing and experimentation, the underlying security of the network often suffers. A key difference from a traditional business network is that the campus network in a university is often not much more secure than the Internet at large.

Organization Overview

University of Insecurity (UI) is a medium-size university with two main campuses within one city and a number of satellite campuses in the smaller cities around the main university. It has an undergraduate population of 20,000 students, nearly all of whom live on campus. Like most universities, it has no host standards for most systems beyond basic guidelines encouraging the use of antivirus and timely patching.

Current Design

The current design is shown in Figure 17-3. This is a high-level diagram focused on the main areas of the network rather than the actual topology.

Figure 17-3. University of Insecurity Current Network Design

As you can see, firewalls are a four-letter word in most university networks. To satisfy the needs of the students and researchers, a firewall would need to be so porous as to not be of any real use. UI currently uses routers with no security as its primary means of interconnection. All systems are of equal trust from the network's perspective. There are certainly L3 divisions throughout the network, but this is for traditional network design reasons rather than security. In addition to the connections to the Internet and the satellite campuses, campus 1 connects to a national research network.

After realizing that nearly 400 student and administrative systems in UI were compromised as part of a DDoS network, the IT staff was able to push through general agreement that some form of security is needed at UI. The IT staff at UI is modest. There are a few individuals with more security expertise than the rest, but they have been mostly tasked with dealing with critical incidents in one or more of their networks.

Security Requirements

The following are the basic network-relevant INFOSEC decisions UI wishes to make.

Internet Connectivity

Because the Internet is a significant source of attacks, some visibility into the attacks occurring on the network is necessary. In keeping with UI's academic focus, Internet firewalls for all traffic are unacceptable. Public services must be better protected against direct attack, however, so firewalls might be appropriate there.

Student Connectivity

After determining that nearly 50 percent of the bandwidth to the Internet was being consumed by peer-to-peer (P2P) file-sharing applications, UI enacted a new policy that mandates certain limits on bandwidth use from the student networks. In addition, the ability to filter out specific applications is needed on a best-effort basis. An implicit "permit any" is the default rule. In addition, some protections against traffic sniffing and man-in-the-middle (MITM) attacks were written into the policy.

Administrative Systems

Most of the policy's focus centers on the administrative systems. It was decided that administrative systems should be secured and kept separate from the rest of the network. Firewalls can be used here as necessary. Although encryption of all administrative applications was deemed too burdensome, strong authentication is required for certain key systems (accounting and student records).

Management Systems

Much like administrative systems, the management network should be separated and secured. Secure management should be used whenever possible for remote systems, and all management traffic should be filtered to limit management spoofing.

WAN Connected Networks

Both the research network and the remote satellite networks need direct access to all services on the campus. Filtering the research network was deemed too restrictive, but it was decided that some ability to view traffic types and flows from the research network would help identify any major attacks.

WARNING

At this point, you have enough information to design the network on your own. After you have tried your hand at the design, turn the page to compare your design to those in the book. Be sure also to consider how the network will migrate to the more secure design.

 

Design Choices

The IT staff decided that the best course of action is to treat the campus network much the same as the Internet in terms of security. Figure 17-4 shows the proposed design. It centers on a design concept I call "islands of trust."

Figure 17-4. University of Insecurity Proposed Network Design

The basic design works by inserting network IDS (NIDS) sensors into the insecure campus network. These should be placed close to the research network and the Internet connection because those are the two most likely sources of malicious traffic. The administrative and management networks are fully separated from the rest of the network by firewalls and, in the case of the administrative network, NIDS. Islands of trust allow UI to focus on securing the systems it cares the most about, leaving the bulk of the network fairly open. This concept can be applied to other elements of UI's network not detailed here such as wireless networks, libraries, and so on.

Basic Changes

Because much of the network must stay fairly open, the level of enforcement that the network can provide is limited. The majority of the security concerns falls on the hosts and applications in these designs. The network is not without some impact, though. First, RFC 2827 filtering should be implemented at all L3 edge devices, and bogon filtering should be implemented at the Internet edge (both discussed in Chapter 6). Second, the network devices must be hardened against direct attack using the techniques described in Chapter 5. Routing protocol authentication is used throughout the internal network and in the connections to the Internet and the research networks.

Additionally, regular audits are put in place to survey the security of hosts connected to UI's network. This will give the IT staff some visibility into the security posture of the connected systems and the ability to notify host admins of problems hopefully before a compromise occurs.

For critical hosts, various host security controls should be considered, as discussed in Chapter 4, "Network Security Technologies." For example, host IDS (HIDS) and file system integrity checkers should be deployed on the accounting and student records systems. Antivirus should be deployed everywhere. As stated before, though, student systems are not under UI's control, so the best that can be done is to make the software available to the students and educate them on its use.

Internet Connectivity

NIDS gives the IT staff the ability to see malicious traffic without blocking it. In the university environment, this is often the best that can be done for the main network, not including administrative systems. In addition to NIDS, NetFlow is enabled on the edge routers to gain better visibility into anomalies on the network. The NetFlow data is sent to the management network, where it is analyzed by software specifically built to deal with NetFlow data (discussed in Chapter 16, "Secure Network Management and Network Security Management"). This will also give the IT staff some visibility into the effectiveness of the bandwidth-limiting measures in the student network and whether there are other sources of excessive bandwidth consumption elsewhere in the network.

The public services are moved off of a dedicated firewall close to the Internet edge and also protected with NIDS. This allows critical web, DNS, and e-mail services to be protected without causing all traffic to flow through the firewall.

TIP

So much of the university security problem is a lack of awareness of the systems that are connected to the network. Using mapping software such as Nmap (particularly with its operating system [OS] identification features) can be a huge help in understanding where vulnerabilities lie in the infrastructure.

 

Student Networks

In addition to the bandwidth limiting, which is more a function of quality of service (QoS), some attention should be paid to the L2 network. Even though the key assets for the university are protected in another area of the network, the students need basic protections to help mitigate attacks from one student system to another. Although the bulk of this will be left to the applications and hosts, L2 security controls (Chapter 6) can be a big help in limiting sniffing and MITM attacks. The limited filtering that was stipulated in the security requirements can be done with stateless ACLs on the routers between the student networks and the rest of the university.

Administrative Networks

The administrative networks follow a design model very similar to the small network campus and edge design in Chapters 13 and 14. A firewall protects the network from the rest of the university network and the Internet at large. Specific access rights are written into the policy to allow the users of these systems to access the applications remotely. Additionally, limited public services can be deployed here using a dedicated interface off of the firewall. This might be most appropriate for the administrative network of a specific college within the university. It might wish to have its own web presence that is managed and secured by that school.

AAA and one-time passwords (OTPs) are also shown here as a mechanism to strongly authenticate users of key applications.

Management Network

The management network is set up much like the administrative network. All the systems are protected by a firewall, and specific connections are allowed inbound and outbound based on the management needs of the devices around the network. Because so much of the surrounding network is untrusted, secure management should be preferred for any type of configuration change. This means using SSH/SSL whenever possible. There will be cases when Telnet is required because there are no other options. Devices that must use cleartext management protocols (such as Telnet) should limit the L3 addresses that can access the Telnet daemon, as shown in Chapter 5 and further discussed in Chapter 16. Depending on the security options your management protocols have, you might opt for direct connections from the management network to the administrative and public services networks.

Migration Strategy

The university network is fairly large and spread out, but the security improvements are fairly contained. The following steps show a possible migration plan for UI, though many are possible depending on the priorities of the university:

1.	Map the network and identify the critical systems with the greatest need for hardening and patching. Then, starting with those systems, improve the host and application security of all the systems in the network.
2.	Harden all the network devices and implement RFC 2827 and bogon filtering.
3.	Deploy the NIDS throughout the network to start getting immediate visibility into attack activity on the network.
4.	Migrate the management systems to a dedicated segment protected by a firewall. Transition to secure management when possible and filtered management everywhere else.
5.	Move the administrative systems to dedicated networks protected by firewalls and NIDS.
6.	Transition the public services to a firewall-protected segment near the Internet edge.
7.	Implement L2 security and bandwidth-limiting measures for the student network.
8.	Configure NetFlow on the Internet edge routers and pass that information to the management network to be analyzed.

Attack Example

There are several likely attacks within the university environment. DDoS infections or attacks, critical system compromises, and student network attacks are all possibilities. Each is highlighted in the following sections.

DDoS Infections/Attacks

It is quite common for attackers to target university networks to build DDoS networks. Universities often have high-speed connections to the Internet and very little control over all hosts on the network, making them ideal victims for DDoS infection. This is certainly true for UI. Nothing in the proposed design prevents these infections from occurring for hosts not protected by firewalls. Even hosts behind firewalls are vulnerable if there is an exploit available for the application versions they are running. Proper patching and hardening techniques must be communicated to all university users and actively audited on a regular basis by using automated scans.

RFC 2827 filtering limits the ability for the traffic to be spoofed as it leaves the university, but most DDoS networks don't spoof traffic anymore. The main visibility into DDoS infections (and attacks) occurs only after a DDoS attack originating from UI begins. The NetFlow and NIDS should both quickly alarm at the anomalies they detect in the Internet edge. Additionally, UI should have arrangements with its ISP to quickly shut down any DDoS attack directed at the university network.

Critical System Compromises

Another common attack will be directed against the public services, administrative systems, or other high-profile systems within the university. Attackers could be motivated by nearly anything, including changing their grades! Because these systems are far less numerous than the rest of the network, more time can be spent securing these systems and diligently keeping them up-to-date. The firewall, host security controls, and NIDS (where deployed) augment this increased attention from the IT staff to provide defense-in-depth against many of the common attacks directed against these systems.

Student Network Attacks

Another common attack will be students, primarily out of curiosity, attacking each other's systems. These attacks will occur unmolested in most cases because there are no strong protections for host security in the student networks. PVLANs could make a difference but would be far too restrictive on interhost communication. What is best is a commitment to educating users about proper patching and host antivirus use.

Universities and Viruses

Viruses are fairly prevalent in universities, even long before the days of the Internet. Back when I was doing basic PC repair/LAN work in the early 1990s, a coworker once quipped that even driving by a university could result in any floppy disks in your car getting infected by the "stoned" virus (a popular, but mostly benign, virus of that time that infected the master boot record [MBR] of floppies and hard disks). Make sure antivirus is available for all systems in a university network.