External Threats

When you have publicly visible systems, as almost everyone does today, there is a always a threat that someone can find a way into your systems. In the preceding chapter you saw how properly configured firewalls could allow HTTP attacks from the outside into internal systems. Systems in the perimeter network are usually the first ones to be hit. When someone attacks your system, the result could be denial of service. For example, your Web server can be slowed considerably if it is hit with a denial-of-service network attack. If someone manages to gain a login shell as a normal user, this represents the next level of severity in threats. Naturally, if someone obtains complete control over a system by gaining root or superuser privileges, and this adversary is a remote user unaffiliated with your enterprise, this represents the worst threat.

External Denial-of-Service Threats

In Chapter 5, “Intrusion Detection and Why You Need It,” you saw that publicly visible network addresses are nearly impossible to defend from all denial-of-service attacks. If your Web server allows arbitrary users to connect, someone can write a program to generate a large number of HTTP transactions with your server as the target. The net result is a flooded Web server. Most Web servers are not designed to detect or defend against these attacks, although this is precisely the only place to adequately defend against such as threat.

A firewall or screening router is also not going to be of much help here because it is difficult to state a packet filtering rule for this condition. For example, a large number of HTTP packets with bad data from a single source address are hard to distinguish from a large number of well-formed HTTP packets unless your filter is smart enough to know the details of the HTTP protocol and partially assembled packets. To really solve the problem, the component that has the highest semantic view of the packets, in other words the Web server program itself, must implement this form of application-level security. If the Web server detects a series of bogus packets or even good packets from the same address in a fixed interval of time, the server could notify the firewall to block incoming traffic from that address. Of course, the clever denial-of-service hacker would just forge a series of IP addresses to avoid detection.

External Privilege Escalations

Hopefully, this class of attacks is becoming less frequent as knowledge of security problems spreads. A remote user can escalate privileges in two different ways:

•  A program that does not permit logins is running on the target node but is accepting network connections (such as a Web server).

•  The remote user is able to gain access to the system via a login, or in other words, a network login program is listening for external connections.

An example of the former is, of course, the Web server daemon. Poor CGI programming practices can permit remote users to execute arbitrary commands on the system, albeit only with the privileges of the Web server daemon. A rather nasty example surfaced in 1997 with some implementations of FTP.

An FTP client can issue a command to the FTP server that requests multiple files at once. The client issuing the mget ^* command is asking the server to send all files in the current directory of the server. Unfortunately, some FTP client implementations did not bother to check that the files sent by the server were only those included in the current directory. A user in a home directory who then FTPs to a malicious server and executes the mget ^* command could find many other files being added to the home directory. The server could push viruses or Trojan Horses to the receiving client because of this bug. If a root user on a UNIX system happened to be executing one of these FTP clients from the root file system directory, the malicious FTP server could replace the password file.

Cases in which remote users gain login access to servers were discussed in Chapter 2, “The Role of Identification and Authentication in Your Environment.” Even if strong authentication is used for login proof of identity, sessions can be hijacked unless other precautions are taken. If a root or Administrator user connects remotely via a protocol that is not protecting against packet injection or session hijacking, the adversary has the opportunity to effectively have root access. The amount of damage done is dependent on what operations the protocol supports. Again, think of the Web server running as root and subject to a CGI hack to understand the consequences.

Layers of Information Sources

To understand the role of various intrusion detection products, take a look at the simplified diagram shown in Figure 6.1. Here, the distinction is made between three different levels of analysis for a computing environment.

Figure 6.1  Layers of information in the operating system.

At the bottom is the network layer, which can be further subdivided into many different layered components itself. For the purposes of this discussion, think of the network layer as a single entity in which all of the TCP/IP or SMB traffic is handled. At the next layer is the OS. Technically, the OS includes the network stack, but think of this OS layer as containing all of the components that are not directly responsible for processing network information. Example components at this second layer include commands, libraries, backup routines, login routines, and other core subsystems that would be in operation even if the computer were not attached to a network. (This distinction is still fuzzy because a computer can open a socket to itself even if it is not directly connected to the network. Don’t think too hard about these divisions.)

At the highest layer are the applications. Think of this layer as containing all of the products that are not normally delivered as part of the operating system. As the last few years have shown, the set of products in this upper level has changed drastically as OS vendors rush to include “for free” add-ons for product differentiation. Still, think of Lotus Notes, Oracle, DB/2, add-on mail programs, manufacturing or CAD software, and a payroll application as examples from this layer. The main idea to drive home here is that these applications typically bring along additional security models with subjects and objects beyond those that are part of the operating system.