last week I had a Stonesoft engineer in my lab demonstrating their techniques of exploit attack via AET. I tested my PAN NFR units (PA-200 & PA-2050) with IPS license last update, together with other vendors IPS units, protecting 2 pretty vulnerable client (one win xp sp2 the other ubuntu 6.04) .
The result scared my quite a bit. Known exploits are blocked once sent in clear way, but when a subset of AET was run under script the catch rate was quite bad, less than 10% with the highest IPS policy in place.
Here the link to Stonesoft attacker that one can freely test: Evader | Stonesoft Evader
Last AET discussion in this forum is pretty old, end of 2010, and I would like how PAN handles nowadays these kind of sophisticated traffic obfuscation, carrying malicious payload.
I know that patching the client solve the problem but the same oparation could be done with client with no patch software available and IPS are meant to handle such situations.
However AET (Advanced Evasion Techniques) is a concern of everybody using a firewall such as a PA device so it would be great if some PA representative could bring the community forum some updates on this topic.
As I understand it the IPS in PA is a strictly stringmatching engine (as most IPS are). That gives if you take one threat thats being identified and obfuscate it through some other scripting language so that the content of the packets being sent is changed then this signature will most likely miss this modified attack unless the modified attack on its own is being identified. For example if there is a signature for a specific exe-file which will no longer be detected if you run the binary through UPX. But then there is perhaps a signature for UPX compressed exe-files which might trigger instead.
Except for having the threat-db up to date also make sure that the PANOS itself is up to date.
Another thing to verify is to have ssl-termination in place (and in a strict mode so if the ssl cannot be intercepted then the session is not allowed to pass through).
You can also use the url-db to only allow clients to visit "known" good sites (or rather categories).
A drawback with Wildfire is that it wont stop the bad file from being downloaded (when its seen first time anywhere in the world) but you will at least get a warning that the file the client just recently downloaded is an (currently) unknown malware (this alert shows up when the analyzing is complete). The next client downloading the same file will however be protected (unless the signature changes).
No matter which IPS or similar product you use there will always be 1-5% malware out there that will, in one way or another, be able to bypass this filtering. That is why its important to also have a good design closer to the clients so WHEN (and not IF) the shit hits the fan (because it will) the infection can be contained and perhaps also segmented away from your sensitive data.
One way to accomplish this is by using a terminalserver setup for the clients to use if they want to browse the internet. This terminalserver cluster is then segmented away from the rest of your network so IF you get some malware through your network this malware will still not be able to reach any of your golden eggs which you handle at the company (it will stay at the terminalserver cluster - by rebooting each instance each time a client logs out or do this once a day will also block out some longliving APT's (Advanced Persistent Threats)).
Another method is to use dedicated clients (and dedicated networks) among other solutions to this problem.
Except for having all your software up to date (so known exploits wont work) its also good to harden the configurations and also ask yourself if you really need all this software you currently have on your clients (the more software the more ways to exploit the client).
For example do you really need a pdf-viewer? And if the answer is yes - does it really have to be Adobe PDF Reader? Perhaps a more limited pdf-viewer such as SumatraPDF would be a better (securitywise) option?
The same thing goes by the way for AppID. If you allow web-browsing then any http-based traffic which isnt identified by some other appid will be allowed through your PA device. However if you combine AppID with the url-DB and threat-DB (IPS) along with Wildfire and SSL-termination and have a good design on your inside so IF something manages to bypass the filtering within your infrastructure you will have a pretty good setup.
What I want to say (for the TLDR people out there ;-) is that you can never trust your network to always catch ALL the malware which is out there - the network can of course be a good resource to help you fight malwares but there will always be 1-5% malware that will be able to bypass the filters and reach all the way to the clients (or the terminalservers if such are being used). So dont forget the overall design and also how to contain and segment WHEN malware will reach all the way. Because except for networks malware can spread through cd/dvd and USB-devices. And dont forget other vectors such as how are emails (and any attachments) being handled on which hardware (clients) in your organisation?
Would be great if you, or even better your country SE, could post what was being said and which commands to test so the rest of the forum will know.
Looking forward for an update on this topic :smileyhappy:
Regarding these "virtual patching" (buzzword of 2012?) features of IPS's im a bit sceptic to those - its a good complement but the proper way to fix the problem is to update the client (or the server for that matter). Because as being said - there is often more than one way to obfuscate shit so it will bypass your IPS no matter which vendor you use...
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!