In response to the question about nessus and admin privileges. FYI, even Microsoft's MBSA needs administrative privileges and netbios and remote registry services and.... nessus, on the other hand, can do 905% of its work with just a normal username/password.
Well, they has to be SOME way to look at the remote registry, which is where most of this stuff is stored. Michael Scheidell SECNAP Network Security, LLC (561) 368-9561 [EMAIL PROTECTED] http://www.secnap.net ----- Original Message ----- From: "EveningStar" <[EMAIL PROTECTED]> Newsgroups: microsoft.public.security Sent: Wednesday, April 17, 2002 2:03 AM Subject: Re: MBSA scan of network computers > raivo wrote: > > We have a small network of W2K computers. > > Some of the computers do not have 'File and Printer Sharing for MS > > Networks' checked. When I try to scan remotely with MBSA using either > > the computername or the IP address I receive the message that the > > computer is not found ... > > Do I have to check the 'File and Printer Sharing for MS Networks' in > > order to scan with MBSA ... isn't the computername or IP address > > enough ... > > > > Can someone help me ... thanks > > > > /raivo kask > > Oddly enough, this question may be more appropriate for > microsoft.public.security.hfnetchk. However, to quote from the doc for > MBSA, > > "Users must have local administrative privileges on each computer being > scanned, whether a local or remote scan is being performed. The Server > service (as well as the Remote Registry service on Windows 2000 and Windows > XP) is required to be running on all systems being scanned." > > In addition (and not mentioned in the documentation) File and Printer > Sharing is required in order to allow access to the administrative share > (which is automatic). You do not have to be sharing any folders or > printers. You can disable NETBIOS over TCP/IP, but if you turn off File and > Printer Sharing on the computer to be scanned and look at the exchange with > a packet sniffer, you'll find that the destination machine (especially if > its a domain controller) may reply (with failure messages) on port 137 even > with NETBIOS disabled on all of its NICs (interesting, huh?). > > -- > David Dickinson > EveningStar Information Services > Las Cruces, NM USA > > Summary of Microsoft Security Bulletins > http://www.zianet.com/bwd/securitybulletins.asp > >
