4.13. Notes on Firewall Operation

A firewall can both protect your computer or network from invasion and make it vulnerable to one. Only carefully configuring your firewall and setting strict access rules can make your system secure.

But even configuring the firewall in the most proper way and creating the most thought-out filters does not guarantee your server will be 100% secure. An unbreakable firewall is a myth. The problem does not lie just with the ipchains or iptables programs. The firewall technology itself does not guarantee total security. Nothing can guarantee you this; if it could, I would not have written this book.

In this section, I will consider some problems that you may encounter when using the firewall. You should have a clear idea of the potential problems so that you could neutralize the danger they present.

4.13.1. Paying Attention

As already stated, only being extremely careful when configuring the firewall can give you higher-than-average confidence in that your system is secure. Examine some of the typical blunders committed when configuring the firewall; this will help you avoid making similar mistakes.

As you should remember, the input and the output chains have three rules apiece. Suppose you no longer require FTP access and disable it. Along with disabling the FTP server, do not forget to delete from the rule chains the rules that allow such access.

Once, an administrator I knew did not delete the rules after disabling the service. Some time later, the FTP service was enabled again, but the IP address, to which the original permission was issued, was now used by another employee. In this case, the person that unexpectedly obtained rights was a loyal company employee and did not intend to misuse them, but you do understand the implications, don't you?

The firewall-configuring task is difficult when IP addresses are assigned dynamically and change constantly. If addresses in your network are assigned using the Dynamic Host Configuration Protocol (DHCP), you should see to it that computers that require special access and rules were assigned a permanent address (for example, that of the main gateway). This will prevent the wrong person from obtaining a privileged IP address and the real owner from losing it by accident .

Imagine what will happen if, in the example considered in Section 4.11.2 , IP address 192.168.8.10 is through a fluke assigned to another computer. It will create problems because the user who is supposed to have it does not and the new user may put it to the wrong use.

To strictly control IP addresses, you should use a DHCP server and assign permanent addresses to those computers that require privileged access and for which there are special filters in the firewall rule chains.

Be careful when creating rules. Some services (for example, FTP) may require more than one port to function properly. Unless you open or close all the ports, you will not achieve the desired result.

Be especially careful when configuring the firewall using a graphical shell. When everything is prohibited , XWindows may hang if it loses the network connection with the Linux kernel.

You should also pay close attention to what you are doing when configuring the firewall using a Secure SHell (SSH) protocol remote connection. One wrong move here may break the connection, and the SSH client will disconnect. Then you will have to go to the firewall server and continue configuring it in situ.

Test all connections after each change to the firewall configuration. If you make a mistake, it will be difficult to trace it after several modifications.

To debug problem rule chains, I save the configuration to a temporary file and then print it. It is much easier to see the whole picture on paper than on the monitor. Make sure you specify the correct source and destination parameters (the address and port). Quite often, administrators are not certain about what parameters to specify and act by the seat of their pants.

Go over each chain in your mind, analyzing which packets are let through and which are not. The investigation is best started with the input chain (where packets enter the system). Next , inspect the forward chain and, finally, the output chain. In this way, the complete packet cycle has to be traced. Remember that after the first rule that meets the packet's criteria, no further checks are conducted .

When inspecting rules dealing with TCP, remember that this protocol establishes a connection, meaning that packets have to travel both ways. UDP does not establish a connection and packets can be passed only one way: input or output. But there are exceptions when some programs require bidirectional exchange over UDP.

If some program does not work, make sure that there are the necessary rules for all necessary ports: Some protocols require access to two or more network ports. Next, check that the permission rule precedes the prohibition rule.

Never open access to the specific port on all computers. For example, simply adding a rule permitting incoming packets on port 80 will open this port on all of the network's computers. But far from all computers require access to this port. Thus, when creating a rule, specify not only the port but also the specific IP address, on which it applies.

And don't forget to make backup copies of the configuration (using the ipchain-save command). These will come in handy in case of problems with test configurations.

