ISAserver.org Newsletter of July 12th 2001

http://www.isaserver.org

Isaserver.org Newsletter
July 12th, 2001

In this issue:

**Feature: Using Packet Filters
**Tip of the Week
**Post of the Week
**ISA Server link of the week
**Ask Dr. Tom
**To the Editor

===============================
Welcome to the first edition of the Isaserver.org newsletter! Each week
we will bring you interesting and helpful information on ISA Server.
Since we are just beginning the newsletter we would like to ask all of
you what it is that *you* are interested in hearing about. Please send
your suggestions for future newsletter content to: tshinder@isaserver.org
===============================

**Feature: Using Packet Filters**
By Thomas W Shinder, M.D., MCSE, etc.

1. Overview
2. When Should Packet Filtering Be Enabled?
A. Servers at the Edge of the Network
B. Packet Filtering for Trihomed DMZs
C. Packet Filtering for Services and App's
3. When Should Packet Filters Not Be Used?
A. To Control Outbound Access
B. To Control Inbound Access
4. Summary

-----------------------------------------
1. Overview
-----------------------------------------
ISA Server uses packet filtering to control inbound and outbound access
on the external interface of the ISA Server. The packet filtering
mechanism is the ISA Server's first line of defense against inbound
attacks. The ISA packet filtering feature supplements the RRAS packet
filtering and you should not run both on the same machine. If you have
RRAS packet filtering enabled, you should disable it now.

In order to have packet filtering work, you have to enable it. To check
on whether packet filtering has been enabled, right click on the "IP
Packet Filters" node in the left pane of the ISA Server Management
console and click "Properties". On the "General" tab put a checkmark in
the "Enable packet filtering" checkbox to activate packet filtering.

Packet Filtering is only available when you are running the Firewall
Service. The Firewall Service is available when you install ISA Server
in either Integrated or Firewall only mode. If you install ISA Server in
Cache mode only, yu will not be able to implement packet filtering.

-----------------------------------------
2. When should I enable packet filtering and when do I create packet
filters?
-----------------------------------------

You should enable packet filtering in the following situations:

*When the ISA Server is at the edge of the network
*When you configure a trihomed ISA Server
*When you need to run services and applications on the ISA Server

When you enable packet filtering, ISA Server closes off all ports on the
external interface that do not have packet filter explitly created to
allow inbound and/or outbound access. If you have packet filtering
enabled and you have *no* packet filters, then there will be no inbound
or outbound access unless you have created Protocol or Publishing rules.

-----------------------------------------
A. Edge of Network Servers
-----------------------------------------

Packet filtering should always been enabled when the ISA Server is at
the edge of the network. When the ISA Server has an interface with the
Internet, you can make sure that no ports are open inadvertently by
enabling packet filtering. By default, the only traffic that will be
allowed when packet filtering is enabled are some ICMP filters required
for basic network management, and the DNS filter which allows the ISA
Server to make DNS queries on the behalf of ISA Server clients on the
internal network.

-----------------------------------------
B. Packet Filtering for DMZ Servers
-----------------------------------------

If you create a trihomed ISA Server with a DMZ segment you need to
enable packet filtering and configure packet filters. Traffic to and
from the DMZ segment is controlled by the use of packet filters. If
there is no filter that allows the traffic into or out of the DMZ, then
the traffic will be blocked at the external interface of the ISA Server.

A special note regarding the configuration of the packet filters for the
DMZ segment. A few people have said that when they configure a filter to
allow "all IP traffic" to and from the trihomed DMZ segment, that it
does not work. That is true. You must create individual packet filters
to move traffic into and out of the DMZ segment. However, ISA Server
does create dynamic packet filters so you do not have to create filters
for response ports.

-----------------------------------------
C. Packet Filtering for Services and App's on the ISA Server
-----------------------------------------

Services and Applications running on the ISA Server require packet
filters. For example, if you want to run a mail client use as Outlook
Express on the ISA Server itself, you must create a packet filter for
outbound access to TCP Port 25 and TCP Port 110 at a minimal in order to
allow access to external SMTP and POP3 servers. You can add other packet
filters such as TCP 119 for NNTP or TCP 143 for IMAP access.

