Security Incidents mailing list archives

Re: We have lots of users with SonicWalls for VPN connectivity in to FW-1, possible major security hole

From: Mark DeFilippis <defilm () acm org>
Date: 25 Oct 2003 14:46:52 -0000

In-Reply-To: <5.1.0.14.2.20020308131249.00adb598 () pop business earthlink net>


I saw this still hanging out on the Site and I wished to follow-up with
information provided by Support at Sonicwall.

The resulting issue was essentially a DOS attack, and there was no work
around.  A faster processor in the current Sonicwall firewalls has helped
but for the existing SOHO2's still in use out there, the issue was that
DNS name resolution on the fly was enabled for Logging.

Ultimately, when these packets were received, the port was blocked (since all default traffic outbound was disabled) 
resulting in a log entry.
The Sonicwall would attempt to resolve the Source Ip from DNS, and when
the resulting DNS response was SLOW, Stateful inspection would fail for the late response, resulting in a very 
overworked Sonicwall, resulting in an effective DOS attack.

Recommendations from Sonicwall were:

1. Provide a local DNS that cached the IP's so additional DNS lookup responses were not slow causing the stateful 
inspection to fail.

2. Disable real-time DNS resolution while logging.

In most cases we chose the 2nd option.

Regards

Mark J. DeFilippis

PS. Under heavy load and heavy load of the DNS server we have been
able to reproduce this on the Sonicwall SOHO-3's, although with the process speed increase, it is much more difficult 
to produce.

Mailing-List: contact incidents-help () securityfocus com; run by ezmlm
Precedence: bulk
Message-Id: <5.1.0.14.2.20020308131249.00adb598 () pop business earthlink net>
Date: Fri, 08 Mar 2002 13:14:10 -0500
To: incidents () securityfocus com
From: "Mark J. DeFilippis" <mark.defilippis () mycroftinc com>
Subject: We have lots of users with SonicWalls for VPN connectivity in
 to FW-1, possible major security hole
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

We use Sonicwall SOHO2 / SOHO3 devices for VPN connectivity to our core 
running FW-1.
The following came  to our attention recently, and I was interested if 
anyone has seen something
similar when using these devices.

With default rule  disabled:  Disable default Src: LAN   Dst: ALL
This rule is the last rule (default) and number 26 which allows any traffic 
to pass from the LAN to the WAN.

We stop packets going out from the LAN on ports we don't know about.
In this case the DNS server is 167.206.7.4
The firewall gateway LAN address is 192.168.1.1
The firewall WAN address is 24.184.168.52
A NT server on the internal LAN is 192.168.1.22
There is NO Public IP address configured for ANY service

Recently in a Hub based cable modem environment we found the following:

                             Message                          Source 
                   Destination                       Notes 
 Rule                  22:02:13.768          UDP packet 
dropped         167.206.7.4,53 WAN       24.184.168.52,5470 WAN
22:02:13.784          ICMP packet 
dropped        192.168.1.22,3,LAN        167.206.7.4,3,WAN            Dest 
Unreachable 26
22:03:43.800          UDP packet dropped         167.206.7.4,53 
WAN       24.184.168.52,5470 WAN
22:03:43:816          ICMP packet 
dropped        192.168.1.22,3,LAN        167.206.7.4,3,WAN            Dest 
Unreachable 26
22:05:13.864          UDP packet dropped         167.206.7.4,53 
WAN       24.184.168.52,5470 WAN
22:05:13.864          ICMP packet 
dropped        192.168.1.22,3,LAN        167.206.7.4,3,WAN            Dest 
Unreachable 26

It continues for what appears every 30 seconds.  My problem is if the DNS 
inbound packet is really dropped,
why is my internal server responding to this packet as a "Destination 
Unreachable". (Note that I allow
LAN to WAN  Ping request and response to pass, but not ICMP type 3.  So it 
is blocking the packet out
to the internet.  My question is why it should have ever received any 
packed based on the DNS packet in the
first place????

BTW - The server 192.168.1.22 is a Win2K AS NT server with DNS Server and 
Client disabled.  No routing
or other services enabled.  It is not even a part of a domain, it is in a 
simple workgroup.  This may have no
bearing on the problem, but I figure if the packet was stopped at the WAN 
interface, it should not have generated
a packet on the LAN that a server responded to with a "Dest Unreachable" 
ICMP type 3!!

Most people run the Sonicwall's with the "Default" LAN to any enabled, so 
they wouldn't even see this
under normal conditions.  I disable default when I found a shareware 
utility running on my network was
communicating system and Network information out port 63002 to a specific 
Host IP.  Then there was
"GameSpy" doing something similar....  So now I block all unknown LAN to 
WAN communications.

Any thoughts on this behavior?  I consider this a serious security 
flaw.  If my Checkpoint FW-1 dumped a packet
and generated a "reaction" packet on my internal LAN because of the 
external dropped packet, I would
be banging at Checkpoint's door!

Thanks

Mark J. DeFilippis
Sr. Network Architect
Mycroft Information Systems

--------------------------

Mark J. DeFilippis
Mycroft Inc - www.mycroftinc.com
12 E 44th St
New York, NY 10017
Tel: 212-632-1928
Cell: 516-330-3809
Fax: 561-264-3101
mark.defilippis () mycroftinc com

#include <std/disclaimer.h>
In no way does my opinion reflect the opinion of my employer unless 
explicitly stated

----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management 
and tracking system please see: http://aris.securityfocus.com


---------------------------------------------------------------------------
Network with over 10,000 of the brightest minds in information security
at the largest, most highly-anticipated industry event of the year.
Don't miss RSA Conference 2004! Choose from over 200 class sessions and
see demos from more than 250 industry vendors. If your job touches
security, you need to be here. Learn more or register at
http://www.securityfocus.com/sponsor/RSA_incidents_031023
and use priority code SF4.
----------------------------------------------------------------------------

Current thread:

Re: We have lots of users with SonicWalls for VPN connectivity in to FW-1, possible major security hole Mark DeFilippis (Oct 27)