We have lots of users with SonicWalls for VPN connectivity in to FW-1, possible major security hole
From: Mark J. DeFilippis (mark.defilippis@mycroftinc.com)Date: 03/08/02
- Previous message: Matt Zimmerman: "sshd: PAM pam_set_item: NULL pam handle passed"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 08 Mar 2002 13:14:10 -0500 To: incidents@securityfocus.com From: "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
- Previous message: Matt Zimmerman: "sshd: PAM pam_set_item: NULL pam handle passed"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
