About mikand

mikand · ‎04-14-2013

Not that much about SSL-decryption but a good document in general:

mikand · ‎04-14-2013

Isnt that what umphmharding already suggested? And the limit regarding maximum number of ip addresses one can handle in a PA-5000 seems to be 25.000 which is far less than the +200.000 needed.

mikand · ‎04-14-2013

Do you have "skype-probe" as allowed appid? Skype-probe is needed to be allowed for the PA to identify the skype stuff. Also incomplete means that the handshake didnt complete (for example a syn was sent but no synack returned) while insufficient-data means that a handshake has completed but not enough data to identify the flow. Also do you have ssl-termination enabled (dunno if that works for skype but in other cases its needed).

mikand · ‎04-14-2013

The main difference between "log on session start" and "log on session end" is: - Session end will display traffic volume (total bytes). - Session end will display the resulting AppID. The volume thingy is pretty obvious but the resulting AppID thing means that for example if you visit facebook the actual identifications might be (not correct but as an example): - unknown-tcp - web-browsing - ssl - facebook (that is if you have ssl-termination in place) The first three logs will be from "log on session start" while the forth will be from "log on session end". A drawback with "on session end" is of course that the log post doesnt show up until the session really ends but on the other hand if you wish to keep number of logrows to a minimum "log on session end" will bring you more info than "log on session start". So what one usually does is to enable "log on session end" for all security rules and "log on session start" on those you need to debug (and then turn off "log on session start" once the troubleshooting session is over). A quickfix in your case would probably be to just clear all logs and start over but since you opened a case I think its best to wait until the support returns to you in case there is a bug somewhere which must be fixed in the PANOS (but also to get an answer of why your logging behaves like this).

mikand · ‎04-13-2013

But that doesnt matter. The firewall (specially if its a modern NGFW from the 21th century) should be able to protect itself. That is force authentication before you can do anything remotely close to management of the device. That is default deny which all PA slides talk about regarding PA's security policy. Would be great if a PA representative could add some info in this thread regarding why 46728 doesnt show up on the Submit Form list? This security hole is as bad as the backdoor in DLINK equipment described in: http://www.devttys0.com/wp-content/uploads/2010/12/dlink_php_vulnerability.pdf Or for that matter the nice backdoor into TP-LINK equipment: http://sekurak.pl/tp-link-httptftp-backdoor/ More information about TP-Link backdoor

mikand · ‎04-13-2013

What one usually does to make sure that DHCP-clients doesnt put in rogue DHCP-servers or for that matter steal each others ip-addresses is to separate the clients from each other along with countermeasures regarding DHCP in the access-layer. That is: 1) Setup private vlan (or protected vlan) on the edge ports. This way traffic between two clients will be forced through your control nodes (that is either a router or a PA-device depending on your taste). Dont forget to also do the same for the uplinks (otherwise clients in the same building cant reach other clients but it will be able to reach clients in the other building (that is one switch per building or such)). 2) Enable DHCP-snooping along with DHCP-relay. This way any DHCP request(s) from an edgeport will be forced (as unicast) to your designated DHCP-server (this ip can of course be anycasted for redundancy in larger networks). 3) Dynamic ACL. The above (DHCP-snooping) often include a feature where the access-switch will keep track of the DHCP response and put that ip as allowed srcip for the particular edgeport. This gives that if the client tries to spoof an ip-address the access-layer will drop these packets. 4) Option82. When DHCP-snooping (or if it was DHCP-relay, I dont remeber) is being used you can enable Option82 which means that the access-switch will add its own name along with which interface the DHCP-request showed up at in the DHCP-request which is redirected to your designated DHCP-server. This information can then be logged in your DHCP-server which gives that you will see not only the mac-address and which IP the client was using but also where in your network this client was physically connected. That is client sends a DHCP-request. Access-switch use DCHP-snooping to intercept this request and by the configuration of DHCP-relay send this request as a unicast towards designated DHCP-server along with Option82 information (switchname + interface the request came from). The DHCP-server responds and the access-switch will use the assigned ip (for the client) as an ACL on the edgeport the client is connected to. This will efficiently stop any address-spoofing attempts. As a bonus you will now in your DHCP-server (if it supports Option82) have a log of IP + mac but also where the client was physically connected to your network.

