Firewall Dos and Don ts

Firewall Dos and Don'ts

A firewall can permanently close any port, blocking both incoming and outgoing connections either selectively or fully. However, such ports mustn't be well-known ports assigned to vitally-important public services that cannot be blocked. For example, if a company uses a corporate email server, then port 25 (SMTP) mustn't be blocked; otherwise , it would be impossible to receive mail messages. Accordingly, the presence of a Web server assumes that port 80 must be available for providing the possibility of connecting to the server from the outside world.

Assume that one or more such services contain vulnerabilities allowing buffer overflow with all possible consequences, such as capturing control over the system and permitting unauthorized access. If this is the case, no firewall, even the most advanced one, will be able to prevent intrusion. This is because at the network layer, the packets containing malicious shellcode are indistinguishable from packets containing legal data. The only exception is searching for a specific worm whose signature is well known to the firewall, and cutting off its head. However, patching a vulnerable service will be a much more efficient method for overcoming the threat. Note that the situations, in which the arrival of the worm happens before the release of the patch, exist only in theory and therefore won't be considered here.

Anyway, the firewall doesn't prevent buffer overflow of a vulnerable service. The only step that it can take is reducing the number of potential holes to a reasonable minimum by closing ports of all services that do not need to be accessed from outside. For example, the Love San worm, propagating through rarely used port 135, has long been successfully blocked by firewalls installed on the Internet backbones, because their owners have decided that it would be much better to slightly limit the rights of legal users than to bear responsibilities for supporting vital activities of worms and viruses. However, such a technique is of no help when it comes to withstanding such worms that propagate through standard ports of popular network services. Thus, the firewall lets the worm head freely pass into the corporate network.

However, throwing the shellcode into the hostile camp is only half of the job. When this task is completed, the worm must at least upload its main body, bypassing all internetwork screens and firewalls. It must install a terminal back door shell that would allow the intruder to control the captured system remotely.

Can a firewall efficiently counteract this? If the firewall is installed at the same host with the server being attacked , and the shellcode is executed with the highest privilege level, then the attackers can do whatever they like to the firewall, including such actions as changing its configuration to a less restrictive one. This case is so simple that even considering it is of no interest. It is more useful to consider a more difficult case, in which the firewall and the service being attacked are installed on different hosts . Furthermore, assume that the firewall is expertly configured and is free from vulnerabilities.

From the intruder's point of view, the simplest (and the most natural) approach is charging the shellcode with the task of opening a new port guaranteed to be unused (for example, port 666) at the target host and then patiently waiting for connections originating from the host that sends the main virus code. It should be pointed out, however, that if the administrator of the attacked system isn't a negligent idiot, then all incoming connections to all nonpublic ports will be blocked by the firewall. However, attackers might choose a more cunning approach installing the server component of the worm on the remote host waiting for connections originating from the shellcode. Not all firewalls block outgoing connections, although administrators have such a possibility. However, expertly designed worms cannot afford to rely on the carelessness and permissiveness of administrators. Instead of establishing a new TCP/IP connection, the worm must be able to use the existing connection the one used for sending the worm's head. In this case, the firewall won't be able to do anything, because everything would appear normal from its viewpoint. In other words, the firewall cannot know that a harmless-looking TCP/IP connection established legally is not processed by a server but, on the contrary, is processed by the shellcode that has inserted its code into the address space of the vulnerable server.

There are several techniques of capturing existing TCP/IP connections. The first and dumbest approach is accessing the socket descriptor variable by fixed addresses typical for this server. To obtain these addresses, the attacker has to disassemble the server code. However, this method cannot stand up to criticism, and it won't be considered here. Nevertheless, it is useful to know about its existence.

It is much better to undertake a brute-force attack on socket descriptors, testing one socket descriptor after another to determine, which one controls the "required" TCP/IP connection. This brute-force attack won't take a long time because, in the operating systems from the UNIX and Windows 9x/NT families, socket descriptors are regularly-ordered small integer numbers (as a rule, they belong to the interval from 0 to 255). As a variant, it is possible to resort to reusing addresses by rebinding to the port opened by a vulnerable server. In this case, all further connections to the host being attacked will be processed by the shellcode, not by the previous port owner. This is an efficient way of capturing secret traffic, isn't it? Finally, the shellcode can stop the vulnerable process and reopen the public port.

As a variant, the worm can kill the process being attacked, automatically freeing all ports and descriptors opened by it. Then, reopening of a vulnerable port won't cause any objections by the operating system. Less aggressive worms won't try to capture anything or even touch anything. Such worms usually switch the system to the promiscuous mode and then listen to all incoming traffic, with which the attacker will pass the remaining tail.

Finally, if ICMP is allowed at least partially (as a rule, this is done to prevent users from annoying the administrator with silly questions, such as, Why doesn't the ping utility work?), then the attacker can wrap the worm tail into ICMP packets. In the most unfavorable case, the worm can send its body in a normal email message (provided that it can manage a new mailbox at the mail server or capture the passwords of one or more users, which isn't a problem if a network sniffer is available to the hacker).

Thus, no firewall, even the most advanced and expertly configured one, will protect your network (to speak nothing about your home PC) against worms or experienced hackers . This doesn't mean that the firewall is useless. It does mean that purchasing a firewall won't eliminate the need to install newest patches.