subject: (Fwd) Re: ISS Spin Control posted: Tue, 3 Apr 2001 18:35:23 +0100
re: stick DOS against RealSecure IDS
(sorry for the flood, folks. I was offline for a few days while I learned
PERL. :) $me = (/\b /,"totally stoked!");
Still getting my head around regular expressions though.
Stuart
------- Forwarded message follows -------
Date sent: Mon, 19 Mar 2001 09:20:09 -0500
Send reply to: "Pierce, John (ISSAtlanta)"
<[email protected]>
From: "Pierce, John (ISSAtlanta)" <[email protected]>
Subject: Re: ISS Spin Control
Originally to: Chris H Mahn <[email protected]>
To: [email protected]
No, the sensor does not stop recording or reacting to attacks.
ISS
sensors are designed to work independent of a console. All
actions that
sensors are able to perform (email, SNMP, OPSEC, kills, user
defined
responses, firecell rules on server sensors, etc.) are preformed
from the
sensor itself. The only thing you lose when the communication to
the
console is lost is the display response. This is not necessarily a
great
loss as all of the data is being logged on the sensor. Either way,
MU 2.2
corrects the loss of the event channel. ISS was not attempting to
"spin"
anything- we merely pointed out that this tool was nothing new and
was not a
significant threat to our IDS.
There is one other thing that I would like to point out- this tool
is not effective as IDS evasion. Stick is a very loud flooder and therefore
not useful in evasion. Any security admin worth his/her salt will know that
something is up as soon as they see you banging on the door. This is akin
to setting a house on fire to distract someone while you break in. The real
danger in this tool is that, just like any other flooder, it can be used to
cause a DOS on the target network. This is why bandwidth becomes a
consideration.
-----Original Message-----
From: Chris H Mahn [mailto:[email protected]]
Sent: Friday, March 16, 2001 12:03 PM
To: [email protected]
Subject: Re: ISS Spin Control
Tez,
I have a question about the following paragraph, part of which came from
ISS.....
"The Network Sensor must be manually reconnected to restore normal
operation. At no point does the Network Sensor or Network Console crash."
... Yes, the connection is lost, and the system administrator needs to
manually re-start the connection. But even though the Network Sensor does
not crash, it does stop recording. This might not be an outright lie, but
it is a misleading statement. The sensor no longer functions as an IDS.
--------------------------
If the sensor doesn't crash, then it doesn't stop recording. If you just
loose connection with the sensor, then the sensor cannot send any events to
the console, but the sensor itself is still recording. After you
re-connect, you can synch the logs. Now that I have that said, when ISS
originally came out with this, I was trying to figure this part out. Can
you tell me if it actually stops the sensor, or if it just looses the
connection to the console? Thanks for any elaboration.
First of all I agree that there is nothing really new in stick that people
have not though of before. I received a number of e-mails from people who
said that they were thinking along the same lines. When I talked to Ron
Gula (Dragon) last year about the tool, he said that such an attack
(information overload) is a problem. I've also received a perl script of a
tool that sends IDS trigger packets. For the most part the community seems
to have been waiting for the tool to appear.
For etiquette reasons I've released the code to product companies that
are/might be affected. What I should have expected is spin control from
companies. I expected companies to make changes and downplay the problem,
but I didn't expect a company to down right lie in their analysis.
I would like to point out inconsistencies in the ISS report on "stick".
"The effectiveness of the Stick attack is a function of the attacker's
available bandwidth" ... does this mean that ISS Real Secure can only
handle a flood of 18 Mbps? I stated in the paper that I didn't know why
ISS had its problems, but I can tell you that flooding was not the problem.
ISS has performed at higher bandwidth levels in other independent tests.
So, the problem is not just bandwidth (flooding).
The effectiveness of an IDS is not based on whether it can record and alarm
off every packet, but to empower administrators and security personnel to
respond to an intrusion or attack. If ISS would read the paper, they would
note that the attack is aimed at information overload of the people using
the IDS and not the IDS itself. The problem arises when IDS alarms (which
ISS might have done if it didn't perform hari- kari) overwhelm the IDS
operator. The IDS becomes useless as a tool for response. Response is the
ultimate reason to have an IDS (unless you are marketing, in which case you
sell it).
"The Network Sensor must be manually reconnected to restore normal
operation. At no point does the Network Sensor or Network Console crash."
... Yes, the connection is lost, and the system administrator needs to
manually re-start the connection. But even though the Network Sensor does
not crash, it does stop recording. This might not be an outright lie, but
it is a misleading statement. The sensor no longer functions as an IDS.
Lastly, I would like to point out that this tool was designed to stress
"Snort" and not ISS Real Secure. The fact that ISS had problems with it
was an interesting side effect and one that makes me wonder about the
uniqueness of their signature base.
I sent ISS the stick source code. If ... "Stick does not employ any new
methods, nor does it expose any new flaws in signature-based IDS", then I
give ISS X-Force permission to post the code and be responsible for its
release, since there is nothing new.
And as ISS's disclaimer states, "In no event shall the author be liable for
any damages whatsoever arising out of or in connection with the use or
spread of this information. Any use of this information is at the user's
own risk."
Or in other word: Use this data. There is no responsibility on the part of
the author that any of this is correct. Any damage caused by incorrect or
misleading information is done so at the readers own risk.
--Tez
------- End of forwarded message -------
generated by msg2page 0.06 on Jul 21, 2006 at 19:04:45
search: