The mechanism of the firewall

What is a firewall?

A firewall is a sort of filter plug (now you're not mistaken), you can make something you like go through the stopper, and everything else is filtered out. In the network world, to be filtered by the firewall is the communication packet that carries the communication data.

The world's firewalls will say at least two words: yes or No. To say is to accept or reject. The simplest firewall is an Ethernet bridge. But few people think the original firewall can be used for much. Most firewalls employ a wide variety of technologies and standards. These firewalls are of various forms: some replace the TCP/IP protocol stacks already installed on the system, some build their own software modules on the existing protocol stacks, and some simply have a stand-alone operating system. There are also application-type firewalls that provide protection only for certain types of network connections (such as SMTP or HTTP protocols, etc.). There are a number of hardware-based firewall products in fact should be grouped into a security router class. The above products can be called firewalls, because they work the same way: Analyze the data packets to and from the firewall, decide to release or throw them aside.

All firewalls have IP address filtering capabilities. This task examines the IP header and makes a release/discard decision based on its IP source address and destination address. Look at this picture below, two network segments between a firewall, one end of the firewall has a UNIX computer, the other side of the network segment is a PC client.

When a PC client initiates a Telnet request to a UNIX computer, the PC's Telnet client generates a TCP packet and passes it to the local protocol stack ready to be sent. Next, the protocol stack "plugs" the TCP packet into an IP packet and sends it to a UNIX computer via a path defined by the PC's TCP/IP stack. In this case, the IP packet must pass through a firewall across both the PC and the UNIX computer to reach the UNIX computer.

Now we "command" (in the professional terms is the preparation) firewall to all the packets to the UNIX computer rejected, after the completion of this work, "heart" a better firewall will inform the client program a sound! Since IP data sent to the destination cannot be forwarded, only users who are on the same network segment as the UNIX computer can access the UNIX computer.

There is also a situation, you can command the firewall dedicated to the poor PC machine to find fault, other people's data packets have let it not. This is the most basic function of the firewall: forwarding judgment based on IP address. But to the big scene this little trick will not turn, because hackers can use IP address spoofing technology, disguised as a legitimate address of the computer can pass through the firewall trust this address. However, according to the forwarding decision mechanism of the address is the most basic and necessary. Also note that, do not use DNS host name to establish a filter table, the forgery of DNS than IP address spoofing is much easier.

Server TCP/UDP Port filtering

It is not feasible to rely only on the address for data filtering in practice, but also because the target host is often running a variety of communication services, for example, we do not want users to use Telnet to connect to the system, but this does not mean that we must also prohibit them to use the Smtp/pop mail server? So, in addition to the address, we have to filter the server's TCP/UDP port.

For example, the default Telnet service connection port number is 23. If we do not allow a PC client to establish a Telnet connection to a UNIX computer (at which point we will be a server), we simply command the firewall to check the packet that sent the target to the UNIX server and filter the packet with the 23 target port number. In this way, we combine the IP address and the target server TCP/UDP port can not be used as a filtering standard to implement a fairly reliable firewall? No, it's not that simple.

The client also has a TCP/UDP port

TCP/IP is an end-to-end protocol in which each network node has a unique address. The application layer of the network node is the same, each application and service in the application layer has its own corresponding "address", that is, the port number. Addresses and ports are available to establish an effective communication relationship between the various applications of the client and the server. For example, the Telnet server listens on port 23 for inbound connections. The Telnet client also has a port number, otherwise how does the IP stack of the client know which application the packet belongs to?

For historical reasons, almost all TCP/IP client programs use a random allocation port number greater than 1023. Only root users on UNIX computers can access ports under 1024, and these ports are also reserved for services on the server. So, unless we let all packets with more than 1023 port numbers enter the network, the various network connections will not work properly.

This can be a hassle for the firewall, and if all the ports in the inbound block are blocked, all clients will not be able to use network resources. Because the server emits an inbound (that is, the meaning of entering a firewall) that responds to external connection requests, packets cannot pass through the inbound filter of the firewall. Conversely, is it possible to open all ports above 1023? It's not necessarily true. This is true because many services use more than 1023 ports, such as X-Client, RPC-based NFS services, and a large number of non-UNIX IP products (NETWARE/IP). So is it safe to let the 1023-port standard packets go into the network? Even these client programs are afraid to say that they are safe enough.

Bidirectional filtering

OK, let's change our thinking. Let's give the firewall this command: packets of known services can come in, and everything else is blocked outside the firewall. For example, if you know that a user wants to access a Web server, then only packets with the source port number 80 will be allowed into the network:

But the new problem has arisen again. First of all, how do you know which server you are trying to access has a running port number? Servers such as HTTP can be configured arbitrarily, and the ports that are used can be configured arbitrarily. If you set up firewalls like this, you won't be able to access Web sites that don't use the standard port number! Conversely, you cannot guarantee that the port number 80 in the packet entering the network must come from the Web server. Some hackers use this point to make their own intrusion tool, and let it run on the local 80 port!

Check ACK bit

Source Address We do not believe that the source port is also incredible, this has to dance with hackers in the crazy world what else we trust it? Fortunately, things have not yet reached the point of desperation. Countermeasures are still available, but this approach can only be used for TCP protocols.

TCP is a reliable communication protocol, the word "reliable" means that the protocol has some special properties, including error correction mechanism. To achieve its reliability, each TCP connection is preceded by a "handshake" process to exchange the connection parameters. Also, each sent packet must obtain a confirmation response before any subsequent packets are sent out. However, not every TCP packet has to adopt a special ACK packet response, in fact, only on the TCP header set a dedicated bit to complete this function. Therefore, as long as the response to the package will set the ACK bit. The first package of the connection session is not used for confirmation, so it does not set an ACK bit, and the TCP packet for subsequent session exchange is set to ACK bit.

For example, a PC initiates a connection to a remote Web server that generates a connection request package that does not have an ACK bit set. When the server rings the request, the server sends back a packet with an ACK bit set, while the packet marks the number of bytes received from the client. The client then responds with its own response packet to the packet, which also sets the ACK bit and marks the number of bytes received from the server. By monitoring the ACK bit, we can limit the data entering the network to the range of response packets. As a result, the remote system cannot initiate a TCP connection at all, but it can respond to incoming packets.

This set of mechanisms is not unassailable, simply for example, assuming we have an internal Web server, port 80 will have to be opened so that external requests can enter the network. Also, for UDP packets can not monitor ACK bit, because the UDP packet does not have an ACK bit. There are also TCP applications, such as FTP, that must be initiated by the server programs themselves.