Learning Articles

Featured Article
    User 'jharlow' had a question about DNS showing up as a top application with web-browsing being second. In a one hour period, he was observing 27,700 DNS and 24,100 web-browsing sessions. He was thinking that they had their own internal DNS server and wondered why he was getting so many sessions showing up?   The reason that this happens is because web pages are more complex today. In today's world, web pages can contain many parts, as shown below: Images hosted on other domains/sites Social Media plugins like Facebook and Twitter to share and like items Website Advertising External links for content distribution Website analytics Every one of these parts not only perform a DNS lookup, but can pull content from those other domains/sites, generating a huge amount of traffic for a small number of legitimate website visits.   In my experience, when DNS traffic is so active on your network, you are going to end up with DNS as the most active application talking through your firewall. In almost every case, it is fine creating a separate outbound rule for DNS traffic using its default port (application-default) and turning off logging for that rule. To remain protected, I recommend that you enable a security profile to catch any malicious traffic, viruses and so forth.   To view the discussion, please visit the following link: DNS top applications?   As always, I welcome any comments or suggestions for live.paloaltonetworks.com, so please comment below!   Thanks for reading. Joe Delio
View full article
‎09-18-2018 11:29 AM
3,947 Views
1 Reply
  This week's discussion focuses on user 'dusk2dusk' having issues with Layer 3 not passing through the untrust/internet interface at random times. Specifically, he is using GlobalProtect Large Scale VPN (LSVPN) to connect 55 current remote sites. On PAN-OS 6.1.2 on remote sites and 6.0.5h3 at hubs in the datacenter. He observed intermittent issues where routes to remote sites are not installed in the Routing Information Base (RIB) on the hub as a result the tunnel is declared active on both sides but there is no traffic passing between remote and hub. Also, on the satellite remote sites he is seeing a dataplane full lockup on Layer 3. The routing of traffic is not occurring until he reboots the dataplane or the entire firewall on remote sites.   The user 'dusk2dusk' has had this occur several times on different PA-200's and tried the following to remedy the issue: Performed a firmware upgrade to PAN-OS 6.1.3 Examined router and determined the ARP entry for the Palo Alto Network firewall is present Cleared ARP table Repopulated with MAC/IP and it responds correctly Rebooted the router (did not help the firewall pass Layer 3)   After further research, it was determined this was a bug and the issue has been fixed in PAN-OS 6.1.4. Below is the official description of the issue: Fixed an intermittent issue on VM-Series firewalls where GlobalProtect clients stopped connecting and displayed a Connection Failed error, possibly due to an encap/decap context leak. With this fix, the encap/decap context leak is no longer observed.   Additional documentation regarding other fixes in PAN-OS 6.1.4 can be found on the following link: PAN-OS 6.1.4 for PA-200 Platform Software Update To read the entire discussion, see the following link: Layer 3 Stops Passing - All PAN-OS Versions incl. 6.1.3   If you have any additional questions regarding this discussion please leave a comment below. Thank you for your time.   Andrea Simon
View full article
‎09-18-2018 11:26 AM
7,042 Views
0 Replies
    For this week's "Discussion of the Week", I will be highlighting the following thread: GlobalProtect Client Loses User-IP Mapping Entry after about 2 minutes   In this discussion, user 'Marcin.Chudzik' seeks help with his GlobalProtect client. He is able to get his GlobalProtect client connected to an HA (High Availability) firewall and everything works for two minutes. But after the two minutes, the GlobalProtect client stops working. When the Palo Alto Networks firewall is checked for its IP to user mapping, it changes from knowing to not knowing this client.   The answer to this issue was simple, the time was not being synchronized between the two HA members.  As soon as the time was corrected on both members, the clients stopped having this issue.   Shown below are a couple of screenshots from the discussion page:   Thanks for reading, Stay secure, Joe Delio
View full article
‎09-18-2018 11:25 AM
11,054 Views
2 Replies
    Palo Alto Networks support engineers receive questions on a regular basis about NAT and something called U-Turn NAT.   NAT is Network Address Translation, and it is used to help translate a Private IP (RFC 1918) into a Public IP for privacy, because it hides behind another IP, and the fact that a Private IP address is not routable on the Internet. This is known as Source NAT or Hide NAT. We also have Destination NAT, which allows the firewall to advertise it's Untrust IP (or another IP) to then be translated to an Internal host or web server.   U-Turn NAT refers to the logical path that traffic appears to travel when accessing an internal resource when they resolve thier external address. U-turn NAT is often used in a network where internal users need to access an internal DMZ server using the server’s external public IP address.   Satish recently posted about a NAT issue that he was experiencing in a recent discussion. NAT Issue   Satish was experiencing an issue with NAT that might be resolved with the use of U-Turn NAT.   More info Lets look at the following layout when we are talking about NAT and U-Turn NAT. 3 zones: Trust Zone - e1/4 192.168.1.4/24 DMS Zone - e1/13 10.1.1.1/24 Untrust Zone - e1/3 203.0.113.100/24     Source NAT To enable the clients on the internal network to access resources on the Internet, the internal 192.168.1.0 addresses will need to be translated to publicly routable addresses. In this case, we will configure source NAT, using the egress interface address, 203.0.113.100, as the source address in all packets that leave the firewall from the internal zone.   Destination NAT To enable the web server—which has both a private IP address on the DMZ network and a public-facing address for access by external users—to both send and receive requests, the firewall must translate the incoming packets from the public IP address to the private IP address and the outgoing packets from the private IP address to the public IP address. On the firewall, you can accomplish this with a single bi-directional static source NAT policy.   U-Turn NAT To enable clients on the internal network to access the public web server in the DMZ zone, we will need to configure a NAT rule that redirects the packet from the external network, where the original routing table lookup will determine it should go based on the destination address of 203.0.113.11 within the packet, to the actual address of the web server on the DMZ network of 10.1.1.11. To do this you must create a NAT rule from the trust zone (where the source address in the packet is) to the untrust zone (where the original destination address is) to translate the destination address to an address in the DMZ zone.   You also need to have a rule that also allows traffic from the Trust to the DMZ to access the web server in question.   For more information, please see this document: How to Configure U-Turn NAT   We always welcome comments and questions below in the comments section.   Thanks for reading, Joe Delio
View full article
‎09-18-2018 11:07 AM
15,198 Views
0 Replies
  Group mapping inside of User-ID is a great feature that many customers use in order to gain the ability to use groups inside of the security policies instead of individual users accounts. The User-ID function is able to accomplish this by communicating to a Microsoft Active Directory server or eDirectory server using LDAP (default port 389).   User-ID can be used one of two ways: Agent - an Agent software that has to run on a Windows server that communicates with the Directory server. Agentless - the firewall communicates directly with the Directory server.   This can be a simple configuration, but often things arise that can cause issues. By default, you use the Management IP address to communicate with the Directory server. By using the Management IP, no additional security rules are needed. If you do not wish to use the Management IP, but instead wish to use another interface, then the "Service Routes" would need to be changed. This can be configured inside of the WebGUI > Device > Setup > Services tab and click on "Service Route Configuration" under "Services Features".   For more information on Service Route configuration, reference the following Admin Guides for more information: PAN-OS Administrator's Guide 5.0 (English) PAN-OS Administrator's Guide 6.0 (English) PAN-OS Administrator's Guide 7.0   In the discussion of the week, user 'Satish' is using Agentless User-ID and was getting an "Internal error" when trying to communicate with his Microsoft Active Directory server, as the firewall was not able to talk with the Directory server.     The root of the issue was that his Service Routes were not properly configured and he was using the wrong password for the account needed to access the Microsoft Active Directory server. To view the full discussion, reference the following link: Group Mapping Issue Discussion   If you have any questions, comments or feedback, please leave them below. Thanks for reading,   Joe Delio
