TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to
[EMAIL PROTECTED]  Contact [EMAIL PROTECTED] for help with any problems!
----------------------------------------------------------------------------

Hi,

When RealSecure detects a synflood it puts the source address as 0.0.0.0 to 
avoid flooding the console (and the user!). A real synflood attack will 
almost certainly come from a spoofed source and quite possibly from a large 
number of spoofed sources. If each one of these IPs was displayed in the 
console as a separate souce address you would get swamped.

So they all get listed as 0.0.0.0. If you drill down on the event or use 
the event inspector the source IP is listed in the info field, just incase 
it's useful.

The way we detect synfloods is not perfect. Basically we count the number 
of half open connections to each IP address. When you hit the magic number 
we detect a synflood.

So imagine RS sitting infront of your firewall. All 2,000 users on your 
network are emailing and surfing like mad. RS needs to keep track of all 
2000 ips for outgoing traffic and all the incoming stuff too. This is not 
that easy.

A real Syn-flood will be a few thousand half open connections. If 
RealSecure was to try to keep track of up to 3,000 half open connections on 
a few thousand machines it would very quickly run out of resources. So we 
call a synflood at much less that a few thousand half open connections. The 
default is in fact 40.

As you have seen, some networks are busier and can run to more than 40 half 
open connections in regular use. When this happens you will see a synflood 
false positive. To change the high water mark open your policy editor and 
select the synflood decode. Click the advanced tab. There are two numbers 
there. The high water mark is how many half open connections are allowed 
before we trigger. You can usually take this to 150 without problems. I've 
seen people run at several hundred without problems. If you do increase 
this number by much take a look at the readme. There is a section on how to 
determine how much memory the detector requires. A sniffer could be used to 
help determine the average number of half open connections, but may 
customers just increase bit by bit until it seems right.

The second parameter to can adjust is the delta. The default is 500. This 
means that once we trigger a syn-flood we wait for another 500 half open 
connections before we tell you again. So in a real syn-flood of several 
thousand events you will actually be told of several syn-floods in the 
space of a minute or two. If there is only one syn-flood logged it's 
probably a false positive and maybe increasing the high water mark is required.

If you have RealSecure Network Engine protecting a busy web server I would 
expect 40 to be too low and you will get false positives. This does not 
mean the engine can't keep up, it's just that there are a lot of 
connections at that time, as it the nature of http traffic.

Of course it's a really good idea to patch those webservers against 
syn-flood and every other DOS attack.

Cheers, Steve

At 11:03 AM 09-03-00 , Matthew F. Caldwell wrote:

>TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to
>[EMAIL PROTECTED]  Contact [EMAIL PROTECTED] for help with any problems!
>----------------------------------------------------------------------------
>
>
>
>If your using Solaris Engines, try using tcpdump or snoop to look at the
>SYN packets further. On Windows NT try windump. This will give you a
>better understanding of the packets and what is causing the SYN signature
>to appear. I've seen the synflood signature appear often in cases where
>the engines can't keep up with the bandwidth. (Most often high traffic
>websites)

----------------------------------------------------------------------------
Steve Reddock
Consulting Manager - Asia Region
[EMAIL PROTECTED]

Internet Security Systems KK, Japan
Phone +81-3-5475-6458      Fax +81-3-5475-0557
http://www.iss.net                   http://www.isskk.co.jp

Adaptive Network Security for the Enterprise

PGP keys available on request
------------------------------------------------------------------------

Reply via email to