--- Michel Arboi <mikhail@private> wrote: > On Sat, 2005-02-19 at 12:55 -0800, Jon Passki wrote: > > Below is the code snippet containing the two I think needing > > adjustment. Both only inform of an NFS server that does not > export > > files. A superfluous service should not cause a warning. > > Mmmhhhh... An unused service is a potential hole, isn't it? > Removing it > hardens the system. I agree that a NFS server that exports > directories > is more dangerous than one that does not export anything, but it > is > useful (or at least should be used), so we cannot close it. > > Maybe we should agree on a precise definition of what should be > security_note, warning and hole, and also the "risk level". This > dead > horse has been beaten many times on the mailing lists, but it is > not yet > clear. > > IMHO: > - a note should be informative only. e.g. for a complete audit. > You > might decide that some things should be closed because there are > useless > or against your policy, but Nessus cannot chose. Agreed! > - a warning should be a potential hole, a weakness. A superfluous > service might fit. Predictable IP IDs or accepting source routed > packets > might fit too: there are not a hole by themselves, but might > allow some > attacks in some precise situation (stealth scan...) Well this relates to another thread that's active on nessus@ on what a vulnerability can produce and how to adequately describe that. I consider predictable IP ID's in the same class as recursive/indirect resource usage (proxy HTTP, recursive DNS, etc). I'm able to use it against a different target, which I consider a risk, too. > - a hole should be a real weakness (or a false positive alerts). > The border is fuzzy. For example, giving too much information > (through > SNMP, or by displaying the web root of your server) might be a > "warning" > or a "hole" (if the data is considered confidential?) This really relates to the thread on nessus@private with the subject "Nessus Risk Rating Discussion Part Deux". Check it out! > Said in another way, grep the "holes" from a report and give them > to the > IT team ("patch that") Of course :-) Jon __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail _______________________________________________ Plugins-writers mailing list Plugins-writers@private http://mail.nessus.org/mailman/listinfo/plugins-writers
This archive was generated by hypermail 2.1.3 : Mon Feb 21 2005 - 08:43:53 PST