I finally had a chance to test drive the beta version of the upcoming Forefront Security release specifically for Office Communications Server 2007 (FSOCS). I deployed this in my lab, co-locating it on an existing Standard Edition server in an internal network segment.
To download the public beta release:
Forefront Security for Office Communications Server 2007 Beta
Before installing, I recommend reading through the TechNet documentation:
Microsoft Forefront Security for Office Communications Server
Create a new domain account for the RTC Proxy service to run under, and as per the install instructions configure the following:
- Grant the Logon As Service right to the account on the server’s Local Security Policy.
- Add the domain account to the server’s local RTC Server Applications group.
- Add the domain account to the domain groups RTCUniversalServerAdmins and RTCProxyUniversalServices.
After the installation completes, launch the Forefront Security Server Administrator (FSSA) console from All Programs. The console is unfortunately not an MMC snap-in but is fairly straightforward. It’s broken up into four main sections: Settings, Filtering, Operate, and Report.
The documentation states that the scan engines should automatically begin to update 5 minutes after the service starts, but to avoid some potential errors in the ProgramLog.txt file it is recommended to manually download at least one update.
I went ahead and manually updated all nine engines, just for good measure.
I didn’t mess around with many of the General Options, but I did later adjust one: the IM Process Count setting under the Scanning group. By default it was set to 4 and I noticed that each instance was taking up about 150-170MB of RAM. After dropping this value to 2 (valid choices are 1-10) FSOCS is using up half the memory it was before. In a production deployment a higher number of process engines would increase scanning performance, but only based on the amount of available RAM in the server.
Natively OCS supports filtering IM conversations only for URLs and file transfers by file extension. But without third-party applications or some extensive custom coding, there was no way to filter or block messages by keyword matching. FSOCS introduces keyword filtering, content filtering, and a more granular control of file transfers. It also supports defining safe sender lists by domain which can be omitted from content filtering, but will always still apply to all virus scans.
FSOCS includes sample keyword lists for content filtering of profanity, which can be installed manually by executing the KeywordInstaller.msi package located in the program installation directory (the default is C:Program FilesMicrosoft Forefront SecurityOffice Communications Server). A number of languages are included.
After installing the package, the files will be located in DataExample Keywords in the same parent directory as listed above. I highly recommend browsing the list for a good laugh; I bet that was an interesting day at work brainstorming that list. I suppose one could pick up some [questionable] foreign language skills as well. Anyway, this file can then be imported into a Filter List, which I labeled Profanity. I also created another filter list and added just the single keyword "chicken", as I didn’t see anything in the provided word list tame enough to take screen shots of.
From the Keyword section, I enabled both Filter Lists, set the Action to Identify: tag message/file, and checked Notify Admin/Sender. You can select different directions of communications between internal, inbound, or outbound directions.
As you can see, the IM containing the filtered keyword (chicken) was blocked in the recipient’s window:
The offending sender also received an IM from the service account with a summary of the filtered message:
Also, under Scan JobSettings, there are buttons to change the Deletion and Tag text seen by intended recipients of infected files and blocked messages. The default "Message has been blocked" entry can be customized:
By enabling the native file extension filtering within OCS, and attempt to send a file with an .EXE extension is immediately blocked, and sender never even sees the transfer attempt in their IM window.
Although .EXE files are filtered by default in OCS (if Intelligent IM Filtering is enabled) there are a different set of file extensions in FSOCS. From the interface alone it doesn’t appear that you can customize the file types list, but I haven’t dug into the documentation far enough to figure out if that is the case. To test it, I enabled a file extension that was not currently filtered by OCS:
But when a file extension is blocked by FSOCS which is not already covered by the Intelligent IM Filter, the sender sees a different message when attempting to transfer that file type.
I’m not to sure what the benefit would be to using file filtering in FSOCS over the native OCS filtering, as even the notifications are less informative to the end user; it’s more clear that the content was blocked instead of it just looking like a general failure.
The only component in this section simply shows the status of the built-in "IM Scan Job" and has options to bypass or enable the scan, as well as export or clear the incidences log.
As you can see from the most recent entry on the list, a virus was detected and removed. Let’s look at how that appears to the end users. During a normal file transfer, the process looks identical as the virus scanning is performed on the back-end, transparent to the users:
This time when I send an infected file it appears to transfer correctly on the sender’s side, but the recipient is presented with an error as the file has been blocked and was promptly quarantined or deleted by FSOCS.
This section allows for notifications to be enabled/disabled and the message content customized. It also contains any quarantined messages or files and there are options to export or allow delayed delivery of the blocked messages.