Working principle of firewall (2)
Kevin WHISTLER
This can be troublesome about the firewall. If all the ports of the inbound are blocked, then all clients cannot use network resources. Because the server issues an inbound of the external connection request (that is, it means to enter the firewall) packets cannot be filtered through the firewall. Conversely, is it possible to open all ports above 1023? Not too good. Since many services used ports are greater than 1023, such as X Client, RPC-based NFS services, and numerous non-Unix IP products (NetWare / IP) is like this. Then, if the packets of the 1023 port standard enter the network, can I say safe? Even these customer programs don't dare to say that they are safe enough.
Two-way filtering
OK, let's change your ideas. We give the firewall as the next command: the data packet known service can come in, and all other blocks are outside the firewall. For example, if you know that the user wants to access the web server, only the packets with the source port number 80 enter the network:
However, the new problem appeared again. First of all, how do you know which port numbers you want to access? The server like HTTP is originally configured, and the port used can also be configured. If you set up a firewall like this, you can't access the network site that does not use the standard port number! Conversely, you can't guarantee that the port number 80 has a port number 80 in the packet of the network. Some hackers use this to make their own intrusion tools and let them run in the 80-port of this machine!
Check ACK
Source address We don't believe that the source port is also not believed, this has to be in the crazy world of hackers worthy of our trust? Fortunately, things have not yet walked around. The countermeasures are still there, but this approach can only be used for TCP protocols.
TCP is a reliable communication protocol that means that the protocol has some special properties including error correction mechanisms. In order to achieve its reliability, each TCP connection must pass through a "handshake" process to exchange connection parameters. Also, a confirmation response must be obtained before each sending package is sent out in subsequent additional packages. However, it is not to respond to each TCP package to respond to a special ACK package, which is actually only set up a special bit on the TCP header. So, as long as the response package is generated, the ACK bit is set. The first package of the connection session is not used to confirm, so it does not set an ACK bit, and the subsequent session exchange TCP package will set the ACK bit.
For example, the PC initiates a connection to the remote web server, which generates a connection request package that does not set an ACK bit. When the server responds to the request, the server sends a packet setting the ACK bit, and marks the number of bytes received from the client in the package. The client then responds to the packet with its own response package, which also sets the ACK bit and tagged the number of bytes received from the server. By monitoring the ACK bit, we can limit the data that enters the network within the scope of the response package. Thus, the remote system cannot initiate a TCP connection but can respond to the received packet.
This mechanism cannot be an impeccable, simply, and assume that we have internal web servers, then port 80 has to be opened so that external requests can enter the network. Also, the ACK bit is not monitored for the UDP package, because the UDP packet is not a ACK bit. There are also some TCP applications, such as FTP, which must be initiated by these server programs.
FTP brings difficulties
General Internet Services use only one pair of port numbers to all communications, and the FTP program uses two pairs of port numbers during the connection. The first pair of port numbers are used for FTP "command channel" to provide a communication link for login and execution commands, while the other pair of port numbers are used for FTP "Data Channel" to provide file transfer between clients and servers. During the usual FTP session, the client first sends a TCP connection request to the server's port 21 (command channel), and then performs various commands such as login, DIR. Once the user requests the server to send data, the FTP server initiates a connection to the customer's data port with its 20-port (data channel). The problem is here, if the server initiates the connection to the client, then it will send a packet without setting an ACK bit, and the firewall refuses the data package in accordance with the rules justified. It means that the data transfer has not played. Usually only advanced, it is a smart firewall to see that the client just tells the server's port, and then allows the port connection to the port.
UDP port filtering
Ok, now we go back to see how to solve the UDP problem. Just said, the UDP package does not have an ACK bit, so the ACK bit filtering cannot be performed. UDP is a "unreliable" communication that is sent, this type of service is usually used in broadcast, routing, multimedia and other broadcast forms of communication tasks. NFS, DNS, WINS, NetBIOS-OVER-TCP / IP and NetWare / IP are used using UDP.
It seems that the simplest possible way is not to establish an inbound UDP connection. The firewall is set to only a UDP package from the internal interface, and the UDP package from the external interface is not forwarded. The current problem is that the DNS name resolution request uses UDP if you provide a DNS service, at least allow some internal request to cross the firewall. There are also client programs such as IRC to use UDP. If you want your user to use it, you should also let their UDP packages enter the network. What we can do is to limit the connections between local to trusted sites. But what is trust! If the hacker takes the address spoofing method not going back to the old road?
Some new routers can solve this problem by "memory" outbound udp package: If the inbound UDP package matches the target address and port number of the recent UDP package, it will come in. If you can't find a matching UDP package in memory, you have to reject it! However, how do we confirm that the external host that generates a packet is the server that the internal client wants to communicate? If the hacker scams the address of the DNS server, he is theoretically to initiate an attack from the UDP port attached to the DNS. As long as you allow DNS queries and feedback packages to enter the network, it will inevitably exist. The method is to adopt a proxy server.
The so-called proxy server, as the name suggests is a server representing your network and the outside world. The proxy server does not allow direct connections inside and outside of the network. It itself provides a variety of functions such as public and dedicated DNS, mail servers. Proxy server rewrites the packet rather than simply forwarding it. The feeling of people is that the hosts inside the network are standing on the edge of the network, but in fact they all hide behind the agent, but the appearance is just a proxy mask.
summary
The IP address may be fake, which is due to the mechanism of the IP protocol, which tells the router not to adopt a normal path for the packet, but in accordance with the path within the header. So hackers can use the system's IP address to get the returned packet. Some senior firewalls allow users to prohibit source routing. Usually our network is connected to the ISP via a path, then go to the Internet. The disabled source route will force the packet to return along the normal path.
