If you are scanning on the outside of a perimeter device, then what would be useful would be a "diff" of a scan results from the outside scan and the inside scan.
Several other comments: - if you are comparing the results of a manual inspection of a Windows server with a remote firewalled Nessus scan, you are sort of comparing apples and oranges. If Nessus can't reach port 445 or you are not scanning with credentials, you will find less "missing patch" vulnerabilities. - the application proxy *may* be dropping packets because of a filtering rule that completely blocks access to a certain port or IP address. However, I question how much of an application proxy would filter a probe from Nessus. Some firewalls recognize "scanning" and will drop the connection. Some Nessus checks may break a protocol like HTTP, but I would be very surprised if this was so and an application proxy dropped the connection. To really see the impact of the proxy or firewall, I'd look at it's "deny" logs. - there may be other limitations in the firewall like maximum number of connections and such. - although mostly NAT focused (you didn't mention NAT or port forwarding, but it may be relevant), I've blogged about scanning hosts from inside and outside of a firewall with Nessus previously: http://blog.tenablesecurity.com/2006/08/using_nessus_to.html Ron Gula, CTO Tenable Network Security http://www.tenablesecurity.com _______________________________________________ Nessus mailing list [email protected] http://mail.nessus.org/mailman/listinfo/nessus
