I'll take a stab at some of your questions/clarifications on application proxy firewalls - specifically the Raptor firewall which is a hybrid application proxying firewall. As a raptor administrator for the past decade I think I can address some of the more important points surrounding this firewall. First, regardless of the network segment you're scanning and depending on the firewall's configuration, you may or may not see a large collection of ports "open" which could then trigger nessus plugins. This firewall allows filters to be placed on the various interfaces much like a common packet filtering firewall which is often used to reduce firewall load and exposure (packets dropped before reaching the proxies) but if no filters are in place then you will see, at the very least, open ports associated with all 12 of the native proxies handling the common protocols like http, ftp, telnet, smtp, nntp, rtsp, dns, ntp, cifs, nbdgram, ping, h323, and other ports handled by the gsp proxy. Just because the ports appear "open" though doesn't mean you're talking to anything other than the firewall's proxies. If rules allow traffic, the native proxies will do their thing which is to inspect packets for rfc compliance and other payload specific tests and either accept or reject the traffic. If the traffic is accepted, the packets are repackaged and passed on to the destination. The difference between the native proxies and the gsp proxy is no rfc payload testing occurs with the gsp. Some basic sanity checks are still performed such as tcp flag settings, src/dst addressing, etc. but that's pretty much it as I recall.
As Ron suggested, quite a few of the CVEs you listed are associated with the standard MS networking ports 139, 445 and perhaps 135. Chances are pretty slim that these ports would truely be opened to the outside segment without some serious restrictions. But if they were, the cifs proxy (139,445) is configurable at the rule level to restrict certain types of cifs connections which could potentially affect test results as well. A more typical scenario is to have a web, ftp, or smtp service running on one of the fw's aux interfaces opened up to the outside in which case you most likely can make connections to these services either with nessus or other means and conduct tests, exploits, etc. But interpretation of the results is not always simple and straightforward depending on the version of the fw software and other components that may be licensed on the fw such as AV, IDS/IPS, and Content Filtering. Even on the earlier versions of the fw software, an administrator could assign url filtering, for instance, to the http proxy which helped blocked common exploits - granted it did not handle encoded data but if you didn't enable nessus' ids evasion features many of the nessus tests would trigger these filters IF they were enabled. This would show up in the fw logs as "packet denied matched url filter at line ..." or something like that and the nessus report would, of course, report no associated vulnerabilities (packets dropped by fw). Newer versions with IDS/IPS may block the traffic depending on the configuration. The IDS/IPS component installs with some default settings blocking the most aggregious traffic and others are just logged so again you would have to compare logs to the report. As Ron mentioned, you'll need to compare results with fw logs and application logs on the targets to clarify findings. I reported a vulnerability to the Symantec group years ago involving the http proxy cause it crashed during some nessus testing I was conducting with a client. Nessus results didn't reflect the crash and the fw did what it was designed to do in this situation, respawn the daemon (proxy) so without reviewing the fw logs we wouldn't have known about this. Greg Smith, <GSEC Gold> Cyber Crews, Inc. _______________________________________________ Nessus mailing list [email protected] http://mail.nessus.org/mailman/listinfo/nessus
