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

["Mark J. DeFilippis" <mark.defilippis () mycroftinc com>]

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