Firewalls in the world will say at least two words: yes or no, and directly saying it means accepting or rejecting. The simplest firewall is an Ethernet bridge. But few people will think that this primitive firewall can be of much use. Most firewalls use various technologies and standards. These firewalls have many forms: some have replaced the TCP/IP protocol stack already equipped on the system; Some build their own software modules on the existing protocol stack; Some are just an independent operating system. There are also some application-oriented firewalls that only provide protection for certain types of network connections, such as SMTP or HTTP protocols. There are also some hardware-based firewall products, which should actually be classified as security routers. All these products can be called firewalls, because they all work in the same way: analyze the packets coming in and out of the firewall and decide whether to let them pass or throw them aside.
All firewalls have IP address filtering function. This task is to check the IP header and make a release/discard decision according to its IP source address and destination address. Look at the picture below. There is a firewall between the two network segments. There is a UNIX computer at one end of the firewall and a PC client at the other network segment.
When a PC client sends a telnet request to a UNIX computer, the telnet client of the PC generates a TCP packet and sends it to the local protocol stack for transmission. Next, the protocol stack "inserts" this TCP packet into an IP packet, and then sends it to the UNIX computer through the path defined by the TCP/IP stack of the PC. In this example, IP packets must pass through the firewall between PC and UNIX computer to reach UNIX computer.
Now we "command" (in technical terms, that is, configure) the firewall to reject all packets sent to UNIX computers. After completing this work, a better firewall will notify the client program! Because IP data sent to the destination cannot be forwarded, only users on the same network segment as UNIX computers can access UNIX computers.
In another case, you can order the firewall to find fault with that poor PC, and other people's bags will not work. This is the most basic function of the firewall: judging the forwarding according to the IP address. However, this trick can't be played when it comes to big scenes. Because hackers can use IP address spoofing technology, computers disguised as legitimate addresses can pass through firewalls that trust the address. However, the forwarding decision mechanism based on address is still the most basic and necessary. It is also important to note that you should not use DNS host names to build filter tables. Forging DNS is much easier than spoofing IP addresses.
Server TCP/UDP port filtering
It is not feasible to filter data only by address. Another reason is that there are many communication services running on the target host. For example, we don't want users to connect to the system through telnet, but that doesn't mean we have to ban them from using SMTP/POP mail servers at the same time, does it? Therefore, in addition to the address, we also need to filter the TCP/ UDP port of the server.
For example, the default telnet service connection port number is 23. If we don't allow a PC client to establish a telnet connection with a UNIX computer (at this time, we think it is a server), then we just need to order the firewall to check the packets sent to the UNIX server and filter out the packets with the target port number of 23. In this case, can we combine the IP address with the TCP/UDP port of the target server as a filtering standard to realize a quite reliable firewall? No, it's not that simple.
Clients also have TCP/UDP ports.
TCP/IP is an end-to-end protocol, and each network node has a unique address. The same is true for the application layer of network nodes. Each application and service in the application layer has its own corresponding "address", that is, port number. Only when the address and port are available can we 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 can the IP stack of the client know which application a packet belongs to?
Due to historical reasons, almost all TCP/IP clients use randomly assigned port numbers greater than 1023. Only root users on UNIX computers can access ports below 1024, which are still reserved for services on the server. Therefore, unless we let all packets with port numbers greater than 1023 enter the network, all kinds of network connections will not work properly.
This is very troublesome for the firewall. If all inbound ports are blocked, all clients cannot use network resources. Because the inbound packets sent by the server in response to the external connection request (that is, entering the firewall) cannot pass the inbound filtering of the firewall. Conversely, is it feasible to open all ports higher than 1023? Not exactly. Because many services use ports larger than 1023, such as X client, NFS service based on RPC and many non-UNIX IP products (NetWare/IP). So, if all packets that meet the 1023 port standard are allowed to enter the network, can the network be said to be secure? Even these client programs dare not say that they are safe enough.
Bidirectional filtration
Okay, let's think about it from another angle. We gave the order to the firewall: packets of known services can come in, and all others are blocked outside the firewall. For example, if you know that users want to access the Web server, only packets with source port number 80 can enter the network:
However, new problems have emerged. First of all, how do you know which port numbers are running on the server you want to access? A server like HTTP can be configured at will, and the ports used can also be configured at will. If you set up a firewall like this, you won't be able to visit any website that doesn't use the standard port number! Conversely, you can't guarantee that the packet with port number 80 entering the network must come from the Web server. Some hackers use this self-made intrusion tool to run on port 80 of this machine!
Check ACK bit
We don't trust the source address and source port. What else can we believe in this crazy world where we have to dance with hackers? Fortunately, things have not reached the point of despair. There are some countermeasures, but this method can only be used for TCP protocol.
TCP is a reliable communication protocol, and the word "reliable" means that the protocol has some special properties, including error correction mechanism. In order to achieve its reliability, each TCP connection must go through a "handshake" process to exchange connection parameters. In addition, before sending other subsequent data packets, each sent data packet must get an acknowledgement response. However, it is not necessary to respond to each TCP packet with a special ACK packet. In fact, this function can be accomplished by setting a special bit on the TCP header. Therefore, whenever a response pACKet is generated, the ack bit should be set to 1. The first packet of the connection session is not used for acknowledgement, so it does not set the ACK bit, and the TCP packets exchanged in subsequent sessions will set the ACK bit.
For example, if a PC starts a connection to a remote Web server, the server will generate a connection request packet with no ACK bit set. When the server responds to the request, the server sends back a packet with the ack bit set, and marks the number of bytes received from the client in the packet. Then, the client responds to the data packet with its own response 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. Therefore, the remote system can't start the TCP connection at all, but it can respond to the received packets.
This mechanism is not perfect. For a simple example, suppose we have an internal Web server, then port 80 must be opened so that external requests can enter the network. In addition, it is impossible to monitor the ACK bit of UDP packets because UDP packets have no ack bit at all. There are also some TCP applications, such as FTP, and the connection must be initiated by these server programs themselves.
Difficulties brought by FTP
General Internet services only use one pair of port numbers in all communications, while FTP programs use two pairs of port numbers when connecting. The first pair of port numbers is used in the "command channel" of FTP to provide communication links for logging in and executing commands, while the other pair of port numbers is used in the "data channel" of FTP to provide file transfer between the client and the server.
In a normal FTP session, the client first sends a TCP connection request to port 2 1 (command channel) of 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 its 20-port (data channel) to start the connection with the customer data port. The problem is that if the server initiates a connection to the client to transmit data, it will send a packet without setting the ACK bit, and the firewall will reject the packet according to the rules just now, which means that data transmission is hopeless. Usually only advanced firewalls, that is, firewalls that are smart enough, can see the port that the client just told the server, and then allow inbound connections to that port.
UDP port filtering
Ok, now let's go back and see how to solve the UDP problem. As I said just now, UDP pACKets have no ack bits, so they can't be filtered with ack bits. UDP is an "unreliable" communication and will be sent out anyway. This type of service is usually used for communication tasks, such as broadcasting, routing and multimedia. NFS, DNS, WINS, NetBIOS-over-TCP/IP and NetWare/IP all use UDP.
It seems that the simplest and most feasible method is not to allow inbound UDP connections to be established. The firewall is set to forward only UDP packets from the internal interface, not UDP packets from the external interface. The problem now is that, for example, DNS name resolution requests use UDP. If you provide DNS service, at least some internal requests must be allowed to pass through the firewall. There are also client programs like IRC that also use UDP. If you want your users to use it, you should also let their UDP packets enter the network. What we can do is to restrict the connection from local to trusted sites. However, what is trustworthy! If hackers take the method of address deception, isn't it back to the old road?
Some new routers can solve this problem by "memorizing" outbound UDP packets: if the inbound UDP packet matches the destination address and port number of the latest outbound UDP packet, let it in. If you can't find a matching UDP packet in memory, you have to reject it! However, how do we determine that the external host generating the data packet is the server with which the internal client wants to communicate? If the hacker lied about the address of the DNS server, theoretically, of course, he can launch an attack from the UDP port attached to DNS. As long as you allow DNS queries and feedback packets to enter the network, this problem is bound to exist. The solution is to use a proxy server.
The so-called proxy server, as its name implies, is the server that deals with the outside world on behalf of your network. The proxy server does not allow any direct connection inside or outside the network. It provides public * * * and private DNS, mail server and other functions. The proxy server rewrites the packet instead of simply forwarding it. It gives people the impression that the hosts in the network are standing on the edge of the network, but in fact they are all hidden behind the agent, just appearing as the mask of the agent.
summary
The IP address may be false, which is caused by the source path mechanism of the IP protocol, which tells the router not to use the normal path for the packet, but to transmit the packet according to the path in the packet header. Then the hacker can use the IP address of the system to get the returned data packet. Some advanced firewalls allow users to block source routes. Usually, our network connects to ISP through a path, and then enters the Internet. Disabling source routing will force packets to return along the normal path.
In addition, we need to know what else the firewall does when rejecting packets. For example, did the firewall send back an ICMP message of "host unreachable" to the connection initiating system? Or did the firewall really do nothing else? These problems may have security risks. ICMP "host unreachable" message will tell hackers that "some ports are blocked by firewall", and hackers can smell something from this message immediately. If ICMP "host unreachable" is a communication error, then an honest system may really send nothing. On the other hand, no response will make the initiating system try to establish a connection until the application or protocol stack times out, and the end user can only get an error message. Of course, this way will make it impossible for hackers to judge whether a port is closed or unused.