An exception to this is the web browser running on the ISA Server
itself. In this case, you can configure the web browser to be a Web
Proxy client. Be careful about your web proxy configuration on the Web
Browser if you are using a dial-up connection. The Web Proxy client
configuration for the web browser on an ISA Server using a dial-up
connection is difference than the configuration for ISA Server's using a
dedicated connection. Check my article regarding this issue at
www.isaserver.org/shinder for more information.

-----------------------------------------
3. When Should I Not Create Packet Filters?
-----------------------------------------

Packet filters should not be used for the following purposes:

*To control inbound access to internal network services
*To control outbound access for ISA Server clients

I find that a lot of people posting on the www.isaserver.org message
boards claim that they must create packet filters to make their access
policies work correctly. This is not the case.

-----------------------------------------
A. Packet Filters and Inbound Access Control
-----------------------------------------

Access to servers on the internal network is configured by using either
Server Publishing or Web Publishing rules. These rules allow you to
"publish" servers to external network users. When you create the
publishing rules, ISA Server will open the ports required to allow
access to the internal servers.

There seems to be a misconception that you need to manually enable
packet filters for these rules to work. This is not the case. You can
confirm that the Publishing Rule you create has opened up the port of
interest by running the command:

netstat -na

In the output, scroll up to the entries for the external interface of
the ISA Server and see what ports it is listening on. You should see the
Port for the service that you published. If you don't see this port
opened, there may have been a server publishing failure.

If you have a Server Publishing failure, make sure that that IIS
services are not contenting for the same port. For example, if you are
trying to publish an SMTP or NNTP server and you get a server publishing
failure, make sure that the IIS SMTP and NNTP services or disabled. Do
not try to change the port on these services, as IIS socket pooling will
prevent your change from working. For more info on Socket Pooling, check
out my article on this subject at www.isaserver.org/shinder.

If your web publishing rules fail, make sure the Inbound Web Requests
listener if configured correctly. Make sure that the WWW service on the
IIS server is not listening on Port 80. Again, its important that you
disable Socket Pooling if you wish to use the IIS WWW on the ISA server
itself.

-----------------------------------------
B. Packet Filters and Outbound Access Control
-----------------------------------------

Outbound Access Control for ISA Server clients should be done with
Protocol Rules and Site and Content Rules. However, only the Protocol
Rules have influence on Port access, since Site and Content rules are
focused only on site names.

When a Protocol Rule is created, ISA Server will allow inbound and
outbound access to the ports specified in the rule. You should never
need to create packet filters to support your Protocol Rules. If the
Protocol Rule is not working, then you should check for other factors
that may be causing this situation.

Something to keep in mind regarding Protocol Rules is that if you enable
a rule that allows "All IP Traffic, it will work differently depending
on what type of client is accessing that rule. Firewall Client computers
will have outbound access to all TCP/UDP ports, but SecureNAT clients
only have access to the protocols that are specified in the Protocol
Defintions that are configured in the ISA Server.

-----------------------------------------
3. Summary
-----------------------------------------

Packet filters are used to control inbound and outbound access on the
external interface of the ISA Server. When packet filtering is enabled,
a packet filter, Protocol Rule or Publishing Rule must exist in order
to allow traffic into and out of the ISA Server.

Packet filtering should be enabled when the ISA Server is on the edge of
the network. You should also enable packet filter when you create a
Trihomed DMZ, since you must use packet filters to control inbound and
outbound access to and from the DMZ segment. Packet filters are also used
to allow applications and services on the ISA Server itself to work
properly.

You should not use packet filters instead of, or to support, Protocol
Rules and Publishing Rules. The Rules themselves will allow inbound and
outbound access required to support the ports specified in the rules.

==================================
ADVERTISEMENT
Do you have "Configuring ISA Server 2000: Creating Firewalls With
Windows 2000" by Tom Shinder, Deb Shinder and Martin Grasdal? If not,
you have to grab this must have book on ISA Server!