View full article
‎09-18-2018 11:04 AM
4,655 Views
0 Replies
Click to read the latest discussion of the week about new policy deny actions
View full article
‎09-18-2018 11:00 AM
8,711 Views
0 Replies
1 Like
Overview For max-packet-rate, the unit is kilobytes per second:   >configure # set deviceconfig setting logging max-packet-rate 250   For max-log-rate, the unit is counts per second:   >configure # set deviceconfig setting logging max-log-rate 250   The current values can be checked with the show system setting logging command. For example: > show system setting logging   Max. logging rate:            50000      cnt/s Max. packet logging rate:     2560       KB/s Traffic log generation rate:  0          cnt/s Threat log generation rate:   0          cnt/s Log sent rate:                50000      cnt/s Current traffic log count:    0        Current threat log count:     0        Random traffic log drop:      off Log suppression:              on default-policy-logging:       off   owner: nayubi
View full article
nrice ‎09-11-2018 05:56 AM
3,353 Views
0 Replies
1 Like
Ensuring sufficient log retention not only enables operations by ensuring data is available to administrators for troubleshooting and incident response, but enables the full suite services provided by the Application Framework. 
View full article
cstancill ‎09-08-2018 09:03 AM
19,188 Views
7 Replies
4 Likes
Scenario A Palo Alto Networks firewall (PA-1) is configured as a GlobalProtect Gateway and as a User-ID redistribution device. Another Palo Alto Networks firewall (PA-2) is configured to retrieve IP-mapping information from PA-1.   Symptom When a user (testuser) connects to the GlobalProtect Gateway, the From value in the IP-user mapping on PA-1 shows GP. However, on PA-2, the From value on PA-2 shows UIA.   admin@PA-1> show user ip-user-mapping all IP        Vsys   From   User           IdleTimeout(s) MaxTimeout(s) --------- ------ ------ -------------- -------------- ------------- 1.1.1.1   vsys1  GP     testuser       8410           8410 admin@PA-2> show user ip-user-mapping all IP        Vsys   From   User           IdleTimeout(s) MaxTimeout(s) --------- ------ ------ -------------- -------------- ------------- 1.1.1.1   vsys1  UIA    testuser       2926           2926   Cause When a Palo Alto Networks firewall acts as a redistribution device (collector), it acts as a User-ID Agent to the other Palo Alto Networks firewalls. Therefore, only PA-1 will see the user as GlobalProtect (GP) user. All firewalls that retrieves the IP-user mapping from PA-1 will see all users as User-ID Agent (UIA) users, including those that connect to PA-1 from GlobalProtect.   owner: sberti
View full article
sberti ‎08-28-2018 10:39 AM
4,776 Views
0 Replies
Overview Log suppression, when enabled, is a feature that instructs the Palo Alto Networks device to combine multiple similar logs into a single log entry on the Monitor > Logs > Traffic page. Clicking on the entry for the log details shows an increased Repeat Count value and the related logs associated with the entry.   Details Use the show system setting logging command to verify the current setting: > show system setting logging Max. logging rate: 50000 cnt/s Max. packet logging rate: 2560 KB/s Traffic log generation rate: 0 cnt/s Threat log generation rate: 0 cnt/s Log sent rate: 50000 cnt/s Current traffic log count: 0 Current threat log count: 0 Random traffic log drop: off Log suppression: on default-policy-logging: off   By default, log suppression is enabled. The command to enable/disable log suppression is: # set deviceconfig setting logging log-suppression {yes|no}   In an example scenario, ping traffic was passed through the firewall. Log suppression was enabled and 4 ping packets were sent. On the traffic logs page, there was only one entry for ping. Clicking on the entry for the details showed a Repeat Count of 4.     When the log suppression was disabled 6 ping packets produced 4 traffic log entries for ping. As expected, each log had a Repeat Count of 1.     owner: ssunku
View full article
Phoenix ‎08-28-2018 09:00 AM
6,268 Views
2 Replies
2 Likes
Starting with PAN-OS 8.1.1, hardware-based and VM-Series firewalls, WildFire appliances, PAN-DB private cloud, and Panorama appliances perform software integrity checks for tamper detection and software corruption. The software integrity check runs transparently in the background at start up and periodically while the device is running to validate that the operating system and data file structure are intact and as delivered by Palo Alto Networks.   Note 1: If you’re using Panorama with GlobalProtect Cloud Service or the Logging Service, you must install the Cloud Services plugin version 1.0.3 before upgrading Panorama to PAN-OS 8.1.1. Otherwise, your Panorama upgrade to 8.1.1 will fail.   If everything is ok and the check passes, the appliance generates a System log (Monitor > System Log) of informational severity and boots successfully.  If the check detects a software corruption or possible device tampering, starting with 8.1.3, the appliance boots in to maintenance mode and you must contact Palo Alto Networks Customer Support for assistance. We’ll help you to learn more about what caused the check to fail.   Note 2: In the event that you simultaneously boot up multiple instances of the VM-Series firewall on a single host or the VM-Series firewall has CPU oversubscription, the firewall may boot in to maintenance mode if a processing delay causes a response timeout during the integrity check. If your VM-Series firewall goes in to maintenance mode, you can check the errors and warnings logged to the fips.log.   To export the log file and review the errors, see: https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Retrieve-the-Palo-Alto-Networks-Firewall-Configuration-in/ta-p/52093   To revert to a previous version and exit maintenance mode, see:  https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Reinstall-or-Revert-PAN-OS-from-Maintenance-Mode.     If a device fails the software integrity check, please contact Palo Alto Networks Support. We’ll help you to learn more about what caused the check to fail.
View full article
‎08-21-2018 02:47 PM
3,760 Views
0 Replies
1 Like
This document describes the packet handling sequence in PAN-OS.   Day in the  Life  of a  Packet PAN-OS  Packet Flow Sequence.   Since PanOS 7.0.2 and 6.1.7 (PAN-48644), dos protection lookup is done prior to security policy lookup.  This DOC was updated to reflect this change in behaviour.   Contents: SECTION 1: OVERVIEW SECTION 2:  INGRESS STAGE 2.1    PACKET PARSING 2.2    TUNNEL DECAPSULATION 2.3    IP DEFRAGMENTATION SECTION 3:  FIREWALL SESSION LOO KUP 3.1    FIREWALL SESSION SETUP 3.2.    ZONE PROTECTION CHECKS 3.3.    TCP STATE CHECK 3.4.    FORWARDING SETUP 3.5.    NAT POLICY LOOKUP 3.6.    USER- ID 3.7.   DOS PROTECTION POLICY LOOKUP 3.8.   SECURITY POLICY  LOOKUP 3.9.   SESSION ALLOCATION SECTION 4:  FIREWALL SESSION FAS T PATH SECURITY  PROCESSING CAPTIVE  PORTAL SECTION 5:  APPLICATION IDENTIFI CATION (APP - ID) SECTION 6:  CONTENT INSPECTION SECTION 7:  FORWARDING/EGRESS SECTION 8:  SUMMARY   Section 1:  Overview This document describes the packet handling  sequence inside of PAN-OS devices . The ingress and forwarding/egress stages handle network functions  and make packet - forwarding decisions on a  per-packet basis. The remaining stages are  session-based security modules highlighted by App-ID and Content-ID. This decoupling offers stateful security functions at the application layer, and the resiliency of per-packet forwarding and flexibility of deployment topologies.    Section 2:  Ingress Stage The  ingress stage receives packets from the network interface, parses those   packets,  and then determines whether  a   given packet is subject to further inspection . If the  packet is subject to  further  inspection, the  firewall continues with a  session lookup and  the  packet enters the security processing stage. Otherwise, the firewall forwards the packet to the egress stage.  Section 3 summarizes cases when the firewall forwards packets without inspection, depending on  the  packet type and the  operational mode of the interface. Note : During packet processing,  the firewall may discard a packet because of a protocol violation. In certain cases,  due to firewall attack prevention features,  it discards packets  without configurable options.   Section 2.1 enumerates  such  cases when  the firewall discards packets  at this stage .   Packet Flow Walkthrough Click HERE for High-res picture     2.1   Packet  Parsing   Packet parsing starts with  the Ethernet (Layer-2)   header of the packet received from  the wire. The ingress  port, 802.1q tag,  and  destination MAC address  are used as keys to lookup the ingress logical interface. If  the interface is not found, the packet is discarded. The hardware interface counter "receive error" and global counter  “flow_rcv_dot1q_tag_err” are incremented.  Next, the IP header is parsed (Layer-3) .    IPv4:  The firewall will discard the packet for any one of the following reasons :     Mismatch of Ethernet type and IP version  Truncated IP header  IP protocol number 0  TTL zero  Land attack  Ping of death  Martian IP address  IP checksum errors   IPv6 :  The firewall will discard the packet for any one of the following reasons :     Mismatch of Ethernet type and IP version Truncated IPv6 header  Truncated IP packet (IP payload buffer length less t han IP payload field)  JumboGram  extension (RFC 2675) Truncated extension header Next,  the Layer-4 (TCP/UDP) header is parsed, if  applicable .   TCP:  The firewall will discard the packet for any one of the following reasons :   TCP header is truncated. Data - offset field is less than 5  Checksum error Port  is  zero  Invalid combination of TCP flags  UDP:  The firewall will discard the packet for any one of the following reasons :     UDP header truncated  UDP payload truncated (not IP fragment and  UDP buffer length less than  UDP length field) Checksum error 2.2   Tunnel Decapsulation The firewall performs  decapsulation/decryption at the  parsing stage. After parsing the packet, if  the firewall determines   that it matches a tunnel, i.e. IPSec, SSL-VPN with SSL transport, then it performs the following sequence:   The firewall decapsulates the packet first and discards it if errors exist. The tunnel interface associated with the tunnel is assigned to the packet as its new ingress interface and then the  packet is fed back through the parsing process, starting with the packet header defined by the tunnel type. Currently,  the supported tunnel types are IP layer tunneling, thus packet parsing (for a tunneled packet) starts with the IP header. 2.3   IP Defragmentation The firewall parses IP fragments, reassembles using the defragmentation process,  and then feeds the packet back to the parser starting with the IP header.  At this stage, a fragment may be discarded due to tear-drop attack (overlapping fragments), fragmentation errors, or if the firewall  hits system limits on buffered fragments (hits the max packet threshold) . Section  3 :  Firewall Session Lookup   A packet is subject to firewall processing depending on the packet type and the interface mode. The  following  table summarizes the packet processing behavior for a given interface  operation mode and packet type:   Packet Type Interface operational modes Layer-3 Layer-2 Virtual-Wire Tap IPv4 unicast   inspect & forward   inspect & forward   inspect & forward inspect & drop IPv4 Multicast (224.0.0.1 - 239.255.255.255)     inspect & forward forward only (flood)   forward, but inspect only if multicast  firewalling is on inspect & drop IP broadcast (255.255.255.255) drop forward only (flood) forward, but inspect only if multicast  firewalling is on drop IP local broadcast drop forward only (flood) forward, but inspect only if multicast  firewalling is on drop IPv6 inspect and forward   if enabled forward, but inspect only if IPv6  firewalling is on  (default) forward, but inspect only if IPv6  firewalling is on (default) drop, but inspect only if IPv6  firewalling is on  (default) Non-IP process if applicable,  not forward forward only   forward only   drop    If the packet is subject to firewall inspection, it performs a flow lookup on the packet. A  firewall session consists of two unidirectional flows, each uniquely identified. In  PAN-OS ’s   implementation, the firewall identifies the flow using a 6-tuple key : Source and destination addresses : IP addresses from the IP packet.  Source and destination ports:  Port numbers from TCP/UDP protocol headers.  For non-TCP/UDP, different  protocol  fields are used (e.g. for ICMP the ICMP identifier and  sequence numbers are used, for IPSec terminating on device the Security Parameter Index (SPI) is used, and for unknown, a constant reserved value is used to skip Layer-4 match). Protocol:  The IP protocol number from the IP header is used to derive the flow  key .   Security zone:  This field is derived from the ingress interface at which a packet  arrives. The firewall stores active flows in the flow lookup table. When a packet is determined to be eligible for firewall inspection, the firewall extracts the  6-tuple flow key from the packet and then performs a flow lookup to match the packet with an existing flow. Each flow has a client and server component, where the client is  the sender of the first  packet of the session from firewall’s perspective, and the server is the receiver of this first packet.    Note:  The distinction of client and server is from the firewall’s point of view and may or may not be the same from the end hosts’ point of view.  Based on the above definition of client and server, there will be a client-to-server (C2S)  and server-to-client (S2C) flow, where all client-to-server packets should contain the same key as that of the C2S flow, and so on for  the  S2C flow.   3.1   Firewall Session Setup The  firewall performs the following steps to set up a firewall session :   3.2.   Zone Protection  Checks After the packet arrives on a firewall interface, the ingress interface information is used to determine the ingress zone. If  any zone protection profiles exist for that zone, the packet is subject to evaluation based on the profile configuration.   3.3.   TCP  S tate  C hec k   If the first packet in a session is a TCP packet and it does not have the SYN bit set, the firewall discards it (default).  If SYN flood settings are configured in the zone protection profile and action is set to SYN Cookies, then TCP SYN cookie is triggered if the number of SYN matches the activate threshold. SYN cookie implementation functions as follows:    The seed to encode the cookie is generated via random number generator each time the data plane boots up. If an ACK packet received from the client does not match cookie encoding,  it treats the packet as non-SYN packet . A session that passes SYN cookie’s process is subject to TCP sequence number translation because the firewall acted as a proxy for TCP 3-way handshake.  If the SYN Flood protection action is set to Random Early Drop (RED) instead, which  is the default, then the firewall simply drops any SYN messages that are received  after hitting the threshold. SYN Cookies is preferred when you want to permit more  legitimate traffic to pass through while being able to distinguish SYN flood packets and drop those instead. RED, on the other hand, will drop SYN packets randomly and can impact legitimate traffic equally.   Note:  You can configure the firewall to allow the first TCP packet, even if it does not have SYN bit set.  Altering the default behavior and allowing non-SYN TCP packets through poses a security risk by opening up the Firewall to malicious packets not part of a valid TCP connection sequence. Although this is not a recommended setting,  it might be required for  scenarios with asymmetric flows.   You should configure the firewall to reject TCP non-SYN when SYN cookies are  enabled.   3.4.   Forwarding  S etup   This stage determines the  packet-forwarding path. Packet forwarding depends on the configuration of the interface . The  following table summarizes the packet-forwarding behavior:   Interface Mode Forwarding action Tap Egress interface/zone is the same as the ingress interface/zone from a policy perspective. The firewall discards the packet. Virtual Wire Egress interface is the peer interface configured in the virtual wire Layer - 2 Egress interface for the destination MAC is retrieved from the MAC table. If the information is not present, the frame is flooded to all interfaces in the associated VLAN broadcast domain, except for the ingress interface . Layer - 3 The firewall uses the route lookup table to determine the next hop, or discards the packet if there is no match.    3.5.   NAT  P olicy  L ookup   This is applicable only  in Layer-3 or Virtual Wire mode. At this stage, the ingress and egress zone information is available.  The firewall evaluates NAT rules for the original packet.    For destination NAT,  the firewall performs a second route lookup for the translated address to determine the egress interface/zone.   For source NAT,  the firewall evaluates the NAT rule for source IP allocation. If the allocation check fails, the firewall discards the packet.   3.6.   User - ID   The firewall uses the IP address of the packet to query the User-IP mapping table (maintained per VSYS) . The corresponding user information is fetched. The firewall next takes this user information to query the user-group mapping table and fetches the group mapping associated with this user (it returns all groups the user belongs to).   There is a chance that user information is not available at this point. In that case, if captive portal policy is setup, the firewall will attempt to find out  the user information via captive portal  authentication ( discussed in Section 4) .   3.7.   DoS Protection  Policy Lookup Next, the firewall checks the DoS (Denial of Service) protection  policy  for traffic thresholds based on the DoS protection profile.  If the DoS protection policy action is set to “Protect”, the firewall checks the specified thresholds and if there is a match (DoS attack detected), it discards the packet.    If the policy action is either allow or deny, the action takes precedence regardless of threshold limits set in the DoS profile.    3.8.   Security  P olicy  Lo okup At this stage, the ingress and egress zone information is available.  The firewall uses application ANY to perform the lookup and check for a rule match.  In case of a rule  match, if the policy action is  set to ‘deny’, the firewall drops the packet.  The firewall denies the traffic if there is no security rule match.   The firewall permits intra-zone traffic by default.   You can modify this default behavior for intra-zone and inter-zone traffic from the security policies rulebase.     Note :  The firewall applies security rules to the contents of the original packet, even if there are NAT rules configured .       3.9.   Session  A llocation The firewall allocates a new session entry from the free pool after all of the above steps are successfully completed. Session allocation failure may occur at this point due to resource constraints:   VSYS session maximum reached, or  The firewall allocates all available sessions. After the session allocation is  successful :     The firewall fills session content with flow keys extracted from the packet and the forwarding/policy results .   Session state changes from INIT (pre-allocation) to OPENING (post-allocation) .   If the application has not been identified, the session timeout values are set to default value of the transport protocol. You can configure these global timeout values from the Firewall’s device settings.  Application specific timeout values override the global settings, and will be the effective timeout values for the session once application is identified .     After setup, session installation takes place :   Firewall queries the flow lookup table to see if a match exists for the flow keys matching the session.  If a flow lookup match is found (session with same tuple already exists), then this session instance is discarded as session already exists, else Session is added to the flow lookup table for both C2S and S2C flows and firewall changes the session’s state from  OPENING to ACTIVE . The firewall then sends the packet into Session Fast Path phase for security processing.   Section 4 :  Firewall Session Fast Path A packet that matches an existing session will enter the fast path. This stage starts with  Layer-2 to Layer-4 firewall processing:     If the session is in discard state, then the firewall discards the packet.  The firewall can mark a session as being in the  discard state due to a policy action change to deny, or threat detection .  If the session is active, refresh session timeout .   If the packet is a TCP FIN/RST, the session TCP half closed timer is started if  this is the first FIN packet received (half closed session) or the TCP Time Wait  timer is started if this is the second FIN packet or RST packet.  The session is  closed as soon as either of these timers expire. If NAT is applicable, translate the L3/L4 header as applicable.  If an application uses TCP as the transport, the firewall processes it by the TCP  reassembly module before it sends the data stream into the  security-processing module. The TCP reassembly module will also perform window check, buffer out-of-order data while skipping TCP retransmission. The firewall drops the packets if there is a reassembly error or if it receives too many out-of-order fragments, resulting in the reassembly buffers filling up.   4.1.  Security Processing A packet matching an existing session is subject to further processing (application identification and/or content inspection) if  packet has TCP/UDP data (payload), or it is a non-TCP/UDP packet .     If the firewall does not detect the session application, it performs an App-ID lookup. If  App-ID lookup is non-conclusive, the content inspection module runs known protocol decoder checks and heuristics to help identify the application.     If the firewall detects the application, the session is subject to content inspection if any of the following apply:   Application Layer Gateway (ALG) is involved . Application is tunneled application . Security rule has security profile associated.  The Application Identification (App-ID) and Content Inspection stages are discussed in detail in later sections (Section 5  and  6) .       4.2.  Captive Portal If the user information wa s not available for the source IP address extracted from the packet, and the packet is destined to TCP/80, the firewall performs a captive portal rule lookup to see if the packet is subject to captive portal authentication. If captive portal is applicable, the packet is redirected to the captive portal daemon.    Note:  Since captive portal is applicable to http traffic  and also supports a URL category based policy lookup, this can be   kicked in only  after the TCP handshake is completed and the http host headers are available in the session exchange.   Section  5 :  Application I dentification (App - ID) The firewall first performs an application-override policy lookup to see if there is a rule match. If there is, the application is known and content inspection is skipped for this session .   If there is no application-override rule, then application signatures are used to identify the application.  The firewall uses protocol decoding in the content inspection stage to determine if an application changes from one application to another .   After the firewall identifies the session application, access control, content inspection, traffic management and logging will be setup as configured.    Security policy lookup: The identified application as well as IP/port/protocol/zone/user/URL category in the session is used as key to find rule match.  If the security policy has logging enabled at session start,  the firewall generates a traffic log, each time the App-ID changes throughout the life of the session.   If security policy action is set to allow and it has associated profile and/or application is subject to content inspection,  then it passes all content through Content-ID .   If security policy action is set to allow, the firewall performs a QoS policy lookup and assigns a QoS class based on the matching policy .   If security policy action is set to allow and the application is SSL or SSH, perform a decryption policy lookup  and set   up proxy contexts if there is a matching decryption rule .   Section 6 : Content Inspection     The firewall performs content Inspection, if applicable,  where protocol decoders’ decode the flow and the firewall parses and identifies known tunneling applications  (those that routinely carry other applications like web-browsing). If the identified application changes due to this, the firewall consults the security policies once again to determine if the session should be permitted to continue . If the application does not change, the firewall inspects the content as per all the security profiles attached to the original matching rule. If it results in threat detection, then the corresponding security profile action is taken.    The firewall forwards the packet to the forwarding stage if one of the conditions hold true:   If inspection results in a ‘detection’ and security profile action is set to allow, or   Content inspection returns no ‘detection’. The firewall then re-encrypts the packet before entering the forwarding stage, if applicable (SSL forward proxy decryption and SSH decryption).   Section 7 : Forwarding/Egress   The firewall identifies a forwarding domain for the packet, based on the forwarding setup (discussed earlier).  The firewall performs QoS shaping as applicable in the egress process. Also, based on the MTU of the egress interface and the fragment bit settings on the packet, the firewall carries out fragmentation if needed. If the egress interface is a tunnel interface, then IPSec/SSL-VPN tunnel encryption is performed and packet forwarding is reevaluated.   Finally the packet is transmitted out of the physical egress interface.   Section  8 :  Summary Palo Alto Networks next-generation firewalls use a unique Single Pass Parallel Processing (SP3) Architecture – which enables high-throughput, low-latency network security, all while incorporating unprecedented features and technology. Palo Alto Networks solves the performance problems that plague today’s  security infrastructure with the SP3 architecture, which combines two complementary components - Single Pass software, Parallel Processing hardware. The result is an excellent mix of raw throughput, transaction processing, and network security that today’s high performance networks require.
View full article
jpa ‎07-25-2018 02:08 AM
165,019 Views
32 Replies
12 Likes
Details A device is configured as a satellite in an LSVPN deployment, (under the IPSEC Tunnel configuration Network > IPSec Tunnels), in the Advanced Tab there is the option to "Publish all static and connected routes to Gateway". If this option is enabled, all the static and connected routes will be forwarded to the gateway. However, shown below there are four filtering conditions that prevent routing loops: Default routes are ineligible. Routes within other Virtual Router (determined by the tunnel interface) are ineligible Routes using the tunnel interface are ineligible Routes using the underlying physical interface (of the tunnel interface) are ineligible   All other routes that are not being matched by these conditions will be propagated to the gateway.     owner: aciobanu
View full article
aciobanu ‎07-23-2018 11:50 PM
3,242 Views
0 Replies
HA-Lite is the name of the high-availability feature on the PA-200 and VM-Series firewalls. It offers a lighter version of the HA capabilities found on the other Palo Alto Networks hardware platforms. A limited version of HA is necessary on PA-200s because of the limited number of ports available for synchronization.   HA-Lite offers the following capabilities: A/P High Availability without session sync Failover of IPSec Tunnels (sessions must be re-established) DHCP Lease information PPPoE lease information Configuration sync Layer 3 forwarding tables   Features not available in HA-Lite: Jumbo Frames Link Aggregation A/A High Availability A/P High Availability with session synchronization Note: Configuration for HA-Lite is similar to configuring active/passive HA, except there is no configuration available for HA2. This is because HA2 is used for session sync and HA-Lite does not support session sync.   owner: apasupulati
View full article
apasupulati ‎07-23-2018 01:43 PM
25,945 Views
9 Replies
2 Likes
This article is out of date, we recommend that you review the BGP details in the following article instead: "HA Active/Passive Best Practices" https://live.paloaltonetworks.com/t5/Management-Articles/HA-Active-Passive-Best-Practices/ta-p/197154   Also, don’t forget to enable IETF graceful restart on your Cisco peers. And don’t enable BFD and Graceful Restart together on a Palo Alto Networks as per: https://www.paloaltonetworks.com/documentation/71/pan-os/pan-os/networking/configure-bfd
View full article
achalla ‎07-18-2018 01:50 PM
8,280 Views
4 Replies
UPDATED 6/21/2018   RAR or 7zip files scanned?   Question: Does the Palo Alto Networks Firewall Scan RAR or 7zip Files for viruses?   Answer: RAR and 7zip archive files are not decoded by the firewall. All processing of these files occurs in the WildFire public cloud.   O nly ZIP and GZIP are currently supported. The reason is related to how compression works for RAR, which would make the firewall need to proxy the entire file to scan it. This would create a significant impact to the performance. Which is why WildFire public cloud is used to examine both RAR and 7zip files. Note: WildFire WF-500 units currently do not support scanning RAR or 7zip files.   For more information on WildFire, please see the WildFire Admin Guide here: https://www.paloaltonetworks.com/documentation/80/wildfire/wf_admin   owner: mzhou
View full article
panagent ‎06-21-2018 07:01 PM
11,464 Views
6 Replies
1 Like
UPDATED 6-18-2018 with v50   The attached spreadsheet details key hardware specifications for all Palo Alto Networks devices. Note: Input voltage, frequency, power factor and input current are based on power supply ratings. The following details for all Palo Alto Networks devices are included in the spreadsheet: Device model Input voltage Input frequency Power factor Maximum input current Average/max power consumption Heat dissipation Maximum Current Consumption Noise level in dBA MTBF CPU DRAM Flash Storage (SSD, EMMC or HDD) VCCI RoHS compliance Other regulatory and safety compliance certifications Chassis dimensions and weight Shipping weight Product weight Environmental Conditions (Humidity) Battery (Also extra tab with battery info included)  2 files attached, one is a zip file with .xls file in it, the other is a PDF of a .xls spreadsheet.   owner: panagent
View full article
nrice ‎06-18-2018 11:39 AM
21,260 Views
9 Replies
Issue : For 7K platform starting with 6.1.0 onwards the virtual mac-address when HA is enabled has been changed as follows .This is a change from the earlier vmac of 00:1b:17:00 : xx:yy   for this platform in versions 6.0.x.  Please note this change only applies to 7K platform with 6.1.x .Other platforms continue using the 00:1b:17:00 : xx:yy format of vmac address.   Impact/Implications:   After an upgrade customers may be affected as ARP cache on neighbour devices may need to be refreshed or in the case of static nat neighbour device configurtion will need to be updated to accomodate the new VMAC of the now PAN-OS 6.1 7k platform   Format: The format of the virtual MAC is b4 -0c-25:e x':xx:yy , where    b4-0c-25:e: The vendor ID ( fixed )    x':xx: The value representation is as follows            x':x - 8 bits - First 6 bits map to the group ID  ( For a group ID of 1 it will be 0000:01xx ) Next bit is fixed to 0 . Next bit is the "Device Id " used for HA A-A.            x: All zeroes    yy: The interface ID : Interface ID for a HW interface starts from 64 ( 6.1.0 onwards )  Interface ID for an AE starts at 16.   Example: PA 7K HA A/P with Group ID of 1   admin@pa7050-01(active)> show interface all   total configured hardware interfaces: 21   name                    id    speed/duplex/state        mac address     -------------------------------------------------------------------------------- ethernet1/1             64    1000/full/up              b4:0c:25:e0:40:40     b4:0c:25:e 0:40:40 breaks down to   b4:0c:25:e :Vendor ID 0:40 - 0000 0100 0000  i.e First 6 bits from left to right map to Group ID of 1 , rest are left as 0 40 - Interface ID of 64
View full article
msandhu ‎06-11-2018 04:02 AM
2,902 Views
0 Replies
NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and vice-versa and was introduced as a feature in PAN-OS 5.0. NAT64 is not supported on VWire mode and is only supported on L3 or Layer3 Mode.   To select NAT64, go to Policies > NAT and click Add to bring up the NAT Policy Rule dialog.   owner: gcapuno
View full article
gcapuno ‎05-14-2018 05:56 AM
4,292 Views
0 Replies
The guide can be found and downloaded from the Palo Alto Networks Education site.   owner: panagent
View full article
panagent ‎05-14-2018 05:03 AM
5,565 Views
0 Replies
While troubleshooting, we may need to enable debug messages for various dameons associated with the issue that we are facing.   To do this, we need to understand the debug levels and hierarcy available in PAN-OS.   The hierarcy for debug level is as follows:   0. Off 1. Error 2. Warn 3. Info 4. Debug 5. Dump (use with caution)   Enabling a debug level also enables the debug levels above them.   For example, If we enable Info level, it will also turn on Error & Warn. That's why Dump level should be used sparingly.   To check the existing debug level for a daemon/function, enter the command: > debug < daemon/function> show (OR) > debug < daemon/function> global show For example, to check the debug level on the DHCP daemon, > debug dhcpd global show     To enable debug for a daemon, use the command below: > debug < daemon/function> on <debug-level> (OR) > debug  < daemon/function> global on <debug-level>   For example, to enable debug on  the DHCP daemon, > debug dhcpd global on debug     After checking the debug logs, remember to revert the debug level to the default. > debug  dhcpd global on info   PAN-OS 8.0 introduces a new set of command options that you can use to display and modify the debug levels of the various service. These new commands branch from debug sofware logging-level [tab]. Initial options are "set" and "show."   To show the current debug level for all services (PAN-OS 8.0 and later only): > debug software logging-level show service all-services To show the debug level and the debug features configurations using debug software logging-level show commands, you must run two separate instances of the command (PAN-OS 8.0 and later only): debug software logging-level show level service <service-name> debug software logging-level show feature service <service-name>  To set the debug level for all services to their default settings (PAN-OS 8.0 and later only): > debug software logging-level set level default service all-services    
View full article
shganesh ‎05-09-2018 10:19 AM
10,838 Views
5 Replies
Kerberos SSO: Kerberos Authentication for Admin access Keytab generation is used to supply the windows credentials automatically to the login prompt when a user accesses the WebGUI of the firewall. A network that supports Kerberos SSO prompts a user to log in only for initial access to the network (for example, logging in to Microsoft Windows). After this initial login, the user can access any browser-based service in the network (for example, the firewall web interface) without having to log in again, until the SSO session expires. (Your Kerberos administrator sets the duration of SSO sessions.)   You enable SSO for a Palo Alto Networks device by importing a Kerberos keytab into an authentication profile. A keytab is a file that contains Kerberos account information (principal name and hashed password) for the device, which is required for SSO authentication. Each authentication profile can have one keytab. If SSO authentication fails, the device prompts the user to log in manually and performs authentication of the type specified in the profile (for example, RADIUS).     ISSUE: Kerberos SSO Admin authentication. Generation of keytabs for SSO and Active Directory settings   For customers who want to use Kerberos SSO authentication for their environment.   SYMPTOMS: Authentication failing due to a malformed keytab.     RESOLUTION: Here is a step-by-step procedure for generation of the keytab and the prerequisites:   Service account on the domain controller which will carry the credentials. For the service account, you need to enable AES 128 bit encryption / AES 256 bit encryption if the encryption algorithm is AES 128/256.   To enable the above settings, open the user account and click on Account, you will observe the encryption algorithm under Account options.   Service account settings     Some settings under the browser. For IE, the settings can be found under the below hierarchy: Internet options> Security> Local intranet (sites button) > Advanced> add service FQDN to the list.   Here under websites, add the firewall’s fqdn or you can use *.domain.local.   Please note: Chrome will use IE settings.     IE settings    For firefox, type about:config as URL and search trusted URLs. Enter the service FQDN in the value.   Firefox settings   Here is a command that can be used to identify the encryption algorithm on the Domain controller:  1. klist Command:  C:\Users\admin> klist Client: gpdomuser1 @ GPQA.LOCAL         Server: HTTP/keytabgpgw61.gpqa.local @ GPQA.LOCAL         KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 <- Information regarding the encryption algorythm.         Ticket Flags 0x40a50000 -> forwardable renewable pre_authentok_as_delegate name_canonicalize         Start Time: 10/1/2015 13:11:33 (local)         End Time:   10/1/2015 23:09:18 (local)         Renew Time: 10/8/2015 13:09:18 (local)         Session Key Type: RSADSI RC4-HMAC(NT)         Cache Flags: 0         Kdc Called: thirugpwinad.gpqa.local   2. setspn Command:  setspn -s http/fqdn domain\service account   For example setspn -s http/fwtrust12.abc.local abc.local\service_account_username     3. The command for creating of the keytab is as follows:  ktpass -princ http/fwtrust12.abc.local@ABC.LOCAL -mapuser service_account_username -pass acct_password -crypto aes256-sha1 -ptype KRB5_NT_PRINCIPAL -out c:\temp\xyz-test.keytab -mapop set  
View full article
schopra ‎05-09-2018 10:16 AM
13,935 Views
3 Replies
1 Like
This article relates to PAN-OS 7.1 and prior, for PANB-OS 8.0 and later, please refer to this article   How to exclude a site from being decrypted by importing its certificate on the PAN and marking it SSL Exclude Certificate. Steps Identify the site to decrypt (e.g. www.wellsfargo.com in the test case). Locate its certificate.  Screenshot from Chrome. Click on Certificate information and browse to Detail tab. Click Copy to File to export this certificate out.  This will launch the Certificate Export Wizard. Select Base 64 (.CER)[PEM] as per following screenshot.  Name it and save it on the PC.  (saved a abcd.cer in test case) Import this cert on the PAN: Device > Certificates > Import.  Browse for where the cert is stored on the PC and select File format as Base64 Encoded Certificate(PEM) and click OK. Once the cert is imported, click on the cert and select SSLExclude Certificate . Once this is complete, browse to the site whose cert was imported onto the PAN and check the certificate presented.  Even though this session is decrypted by the SSL Decryption policy, it shows the original issuer certificate not the cert proxied by the PAN.  Thus, showing the session was excluded from being decrypted.     Also see List of Applications Excluded from SSL Decryption SSL Website not working even after using excluding the Server Certificate from Decryption     owner: achitwadgi
View full article
panagent ‎05-04-2018 04:33 AM
13,537 Views
5 Replies
HIP tips and tricks — no, not a blast from the 70s but rather an excellent treatise on Host Information Profile (HIP) configuration for patch management. Use the  GlobalProtect Host Information Profile (HIP) feature   to collect information about the security status of the endpoints, such as whether they have the latest security patches and antivirus definitions installed, and more.  
View full article
srajasekar ‎04-27-2018 03:33 PM
35,746 Views
5 Replies
Fortnite is an online multiplayer game, for PC and other devices ,  common amongst school-age students and one of many such games that boarding schools need to accommodate on their network.  Pre-defined App-IDs are provided for a number of well-known games. However, for very new or uncommon games, App-IDs may not be available.  Enjoy this custom  App-ID for Fortnite.
View full article
jwood ‎04-27-2018 03:30 PM
9,092 Views
1 Reply
5 Likes
This document provides a general overview of creating Custom Threat Signatures from Snort Signatures on the Palo Alto Networks Firewall using three use cases.   Introduction   The Vulnerability Protection feature detects and prevents network-borne attacks against vulnerabilities on client and server systems. Vulnerabilities can be system and service specific or generic and are not bound to a specific port, but to a protocol or application. In addition to the predefined Vulnerability Protection profiles, you can create custom profiles tailored to the environment you want to protect. A custom profile can contain one or more rules and exceptions that define which vulnerability protection signatures to include. 
 The Anti-Spyware feature detects and prevents spyware and malware network communications. The Anti-Spyware feature is not limited to specific protocols and can detect any type of phone- home communication. In addition to the predefined Anti-Spyware profiles, you can create custom profiles tailored to the environment you want to protect. A custom profile can contain one or more rules and exceptions that define which Anti- Spyware signatures to include. 
   Custom profiles also allow you to enable packet captures of matching traffic. This can be used for evidence gathering or troubleshooting purposes. Please look at Recommendations section at the end of the document before deployment in a production network.     Use Cases   1. Alert TA17-318B HIDDEN COBRA – North Korean Trojan: Volgmer   Reference:  https://www.us-cert.gov/ncas/alerts/TA17-318B   IOC List: https://www.us-cert.gov/sites/default/files/publications/TA-17-318B-IOCs.csv   Snort rule: alert tcp any any -> any any (msg:"Malformed_UA"; content:"User-Agent: Mozillar/"; depth:500; sid:99999999;)   General Notes: Use the IP addresses provided as part of the IOC List to detect if a possible infection already exists by searching the Firewall logs The IP addresses provided can be part of an EDL or Address group and added to a Policy to block traffic to and from the suspicious list. Use the provided Snort signature and convert it to a custom spyware signature. This signature will become part of the Spyware profile added to the appropriate Policy.   Detailed Steps: Create a Custom Spyware Object Navigate to Objects tab -> Custom Objects -> Spyware Click on Add and provide appropriate details as shown in below screenshot Click on Signatures -> Add [Standard Signature option] Create a custom signature as shown below:   The pattern “User-Agent: Mozillar/" from the snort signature is used with the “http-req-headers” context to create the Custom Signature. Click OK to create the Spyware Object. Verify the created Spyware Object is part of your Anti-Spyware Profile   Create an EDL object Navigate to Objects tab -> External Dynamic Lists Click Add Add the suspicious IP address provided from the IOC list to a previously created EDL or a new EDL as shown below.   Add the EDL and Anti-Spyware profiles to appropriate Policy Objects. Test Policy is working per expectation by looking at Threat logs. Change the action for the spyware object from alert to drop/reset after verification. Also change severity of the custom object created as needed.       2. Alert TA17-293A Advanced Persistent Threat Activity   References: https://www.us-cert.gov/ncas/alerts/TA17-293A https://www.us-cert.gov/ncas/current-activity/2017/01/16/SMB-Security-Best-Practices   IOC List:   https://www.us-cert.gov/sites/default/files/publications/TA17-293A_TLP_WHITE_CSV.csv   Snort rules :   alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"HTTP URI contains '/aspnet_client/system_web/4_0_30319/update/' (Beacon)"; sid:42000000; rev:1; flow:established,to_server; content:"/aspnet_client/system_web/4_0_30319/update/"; http_uri; fast_pattern:only; classtype:bad-unknown; metadata:service http;)   alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"HTTP URI contains '/img/bson021.dat'"; sid:42000001; rev:1; flow:established,to_server; content:"/img/bson021.dat"; http_uri; fast_pattern:only; classtype:bad-unknown; metadata:service http;)   alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"HTTP URI contains '/A56WY' (Callback)"; sid:42000002; rev:1; flow:established,to_server; content:"/A56WY"; http_uri; fast_pattern; classtype:bad-unknown; metadata:service http;)   alert tcp any any -> any 445 (msg:"SMB Client Request contains 'AME_ICON.PNG' (SMB credential harvesting)"; sid:42000003; rev:1; flow:established,to_server; content:"|FF|SMB|75 00 00 00 00|"; offset:4; depth:9; content:"|08 00 01 00|"; distance:3; content:"|00 5c 5c|"; distance:2; within:3; content:"|5c|AME_ICON.PNG"; distance:7; fast_pattern; classtype:bad-unknown; metadata:service netbios-ssn;)   alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"HTTP URI OPTIONS contains '/ame_icon.png' (SMB credential harvesting)"; sid:42000004; rev:1; flow:established,to_server; content:"/ame_icon.png"; http_uri; fast_pattern:only; content:"OPTIONS"; nocase; http_method; classtype:bad-unknown; metadata:service http;)   alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"HTTP Client Header contains 'User-Agent|3a 20|Go-http-client/1.1'"; sid:42000005; rev:1; flow:established,to_server; content:"User-Agent|3a 20|Go-http-client/1.1|0d 0a|Accept-Encoding|3a 20|gzip"; http_header; fast_pattern:only; pcre:"/\.(?:aspx|txt)\?[a-z0-9]{3}=[a-z0-9]{32}&/U"; classtype:bad-unknown; metadata:service http;)   alert tcp $EXTERNAL_NET [139,445] -> $HOME_NET any (msg:"SMB Server Traffic contains NTLM-Authenticated SMBv1 Session"; sid:42000006; rev:1; flow:established,to_client; content:"|ff 53 4d 42 72 00 00 00 00 80|"; fast_pattern:only; content:"|05 00|"; distance:23; classtype:bad-unknown; metadata:service netbios-ssn;)     General Notes : Use the IP addresses provided as part of the IOC List to detect if a possible infection already exists by searching   the Firewall logs The IP addresses, domains and URL’s provided can be part of an EDL and added to a Policy to block traffic to and from the suspicious list. Blocking SMB application traffic from trust to untrust zones is a recommended best practice. This policy can be used as a workaround for the limitations in converting netbios-ssn related snort signatures to Custom Threat Signatures. Use the other provided Snort signatures and convert them to custom spyware signatures. These signatures will become part of the Anti-Spyware profile added to an appropriate Policy.   Detailed Steps: Create a Custom Spyware Object Navigate to Objects tab -> Custom Objects -> Spyware Click on Add and provide appropriate details as shown in below screenshot   Click on Signatures -> Add [Standard Signature option] Create a custom signature as shown below   Sig-1: The pattern "/aspnet_client/system_web/4_0_30319/update/" in the snort signature is used with the “http-req-uri-path” context to create the custom spyware signature as shown below   Sig-2: The pattern “/img/bson021.dat” in the snort signature is used with the “http-req-uri-path” context to create the custom spyware signature as shown below   Sig-3: The pattern “/A56WY" in the snort signature is used with the “http-req-uri-path” context to create the custom spyware signature. Since there is no 7 byte anchor we include GET and POST request methods along with the trailing space in the pattern as shown below   Sig-4: The pattern “/ame_icon.png" in the snort signature is used with the “http-req-uri-path” context and “http-method: OPTIONS” qualifier to create the custom spyware signature as shown below.   Sig-5 deep dive: Snort Signature: alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"HTTP Client Header contains 'User-Agent|3a 20|Go-http-client/1.1'"; sid:42000005; rev:1; flow:established,to_server; content:"User-Agent|3a 20|Go-http-client/1.1|0d 0a|Accept-Encoding|3a 20|gzip"; http_header; fast_pattern:only; pcre:"/\.(?:aspx|txt)\?[a-z0-9]{3}=[a-z0-9]{32}&/U"; classtype:bad-unknown; metadata:service http;) Actual HTTP Request :   GET /aspnet_client/system_web/4_0_30319/update/DefaultForm.aspx?9bf=04631fbd3f402316f0a006b997863998&pfr=881456FCno& 771=29c7ac4b37168dc9e0e246ca915da8b0 HTTP/1.1 Host: 5.150.143.107 User-Agent: Go-http-client/1.1 Accept-Encoding: gzip   Custom Spyware Signature Explanation: The pattern “User-Agent|3a 20|Go-http-client/1.1” is used part of the “http-req-headers” context. Here the hex 3a and 20 corresponds to colon and space characters. The pattern “Accept-Encoding|3a 20|gzip” is used part of the “http-req-headers” context. Here the hex 3a and 20 corresponds to colon and space characters. The pattern “DefaultForm\.((aspx)|(txt))\?” is used as part of the “http-req-uri-path” context. This is used since there is no 7 byte anchor provided in the pcre section of the snort signature. The final resulting Custom Spyware Signature is an AND of all the above signatures as seen below.   Click OK to create the new Spyware Object Verify the created Spyware Object is part of your Anti-Spyware Security Profile   Create a policy to block SMB application from internal to external zone or vice versa. This is a recommended best practice and addresses the “netbios-ssn” related snort signatures   Create an EDL object for suspicious IP addresses in IOC List Navigate to Objects tab -> External Dynamic Lists Click Add Add the suspicious IP addresses from the IOC list to a previously created EDL or a new EDL as shown below.   Create an EDL object for suspicious URL’s in IOC List Navigate to Objects tab -> External Dynamic Lists Click Add Add the suspicious URL’s from the IOC list to a previously created EDL or a new EDL as shown below. This can now be included with appropriate action under the URL Filtering Security Profile Create an EDL object for suspicious domains in IOC List Navigate to Objects tab -> External Dynamic Lists Click Add Add the suspicious domains from the IOC list to a previously created EDL or a new EDL as shown below. For the list of domains included in the External Dynamic List, the firewall creates a set of custom signatures of type spyware and medium severity, so that you can use the sinkhole action for a custom list of domains.     Add the EDL’s and Anti-Spyware profiles to appropriate Policy Objects. Test Policy is working per expectation by looking at Threat logs. Change the action for the spyware object from alert to drop/reset after verification. Also change severity of the custom object created as needed.     Other useful information:   -- Example GET Request-1 -­ GET /aspnet_client/system_web/4_0_30319/update/DefaultForm.aspx?9bf=04631fbd3f402316f0a006b997863998&pfr=881456FCno& 771=29c7ac4b37168dc9e0e246ca915da8b0 HTTP/1.1 Host: 5.150.143.107 User-Agent: Go-http-client/1.1 Accept-Encoding: gzip     -- Example GET Request-2 -- GET Request-­ GET /A56WY HTTP/1.1 Host: 167.114.44.147 Connection: Keep-Alive Cache-Control: no-cache         3. CVE-2018-4878   References: https://www.krcert.or.kr/data/secNoticeView.do?bulletin_writing_sequence=26998 https://www.flashpoint-intel.com/blog/targeted-attacks-south-korean-entities/ http://blog.talosintelligence.com/2018/02/group-123-goes-wild.html https://threatpost.com/adobe-flash-player-zero-day-spotted-in-the-wild/129742/   Snort rule: alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:”Possible CVE-2018-4878 check-in alert”; flow:established,to_server; http_uri; content:”?id=”; http_uri; content:”&fp_vs=”; http_uri; content:”&os_vs=”; http_uri; reference: source, Vitali Kremez-Flashpoint; classtype:Trojan-activity; rev:1;)   IOC: hxxp://www[.]1588-2040[.]co[.]kr/conf/product_old.jpg hxxp://www[.]1588-2040[.]co[.]kr/design/m/images/image/image.php hxxp://www[.]korea-tax[.]info/main/local.php hxxp://www[.]dylboiler[.]co[.]kr/admincenter/files/board/4/manager.php   General Notes: Use the URL’s provided as part of the IOC to detect if a possible infection already exists by searching the Firewall logs. The URL’s provided can be made part of an EDL or a Custom URL Category Object that is added to a Policy as a URL filtering Profile. Use the provided Snort signature and convert it to a custom vulnerability signature. This signature will become part of the Vulnerability profile added to an appropriate Policy. Detailed Steps: Create a Custom Vulnerability Object Navigate to Objects tab -> Custom Objects -> Vulnerability Click on Add and provide appropriate details as shown in below screenshot   Click on Signatures -> Add [Standard Signature option] The patterns ”id=”, “&fp_vs=” and ”&os_vs=” are used with the “http-req-params” context to create the custom vulnerability signature. This is done to overcome the 7 byte anchor restriction. Also path in a HTTP request header upto and including the ‘?’ is part of the “http-req-uri-path” context and query string as well as parameters in the HTTP request is part of the “http-req-params” context.   Click OK to create the new Vulnerability Object. Verify the created Vulnerability Object is part of your Vulnerability Protection Security Profile   Create a custom URL Category Object Navigate to Objects -> Custom Objects -> URL Category and add the suspicious URL’s part of the IOC list.   Also add the URL Category Object to the appropriate URL Filtering Security Profile   Add the Vulnerability Security Profile and the URL Filtering Profile to the appropriate Policy Test Policy is working per expectation by looking at Threat logs. Change the action for the vulnerability object from alert to drop/reset after verification. Also change severity of the custom object created as needed.    Other Useful Information:    A snippet of the decompiled Flash object is shown below:     Recommendations   When deploying vulnerability protection and anti-spyware profile based policies, special care should be taken to avoid a negative impact on the protected traffic. While these signatures are developed with great care and are submitted to extensive regression tests, some of the signatures are generic in nature and can trigger on traffic coming from misconfigured services or faulty applications.   This is also true for any 3rd party content being used to build Custom Threat Signatures since they often have not been through the same number of extensive tests as the Palo Alto Networks developed threat signatures. Because of this, it is generally not a good idea to simply turn on blocking for Custom Threat Signatures without prior examination of those signatures and the potential impact they may have on the network.   If time and circumstances permit, it is advised to include an analysis phase in the vulnerability protection deployment timeline. In particular for environments where service availability is critical, such a phase will be required to assure proper functionality of the infrastructure once vulnerability protection and anti-spyware policies are made fully operational.   In general, it is advised to start with a profile that uses the default action for each signature. Especially for Custom threat signatures it is advised to start with a default action of “alert” for each created signature. Alternatively, it is possible to deploy a custom vulnerability protection profile in alert-only or monitoring mode first, to obtain a clear picture on how blocking-mode may affect the infrastructure. Such a profile will have the action set to ‘alert’ for each signature.   The following steps will help you determine the correct profile settings for a given location or host. Configure an ‘alert-only’ protection profile. 
 Configure the necessary firewall rules for hosts and segments you want to protect. 
 Apply the ‘alert-only’ protection profile to each rule. 
 Monitor the threat logs for a representative period of time (e.g. 1 week, 1 month). 
 Investigate any potential false positives. 
 Use the gathered analysis information to build and fine-tune a block-enabled protection profile.     Useful Guides   - Creating Custom Application and Threat Signatures: https://live.paloaltonetworks.com/t5/Tech-Note-Articles/Creating-Custom-Application-and-Threat-Signatures/tac-p/5857   -  Tips & Tricks: Custom Vulnerability: https://live.paloaltonetworks.com/t5/Featured-Articles/Tips-amp-Tricks-Custom-Vulnerability/ta-p/71603
