- Table of Contents
-
- 06-Security Configuration Guide
- 00-Preface
- 01-AAA Configuration
- 02-802.1X Configuration
- 03-MAC Authentication Configuration
- 04-Triple Authentication Configuration
- 05-Port Security Configuration
- 06-User Profile Configuration
- 07-HABP Configuration
- 08-Public Key Configuration
- 09-PKI Configuration
- 10-SSH2.0 Configuration
- 11-SSL Configuration
- 12-TCP Attack Protection Configuration
- 13-IP Source Guard Configuration
- 14-ARP Attack Protection Configuration
- 15-ND Attack Defense Configuration
- Related Documents
-
Title | Size | Download |
---|---|---|
12-TCP Attack Protection Configuration | 84.81 KB |
Contents
TCP attack protection configuration
TCP attack protection overview
Enabling the SYN Cookie feature
Enabling protection against Naptha attacks
Displaying and maintaining TCP attack protection
This chapter includes these sections:
· TCP attack protection overview
· Enabling the SYN Cookie feature
· Enabling protection against Naptha attacks
· Displaying and maintaining TCP attack protection
|
NOTE: · The term "switch" or "device" in this chapter refers to the switching engine on a WX3000E wireless switch. · The WX3000E series comprises WX3024E and WX3010E wireless switches. · The port numbers in this chapter are for illustration only. |
TCP attack protection overview
An attacker can attack the device during the process of TCP connection establishment. To prevent such attacks, the device provides the following features:
· SYN Cookie
· Protection against Naptha attacks
This document describes the attacks these features can prevent, working mechanisms of these features, and configuration procedures.
Enabling the SYN Cookie feature
As a general rule, the establishment of a TCP connection involves the following three handshakes.
1. The request originator sends a SYN message to the target server.
2. After receiving the SYN message, the target server establishes a TCP connection in the SYN_RECEIVED state, returns a SYN ACK message to the originator, and waits for a response.
3. After receiving the SYN ACK message, the originator returns an ACK message, establishing the TCP connection.
Attackers may mount SYN Flood attacks during TCP connection establishment. They send a large number of SYN messages to the server to establish TCP connections, but they never make any response to SYN ACK messages. As a result, a large number of incomplete TCP connections are established, resulting in heavy resource consumption and making the server unable to handle services normally.
The SYN Cookie feature can prevent SYN Flood attacks. After receiving a TCP connection request, the server directly returns a SYN ACK message, instead of establishing an incomplete TCP connection. Only after receiving an ACK message from the client can the server establish a connection, and then enter the ESTABLISHED state. In this way, incomplete TCP connections could be avoided to protect the server against SYN Flood attacks.
Follow these steps to enable the SYN Cookie feature:
To do... |
Use the command... |
Remarks |
Enter system view |
system-view |
— |
Enable the SYN Cookie feature |
tcp syn-cookie enable |
Required Enabled by default. |
|
NOTE: With the SYN Cookie feature enabled, only the maximum segment size (MSS), is negotiated during TCP connection establishment, instead of the window’s zoom factor and timestamp. |
Enabling protection against Naptha attacks
Naptha attacks are similar to the SYN Flood attacks. Attackers can perform Naptha attacks by using the six TCP connection states (CLOSING, ESTABLISHED, FIN_WAIT_1, FIN_WAIT_2, LAST_ACK, and SYN_RECEIVED), and SYN Flood attacks by using only the SYN_RECEIVED state.
Naptha attackers control a huge amount of hosts to establish TCP connections with the server, keep these connections in the same state (any of the six), and request for no data so as to exhaust the memory resource of the server. As a result, the server cannot process normal services.
Protection against Naptha attacks mitigates such attacks by accelerating the aging of TCP connections in a state. After the feature is enabled, the device (serving as a TCP server) periodically checks the number of TCP connections in each state. If the device detects that the number of TCP connections in a state exceeds the maximum number, it considers that a Naptha attack occurs and accelerates the aging of TCP connections in this state. The device will stop accelerating the aging of TCP connections when the number of TCP connections in the state is less than 80% of the maximum number (1 at least).
Follow these steps to enable the protection against Naptha attack:
To do... |
Use the command... |
Remarks |
Enter system view |
system-view |
— |
Enable the protection against Naptha attack |
tcp anti-naptha enable |
Required Disabled by default. |
Configure the maximum number of TCP connections in a state |
tcp state { closing | established | fin-wait-1 | fin-wait-2 | last-ack | syn-received } connection-number number |
Optional 5 by default. If the maximum number of TCP connections in a state is 0, the aging of TCP connections in this state will not be accelerated. |
Configure the TCP state check interval |
tcp timer check-state timer-value |
Optional 30 seconds by default. |
Displaying and maintaining TCP attack protection
To do… |
Use the command… |
Remarks |
Display current TCP connection state |
display tcp status [ | { begin | exclude | include } regular-expression ] |
Available in any view |