topic Re: PA and icap? in General Topics

PA and icap?

migration — Wed, 23 Feb 2011 08:09:18 GMT

Hello world,

is there a chance/way of talking icap between my squid and the PA?

Thanks a lot

Marcus

Re: PA and icap?

rapoint_person — Wed, 23 Feb 2011 08:20:36 GMT

No, but can you solve whatever you want to do with PBF? Tell us more!

Re: PA and icap?

amansour — Tue, 19 Jul 2011 18:13:36 GMT

yeah I need to setup an ICAP server to SQUID as well, did PBF do this for you? Could you send block pages from PA directly?

Re: PA and icap?

amansour — Thu, 18 Aug 2011 14:50:11 GMT

Any updates. We have a number of customers that run 3rd party DLP and want to eliminate their proxy and ICAP, if we can do policy based forwarding or receive messages like ICAP we can send the pages from PA, which would truly make this a proxy replacement.

Re: PA and icap?

jmahoney — Thu, 18 Apr 2013 17:38:16 GMT

2 years later and this is still on my wishlist. Working with a solution like RSA DLP is impossible with a Palo Alto. It's a huge problem in helping customers build a comprehensive DLP strategy. The PA built in DLP doesn't do enough and the solution of "just block Dropbox and Gmail Send" isn't really an option for most customers.

Re: PA and icap?

amansour — Thu, 18 Apr 2013 17:48:41 GMT

@jmahoney I think this will never make the roadmap. ICAP and WCCP are forwarding for proxies (HTTP/HTTPS/FTP) that's the problem. PAN does all protocols all the time, they can't proxy, there not a proxy, the developers likely cannot make this happen. I think network based DLP better get more protocols to stay relevant on the wire which is why ICAP is no good.

What I do is instead you should look at a re-generator TAP. Then tools which need to see all the traffic to do their job can have multiple copies (DLP is a great example, RSA Netwitness and other recorders like Niksun too).

Then everyone gets a copy and is happy. With respect to blocking (the ICAP forward) the DLP integration would likely have to create a flexible response (Symantec DLP does this) where you could send something to the XML API, like you could with a proxy filter (Websense) or MTA and SPAM filter. Each response is going to be specific to the type of block and in the PAN case I think that's an XML-API call.

Anyway my two cents. Have the DLP bend the response because proxy is dead and they will be too if THEY don't adapt.

Re: PA and icap?

amansour — Thu, 18 Apr 2013 17:51:50 GMT

Oh yeah and for anyone wondering. PBF doesn't do it. It send routes out an egress, ICAP is different than routing in the DLP world because the DLP can mark up ICAP like it cal SPAM X-FORWARD messages. PBF Doesn't allow this so unless your DLP tool (Websense has a few articles on this) can do that then you're out of luck.

Re: PA and icap?

dyang — Thu, 18 Apr 2013 19:01:56 GMT

amansour is correct - since we are not a proxy nor do we intend to be one, we will not support ICAP.

Re: PA and icap?

mikand — Thu, 18 Apr 2013 19:23:00 GMT

So how do you explain the SSL/SSH-proxy and DNS-proxy? :smileysilly:

Re: PA and icap?

amansour — Thu, 18 Apr 2013 19:52:30 GMT

@mikand, they should have probably labelled it forward instead of proxy. SSL and SSH also misleading but proxy in our DLP case means re-write. It terminates the session and re-establishes it which can work for protocols like http, https, ftp but not all applications. Those proxy features forward traffic they don't re-write it. I think It's also why the GlobalProtect portal is only somewhere you can download the agent and not put links or content that is re-written to the internal segments like other SSL-VPNs.

Also Nice Pantopia score

Re: PA and icap?

jmahoney — Thu, 18 Apr 2013 23:42:36 GMT

Dyang, my recommendation is that Palo Alto work with top DLP vendors to figure out some sort of DLP solution, doesn't have to be ICAP. The Palo Alto strategy is not realistic for most customers and I've seen PA lose a number of engagements to customers who want a real DLP strategy. The fact that Palo Alto doesn't integrate with anyone out of the box is an issue. I haven't run into a customer yet that wants to create custom connectors with the API. If you put anything in Gartner, which I don't, at least Checkpoint has a more robust DLP strategy.

That's just my 2 cents. We work with a ton of customers and a lot of PA customers and this (and global protect) are my only two complaints against the platform.

Re: PA and icap?

dyang — Thu, 18 Apr 2013 23:54:54 GMT

Agreed - we have reached out to vendors such as Symantec to see if there's something that we can do to at least provide a viable solution for our customers. We have not made any progress to-date, but you'll certainly hear about it once there is something to report!

Re: PA and icap?

mikand — Fri, 19 Apr 2013 01:39:20 GMT

Regarding those scores, thanks 😉

Regarding those proxies another example is wildfire.

Even if PA hardware design most likely cannot be used with a ICAP and then continue (that is client click on a link, PA downloads the file, sends it to ICAP, gets the response and if negative (that is nothing bad was found) it will forward the file to the client) at least not with +10Gbit/s speeds (because the mgmtplane would need to be part of this) it perhaps should be possible to make it a one way the same way as with wildfire (this way, as with wildfire, the files can be buffered by the mgmtplane and it in some extend doesnt matter if the file was scanned now or a few seconds later (due to high load)).

That is client downloads file but instead of sending it to wildfire the PA device will send it as ICAP to a ICAP server. The response will then later be attached to the log. This wont bring you DLP (as in prevention) but at least DLD (as in detection) - the question here might be if this is enough (at least it would be enough for those who accept DLD)?

Perhaps something for PA to consider for upcoming hardware releases?

Same goes (if we speak about DLP) with that 7 bytes limit (your signature must look for 7 bytes or more)...

Re: PA and icap?

amansour — Fri, 19 Apr 2013 13:33:39 GMT

Hey All I have the Symantec DLP 11.6 deployed with PAN in a few places. For the integration Symantec uses PCAP (SPAN or Mirror Ports to do network detection and the response is to markup the messages (ICAP and X-Forward for Web and Email) What we recommend is creating a FlexReponse (Symantec Specific) which makes an XML call can take a quick action on the user (so far this isn't fast enough to stop because we don't have a way to instantly send the user a block page or at least haven't found it). @jmahoney I think we should put a thread together like the SIEM one with a point person assigned for each DLP platform. Just like ArcSight and RSA and others put their SIEM integration and docs on the forum there should be an integration for each documented here.

For Symantec Email Prevent there is no integration required, for Web Prevent this ICAP integration will likely need to be supplemented with a better FlexResponse.

As for the others, without ICAP we'd need a way to call the XML quickly to do something, (Block URL is the most common). But without doing a commit.

Anyway happy to work on this with you guys on it we are a CPSP and ASC and Go to Partner with Symantec DLP at least.

Re: PA and icap?

coldstone2 — Thu, 23 Jan 2020 18:58:16 GMT

I'm curious whether anyone is using the PANOS L3 security broker service -> Proxy supporting ICAP -> Symantec Network Prevent server. I've heard this design works with PANOS, F5 > v14 and Symantec DLP NWP 15.5.

Re: PA and icap?

BobbyHiers — Fri, 03 Sep 2021 19:58:18 GMT

We just implemented that design with their new version of Security Broker called Network Packet Broker in version 10.1.X. We used the NPB to build a transparent bridge that sends all traffic (decrypted and clear text) through the bridge into our DLP and back out into our Palo. Works really nice!