Archive

Archive for the ‘Networking’ Category

IP Spoofing Alert from APIPA Address in Forefront TMG 2010

Security administrators may encounter the following IP spoofing alert on their Forefront TMG 2010 firewall:

Alert: IP Spoofing

Description: Forefront TMG 2010 detected a possible spoof attack from the IP
address 169.254.x.x. A spoof attack occurs when an IP address that is not
reachable through the network adapter on which the packet was received. If 
logging for dropped packets is enabled, you can view the details of this
attack in the firewall log in Forefront TMG 2010 log viewer. If the IP
address belongs to a VPN client, this event may be ignored.

This alert occurs because the Forefront TMG 2010 firewall received a packet on its internal network interface from a client (server, workstation, or other host) that did not have a statically assigned IP address and was not able to obtain one from DHCP, so the client selected an IP address from the Automatic Private IP Address Assignment (APIPA) address range defined in RFC 3927.

You can safely ignore this alert, or you can resolve the issue by adding the APIPA reserved network 169.254.0.0/16 to the Internal network definition. This can be accomplished by opening the Forefront TMG 2010 management console and highlighting the Networking node in the navigation tree, then right-clicking the Internal network, selecting the Addresses tab, then clicking the Add Private button and choosing the address range 169.254.0.0 – 169.254.255.255.

Note: It is possible to resolve this issue by disabling alerts for IP spoofing attempts. However, this is considered bad security practice and is strongly discouraged.

You may recall from an earlier blog post I indicated that the best way to configure the Internal network definition in Forefront TMG 2010 is to choose the Add Adapter option. This still remains true. However, this is one of those rare cases in which you’ll want add an additional network address space to your Internal network definition to reduce the volume of IP spoofing alerts being raised by the Forefront TMG 2010 firewall.

The one side effect to implementing this change is that you will now receive a Configuration error alert informing you that your Internal network does not correlate with the network adapters that belong to it.

Essentially you have traded one annoying alert for another. However, the noise generated by IP spoofing alerts from clients with APIPA IP addresses might make this tradeoff worthwhile. In addition, it is much safer to disable the configuration error alert than it is the IP spoofing alert.

Forefront TMG 2010 Protocol Direction Explained

December 5, 2011 4 comments

When reviewing the configuration of a pre-defined protocol or creating a custom protocol on the Forefront TMG 2010 firewall, many new (and sometimes even veteran) firewall administrators can be confused by the protocol direction. The correct configuration of the protocol direction is essential for proper firewall operation, but there are times when it can be somewhat unintuitive. In this post I’ll provide some clarification.

TCP

For TCP protocols the direction can be specified as either inbound or outbound.

For access rules, protocol direction is configured as outbound. Traffic flows outbound from the source to the destination. This is true even when creating an access rule to allow traffic inbound to the Forefront TMG 2010 firewall itself. It sounds counterintuitive, but the TCP protocol direction for access rules allowing access to the Local Host network should still be outbound. Why? Again, because traffic flows outbound form the source to the destination, in this case the TMG firewall’s Local Host network. If, in this case, you were to configure the protocol direction as Inbound (intuitively, inbound to the TMG firewall) it will not work.

For publishing rules, protocol direction is configured as inbound. Traffic flows inbound from the source to the published service on the Forefront TMG 2010 firewall. Pre-defined server publishing protocols include the “server” suffix, as shown here:

UDP

For UDP protocols the direction can be specified as either Receive, Receive Send, Send, or Send Receive.

For access rules, protocol direction is configured as Send. Traffic is sent from the source to the destination. If a response is expected then the protocol direction is configured as Send Receive. This is required because UDP is connectionless and the return traffic would otherwise be denied by the TMG firewall.

For publishing rules, protocol direction is configured as Receive. Traffic is received by the TMG firewall from the source to the published service on the Forefront TMG 2010 firewall. If a response is expected then the protocol direction would be configured as Receive Send.

IP and ICMP

For IP and ICMP protocols the direction can be specified as either Send or Send Receive.

IP and ICMP protocol definitions are only supported for access rules, so protocol direction is configured as Send. As with UDP, IP and ICMP are connectionless and if a response is expected then the protocol direction is configured as Send Receive.

