TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to
[EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any problems!
----------------------------------------------------------------------------
Mukund!
The following is from one of the developers of the Real Secure network
engine:
snip>>>>>
RealSecure 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.
<<<<end snip
The address that is seen in the packet is placed in the "SPOOFEDSRC" column
of the event details.
This being said, you can expect false positives especially from congested
web servers and email servers.
You can work to reduce the false positives by configuring the advanced
properties for the SynFlood decode in your policy. You would want to
increase the HighWaterMark, which is the number of half open TCP connections
RS allow to wait in each port's queue and probably the PacketsPerEvent which
is the number of the SynFlood packets before RS sends an alert to the
console or logs to the DB.
Optimum values for the advanced properties depends entirely on the
environment. Increase each value until false positives are reduced to your
satisfaction level.
If you're new to the issforum, it's archived at:
http://archives.neohapsis.com/archives/iss/current/0127.html
Greetings,
==================================
Brian Fitch, IDS Support Engineer
Internet Security Systems, Inc.
Phone - 404-236-2700 / 1-888-447-4861
Email - [EMAIL PROTECTED]
==================================
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 06, 2000 8:37 PM
To: [EMAIL PROTECTED]
Subject: Interpreting SYN Flood Alerts in RS
TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to
[EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any
problems!
----------------------------------------------------------------------------
Hi All,
We are getting lots of SYN Flood alerts in the Real Secure Console.
Source Address:0.0.0.0
Destination Address: <IP Address of Web Server>
Info : SPOOFEDSRC < Valid IP Address not in our range >
1. Can Somebody help in interpreting this alert.
2. What is the optimum value to be set for "High Water Mark" and "Packets
Per Event" in Real Secure. Web server is IIS 4.0 (NT 4.0 SP5).
Thanks in Advance,
Mukund
Chequemail.com - a free web based e-mail service that also pays!!!
http://www.chequemail.com
