The document discusses configuring an ISA Server to respond to incoming ping requests by default it drops incoming ICMP ping packets for security. It provides steps to create a new packet filter based on the predefined ICMP ping response filter to allow ping responses from the external interface. It also discusses configuring additional external IP addresses on the ISA Server to respond to pings by creating new outbound and inbound ICMP packet filters applied to the additional IP addresses.
The document discusses configuring an ISA Server to respond to incoming ping requests by default it drops incoming ICMP ping packets for security. It provides steps to create a new packet filter based on the predefined ICMP ping response filter to allow ping responses from the external interface. It also discusses configuring additional external IP addresses on the ISA Server to respond to pings by creating new outbound and inbound ICMP packet filters applied to the additional IP addresses.
Original Title
Configuring ISA Server for Incoming Ping Responses
The document discusses configuring an ISA Server to respond to incoming ping requests by default it drops incoming ICMP ping packets for security. It provides steps to create a new packet filter based on the predefined ICMP ping response filter to allow ping responses from the external interface. It also discusses configuring additional external IP addresses on the ISA Server to respond to pings by creating new outbound and inbound ICMP packet filters applied to the additional IP addresses.
The document discusses configuring an ISA Server to respond to incoming ping requests by default it drops incoming ICMP ping packets for security. It provides steps to create a new packet filter based on the predefined ICMP ping response filter to allow ping responses from the external interface. It also discusses configuring additional external IP addresses on the ISA Server to respond to pings by creating new outbound and inbound ICMP packet filters applied to the additional IP addresses.
Download as DOCX, PDF, TXT or read online from Scribd
Download as docx, pdf, or txt
You are on page 1of 227
Configuring ISA Server for Incoming Ping Responses
Dieter Rauscher [MVP ISA Server]
By default after installing ISA Server you cant ping the ISA Server's external interface. This is due to ISA Servers handling of incoming ICMP ping query packets. They are all dropped. In most cases theres no need to change that behavior. I would say its one more little security feature. Thereby ISA Server is hidden to intruders who use ping to detect server presence. Also, if you dont use any publishing rules, your ISA wont be found by port scan attacks. When using publishing scenarios of course, it will be detected by specific port scans or port attacks. But that is not topic of this article. In exceptional cases it is necessary to configure the ISA Server to respond on external incoming ping requests. But my recommendation is not to change the default setting unless youve a good reason. Without any configuration you get this when pinging the external interface of the ISA Server:
(Dont wonder about Windows Version 5.2.3718. Its a second Windows Server 2003 in front of ISA Server.) To understand my current environment here is my ipconfig:
To enable ping response, we need to create a new packet filter based on a predefined IP Packet Filter definition:
Type a name to identify your Packet Filter
Yes, we want to allow transmission.
The guys from Microsoft made our life easiertheres a predefined Filter available.
In the first step of this tutorial we use the default IP address. Well take a closer look to that screen in the next part.
Its up to you to set further restrictions. Only this computer means that only the typed-in IP address is able to get a ping response.
The last wizard screen provides a short summary. Now lets do another ping if we made our work correct well get a different ping screen than above.
Great! It works! As shown in ipconfig ISA Server has several external IP Addresses. Lets try to ping the second one (192.168.69.71):
Oh no! Something must be wrong..? No. It's OK. Its normal. Remember, I mentioned at the screen Apply this packet filter to that well have a closer look at the other options later. Now its time to do so.
As shown in the screen above both relevant IP Packet Filters (marked) are configured to use Default external IP address. Thats the point. The default IP address of ISA is always the first IP address of the NIC. Dont be confused about the pre-defined Packet Filter ICMP ping response (in). That packet filter is necessary to receive the ICMP ping replies for outbound ICMP ping query request from ISA machine itself to the internet only.
If we want to use another IP, we have to configure two new IP Packet Filters. First we define a IP Packet Filter ICMP outbound for all types and codes:
In the next screen we select Allow packet transmission.
Now its time to tell ISA that we want to get the second IP address published:
Finish wizard by clicking Next. Let me show you the important screens for the second IP Packet Filter we need:
Lets have a look to the result:
How to create a packet filter for dropping ICMP Packets (Ping Requests) by Ellis M. George [Published on 7 March 2001 / Last Updated on 21 May 2013] How to create a packet filter for dropping ICMP Packets (Ping Requests). Select the Internet Security and Acceleration Server Snap-In and expand the tree by left clicking.
Select Access Policy and left click to expand the tree. Select IP Packet Filters, the existing filters should now be displayed in the right portion of the MMC screen. Right click on IP Packet Filters and select NEW > Filter
The wizard screen will open, type in a name for the rule, something descriptive so that you will know what the filter is supposed to do, then press next.
The wizard will now show a screen that will ask you which server(s) this rule should be applied too. If the ISA is a stand alone you can either choose the all option or specify the local server, and then click next.
The next wizard page will ask you to decide whether to block or allow packet transmission, make your choice and then press next. (Choose Block to not allow packet transmission.)
The next page will ask you to specify what the filter is to do, for this example we will choose the ICMP Ping Query, and press next.
This next page will ask you for the IP information for the ISA server or other computer in the ISA array that this rule is to be applied. Make the choice for your particular situation and press next.
This screen allows you to select which computer(s) you will apply this rule too. Since we are dropping ICMP Ping Requests select the All Remote computers and press next.
The final screen shows the information of the packet filter you have created, you can now cancel or click finish to apply the new rule to your array or server. This procedure can be used to create various packet filters for your ISA Server or Array.
Publishing Exchange Outlook Web App (OWA) with Microsoft Forefront Threat Management Gateway (TMG) 2010: Part 1 Preparing the Client Access Server (CAS) by Richard Hicks [Published on 20 July 2010 / Last Updated on 20 May 2013] 8 Preparing the CAS in order to publish Exchange OWA with Micrsoft TMG 2010. If you would like to read the next part in this article series please go to Publishing Exchange Outlook Web App (OWA) with Microsoft Forefront Threat Management Gateway (TMG) 2010 Part 2 Configuring TMG. Introduction Forefront Threat Management Gateway (TMG) 2010 includes support for publishing Microsoft Exchange Outlook Web App (OWA) for Exchange 2010, as well as Outlook Web Access for Exchange 2007, 2003, and 2000. In the first part of this two-part series we will go through the steps required to prepare the CAS server for publishing with TMG. In part two we will focus on actually publishing OWA using TMG. Preparing the Client Access Server (CAS) Before we can publish OWA using TMG, we need to make some configuration changes on the Exchange CAS server. With Exchange 2010, Forms Based Authentication (FBA) is now the default authentication method. Since TMG will be presenting its own authentication form to the client and pre-authenticating the user at the edge, well need to configure Exchange OWA to use NTLM authentication instead. To change the authentication method for OWA, open the Exchange management console and highlight Client Access under the Server Configuration node in the console tree.
Figure 1 Select the Outlook Web Apptab, and then right-click OWA (Default Web Site) and choose Properties.
Figure 2 Select the Authentication tab, then choose the option to Use one or more standard authentication methods:. For demonstration purposes I will choose Basic Authentication (password is sent in clear text). Since this communication is protected using SSL encryption, clear text passwords will not be visible on the network.
Figure 3 Select the Exchange Control Paneltab and then right-click the ECP (Default Web Site) and choose Properties.
Figure 4
Select the Authetnication tab, then choose the option to Use one or more standard authentication methods: and select Basic Authentication (password is sent in clear text).
Figure 5 Once complete, open an elevated command prompt and execute the iisreset /noforce command.
Figure 6 The last step in preparing the Exchange CAS is to obtain and install an SSL certificate for use by OWA. To do this, open the IIS management console and highlight the root node in the console tree.
Figure 7 In the main window, double-click Server Certificates.
Figure 8 In the Actions pane, click the Create Certificate Request link.
Figure 9 Complete the request form, making sure the Common Name field includes the Fully Qualified Domain Name (FQDN) of the CAS server.
Figure 10 Note: In our example we are using split DNS, so the external public-facing FQDN is identical to the internal FQDN. If you are not using split DNS it will be necessary to make separate certificate requests for each FQDN (internal and external). Select the appropriate Cryptographic Service Provider and Bit Length that meet your requirements. In most cases the defaults will be sufficient.
Figure 11 Specify a location to save the request file and submit the request to a Certificate Authority (CA).
Figure 12 Once the request has been processed by a CA, complete the request by clicking the Complete Certificate Request link.
Figure 13 Specify the location of the certificate file issued by the CA and enter a descriptive name.
Figure 14 To use this certificate with TMG well need to export the certificate along with its private key. Highlight the new certificate in the main window and In the Actionspane, click the Export link.
Figure 15 Specify the location to save the file and enter a strong password.
Figure 16 To assign this new certificate to the OWA web site, highlight the root node in the console tree.
Figure 17 In the Actions pane click the Bindings link.
Figure 18 Highlight the HTTPS protocol and choose Edit
Figure 19 Select the new certificate from the dropdown list.
Allowing Norton AntiVirus software LiveUpdate through ISA Server by Liran Zamir [Published on 17 March 2002 / Last Updated on 21 May 2013] 1 Many businesses use Norton AntiVirus servers to keep the companys servers and client computers virus free. In order to keep the virus definitions updated, the Live-Update is used to schedule virus definitions download to the main NAV server, which in turn, updates the client computers. Many businesses use Norton AntiVirus servers to keep the companys servers and client computers virus free. In order to keep the virus definitions updated, the Live-Update is used to schedule virus definitions download to the main NAV server, which in turn, updates the client computers.
From my experience, some integrators seem to be having difficulties with the LiveUpdate configuration on a network protected by ISA Server, so I decided to write this article.
The LiveUpdate feature requires both HTTP and FTP access to Symantecs web site. In order to configure ISA to allow the main server to download definition updates, use the following instructions: 1. Open the ISA management console. 2. Expand the Server -> Policy Elements -> Client Address sets in the ISA tree. 3. Create a Client address set named NAV Server. Enter the IP address of the server on which the Norton AntiVirus Server is installed. If the NAV server is installed on the ISA Server itself (such as in the case of SBS 2000), make sure that the IP address specified is the internal IP address of the server (the private ISA server IP address).
4. Expand the Access Policy object, and create a new rule in Protocol Rules. This rule should allow the specified client address set which was created in step 3 to access FTP and HTTP sites.
5. Install Symantec Norton Anti-Virus for Servers, include all the components recommended by Symantec. Open the Norton Antivirus Corporate Edition program.
From the File menu, select Live Update
Click on the Configure button, and move to the Proxy tab. As shown in the picture below, select I want to customize my proxy settings for LiveUpdate. Select both the HTTP Proxy and FTP Proxy.
Enter the ISA Servers private network IP address (internal) for both Proxy settings, use port 8080 for the HTTP Proxy, and port 21 for the FTP proxy. Apply the changes and click OK.
Click Next, and test the your ability to download the required updates.
6. To schedule a daily download of new virus definitions, open the Symantec System Center console, expend the System Hierarch, and right click the Norton Server group (by default named Norton Antivirus 1). Select All Tasks -> Norton AntiVirus -> Virus Definition Manager
In the Virus Definition Manager screen, select Update the primary Server Group only, in the How servers retrieve virus definitions updates and click configure.
Select the required schedule for the definition download. In order to check if the settings work, click Update Now. If the update was successful, an event ID 16 should be logged in the servers application log, which will inform you if the definitions are current (was able to connect, but no download was required), or if the download of the virus definition file was successful. Note! There is no need to configure the LiveUpdate proxy use from the Symantec System Center. 7. Dont forget to additionally configure how Client computer retrieve the definition update. The recommended way is to Update virus definitions from parent server. That way, the new virus definitions will only be downloaded by the NAV server, and not by the client computer. Fixing the Symantec LiveUpdate Problem. by Thomas Shinder [Published on 19 Dec. 2001 / Last Updated on 20 May 2013] Some of you might have noticed that you cant update your virus definitions using the Norton Antivirus LiveUpdate feature after installing ISA Server. I ran into this one myself a few weeks ago. After a bit of head banging, I found a configuration that should work for everyone. Some of you might have noticed that you cant update your virus definitions using the Norton Antivirus LiveUpdate feature after installing ISA Server. I ran into this one myself a few weeks ago. After a bit of head banging, I found a configuration that should work for everyone. If you have problems getting Live Update to work, take a look at the follow procedures. Scenario 1: Browser Configured as a Web Proxy Client Perform the following steps if you are using the Web Proxy client configuration: 1. Click Start and point to Settings. Click on Control Panel. 2. In the Control Panel, click on Symantec LiveUpdate. 3. In the LiveUpdate Configuration dialog box, select the Internet Options in the Control Panel option. Configuring ISA Server 2000 : Building Firewalls for Windows 2000 By Deb and Tom Shinder
Amazon.com
4. Click on the Proxy tab. Select the I want to use my Internet Explorer proxy settings option.
5. Click Apply and then click OK. Scenario 2: Browser Not Configured as Web Proxy Client In this scenario your machine is configure as either a SecureNAT or a Firewall client. When a SecureNAT or Firewall client sends a request to the ISA Server, the request can be handled by the Web Proxy service, or it can be sent directly to the Web server. How the request is dispatched depends on the configuration of the HTTP Redirector Filter. If you want to make life easy, youll configure the HTTP Redirector filter to forward requests directly to the Web server. Note that, while configuring the HTTP Redirector Filter to send the requests directly to the server will make life easier for you when it comes to dealing with LiveUpdate, it will ruin your ability to force everyone to use the Web Proxy service. The reason is that if you want to force everyone to use the Web Proxy client to access HTTP sites, you must configure the HTTP Redirector filter to drop requests from SecureNAT and Firewall clients. 1. Click Start and point to Settings. Click on Control Panel. 2. In the Control Panel, click on Symantec LiveUpdate. 3. In the LiveUpdate Configuration dialog box, select the Internet Options in the Control Panel option. 4. Click on the Proxy tab. 5. On the Proxy tab, select the I dont connect to the Internet through a proxy server option. You select this option because the SecureNAT and Firewall clients are not aware of the Proxy server, and you dont want the LiveUpdate feature to be aware of it either.
6. Now go to the ISA Server Management console at the ISA Server itself (I dont trust the ISA MMC on remote computers; you can use Terminal Services though, if you want). 7. Expand your server name, then expand the Extensions node. Click on the Application Filters node. Double click on the HTTP Redirector Filter entry in the right pane of the console. 8. In the HTTP Redirector Filter Properties dialog box, click on the Options tab. 9. On the Options tab, select the Send to requested Web server option. Click Apply and then click OK.
You dont need to restart the server. Now go back to the SecureNAT or Firewall client on the internal network, and enjoy the LiveUpdate feature, now that it works again!
How to use ISA Server Packet Filters. by Thomas Shinder [Published on 28 Nov. 2001 / Last Updated on 20 May 2013] ISA Server uses packet filtering to control inbound and outbound access to and from the external interface of the ISA Server. Packet filtering is the ISA Server's first line of defense against inbound attack. The ISA packet filtering feature supplements the RRAS packet filtering. If you have RRAS packet filtering enabled, you should not use it to control inbound and outbound access to and from the external interface of the ISA Server. ISA Server uses packet filtering to control inbound and outbound access to and from the external interface of the ISA Server. Packet filtering is the ISA Server's first line of defense against inbound attack. The ISA packet filtering feature supplements the RRAS packet filtering. If you have Configuring ISA Server 2000 : Building Firewalls for Windows 2000 By Deb and Tom Shinder
RRAS packet filtering enabled, you should not use it to control inbound and outbound access to and from the external interface of the ISA Server. In order for packet filtering to work, it has to be enabled. Perform the following steps to see if packet filtering is enabled on the ISA Server:
Amazon.com 1. Right click on the IP Packet Filters node in the left pane of the ISA Server Management console and click Properties.
2. On the General tab put a checkmark in the Enable packet filtering checkbox to activate packet filtering.
3. While youre there, you might want to enable IP Routing, if you wish internal SecureNAT clients to have access to non-TCP/UDP protocols such as ICMP and GRE. Packet Filtering is only available when you are running the Firewall Service. The Firewall Service is present when you install ISA Server in either Integrated or Firewall only mode. If you install ISA Server in Cache mode only, you will not be able to implement packet filtering. You can find the ISA Server Mode right clicking on your server name in the left pane of the ISA Management console and clicking the Properties command. Youll see the Mode in the General tab.
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 ISA Server at the Edge of the Network When you enable packet filtering, ISA Server closes off all ports on the external interface that do not have a packet filter explicitly 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.
Note that the absence of packet filters does not prevent inbound or outbound access to and from the internal network. You should always use Protocol Rules to allow outbound access to external network resource for internal network clients. You should Web Publishing and Server Publishing Rules to allow inbound access from external network clients to internal 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 on the Internet, you can make sure that no ports have been opened inadvertently by enabling packet filtering. By default, the only traffic that is allowed when packet filtering is enabled are some ICMP packets required for basic network management, and a DNS filter that allows the ISA Server to make DNS queries on the behalf of Web Proxy and Firewall clients on the internal network. 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 packet filters. If there is no filter that allows 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 commented to me 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. 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 is when you configure the web browser running on the ISA Server itself. In this case, you can configure the web browser to be a Web Proxy client. In this way, you can get around creating a packet filter for outbound HTTP. 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. When Should I Not Create Packet Filters?
Packet filters should not be used for the following purposes: To control inbound access to internal network servers To control outbound access from ISA Server clients I find that a lot of people posting on the message boards claim that they must create packet filters to make their access policies work correctly. This is not the case in the vast majority of cases. However, there are some special circumstances where you need to configure Packet Filters instead of Protocol Rules to support outbound access. Packet Filters and Inbound Access Control Access to servers on the internal network is accomplished 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 is a misconception that you need to manually enable packet filters for Server Publishing or Web Publishing Rules to work. This is not true. You can confirm that the Publishing Rule has opened up the port by running the command: netstat na In the output, scroll 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. You can use the following command to help you find a port of interest more quickly: netstat na | find :25 Replace the 25 with the port number you are looking for in the print out. 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 protocol access, since Site and Content rules are focused only on site names. When you create a Protocol Rule, ISA Server will allow inbound and outbound access to 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. The only exception to the above is when you need to allow outbound access to non-TCP/UDP protocols. Protocol Rules are based on Protocol Definitions. You can only create Protocol Definitions for TCP and UDP based protocols. Therefore, if you need to allow outbound access to protocols such as ICMP or GRE, you must create packet filters to allow SecureNAT clients outbound access to these non-TCP/UDP protocols. NOTE: Keep in mind that while you can allow SecureNAT clients to access these non-TCP/UDP protocols using packet filters, you cannot apply access controls. For example, if you enable outbound PPTP through the ISA Server, ALL SecureNAT clients will have access to outbound PPTP. The same is true for ICMP based protocols, such as PING. All SecureNAT clients will have access to outbound ICMP and PING. 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. 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 open the ports specified in the rules.
TMG Back to Basics - Part 2: Using the TMG Firewall Log Viewer by Deb Shinder [Published on 14 Dec. 2010 / Last Updated on 20 May 2013] This article provides an overview of the TMG firewall's logging features. If you would like to read the other parts in this article series please go to: TMG Back to Basics - Part 1: Server Publishing Rules TMG back to Basics - Part 3: Protocol Definitions TMG Back to Basics - Part 4: Network Objects TMG Back to Basics - Part 5: Network Objects (Cont.) TMG Back to Basics - Part 6: Reports TMG Back to Basics - Part 7: SharePoint Server Publishing TMG Back to Basics - Part 8: SafeSearch, URL Filtering and Certificate Revocation Options Introduction Continuing our Back to Basics series, this time were going to talk about how to use the TMG Firewall log viewer. The TMG firewall, like the ISA firewall before it, is a product that can do many good things. It can serve as a network firewall, forward and reverse web proxy server, remote access VPN server, site to site VPN server, and web anti-malware and URL filtering server; these are some of the key roles the TMG firewall can play on your network. But one feature that might not be apparent to the new TMG firewall administrator is the powerful and useful logging feature. In this article, well provide an overview of the TMG firewalls logging feature. Theres no better way to understand how it works than to see it in action. To begin our overview, lets click the Logs & Reports node in the left pane of the TMG firewall console, as seen in Figure 1 below.
Figure 1 In the Task Pane, on the Tasks Tab, youll see a number of options available for configuring and running the logging function on the TMG firewall. Lets start by clicking the Configure Firewall Logging link in the Tasks Tab, as seen in Figure 2 below.
Figure 2 This brings up the Firewall Logging Properties dialog box. On the Log tab, you can choose what type of logging you want to enable. There are three options: SQL Server Express Database (on local server) DQL Database File The default setting is SQL Server Express Database (on local server). If you want to log to an off-box SQL server, you would select the SQL Database option and then click the Options button to configure what SQL database the TMG firewall would use for logging. If you want to log to a flat file, you can select the File option and then select the file type; in this case, both W3C extended log file format and TMG Log File format are available options. So how do you decide which is best for you? File logging is faster than SQL logging, but you have limited query abilities on flat file logging, so if you dont have an off-box SQL database you want to use, I recommend that you use the default logging option. Click the Options button to the right of the SQL Server Express Database (on local server) option, which is shown in Figure 3.
Figure 3 In the Options dialog box, configure the location where you want to save the log files, as shown in Figure 4. The default location is the Logs folder in the default TMG installation folder on the local hard disk, but you can select another location by typing in the full path or browsing for it. You can also configure log file storage limits. The defaults are: Limit total size of log files is limited to 8 GB by default Main free disk space is set to 512 MB by default this prevents the hard disk from becoming full with log files Main log storage limits by : Deleting older log files as necessary is the default setting when storage limits are exceeded; you also have the option to discard new entries if you prefer to keep the old entries Delete files older than (days) is set to 7 by default Notice that the Compress log files option is grayed out when we selected to log to a SQL or SQL Express database. This is because you can only compress flat file logs.
Figure 4 Click the Fields tab, shown in Figure 5. Here you can specify which fields the TMG firewall will log for each of the connections that are logged to the firewall service. If you find that your log files are too large, one thing you can do to decrease the size is to reduce the number of fields that are logged for the connections.
Figure 5 Note that similar options are available when you click the Configure Web Proxy Logging link in the Tasks Tab on the Task Pane. Now, we will click the Configure Log Queue link in the Tasks Tab on the Task Pane. This brings up the Log Queue Storage Folder dialog box thats shown in Figure 6. Here you can configure where you want to place the log queue. The log queue is a storage location for log entries that need to wait for the firewall to format them properly. The purpose of the log queue is to allow the TMG firewall to keep log entries that might have otherwise been lost because they were coming in too quickly. With the TMG firewall log queue, these entries are quickly placed in the queue and will wait there until the firewall is able to process the log entries.
Figure 6 Now click the View Log Status link in the Tasks Tab in the Task Pane. This will display the Log Status dialog box, which is shown in Figure 7. You can view the following information here: Server shows the server where the log queue is being reported Updated Up To shows the time to which the log file has been updated Log Queue (KB) shows the number of log entries that are currently in the log queue Status shows the status of the log queue This is all useful information to check when you suspect that youre getting flooded by a virus or worms.
Figure 7 Next, click the Define Log Text Colors link on the Tasks Tab in the Task Pane and you will see the Define Log Text Colors dialog box thats shown in Figure 8. The default colors are listed here for the most common log file entries of interest. Color coding of the log file entries makes it much easier for you to get a quick visual representations of what how many entries of each type there are, and to find the entries youre looking for. You can click the Color button if you want to change the color of any of these entries. Another handy feature is that you can use the Export Colors Scheme and Import Colors Scheme button to export and import color schemes from other TMG firewalls.
Figure 8 The Hide IPv6 log entries link in the Tasks Tab on the Task Pane, shown in Figure 9, is a very useful option. When you spend a lot of time reading TMG log files, youll find that there are a very large number of IPv6 broadcasts on your network. These IPv6 entries can make the log file very cluttered and hard to eyeball. When you click this button, the IPv6 entries will still be logged, but they will be hidden from view so that its easier for you to view the log entries without the IPv6 noise.
Figure 9 Now click the Edit Filter link in the Tasks Tab on the Task Pane. Here you will see that there are three default values: Log Record Type is set to firewall or web proxy filter. You typically will not change this. Log Time is set to live you will sometimes want to change this Action is set to not equal Connection Status this helps reduce the noise in the log file filter In Figure 10 below, you can see that I have selected the Log Time entry and then clicked the down arrow for the Condition drop down box. You will see here that there are many options for filtering the time window for the log file entries you want to see. Note that after you change the value, you will need to click the Update button to change the filtering value.
Figure 10 You can filter the log files by a large number of factors. In Figures 11, 12 and 13 below you can see the options in the Filter by drop down list. When you select a value on this list, you then click the Condition down arrow to select the condition and then you set the Value. After you do these three things, you click the Add To List button so that it will appear in the list of filters.
Figure 11
Figure 12
Figure 13 In the Figure 14 below, I selected the Client IP entry in the Filter by drop down list. Then I clicked the down arrow for the Condition drop down box. Here you can see that you have a number of choices, which allows you to drill down to the entries that interest you the most.
Figure 14 After you make the selections you want for the log filter, click the Start Query button. After a while, you will see in the status bar on the bottom on the console that the Query is done and it will show you the number of log file entries that match the parameters of your query, as shown in Figure 15.
Figure 15 The results of the query will appear in the console and the colors of the entries will match those that you configured in the log colors dialog box we saw earlier. Notice that the names of the fields are in the columns for each of the log file entries, as shown in Figure 16. You can scroll to the right to see the details of each of the log file entries.
Figure 16 Note that the columns you see at first are the default fields configured to be displayed. If there is a field that youre interested in and it doesnt appear, you can right click one of the columns and click the Add/Remove Columns command, as seen in Figure 17 below.
Figure 17 This brings up the Add/Remove Columns dialog box. On the left side is a list of Available columns, which you can see in Figure 18. Scroll through the list and find the field(s) that youre interested in and then click the Add button to move it to the Displayed columns section. Click OK and then return to the console. Now scroll to the right and youll see the information for those columns you added listed for the log file entries you filtered. Nice!
Figure 18 When you click on a log file entry, you can see more details in the details section under the list of the log file entries. In Figure 19 below you can see detailed information about the entry, including valuable HTTP and proxy related information in the Additional information section.
Figure 19 Summary In this Back to Basics article, we showed you a high level overview of the logging and log filtering features that are included with the TMG firewall. As you can see, the TMG firewall logs a great deal of information about each connection made to and through the TMG firewall. You can use the log viewer to drill down to the entries that are of most interest to you and the filtering process is comprehensive and very easy to configure. I hope you enjoyed this overview and if you have any questions about how to use the logging and filtering feature included with the TMG firewall, let me know! Write to me at [email protected] and Ill get back to you as soon as I can. Thanks! If you would like to read the other parts in this article series please go Home Articles & Tutorials Miscellaneous Fix for ISA stall when ODBC data source is unavailable. by Jens Madsen [Published on 19 Dec. 2001 / Last Updated on 21 May 2013] 1 One weekend I had an ISA server failure due to the SQL server that is used for my logs was unavailable. ISA server stalls its services if the ODBC data source becomes unavailable or when it cant authenticate to the SQL server.
One weekend I had an ISA server failure due to the SQL server that is used for my logs was unavailable. ISA server stalls its services if the ODBC data source becomes unavailable or when it cant authenticate to the SQL server. This gave me some problems since I couldnt get in remotely (ISA wouldnt let any traffic thru) to change the ISA logging configuration and restart the services. I found a way to have ISA reconfigure itself to use text logging and restart its services by using alerts and events in case ISA cant connect or authenticate to its ODBC data source. 1. Reconfigure all three services in the Logs node to log to text files and save the configuration. Do not restart the services since this is only a temporary configuration.
2. Start the registry editor (Regedit.exe) and export the following branch to the root of the c: drive. Name the file txt-logs.reg:
Hkey_Local_Machine\Software\Microsoft\Fpc\Arrays\{GUID}\Logs Verify that you have a registry file on your c: drive called: txt-logs.reg 3. Configure all three services in the Logs node back to log to your already defined ODBC data source and save the configuration. (I assume you were already using an ODBC data source for logging). Do not restart the services since the reconfiguration in step 1 was never in effect (we didnt restart the services in that step).
4. Configure Invalid ODBC log credential alert in the Alerts node. On the General tab; make sure that alert is enabled. The Events tab should be left unchanged (let the event fire on the first occurrence). The Actions tab is where the important configuration is done. Check the Program switch and enter regedit /s c:\txt-logs.reg in the Run this program field. This will let regedit merge the registry branch we saved earlier back into the registry and reconfigure ISA to log to text logs. The /s switch after regedit will do it in silent mode (you will not get an annoying dialog on the screen telling you the branch was imported into the registry). Check the Stop selected services switch, click on the Select button and make sure all three services are selected. Then check the Start selected services switch, click on the Select button and make sure all three services are selected. This will stop and then start all three services so that the reconfiguration of the logging that was entered into the registry will take effect.
I tested this setup by all of a sudden just downing my SQL server. The alert came up which then triggered the event that modified my registry and restarted the services. It worked beautifully. There was only a short (seconds) interruption of the services. Once the database server is again available I can reconfigure the ISA back to ODBC logging and restart the services manually. Also the text logs can be imported back into your database server using Access or Foxpro. It might be a good idea to also send an e-mail alert in case this happens, since the re- configuration and starting/stopping of the services is pretty transparent. The reconfiguration options based on alerts are endless when you know where to pull the configuration parameters out of the registry (and merge them in again). Hope this is a helpful little trick.
SA 2006 Dashboard System Performance Monitoring DOA by Debra Shinder [Published on 17 Oct. 2006 / Last Updated on 17 Oct. 2006] During beta testing of the 2006 ISA Firewall I noticed that a few of the versions came with a broken packet counting feature on the ISA Firewall monitoring Dashboard. I figured it was just a beta bug and that it would be fixed in the RTM version of the 2006 ISA Firewall. In fact, I was right about this, because there was a final version of the ISA Firewall, released during the beta phase of the product, where the packet performance graphs worked correctly. So what's the beef? The final beta version of the ISA Firewall apparently wasn't the one used in the RTM product, because in the RTM ISA 2006 Standard Edition release, the packet graphs in the System Performance area of the Dashboard no workie, as you can see in the figure below.
I'm posting this not to just complain, but to find out if anyone else has noticed the same thing, and if so, has anyone found a "secret fix" to get the graphs working again. I'm sure it will be fixed by ISA 2006 SP1, but if there's a way to get them working again before that, it would be great! Missing in Action -- Log Off When User Leaves Site by Debra Shinder [Published on 16 Oct. 2006 / Last Updated on 16 Oct. 2006] One of the nice features included with the ISA 2004 Firewall was the ability to publish an OWA Web site and configure the Web listener for the rule to automatically log the user off when the user moves to a different site in the same browser session. For example, the user might be at an airport kiosk and log onto his email account using OWA. Then the user might enter the URL to the www.foxnews.com site to check on the latest news. In ISA 2004, if the user returned to the OWA site clicking the back button a few times, he would have to log in again because the Web listener would be configured to log the user off when he leaves the site. Apparently, this feature was supposed to be included in the 2006 ISA Firewall, but somehow got left on the cutting room floor. Why do I think it was supposed to be included with the new ISA Firewall? Check out the screenshot below of the ISA 2006 Help File:
However, if you check out the dialog box that this Help File entry refers to, you'll see:
Perhaps there is a Registry entry that will enable this behavior? If so, I'm not aware of it. Hopefully this setting will be returned to us with ISA 2006 SP1 is released. SA 2006 Firewall Alerts -- Doing Their Job by Debra Shinder [Published on 12 Oct. 2006 / Last Updated on 12 Oct. 2006] Most of the books and instructional materials aren't very good at providing you a good look at a live ISA Firewall and the alerting mechanism on a production ISA Firewall deployment. Because of that, I thought I'd share a screenshot with you of one of my ISA Firewall's Alerts Section and also it's performance console. Nothing really to teach here, but it gives you something neat to look at :)
HTH, How to setup SQL Logging in ISA Server. by Nathan Obert [Published on 5 March 2001 / Last Updated on 21 May 2013] How to setup SQL Logging in ISA Server. How to setup SQL Logging in ISA Server. 1. Create service account in Active Directory/User Manager. 2. Open SQL Enterprise Manager
3. Create new database in SQL Server (SQL Enterprise Manager)
4. Create login in SQL Enterprise Manager, using NT Account from step #1.
5. Assign login 'db_owner' security of newly created database.
6. Locate SQL Files on ISA Server CD (g:\isa\*.sql)
7. Open all 3 files individually and run from Query Analyzer. This will create tables and indexes.
8. Open Data Sources (ODBC) within Administrative Tools.
9. Create new System DSN by clicking on 'Add'.
10. Select SQL Server, and click 'Finish'.
11. Type in Name, and Description. Select your SQL server from dropdown. (click next)
12. Click Next
13. Select 'Change the default database to:' and select newly created database.
14. Click Next.
15. Click 'Test Data Source...'
16. Click 'OK'. As you can see everything is setup right so far.
17. Select 'Monitoring Configuration' and then 'Logs'. The next steps involve reconfiguring the 3 components in the above screenshot. 18. Double click on each of the 3 components individually and configure as instructed below.
19. Select 'Database' 20. Make sure the DSN matches the one you just created. 21. Table name is 'FirewallLog' . 22. Click 'Set Account', and choose the account you created. Note: In this example a local account was used, so no domain name is displayed.
23. Same as previous steps but Table Name is 'PacketFilterLog'.
24. Same as previous steps but Table Name is 'WebProxyLog'.
Sign in
The Private Cloud Man Private Cloud Technologies, Architecture and more! Options Home About Email Blog Author Share this RSS for posts Atom RSS for comments Search Blogs
Search this blog Search all blogs Tags Certificates Contest DA DirectAccess Fun Infrastructure IP-HTTPS IPv6 IPv6 Transition Technology ISATAP NAP Security Split Tunneling SSTP Teredo test lab guides The Edge Man TLG TLGs Tom Shinder tomsh Troubleshooting UAG UAG SP1 RC Unfied Access Gateway Archive June 2013 (1) April 2013 (1) January 2013 (1) November 2012 (1) March 2012 (1) May 2011 (1) April 2011 (6) March 2011 (6) February 2011 (10) January 2011 (14) December 2010 (16) November 2010 (13) October 2010 (11) September 2010 (2) August 2010 (6) July 2010 (4) June 2010 (4) May 2010 (4) April 2010 (4) March 2010 (6) February 2010 (1) TechNet Blogs The Private Cloud Man Considerations When Using Ping to Troubleshoot DirectAccess Connectivity Issues Considerations When Using Ping to Troubleshoot DirectAccess Connectivity Issues Thomas W Shinder - MSFT 13 Jul 2010 7:06 PM 2 Youre learning about DirectAccess and you like what you see. The next step is to build out a test lab. You can build out your own, or you can let me to the heavy lifting for you and use the UAG DirectAccess Step by Step Guide over at http://technet.microsoft.com/en- us/library/ee861167.aspx Youll save a lot of time by using the lab I put together for you, and youll learn a lot about DirectAccess terminology and configuration issues. When you do put your Test Lab together, youll find that there are a lot of technologies and a lot of steps involved with making it work. The reason for this is that DirectAccess is really a collection of product and platform technologies that work together to create a working remote access solution that weve named DirectAccess. All the components of the solution need to be configured correctly for it to work. And that will likely be your first challenge when you start working with DirectAccess. Youll have gone through all the steps in the Step by Step guide and BAM! It didnt work. Dont worry a lot of the technologies are probably new to you. That means theres a good chance that you missed a step. Ive done it, other DirectAccess experts have done it. Consider this a normal part of the DirectAccess learning process. After youve gone through the test lab a few times, all the concepts and technologies will fall into place in your mind and youll actually get to a place where youll forget what it was like not to understand how all the DirectAccess pieces fit together. With that in mind, I wanted to take a few minutes to talk to you about using ping to test DirectAccess connectivity. Were all accustomed to using ping to test connectivity issues this is something firmly ingrained in all of our years with working with the Windows network operating system. And while you definitely can take advantage of ping to help you troubleshoot DirectAccess connectivity issues, there are a few things that you need to keep in mind about ICMP and DirectAccess connectivity. DirectAccess Tunnels are IPsec Tunnels First, remember that DirectAccess uses IPsec tunnels between the DirectAccess client and DirectAccess server to allow DirectAccess clients access to intranet resources. There are two tunnels: The Infrastructure Tunnel the purpose of this tunnel is to allow the DirectAccess client to a subset of servers on the intranet that are required for name resolution (DNS servers) and authentication (domain controllers) and health checking (NAP servers) and remediation (update servers). There may also be other servers you want to include in this list, such as management servers (Configuration Manager). The infrastructure IPsec tunnel is established after both computer certificate and computer account (NTLMv2) authentication is successful. Enabling the user account (normally computer account) access allows the Infrastructure tunnel to come up before the user logs on. The Intranet Tunnel the purpose of this tunnel is to allow the DirectAccess clients access to the rest of the network. It should be clear that DirectAccess is not a firewall solution and should not be considered one. DirectAccess is meant to replicate the intranet experience and the DirectAccess client should be considered the same as any client on the intranet. For that reason, there are no access controls places on the DirectAccess client after the DirectAccess client authenticates with the DirectAccess server. The intranet IPsec tunnel is established after computer certificate and user account (the logged on user) (Kerberos) authentication is successful. It is commonly said by DirectAccess experts (including myself) that all traffic moving through the DirectAccess client to resources on the intranet is through one of these tunnels. This is true for all traffic except ICMP traffic. In a UAG DirectAccess scenario, IPsec policy is configured to exempt ICMP from IPsec authentication and encryption. Therefore when you ping a resource on the intranet, you are sending those pings outside of the infrastructure and intranet IPsec DirectAccess tunnels. Now you might be asking yourself If the ping traffic isnt going through the DirectAccess tunnels, how it is getting to the intranet? Thats a good question and unless youve been in the IPv6 transition technology game for awhile, the answer is definitely not obvious. A Tale of Two Tunnels Take a look at the figure below. What I tried to draw here are two tunnels. The larger tunnel is an IPv6 transition technology tunnel. IPv6 transition technologies can be used to allow the IPv6 communications between the DirectAccess client and DirectAccess server to be carried over the IPv4 Internet. The DirectAccess client can use one of three IPv6 transition technologies over the Internet: 6to4, Teredo or IP-HTTPS. The details of each these isnt important here. What is important is to understand is that each of these IPv6 transition technologies tunnel IPv6 packets inside an IPv4 header. Inside of the IPv6 transition technology IPv4 tunnel is the IPsec tunnel where IPsec is used to authenticate and encrypt the IPv6 packets. When you think about DirectAccess tunnels, you should think of two tunnels the IPv6 transition technology tunnel and the IPsec tunnel.
The above figure shows that ICMP messages are carried over the IPv6 transition technology tunnel, but that they are outside the IPsec tunnel. The reason why we decided to do this is to make Teredo work correctly, as Teredo requires ICMP access outside the IPv6 IPsec tunnel to determine what type of NAT device the DirectAccess client might be located. What are the Issues Related to ICMP Being Passed Outside the IPsec Tunnel? Because of this decision, you need to be aware of a couple of issues: Since the ICMP traffic is not encrypted, it can potentially be read by a device that is IPv6 transition technology aware. This information might be of interest to attackers or other curious individuals. For information on this issue, please see http://technet.microsoft.com/en- us/library/ee809059.aspx Be aware that if you force ICMP through the DirectAccess IPsec tunnels, you will not be able to use Teredo. When troubleshooting DirectAccess connectivity issues, the ability to ping resources on the intranet indicates that the IPv6 transition technology is working, but does not provide any information regarding whether or not the infrastructure or intranet IPsec tunnels were established. Before going into the details of ICMP traffic and troubleshooting, I wanted to point out where the ICMP exemptions for IPsec traffic are configured. In the first figure below you can see the Group Policy Object (GPO) for the DirectAccess servers. When you right click the Windows Firewall with Advanced Security LDAP {GUID} entry and click Properties, youll see what appears in the figure right below it in the Windows Firewall with Advanced Security dialog box, on the IPsec Settings tab. In the IPsec exemptions frame, youll see the Exempt ICMP from IPsec option is set to Yes.
ICMP, Ping and Troubleshooting DirectAccess Connectivity Now lets take a look at what happens when the IPsec infrastructure and intranet tunnels fail. In this example, I took a working DirectAccess setup and broke it by configuring the UAG DirectAccess server to use the wrong root certificate for mutual computer authentication. Since the root certificate configured in the UAG DirectAccess configuration points to a root CA that didnt issue the computer certificates used for computer certificate authentication, all IPsec tunnel connection attempts will fail. One of the standard things we do when troubleshooting DirectAccess connections is to see if we can ping the 6to4 address of the UAG DirectAccess server itself. You can get this address by using the netsh namespace show effectivepolicy command on the DirectAccess client, as seen in the figure below.
Now that we have that address, lets try and ping it.
Yay! That worked and shows that we have IPv6 connectivity with the DirectAccess server. This proves that at least the IPv6 transition technology is working enough so that we can ping the UAG DirectAccess server side of the Teredo (in this example) tunnel. What it doesnt tell us is if the other components that allow address to resources behind the UAG DirectAccess server are functional. To enable ICMP access to resources behind the UAG DirectAccess server, you will need to know the IPv6 address of the resource you want to connect to. This can be an ISATAP address or a native IPv6 address (or as well see later, a NAT64 address). It doesnt matter which type what matters is the fact that the DirectAccess client only communicates with the DirectAccess server and the networks behind it using IPv6 (except when NAT64/DNS64 is used, in which case the communications are NATed by the UAG DirectAccess server, so that between the DirectAccess client and the UAG DirectAccess server IPv6 is used and communications between the UAG DirectAccess server and the IPv4 resource on the intranet, IPv4 is used). We can go to the domain controller on the network and use ipconfig /all to check its ISATAP address. In this example the ISATAP address of the domain controller (DC1) is 2002:836b:2:8000:5efe:10.0.0.1 so well ping that ISATAP IPv6 address from the DirectAccess client on the Internet.
Yay again! It worked. Now we know that the Teredo tunnel between the DirectAccess client and the DirectAccess server is up, and that the Teredo relay configured on the UAG DirectAccess is working. What About IPv4 Only Resources How Do I Ping Them? What if youre not using ISATAP and youre not using native IPv6 addresses behind the UAG DirectAccess server? This is a common scenario where you have an IPv4-only network behind the UAG DirectAccess server. In this case, youre taking advantage of the UAG DirectAccess servers NAT64/DNS64 capabilities. If you want to learn more about NAT64/DNS64, I highly recommend you read Meir Mendelovichs excellent coverage of this subject over at http://blogs.technet.com/b/edgeaccessblog/archive/2009/09/08/deep-dive-into-directaccess- nat64-and-dns64-in-action.aspx The problem we have to solve is how do we figure out what the NAT64 address is of an IPv4 only host? Well, the answer comes from an exceptional blog post by Ben Bernstein over at http://blogs.technet.com/b/edgeaccessblog/archive/2009/10/13/deep-dive-into-uag-directaccess- ipv6-and-directaccess.aspx The UAG NAT64 address of an IPv4 only host is: 2002:WWXX:YYZZ:8001:[Hex of IPv4 address] /96 (the /96 means that the prefix is 96 bits of the 128 bit IPv6 address) The WWXX:YYZZ is the Hex representation of the first of the two consecutive IPv4 public address on the UAG DirectAccess Server. You can figure this out if you like, but UAG has already done this work for you. If you look in the figure above, you can see these components of the IPv6 address: 836b:2: this is the WWXX:YYZZ Hex representation of the IPv4 address 8000: this is the value used to represent the ISATAP prefix (this is covered in more detail in Bens article if you want more information in this) What we can do is take this information and build out our NAT64 address for the IPv4 only resource. First, we can define our prefix, which is: 2002:836b:2:8001 /96 (the 8001 value is used to represent the NAT64 prefix) The last 32 bits of the address is Hex representation of the IPv4 only resource. In this example, the IPv4 only resource has the IPv4 address 10.0.0.4. We convert to this to Hex: 10 = 0a in Hex (8 bits) 0 = 00 in Hex (8 bits) 0 = 00 in Hex (8 bits) 4 = 04 in Hex (8 bits) Or 0a00:0004 (32 bits represented by two 16 bit blocks) Now we can put our prefix and address together and get: 2002:836b:2:8001:0000:0000:0a00:0004 /96 You might be wondering where the 0000:0000 entry came from. First, you need to know that each block (the value between the colons) represents 16 bits. There are eight blocks in a 128 bit IPv6 address. We defined the first 64 bits of the NAT64 prefix with the four blocks 2002:836b:2:8001. However, the NAT64 prefix is 96 bits, so we need to add another 32 bits to the prefix to make it add up to 96. We can do this by adding two blocks of zeros. That gives us the 96 bit prefix. Then we just append the Hex presentation of the 32 bit IPv4 address at the end. NOTE: There is something called zero suppression when describing IPv6 addresses where leading zeros can be left out and where they can be replaced with a double colon ::. We dont need to get into that now, but youll notice that is done automatically by the operating system when it converts the WWXX:YYZZ and also in the ping responses. Lets give it a try.
Yay for a third time! It worked again. This proves that we have ICMP connectivity to both IPv6 and IPv4 resources on the intranet. At this point we must be feeling pretty good, as weve successfully pinged the UAG DirectAccess server and a IPv4 and IPv6 resources on the intranet. But what about traffic isnt ICMP? A quick check can be done by using the web browser. In the figure below Im using the ISATAP address of a web server on the intranet. Notice that if you want to use IPv6 addresses in Internet Explorer, you have to surround them with brackets.
This connection fails because its using HTTP, which isnt ICMP. The reason for the failure is that in order to transport HTTP, the DirectAccess IPsec tunnels must be available. And because I broke IPsec, there are no tunnels. You can prove that to yourself by using the Windows Firewall with Advanced Security console and finding no Main Mode or Quick Mode Security Associations. There is a process to troubleshoot IPsec tunnel establishment failure, but thats not why were here today :) Summary The key points I want you to remember from this article include: DirectAccess uses two tunnels: IPv6 transition technology tunnels and an IPsec tunnels ICMP is exempted from IPsec protection You can ping the UAG DirectAccess server and resources behind it without establishing an IPsec tunnel If the IPsec tunnels do not come up, you will not be able to use any non-ICMP protocol to connect to the the UAG DirectAccess server or resources behind it The ability to ping gives you no information about IPsec tunnel establishment. TMG Back to Basics - Part 1: Server Publishing Rules by Deb Shinder [Published on 30 Nov. 2010 / Last Updated on 20 May 2013] 3 TMG Back to Basics series, is a continuation of the "Controlling Internet Access: A short Primer on TMG Access Rules" series for new TMG administrators. Weve already covered Web Publishing Rules, Networks and Network Rules, and Access Rules. If you would like to read the other parts in this article series please go to: TMG Back to Basics - Part 2: Using the TMG Firewall Log Viewer TMG back to Basics - Part 3: Protocol Definitions TMG Back to Basics - Part 4: Network Objects TMG Back to Basics - Part 5: Network Objects (Cont.) TMG Back to Basics - Part 6: Reports TMG Back to Basics - Part 7: SharePoint Server Publishing TMG Back to Basics - Part 8: SafeSearch, URL Filtering and Certificate Revocation Options If you would like to revert back to the "Controlling Internet Access: A short Primer on TMG Access Rules" series please go to: Controlling Internet Access: A Short Primer on TMG Access Rules (Part 1) Controlling Internet Access: A Short Primer on TMG Access Rules (Part 2) Controlling Internet Access: A Short Primer on TMG Access Rules - Part 3: TMG Firewall Web Publishing Rule Basics Controlling Internet Access: A short Primer on TMG Access Rules - Part 4: TMG Networks and Network Rules Introduction If youre new to the TMG firewall, you might have wondered what Server Publishing Rules are all about. The good news is that Server Publishing Rules are really simple they are essentially reverse Network Address Translation rules that allow you to reverse NAT for a number of protocols. However, Server Publishing Rules are more than just reverse NAT, because the TMG firewall includes a number of Application Filters (essentially NAT Editors) to support complex protocols, and there are also a number of security related application Filters that improve the security of the reverse NAT. In contrast to Web Publishing Rules, which can be extraordinarily complex, Server Publishing Rules are typically very simple. Because of their simplicity, some TMG administrators prefer to use Server Publishing Rules over Web Publishing Rules, even though a Web Publishing Rule might be the better decision from a security point of view. For example, publishing Exchange 2010 can be very complex, and while there is a wizard that does part of the work for you, it ignores the auto discovery feature that is so useful. Thus many people will do an SSL Server Publishing Rule to publish Exchange instead of going through the major hassle of trying to Web Publish Exchange. In fact, because that scenario is so common, in todays example well create an SSL Server Publishing Rule to show you exactly how its done. To begin creating a Server Publishing Rule, click on the Firewall Policy node in the left pane of the console, and then click the Tasks Tab in the Task Pane. On the Task Pane, click the Publish Non-Web Server Protocols link, as shown in Figure 1.
Figure 1 This brings up the Welcome to the New Server Publishing Rule Wizard page, shown in Figure 2. In the Server publishing rule name text box, enter a number for the Server Publishing Rule. In this example, well name the rule Complex SSL Site (well pretend, for purposes of this example, that this is an Exchange CAS server that were publishing). Click Next.
Figure 2 On the Select Server page, shown in Figure 3, enter the IP address of the server on the internal network that you want to publish. If you dont know the IP address, you can click the Browse button.
Figure 3 When you click the Browse button, it will bring up the Find Internal IP Address dialog box thats shown in Figure 4. Enter the name of the server you want to publish in the Server name text box and click Browse. When the system finds the server, it will list the IP address in the IP addresses list. Click OK after finding the IP address.
Figure 4 After you see the IP address on the Select Server page, shown in Figure 5, click Next.
Figure 5 On the Select Protocol page, as seen in Figure 6, select the protocol you want to allow to be used by the published server. In this example, we want to allow SSL to the published server, so we select the HTTPS Server protocol from the drop down list. Note that when publishing sites using Server Publishing Rules, you use Server protocols, such as the HTTPS Server protocol we used in this rule. Click the Properties button.
Figure 6 This brings up the Properties dialog box thats shown in Figure 7. Click the Parameters tab. Here you can see the port or port ranges that are used by the protocol. When you use the built in protocols, you typically wont want to change the ports. Here you get information about the primary and secondary connections that are supported by the protocol. You also get information about any Application Filters that are bound to the protocol. In this example, you can see that this server has Bandwidth Splitter installed on it, and the Bandwidth Splitter Application Filter appears in the Application Filters list. Click Cancel to dismiss this dialog box.
Figure 7 Click the Ports button. In the Ports dialog box shown in Figure 8, you can exercise more fine- tuned control over the ports used by the Server Publishing Rule. In the Firewall Ports section, you can use the default port for the protocol, or you can change the port. For example, the default port used by the HTTPS Server protocol is TCP 443. However, if you wanted to use an alternate port, you could select the Publish on this port instead of the default port option and name an alternate port. As long as no other rule or application is listening on that port and IP address, itll work fine. You can also do port redirection if you like. In the Published Server Ports section, you see that the default setting is to Send requests to the default port on the published server. In this example, the HTTPS Server protocol uses the default port of TCP 443 so it would forward the connection to that port on the published server. However, if you wanted to use another port on the published server to accept SSL connections, you can change it to something else, and then select the Send requests to this port on the published server option and enter the alternate port. This is pretty user friendly stuff. You can also control which source ports are used by the user who wants to connect to the published server. In the Source Ports section, the default setting is Allow traffic from any allowed source port. Since most applications are going to use a dynamically assigned source port, this is generally the best way to go. However, if you want to improve the security for some applications (such as RDP publishing), you could select the Limit access to traffic from this range of source ports and then enter a limited range, and force the RDP client application to use the ports you designate here.
Figure 8 Click Next after selecting the protocol that you want to publish on the Select Protocol page, shown in Figure 9.
Figure 9 Before we move to the next page of the wizard, lets take a look at the Server Protocols that are available to you out of the box. Remember, when you create Server Publishing Rules, you need to use a Server protocol. When you click on the Firewall Policy node in the left pane of the console and click the Toolbox tab (you cant do it right now because youre in the middle of the wizard) and then click the Server Protocols node, shown in Figure 10, youll see a list of Server Protocols that you can use in Server Publishing Rules. This is a pretty comprehensive list! Of course, if the protocol you want to use isnt in this list, you can always create your own Server Protocol by clicking on the New menu.
Figure 10 Now lets get back to the wizard. On the Network Listener IP Addresses page thats shown in Figure 11, select the Network or Networks on which you want to listen for incoming requests. In most instances youll want to accept incoming connections from the default External Network, so youll put a checkmark in the External checkbox on this page. However, in most cases you dont want to listen on all the IP addresses on the NIC. If you have more than one IP address bound to the external interface, you should click the Addresses button and select the specific IP address to which you want users to make the connection. If you have a NAT device in front of the TMG firewall, then you should select the IP address to which the NAT device is forwarding the connections when external users are trying to connect to the published server.
Figure 11 Review your settings on the Completing the New Server Publishing Rule Wizard page, shown in Figure 12, and then click Finish.
Figure 12 After you click Finish, you can see the new Server Publishing Rule in the Firewall Policy list, as seen in Figure 13.
Figure 13 Double click on the Server Publishing Rule you just created. There are a couple of tabs worth taking a look at here, as they expose some options that you didnt have when you went through the wizard. Click on the From tab, shown in Figure 14. Notice on the From tab that This rule applies to traffic from these sources lists Anywhere. In most cases, youll want to leave it this way. But what if you have some addresses or networks that you dont want to have access to the published server through this rule? You can click the Add button in the Exceptions section and enter those addresses. This gives you some measure of access control over which addresses can connect through this Server Publishing Rule.
Figure 14 On the To tab, shown in Figure 15, notice the two options in the Request for the published server section. The default setting is Requests appear to come from the original client. This means that the published server will see the actual IP address from which the connection came over the Internet. If you choose this option, the published server will need a route to the Internet and its default gateway must provide access to such a route. If you dont want to provide the published server a route to the Internet, you can select the Requests appear to come from the Forefront TMG computer. When you select that option, the published server only needs a route that enables it access to the internal IP address of the TMG firewall. However, when you select that option, the source IP address for the incoming connections to the published server will be the IP address on the internal interface of the TMG firewall and that address will appear in the published servers log files.
Figure 15 Once youre done, click Apply at the top of the middle pane of the TMG firewall console and save the changes to firewall policy. After that, connections to the published server will be allowed on the protocol you selected for the rule. Summary In this article, part of our Back to Basics series for new TMG administrators, we went over the topic of Server Publishing Rules. As you saw, Server Publishing Rules are very simple to put together and allow you to enable reverse NAT to published servers on your intranet. There are a number of Server protocols that you can use to create Server Publishing Rules right out of the box, or you can create your own Server Protocols. Some of the Server Protocols have Application Filters that make the protocol more secure, or that perform some level of protocol validation. You also saw that you could customize the protocol and redirection behavior when configuring the Server Publishing Rule. Have fun with Server Publishing Rules and let me know if you run into any problem with them! MG back to Basics - Part 3: Protocol Definitions by Deb Shinder [Published on 4 Jan. 2011 / Last Updated on 20 May 2013] 1 This article reviews TMGs Protocol Definitions. All firewall rules require a Protocol Definition as part of the rule configuration. If you would like to read the other parts in this article series please go to: TMG Back to Basics - Part 1: Server Publishing Rules TMG Back to Basics - Part 2: Using the TMG Firewall Log Viewer TMG Back to Basics - Part 4: Network Objects TMG Back to Basics - Part 5: Network Objects (Cont.) TMG Back to Basics - Part 6: Reports TMG Back to Basics - Part 7: SharePoint Server Publishing TMG Back to Basics - Part 8: SafeSearch, URL Filtering and Certificate Revocation Options This week we continue our TMG Back to Basics series with a simple, but very important basic TMG concept that you might not even be aware of: Protocol Definitions. The reason why you might not be aware of Protocol Definitions is that Microsoft has done a great job of including a number of Protocol Definitions in TMG right out of the box so that you dont even need to know about them. But there are times when it is useful to be aware of this feature. Protocol Definitions are a key feature of every firewall rule you create on the TMG firewall. The Protocol Definition defines the protocol thats used to allow inbound or outbound access to or through the TMG firewall. For example, if you create a rule that allows outbound access to the HTTP and HTTPS protocols, that rule will include the Protocol Definitions for the HTTP and HTTPS protocols. A Protocol Definition is required for all firewall rules, which includes Access Rules and Web Publishing Rules and Server Publishing Rules. Lets delve a little deeper into this. To view information about your Protocol Definitions, click the Firewall Policy node in the left pane of the TMG firewall console. Click the Toolbox tab in the Tasks Tab, then click the Protocols entry on the Toolbox tab. There you will see a number of groups of Protocol Definitions, as shown in the figure below.
Figure 1 Click on the Common Protocols group. Here, as shown in Figure 2, you will see a list of Protocol Definitions for the protocols that are most commonly used when configuring firewall rules on the TMG firewall.
Figure 2 Scroll down the list of Protocol Groups. Click on the All Protocols group, as shown in Figure 3. Here you will see a list of all the Protocol Definitions that are included in the TMG firewall right out of the box. There are well over a hundred Protocol Definitions included and that selection should support just about any protocol to which you would want to allow inbound or outbound to or through the TMG firewall in typical scenarios. But there are special circumstances when youll need to create your own definitions. Scroll through the list of Protocol Definitions to get an idea of whats available. Being aware of whats available out of the box can save you time when you are considering creating your own custom Protocol Definition. After all, why go to the trouble of creating a new Protocol Definition if theres already one there that will serve your purpose?
Figure 3 Now lets look at a specific definition. Double click the HTTPS Protocol Definition. This brings up the HTTPS Properties dialog box thats shown in Figure 4. On the General tab, youll see the name of the Protocol Definition and a short description of the protocol. Youll also see the Associated Standard Protocol section, but it will be grayed out in most cases; well talk about this feature later.
Figure 4 Now click on the Parameters tab. On the Parameters tab, shown in Figure 5, you can see the Primary Connections, the Secondary Connections and the Application Filters sections. Well talk about these sections in more detail later, too but you can see here which protocols, ports and direction is associated with the protocol.
Figure 5 Speaking of directions for Protocol Definitions, check out Figure 6 below. Notice that there is an SMTP Protocol Definition and a SMTP Server Protocol Definition. You might be wondering: What is the difference?
Figure 6 Its all about direction. If you look at the Parameters of the SMTP Protocol Definition, shown in Figure 7, youll see that the Direction is Outbound. When you create Access Rules, you will always use a Protocol Definition that supports outbound protocols.
Figure 7 Now if you look at the SMTP Server Parameters, shown in Figure 8, youll see that the direction there is Inbound. When you create Server Publishing Rules, you will always use a Protocol Definition that has the Inbound direction. In addition, notice that there is an Application Filter associated with the SMTP Server Protocol Definition. In this case, the SMTP Filter is associated with the SMTP Server Protocol Definition. This means that some level of application layer inspection will be applied to connections that match firewall rules that use the SMTP Server Protocol Definition.
Figure 8 How to Create New Protocol Definitions Now that youve seen some examples of existing Protocol Definitions, lets find out how you can create your own custom Protocol Definitions. Why would you ever want to do this? Well, you might need to create a custom definition if you have a new application that requires a protocol that isnt included with the out of the box Protocol Definitions. Luckily, its pretty simple. You start creating a new Protocol Definition by clicking the Toolbox tab in the Task Pane and then clicking the Protocols section. Then click the New menu and click Protocol, as shown in Figure 9 (the RPC Protocol is an advanced option that we wont cover in this article).
Figure 9 This will bring up the Welcome to the New Protocol Definition Wizard page thats shown in Figure 10. Enter a name for the new Protocol Definition in the Protocol Definition name text box. In this example, well name the Protocol Definition Disambigulator Protocol and then click Next.
Figure 10 On the Primary Connection Information page, as seen in Figure 11, you enter the protocol and the port or ports required for the primary connection. The primary connection is the first connection(s) made by the system initiating the connection to another host. Click the New button.
Figure 11 This brings up the New/Edit Protocol Connection dialog box that you can see in Figure 12. Here you must select the following: Protocol type. You select from a list that includes TCP, UDP, ICMP and IP-Level. If you select IP- Level you will need to enter the IP Protocol Number in the Protocol Number text box. If you select the ICMP option, you will need to enter an ICMP Code and an ICMP Type. For TCP and UDP protocols, you will need to enter a port or port range. For all protocols, you will need to enter a direction. Direction. Here you enter the direction. For all protocols except UDP, you need to select either inbound or outbound. For UDP, you have more choices, as youll see in the next step. Port Range. If you select TCP or UDP, you need to enter a port range here. If there is only a single port, then enter the same port number in the From and To boxes. ICMP Properties. If you are creating a new ICMP protocol, then you will need to enter an ICMP type and code in the text boxes.
Figure 12 If you select a UDP protocol, then your choices for selecting a direction are different. As you can see in Figure 13, our choices are Receive, Receive Send, Send and Send Receive. It can be hard to know in advance which direction will work. In general, I will start with Receive or Send (depending on the direction receive is equivalent to inbound and send is similar to outbound). If that doesnt work, Ill use Receive Send or Send Receive. Its tricky in some cases, and you might need to experiment with the direction for UDP protocols.
Figure 13 In this example, our protocol is a UDP protocol and its used for outbound connections so we will select UDP and Send, as shown in Figure 14. This protocol uses a single port, which is 9966, so we enter that number in the From and To boxes in the Port Range section and then click OK.
Figure 14 The Secondary Connections page, which you can see in Figure 14, is used for what we call complex protocols. A complex protocol is one that requires new connections after the initial connection. For example, the client might require a secondary inbound connection from the server after it establishes its connection to the server using the primary connection protocol/port. If thats the case, you will need to configure a secondary connection. Its important to note that if you have a protocol that requires a secondary connection, the client type youre using is going to matter. SecureNAT clients require an Application Filter to support complex protocols. However, if youve deployed the Firewall Client (TMG client), then you dont need an application filter. Application Filters are complex to develop, so its highly recommended that you deploy the TMG client if you need support for secondary connections.
Figure 15 Okay, were at the end of the wizard. Lets review the settings on the Complete the New Protocol Definition Wizard page thats shown in Figure 16 and click Finish.
Figure 16 Youre finished with the wizard, but youre not done yet. Go back to the Toolbox tab and click the User-Defined group. Here you see a list of Protocol Definitions that you created. Double click on the Protocol Definition you just created, as shown in Figure 17.
Figure 17 Notice on the General tab, shown in Figure 18, that you have the option to Associate this protocol definition with this standard protocol. You would choose this option if you wanted the TMG NIS to inspect this connection with signatures written for the protocol you select here. In general, you wouldnt want to do this, but there might be situations where youd want to take advantage of this option. One example might be when you want to support an alternate port for HTTP or HTTPS connections that are being established outside of the web proxy filter.
Figure 18 On the Parameters tab thats shown in Figure 19, you can also associate an Application Filter with the protocol. You need to be careful about doing this, though, since the filters are designed for specific protocols and wont work if you assign them to Protocol Definition that doesnt match the requirements of the filters. In general, you would not assign an application filter to a custom Protocol Definition.
Figure 19 Summary In this article, we covered Protocol Definitions. All firewall rules require a Protocol Definition as part of the rule configuration. Protocol Definitions are generally designed to be either inbound or outbound. Outbound Protocol Definitions are used for Access Rules and inbound Protocol Definitions are used for Web and Server Publishing Rules. There are also complex Protocol Definitions, where more than one connection is required to support the application. When using complex protocols remember that SecureNAT clients require an application filter to support the complex protocol, whereas Firewall clients do not require an application filter. You likely wont often need to create new Protocol Definitions, but there might be times when you need to create a custom Protocol Definition to support a new application or product. Let me know if you have questions about Protocol Definitions and Ill get back to you as soon as possible. Thanks! Deb. MG Back to Basics - Part 4: Network Objects by Deb Shinder [Published on 1 Feb. 2011 / Last Updated on 20 May 2013] In this article, well take a high level view of the Network Objects available with the TMG firewall and also discuss how you might use them in common scenarios. If you would like to read the other parts in this article series please go to: TMG Back to Basics - Part 1: Server Publishing Rules TMG Back to Basics - Part 2: Using the TMG Firewall Log Viewer TMG back to Basics - Part 3: Protocol Definitions TMG Back to Basics - Part 5: Network Objects (Cont.) TMG Back to Basics - Part 6: Reports TMG Back to Basics - Part 7: SharePoint Server Publishing TMG Back to Basics - Part 8: SafeSearch, URL Filtering and Certificate Revocation Options Introduction Continuing our TMG Back to Basics series, this time were going to take a close look at Network Objects. This is one TMG concept that doesnt get much attention. Although Network Objects arent particularly exciting, they are critical to configuring all firewall rules on the TMG firewall. If you dont have a Network Object to support the source or destination in a firewall rule, then you wont be able to create the rule that you intend to create. Network Objects allow you to configure source and destination settings for all firewall rules, including publishing rules, on the TMG firewall. Network Objects are reusable software pieces settings that allow you to define source and destination in a variety of ways. Those of you who have been working with Microsoft firewall products for a while may remember that Network Objects were first introduced with ISA Server 2004. The TMG firewall builds on the Network Objects used in previous versions of the ISA firewall and significantly improves on them. Working with Network Objects To find the Network Objects, click the Firewall Policy node in the left pane of the TMG firewall console, and then click the Toolbox tab in the Task Pane. Click the Network Objects section header. Here you will see a list of the types of Network Objects available to you, as shown in Figure 1. Each folder actually contains a number of Network Objects you can use to construct TMG firewall rules.
Figure 1 Click the Networks folder. Here youll see a list of TMG Firewall Networks that are configured on this machine, as shown in Figure 2. Remember that a TMG Firewall Network is required for each NIC on your TMG computer. In addition, there are some default TMG Firewall Networks, such as the VPN Clients network, which is dynamically constructed to include the IP addresses used by remote access VPN client computers. For more information on TMG Firewall Networks, check out my article here.
Figure 2 Now click on the Network Sets folder. This exposes the Network Sets that are currently configured on this computer, as shown in Figure 3. A Network Set is a collection of Networks that you can use when setting a source or destination on an Access Rule or Publishing Rule. The default Network Sets include: All Networks (and Local Host). This Network Set includes all IPv4 addresses. While this Network Set can be useful for some troubleshooting scenarios, its a fairly dangerous Network Set to use because if you create a rule that uses this Network Set as a destination, it includes the Local Host Network, which is the TMG firewall itself and this could potentially open the firewall up to unintended compromise. All Protected Networks. This Network Set includes all TMG Firewall Networks except for the default External Network. Essentially, this Network Set is defined by all TMG Firewall Network that are behind the TMG firewall. Forefront Protection Manager. This is not used, as Forefront Protection Manager was cancelled.
Figure 3 If you double click on All Protected Networks you will see the Properties dialog box for that Network Set. Click the Networks tab, shown in Figure 4. Note that all Networks that do not have a checkmark in the checkbox are included in the Network Set. This can be a little confusing at first glance since the logical assumption would be that checked items are included.
Figure 4 Click the Computers folder. Here you see the Computer objects configured on the TMG firewall, as shown in Figure 5. There are no default Computer objects. All computer objects are custom objects and you need to create them yourself.
Figure 5 If you double click on one of the Computer objects, youll see that it consists of a name and an IPv4 address, as shown in Figure 6.
Figure 6 Click on the Computer Sets folder. Here you see the Computer Sets that are currently configured on the TMG firewall. There are a number of default Computer Sets, and the default Computer Sets will vary based on which edition of the TMG firewall youre using. In other words, the Standard Edition of the TMG firewall will have different default Computer Sets than the Enterprise Edition of the TMG firewall. In Figure 7 below, youll notice that there are a number of Forefront Protection Manager Computer Sets. These are not used because the Forefront Protection Manager project was cancelled. Some important Computer Sets that you should know about include: Anywhere. This means, literally, anywhere which is the same as all IPv4 IP addresses. Array Servers. This is automatically configured for you to include the IP addresses of all servers that are part of the same array. Enterprise Remote Management. This Computer Set includes the IP addresses of machines that are allowed to remotely manage the array. This is not automatically populated except in the situation where you use an EMS. In all other cases, you will need to enter the addresses yourself. Managed Server Computers. This is a predefined list of computers that are allowed to connect to the EMS server. You can double click on the other Computer Sets to see their intended purposes.
Figure 7 When you double click on one of the Computer Sets, you can see the details of the set, as shown in Figure 8. A Computer Set can contain multiple entries, and each entry can be an IPv4 address, a range of IPv4 addresses or even a subnet.
Figure 8 Click the Address Ranges folder. In the TMG firewall, there is a single default Address Range, which is Anywhere (IPv6), as shown in Figure 9. Since TMG has very limited support for IPv6, this Address Range is mostly often used to support DirectAccess on UAG DirectAccess servers.
Figure 9 When you double click on the Address Range, you can see that it includes the name of the Address Range, the Start Address and the End Address, as shown in Figure 10.
Figure 10 Click the URL Sets folder next. There is a single default URL Set, shown in Figure 11, which is not used as it was intended to be used to support Forefront Protection Manager scenarios because yep, you remembered FPM was cancelled. All URL Sets now are custom URL Sets that you need to create yourself. URL Sets are used in rules that use the HTTP or HTTPS protocols and are applied only to Web proxy clients. If you want to set a source or destination in a firewall rule that will not have Web proxy clients, then you should use Domain Name Sets instead of URL Sets. In the past, URL Sets were useful for URL Filtering but with the new TMG Firewall URL Filtering feature, URL Sets are typically used for highly customized access control settings on firewall rules.
Figure 11 Now click the URL Categories folder. Here, as shown in Figure 12, you see a large number of URL Categories that are used by the URL Filtering feature included with the TMG firewall. These URL Categories are dynamically updated by the Microsoft Reputation Services servers on the Internet and are not populated on the TMG firewall so you will not see the URLs in a particular set when you look at the Properties dialog box of specific URL Category.
Figure 12 Click the URL Category Sets folder. Here you see a list of the default URL Category Sets, shown in Figure 13. Each Category Set is a collection of other URL Categories. URL Category Sets are intended to simplify the task of URL filtering for you, so that you dont have to pick and choose multiple URL Categories yourself to get your desired result for web filtering.
Figure 13 Double click on one of the URL Categories and click the URL Categories tab in the Properties dialog box. Here, as shown in Figure 14, you will see a list of all the URL Categories. The URL Categories that belong to the set will have a checkmark in the checkbox next to the category.
Figure 14 Click the Domain Name Sets folder. Here you see a list of Domain Name Sets configured on this computer, as shown in Figure 15. Domain Name Sets include domain names, which can also include a wildcard on the high-order label in a domain name. Domain Name Sets are used by all TMG client types: SecureNAT, web proxy and Firewall client (TMG client). There are also a number of built-in domain name sets, which vary depending on whether youre using the Standard or Enterprise Edition of the TMG firewall. Some of the Domain Name Sets are pre- populated for you, such as the Sites Example from HTTPS Inspection.
Figure 15 You can see the details of a Domain Name Set when you double click on it, as shown in Figure 16. You can add more domain names to the list by clicking the Add button.
Figure 16 Click on the Web Listeners folder, as you can see in Figure 17. Note that there are no default Web Listeners all Web Listeners are custom and you need to create the ones you need.
Figure 17
25. You are now done, here is an example SQL Query you can run to display ICMPs only. MG Back to Basics - Part 5: Network Objects (Cont.) by Deb Shinder [Published on 15 Feb. 2011 / Last Updated on 20 May 2013] In this article we'll take a look at how you can create the more complex types of Network Objects. If you would like to read the other parts in this article series please go to: TMG Back to Basics - Part 1: Server Publishing Rules TMG Back to Basics - Part 2: Using the TMG Firewall Log Viewer TMG back to Basics - Part 3: Protocol Definitions TMG Back to Basics - Part 4: Network Objects TMG Back to Basics - Part 6: Reports TMG Back to Basics - Part 7: SharePoint Server Publishing TMG Back to Basics - Part 8: SafeSearch, URL Filtering and Certificate Revocation Options Intorduction In the first part of this two part series on TMG Firewall Network Objects, we went over the different Network Objects and what they represent. We also saw how you can create simple new Network Objects. Dont let that word scare you. Heres the good news: Each of the complex Network Objects can be created by using a wizard. Wizards are available to create the following types of Network Objects: Network Network Sets URL Category Sets Web Listener Server Farm Lets take a look at the information that youll need to know in order to create each of these. The New Network Wizard You can begin the process of creating a new Network by clicking on the Network entry in the New menu. Remember that in TMG Firewall nomenclature, a Network represents a collection of IP addresses that are directly reachable from a particular interface on the TMG firewall. The first thing youll see is the Welcome to the New Network Wizard page. On this page, you enter a name for the Network in the Network name text box. In this example, well name the Network DMZ 2, as shown in Figure 1.
Figure 1 On the Network Type page, which you can see in Figure 2, you are given several different Network types to choose from: Internal Network. This is typically a Network that contains servers or clients that you want to be protected by the TMG firewall. When you create an Internal Network, the Properties dialog box of the Network will have all the options you see in the default Internal Network. Perimeter Network. A Perimeter Network is similar to an Internal Network. In fact, there is no practical difference between a Perimeter Network and an Internal Network both provide the same options in their Properties dialog boxes. However, for accounting purposes, you will want to choose the Perimeter Network option to make it clear that this is a DMZ network, and not an Internal Network. The key difference here is that DMZ Networks typically will include Internet facing devices. VPN Site-To-Site Network. This is a special Network type that is used when you want to create a site to site VPN connection between your TMG firewall and another firewall. Note that while you can create the remote site Network from this wizard, you would more typically do it from within the wizard that is used to create the site to site VPN. External Network. An External Network is considered an unprotected Network and represents a collection of IP addresses that reside outside of any of the TMG Firewall Protected Networks. You would create an External Network if you want to add additional external interfaces on the TMG firewall and then create routing table entries for specific destinations that can be reached through the NIC that form the root of the External Network you created. In this example, well select the Perimeter Network option.
Figure 2 On the Network Addresses page, which is shown in Figure 3, you configure the addresses that define the Network. You can add the addresses in three different ways: by adding an adapter, by adding a private address range, or by adding a custom address range. Weve found that in most cases, the best way to create a new Network is to base it on a specific NIC. In this example, well click the Add Adapter button. That brings up the Select Network Adapters dialog box. In this dialog box, you need to put a checkmark in the checkbox next to the NIC that is the root of your new Network.
Figure 3 Once youve done all this, you can then review the settings of the new TMG Firewall Network on the Completing the New Network Wizard page, which you see in Figure 4. (Note that the IP addresses are different because I already used the Guest Network for another TMG Firewall Network).
Figure 4 You can then go to the Networking node in the left pane of the console and double click the new Network. There youll see the Properties dialog box thats shown in Figure 5. Notice that this Perimeter Networks Properties dialog box is the same as what you would find if you had created an Internal Network.
TMG Back to Basics - Part 6: Reports by Deb Shinder [Published on 1 March 2011 / Last Updated on 20 May 2013] 3 TMG Back to Basics is a set of articles designed with the new TMG administrator in mind. We continue our Back to Basic series today with a discussion of the TMG Reporting feature. If you would like to read the other parts in this article series please go to: TMG Back to Basics - Part 1: Server Publishing Rules TMG Back to Basics - Part 2: Using the TMG Firewall Log Viewer TMG back to Basics - Part 3: Protocol Definitions TMG Back to Basics - Part 4: Network Objects TMG Back to Basics - Part 5: Network Objects (Cont.) TMG Back to Basics - Part 7: SharePoint Server Publishing TMG Back to Basics - Part 8: SafeSearch, URL Filtering and Certificate Revocation Options Introduction The TMG reporting feature is one of the more interesting and impressive features included with the TMG firewall, with which you can create interesting and informative reports without the need to learn any query language. While the TMG reports are somewhat limited in their configurability, youll find that these reports are likely to contain the information you need to make key decisions regarding TMG firewall policies and your users. Lets get started with reports. In the left pane of the TMG firewall console, click the Logs & Reports node and then click the Reports tab. After you click the Reports tab, click the Tasks Tab in the Task Pane. Here youll see the Tasks list that appears in Figure 1 below. Lets start by examining what you can do after clicking the Configure Reporting Settings link.
Figure 1 In the Reporting Properties dialog box, the first tab is the Log Summary tab. All reports are based on the information contained in Log Summaries. The default setting is to Enable daily and monthly summaries option. Make sure this option is enabled if you want to generate daily and monthly summaries. Weekly reports are based on the daily summaries. The Generation time is the time during which the summary is created. Because the creation process is processor intensive, its a good idea to set this so the summaries will be generated late at night (assuming thats when the load on your server is lightest). In keeping with this, the default setting is 12:30 A.M. You can also configure the Number of saved daily summaries and Number of saved monthly summaries here, as shown in Figure 2. The number of summaries saved will determine how far into the future you can create various types of reports.
Figure 2 On the Report Server tab, which is shown below in Figure 3, you can configure which of the firewalls in a TMG firewall array is to be responsible for creating the reports. Only one machine in the array will create the report, so you should choose the machine that has the most CPU horsepower, since report generation is processor intensive.
Figure 3 Creating a Recurring Report Now lets take a look at how you go about creating a report. On the Tasks Tab in the Task Pane, click the Create a Recurring Report link. This brings up the Welcome to the Recurring Report Job Wizard page thats shown in Figure 4. In the Report Job name text box on this page, enter a name for the report. Since well be creating a weekly report here, well get really creative and name the report Weekly Report. Click Next.
Figure 4 On the Recurring Report Job Scheduling page thats shown in Figure 5, you specify how often and on what day of the week or month the report job is to run. You have three options: Daily Weekly, on this day every week Monthly, on this day every month Notice that the weekly and monthly options give you a choice of the day or date for report generation. In this example, were creating a weekly report, so well select that option and then choose Monday as the day to generate the report each week. Click Next.
Figure 5 On the Report Content page thats shown in Figure 6, you select which types of content you want to appear in the report. By default, all of the listed categories of content are included. These include the summary, web usage, application usage, traffic and utilization, security, malware protection, URL filtering and Network Inspection System (NIS). For each of the content categories, you can edit the details that will be included in that category by clicking the Edit Report Details button.
Figure 6 When you click on the Edit Report Details button, youll see the Report Details dialog box for that section, as shown in Figure 7. In the Subcategory section, you can click the down arrow to configure a subsection. Then in the Report details for this subcategory section, you can configure the Parameter Value.
Figure 7 Figure 8 below shows the configuration option for another subcategory.
Figure 8 Next, on the Send E-mail Notification page thats shown in Figure 9, you enter the details required for the system to notify you by email that a report is available. These details include: SMTP server the name or address of an SMTP server that can send email to the people to whom you want notifications sent. Make sure there is a firewall rule on the TMG firewall that allows outbound SMTP to the location of the SMTP server. From the email address you want to assign to the TMG firewall. To the email address(es) to which you want the notification to be sent. Cc the email address(es) of anyone you want cc:d on the notification. Message a message to be included in the email notification. An example of how you would configure this is in the figure.
Figure 9 On the Report Publishing page, shown in Figure 10, put a checkmark in the Publish reports to a directory checkbox. In the Published reports directory text box, enter the local or remote location where you want to store the reports. If you store the reports on a file server, then click the Set Account button to enter the user name and password of the user account who has permissions to post to the file servers directory where the reports are stored. Note that you dont have to do this if you are storing the reports on the TMG firewall, but if you want to see the reports that are stored on the TMG firewall, you will need to access them at the firewall itself and not through an SMB connection to the firewall from some other computer on the network.
Figure 10 Review the settings on the Completing the Recurring Report Job Wizard page, as shown in Figure 11, and click Finish.
Figure 11 Click the Apply button, shown in Figure 12, to save the changes.
Figure 12 User Activity Reports Now lets see how to create a User Activity Report. This is a new feature included with the TMG firewall that wasnt available with the ISA firewall. Click the Generate User Activity Report link in the Tasks Tab in the Task Pane. This brings up the Welcome to the User Activity Report Job Wizard, which is shown in Figure 13. In the Report Name test box, enter a name for the report. In this example, well name the report Tom Shinders laptop, so we can keep tabs on what Toms been up to. :)
Figure 13 On the Report Content page thats shown in Figure 14, youll see that the only option is User Activity. Click Editor Report Details.
Figure 14 In the Report Details dialog box, which is shown in Figure 15, the only subcategory thats listed is Web Sites, so you wont be able to see any information about any other types of servers the user accessed. In the Report details for this subcategory section, you can edit the Parameter Value for the Report Period and Users. For users, you can use user names or IP addresses. User names only appear if you configured the client systems as Firewall or Web Proxy clients.
Figure 15 On the Send E-mail Notification page, which is shown in Figure 16, you enter the mail details in the same way as described earlier.
Figure 16 On the Report Publishing page, which is shown in Figure 17, you once again enter the details in the same way as described earlier.
Figure 17 Now review the settings on the Completing the User Activity Report Job Wizard page, shown in Figure 18, and click Finish.
Figure 18 Remember to click the Apply button, shown again in Figure 19, to save the changes to the firewall configuration.
Figure 19 Now right click the report name and click Generate and View Report, as shown in Figure 20. It will probably take a minute or so for the report to generate.
Figure 20 You can watch the gears turn, as seen in Figure 21, while youre waiting!
Figure 21 After the report has been generated, it will be displayed automatically. Figure 22 below shows the results of this report. Not very interesting, is it? It seems that Toms activities are all business.
Figure 22 Viewing Reports You can view reports after theyre created, by right clicking on the name of the report you want to see and then clicking View Published Reports, as shown in Figure 23.
Figure 23 This will open the folder where you are saving the reports, as you can see in Figure 24. Double click on the folder that contains the report you want to see.
Figure 24 In this example, find the file named Report in the folder that contains the report in which youre interested and double click on it, as shown in Figure 25.
Figure 25 The report opens and shows a number of sections, as you can see in Figure 26.The figure shows the sections that are contained in the default report.
Figure 26 Figure 27 shows an example of one of the sections; in this case, its the Top Applications section, which shows which are the top used applications for connecting to the Internet. Note that the Firewall Client must be installed on the client computers in order to get this information about which applications are being used.
Figure 27 Figure 28 below shows an example of another section, which in this case is the Top URL Categories section.
Figure 28 Summary In this Basics article for new TMG admins, we provided you with a high level overview of how to create reports on the TMG firewall. This included how to configure report settings, including log summaries, and how to create recurring and user reports. Then we finished up by looking at the categories of information contained in the default report and saw some examples of the details of report categories. TMG Back to Basics - Part 7: SharePoint Server Publishing by Deb Shinder [Published on 10 May 2011 / Last Updated on 20 May 2013] 1 We continue our "back to basics" series for the TMG firewall this week with some coverage of basic SharePoint Server publishing. If you would like to read the other parts in this article series please go to: TMG Back to Basics - Part 1: Server Publishing Rules TMG Back to Basics - Part 2: Using the TMG Firewall Log Viewer TMG back to Basics - Part 3: Protocol Definitions TMG Back to Basics - Part 4: Network Objects TMG Back to Basics - Part 5: Network Objects (Cont.) TMG Back to Basics - Part 6: Reports TMG Back to Basics - Part 8: SafeSearch, URL Filtering and Certificate Revocation Options Introduction If youre new to the TMG firewall, you might not be familiar with the term publishing in this context. When working with the TMG firewall, the term publishing is used to refer to the use of either reverse web proxy or reverse NAT. When publishing SharePoint, youll be configuring the TMG firewall to perform the reverse web proxy function. The TMG firewall includes a wizard that makes publishing SharePoint sites very easy. The TMG firewall can publish one SharePoint server or multiple SharePoint servers, or even SharePoint web farms, with or without a load balancer. The TMG firewalls SharePoint Publishing Wizard does a lot of configuration in the background that you dont see in the wizard interface, which ensures that when you publish your SharePoint server, everything is set up automatically to make sure that the users can access all components of your SharePoint solution. Since this is part of our Back to Basics series, in this article on publishing SharePoint servers well focus on a very simple scenario: a public access SharePoint server that doesnt require users to authenticate and that hosts information that is available to everyone. In this simple scenario, no authentication is required and no encryption is required. More complex scenarios can involve a variety of authentication and encryption options and well address those in other future articles. But for a back to basics article, well stick with the basics. Setting up your SharePoint server is way beyond the basics of this article, but if you need help with that, check out the comprehensive guidance on the Microsoft TechNet site. After your SharePoint site is set up, you can then open the TMG firewall console and click on the Firewall Policy node in the left pane of the TMG firewall console. In the Tasks Tab of the Task Pane, click the Publish SharePoint Sites link. This brings up the Welcome to the SharePoint Publishing Rule Wizard page. Enter a name for the rule in the SharePoint publishing rule name text box. In this example, shown in Figure 1, well name the rule TACTEAM SharePoint. Click Next.
Figure 1 On the Publishing Type page, you have three options: Publish a single web site or load balancer. Use this option if you want to publish a single SharePoint server or publish multiple SharePoint servers that are located behind a load balancer. Publish a server farm of load balanced web servers. Use this option when you want to publish a farm of SharePoint servers and take advantage of the built in web farm publishing feature included with the TMG firewall. Publish multiple web sites. Use this option if you want to publish multiple SharePoint sites or multiple sites located behind multiple load balancers In this example, we want to publish a single SharePoint server, so well select the Publish a single web site or load balancer option, as shown in Figure 2. Click Next.
Figure 2 On the Server Connection Security page, shown in Figure 3, you have two options: Use SSL to connect to the published web server or server farm. Use this option if you want to create a connection between the internal interface of the TMG firewall and the SharePoint server that uses SSL encryption to secure the connection. Use non-secured connections to connect the published web server or server farm. Use this option if you want the connection between the internal interface of the TMG firewall and the SharePoint server to be unencrypted. For this example, well use the Use non-secured connections to connect to the published web server or server farm option and click Next, but note that the SSL option is more secure.
Figure 3 On the Internal Publishing Details page, which is shown in Figure 4, enter the internal name of the SharePoint site in the Internal site name text box. This is the name that internal clients use to connect to the SharePoint server on the internal network. In this example, well use the name sps.tacteam.net and click Next.
Figure 4 On the Public Name Details page, shown in Figure 5, always select the This domain name (type below) option from the Accept requests for drop down list. In the Public name text box, enter the name that external users will use to access the SharePoint site. In this example, well use the name spspublic.tacteam.net and click Next. Notice in the example that I dont use a strict split DNS infrastructure for publishing the SharePoint site. If youve been a fan of ISAserver.org for a while, you might know that Tom is a big fan of the Split DNS infrastructure. However, Tom will also tell you that a strict split DNS infrastructure can cause some problems with DirectAccess and Ive seen that myself in my own DirectAccess deployment. Therefore, well be using different host names to connect to the SharePoint site, based on whether the user is located on the external or internal network.
Figure 5 A Web Listener is required to accept incoming connections for published servers. You can create HTTP and HTTPS Web Listeners. In this example, we need to create an HTTP Web Listener. On the Select Web Listener page, shown in Figure 6, click the New button.
Figure 6 On the Welcome to the New Web Listener Wizard page, which is shown in Figure 7, enter a name for the Web Listener in the Web Listenername text box. In this example, well name the Web Listener HTTP Listener, since it will be accepting only HTTP connections for the published SharePoint site. Click Next.
Figure 7 On the Client Connection Security page, shown in Figure 8, you have two options: Require SSL secured connection with clients. Use this option when you want to force external clients to use SSL to connect to the external interface of the TMG firewall to reach the SharePoint site, for better security. Do not require SSL secured connections with clients. Use this option to allow unencrypted connections to the TMG firewalls external interface to reach the SharePoint site behind the TMG firewall. In todays example, since were keeping everything basic, well select the Do not require SSL secured connections with clients and click Next.
Figure 8 On the Web Listener Addresses page, shown in Figure 9, you specify which IP addresses are used to accept connections for this Web Listener. In this example, well select External and then click Select IP Addresses. Then well select the specific IP addresses for which we want this Web Listener to accept connections.
Figure 9 You can see the IP address that was selected for this Web Listener in Figure 10 below. Notice that you can configure the Web Listener to listen for incoming connections on other Networks, including internal Networks. This would allow you to publish your SharePoint server to internal clients too. This is very useful in many scenarios when you want to take advantage of the TMG security benefits for access not only for external clients, but internal clients as well.
Figure 10 On the Authentication Settings page, shown in Figure 11, you can set the type of authentication you want to require to access the published SharePoint site. In this example, were not requiring any type of authentication, so well select the No Authentication option. Click Next.
Figure 11 On the Single Sign On Settings page, as shown in Figure 12, you can configure Single Sign On to allow users to authenticate once with the TMG firewall and then access all published web sites that use this web listener. Notice that the option isnt available at this time. The reason for this is that weve configured this Web Listener to not require authentication. Click Next.
Figure 12 Review the settings on the Completing the New Web Listener Wizard page and then click Finish, as shown in Figure 13.
Figure 13 On the Select Web Listener page, shown in Figure 14, click Next.
Figure 14 On the Authentication Delegation page, shown in Figure 15, you can configure the method the TMG firewall uses to authenticate the session it opens with the published sites. When authentication is required by the TMG firewall, you can configure the TMG firewall to delegate credentials so that the user doesnt have to authenticate again with the published SharePoint site; instead, the TMG firewall forwards the credentials it has already received by the user. In this example, the users arent authenticating with the TMG firewall, so well select the No delegation, and client cannot authenticate directly. There is also another option available that enables the user to authenticate directly with the published SharePoint site, but this is a bad idea since the session is not encrypted.
Figure 15 On the Alternate Access Mapping Configuration page, shown in Figure 16, you have two choices: SharePoint AAM is already configured on the SharePoint server. Use this option when you have configured the AAM settings on the SharePoint site. I recommend that you always configure the AAM settings on the SharePoint site in advance of publishing the SharePoint site with the TMG firewall. While you can access some features of the SharePoint site without configuring AAM, not everything will work. For the best experience, always configure AAM and then select this option when you publish the SharePoint site. SharePoint AAM is not yet configured.Also select this option if you are unsure if AAM is configured.I recommend that in general, you should never use this option; configure AAM first on the SharePoint site before publishing the site. In this example well select the SharePoint AMM is already configured on the SharePoint server and click Next.
Figure 16 On the User Sets page, shown in Figure 17, you can specify which users are allowed to connect to the SharePoint site. In this example we will allow anonymous access, which is the same as All Users. Click Next.
Figure 17 Review the settings on the Completing the New SharePoint Publishing Rule Wizard page, shown in Figure 18, and then click Finish.
Figure 18 Summary In this back to basics article, we reviewed the SharePoint publishing wizard and to run the wizard in a very simple SharePoint publishing scenario where anonymous access is allowed and no encryption is required. In a future article, well publish a SharePoint site that requires users to authenticate with the TMG firewall and have the TMG firewall delegate credentials to the published site. Well also discuss issues related to SSL bridging, and things you want to consider regarding SSL bridging. See you then! Deb. MG Back to Basics - Part 8: SafeSearch, URL Filtering and Certificate Revocation Options by Deb Shinder [Published on 14 June 2011 / Last Updated on 20 May 2013] In this article, we will take a quick look at three key features in the TMG firewall - SafeSearch, URL Filtering and Certificate Revocation. If you would like to be notified of when Deb Shinder releases the next part in this article series please sign up to our Real Time Article Update newsletter. If you would like to read the other parts in this article series please go to: TMG Back to Basics - Part 1: Server Publishing Rules TMG Back to Basics - Part 2: Using the TMG Firewall Log Viewer TMG back to Basics - Part 3: Protocol Definitions TMG Back to Basics - Part 4: Network Objects TMG Back to Basics - Part 5: Network Objects (Cont.) TMG Back to Basics - Part 6: Reports TMG Back to Basics - Part 7: SharePoint Server Publishing Introduction This week I thought Id poke around the TMG firewall console to see if there were some interesting options that I hadnt covered in my Back to Basics series. And lo, I did discover some options that I havent addressed, including the Safe Search, URL Filtering and Certificate Revocation options. So in this article, well take a look at these options and what you can do with them. When you open the TMG firewall console and click the Web Access Policy node in the left pane and then click the Tasks Tab in the in tasks pane, youll see the Web Protection Tasks as shown in Figure 1 below. The Web Protection Tasks that were most interested in today are: Configure SafeSearch Configure URL Filtering Configure URL Category Overrides Query for URL Category
Figure 1 SafeSearch First lets click on the SafeSearch link. This brings up the General tab in the SafeSearch dialog box, which is shown in Figure 2. Youll see that its s pretty simple dialog box. You have one option here: Enable SafeSearch. But what does that mean? When you enable SafeSearch, the TMG firewall will enforce strict filtering of adult content from search results delivered by supported search engines. This makes it possible for you to automatically block adult-oriented text, videos and images in the workplace. The supported search engines are those that are included in the Search Engines URL Category.
Figure 2 When SafeSearch is enabled, TMG will step in every time a user does a search on a major search engine, and modify the query string so that filtered results will be returned. The user cant disable this in their browsers, so you maintain control over the web content that users can access, which is increasingly important to avoid lawsuits and liability. When you enable SafeSearch, it creates a firewall rule, as you can see in Figure 3 below. In this example, the firewall rule is disabled because I disabled SafeSearch after initially enabling it. The rule doesnt appear until you enable SafeSearch the first time. If you disable it later, the TMG firewall will not remove the rule; it will just disable it. That makes it easy for you to switch SafeSearch on and off when needed. If you enable SafeSearch again, the rule will change state from disabled to enabled.
Figure 3 But what if there are some users in your organization who need to be exempt from the filtering? Maybe they do research that gives them a legitimate reason to access adult content. Click the Users tab, which is shown in Figure 4. On this tab, you can add users who will be excluded from SafeSearch. When you click the Add button, it will bring up the Users Excluded From SafeSearch dialog box. Note that these are user groups that you configure on the TMG firewall. You can use Active Directory groups to populate these groups, but you do need to create the groups first.
Figure 4 Thats about it for SafeSearch. Its very easy to configure it and works great! Id demo it for you, but all you would see is a search results page that doesnt include any adult links.
URL Filtering Options Next, well look at the URL Filtering options. Click on the Configure URL Filtering link in the right pane of the TMG console. This brings up the General tab that you can see in Figure 5. Once again, there is only one option here: Enable URL Filtering. When URL Filtering is enabled, access rules can be configured to allow or block traffic based on the URL categories you select. Note that when this feature is enabled, information about the URL being reached is sent to the Microsoft Reputation Services for categorization. The TMG firewall doesnt download a database for this, it sends queries to the MRS database to determine to what category each URL belongs. This is done over an SSL connection and Microsoft does not keep a record of the URLs your users are accessing.
Figure 5 URL filtering gives you granular control over the types of content that users can access on the web. There are a number of predefined category sets: Liability, Bandwidth, Business, Communication, Entertainment, General Productivity, Information Technology, Lifestyles, News/Reports, Purchasing, and Security. Each category set includes subcategories; for example, those in the Liability category set include: Alcohol Gambling Tobacco Obscene/tasteless Profanity Violence Weapons Nudity Pornography Provocative attire Mature content Criminal activities Dubious Hacking/computer crime Hate/discrimination Illegal drugs Illegal software School cheating information For more information about exactly what types of web sites fall under each of these subcategories, see this link Click on the Category Query tab. Here you can test to see what category a particular URL belongs to. For example, in Figure 6 below you can see that I wanted to determine what category the URL www.hotpants.com belongs to (I have no idea what kind of site this is so I recommend that you dont go there). After entering the URL, click the Query button. In the Query Results section you can see that this URL belongs to the Pornography category (big surprise!).
Figure 6 If you dont agree with Microsofts assessment of a particular category, you can click the Report a URL to Microsoft Reputation Service as incorrectly categorized link. This brings up a web page that allows you to enter the URL you want re-categorized, as seen in Figure 7 below. You can also go there directly by visiting this link.
Figure 7 In the URL Filtering Settings dialog box, click on the URL Category Override tab, as shown in Figure 8. Here you can add a URL to a different category than the one to which its automatically added by Microsoft. Click the Add button and the URL Category Override dialog box appears. Enter the URL in the Override the default URL category for this URL pattern text box and then from the Move the URL pattern to this URL Category drop down list, select the new category.
Figure 8 The License Details tab provides a space where you can enter your License agreement number. You can test the TMG firewall for four months, but then youll need to enter a license number to keep using the URL filtering feature. URL filtering is subscription-based and is part of TMGs Web Security Service license, which also includes the Malware Inspection updates.
Figure 9 One more thing. If you create Deny rules, then you need to know about a new option available for the rule that allows your users to temporarily override the deny rule. Double click on the rule and click the Action tab, as shown in Figure 10. If you select Deny, you have the option to Allow user override. When you enable the users to override, you can also set a limit on how long that override lasts. When a user overrides the rule, the rule is temporarily disabled, and the Web request continues in the firewall policy evaluation. If you click the Advanced button, you can select the Display denial notification to user option and include text that the user will see when the access to a site is denied. The other option is to redirect the user to another site.
Figure 10 URL filtering is important because, by blocking access to inappropriate web sites, you not only reduce the risk of lawsuits and liability but you also increase security, because these types of sites often host malware. Further, you conserve bandwidth for legitimate network usage, and you improve productivity by denying users the opportunity to waste time on such sites. You can also use URL filtering to block advertising, and you can use URL Filtering reports to track how the organization uses the Web, determine which users visit which types of sites, and so forth. Certificate Revocation Finally, were going to move on to the Certificate Revocation options in TMG, which allow you to control how TMG handles verification that incoming client and server certificates are not revoked. If you click on the Web Access Policy node in the left pane of the console and click the Tasks Tab in the Task Pane, and scroll down to the bottom of the Tasks Tab, youll see the Configure Certificate Revocation link, as shown in Figure 11 below.
Figure 11 This brings up the Certificate Revocation dialog box thats shown in Figure 12. You have three options here: Verify that incoming client certificates are not revoked. This option is enabled by default. When enabled, the TMG firewall will block access from web clients whose certificates are revoked; this is typical for web publishing rules. Verify that incoming server certificates are not revoked in a forward scenario. This is for outbound access. If the destination web site or web proxy in front of the TMG firewall presents a revoked certificate, the connection will fail. This is the default setting. Verify that incoming server certificates are not revoked in a reverse scenario. This option, which is disabled by default, applies to web publishing scenarios where you are using SSL to SSL bridging. If the web server that youre publishing presents a revoked certificate, then the connection request will fail when this option is enabled.
Figure 12 Summary In this article, we took a quick look at three key features in the TMG firewall SafeSearch, URL Filtering and Certificate Revocation. While these configuration options arent complex, its important that you know about them and understand the effects of the various settings. After all, thats why you have a TMG firewall anyway because its easy to create a secure configuration for web access control. MG Back to Basics - Part 8: SafeSearch, URL Filtering and Certificate Revocation Options by Deb Shinder [Published on 14 June 2011 / Last Updated on 20 May 2013] In this article, we will take a quick look at three key features in the TMG firewall - SafeSearch, URL Filtering and Certificate Revocation. If you would like to be notified of when Deb Shinder releases the next part in this article series please sign up to our Real Time Article Update newsletter. If you would like to read the other parts in this article series please go to: TMG Back to Basics - Part 1: Server Publishing Rules TMG Back to Basics - Part 2: Using the TMG Firewall Log Viewer TMG back to Basics - Part 3: Protocol Definitions TMG Back to Basics - Part 4: Network Objects TMG Back to Basics - Part 5: Network Objects (Cont.) TMG Back to Basics - Part 6: Reports TMG Back to Basics - Part 7: SharePoint Server Publishing Introduction This week I thought Id poke around the TMG firewall console to see if there were some interesting options that I hadnt covered in my Back to Basics series. And lo, I did discover some options that I havent addressed, including the Safe Search, URL Filtering and Certificate Revocation options. So in this article, well take a look at these options and what you can do with them. When you open the TMG firewall console and click the Web Access Policy node in the left pane and then click the Tasks Tab in the in tasks pane, youll see the Web Protection Tasks as shown in Figure 1 below. The Web Protection Tasks that were most interested in today are: Configure SafeSearch Configure URL Filtering Configure URL Category Overrides Query for URL Category
Figure 1 SafeSearch First lets click on the SafeSearch link. This brings up the General tab in the SafeSearch dialog box, which is shown in Figure 2. Youll see that its s pretty simple dialog box. You have one option here: Enable SafeSearch. But what does that mean? When you enable SafeSearch, the TMG firewall will enforce strict filtering of adult content from search results delivered by supported search engines. This makes it possible for you to automatically block adult-oriented text, videos and images in the workplace. The supported search engines are those that are included in the Search Engines URL Category.
Figure 2 When SafeSearch is enabled, TMG will step in every time a user does a search on a major search engine, and modify the query string so that filtered results will be returned. The user cant disable this in their browsers, so you maintain control over the web content that users can access, which is increasingly important to avoid lawsuits and liability. When you enable SafeSearch, it creates a firewall rule, as you can see in Figure 3 below. In this example, the firewall rule is disabled because I disabled SafeSearch after initially enabling it. The rule doesnt appear until you enable SafeSearch the first time. If you disable it later, the TMG firewall will not remove the rule; it will just disable it. That makes it easy for you to switch SafeSearch on and off when needed. If you enable SafeSearch again, the rule will change state from disabled to enabled.
Figure 3 But what if there are some users in your organization who need to be exempt from the filtering? Maybe they do research that gives them a legitimate reason to access adult content. Click the Users tab, which is shown in Figure 4. On this tab, you can add users who will be excluded from SafeSearch. When you click the Add button, it will bring up the Users Excluded From SafeSearch dialog box. Note that these are user groups that you configure on the TMG firewall. You can use Active Directory groups to populate these groups, but you do need to create the groups first.
Figure 4 Thats about it for SafeSearch. Its very easy to configure it and works great! Id demo it for you, but all you would see is a search results page that doesnt include any adult links. URL Filtering Options Next, well look at the URL Filtering options. Click on the Configure URL Filtering link in the right pane of the TMG console. This brings up the General tab that you can see in Figure 5. Once again, there is only one option here: Enable URL Filtering. When URL Filtering is enabled, access rules can be configured to allow or block traffic based on the URL categories you select. Note that when this feature is enabled, information about the URL being reached is sent to the Microsoft Reputation Services for categorization. The TMG firewall doesnt download a database for this, it sends queries to the MRS database to determine to what category each URL belongs. This is done over an SSL connection and Microsoft does not keep a record of the URLs your users are accessing.
Figure 5 URL filtering gives you granular control over the types of content that users can access on the web. There are a number of predefined category sets: Liability, Bandwidth, Business, Communication, Entertainment, General Productivity, Information Technology, Lifestyles, News/Reports, Purchasing, and Security. Each category set includes subcategories; for example, those in the Liability category set include: Alcohol Gambling Tobacco Obscene/tasteless Profanity Violence Weapons Nudity Pornography Provocative attire Mature content Criminal activities Dubious Hacking/computer crime Hate/discrimination Illegal drugs Illegal software School cheating information For more information about exactly what types of web sites fall under each of these subcategories, see this link Click on the Category Query tab. Here you can test to see what category a particular URL belongs to. For example, in Figure 6 below you can see that I wanted to determine what category the URL www.hotpants.com belongs to (I have no idea what kind of site this is so I recommend that you dont go there). After entering the URL, click the Query button. In the Query Results section you can see that this URL belongs to the Pornography category (big surprise!).
Figure 6 If you dont agree with Microsofts assessment of a particular category, you can click the Report a URL to Microsoft Reputation Service as incorrectly categorized link. This brings up a web page that allows you to enter the URL you want re-categorized, as seen in Figure 7 below. You can also go there directly by visiting this link.
Figure 7 In the URL Filtering Settings dialog box, click on the URL Category Override tab, as shown in Figure 8. Here you can add a URL to a different category than the one to which its automatically added by Microsoft. Click the Add button and the URL Category Override dialog box appears. Enter the URL in the Override the default URL category for this URL pattern text box and then from the Move the URL pattern to this URL Category drop down list, select the new category.
Figure 8 The License Details tab provides a space where you can enter your License agreement number. You can test the TMG firewall for four months, but then youll need to enter a license number to keep using the URL filtering feature. URL filtering is subscription-based and is part of TMGs Web Security Service license, which also includes the Malware Inspection updates.
Figure 9 One more thing. If you create Deny rules, then you need to know about a new option available for the rule that allows your users to temporarily override the deny rule. Double click on the rule and click the Action tab, as shown in Figure 10. If you select Deny, you have the option to Allow user override. When you enable the users to override, you can also set a limit on how long that override lasts. When a user overrides the rule, the rule is temporarily disabled, and the Web request continues in the firewall policy evaluation. If you click the Advanced button, you can select the Display denial notification to user option and include text that the user will see when the access to a site is denied. The other option is to redirect the user to another site.
Figure 10 URL filtering is important because, by blocking access to inappropriate web sites, you not only reduce the risk of lawsuits and liability but you also increase security, because these types of sites often host malware. Further, you conserve bandwidth for legitimate network usage, and you improve productivity by denying users the opportunity to waste time on such sites. You can also use URL filtering to block advertising, and you can use URL Filtering reports to track how the organization uses the Web, determine which users visit which types of sites, and so forth. Certificate Revocation Finally, were going to move on to the Certificate Revocation options in TMG, which allow you to control how TMG handles verification that incoming client and server certificates are not revoked. If you click on the Web Access Policy node in the left pane of the console and click the Tasks Tab in the Task Pane, and scroll down to the bottom of the Tasks Tab, youll see the Configure Certificate Revocation link, as shown in Figure 11 below.
Figure 11 This brings up the Certificate Revocation dialog box thats shown in Figure 12. You have three options here: Verify that incoming client certificates are not revoked. This option is enabled by default. When enabled, the TMG firewall will block access from web clients whose certificates are revoked; this is typical for web publishing rules. Verify that incoming server certificates are not revoked in a forward scenario. This is for outbound access. If the destination web site or web proxy in front of the TMG firewall presents a revoked certificate, the connection will fail. This is the default setting. Verify that incoming server certificates are not revoked in a reverse scenario. This option, which is disabled by default, applies to web publishing scenarios where you are using SSL to SSL bridging. If the web server that youre publishing presents a revoked certificate, then the connection request will fail when this option is enabled.
Figure 12 Summary In this article, we took a quick look at three key features in the TMG firewall SafeSearch, URL Filtering and Certificate Revocation. While these configuration options arent complex, its important that you know about them and understand the effects of the various settings. After all, thats why you have a TMG firewall anyway because its easy to create a secure configuration for web access control. If you would like to be notified of when Deb Shinder releases the next part in this article series please sign up to our Real Time Article Update newsletter.