Bug in Forefront TMG 2010 Service Pack 2

November 14, 2011 7 comments

Today I confirmed a bug in Service Pack 2 (SP2) for Forefront TMG 2010 that was discovered by Jason Jones. If you have deleted the default Internet Access network rule and replaced it with something else, installing SP2 for Forefront TMG 2010 mysteriously restores this rule. Unfortunately it places the default Internet Access rule ahead of your custom rule which in most cases will cause serious problems. This bug only affects Forefront TMG 2010 configurations where the default Internet Access network rule has been specifically deleted. If you’ve altered this rule in any way, those changes are unaffected.

Before Forefront TMG SP2 installation…

After Forefront TMG SP2 installation…

Microsoft Security Bulletin MS11-083 and Forefront TMG 2010

November 12, 2011 2 comments

Included in the November Microsoft security bulletin release was security update MS11-083 (KB2588516) that addresses a critical vulnerability in TCP/IP that could allow remote code execution. Forefront TMG 2010 firewalls are protected from this vulnerability, as the firewall engine’s kernel mode driver processes packets even before the operating system sees them. More information about how the Forefront TMG 2010 firewall engine and service work can be found here [this document is for ISA, but TMG is similar]. Although the underlying operating system’s TCP/IP networking stack is protected by the Forefront TMG firewall engine driver, TMG administrators are still strongly encouraged to install the MS11-083 update as soon as possible.

Deploying IPv6 and Forefront UAG 2010 DirectAccess Technical Deep Dive

September 8, 2011 4 comments

On Tuesday, September 20 2011, join me and Ed Horley at the Pacific IT Professionals Los Angeles event where we will be presenting a Technical Deep Dive on IPv6 and DirectAccess. During the first session, Ed will discuss in detail how to deploy IPv6 in a Microsoft enterprise network. During the second session I’ll dig in to Microsoft DirectAccess with Forefront Unified Access Gateway (UAG) 2010. The event begins at 6:00PM PDT and is being held at the Microsoft offices in downtown Los Angeles. For more information and to register for the event, click here.

Hope to see you there!

Access to the Web Proxy Filter on Forefront TMG 2010 is Denied

August 29, 2011 26 comments

Frequently I am asked to review Forefront TMG 2010 firewall logs for suspicious behavior. Often times a security administrator will express concerns about many instances of denied requests by clients attempting to connect to Forefront TMG’s web proxy service. On busy TMG firewalls there may be hundreds or even thousands of instances where the following access denied record appears in the Web Proxy logs:

Status: 12209 Forefront TMG requires authorization to fulfill the request.
Access to the Web Proxy filter is denied.

On a Forefront TMG 2010 firewall where web access rules require authentication, this behavior is expected and by design. It does not indicate an attack of any type on the Forefront TMG firewall or its web proxy service. The root cause for the flood of access denied messages has to do with how the Web Proxy client behaves when accessing resources via an authenticating web proxy like the Forefront TMG 2010 firewall. When a Web Proxy client sends its initial request for a resource it will always attempt to do so anonymously. Only when prompted for authentication by the firewall will the web proxy client provide the credentials of the logged on user.

Consider a scenario where Forefront TMG is configured to only allow authenticated users to access the Internet. The firewall policy might look something like this:

Below is a network trace taken from a client attempting to access http://www.bing.com/ through a TMG firewall as configured above.

We can see that the first three packets of the trace are the TCP three-way handshake taking place between the web proxy client and the Forefront TMG firewall. Once a connection to the web proxy listener has been established, in packet 8 the client sends an HTTP GET request for http://www.bing.com/. In packet 13 you’ll see that the Forefront TMG firewall denied the request and replied with an HTTP 407 response, indicating that proxy authentication was required. This was done because the Forefront TMG firewall did not have any access rules which would allow the anonymous request. It did, however, have access rules that might apply to this request, depending on who the user is. This response also includes which authentication methods the web proxy listener is configured to accept.

