WO2011029357A1 - 认证通信流量的方法、通信系统和防护装置 - Google Patents

认证通信流量的方法、通信系统和防护装置 Download PDF

Info

Publication number
WO2011029357A1
WO2011029357A1 PCT/CN2010/075751 CN2010075751W WO2011029357A1 WO 2011029357 A1 WO2011029357 A1 WO 2011029357A1 CN 2010075751 W CN2010075751 W CN 2010075751W WO 2011029357 A1 WO2011029357 A1 WO 2011029357A1
Authority
WO
WIPO (PCT)
Prior art keywords
tcp
packet
syn
cookie
tcp packet
Prior art date
Application number
PCT/CN2010/075751
Other languages
English (en)
French (fr)
Inventor
高程
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP10814959A priority Critical patent/EP2464079A1/en
Publication of WO2011029357A1 publication Critical patent/WO2011029357A1/zh
Priority to US13/411,178 priority patent/US20120227088A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1458—Denial of Service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks

Definitions

  • the present invention relates to the field of communications and computers, and in particular, to a method, a communication system, and a protection device for authenticating communication traffic.
  • BACKGROUND In a Denial of Service (DoS) attack an attacker bombards a victim network or server with a large amount of message traffic. Processing this traffic consumes the victim's available bandwidth, CPU power, or other critical system resources, and ultimately prevents the victim from serving its legitimate customers.
  • Distributed DoS (DDoS) attacks involve the generation of simulated network traffic from multiple sources at the same time, so its destructiveness may be greater.
  • IP Internet Protocol
  • Embodiments of the present invention provide a method, apparatus, and system for authenticating communication traffic on a network to prevent DOS attacks and improve communication security.
  • An embodiment of the present invention is to provide a method for authenticating communication traffic, which is applicable to a scenario including at least one client and server, and includes: receiving a first transmission control protocol sent by a client Determining whether the source address of the first TCP packet has been verified, if the source address of the first TCP packet has been verified, forwarding the first TCP packet to the server; if the source of the first TCP packet If the address has not been verified, the second TCP packet is sent to the sender of the first TCP packet, the partial field of the second TCP packet is encapsulated with a cookie, and the second TCP packet does not include the TCP ACK packet; Determining, by the sender of the first TCP packet, a third TCP packet, whether the corresponding field value of the third TCP packet matches the cookie, and if the corresponding field value of the third TCP packet does not match the cookie, determining The source address of the sender of the first TCP packet is forged; if the corresponding field value of the third TCP packet matches the
  • the protection device includes: an obtaining module, a first determining module, a second determining module, a sending module, and a forwarding module, where: the obtaining module is configured to acquire a client sent to the server First transmission control protocol
  • the first determining module configured to determine a source of the first TCP packet acquired by the acquiring module Whether the address has been verified, if the source address of the sender of the first TCP packet has been verified to allow the sender of the first TCP packet to establish a TCP connection with the server, the forwarding module forwards the first TCP packet to the server, The client directly establishes a TCP connection with the server; if the source address of the first TCP packet has not been verified, the sending module sends a second TCP packet to the client, where a part of the second TCP packet is encapsulated
  • the obtaining module is further configured to receive a third TCP packet sent by the client, and send the packet to the second determining module, where the second determining module is configured to determine a corresponding field value of the third TCP packet.
  • the embodiment of the present invention further provides a communication system, including a server, at least one client, and a protection device between the server and the at least one client, where: the client is configured to send a first TCP to the server.
  • the packet is configured to establish a row TCP connection with the service; the protection device is configured to intercept the first TCP packet sent by the client to the server, and determine whether a source address of the sender of the first TCP packet is confirmed, if Whether the source address of the sender of the first TCP packet is confirmed to be authentic, and forwarding the first TCP packet to the server; if the source address of the sender of the first TCP packet is not confirmed, Sending a second TCP packet to the sender of the first TCP packet, the second TCP Some of the fields of the packet are encapsulated with a cookie.
  • the server configured to receive a fourth TCP packet sent by the protection device, and respond to the first TCP packet
  • the method, the communication system, and the protection device for authenticating the communication traffic in the embodiment of the present invention perform authentication before the TCP packet arrives at the server, confirm the real source address, and then confirm whether it attacks the packet, and determine whether to allow it to establish a TCP connection with the server.
  • FIG. 1 is a schematic flowchart of a processing method for simultaneously transmitting a SYN report by a communication partner when establishing a TCP connection defined in RFC 793;
  • FIG. 2 is a schematic structural diagram of a communication system in which a TCP client communicates with a TCP server via a guard device;
  • FIG. 4 is a schematic flowchart of a method for authenticating communication traffic according to an embodiment of the present invention;
  • FIG. 5 is a schematic flowchart of another method for authenticating communication traffic according to an embodiment of the present invention;
  • FIG. 6 is a schematic flowchart of a method for authenticating communication traffic according to the embodiment shown in FIG.
  • FIG. 5; FIG. 7 is a schematic flowchart of another method for authenticating communication traffic according to an embodiment of the present invention; 8 and 9 are schematic flowcharts of another method for authenticating communication traffic according to an embodiment of the present invention;
  • FIG. 10 is a schematic structural diagram of a communication system according to an embodiment of the present invention; and
  • FIG. 11 is a protection device according to an embodiment of the present invention;
  • FIG. 12 is a schematic structural view of another protection device according to an embodiment of the present invention.
  • TCP is a connection-oriented, end-to-end full-duplex protocol that provides reliable interprocess communication between pairs of processes in a host.
  • the exchange of information between TCP peer devices is assembled into datagrams called segments, each datagram containing a TCP header followed by payload data. Fragments are transmitted over the network in the form of IP packets.
  • DARPA Defense Advanced Research Projects Agency
  • Each octet sent in the TCP segment is assigned a Sequence Number, which is used by the receiving computer to recover from corruption, loss or duplication of the packet, and to reorder the segments delivered in the wrong order.
  • the receiver Upon receiving the segment, the receiver should give a positive acknowledgment (ACK) by returning to the sender a packet with the "ACK" control bit set in the TCP header. If the sender does not receive an ACK within the timeout interval, it resends the data. Since TCP is Full-duplex protocol, so the header of each fragment contains a serial number and a confirmation number
  • the sequence number field holds the sequence number of the first data octet in the fragment (or the initial sequence number ISN ( Initial Sequece, ISN) in the case of a SYN packet).
  • the acknowledgment number field contains the value of the next sequence number that the fragment sender expects to receive on the TCP connection. Thus, the confirmation number is determined by the highest sequence number of the last segment received. In order to manage the amount of data sent by the sender, the receiver also returns when returning each ACK.
  • Window indicating the range of serial numbers that are acceptable in addition to the last fragment successfully received.
  • the handshake is based on the connection to establish the exchange of the fragment, as well as the initial sequence number, where the connection establishment fragment is included in the header of its fragment is called
  • ISN (ISN).
  • Computer B responds with a SYN-ACK packet, gives its own ISN, and acknowledges the ISN sent by computer A (by setting the ACK bit and placing the value ISN+1 in its acknowledgment number field).
  • Computer A finally responds with an ACK packet, confirms the ISN sent by computer B, and the connection is established.
  • the TCP fragment header also contains a "RST" control bit that is used to reset a TCP connection that is not properly synchronized when it is necessary to reset a TCP connection that is not properly synchronized.
  • the general rule is that whenever the connection is not in the "established" state, the RST packet (where the RST bit is set) is sent whenever it is apparent that it does not want to continue the segment of the currently connected segment. Thus, for example, if a computer in the process of establishing a TCP connection receives an ACK packet containing an unexpected acknowledgment number, the receiving computer will return an RST packet to the sending computer.
  • the TCP reverse detection scheme is used to prevent the DoS attack, and in the embodiment of the present invention, the TCP state transition of the client conforms to the definition in the TCP standard RFC793.
  • RFC793 the way in which the communication parties simultaneously send TCP SY packets when establishing a TCP connection is defined.
  • TCP B replies to TCP A with the first SYN-ACK packet.
  • the ACK number is 101, and the TCP connection from TCP A to TCP B is established; TCP A receives the first After the two SYN packets, the second SYN-ACK packet is replied to the TCP B.
  • the ACK number is 301, and the TCP connection from TCP B to TCP A is established.
  • the TCP client communicates with the TCP server via the guard device, and uses the guard device to perform TCP reverse detection between the TCP client and the TCP server. Only the detected client communication data is allowed to be sent to the TCP. Service-Terminal.
  • the guard can be placed on a router or internetwork or server.
  • the inter-network device includes, but is not limited to, an intermediate device such as a firewall.
  • the client and server refer to the client and server in the sense of TCP connection
  • the client refers to the communication end that initiates the TCP connection
  • the server refers to the communication end that receives the TCP connection.
  • a method for authenticating communication traffic is applicable to a scenario including at least one client and a server, where the method includes:
  • the guard device acquires a first TCP packet sent by the client to the server, where the first TCP packet may be a TCP SYN packet, or may be a TCP SYN-ACK packet.
  • S102 Determine whether the source address of the first TCP packet has been verified, and if the source address of the first TCP packet has been verified, forward the first TCP packet to the server; if the source address of the first TCP packet If the verification has not passed, the process proceeds to S104; the protection device determines whether the source address of the first TCP packet has been verified, and if the source address of the first TCP packet has been verified, the first TCP packet is forwarded to the server. If the source address of the first TCP packet has not been verified, then S104 is performed. SI 04, sending a second TCP packet to the sender of the first TCP packet, a part of the second TCP packet is encapsulated with a cookie, the second TCP packet does not include a TCP ACK packet;
  • S108 Determine whether the corresponding field value of the third TCP packet matches the cookie. If the corresponding field value of the third TCP packet does not match the cookie, determine that the source address of the sender of the first TCP packet is forged. If the corresponding field value of the third TCP packet matches the cookie, determining that the source address of the sender of the first TCP packet is authentic, and executing S110;
  • S112. Allow the sender of the first TCP packet to establish a TCP connection with the server.
  • the sender of the first TCP packet re-initiates a TCP connection request to the server, the sender of the first TCP packet is allowed to establish a TCP connection with the server.
  • S110 is an optional step. After S108 is executed, S110 may not be executed, and S112 is directly executed. The specific flowchart is shown in FIG. 4.
  • the first TCP packet is a first TCP SYN packet
  • the second TCP packet is a second TCP SYN-ACK packet
  • an ACK field of the second TCP SYN-ACK is encapsulated with a cookie
  • the first TCP packet is the first TCP SYN-ACK packet
  • the second TCP packet For the second TCP SYN-ACK packet, the ACK field of the second TCP SYN-ACK packet is encapsulated with a cookie
  • the third TCP packet is a TCP RST packet; and the corresponding field value of the third TCP packet matches the cookie
  • the method before receiving the first TCP SYN-ACK packet, the method further includes: the server sending the fourth TCP SYN packet to the client Requiring a TCP connection with the client, the client sending the first TCP SYN-ACK packet after receiving the fourth TCP SYN packet.
  • the source address is an Internet Protocol IP address, the IP address. Includes IPv4 address or IPv6 address.
  • the client with the real source address returns a second SYN-ACK packet for the second SY packet sent by the guard device, where the ACK field value of the second SYN-ACK packet should be Cookie+1, that is, the second SYN.
  • ACK Cookie+l.
  • the guard device can detect the authenticity of the source address of the client by detecting the value of the ACK field in the second SYN-ACK packet. If the value of the ACK field in the second SYN-ACK packet is not equal to Cookie+1, determining that the source address of the first SYN packet is ⁇ , the guard device may discard the source address in the TCP header as the source address of the first SYN packet.
  • the protection device may send a TCP RST to the client that sent the first S YN packet.
  • the packet is reset to the connection, and the third SY packet resent by the client is forwarded directly to the server, so that the client and the server directly establish a TCP connection.
  • the guard can act as an extended function board of the router to reversely detect the source address of the data packet before the router forwards the data packet, discarding the suspicious DDoS attack grouping.
  • a protection device is set between a client and a server, and a method for authenticating communication traffic includes:
  • TCP S600 receiving the first TCP SYN packet, when the client wants to establish a TCP connection with the server for communication, the client sends the first TCP SY packet to the server, and the protection device between the client and the server obtains the first message sent by the client to the server.
  • a TCP SY packet receiving the first TCP SYN packet, when the client wants to establish a TCP connection with the server for communication, the client sends the first TCP SY packet to the server, and the protection device between the client and the server obtains the first message sent by the client to the server.
  • the protection device intercepts the first TCP SY packet sent by a client, it is determined whether the source address of the first TCP SYN packet has been verified, if the first TCP If the source address of the SY packet has been verified, it indicates that the source address of the first TCP SY packet has been confirmed as a real legal source address, and a TCP connection can be established with the server, and the protection device forwards the first
  • the TCP SY is grouped to the server, so that the client establishes a TCP connection directly with the server; if the source address of the first TCP SYN packet has not been verified, then S604 is performed.
  • the source IP address, the destination IP address, the source port number, the destination port number, and the TCP/UDP (User Datagram Protocol) number of the sender of the first TCP SYN packet are included.
  • the second TCP SYN packet is a TCP SYN packet that meets the requirements defined in RFC793, and indicates that the protection device requires a TCP connection with the sender of the first TCP SYN packet, that is, the client.
  • RFC793 under normal circumstances, that is, when the source address of the sender of the first TCP SY packet is true, when the sender of the first TCP SY packet receives the second TCP SY packet sent by the guard, it is required to When a TCP connection is established, the sender of the first TCP SYN packet will send a SYN-ACK packet to the sender of the second TCP SYN packet (ie, the guard) as a response to the second TCP SYN packet.
  • S606 Receive a SYN-ACK packet sent by a sender of the first TCP SYN packet, and execute S608.
  • the guard receives the SYN-ACK packet sent from the sender of the first TCP SYN packet, and performs S608 to confirm the SYN-ACK sent by the sender of the first TCP SYN packet. Whether the grouping meets specific requirements.
  • S608 Determine whether the ACK number of the SYN-ACK packet matches the cookie. If the ACK field value of the SY-ACK packet matches the cookie, go to S610. If the ACK field value of the SYN-ACK packet does not match the cookie, determine to issue the first The source address of the sender of a TCP SYN packet is forged. After receiving the SYN-ACK packet sent by the sender of the first TCP SYN packet (ie, a certain client), the protection device determines whether the ACK field value of the SYN-ACK packet matches the cookie, that is, determines the ACK of the SYN-ACK packet.
  • the field value is equal to Cookie+1, if the ACK field value of the SYN-ACK packet is equal to Cookie+1, indicating that the source address of the sender of the first TCP SYN packet is authentic, executing S610; if the SYN-ACK packet is If the ACK field value is not equal to Cookie+1, it indicates that the source address of the sender of the first TCP SY packet is forged.
  • the sender of the first TCP SY packet is allowed to establish a TCP connection with the server, and the sender of the first TCP SYN packet sends a third TCP SYN packet to the server after receiving the protection device to send the TCP RST packet, requesting The server establishes a TCP connection.
  • the protection device After obtaining the third TCP SY packet, the protection device confirms that the source address of the third TCP SYN packet has been verified, and is a real source address, and directly forwards the third TCP SYN packet retransmitted by the client to the server, so that The client and server establish a TCP connection.
  • a protection device is disposed between a client and a server, and the method includes:
  • TCP SYN packet receiving the first TCP SYN packet, when the client wants to establish a TCP connection with the server for communication, the client sends the first TCP SY packet to the server, and the protection device between the client and the server obtains the first message sent by the client to the server.
  • a TCP SYN packet receiving the first TCP SYN packet, when the client wants to establish a TCP connection with the server for communication, the client sends the first TCP SY packet to the server, and the protection device between the client and the server obtains the first message sent by the client to the server.
  • a TCP SYN packet receiving the first TCP SYN packet, when the client wants to establish a TCP connection with the server for communication, the client sends the first TCP SY packet to the server, and the protection device between the client and the server obtains the first message sent by the client to the server.
  • the protection device intercepts the first TCP SYN packet sent by a certain client, determining whether the source address of the first TCP SYN packet has been verified, if the source address of the first TCP SYN packet has been verified, The source address of the first TCP SYN packet has been confirmed as a real legal source address, and a TCP connection can be established with the server, and the protection device forwards the first TCP SY packet to the server, so that the client directly establishes a TCP connection with the server; If the source address of the first TCP SY packet has not been verified, the process proceeds to S704.
  • the quintuple information of the sender of the first TCP SYN packet is calculated by a hash algorithm, and the quintuple information of the sender of the first TCP SYN packet includes: the source IP address of the sender of the first TCP SYN packet, and the destination IP address, source port number, destination port number, TCP/UDP number.
  • the ACK field of the SY-ACK packet The value should be equal to the value of the SEQ field of the first TCP SY packet plus one, however, since the ACK value sent by the guard to the sender of the first TCP SYN packet to the SYN-ACK packet is not equal to the SEQ of the first TCP SYN packet.
  • the field value is incremented by 1, but is equal to the cookie.
  • the sender of the first TCP SYN packet will send a TCP RST packet to reset the TCP connection.
  • the SEQ field value of the TCP RST packet should be equal to the cookie.
  • S706 Receive an RST packet sent by a sender of the first TCP SYN packet, and execute S708.
  • the guard receives the TCP RST packet sent from the sender of the first TCP SY packet, and performs S708 to confirm whether the TCP RST packet sent by the sender of the first TCP SYN packet meets a specific requirement.
  • S708 Determine whether the SEQ value of the TCP RST packet matches the cookie, if the SEQ field value of the TCP RST packet does not match the cookie, determine that a source address of a sender of the first TCP SYN packet is forged; If the SEQ field value of the TCP RST packet matches the cookie, it is determined that the source address of the sender of the first TCP SYN packet is authentic, and S710 is performed.
  • the protection device After receiving the TCP RST packet sent by the sender of the first TCP SYN packet, the protection device determines whether the SEQ value of the TCP RST packet matches the cookie, that is, determines whether the SEQ field value of the TCP RST packet is equal to the cookie, if the TCP RST packet SEQ field value is equal to The cookie indicates that the source address of the sender of the first TCP SYN packet is authentic, and S710 is performed; if the value of the SEQ field of the TCP RST packet is not equal to the cookie, it indicates that the source address of the sender of the first TCP SYN packet is forged. of.
  • the protection device allows the sender of the first TCP SYN packet to establish a TCP connection with the server.
  • the sending direction server of the first TCP SY packet sends a second TCP SYN packet, requesting to establish a TCP connection with the server.
  • the protection device After intercepting the second TCP SYN packet, the protection device confirms that the source address of the second TCP SYN packet has been verified, and is a real source address, and directly forwards the second TCP SY packet retransmitted by the client to the server, so that The client and server establish a TCP connection.
  • a protection device is set between a client and a server.
  • a server initiates a TCP connection request to a client, that is, the server sends a server to a client.
  • the first SYN-ACK packet may also be a DoS attack packet sent by an attacker.
  • the first SYN-ACK packet sent by the client to the server is acquired by the guard before reaching the server. Since the protection device does not acquire the packet sent from the server to the client, but only acquires the packet sent from the client to the server, when the protection device acquires the client and sends the packet to the server. When the first SYN-ACK packet is sent, the protection device needs to confirm whether the source address of the first SYN-ACK packet is true.
  • FIG. 9 it is a schematic flowchart of another method for authenticating communication traffic according to an embodiment of the present invention. , the method includes:
  • S900 Receive a first SYN-ACK packet, and obtain, by the protection device, the client to send to the first SYN-ACK packet.
  • S902 Determine whether the source address of the first SYN-ACK packet has been verified, and if the source address of the first SYN-ACK packet has been verified, forward the first SYN-ACK packet to the server; if the first SYN If the source address of the -ACK packet has not been verified, then S904 is performed.
  • the guard intercepts the first SYN-ACK packet sent by a certain client, it is determined whether the source address of the first SYN-ACK packet has been verified, if the source address of the first SYN-ACK packet has been verified.
  • the protection device forwards the first SYN-ACK packet to the server, so that the client and the server directly Establishing a TCP connection; if the source address of the first SYN-ACK packet has not been verified, then S904 is performed.
  • the cookie value is calculated by the hash algorithm according to the quintuple information of the sender of the first TCP SYN packet, first
  • the quintuple information of the sender of the TCP SY packet includes: the source IP address, the destination IP address, the source port number, the destination port number, and the TCP/UDP number of the sender of the first TCP SY packet, that is, when the first When the source address of the sender of the SYN-ACK packet is true, the sender of the first SYN-ACK packet receives the first ACK packet sent by the other party (such as a server), and the ACK field value of the second ACK packet should be equal to The SEQ field value of the first SYN-ACK packet is incremented by one.
  • the guard since the guard sends the second SYN-ACK packet to the sender of the first SYN-ACK packet, the ACK value of the second SYN-ACK packet is not equal to
  • the SEQ value of the first SYN-ACK packet is incremented by one, but is equal to the cookie, so the sender of the first SYN-ACK packet will send a TCP RST packet to reset the TCP connection.
  • the SEQ field value of the TCP RST packet should be equal to the cookie.
  • S906 Receive an RST packet sent by a sender of the first SYN-ACK packet, and execute S908.
  • the guard receives the TCP RST packet sent from the sender of the first SYN-ACK packet, and performs S908 to confirm whether the TCP RST packet sent by the sender of the first SYN-ACK packet meets a specific requirement.
  • S908 Determine whether the SEQ field value of the TCP RST packet matches the cookie. If the SEQ field value of the TCP RST packet does not match the cookie, determine that the source address of the sender of the first SYN-ACK packet is forged. If the SEQ field value of the TCP RST packet matches the cookie, it is determined that the source address of the sender of the first SYN-ACK packet is authentic, and S910 is performed.
  • the protection device After receiving the TCP RST packet sent by the sender of the first SYN-ACK packet, the protection device determines whether the SEQ field value of the TCP RST packet matches the cookie, that is, determines whether the SEQ field value of the TCP RST packet is equal to the cookie, if the TCP SEQ field value of the RST packet Equivalent to Cookie, indicating that the source address of the sender of the first SY-ACK packet is authentic, and executing S310; if the SEQ field value of the TCP RST packet is not equal to the cookie, indicating the source of the sender of the first SY-ACK packet The address is forged.
  • the protection device allows the sender of the first SYN-ACK packet to establish a TCP connection with the server.
  • the sending direction server of the first SYN-ACK packet sends a third SYN-ACK packet, requesting to establish a TCP connection with the server.
  • the protection device After intercepting the third SYN-ACK packet, the protection device confirms that the source address of the third SYN-ACK packet has been verified, and is a real source address, and directly forwards the third SYN-ACK packet retransmitted by the client to the The server, which enables the client and server to establish a TCP connection.
  • the embodiment of the present invention further provides a communication system.
  • the communication system includes a server, at least one client, and a protection device between the server and the at least one client, where: a client, configured to send a first TCP packet to the server to establish a TCP connection with the server; the protection device, configured to intercept the first TCP packet sent by the client to the server, determine the first TCP packet Whether the source address of the sender is acknowledged, if the first group is forwarded to the server; if the source address of the sender of the first TCP packet is not confirmed, sending to the sender of the first TCP packet Second TCP packet, the second TCP Some of the fields of the packet are encapsulated with a cookie.
  • the server configured to receive a fourth TCP packet sent by the protection device, and respond to the first TCP packet
  • the structure of the protection device is as shown in FIG.
  • the obtaining module 1101 is configured to obtain a first TCP packet sent by the client to the server, where the first determining module 1102 is configured to determine whether the source address of the first TCP packet obtained by the acquiring module 1101 has been verified.
  • the forwarding module 1107 forwards the first TCP packet to the server, so that the client A TCP connection is established directly with the server; if the source address of the first TCP packet has not been verified, the sending module 1104 sends a second TCP packet to the client, and a part of the field of the second TCP packet is encapsulated with a cookie.
  • RFC793 if the source address of the client is real, when the client receives the second TCP packet sent by the sending module 1104, the client will send the sender of the second TCP packet (ie, the guard) A third TCP packet is sent as a response to the second TCP packet. According to the definition of RFC793, the corresponding field value of the third TCP packet should match the cookie.
  • the obtaining module 1101 is further configured to receive a third TCP packet sent by the client, and
  • the second judging module 1103 is configured to determine whether a corresponding field value of the third TCP packet matches the cookie, and if the corresponding field value of the third TCP packet matches the cookie, indicating that the The source address of the client is authentic; if the corresponding field value of the third TCP packet does not match the cookie, it indicates that the source address of the client is forged. If the source address of the client is authentic, the reset module 1106 sends a TCP RST packet to the client to reset the TCP connection that the client requires to establish.
  • the forwarding module 1107 forwards the fourth TCP packet to the server, so that the client establishes a TCP connection with the server.
  • the reset module 1106 is not necessary, and the reset module 1106 may be omitted in the guard device.
  • the implementation of omitting the reset module 1106 is as shown in FIG. 12, and when the reset module 1106 is omitted, the first TCP is issued. If the source address of the packet client is true, when the TCP connection times out, the fourth TCP packet is sent again.
  • the forwarding module 1107 forwards the fourth TCP.
  • the client and server allowing the client and server to establish a TCP connection.
  • the first TCP packet is a first TCP SYN packet
  • the second TCP packet is a second TCP SYN packet
  • the first TCP packet is a first TCP SYN packet
  • the second TCP The packet is a second TCP SYN-ACK packet
  • the ACK field of the second TCP SYN-ACK is encapsulated with a cookie
  • the third TCP packet is a TCP RST packet
  • the corresponding field value of the third TCP packet matches the cookie
  • the module 1106 is not required to be reset at this time, that is, the guard does not need to send a TCP RST packet to reset the TCP connection, but by the first TCP.
  • the sender of the packet sends a TCP RST packet to reset the TCP connection.
  • the second TCP packet is the second TCP SYN-ACK packet.
  • the ACK field of the second TCP SYN-ACK is encapsulated with a cookie
  • the guard does not need to send a TCP RST packet to reset the TCP connection, but is sent by the sender of the first TCP packet to the TCP RST packet reset. TCP connection.
  • the method further includes: the server sending a fourth TCP SY packet to the client, requesting to establish a TCP connection with the client, and after receiving the fourth TCP SYN packet, the client sends a first TCP SYN-ACK
  • the source address is an Internet Protocol (IP) address
  • the IP address includes an IPv4 address or an IPv6 address.
  • the source address is an IP address, which may be an IPv4 address or an IPv6 address.
  • the method, the communication system and the protection device for authenticating communication traffic in the embodiment of the present invention perform authentication before the TCP packet arrives at the server, confirm the real source address, and then confirm whether it attacks the packet, and determine whether to allow it to establish a TCP connection with the server. It can effectively prevent DoS attacks using TCP packets and improve communication security.
  • the computer software product is stored in a storage medium, including thousands of instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform the present invention.
  • a computer device which may be a personal computer, a server, or a network device, etc.
  • the method described in the examples. The above is only a preferred embodiment of the present invention, but the scope of the present invention is not limited thereto, and any technical person skilled in the art can disclose the technical scope of the present invention and the technical idea of the present invention. Variations or substitutions that are conceivable within the scope of the invention are intended to be included within the scope of the invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Description

