PA has already today a farily high hitrate (according to NSS Labs) of various obfuscation techniques and other methods to bypass IPS functionality - however new applications and protocols will continue to develop and so will the techniques to bypass IPSes. And as long as PA continue to fix and update their software PA will continue to be among the TOP 5 or so in both NGFW and IPS field. However as with all configuration some of the bypass possibilities is due to how the firewall is actually being setup. For example if you want to allow your clients to visit http sites which isnt categorized yet? First thing to remember is that application identification (which is somewhat the main reason most chooses to PA I would assume) isnt foolproof and will on its own, depending on application, let one or more packets through before the appid is sucessfully identified. Thats why you should use "application-default" as service unless you can specifiy the port or portrange to use. Along with fighting to identify bad stuff on the network and identify the good stuff there is also a fight of not having falsepositives. One example is if you transfer a file using ftp containing a http-header. In this case this transmission should be identified as ftp and not suddently a http request. However if you are in control of the ftp server you can probably make some cleartext tunneling this way, until PA finds out about this and are able to create an IPS signature for this (or even better an appid signature, either by text or by behaviour/heuristic (similar to how bittorrent, skype etc is identified)). But to sum it up of historical cases: 2.1 Obfuscation: Look at the appid cache pollution case from last xmas, or similar stuff last autumn (www.what2code.net has a description that affected not only PA but also Checkpoint and Fortigate). The xmas thing was fixed in: 5.0.2 15 Jan 13 4.1.11 06 Feb 13 4.0.14 12 Feb 13 2.2 Encryption and tunneling The tunneling part I would say is similar to 2.1. The encryption stuff depends on the configuration of your PA box - if you have ssl decryption enabled or not (and for that matter which url categories do you choose to not decrypt and also if you will allow traffic that cannot be decrypted or not). If we take Sourcefire as example you need to invest into additional hardware to be able to perform SSL-decryption, this is built in and included with the PA box. 2.3 Fragmentation NSS Labs found in 2011 a split TCP-handshake method to bypass the IPS in PA. Was fixed in 4.0.2 and 3.1.9 (5.0 didnt exist at that time): https://www.nsslabs.com/research/network-security/firewall-ngfw/network-firewall-group-test-q2-2011.html 2.4 Protocol violations Again similar to 2.1. One example is how *nix vs windows interprets various packets. If im not mistaken *nix identifies the first packets while windows chooses to go by what the last packets says (or if it was the other way around :smileysilly:). I think this is also highly dependent on which appid's you chooses to allow which I also think is a major component when using PA as IPS because the IPS can interact with the AppID (compared to the workflow in lets say Checkpoint and other products). Again, AppID isnt foolproof but that doesnt mean you should ignore it. Properly setup a PA (with all its features enabled) will be able to better allow the good stuff and block the bad stuff compared to other vendors in my experience. There is also other features that in some way could be involved in the IPS work (or more as a IDS) and that is Wildfire. This will become more interresting when the appliance boxes will be released along with capabilities of not only scan and run PE-files (.exe, .dll and .scr) but also Java, Flash, PDF and Office-documents. Another aspect to this except risk of falsepositives is also performance. Its not fun if you have 10Gbit/s boxes and they can only let through 400Mbit/s or so (or even worser than that) as with some vendors. This doesnt mean that a 10Gbit/s box from PA always has a throughput of 10Gbit/s but generally speaking it seems that the PA hardware design has a higher throughput than many competitors specially when enabling most of the features (most vendors can match their numbers in the datasheets when you have only one "any, any allow" rule at top of your ruleset and all other features, such as IPS, disabled - but when you start to enable stuff like IPS, SSL-termination, AppID etc the performances often drops way below the numbers mentioned in the datasheets). Notes regarding the report: According to page 26 they use "default" profile for the IPS in PA. More correct would be to set it up as: Critical: Block High: Block Medium: Block Low: Default Informational: Default This is what NSS Labs did when they went from 56.4% hitrate (default) to 93.4% hitrate (as above "tuned"). They also only had a "any, any allow" rule (and only blocked by "default" in the IPS setting) - meaning no interaction with appid in this case (which probably could block one or more of the evasion techniques on its own). Apart from the above I do hope some PA people will read the report and implement fixes to handle the evasion techniques described in this report. But also, as the report states, using IPS isnt foolproof. What you need to do is to have as narrow hole for the good traffic as possible and as broad detection of the bad traffic. But also take into account, what if bad stuff will hit the client? Sometimes corporations chooses to use two webbrowsers (like google chrome for internet and internet explorer or something else for internal use) but since no matter which technique you use to protect yourself approx 5% bad stuff will still be able to bypass and hit the browser I think you should decide that if you do have sensitive data on your internal networks - perhaps those clients shouldnt be able to browse the internet at all? Or at least use a terminalserver solution so if the bad stuff hits the browser then its the terminalserver that gets infected and not the client itself. And dont forget other attackvectors such as email (both incoming but also outgoing as method of communication for malwares) and the (by now) infamous usb-drives (stuxnet anyone? ). Regarding email one solution can be to allow incoming email but not outgoing. In order to send an you email you must connect to a terminalserver setup from where you can send your emails. This way the bad stuff can get into your network - but hopefully never leave...
... View more