In packet 15 the web proxy client again submits its HTTP GET request for http://www.bing.com/, this time indicating that it would like to use the NTLM Secure Service Provider (SSP). In packet 16 the Forefront TMG web proxy denies the request yet again and replies with another HTTP 407 response, this time including the NTLM challenge. In packet 17 the client submits an HTTP GET request for http://www.bing.com/ and supplies the credentials in the form of an NTLM response.

As you can see, each time a web proxy client requests a resource through a Forefront TMG firewall that requires NTLM authentication the client is actually denied twice during the transaction before being successfully authenticated and allowed access. If this sounds like a lot of overhead for authenticated proxy traffic, you are right. Denying each request twice consumes additional resources on the Forefront TMG firewall and introduces some latency for clients as well. In addition, the burden of authenticating the user is placed on the TMG firewall when using NTLM, as the firewall itself must contact a domain controller to authenticate the user. You can reduce the authentication load on the Forefront TMG firewall considerably by enabling Kerberos authentication. When the Forefront TMG firewall is configured to use Kerberos there is only a single denied request and HTTP 407 response. The client must then contact a domain controller and obtain a Kerberos ticket to present to the TMG firewall to gain access to the resource. Information on how to configure Microsoft ISA Server and Forefront TMG 2010 to use Kerberos authentication can be found here.

Additional information…

HTTP response codes – http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
NTLM challenge/response – http://en.wikipedia.org/wiki/NTLM

Forefront TMG 2010 Network Inspection System and Custom Protocols

August 1, 2011 Comments off

An intrusion detection and prevention system (IDS/IPS) is an essential component of a modern secure web gateway. The Network Inspection System (NIS) in Forefront Threat Management Gateway (TMG) 2010 is a unique implementation of IDS/IPS. NIS is focused specifically on detecting and preventing attacks on Microsoft operating systems and applications. NIS uses signatures that are developed by the Microsoft Malware Protection Center (MMPC) and are distributed through Windows Update or WSUS.

NIS in Forefront TMG 2010 provides protection by performing low-level network protocol inspection. Each packet is analyzed for protocol state, message structure, and message content. When a packet is received, NIS will inspect it only after the firewall policy has allowed it, and only after any associated web or application filters have processed it.

There is one caveat, however. A custom protocol is not subject to NIS inspection by the Forefront TMG firewall unless it is associated with a standard protocol. Often a Forefront TMG firewall administrator will create a custom protocol for a standard protocol that uses a non-standard port. One of the most common protocols to be configured to use non-standard ports is the HTTP protocol. For example, if an administrator defines a custom protocol to support a web-based application that uses the non-standard TCP port 62112, by default NIS will not inspect this traffic even though the communication is HTTP, a protocol which NIS normally inspects when it takes place over the standard TCP port 80.

To apply Forefront TMG NIS inspection to a custom protocol it must first be associated with a standard protocol. In our example we’re using HTTP over a non-standard port, so we need to associate our custom protocol with the Web Proxy Filter.

Next, associate the custom protocol with a standard protocol definition, in this case HTTP Proxy.

Once complete, Forefront TMG NIS inspection will be applied to the custom protocol and policy will be enforced according to the current NIS configuration.

Forefront TMG NIS additional information:

Enabling and configuring Forefront TMG 2010 NIS

Forefront TMG 2010 NIS Whitepaper [Word Document]

Forefront TMG 2010 Web Proxy Auto Detect Fails

Recently I received a call from a customer who was trying to resolve an issue where all web proxy clients that were configured to use Web Proxy Auto Discovery (WPAD) with DNS suddenly stopped working. We began troubleshooting by confirming that the hostname WPAD resolved to the internal IP address of the Forefront TMG firewall, which it did correctly. Next we used a telnet client to confirm that the TMG firewall was listening on TCP port 80 (used by TMG for DNS WPAD clients) and indeed it was responsive. A scan of the event logs on the firewall turned up the following warning message:

The Web Proxy filter failed to bind its socket to 172.16.1.253 port 80. This may have been caused by another service that is already using the same port or by a network adapter that is not functional. To resolve this issue, restart the Microsoft Firewall service. The error code specified in the data area of the event properties indicates the cause of the failure.”

Something was listening on TCP port 80, so we opened a command prompt and entered the following command in order to determine which process was listening on this port:

netstat –ano | findstr :80

