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

"Jim Harrison (ISA SE)" <jmharr@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:30BF0330-ECE4-492B-B04F-507B4B2BC3BA@xxxxxxxxxxxxxxxx
The rules aren't "compiled".

When you make changes to firewall rules and "Apply" them, you get a modal
dialog that announces the changes are being "applied". A compiler is a
program that converts text written in one language to some target form.
Surely ISA doesn't store the firewall rules in a human-readable form. So
in the broadest sense the human readable version of the firewall rules must
be getting converted to *some* other form. That meets my test for what
compilation mean. It would be good to know what the more formal terms ISA
uses for the source and "applied" versions of firewall rules, but I think we
are just saying the same things using different words.


One thing that can affect performance for URL and domain sets is name
resolution.
ISA will attempt to perform fwd and rev resolution for these to ensure
that
IP-based requests aren't used to circumvent name-based policies.
If the destination doesn't have PTR records, then these failures can take
a
bit of time.

Without a large domain name set, our firewall rules compile in under 30
seconds. Adding in several domain name sets that each have thousands of
domain names in them, now the firewall rules take about four minutes to
"apply". Run time performance seemed acceptable. It was just the time
to "apply" (my word "compile") the rules with large domain name sets that I
was objecting to.


The reason I discourage the use of hosts file games is that they quickly
become unwieldy and completely circumvent ISA policy structure.

I guess one could assign groups of host names that are the same type of
target site in the hosts file to a unique IP that is an internal web server.
As long as you had as many unique target web server IPs as you do types of
sites, you should be able to create ISA rules to align to those IP targets.
So one could by some design and discipline at least create some cooperation
between the hosts file usage and the ISA rules.

I do understand your point on the hosts file being a very cumbersome vehicle
for long term maintenance of many such hosts.

--
Will


"Will" <westes-usc@xxxxxxxxxxxxxx> wrote in message
news:zsidnSNZb79bf57VnZ2dnUVZ_v2pnZ2d@xxxxxxxxxxxxxxx
"Jim Harrison (ISA SE)" <jmharr@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:up2HHJlnIHA.5472@xxxxxxxxxxxxxxxxxxxxxxx
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.

We did try it that way, using domain name sets, and our general conclusion
was the performance - particularly the time required to compile the
rules -
is not very good.

What are the reasons you object to using Hosts file to optimize
performance?

--
Will


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