Tom supports the book on the www.isaserver.org message boards. What
other author gives you this kind of curb service on his book?

If you don't have the book yet, get it now from the link on the front
page of www.isaserver.org. You'll also help support the site that
supports you!
==================================

**TIP OF THE WEEK**

This week's ISA Server Tip is courtesy of John Munyon. John is one of
our premiere posters! He posted this tip at
http://www.isaserver.org/ubb/Forum14/HTML/000015.html

"I can think of no good reason to leave the qos network settings in
their default position of enabling qos. However, having qos enabled
dramatically raises the chances of having a problem with VPNs and
service failures."

==================================
**POST OF THE WEEK**

The Post of the Week comes from Hugo Caye, who is an active participant
on the isaserver.org mailing list. Although focused on Exchange Server,
the tip a really cool nonetheless:

"Can I place disclaimers at the bottom of each e-mail message that is
sent to the Internet via Microsoft Exchange Server 5.5?"

Yes. The BackOffice Server 4.5 Resource Guide includes a Resource Kit
utility called "IMS Extension" that allows you to pre- and post-process
e-mail messages that travel through the Internet Mail Service. It also
allows you to add text to the body of a message. Your company can use
this feature to add disclaimer text to Internet mail. This utility is
also available with the CD subscription versions of Microsoft TechNet."

==================================
**ISA Server Link of the Week**

The ISA Server Link of the Week goes to Martin Grasdal's excellent
article on publishing OWA running on the ISA Server itself. Check it out
here:
http://itresources.brainbuzz.com/tutorials/tutorial.asp?t=S1TU1316&tn=OW
A%2Band%2BISA%2BServer&pi=S1C63&pn=Firewalls
(link may wrap -- copy and paste the entire link to get there)

==================================
ADVERTISEMENT
LANguard Content Filtering & Anti-Virus for ISA Server

Provides content checking and anti-virus of HTTP and FTP downloads and
browsing. LANguard will check inbound traffic for viruses, malicious
scripts and objectionable material. It also permits quarantining of
downloads for approval. In addition, LANguard content filtering allows you
to set up rules that can stop unproductive use of the Internet at the
workplace.
More info at http://www.gfi.com/isanl.shtml

==================================
**Ask Dr. Tom**

This question comes from Useche:

"If I wanted to deny certain FW client users/groups access to the
internet, will I have to disable the HTTP Redirector? Is there anyway
around this? What if I had two ISA servers. The first one will have the
HTTP redirector disabled and and I will be denying internet access to
certain FW client users, this server will also have a Routing Rule that
will forward all requests to an upstream ISA server that will do all the
caching for my firewall clients. This way I can control who accesses the
internet without prompting my users for a password and I still get the
advantage of the Web Cache feature. Will this work?"

Answer:
The Firewall Client will not pass authentication information to the Web
Proxy Service when you have the HTTP Redirector configured to send web
requests to the Web Proxy service.

The best way to control access to Web Requests is to configured the HTTP
Redirector to drop requests from SecureNAT and Firewall Clients and then
configure all machines as Web Proxy clients. This approach is operating
system independent because virtually any browser can be configured as a
Web Proxy client.

This method will allow you to do what you want to do, and is a lot
simpler than what you were planning to do.

==================================
**To the Editor**

Since this is the first Newsletter, no one has had a chance to write to
the Editor. Write to us your opinions, beefs, suggestions, gripes, or
just get out some frustrations about ISA Server. We'll post one or two
of these with every newsletter. Write to tshinder@isaserver.org

==================================

ADVERTISE ON THIS NEWSLETTER!
Reach thousands of ISA Server administrators, contact Stephen Chetcuti
today at advertising@isaserver.org!

==================================
Copyright(c) isaserver.org 2001
All Rights Reserved
Disclaimer:
We are not responsible for anything good or bad that might happen to
your systems based on the advise given herein. You must test and retest
the configuration options suggested in this newsletter and validate and
confirm for yourself that they work as you intend.