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
swozny@i'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
Nessus@list.nessus.org
http://mail.nessus.org/mailman/listinfo/nessus
