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.
Received: (qmail 2963 invoked from network); 9 Mar 2002 00:31:01 -0000 Received: from outgoing3.securityfocus.com (HELO outgoing.securityfocus.com) (66.38.151.27) by mail.securityfocus.com with SMTP; 9 Mar 2002 00:31:01 -0000 Received: from lists.securityfocus.com (lists.securityfocus.com [66.38.151.19]) by outgoing.securityfocus.com (Postfix) with QMQP id D7289A374B; Fri, 8 Mar 2002 14:44:03 -0700 (MST) Mailing-List: contact incidents-help () securityfocus com; run by ezmlm Precedence: bulk List-Id: <incidents.list-id.securityfocus.com> List-Post: <mailto:incidents () securityfocus com> List-Help: <mailto:incidents-help () securityfocus com> List-Unsubscribe: <mailto:incidents-unsubscribe () securityfocus com> List-Subscribe: <mailto:incidents-subscribe () securityfocus com> Delivered-To: mailing list incidents () securityfocus com Delivered-To: moderator for incidents () securityfocus com Received: (qmail 8484 invoked from network); 8 Mar 2002 18:12:34 -0000 Message-Id: <5.1.0.14.2.20020308131249.00adb598 () pop business earthlink net> X-Sender: defilippismark%mycroftinc.com () pop business earthlink net X-Mailer: QUALCOMM Windows Eudora Version 5.1 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)