TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to
[EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any problems!
----------------------------------------------------------------------------
>Date: Wed, 19 Jan 2000 17:23:26 -0500
>From: Paul Cardon <[EMAIL PROTECTED]>
>
>I know some parts of this expanation are fairly detailed but I
>hope it is useful.
>If I have anything wrong, hopefully somebody from ISS will correct me.
As one of the people who worked on this code in the RealSecure Network
Engine, I'll try to clarify a bit.
RealSecure tracks all SYN's as you theorize. It keeps a table of SYN's that
have been seen which have not been followed by ACK packets traveling in the
same direction to the same connection. Once a following ACK (presumably the
ACK that completes the three way handshake, but it can be *ANY* ACK packet
in the subsequent connection) is seen, the SYN is removed from the "half
open connections" table. This goes on for all SYN's and ACK's that
RealSecure sees.
It also, of course, processes any FIN's or RST's it sees appropriately, so
for instance if a SYN is seen going to a non-open port, and a RST comes back
off that port, it will not be considered as a half-open connection.
If, for a given listening port, the number of half open connections in the
table exceeds a certain number (which is configurable by the user in their
policy file), RealSecure decides a SYNFlood has occurred. It will then
(optionally, only if the user has the RSKILL action enabled) send a RST
packet to the listening host to close the half-open connection on the server
side. This mitigates the effect of the flood.
As a flood proceeds, the RST packets are sent for every contributing SYN.
However, to keep from creating a subsidiary flood at the console, actual
SYNFLOOD events are only generated every "Nth" SYN, N again being
configurable in the users policy file.
>In other words, completed connections, not just
>half-opens trigger the
>signature. That is why so my false positives are seen
This is not true. If RealSecure sees an ACK packet which completes the
three-way handshake, that SYN is removed from the table and does not
contribute to the SYNFLOOD determination. Therefore, a properly operating
RealSecure network engine will not consider completed connections in
SYNFLOOD.
Most of the rest of your explanation is pretty accurate, including the
explanation of why you see 0.0.0.0 in the reports. Of particular note is
your mention of the danger of maintaining state in the RealSecure engine and
why we might not want to do this. That was very astute. As it happens, we
ARE maintaining state information, but a very small amount. This does have
its limitations which result in some false positive situations.
There are a number of reasons these false positives can occur. Here are a
few:
(0) Your tuning parameters for SYNFLOOD in your policy file are set too low
for your network. Look for "HighWaterMark" and "PacketsPerEvent" under the
Advanced button for SYNFLOOD in the Policy editor for RealSecure 3.2 or
higher. Experiment with raising these numbers and see what effect it has on
the reports. However, don't go crazy with these values (for instance,
increasing them by several orders of magnitude all at once).
(1) You have asymmetric routes on your network near the RealSecure sensor.
In this case, RST and FIN packets that are coming back off the target server
cannot be seen by the same RealSecure engine that saw the SYN's. Thus
connections which are being legitimately closed (or were never opened in the
first place) are not being closed out of the half-open table in RealSecure's
memory and contribute to SYNFLOOD determinations.
(2) Due to packet bursts or sustained loading, your RealSecure Network
Engine may be dropping packets, and therefore missing the ACK's that
correspond to some SYN's, again contributing to false SYNFLOOD
determinations.
As it happens, in all of the known cases where SYNFlood false positives, the
RST packet we send will end up being ignored by the target host because it
either (a) doesn't correspond to an open port or (b) doesn't match the
current window of an actual open TCP connection. Thus it is pretty safe to
leave RSKILL turned *ON* for SYNFLOOD, even though false positives do occur!
Here is the rule of thumb: if you have a real SYNFLOOD on your hands, you
will see multiple, repeated, regular reports of SYNFLOOD aimed at the same
IP and port. It will be like a "heartbeat" on your RealSecure console. In
other words, you will see SYNFLOOD over and over and over, on intervals on
the order of a few seconds or minutes, and the destination IP/Port will be a
critical server on your network. This type of report is real and should be
reacted to.
If you see SYNFLOOD other than this, such as a single SYNFLOOD event, or on
the order of one every hour or less, then this is clearly a false positive
and can be safely ignored. Of particular note are low-volume SYNFLOOD
reports that appear to be aimed at IP/PORT combinations that do not actually
exist on your network (these are often caused by case (1) above), or
low-volume SYNFLOOD reports that correspond to legitimate traffic to very
high volume servers on your network.
=====================================
Tim Farley
Software Engineer
[EMAIL PROTECTED]
Internet Security Systems, Inc.
(678) 443-6000 / Direct Dial (678) 443-6189 / fax (678) 443-6479
http://www.iss.net
ISS CONNECT 2000
International User Group and Information Security Summit
March 19-24, 2000 http://connect.iss.net
REGISTER TODAY!
=====================================
