Forefront TMG (ISA Server) Product Team Blog

TMG SCOM-Pack – Monitor TMG with System Center 2007 R2

The “one stop shop” is a leading concept for a monitoring program like SCOM.

When we looked for a monitoring program for testing TMG servers internally we decided to explore MS system center 2007 R2 for this purpose, knowing that the Forefront TMG product team is developing an out-of-the-box SCOM pack, for administrators that includes a set of rules, monitors and performance counters.

The currently developed Forefront TMG SCOM/MOM pack is for Forefront TMG, Medium Business Edition, which comes with Windows Essential Business Server, but is compatible with TMG enterprise edition as well.

Although new features like Enterprise Malware Protection EMP, HTTPS Inspection and URL Filtering are not supported yet, Forefront TMG is planning to extend the monitoring capabilities in the future.

The following post below describes deployment and configuration of a Forefront TMG SCOM pack to better monitor and evaluate Forefront TMG server functionality and performance.

Disclaimer: The information and code attached in this blog-post are not officially supported by Microsoft. They are tested to work in Forefront TMG Beta3 test environment. Please use it in a test environment before deploying in production.

Forefront TMG SCOM-Pack deployment – SCOM Server Side

Let’s start with understanding the operations Console. The operations console is made up of the following parts:

Image 1:  SCOM server main console

Click on Administration in the Navigation button, right click on Management Packs, select import management pack, browse to the location of your MP file and import it.

Image 2:  SCOM server Administration console view

You’ll find the Forefront TMG SCOM pack in the list of packs.

Image 3:  SCOM server Administration console view

That’s it for the SCOM server side. It’s set with the appropriate monitors and rules for your TMG servers right out of the box.

 

TMG SCOM pack deployment – Forefront TMG Side

Now let’s deal with the TMG server rule-set to allow the traffic from TMG to SCOM. There are 2 system rules that TMG Beta3 contains, allowing SCOM traffic to pass. These rules exist in the system policy rules, and you should enable them once installing the SCOM agent.

Image 4:  Forefront TMG System policy rules view

Notes

1. TMG does not currently support the remote installation of the SCOM agent through the SCOM server, so until this is fixed, you’ll have to install the SCOM agent from the TMG side, providing the SCOM agent installation wizard the SCOM management group and server names.
2. You must restart TMG FW service after SCOM agent installation to allow traffic flow towards the SCOM server.
3. It can take a few minutes to see data from the Forefront TMG server loaded in SCOM.
4. You need SCOM 2007 R2 to import Forefront TMG SCOM pack without other SCOM packs dependencies. In case you are using an earlier version of SCOM/MOM, note that you may be required to import a few other SCOM packs that Forefront TMG SCOM pack is dependent on.

You now have completed end to end TMG - SCOM monitoring deployment.

Using the new deployed package

The first step is to click the Monitoring Navigation button on the SCOM console and look for MS Forefront TMG in the Navigation Pane. It lists built-in performance counters, TMG Server Roles and Monitors, active alerts from your TMG machines and Computer State.

Image 5:  SCOM Left Navigation Tree showing the relevant TMG components

Image 6:  Two of the main counters powered by TMG SCOM pack

By right-clicking on each of these graphs, you’ll get an extensive set of filtering options to display data range from minutes to weeks.

A few of the many cool options powered by the SCOM pack:

1. A diagram view of the deployed Forefront TMG servers.

2. You can add the Forefront TMG alerts view to your counter graphs, showing alerts along the timeline of the graph, as can be seen in the graph above.

3. One repository for alerts for all of your TMG and other servers in the organization.

Image 7:   SCOM Left Navigation Tree showing the relevant TMG components

4. You can take action upon a specific event or alert like sending a mail/IM/SMS or running some command line or a script.

Image 8:  SCOM server Administration console view

Troubleshooting connectivity issues between Forefront TMG and SCOM.

Use TMG log-viewer monitor for troubleshooting connectivity. You can monitor the traffic between TMG and the SCOM server (destined to ports 5723, 5724) and validate that it’s reaching the SCOM server.

Image 9:  Forefront TMG log-viewer

Conclusion

This post covered deployment and configuration of a SCOM pack to better monitor and evaluate TMG’s deployed functionality and performance. However, there were some areas that were not covered but might also be useful for enhancing the monitoring requirements, which I’ll get to in my next posts:

1. Advanced tasks for extending the Forefront TMG SCOM pack capabilities, like adding rules, monitors and counters of your own.

2. Administering TMG SCOM-pack using Power Shell.

Feedback is welcome.

Author:

Gabriel Koren, Forefront TMG Test team.

Reviewers:

Noam Ilovich, Program Manager, Forefront TMG Team

Roiy Zysman, Lead, Forefront TMG test team

Configuring Network Inspection System (NIS)

 

Network Inspection System (NIS), the vulnerability signature component of TMG Intrusion Prevention System (IPS), comes with a pre-defined recommended policy out of the box – this is the recommended configuration for NIS.  Nevertheless, NIS supports granular control and policy configuration to comply with your specific organization needs, troubleshooting and investigation requirements.

In this blog, I would like to explore NIS configuration options while in subsequent blog postings, we will explore how they can be used for specific detailed scenarios.

General configuration

You can easily locate configuration options on the Task Menu of the NIS IPS Tab.

Once you click on Configure Properties task, the main NIS Properties Configuration Pane is ready to use.

Enabling NIS– Properties Configuration Pane:

NIS is enabled by default.

If NIS is disabled, click on Configure Properties the main NIS Properties Configuration Pane.

Check Enable NIS à you are ready to go!

You can choose to Enable or Disable NIS. If you choose to Disable NIS, your policy configuration (signature overrides, new signature policy, exception list etc) are still saved. Once you enable NIS you are up and running again with no further action required. NIS it will immediately check for new updates and comply with your signature snapshot update policy.

Configuring Signature Sets Updates

NIS uses signatures developed by the Microsoft Malware Protection Center to protect un-patched systems from attacks that exploit known vulnerabilities of Microsoft operating systems and applications. To keep your systems protected from the latest threats, we recommend that you verify that you have connectivity to the appropriate update source (Microsoft Update or WSUS) and that you enable automatic installation of the latest signatures.

Before you can use Forefront TMG to block attacks on known vulnerabilities, you must first download the latest NIS signature set. Follow the instructions below to configure NIS signature set updates.

To manage NIS signature set downloads:

1. In the Forefront TMG Management console, in the tree, click the Intrusion Prevention System node.
2. On the Tasks tab, click Configure Settings.
3. On the Update Configuration tab, under Select automatic update action, select one of the following options:
   • Check for and install updates (recommended) — select this configuration to automatically download and install the latest signature updates.
   • Only check for updates — select this configuration to be notified of the availability of new signatures for download.
   • Do nothing — select this configuration to disable automatic updates.
4. Select Automatic Polling Frequency – Recommended default is 15 minutes. Definition Updates will be downloaded only when new ones are available!
5. Under Select the response policy for new signatures, select one of the following options:
   • Microsoft default policy (recommended) — select this configuration to accept the default response to the signature.
   • Detect only response — select this configuration to record a log only when traffic matching this signature is detected.
   • No response (disable signature) — select this configuration to take no action and to not record a log if traffic matching this signature is detected.

You can click the Version Control button to select older signature snapshot. This feature should be used only for troubleshooting scenario; this will be discussed in detail in a future blog posting; stay tuned…

You can verify the NIS overall Signature Update Configuration in the Information Bubble in the main Pane:

