Status detection work mechanism
Creation time: 2001-04-27
Article attribute: original
Article Source:
http://www.xfocus.org
Article submission:
Tangram (tang002_at_163.net)
First, how should status monitoring should work?
Whenever, a firewall receives an SYN package that initializes TCP connections, which is checked by the SYN packet by the firewall. This package is compared in the rule library. If all the rules are checked, the package is not accepted, then the connection is rejected. An RST packet sends it to the remote machine. If the package is accepted, the session is recorded in the status monitoring table. The table is located in the kernel mode. Subsequent packets (no SYN flags are compared to the content of the status monitoring table. If the session is in the status table, and the packet is part of the session, the packet is accepted. If it is not part of the session, the packet is discarded. This approach improves the performance of the system because each packet is not compared to the rule base, but compared to the status monitoring table. Only when SYN's packet arrives, it is compared to the rule base. The comparison of all packets and status detection tables should be made in kernel mode, so it should be very fast.
Second, the state monitoring table is established?
So when you initialize a connection, use the ACK to do it? What is wrong with it?
If the firewall's status detection table uses ACK to establish a session, it will be incorrect.
If a package is not in the status detection table, the package uses a rule library to check without considering whether it is SYN, ACK, or other packages. If the rule library passes this packet, this session is added to the status detection table. All subsequent packages will be compared to the status detection table. Because there is an entrance in the state monitoring table, the subsequent packets have not been ruled. And when we do a status monitoring entry, we also need to consider the problem of time overflow. Using this method, some simple DOS attacks will be very effectively destroyed firewall systems.
So what should the state detection table be established?
First, what we use for a session to distinguish. From the simplest angle, we can use the source address, destination address, and port number to distinguish whether it is a session.
When establishing a session by using a SYN package, the firewall compares this packet and rule base. If this data connection request is passed, it is added to the status detection table. At this time, you need to set a time overflow value, refer to the time value of the check-point fw-1, set its value to 60 seconds. The firewall then looks forward to a returned confirmation packet, when receiving such a package, the firewall sets the connection time overflow value to 3600 seconds. The type of packet for the returned connection request needs to be judged, confirmed that it contains the SYN / ACK flag. (Note: For time overflow values, it should be set by the user.)
When performing status monitoring, the confirmation of a session can only be distinguished by using the source address, destination address, and port number, and if the requirements can be met, the maintenance of the serial number of the TCP connection should be considered, although this may Need to consume more resources
Third, the connection is closed
The connection in the status monitoring table should be maintained for a period of time after the connection is closed by the communication between the communication.
The following processing method can be used as a reference to the state detection behavior after the connection is closed.
When the status monitoring module monitors a FIN or an RST package, the reduction time overflow value is reduced from our default value of 3600 seconds to 50 seconds. If there is no packet exchange in this cycle, this status detection entry will be deleted. If there is a packet exchange, this cycle will be reset to 50 seconds. If communication, this connection state will continue to be maintained at a period of 50 seconds. This design can avoid some DOS attacks, for example, some people deliberately send some FIN or RST packages to try to block these connections.
Fourth, UDP connection maintenance
Although the UDP connection is stateless, similar methods can still be used to maintain these connections. When a completed rule check When a firewall is passed through a firewall, this session is added to the status detection table, and sets a time overflow value, and any package returned in this time value will be allowed to pass, of course its SRC / The DST IP address and port number of SRC / DST are must match. V. ICMP status detection problem
For some analysis of ICMP packets, it is not enough in many firewall systems. It is necessary to analyze the contents of ICMP when performing state detection. What is the key to what ICMP can be issued and placed in the status monitoring module. The following is just what kind of ICMP package is secure, and can be used as a reference to the status detection module ICMP.
#define ICMP_ECHOREPLY 0 / * Echo reply * /
Needed if you want to allow ping, so you can allow trus for trusted peers
Outgoing and incoming for all to allow the tool to ping the internet
#define ICMP_DEST_UNREACH 3 / * DESTINATION Unreachable * /
Some Sub Types Are Needed In and Out, See Below
#define icmp_source_quench 4 / * Source quench * /
Allow It Outbound Anyway, Inbound Is Less Likey To Be a Problem, Unless
Are Doing Some Streaming or Multicast Feeding to the Internet.
#define icmp_redirect 5 / * Redirect (Change Route) * /
BLOCK!
#define ICMP_echo 8 / * echo request * /
You might allow it incoming for trusted addresses (Note Some NICS Will
Require you to make your primary dns server pingable!)
#define icmp_time_exceeded 11 / * Time Exceeded * /
HelpFull if you allow it iT incoming, could allow expend your network if you
Allow it outbound.
#define ICMP_ParameterProb 12 / * Parameter Problem * /
HelpFull if you allow it iT incoming, could allow expend your network if you
Allow it outbound.
#define icmp_timestamp 13 / * TimeStamp Request * /
#define icmp_timestampreply 14 / * TimeStamp reply * /
#define ICMP_INFO_REQUEST 15 / * Information Request * /
#define ICMP_INFO_REPLY 16 / * Information reply * /
#define icmp_address 17 / * address mask request * / # define icmp_addressReply 18 / * address mask reply * /
Block Those on The External Interface
/ * CODES for unreach. * /
#define ICMP_NET_UNREACH 0 / * NETWORK Unreachable * /
Ignored, SO Block IT
#define ICMP_HOST_UNREACH 1 / * HOST Unreachable * /
Allow It at Least Inbound, Best Would Beness INBOAN DO THATESTETEFUL
#define ICMP_PROT_UNREACH 2 / * Protocol unreachable * /
You Can Block That
#define ICMP_Port_unreach 3 / * Port Unreachable * /
You Should Allow That At Least Inbound. Be aware That Filter Rules
SHOULD Send Port_unreach on Connection Request (at Least 137, 139 And Auth),
So Make Sure Not to Block Those ICMP Packetes Which Are Generated by Your
REJECT RULE.
#define icmp_frag_needed 4 / * fragmentation needed / df set * /
Allow it in, and Possible Out if you have difference MTUS INSIDE YOUR
NetWork.
#define ICMP_SR_FAILED 5 / * Source Route Failed * /
NOT STRICTLY NEDEDEDEDED. NOBOBODY SHOULD Asume Sr Works Anywhere, Anyway.
#define ICMP_NET_UNKNOWN 6
Block, ITS IGNORED
#define ICMP_HOST_UNKNOWN 7
Allow it at least inbound.
#define ICMP_HOST_ISOLATED 8
BLOCK.
#define ICMP_NET_ANO 9
#define ICMP_HOST_ANO 10
Those Are The New Types Returned by ipfilters. You May Let Them Pass in and
OUT.
#define ICMP_NET_UNR_TOS 11
#define ICMP_HOST_UNR_TOS 12
Block
#define ICMP_PKT_FILTERED 13 / * PACKET FILTERED * /
Block, deficated
#define ICMP_PREC_VIOLATION 14 / * Precedence Violation * /
#define ICMP_PREC_CUTOFF 15 / * Precedence Cut Off * /
BLOCK.
Six, IP framed problems
At routing, if the content of the IP packet is greater than the size of the MTU, the packet will be divided into several smaller IP packets. Although the framing is not directly applied to the status detection table, it is still very important. So whether to assemble the data packet received after the data packet received before the data packet is intercepted.
In most cases, the firewall is detected as a state, which is required for some types of framing IP packets. The firewall monitors the head information of TCP as a monitoring of a session. However, only the first fragment in all the framed IP packets contains complete information, and other frameds are only IP address information. If some divided frames are not restructure, then the status monitoring module will have no way to identify whether subsequent divided data packets belong to a part of a session. By recombination, the status detection module of the firewall can identify the entire framed data packet.
However, if the packet is checked if the data packet is completed, the firewall exhibits a lot of weaknesses for the use of divided attacks (incomplete or illegal). Because they may not be restructured at all. Of course, they will not be recorded by the log. The firewall system will soon consume the resources of the system due to the attempt to continue to restructuring these simply impossible data packets. Then you must use a very good reorganization method if you need to achieve a division reorganization. For specific applications, too small scheduling packets should be discarded.
