Securing the ISA Server Configuration

[ben611b]

ISA Server is completely secure when you first install it. The default configuration settings on ISA Server prevent all inbound and outbound access (with the exception of some DNS and ICMP packets that are allowed by the default packet filters). ISA Server only becomes insecure after you start configuring it.

Note: Before evening getting into the specifics of ISA Server configuration, you should always install the latest hotfixes for both Win2k and ISA Server. At the time of writing this article, MS has released a Security Hotfix Rollup that updates the operating system with all the currently available hotfixes since SP2. You should also install the ISA Server SP1.
In this section we'll focus on ISA Server security in the following realms:
· Packet Filters
· Web Proxy Listeners
· Site and Content Rules
· Protocol Rules
· Publishing Rules
· Alerts
· Logging
· Application Filters
· LDT/LAT
· VPN

Packet Filtering

Packet filtering must be enabled on the ISA Server. If you don't enable packet filtering, all ports that are opened by applications and services on the ISA Server will be open for business! The goal of enabling packet filtering on the ISA Server is to close off all ports on the external interface except those you have explicitly opened.

You have the option to allow IP Routing when packet filtering is enabled (actually, you can enable IP Routing even when packet filtering is disabled, but you will never want to do this). IP Routing is somewhat of a misnomer when it comes to moving packets between the Internet and the internal network. The reason for this is that all LAT hosts must use NAT to access the Internet. Even though NAT is considered a routing protocol, packets are not directly routed from the Internet to the internal network, so you don't have to worry about Internet packets being directly routed into your internal network.

However, IP Routing does allow non-TCP/UDP packets to move outbound from the internal network. IP Routing must be enabled to allow PPTP (which uses IP Protocol 47 GRE packets) and ICMP through the ISA Server. The problem with allowing IP Routing of these protocols is that you do not have any degree of access control over the routing of these packets. If you enable IP Routing everyone has access to outbound non-TCP/UDP protocols (as long as the packet filter is in place to support them).

This brings up the security weakness of packet filters and why you never use packet filters to control outbound or inbound access unless you really need to use them. Always use Protocol Rules and Publishing Rules to control outbound and inbound access.

You should also enable filtering of IP Options and IP Fragments. One of the most popular exploits on the Internet today involves bypass firewall protection through the use of fragmented packets. However, if you filter out IP fragments, you will find that some multimedia will not work correctly. Jim Harrison informs me that streaming over 100K is especially susceptible to breaking if fragment filtering is enabled. There should be some improvement in this regard with SP1, which allows for larger UDP packets. Be sure to test your application to ensure they work with fragment filtering enabled. IP Options filtering should always be enabled. This prevents source routed packet attacks.

Checkpoint:
· Turn on packet filtering
· Do not enabled IP Routing unless absolutely required
· Enable fragment filtering
· Enable intrusion detection
· Enable filtering of IP Options

Incoming Web Proxy Listeners

Incoming Web Proxy listeners should be created and enabled only if you plan to use Web Publishing Rules to publish Web Servers on the internal network. If you do not plan to use Web Publishing Rules, eliminate all Web Proxy service listeners.

You can remove Incoming Web Proxy Listeners by selecting the Configure listeners individually per IP address and then deleting any listeners that might be there. If you have not already created listeners, then the list should be empty. If so, leave it empty.

If you do plan on use Web Publishing, then you will need to use Incoming Web Proxy listeners. You can force authentication at the listener if you like, but many prefer to authenticate at the Web server itself. Its up to you. One thing you probably want to avoid is authenticating at both the listener and the Web site. I say this because there have been issues with this setup, although they may be resolved with Service Pack 1.
Checkpoint:
· Remove all Incoming Web Proxy listeners if you do not plan to use Web Publishing Rules

Site and Content Rules

On a stand-alone ISA Server, a default Site and Content Rule is created that allow access to all sites, and all content, at all times, to everyone. You should change this as soon as possible. You can delete this rule, or you can change it to allow Domain Users. If you leave this rule as is, you will have an anonymous access rule, and all Web Proxy clients will use the anonymous access rule first. That is the nature of the HTTP Protocol and there's nothing you can do about it. So, make the change to the default Site and Content Rule.

Keep in mind that if you have an anonymous access rule, that rule will always be applied before any other rules. For example, if you have a Deny rule that prevents the temps group from accessing www.hotmale.com , the Deny rule will be ignored because the anonymous access rule is applied first. However, if you have an anonymous access rule that Denies access, then the Deny anonymous access rule will be applied before the Allow anonymous access rule.

If you use Enterprise Policies, you'll notice that a default Site and Content is not created.

Note: If you change the default Site and Content Rule to a rule that requires authentication, you will have problems with servers that do not have logged on users. You can solve this problem by creating a Client Address Set for your servers and allow your servers access to the protocols they need access to.
Checkpoint:
· Change the default anonymous access Site and Content rule so that it applies to domain users, or delete the rule entirely.

Protocol Rules

There are no Protocol Rules configured on ISA Server after its installed. Because Protocol Rules are required for outbound access, no outbound access is possible until your create them.

