About gwesson

gwesson · ‎08-07-2018

You can add comments to the list itself. The only requirement is that there is a space after the IP. Here's the documentation talking about syntax requirements for EDL: https://www.paloaltonetworks.com/documentation/71/pan-os/pan-os/policy/formatting-guidelines-for-an-external-dynamic-list The most relevant bit is: The external dynamic list can include individual IP addresses, subnet addresses (address/mask), or range of IP addresses. In addition, the block list can include comments and special characters such as * , : , ; , #, or /. The syntax for each line in the list is [IP address, IP/Mask, or IP start range-IP end range] [space] [comment] That said, as @BPry eluded to the comment won't show up on the firewall. The comment only exists in the list source, but if it's something you control anyway you can add the comment there.

gwesson · ‎08-07-2018

It can be simple, but it depends on the CA. I'm not all that familiar with how Thawte works these days, but most public CAs have the option of just renewing now instead of having to submit a new CSR. If you do have that option at Thawte, have them issue the new certificate to you. When you get the PEM or DER cert, just import it using the exact same name as the one you're renewing. When you do that, the import overwrites the public key only, leaving your existing private key in tact. If Thawte requires a new CSR, then it gets more complicated. I find it easier to just generate a brand new CSR and just update the certificate profiles and such to the new cert. If you still have the original CSR you submitted to Thawte, you can actually resubmit that same one and the signed cert should import just fine.

gwesson · ‎08-03-2018

The operation is to apply a bitwise AND operation to the number logged (0x19) with each value from the documentation image posted. If the bitwise AND result is 0, then then the documentation detail is false. If it's 1, then it's true. 0x19 AND 0x00400000 = 0 (no NAT applied) 0x19 by itself doesn't mean anything, it's just a value that can be ANDed to produce a result of zero for each of the types there are. As @Remo mentions, another set of flags will produce a different result. On my logs, I have NAT enabled, so my logs flags are: 0x400019. When I do a bitwise AND operation on that and 0x00400000 I get a non-zero result, meaning it's "true".

gwesson · ‎08-03-2018

Do you mean to block from a specific source by client hostname? The client's hostname is never sent as part of their HTTP request, so there would be nothing to trigger on there. I'd recommend setting up user-id so that you have the username logged into the kiosks and can simply apply a URL filtering policy. If you're going TO a site with the name "kiosk" in the host header, you can set up a custom vulnerability or spyware signature using the host header as the context and a regex of "..kiosk0.+" (not tested) that could trigger for you.

gwesson · ‎08-03-2018

If the 3-way handshake completed, you shouldn't see "incomplete" as the application. It should be "unknown-tcp", even if there is no data. At a minimum, you should be seeing around 6 or 7 packets depending on how the TCP session is closed. Are you seeing that many frames in your sessions for these health checks? If I remember correctly from my years with BlueCoat, there are a couple options for health checks: simple TCP handshake, or full request/response parsing. If you have an option for the more robust checks that may help. Since you know it's just a health check and you never have to worry about inspecting the traffic, you could also just set up an application override policy for the traffic to ensure you don't even enter layer 7 checks.

gwesson · ‎07-31-2018

As long as you're using an official PAN SFP and the other side is configured with something compatible you'll be fine. 3rd Party transceivers on a PAN device might work, but aren't officially supported. It can be a challenge (putting it lightly) trying to troubleshoot an issue when using a 3rd party part, so there's a policy about that: https://www.paloaltonetworks.com/services/support/support-policies/third-party-components-support There's a PDF of the specs on the various transceivers here. It's broken down by platform, so it should make it fairly short work to review: https://www.paloaltonetworks.com/services/support/support-policies/third-party-components-support

gwesson · ‎07-30-2018

