Archive
Relocating SQL Database Files on Forefront TMG 2010
When Forefront Threat Management Gateway (TMG) 2010 is installed, an instance of SQL Server 2008 Express is included for Forefront TMG firewall and web proxy logging. By default, the log database files are installed on the system partition, which is less than ideal. Best practices dictate that log database files should reside on a separate, dedicated partition.
I’ve had many people ask how to move these database files once the product is installed. Most assume that the process involves using SQL database management tools to detach the database and manually move the database files to a new partition. Not true! Since Forefront TMG handles all of the underlying SQL database management, the process is actually quite simple.
To move the log database files, first create a folder to store them in the new location. Next, open the Forefront TMG management console, highlight Logs & Reports in the navigation tree, select the Logging tab in the center console window, then click Configure Firewall Logging in the Tasks pane on the right.
Click the Options… button, then select This folder (enter the full path): and enter the new path to store the log database files.
For EMS-managed or standalone arrays, make certain this path exists on each array member. If it does not, the service will not start. If the folder does not exist, TMG will complain.
Repeat this process to move the web proxy log database files. In addition, it would be an excellent idea to also move the Log Queue Storage Folder. This folder should be located on a partition that is separate from the one used to store the log database files. For optimum availability this will be a separate physical disk, allowing for Forefront TMG to continue logging to the queue even in the event of a physical disk failure where the log database files are stored. As with the log database files, this folder must exist on each array member.
A system variable can be used to specify the path to log database or log queue files. For example, %LOGDRIVE%\FWS, where %LOGDRIVE% can be a different drive letter and path on each array member, if necessary. To create a system variable, open the advanced system properties and click Environment Variables….
Under System variables click New…, enter the variable name (e.g. LOGDRIVE), and specify the location where the log files should be stored on this array member (e.g. D:\TMGLogs). Repeat these steps on each array member, specifying the local path where log database files are to be stored.
Confirm the system variable was created properly by opening a command prompt and entering the following command:
set logdrive
The output for our example should appear as follows:
LOGDRIVE=D:\TMGLogs
Network Egress Filtering and the RSA SecurID Attack
Reading details about the recent attack and compromise at SecurID, I was dumbfounded when I came across the following:
“The attacker then used FTP to transfer many password protected RAR files from the RSA file server to an outside staging server at an external, compromised machine at a hosting provider. The files were subsequently pulled by the attacker and removed from the external compromised host to remove any traces of the attack.”
I’m not surprised at all that an attacker was able to infiltrate the RSA private network. However, with this and myriad similar attacks I’ve read about over the past few years, one thing that consistently amazes me is the relative ease with which attackers can get back out.
It appears in this case that RSA allows outbound FTP to anywhere on the Internet. Clearly this is not good security practice. This is not to say that an attacker couldn’t use another channel to exfiltrate stolen data, but having such generous outbound access rules for file transfer protocols makes it that much easier for the criminals.
To provide better protection from these types of attacks, security policy should be updated to disallow unrestricted outbound FTP access to the general Internet. Following the principle of least privilege, outbound FTP access should be granted only to certain users and to specific sites, and only after it is determined there is a business requirement for such access. This access should be reviewed on a periodic basis.
Using Forefront TMG 2010 and leveraging the TMG Firewall Client, it is possible to create outbound FTP access rules and enforce user and group authentication. Although this won’t necessarily prevent an attacker from uploading data through the gateway, it presents yet another hurdle for the attacker to clear in order to extract data. If the attacker is still successful, the access logs on the Forefront TMG firewall will include valuable forensic data, including the name of the application used to transfer data and the account information used by the attacker, in addition to the usual log detail (e.g. source and destination IP addresses, etc.).
State-of-the art perimeter defense technology is not enough. Security policy and strong network egress filtering are essential to prevent data loss. I’d suggest reviewing your outbound access policies today.
Connect
Richard Hicks' Forefront TMG Blog 