Re: Nessus scripts and Moore's Law
Michel Arboi <[email protected]> Thu, 11 Nov 2004 22:53:47 +0100
| Newsgroups | gmane.comp.security.nessus.devel |
|---|---|
| Message-ID | <[email protected]> |
On Thu Nov 11 2004 at 21:59, George Theall wrote: > What are people's feelings about combining related plugins, especially > those that rely on simple version strings? For example, I count 9 > plugins named apache_2_0_*.nasl, most of which do nothing more than > check the banner. The philosophy of Nessus is to have one plugin for each flaw (whenever possible). As the different Apache versions are vulnerable to different flaws, it makes sense to have different scripts. There might be one rare case when we can (and should) remove old plugins. If Gizmo 1.23 is vulnerable to a web directory traversal for example, which is fixed in 1.24, and if sometimes later, somebody finds a new way to exploit the directory traversal, which is fixed in 1.45, than we don't need two plugins. But I'm afraid that this situation is rare :-\ Over optimizing might be dangerous too: if the web server banner is not in the KB because of a network glitch, the plugin should try to grab it again (that's what get_http_banner does) Maybe we should spend a little more time on service identification and banner grabbing to be able to run at full speed once the KB is filled with information. As I had some incomplete reports sometimes, I wrote doublecheck_std_services.nasl which tries hard to identify common services: I'd rather lose some time during the first phase than run the whole scan again. The service identification system is split in several scripts 1) to make it more flexible (as find_service is in C), and 2) to make it more reliable (let's hope!) > It seems to me that they could be replaced by a single plugin that > checks the banner against the latest version and is updated as new > versions and vulnerabilities are announced. We don't want to just read: "upgrade to the latest versions". We need to know if the flaws are dangerous or not, considering the environment. Another point before we try to enhance anything: profiling Nessus is not easy. Some time ago, I wrote a quick & dirty patch which printed at the end of each plugin the used resources (real time, CPU time...). It is still in exec.c (but commented out of course). We may enable it and look at the results... -- [email protected] http://arboi.da.ru NASL2 reference manual http://michel.arboi.free.fr/nasl2ref/ _______________________________________________ Nessus-devel mailing list [email protected] http://mail.nessus.org/mailman/listinfo/nessus-devel