Jan-Oliver Wagner wrote: > On Samstag, 27. Februar 2010, Vlatko Kosturjak wrote: >> OpenVAS was focusing too much on local checks recently. > > I disagree with this statement. > > Incresing the number of local security checks developed of course > increases the fraction of local security checks based on the total > number of NVTs. But this does not mean there are less remote checks.
Not less remote checks, but not too much more as well. As you said you disagree, I've made quick test just to check if something is changed in the meantime that I wasn't aware of. For example, tried to scan with latest plugin feed Windows 2003 box without SP and Debian Etch (4.0r0). It did not find following important vulnerabilities (amongst many others): http://www.microsoft.com/technet/security/Bulletin/MS03-026.mspx http://www.microsoft.com/technet/security/Bulletin/MS08-067.mspx http://www.microsoft.com/technet/security/Bulletin/MS09-001.mspx http://wiki.debian.org/SSLkeys http://lists.debian.org/debian-security-announce/2007/msg00047.html These all are quite old distros and well known (and old) vulnerabilities. Currently, OpenVAS *remote* checks cannot detect that. And ALL of them are possible to implement remotely and anonymously. > In fact, we try the maximum possible and if you know of missing > remote checks, please forward details to this list! I think paper at: http://www.openvas.org/articles-studies.html goes much more deeper and also proves my point and I guess you read it already. Also, refer to IRC archive at: http://www.linux.hr/openvas/archive/index.php?d=2010-02-10#msg38889 > Of course we can't easily develop security checks for products > where the vendors refuse to cooperate. Greenbone is currently > working on partnerships so that we get respective support. > This is not easy because vendor's requirements conflict > with our wish to publish the tests under GNU GPL. I don't believe that Debian doesn't let you do it? :) I understand that some feature is developed where commercial interest is present. And that is good. I think it's also good to have such features and OpenVAS should continue that, but I think OpenVAS should also focus more on it's core feature which is vulnerability identification. I think everyone would agree, all those bells and whistles added to OpenVAS are losing its value without realiable vulnerability identification. As soon as we accept the problem (or better to say challenge?), it will be the first step in fixing it. Kost _______________________________________________ Openvas-plugins mailing list [email protected] http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins
