Working principle of Firewall

Www.bkjia.com: an old article written before January 1, year 45

"Will hackers give me their ideas ?" That's right. hackers just want to crack the fly with eggs and see the light from system vulnerabilities! Okay. How can we protect your network? Computer experts may propose you to install the network firewall as soon as they open their mouths:What is a firewall?
A firewall is a filter plug (which is not an error in your understanding). You can filter out all your favorite things through this plug-in. In the world of networks, the firewall filters communication packets that carry communication data.
A firewall in the world can say either Yes or No. Simply accept or reject the request. The simplest firewall is Ethernet bridge. But almost no one will think that the original firewall can be used in a great way. Most firewalls use a wide variety of technologies and standards. These firewalls have a variety of forms: Some Replace the TCP/IP protocol stack that has been installed on the system; some build their own software modules on the existing protocol stack; some are simply an independent operating system. Some application-oriented firewalls only protect network connections of specific types (such as SMTP or HTTP ). Some hardware-based firewall products should be classified as security routers. The above products can all be called firewalls, because they work in the same way: analyze the data packets entering and exiting the firewalls and decide whether to allow them or throw them aside.
All firewalls have the IP address filtering function. This task checks the IP address header and determines whether to allow or discard the IP address based on its source address and target address. Take a look at the figure below. Two network segments are separated by one firewall. one end of the firewall has a UNIX computer, and the other has a PC client.
When a PC client initiates a telnet request to a UNIX computer, the PC's telnet client program generates a TCP packet and sends it to the local protocol stack for sending. Next, the protocol stack "plugs" the TCP packet into an IP packet and sends it to a UNIX computer through the path defined by the PC's TCP/IP stack. In this example, the IP package must pass through the firewall on both PC and UNIX computers to reach UNIX computers. Now, the firewall rejects all the packets sent to UNIX computers by using the "command" (in terminology). After this is done, A good firewall with a "heart" will notify the customer of the program! Since the IP data sent to the target cannot be forwarded, only users with the same network segment as the UNIX computer can access the UNIX computer.
In another case, you can run the firewall to find the poor PC. If other packets are too popular, the firewall won't work. This is the most basic function of the firewall: Based on the IP address for forwarding judgment. However, if you want to go to the big scene, you will not be able to turn around. Because hackers can use IP address spoofing technology, computers disguised as legitimate addresses can pass through the firewall that trusts this address. However, the forwarding decision-making mechanism based on the address is still the most basic and necessary. In addition, do not use the DNS host name to create a filter table. It is much easier to forge a DNS table than to spoof an IP address. Server TCP/UDP port filtering
Data filtering by address alone is not feasible in practical use. Another reason is that the target host often runs a variety of communication services. For example, we don't want users to connect to the system via telnet, but it's not that we have to prohibit them from using the SMTP/POP mail server at the same time? Therefore, in addition to the address, we also need to filter the TCP/UDP ports of the server.
For example, the default telnet connection port number is 23. If we do not allow the PC client to establish a telnet connection to a UNIX computer (when it is a server), we only need to command the firewall to check the packets sent to the UNIX server, filter out the packages with 23 destination port numbers. In this way, can we combine the IP address and the TCP/UDP port of the target server be used as a filter standard to implement a quite reliable firewall? No, it's not that simple.
The client also has TCP/UDP ports.
TCP/IP is an end-to-end protocol. Each network node has a unique address. The same applies to the application layer of network nodes. Each application and service at the application layer has its own corresponding "Address", that is, the port number. Both the address and port can establish effective communication between various applications of the client and the server. For example, the telnet server listens for inbound connections on port 23. At the same time, the telnet client also has a port number. Otherwise, how does the client's IP stack know which application a data packet belongs?
For historical reasons, almost all TCP/IP client programs use a random allocated port number greater than 1023. Only root users on UNIX computers can access ports lower than 1024, which are reserved for services on the server. Therefore, unless we allow all packets with port numbers greater than 1023 to enter the network, all network connections will not work properly.
This is troublesome for the firewall. If all the ports of the inbound station are blocked, all clients cannot use network resources. Because the incoming packets sent by the server to respond to external connection requests cannot be filtered by the firewall's inbound traffic. In turn, is it feasible to open all ports above 1023? Not all. Many services use over 1023 ports, such as X client, RPC-based NFS service, and a large number of non-unix ip Products (NetWare/IP. Is the network safe if all data packets that meet port 1023 are connected to the network? Even these customer programs do not dare to say they are safe enough. Bidirectional filtering
OK. Let's change our thinking. Let's give the firewall a command like this: data packets of known services can come in, and all others are blocked outside the firewall. For example, if you know that you want to access the Web server, you can only let the data packet with the source port number 80 enter the network:
However, new problems have emerged. First, how do you know the running Port Number of the server you want to access? Servers such as HTTP can be configured at will, and ports used can also be configured at will. If you set up a firewall like this, you will not be able to access any network sites that do not use the standard port number! In turn, you cannot guarantee that packets with port 80 on the network must come from the Web server. Some hackers use this to create their own intrusion tools and run them on port 80 of the local machine! We don't believe the source address, nor the source port. in this crazy world that has to dance with hackers, what is worth our trust? Fortunately, things have not reached the point of nowhere to go. There are still some countermeasures, but this method can only be used for TCP.
TCP is a reliable communication protocol. The term "reliability" means that the Protocol has some special properties including the error correction mechanism. To achieve its reliability, each TCP connection must first exchange the connection parameters through a "handshake" process. Also, each package sent out must receive a confirmation response before other packages are sent out. However, not every TCP packet must adopt a dedicated ACK packet for response. In fact, this function can be completed only by setting a special bit on the TCP packet header. Therefore, as long as a response packet is generated, the ACK bit must be set. The first packet of the connection session is not used for confirmation, so it does not set the ACK bit. In the future, the TCP packet of the session is required to set the ACK bit.
For example, a PC initiates a connection to a remote Web server and generates a connection request packet without an ACK bit. When the server responds to this request, the server sends back an ACK packet and marks the number of bytes received from the client in the packet. Then the client uses its own response packet to respond 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 restrict the data entering the network to the response packet range. Therefore, the remote system cannot initiate a TCP connection but can respond to the received data packets.
This mechanism is not impeccable. For example, if we have an internal Web server, port 80 has to be opened so that external requests can enter the network. In addition, UDP packets cannot monitor ACK bits, because UDP packets do not have ACK bits. Some other TCP applications, such as FTP, must be initiated by these server programs.
Generally, Internet services only use one pair of port numbers for all communications, while FTP programs use two pairs of port numbers during connection. The first port number is used for the FTP "Command Channel" to provide the communication link for logon and command execution, while the other port number is used for the FTP "Data Channel" to provide file transfer between the client and the server.
In a common FTP Session, the client first sends a TCP connection request to port 21 (Command Channel) on the server, and then executes various commands such as LOGIN and DIR. Once the user requests the server to send data, the FTP server uses Port 20 (data channel) to initiate a connection to the customer's data port. The problem arises. If the server initiates a data transmission connection to the client, it will send packets without an ACK bit, the firewall rejects the data packet according to the preceding rules, which means that data transmission is useless. Generally, only the advanced firewall, that is, the smart firewall, can see the port that the client just told the server, and then permit the inbound connection to the port.
Now let's look back at how to solve the UDP problem. As mentioned earlier, UDP packets do not have ACK bit, so ACK bit filtering is not allowed. UDP is an untrusted communication. This type of service is usually used for broadcast, routing, multimedia, and other broadcast communication tasks. UDP is used for NFS, DNS, WINS, NetBIOS-over-TCP/IP, and NetWare/IP.
It seems that the simplest feasible method is not to allow Inbound UDP connections. If the firewall is set to forward only UDP packets from internal interfaces, UDP packets from external interfaces are not forwarded. The problem is, for example, UDP is used for DNS name resolution requests. If you provide DNS services, at least some internal requests must be allowed to pass through the firewall. Clients such as IRC also use UDP. If you want your users to use it, they also need to bring their UDP packets into the network. What we can do is to restrict connections between local and trusted sites. However, what is trustworthy! If the hacker fails to return to the old path by means of address spoofing, will the hacker go back to the old path?
Some new routers can solve this problem through the "Memory" Outbound UDP packet: If the Inbound UDP packet matches the destination address and port number of the recent Outbound UDP packet, let it in. If no matching UDP packet is found in the memory, you have to reject it! However, how can we ensure that the external host that generates data packets is the server on which internal clients want to communicate? If a hacker swindles the address of a DNS server, he can theoretically launch an attack from the UDP port attached to the DNS server. As long as you allow DNS queries and feedback packets to enter the network, this problem will inevitably exist. The solution is to use a proxy server.
The so-called proxy server, as its name implies, represents the server on which your network is dealing with the outside world. The proxy server does not allow any direct connection between internal and external networks. It provides public and dedicated DNS, mail server, and other functions. The proxy server overwrites the data packet instead of simply forwarding it. The impression is that all hosts inside the network are standing on the edge of the network, but they are actually hiding behind the proxy. What they show up is the proxy mask.
The IP address may be false because the Source Path of the IP protocol has a mechanism. This mechanism tells the router not to use a normal path for the data packet, but to transmit the data packet according to the path in the packet header. Therefore, hackers can use the system IP address to obtain the returned data packets. Some advanced firewalls allow users to disable source routing. Generally, our network connects to the ISP through a path and then enters the Internet. Disabling the source route forces the data packet to be returned along the normal path.
Also, we need to know what other work the firewall has done when rejecting data packets. For example, does the firewall send an ICMP message "the host cannot be reached" to the connection initiating system? Or is the firewall actually not doing anything else? These problems may have security risks. The ICMP "host inaccessible" message tells the hacker that the firewall has blocked some ports, and the hacker can immediately smell something from the message. If ICMP "host inaccessible" is an error in communication, the honest system may not send anything. In turn, if no response is received, the system that initiates the communication will constantly try to establish a connection until the application or protocol stack times out. As a result, the end user can only get an error message. Of course, this method will make it impossible for hackers to determine whether a port is closed or not used.