4.13.2. Bypassing the Firewall

A firewall cannot provide absolute security because its operation algorithm, like everything in life, is not perfect. It is based on certain rules, according to which the firewall inspects the traffic passing through the network interface and makes decisions as to whether or not to let it through. But, short of complete prohibition, no filter can provide 100% security because there is no rule that cannot be circumvented.

Most firewalls are vulnerable to DoS attacks. When considering the technology of DoS attacks in Section 1.1.6 , I said that such an attack is easy to carry out in the following cases:

Your channel's bandwidth is wider than that of the target computer.
A resource- intensive task exists on the target computer, and the attacker can start this task.

A firewall is a complex software system that requires significant technical resources to analyze all transiting traffic. Most of these resources are spent analyzing syn packets, that is, connection request packets. The firewall has to check the parameters of each syn packet against all set rules.

At the same time, no great bandwidth or computer resources are necessary to send syn packets. A hacker can easily flood a permitted server's port with syn packets with random source addresses. The target machine may not be able to handle the great volume of requests that has to be filtered and will queue them, which will prevent it from processing bona fide connection requests .

The problem becomes worse if the firewall is configured to issue error messages. This increases the processor workload because it has to create and send packets to nonexisting addresses or addresses that do not belong to the hacker.

If a client sends data that does not fit into one packet, the packet is broken into several parts . This process is called packet fragmentation. Most firewalls inspect only the first block in a session and consider the rest of them valid. This is logical, because if the first block is valid, why waste the server's resources on inspecting the rest of them?

Packets can be fragmented in such a way that the firewall will let them through. This type of attack can be defended against only if the firewall automatically assembles packets and inspects them assembled . Most firewalls cannot do this.

Firewalls sometimes experience attacks that are successful. If hackers take over the firewall, they will obtain complete access to the network it is supposed to protect. In this case, you can only be saved from complete defeat by an individual firewall on each of the network's computers. Even though the individual workstation firewall security policy may not be as stringent, it may be just enough to prevent the hackers' further invasion into the network.

Any type of firewall can come under attack. Both Linux firewalls and routers with firewall functions can have bugs .

The main task performed by a firewall is to prohibit access to the resources, to which access is restricted. But some resources must be available to everyone. For example, a firewall cannot protect against a break-in taking advantage of bugs in Web scripts on a Web server that is supposed to have free access for Internet users.

Maximum security comes at the price of sacrificing some conveniences . Thus, as I already stated, all outside attempts to connect to the system are best prohibited. Only a network's client can initiate a connection, not a remote computer. This will make it impossible for hackers to connect to the system but may also cause problems for the legitimate network users when, for example, they try to connect to an FTP server in the active mode. As you already know, this service uses two ports: ftp and ftp-data ( ftpd ) . It will be no problem for the user to connect to the server's ftp port. To serve a file, however, the FTP server itself has to initiate a connection with the client, which will not be let through by the firewall. This problem has been solved for the FTP service by adding the passive operating mode; the issue remains open for other services chats, for example.

It is also possible to connect to a protected network through a tunnel on an open port and a permitted address inside the network. This cannot be avoided because there must be at least something allowed.

There can be more than one server in large networks. It was only in one company and movies that I saw network administrators using a separate monitor and keyboard to control each of them. In real life, network administrators are too lazy to work on several monitors and keyboards and use only one computer, controlling the rest of the servers through a remote connection.

But this is not the extent of their laziness . So as not to come to work after hours in case of emergency, they connect to the server's console from home. And this is a serious breach of security that may place the network they are supposed to protect in a serious danger. It's all right if the program used to manage the remote servers encodes the transmitted data in some way, but what if it's just your regular Telnet client? Hackers can intercept the authentication information using a sniffing utility and obtain the same access privileges to the server as the administrator.

4.13.3. Safe Internet

The Internet will not be safe until it is possible to determine the source of each packet that comes from there. The way things are now, any field of the IP packet can be faked to the effect that its authenticity can never be established.