I think you want the "hex-" command options: view-pcap hex + hex Print each packet (minus link header) in hex + hex-ascii Print each packet (minus link header) in hex and ASCII + hex-ascii-link Print each packet (including link header) in hex and ASCII + hex-link Print each packet (including link header) in hex For example, using the full "verbose++ yes" option (top line) with "hex-ascii-link yes" gets this type of output: 11:50:35.821556 70:8b:cd:51:d6:90 (oui Unknown) > 33:33:00:00:00:0c (oui Unknown), ethertype IPv6 (0x86dd), length 718: 0x0000: 3333 0000 000c 708b cd51 d690 86dd 6009 33....p..Q....`. 0x0010: e6a6 0298 1101 fe80 0000 0000 0000 5c97 ..............\. 0x0020: 2f45 3d8c f357 ff02 0000 0000 0000 0000 /E=..W.......... 0x0030: 0000 0000 000c db69 0e76 0298 13f2 3c3f .......i.v....<? 0x0040: 786d 6c20 7665 7273 696f 6e3d 2231 2e30 xml.version="1.0 0x0050: 2220 656e 636f 6469 6e67 3d22 7574 662d ".encoding="utf- 0x0060: 3822 3f3e 3c73 6f61 703a 456e 7665 6c6f 8"?><soap:Envelo 0x0070: 7065 2078 6d6c 6e73 3a73 6f61 703d 2268 pe.xmlns:soap="h 0x0080: 7474 703a 2f2f 7777 772e 7733 2e6f 7267 ttp://www.w3.org 0x0090: 2f32 3030 332f 3035 2f73 6f61 702d 656e /2003/05/soap-en 0x00a0: 7665 6c6f 7065 2220 786d 6c6e 733a 7773 velope".xmlns:ws 0x00b0: 613d 2268 7474 703a 2f2f 7363 6865 6d61 a="http://schema .....

gwesson · ‎07-25-2018

I never actually paid any attention to that, but yeah I see it now. The full date + time are in the log itself, so you can either click on the magnifying glass to see it or you can click on the date/time link in that column to add the full timestamp (receive_time leq '2018/07/25 08:54:17). I think it's probably a purposeful decision. The vast majority of logs on the system won't stay present for more than a year, and even if they did you wouldn't need the year visually since intermediate logs between years would indicate how many years have passed.

gwesson · ‎07-23-2018

Nothing on the firewall GUI other than the Remote Users item you mention. In CLI (and thus, using the API as well) you can grab the list: show global-protect-gateway current-user You can also restrict that command to a specific gateway, domain, or username. System logs aren't great for what you want because you won't be able to easily tell which logs are no longer relevant. A user who logged in 5 minutes ago but logged out 3 minutes ago will still show up if you query all login events. If you query by both login and logout events, you'd have to sort those in a way that was unique to the user.

gwesson · ‎07-20-2018

The terms are defined on the EOL policy page (though there are no links to it from the EOL page you supplied): https://www.paloaltonetworks.com/services/support/end-of-life-announcements/end-of-life-policy The key terms are defined at the bottom, but for what you're specifically referring to it means: "Support includes technical support, bug fixes, maintenance releases, workarounds, and patches for critical bugs" So essentially, when something is end-of-life (or end-of-support), it means you should not expect to even be able to open a case or get configuration help. By extension, it also means no bug fixes (including security fixes). In fact, you'll notice on the Security Advisories page there are no recent updates for any 7.0 release as that version is EOL.

gwesson · ‎07-18-2018

Free is a transient state that is generally rather short in life. Since the session state is under transition, there isn't much of value in the session state. Here's a list of the states and their meanings: https://live.paloaltonetworks.com/t5/Management-Articles/Session-States-and-Types/ta-p/62572 Application DB being zero is related. That session isn't referencing any current app-id database since there is no app at all, so that's all it means.

gwesson · ‎07-10-2018

I don't, but I'd recommend starting a new thread so your question can be seen by the whole community instead of to an answered-ish thread.

gwesson · ‎07-09-2018

Just to make sure we're troubleshooting the right spot, did you do all of the following? 1. Created the OCSP responder on the firewall (Device tab > Certificate Management > OCSP Responder). 2. Created the certificate with that OCSP responder selected. 3. Allow connections to a dataplane interface to let OCSP respond (Network tab > Network Profiles > Interface Mgmt > Select "HTTP OCSP") 4. Have a security rule allowing the inbound OCSP requests. Steps 1 & 2 are required to do in that order (though can be done after steps 3 & 4). If the cert was created before the OCSP responder was created, it won't work since the cert doesn't have the OCSP location present. Steps 3 & 4 can be done in any order, but are required also. I wrote up a document a few years ago that goes over the procedure and talks about testing it as well: https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Configure-an-OCSP-Responder/ta-p/62256

gwesson · ‎07-05-2018

You're correct, there was a change in 8.1 for the directionality, but I also cannot find any specific documentation on this. The direction of certain logs was purposefully altered in 8.0 and older to help readability for logs like Threat and Data. The "source" and "destination" fields are changed to "Attacker" and "Victim", and because the victim is generally the user (not the external web server) that swap makes sense. Here's a good article discussing it: https://live.paloaltonetworks.com/t5/Management-Articles/Threat-Logs-Show-Inverted-Reversed-Direction-for-Source-and/ta-p/55493 The problem was that in 8.0 the Unified Logs page was added, allowing admins to review all the different logs in one place. When the Threat and Data logs were viewed along with the Traffic log, the swapping of addresses loses its context because the Unified Log page only has one field for each IP ("Source address" and "Destination address"). Thus, 8.1 stops doing that so the Unified Logs don't have a weirdly swapped source/destination ip/port. If you've still got an 8.0 firewall check out the columns in the Threat Log and you'll see Attacker and Victim instead of Source Address and Destination Address.

gwesson · ‎07-05-2018

That is expected behavior. Before the session ends, the values for things like duration and bytes would not be accurate later if you needed to investigate a particular flow. There wouldn't be an easy way to do delta calculations on the same session since that would require keeping a table of the various active sessions that were still active before, which would probably too much overhead. You're right in that there is a delta reporting for your configured interval, but that serves to buffer requests and provide cadence. Since the session still didn't end in that interval, the firewall won't use that session until it is actually completed.

Member Since	‎03-27-2012 04:23 PM
Date Last Visited	‎10-10-2019 02:19 PM
Posts	731
Total Likes Received	296

Online Status	Offline
Date Last Visited	‎10-10-2019 02:19 PM

About gwesson

Re: Source User ID being replaced by service account for SCCM

Re: Commit error profile compiler can not find tid 40006 in threat database

Re: SSL Expired Cert and SSL decryption

Re: SSL Expired Cert and SSL decryption

Re: SSL Expired Cert and SSL decryption

Re: Intel MDS Attack

Re: Getting this from Vendor device eventid eq ike-recv-p1-delete

Re: Add LDAP GROUP as Administrator

Re: Certificate based authentication for IOS microsoft intune intergration

Re: aggressive-cleaning enable but still got disk usage email alert?

Re: Importing a WildCard SSL to use with GlobalProtect

Re: How to filter policies by zone

Re: Does it exist a CLI command that close all active sessions for a Zone?

Re: capturing ssl decrypted traffic

Re: Global Protect Client 1.2.0

Re: Python Script

Re: HELP: Clients going 'under the radar' when CP is switched on...

Re: URL Redirect

Re: Minimum allowed version of Global Protect

Re: Why Panorama commit is always not greyed out

Re: Can comments be added to an EDL?

Re: External Certificate Renewal

Re: Flags field in csv file

Re: Question about outbound hostname restrictions

Re: BlueCoat Proxy Health Checks Failing through Palo Alto - App-ID "incomplete"

Re: SFP Compatibility

Re: tcpdump - view whole packet in CLI

Re: What year is it - system logs

Re: Monitoring Global Protect

Re: Software End-of-Life policy vs end of support

Re: What is application db = 0 and app.id c2s node (0, 0) s2s node (0, 0) in session id comman

Re: OCSP unknown status

Re: OCSP unknown status

Re: 8.1.2 file-blocking / logging traffic direction

Re: netflow behavior

Unlock your full community experience!

About gwesson