[prev in list] [next in list] [prev in thread] [next in thread] 

List:       firewall-wizards
Subject:    Re: sndvol.exe
From:       0x1c <nick () shibumi ! feralmonkey ! org>
Date:       1999-03-23 23:16:42
[Download RAW message or body]

Agreed. Any system *is* subject to resource starvation. The key is, as you
say, to make a design choice (in this scenario, how the PIX handles port
scans).

Personally, I would hope that the pix had some rudimentary intelligence to 
identify when a port scan is taking place, and addressed it by either
alerting the administrator or taking action itself. Of course, if it were
to take action itself you would potentially have a nice DoS attack on your
hands...

It's a question I leave open to the masses. It all depends on the nature
of the organisation running the firewall and how they choose to address
such probes.

Nick

--
Therefore those skilled at the unorthodox are as infinite as heaven and
earth, inexhaustible as the great rivers. -- Sun Tzu, The Art of War

On Sun, 21 Mar 1999, Paul M. Cardon wrote:

> "0x1c <nick@shibumi.feralmonkey.org>" thus spake unto me:
> : I would have hoped a firewall product from Cisco would be smarter than
> : that.
> 
> Any system is subject to resource starvation of some sort.  A design  
> decision has to be made to deny additional sessions or to permit existing  
> sessions to slow to a crawl or terminate entirely when the device is flooded.  
>  With some systems the behavior is tunable.  I haven't worked with Pix so I  
> don't know the specifics of how Pix deals with it.
> 
> Do you instead have some suggestions on how Cisco can improve their product  
> to be more resilient to adverse conditions such as those caused by this  
> trojan?
> 
> -paul
> 
> 
> 
> : On Thu, 18 Mar 1999, Randy Garbrick wrote:
> :
> : > Has anyone noticed a Trojan horse called sndvol.exe that replaces the
> : > Win NT/9X sndvol.exe and then does a continuous port scan from inside a
> : > firewall to multiple outside addresses?  It created a denial of service
> : > by maxing out the sessions on our Pix.  We're trying to locate the
> : > source of the executable.
> 

[prev in list] [next in list] [prev in thread] [next in thread]