认证通信流量的方法、 通信系统和防护装置
本申请要求于 2009 年 09 月 08 日提交中国专利局、 申请号为 CN 200910190037.4、发明名称为 "认证通信流量的方法、通信系统和防护装置" 的中国专利申请的优先权， 其全部内容通过引用结合在本申请中。
技术领域 本发明涉及通信和计算机领域， 尤其涉及一种认证通信流量的方法、 通信系统和防护装置。
背景技术 在拒绝服务（Denial of service, DoS )攻击中， 攻击者用大量消息流量 轰击受害网络或服务器。 对该流量的处理会消耗受害者的可用带宽、 CPU 能力或其他关键性系统资源， 并且最终使受害者无法服务其合法客户。 分 布式 DoS ( Distribution DoS , DDoS )攻击涉及产生同时来自多个源的仿真 网络流量， 因此其毁坏性可能更大。 在传统大带宽攻击中， 可在对输入分 组（ Packet )的源因特网协议（ Internet Protocol , IP )地址的统计分析的帮 助下追踪攻击的源。 然后受害者可过滤掉源自可疑 1P地址的任何流量， 并 且可利用该证据对攻击者采取法律行动。 但是， 现在许多攻击使用 "欺骗 性（ Spoofed ) " IP分组——包含 IP 源地址的分组——使得受害者更难以 防止自己遭受攻击。 因此需要一种防止 DoS攻击， 提高通信安全性的方法。 发明内容 本发明实施例提供一种用于认证网络上的通信流量的方法、 装置和系 统， 以防止 DOS攻击， 提高通信安全性。 本发明实施例解决上述技术问题的一个实施方式是： 提供一种认证通 信流量的方法， 适用于包括至少一客户端和服务器的场景中， 包括： 接收某一客户端发送的第一传输控制协议 TCP分组； 判断该第一 TCP分组的源地址是否已经验证通过，如果该第一 TCP分 组的源地址已经验证通过， 则转发该第一 TCP分组给所述服务器； 如果该 第一 TCP分组的源地址还没有验证通过，则发送第二 TCP分组给所述第一 TCP分组的发送方， 该第二 TCP分组的部分字段封装有 Cookie , 所述第二 TCP分组不包括 TCP ACK分组； 接收所述第一 TCP分组的发送方发送的第三 TCP分组，判断所述第三 TCP分组的相应字段值是否匹配所述 Cookie, 如果所述第三 TCP分组的相 应字段值不匹配所述 Cookie, 则确定第一 TCP分组的发送方的源地址是伪 造的； 如果所述第三 TCP分组的相应字段值匹配所述 Cookie, 则确定第一 TCP分组的发送方的源地址是真实的； 当所述第一 TCP分组的发送方重新向服务器发起 TCP连接请求时，允 许所述第一 TCP分组的发送方与服务器建立 TCP连接。 本发明实施例提供的一种防护装置， 包括： 获取模块、 第一判断模块、 第二判断模块、 发送模块及转发模块， 其中： 所述获取模块， 用于获取某一客户端发给服务器的第一传输控制协议
TCP分组； 所述第一判断模块， 用于判断所述获取模块获取的第一 TCP分组的源 地址是否已经验证通过， 如果该第一 TCP分组的发送方的源地址已经验证 允许该第一 TCP分组的发送方与服务器建立 TCP连接，则由所述转发模块 转发该第一 TCP分组给服务器， 使该客户端与服务器直接建立 TCP连接； 如果该第一 TCP 分组的源地址还没有验证通过， 则由发送模块发送第二 TCP分組给所述客户端， 该第二 TCP分組的部分字段封装有 Cookie; 所述获取模块， 还用于接收所述客户端发来的第三 TCP分组， 交给第 二判断模块； 所述第二判断模块， 用于确定所述第三 TCP分组的相应字段值是否匹 配所述 Cookie, 如果所述第三 TCP分組的相应字段值匹配所述 Cookie, 则 确定所述客户端的源地址是真实的； 如果所述第三 TCP分组的相应字段值 不匹配所述 Cookie , 则确定所述客户端的源地址是伪造的； 如果所述客户端的源地址是真实的， 当所述获取模块接收到所述客户 端发送的第四 TCP分组时，由转发模块转发该第四 TCP分组给所述服务器。 本发明实施例还提供一种通信系统， 包括服务器、 至少一个客户端以 及位于该服务器和所述至少一个客户端之间的防护装置， 其中： 所述客户端 ,用于向服务器发出第一 TCP分组以与服务建立行 TCP连 接； 所述防护装置， 用于截获所述客户端向所述服务器发出的第一 TCP分 组， 确定所述第一 TCP分组的发送方的源地址是否经过确认， 如果所述第 一 TCP分组的发送方的源地址是否经过确认为真实的，则将该第一 TCP分 组转发给所述服务器； 如果所述第一 TCP分组的发送方的源地址没有经过 确认， 则向所述第一 TCP分组的发送方发出第二 TCP分组， 该第二 TCP 分组的部分字段封装有 Cookie。 如果所述第一 TCP分组的发送方返回的第 三分组的相应字段值匹配所述 Cookie, 则确定所述第一 TCP分组的发送方 的源地址是真实的； 当接收到所述第一 TCP分组的发送方发送的第四 TCP 分组时， 将该第四 TCP分组转发给所述服务器； 所述服务器， 用于接收所述防护装置发来的第四 TCP分组， 响应所述 第一 TCP分组的发送方发来的第四 TCP分组并与所述客户端建立 TCP连 接。 本发明实施例的认证通信流量的方法、 通信系统和防护装置， 在 TCP 分组到达服务器前进行认证， 确认其真实源地址， 进而确认其是否攻击报 文， 确定是否允许其与服务器建立 TCP连接， 可有效防范利用 TCP分組进 行的 DoS攻击。 附图说明 图 1为 RFC793中定义的建立 TCP连接时，通信双方同时发送 SYN报 的处理方法的流程示意图； 图 2为 TCP客户端经防护装置与 TCP服务器通信的通信系统结构示意 图； 图 3为本发明实施例的一种认证通信流量的方法的流程示意图； 图 4为本发明实施例的一种认证通信流量的方法的流程示意图； 图 5为本发明实施例的另一种认证通信流量的方法的流程示意图； 图 6为图 5所示实施例的认证通信流量的方法的流程示意图； 图 7为本发明实施例的另一种认证通信流量的方法的流程示意图； 图 8和 9为本发明实施例的另一种认证通信流量的方法的流程示意图; 图 10为本发明实施例的一种通信系统的结构示意图； 图 11为本发明实施例的一种防护装置的结构示意图； 图 12为本发明实施例的另一种防护装置的结构示意图。 具体实施方式 以下结合具体实施方式来说明本发明的实现过程。 传输控制协议 /因特网协议 ( Transmission Control Protocol /Internet Protocol , TCP/IP )套件是目前在数字分组网络中最广泛使用的传输协议。 TCP是面向连接的端到端全双工协议 ,它提供了主机中的进程对之间的可靠 的进程间通信。 TCP同级设备之间的信息交换被组装成被称为片段 ( segment ) 的数据报， 每个数据报包含一个 TCP头部， 其后是有效载荷数 据。 片段以 IP分组的形式在网络上传输。 Postel在美国国防部高级研究项目 署（ DARPA )的题为《Transmission Control Protocol： DARPA Internet Program Protocol Specification (传输控制协议： DARPA因特网程序协议规范）》 的 RFC793中描述了 TCP(Transmission Control Protocol) , 此处通过引用将 RFC793包含进来。 以下给出的对 TCP的某些特征的描述是基于 RFC793中的 信息， 关于进一步的细节， 请参看相关 RFC。
TCP 片段中发送的每个八位字节被分配序列号 （ Sequence Number ) ， 该序列号被接收计算机用于从分组的损坏、 损失或复制中恢复， 并对按错 误顺序递送的片段重新排序。 在接收到片段时， 接收者应该通过向发送者 返回在 TCP头部中设置了 "ACK"控制比特的分组，来给出肯定确认（ ACK )。 如果发送者在超时间隔内未接收到 ACK, 则其重新发送数据。 由于 TCP是 全双工协议， 因此每个片段的头部包含用于表示序列号和确认号
( Acknowledgment Number )的字段。 序列号字段保存片段中的第一个数据 八位字节的序列号 （或者在 SYN分组的情况下的初始序列号 ISN ( Initial Sequece, ISN ) )。 确认号字段包含片段发送者期望在 TCP连接上接收到的 下一序列号的值。 从而， 通过接收到的最后片段的最高序列号， 确认号被 确定。 为了管理由发送者发送的数据量， 接收者在返回每个 ACK 时还返回
"窗口" ， 指示成功接收到的最后片段之外还可接受的序列号的范围。 为了建立 TCP 连接，两个参与计算机使用公知的 "三次握手（ three - way handshake ) " , 来同步彼此的初始序列号。 握手是基于连接建立片段的交 换， 以及初始序列号的， 其中连接建立片段在其片段头部中包含被称为
"SY " 的控制比特。 每一方还必须接收另一方的初始序列号， 并发送确 认。 为了启动连接， 计算机 Α 向计算机 B发送 SYN分组， 指示其初始序列号
( ISN )。 计算机 B以 SYN- ACK分组响应， 给出其自己的 ISN , 并确认由计 算机 A发送的 ISN (通过设置 ACK比特，并将值 ISN+1放在其确认号字段中）。 计算机 A最终以 ACK分组响应， 确认由计算机 B发送的 ISN, 从而连接被建 立。
TCP 片段头部还包含 "RST" 控制比特， 该控制比特用于有必要重置 未正确同步的 TCP连接时重置未正确同步的 TCP连接。 一般规则是， 只要连 接不处于 "己建立" 状态， 无论何时当明显不想继续当前连接的片段到达 时， RST分组（其中设置了 RST比特）就被发送。 从而， 例如， 如果处于建 立 TCP连接过程中的一台计算机接收到包含未预期的确认号的 ACK分组， 则接收计算机将会向发送计算机返回 RST分组。 本发明的实施例中， 釆用 TCP反向检测方案防范 DoS攻击， 并且本发明 实施例中， 客户端的 TCP状态迁移符合 TCP标准 RFC793中的定义。 RFC793 中定义了建立 TCP连接时， 通信双方同时发送 TCP SY 分组的处理方式。 如图 1所示， TCP A向 TCP B发出第一 SY 分组， 该第一 SYN分组中， SEQ=100 ; TCP B向 TCP A发出第二 SYN分组， 该第二 SYN分组中， SEQ=300; TCP B收到第一 SYN分组后， 向 TCP A回复第一 SYN-ACK分组， 该第一 SYN-ACK分组中 , ACK号为 101 , TCP A至 TCP B的 TCP连接建立； TCP A收到第二 SYN分组后， 向 TCP B回复第二 SYN-ACK分组， 该第二 SYN-ACK分組中， ACK号为 301 , TCP B至 TCP A的 TCP连接建立。 如图 2所示， TCP客户端经防护装置与 TCP服务器通信， 在 TCP客户端 和 TCP服务器端之间使用防护装置进行 TCP反向检测，只有检测通过的客户 端通信数据才被允许发送给 TCP服务器端。防护装置可以设置在路由器或网 间设备或服务器上。 所述网间设备包括但不限于防火墙等中间设备。 这里 的客户端、服务器端指的是 TCP连接意义上的客户端、服务器端， 客户端指 发起 TCP连接的通信端， 服务器端指接收 TCP连接的通信端。 如图 3所示， 为本发明实施例提供的一种认证通信流量的方法， 适用于 包括至少一客户端和服务器的场景中， 该方法包括：
S100、 接收某一客户端发送的第一 TCP分组； 防护装置获取客户端发往服务器的第一 TCP分组，该第一 TCP分组可以 是 TCP SYN分组 , 也可以是 TCP SYN- ACK分组。
S102、 判断该第一 TCP分组的源地址是否已经验证通过， 如果该第一 TCP分组的源地址已经验证通过， 则转发该第一 TCP分组给所述服务器； 如 果该第一 TCP分组的源地址还没有验证通过， 则执行 S 104; 防护装置判断该第一 TCP分组的源地址是否已经验证通过，如果该第一 TCP分组的源地址已经验证通过， 则转发该第一 TCP分组给所述服务器； 如 果该第一 TCP分组的源地址还没有验证通过， 则执行 S 104。 SI 04、 发送第二 TCP分组给所述第一 TCP分组的发送方， 该第二 TCP分 组的部分字段封装有 Cookie, 所述第二 TCP分组不包括 TCP ACK分组； 执 行 S106;
S106、接收所述第一 TCP分组的发送方发送的第三 TCP分组，执行 S108;
S108、判断所述第三 TCP分组的相应字段值是否匹配所述 Cookie, 如果 所述第三 TCP分组的相应字段值不匹配所述 Cookie, 则确定第一 TCP分组的 发送方的源地址是伪造的； 如果所述第三 TCP分组的相应字段值匹配所述 Cookie, 则确定第一 TCP分组的发送方的源地址是真实的， 执行 S110;
S110、 发送 TCP RST报文给所述第一 TCP分组的发送方， 执行 S112;
S112、 允许所述第一 TCP分组的发送方与服务器建立 TCP连接。 当所述第一 TCP分组的发送方重新向服务器发起 TCP连接请求时，允许 所述第一 TCP分组的发送方与服务器建立 TCP连接。 其中 S110为可选步驟， 执行完 S108后， 也可以不执行 S110, 直接转而 执行 S 112, 具体流程图如图 4所示。 优选地， 如果所述第一 TCP分组为第一 TCP SYN分组， 则所述第二 TCP 分组为第二 TCP SYN分组， 所述第二 TCP SYN分组的 SEQ字段封装有 Cookie, 所述第三 TCP分组为 TCP SYN- ACK分组； 所述第三 TCP分组的相 应字段值匹配所述 Cookie , 为第三 TCP分组的 ACK字段值等于 Cookie加 1 , 即 ACK=Cookie+l。 优选地， 如果所述第一 TCP分组为第一 TCP SYN分组， 则所述第二 TCP 分组为第二 TCP SYN- ACK分组， 所述第二 TCP SYN- ACK的 ACK字段封装 有 Cookie, 所述第三 TCP分组为 TCP RST分组； 所述第三 TCP分组的相应字 段值匹配所述 Cookie , 为第三 TCP分组的 SEQ字段值等于 Cookie , 即 SEQ=Cookie„ 优选地， 如果所述第一 TCP分组为第一 TCP SYN-ACK分组， 则所述 第二 TCP分组为第二 TCP SYN-ACK分组 , 所述第二 TCP SYN-ACK分组 的 ACK字段封装有 Cookie, 所述第三 TCP分组为 TCP RST分组； 所述第 三 TCP分组的相应字段值匹配所述 Cookie, 为第三 TCP分组的 SEQ字段 值等于 Cookie, 即 SEQ=Cookie。 优选地， 在收到所述第一 TCP SYN-ACK分组前， 还包括： 服务器向 所述客户端发送第四 TCP SYN分组，要求与客户端建立 TCP连接，所述客 户端收到所述第四 TCP SYN分組后， 发出第一 TCP SYN-ACK分組。 优选地 , 所述源地址为互联网协议 IP地址 , 所述 IP地址包括 IPv4地 址或 IPv6地址。
如图 5所示， 在本发明的一个实施例中， 防护装置截获客户端发送给服 务器端的 TCP握手第一 SYN分组， 并不按照 TCP的三次握手流程回复第一 SYN-ACK分组，而是按照 RFC793中定义的 TCP同时连接的情况向客户端发 送第二 SYN分组 , 并在该第二 SYN分组的 TCP首部中的 SEQ字段值中写入 Cookie, 即第二 SYN分组中， SEQ=Cookie。 按照 RFC793, 拥有真实源地址 的客户端会针对防护装置发送的第二 SY 分组返回第二 SYN-ACK分组， 其 中该第二 SYN-ACK分组的 ACK字段值应该为 Cookie+1 , 即第二 SYN-ACK 分组中 , ACK=Cookie+l。防护装置可以通过检测第二 SYN-ACK分组中 ACK 字段值， 实现对客户端的源地址的真实性检测。 如果第二 SYN-ACK分组中 ACK字段值不等于 Cookie+1 , 则确定第一 SYN分组的源地址是^^的， 防护 装置可以丢弃 TCP报头中源地址为该第一 SYN分组的源地址的后续 TCP分 组； 如果第二 SY -ACK分组中 ACK字段值等于 Cookie+1 , 则确定第一 SYN 分组的源地址为真实的源地址， 防护装置可以向发出该第一 S YN分组的客 户端发送 TCP RST分组以重置连接， 并将该客户端重新发送的第三 SY 分 组直接转发到服务器端， 使得该客户端和服务器端直接建立 TCP连接。 当防护装置位于路由器上， 为服务器端提供针对 DDoS攻击的防护时， 防护装置可作为路由器的一个扩展功能板， 在路由器转发数据分组之前对 数据分组的源地址进行反向检测， 丢弃掉可疑的 DDoS攻击分组。 这样做不 仅能提供对服务器端的保护， 还能有效降低通讯线路上的攻击数据分組流 量。 如图 6所示， 在本发明的一个实施例中， 在客户端和服务器之间设置 防护装置， 一种认证通信流量的方法包括：
S600、 接收第一 TCP SYN分组 当客户端希望与服务器建立 TCP连接进行通信时， 客户端向服务器发 送第一 TCP SY 分组， 位于客户端和服务器之间的防护装置获取客户端发 给服务器的第一 TCP SY 分组。
S602、 判断该第一 TCP SY 分组的源地址是否已经验证通过， 如果该 第一 TCP SYN分组的源地址已经验证通过， 则转发该第一 TCP SY 分组 给服务器； 如果该第一 TCP SYN分组的源地址还没有验证通过， 则执行 S604; 当防护装置截获到某个客户端发来的第一 TCP SY 分组时， 判断该第 一 TCP SYN分组的源地址是否已经验证通过， 如果该第一 TCP SY 分组 的源地址已经验证通过， 则表明该第一 TCP SY 分组的源地址已经确认为 真实合法的源地址， 可以与服务器建立 TCP连接， 则防护装置转发该第一 TCP SY 分组给服务器， 使该客户端与服务器直接建立 TCP连接； 如果该 第一 TCP SYN分组的源地址还没有验证通过， 则执行 S604。
S604、 发送第二 TCP SY 分组给所述第一 TCP SYN分组的发送方， 该第二 TCP SYN分组的 SEQ字段封装有 Cookie, 即该第二 TCP SYN分组 中， SEQ=Cookie。 如果防护装置确认该第一 TCP SYN分组的源地址还没有验证通过， 则 发送第二 TCP SY 分组给所述第一 TCP SY 分组的发送方， 该第二 TCP SYN 分组的 SEQ 字段封装有 Cookie , 即该第二 TCP SYN 分组中， SEQ=Cookie, Cookie值根据第一 TCP SYN分组的发送方的五元组信息通 过哈希算法计算得出， 第一 TCP SYN分組的发送方的五元組信息包括： 第 一 TCP SYN分组的发送方的源 IP地址、 目的 IP地址、 源端口号、 目的端 口号、 TCP/UDP ( User Datagram Protocol )号。 所述第二 TCP SYN分组为 符合 RFC793定义要求的 TCP SYN分组， 表示防护装置要求与该第一 TCP SYN分组的发送方， 即客户端， 建立 TCP连接。 按照 RFC793定义， 正常 情况下， 即当第一 TCP SY 分组的发送方的源地址真实的情况下， 当第一 TCP SY 分组的发送方接收到防护装置发送的第二 TCP SY 分组，要求与 之建立 TCP连接时， 所述第一 TCP SYN分组的发送方将向所述第二 TCP SYN分组的发送方 （即防护装置）发送 SYN-ACK分组， 作为对第二 TCP SYN分组的响应。根据 RFC793的定义， 该 SYN-ACK的 ACK字段值应该 是 Cookie+1 , 即 ACK=Cookie+l。
S606、 接收所述第一 TCP SYN分组的发送方发送的 SYN-ACK分组， 执行 S608。 防护装置接收从所述第一 TCP SYN分组的发送方发送的 SYN-ACK分 组， 执行 S608以确认所述第一 TCP SYN分组的发送方发来的 SYN-ACK 分组是否符合特定要求。
S608、 判断该 SYN-ACK分组的 ACK 号是否匹配 Cookie, 如果该 SY -ACK分组的 ACK字段值匹配 Cookie, 则转 S610; 如果该 SYN-ACK 分组的 ACK字段值不匹配 Cookie , 则确定发出第一 TCP SYN分组的发送 方的源地址是伪造的。 防护装置接收到第一 TCP SYN分组的发送方 (即某个客户端）发送的 SYN-ACK分组后，判断该 SYN-ACK分组的 ACK字段值是否匹配 Cookie, 即确定该 SYN-ACK 分组的 ACK 字段值是否等于 Cookie+1 , 如果该 SYN-ACK分组的 ACK字段值等于 Cookie+1 , 则表明第一 TCP SYN分组 的发送方的源地址是真实的，执行 S610; 如果该 SYN-ACK分組的 ACK字 段值不等于 Cookie+1 ,则表明第一 TCP SY 分组的发送方的源地址是伪造 的。
S610、 发送 TCP RST分组给所述第一 TCP SYN分组的发送方 当确定第一 TCP SYN分组的发送方的源地址真实时， 防护装置发送 TCP RST分组给所述第一 TCP SY 分组的发送方， 重置该第一 TCP SYN 分组的发送方要求建立的 TCP连接。
S612、 允许所述第一 TCP SY 分组的发送方与服务器建立 TCP连接 所述第一 TCP SYN分组的发送方收到防护装置发送到 TCP RST分组 后， 向服务器发送第三 TCP SYN分组，要求与服务器建立 TCP连接。 防护 装置获取所述第三 TCP SY 分组后， 确认该第三 TCP SYN分组的源地址 已经验证通过， 是真实的源地址， 则将客户端重新发送的第三 TCP SYN分 组直接转发到服务器， 使得客户端和服务器建立 TCP连接。 如图 7所示， 本发明的另一种实施例中， 在客户端和服务器之间设置 防护装置， 该方法包括：
S700、 接收第一 TCP SYN分组 当客户端希望与服务器建立 TCP连接进行通信时， 客户端向服务器发 送第一 TCP SY 分组 , 位于客户端和服务器之间的防护装置获取客户端发 给服务器的第一 TCP SYN分组。
S702、 判断该第一 TCP SY 分组的源地址是否已经验证通过， 如果该 第一 TCP SYN分组的源地址已经验证通过， 则转发该第一 TCP SYN分组 给服务器； 如果该第一 TCP SYN分组的源地址还没有验证通过， 则执行 S704。 当防护装置截获到某个客户端发来的第一 TCP SYN分组时， 判断该第 一 TCP SYN分组的源地址是否已经验证通过， 如果该第一 TCP SYN分组 的源地址已经验证通过， 则表明该第一 TCP SYN分组的源地址已经确认为 真实合法的源地址， 可以与服务器建立 TCP连接， 则防护装置转发该第一 TCP SY 分组给服务器， 使该客户端与服务器直接建立 TCP连接； 如果该 第一 TCP SY 分组的源地址还没有验证通过， 则执行 S704。
S704、 发送 SY -ACK分组给所述第一 TCP SYN分组的发送方， 该 SY -ACK分组的 ACK字段封装有 Cookie, 即， 该 SYN-ACK分组中， ACK=Cookie; 执行 S706。 如果防护装置确认该第一 TCP SYN分组的源地址还没有验证通过， 则 发送 SYN-ACK分组给所述第一 TCP SYN分组的发送方， 该 SYN-ACK分 组的 ACK字段封装有 Cookie, 即， 该 SYN-ACK分组中， ACK=Cookie; 该 Cookie值不等于第一 TCP SYN分组的 SEQ字段值加 1 , Cookie值根据 第一 TCP SYN分组的发送方的五元组信息通过哈希算法计算得出， 第一 TCP SYN分组的发送方的五元组信息包括：第一 TCP SYN分组的发送方的 源 IP地址、 目的 IP地址、 源端口号、 目的端口号、 TCP/UDP号。 正常情 况下， 即当第一 TCP SYN分组的发送方的源地址真实的情况下， 当第一 TCP SY 分组的发送方接收到防护装置发送的 SY -ACK 分组， 该 SY -ACK分組的 ACK字段值应该等于第一 TCP SY 分組的 SEQ字段值 加 1 , 然而， 由于防护装置向该第一 TCP SYN分组的发送方发送到所述 SYN-ACK分组的 ACK值不等于第一 TCP SYN分组的 SEQ字段值加 1 , 而是等于 Cookie, 该第一 TCP SYN分组的发送方将会发送 TCP RST分组 以重置 TCP连接。 当该第一 TCP SYN分组的发送方的源地址真实时， 该 TCP RST分组的 SEQ字段值应该等于 Cookie。
S706、 接收所述第一 TCP SYN分组的发送方发送的 RST分组， 执行 S708。 防护装置接收从所述第一 TCP SY 分组的发送方发送的 TCP RST分 组， 执行 S708以确认所述第一 TCP SYN分组的发送方发来的 TCP RST分 组是否符合特定要求。
S708、 判断所述 TCP RST分组的 SEQ值是否匹配所述 Cookie, 如果 所述 TCP RST分组的 SEQ字段值不匹配所述 Cookie,则确定第一 TCP SYN 分组的发送方的源地址是伪造的；如果所述 TCP RST分组的 SEQ字段值匹 配所述 Cookie, 则确定第一 TCP SYN分组的发送方的源地址是真实的， 执 行 S710。 防护装置接收到第一 TCP SYN分组的发送方发送的 TCP RST分组后， 判断该 TCP RST分组的 SEQ值是否匹配 Cookie , 即确定该 TCP RST分组 的 SEQ字段值是否等于 Cookie, 如果该 TCP RST分组的 SEQ字段值等于 Cookie,则表明第一 TCP SYN分组的发送方的源地址是真实的 ,执行 S710; 如果该 TCP RST分组的 SEQ字段值不等于 Cookie, 则表明第一 TCP SYN 分组的发送方的源地址是伪造的。
S710、 当所述第一 TCP SYN分组的发送方重新向服务器发起 TCP连 接请求时， 防护装置允许所述第一 TCP SYN分组的发送方与服务器建立 TCP连接。 所述第一 TCP SY 分组的发送方向服务器发送第二 TCP SYN分组， 要求与服务器建立 TCP连接。 防护装置截获所述第二 TCP SYN分组后，确 认该第二 TCP SYN分组的源地址已经验证通过 , 是真实的源地址 , 则将客 户端重新发送的第二 TCP SY 分組直接转发到服务器， 使得客户端和服务 器建立 TCP连接。
如图 8所示， 在本发明的一个实施例中， 在客户端和服务器之间设置 防护装置， 在一种场景中， 服务器向某一客户端发起 TCP连接请求， 即服 务器向某一客户端发送第一 TCP SY 分组， 假设该 TCP SY 分组的 SEQ=S, 其中， S为任意值； 如果该 TCP客户端不是攻击源， 即， 该 TCP 客户端的源地址是真实的， 那么， 根据 RFC793, 该 TCP客户端将针对服 务器发送的第一 TCP SYN 分组， 回复第一 SY -ACK 分组， 该第一 SY -ACK分组中 SEQ=S，， ACK=S+1 , S，为任意值。 当然， 该第一 SYN-ACK分组也可能是攻击者发出的 DoS攻击报文。 客户端向服务器发送的第一 SYN-ACK分组在到达服务器前被防护装 置获取。 由于防护装置并不获取从服务器发往客户端的分组， 而是仅仅获 取从客户端发往服务器的分组， 因此， 当防护装置获取客户端向服务器发 送的第一 SYN-ACK分组时，防护装置需确认该第一 SYN-ACK分组的源地 址是否真实， 如图 9所示， 为本发明实施例的另一种认证通信流量的方法 的流程示意图， 该方法包括：
S900、 接收第一 SYN-ACK分组 防护装置获取客户端发送到第一 SYN-ACK分组。
S902、 判断该第一 SYN-ACK分组的源地址是否已经验证通过， 如果 该第一 SYN-ACK分组的源地址已经验证通过， 则转发该第一 SYN-ACK 分组给服务器； 如果该第一 SYN-ACK分组的源地址还没有验证通过， 则 执行 S904。 当防护装置截获到某个客户端发来的第一 SYN-ACK分组时， 判断该 第一 SYN-ACK分组的源地址是否已经验证通过， 如果该第一 SYN-ACK 分组的源地址已经验证通过， 则表明该第一 SYN-ACK分组的源地址已经 确认为真实合法的源地址， 可以与服务器建立 TCP连接， 则防护装置转发 该第一 SYN-ACK分组给服务器，使该客户端与服务器直接建立 TCP连接； 如果该第一 SYN-ACK分组的源地址还没有验证通过， 则执行 S904。
S904、 发送第二 SYN-ACK分组给所述第一 SYN-ACK分组的发送方， 该第二 SYN-ACK分组的 ACK字段封装有 Cookie, 即， 该第二 SYN-ACK 分组中， ACK=Cookie; 执行 S906。 如果防护装置确认该第一 SYN-ACK分组的源地址还没有验证通过， 则发送第二 SYN-ACK分组给所述第一 SYN-ACK分组的发送方， 该第二 SYN-ACK分组的 ACK字段封装有 Cookie , 即该第二 SYN-ACK分组中 , ACK=Cookie; SEQ=S+1 , 当然 SEQ也可以是其他任意值。， Cookie值才艮据 第一 TCP SYN 分组的发送方的五元组信息通过哈希算法计算得出， 第一 TCP SY 分组的发送方的五元组信息包括：第一 TCP SY 分组的发送方的 源 IP地址、 目的 IP地址、 源端口号、 目的端口号、 TCP/UDP号 正常情况下， 即当第一 SYN-ACK分组的发送方的源地址真实的情况 下， 第一 SYN-ACK分组的发送方会接收到对方 （比如服务器）发送的第 一 ACK分组，该第二 ACK分组的 ACK字段值应该等于第一 SYN-ACK分 组的 SEQ字段值加 1 , 然而， 由于防护装置向该第一 SYN-ACK分组的发 送方发送了第二 SYN-ACK分组， 该第二 SYN-ACK分组的 ACK值不等于 第一 SYN-ACK分組的 SEQ 值加 1 , 而是等于 Cookie, 因此， 该第一 SYN-ACK分组的发送方将会发送 TCP RST分组以重置 TCP连接。 当该第 一 SYN-ACK分组的发送方的源地址真实时，该 TCP RST分组的 SEQ字段 值应该等于 Cookie。
S906、 接收所述第一 SYN-ACK分组的发送方发送的 RST分组， 执行 S908。 防护装置接收从所述第一 SYN-ACK分组的发送方发送的 TCP RST分 组， 执行 S908以确认所述第一 SYN-ACK分组的发送方发来的 TCP RST 分组是否符合特定要求。
S908、 判断所述 TCP RST分组的 SEQ字段值是否匹配所述 Cookie, 如果所述 TCP RST分组的 SEQ 字段值不匹配所述 Cookie, 则确定第一 SYN-ACK分组的发送方的源地址是伪造的；如果所述 TCP RST分组的 SEQ 字段值匹配所述 Cookie, 则确定第一 SYN-ACK分组的发送方的源地址是 真实的， 执行 S910。 防护装置接收到第一 SYN-ACK分组的发送方发送的 TCP RST分组后 , 判断该 TCP RST分组的 SEQ字段值是否匹配 Cookie, 即确定该 TCP RST 分组的 SEQ字段值是否等于 Cookie, 如果该 TCP RST分组的 SEQ字段值 等于 Cookie, 则表明第一 SY -ACK分组的发送方的源地址是真实的， 执 行 S310; 如果该 TCP RST分组的 SEQ字段值不等于 Cookie, 则表明第一 SY -ACK分组的发送方的源地址是伪造的。
S910、 当所述第一 SYN-ACK分组的发送方重新向服务器发出 TCP分 组时， 防护装置允许所述第一 SYN-ACK分组的发送方与服务器建立 TCP 连接。 所述第一 SYN-ACK分组的发送方向服务器发送第三 SYN-ACK分组， 要求与服务器建立 TCP 连接。 该第三 SYN-ACK 分组中， SEQ=S，， ACK=S+1。 防护装置截获所述第三 SYN-ACK 分组后， 确认该第三 SYN-ACK分組的源地址已经验证通过， 是真实的源地址， 则将客户端重新 发送的第三 SYN-ACK分组直接转发到服务器， 使得客户端和服务器建立 TCP连接。
本发明实施例还提供一种通信系统， 如图 10所示， 该通信系统包括月良 务器、 至少一个客户端以及位于该服务器和所述至少一个客户端之间的防 护装置， 其中： 所述客户端 ,用于向服务器发出第一 TCP分组以与服务器建立 TCP连 接； 所述防护装置， 用于截获所述客户端向所述服务器发出的第一 TCP分 组， 确定所述第一 TCP分组的发送方的源地址是否经过确认， 如果所述第 组转发给所述服务器； 如果所述第一 TCP分组的发送方的源地址没有经过 确认， 则向所述第一 TCP分组的发送方发出第二 TCP分组， 该第二 TCP 分组的部分字段封装有 Cookie。 如果所述第一 TCP分组的发送方返回的第 三分组的相应字段值匹配所述 Cookie, 则确定所述第一 TCP分组的发送方 的源地址是真实的； 当接收到所述第一 TCP分组的发送方发送的第四 TCP 分组时， 将该第四 TCP分组转发给所述服务器； 所述服务器， 用于接收所述防护装置发来的第四 TCP分组， 响应所述 第一 TCP分组的发送方发来的第四 TCP分组并与所述客户端建立 TCP连 接。 具体地， 所述防护装置的结构如图 11所示， 包括获取模块 1101、 第一 判断模块 1102、 第二判断模块 1103、 发送模块 1104、 重置模块 1106及转 发模块 1107, 其中： 所述获取模块 1101 , 用于获取某一个客户端发给服务器的第一 TCP分 组； 所述第一判断模块 1102,用于判断所述获取模块 1101获取的第一 TCP 分组的源地址是否已经验证通过， 如果该第一 TCP分组的源地址已经验证 通过， 则表明该第一 TCP分组的源地址已经确认为真实的源地址， 则由所 述转发模块 1107转发该第一 TCP分组给服务器，使该客户端与服务器直接 建立 TCP连接； 如果该第一 TCP分组的源地址还没有验证通过， 则由发送 模块 1104发送第二 TCP分组给所述客户端， 该第二 TCP分组的部分字段 封装有 Cookie。 按照 RFC793定义， 如果该客户端的源地址是真实的， 当 该客户端接收到发送模块 1104发送的第二 TCP分组，所述客户端将向所述 第二 TCP分组的发送方 （即防护装置）发送第三 TCP分组， 作为对第二 TCP分组的响应。 根据 RFC793的定义， 该第三 TCP分组的相应字段值应 该匹配所述 Cookie。 所述获取模块 1101 , 还用于接收所述客户端发来的第三 TCP分组， 并 交给第二判断模块 1 103; 第二判断模块 1103, 用于确定第三 TCP分组的相应字段值是否匹配所 述 Cookie, 如果第三 TCP分组的相应字段值匹配所述 Cookie, 则表明所述 客户端的源地址是真实的； 如果第三 TCP 分组的相应字段值不匹配所述 Cookie, 则表明所述客户端的源地址是伪造的。 如果所述客户端的源地址是真实的， 则重置模块 1106向所述客户端发 送 TCP RST分组以重置该客户端要求建立的 TCP连接。 当获取模块 1101接收到所述客户端发送的第四 TCP分组时，由转发模 块 1107转发该第四 TCP分组给服务器， 使得客户端和服务器建立 TCP连 接。 在该实施例中， 重置模块 1106并非必需， 防护装置中也可以省略该重 置模块 1106, 省略重置模块 1106的实施例如图 12所示， 在省略重置模块 1106时，发出第一 TCP分组的客户端的源地址如果真实，在 TCP连接超时 时，会再次发送第四 TCP分组， 当获取模块 1101接收到所述客户端发送的 第四 TCP分组时， 由转发模块 1107转发该第四 TCP分组给服务器， 使得 客户端和服务器建立 TCP连接。 在上述通信系统和防护装置中， 优选地， 如果所述第一 TCP分组为第一 TCP SYN分组， 则所述第二 TCP 分组为第二 TCP SYN分组， 所述第二 TCP SYN分组的 SEQ字段封装有 Cookie, 所述第三 TCP分组为 TCP SYN-ACK分组； 所述第三 TCP分组的相 应字段值匹配所述 Cookie , 为第三 TCP分组的 ACK字段值等于 Cookie加 1 , 即 ACK=Cookie+l。 优选地， 如果所述第一 TCP分组为第一 TCP SYN分组， 则所述第二 TCP 分组为第二 TCP SYN-ACK分组， 所述第二 TCP SYN-ACK的 ACK字段封装 有 Cookie, 所述第三 TCP分组为 TCP RST分组； 所述第三 TCP分组的相应字 段值匹配所述 Cookie , 为第三 TCP分组的 SEQ字段值等于 Cookie , 即 SEQ=Cookie„ 此时并不需要重置模块 1106, 即并不需要防护装置发送 TCP RST分组来重置 TCP连接， 而是由第一 TCP分组的发送方发送到 TCP RST分 組重置 TCP连接。 优选地， 如果所述第一 TCP分组为第一 TCP SYN-ACK分组， 则所述 第二 TCP分組为第二 TCP SYN-ACK分組，所述第二 TCP SYN-ACK的 ACK 字段封装有 Cookie, 所述第三 TCP分组为 TCP RST分组； 所述第三 TCP 分组的相应字段值匹配所述 Cookie, 为第三 TCP分组的 SEQ字段值等于 Cookie, 即 SEQ=Cookie。 此时并不需要重置模块 1106, 即并不需要防护装 置发送 TCP RST分组来重置 TCP连接， 而是由第一 TCP分组的发送方发 送到 TCP RST分组重置 TCP连接。 优选地， 在收到所述第一 TCP SYN-ACK分组前， 还包括： 服务器向 所述客户端发送第四 TCP SY 分组，要求与客户端建立 TCP连接，所述客 户端收到所述第四 TCP SYN分组后， 发出第一 TCP SYN-ACK分组。 优选地， 所述源地址为互联网协议 IP地址， 所述 IP地址包括 IPv4地 址或 IPv6地址。 本发明的以上实施例中 , 所述的源地址为 IP地址 , 可以是 IPv4地址或 IPv6地址。 本发明实施例的认证通信流量的方法、 通信系统和防护装置， 在 TCP 分组到达服务器前进行认证， 确认其真实源地址， 进而确认其是否攻击报 文， 确定是否允许其与服务器建立 TCP连接， 可有效防范利用 TCP分组进 行的 DoS攻击， 提高通信安全性。 通过以上的实施方式的描述， 所属领域的技术人员可以清楚地了解到 本发明可借助软件加必需的通用硬件平台的方式来实现， 当然也可以通过 硬件， 但很多情况下前者是更佳的实施方式。 基于这样的理解， 本发明的 体现出来， 该计算机软件产品存储在一个存储介质中， 包括若千指令用以 使得一台计算机设备（可以是个人计算机， 服务器， 或者网络设备等）执 行本发明各个实施例所述的方法。 以上所述， 仅为本发明较佳的具体实施方式， 但本发明的保护范围并 不局限于此 , 任何熟悉本技术领域的技术人员在本发明揭露的技术范围和 不脱离本发明的技术思想范围内， 可轻易想到的变化或替换， 都应涵盖在 本发明的保护范围之内。 因此， 本发明的保护范围应该以权利要求的保护 范围为准。

Claims

权利要求
1. 一种认证通信流量的方法， 适用于包括至少一客户端和服务器的场 景中， 其特征在于， 包括：
接收某一客户端发送的第一 TCP分组；
判断该第一传输控制协议 TCP分組的源地址是否已经验证通过， 如 果该第一 TCP分组的源地址已经验证通过， 则转发该第一 TCP分组给 所述服务器； 如果该第一 TCP分组的源地址还没有验证通过，则发送第 二 TCP分组给所述第一 TCP分组的发送方， 该第二 TCP分组的部分字 段封装有 Cookie, 所述第二 TCP分组不包括 TCP ACK分组；
接收所述第一 TCP分组的发送方发送的第三 TCP分组，判断所述第 三 TCP分组的相应字段值是否匹配所述 Cookie, 如果所述第三 TCP分 组的相应字段值不匹配所述 Cookie, 则确定第一 TCP分组的发送方的 源地址是伪造的； 如果所述第三 TCP 分组的相应字段值匹配所述 Cookie, 则确定第一 TCP分组的发送方的源地址是真实的；
当所述第一 TCP分组的发送方重新向服务器发起 TCP连接请求时， 允许所述第一 TCP分组的发送方与服务器建立 TCP连接。
2. 如权利要求 1所述的方法， 其特征在于， 如果所述第一 TCP分组为 第一 TCP SY 分组， 则所述第二 TCP分组为第二 TCP SYN分组， 所述第 二 TCP SY 分组的 SEQ字段封装有 Cookie, 所述第三 TCP分组为 TCP SYN-ACK分组；
所述第三 TCP分组的相应字段值匹配所述 Cookie,为第三 TCP分组的 ACK字段值等于 Cookie加 1。
3. 如权利要求 1所述的方法， 其特征在于， 如果所述第一 TCP分组为 第一 TCP SYN分组，则所述第二 TCP分组为第二 TCP SYN-ACK分组，所 述第二 TCP SYN-ACK分组的 ACK字段封装有 Cookie, 所述第三 TCP分 组为 TCP RST分组；
所述第三 TCP分组的相应字段值匹配所述 Cookie,为第三 TCP分组的 SEQ字段值等于 Cookie。
4. 如权利要求 1所述的方法， 其特征在于， 如果所述第一 TCP分组为 第一 TCP SYN-ACK分组， 则所述第二 TCP分组为第二 TCP SYN-ACK分 組， 所述第二 TCP SYN-ACK的 ACK字段封装有 Cookie, 所述第三 TCP 分组为 TCP RST分组；
所述第三 TCP分组的相应字段值匹配所述 Cookie,为第三 TCP分组的 SEQ字段值等于 Cookie。
5. 如权利要求 4 所述的方法， 其特征在于， 在收到所述第一 TCP SYN-ACK分组前， 还包括：
服务器向所述客户端发送第四 TCP SYN分组，要求与客户端建立 TCP 连接 ,所述客户端收到所述第四 TCP SYN分组后，发出第一 TCP SYN-ACK 分组。
6. 如权利要求 1-5 中任一所述的方法， 其特征在于， 所述源地址为互 联网协议 IP地址。
7. 一种防护装置， 其特征在于， 包括： 获取模块、 第一判断模块、 第 二判断模块、 发送模块转发模块， 其中：
所述获取模块， 用于获取某一客户端发给服务器的第一 TCP分组； 所述第一判断模块， 用于判断所述获取模块获取的第一 TCP分组的源 地址是否已经验证通过， 如果该第一 TCP分组的发送方的源地址已经验证 通过，则表明该第一 TCP分组的发送方的源地址已经确认为真实的源地址 , 允许该第一 TCP分组的发送方与服务器建立 TCP连接，则由所述转发模块 转发该第一 TCP分组给服务器， 使该客户端与服务器直接建立 TCP连接； 如果该第一 TCP 分组的源地址还没有验证通过， 则由发送模块发送第二 TCP分组给所述客户端， 该第二 TCP分组的部分字段封装有 Cookie; 所述获取模块， 还用于接收所述客户端发来的第三 TCP分组， 交给第 二判断模块；
所述第二判断模块， 用于确定所述第三 TCP分组的相应字段值是否匹 配所述 Cookie, 如果所述第三 TCP分组的相应字段值匹配所述 Cookie, 则 确定所述客户端的源地址是真实的； 如果所述第三 TCP分组的相应字段值 不匹配所述 Cookie , 则确定所述客户端的源地址是伪造的；
如果所述客户端的源地址是真实的， 当所述获取模块接收到所述客户 端发送的第四 TCP分组时，由转发模块转发该第四 TCP分组给所述服务器。
8. 如权利要求 7所述的方法， 其特征在于， 如果所述第一 TCP分组为 第一 TCP SY 分组， 则所述第二 TCP分组为第二 TCP SYN分组， 所述第 二 TCP SY 分组的 SEQ字段封装有 Cookie, 所述第三 TCP分组为 TCP SYN-ACK分组；
所述第三 TCP分组的相应字段值匹配所述 Cookie,为第三 TCP分组的 ACK字段值等于 Cookie加 1。
9. 如权利要求 7所述的方法， 其特征在于， 如果所述第一 TCP分组为 第一 TCP SYN分组 ,则所述第二 TCP分组为第二 TCP SYN-ACK分组 ,所 述第二 TCP SYN-ACK的 ACK字段封装有 Cookie, 所述第三 TCP分组为 TCP RST分组；
所述第三 TCP分组的相应字段值匹配所述 Cookie,为第三 TCP分组的 SEQ字段值等于 Cookie。
10. 如权利要求 7所述的方法， 其特征在于， 如果所述第一 TCP分组 为第一 TCP SYN-ACK分组， 则所述第二 TCP分组为第二 TCP SYN-ACK 分组，所述第二 TCP SYN-ACK的 ACK字段封装有 Cookie, 所述第三 TCP 分组为 TCP RST分组；
所述第三 TCP分组的相应字段值匹配所述 Cookie,为第三 TCP分组的 SEQ字段值等于 Cookie。
11. 如权利要求 7所述的防护装置， 其特征在于， 所述防护装置设置在 路由设备或防火墙或服务器中。
12.一种通信系统， 其特征在于， 包括服务器、 至少一个客户端以及位 于该服务器和所述至少一个客户端之间的防护装置， 其中， 所述防护装置 为权利要求 7-11中任一所述的防护装置。
13.一种通信系统， 其特征在于， 包括服务器、 至少一个客户端以及位 于该服务器和所述至少一个客户端之间的防护装置， 其中：
所述客户端， 用于向服务器发出第一传输控制协议 TCP分组以与服务 器建立 TCP连接；
所述防护装置， 用于截获所述客户端向所述服务器发出的第一 TCP分 组， 确定所述第一 TCP分组的发送方的源地址是否经过确认， 如果所述第 组转发给所述服务器； 如果所述第一 TCP分组的发送方的源地址没有经过 确认， 则向所述第一 TCP分组的发送方发出第二 TCP分组， 该第二 TCP 分组的部分字段封装有 Cookie. 如果所述第一 TCP分组的发送方返回的第 三分组的相应字段值匹配所述 Cookie, 则确定所述第一 TCP分组的发送方 的源地址是真实的； 当接收到所述第一 TCP分组的发送方发送的第四 TCP 分组时 , 将该第四 TCP分组转发给所述服务器；
所述服务器，用于接收所述防护装置发来的第四 TCP分组，响应所述第 一 TCP分组的发送方发来的第四 TCP分组并与所述客户端建立 TCP连接。
PCT/CN2010/075751 2009-09-08 2010-08-06 认证通信流量的方法、通信系统和防护装置 WO2011029357A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP10814959A EP2464079A1 (en) 2009-09-08 2010-08-06 Method for authenticating communication traffic, communication system and protection apparatus
US13/411,178 US20120227088A1 (en) 2009-09-08 2012-03-02 Method for authenticating communication traffic, communication system and protective apparatus

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200910190037.4 2009-09-08
CN2009101900374A CN102014110A (zh) 2009-09-08 2009-09-08 认证通信流量的方法、通信系统和防护装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/411,178 Continuation US20120227088A1 (en) 2009-09-08 2012-03-02 Method for authenticating communication traffic, communication system and protective apparatus

Publications (1)

Publication Number Publication Date
WO2011029357A1 true WO2011029357A1 (zh) 2011-03-17

Family

ID=43731991

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2010/075751 WO2011029357A1 (zh) 2009-09-08 2010-08-06 认证通信流量的方法、通信系统和防护装置

Country Status (4)

Country Link
US (1) US20120227088A1 (zh)
EP (1) EP2464079A1 (zh)
CN (1) CN102014110A (zh)
WO (1) WO2011029357A1 (zh)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8595477B1 (en) * 2011-03-24 2013-11-26 Google Inc. Systems and methods for reducing handshake delay in streaming protocol web requests
CN102231748B (zh) * 2011-08-02 2014-12-24 杭州迪普科技有限公司 一种客户端验证方法及装置
US9027129B1 (en) * 2012-04-30 2015-05-05 Brocade Communications Systems, Inc. Techniques for protecting against denial of service attacks
US10009445B2 (en) * 2012-06-14 2018-06-26 Qualcomm Incorporated Avoiding unwanted TCP retransmissions using optimistic window adjustments
CN102857515B (zh) * 2012-09-21 2015-06-17 北京神州绿盟信息安全科技股份有限公司 一种访问网络的控制方法及装置
CN102946387B (zh) * 2012-11-01 2016-12-21 惠州Tcl移动通信有限公司 一种防御拒接服务攻击的方法
US9288227B2 (en) 2012-11-28 2016-03-15 Verisign, Inc. Systems and methods for transparently monitoring network traffic for denial of service attacks
US10027761B2 (en) * 2013-05-03 2018-07-17 A10 Networks, Inc. Facilitating a secure 3 party network session by a network device
KR20170074328A (ko) * 2015-12-22 2017-06-30 주식회사 마크애니 티씨피 동기 패킷을 이용한 인증 시스템 및 방법 및 클라이언트 및 기록매체
US10432650B2 (en) 2016-03-31 2019-10-01 Stuart Staniford System and method to protect a webserver against application exploits and attacks
US10158666B2 (en) * 2016-07-26 2018-12-18 A10 Networks, Inc. Mitigating TCP SYN DDoS attacks using TCP reset
CN110120854B (zh) * 2018-02-07 2021-08-31 华为技术有限公司 传输数据的方法和装置
WO2020111456A1 (ko) * 2018-11-26 2020-06-04 숭실대학교산학협력단 Sdn 네트워크의 tcp 세션 생성 방법 및 그 방법이 적용된 sdn 네트워크
CN109688136B (zh) * 2018-12-27 2021-08-13 深信服科技股份有限公司 一种伪造ip攻击行为的检测方法、系统及相关组件
US20210119930A1 (en) * 2019-10-31 2021-04-22 Intel Corporation Reliable transport architecture
KR102495369B1 (ko) * 2022-04-25 2023-02-06 프라이빗테크놀로지 주식회사 컨트롤러 기반 네트워크 접속을 제어하기 위한 시스템 및 그에 관한 방법

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1716868A (zh) * 2004-06-29 2006-01-04 华为技术有限公司 一种抵御拒绝服务攻击的方法
WO2006077659A1 (ja) * 2005-01-20 2006-07-27 Mitsubishi Denki Kabushiki Kaisha ネットワーク伝送装置
CN101047697A (zh) * 2006-03-29 2007-10-03 华为技术有限公司 针对web服务器进行DDOS攻击的防御方法和设备
CN101170402A (zh) * 2007-11-08 2008-04-30 华为技术有限公司 一种采用网流技术防御tcp攻击的方法和系统

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7584352B2 (en) * 2002-12-04 2009-09-01 International Business Machines Corporation Protection against denial of service attacks
US7979694B2 (en) * 2003-03-03 2011-07-12 Cisco Technology, Inc. Using TCP to authenticate IP source addresses
US20050240989A1 (en) * 2004-04-23 2005-10-27 Seoul National University Industry Foundation Method of sharing state between stateful inspection firewalls on mep network
US7568224B1 (en) * 2004-12-06 2009-07-28 Cisco Technology, Inc. Authentication of SIP and RTP traffic
US7613193B2 (en) * 2005-02-04 2009-11-03 Nokia Corporation Apparatus, method and computer program product to reduce TCP flooding attacks while conserving wireless network bandwidth
US7675854B2 (en) * 2006-02-21 2010-03-09 A10 Networks, Inc. System and method for an adaptive TCP SYN cookie with time validation
US7921282B1 (en) * 2007-08-20 2011-04-05 F5 Networks, Inc. Using SYN-ACK cookies within a TCP/IP protocol

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1716868A (zh) * 2004-06-29 2006-01-04 华为技术有限公司 一种抵御拒绝服务攻击的方法
WO2006077659A1 (ja) * 2005-01-20 2006-07-27 Mitsubishi Denki Kabushiki Kaisha ネットワーク伝送装置
CN101047697A (zh) * 2006-03-29 2007-10-03 华为技术有限公司 针对web服务器进行DDOS攻击的防御方法和设备
CN101170402A (zh) * 2007-11-08 2008-04-30 华为技术有限公司 一种采用网流技术防御tcp攻击的方法和系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2464079A4 *

Also Published As

Publication number Publication date
EP2464079A4 (en) 2012-06-13
US20120227088A1 (en) 2012-09-06
CN102014110A (zh) 2011-04-13
EP2464079A1 (en) 2012-06-13

Similar Documents

Publication Publication Date Title
WO2011029357A1 (zh) 认证通信流量的方法、通信系统和防护装置
US9438592B1 (en) System and method for providing unified transport and security protocols
Touch Defending TCP against spoofing attacks
US8499146B2 (en) Method and device for preventing network attacks
AU2004217318B2 (en) Using TCP to authenticate IP source addresses
EP1751910B1 (en) Preventing network reset denial of service attacks using embedded authentication information
US7568224B1 (en) Authentication of SIP and RTP traffic
US6779033B1 (en) System and method for transacting a validated application session in a networked computing environment
WO2010048838A1 (zh) 网络认证方法、客户端请求认证的方法、客户端和装置
Pandey Prevention of ARP spoofing: A probe packet based technique
JP2009525708A (ja) プロトコルリンクレイヤ
Thornburgh Adobe's Secure Real-Time Media Flow Protocol
WO2010000171A1 (zh) 一种通信的建立方法、系统和装置
Simpson TCP cookie transactions (TCPCT)
Feng et al. PMTUD is not Panacea: Revisiting IP Fragmentation Attacks against TCP.
Cao et al. 0-rtt attack and defense of quic protocol
Dulik Network attack using TCP protocol for performing DoS and DDoS attacks
Biagioni Preventing udp flooding amplification attacks with weak authentication
US7860977B2 (en) Data communication system and method
Noureldien et al. Block Spoofed Packets at Source (BSPS): a method for detecting and preventing all types of spoofed source IP packets and SYN Flooding packets at source: a theoretical framework
Yang Introduction to TCP/IP network attacks
Sairam et al. Defeating reflector based denial-of-service attacks using single packet filters
Chu et al. The security research of SIP-based Denial of Service attack
Feng et al. A Reliable Lightweight Communication Method via Chain Verification
Simpson RFC 6013: TCP Cookie Transactions (TCPCT)

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10814959

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2010814959

Country of ref document: EP