About mikand

I think currently the best option is to contact the appid team at reasearch center to get an official appid: http://researchcenter.paloaltonetworks.com/tools/ And until their work hits the appid-db, as a workaround, create a custom-appid which will look at the host part of the http request (using web-browsing or such as a base-app) along with an url-filter. Also dont forget the ssl-termination (dunno if Mega is compatible with this or not). ... View more

Using IPS is a classic chickenrace. You will never get 0% false-positives so it depends if you wish to protect your golden eggs (with a 95% or so probability to find bad traffic) but at the same time risk that some good traffic will be blocked aswell or do you want to allow all good traffic and by that allow 100% bad traffic aswell? A good default setting to find most bad stuff and at the same time lower probability of false positives is to use this setup as a start: critical: block high: block medium: block low: default information: default and then activealy monitor your logs to whitelist any verified false positives. An example (in informational which has default alert) is urls in pdf files. Today not uncommon, but at the same time a high probability that a bad pdf will contain urls. So blocking this would probably give you a high rate of false positives but at the same time, if you know that NO pdf's within your organisation should contain urls then you could put this particular threatid into block instead of alert. As a starter you could of course put all levels to alert mode and then followup each day to identify at least how many critical, high and medium threats you have today before you put them into block default. ... View more

I agree with you if the appid cache only looks for dstip/dstport instead of the full session which would be srcip/srcport/dstip/dstport (+ any transaction id's). A good example is as you already mentioned if you would allow facebook-chat but not facebook-upload, most likely both of them can use the very same dstip:dstport. On the other hand the same srcip:srcport could be used aswell... However if using a nat-device between the client and the PA-device would probably yield a different srcport for a different session. Perhaps someone from PA could bring some light into this? However only watching the videos doesnt necessary give you the full insight of whats actually happening. I mean the person recording the video could for instance force all its outbound traffic using the same srcport or such (like through a nat-router or so). Or these particular appid's used to pollute the cache perhaps on their own allows srcport >1023 compared to more restrictive appid's lets say ssh or such. Also watching the "Take 2" video now shows an url towards Image-Share - image-png-1981-170 which contains something interresting. To my knowledge if you setup two or more appid's in the same security rule and use "application-default" as service this would mean only the ports for each application would be allowed through. Lets say you setup "ssh, web-browsing" then only TCP22 would be allowed for ssh and TCP80 for web-browsing. Not allowing web-browsing to use both TCP22 or TCP80. If you setup the rules as in the picture above (multiple appid's and multiple services) then each appid will be allowed to use all of the services defined (in the above picture that would mean that sip would be allowed for udp/tcp53, tcp80 and tcp443 - compared to if the ruleset was as in the video saying application-default, then sip would only be allowed for udp/tcp5060). So an "editing glitch"? Depends on who you wish to trust ... View more

I think a combination of appid's with url-filter is always advisable specially when the domain(s) use a dedicated name and the application is http/https-based. Just compare with the app-id cache pollution during the xmas-holidays. If an url-filter had been used in combination with appid it would have been much harder to bypass the filter. ... View more

Isnt the stats available through the REST-api or such? This way you could at least as a workaround (until your feature request shows up in the PANOS ) create your own script to poll the PA-device and through the REST-api get the QoS figures as in cli/ssh. ... View more

Then unfortunately I think your current option is to implement a device similar to safesquid to do the rewriting of the urls. Check this thread (among others) regarding placing a webproxy inline with a PA-device: ... View more

No hits when I searched for that CVE in threat vault https://threatvault.paloaltonetworks.com/ However searching for networker gave me this: https://threatvault.paloaltonetworks.com/Home/ThreatDetail/31529 31529 EMC Legato NetWorker Remote Exec Service Buffer Overflow high CVE-2007-3618 EMC Legato NetWorker Remote Exec Service Buffer Overflow Overview     Attack Name EMC Legato NetWorker Remote Exec Service Buffer Overflow Description There exists a buffer overflow vulnerability in EMC legato NetWorker product. The flaw is due to improper boundary protection when processing RPC requests. A remote unauthenticated attacker can leverage this vulnerability by sending crafted RPC message to the target host, potentially inject and execute arbitrary code with System level privileges. Threat ID 31529 References http://secunia.com/advisories/26517 http://www.zerodayinitiative.com/advisories/ZDI-07-049.html Severity high Category overflow ... View more

According to this page google, yahoo and bing uses safesearch by get-request: http://www.safesquid.com/html/portal.php?page=137 Google: &safe=active Yahoo: &vm=r Bing: &adlt=strict So im thinking if its possible to create custom-appids which are based on lets say google-search but you add that the get-query must contain &safe=active (in the end of the line) and then only allow this custom_google-search for urls with *.google.* as url? However as long as you allow various anonymizers the clients can still bypass your restriction. Did you try to contact the app-id team at PaloAlto to see if they can create a better appid which would only allow safe-searches? ... View more

Note however that you will lose logs if you do factory reset. So if the logs needs to be saved its better to first contact the support in order to save them and them perform a factory reset. ... View more

1) I was talking about that when the packet leaves your Proxy (towards internet) the srcip will be the clientip (instead of the ip of the physical interface). Like so, before proxy: srcip: <clientip> dstip: <proxyip_insideinterface> after proxy: srcip: <clientip> dstip: <webserverip> I will check if squid can do the "keepsource=yes" feature and get back, otherwise there are other proxies which can do this. 2) Yes, you can specify which interface to use in Device -> Setup -> Services and then Service route configuration to define which mgmt-services should use the mgmt-interface and which should use one of the dataplane-interfaces. Edit: I found some info on how to do this with squid: http://wiki.squid-cache.org/Features/Tproxy4 http://wiki.squid-cache.org/ConfigExamples/Intercept/CentOsTproxy4 http://wiki.squid-cache.org/ConfigExamples/FullyTransparentWithTPROXY http://www.squid-cache.org/mail-archive/squid-users/200705/0443.html http://www.squid-cache.org/mail-archive/squid-users/200705/0447.html Some newer info regarding Squid3: http://www.deckle.co.uk/squid-users-guide/transparent-caching-proxy.html http://www.lesismore.co.za/squid3.html The device where I first saw this keepsource=yes feature was in the Farist Firewall http://www.tutus.se/products/farist-firewall.html ... View more

