Exercising NIS with test signature

One of the new features in TMG Beta2 is Network Inspection System (NIS) component of TMG Intrusion Prevention System. NIS is a protocol decode-based traffic inspection system that uses signatures of known vulnerabilities, downloaded from the Microsoft Malware Protection Center, to detect and potentially block attacks on network resources. By blocking malicious traffic at the firewall, you can protect internal systems without the latest patches.

NIS transparently inspects all traffic that passes through TMG, and as such its action usually goes unnoticed until an attack is detected. One doesn’t have to wait for a real attack to see NIS in action. NIS ships with a few test signatures which can be triggered by specially crafted network traffic to illustrate NIS user experience. Administrators are encouraged to try these test signatures, since they allow verifying that NIS is deployed properly, as well as experiencing the typical attack detection, both from the user and from the administrator perspective.

First, we’ll find the HTTP test signature in the TMG UI (IPS -> NIS tab). Select the Intrusion Prevention System node, and locate the Plcy:Win32/NIS.Signature.Test!0000-0000 signature (grouping signatures by protocol or by category simplifies this task):

Let’s verify the status and response of the signature - in this test we’d like it to be enabled and its response to be Block (meaning the connection attempt will be blocked, as opposed to just logging the incident). Double-clicking the entry in the list brings the properties of this signature:

Note the description - it tells us how to trigger the test signature. This particular signature is for HTTP traffic, and it detects HTTP requests sent to http://www.contoso.com/ (non-existent test web site) with the strangely looking URL above. We can send the request from any client machine in the internal network that goes out to the Internet through this TMG box (either transparently as a default gateway, using Firewall Client aka TMG Client or with explicitly configured Proxy in the Web Browser’s connection settings).

All we need to do is to point the browser to the suggested URL:

The attempt is blocked by TMG and the error message reflects this. If this doesn’t work as expected, the most common possible reasons are:

  1. NIS is not enabled in TMG. See "Configure Settings" task under the IPS node.
  2. The HTTP request is not sent through this particular TMG machine. Check the browser proxy configuration and that the particular browser machine is not excluded from NIS inpection. You can verify that Web traffic from the browser’s machine is logged by TMG.
  3. The query part of the URL in the address bar is not complete and does not match the test signature.

The incident is logged by TMG (an alert is also raised):

Under the covers

Here are some technical details about NIS and the detection mechanism of this signature.

NIS performs inline inspection of all network traffic that passes through TMG, including HTTP. HTTP traffic is parsed by NIS similar to how it would’ve been parsed by the endpoint (web server).

In the process of HTTP analysis the values of the URL field, its query string and the “Host” header are extracted from the request. The test signature looks at the “Host” header and the URL query part, at a specific state; if they match the predefined values, NIS raises the “Signature match” event. If the signature response is “Block”, TMG will not forward the traffic, but will instead abort the connection sending the error response page to the client.

Though the test signature is quite simple, the same process applies to other protocols inspected by the NIS in TMG, among them DNS, RPC, SMB and mail protocols.



  • Evgeney Ryzhyk, Software Engineer, Forefront TMG


  • Moshe Golan, Program Manager, Forefront TMG
  • Alex Reicher, Software Engineer, Forefront TMG
  • Gabriel Koren, Test Team, Forefront TMG
  • Eli Pozniansky, Software Engineer, Forefront TMG

Comments (3)

  1. Anonymous says:

    Hello Community: I first wanted to thank everyone who came to our session(s) – with Yigal and myself,

  2. Anonymous says:

    I really love this feature! Good work!

    One thing that could be better is the user-experience and the Network Access Message. Why not have a more clearly message like “<sitename> is not a safe web site because of…”.

    Or make it easier to create your own user-message.

    In this way you get a more satisfied and informed end-users

    Best regards,


Skip to main content