mikand · ‎04-13-2013

Even if dynamic objects would solve the administrative hazzle they still doesnt seem to be the solution. According to the linked technote: "Each dynamic address object can have 256 unique IP addresses associated with it." This can of course be workedaround with some script-fu to create 782 dynamic address objects and put them into a single address group and put that into a single security policy... but then on the next page: " Each dynamic address object counts as one object towards the platform’s maximum objects threshold regardless of how many IP addresses are registered to that object. The maximum objects per platform and the maximum registered IP address per platform (for 5.0.0) are detailed below: Platform / Maximum Objects / Maximum Registered IP addresses PA-5060 80,000 25,000 PA-5050 40,000 25,000 PA-5020 10,000 25,000 PA-4060 and PA-4050 40,000 5,000 PA-4020 10,000 5,000 PA-3050 10,000 5,000 PA-3020 5,000 5,000 PA-2050 10,000 1,000 PA-2020 5,000 1,000 PA-500 2,500 1,000 PA-200 2,500 1,000 VM-300 5,000 1,000 VM-200 2,500 1,000 VM-100 2,500 1,000 " So back to square 1 😞

mikand · ‎04-12-2013

A discussion in a IRC-channel this evening was regarding the ongoing DDoS against wordpress installations all around the world and what to do in order to protect your webservers from the known bad ip addresses. Using ACLs in for example a modern Cisco router seems to only be able to handle something like 1-10k ace's depending on masks being used etc. Using iptables locally on the webservers seems to bail out after approx 30-40k lines with 10% cpu usage in kernel space for the linux kernel. So what other countermeasures can be used? A BGP based blackholing should be doable - however that only seems to block outgoing (returning) traffic from your network, it wont stop the incoming bad request (at least the syn will reach the server and then become hanging - while udp-traffic will be able to reach your server anyway). Unless im missing something here? Another possible approach could be to enable HostnameLookups in your apache-server and use something like: <Directory "/www/"> Options None AllowOverride None <Limit GET POST> Order deny,allow Deny blacklisted.example.com </Limit> <LimitExcept GET POST> Order allow,deny </LimitExcept> </Directory> and then in your DNS server make it authoritive for PTR records regarding the ip addresses you wish to block. When bad ip shows up your apache will ask the DNS for PTR-record of this host and if the answers from the DNS is "blacklisted.example.com" (or whatever you wish to call it) the apache will just drop the connection (perhaps with a http error 403 or such in return). Which boils down to why I created this thread... what can be used if you have a PA device in place? According to the datasheet the PA-5060 can use up to 40.000 security policies - but this is of course unique security policies. A single security policy could perhaps be something like: srczone: internet dstzone: dmz srcip: country(blacklist) dstip: webserver appid: any service: any action: deny option: log on session end or for that matter: srczone: internet dstzone: dmz srcip: group(blacklist) dstip: webserver appid: any service: any action: deny option: log on session end So the question is really is it possible and in which way can one setup a custom country (or a custom address group) to hold 200k+ members (mostly /32 ip addresses)? And as a sidenote - any efficient ways to keep this list easily up2date? There is for example methods to setup dynamic objects where the PA device will load a textfile from a webserver containing the ip addresses to act on as srcip (in this case) - or for that matter using the REST API to push (or withdraw) ip-addresses to blacklist. Will any of these methods work for a list that contains 200k+ ip addresses? Or does any of you have other suggestions mainly from own experience? 🙂

mikand · ‎04-12-2013

