Enterprise SAFE Axioms

Axioms are general truths accepted on their intrinsic merit. They are used as the underlying principles to prove other, less obvious truths. The SAFE Blueprint includes a number of axioms, and you should know what they are.

Routers Are Targets

This is the first axiom . Routers are the traffic cops of the network, determining what traffic is allowed and what is denied , and what those on the other side of a connection know about what is on this side (advertisement). Another view of routers is that they are the gatekeepers of a network. Whichever view you prefer, their role makes them a high-priority target for anyone trying to enter or misuse any information asset on the network. Control of a router makes traffic redirection or illegal entry possible. Routers should be protected by the following:

• Locking down Telnet access

• Locking down SNMP access

• Applying access control through TACACS+

• Disabling all unneeded services

• Requiring authentication of routing updates

These methods are discussed in more detail in Chapter 9, "Products in the Edge." Remember, of course, that the router you are protecting is not an isolated element, but is one element of a larger network design. That design can help protect the router; for instance, an external firewall can help limit the potential threats that can reach the router. Likewise, you can always take measures that are not listed in this part of the SAFE Blueprint or in the IOS Security Configuration Guide, such as logging activities that might have security impactsand reviewing those logs.

Switches Are Targets

Perversely, there is less readily available information on securing switches than there is on securing routers, yet switches touch more resources directlyespecially the high-value resources, such as serversthan routers do. The recommendations for routers certainly apply (with the possible exception of the last item, depending on whether the switch also operates at Layer 3). However, because they access so many devices via so many ports, and because they operate primarily at Layer 2, where filtering and traffic control is more difficult, they require extra precautions :

• Disable all unused ports.

• Enable trunking (including automatic trunking) only on ports that actually need it.

• Trunking ports require extra precautions:

  • Use a dedicated VLAN ID.

  • VLAN 1 might have special meaning for some vendors .

  • Eliminate native VLANs from any 802.1q trunks.

• If possible, limit the MAC addresses associated with a given port to two or three. (Remember that a switch essentially directs traffic according to the MAC addresses from which traffic enters a given port. If you have many addresses at one portsuch as a many-device hubbed segment attached to the portcontrolling traffic to and from the port is more complex than if you have implemented a switched network with very few hosts per port.)

• Manage change control ( especially on switches that can be modified by multiple departments).

• Use private VLANs to limit traffic between hosts in the same VLAN (force the traffic to Layer 3 for filtering).

These methods are discussed in more detail in Chapter 8, "Products in the Campus."

Private VLANs?

If you are not familiar with private VLANs, you should be: They are used in almost every module of the SAFE Blueprint. In an ordinary VLAN, members of the VLAN exchange traffic via Layer 2; traffic is never decapsulated as far as Layer 3, so security features made possible by filtering on IP or upper-layer headers are not available. Even if traffic is on the same physical segment, traffic belonging to different VLANs is not seen by hosts except those that belong to the appropriate VLAN (hosts that belong to VLAN 3 do not see traffic that belongs to VLAN 6, for instance). To see such traffic, it must be handled at Layer 3 by inter-VLAN routing, sometimes called a "router on a stick," or by another Layer 3 device.

Private VLANs mitigate the capability of VLAN members to see the traffic of other members of their VLAN. Ports of a private VLAN fall into one of three categories: isolated, community, or promiscuous. Isolated ports can communicate only at Layer 2 with promiscuous ports of the same VLAN. Community ports can communicate at Layer 2 with other members of the same community or with promiscuous ports (within that VLAN). Obviously, promiscuous ports can communicate with any other port in the same VLAN at Layer 2.

By isolating ports within a VLAN, it is more difficult for malware to use port redirection to migrate problems from one host to another in that VLAN. Because you will often find servers (high-value targets) grouped for ease of management on one VLAN, this is a good way to protect them.

The previous information on routers and switches is no surprise if you already have a CCNP. Recall that the CCSP was originally a specialization for those with a CCNP. The guidance in the SAFE Blueprints assumes, at least implicitly, an intermediate-level knowledge of routing and switching. However, the only prerequisite to earning a CCSP now is the CCNA, which does not cover this material as deeply. If you do not have your CCNP yet, you will need to study and think about traffic flows and which devices do what tasks at which layers of the OSI model. By the time one has earned a CCNP, this knowledge is virtually automatic. You can pass this exam without a CCNP; you just have to work on routing and switching concepts more.

Hosts Are Targets

Hosts are the most difficult asset to protect because the network administrator cannot entirely prevent users from modifying configurations or adding unauthorized software and services. Plus, of course, there are so many of them: There are generally far more hosts than there are any other class of asset. Hosts are often a mix of hardware and software sets, reflecting generations of the organization's acquisitions. Adding to the difficulty, hosts are more than workstations; hosts include servers, including the public- facing servers, which are frequent attack targets. Securing hosts is a matter of staying on top of the security status of every componenthardware as well as softwarefor patches and upgrades. When it comes to this work, smart administrators prioritize their efforts, protecting the most valuable and/or the most vulnerable first. However, as you have seen with recent worm attacks, all hosts are targets and must be securedone bad apple can indeed spoil the barrel, not to mention your entire day.

Networks Are Targets

Up to now, we've looked at targeting specific devices, but it pays to remember that the entire system can be a target as well. Network attacks often take advantage of weaknesses in the networking protocols themselves . Network attacks can use Layer 2 or Layer 3 protocols (ARP-and MAC-based attacks, IP spoofing, and so on). The worst attack, though, is the one you cannot stop. If you can't stop it, how can you begin to recover? These are often DoS or DDoS attacks, and the only way to counter them is with help from upstreamyour carrier or service provider must rate limit your incoming traffic. But to get effective help, you must be able to characterize the traffic to be throttled, which means that you will be examining your logs for sources, protocols, ports, and so on to specify as tightly as possible the traffic to deny so that legitimate traffic (hopefully) still gets through.

