About gwesson

> Couldn't one block the "search" category though, and allow google as an exception?   Probably not, because like Google the services are much more than just search. You could cover many examples, but someone logged into live.com to view their hotmail account would likely be able to do a bing search from inside their email. The user isn't on a search site, and they didn't make a new connection to bing.    I'd say start with the DNS method you linked in the first post on this thread, and push for decryption as a more full solution later.   Cheers ... View more

Blocking outbound DNS from students would also need to be blocked, or else they'll just point their DNS queries to an external resolver.    Without SSL decryption though, you'll be chasing this a lot. A student forced to use google safe search may decide Bing is just fine for them (or DuckDuckGo, or Yandex, or... etc.). Longer term I'd recommend looking into the decryption end. You'll get a lot better enforcement if you can trigger on every request rather than just the requests in clear text. ... View more

Nope, every initial packet will get Layer 7 inspection. It makes sense if you know the flow - if it has enough information to know it doesn't match any app, then it's already done the L7 inspection.   If no app is matched, you'll see the app listed as "unknown-tcp" or "unknown-udp" depending on the underlying protocol. That is fairly rare though, as the app-id database is pretty expansive. ... View more

@TranceforLife Every once in a while I can be a post ninja, but you usually beat me 🙂 ... View more

Those are actually two different fields.   Rate is the number of packets per second for the duration you've run. So if you run the counter command after 5 seconds and the total number of counters is 1000, then your rate would be 200 (1000/5 seconds). Severity is the type of counter: flow, drop, error, info, etc.     In your example, the first counter has 27215 as the value, 0 as the rate (none incremented since the last time the counters were displayed) and drop is the severity. Same explanation for the 2nd counter.   Hope this helps, Greg ... View more

Your first rule will match all traffic initially when evaluated, because the first packet is not enough to identify the application. Every time the application shifts (as the firewall learns more about the traffic with subsequent packets) it will re-evaluate the rules.   Think of it this way: 1. The firewall gets a packet on some port that *could* be docstoc-base. The rule has "any" for everything else, so it goes ahead and transmits the packet tentatively matching the first rule. Remember app-id has not been completed yet so nothing will be denied yet 2. One or several more packets arrive, and the firewall now sees that the traffic is something that can still shift to another app, like web-browsing. The firewall re-evaluates the policy again, and this time only rule 1 could possibly match (maybe you have other rules for other apps). 3. More packets arrive, and the firewall can now determine that the app is NOT docstoc-base, and with no other rules matching it finds the intrazone-deny rule.    Because the traffic last matched the first rule, which was an allow rule, that's the rule that is shown.   If the firewall was unable to match any rules on the first packet, you would see the "not-applicable" app and it would hit the intrazone-deny policy.   To address your bullet points:   You can always deny a specific app regardless of whether or not you define the zones/addresses in the rule. The firewall itself cannot determine the app until the zones/addresses are evaluated, but that happens with that first packet. It's just that the app won't be known on the first packet. Sort of. If your policy has a zone/address and an application, and the rule is set to deny, it won't actually hit that rule and deny the traffic before the app is determined. The exception to this is if you define the port. The app is irrelevant if you're denying the port as well, since it won't matter what the app turns out to be if you're going to deny it anyway. See my first point above. It passes the first rule but tentatively shows it as matching since the app hasn't been determined yet.   You might want to take a look at the life of a packet document. It goes through a lot of the deeper details about this whole process: https://live.paloaltonetworks.com/t5/Learning-Articles/Packet-Flow-Sequence-in-PAN-OS/ta-p/56081   Best regards, Greg edit: formatting ... View more

If your HA peer is up and reachable, you could add a management profile to one of the DP interfaces as suggested earlier to the peer device and commit that change. Config sync would go over HA1 or HA1-backup (if configured). Then you can SSH into the DP interface without having to go to the device physically if there's no console server. ... View more

You will lose it, but the firewall gives you the option to import the Panorama-pushed items before you do so:   ... View more

@VinceM and @TranceforLife are both correct.    When the first packet arrives, it looks to see if it matches your first rule (IT_Deny). If you're attempting to block sites like bbc.com and cnn.com, the first packet will just be a SYN packet on port 443. That SYN packet is not enough to identify the app as SSL for the app-id engine (even though eventually it will be identified as such). Since that first packet doesn't get denied, it won't match that rule until an app-id shift.   When your first TLS packet arrives at the firewall (Client Hello, likely containing the server name) can now identify that it is cnn/bbc, and deny it based on your URL filtering profile. The traffic was being processed on rule 2 (IT_Allow) at the time that information was available, so that's what it matches in your logs.   If you're set on having a deny policy for this, add the category to the IT_Deny policy. But it won't give the user a nice category deny page, instead it'll just drop the packet. It's generally much better to allow the traffic and use the URL filtering profile to handle what is denied and allowed. ... View more

You can also just view (and export if you want) the config logs.    Monitor > Logs section > Configuration.   Each change is documented, and it contains what was edited before commit too in case you want to see what each edit was. ... View more

The answer is actually in the recent update: @BPry wrote: Attackers might be trying to steal your information from yyyy.com.proxy.mycompany.com (for example, passwords, messages or credit cards). net-err_cert_common_name_invalid   Hide Advanced This server could not prove that it is yyyy.com.proxy.mycompany.com ; its security certificate is from *.proxy.mycompany.com. The certificate on the proxy is wrong. Each "dot" is literal when it comes to wildcard certificates. If it's for *.example.com, but the URI requested is alpha.bravo.example.com, then it won't match. If you want to match on those, your cert would need to have a Subject Alternative Name field of at least: *.example.com *.*.example.com   Each subdomain level needs a separate *. for itself.    The reason you're getting the HSTS message is that you had previously gone to the site in that browser and it pinned the certificate from before. ... View more