RE: NetScreen ScreenOS 2.6 Subject to Trust Interface DoS
From: Dave Killion (Dkillion@netscreen.com)Date: 02/01/02
- Previous message: shimi: "Vulnerability in all versions of DCForum from dcscripts.com"
- Maybe in reply to: Chris Lathem: "NetScreen ScreenOS 2.6 Subject to Trust Interface DoS"
- Next in thread: Alexander Poizner: "RE: NetScreen ScreenOS 2.6 Subject to Trust Interface DoS"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: Dave Killion <Dkillion@netscreen.com> To: "'clathem@skyhawke.com'" <clathem@skyhawke.com> Date: Fri, 1 Feb 2002 10:27:11 -0800
Chris,
You were misinformed about the time for a fix. Your device was also more
than likely misconfigured. This issue has already been addressed, and
preventative measures were added in ScreenOS 2.6.1 back in September of 2001
in response to trouble people were having with the Code Red series of
Internet worms. The feature is called Source IP Session Thresholding. This
feature was implemented as a CLI command in 2.6.1r2, and has been
incorporated into the WebUI starting with ScreenOS 3.1. ScreenOS 3.1 is
currently available for the NS-204, NS-208, and NS-500.
The command:
set firewall session-threshold source-ip-based [num]
limits any one source IP from the trusted side to [num] number of concurrent
sessions. Since the 5XP can support 2048 concurrent sessions, it would make
sense to set the limit lower than that. I would recommend the higher of the
following two numbers as a starting point: 100, or 2048/n where n is the
number of systems on your private side network. You might want to check
your flow counters to see if that's an acceptable number, and modify
accordingly.
As to how long these sessions remain active is user configurable. ScreenOS
has a default setting for session inactivity timeout of 30 minutes. Both
pre-defined and custom services can be adjusted in timeout value from 1
minute to 2 days. If you would have waited 30 minutes, your portscans to an
unresponsive machine would have timed out and the sessions cleared for
reuse. If you had scanned a machine that responded to the scans (with
either ICMP unreachable or RST), the session would have closed immediately.
I'm curious as to from who you received this incorrect and outdated
information, so we can correct our own internal information distribution
system. A NetScreen Whitepaper was also written (by me) that covers this
new feature and it's use, as well as information on the worms from last
year. It's somewhat dated now, and I didn't feel like spamming the bugtraq
alias with it as well, but if you'd like a copy, please drop me a note and
I'll forward it to you.
If you have any further questions on this matter, please feel free to ask.
Dave Killion
Senior Support Engineer
NetScreen Certified Security Associate (NCSA)
NetScreen Technical Assistance Center
support@netscreen.com
(800)638-8296
Please visit our Enhanced Services support offerings at
http://www.netscreen.com/support/enhanced_services.html
- Previous message: shimi: "Vulnerability in all versions of DCForum from dcscripts.com"
- Maybe in reply to: Chris Lathem: "NetScreen ScreenOS 2.6 Subject to Trust Interface DoS"
- Next in thread: Alexander Poizner: "RE: NetScreen ScreenOS 2.6 Subject to Trust Interface DoS"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
