> Esteemed members of the mailing list, > > I'm getting some output from a /28 network scan on the Internet I > can't seem to reconcile and wanted to see if anyone else had seen > anything similar. > > I have a 16 address space provided by the ISP for DMZ services > X.Y.Z.48/28. Only thing that should be reporting back is X.Y.Z.49 TCP > 25 for the inbound mail server as that's the only NAT configured on > the outside interface of the firewall. When I run the scan against > the /28 net with Safe Checks on, I see what I expect to see. FYI, the > outside interface address itself is not in this /28 address space and > Nessus reports that it can get little information which is what I > wanted to see. > > Since this network is not production yet, I decided to rescan with > Safe Checks turned off. My initial results back from this scan are > below (abbreviated because the full results exceed the list server > size limit; if you want them, email me). So now I'm seeing all sorts > of crazy DoS signatures trip and claim the firewall (which it > mis-characterized as an Ascend Router sometimes) was able to be > crashed which it wasn't (system up time shows no interruption). So I > scanned again while pinging the inside interface of the firewall and > started losing a significant percentage (but not all) responses. Now, > I'm willing to accept that the firewall is dropping pings because it's > a low priority process and the firewall had better things to do, but > I've asked the vendor if they've seen this before (no response yet). > > So, I'm seeing results inconsistent with NMAP and another commercial > vulnerability scanner which both showed me what the Nessus safe checks > showed me. The next step was to see if Nessus is being consistent > with itself. While Nessus is still reporting various and sundry DoS > vulnerabilities, the results are different (due to message size > constraints I couldn't attach the results; if you'd like them, email > me). > > So, after all that lead up, here is my question. Have any of you seen > crazy results from running scans against NAT pools with Safe Checks > turned off? I can imagine the non-safe-checks aren't as well debugged > as the safe checks because they probably don't get used in production > environments as often, but I thought I'd see if anyone had seen this > before. I don't want to post the firewall vendor's name here as > they're still getting back to me, but if you think you've seen this > and want to confirm the vendor ping me directly off list. > > Thanks for any help you may be able to provide, > > Scott A. Wozny > Deloitte > [EMAIL PROTECTED]'m_pretty_sure_you_can_figure_it_out.com > > Original Scan: > > NESSUS SECURITY SCAN REPORT > > Created 16.11.2007 Sorted by host names > > Session Name : CLIENT x.x.x.x Hosts > Start Time : 08.11.2007 14:34:44 > Finish Time : 08.11.2007 15:04:11 > Elapsed Time : 0 day(s) 00:29:26 > > > Total security holes found : 30 > high severity : 10 > Medium severity : 0 > informational : 20 > > > Host: REDACTED.48 > > Open ports: > > discard (9/udp) > > > Service: discard (9/udp) > Severity: High > > It was possible to make > the remote Ascend router reboot by sending > it a UDP packet containing special data on > port 9 (discard). > > An attacker may use this flaw to make your > router crash continuously, preventing > your network from working properly. > > Solution : filter the incoming UDP traffic coming > to port 9. Contact Ascend for a solution. > > Risk factor : High > CVE : CVE-1999-0060 > BID : 714 > > > > ---------------------------------------------------------------------- > ---- > > > Host: REDACTED.49 > > Open ports: > > smtp (25/tcp) > discard (9/udp) > > > Service: discard (9/udp) > Severity: High > > It was possible to make > the remote Ascend router reboot by sending > it a UDP packet containing special data on > port 9 (discard). > > An attacker may use this flaw to make your > router crash continuously, preventing > your network from working properly. > > Solution : filter the incoming UDP traffic coming > to port 9. Contact Ascend for a solution. > > Risk factor : High > CVE : CVE-1999-0060 > BID : 714 > > > Service: general/tcp > Severity: Info > > > Synopsis : > > The remote service implements TCP timestamps. > > Description : > > The remote host implements TCP timestamps, as defined by RFC1323. > A side effect of this feature is that the uptime of the remote > host can be sometimes be computed. > > See also : > > http://www.ietf.org/rfc/rfc1323.txt > > Risk factor : > > None > > > Service: general/tcp > Severity: Info > > > Synopsis : > > The remote host is behind a firewall > > Description : > > Based on the responses obtained by the TCP scanner, it was possible to > determine that the remote host seems to be protected by a > firewall. > > Solution : > > None > > Risk factor : > > None > > > > ---------------------------------------------------------------------- > ---- > > > Host: REDACTED.52 > > Open ports: > > > > Service: general/tcp > Severity: High > > > It was possible to crash the remote host by sending a specially > crafted IP packet with a null length for IP option #0xE4 > > An attacker may use this flaw to prevent the remote host from > accomplishing its job properly. > > Risk factor : High > CVE : CVE-2005-2577 > BID : 7175, 14536 > > > > ---------------------------------------------------------------------- > ---- > > > Host: REDACTED.53 > > Open ports: > > > > Service: general/tcp > Severity: High > > > It was possible to make the remote server crash using the 'teardrop' > attack. > > An attacker may use this flaw to shut down this server, thus > preventing your network from working properly. > > Solution : contact your operating system vendor for a patch. > Risk factor : High > CVE : CVE-1999-0015 > BID : 124 > Other references : OSVDB:5727 > > > Service: general/tcp > Severity: Info > > > Synopsis : > > The remote host is behind a firewall > > Description : > > Based on the responses obtained by the TCP scanner, it was possible to > determine that the remote host seems to be protected by a > firewall. > > Solution : > > None > > Risk factor : > > None > > > > ---------------------------------------------------------------------- > ---- > > > Host: REDACTED.54 > > Open ports: > > > > Service: general/tcp > Severity: High > > > It was possible to disconnect the remote > host by sending it an ICMP echo request packet > containing the string '+ + + ATH0' (without the spaces). > It is also possible to make the remote modem > hangup and dial any phone number. > > Solution : add 'ATS2=255' in your modem > init string. > > Risk factor : High > CVE : CVE-1999-1228 > > > > ---------------------------------------------------------------------- > ---- > > > Host: REDACTED.55 > > Open ports: > > > > Service: general/tcp > Severity: Info > > > Synopsis : > > The remote host is behind a firewall > > Description : > > Based on the responses obtained by the TCP scanner, it was possible to > determine that the remote host seems to be protected by a > firewall. > > Solution : > > None > > Risk factor : > > None > > > Service: general/tcp > Severity: Info > > Information about this scan : > > Nessus version : 3.0.5 (Nessus 3.0.6 is available - consider > upgrading) > > Plugin feed version : 200711081035 > Type of plugin feed : Registered (7 days delay) > Scanner IP : REDACTED > Port scanner(s) : nessus_tcp_scanner > Port range : 1-65535 > Thorough tests : no > Experimental tests : no > Paranoia level : 1 > Report Verbosity : 1 > Safe checks : no > Optimize the test : yes > Max hosts : 16 > Max checks : 10 > Scan Start Date : 2007/11/8 14:35 > Scan duration : 1184 sec > > > >
This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. [v.E.1]
_______________________________________________ Nessus mailing list [email protected] http://mail.nessus.org/mailman/listinfo/nessus
