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

From: Mark DeFilippis (
Date: 10/25/03

  • Next message: Damian Gerow: "Re: New Trojan"
    Date: 25 Oct 2003 14:46:52 -0000
    ('binary' encoding is not supported, stored as-is) In-Reply-To: <>

    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.


    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 (HELO (
    > by with SMTP; 9 Mar 2002 00:31:01 -0000
    >Received: from ( [])
    > by (Postfix) with QMQP
    > id D7289A374B; Fri, 8 Mar 2002 14:44:03 -0700 (MST)
    >Mailing-List: contact; run by ezmlm
    >Precedence: bulk
    >List-Id: <>
    >List-Post: <>
    >List-Help: <>
    >List-Unsubscribe: <>
    >List-Subscribe: <>
    >Delivered-To: mailing list
    >Delivered-To: moderator for
    >Received: (qmail 8484 invoked from network); 8 Mar 2002 18:12:34 -0000
    >Message-Id: <>
    >X-Mailer: QUALCOMM Windows Eudora Version 5.1
    >Date: Fri, 08 Mar 2002 13:14:10 -0500
    >From: "Mark J. DeFilippis" <>
    >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
    >The firewall gateway LAN address is
    >The firewall WAN address is
    >A NT server on the internal LAN is
    >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,53 WAN,5470 WAN
    >22:02:13.784 ICMP packet
    >dropped,3,LAN,3,WAN Dest
    >Unreachable 26
    >22:03:43.800 UDP packet dropped,53
    >WAN,5470 WAN
    >22:03:43:816 ICMP packet
    >dropped,3,LAN,3,WAN Dest
    >Unreachable 26
    >22:05:13.864 UDP packet dropped,53
    >WAN,5470 WAN
    >22:05:13.864 ICMP packet
    >dropped,3,LAN,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 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!
    >Mark J. DeFilippis
    >Sr. Network Architect
    >Mycroft Information Systems
    >Mark J. DeFilippis
    >Mycroft Inc -
    >12 E 44th St
    >New York, NY 10017
    >Tel: 212-632-1928
    >Cell: 516-330-3809
    >Fax: 561-264-3101
    >#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:

    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
    and use priority code SF4.

  • Next message: Damian Gerow: "Re: New Trojan"

    Relevant Pages

    • Re: Satellite Branch Office Woes
      ... I would suggest putting a domain controller with DNS in the site. ... AD client ... servers in the SBO) for several small locations that will be coming online ... WAN configuration issue. ...
    • Re: Bad packets and invalid domain names Please help
      ... At any rate, it isn't clear whether these errors, or DNS at all, has anything to do with your issues. ... > Source DNS ... > The DNS server has encountered numerous run-time events. ... > The DNS server encountered a bad packet from X.X.X.X. ...
    • We have lots of users with SonicWalls for VPN connectivity in to FW-1, possible major security hole
      ... With default rule disabled: Disable default Src: LAN Dst: ALL ... The firewall WAN address is ... A NT server on the internal LAN is ... why is my internal server responding to this packet as a "Destination ...
    • Re: Neotrace program snoops on me
      ... >> DNS servers. ... A client starts a traceroute to some computer. ... the TTL field in the IP packet by one. ... > those hops from McAfee's database. ...
    • Re: Cannot ping Active Directory Domain Name
      ... This is not the WAN DCand also from another subnet, but should be the WAN DC. ... The WAN domain controller and the LAN domain controller are on the ... Connection-specific DNS Suffix. ... Ipconfig from LAN Domain Controller: ...