About PeterT

So let me start here fundementally all I'm trying to do is something like "Computer Y can access MS updates and nothing else" and my three pointers were:   https://live.paloaltonetworks.com/t5/General-Topics/Security-Policy-with-Service-URL-category-configuration/m-p/233176#M66885   https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClbvCAC   https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClHXCA0   Also as an asside let me say 1) i really hate how often PA KB's conflict each other or do things differently, i.e. is it really that hard to deconflict (i.e. check the URI's listed; yes I understand somebody just went * for one of them) and 2) Why people never do anything in Panorama as it makes following examples / screenshots a PITA; like simpy show/list both ways.   Anyways generally speaking what I want to know, and a search didn't really say anything, is exactly when does URL filtering kick in.  Does it kick in after a Service="ssl" or Service="web-browsing" match?  Does it kick in regadless of service context the first time it thinks it sees HTTP (or HTTPS)?  Basically what is the interaction between "service" and "URL categories".  For example if I say "service=web-browing deny; URL Catgory=allow list google.com" does it still let me to google? If say "service=webex allow; URL Category=webex_category deny" does it allow webex.com or not?  The specific interaction between those two times when licensed for both is pretty unclear to include OOP.  What if I HTTP to a non-standard port, does URL filtering still kick in if it sees HTTP on port 48123? etc.  Like I get the context of URL filtering IF service=web-browing (or service=ssl) when they are complimentary but not when it's they are dependency services or the OOP interactions when they conflict.   Fundementally in Panorama (to the point) I assume I'm just making a rule that says "allow service=web-browsing/ssl; block-categories all (67) allow list *.microsoft.com" which should work as long service doens't override it.  Either way documentation on this could be clearer. Lastly (since I'm here) do you EVER have to update the PAN-DB URL FIltering database (Device->licenses) or is this just a one time thing when you first activate your license never to have to do it again until it expires or you wipe the box?  It's the only license with an active/download status field hence I've always wondered on that given I can always 'download now' which I find odd as it suggetts it's something you may need to occasionally do but at the same time, it's not a dynamic update. I assume it just autoupdates somehow or it queries real time? LIke I've never understood on teh URL filtering side how those updates are handled. ... View more

In Panorama where are the adminsitrator access logs? I.e. if I want to see when a adminsitrator user last accessed the system.  I know where that is on the PA firewalls, but on Panorama?? ... View more

So our organization makes use of Google's cloud services as our email provider and it's a nightmare trying to control on the PA's as they don't accept wildcard's for IP's nor FQDN's.  Challenge here is Google seems to send emails (SMTP) to every **bleep** *.*.*.26 and *.*.*.27 address on the planet (1e100.net servers) and gets old coming in every day and adding more IP's to the "allow" list as they pop up (already up to 328 entries).  Anybody found a way to manage these? ... View more

Recently as part of our PA-3200 deployment been going through the joys of implementing NIST SP 800-70 configuration controls which in this case means the DoD STIG's (specifically Firewall and IDS STIG, v8 r17) and running into a problem which I noticed during my demo but didn't think much about it until now is a distinct lack of vulnerability rule documentation where is gets way down in the weeds.  A great example is ipv6-opts which block "IPv6 options" but which options? all of them? etc.  Anyways part of the config requirements is certain check box items must be met and the "NG" feature is irrelevant in this case .. not many but a couple so I'm hoping somebody can point me where to implement as opposed to "not supported".  Specific questions are (and some of this will be "how do I meet this compliance language"): PREFACE: Yes I have reviewed all the "IPv6" vulns and they simply aren't very verbose (or even named well), for example "ipv6" is really 6-to-4.  IPv6-frag might do what I need but I have no idea because "Fragment Header for IPv6" doesn't mean anything specific. 1) Drop Undefined IPv6 Header Extensions/Protocol Values (May be an intrinsic FW feature.) - Undefined IPv6 header extensions means that the Next Header type is not registered with Internet Assigned Numbers Authority (IANA).  The header extension is the same as the protocol value, and should be dropped.  Drop all undefined extension headers/protocol values. 2) Drop at least one fragment of any inbound fragmented packet for which the complete data set for filtering to include protocol/port values cannot be determined.(May be an intrinsic FW feature) - A FW must be able to properly enforce its filtering policy upon fragmented packets. This requires that the FW be able to find the complete set of header data including extension headers and the upper layer protocol/port values. It also requires that the packet not be susceptible to fragment overlap attacks. Fragment overlaps are a more serious problem in IPv6 than in IPv4 because the presence of extension headers can push the upper layer protocol/port information outward (toward packet boundaries) making it much harder to protect. How a FW achieves these requirements is not important as long as both aspects are met.  The wording “drop at least one fragment” used in the actions below is a statement of the bare minimum action to secure a packet, and is chosen to allow FW venders flexibility in achieving it. 3) Drop all inbound IPv6 packets containing more than one Fragmentation Header within an IP header chain. (May be an intrinsic FW feature) - Nested fragmentation is an unnecessary and unwanted IPv6 condition that is not forbidden by the specifications. It occurs when an IP header chain contains more than one Fragmentation Header implying that a fragment has been fragmented. In the specification, the phrase “IP header chain” rather than “packet” is used, because a tunneled packet has more than one IP header chain and each chain can have a Fragment Header (this case is not nested fragmentation).  Nested fragmentation is a new phenomenon with IPv6. It is not possible in IPv4, because the fragmentation fields are part of the main header and are modified in the event of a secondary fragmentation event.  Nested fragmentation in IPv6 should be dropped by FWs since internal nodes that process the fragmentation may or may not be equipped to handle this unexpected case.  These nodes may crash or behave in some unpredictable manner. 4) Validate IPv6 router advertisement suppression is enabled on all external-facing interfaces. 5) Firewall drops all inbound and/or outbound IPv6 packets containing a hop-by-hop option of option type 0xC2. [This go back to my ipv6-opts issue, I don't want to drop all options, just 0xC2] PS: Yes I know I can kill all of this with default deny/deny all/any at the end but looking for specific rules for compliance reasons. ... View more