1) Keepsource=yes meaning that the proxy on its "internet" interface should use the client-ip as srcip instead of its own. How you do this depends on which proxy you are using. Which vendor and model (and if possible software version) is it in your case? 2) In order for the PA box to know the users (unless you want to use captive portal which I imagine you want to avoid) the PA must be allowed to speak to the PAN-agent server(s) on your inside network. This means except for rules client (inside) -> internet (outsice) in the proxy you must have a rule which will allow pa (outside) -> pan-agent (inside). The PANOS 5.x can use dedicated PAN-agent server(s) as previously. Whats new in PANOS 5.x is that itself contains a limited PAN-agent server (runned in the mgmt-plane) so there is no need for a dedicated server(s) in smaller networks. I dont remember the recommendation for using the internal PAN-agent server in the PA box but it was something like less than 100 users or such. If you network have several hundred or thousands of users the recommendation is to use dedicated PAN-agent servers (or install the PAN-agent service on each DC-server). You can of course still use dedicated PAN-agent server(s) even in small networks (just put that in your VMware cluster or such if you cant spare it a dedicated hardware or install it directly on the DC-servers). 3) The PaloAlto will do the SNAT meaning since the PA will see the clientips (which I assume is RFC1918 like 10.x.x.x or 192.168.x.x or such) the PA will do the NAT so this traffic on the interface facing internet will have its srcip replaced into the ip which the PA uses on this internet interface (or if you wish to replace it into some other ip or range of ips which is routed towards the PA by your internetrouter). ... View more