There is a security concept known as the principle of least privilege. This means that you should only allow outbound access for those protocols that you require. Also, you should only access to those protocols to the users that require the user of those protocols. If there is no business need for a particular protocol, do not allow access to it.

How do you know which protocols you require? The best way to find out is to survey the users for the applications they require to get their jobs done. Then you can confer with the security team in your organization to determine which protocols are required by the organization. After you determine the required protocols and who needs to use them, create the appropriate Protocol Rules.

You should make it a daily policy to review the Firewall, Packet Filter and Web Proxy logs. Your review will be helpful in determining if users are attempting to use unapproved applications. The firewall logs are especially helpful in this regard because applications report to the Firewall client and service their names.

If you find that users are attempting to use warez applications like Napster, Kaaza and Morpheus, you must take action immediately as this places the company at risk. Make a network use policy and get the highest levels of management to sign off on it, so that employees can be fired if they violate corporate security policy.

Note: During your testing of ISA Server, you may have created "All Open" Protocol Rules and Packet Filters. After your testing is done, you must remove these settings to protect the integrity of your internal network.

Checkpoint:
· Use the principle of least privilege
· Create Protocol Rules for only required protocols
· Limit access to protocols only to users that require them

Publishing Rules

Publishing Rules allow Internet and other external network users to access services on your internal network. Protocol Rules themselves don't offer must in terms of access control or protection from external network intrusion. If you create a Protocol Rule that allows access to your internal network servers, then anyone that has access can access the server service just as if they were on the internal network accessing the same service.

Web Publishing Rules allow you to control access based on user/group and client address sets. Server Publishing Rules allow you to grant access to the rule based on client address set. But once the user is allowed in, they have as much access as you have granted the user on the published server.

This means that Publishing Rules do not obviate your responsibility to maintain a high level of host based security. You must keep your internal network servers up to date with the latest security patches, and you must harden the servers as you would as if they were directly connected to the Internet. Do not think of Publishing Rules as a security measure. Think of them as a convenience measure that allows you to bring those servers onto your internal network so as to more easily manage them.
Checkpoint:
· Allow access to Publishing Rules only for those that require access to the published server
· Configure the published server to allow access only to those that require access to the server
· Harden the published server as you would if the server were directly connected to the Internet

Alerts

The ISA Server will always post an alert to the Event Logs in the event that an enabled alert was triggered. Alerts are strange things in ISA Server. You have the option to create new alerts, but you can't create any new alerts other than those that have already been configured on the server! I admit, you can create new alerts to allow you to perform extra actions, but you cannot create new alerts (at least there no non-programmatic way of doing this).

Nevertheless, you should review all the alerts available in the Alerts node. Some of them are more interesting than others. For those alerts that are more serious, such as an intrusion alert, you should configure an email be sent to you notifying you the alert took place. If you are in a high security environment, you should decide if you want to stop the services in the event of a major alert or start a monitoring program of some kind.

There are no hard and fast rules regarding alerts. You can leave the default configuration as it is, as all enabled alerts will report to the Event Logs.
Checkpoint:
· Review the Available Alerts
· Configure important Alerts with response actions as determined by your corporate security policies

Logging

Logging should always be enabled for each service. This is the default setting. You should never disable logging for any of the services because the logs are your first line of defense against a major attack or troubleshooting a problem with access and access controls.

New log files should be created each day, and the log files should be copied from the ISA Server to a safe location each day so that they are available if a hacker or hardware failure makes it impossible to retrieve them. The format isn't important, unless you want to use local time. Then you should save the logs in ISA Server file format.

The more fields you log, the more system resources will be required to log all of those fields. Review the fields included in you log files. The default settings are good and you are unlikely to need to change them. However, you might want to consider logging Rule#1 and Rule#2 for troubleshooting purposes.

By default, ISA Server will save the last 30 log files. If you create a new log file each day, then it will save one month's worth of log files. You might want to increase the number of log files to a larger number. I store a years worth of log files. Make sure that you select the compression option for the log files so that they do not overwhelm your disk space. I highly recommend that you get a 100+ GB drive dedicated to the storage of your log files. With compression, you should be able to keep about 200 GB of log files. The logs can grow very fast, and you may wish to save the logs on an extendable volume so that its easy to add disk space when required.

Hand in hand with Log Files are the log summaries. The ISA Server reports are constructed using the Log Summaries. You must select the Enable Reports option to create the reports. You must enable the Enable daily and monthly summaries options. To enable the greatest flexibility when creating reports, you should save a bunch of them. I saved two years worth of Daily summaries and three years worth of monthly summaries.

Checkpoint:
· Store Logs and Summaries on a dedicated, extendable disk
· Increase the number of saved log files
· Copy the log files each day to a safe location
· Increase the number of saved summaries

Application Filters

There are a number of application filters that ship with ISA Server. Several of them are important in generating security alerts. These filters are:
· The DNS intrusion detection filter
· The POP intrusion detection filter
· The SMTP filter
These application layer filters are able to examine the application layer data portion of the packet and alert you to certain security related concerns about that data. You should enable each of these filters, and for the DNS filter, enable each option. The SMTP filter allows for a greater number of options when used together with the SMTP Message screener.