or through the TMG Update Center, the centralized management console for all TMG protection mechanisms definition updates. This is an area for a dedicated blog; stay tuned…

Configuring Exceptions

NIS allows you to exclude network entities from inspection. You may choose to exclude any network objects known to TMG (IP Sets, URLs Sets etc) for capacity planning or troubleshooting scenarios. When you exclude a network object both incoming and outgoing traffic is excluded from inspection.

To manage NIS exceptions:

1. In the Forefront TMG Management console, click the Intrusion Prevention System node.

2. On the Tasks tab, click Define Network Inspection System Exceptions.

3. On the Exceptions tab, click Add, and then select the network entities you want to exclude from inspection.

4. When finished, on the Apply Changes bar, click Apply.

Configuring Protocol Anomaly Policy

Network Inspection System (NIS) checks that the network traffic is in compliance with protocol standards. In some cases, an anomaly is by design and for a legitimate purpose, but in others it may be a network attack designed to evade intrusion prevention systems. You can choose which action NIS takes when detecting traffic with a protocol anomaly: Allow, avoiding blocking legitimate traffic or Block, to tighten security.

Configuring Global Setting

NIS can be operated in Either Microsoft Recommended Default (Discussed more in Signature Overrides section next) or as Intrusion Detection System (IDS). Once Global Policy is chosen new signature updates will receive the Global Policy setting automatically.

Configuring Signatures Overrides

NIS allows you to have granular control over policy configuration. Basically, NIS comes with a pre-defined recommended policy out of the box – this is the recommended configuration for NIS. The NIS Response Team set the Recommended Policy based on multiple factors including the vulnerability severity and business impact. Microsoft Malware Protection Center may change the recommended policy automatically through signature snapshot update. If you choose your own policy, such as setting a “Block” mode signature to "Detect Only" we will not change it automatically for you.

You can change the policy for a specific signature, multiple selection signatures or a group of signatures.

To select a group of signatures, you should group the signature by choosing one of the pull down options available in the NIS IPS Tab: Response, Policy Type, Business Impact, Category, Date Published, Severity, Fidelity, Protocol or Status.

Once a group is selected , you can choose the appropriate policy from the Task Menu or by right click options available below:

You can also perform an operation on all signatures to enable NIS as an Intrusion Detection System (IDS) by setting all responses to “Detect Only” or Intrusion Prevention System (IPS) by setting all responses to Microsoft Recommended Defaults.

Watch for our upcoming blog entries and whitepapers planned for the near future discussing NIS deployment, monitoring and troubleshooting in depth.

Author

 

Moshe Golan, GAPA Program Manager – Forefront

Reviewers

 

David B. Cross, Product Unit Manager – Forefront

Avi Ben-Menahem, GAPA Group Manager – Forefront

Evgeny Skarbovsky, GAPA Senior Development Lead – Forefront

Erez Sharvit, GAPA Software Developer Engineer – Forefront

 

Understand duplicate authentication prompts ISA 2006 publishing MOSS using FBA

When you're publishing your MOSS/Sharepoint server with ISA 2006 using the ISA Form Based Authentication (FBA), you may see that your users are complaining about duplicate authentication prompts. This may happen when your users are opening Office documents.

This behavior can be explained on how ISA Server authenticates clients when you're using ISA FBA.

ISA server generates a cookie to authenticate the web request which is send to the client. For improved security the default cookie setting is 'never use persistent cookies' (screenshot below). However, with this configuration the cookie that was send to the client can only be used by the process which requested the cookie!

When the user clicks on a link within your MOSS/Sharepoint page and want to open an Office document, your Client will automatically start the application associated with the file type extension in a new process.

This process will then send a request using the Hyperlink in the MOSS/Sharepoint, in order to access/open the file.

As mentioned before the cookie the client uses to authenticate each request, may only be used by the process which requested it. Therefore the process which sends the request to the ISA server is not able to use this cookie, and the request send to the ISA server will not contain the cookie and therefore ISA Server will not be able to associate this client request to the connection on which the authentication cookie was send. As a result ISA server will prompt the user to authenticate (again).

The only solution to change this behavior in this scenario is to change the cookie type ISA server uses to authenticate the client to 'persistent'.

Before changing this setting you should understand the following security issues related to persistent cookies:

• A malicious attacker who obtains a persistent cookie may be able to perform a brute force attack to obtain user credentials from the cookie.
• On a public computer, if the user does not log off, the session cookie can be used by the next user to access published sites. This threat can be mitigated by not enabling persistent cookies for public computers or by adding authentication features like one time passwords.
• Spyware may be able to access the cookie as well.

To change the cookie behavior, please open the Web Listener connected to the MOSS/Sharepoint publishing rule and navigate to the 'Forms' tab. Now select 'Advanced...'.

In the case you decide that you have to use persistent cookies, we recommend to use the 'Only on private computers' setting and ask your users not to use the 'private computers' setting on computers not matching your company policy.

After changing this setting to use persistent cookies, each cookie aware application on the client PC is able to access this cookie and to use it to authenticate with the ISA server. Therefore you should not see any duplicate authentication prompts caused by this cookie type.

However we've heard from customers, still having issues with duplicate authentication prompts, although ISA is configured to use persistent cookies, and your users are using Vista or Win7 to access the MOSS/Sharepoint. This issue is described in detail in KB932118.

In order to resolve the duplicate authentication prompts, you have to add the published MOSS/Sharepoint site to the Trusted Sites zone and make sure, that the Protected Mode is disabled for the Trusted Sites zone.

Author

Philipp Sand
Microsoft CSS Forefront Security Edge Team

Technical Reviewer

Thomas Detzner

Escalation Engineer - Microsoft CSS Forefront Edge Team

ISA Integrated NLB - Multicast with IGMP… ISA “blocks” IGMP packets

After configuring ISA Integrated NLB to use multicast with IGMP, you may see blocked IGMP packets between your ISA array members. The ISA nodes don't need these packets  to work properly, and it's ok when they are blocked by the Firewall Engine.

