It’s a fact: Today’s threats have made the threats of yesterday a vision in the rear-view mirror, along with the security counterparts developed to tackle them. It’s also quite known that the legacy firewall is easily circumvented by modern threats. For example, botnets frequently communicate over common ports like HTTP to do their dirty work – sending stolen information and receiving tasks to carry out. Thus, one could deduce that TCP port 80 is a security threat and, on the strongest countermeasure, should be blocked.
However, in today’s day and age, we need to observe threats on a deeper level for practical mitigation and several questions must be asked. What activity is occurring over that channel? Are there anomalies? What data is in transit? Is it malicious by nature or simply some text being delivered to the browser? What URL/Server is the data in transit from — have they been red flagged?
The list goes on, and these are the questions we face here in FortiGuard Labs on an hourly basis, having to react and push out dynamic threat definitions. You can get an idea of how often this happens with our latest service report.
To that end, there are many industry tests performed on a regular basis against particular security functions — firewall, antivirus, antispam, web filtering, intrusion prevention (IPS), and so forth, all of which rely on varying degrees of environments and configuration parameters.
Take, for example, the latest test made public today by NSS Labs (more about this here) regarding TCP split-handshakes. The lab provided a test in which, to get a pass, the *firewall* must be able to block a split-handshake. That’s it. Other important environmental considerations, such as antivirus and intrusion prevention, were not taken into consideration. The critical questions I posed earlier are then negated since antivirus and deep packet inspection are also not enabled. The problem is that this tests an outdated firewall concept. Many qualified research firms, from Gartner to IDC to Frost & Sullivan, all support an integrated security approach for enterprises for many reasons. The main reason, of course, is that is what customers are requiring.
Before going further, it’s important to share a little bit of detail about the split handshake concept. The most common TCP handshake is the 3-way handshake (SYN, SYN-ACK, ACK). Less common is the simultaneous open handshake, where both devices act as clients trying to reach each other: using an active OPEN state, they both send SYNs and await ACK responses from each other before establishing connection. The split-handshake combines both of these methods, using stages (like the simultaneous open connection) but effectively reversing the direction of client-server flow once the connection is established.
Therein lies the problem, since inspection logic may be fooled. It should be noted that threats we see today traverse through normal (3-way handshake) established TCP connections using attacks higher than layer 4 (transport), in particular layer 7 (application). Stopping this particular split-handshake attack alone will not guarantee you protection against the vast majority of real-world attack scenarios we observe in our labs.
In the particular case of the NSS test, FortiGuard Labs released an IPS signature to inspect and detect/block split-handshake traffic before a connection is established, dynamically available to all customers through Fortinet’s Distribution Network. This is the same process we use to push out hot signatures on breaking threats such as software vulnerabilities and botnets – no downtime, no immediate firmware update required. It’s a flexible, real-time approach to modern threats. We also apply this beyond IPS, from antivirus to web content filtering rating for the latest web sites serving malware. This is where UTM truly separates itself from both legacy and point product solutions. Any devices with IPS enabled now have the benefit of identifying split-handshake traffic, AND all other malicious traffic such as vulnerability exploitation or botnet communication.
As mentioned in our previous blog post, our development team has worked in parallel on a firmware fix purely for the firewall itself. Though, as I mentioned, fewer and fewer companies are relying on standalone firewall without multi-function protection, because integrated security remains the best approach for protecting against a wide range of threats.
