Juniper NETWORK AND SECURITY MANAGER 2010.3, Руководство администратора

Страница: 541 / 1016

Entering Comments
You can enter notations about the rule in the Comments column. Anything you enter in
the Comments column is not pushed to the target devices. To enter a comment, right-click
the Comments column and select
Edit Comments . The Edit Comments dialog box
appears. You can enter up to 1024 characters in the Comments field.
Configuring SYN Protector Rules
The SYN-Protector rulebase protects your network from SYN floods by ensuring that
the three-way handshake is performed successfully for specified TCP traffic. If you know
that your network is vulnerable to a SYN flood, use the SYN Protector rulebase to prevent
it.
The TCP Handshake
When a TCP connection is initiated, a three-way handshake takes place:
•
A client host sends a SYN packet to a specific port on the server to request a connection.
• Next, the server sends the client host a SYN/ACK packet, which both acknowledges
(ACK) the original SYN packet from the client host and forwards a new SYN packet.
The potential connection is now in a SYN_RECV state.
•
Finally, the client host sends an ACK packet to the server to acknowledge receipt of
the SYN/ACK packet. The connection is now in an ESTABLISHED state.
This three-way handshake contains an inherent, exploitable vulnerability that attackers
can use to disable the system: a SYN flood. Most systems allocate a large, but finite
number of resources to a connection table that is used to manage potential connections.
While the connection table can sustain hundreds of concurrent connections across
multiple ports, attackers can generate enough connection requests to exhaust all
allocated resources.
SYN-Floods
Attackers initiate a SYN flood by manipulating the basic three-way handshake:
• A client host sends a SYN packet to a specific port on the server. However, the attacker
ensures that the client host’s IP address is a spoofed IP address of an unreachable
system.
•
Next, the server sends the client host (spoofed address) a SYN/ACK packet. The
potential connection is now in a SYN_RECV state.
• Since the system is unreachable, the server never receives an ACK or RST packet back
from the client host. The potential connection is now in the SYN_RECV state, and is
placed into a connection queue while it waits for an ACK or RST packet. This potential
connection remains in the queue until the connection-establishment timer expires
(when it will be deleted).
•
The attacker sends another SYN packet to the server, requesting another connection.
And then another. And another. The connection table fills to capacity and cannot
accept new SYN requests. The server is overwhelmed, and quickly becomes disabled.
491 Copyright © 2010, Juniper Networks, Inc.
Chapter 9: Configuring Security Policies