ISA Server/Forefront TMG on the edge, done fine and doing fine, real world attacks

This was and seems to still be a common question regarding ISA Server 2004/2006/Forefront TMG: “is it OK to have ISA Server 2006/Forefront TMG on the edge or has to be behind another firewall due to security considerations ?“.

I’m not going to talk about cascading firewalls scenarios, “best practices” or so.

Let’s have a look back at real world various attacks(including over firewalls) that required the ISA Server 2004/2006/Forefront TMG administrators to do nothing over the default configuration in order to mitigate them. Do note that actually the firewalls in front of ISA/TMG might have been deployed to address some of these. ISA/TMG would be have been just fine alone placed at the edge of the network.
Below real world examples are just a few ones that quickly come though my mind as writing.

Most often the front firewall in front of ISA Server 2004/2006/Forefront TMG was/is doing only stateful packet filtering, or at least a form of stateful wannabe.
I say wannabe as most of the time the stateful packet filtering isn’t in full mode on certain firewalls within the default configuration and requires the admin to perform extra steps to enable additional options.

What TMG does by default ? [1][2][3]
Forefront TMG fully parses and then reconstructs the IP and TCP headers, transferring only the data parts.
TMG validates the three-way handshake packets required in a sequence.
Provides sequence verification for RST or SYN segments.
When doing NAT, say from Internal to External, SYN sequence numbers and source ports are randomized on SYN segments used to establish new connections(in fact, as already said, TMG “intercepts and alters” the entire TCP three-way handshake handshake).
TCP connections/UDP sessions limits(new requests and concurrent) are on by default.
Advanced spoofing protection is on by default.
Packets with certain IP options are dropped.

As a result the late TCP Split Handshake vulnerability did not affect TMG.[10][11]
Crafted RST segments can’t be used to reset TCP connections from other clients; no need to enable “sequence number verification” or so.[4][5][6][7][8][9]
Also no need to enable “TCP intercept” for flood mitigation.[8][9]
Same for Reverse Path Forwarding as spoofing protection.[8][9]
The original VPN client split-tunneling danger is mitigated, since ISA/TMG will block source IP addresses appearing from the client side of the VPN tunnel different from the original client source address, the spoofing protection can only be bypassed if a form of NAT-ing or proxying is done on the VPN interface on the VPN client.[12]

Application layer inspection
Application layer inspection is on by default through the available application filters. [22][23]

As a result default protection against Slowloris, HTTP denial of service condition, is provided[15](as a side note, on some application aware firewalls you need to have the IPS configured to block this [14]).

US-Cert VU#435052, some transparent intercepting proxy implementations made connection decisions(routing) based on the HTTP host-header value, but this was not ISA Server’s case.[16][17]

FTP clients using the PASV command could be manipulated to connect to TCP ports on another hosts, ISA’s FTP filter blocked this.[20][21]

US-Cert Vu#150227, some HTTP proxy default configurations allowed arbitrary TCP connections through the CONNECT method, ISA Server/TMG by default limit this to TCP port 443.[18][19]

As an extra feature, when application layer inspection occurs, TCP sequence randomization on SYN segments is done by default(meaningless if NAT is used or not).
Also to prevent HTTP denial-of-service (DoS) attacks, HTTP requests limits are on by default.


[1] ISA Server Network Protection: Protecting Against Floods and Attacks

[2] Overview of intrusion detection

[3] Forefront TMG flood mitigation

[4] What is the default setting for 'set flow tcp-syn-check' and how do you check

[5] Configuring Firewall/NAT Flow—Quick Configuration

[6] [ScreenOS] Firewall is dropping TCP RST/ACK packets after a TCP RST is passed through

[7] Resolving the TCP Reset (RST) Attack

[8] ASA/PIX 7.x and Later: Mitigating the Network Attacks

[9] Configuring TCP Intercept (Prevent Denial-of-Service Attacks)

[10] The TCP Split Handshake: Practical Effects on Modern Network Equipment

[11] Forefront TMG 2010 vs TCP split handshake

[12] VPN client IP routing and split tunneling

[13] Slowloris HTTP DoS

[14] Detecting Slowloris: A Denial of Service (DoS) over HTTP

[15] Forefront TMG Beta 3 vs Slowloris

[16] Intercepting proxy servers may incorrectly rely on HTTP headers to make connections

[17] ISA Server vs US-CERT VU#435052 – A Quick Test

[18] HTTP proxy default configurations allow arbitrary TCP connections

[19] ISA Server 2006’s web proxy and the default port allowed within the HTTP CONNECT Method

[20] Manipulating FTP Clients Using The PASV Command

[21] ISA 2006 Firewall's FTP Filter by default blocks the FTP Clients behind it from connecting to a different IP address returned in the FTP server's response for the PASV Request command

[22] About application filters

[23] "Deep Packet Inspection"; What Does it Mean, Really?

Comments are closed