About mikand

Got an answer from "my" sales engineer that the fix for the above case will be available in the Version 336 Content Release. ... View more

Hopefully this is already addressed in soon to be released PANOS 5.0 which will have the "preauth" capabilities (using a machine cert to setup the global protect tunnel so its up and running when the client logins to the AD which then UserID will be able to pick up). This way you can setup security rules where userid=preauth to let those boxes to WSUS and AV-update servers and not until the user is actually authed to the domain they will be able to pass specific userid rules or where userid=known-user. ... View more

Perhaps thats why the 3000-series are coming in order to replace the 2000-series regarding commit times (in reality more ram and faster mgmtplane cpu to lower the commit times from 20 minutes or more to sub minute)? ... View more

Respond to that threat by asking for srcip and srcport used on their side (and when they replies with this information you can search for it as dstip and dstport in PA logs). If they refuse to answer then throw this threat to /dev/null. ... View more

Is UserID ignoring this for a particular reason or would a feature request through the local sales engineer change this behaviour? Edit: In PANOS 5.0 if im not mistaken Globalprotect will have a similar feature where you in the security policy can choose "preauth-user" as userid (compared to todays known-user etc). ... View more

Can someone from PA confirm that this bug has already been dealt with? 2012-10-24 02:46 Version 335 Content Release Notes Application and Threat Content Release Notes Version 335 <snip> Modified Decoders (5)       Name       freegate       http       gtalk-file-transfer       ssl       sccp ... View more

Really good question The manual doesnt really explain this: target Configures and shows a management session target. Syntax target {set <value> | show} Options > set — Sets the target device > show — Shows the management session target Sample Output The following command displays the management session target. username@hostname> target show TBS username@hostname> Required Privilege Level superuser, vsysadmin, deviceadmin Edit. Could this have to do with either VSYS or when you work in Panorama? ... View more

Dont forget to setup DHCP snooping (along with Option82 for logging) and DAI (Dynamic Arp Inspection) so your box you want to limit just not changes its ip address manually and connects to the network to bypass the filtering. ... View more