Netstat was reporting that TCP port 80 was in a listening state and bound to the IP address 172.16.1.253. The process using this port was the System process (PID 4). This is unexpected, because the Forefront TMG web proxy service (wspsrv.exe) should be bound and listening on this port. Clearly this was a web service hijacking this port, so to find out more we entered the following command at a command prompt:

netsh http show servicestate

The output of this command revealed a valuable clue. Notice the registered URL below…

HTTP://172.16.1.253:80:172.16.1.253/REPORTSERVER_ISARS/

As it turns out, this customer had attempted to change the SQL Reporting Services Web Service URL. By assigning the Forefront TMG firewall’s internal IP address and changing the port to 80 in the Reporting Service Configuration Manager, this caused a conflict with the Forefront TMG web proxy filter, which requires TCP port 80 to provide WPAD for DNS.

To resolve the issue, the administrator chose a TCP port other than 80 and restarted the system.

Network Egress Filtering and the RSA SecurID Attack

April 2, 2011 1 comment

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.

Configuring Site-to-Site VPN with Forefront TMG and Cisco PIX and ASA

January 25, 2011 60 comments

Forefront Threat Management Gateway (TMG) 2010 supports several protocols for establishing a site-to-site (LAN to LAN) VPN, including PPTP, L2TP, and IPsec. Of these, IPsec is the only supported protocol for establishing site-to-site VPN connections with third-party VPN devices such as Cisco PIX and ASA. In this post I will demonstrate how to configure Forefront TMG and the Cisco PIX/ASA to create a site-to-site VPN for the following branch office deployment scenario:

[Note: Site-to-site VPN in TMG is supported only in multi-homed network configurations. The TMG firewall must be configured with a minimum of two network interfaces to function as a site-to-site VPN gateway.]

Configuring the TMG Firewall

Open the TMG management console and highlight the Remote Access Policy (VPN) node in the navigation tree, then select the Remote Sites tab in the main window. In the Tasks pane on the right side, click Create VPN Site-to-Site Connection.

The Site-to-Site Connection Wizard will collect the necessary information to establish the VPN tunnel. Enter a descriptive name when prompted.

Select IP Security protocol (IPsec) tunnel mode.

If the TMG firewall is a member of an array that does not have Network Load Balancing (NLB) enabled, select a node to be the connection owner. If NLB is enabled, the connection owner is assigned automatically. [Note: When configuring a site-to-site VPN connection on a TMG firewall that is a member of an array and NLB is not enabled, hosts that are accessed via the tunnel must be configured with a default gateway or static route that will direct traffic back to the array member chosen as the connection owner.]

Enter the IP addresses of the remote and local VPN gateways. The remote VPN gateway IP address will be the IP address assigned to the outside network interface on the Cisco PIX/ASA firewall. The local VPN gateway IP address will be the IP address assigned to the External network interface on the TMG firewall. If the TMG firewall is part of an NLB-enabled array, specify the Virtual IP (VIP) address assigned to the External network of the array.

Certificates are the most secure and preferred method for authenticating tunnel endpoints, but because they are more complex and difficult to configure, many security administrators opt instead to use pre-shared keys. When choosing a key, be sure it is very long and complex (up to 128 characters – it is a good idea to use a random password generator for this task). Although using special characters is an excellent idea for complex keys, avoid using the question mark as the PIX and ASA object to this.

Add the address range(s) of the remote site network(s). It is recommended that these addresses be configured along subnet boundaries.

A network relationship needs to be established between the Internal network and the remote site network. The wizard automatically establishes a route relationship between these two networks.

An access rule is required to allow communication between the Internal network and the remote site network. If this is a fully trusted remote network (e.g. branch office), select all outbound traffic. If the remote network is untrusted (e.g. business partner), specify which protocols and ports are allowed.

Review the configuration and select Finish.

Do not apply the configuration now. The default encryption settings chosen by TMG are incompatible with the Cisco PIX and ASA. To change these settings to match the settings on the PIX/ASA, right-click the remote site and choose properties. Choose the Connection tab and then click IPsec Settings.

