The firewall is a filter plug (now you understand this is not wrong), you can make your favorite things through this plug, other things are all filtered out. In the world of the network, it is to be filtered by the firewall is a communication package that carries communication data.
At least two words: Yes or No. at least two words: yes or no. It is directly that it is accepted or refused. The simplest firewall is an Ethernet bridge. But almost no one will think that this original firewall can be used. Most firewalls use technology and standards can be described as a five-flowers. These firewalls have a variety of ways: some replacement of TCP / IP protocol stacks on the system; some have their own software modules on existing protocol stacks; some are simply an independent operating system. There are also some application-type firewalls to provide only protecting specific types of network connections (such as SMTP or HTTP protocols, etc.). There are also some hardware-based firewall products, which should be classified into a secure router. The above products can be called firewalls because their work mode is the same: analyze the packets of the firewall, decide to release them on one side.
All firewalls have IP address filtering. This task is to check the IP header and make a release / discard decision based on its IP source address and destination address. See the picture below, between the two network segments, have a firewall, one end of the firewall with a Unix computer, and the network segment of the other is a platform PC client.
When the PC client initiates a Telnet request to the UNIX computer, the PC's Telnet client produces a TCP package and transmits it to the local protocol preparation. Next, the protocol stack will "plug" into an IP package, and then send it to UNIX computers through the path defined by the PC's TCP / IP stack. In this example, this IP package must pass through the firewall in the PC and UNIX machines to the UNIX computer.
Now we "command" (speculative by professional terminology) firewall refused to send all packets sent to UNIX computers, after completing this work, "Heart intestines" firewall will notify the customer program! Since IP data that is swimming is not forwarded, then only the Unix computer can access the UNIX computer with a UNIX computer in a network segment.
There is also a situation, you can order the firewall to find the poor PC to find 茬, someone else's packets have made it. This is the most basic function of the firewall: the forwarding judgment is made according to the IP address. But I have to go to the big scene. This kind of little trick doesn't turn. Since the hackers can use IP address spoofing technology, the computer that disguise into a legitimate address can pass the firewall trusting this address. However, the forwarding decision mechanism according to the address is still the most basic and necessary. In addition, it is to pay attention to it. Do not build a filter table with the DNS hostname, which is much easier to deceive the DNS than IP address.
Server TCP / UDP port filtering
It is not feasible to rely on the address to perform data filtering in practical use. There is a reason is that the target host is often running a variety of communication services. For example, we don't want users to connect to the system in a Telnet, but this is never Is it possible to ban them using the SMTP / POP mail server at the same time? So, we have to filter the server's TCP / UDP port outside of the address.
For example, the default Telnet service connection port number is 23. If we don't allow the PC client to establish a Telnet connection to UNIX computers (at this time we are server), then we only need to command the firewall check the sending target is a packet of UNIX servers, and filtering it with a 23 target port number. Ok. In this way, do we combine IP addresses and target server TCP / UDP ports that can be used as a filter criteria to achieve a fairly reliable firewall? No, not so simple.
The client also has TCP / UDP ports
TCP / IP is an end-to-end protocol, each with a unique address. The application layer of the network node is also the case, each application and service in the application layer have its own corresponding "address", which is the port number. Equipment and ports have effective communication links between various applications of clients and servers. For example, a Telnet server listens in inbound connections at port 23. At the same time, the Telnet client also has a port number, otherwise how the client's IP stack knows which application belonging to a packet? For historical reasons, almost all TCP / IP clients use a random allocation port number greater than 1023. Only Root users on UNIX machines can access ports below 1024, and these ports are also used for services on the server. So, unless we let all packets with greater than 1023 port numbers into the network, various network connects cannot work properly.
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.
Also, we need to understand which other work will be done when the firewall is rejecting the packet. For example, whether the firewall has sent an ICMP message that "host is not reachable" to the connection initiator system? Or don't you do anything else or other things? These problems may have security hazards. ICMP "The host is not reached" message will tell the hacker "The firewall specially blocks some ports", and the hacker will immediately smell from this news. If the ICMP "host is not reached" is an error that occurs in communication, then a honest system may really be sent. Converse, no response does not cause the system that initiates communication constantly attempts to establish a connection until the application or protocol stack timeout, the end user can only get an error message. Of course, this way will make hackers can't determine that a port is closed or not.