The reply I received from "my" sales engineer was that this is a confirmed bug in the http decoder and a fix will be released shortly. My sceptism comes from years in this business when you will learn that things are not always as they first showed up as (same goes with PA for that matter 😉 Regarding this specific blog post, yes (and I already said this) its great to point out bugs and other misbehaviours from equipment - but an even greater lession (which the blogposter seems to miss) is how NOT to setup security policies (in production). There will most likely be more of similar findings in future and having an "any any allow" as last rule will always make you vulnerabile to this and similar bugs. Another lession which should be learned is of course that you cannot trust a single box. You must have a design to when shit hits the fan so the spreading will be limited or can even easily be quarantined and mitigated. Unfortunately thats not how most corporate networks looks like today where clients can (in most cases) without problems reach each other and the network is basically flat (with hopefully at least the servers segmented away - but then the servers can reach each other instead and bad things can continue to happen on your inside). ... View more

A workaround could be to have the switch/routers before/after your cluster of PA's to do the loadsharing instead. This way each PA is a standalone setup (you can use Panorama to get the same security policies out to the boxes) as described in: http://www.paloaltonetworks.com/literature/solution-briefs/tech-partners/arista.pdf (this can of course be aschieved with other components than Arista equipment - as long as your aggregated interfaces uses srcip as loadsharing hash on one end and dstip on the other, that is so the traffic will always takes the same path until that path fails and gets loadbalansed to another path) The drawback is of course if you have fully utilized both paths and one path fails then you will get packetdrops because there is not enough of bandwidth available between outer and inner router/switches. Another drawback is because each box is standalone then there is no session sync which gives that when box1 fails and all traffic goes through box2 then the clients who previously had their sessions through box1 will have dropped sessions and must reinitialize (which shouldnt be a problem but there are plenty applications out there who just cannot deal with that their tcp session suddently must reinitialize). ... View more

I do hope you did notify your sales engineer regarding this as a feature request? I think the f**k up comes from that the PA-200 is a desktop device (fanless and all that) and not necessary a rackmounted device. But I totally agree with you - the brackets (to make PA-200 fit in a 19") should be included free of charge (just as with the other models). ... View more

Im always a bit sceptic to closed source "disclosures" because there is often one or more "tweaks" not being mentioned that makes the particular example to work: " I will not publish the source code, the server script has been written in Perl, and the client one in C#. " I mean in theory this person could just have manually disabled L7 detection in the PA which of course basically disables appid ability to track changes in a single session. In this blog I also later found out about two drawings explaining the overall design of this evasion however no details are really being showed: http://www.what2code.net/wp-content/uploads/2012/07/serverforwarder.png http://www.what2code.net/wp-content/uploads/2012/07/clientforwarder.png Given that the two pics you linked to: http://www.what2code.net/wp-content/uploads/2012/07/3.png http://www.what2code.net/wp-content/uploads/2012/07/4.png are in the same session we can still see that there are missing some data between them two. It seems like the server answers with a real gif-picture but in the end of the packet injects some SSH server code. To which the client then replies with its own version and a SSH-handshake is being performed. So questions which hopefully PA can answer: 1) Does this show a bug in the http-decoder/appid-engine? 2) Would enabling IPS react to this sudden "SSH-2.0-OpenSSH_5.5p1" in the middle of the http-transaction? Regarding your comment to 1&4) Well the case was "we want to block ssh" according to the post, not "we want to block ssh and allow everything else including web-browsing". Because if you alter the security policy to allow web-browsing then why not at the same time alter the policies to also enable the builtin IPS? Or for that matter create your own IPS signature to block traffic where "SSH-2.0-OpenSSH_" is being seen? I also wonder if this really can be fixed. I mean the server reply which is a binary file such as a gif could of course contain a string such as "SSH-2.0-OpenSSH_", so PA cant block traffic based on that (due to high probability of false positives). However the client response along with the ssh-handshake should be detectable - which is also why I would like to see the same test with the IPS enabled (because the IPS acts on allowed traffic). I think its good that bugs (with the disclaimer that this is a bug) are found and fixed - but the blogpost is slightly more of a tabloid news paper style which leaves out several details not to mention that almost noone would use a "any any allow" as a default last rule in a firewall. I mean the specific finding cannot be verified by anyone else since the source code is not being published (which when you come to science is like the major issue - whatever you find shall be able to be reproduced by somebody else). And regarding 3&5) to my knowledge various protocols have various ways of identifying what kind of application it is. If the session is offloaded to the http-decoder and the http-decoder fails to detect that this is no longer the same http-session containing http-data then there is a bug in the http-decoder. According to the answer from "my" sales engineer the PA do verify appid's even in already verified sessions from time to time. Another sidenote... by default PA logs on session end... during debugs you often want to enable on session start to see how the appid's is being switched such as unknown etc. I wonder if there would be the same result in the log if both on session start AND on session end would be enabled? A possibility could be that the appid when tcp-session is closed is web-browsing, but until that there were perhaps both unknown and ssh (but not shown and due to "any any allow" they are allowed)? Oh and regarding "locking web-browsing for users would be hard, would it not?" - not at all, use a terminal server solution where the terminal servers are locked down and voila, the users have no direct communication to the internet from their client stations and you as the admin have control of the client environment (as in the terminal servers). ... View more

OK, so if AppID=Any and Service=Custom (TCP / UDP / Port number / range) then the device works like a traditional stateful firewall (even if AppID classifies the traffic as unknown)? Yes and no. Appid is always active in the background - but this particular rule will just ignore whatever appid the session is being identified as. There is also a sales slide with a brief description on what the PA will do on a packet which arrives on one of its dataplane interfaces. The first thing (according to this slide) which the PA does is to verify the ip header in terms of srcip, dstip, srcport, dstport. If there are no security rules which matches these items then the packet is dropped right away. But if the packet is accepted then all the shebang of appid, decoding, heuristics etc is performed in what the marketing people calls "single pass engine". So in this case the flow is: 1) Verify ip header (do we have any security rule which might match the ip header?). 2) Detect appid etc. 3) Now go through the security rules and see if the packet should be allowed or not. Would that approach be a viable option for a migration in large enterprise environment with a lot of firewall rules allowing proprietary applications where no signature for AppID exists (inhouse application, niche applications). At least for a transition phase until a custom AppID definition can be created or research can be done what is actually transfered over the connection (may be with help of the log or reporting). Except for what umphmharding already said you wont make it worse by just doing a 1:1 replacement. However the point of getting a PA is in most cases to improve the security but at the same time if you do this in small steps then it will most likely be easier to troubleshoot. Otherwise if you do everything in a single service window and problems arrives (not necessary due to the PA but more likely due to app developers being detected doing things they are not allowed to with their apps like pushing SSH over TCP80 and such) there will most likely be one or another blame on "yeah its that PA's fault". So if you start with just do a 1:1 transition on srcip, dstip, srcport, dstport and see that being stable for a week or so the next step will be to, along with the reports from PA device itself, start to limit each flow (security rule) by enabling appid. And the final step will be to enable IPS, AV, blocking of files etc (unless you do this rule by rule in step 2 above). Another question: Web Server in DMZ hosting web sites, which application would you use here to allow connections from public Internet to the web server in the DMZ: web-browsing? That sounds inappropriate but there is no web-hosting application in applipedia? You could as a start just use a security rule for your DMZ server where you set "appid=any" and then look in the logs (or create a report) where you see how the PA identifies this traffic and then apply just that appid for this particular security rule. If you use HTTPS I would strongly advice you to read up on the SSL termination features of PA so the PA can inspect the encrypted traffic aswell. For other cases you can also contact the appid team at PA if you have an application which isnt being identified by PA and this team will either create a custom appid for you (available through regular updates but only your boxes will see it) or make it commonly available for everybody to use. You can also create your own custom appid's (and IPS signatures which are similar) without involving the appid team. Edit: WTF - the quoting works in edit mode but not when I save the post :S ... View more

For example (replacing current FWSM with PA): FWSM(1?) outside: 3.2.4.4/29 FWSM(2?) outside: 3.2.4.5/29 FWSM outside floating: 3.2.4.6/29 In this case you will use 3.2.4.6/29 on the outside interface of your PA. While: FWSM(1?) inside: 1.2.1.4/29 FWSM(2?) inside: 1.2.1.5/29 FWSM inside floating: 1.2.1.6/29 means you will use 1.2.1.6/29 on the inside interface of your PA. The above gives that you wont need to alter any routes (nexthop ip's). However if you like you could shrink the networks down to /30 but not if at least one of the sides uses HSRP (because HSRP needs two physical ip's and one floating (which will be used by the current active HSRP device)). ... View more