Docstoc

Beyond

Document Sample
Beyond Powered By Docstoc
					Wade

I have experienced similar SynFlood issues. In fact, I found cases
where the events were being triggered on packets flowing outbound from
our network. I set up tcpdumps to catch who, internally, was trying to
send them and to whom they were sending them. What I found in many
cases were not what I call syn floods. I trapped several events and
found the workstation in my network was trying to access a server in
another network that was not in service, or, for some other reason, not
responding. My side was seeing these as timeouts and tried several
times to resend. What it appeared to me was that the SynFlood flood
signature counts the number of syn's that are sent to one address
without sending anything else regardless of whether the target machine
was responding or not and regardless of frequency.

Typically, the TCP three way handshake starts with a syn from the
source machine to the target machine, followed by a syn-ack received
from the target machine and an ack being sent back to target machine.
In a syn flood, a source machine sends many syn packets to the target
machine and does not care about the syn-ack from the target machine.
If the syn-ack comes back, the source machine ignores it and sends out
more syn's keeping half sessions open.

However, what I saw in my tcpdumps, is one of my machines trying to
access the target machine with a syn and not receiving a syn-ack back.
A short period of time later, my machine would resend the syn. In
fact, I found 15 syn's being transmitted over the 12 minute period that
my tcpdump was running without ever receiving a syn-ack. Over a long
period of time, this would appear to a be a syn flood because my
machine has repeatedly sent only a syn to the target machine; nothing
malicious, it was only trying to communicate with the server. I had
set my HighwaterMark to 80 but it did not take long for 80 packets to
time out (about an hour) and RS report a SynFlood. I now disregard
outbound SynFloods.

Regards
Dan Wangler, GIAC Certified Intrusion Analyst
IT Security Response Team, Texas Instruments, Inc.
Spring Creek Bldg 1, C196,
6500 Chase Oaks, Blvd, MS 8417, Plano, Texas, 85023
Tel #; 214-567-8304; Email:; dwangler@ti.com




TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your
message to
majordomo@iss.net Contact issforum-owner@iss.net for help with any
problems!
-----------------------------------------------------------------------
-----

I am experiencing the problem that Jayme has described. I have walked
through increasing the values for "HighWaterMark" and "PacketsPerEvent"
both
myself and with the help of ISS tech support. I have not seen a
reduction
in the false positives. What I'd really like to understand is what
host
RealSecure sees this traffic coming from? Is the SPOOFEDSRC address
that is
reported the source of the SYN Flood traffic? Probably not if that
host has
been removed from the network. Or is it that another source on the
network
is spoofing the address being reported in the SPOOFEDSRC field? If so,
what
is the best method to try and detect the 'actual' source address?

Wade Dauphinee CCNA,GCIA



-----Original Message-----
From: Fitch, Brian (ISS Atlanta) [mailto:BFitch@iss.net]
Sent: Thursday, October 11, 2001 9:49 PM
To: 'JBFRYE@UP.COM '; 'issforum@iss.net '
Subject: RE: SYN-Flood false positives.



TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your
message to
majordomo@iss.net Contact issforum-owner@iss.net for help with any
problems!
-----------------------------------------------------------------------
-----

Your parameters for SYNFlood are probably left to the defaults (check
the
advanced tab on the decode in your policy editor and you'll see what I
mean). This will cause a lot of false positives in regards to web
traffic
and SMTP traffic.

Chances are the "External IP" are web sites.

Try increasing the values for "HighWaterMark" and "PacketsPerEvent"
until
you see a reduction in the false positives. Whatever final value you
choose
will depend on your network and your troubleshooting.

The topic of SYNFlood has been discussed many times on the issforum,
the
archives are found here:

http://archives.neohapsis.com/archives/iss/

Brian Fitch, ISS Named Accounts Engineer


-----Original Message-----
From: JBFRYE@UP.COM
To: issforum@iss.net
Sent: 10/11/01 2:23 PM
Subject: SYN-Flood false positives.


TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your
message
to
majordomo@iss.net Contact issforum-owner@iss.net for help with any
problems!
-----------------------------------------------------------------------
-
----

RealSecure 5.0.2 detects a great deal of what it flags as SYNflood
attacks.
See Event detail below:
     Event:              SYNFlood
     Date:               2001/10/11 13:10:13
     Source Addr:        0.0.0.0
     Deatination Addr:   External IP address
     Sensor Location:    Internal IP address behind firewall
     Protocol:      TCP
     Source Port:        Any
     Destination Port:   HTTP
     SPOOFEDSRC:    Internal IP address

Events similar to this are being generated approx. seven times per min.
with three differen't SPOOFEDSRC internal IP adresses.
The oddest thing about this is that the events continue to be generated
for
a particular SPOOFEDSRC internal IP address even after the host
associated
with that IP address has been removed from the network i.e. powered
off.
Anyone seen anything like this?

Jayme Frye
Union Pacific Railroad
Data Security
271-3970




Dan Wangler, GIAC Certified Intrusion Analyst
IT Security Response Team, Texas Instruments, Inc.
Spring Creek Bldg 1, C196,
6500 Chase Oaks, Blvd, MS 8417, Plano, Texas, 85023
Tel #; 214-567-8304; Email:; dwangler@ti.com

				
DOCUMENT INFO
Tags:
Stats:
views:0
posted:8/13/2013
language:
pages:3