Even if you do not use the SMTP Message Screener feature, the SMTP filter will examine SMTP commands and look for buffer overflow conditions for these command. The SMTP filter is disabled by default, but you should enable it before connecting the ISA Server to the Internet.

There are few legitimate users for the SOCKS filter unless you are in a hybrid environment. If you use a Windows environment, all clients will have the Firewall client software installed and thus will not need the SOCKS filter. The SOCKS filter can be used by dangerous applications, such as instant messengers, to subvert your security scheme.
Checkpoint:
· Enable the DNS, POP and SMTP application filters
· Use the SMTP Message Screener if you require detection of more than SMTP command buffer overflows
· Disable the SOCKS filter

LAT/LDT

The Local Address Table (LAT) defines what addresses are trusted by the ISA Server. Connections to trusted addresses are not handled by the ISA Server firewall service. This prevents wastage of processor cycles for internal client access to internal resources. One of the most egregious errors you can make is to try and "loopback" access to internal network resources through the ISA Server. This loopback situation is a result of a misconfigured DNS infrastructure, and not a problem with the ISA Server itself.

Never include external network addresses in the LAT. You can seriously subvert the security configuration of the ISA Server if you enter external addresses in the LAT. The ISA Server will see those addresses as local and will not subject requests from those clients to the rules engine.

The local domain table serves the same purpose as the LAT. You should put only local domains in the LDT. If you put external domains in the LDT, access to external resources in those domains will not be subject to the ISA Server rules engine. That explains why you can use the LDT workaround to get Outlook Express to access Hotmail. But this should be considered a security lapse. Any time an external domain is included in the LDT, you are weakening your security configuration on the ISA Server.

Note: You should add your external domain into the LDT if you've installed an internal DNS to avoid the dreaded 14120 error.
Checkpoint:
· Put only internal network addresses in the LAT
· Put only internal network domains in the LDT
· Do not "loopback" access to internal network resources through the ISA Server

VPN Settings

ISA Server includes some very nice Wizards that walk you through the process of configuring a VPN server and a gateway to gateway VPN configuration. However, keep in mind that the only ISA Server configuration made is to create packet filters to allow PPTP and L2TP/IPSec connections. All other VPN related configurations are made in the RRAS console.

If you allow VPN connections, you should configure RRAS Policies to limit who and how VPN connections are made to your server. There are a great number of options available to you via RRAS Policies and it's definitely worth your time to check these out.

If you use PPTP, you must require complex passwords. The level of security offered by PPTP is dependent on the complexity of the password. If your users use simple passwords, it will be relatively simple for a intruder to access your network via the VPN connection. If at all possible, you should use L2TP/IPSec as your VPN protocol. L2TP/IPSec requires the use of machine certificates. It can be difficult for an intruder to get access to a machine certificate from your organization. This provides an extra layer of security to your VPN solution.
Checkpoint:
· Use RRAS Policies to control access to your VPN server
· Require complex passwords, especially if you are using PPTP
· Migrate to an L2TP/IPSec VPN solution as soon as possible

Conclusion

In this article we went over what I consider to be important steps you should take to secure your ISA Server. Keep in mind that ISA Server is only one facet of your network security scheme. Host based security must also be implemented. The ISA Server is not the "total network security solution". Several other things you should think about in terms of securing your network include:
· Control application access at the desktop via Group Policy
· Regular computer audits for unapproved applications
· Network usage policies and strong punishment for violating policy
· Harden all machines, especially servers accessible to Internet users
· Use IPSec for all internal network communications
· Require Smartcards or biometric access for authenticated access
These are just a few of things you should consider when securing your network. ISA Server can do a lot, but it can't do it all. No firewall product can. But ISA Server does a damn good job at being a firewall!
Now for the checklist:
· Do not install services and applications on the ISA Server
· Harden the Windows 2000 OS
· Always install the latest security updates to Win2k and ISA Server
· Disable all services that aren't required by the base operating system and ISA Server
· Do not install ISA Server on a domain controller unless it's a dedicated ISA Server domain and forest
· Disable File and Printer sharing on the external interface
· Disable Client for Microsoft Networks on the external interface
· Disable NetBIOS over TCP/IP on the external interface
· Change the method for resolving unqualified names by choosing the Append these DNS suffixes (in order) option in the DNS tab in the Advanced TCP/IP settings Properties dialog box
· Determine whether your network infrastructure requires enabling the Microsoft Client, File and Printer sharing, and NetBIOS on the internal interface. If you do not require these features, try turning them off.
· Turn on packet filtering
· Do not enabled IP Routing unless absolutely required
· Enable fragment filtering
· Enable intrusion detection
· Enable filtering of IP Options
· Remove all Incoming Web Proxy listeners if you do not plan to use Web Publishing Rules
· Change the default anonymous access Site and Content rule so that it applies to domain users, or delete the rule entirely.
· Use the principle of least privilege
· Create Protocol Rules for only required protocols
· Limit access to protocols only to users that require them
· Allow access to Publishing Rules only for those that require access to the published server
· Configure the published server to allow access only to those that require access to the server
· Harden the published server as you would if the server were directly connected to the Internet
· Review the Available Alerts
· Configure important Alerts with response actions as determined by your corporate security policies
· Store Logs and Summaries on a dedicated, extendable disk
· Increase the number of saved log files
· Copy the log files each day to a safe location
· Increase the number of saved summaries
· Enable the DNS, POP and SMTP application filters
· Use the SMTP Message Screener if you require detection of more than SMTP command buffer overflows
· Disable the SOCKS filter
· Put only internal network addresses in the LAT
· Put only internal network domains in the LDT
· Do not "loopback" access to internal network resources through the ISA Server
· Use RRAS Policies to control access to your VPN server
· Require complex passwords, especially if you are using PPTP
· Migrate to an L2TP/IPSec VPN solution as soon as possible