View full article
sshibiraj ‎04-04-2018 01:26 AM
6,042 Views
0 Replies
Overview Palo Alto Networks devices can optionally utilize users and groups to create security policies. Checking users in LDAP groups lets administrators create access permissions based on group membership.   Details Device administrators use LDAP groups to provide access based on users, not IP addresses. The User-ID agent (software or hardware) is responsible for getting the IP-user-mappings and the Palo Alto Networks firewall. Based on the LDAP profile, the User-ID agent reads groups from the LDAP server. These mappings are stored in the firewall's IP-user-mappings table, the groups and members of the groups are stored in the group-mappings list.   Steps Find the groups that the Palo Alto Networks firewall is reading from using an LDAP profile by performing the steps below. The lists for every group can be read using the following CLI command : > show user group list cn=sales,cn=users,dc=al,dc=com cn=it_development,cn=users,dc=al,dc=com cn=groùpé,cn=users,dc=al,dc=com cn=domain admins,cn=users,dc=il,dc=al,dc=com cn=domain guests,cn=users,dc=al,dc=com cn=it,cn=users,dc=al,dc=com cn=marketing,cn=users,dc=al,dc=com cn=it_operations,cn=it,ou=groups,dc=al,dc=openldap,dc=com cn=it_operations,ou=groups,dc=al,dc=openldap,dc=com cn=it_operations,cn=users,dc=al,dc=com cn=domain users,cn=users,dc=il,dc=al,dc=com cn=hr,cn=users,dc=al,dc=com cn=it,ou=groups,dc=al,dc=openldap,dc=com cn=vpn_users,cn=users,dc=al,dc=com cn=domain users,cn=users,dc=al,dc=com To use the needed group in the previous step: > show user group name cn=it_operations,cn=users,dc=al,dc=com source type: service source:      AD_Group_Mapping_al.com [1     ] al\alex [2     ] al\biljanap [3     ] al\damem [4     ] al\ilija [5     ] al\ilijaal [6     ] al\ristok [7     ] al\jovan NOTE: Beginning with PAN-OS 6.0 it will not list the disabled AD users. The example below shows the "alex" domain user on AD has been disabled: The group-mappings on the LDAP profile can be reset with the following CLI command: > debug user-id reset  group-mapping AD_Group_Mapping group mapping 'AD_Group_Mapping' in vsys1 is marked for reset. When using the CLI command below, it now displays that the user is no longer listed in the output: > show user group name cn=it_operations,cn=users,dc=al,dc=com short name:  al\it_operations source type: service source:      AD_Group_Mapping [1     ] al\biljanap [2     ] al\damem [3     ] al\ilija [4     ] al\ilijaal [5     ] al\ristok [6     ] al\jovan   owner: ialeksov
View full article
ialeksov ‎03-27-2018 05:21 AM
71,628 Views
2 Replies
3 Likes
Introduction This document will walk through an automation example using the Palo Alto Networks firewall and Dynamic Address Groups (DAGs). Using DAGs is a powerful way to bring automation to security policies. The idea is to have pre-set policies configured on the firewall which utilize Dynamic Address Groups. As conditions change for a host, it may be dynamically moved to a DAG, and therefore, be subject to a different policy in the rulebase. If conditions change once more for that host, it may be moved to yet another DAG, hitting a different policy altogether. All without an administrator adding and deploying new rules or committing changes to be pushed out.   The conditions which may be monitored are vast! In this example we will use DAGs to dynamically move a host into and out of an SSL decryption group for troubleshooting. However, the use cases are virtually endless.   Requirements   Required Item Notes Palo Alto Networks Firewall Tested with a VM50, PANOS 8.1.0 Host with browser Tested with Windows 7 64-bit VM       Network Diagram   Use Case Diagrams       Configuration Dynamic Address Group   We will begin by creating the tag which will be used by the Dynamic Address Group. Create the tag for disabling SSL decrypt.   Objects > Tags > Add     Create the DAG to be used within the decryption policy.   Objects > Address Groups > Add Name the address group Change type to ‘Dynamic’ Click the Add Match Criteria and select the tag created in the previous step to denote no SSL encryption     SSL Decryption Policy   Configure the SSL decryption policies to decrypt (hosts outside of DAG) and exclude decryption (hosts inside of DAG).   Policies > Decryption> Add   Add two policies in this order Do not decrypt Use the do not decrypt DAG as the source address Make the Action ‘no-decrypt’ Decrypt all other Use Any for source/destination addresses Make the Action ‘decrypt’ Ensure the Type is ‘ssl-forward-proxy’   Note: this document assumes there is a certificate on the firewall and client to perform the decryption. See instructions here if needed: https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Implement-and-Test-SSL-Decryption/ta-p/59719   The decryption policies should reflect the following:     Vulnerability Signatures   Before we add the logging conditions, we need a way to trigger the condition. In this example, we will create custom vulnerability signatures that watch for a specific URI paths. We will use the URI path as way to move a host into or out of our DAG.   Create a vulnerability signature which looks for the URI path of ‘/kw-nodecrypt/’.   Objects > Custom Objects > Vulnerability > Add   For the Configuration tab: Assign the Thread ID a custom signature number It is recommended to set Severity to informational and Action to Alert For live environments, work with the Incident Response team so they know to ignore this specific alert Direction is client2server     For the Signatures tab: Add a Standard signature (opens a new window) Leave the Scope as Transaction Use the green plus button to Add And Condition (opens a new window) Change context to: http-req-uri-path For the Pattern, enter our custom command to disable decryption: /kw-nodecrypt/     Select OK to see the result.     Click OK twice to save.   Create a vulnerability signature which looks for the URI path of ‘/kw-nodecrypt-remove/’. This will tell the firewall to remove the host from the SSL bypass DAG and begin decrypting once again. This will be further explained in the Log Forwarding portion of the configuration.   Objects > Custom Objects > Vulnerability > Add   For the Configuration tab: Assign the Thread ID a custom signature number It is recommended to set Severity to informational and Action to Alert For live environments, work with the Incident Response team so they know to ignore this specific alert Direction is client2server     For the Signatures tab: Add a Standard signature (opens a new window) Leave the Scope as Transaction Use the green plus button to Add And Condition (opens a new window) Change context to be http-req-uri-path For the Pattern, enter our custom command to disable decryption: /kw-nodecrypt-remove/     Click OK to see the result.     Click OK twice to save.   The two custom vulnerability signatures similar to the following:     Log Forwarding Profile   With the supporting configuration in place, we can now configure the firewall to watch for our custom signatures and take action (move host into or out of a DAG).   Create a custom Log Forwarding profile.   Objects > Log Forwarding > Add   Name the log forwarding profile Select Add to create a new match list (opens a new window) Name the match list Select threat as the Log Type For the filter use: (name-of-threatid eq 41000) Use the threatID you entered when creating the first vulnerability signature Note: the filter can also be manually built by selecting the down arrow in this field and choosing Filter Builder Select Add in the Built-in Actions window (opens a new window) Name the Action Select Tagging as the action type Target is Source Address Action is Add Tag Registration is Local User-ID In the Tags dropdown, select the tag created in the first step     Click OK twice to be taken back to the Log Forwarding Profile. If you exit too far, click on the Log Forwarding Profile so you can add another match list.   Select Add to create a second match list (opens a new window) Name the match list Select threat as the Log Type For the filter use: (name-of-threatid eq 41001) Use the threatID you entered when creating the second vulnerability signature Note: the filter can also be manually built by selecting the down arrow in this field and choosing Filter Builder Select Add in the Built-in Actions window (opens a new window) Name the Action Select Tagging as the action type Target is Source Address Action is Remove Tag Registration is Local User-ID In the Tags dropdown, select the tag created in the first step     Click OK three times to save the Log Forwarding profile. The results should be similar to the following:     Vulnerability Profile   In order to have the custom vulnerability objects to appear in the threat logs, we will need to modify an existing vulnerability profile, create a new one, or clone one. Take these steps to clone the default.   Objects > Security Profiles > Vulnerability Protection   Clone the default by selecting the checkbox to the left of ‘Default’ and clicking on Clone at the bottom of the window Open the cloned profile (optional) change the name of the profile Select the ‘simple-client-medium’ rule and clone it Open the cloned rule (opens a new window) Change the rule name to read: simple-client-informational Change the Action to Alert (this will provide a threat log entry) Check ‘informational’ in the Severity (uncheck all others)     Click OK twice to save the profile.   The new vulnerability profile should look something like this:     Firewall Policy   Configure a firewall policy to use the Log Forwarding profile and custom vulnerability profile.   Policies > Security   Select a rule which allows web browsing and edit the rule.   Under the Actions tab, select the newly created Log Forwarding profile in the Log Forwarding dropdown.   Change the Profile Type to ‘Profiles’ and ensure the newly created vulnerability profile is selected.     Click OK to save the policy.   Commit the configuration.   Test Configuration Ensure the default action to decrypt SSL is working. Browse to an encrypted site such as https://paloaltonetworks.com and look at the certificate information in the browser.     Look for SSL decryption column ‘yes’ in Traffic logs. If the column isn’t visible, it can be added (https://live.paloaltonetworks.com/t5/Management-Articles/Adding-Columns-to-the-Traffic-Logs-to-View-Additional-Session/ta-p/54193)     Check the dynamic address group to see that the group is empty (i.e. no host is bypassing SSL decryption).   Objects > Address Groups   Under the Addresses column, select ‘more’ from the dynamic address group created in the first steps. Ensure the group is empty.       Use the URI path created to remove a host from SSL decryption. The command should trigger one of the custom vulnerability signatures, which will trigger the log forwarding profile to add a tag which will exempt the host from SSL decryption.   On the host, browse to any site and append the URI string you created which indicates no decryption: /kw-nodecrypt/   For example, https://paloaltonetworks.com/kw-nodecrypt/   The browser will not pull up the page (404 error) as it does not exist, but more importantly, the host should now be exempt from SSL decryption. Be sure to close the browser to trigger the log event if the policy is configured to log at session end.   Verify that the correct vulnerability signature is recorded in the threat logs.   Monitor > Logs > Threat     Check the dynamic address group to see that it contains your host.   Objects > Address Groups   Under the Addresses column, select ‘more’ from the dynamic address group created in the first steps.     Browse to another HTTPS site and check the certificate. It should not show your certificate.     Check the traffic logs to ensure SSL sites are not being decrypted.   Monitor > Logs > Traffic     Use the URI path created to remove a host from decryption exemption. The command should trigger one of the custom vulnerability signatures, which will trigger the log forwarding profile to remove a tag which will cause the host to undergo SSL decryption.   On the host, browse to any non HTTPS site and append the URI string you created which indicates you want to decrypt: /kw-nodecrypt-remove/   For example: http://www.calculator.net/kw-nodecrypt-remove/   The browser will not pull up the page (404 error) as it does not exist, but more importantly, the host should now be subject to SSL decryption. Be sure to close the browser to trigger the log event if the policy is configured to log at session end.   Verify that the correct vulnerability signature is recorded in the threat logs.   Monitor > Logs > Threat     Browse to another HTTPS site and check the certificate. It should show your certificate.     Check the traffic logs to ensure SSL sites are being decrypted.   Monitor > Logs > Traffic     Summary There are many use cases for Dynamic Address Groups and Log Forwarding. From this example it served useful in troubleshooting SSL decryption by way of dynamically directing a host between decryption rules. When creating conditions in Log Forwarding objects, virtually anything that is logged is available. Traffic Threats WildFire Authentication Tunnel Data URL   For another example, see this article on Live: https://live.paloaltonetworks.com/t5/Learning-Articles/Protecting-ICS-and-SCADA-Networks-with-PAN-OS-8-0/ta-p/180651    
View full article
kwall00 ‎03-24-2018 11:41 AM
7,804 Views
1 Reply
1 Like
Overview Using the wildcard character  * is allowed for URL filtering policies.   Shown below are some examples on how to use it: To block any host for site.com: *.site.com   The settings below allow access to youtube when the category streaming-media is blocked. The Allow List should contain the following: *.youtube.com *.ytimg.com *.youtube.com/watch *.googlevideo.com   Also note when you allow the above you open the entire youtube website to the end users. If you want to block adult content you will need to add the following in the block list: */verify_age*   The following characters are considered separators: ./?&=;+ Every substring that is separated by the characters listed above is considered a token. A token can be any number of ASCII characters that does not contain any separator character or *. For example, the following patterns are valid: *.yahoo.com (Tokens are: "*", "yahoo" and "com") www.*.com (Tokens are: "www", "*" and "com") www.yahoo.com/search=* (Tokens are: "www", "yahoo", "com", "search", "*") The following patterns are invalid because the character “*” is not the only character in the token. ww*.yahoo.com www.y*.com   owner: panagent
View full article
nrice ‎03-02-2018 03:31 AM
35,067 Views
3 Replies
1 Like
Quick Reference Guide contains helpful PAN-OS CLI Commands.   COMMAND DESCRIPTION General System Health show system info Shows the system’s management IP, serial #, and code version show jobs processed Shows when commits, downloads, upgrades are completed show system disk-space Shows percent usage of disk partitions show system logdb-quota Shows the maximum log file sizes show system software status Shows running processes Monitor CPUs show system resources Shows processes running in the Management Plane show running resource-monitor Shows the resource utilization in the Dataplane Dropped Packet Troubleshooting ping source <IP_addr_src_int> host <IP_addr_host> Ping from a specified device source interface to destination IP ping host <IP>  Ping from the management interface show session all filter source <source-IP> destination <destination-IP>  Shows specific sessions in the sessions table for source and destination IPs. show session info  Shows usage, pps rates, etc show session id <id-number> Shows session details by entering the session ID number. Packet Filters and Capture - WARNING: Running debug commands on a production device may cause instability or other undesirable results! debug dataplane packet-diag clear all debug dataplane packet-diag clear log log Clear/delete settings and files previously created. delete debug-filter file * Removes all packet capture files debug dataplane packet-diag set filter match source x.x.x.x destination y.y.y.y destination-port debug dataplane packet-diag set filter match source y.y.y.y destination x.x.x.x destination-port debug dataplane packet-diag set filter on Sets filter with the source IP, destination IP and port to capture from/to packets. debug dataplane packet-diag set capture stage receive file pantacrx.pcap debug dataplane packet-diag set capture stage transmit file pantactx.pcap debug dataplane packet-diag set capture stage drop file pantacdrop.pcap debug dataplane packet-diag set capture stage firewall file pantacfw.pcap debug dataplane packet-diag set capture on Configures the different stage of capture types to be executed. debug dataplane pack-diag show setting Verifies packet filters are setup correctly. show counter global filter delta yes packet-filter yes  While test is running, run the command 2-3 times to verify filtered traffic is being captured. debug dataplane packet-diag set capture off Turns off packet capture and filter tcpdump filter “src net <ip/netmask>” tcpdump snaplen 1500 filter “src net <ip/netmask>” view-pcap mgmt-pcap mgmt.pcap Captures PCAP on management interface. Packet Flow Logs - WARNING: Always set specific packet filters to minimize CPU usage. See above Packet Filters and Capture commands. debug dataplane packet-diag set log feature flow basic Set packet-diag log to capture flow basic debug dataplane packet-diag set log on Turns on packet-diag log. debug dataplane packet-diag set log off Capture traffic then immediately disable packet-diag log. debug dataplane packet-diag aggregate-logs Aggregates pack-diag logs to a single file. After disabling packet-diag log, wait 1-2 minutes before running this command. less dp-log pan_packet_diag.log View packet-diag log output. Note: PA-5000 series writes to individual dp0-log, dp1-log or dp2-log Log/Forward Device Issues debug log-receiver statistics Shows the log statistics, like logging incoming rate, log written rate, corrupted packets and logs discarded due to a full queue. less mp-log logrcvr.log Shows debug logging issues on the device. debug software restart log-receiver Restarts log-receiver process. Log Viewing/Deleting show log [system | traffic | threat] direction equal [forward | backward] Goes to the beginning/end of a log. Note: Arguments shown with square bracket [] and pipe | symbols mean choose one of the arguments listed. Monitor Management or Device Server show system resources follow tail follow yes mp-log ms.log Shows management server messages for commit failures, updates, licenses, link status, policy details, etc. tail follow yes mp-log devsrv.log Shows device server message for commit failures, updates, licenses, link status, policy details, etc. Authentication Logs less mp-log authd.log  Shows the detail authentication logs on the device. NAT show running nat-policy Shows current NAT policy table. show running ippool show running global-ippool Shows NAT pool utilization. Routing show routing route Shows routing table. Policies show running security-policy Shows current policy set. User-ID Agent show user user-id-agent state all show user user-id-agent statistics Shows agent’s status. Status should be connected OK and there should be numbers shown under users, groups, and IPS. show user user-ids show user user-IDs show user group-mapping state all show user group-mapping statistics show user group list show user group name <value> Shows the groups pulled from User-ID Agent. show user ip-user-mapping all Shows IP to username mappings. clear user-cache all clear user-cache ip <ip/netmask> Clears user-ID cache. BrightCloud URL Filtering test url <url or IP> Tests categorization of a URL on the device. tail follow yes mp-log pan_bc_download.log Shows the BrightCloud database update logs. debug dataplane show url-cache statistics Shows statistics on the URL cache clear url-cache url <url> Clears URL cache for a site. show log url direction equal backward Shows the URL log, most recent entries first. Note: Cache contains 100k of the most popular URLs on the network. ping host service.brightcloud.com Tests connectivity to the BrightCloud servers. PAN-DB URL Filtering show url-cloud status  Check URL cloud status. debug dataplane test url-resolve-path  <url> test url-info-host <url> test url-info-cloud <url> Tests categorization of a URL on Dataplane cache. Tests categorization of a URL on Management Plane cache. Tests categorization of a URL on Cloud. clear url-cache url <url> delete url-database url <url> Clears URLs from the Dataplane cache. Clears URLs from the Management Plane cache show running url-cache statistics debug device-server pan-url-db show-stats Show statistics on URL Dataplane cache. Show statistics on URL Management Plane cache IPSEC show vpn flow Shows encap/decap counters show vpn gateway Shows list of IKE gateway configurations. show vpn ike-sa Shows IKE Phase 1 SA show vpn ipsec-sa Shows IPSEC Phase 2 SA. show vpn tunnel Shows list of auto-key IPSec tunnel configurations. show log system subtype equal vpn direction equal backward debug ike global on debug less mp-log ikemgr.log Shows detail debug information for IPSec tunneling. High Availability show high-availability state Shows the HA state of the device. show high-availability all Shows the HQ settings configured on the device and peer. show high-availability state-synchronization Shows if the devices are synchronized request high-availability state suspend Suspends active device and makes passive device active request high-availability state functional Changes the state from suspend to passive. Software, Content and Licenses request restart system Reboots the system. request content upgrade > check > download > info > install Upgrades content. Gets info from Palo Alto Networks server. Downloads content packages. Displays available content packages info. Installs content packages. request content downgrade install previous Downgrades to previous content version request license info Shows the license installed on the device. delete license key Deletes a license file. Miscellaneous configure set deviceconfig setting session tcp-reject-non-syn no commit show session info   Ignore SYN when creating sessions.   Confirms command took effect configure set deviceconfig setting session offload no commit show session info Make all packets go through CPU, otherwise all fastpath packets go through the chip. Turns session offload to fastpath. Confirms command took effect. debug dataplane pool statistics Shows the different dataplane buffers and capacity
View full article
panagent ‎02-07-2018 02:26 PM
46,876 Views
5 Replies
7 Likes
Ask Questions Get Answers Join the Live Community