Turn off DCOM if you can't patch or you could possibly put a personal firewall on the box to block traffic to that port if you can't turn it off. I personally have never trusted the personal firewalls, but I guess it's an option. As far as the .... and ? ? results, I am marking those as unknown in my reports and making sure someone touches those machines by hand. So far every unknown system that has been checked has been patched. -----Original Message----- From: Russell Fulton [mailto:r.fultonat_private] Sent: Thursday, July 31, 2003 2:26 PM To: Schmehl, Paul L Cc: incidentsat_private On Fri, 2003-08-01 at 03:30, Schmehl, Paul L wrote: > I have both eEye's tool and ISS's tool. I decided to run the ISS > commandline scanner on our entire class B last night. That way I could > come in this morning and have a complete report of patch compliance. Or > so I thought. When I got in to my office this morning, the ISS tool had > been running for 15 hours and had reported on a total of 99 hosts. I ran it on our class B a couple of days ago and after about 5 hours it stopped scanning after finding 7500 hosts listening on port 135. The process did not terminate it just hung with no more output being written to stdout. The output file had a truncated line at the end suggesting that the buffer had not been fully written. The number of host is close to what I would expect so I'm going to try again today. Another feature of this scanner is that it scans in random order so if anything goes wrong you can't simply restart from where you left off :( I don't know why ISS decided to do this rather than a simple sequential scan. As others have mentioned the scanner does two tests and returns one of 4 results for each: [VULN], [ptch], [....] and [ ? ? ]. THe meaning of the first two are obvious but the others are not specified and I would like to have more information of exactly what they mean. Anyone worked it out? We have found some systems that are proving very difficult to patch - we can't get them to the requisite SP levels because of lack of disk space or other issues. Does anyone know of safe workarounds for such systems? -- Russell Fulton, Network Security Officer, The University of Auckland, New Zealand. --------------------------------------------------------------------------- ---------------------------------------------------------------------------- --------------------------------------------------------------------------- ----------------------------------------------------------------------------
This archive was generated by hypermail 2b30 : Fri Aug 01 2003 - 09:29:57 PDT