Darrell, MSBLAST easily found the NT machine over one-to-one NAT. Despite the 'deny WAN to anything', adding just one rule to allow a single IP does potentially allow any service exploit to occur.
Incidentally, the second rule should have been interpreted as 'deny RPC from WAN to any'. The asterisk in this context represents the physical ports on the SonicWall. My ambiguous bad. The main thing I learned (again) here was that service-specific rules have priority over all-service rules. Regards -- David McRell on 8/14/2003 9:46 PM, Darrell Shandrow at [EMAIL PROTECTED] wrote: > Hi David, > > I don't think that first rule, deny * > RPC, should be necessary since > everything is already denied inbound from the WAN unless it has already been > opened in the state table from inside the LAN. The second rule could sure > help if something in your LAN has somehow gotten infected. The question is, > how could that happen? One possible answer that does not point to the > SonicWALL could be the connection of laptops that are also connected to > unprotected networks in other locations, such as when dialing up from remote > locations or on an unprotected home network. >> DENY * > WAN 'RPC Service' >> DENY WAN > * 'RPC Service' >> >> Consider that my existing rules deny ALL incoming WAN connections except for >> a few IPs and small ranges. Goes to show that was not an effective defense. >> Now I realize that to deny all ports except the ones we need is impossible - >> or is it? --- [This E-mail scanned for viruses by Declude/F-Prot AV] =================================================================================================== To unsubscribe, send email to [EMAIL PROTECTED] In the body of the email put the following: unsubscribe sonicwall your_name The archive of this list is at http://www.mail-archive.com/sonicwall%40peake.com/
