The small network's edge is composed of a Corporate Internet module that is far from complex: an Internet connection via a router with a firewall (or a dedicated firewall appliance, as noted), with incoming traffic for public servers sent to a switch that further sends it to the correct host. This module terminates incoming VPNs (quite possibly for professionals working from home as well as teleworkers or personnel who are traveling). The public- facing servers can include Web, mail, file transfer, and name servers. AssetsAssets in this module are the router or firewall itself, the switch, the servers, and their contents. The router with a software firewall or the dedicated firewall appliance (henceforth, just referred to as the router/firewall) is certainly a valuable resource, representing the ingress choke point. The switch segregates the traffic of one server from another, which makes it a target for manipulating traffic inside the module. The servers themselves are targets, of course, for the information they contain and for the possibility that an application vulnerability on one can be capitalized upon and turned into access elsewhere in the network. Concerning the content of the servers and the asset value, you have to think like a bad guy: How can I turn this into money or satisfaction? If present, the Web server might have Web pages to be defaced (for pure vandalism or competitive sabotage ). The file server might have product information files available for download (a colleague of mine once browsed anonymously from home into the FTP server of a hardware contract manufacturer and found the complete production specifications of a Layer 3 switchnot from Ciscoopenly available). Even though the mail server should be a relay, not the main mail server, it might have copies of significant business correspondence. The DNS server has zone files, which can be altered to point prospective business contacts to a "404 Not Found" error ( causing this business to suffer reputation damage and perhaps lost business) or simply to a competitor's Web site. All these could be done for hire. In addition to business disruption, whether vandalism or competitive, the servers could be "borrowed" or hijacked to support activities that are illegal in that area, from storing and serving pornography (as defined locally) to gambling, serving as a mail relay for fraudulent solicitations (email scams), and so forth. Even if not locally illegal, the organization's hosting of this material would probably be extremely damaging to its reputationand such damage leaves essentially permanent effects because the taint lingers in people's minds. "Data kidnappings" have actually occurredsensitive corporate data was encrypted in place, and the key to decrypt it was obtained for a ransom payment. In addition, other forms of extortion (protection payments to not be hacked again, for instance) are believed to be widely underreported to law enforcement authorities. The point is that the business can suffer damagereal, substantial financial damageif its public servers are hacked. The way into those servers is via the router/firewall and the switch, which makes these networking devices targets to be neutralized (if not taken over) in the approach to the servers. ThreatsWe have just covered some of the threats possible to these assets, but those were threats of what could happen to them. We need to concern ourselves here with the threat technologies and, to a lesser extent, the people who might wield them. The reason we focus less on the people is that they are harder to predict. Threats that can be encountered in this module are grouped into one of two broad categories: low-profile and forceful. The low-profile threats include the following:
Other threats attempt to apply force (digital force, if you will) to exploit the network including these:
These are the same attacks as listed in the SMR SAFE Blueprint, but I have rearranged them into the two qualitative groupings based on shared characteristic (attack style). Smaller groups also are simply easier to remember and associate. You might remember that one of the axioms of the SAFE Blueprint involved reading your logs, not just keeping them. Unfortunately, smaller businesses rarely have a multiperson IT staff; they might have no one and outsource their network management altogether. Such networks are readily susceptible to low-profile attacks, which, if done with any reasonable level of skill, can go on for some time before being noticed in a relatively unsecured or "unattended to" network. Trust exploitation is especially hard to detect because (technically) nothing has gone wrong. A device that was trusted has accessed a device that did the trusting, and that relationship is intentional (the FTP server trusts the Web server, for instance, because the request came from an internal address, so the FTP server automatically honors any request from it). Digital force attacks, however, are usually not subtle. Even password attacks can involve repeated login attempts, such as battering at a door until the lock gives way. Although a login function doesn't "give way" in the physical, materiel-fatigue sense, a dictionary attack on a password function is likely to succeed in a shockingly short period of time.
Port redirection, application-layer attacks, and virus and trojan horse attacks all exploit technological weaknesses present in software. Port redirection is especially difficult to counter because the traffic enters on a legitimate portport 80, HTTP, for instanceand a malicious software application redirects that traffic to another port used by a different process. This can be used, for instance, to open an FTP connection to upload more malicious software, enabling the hijacking of a server, or to facilitate the progressive compromise of a host. These more subtle attacks can proceed slowly if they are skillfully crafted, but more often they run amok, presenting you with a cascade of errors and problems that seem critical. Of course, DoS attacks simply consume resources so that others cannot use thembut the consumption means that real work is not getting done. The people perpetrating an attack might be quickly recognizable, especially if they are relatively new and clumsy. More often than not, however, you cannot identify the perpetrator quickly, if at all. To make things more interesting, you might not ever be able to tell with certainty whether the attack originated externally or internally. Remember the outsourced IT: If a contractor present on the site two months ago placed a trojan horse in the system, what appears to be an external attack today actually originated internally two months ago. This uncertainty is one reason the SAFE Blueprints do not spend significant attention on forensics (aside from the fact that it is a large and highly technical topic in its own right). Another reason is that the SAFE Blueprints are practical: They focus on what you should do to prevent problems and mitigate their effects if they do occur. Your hands will be quite full with that. Devices and ImplementationThe servers are the principal target of most hackers. A strong antivirus package should be installed and kept current on every host in the entire network, including the servers in the edge. Every host should also be periodically scanned for viruses and other malware (trojan horses, keystroke loggers, and so on). Every application and OS on the servers should be kept current on patches, and no unnecessary processes should be allowed to run. This is often referred to as "locking down" the OS or the server (depending on the immediate subject). Wherever possible, all applications should be configured to accept updates only from specified internal addresses. An example of this is the DNS server: It is the source of name-to-address mappings for the public. You might choose to make this DNS server in the edge the network's authoritative server, in which case another server inside your network is the secondary server. The DNS server in the DMZ should accept a zone transfer only from your legitimate secondary server at a specified inside address. If this is a secondary server, it should accept a zone transfer only from the authoritative server inside the campus. Either way, it should never accept a zone transfer from any host but the specified serverspecified by IP address because name mappings can be compromised (if nothing else, through the addition of a hosts file).
A host IDS should be one of the processes running on every server in the edge. A number of vendors make HIDS; although the SAFE Blueprint was validated in the lab using HIDS from Entercept, Cisco now offers such a product with its acquisition of Okena (the new product is known as the Cisco Security Agent). Because the HIDS is being applied to a specific host serving a specific function, it can be set to be aggressive in its protection: Rather than merely sending an alarm, it should be configured to send an alarm and to drop offending traffic (sending a reset might depend on whether you want the attacker to realize that he got as far as the serverit can be debated whether this is really wise). The switch in this module isolates the traffic for each server to a separate wire (in the nature of switches). Using private VLANs, this separation can be made stronger. Servers should be on private ports rather than community ports and certainly not on promiscuous ports. Any unused ports should be disabled rather than left available for device connectivity. Unless there is an overwhelming need, there should be no trunking on any port facing the servers in this DMZ: Traffic between VLANs should have to pass through Layer 3 inspection and filteringat the router/firewallbefore being permitted to pass. The router or firewall is where the security heavy lifting is done in this small edge. For ingressing traffic, it filters both according to RFC 2827 and RFC 1918, and it filters out fragmented packets (which are often used to consume router and server resources, especially if the fragmentation is "artful"that is, deliberately misconfigured in the header, for instance). Adding limits on the number of half-open connections protects against SYN floods (a DoS attack). Further rate limiting can be configurable, if needed, or the organization might need the cooperation of its upstream to prevent the limited incoming bandwidth from being consumed by DoS traffic (that cooperation will likely be greater if you can describe the offending traffic carefully based on your logs). Another external connection managed by the router/firewall might be VPNs for remote users. Preshared keys are the only practical means of tunnel authentication unless this small network is a branch of a very large organization that operates a CA. User authentication for the VPNs is made via an authentication server inside the Campus module (often the management server). The router/firewall filters traffic ingressing on its DMZ and inside ports as well. No server in this DMZ should need to initiate an outgoing session, nor, in all likelihood , should it need to initiate a session with any other server. If this organization operated an e-commerce module, there might be such a need, but it does not. Filtering such server requests prevents one compromised server from compromising another, just as private VLANs prevent traffic from traveling without Layer 3 filtering. The router/firewall also filters traffic from this network to the outside according to RFC 2827 and RFC 1918. Apart from being good Internet citizenship, this filtering demonstrates intent to essentially quarantine problems that do develop. This makes any negligence claim by an aggrieved party elsewhere harder to prove . Threats MitigatedWe have already listed the threats. Table 10.1 presents the threats with the technology used to mitigate each of them, to help you make the connections. Table 10.1. Small Network Edge Threats and Their Mitigation
As you can see from Table 10.1, not all mitigation techniques involve Cisco equipment or software features. Some, such as locking down the OS (three failed login attempts lead to a locked account for 20 minutes is one aspect of a lockdown) and a strong password policy are system administration and management functions. However, they all contribute to the mosaic of a secured network, even for a small business. Design AlternativesOne alternative already is built into this design: the choice between a router with an integrated (software) firewall and a dedicated firewall appliance. A firewall has fewer external connection options (usually requiring Ethernet input), but this could work well in a small business with DSL or local broadband connectivity. The design alternative discussed in the SAFE SMR Blueprint is to add a VPN concentrator if many VPNs must terminate here. This could occur in a medical or legal practice, in which several professionals connect from home or when traveling. When the numbers grow large enough to justify a concentrator, however, the size of the overall network begins to look more like that of the midsize network (covered in Chapter 11, "The Medium Network Implementation"). |