I had a multitude of discussion with different people, some technicians, some sales people, some managers, and whilst they we all very excited about Check Point's new IPS, embedded in the R70 gateway release, no one could really tell me what all the fuss was about. And so, my quest began!
I originally hopped to have this entry completed by Monday 16th March 2009 but was delayed for many reasons. Please accept my apologies.
In the following pages, we'll talk about the majority of the new IPS features, and also take a clumsy but insightful tour of the IPS configuration under the hood, trying to determine if there are in fact core changes made to the IPS engine.
Confidence, Severity, and Performance: All need consideration
My first port of call was the GUI DBedit so I could take a look at how the ASM table had changed. This is the table that determines how the SmartDefence (now called IPS) tab is displayed. We see here that there is now a 'protection_info' part.
To help manage IPS protections, Check Point have gone through and marked each protection with a Confidence Level, meaning how likely the protection is to false positive, Performance Impact, which describes the impact on the gateway CPU, Severity, which indicates how bad a successful exploitation of the protected vulnerability would be, and finally Type, which tells us whether it's a signature based protection or a protocol validation protection.
All of a sudden the security administrator can be fearless in his application of the protections. Previous software versions did not contain this sort of information, and as such, enabling protections was hit and miss. If an administrator enabled a group of protections with critical performance impact, they would find that their security gateway becomes a little too secure as the CPU hits 100% utilisation and drops traffic. Likewise, an administrator may of enabled a protection that would be classes as having a low confidence level, and may block business traffic that perhaps behaves in a non-standard way.
TIP: Whilst undoubtedly unsupported, if you we're to disagree with Check Points determination of any of the four fields, you can change them in GUI DBedit and have the changes reflect in SmartDashboard GUI. I can see that becoming a feature request as, rightly so, a vulnerability in one environment deemed high severity would be deed low severity in another.
The usefulness of these protection attributes does end there. They can be used to set automatically configure the IPS policy. Lets look at an example.
Below we have an IPS profile, created by Bob. He wants the all of his enabled protections to be set to 'Prevent' mode (in other words, if they detect an attack, they'll block it).
He wants both Client & Server protections to be activated automatically.
Most importantly, he wants protections that have a medium severity or above, a performance impact of less than high, and a confidence level of medium-low or above to be automatically activated.
Or put another way, as long as exploitation is going to cause him to get fired, the signature is written carefully enough not to false positive, and the protection won't cause his firewall to fall over, he's happy to switch it on. He's also a had trouble with the HTTP information exposure protection (I'm making this up, the protection is fine) so he's added that as a category to the 'do not activate' list.
At this point, he clicks ok, and all of the protections are then automatically configured according to the rules he just set.
Now, Bob has one final concern: he's scared that a new protection provided by an IPS update might download and block some mission critical traffic. After all, his company has all sorts of legacy protocols, and he doesn't want to loose his job. So Bob sets the update policy so that new protections that are automatically activated by the IPS policy will be set in detect mode only, with no chance of blocking traffic.
Bob can rest easy.
After a bit more digging around I found some things that were even more interesting. Four new tables all labelled IPS!
IPS_contexts
IPS_exceptions
IPS_protections_override
IPS_signatures
Now, whilst these only hold configurations, they are a damn find indicator that there is indeed a new IPS engine under the hood.
I take exception to that!: IPS_exceptions table
Here we see how one of the most import new features of Check Point's gateway IPS is controlled. The exceptions feature gives us the ability to select traffic that will bypass IPS inspection completely using source IP address, destination IP address, and destination port. We can then choose to apply this 'exception' to a single protection only, or to all protections within a profile (noting that not all protections support exceptions - if you want to know how to tell, look at the first screen shot, for the field 'supports_exceptions').
This feature is massive: it adds another reason for the administrator not to be fearful of using IPS.
Probably the very best part about exceptions is that you can create them from the log viewer, making the task of fine tuning your IPS easy. Here we can see 'Add Exception...' link in the new look SmartView Tracker.
Lets finish our look at the other tables before moving on to the other features.
FIne tuning our IPS policy: IPS_protections_override
As we said earlier, the IPS policy as defined in the profile automatically enables based on your criteria. This is really useful as there are a lot of protections however, it's leaves your with a rather generic policy.
You can now go through each protection by hand, and using your own knowledge of the environment, override the configuration applied to each protection my the IPS policy.
In the screen shot, you can see the default action, as determined by our IPS policy, for Null CIFS Sessions is to prevent (block) them. However, we're a little more conservative, and wish to detect them which allowing the traffic to pass.
IPS Contexts: Reducing False-Positives
A long time ago, in a galaxy far far away, network IDS would simply take a bunch of packets, defragment/reassemble them into a stream of data, and grep for patterns. This was great: you could fire an exploit through a packet analyser and pick out any old string that could become your signature. The IDS would then look for that string.
However, this had it's drawbacks in that the string could occur naturally within file transfers, or many other types of network traffic, and would trigger the IDS even when the exploit was not present. This is bad, and known as a false positive.
So, a better idea is to write a signature that only targets a particular part of the datastream. For example, if you are look for an exploit which sends it's exploit code (a string of bytes) only in the HTTP header, then you want to be able to target your signature at that area of the data only, and not at the other part that contains the 2GB ISO that you are downloading.
This is what IPS Contexts appear to be for (in the IPS_Context table)! The ensure that the signature is applied against the part of datastream where the exploit will be, and so reducing the likelihood of false positives.
(Well, it also caters for encoded and encapsulated data, such as you see HTTP using Base64, which prevents the attacker evading detection simply by encoding his exploit).
This nicely introduces us to the.......
IPS Signatures: Targeting the nasties!
The IPS signature is the part that tells the IPS engine what to look for (with the IPS context telling the engine where to look). We take the ASCII Only Responses protection (under the Web Intelligence section) as an example. We can see that there is a bunch of hex values all separated by the the or operator "|" and that this signature is used in four contexts:
HTTP_STATUS_CODE
HTTP_STATUS_REASON
HTTP_RESPONSE_VERSION
HTTP_RESPONSE_HEADER
Essentially, this signature, assisted by the contexts, matches (and so blocks) any non-ascii values that come back from the server as status codes, reason, version responses or any other http header. This can be called a protocol anomaly protection as it's a broad signature that doesn't target a specific exploit but enforces a certain protocol behavior.
You can see in my example picture, we've got the unicode text of the string 'Hello World' show in a hex editor. The values FF FE & 00 are non-ascii and are included in the signature; if the data in the hex editor was part of a HTTP header - it would have been dropped, and rightly so.
This signature is also very useful because it forces all the data carried by the contexts to be ascii, removing the possibility for the attacker to encode his exploit in unicode, say, in an attempt to evade any signatures that aren't written for both types*.
* Although I should mention that I used this as an example only. There seems to be a number of contexts in the Check Point IPS that 'decode' HTTP so even without ASCII only protections, I would imagine that the evasion attempt would fail.
Other Features
Enough hacking about, lets show you the other features.
Packet Captures
Each protection has the ability to captures the packet that triggered the protection as part of the log entry. This is a feature that has been lacking since the NG AI days but it's critical if you want to take any legal action against a hacker, or carry out a decent level of incident response.
Worth noting is that it only seems to capture the triggering packet (that that contained the exploit or the protocol anomaly), and not a few packets before and after the trigger packet as other IPS do. However, is this a big deal? Perhaps not.
As the picture shows, the capture is in a standard format and can be opened in Wireshark or any decent protocol analyser.
IPS Updates
The IPS (SmartDefense) update dialog is a little more detailed now, so you see where the issue is if it bombs out at any time. Most important is that new protections that are downloaded are 'Marked for Follow Up' which allows you to go to the protection viewer and clearly see what is new and what is existing.
Protection Browser
This is a real enabler for IPS and in my mind needs to be demo'd to every prospective new Check Point customer. Essentially you've a matrix with the protections listed with their serverity, confidence, release date etc against the IPS profiles that you would have assigned to each gateway. It's completely searchable by any column using the 'look for' field you see there, supports rearrangement of the column order, and supports sorting by the columns (I'd sorted by release data). You can also use the back and forward buttons to move back to previous views you'd just used.
There is a host of labor saving options under the 'Protection Actions...' button that let you shift-click as many protections as you wish, and set their setting for each profile, Prevent, Detect or Inactive, or mark many protections with a follow up comment.
In fact, the Follow Up Comment column is the most important. Newly downloaded protections will be activated in Detect mode (according to your IPS policy) and marked as 'Newly Downloaded.... enabling the administrator to sort by this column and review each protection, one by one, removing the flag as he goes. This is a welcome feature as, to be frank, reviewing new updates on R65 was near impossible unless you maintained very good notes as to what you've reviewed and what you hadn't.
Last but certainly not least.... Are you ready for this? You can export the matrix as a CSV file and view it in Excel etc. Great for communicating your policy to third parties or other departments without giving them a GUI.
Bypass Under Load
With this feature enabled, IPS inspection will be automatically disabled if with CPU% or Memory% goes over a high watermark (90% by default) and be automatically re-enabled when the CPU% & Memory% both fall below the lower water mark (70%). It's configured per gateway.
This is a great feature, and allows the customer to choose what is more important, connectivity of security. Whilst security purists would argue that this feature is misguided, enabling an attacker to disable IPS if he can push the gateway hard enough, the truth of the matter is that without this sort of feature it's unlikely that the IPS would be enabled at all by a business that is even a little sensitive to downtime.
One point I would raise is that if you configure this feature, I would highly recommend resetting the alert thresholds on your SNMP Management Station to alert when CPU/Memory hits 60%, and start going nuts at 68%. After all, disabling the IPS feature is the same as walking up to your dedicated IPS appliance and disabling it. You want advanced notice before you IPS is going to drop the shield is provides to your network.
But is there really a new engine inside? Yes, for sure!
From looking at the kernel debug topics, there is a few new modules:
kiss
kissflow
fw: aspii cmi
And when running these debugs and sending an exploit through the gateway you see vastly different outputs from pervious versions, some talking about an 'Advanced Patterns Search Application' others referring to handlers written in INSPECT which we can find if we look hard enough.
Conclusion
From what I've seen, and I've not published the 20MB of debugs I generated, there seems to be a great deal of work that has gone into the new IPS, and whilst it's easy to cast doubt and and argue Check Point have simply painted up the GUI, this is not the case.
The old SmartDefense feature of the gateway has been replaced with a feature rich IPS that is flexible, granular, and above all seems to have a signature language based on INSPECT that will allow Check Point to expand the value of the IPS through quality protection updates.
If you looked at SmartDefense in the past, and wrote it off - now is the time to look again.