Details
SYN cookies are a technique to prevent SYN flooding attack. It was originated from D. J. Bernstein and Eric Schenk, and it is now a standard part of Linux kernel. However, the implementation in Linux is now aimed to protect only the box. The IP SCFW tries to create a firewall feature in Linux that provides SYN cookies protection for the entire internal network. You can use this firewall to interdict half-open TCP connection, so the protected server will not enter half-open state (TCP_SYN_RECV). When the connection is fully established, the firewall relays the connection between the client and the server.
What is SYN flooding attack? (Quoted from CERT's alert)
When a system (called the client) attempts to establish a TCP connection to a system providing a service (the server), the client and server exchange a set sequence of messages. This connection technique applies to all TCP connections-telnet, Web, email, etc.
The client system begins by sending a SYN message to the server. The server then acknowledges the SYN message by sending SYN-ACK message to the client. The client then finishes establishing the connection by responding with an ACK message. The connection between the client and the server is then open, and the service-specific data can be exchanged between the client and the server. Here is a view of this message flow:
Client Server
------ ------
SYN-------------------->
<--------------------SYN-ACK
ACK-------------------->
Client and server can now
send service-specific data
The potential for abuse arises at the point where the server system has sent an acknowledgment (SYN-ACK) back to client but has not yet received the ACK message. This is what we mean by half-open connection. The server has built in its system memory a data structure describing all pending connections. This data structure is of finite size, and it can be made to overflow by intentionally creating too many partially open connections.
Creating half-open connections is easily accomplished with IP spoofing. The attacking system sends SYN messages to the victim server system; these appear to be legitimate but in fact reference a client system that is unable to respond to the SYN-ACK messages. This means that the final ACK message will never be sent to the victim server system.
The half-open connections data structure on the victim server system will eventually fill; then the system will be unable to accept any new incoming connections until the table is emptied out. Normally there is a timeout associated with a pending connection, so the half-open connections will eventually expire and the victim server system will recover. However, the attacking system can simply continue sending IP-spoofed packets requesting new connections faster than the victim system can expire the pending connections.
In most cases, the victim of such an attack will have difficulty in accepting any new incoming network connection. In these cases, the attack does not affect existing incoming connections or the ability to originate outgoing network connections.
However, in some cases, the system may exhaust memory, crash, or be rendered otherwise inoperative.
The location of the attacking system is obscured because the source addresses in the SYN packets are often implausible. When the packet arrives at the victim server system, there is no way to determine its true source. Since the network forwards packets based on destination address, the only way to validate the source of a packet is to use input source filtering.
What are SYN cookies?
SYN cookies are an implementation of TCP that can respond to the TCP SYN request with a cookie. Following the descriptions above, in normal TCP implementation, when the server received a SYN packet, it responds with a SYN-ACK to acknowledge, and enter the TCP_SYN_RECV state (half-open connection) to wait the last ACK. The server uses a data structure describing all pending connections, and the data structure is of finite size. Therefore, the attacker may fill up the structure.
In the SYN cookies implementation of TCP, when the server received a SYN packet, it responds a SYN-ACK packet with the ACK sequence number calculated from source address, source port, source sequence, destination address, destination port and a secret seed. Then the server releases state. If an ACK comes from the client, the server can recalculate it to determine if it is a response to the former SYN-ACK. If it is, the server can directly enter the TCP_ESTABLISHED state and open the connection. In this way, the server avoids to keep watch half-open connections.
This is just the basic idea of SYN cookies. There are still many mechanics in the implementation.
What is the SYN cookies firewall?
SYN cookies firewall is an extension of SYN cookies. SYN cookies is built in the TCP stack of a Linux, it protects the Linux box. SYN cookies firewall adds a firewall feature in Linux, you can use it as a firewall to protect your network to avoid SYN flooding attacks.
client firewall server
------ ---------- ------
1. SYN----------- - - - - - - - - - ->
2. <------------SYN-ACK(cookie)
3. ACK----------- - - - - - - - - - ->
4. - - - - - - -SYN--------------->
5. <- - - - - - - - - ------------SYN-ACK
6. - - - - - - -ACK--------------->
7. -----------> relay the ------->
<----------- connection <-------
1. A SYN is sent from C (client) to S (server)
2. The firewall acts as S to respond a SYN-ACK with SYN cookie.
3. C sends the ACK. Then the connection should be established.
4. The firewall acts as C to send a SYN to S.
5. S responds to the SYN and sends it to C.
6. The firewall acts as C to send the ACK. Then the connection is established.
7. The firewall relays data between C and S.
If the server is under attack, the step 3 will never occur. Nevertheless, both the firewall and the server do not hold corresponding data of the SYN received in step 1. SYN flooding has therefore been beat.
原文出处:http://www.securiteam.com/tools/6D00K0K01O.html
阅读(2787) | 评论(1) | 转发(0) |
