But I didnt want to have to waste my time spoon feeding you with the fact that many of
our collegues use products that can be subverted by dwords and similar tactics, and
thus it IS a valid topic to be discussed in this forum...
cheers..
>>> mouss <[EMAIL PROTECTED]> 04/24 10:58 AM >>>
At 09:10 24/04/01 -0700, Network Operations wrote:
>Exactly Carl, I didnt really want to get into a fencing match with Paul,
>but ...
but what? Paul is right in what he says.
The fact that Websense is buggy doesn't change anything:)
The correct way to do it is something like this:
assume you want to match a URL "u" with a balacklisted URL "b".
then first decompose each of them to the base components:
scheme (http, ftp, ...)
server (either a hostname or an IP address)
port
path
[scheme]
the scheme is obvious to match if one keeps in mind that if not present, it
should
be automatically computed ffrom the port (so 80 defaults to http and so on)
[server]
for the server, there are 4 cases:
1. If both use numeric IP addresses, then convert to binary and do an
arithmetic
comparison. the basic thing is an IP address X is in a network specified by an
address A and a netmask M if (x & M) = (A & M). smart guys convert A to
A&M in
the first place, so only one & (bitwise and) is needed.
2. both "u" and "b" use hostname based expressions. then the usual regex
matching
is used. so www.playboy.com matches *.playboy.com
3. If "b" uses numeric addresses and "u" specifies a hostname, then the
hostname is to be
converted to an IP address, then do like in 2.
4. if "b" uses a hostname expression and "u" a numeric address, the
address is to be converted
to a hostname (reverse lookup) and compared. There is a trick though: an
IP address may have
many hostnames. so this must be repeated until a match is found or all
hostnames have been
tried.
[port]
ports are easy to match. convert both to numeric representation (may need
getservbyname,
or the use of a proprietary replacement for /etc/services) and compare the
numbers.
if the port is not specified in the URL, then either the scheme dictates a
default port, or 80
the one
[path]
the path must first be converted to a simple form (replace the %things) and
regex match is
used.
More details may be found in the URI (or URL?) RFC.
so all this is known since a long time, has been coded and documented. but
still, people
write flawed software.
cheers,
mouss
> >>> "Carl E. Mankinen" <[EMAIL PROTECTED]> 04/24 8:15 AM >>>
>The reason to get use this type of URL is to get around filters like
>WebSense or to make it harder for people to use tools like
>ARIN/WHOIS etc, to report abuse.
>.
>I am sure the LATEST version of WebSense blocks this, but when I did
>testing with versions prior to 4.3
>and several other filtering products, I found that the blocking did not
>always work:
>
>http://www.playboy.com result, access denied.
>nslookup www.playboy.com
>http://209.247.228.201 result, access allowed
>http://3522684105 result, access allowed.
>
>
>----- Original Message -----
>From: "Paul D. Robertson" <[EMAIL PROTECTED]>
>To: "Network Operations" <[EMAIL PROTECTED]>
>
> > I'm not sure how you drew this conclusion? For anything that's not doing
> > a direct string match, unless it's incredibly poorly written software, the
>
>
>-
>[To unsubscribe, send mail to [EMAIL PROTECTED] with
>"unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
