Re: Best Practice for Using MVPS HOSTS File on ISA Server?

Don't ever use the hosts file to second-guess the ISA rules engine.
This is an old idea that was used in the "openaport" firewall days to work
around the limited rules engines available at the time.
Instead, import these destinations into a domain or computer set and include
those in a "deny" rule.

--
Jim Harrison (ISA SE)

This posting implies no warranty and confers no rights.
http://catb.org/~esr/faqs/smart-questions.html



"Will" <westes-usc@xxxxxxxxxxxxxx> wrote in message
news:VvydnfbZuN90i27anZ2dnUVZ_hmtnZ2d@xxxxxxxxxxxxxxx
After reading an article that claimed that the MVPS HOSTS file could be
installed on ISA Server 2004 to block all connects to advertising servers
there, I decided to try it as an experiment, and it presents a few issues on
which I would like advice.

The problem is that the MVPS hosts file sets the IP address of well known
advertising domains to 127.0.0.1. Now when a web proxy user connects to a
web page that tries to display advertising, the advertisements result in web
connection attempts to 127.0.0.1 by ISA. The following problems present:

1) For whatever reason, the connection attempts to 127.0.0.1 are being
reported on the web proxy clients as "timed out" connections, and the pages
with advertising take a long time to draw as a result. I "corrected"
this by adding a computer object for 127.0.0.1, and then adding a deny rule
for anyone trying to connect by http/https to that object. I don't like
this solution. 127.0.0.1 is normally a special reserved address and I
don't like having to add it into the ruleset. It did appear to solve the
problem with performance, but it may have other unintended side effects, so
I would appreciate the thinking of others on a better way to handle the
issue. I'm not keen on running a web server on the ISA Server to serve out
an image when connecting to 127.0.0.1, but maybe there is another way to
accomplish the desired effect here.

I suppose we could modify the HOSTS file to point to an internal web server
IP and server an image from that. I'd rather not set up a special web
server, so perhaps ISA has a way to create a virtual server or redirect
requests to specific IPs to some specific result image or page?

2) I found it very odd, but when at the ISA Server 2004 console, attempts to
telnet to 127.0.0.1 port 80 immediately fail. When the connection takes
place to the same address by a remote user through web proxy, the connection
times out instead (prior to my adding a failure rule). So 127.0.0.1
appears to be getting some inconsistent handling based on context of the
request.

3) Most disturbing, attempts to connect to 127.0.0.1 through web proxy
clients ARE NOT SHOWING IN THE MONITOR LOG. That has to be a bug. And
doesn't that suggest an attack vector that someone could use to try to break
into ISA Server? The person launching the attack could simply issue
attacks through web proxy by going to any web server he controls, to a page
that he authors, which contains embedded URLs that would be resolved by the
proxy server to 127.0.0.1. Any mal-formed URL going to 127.0.0.1 would be
invisible to the administrator because of this hole in the ISA Server
logging that fails to record such traffic.

Granted, even exploiting this hidden back end, it's not clear the attacker
could compromise anything, but its not a great situation so I'm anxious to
find a more normal way of handling this traffic.

--
Will


.

Relevant Pages
Loading