One drawback with captive portal is that you must use a browser (well for obvious reasons 😃 to identify yourself even if the actual protocol being used might be different (like if you use FTP or such to access this restricted zone). Also user-id in PA is global meaning (as I understand it) the PA device doesnt care on how it learned which user it is as long as it knows which user the srcip belongs to. This can however be workaround if the user/pass identification is a different user in the AD compared to the user normally authenticated against the AD. I mean regular access (which user-ids to allow) looks at AD\Users, while this enhanced security access look at AD\RestrictedUsers (where the useraccount in AD\Users is different from AD\RestrictedUsers) or for that matter from a different AD. The problem here might be that regular access might be smartcard based where accessing your golden eggs suddently only needs a basic user/pass auth (even if the pass is OTP based like secureid or such). So in your case I guess you want first the regular access and only if this passes then add the restricted access (which use user/pass(OTP or such))? Cant this be done in the AD itself? Because then the PA would only have to look at the proper AD-group to grant access to the more sensitive areas. Im thinking that a regular user first login with their smartcard or whatever. Then when they are logged in they can do a second auth to the AD using their OTP. The problem here might be that the PA currently only maps one user per ip. So as soon as the second useraccount (part of AD\RestrictedUsers) is authed the PA will no longer allow access to the regular services which checked for AD\Users. Or if this can be done at the loginpart of the workstation, if the user adds OTP info the user is identified for RestrictedUsers group otherwise it will just be identified for Users group. ... View more

I wrote some of the comments I received from PA earlier (see the post from 6 jan) at which might answer some of your questions. As I understand the app-id cache problem is basically two (well three depending on how you count) folded. For an existing session that gets offloaded the app-id cache value is a hint regarding "how was this session identified last time this box saw a packet which belongs to this session?". This gives for example that app-id cache says "sip". The packet, because of the value in app-id cache, will then be sent to the sip-decoder. Here is the second problem, the sip decoder didnt successfully identify that this packet no longer is a "sip-packet". And since PA is a NGFW and not a ProxyFW it means that if nothing is identified being wrong with the packet (or rule saying it should be dropped or so) the packet will be forwarded in its original state. And here comes the third problem (but might not count since its out of range for the PaloAlto device) - the server at dstip will interpret the bad packet and on its own handle it as a http request instead of a sip request. I think one way to imagine this is if you use ftp to upload a file which contains a full http header. Now assume that the file (with the http header) accidently turns up in its own packet. So if you only look at the packet itself you will only see a full http header. If PA didnt have any form of app-id cache you would most likely get a false positive where the NGFW would identify this particular packet as app-id:web-browsing (or similar) instead of app-id:ftp. Now regarding the ports the PA will intially work (in its flow) as a regular SPI based firewall. Meaning if srcip, srcport, dstip, dstport isnt matched by any rule the packet will be dropped. Now if you use "service:any" this check will never drop any packets, compared to if you specify "service:application-default" or for that matter "service:TCP12345". This gives that as long as you specify dstport (named service in PA) you will in most cases fix the third problem described above. For example if your rule allows appid:ssh service:application-default (meaning only TCP22 will be allowed) which also gives that the server at dstip must understand http if arrived at TCP22. This will of course not stop any manual evasive behaviour (a user who setup a http server at home that listens to TCP22 and accepts a few bad initial packets before it will find the http header to act on) but it will stop if you try to first initiate a sip session towards facebook TCP80 (or TCP443) servers if your allowing rule only allows TCP5060 and TCP5060 according to applipedia (was looking at appid:sip). Except for the above (knowing which decoder the packet should be sent to which according to PA gives a boost of up to 5% in performance) the app-id cache is also used for heuristics. I assume that is if a session in the first packet is identified as dns, the second packet http and the third as ssh then there is a signature for this behaviour aswell and the PA could classify this session as app-id:xxx. There is an description in regarding the new app-id settings found in 5.0.2 (and soon to be in 4.0 and 4.1 as I have been told) to fix the app-id cache polution. ... View more

What about my suggestion for a solution described in ? ... View more

The best solution is obviously to rearrange the flow in your case so it becomes: [User]-------[Proxy]-------[PaloAlto]------(internet) and by that configure your proxy to keepsource=yes and also allow PaloAlto to communicate with PAN-agent through your proxy (unless your PAN-agent is reachable over mgmt-interface). In this case the PaloAlto will do the SNAT. This way it doesnt matter if your proxy is a forward-proxy (preferred because you will then have only internal ip's between User and Proxy) or transparent (the difference is that with forward-proxy the clients use CONNECT with dstip as the Proxy ip while in transparent the clients use HEAD/GET/POST with dstip as the real server on internet). Another possibility, if you only have one set of PaloAltos, is to use VSYS (unless you have some policy which wont let you physically mix external and internal resources in the same hardware - meaning with VSYS you can let VSYS1 be the above internet firewall and VSYS2 will be some internal server firewall). ... View more