Castles: An Example of Defense-in-Depth Architecture
|
| Castles are often used as an information security analogy; castles typically have a perimeter control that includes one way in and out. Castles also use chokepoints. It is easy to see defense in depth in action; to rescue the princess in the tower, you have to cross the moat and bash down the big door. Then you find yourself in a sally port area, which is similar to an airlock. There are external control doors, an assembly area, an interior set of doors, and only one set of doors opens at a time. So even if you break down one set of doors, you have to cram into the assembly area, where there may be ports through which the insiders can shoot at you. Then you have another set of doors to go through. We can employ many elements from castle architecture in our networks. The border routers and firewalls are used in the same way as moats and sally ports. The castle is not invincible, but the defense-in-depth architecture is one to carefully consider. Castles aren't still in military use today because they had a number of problems that relate to modern perimeter defense. Cannons were a big problem. Backdoors and secret passages did more than a few castles in, and the fact that they were stationary and easy to find was a significant disadvantage. With our networks, we have similar problems. 802.11 wireless access points and modems, especially on auto-answer, are the backdoors and secret passages of our networks. Sites with public address space, like castles, are exposed, stationary, and easy to find and attack. In the next section of this chapter, we use the analogy of a castle to explore some of the components of defense in depth. Hard Walls and Harder CannonballsGunpowder and cannons were the primary forces that put castles out of business. Even if you build the walls 60 meters thicka huge investment of building resourcesthe attackers can hammer the walls into dust and then breach the perimeter. By using denial of service (DoS) techniques of SYN floods or UDP floods as cannonballs, attackers might not be able to turn your firewall into dust, but they might well be able to shut down your site. If a firewallespecially an application gateway firewallis directly connected to the Internet, it probably doesn't have the speed in terms of CPU cycles to withstand a DoS attack. As we covered in Chapter 12, "Fundamentals of Secure Perimeter Design," the border router and firewall deployed together are more robust because the router is faster and can be configured to block many DoS attacks. Thus, a couple layers of defense are more effective than a single layer. Before the cannon was available, the perimeter breach device of choice for castles and keeps (a keep is the inner sanctuary of a castle) was the battering ram. The actual doorway of the castle tended to be made of metal and wood and was connected to stone, each of which reacts differently to the ram's attack. Wood, for instance, is softer than iron; therefore, the metal fasteners tend to erode the wood as the doorway withstands the shock. The holes in the wood get bigger; the joints weaken, and pretty soon the defense is breached. The functional equivalent for the battering ram is the DoS attack. As discussed in the preface to this book, in our networks, we have the firewall applications on top of operating systems, and attackers might target either the firewall application or the underlying operating system. This was the case with the flaw in Intel Pentium chips, where a single op code command series (F0 0F C7 C8) could halt the processor (http://catless.ncl.ac.uk/Risks/19.45.html#subj5). We have already discussed using border routers to shield firewalls from attack, but border routers are also susceptible to attack. Many of them do not respond well to ping floods directed against them. In fact, a sufficiently large number of attacking systems directed against the primary backbones might be able to drop portions of the Internet. The solution for an attack against the Internet is outside the scope of this book, but the best answer is related to defense in depthdesign the routers and network to be managed by an out-of-band network. A solution to the ping flood against your border router might be to add one more layer. A tool such as Attack Mitigator from Top Layer is an example of a very fast box that can be optimized to stop DoS attacks. Unless these attacks can saturate your entire data pipe, this layer can withstand the attacker's battering ram. Several companies are currently developing similar defenses against distributed DoS attacks, and additional products should be available by the time this book is printed. Secret PassagesAlthough it is certainly true that a castle's perimeter can be breached, we should also take a second to think about how well those ancient perimeters worked. Thick stone walls, like firewalls, do work well to help keep the barbarians out. Because they work so well, people invested a lot of effort trying to get around perimeter defenses. A favorite movie trick to circumvent these perimeters is the secret passage. Let's take a minute to examine how easy and likely it is that you might have a tunnel through your firewall that acts as a secret passage, or a leak you are not aware of in your perimeter. Tunnels Through the FirewallIf the firewall is perceived to be too restrictive, users may find ways to get through it; one of the most common ways is to tunnel through HTTP. There are several ways to do this, including SOAP (Simple Object Access Protocol), non-RFC tunnels, and attacking the web server (putting it under your control and using it to send data via HTTP). SOAP (Simple Object Access Protocol)RFC 3288 describes SOAP as a means of implementing web services across the Internet and tunneling through perimeters using HTTP. These tunnels act as third-party servers to forward your message from, say, a system inside your firewall to a server you might not otherwise be able to access. SOAP can be sent either in a synchronous way (for example, when it contains an RPC call) or in an asynchronous way (for example, when it contains an XML message). The latter is usually the case. SOAP does not care about the content, only about the addressee. You might as well regard it as a simple envelope: It can carry anything. SOAP is not concerned about the content; it just lets the mailman (usually HTTP) deliver the envelope. The first generation of commercial SOAP and XML firewalls is already available from companies such as Xtradyne, Flamenco, and Datapower. Non-RFC Approaches to HTTP TunnelingHTTP tunneling does not have to be based on the RFC standards; all you have to do is encode your message properly using HTML and the tunnel will work. On the non-RFC side of the house, dozens of tools, such as the original GNU httptunnel, encapsulate a communication stream in HTTP. For one example, you might want to visit http://www.nocrew.org/software/httptunnel.html. If you look at the data, you will see GET, PUT and POST commands passing through the tunnel. Most even incorporate HTML tags, making these tunnels a bit tough to spot. If you have an intrusion detection system (IDS), such as Snort, that can perform statistical analysis, or a traffic measurement tool, such as Cisco's NetFlow, you can often detect these HTTP tunnels. If you think about it, when you surf the Web, you specify a URL, wait, and then the page starts to display. In terms of the traffic signature, the client initiates the connection and sends a few bytes to the server, and the server sends a considerable amount of data back to the client. Now to be sure, some web applications enable the client to PUT or POST, so there is a potential for a false positive; however, with a bit of practice, you can detect a number of these tunnels. Of course, technology is not enough. After you detect a tunnel, your organization's policy dictates your next move. Is there a policy against unauthorized connections at your site? Would your organization's policy define a tunnel as an unauthorized connection? If the answer to the preceding two questions is yes, then what actions does the policy permit or require you to take? Attacking the Web ServerA lot of organizations feel that web server security is not an interesting or important topic. The SANS Institute commissioned a course on Apache security from researcher Ryan Barnett. When it did not sell, we purchased Google AdWords for the Hands On Apache Security class with a number of search words related to web security. Google reported we had such an abysmal "click-through ratio" that it essentially said, "Keep your money," and disabled the search words (http://www.sans.org/onsite/description.php?tid=41). However, because web servers are Internet facing, they remain under constant attack. If an attacker is able to compromise a web server, he can tunnel information from the server. This is why your IDSs should always alert if your web server initiates a connection to any other system. However, the attacker can still PUT and GET information right in the HTTP stream. Ryan Barnett conducted an experiment using an open proxy server for a week as a honeypot demonstrates that not only are web servers directly under attack, but they are also being tested to see if they are an open proxy so the attackers can create "proxy chains" (proxy web servers connecting to other proxy web servers) to mask their identity. An article by Barnett and Northcutt describing the experiment can be found at http://www.sans.org/rr/special/http_elephant.php.
Change in the Perimeter ConfigurationEven a performance problem or the perception of a performance problem can lead to the creation of a secret passagea leak in the perimeter. People just want to get their work done, and if the perimeter is slowing them down, they find ways to get around the perimeter. Even at highly secured DoD facilities or other high-value assets, security officers might discover that the firewall administrator has changed the web or some other proxy application on the firewall to a simple packet filter. If it happened to you, would you be at a loss as to why the officer would have done such a thing? It does make sense. The primary task of firewall administrators is to create ACLs or rules that open up the firewall. Firewalls might ship with a default rule to deny anything that is not specifically allowed (deny all), but that does not mean the firewall administrator is oriented to deny all. We should never forget the human element. From time to time, this administrator will almost certainly get phone calls or emails from people saying that the firewall is too slow. He knows packet filters are faster than proxy applications, so one day he decides to fix the firewall and switch it from a proxy to a packet filter. If you are not monitoring your firewall configuration, the first time you realize something is wrong might be when you start seeing attacks from the Internet that are clearly operating-system specific. HTTP, for instance, often gives away operating system information in the protocol headers; therefore, if the attackers run a website, they might know exactly what to target. Of course, this would only be an issue if certain websites on the Internet were malicious. This would be a serious problem for a site that is not interested in using NAT and making all the internal machines private addresses. An emerging best practice to help protect your site from administrative changes is to continually scan your perimeter from the outside using assessment tools. Managed scan services, such as Qualys (http://www.qualys.com), have subscription offerings so that you can schedule these scans via a web browser interface. They maintain a database of your configuration and provide a variety of canned reports. They also have an interface so that you can build your own reports. This way, if a new port is open or a new IP address becomes active, you can get a report to that effect. From a defense-in-depth perspective, you should seriously consider an active scanning program for any of your systems that can be reached from the Internet. Attackers will certainly scan you, so you had best probe your systems so that you see what the attackers see. Insider ThreatsThe insider threat is divided into two major components: people and programs. It never hurts to mention that throughout history, one of the best ways to get into a castle, bank, Secure Compartmented Information Facility (SCIF), or perimeter defense is to pay someone off. An equally effective and potentially cheaper method is the use of spyware and keystroke loggers. Insider Employees and ContractorsMoney is a powerful tool. If a firewall administrator would put a site at risk for free, imagine what a bit of coercion and $100,000 might be able to do. The CERT study on the insider threat, available at http://www.cert.org/archive/pdf/bankfin040820.pdf, shows that 87% of the time, attackers do not use a technically sophisticated approach. Why bother? They can burn a DVD of all your intellectual property, put it in a briefcase, and walk out of the facility. The defense-in-depth strategy here is to employ good background checks when hiring, do a bit of random monitoring, and keep an eye out for people who come in early, leave late, and work weekends. (Although all my peers work long hours, this is still a classic indicator of problems.) Sudden changes in financial status, signs of alcohol or drug use, and talk of entitlement ("They owe me.") can all be signs of an insider problem. Insider Programs, Spyware, and Keystroke LoggersIt is a lot of fun to watch the expression on people's faces the first time they run antispyware tools such as Spybot Search and Destroy or Ad-Aware. Here are the links for these tools:
Folks that do not run antispyware tools regularly will typically have 60 to 100 spying URLs, a couple of bots, and a keystroke logger or two. We'll probably be plagued with software that spies on where we go and what we do as long as people use browsers that execute software. Many organizations are not aware of the vulnerabilities browsers have. For instance, see CERT advisory CA 2003-22 (http://www.cert.org/advisories/CA-2003-22.html). These organizations using vulnerable browsers have probably yielded a lot of information to their unscrupulous competitors that are happy to engage in espionage, one password, one credit card number, one email marked "Proprietary" at a time. In addition to the antispyware tools, part of defense in depth is to eliminate the buildup of information that can be mined. If intellectual property is a significant component of the value of your organization, consider a tool such as CyberScrub (http://www.cyberscrub.com), which deletes temporary Internet files and all the other intelligence information that accumulates on your organization's desktop and mobile systems. Insider people and programs will always be a significant problem. The classic concepts of the principle of least privilegeletting people and systems have only the access they need to do their jobs, and the separation of duties, especially where money or valuable intellectual property is involvedare two of your best defenses. A third defense is similar to the principle of least privilege: the need to know. The less the insiders know, the less harm they can do. Strictly enforcing the need to know is one way to hide crucial assets in the mist, even from insiders. Hiding in the MistRemember the TV mini series The Mists of Avalon from a few years back? The castle dwellers did one smart thing: They used magic to call up mists to hide their castle. The location of castles is one of the big problems in the whole castle concept from the standpoint of military strategy. After the cannon was developed, it became apparent that castles were the perfect targets. They were so big that it was hard to miss them and waste a cannon ball, and you knew just where to find them because they were not mobile and couldn't be hidden. The great news is that we can deploy the functional equivalent of the mists of Avalon on our networks by using NAT. Someone can attack a perimeter in many ways, but if you have private addresses and NAT, the attacks or probes might still work to some extent, but they won't be as useful to the attacker. Suddenly, your internal systems become difficult to find, as if they are hidden in the mists. Imagine listening in on an IRC chat room discussion, and you realize the attackers are experimenting with the latest technique to slip through the perimeter. As you are watching the chat room discussion between Attacker 1 (A1) and Attacker 2 (A2), you see something resembling the following scroll across your screen:
Easily 100,000 networks start with 192.168.1, and unless you can nail up a source route or come through a tunnel, you probably can't get to and from one of these networks across the Internet. If you do have public addresses for the internal machines at your site, you should seriously consider transitioning to a NAT and private address structure. It can be the single most valuable tool to prevent successful reconnaissance by those who desire to be your enemy. In the next section, we briefly discuss three classic techniques used every day to penetrate perimeters: setting additional flags with a SYN, fragments, and echo replies. These examples illustrate the point about public and private addresses. SYN/FINMany of the buffer overflows from 1998 through just yesterday often follow reconnaissance using SynScan, which uses a combination of flags found in byte 13 from offset zero in the TCP header, and set both the SYN and FIN flags or bits. For a long time, the SYN and FIN set, in conjunction with an IPID of 39426, has announced the use of the SynScan tool. However, the flag combination can be more than a signature, the idea behind a SYN/FIN attack is to add an additional spurious flag to the SYN to attempt to originate a connection behind a perimeter. Many packet-filtering systems, especially static packet filters, mask on byte 13 of the TCP header checking for the value 2, the value of the SYN flag as the only bit set. The TCP flags are URG, ACK, PSH, RST, SYN, and FIN. FIN is the low-order bit, with a value of 1, if set; SYN is 2, RST is 4, and so on. This is what RFC 793 specifies, so it makes sense that designers of perimeter systems would inspect for a value of 2 in byte 13. SYN/RST, for instance, would not meet the logical test and would be allowed through the packet filter into the internal network, as would SYN/ACK, an ACK only, and so on. The kicker is that both UNIX and Windows systems will respond to a SYN/FIN with a SYN/ACK. SYN/FINs are used to penetrate perimeters and to establish a connection. This attack is the most dangerous perimeter penetration we are going to discuss; fragments and echo replies are primarily for reconnaissance, as opposed to system compromise attacks. Reconnaissance with FragmentsIn this section, we examine the use of incomplete fragment trains. When this reconnaissance technique is used on a vulnerable site, attackers get a positive answer as to the existence, or lack thereof, of a live host at every address that is checked. Fragmentation occurs when a packet is larger than the maximum transmission unit (MTU) of the next hop in its journey to its destination host. Only the first fragment has the true header from the original datagram. The other fragments have only the IP header generated by the router that breaks up the original datagram; those fragments do not get their true protocol headers until the destination host reassembles them. This lack of protocol header makes them ideal reconnaissance tools for attackers. Many perimeter devices do not choose to make the blocking decision on anything but the first fragment. An attacker can intentionally send in fragments without the protocol information; these fragments tend to pass through the perimeter to internal systems. If the internal systems have public addresses, a number of thingsall badcould happen. If the system being probed exists, it might receive the fragment. Then, when the other fragments do not arrive, the probed system might respond with an ICMP error messages saying that the reassembly time was exceeded, which tells the attacker that there is a live host at that IP address. If the system being probed does not exist, an internal router might respond with an ICMP host unreachable error message. The attacker then knows an IP address is not active. To defend against this technique, the perimeter must block both outgoing ICMP time exceeded in reassembly messages and ICMP host unreachable messages. Next, we look at one more way attackers can penetrate perimeter defenses for reconnaissanceusing echo replies. Reconnaissance with Echo RepliesICMP has two forms: error messages that are never replied to and error messages that take the form of request/reply. ICMP Type 8, Code 0 is an echo request, although it is also known as a ping, after the ping program. If an ICMP listener receives an echo request, the listener generally responds with an ICMP Type 0, Code 0 echo reply to tell the original ICMP speaker that the datagram was received. These request/reply types of ICMP are generally used for network managementfor instance, to see if hosts or routers are up. They can also be used for reconnaissance in many cases because echo replies often pass through perimeters; to block them would break outbound ping, and people like to use ping. Therefore, attackers send in echo replies to cause internal routers to respond with ICMP host unreachable error messages. This is known as inverse mapping. The only active response from the probed site is for systems that do not exist. The defense strategy is obvious here. As you learned in Chapter 3, "Stateful Firewalls," stateful firewalls maintain a table and might be able to determine whether or not the echo reply is a response to a ping initiated from within your site. Your design should have a stateful perimeter layer. As an additional layer of protection, you learned about the importance of squelching the outbound ICMP error messages in Chapter 6, "The Role of a Router." If we drop outgoing ICMP unreachable messages, even if our state table fails, we have this second layer of defense. Of course, the best defense would be to employ filtering, thus squelching outbound ICMP and NAT. Defense on the InsideEven if you are able to enter a castle though a secret passage, a number of barriers still exist, including those pesky guards with swords, before you can rescue the princess in the tower. Every single person who sees you is likely to either raise an alarm or attack you. Plus there will still be additional locked doors. In the past, this was not so with most of our sites. We did not typically use internal barriers or internal instrumentation. Nowadays, this is beginning to change with network segmentation and even self-defending networks.
If attackers get through the perimeter, we still want to employ layers of defense and instrumentation. Chapter 20, "Network Log Analysis," discusses the kind of information available in log files. The following sections of this chapter review some of the technologies we can employ to really get a clue as to what is going on in our networks as well as how to harden them. These technologies include personal (or host-centric) firewalls, appliance firewalls, physical airgaps, segmenting the network using switches, active network defense, as well as the emerging log fusion products. Host-Centric Firewalls as SensorsPersonal, or host-centric, firewall technology is one of the great breakthroughs in the past few years, and it is clearly a defense-in-depth technology. Firewalls are barriersone more layer of defenseand that additional layer is valuable in and of itself. Some firewalls do not even allow systems to answer pings. In addition to being an another layer of defense, host-centric firewalls, described in Chapter 10, "Host Defense Components," are equally as valuable as canaries in a coal mine. In the past century before modern sensors were developed to detect poisonous gas, miners took canaries into coal mines. Canaries are more sensitive to poisonous gas than people, so when the canaries started keeling over, it was time to get out of the mine. Because we have very little instrumentation internally in our sites, a personal firewall can be an early sensor, much like a canary, that alerts us to a serious problem of which we might not otherwise be aware. If all the writers and editors of this book could be in a very large room with each of you, the readers, we could conduct a poll. If we asked all of you to raise your hands if you use a personal firewall, about 70% of your hands would go up. If we asked you if you run a personal firewall at work behind your corporate firewall, maybe 40% of you would raise your hands. If the members of that last group were asked how many had ever received an alarm on their work personal firewall, almost every hand would stay up. The implications of those alarms are startling. You can chalk up those alerts to one of three things:
When we instrument an internal network, the results can include finding compromised systems being used to attack other systems and finding employees who are involved in hacking. When choosing a personal firewall solution for your organization, you might want to make the console available with enterprise versions a priority. These are available from Sygate, Symantec, McAfee, and others. In terms of maintaining situational awareness (knowing what is going on inside your network) by having reports coming to a central place, this is a great aid. Internal Firewalls/AppliancesA number of tools are logwatchers and correlation engines. These are major improvements on the original swatch. Almost all these include a relational SQL database to manage the information. Examples include NetForensics, ArcSight, and Intellitactics' NSM, which are all costly because of the amount of compute power needed to drive the database, the amount of storage they require, and the amount of manual intervention needed to keep them up to date. As these tools mature and integrate with passive OS sniffers such as SourceFire's RNA and Tenable's NeVO, they will enable us to do the same sorts of attack detection and trend analysis, possibly even more than we can do by using a personal firewall console. If we design our networks with multiple internal compartments, possibly using firewall appliances, we have the opportunity for both protection from attacks and detection of attack attempts inside our internal network. The Case for AirgapsNothing beats a genuine, old fashioned, not-connected-to-the-Net airgap. The department of defense has a rule that a classified network has to be airgapped from any unclassified network. That is a sensible rule. You need an airgap between your networked assets and the servers where you locate your most critical information. What is the information that truly differentiates you from your competition? The SANS Institute is engaged in research into securing systems every day, but its most critical information is either encrypted at rest while on networked computers or stored on airgapped systems if not encrypted. Several of our peers working for startup security companies have told us their software development and lab systems are not connected to a network connected to the Internet. We have discussed the notion of the hard, crunchy perimeter and the soft, chewy interior. The next section of this chapter suggests that we should think a bit about softer, absorbent perimeters. Although that might conjure up thoughts of paper towels, the plan is to discuss honeypots, rate limiting, and failover. Self-Defending Network (SDN)If we look at the way attacks come in today, we can clearly see the secret passage analogy is quite accurate: Attacks and attackers don't walk in the front door per se anymore. Our problems come from rogue machines, laptops that have been brought home, put in sleep mode, and connected back up to your network. The problem lies within the machines we don't control, such as those of the contractors and vendors who come on your network to check email and so on. You might have seen the new advertisements on TV about the Self-Defending Network from Cisco, with the little girl who installs software on her father's computer! A worm immediately tries to infect the machine, but luckily the outbreak is stopped before it can happen, due to the new SDN technology deployed. Let me give you a bit of insight into what is behind the Self-Defending Network. The Self-Defending Network is a Cisco-led strategy that includes the facility to improve the way a host can attach to your network via the checking of parameters that you set to see if it complies with your security policy, hence enhancing the ability to identify, prevent, and adapt to threats. Obviously, this will not be perfect, but it seems to be a major trend. Similar technology is available from Sygate. Note The authors wish to thank Patrick Ramseier and other Cisco engineers for providing us with the technical content to ensure this section is accurate. This fundamental element of SDN is called NAC, which is short for Network Admission Control. NAC is an efficient way to leverage the network to intelligently enforce access control based on your endpoint security posture and is currently supported by a number of vendors, including Computer Associates, Symantec, Trend Micro, McAfee, and IBM. There are a few prerequisites in order for NAC to work:
NAC works by utilizing a software agent called CTA, which will be available as a free download from http://www.cisco.com and potentially embedded in Symantec, McAfee, Trend Micro Virus programs as well as the Cisco Security Agent. Here are the steps used for the comprehensive compliance validation on a Layer 3 device such as a router:
Active hosts are reassessed as well. If they stop responding to the status queries, a revalidation is triggered. If a large number of vendors support NAC in the same way the major antivirus players have, you will be able to make sure all your endpoints conform to your security policy before they attach to your network via switch, router, wireless, or any other method. If this is done in conjunction with absorbent perimeters (the next strategy we discuss), you have a very solid security model. |
|
EAN: 2147483647
Pages: 230