Sounds like a FUD race from a competitor which doesnt like the competition from PA 🙂 Here is the response I got from "my" SE regarding a similar statement and the defcon 19 video presented by a Juniper guy: " Hi Folks, It is unfortunate that i need to send this out but i have received several questions form partners and customers now to comment on some of the messaging seen from Juniper on Application firewalling and its short comings, and we feel that we need to point out some things in the messaging that are not quite correct when applied to our technology. Otherwise we love that everyone is discussin nextgen firewalls to build the market. I provide this so you can provide your customers with good information, it also gives you a good summary on how AppID actually handles special and unusual cases. Let us know if you have any followup questions. Claim: Application firewalling does not replace the need for IPS. Absolutely true. There is no question that IPS technology is a requirement. App-ID is not intended to replace IPS or even reduce the need for it. This is the reason we have invested in building a best-in-class IPS functionality into the device. This is also why IPS is a critical piece of the next-gen firewall requirements. Claim: Application cache causes traffic to be misidentified. Not true. App-ID cache delivers performance gains without sacrificing accuracy. Application and protocol decoders validate the traffic on sessions identified using the cache, and if the validation checks fail, the cache entry is removed. The session is then switched out of the decoder and identified as unknown. Also, at short periodic intervals, new sessions are inspected by the App-ID engine regardless of the cache hit. This handles cases where the destination/port may have been reused for a different application server. We repeated the test described in their claim by populating the App-ID cache with an entry for web-browsing by sending multiple HTTP sessions on the same destination/port. The SMTP traffic in a following session on the same destination/port causes a cache hit, is inspected by the HTTP decoder, fails validation checks, is switched out of the decoder, and reported as unknown. The cache entry is invalidated as part of this and the next SMTP session will be identified as SMTP. Claim: Does not inspect both Client-to-server and Server-to-client directions of traffic. Not true. Traffic is inspected in both directions. We repeated the test described in their claim, sending an HTTP GET request followed by a FTP server response on the same session. The session is initially identified as web-browsing but switches to unknown-tcp when inspecting the FTP server response, since the traffic is neither HTTP nor FTP. Claim: Can evade Application firewall using client-server collusion by starting the connection as a permitted application and switching to another. Not a genuine or valid test. The scheme devised in the test assumes both the client and server are already under the control of the attacker. We don¹t know of any real-world clients or servers that can talk HTTP initially and then switch to SMTP. In any case, App-ID has coverage for many evasive real-world tunneling applications and we continue to add coverage for more as we discover them. Claim: Some applications can only be identified on specific ports. Partially true. The application example given was DNS. The identification scheme for DNS includes a check for port 53 since we don¹t expect any real world DNS service to be running on any other port and since DNS traffic is often very short and difficult to reliably identify by signature alone. Non-DNS traffic sent to port 53, will be validated in the DNS decoder to ensure it is really DNS. If the validation checks fail, the session is switched out of the DNS decoder and identified as unknown. Claim: Does not inspect traffic at Layer 7 when the Application can¹t be identified. Partially true. Traffic that does not match any of the applications that we have coverage for will be reported as unknown and eventually stop being scanned for threats. The best practice for dealing with unknown traffic is to deny it in security policy. Customers using an application that we don¹t currently have coverage for, can submit a request for adding coverage for it in one of our weekly content updates, or create a custom App-ID on their own. Allowing unknown applications is a risk that other firewalls or IPS products cannot prevent. " In my opinion you cant entirely rely on appid - simply because appid triggers on various behaviour and strings like a signature (which is also why appid's are updated every now and then), thats why I recommend people to never use service:any in an allow rule but at least use service:application-default unless you can specify which port(s) you want to use like service:TCP443. Meaning when you build your security rules you start to configure the PA as a regular SPI firewall (srcip, dstip, srcport, dstport), THEN you enable appid for each security rule (where needed) and perhaps userid and urlcategories (and AV, IPS, File etc) and so on. In reality you do this line by line but to explain the flow of how (at least I :P) thinks when I setup rules in a PA. In order to see how application identification works in real life you can use this simple test: Setup a rule which will allow "appid:web-browsing" (basically any HTTP based traffic) along with "service:any" (yeah I know I said you should NEVER EVER use service:any in an allow rule but this is just an example 🙂 along with a http server who listens at TCP81. When the client sends a request such as "a b c" (instead of "GET / HTTP/1.0" which is more like a true HTTP request) the packet is allowed through to the server. Not until the server replies with "HTTP ERROR 400/Bad Request" the AppID engine will know that this flow/session is supposed to be a HTTP communication but "a" is not a valid HTTP request and the response will never reach the client. Workaround for above (if you dont want the request to hit the server) is to deny "appid:unknown" but also create a custom AppID (application signature) or ThreatID (IPS signature) which demands that the "HTTP-Request-Method" should be HEAD, GET or POST (or which HTTP request methods you wish to allow). Another method (along with previously mentioned methods) is to use "service:application-default" or if possible "service:TCP80" (given that your server normally would listen to TPC80 and the stuff at TCP81 was some other service). You can also put a proxybased firewall inline with the NGFW device to further inspect the contents of the traffic (depends of course on how the proxyfirewall is being setup but still). There are some options which in combination can be a sufficient "workaround" to handle this testcase security wise.
... View more
