Changing to a normal connect() scan for these systems might solve the problem. The same applies for the original Novell client software whicih ships with Win9x, the syn scan will blue-screen the box. Our specific workaround involves switching to a connect scan if TCP port 427 is open on the system, with some creative hacks to NASL-based portscanner this might be possible to implement in Nessus.
As for JetDirects, you need to query the snmp desc, parse the firmware, and either change the scan type or not scan at all if it hits an affected version (some older versions can't even be connect() scanned). HP doesn't provide an accurate list of rom versions that die when scanned, you either have to compile your own list from experience or just do a connect() scan and hope you dont hit any of the really really old ones. The "F" series of firmware revisions (a few others too) can't even be upgraded. We actually had to build this table of vulnerable versions and implement a workaround system that either changes the assessment parameters for that host (in the case of kinda-recent versions) or tags it with an "outdated firmware" vulnerability and bypasses that phase of the audit. I hate crappy tcp/ip stacks on hardware :( It might be possible to do some pre-portscan processing using ACT_INIT or ACT_SETTING plugins, but in general these types of workarounds are painful to implement in Nessus. -HD On Tuesday 11 February 2003 12:55 pm, Kristofer T. Karas wrote: > On Tue, 2003-02-11 at 11:37, Javier Fernandez-Sanguino wrote: > > Kristopher Karas commented a while back on the list that Novell > > servers running FlexIP might have issues when scanned by Nessus. > > Heh, OK, trying to be a bit more serious now... The SYN scan from NMAP > is the culprit. Certain TCP/IP implementations don't know what to do > with one, including older JetDirect and Novell FlexIP. And of course, > NMAP is enabled by default regardless of whether you have "safe checks" > enabled or not.