Sounds odd... The like two "newbie mistakes" are already covered by you: 1) It takes something like 15min or so before the ACC starts to index and stuff (or how many minutes it is nowdays). Which of course means that after 6 hours it cannot be this one... 2) The default is "view last hour" (if I remember correctly) which of course means selecting 6 hours or longer should display you some stuff (in case it were 6 hours ago you last had some traffic). What about internal clock - did it sync with NTP (or manually) some time after you had start to push traffic through the unit? Im thinking that the clock was incorrect and once set it had already pushed stuff into the db which means that you can either just throw away all logs and start over or just wait until it will pass the old time before new data starts to show up? I assume you have verifiied that you actually do have "log on session end" (or even "log on session start" as debug) on each security rule you wish to log?

mikand · ‎04-11-2013

Thanks for the headsup regarding the loadsharing algorithm to make sure its L2 or L3 and not L4 (that is loadsharing where srcport and/or dstport is involved would be bad). Another workaround to add for this might be to use: set deviceconfig setting session tcp-reject-non-syn no What about session-syncing? In your case you used A/A but wouldnt it be sufficient to use two (or more) standalone PA-boxes aswell? Configuration-wise this could be handled by a Panorama which pushes the same config (security policies etc) to both devices. Or is it possible to setup a HA-sync between two PA-boxes and only sync the config between them (like two standalone boxes but they share the same security policies)? Regarding the failover situation, when a link in the etherchannel breaks, Im thinking if im missing something with this assumption? *) Etherchannel is formed between R1 and SW1 where one link goes through PA1 and the other through PA2 (PA's running with VWIRE). *) Thanks to loadsharing algorithm set to L3-mode (srcip+dstip), or perhaps even better dstip going R1->SW1 and srcip going SW1->R1 (this would handle any appid's based on heuristics like skype or whatever), traffic for a specific server/client-combo connected to SW will always travel the same path (and by that the packets will be in order aswell etc). *) Now there is a linkfailure and the traffic start to pass through the other PA-device instead. If "set deviceconfig setting session tcp-reject-non-syn no" is set this shouldnt be any problem. However if AppID is being used this could force an ongoing session to become blocked on the other PA (the one which the ongoing session is now being sent through) after a few packets (which of course would be bad) depending on which AppIDs are being used of course? If this is true then A/A seems to be the only option to make this work - or how is it supposed to work in the design described in the following docs (or am I missing something here)? http://www.paloaltonetworks.com/literature/solution-briefs/tech-partners/arista.pdf http://www.aristanetworks.com/media/system/pdf/palo_alto_networks_arista.pdf

mikand · ‎04-11-2013

Hopefully someone from PA will see this thread and create such document? 🙂 Closest to your request today is: (look at page 4) along with http://media.paloaltonetworks.com/documents/techbrief-app-id.pdf and http://media.paloaltonetworks.com/documents/techbrief-content-id.pdf but these docs are more into the flow of a packet and not necessary the architecture of the hardware (regarding dependencies). There are also some slides in the PAN-EDU-301 course which somewhat shows what happens where but still not on the level as your example. Even if PA has one mgmtplane and one dataplane (well sometimes several DP's) there are still dependencies between them. For example if you use url-categories and the url doesnt already exist in the DP cache then a request is made towards mgmtplane which will perform the lookup if im not mistaken. Same goes with userid-stuff. Which gives that during a reboot of the mgmtplane, even if dataplane is separate, then new sessions (during the time the mgmtplane is rebooting) might be blocked depending on how your rules are setup (like if they use userid and/or url-filtering and the item doesnt already exist in the DP cache).

mikand · ‎04-10-2013

A workaround might be to use syslog or something from which you can fetch the user/ip bindings and push into PA using XML API.

mikand · ‎04-10-2013

