Re: families
David Lodge <[email protected]>
| Newsgroups | gmane.comp.security.nessus.devel |
|---|---|
| Message-ID | <[email protected]> |
Quoting Bob Gerdes <[email protected]>: [multiple families] > One dilemma that we face is to be able to identify plugins by their > scanning effects (DOS, disruptive, banner, etc.) to aid the scanning > process; then identify plugins by service being tested (ssh, ftp, > backdoors, etc.) to aid both scan choices and remediation processes; and > then identify remediation effort (patch via windowsupdate, other patching, > configuration, and so on) to help understand policy efforts and > remediation efforts. The first draft of this has helped at negotiating > vulnerabilities at each stage of the effort. >From a A&P persepctive (working for a large company), I need to reference plugins by different requirements, depending upon what I'm checking: For internal systems I require to know the impact to the systems I'm scanning - even though I normally scan systems before implementation, bringing a system down -- or even doing a permanent DoS (in one case - on a printer) is a bad thing. For external systems, I'm restricting what I do on the scan, especially if I'm scanning over the internet. On this basis its better to restrict to protocol - if I see only http and ftp open then its not worth it performing DCE tests on the system. This is due to trying to restrict the amount of traffic, and due to having a limited time slot to perform the test in. I think that for the next major release of Nessus, it may be worth looking at the header of the Plugin, allowing more choice of how one may select plugins - even if this does mean updating the protocol. What I have in mind is a header with the rough information, for example: Name="NTP Information Gathering" Description="Check for whether NTP leaks system information" Protocol="NTP" Ports="123/udp" Risk="Low" Keywords[]="Informational","Access Control" Resolution="Restrict the hosts which the NTP server allows information requests from:\ restrict default ignore" dave _______________________________________________ Nessus-devel mailing list [email protected] http://mail.nessus.org/mailman/listinfo/nessus-devel