---

موضوعات مشابه:

• Securing Printer Usage in Windows Server 2003
• Securing an Exchange 2007 Client Access Server using a 3rd party SAN Certificate

---

[ben611b]

Strong user/group based inbound and outbound access control is one of the key security features seen in true stateful application layer inspection firewalls. Unlike simple stateful filtering firewalls, the stateful application layer inspection firewall can make allow or deny decisions based on application layer information, such as the name of the user or the user's group membership, when evaluating an inbound or outbound request. This article discusses how to use the ISA 2004 firewall's Domain Name Sets feature to control outbound access and block forbidden sites.
One of the more popular applications of the ISA 2004 firewall is to control what sites users can access through the ISA firewall. For example, you might want to limit a group of users to a specific collection of Web sites, while blocking access to all other sites. At the same time, you might want other groups to have full access to all sites on the Internet.

There are a number of ways this can be accomplished using ISA 2004 firewalls. In this article, we’ll focus on how to use the ISA 2004 firewall’s Domain Name Sets feature to control access to Internet servers. Domain Name Sets can be used by all ISA client types, including SecureNAT, Web Proxy and Firewall clients. However, if you want to control access by user or group, you need to configure the clients as Web Proxy or Firewall clients (or both).
Now I can hear you say "but I don’t want to install the Firewall client and I don’t want to configure the browsers as Web Proxy clients". That’s fine, but you’ll have to go without user/group based authentication. The reason is there is no provision in the network or transport layers (or any layer under layer 7) to send user credentials to the firewall. So, all firewalls that perform user/group based authentication depend on a client "piece" to enforce authentication requirements.
The good news is that it’s fairly easy to automate provisioning for the Web Proxy and Firewall clients, and to automate the installation of the Firewall client. Check out the ISA Server 2000 in Education Deployment Kit (http://isaserver.org/tutorials/isaedukit.html) for details on how to automate these processes.
Domain Name Sets are used to control access to an entire site. For example, if you don’t want people going to any site in the cisco.com domain, then you create a Domain Name Set with the entry *.cisco.com. If you didn’t want anyone going to any site in the domain checkpoint.com, then you would create a Domain Name Set entry for *.checkpoint.com. If you wanted to block only a particular server in the cisco.com domain, you could create an entry like www1.cisco.com, and that could be used to block access to the www1.cisco.com server, but allow access to other servers on the cisco.com site.
An advantage of Domain Name Sets is that they apply to all protocols and all client types. In contrast, URL Sets are only used for Web connections. These Web connections must be handled by the Web proxy filter and include connections made using the HTTP, HTTPS and FTP (FTP from machines explicitly configured as Web Proxy clients) protocols.
For example, we create a URL set with an entry news.cisco.com and create a rule blocking connections to the site using any protocol. We then open the Outlook Express newsreader. The connection will be allowed to the news.cisco.com NNTP server because the URL Set is only evaluated for HTTP, HTTPS and HTTP tunneled (Web Proxy) FTP sessions.
WARNING:
It’s critical that you understand the differences between the functionality provided by Domain Name Sets and URL Sets. Remember that Domain Name Sets can be used to control access for all protocols and all client types. URL Sets control access for clients establishing a connection via the Web Proxy filter.
In this article we’ll take a look at two examples that demonstrate how to use ISA 2004 firewall Domain Name Sets:

• A simple scenario, where we create a Domain Name Set for a list of blocked sites for all users
• A less simple scenario, where you want to allow a group of users access to a selected group of sites, but want to block access to all other sites for all protocols

Before we get into the scenarios, let’s examine the basic network infrastructure used in our example.
The Lab Network
The figure below shows the IP addressing information, the operating system and the salient services running on each machine participating in our lab network.

The domain controller on the protected network behind the ISA 2004 firewall is also a DNS resolver for the network. The DNS resolver can resolve names for internal network clients and can also resolve names for Internet hosts. If the DNS root hints file is primed correctly on the DNS server on the DC, then you’ll be able to resolve Internet host names too using the same DNS server as that used to resolve internal network host names. Note that this is not my preferred configuration. I prefer the DNS server on the internal network to use a DNS forwarder that is under my control (such as a caching-only DNS server on the ISA firewall itself, or a caching-only forwarder on a DMZ segment). But to keep things simple in our current discussion, we’ll allow the DNS server on the Internal network domain controller to perform recursion to resolve Internet host names.
NOTE:
Depending on how you configured the DNS server, you may or may not have a "primed" (ready) Root Hints file. Check out http://support.microsoft.com/default.aspx?scid=kb;EN-US;249868 for information on fixing the problem.
The ISA 2004 firewall is a member of the internal network domain. We make this machine a member of the Internal network domain so that we can use the Active Directory user database to authenticate Firewall and Web Proxy client users. The ISA 2004 firewall must be a member of the Internal network domain to authenticate domain users that are Firewall clients. The ISA 2004 firewall does not need to be a member of the domain if you only want to authenticate Web Proxy clients. In the case of Web Proxy clients, you can use RADIUS to authenticate domain users. Full details on configuring RADIUS for Web Proxy clients are included in Tom and Deb Shinder’s Configuring ISA Server 2004.
In the current example, the ISA 2004 firewall is a bastion host because it has a network interface on an external, untrusted network. In general, I do not like a bastion host to be a member of the domain. A better solution is to put an ISA 2004 firewall that is not a domain member in front of the ISA 2004 firewall that is a domain member. This creates a back to back ISA 2004 firewall configuration and provides a very high level of protection for the Internal network. While it’s unlikely that the domain member ISA firewall will ever be compromised, the possibility always exists. The front-end firewall in this configuration provides a high level of security and better "peace of mind".
NOTE:
In order to obtain a very high level of protection for your back-end ISA firewall, its important to have more than a stateful filtering firewall in front of the back-end ISA firewall. This is why I prefer to use an ISA 2004 firewall in front of the back-end ISA 2004 firewall. A basic stateful packet filtering firewall, like PIX or Netscreen, performs only stateful filtering but is unable to perform both stateful filtering and stateful application layer inspection. A simple stateful filtering ‘firewall’ provides only nominal protection for the services located on the DMZ segment between the front-end firewall and the domain member ISA firewall, and the stateful filtering device provides little or no protection for the back end ISA firewall. For details on these issues, check out ISA Firewall Fairy Tales - What Hardware Firewall Vendors Don't Want You to Know at http://isaserver.org/articles/2004tales.html
The Windows XP client machine on the ISA 2004 protected network is configured as a Web Proxy, Firewall and SecureNAT client. The SecureNAT client configuration will apply to the first scenario we cover in this article where we block a group of sites to everyone. The Web Proxy and Firewall client configuration applies to the second example, where we block and allow sites based on group membership.
In general, all Windows clients should be configured as both Web Proxy and Firewall clients. They should be configured a SecureNAT clients only if you require SecureNAT functionality (e.g., if the machine needs PPTP or ICMP access). The exceptions to this rule are network servers, such as DHCP, DNS, Active Directory, Certificate, RADIUS, SQL, SharePoint and just about any other network server you can think of. These servers should never be configured as Firewall clients, although feel free to configure them as Web Proxy or SecureNAT client if you have a reason to do so.
I have done some very basic configuration of the ISA 2004 firewall in advance. The firewall rule set includes a DNS server Access Rule that allows all clients outbound access to the DNS protocol from the Internal network to the External network. You can lock this down a bit by allowing only the DNS server outbound access to the DNS protocol. I have also created an "all open" rule that allows outbound access to all protocols to all users from the Internal network to the External network. We’ll look at the effect of the rule order in each of the scenarios covered here.

[ben611b]

In the first example, we create a rule that blocks all users from accessing all servers in the cisco.com, checkpoint.com and sonicwall.com domains. User authentication is not required because this rule will apply to all users.
There are a couple ways we can approach creating this deny rule. One way is to first create the Domain Name Set first and then create the Access Rule. That’s how we used to do things with ISA Server 2000 firewalls. The problem with this approach is that 9 times out of 10, I would forget to create the Destination Set before trying to create the rule. In contrast, the ISA 2004 firewall allows us to create rule elements "on the fly", so we don’t need to create these elements in advance.
Perform the following steps to create the Deny Access Rule:
1. In the Microsoft Internet Security and Acceleration Server 2004 management console, expand the server name and then click the Firewall Policy node.
2. Click the Tasks tab in the Task Pane. On the Task Pane, click the Create a New Access Rule link.
3. On the Welcome to the New Access Rule Wizard page, enter a name for the rule. In this example, we’ll name the rule Block Forbidden Sites. Click Next.
4. On the Rule Action page, select the Deny option and click Next.
5. On the Protocols page, select the default option All outbound traffic and click Next.
6. On the Access Rule Sources page, click the Add button.
7. In the Add Network Entities dialog box, click the Networks folder and then double click Internal. Click Close.
8. Click Next on the Access Rule Sources page.
9. On the Access Rule Destinations page, click the Add button.
10. In the Add Network Entities dialog box, click the New menu and then click Domain Name Set.
11. In the New Domain Name Set dialog box, enter in the Name text box Forbidden Sites. Click the New button. Enter *.cisco.com and press ENTER. Click the New button again and enter *.checkpoint.com and press ENTER. Click the New button one more time and enter *.sonicwall.com and press ENTER. Click OK.

12. In the Add Network Entities dialog box, click the Domain Name Sets folder and then double click the Forbidden Sites entry. Click Close.

13. Click Next on the Access Rule Destinations page.
14. On the User Sets page, accept the default entry All Users and click Next.
15. Click Finish on the Completing the New Access Rule Wizard page.
16. Move the Forbidden Sites rule to the top of the list. The rule set now looks like that in the figure below.

17. Click Apply to save the changes and update the firewall policy.
18. Click OK in the Apply New Configuration dialog box.
The first rule will block connections from any host, using any protocol, to the forbidden sites. The second rule allows all hosts on the Internal network to access DNS servers on the Internet, and the third rule allows all users access to all sites on the Internet using any protocol. ISA 2004 firewalls evaluate connections from the top down and the first rule to match the connection’s parameters is applied. Well, almost. Rules that apply to authenticated users are also applied to unauthenticated users, so there’s sort of an implicit "unauthenticated users" group. We’ll examine this issue in more detail later in this article.
Now let’s test the connection. We’ll go to the Windows XP machine on the Internal network and try to connection to the www.cisco.com Web site using Internet Explorer. Remember, Internet Explorer is configured as a Web Proxy client (actually, it’s using the default configuration, which is to autodetect the proxy, and we’ve configured the required wpad entries to make this work). The figure below shows what the user sees when trying to access a forbidden site.

When we check out the connection in the ISA 2004 firewall’s log viewer, we can see that the Block Forbidden Sites rule denied the connection attempt to the site.

Next, let’s see what happens when we try to access a forbidden site using a non-Web protocol. We can simulate such a connection using the Telnet command. Open a Command Prompt and at the Command Prompt, enter telnet news.cisco.com 119 and press ENTER. You’ll see an error message indicating that the connection failed.

If we go to the ISA 2004 firewall’s log viewer, we can see that the Block Forbidden Sites rule denied the connection attempt to TCP port 119. Note the question mark to the right of the user name, Administrator. If you want to know what the question mark means, make sure to grab a copy of our ISA 2004 firewall book, Tom and Deb Shinder’s Configuring ISA Server 2004

[ben611b]

من این را رو پیدا کردم حیفم اومد برایتون نزارم چون بدرد من خیلی خورد

[ben611b]

In this scenario, we will create a group called TEMPS and place user accounts of users who are temporary workers in that group. In this example, we have created a global security group called TEMPS and have created a user named Temp1. We then placed user Temp1 in the TEMPS Global Group. This prepares us for the ISA 2004 firewall configuration steps.
In the following procedure, we will create a rule that blocks the TEMPS group from accessing the Internet, with the exception of the microsoft.com., isaserver.org, and msexchange.org sites. In this example we will allow the members of the TEMPS group access to all protocols when accessing these sites. If we wanted, we could limit these users to just the HTTP and HTTPS protocols. These three sites contain all the information required by the users in the TEMPS groups. All other authenticated users will have access to all Internet sites by virtue of an "all open" authenticated users outbound access rule.
Perform the following steps to create the Deny rule that denies members of the TEMPS group access to all sites except the allowed sites:
1. In the Microsoft Internet Security and Acceleration Server 2004 management console, expand the server name and then click the Firewall Policy node.
2. In the Firewall Policy node, click the Tasks tab on the Task Pane. Click the Create a New Access Rule link.
3. On the Create a New Access Rule Wizard page, enter a name for the rule in the Access Rule name text box. In this example, we’ll call this rule Block TEMPS Except TEMPS Sites. Click Next.
4. On the Rule Action page, select the Deny option and click Next.
5. On the Protocols page, select the All outbound traffic option in the This rule applies to list and click Next.
6. On the Access Rule Sources page, click the Add button.
7. In the Add Network Entities dialog box, click the Networks folder and double click the Internal network. Click Close.
8. On the Access Rule Destinations page, click the Add button.
9. In the Add Network Entities dialog box, click the Networks folder and double click the External network.
10. Click Next on the Access Rule Destinations page.
11. On the User Sets page, click the Add button. In the Add Users dialog box, click the New menu.
12. On the Welcome to the New User Sets page, enter a name for the firewall group in the User set name text box. In this example, we’ll name the group TEMPS Access. Firewall groups allow you to group users based on firewall requirements, not Active Directory requirements. ISA 2004 Firewall Groups allows you to group users and does not require you to be a member of the domain admins group. Click Next.
13. On the Users page, click the Add button. In the fly-out menu, click the Windows users and groups option.

14. In the Select Users or Groups dialog box, click the Locations button and select the Entire Directory option. In the Enter the object names to select text box, enter TEMPS and click the Check Names button. The Temps entry will become underlined. Click OK.

15. Click Next on the Users page.

16. Click Finish on the Completing the New User Set Wizard page.
17. In the Add Users dialog box, double click on the TEMPS Access Firewall Group. Click Close.
18. On the User Sets page, click the All Users entry in the This rule applies to requests from the following user sets list and click the Remove button. Click Next.
19. Click Finish on the Completing the New Access Rule Wizard page.
20. In the Firewall Policy list in the details pane, double click the Block Temps Except Temps Sites rule.
21. In the Block Temps Except Temps Sites Properties dialog box, click the To tab.
22. On the To tab, click the Add button in the Exceptions section.

23. In the Add Network Entities dialog box, click the New menu and then click the Domain Name Set command.
24. In the New Domain Name Set Policy Element dialog box, enter TEMPS Allowed in the Name text box. Click the New button. Enter *.microsoft.com and press ENTER. Click the New button again. Enter *.isaserver.org and press ENTER. Click the New button one more time. Enter *.msexchange.org. Click OK.

25. In the Add Network Entities dialog box, click the Domain Name Sets folder and then double click on the TEMPS Allowed entry. Click Close.

26. Click Apply and then click OK in the Block Temps Except Temps Sites Properties dialog box.

27. Move the DNS outbound Access Rule to the top of the firewall policy list, and make the Block Temps Except Temps Sites to second on the list, as it appears in the figure below. You might wonder why we need to do this. The reason is that although the condition on the Block Temps Except Temps Sites rule indicates that the rule only applies to the TEMPS group, the fact is that it also applies to any unauthenticated connections. However, the rule has more far-reaching effects than just blocking access to whatever is listed in the To column. If the first rule matching the connection’s parameters requires authentication, and the user is unable to authenticate, then the connection is DENIED, even though the connection was not initiated by a user in the Firewall Group for which the Rule was intended. Make sure you understand that last statement. Again, if there is a rule that applies to the connection by matching the connection’s characteristics, but the user is unable to authenticate, then the connection is DENIED. This is why we need to put the DNS access rule before the Block Temps Except Temps Sites rule. If we put the DNS access rule after the Block Temps rule, then the connection would match the Protocol, the From and the To for the Block Temps Except Temps Sites rule, an the connection would be denied, even though its an anonymous access attempt and not an attempt from a member of the TEMPS Access group. For this reason, I recommend that you put your anonymous allow rules before any authenticated deny rules (by ‘anonymous rule’ I mean any rule that applies to ‘all users’). I promise that you will have trouble with this and hopeful this rule matching model will change either with a service pack or a "dot" upgrade to the ISA 2004 firewall software.

Whenever I make a rule that denies a group access to all sites except for a small collection of sites, I like to make a rule that explicitly allows them access to the allowed sites. This helps keep things organized and doesn’t require that you depend on a "all open" rule or some other rule that provide them access to the required sites.
Perform the following steps to create the rule that allows the TEMPS group access to the TEMPS Allowed Domain Name Set:
1. In the Microsoft Internet Security and Acceleration Server 2004 management console, click the Firewall Policy node and then click the Tasks tab on the Task Pane. Click the Create a New Access Rule link.
2. On the Welcome to the New Access Rule Wizard page, enter a name for the rule in the Access Rule name text box. In this example, we’ll name the rule Allow TEMPS to TEMPS Allowed. Click Next.
3. On the Rule Action page, select the Allow option and click Next.
4. On the Protocols page, select the Selected protocols option in the This rule applies to list and then click the Add button.
5. In the Add Protocols dialog box, click the Common Protocols folder and then double click on the HTTP and HTTPS protocols. Click Close.
6. Click Next on the Protocols page.
7. On the Access Rule Sources page, click the Add button.
8. In the Add Network Entities dialog box, click the Networks folder and double click Internal. Click Close.
9. Click Next on the Access Rule Sources page.
10. On the Access Rule Destinations page, click the Add button.
11. In the Add Network Entities dialog box, click the Domain Name Sets folder. Double click on the TEMPS Allowed entry and click Close.
12. Click Next on the Access Rule Destinations page.
13. On the User Sets page, click the All Users entry and click Remove. Click the Add button.
14. In the Add Users dialog box, double click on the TEMPS Access Firewall Groupand click Close.
15. Click Next on the User Sets page.
16. Click Finish on the Completing the New Access Rule Wizard page.
Now we’ll make one more change. Instead of an "all open" rule that applies to all users, we’ll change the "all open" rule we made before starting this exercise so that it applies to all authenticated users except for members of the TEMPS Access group. This will prevent the members of the TEMPS Access Firewall Group from using the anonymous "all open" rule to access sites outside of those we want them to access.
I should note that this is not strictly required, as the Block Temps Except Temps Sites rule should block all access from members of the TEMPS Access Firewall Group to sites and protocols outside of those allowed and explicitly allowed. However, I do recommend the approach we use here as it prevents you from getting into trouble by having groups "inadvertently" use a rule to access content they should not have otherwise accessed.
Perform the following steps to change the "all open" rule:
1. In the Microsoft Internet Security and Acceleration Server 2004 management console, click on the Firewall Policy node.
2. Click the Toolbox tab in the Task Pane. On the Toolbox tab, click the Users entry beneath it.
3. Drag the All Authenticated Users entry from the list of Users to the Condition column for the All Open rule and then release the left mouse button. Click the Include command in the menu that appears.

4. In the Users list, drag the TEMPS Access Firewall Groupto the same location. This time, click the Exclude command.
5. Next, right click the All Users entry for the All Open rule and click Remove

6. Click Apply to save the changes and update the firewall policy.
7. Click OK in the Apply New Configuration dialog box.
8. Your firewall policy should look like the figure below.

The first rule allows all hosts on the Internal network access to DNS servers on the Internet. This is an anonymous access rule, so no host needs authenticate to match this rule.
The second rule, Block Temps Except Temps Sites, denies all outbound protocols from Internal network clients to the Internet if they belong to the TEMPS Access Firewall Group and if they are not able to authenticate. Again, there is no reason to expect that unauthenticated users should be denied, but they are. If a rule requires a user to authenticate and the user is unable to authenticate (is acting as a SecureNAT client), then the connection is denied. Go figure.
The third rule, Allow TEMPS to TEMPS Allowed, allows members of the TEMPS Access Firewall Group located on the Internal network access to only the HTTP and HTTPS protocols to sites in the TEMPS Allowed Domain Name Set. This rule does not allow access to other sites, and does not allow access to other protocols when members of the TEMPS Access Firewall Group connect to the allowed sites.
The last rule, All Open, allows all authenticated users access to all sites using all protocols, except for user in the TEMPS Access group. This rule provides for outbound "all open" for authenticated users while preventing members of the TEMPS Access Firewall Group from using this rule to access other sites.
Let’s test this rule set by logging onto the Windows XP machine as a domain admin. Domain admins are not a member of the TEMPS Access group, so they would fit into the groups All Users and Authenticated Users if they are using the Web Proxy and/or Firewall client configuration. Since the Windows XP is a Firewall and Web Proxy client, all TCP and UDP connections will be authenticated.
Open Internet Explorer and go to www.isaserver.org. You should get to the Web site successfully because the All Open rule allowed the connection, as seen in the figure below. Try other sites, like www.msexchange.org and www.windowsecurity.com. You will be able to connect to each of these sites because you are able to use the All Open rule to connect to them.

Log off of the Windows XP machine and log on as Temp1, who is a member of the TEMPS Global Group and a member of the TEMPS Access Firewall Group.
Open Internet Explorer and go to www.msn.com. You should see what appears in the figure below.

Now try to go to www.isaserver.org. You’ll be able to access the ISAServer.org home page. The log file entries look like what you see in the figure below.

However, this doesn’t mean this user has free reign over ISAServer.org Web sites. Remember, we limited users of the TEMPS Access Firewall Group to only the HTTP and HTTPS protocols. To test this, let’s do the NNTP test again using Telnet from the Command Prompt.
Open a Command Prompt on the Windows XP client and enter telnet www.isaserver.org 119 and press ENTER. You’ll receive an error indicating that the connection failed. If you look in the ISA 2004 firewall’s log file viewer, you’ll see a line like that in the figure below.

Summary

In this article we examined two scenarios where you can use Domain Name Sets to control outbound access through the ISA 2004 firewall. In the first scenario, we saw how we can create a deny rule that blocks specific sites for all users. In the second scenario, we saw how you can create Access Rules that allow a group of users access to a collection of sites using specific protocols and deny access to sites and protocols outside of those explicitly allowed. Domain Name Sets are a powerful tool that allow you to lock down SecureNAT, Web Proxy and Firewall clients with a minimum of effort. When combined with the principle of least privilege, your ISA firewall can provide a higher level of security than any other firewall on the market today.
I hope you enjoyed this article and found something in it that you can apply to your own network. If you have any questions on anything I discussed in this article, head on over to http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=25;t=000113 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom

If you would like us to email you when Tom Shinder releases another article on ISAserver.org, subscribe to our 'Real-Time Article Update' by clicking here. Please note that we do NOT sell or rent the email addresses belonging to our subscribers; we respect your privacy.

[bhrzk]

مقاله انگلیسی میزاری ؟

خب E-Book بزار دانلود کنند دیگه از اون کاملتر هم هست مگه ؟

[ben611b]

سعی کردم این را رو جمع آوری کنم برایتان بزارم چون بدردم خورد باشه دیگه نمیزارم

[aspakho]

خیلی ممنون بدرد من که خیلی خورد.بنطرم استفاد از تجربه دیگران راه حل بهتری تا بخواهی خودت تجریه کنی

[t_jn2001]

لطفا در مورد تنظیمات بین حوضه ای (dns) مطالبی برایم بگذارید

[saharbar]

سعی کردم این را رو جمع آوری کنم برایتان بزارم چون بدردم خورد باشه دیگه نمیزارم

از اينكه پاسخ ها و مطالب خيلي جامع و كاربردي و معتبر هستند بسيار متشكرم .

[zeighami]

تشكر

[sehagh]

خواستم تشکر کنم ولی دیدم یکی از دوستان اعتراض کرده بودن

خواستم بگم اگه دنبال مطلب باشی تو گوگل زیاد ریخته اما اینکه یه نفر حاصل تلاش و زحماتش و تجربیاتش رو به اشتراک بذاره فرق میکنه

حد اقل مطلب رو میخوندی بعد اعتراض میکردی (امیدوارم ازش بتونی استفاده کنی)

[Hakimi]

تاریخ نوشته ها رو هم دیدید؟ 2 - 3 سال از این موضوع می گذره