One can find in the datasheets various limits regarding VSYS (where some models wants an additional license) but what about VWIRE? Are there any limits regarding number of VWIREs one can use for each model (I assume the VM-models doesnt support VWIRE at all)? Also, are there any drawbacks of putting various VWIREs into the same zone (or is this even possible)? Im thinking of an example such as: R1 / R2: outer devices PA1 / PA2: PA-devices running 1:1 VWIREs SW1 / SW2: inner devices and then that R1/R2 will form etherchannels with SW1/SW2 where PA1/PA2 uses VWIRE to be fully transparent. In a full-mesh version that would mean that PA1 would need something like: int1: R1_11 int2: SW1_11 int3: R1_12 int4: SW2_12 int5: R2_21 int6: SW1_21 int7: R2_22 int8: SW2_22 That is the aggregating group 11 (formed between R1 and SW1) would have one cable through PA1 and one through PA2 and so on. The above ends up with 4 x VWIREs. What Im thinking of here is if there would be any problems of setting up the zones such as: zone_outer: int1, int3, int5, int7 zone_inner: int2, int4, int6, int8 Edit: Also what is your experience of a setup such as the one above?

mikand · ‎04-10-2013

What about creating a new VSYS on your PA device and attach 2 interfaces to it which you configure as VWIRE and then plug that between your DNS and the rest of the network? Oh and in this VSYS configure it only for alterting to not disturb the flows (that is unless you wish to block the queries with the help of the PA).

mikand · ‎04-10-2013

Not in my opinion. Putting the proxy inline (that is client <-> proxy <-> PA <-> Internet) is the best option along with "reflect srcip" / "keepsource=yes" which would make that not only the srcip will be accurate in the logs of the PA but also that the PA can do userid, appid, ssl-termination etc. If you put PA in front of the proxy (from the client perspective, that is client <-> PA <-> proxy <-> Internet) then the appid will always be "http-proxy" and you wont be able to use ssl-termination either (and by that become vulnerable for all the SSL-based malware out there). A workaround (if you want it to be client <-> PA <-> proxy <-> PA <-> Internet) is to do as I described earlier with two vlans for the proxy, one outer and one inner vlan - this way you can still use the "reflect srcip" / "keepsource=yes" (and use aggregated interfaces to get redundancy instead of a single cable) with the downside of twice as many logs in the PA and only able to do half the number of concurrent sessions (because each session will be seen twice in the PA, first the session client -> PA -> proxy and then the proxy -> PA -> Internet).

Member Since	‎03-30-2010 08:39 AM
Date Last Visited
Posts	1,446
Total Likes Received	496

About mikand

Re: What is your experience of using site-to-site VPN with PA devices and how is the performance?

Re: Azure VPN Tunnel configuration MTU adjustment

Re: What the different between 'count' and 'repeat count' in the report?

Re: HA Cluster different transceiver type on each firewall

What is your experience of using site-to-site VPN with PA devices and how is the performance?

What tunnel options do you have for site-to-site using PA devices?

Re: PAN response to: Attacking Next-Generation Firewalls: Breaking PAN-OS ?

Re: PAN response to: Attacking Next-Generation Firewalls: Breaking PAN-OS ?

Re: PAN response to: Attacking Next-Generation Firewalls: Breaking PAN-OS ?

Re: PAN response to: Attacking Next-Generation Firewalls: Breaking PAN-OS ?

PAN response to: Attacking Next-Generation Firewalls: Breaking PAN-OS ?

Re: Feature Request

Re: When should I use a non-tunnel mode gateway with GlobalProtect? Also: license needed for HIP? SSL vs. IPSEC?

Re: Pc does not join into Domain

Re: Overcoming an application filter and url groups

Re: Encrypted and Zipped files with virus in it

Re: skype video call insufficient-data

Re: How to efficiently block shitloads of ip-addresses?

Re: skype video call insufficient-data

Re: "No matching record" in ACC after initialy using the PA-device

Re: Does Palo Alto issue security advisories for security related fixes in patches/updates?

Re: Unauthorized DHCP offers

Re: How to efficiently block shitloads of ip-addresses?

How to efficiently block a large number of ip-addresses?

Re: "No matching record" in ACC after initialy using the PA-device

Re: Limits of VWIRE?

Re: Planes

Re: can Iplanet Directory Server be integrated with Palo Alto?

Limits of VWIRE?

Re: Suspicious DNS Query - how to find source computer?

Re: Dual ISP's - How to PA-500

Unlock your full community experience!

About mikand