For the Phase I settings, change the Encryption algorithm to 3DES, the Integrity algorithm to SHA1, and the Authenticate and generate a new key every: to 86400 seconds (24 hours).

For the Phase II settings, change the Encryption algorithm to 3DES and the Integrity algorithm to SHA1. Change the Session key settings so that a new key is generated every 4608000 Kbytes or 28800 seconds (8 hours).

Once complete, save and apply the changes.

Configuring the Cisco ASA 7.x

Connect to the ASA with administrative privileges and enter enable mode. To configure the management connection (phase 1) parameters, establish an ISAKMP policy and set the parameters to use a pre-shared key, use 3DES/SHA for encryption and integrity, specify the use of Diffie-Hellman group 2 (1024-bit) and authenticate and generate a new key every 86400 seconds (24 hours).

crypto isakmp policy 10
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
crypto isakmp enable outside

Configure a tunnel-group for the remote peer and establish authentication using a pre-shared key.

tunnel-group 63.166.231.17 type ipsec-l2l
tunnel-group 63.166.231.17 ipsec-attributes
pre-shared-key mMWsT0umh_UQmh]yevjNBW_F

For the data connection (phase 2) create an access rule that defines which traffic to protect using this tunnel. In this example, create an access rule that defines all IP traffic going from 10.12.0.0/24 to 172.16.1.0/24.

access-list branch_office extended permit ip 10.12.0.0 255.255.255.0 172.16.1.0 255.255.255.0

Create a NAT rule to exempt any traffic matching this access rule from NAT.

nat (inside) 0 access-list branch_office

Define which encryption algorithms will be used to protect this traffic. In this example specify the use of 3DES and SHA1.

crypto ipsec transform-set branch_office esp-3des esp-sha-hmac

Build the crypto map, indicating that any traffic that matches the branch_office ACL is sent to the specified remote peer using the encryption algorithm defined in the brach_office transform set with Perfect Forward Secrecy (PFS) enabled using Diffie-Hellman Group 2.

crypto map branch_office_map 1 match address branch_office
crypto map branch_office_map 1 set pfs group2
crypto map branch_office_map 1 set peer 63.166.231.17
crypto map branch_office_map 1 set transform-set branch_office

Activate the crypto map on the ASA’s outside interface.

crypto map branch_office_map interface outside

Configuring the Cisco PIX 6.x

Creating a site-to-site VPN connection on a Cisco PIX is similar but slightly different than configuring an ASA. For example, when configuring the management connection (phase 1) parameters using the same configuration used previously, use the following commands:

crypto isakmp policy 10 authen pre-share
crypto isakmp policy 10 encrypt 3des
crypto isakmp policy 10 hash sha
crypto isakmp policy 10 group 2
crypto isakmp policy 10 lifetime 86400
crypto isakmp key mMWsT0umh_UQmh]yevjNBW_F address 63.166.231.17 netmask 255.255.255.255
crypto isakmp enable outside

Create the access rule defining which traffic to protect using this tunnel.

access-list branch_office permit ip 10.12.0.0 255.255.255.0 172.16.1.0 255.255.255.0

Exempt this traffic from NAT.

nat (inside) 0 access-list branch_office

Protect this traffic using 3DES and SHA1.

crypto ipsec transform-set branch_office esp-3des esp-sha-hmac

Build the crypto map.

crypto map branch_office_map 1 ipsec-isakmp
crypto map branch_office_map 1 match address branch_office
crypto map branch_office_map 1 set peer 63.166.231.17
crypto map branch_office_map 1 set transform-set branch_office
crypto map branch_office_map 1 set pfs group2

Activate the crypto map on the PIX outside interface.

crypto map branch_office_map interface outside

Unlike the ASA, the PIX requires an access rule to allow tunneled traffic to cross the firewall. For the branch office scenario (fully trusted network), allow all IP traffic from the 172.16.1.0/24 network to reach the 10.12.0.0/24 network and assign that access rule to the outside interface.

access-list main_office_in permit ip 172.16.1.0 255.255.255.0 10.12.0.0 255.255.255.0
access-group main_office_in in interface outside

Due to formatting issues, some of the text in the PIX and ASA command examples may be truncated. You can download the script files for these examples here: PIX | ASA.