Once that you can never be sure that it is not a wolf in sheep's clothing that is knocking at your server's door, you should take good care to conceal, which permissions and to whom they are given on your server. The less information you make available to hackers, the more secure your server will be. You should also ruthlessly suppress any recognizance moves, for example, port scanning, or tracing, etc.

The tracing principle is as follows : In a network, a packet travels over a certain route to its destination. A packet addressed to another network is delivered there by routers. But for one reason or another, a packet can stray from the destination route and travel endlessly from one network to another. To prevent this, there is the Time-To-Live (TTL) field in the header of an IP packet. This field is set to a certain value by the sender and is decremented by one by each router it passes . When the TTL value reaches zero, the packet is considered lost and is destroyed , with a message sent to the sender that the host is unreachable.

This feature can be used to determine the route a packet travels to its destination. It works as follows: In 99% of cases, packets travel to the destination over the same route. Setting the packet's TTL value to 1 will make the first router it reaches issue an error message, which contains the router's address. The next packet's TTL value is set to 2. The TTL error message for this packet will be issued by the second router it reaches. Thus, sending a series of packets, sequentially incrementing the TTL value of each packet by 1, all routers that the packets pass to reach the specified destination can be established.

A firewall should drop any packets whose TTL value equals 1. This will protect the network but will also reveal that it is protected by a firewall. If a regular packet (with a real TTL value) reaches the addressee but the traceroute command to the same destination produces an error message, this means there is a firewall somewhere in the route.

Tracing in Linux is performed by executing the traceroute command with the -I option and the host's name specified:

 traceroute -I redhat.com

Windows uses the analogous tracert command. It is issued with only the host's name to the trace specified.

Executing any of these commands displays the addresses of the intermediate routers in the packet's route. For example, the information displayed may look similar to the following:

 traceroute to redhat.com (xxx.xxx.xxx.xxx)? 30 hops max, 38 byte packets 1  218 ms 501 ms 219 ms RDN11-f200.101.transtelecom.net [217.150.37.34] 2  312 ms 259 ms 259 ms sl-gw10-sto-5-2.sprintlink.net [80.77.97.93] ... ... 17 638 ms 839 ms 479 ms 216.140.3.38 18 *      *      *      Request timed out.

If the firewall lets through ICMP packets, the traceroute command can be used to trace the route, even though it may produce an error message. In this case, entry 18 reveals that the timeout value was exceeded. This means that the packet sent was rejected by the server; consequently, the packet with the TTL value of 18 will be dropped.

To continue tracing beyond the firewall, the command has to be issued with the TTL value of 19. The first 17 requests will produce responses, the 18th will be lost, and the 19th will be let into the network The reason packet 19 is let in is because when it reaches the firewall, its TTL value equals 2. But the first router in the local network will drop this packet.

In real life, however, ICMP packets are prohibited, and this method seldom produces results.

On the other hand, even if you trace the entire route to the destination computer, it does not mean that there is no firewall in the way: It may be there but simply not prohibit ICMP traffic.

A network behind a firewall can also be scanned using the Domain Name System (DNS) server if it is inside the network and is publicly available.

4.13.4. Additional Protection

In addition to the filters based on the firewall rules, supplementary protection mechanisms independent of the firewall configuration or enabled by special settings can be implemented.

One of the popular techniques of bypassing a firewall is faking the source IP address. For example, access to the FTP server is prohibited from all IP addresses except 100.2.2.2. To obtain access to FTP, a hacker can send packets, in which his source IP address is replaced by the permitted address.

But simply replacing a prohibited IP address with the good one will not let the hacker through. The server simply will not respond to packets with the faked IP address. Why? Take a look at Fig. 4.9: The answer to the hacker's query goes to the real owner of the permitted address.

Figure 4.9: Replacing the IP address

For the server to respond to the hacker's request, special information by which the server can determine the real address of the hacker has to be included in the IP packet.

A modern firewall, including those supplied with Linux, easily detects the swap and blocks fake IP address packets.