As many customers are using Multicast NLB, we added multicast and multicast with IGMP for ISA Integrated NLB in SP1, (http://support.microsoft.com/kb/938550; also part of ISA 2006 SP1) we've heard from some customers  who were confused by seeing denied IGMP packets in the ISA logging after they enabled Multicast IGMP NLB mode.

In the following example, the source IP (147.88.201.25) is the primary NLB IP and the destination IP is the multicast IP of the NLB Array:

The packets you see denied are multicast IGMP packages, which are denied by the Firewall Service. As a good admin you start to worry and double check the status of your NLB array by executing the command wlbs query :

WLBS Cluster Control Utility V2.4 (c) 1997-2003 Microsoft Corporation. 

Cluster 147.88.201.25 

Host 3 has entered a converging state 3 time(s) since joining the cluster and the last convergence completed at approximately: 07.05.2009 18:49:20 

Host 3 converged with the following host(s) as part of the cluster: 

2, 3

No errors can be found here. For more details, and to verify, that you're running IGMP NLB, you can use wlbs display:

WLBS Cluster Control Utility V2.4 (c) 1997-2003 Microsoft Corporation.

Cluster 147.88.201.25

=== Configuration: ===

Current time              = 08.05.2009 18:38:11

ParametersVersion         = 4

VirtualNICName            =

AliveMsgPeriod            = 1000

AliveMsgTolerance         = 5

NumActions                = 100

NumPackets                = 200

NumAliveMsgs              = 66

ClusterNetworkAddress     = 01-00-5e-7f-c9-19

ClusterName               = External

ClusterIPAddress          = 147.88.201.25

ClusterNetworkMask        = 255.255.255.0

DedicatedIPAddress        = 147.88.201.156

DedicatedNetworkMask      = 255.255.255.0

HostPriority              = 3

ClusterModeOnStart        = STOPPED

PersistedStates           = SUSPENDED

DescriptorsPerAlloc       = 512

MaxDescriptorAllocs       = 512

TCPConnectionTimeout      = 60

IPSecConnectionTimeout    = 86400

FilterICMP                = DISABLED

ScaleSingleClient         = 0

NBTSupportEnable          = 1

MulticastSupportEnable    = 1

MulticastARPEnable        = 1

MaskSourceMAC             = 1

IGMPSupport               = ENABLED

IPtoMcastIP               = ENABLED

McastIPAddress            = 239.255.201.25

NetmonAliveMsgs           = 0

EffectiveVersion          = V2.1

IPChangeDelay             = 60000

IPToMACEnable             = 1

ConnectionCleanupDelay    = 300000

RemoteControlEnabled      = 0

RemoteControlUDPPort      = 2504

RemoteControlCode         = 0x0

RemoteMaintenanceEnabled  = 0x0

CurrentVersion            = V2.4

InstallDate               = 0x4A00418C

VerifyDate                = 0x0

NumberOfRules             = 1

BDATeaming                = ENABLED

TeamID                    = {5601BF8D-2D28-46D2-B4DC-0983B2B6532E}

Master                    = ENABLED

ReverseHash               = DISABLED

IdentityHeartbeatPeriod   = 10000

IdentityHeartbeatEnabled  = ENABLED

PortRules                

Virtual IP addr Start   End     Prot    Mode            Pri     Load    Affinity

            ALL     0   65535   Both    Multiple                Equal   S

No problems can be found here and the array is load-balancing traffic just fine...

Why is ISA blocking the IGMP status messages from its own NLB array, and why is the array still working?

1. If ISA is not configured to explicitly allow Multicast traffic, ISA will always block the Multicast packets.

2. The Multicast packets you see blocked by the Firewall Engine, are IGMP messages sent periodically from the router to each member in the multicast group (Host membership query). Additionally, you'll see packets sent from the ISA node to the multicast router (Host membership report or Leave group). http://technet.microsoft.com/en-us/library/cc787925(WS.10).aspx provides more detail on how IGMP works.

In order to understand why NLB is still working, a quick look at the ISA Server Architecture should clarify things:

More information about the ISA architecture can be found in the ISA Server 2006 Firewall Core Whitepaper (http://download.microsoft.com/download/e/7/6/e76fdda3-5c2c-4fbb-9c6f-3bcd0ed4b8ef/Firewall_Corewp.doc)

The ISA Firewall Engine hooks itself to the TCP/IP Stack. However the NLB driver can be found below the TCP/IP Stack in the NDIS layer. Because of this the NLB driver will process the packets before the Firewall Engine can deny them. As other applications don't need to process those packets, NLB continues working, although it appears as if ISA denied them.

TIP: In order to prevent those denied packets from flooding your logs with data you don't really need, you may create a deny rule for all IGMP traffic sent to the Multicast IP address (displayed in the wlbs /display output) and configure this rule to not log matched requests.

In order to create this rule you'll have to create a new protocol, to match the IGMP protocol. In the ISA MMC go to Firewall Policy - Tool Box - Create a new Protocol with the following details:
IGMP - IP Protocol ID 2, send-receive:

in the next step you should create a new computer object for your IGMP Multicast address:

Note:  this IP address will most likely be different in your environment. Make sure to verify it with the output from the wlbs display command.

Create an access rule with the appropriate sources (in this example the source would be External) and choose the IGMP protocol and the new computer object as the destination.

After you finish the new access rule wizard, open the rule properties, and disable the logging for this rule in the Action tab by unchecking 'Log requests matching this rule'.

Author

Philipp Sand
Microsoft CSS Forefront Security Edge Team

Technical Reviewer

Jim Harrison
Microsoft PM Forefront Edge CS

Doron Juster
Microsoft SENIOR SDE ForeFront Edge

Bing Safe Search, ISA Server and Forefront TMG

With the release of Microsoft’s new search portal (AKA decision engine), the Bing team has offered a coup;le of methods by which you can filter out unwanted content; generally classified as “explicit”.  Unfortunately, the first method outlined in the Bing blog doesn’t help ISA or TMG users. To help make this easier for firewall and proxy administrators, the Bing team created a new subdomain as explicit.bing.net. In this posting, I’ll show you how to use that new method in your ISA and TMG policies.

TMG Beta 3 brings with it the long-awaited URL categories feature. In concert with Microsoft Reputation Services and their many partners, TMG allows you to block content you or your organization consider inappropriate. This process will help you include the new Bing explicit sites to that set.

1.       In the TMG management console, select Firewall Policy

2.       In the right pane:

a.        select the Toolbox tab

b.       expand Network Objects, then URL Categories

3.       Right-click Pornography (or whichever category you prefer) and select Properties

4.       In the URL Categories Properties page:

a.        click Add

b.       in the URL Categories Override dialog, enter explicit.bing.net/*, click OK

c.        click Add

d.       in the URL Categories Override dialog, enter *.explicit.bing.net/*, click OK

5.       Your modified URL category should appear as shown below

 

 

 

6.       Click OK to close the URL Category Properties page

Ideally, you would have allowed TMG to build a default blocked URL category set as part of the Web Access Policy wizard. If you’ve already created your Web Access policy set using this option, your Web Access policy set will include a Blocked Web Destinations “deny” access rule as shown below:

If you don’t have this rule and you’re willing to completely rewrite your Web Access Policy, use the Configure Web Access Policy wizard to create a default Web Access policy that includes this set. Otherwise…

7.       In the TMG management console left pane, select Firewall Policy

8.       In the center pane, select the first-listed access rule (this ensures that the new rule is listed first)

9.       In the left pane, right-click Firewall Policy and select New, then Access Rule

10.    In the Welcome page, enter Deny Porn and click Next

11.    In the Rule Action page, select Deny and click Next

12.    In the Protocols page, click Add

13.    In the Add Protocols page:

a.        expand Web

b.       Select HTTP, then click Add

c.        Select HTTPS, then click Add, then click Close

14.    In the Protocols page, click Next

15.    In the Access Rule Sources page, click Add

16.    In the Add Network Entities page:

a.        expand Network Sets

b.       select All Protected Networks, click Add

c.        click Close

17.    In the Access Rule Sources page, click Next

18.    In the Access Rule Destinations page, click Add

19.    In the Add Network Entities page:

a.        expand URL Categories

b.       select Pornography, click Add

c.        click Close

20.    In the Access Rule Destinations page, click Next

21.    In the User Sets page, click Next

22.    In the Completing the New Access Rule Wizard page, verify that the summary data is correct, and then click Finish; your new rule should appear immediately above the previously-selected access rule.

If you don’t want to mess with URL Categories (or you haven’t upgraded from TMG B2 yet – fer shame on ya), or you’re still using ISA Server, then you need to use domain name sets in a deny rule.

1.       In the management console, select Firewall Policy

2.       In the right pane:

a.        Select the Toolbox tab

b.       Expand Network Objects

c.        Select New, then Domain Name Set

3.       In the New Domain Name Set Policy Element page:

a.        Enter Bing Explicit in the Name field

b.       click Add

c.        in the center pane, enter explicit.bing.net, click Add

d.       in the center pane, enter *.explicit.bing.net, click OK

4.       Your modified Domain Name Set should appear as shown below

 

 

 

5.       Click OK to close the New Domain Name Set Policy Element page

6.       In the management console left pane, select Firewall Policy

7.       In the center pane, select the first-listed access rule (this ensures that the new rule is listed first)

8.       In the left pane, right-click Firewall Policy and select New, then Access Rule

9.       In the Welcome page, enter Deny Bing Explicit and click Next

10.    In the Rule Action page, select Deny and click Next

11.    In the Protocols page, click Add

12.    In the Add Protocols page:

a.        expand Web

b.       Select HTTP, then click Add

c.        Select HTTPS, then click Add, then click Close

13.    In the Protocols page, click Next

14.    In the Access Rule Sources page, click Add

15.    In the Add Network Entities page:

a.        expand Network Sets

b.       select All Protected Networks, click Add

c.        click Close

16.    In the Access Rule Sources page, click Next

17.    In the Access Rule Destinations page, click Add

18.    In the Add Network Entities page:

a.        expand Domain Name Sets

b.       select Bing Explicit, click Add

c.        click Close

19.    In the Access Rule Destinations page, click Next

20.    In the User Sets page, click Next

21.    In the Completing the New Access Rule Wizard page, verify that the summary data is correct, and then click Finish; your new rule should appear immediately above the previously-selected access rule.

In the center pane, click Apply to enforce your new policy. When prompted, enter a description for this change (hey - the URL for this blog could work) and click OK

Jim Harrison, Program Manager, Forefront Edge CS

Tech Reviewers
Chris Rayner, Sr Program manager, Search
Mike Dean, Sr Product Mgr, Search
Yuri Diogenes, Support Engineer, Forefront Edge
Mohit Saxena, Tech Lead, Forefront Edge

How to exclude specific computers from URL Filtering?

I have seen this question a few times on both  internal and external lists so I figured I would write a quick blog on this.

Forefront TMG Beta3 URL filtering feature allows you to create rules that will block or allow traffic based upon the categorization of the URL. For more information the URL filtering feature see the Dotan’s blog post, URL Filtering is Here!.

So you created a rule to block specific access to Restaurant/Dining  URL category like the one below. Replace Restaurant/Dinning with the category of your choice.

As the admin you need access to  restaurant sites or your day is not complete and with the new rule added above you TMG is blocking you.   Replace “admin” with CEO, President, etc.

You have a few options available at your disposal to give the employee access to the restaurant and dinning web sites.

 Solution 1:

Modify the existing rule and add an exception on either the From tab or the Users tab. In the configuration below the Block rule would not apply to traffic originating from “MyComputer” computer object.  You still need a rule after the block rule that allows traffic out to the Internet.

or

Solution 2:

Create a new rule above the block rule allowing traffic from “MyComputer” to the Restaurants/Dinning URL category.  You can also create an allow rule for specific users.

 

 

Both solutions work, I personally prefer Solution 1 as it does not require creating additional rules, however on the other hand Solution 2 is a little bit easier to understand with a quick glace at the rule base.  It is nice to have options. :)

 

Author:

Gershon Levitz, Program Manager,  Forefront TMG

Reviewers

Jim Harrison, Program Manager, Forefront TMG

Introducing Forefront Network Inspection System (NIS) in TMG Beta 3 release

You may have had the opportunity to experiment with NIS when it was first released with TMG Beta 2 andich provies preliminary insights into the new technology provided technology preview of the new Network Inspection System. NIS is a protocol decode-based traffic inspection system that uses signatures of known vulnerabilities, to detect and potentially block attacks on network resources. TMG Beta 3 release is the first release in which NIS provides comprehensive protection for Microsoft network vulnerabilities, researched and developed by Microsoft Malware Protection Center - NIS Response Team, as well as an operational signature distribution channel which enables dynamic signature snapshot distribution.  

What is the motivation behind NIS?

As information worker users increasingly find it more difficult to achieve anytime anywhere access in a re-perimeterized world, ubiquitous and comprehensive protection for the “outbound access” scenario is paramount.  Outbound access is defined as user initiated network access whether it is the Internet or corporate network regardless of application or protocol.  End users are predominately accessing the Internet using a web browser which creates an easy attack surface for malicious hackers. The nature of the web demands unique protections around protocol vulnerabilities, including the frequently used HTTP and HTTP/s protocols as well as other protocols such as RPC, SMB and the different mail protocols. Forefront Network Inspection System (NIS) is Microsoft’s response to this new and growing IT concern.  In its first release NIS is integrated with Threat Management Gateway (TMG) as a component of its Intrusion Prevention System (IPS) offering.

Motivated by the large number of application-level protocols and new ones constantly emerging, Microsoft Research (MSR) have architected a Generic Application-level Protocol Analyzer (GAPA), consisting of a protocol specification language (GAPAL) and an analysis engine that operates on network streams and traces. GAPA allows rapid creation of protocol analyzers, greatly reducing the development time needed (See the MSR research paper: http://research.microsoft.com/pubs/70223/tr-2005-133.pdf ). In TMG, we have implemented NIS based on the GAPA research as a signature-based Intrusion Prevention System (IPS).

As we are seeing increasing number of zero-day attacks at the network and application layer, we are constantly looking for ways to protect hosts and networks against exploitation of the discovered vulnerabilities.

One of the key problems is that attackers can usually develop and use exploits for the disclosed vulnerabilities faster than software vendors can develop patches and customers can deploy the patches. Reviewing past vulnerabilities shows that it can take up to a month from the initial attacks reports to develop and release patches, and on top of this another 1-2 weeks for the customer to deploy the patch across the vulnerable computers. This leaves computers for over a month vulnerable to attacks and exploitation.  As stated, NIS is a signature-based IPS leveraging the GAPA technology for the purpose of developing and deploying vulnerability-signatures. The main purpose and value proposition of NIS is to close the vulnerability window between vulnerability disclosures and patch deployment from weeks to few hours. 

What is so special about NIS?

NIS main differentiator is Signature Quality (minimum False Positive and False Negative) on Microsoft focused vulnerabilities. NIS vulnerability signatures (versus exploit based) cover all flavors of exploit attacks leveraging vulnerability in contrast to exploit specific detections which are susceptible to evasion.  

Microsoft assets (Operating Systems and Application) may be extremely important to protect. Therefore, even if you have existing IPS solution, we encourage NIS deployments as first or second line of defense to strengthen MS assets protection.

One important and not obvious benefit for using NIS is protection for retired OS and applications.  Once a product is retired (not supported by Microsoft) it is not supported for security patches (See Microsoft’s Support Lifecycle pages for details).  Recently, Windows Server 2003 Service Pack 1 was retired - on April 14, 2009. The Conficker for instance attacked un-patched machines, as well as many older versions of Windows for which patches are not available. The only way to protect retired OS and applications is by using Virtual Patching such as NIS.

Following are a few samples of NIS Signatures Protection on Microsoft Malware Protection Center Security Portal:

·         http://www.microsoft.com/security/portal/beta/Threat/Encyclopedia/NIS.aspx?threat=Vuln-Win-MSRPC-DNS-RCE-2007-1748

·         http://www.microsoft.com/security/portal/beta/Threat/Encyclopedia/NIS.aspx?threat=Vuln-Win-SMB-Trans-RCE-2008-4835

 

 Well, now all that is left to do is to enable NIS on TMG Beta 3 and try it out!

Enabling NIS through the NIS IPS – Property Configuration Pane:

Just click on Configure Properties the main NIS Property Configuration Pane.

 

 Check Enable NIS à you are ready to go!

 

 

Basically, NIS comes with a pre-defined recommended policy out of the box – this is the recommended configuration for NIS. The NIS Response Team set the Recommended Policy based on multiple factors including the vulnerability severity, business impact, Signature Category and others. We will leave this discussion for another blog including detailed NIS configuration blog. The NIS Response Team may change the recommended policy automatically through signature snapshot update. You may note in Beta 3 lifecycle, that gradually most signatures that are set to "Detect Only" will be updated to “Block” mode once we gain confidence in them. With that said, though NIS supports granular control and policy configuration, we recommend in Beta 3 to enable NIS in Microsoft Recommended mode.

You can choose to Enable or Disable NIS at anytime. If you choose to Disable NIS, your policy configuration (signature overrides, new signature policy, exception list etc) are saved. Once you enable NIS you are up and running again with no further action required.

What’s next?

Please look for our upcoming blog entries and whitepapers planned for the near future discussing NIS deployment, configuration, monitoring and troubleshooting in depth.

Authors:

Avi Ben-Menahem, GAPA Group Manage – Forefront TMG

Moshe Golan, GAPA Program Manager – Forefront TMG

 

Troubleshooting Authentication Issues in ISA Server Using Net Logon Logging

Background:

I recently had a case where web proxy clients were randomly being prompted for credentials when going to the Internet through ISA Server 2006. Even after entering the proper credentials they were not able to get to the Internet.  This particular environment had Internet access restricted to a certain group of users so authentication was required.  The problem seemed to plague random users at various times and would only last for about 15 minutes. Eventually the issue would go away on its’ own and Internet access would return for the affected users. Normally I might lean towards the domain controller being overloaded but since there were only about 1000 web proxy clients this didn’t seem to make sense.

To make the issue even a bit trickier to troubleshoot, the issue would often go away before their technical people could gather any diagnostic information. The ISA Best Practices Analyzer is an invaluable tool to help us capture and analyze data when reproducing the issue is easy to do.  In this case, the IT Team was usually alerted to the issue after it was too late to gather the necessary data.  When using this tool for reactive scenarios such as this you should capture data using the ISA Data Packager.  Please see the article “Using ISABPA for Proactive and Reactive Work with ISA Server – Part 2 of 2” that has step by step instructions for this tool.

Analysis:

Since the issue involved authentication issues we decided to enable Net Logon logging on the Domain Controller which ISA Server had a secure channel established with.  For this we need the tool NLTEST which is found in the Windows Support Tools on the Windows 2003 CD.  An article to reference for NLTEST syntax can be found at http://technet.microsoft.com/en-us/library/cc786478.aspx

 

 

I used the alternate method it mentions and ran nltest /dbflag:0x2080ffff in a command window.  Next, I stopped and restarted Net Logon service.  Note:  You can actually run a slightly different flag if you want to eliminate some of the extraneous information:  nltest /dbflag:0x20000004 

 

After you enable debug logging and stop and restart the Net Logon Service a log will be created called netlogon.log in the Systemroot\Debug directory.  Please note that performance can be degraded by this logging process and you will want to turn it off when you are done troubleshooting. To do this run nltest /dbflag:0x0 and then stop and restart the Net Logon Service.

 

Below is a sample of what the information in this log file that is created looks like.

 

To help you interpret the output and for additional details about Net Logon logging please see Maintaining and Monitoring Account Lockout

 

Using this article we see that the code 0x0 is a successful logon. Since this log file can get quite large depending on your environment it would help to be able to quickly find what you are looking for.  Since we knew the account name of a user being affected (contoso\keith)  it could be possible to filter this log file and find the information we needed.  There is  a nice command to help you do this at a command prompt using findstr :

 

findstr /I “contoso\keith” c:\windows\debug\netlogon.log >> c:windows\debug\failed.txt

 

Looking at the file we just created we now see information relevant to the account contoso\keith

 

When we looked up the code 0xC0000234 we see that the account was being locked out.  I used the table found at http://technet.microsoft.com/en-us/library/cc776964.aspx for an explanation of the code.

 

We found out that the customer had a password policy which allowed for 3 bad password attempts set in Group Policy for the Domain. The Account Lockout Duration was set to 15 minutes. This explained why the issue would last only for a little while and then go away.

The next question was “Why were the accounts being locked out?” Debug logging was enabled on the other Domain Controllers and analysis was done using the articles previously mentioned. It turns out that a few machines in another site were infected by a virus that was using a dictionary attack to try to gain access to various accounts.

 

Note: A great article that explains how to troubleshoot account lockout can be found at the Microsoft Download Center.

 

Conclusion:

Authentication issues affecting ISA Server can often be tricky to troubleshoot. Using the tools and techniques outlined in this article, specifically Net Logon debug logging , can help us more quickly get to the source of the problem.

 

Author

Keith Abluton

Security Support Engineer – Forefront Edge Team

Microsoft – Charlotte

 

Technical Reviewer
Yuri Diogenes
Sr Security Support Escalation Engineer – Forefront Edge Team

Microsoft – Texas

 

 

Posted by isablog | 1 Comments

Filed under: Troubleshooting, ISA 2006

URL Filtering is Here!

Quick Introduction

Hi Everyone,

We are proud to introduce as part of Forefront TMG Beta3 one of the key elements in the Secure Web Gateway (SWG) role of Forefront TMG – URL Filtering.

URL Filtering allows controlling end-user access to Web sites, protecting the organization by denying access to known malicious sites and to sites displaying inappropriate or pornographic materials, based on predefined URL categories.

The typical use case for this feature includes:

· Enhancing your security.

· Lowering liability risks.

· Improving the productivity of your organization.

· Saving network bandwidth.

The URL Filtering administration experience is pretty straightforward. All you need to do after enabling the feature is add one or more of the predefined URL categories into Forefront TMG policy (you can find some UI snapshots further below). Once this is done, end-users browsing to a Web site included in one of those categories will be blocked and presented with a relevant notification page, which you can customize.

Additional value can be obtained from URL Filtering related reports and log entries. Have you ever wanted to understand how Web usage in your organization is distributed? And how about identifying those users who consistently violate your Web usage policy? You can do those easily now by looking at the built-in URL filtering reports.

Finally, URL Filtering categories can also be leveraged to exclude sites from being inspected by the HTTPS Traffic inspection and the Malware Inspection features. For instance, you may wish to exclude financial sites from HTTPS inspection, due to privacy considerations.

Before going into further details, note that the feature is still in Beta, so we do expect significant improvements in coverage and accuracy by the final TMG release.

URL categorization data, where does it come from?

TMG features over 80 URL categories ranging from security-oriented selections, like Phishing, Malicious and Anonymizers, through productivity-oriented categories such as Games, or Instant Messaging, and ending with liability-oriented categories like Criminal Activities and Pornography. Categories are also grouped into a higher-level hierarchy which we call Category Sets. The latter can also be used in TMG policy to simplify configuration.

As some of you may have noticed, at the RSA 2009 Conference Microsoft announced its new reputation services and its intention to provide these capabilities for our security products and solutions.  Microsoft also announced several key partnerships in the URL filtering space that will be used to support these reputation services. Forefront TMG will be the first system at Microsoft to leverage and utilize Microsoft Reputation Service (MRS).

MRS is a cloud-based object categorization system hosted in Microsoft data centers and designed to provide comprehensive reputation content to enable core trust scenarios across Microsoft solutions. In the case of Forefront TMG, in order to find out the category of a URL, TMG issues an online query to MRS. MRS maintains a database with tens of millions of unique URLs and their respective categories.

Does this mean every end-user request is sent out to the cloud? No it doesn’t. To improve bandwidth utilization and performance, we have implemented a local cache (residing on a TMG server), that stores the recently queried URLs and their respective categories. Cache entries are subject to a time-to-live value, allowing refreshing the entry periodically. This local cache is expected to serve the overwhelming majority of user requests.  The cache is persistent so it doesn't need to be refreshed after each reboot. TMG will query MRS only when a request cannot be served from the local cache.

But that's only the tip of the iceberg. Read on to find out why we think we are building something special with TMG and MRS together.

What is so special about Microsoft Reputation Service (MRS)?

The MRS team wanted to confront an inherent problem with traditional URL Filtering solutions: the problem domain is simply too large for any single vendor to provide a complete solution on its own. As a result, there are multiple vendors out there, each one specializing in a specific area of the solution.

Some vendors specialize in identifying malicious sites and spam URLs; others are rich with productivity related categories. Some specialize in covering the Internet's “long tail”; others are great with quick classification of previously unknown sites. Some use human-based classification where others use machine-based techniques. Some are great with Web2.0 style URLs… OK, I'll stop here as you get the idea by now. Even those vendors who employ several classification techniques and cover multiple categories can't deal with the huge and ever-expanding challenges of today's Web.

MRS team's idea was simple; let's leverage complementary capabilities of different vendors/sources to create a unified database that is best suited to deal with the challenges described above. And so, they have implemented a scalable architecture that allows incorporating multiple streams of data into a merged database. This way – each vendor/source brings its unique strengths to the table into a common solution.

MRS already integrates several data sources and others will be on-boarded in the following months. Some of these data sources are Microsoft internal, and others are the result of collaboration with 3^rd party partners. One such agreement, announced during RSA, is an agreement with Marshal8e6.  Other agreements have not been disclosed yet. Expect some surprises...

But the real beauty is that being a Web service, and given its unique architecture, MRS can easily incorporate new DBs completely transparently to the customers. We expect the MRS unified database to expand over time and become the recognized industry leader. TMG customers will benefit naturally from this ongoing upgrade, through our Web security subscription services.

Other interesting aspects – security ,privacy, licensing

Security – Both Forefront TMG URL Filtering and MRS were designed with security in mind, following Microsoft's Security Development Lifecycle (SDL) strict standards and guidelines. Both are resilient to a variety of attacks, and the communication between the two is encrypted.

Privacy – this is a known concern when discussing cloud based services, and therefore the privacy of our customers' data is paramount. We are issuing detailed privacy statements along with the Beta 3 release to provide clarity and transparency on our privacy policies. Make sure to read those.

Licensing – URL Filtering is subscription based, and is part of the Forefront TMG Web Security Service license (together with the Malware Inspection updates).

The small (but important) things

As this is a high-level overview of the feature, we will not dive into all the small details that make for a complete, rich user experience. We will cover some of those in subsequent posts, as we go along. But here are few examples for flexibility you are likely to need/want when working with URL Filtering:

- You can locally override a URL category

- You can query for a URL's category in the TMG UI

- You can customize the block page displayed to end-users, introducing your own HTML tags into the text area.

- You can leverage URL Filtering for ad blocking

- You can use the build-in TMG scripting capabilities to allow non-TMG administrators to locally override a URL (enabling advanced help-desk scenarios)

- You can use URL Filtering related reports to figure out how your organization uses the Internet (which are the top browsed categories for instance)

- You can report classifications issues to Microsoft (this one is not available in Beta3)

A sneak peek at the UI

TMG Web Access Wizard allows you to easily introduce URL categories into your policy:

This is how the policy may look like after completing the Web Access Wizard (viewed from the Web Access Protection node). Note that URL Categories are standard TMG network objects, so you can use the toolbox on the right to drag-drop additional categories into an existing rule, or to create new rules.

You can query for a URL's category (available as a task in the Web Access Protection node)

You can locally override a URL's category (available as a task in the Web Access Protection node)

You can customize the block page presented to end users, introducing your own HTML tags (this is a per-rule setting available from the ‘Action’ tab of the rule’s properties)

Wrap-up

Thanks for reading all the way! I hope you have found this post helpful. We are certainly interested in your comments and thoughts!! Feel free to post them below.

Author:

Dotan Elharrar, Program Manager, Forefront TMG

 

Reviewers

Yair Geva, Senior Development Lead

Vladimir Holostov, Senior Program Manager Lead

Nathan Bigman, Content Publishing Manager

Bill Jensen, Senior Product Manager

Yigal Edery, Principal Group Program Manager

David B. Cross, Product Unit Manager

Forefront TMG Beta 3 is Released

Hi Everyone:

Our third and final planned beta is upon us and I am proud to announce that Forefront TMG Beta 3 is not only feature complete, but it is publicly available for everyone to download.  This is an important milestone for the team as we are for the first time publicly previewing our integrated URL filtering capability in TMG using the Microsoft Reputation Services (MRS).  This completes our feature set and value proposition for the secure web gateway (SWG)aspect of this release and we look forward to the feedback from the community around this integration.  We have started already announcing some our partnerships and agreements for MRS and URL filtering.  One such example is the BrightCloud agreement announced last week.  There will be a follow-on blog in detail about URL filtering and MRS from Dotan in the team.  With this final addition, we are pretty excited about the overall value proposition for customers large and small to benefit from such a rich set of threat management and protection capabilities all integrated with the Microsoft security, identity and management infrastructures.

So, what else is new with Beta 3?  First and foremost, we have an all new Setup Preparation Tool which installs the prerequisites for TMG and should introduce a much more reliable and simplified experience for installing the product for the first time.  With this beta will also be introducing both our Standard Edition and Enterprise Edition SKUs with the differentiated feature sets.  We will enable easy migration from both ISA 2006 customers as well as TMG customers that want to move or upgrade from SE to EE at a later time. In Beta 2, we did not support workgroups, so in Beta 3 we have re-introduced this capability and are also introducing the capability for running and testing TMG on the Windows Server 2008 R2 platform.   We plan on fully supporting both Windows Server 2008 and Server 2008 R2 when we release later this year.

I think everyone will find that there is also a lot of what we call "fit and finish".  We have implemented a lot of polish and fixes based on your bug reports and feedback.  We have made a number of performance enhancements to the overall system and we are looking for customer feedback on how the system performs under your workloads and environments.  We won’t have capacity and planning tools until closer to our actual release date, but we are collecting a lot of data and we would love to hear from you on your testing and requirements as well as your target hardware profiles to help us develop the best possible guidance.  In addition to performance, we have added additional coverage with our Network Inspection System.   Wait for a future dedicated blog entry on our NIS enhancements that we are announcing with this beta.

Also in the new functionality area, we are introducing SSL VPN functionality through SSTP (Secure Socket Tunneling Protocol) support in this beta.  This has been something long requested from the community and we are excited to finally preview the functionality natively integrated into TMG.  Some other interesting surprises based on community request that will first appear in this beta is rule set grouping and search capabilities integrated into the user interface – this is something that we implemented as a direct result from the beta feedback program.  This may not be a surprise for those of you who we met at TechEd, but for many of the ISA fans out there, I think you will find this functionality long overdue.  So we can fully integrate our secure email solution with Exchange Edge Server with Exchange 14 beta and Exchange 12 SP1, we are introducing our first capabilities around the Windows PowerShell.  We are only introducing read only support with PowerShell so we can get community feedback in this area.  We look forward to hearing from you.

We had an overwhelming 11,000+ downloads of Beta 2 and we received even more great feedback on live deployments in your environments.  Please take a look at what we have polished and added with Beta 3 and we look forward to hearing what you think.  The download is available now on our download center and I invite you to install and test in your environment today: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=e05aecbc-d0eb-4e0f-a5db-8f236995bccd.

 

David B. Cross

Product Unit Manager

 

Posted by isablog | 6 Comments

Filed under: Threat Management Gateway, Forefront TMG, TMG Beta 3, Beta 3

FWC Parser for Netmon 3.3 on CodePlex

Anyone who has spent any time at all with ISA Server or Forefront TMG has found themselves needing to evaluate the network traffic generated by the ISA Server Firewall client (TMG client for Forefront TMG). The problem with that effort is that none of the available network capture tools included a parser for this traffic.

Today that changes.  In collaboration with the Network Monitor and Forefront Edge Core teams, the Forefront Edge CS team is happy (little-girl-giggly, truth be told) to announce the public availability of a parser written specifically for Network Monitor 3.3. Now you can actually understand what happens between the client and the firewall when your favorite application is misbehaving. You can obtain the parser from CodePlex. The parser provides two new protocols for Network Monitor 3.3:

·         RWS (Remote WinSock): the control channel protocol used between the client and firewall

·         WSP (WinSock Proxy): the abstracted application protocol

Look for additional articles that describe this traffic and offer some hints on using the parser for troubleshooting.

 

HUGE Thanx to the Network Monitor and Forefront Edge Core teams for their support – we literally could not have done this without them!

Jim Harrison
PM FF Edge CS

ISA BPA 7 and Forefront TMG for Windows Essential Business Server

If  you are running Forefront TMG for Windows Essential Business Server (EBS) and you have problems you may find it useful to use the ISA Best Practices Analyzer version 7 (announced earlier in the blog post http://blogs.technet.com/isablog/archive/2009/05/06/announcing-the-availability-of-isa-tmg-best-practices-analyzer-version-7.aspx) and more specifically the ISA Data Packager which is able to gather diagnostic data while reproducing a problem.

 

More specifically you may want to have a look at the Firewall and Webproxy log files created when reproducing the problem. If your server is running in production the log snippet may contain a lot of clients going through TMG. So you load the file into for instance Excel to be able to filter the data in the file.

 

Then you start looking at the IP addresses to find the log entries you are interested in… which look kind of interesting, here’s an example:

 

c0a8b12c-ffff-0000-0000-000000000000

 

The format is IPv6 but you are not running IPv6 as Forefront TMG for EBS is not supporting it… so what is it? It is an IPv4 address in the shape of a IPv6 address and the reason for this is to prepare for future IPv6 support although Forefront TMG for EBS do not support IPv6 currently. The logging query function in the Forefront TMG MMC as well as the Reporting engine converts these addresses to IPv4 format, the issue does only occur when extracting log data directly from the database.

 

You can convert the IP address to “classical IPv4” as follows, take the first eight characters in the address and convert from hex to dec using for instance Calculator as follows:

 

c0 = 192

a8 = 168

b1 = 177

2c = 44

 

resulting in the IPv4 address 192.168.177.44.

 

If you would like to do this programmatically when querying the logs yourself you can use this SQL function.

 

NOTE: This function is provided as-is without expressed or implied warranty. Use at your own risk.

 

CREATE FUNCTION [dbo].[fnIpAddressToText]

(

    @Ipv6Address [uniqueidentifier]

)

RETURNS varchar(40) AS

BEGIN

    DECLARE @strInAddress varchar(40)

    DECLARE @strOutAddress varchar(40)

    SET @strInAddress = LOWER(CONVERT(varchar(40), @Ipv6Address))

    SET @strOutAddress = ''

 

    IF (SUBSTRING(@strInAddress, 10, 4) = 'ffff')

    BEGIN

        -- ipv4 (hex to int conversion)

        DECLARE @IsNum int, @ZERO int, @IsAlpa int

        set @ZERO = ASCII('0')

        set @IsNum = ASCII('9')

        set @IsAlpa = ASCII('a') - 10

        DECLARE @intH int, @intL int

 

        SET @intH = ASCII(SUBSTRING(@strInAddress, 1, 1))

        IF (@intH <= @IsNum) SET @intH = @intH - @ZERO ELSE SET @intH = @intH - @IsAlpa

        SET @intL = ASCII(SUBSTRING(@strInAddress, 2, 1))

        IF (@intL <= @IsNum) SET @intL = @intL - @ZERO ELSE SET @intL = @intL - @IsAlpa

        SET @strOutAddress = CONVERT(varchar(3), @intH * 16 + @intL) + '.'

 

        SET @intH = ASCII(SUBSTRING(@strInAddress, 3, 1))

        IF (@intH <= @IsNum) SET @intH = @intH - @ZERO ELSE SET @intH = @intH - @IsAlpa

        SET @intL = ASCII(SUBSTRING(@strInAddress, 4, 1))

        IF (@intL <= @IsNum) SET @intL = @intL - @ZERO ELSE SET @intL = @intL - @IsAlpa

        SET @strOutAddress = @strOutAddress + CONVERT(varchar(3), @intH * 16 + @intL) + '.'

 

        SET @intH = ASCII(SUBSTRING(@strInAddress, 5, 1))

        IF (@intH <= @IsNum) SET @intH = @intH - @ZERO ELSE SET @intH = @intH - @IsAlpa

        SET @intL = ASCII(SUBSTRING(@strInAddress, 6, 1))

        IF (@intL <= @IsNum) SET @intL = @intL - @ZERO ELSE SET @intL = @intL - @IsAlpa

        SET @strOutAddress = @strOutAddress + CONVERT(varchar(3), @intH * 16 + @intL) + '.'

 

        SET @intH = ASCII(SUBSTRING(@strInAddress, 7, 1))

        IF (@intH <= @IsNum) SET @intH = @intH - @ZERO ELSE SET @intH = @intH - @IsAlpa

        SET @intL = ASCII(SUBSTRING(@strInAddress, 8, 1))

        IF (@intL <= @IsNum) SET @intL = @intL - @ZERO ELSE SET @intL = @intL - @IsAlpa

        SET @strOutAddress = @strOutAddress + CONVERT(varchar(3), @intH * 16 + @intL)

    END

    ELSE

    BEGIN

        -- ipv6

        SET @strOutAddress = @strOutAddress + SUBSTRING(@strInAddress, 1, 4) + ':'

                                        + SUBSTRING(@strInAddress, 5, 4) + ':'

                                        + SUBSTRING(@strInAddress, 10, 4) + ':'

                                        + SUBSTRING(@strInAddress, 15, 4) + ':'

                                        + SUBSTRING(@strInAddress, 20, 4) + ':'

                                        + SUBSTRING(@strInAddress, 25, 4) + ':'

                                        + SUBSTRING(@strInAddress, 29, 4) + ':'

                                        + SUBSTRING(@strInAddress, 33, 4)

    END

    ---- guid sample '6F9619FF-8B86-D011-B42D-FFF34FC964FF'

    RETURN @strOutAddress

END

 

Anders Janson

Senior Support Engineer

Microsoft CSS Forefront Edge Team

 

 

IPSec Domain Isolation Using ISA Server Updated and Reposted

The IPsec Domain Isolation article that was originally announced here has been rewritten and reposted here.
Feel free to comment and critique.

Jim Harrison
PM, FF Edge CS

 

A Few Words on the TMG Firewall Client

One of the more common questions I have heard recently from customers is: “Do I need to deploy the new TMG Firewall Client (FWC) to interoperate with TMG on down-level clients?”  The very simple answer is no.  The previous versions of the (ISA) firewall client work just fine with TMG and accordingly, the TMG FWC will interoperate with ISA Server. 

So why does a customer choose to deploy the FWC in the first place?  First of all, the FWC is an optional desktop software component that basically provides enhanced security and application support.  Most specifically, the FWC supports the following:

·         Strong user authentication for all Winsock applications using the TCP and UDP protocols

·         Enables user identification and application information to be logged in the ISA/TMG logs and reports

·         Supports per-user based policies and rules

·         Enables applications that require secondary network connections to access the Internet through the proxy

So what is new with the TMG firewall client?  What are the benefits over the previous version?  There are really two key updates that will be available with our upcoming Beta 3 release:

1.       Secure auto-discovery using Active Directory – improved discovery of the approved proxies in your enterprise

2.       HTTPS inspection notification – enabling end users to control the notification of when their Internet traffic and browsing will be monitored and controlled by policy through the TMG proxy

Watch for more updates and information as we are getting ready to announce the availability of Beta 3 publicly.

 

David B. Cross

Product Unit Manager

 

Fun with ISA Server and AES Cipher Suites

“AES” stands for “Advanced Encryption Standard”; a symmetric encryption algorithm used in several encryption schemes, such as FIPS-197. http://csrc.nist.gov/archive/aes/index.html provides links to detailed discussions of AES.

1.       Netaction Encryption Guide article

2.       NIST FIPS-197 article

3.       Microsoft Knowledgebase article 246071 Description of Symmetric and Asymmetric Encryption

4.       Microsoft Knowledgebase article 948963 Update to add two AES cipher suites to Windows Server 2003

5.       Microsoft Knowledgebase article 922706 How to use Certificate Services Web enrollment pages with Windows Vista or Windows Server 2008

6.       Microsoft Developer Network article Microsoft Cryptographic Service Providers

7.       Microsoft Developer Network article Microsoft AES Cryptographic Provider

8.       Microsoft Developer Network article AES Provider Algorithms

AES was initially offered in Windows XP WPA2 updates and later in Vista and Windows Server 2008 as part of the improved cipher suites.  These same encryption algorithms may be used to create the public and private keys used to sign certificates as well, which brings us to the point of this article – certificate keys generates using AES cipher suites.

 

Anyone who has used ISA Server to publish a secure Web application has become familiar with the necessity for obtaining and installing a certificate suitable for server authentication. The methods available for acquiring a certificate suitable for use in the Web listener vary greatly.

Some folks like to use the command-line tools certreq and certutil, while others prefer to use the certificate enrollment pages offered by Windows Certificate Services, and still others will opt for a popular open-source tool, such as SelfSSL. The point is that you must create a certificate that meets the following criteria:

1.       The issuing CA certificate is stored in the local computer Trusted Roots store

2.       Enhanced Key Usage includes Server Authentication (1.3.6.1.5.5.7.3.1)

3.       Key Usage includes Digital Signature, Key Encipherment

4.       Subject or Subject Alterative Name includes a name appropriate to the URL used by the client

When you install the certificate, you must satisfy the following criteria:

1.       The certificate is stored in the local computer Personal store

2.       The private key is stored in the Local computer Personal store

The ISA Server 2006 Supportability Update (included in Service Pack 1) allows ISA Server to validate all of these requirements and will generate alerts when any of them are not satisfied. One thing ISA does not do until it actually tries to use the certificate through CAPI is to validate that the encryption keys are usable; in other words, that they can be used to sign and encrypt data. This is where the fun begins. 

By default, Windows Server 2003 cannot use AES-based encryption so any certificate key that is created using AES-based cipher suites will generate certificate access errors for the application that is trying to use the certificate.  If you’re not paying attention to this difference when you request the certificate, you could generate a certificate that appears perfectly functional for the intended purpose, but will actually cause a failure when ISA Server attempts to apply the policies because Windows Server 2003 cannot process AES-based ciphers.

If you obtain your certificate from a Windows Server 2008 Certificate Authority enrollment web site, you have the ability to select the Cryptographic Service providers (CSP) for use in the private key. If you connect using a Windows XP or Windows Server 2003 host, the CSP provided by default is the Microsoft Enhanced Cryptographic Provider v1.0 as shown in Figure 1.

 

Figure 1 Default CSP for Windows XP and Windows Server 2003 clients

If you connect using a Windows Vista or Windows Server 2008 client, the default CSP chosen will be Microsoft Enhanced RSA and AES Cryptographic Provider as shown in Figure 2.

Figure 2 Default CSP for Windows Vista and Windows Server 2008 clients

The upshot of this is that if you:

1.       requesting a certificate from the Windows Server 2008 certificate enrollment pages

2.       connect using a Windows Vista or Windows Server 2008 computer

3.       accept the default CSP

..the certificate will not usable at a Windows Server 2003 computer that does not have the patch offered by MSKB 948963.

 

If you install a certificate that uses AES-based CSP on an ISA Server, you will encounter startup or policy application failures when ISA Server attempts to apply the policy updates to include the new certificate, as shown in the following examples:

Figure 3 ISA Server Standard Edition Certificate Access Error

Figure 4 ISA Server Enterprise Edition Certificate Access Error

You should notice that the common point between these two events is that they both indicate the same error code; 0x030d. ISA Server Enterprise Edtition translates the CAPI error code 0x8009030d to a WINERR 0x8007030d, but they're the same lower-level error. This error resolves to SEC_E_UNKNOWN_CREDENTIALS, which in this case means “CAPI couldn’t process the private key”.

 

Unfortunately, you can’t use the certificates MMC to determine if an AES CSP is the cause of the certificate failure. Fortunately, the Windows security team saw fit to include a nice command-line tool that will tell you quite a lot about your certificate storage called certutil.exe. The syntax you would use to examine the certificates contained in the local computer Personal store is certutil -store my. The following provides an example of two certificates located in the local computer Personal store that were created using identical criteria except for the CSP:

When you select the certificate listed as “Certificate 0” for use in an ISA Server Web listener, if the ISA Server does not have the patch offered in MSKB 948963 installed, it will fail to use the certificate and generate alerts and event log entries indicating SEC_E_UNKNOWN_CREDENTIALS errors. When you select the certificate listed as “Certificate 1” in the certutil output, ISA Server will use the certificate normally. It's worth noting that although certutil indicates "encryption test passed", this does not mean that it actually used the keypair to encrypt & decrypt anything with them. What certutil does is validate that the oldest (most commonly available) cipher is usable for encryption. This means that in the case of the RSA / AES cipher, AES is skipped.

 

You can solve this problem in a couple of ways:

1.       Ensure that your certificate request specifies a CSP that does not include AES ciphers

2.       Install the patch offered in MSKB 948963

The problem is a bit obscure if you’re not fully conversant with CAPI error codes and since it took me the better part of the day to sort out all the various aspects of the problem, I thought it might be useful information for the larger ISA community.

HTH, 

Jim Harrison, Program Manager, FF Edge CS

 

Reviewers

Avi Ben-Menahem, Principle Group Program Manager, FF Edge

Yuri Diogenes, Sr Support Engineer, CSS Security

Mohet Sexana, Technical Lead,  CSS Security