Some techniques to help you minimize the likelihood of such attacks are described in Chapter 9, when we look at the Edge module.

Applications Are Targets

We all know that some applications are easier to attack than others. Those are (hopefully) the applications that you patch the most; of course, they could also be applications for which patches have not been prepared. Applications, like operating systems, have become bloated as vendors have offered more options and features. With software code running to hundreds of thousands and (too often) millions of lines, human error alone will introduce vulnerabilities. If the software also suffers from design flaws, the vulnerabilities could be more pervasive or more severe. However, that leads us to the next axiom .

Intrusion-Detection Systems Help

Intrusion-detection systems (IDS) can run on individual hosts (host IDS, or HIDS) or on a networking device (network IDS, or NIDS), monitoring a given traffic flow. The goal is to protect the applications that are being targeted for exploitation. IDSs operate on the same principle as antivirus packages: They have a data set of known characteristics of attacks. When a traffic flow occurs matching the (known) characteristics, an alarm can be generated, the traffic can be dropped, or a combination of actions can be taken.

HIDSs monitor specific traffic typesto a mail server, for instancefor which compromise is a known high-risk event. Therefore, HIDSs are often set to automatically drop suspicious traffic (a better-safe-than-sorry approach). However, HIDS sees only a subset of the traffic, so NIDS is needed as well. Because NIDS sees so much more traffic, it is often set only to alarm rather than to presumptively drop traffic. This is one of those trade-offs to be taken with careful thought, depending on what traffic should reasonably flow on the segment being monitored , as well as the nature and value of the assets on the segment being protected. As you will see in Chapters 8 and 9, in high-value segments of the network, you might need both HIDS and NIDS deployed to maximize your ability to find problems before they become too big and much too expensive.

Having made IDSs sound like your best friend, some caution is in order: You must expect to take some time to " settle in" your IDS implementation. There will be false positives, instances in which IDS falsely categorizes traffic as an attack. You will find these when legitimate traffic does not get through and people complain. Unfortunately, false negatives are a problem, too, but you learn of them when the IDS did not catch a real problem (its negative reading was false) and the problem becomes your network problem to solve. Likewise, the IDS can detect only what it knows about: You must depend on the vendor to update the attack signature profile promptly. If you are the lucky first network to suffer from a new attack, the IDS cannot help you until your vendor can characterize the attack and add the relevant data to the profile.

When IDS blocks traffic, it can use what is called "shunning" the traffic: dynamically adding entries to access lists and filters to drop the offending traffic. Typically, the traffic is blocked for a short period of time, long enough for the network administrator to determine whether there is a real problem (a true or false positive). Alternatively, if the traffic uses TCP, the IDS can send a TCP Reset (the RST flag in the TCP header is set). A reset prevents whatever action is ongoing between the attacking host and its target on your network from continuing; as with shunning, however, it is likely to continue only long enough to give network monitorshumans watching the systemtime to do something in response to the attack.

IDSs will help, but they are not a miracle cure.

Secure Management and Reporting

The last axiom in the Enterprise SAFE Blueprint is that you must read your logs for them to do you any good. This is hardly a surprise; in fact, you already know that there are many logs, and they each contain many messages, only some of which are truly important. But those two characteristics of system logs too often lead to spot checks (at best). Even if you do read the logs religiously , you have to wonder how confident you can be of their contentafter all, hackers know that logs can reveal what they did, so they target logging. That is the point of this axiom: You must secure your network-management and reporting system for it to be reliable. Then you can confidently use one of the many utilities to parse and analyze those logs, creating reports that direct your attention to suspected problems.

This discussion revolves around one direction of traffic: severs and networking devices reporting to you. However, the other direction is just as important. You must have a secure means of sending your management traffic to the important devices. As a solution to both sides of this problem, the SAFE Blueprint recommends that you establish a separate network for your network-management needs, preferably with direct connections to the networking devices. This network means that you will exercise management out-of- band (OOB) with respect to the regular traffic. In fact, this separate network carries no production traffic; however, the syslog hosts are on this network (not the production network). Establishing a separate network requires a few more ports and a separate logical network. This level of structure usually is justifiable only with a large, enterprise-level network or one on which network control and management have exceptional value (perhaps protecting particularly high-value content). If OOB is not practical or perhaps not desirable, there are alternatives.

One of the strengths of the SAFE Blueprint is that not everyone is forced to fit in the same box; there are always design alternatives. Of course, remembering the alternatives is a little more work, but you'll find it useful during the examyou can expect to see questions about the alternatives available to a certain module's design.

If you are managing your devices in-band, you want to be sure that only youdefinitely not anyone elsemake configuration changes (and especially any change to loggingwith that changed, you might not know that something else was changed). You have two acceptable choices for secure in-band device management:

• If the device has IPSec, perform device management via an IPSec tunnel terminating on the device.

• If IPSec is not available, use SSH instead of Telnet (and disable Telnet so that no one else can use it, either).

Unfortunately, there is no secure substitute for TFTP (or FTP), but you can sharply limit the addresses allowed to run either or both of them with an access list. Likewise, you can limit the acceptable addresses for SNMP, but consider whether you really must use that for management or whether you can work with it only for reporting (if so, use a read-only community). You should also consider using only SNMPv3 and taking advantage of its improved security features.

Finally, the SAFE Blueprint reminds you to manage configurations carefully and archive them to a safe place via TFTP or FTPyou might need to recover a copy, and copying in an archive is better than rebuilding the configuration.