In this post, I show you how to block users from playing YouTube videos on your network. I also show you how to block Flash content embedded on web pages (although in today’s times blocking all Flash content may not be such a good idea )
Yes you could always block the URL youtube.com but this may not be effective as YouTube videos can be embedded in other websites and there are plenty of sites *like* YouTube out there. A more effective approach would be to block by MIME type, thanks to the enhanced content filtering capabilities built into TMG.
Before I get started, two important notes:
I mention YouTube because it is everyone’s favorite, but the steps below will work for Vimeo, and any other video sharing sites that rely on Adobe Flash technology.
The steps below can be used to block YouTube and flash content on ISA Server 2004/2006 too.
Blocking YouTube videos using TMG
1. On the TMG Console, right-click Firewall Policy, choose New Access Rule and create a new “Deny” rule named “Block Youtube” as follows:
Applies to: All Outbound traffic
Click Finish to close the wizard.
2. Do not apply the changes yet! Right click on the new rule you just created and choose Properties.
3. Open the Content Types tab. Click New.
4. Create a new Content Type Set as follows:
Available types: (type each of the below and click the Add button)
5. Click OK. Ensure the check box next to your new content type set is enabled:
6. Click OK and apply your changes. Wait for the config synchronization to complete.
Test your changes by trying to play some videos on YouTube or other video sharing websites.
Blocking Adobe Flash Player content using TMG
1. Follow steps 1 to 3 above.
2. While creating a new Content Type set, use the following parameters:
In the available types box, type:
3. Proceed with step 5 above.
Blocking additional MIME types
If you need to block something else, it is easy to find what content type to block. Simply monitor the Logging (Logs & Reports > Logging) in the TMG console. Once you encounter the log entry that allowed the content you want to block, expand the “Additional Information” and you will find the MIME type that you need to block.
What is Forward HTTPS Inspection or Outbound HTTPS Inspection?
In ISA Server 2004/2006, we had Inbound HTTPS inspection, which we are familiar with by the name “SSL Bridging”. SSL Bridging or Inbound HTTPS inspection is used to protect published web servers from malicious requests originating from the Internet/external network. In essence, the ISA Server had the same SSL certificate that the web server had, along with its private key. When an HTTPS request reaches the ISA Server, it decrypts the request using the certificate and inspects it. If it is found to be safe, the ISA Server establishes another SSL session between itself and the published web server.
SSL Bridging was an excellent piece of technology for inspecting inbound HTTPS traffic, but ISA Server did not have a feature to inspect “outbound” HTTPS traffic.
Okay – so what’s Outbound HTTPS Inspection?
Outbound HTTPS traffic refers to the HTTPS requests originating from the internal network to the Internet, (for example, user’s internet browser). Why is this required? Often blocked websites or services can be accessed through an HTTPS session because the proxy servers do not have visibility of the content that is passing inside the HTTPS session.
This is often the technique used by many anonymizers, P2P software, and applications like Skype to evade being blocked by a proxy server. More dangerously, it is often used by modern malware to pass undetected between your internal network and the internet, as your edge security products simply cannot see what’s inside the SSL.
So, how does HTTPS Inspection work? I’m putting it down in *very* simple terms below:
1. TMG Server has an SSL CA Certificate on it (can be self-generated or from Active Directory). However, all client computers in your internal network must trust TMG’s HTTPS Inspection certificate.
2. User’s computer tries to access an HTTPS website (or other HTTPS content) on the Internet.
3. TMG does not blindly “proxy” the request to remote HTTPS server. Instead, TMG Server acts like a client and talks to the remote HTTPS website.
4. TMG validates the site’s certificate, copies the details of that certificate and creates a new SSL certificate with those exact same details and signs it with its own CA Certificate. It then returns this certificate to the internal client.
Since TMG pretends to be the client to the remote server, it gets to decrypt the content sent back and perform malware inspection and policy based filtering on the content returned.
5. What you get here is two different tunnels, one from TMG to the remote HTTPS server and another from TMG to the internal client – a perfect “man-in-the-middle attack”. I like to call it the “good-man-in-the-middle attack”. With the connection being “cut” into two different tunnels, TMG server can decrypt, inspect and re-encrypt all communication between the client and the remote HTTPS server.
Let’s now roll up our sleeves and see how to turn on HTTPS inspection.
Right click on Web Access Policy. Choose “Configure” > “HTTPS Inspection”
Choose “Enable HTTPS inspection”
You can choose to Inspect traffic and validate site certificates (recommended).
Under the HTTPS Inspection Certificate settings, you have two options – Use TMG to generate a certificate or Import a certificate already issued by your Enterprise Root CA trusted by your organization or issued by a third party certificate. In either case, all client computers in your network MUST trust the CA certificate.
If you used Forefront TMG to generate the certificate, make sure you save the CA certificate in the Trusted Root CA store on all your computers. You can automatically deploy the certificate by clicking on the HTTPS Inspection Trusted Root CA Certificate Options button. You will need domain administrator credentials.
It has never been easier to block instant messaging (IM) with Forefront Threat Management Gateway (TMG). If you’ve read my article that I wrote a couple of years ago on how to block IM protocols on ISA Server, you’ll definitely appreciate the ease with which you can do the same stuff more effectively with TMG.
In this post, I show you how you can block Skype, Google Talk, Yahoo Messenger, Live Messenger, etc using Forefront TMG 2010.
Before I go in to the step-by-step procedure, I want to highlight what’s happening in the background.
Microsoft Forefront TMG 2010 now comes with URL Filtering. URL filtering enables you to block web content belonging to a particular category such as Chat, Social Networking, or Pornography.
These are the two new features that we will leverage to block chat. Here is a summary of what we will do:
The only allowed traffic on your TMG server is regular web traffic (HTTP and HTTPS). I am against creating “generic” rules like “allow all” from internal to external when you have SecureNAT clients in your network as this defeats the purpose of filtering.
Turn on HTTPS inspection. Read my earlier post if you need help enabling HTTPS inspection.
In a “Deny” rule on your Web Access Policy, add the “Chat” URL category.
Why do you need HTTPS inspection?
Many IM clients and software like Skype, try to connect using dynamic UDP ports and eventually fail back using HTTPS. With HTTPS inspection turned on, TMG will be able to inspect inside HTTPS to see if the software is trying to request access from a blocked URL.
1. In the Forefront TMG console, locate your Web Access Policy that denies traffic. If you do not have one, right click on Web Access Policy in the left pane and choose Configure Web Access Policy.
2. Click on the “To” tab. Click the Add button.
3. Expand URL Categories. Add the “Chat” URL category to the list.
4. Click OK and Apply your changes. Wait for the changes to synchronize (Tip: you can verify this under Monitoring > Configuration)
Now for the best part: try connecting to Skype, or any of your favorite instant messaging software. Note that the web versions of these messengers are also blocked!
On a closing note – you can use the same technique to block P2P (peer-to-peer) and file sharing applications like eMule, Kazaa, eDonkey, BitTorrent, etc using TMG. In step 3, choose “P2P/File sharing” URL category.
How to enable and configure Malware Inspection in TMG
Web traffic may contain malware (such as worms, viruses, and spyware). Microsoft Forefront Threat Management Gateway (TMG) includes malware inspection for scanning, cleaning, and blocking harmful HTTP content and files. When malware inspection is enabled, downloaded Web pages and files allowed by access rules may be inspected for malware.
Malware inspection is performed by the Malware Inspection Filter (Web filter). Malware inspection applies to traffic that uses the HTTP protocol and does not involve the Firewall Client software.
The body of all HTTP requests and responses is inspected, regardless of the HTTP verb in the header. If the body is compressed and the encoding scheme is not recognized, Forefront TMG cannot inspect the content. HTTP content compressed with gzip encoding can be decoded, inspected, and encoded in both directions.
In this post, I will explain how to enable malware inspection and also explain the user experience when this feature is enabled.
1. Enable Malware Inspection on the server
Malware Inspection requires a special “subscription license” (per user, per year). The first time you install TMG, you can enable Malware Inspection time-based trial for free. You can check if Malware Inspection is enabled and check the status by navigating to the “Update Center” option in TMG console. You can also check if the signature updates are getting installed.
2. Configure Malware Inspection
Merely having Malware Inspection filters will not protect your users unless it is turned on and configured. To configure Malware Inspection, open your Web Access Policy and click on Configure Malware Inspection on the Tasks pane.
Ensure that the Enable malware inspection checkbox has been enabled.
In the above dialog box, you can also configure exceptions, definition updates and licenses.
An important option that you can configure here is to choose between “standard trickling” and “fast trickling”. “Trickling” refers to the process in which the file is transferred to the user after/while being scanned for threats.
Standard Trickling: TMG keeps most of the file, but sends small parts of it to the client to keep the connection alive.
Fast tricking: TMG sends the file as fast as possible to the user, holding back the last part till the whole file is scanned. The user “perceives” better performance, although the TMG server needs more resources in this method.
You can also choose “Progress Notification” method for some file types so that TMG presents a scanning progress notification message in the browser before letting the user download the file. This is done by clicking “Content Types for Progress Notification”.
Notice in my example, the PDF file type is configured for Progress Notification.
3. Enable Malware Inspection on your rules
You also need to enable malware inspection in the applicable Web Access policy rules and Firewall policy rules. To enable Malware Inspection on an “allow” rule, right click on the rule and choose properties
Ensure “Inspect content downloaded from Web servers to clients” and “Force full content requests” is checked.
You can have more control on the malware inspection by enabling to “use rule specific settings for malware inspection”. Then click on the Rule Settings button.
Click OK all the way out and save your configuration. It might take a while till your configuration is synchronized. (This can be verified at Monitoring > Configuration)
Once the rule is applied, try downloading a file on a Web proxy client. TMG presents a scanning status message on the browser.
Once the scanning is complete, the user is allowed to download the file.
If the file contained a virus, the user is shown a warning message and access to the file is blocked.
Malware Inspection is a brand new feature in TMG and I’m sure you will find this feature very exciting. Feel free to post your comments below.
Most anti-virus solutions provide tamper protection mechanisms to prevent the users from disabling the Forefront Client Security software on their machines. Forefront Client Security only provides basic control over what the user can do with the FCS client console.
In order to further increase the tamper-protection measures, users should be prevented from stopping the FCS service or uninstalling the software from the machines.
Both of the above can be achieved by not providing administrative privileges to the users, but there are instances where the users may need to be local administrators on their machines. Under such circumstances, the following can be done:
Use Group Policy to protect the FF client services so that only a few selected accounts can stop these services. The service to protect is the "Microsoft Forefront Client Security Antimalware Service". Additionally, protecting the "Microsoft Forefront Client Security State Assessment Service" won’t hurt.
Change permissions in the registry for uninstalling FCS. HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionUninstall
This can also be done using Group Policy.
Both of these steps are described in detail over at the Security Wizard blog.
I thought I’d share this great video by Jim Harrison on considerations to make when planning to run Microsoft Forefront Threat Management Gateway (TMG) (or ISA Server, for that matter) on a virtualized environment.
In this video, he discusses:
Performance, security and management considerations
Why it’s not recommended to place TMG on the parent, and how to configure the parent partition
High Availability with TMG in a virtual environment
I am excited to write about the latest anti-spam comparative test results from VirusBulletin. Forefront Protection for Exchange emerged as the winner in the May 2010 test results, with an extremely high spam catch (SC) rate and a very low false positive (FP) rate.
SC rate: 99.93%
SC rate (VB corpus): 97.35%
SC rate (image spam): 99.77%
SC rate (large spam): 99.90%
FP rate: 0.23%
FP rate (VB corpus): 0.79%
Final score: 99.25
[SC=Spam Catch rate; FP=False Positive rate]
Quote from the report:
Microsoft’s Forefront Protection 2010 for Exchange Server was the clear winner of the last test, achieving the highest final score by some distance. The final scores of the various products were closer this month, but with the second highest spam catch rate and just a handful of false positives,Forefront was yet again the product with the highest final score and adds another VBSpam award to its collection.
McAfee released an antivirus update yesterday that crippled Windows XP computers worldwide. The DAT 5958 update affects only computers running Windows XP Service Pack 3.
Here’s how the SANS Internet Storm Center describes the mess-up:
McAfee’s “DAT” file version 5958 is causing widespread problems with Windows XP SP3. The affected systems will enter a reboot loop and [lose] all network access. We have individual reports of other versions of Windows being affected as well. However, only particular configurations of these versions appear affected. The bad DAT file may infect individual workstations as well as workstations connected to a domain. The use of “ePolicyOrchestrator”, which is used to update virus definitions across a network, appears to have [led] to a faster spread of the bad DAT file. The ePolicyOrchestrator is used to update “DAT” files throughout enterprises. It can not be used to undo this bad signature because affected system will lose network connectivity.
The problem is a false positive which identifies a regular Windows binary, “svchost.exe”, as “W32/Wecorl.a”, a virus.
This is ridiculous if you ask me. The svchost.exe is a crucial Windows binary and just about everyone knows about it. Funny it should identify svchost.exe as a virus! I’ve been told this is the third mess-up from McAfee in a period of 4 years.
If you’re a McAfee customer, I have two recommendations for you:
1. Do not install the DAT 5958 update – block it. Wait for instructions from McAfee.
2. Consider implementing a state-of-the-art antivirus solution, that is more reliable and fares better in the comparative reports.
Microsoft Forefront Client Security is Microsoft’s cutting-edge client security solution which fared well in the VirusBulletin reports and many other studies. For more information, read my earlier post on “Forefront vs. the Competition”.
I was chatting with Tom Shinder this evening when he started an interesting discussion on setting up a Windows VPN connection to use SSTP to connect to the corporate network via Forefront Unified Access Gateway (UAG). This would allow Windows 7 users to connect via SSTP without having to log in to the UAG portal.
So far, we’ve seen it only being done on the UAG Portal – where the user has to log in to the UAG portal and open the Remote Network Access application.
So I fired up my UAG lab VMs to see if this is do-able – and we were successful in getting it to work! Here’s how we did it.
Open the user’s properties in Active Directory Users & Computers. On the Dial-in tab, choose Allow Access under Network Access Permission. Alternatively, you can configure the NPS Network policy accordingly.
On the Windows 7 client machine, create a new VPN connection. (Hint: Network & Sharing Centre –> Set up a new connection or network –> Connect to workplace)
For the newly created connection, set the connection properties as below. The host name will be the same that’s configured on your UAG trunk.
On the Security tab of the VPN connection properties, set the Type of VPN as Secure Socket Tunneling Protocol (SSTP). Select the option to automatically use te Windows logon name and password.