[Snort-sigs] SID 526 Rule Description

Ryan Hill rhill at ...290...
Tue Jan 22 19:12:07 EST 2002


# This is a template for submitting snort signature descriptions to
# the snort.org website
#
# Ensure that your descriptions are your own
# and not the work of others.  References in the rules themselves
# should be used for linking to other's work. 
#
# If you are unsure of some part of a rule, use that as a commentary
# and someone else perhaps will be able to fix it.
# 
# $Id$
#
# 

Rule:  alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"BAD TRAFFIC data
in TCP SYN packet"; flags:S; dsize:>6; sid:526; classtype:misc-activity;
rev:3;) 

--
Sid: 526

--
Summary: 
Non-RFC Compliant TCP Session Start Request
In brief terms, this alert means that data was sent during a request to
establish a connection with a remote host and should not occur during normal
TCP communications.  Essentially, a remote caller is attempting to talk
before it has finished dialing.

--
Impact: Any application using the TCP protocol, requiring trend analysis to
determine severity.  Large numbers of alerts from single or distributed
sources may indicate Denial-of-Service attack in progress, especially if
source addresses are unverifiable (spoofed).

--
Detailed Information: 
The alert triggers based on the detection of data content within a TCP
packet with the SYN (synchronize) flag set, which is used as part of the TCP
"three-way handshake" process used to establish communications between two
hosts. 

A TCP "three-way handshake" essentially consists of the following:

1.) A --> B	TCP SYN 'my sequence number is X'
2.) B --> A	TCP ACK 'your sequence number is X'
    B --> A	TCP SYN 'my sequence number is Y'
3.) A --> B TCP ACK 'your sequence number is Y'

Where A = Source Host and B = Destination Host. 

Once this handshake process completes successfully, the two hosts have
successfully negotiated a TCP session, and data exchange may occur.  For
alerts matching this signature, it means that data was detected in a SYN
phase of the three-way handshake, and by definition, shouldn't be there
because the two hosts haven't finished setting up a TCP session.

For more information regarding TCP sessions, see RFC 793: 
ftp://ftp.isi.edu/in-notes/rfc793.txt

--
Attack Scenarios: 
Denial-of-Service (DoS) - SYN Flood, System Probing

--
Ease of Attack: Easy
Several public tools exist to create packets matching this profile,
including automated and scripted Denial-of-Service tools.

Examples: http://www.cert.org/incident_notes/IN-99-07.html  

--
False Positives:
[Commentary] Unconfirmed reports that some load-balancing and content
distribution systems may use similar packets for distance calculations,
especially when packets are received on port 53 (DNS).  Alerts may also be
generated by poorly implemented TCP/IP stacks or applications that are
generating non-RFC compliant packets.

--
False Negatives:

--
Corrective Action:
For Denial-of-Service situations, the primary concern is identifying hostile
traffic and implementing changes to stop the traffic from reaching your
network, which varies depending on the type of the attack and the scope.  

At a minimum, you should implement egress filtering
(http://www.incidents.org/protect/egress.php) on your network border routers
to prevent and help mitigate the risk of denial-of-service attacks and
contact your ISP for assistance in stopping attacks in progress.

Denial-of Service Information:
http://www.cert.org/tech_tips/denial_of_service.html
http://www.cisco.com/warp/public/707/newsflash.html
http://www.sans.org/ddos_roadmap.htm

--
Contributors: Ryan Hill, rhill at ...290...




More information about the Snort-sigs mailing list