Two issues here: 1) Traceroute information is useful for debugging why systems may not be reachable as a normal course of running an audit. If an intermediate network has a routing problem, having the traceroute available AT THE TIME OF THE AUDIT is a useful diagnostic tool.
2) traceroute has the potential, afaik, of revealing network addresses that are not intended to be shown. Admittedly not a really big deal, and I agree the signal to noise ratio is pretty low on this one. Thomas Jan-Oliver Wagner wrote: > On Monday, 2. January 2012, Henri Doreau wrote: >> 2012/1/2 Jan-Oliver Wagner <[email protected]>: >>> However, in some cases it might be a information leak problem. >>> >>> So, I wonder whether we should split this functionality into two NVTs: >>> - one that simply retrieves the traceroute information and stores it >>> in the host details. >>> - one that reads the host details and sends a security note if it looks >>> reasonable to do so (what are the hints for information leaks?) >>> Ideally this NVT should already define a CVSS which explains the >>> the severity with its base vector. >>> >>> What do you think? >>> >> could you elaborate on situations where reporting the detailed >> traceroute information would be a problem? > > not reporting is the problem. The current traceroute NVT thinks it is > a security threat if some information are available via traceroute. > >> We should pay attention to >> the fact that host details end up in the final reports just like the >> security messages. > > this is not the actual problem. > > The actual question is: why and what type of threat is present by traceroute > information? > > Best > > Jan > _______________________________________________ Openvas-plugins mailing list [email protected] http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins
