Re: Bypassing website filter in SonicWall

["Justin King" <justin () othius com>]

Why are people constantly focusing on reverse lookups in this thread? How
does this make sense? How often are reverse lookups really accurate for web
servers?

I think it would be better for this software to keep the list of domains,
and routinely do *forward* lookups, and add the IPs to a blacklist.

For instance, you could look up www.google.com every two hours, and
blacklist every IP returned with a two to four hour timeout. In addition,
still check the http host header.

Further, the firewall could filter dns requests and stop any relating to an
invalid domain. Obviously, it's near impossible to allow all except a few,
but forward lookups with IP blacklisting seems to make a lot more sense than
reverse lookups on every request.

-Justin

> -----Original Message-----
> From: Marc Ruef [mailto:marc.ruef () computec ch]
> Sent: Tuesday, October 29, 2002 2:36 PM
> To: bugtraq () securityfocus com; news () securiteam com
> Subject: Bypassing website filter in SonicWall
>
>
> Hi!
>
> I found a little weakness in SonicWall: I turn on the blocking
> mechanism for websites (e.g. www.google.com). Now I can't reach
> the website using the domainname. But if I choose the IP address of the
> host (e.g. http://216.239.53.101/), I can contact the forbidden
> website. The same issue I've discovered for NetGear FM114P in
> http://online.securityfocus.com/bid/5667
>
> It would make sense if you can do an internal nslookup. Otherwise the
> user can do a workaround and adding always the ip address(es) of the
> blocked websites. But this can cause some problems if there were some
> virtual hostings. A smart attacker can use some dottless-ips to bypass
> the new workaround IP filter. The box will sadly loose performance
> because of the additional filter line(s).
>
> My description was sent on 02/10/15 to info () sonicwall com - No response
> came back. The blocking URL message style and problem reminds my the
> website blocking mechanism by NetGears FM114P. It could be that both
> use the same mechanism (by a 3rd party?). So, if the bug is fixed for
> one box the other will also be fixed - I think so.
>
> Bye, Marc