Configuration Articles

Featured Article
Forwarding threat logs to a syslog server requires three steps Create a syslog server profile Configure the log-forwarding profile to select the threat logs to be forwarded to syslog server Use the log forwarding profile in the security rules Commit the changes   Note: Informational threat logs also include URL, Data Filtering and WildFire logs.   Syslog server profile Go to Device > Server Profiles > Syslog Name: Name of the syslog server Server : Server IP address where the logs will be forwarded to Port: Default port 514 Facility: To be elected from the drop down according to the requirements   Log forwarding profile Go to Objects > Log forwarding Create the syslog server profile for forwarding threat logs to the configured server. Add a Log Forwarding Match List to the profile add the syslog server and select a desired (if any) filter Use the filter builder to add more filtering parameters for logs to be forwarded   Once configured, the log forwarding should look like the following   Security Rule Go to Policies > Security Rule Select the rule for which the log forwarding needs to be applied. Apply the security profiles to the rule. Go to Actions > Log forwarding and select the log forwarding profile from drop down list.   Commit the configuration  
View full article
ppatel ‎06-12-2018 12:47 AM
48,643 Views
9 Replies
Overview   WildFire allows users to submit files to the Palo Alto Networks secure, cloud-based, virtualized environment where they are automatically analyzed for malicious activity. Palo Alto Networks lets the file run in a vulnerable environment and watches for specific malicious behaviors and techniques, such as modifying system files, disabling security features, or using a variety of methods to evade detection. Zipped and compressed HTTP (GZIP) files are inspected and any internal EXE and DLL files can be submitted for analysis. The WildFire portal can be used to view the detailed analysis of the analyzed files to see which users were targeted, applications used, and malicious behavior observed. The WildFire portal can also be configured to send email notifications when results are available for review.   Topology   How to configure: Go to Device > Setup > WildFire tab. Choose the default-cloud, maximum file size of 2MB. Specify the information to be forwarded to the WildFire server. Source IP—Source IP address that sent the suspected file. Source Port—Source port that sent the suspected file. Destination IP—Destination IP address for the suspected file. Destination Port—Destination port for the suspected file. Vsys—Firewall virtual system that identified the possible malware. Application—User application that was used to transmit the file. User—Targeted user. URL—URL associated with the suspected file. Filename—Name of the file that was sent.   By default, all the options are selected but they are not required for WildFire to work. Deselect any information that shouldn't be sent to the WildFire cloud.   If a Decryption policy is used, WildFire can be enabled to upload the decrypted files. Go to Device > Setup > Content-ID > Enable “Allow Forwarding of Decrypted Content.”                     By default, files that are decrypted will not be forwarded to the WildFire cloud, so adjusting this value in PAN-OS 6.0 will change the behavior. Go to Objects > Security Profiles > File Blocking. Add a rule, by Name. Enter a rule name (up to 31 characters). • Applications— select any. • File Types—Select the file types exe, dll. • Direction—Select the direction of the file transfer (Upload, Download, or Both). • Action—Select the action taken when the selected file types are detected: forward (The file is automatically sent to WildFire).     Apply the File Blocking profile in Policies > Security > to the rule on which WildFire protection should be applied. Click OK. Commit the configuration.     WildFire CLI commands After the basic configuration is complete, the following commands provide the details of the best server selected. To test the connectivity: > test wildfire registration This test may take a few minutes to finish. Do you want to continue? (y or n) Test wildfire         wildfire registration:        successful         download server list:        successful         select the best server:      va-s1.wildfire.paloaltonetworks.com   Initial registration can be done only on the active unit in an Active/Passive cluster.   Note: Do not use PING to test connectivity to the server. Ping requests are disabled on the WildFire server. Best practice to test connectivity is to Telnet to the server on port 443.   To verify, if any files have been forwarded to the server, use the following command: > show wildfire status Connection info:         Wildfire cloud:                default cloud         Status:                        Idle         Best server:                  va-s1.wildfire.paloaltonetworks.com         Device registered:            yes         Service route IP address:      10.30.24.52         Signature verification:        enable         Server selection:              enable         Through a proxy:              no Forwarding info:         file size limit (MB):                  2         file idle time out (second):            90         total file forwarded:                  0         forwarding rate (per minute):          0         concurrent files:                      0   The total file forwarded counter will provide the number of files being forwarded to the server.   To view WildFire Logs Go to the Monitor > Logs > Data Filtering page:   Use data filtering logs to check the status of the file. If you see only “forward” with no “wildfire-upload-success” or “wildfire-upload-skip,” then the file is either signed by a trusted file signer, or a benign sample the cloud has already seen.   Below is an explanation of the possible actions:   Forward Data plane detected a Potentially Executable file on a WildFire-enabled policy.  The file is buffered in the management plane. If only “forward” is displayed for a specific file, then the file is either signed by a trusted file signer, or a benign sample that the cloud has already seen.  In either case, no further action is performed on the file, and no further information is sent to the cloud (not even session information for previously seen benign files).  There will not be an entry in the WildFire Web portal for these files.   To view the count of how many PE files have been checked, found to be clean or uploaded, issue the command: > show wildfire statistics statistics for wildfire DP receiver reset count:                  12 File caching reset cnt:                  12 FWD_ERR_CONN_FAIL                        1 data_buf_meter                            0% msg_buf_meter                            0% ctrl_msg_buf_meter                        0% fbf_buf_meter                            0%   wildfire-upload-success This means that the file wasn't signed by a trusted signer, and the file hasn't yet been seen by the cloud.  In this case, the file (and session info) was uploaded to the cloud for analysis.   wildfire-upload-skip This means the file was already seen by the cloud. If the file had been previously determined to be malicious, then the report, previously generated when the verdict was made, appears on the WildFire server. If the file was not malicious and was determined to be benign, then the report is not shown on the WildFire server.   WildFire Portal To access the WildFire portal, go to https://wildfire.paloaltonetworks.com and log in using your Palo Alto Networks support credentials or your WildFire account. The portal opens to display the dashboard, which lists summary report information for all of the firewalls associated with the specific WildFire account or support account, as well as any files that have been uploaded manually. The display includes the number of analyzed files and indicates how many are infected with malware, benign, or pending analysis.     Other useful commands are show wildfire disk-usage debug wildfire dp-status   See Also Not All Files Appear on the WildFire Portal When Logs Show the Wildfire-Upload-Skip Message   owner: rhirannaiah
View full article
rhirannaiah ‎10-28-2015 12:24 AM
80,257 Views
18 Replies
1 Like
When submitting application requests or information about a possible bug to Support, please provide the documentation listed by the following types:   App Bugs and App Requests Application Name Application URL Packet Capture Spyware Bugs (All spyware communication related bugs) Threat id range is 10000 to 20000 Threat id Packet Capture Sample of the spyware   Virus (Any sample/malware download/upload false positive, or false negative (bypass the firewall)) Virus threat id range is from 100,000 to over 1,000,000 The threat id triggered Samples URL associated with the bug   Vulnerability (Any vulnerability related bugs, anything related to exploit or attacks) The threat id range for vulnerability is from 30000 to 50000 Threat id Packet Capture Reference URL   owner: panagent
View full article
nrice ‎09-25-2015 01:28 PM
5,549 Views
0 Replies
To enable Vulnerability Scanning Vulnerability scanning is automatically enabled if the custom app is based off a "base app" like HTTP or SMB and also based on the settings of that policy's vulnerability/spyware profile. Note: The spyware checkbox in the screenshot is a non-operational.     To enable Anti-Virus Scanning Anti-Virus Scanning for Custom-Application is done by setting the Virus-Identification flag to "yes" as follows:   Multi-Vsys Platforms : # set vsys vsys1 application myapp virus-ident yes   Single Vsys Platforms : # set application test virus-ident   owner: akawimandan
View full article
Ameya-Kawimandan ‎09-11-2015 02:00 AM
4,099 Views
0 Replies
Overview This document describes the steps to configure a security policy to block brute force attacks on the GlobalProtect Portal page.   Steps Create a vulnerability profile. Go Object > Security Profiles > Vulnerability Protection. Click the "Edit" Icon under the Threat Name column to open the Edit Time Attribute dialog. Adjust the number of instances detected from the child signature that is being triggered and adjust the time window to trigger the defined action. The child signature "Palo Alto Networks Firewall VPN Login Authentication Attempt" with ID 32256 is looking for "x-private-pan-sslvpn: auth-failed" from the http response header. The default is 10 hits within a 60-second time window. The screenshot below shows an example of a configured vulnerability profile. When creating the profile, search for the vulnerability ID 40017 in the search bar and check the enable box. Set the action to block-ip. With this option a block time can be configured and tracked by IP source or source and destination. Create a security policy to apply this profile. While creating a security policy, add the IP address of the portal under Destination Address and select the vulnerability profile created in step 1 above.   Follow these steps to test if it is working. This is how the GlobalProtect Portal page appears when users try to authenticate for the first time: Log into the portal using random user names and passwords. The firewall processes incorrect login attempts for the first 9 times. The following screenshot shows the GlobalProtect Portal page during the 9 unsuccessful attempts: After the 9th unsuccessful attempt, the user will not be authenticated even with the correct credentials. The GlobalProtect Portal appears as follows after the 9th unsuccessful attempt: Brute Force Authentication Attempt is identified as the vulnerability threat. This can be seen in the threat logs. Go to Monitor > Logs > Threat. If block-ip action was configured, check the block-list on the CLI with command: debug dataplane show dos block-table   New sessions are set to DISCARD with a tracker stage firewall "mitigation block ip" and end-reason "threat". Global counters show drop counts under the name "flow_dos_drop_ip_blocked", and description "Packets dropped: Flagged for blocking and under block duration by other modules".   owner: schaganti
View full article
schaganti ‎09-01-2015 04:24 AM
13,764 Views
2 Replies
4 Likes
Overview This document explains how multiple rules for vulnerability and sypware profiles are processed for the same severity.   Details If one vulnerability profile has multiple rules for the same severity then traffic takes the top down approach, much like security policies.   Examples T he following vulnerability profile has 3 rules: If the Palo Alto Networks firewall detects traffic with a MEDIUM severity vulnerability, rule 2 will take effect and an ALERT action will be applied.   The following spyware profile has 3 rules: If the firewall detects traffic with a HIGH severity spyware, rule 1 will take effect and an action of ALERT will be applied.   For file blocking rule order precedence, refer to this document: File Blocking Rulebase and Action Precedence   owner: kadak
View full article
kadak ‎08-28-2015 07:50 AM
3,649 Views
1 Reply
Overview Under Reconnaissance Protection in a Zone Protection Profile, the "Track By" and "Duration" values can be configured for the 'block-ip' action. Steps On the Zone Protection Profile configuration, go to the Reconnaissance Protection tab. Click on block-ip under Action. The "Track By" and "Duration (sec)" fields will be displayed for editing, as shown below: owner: mivaldi
View full article
mivaldi ‎10-03-2014 11:25 AM
6,375 Views
1 Reply
PAN-OS 6.0, 6.1 Overview Conficker was first detected in November 2008, and is one of the most widespread worms that infects machines running Windows OS. Palo Alto Networks has created signatures that can detect and block the Conficker worm. Among them are Anti-Virus/Anti-Spyware signatures that detect the DNS domains used by Conficker variants. These domains are updated as soon as Conficker variants are discovered. If a WildFire license is used, the newly discovered domains are pushed to the Palo Alto Networks firewall every hour through the WildFire signatures. If a license is not used, the signatures are pushed every 24 hours and downloaded by dynamic updates to for all Palo Alto Networks devices. Updates will also be implemented in the new AV signatures in the next update interval. This protection detects when a user in the network is requesting “bad” domains. When an analysis of the logs is completed, it can be reviewed and determined that the request for the infected domain came from the local DNS server. This is possible because of the hierarchical nature of DNS. Details All Palo Alto Networks platforms have an implementation of sinkhole action for queries towards malicious domains. Using this capability, the Palo Alto Networks firewall can detect the infected host in the network and send notification to the security administrator. This enables the infected workstation to be removed from the network. How it works: The infected machine asks for a DNS resolution of an infected domain from the local DNS server. The local DNS forwards the query to the public DNS server. The Palo Alto Networks device sees the query and detects the malicious domain using the newest signatures. It overrides the DNS response with an IP address that the administrator dedicates, (sinkhole address) and sends the spoofed response to the client. The client attempts a connection to the sinkhole IP address. The Palo Alto Networks blocks the traffic and logs the attempt. The firewall administrator receives a notification about the event. The malicious client is removed from the network and cleaned. Steps To  configure the DNS sinkhole action, see: How to Configure DNS Sinkholing on PAN-OS 6.0 Using a Palo Alto Networks device that is dedicated to an L3 interface as a sinkhole interface, (the loopback interface can be used) perform the following steps: Add the interface to a virtual router and to a security zone, as shown in the example. This zone is different because it is where users are initiating connections. A best practice is to create a new sinkhole zone for this interface, as it is never certain where the malicious machines will send traffic. The creation of the new "sinkhole" zone places the created loopback interface as loopback.222. Add an IP address to the interface that is not currently being used and that is well known to the administrator. If IPv6 is used throughout the company, also assign an IPv6 address to the interface. Go to Objects > Security Profiles > Anti-Spyware, choose (or create) the Profile that will be assigned to the internet user. Under DNS Signatures, select sinkhole as an action on DNS queries. If block is chosen, it will block the queries to the malicious domains. In the logs, only the local DNS will be shown as an attacker. Choose the sinkhole IP address that was generated before (222.222.222.222). Choose the IPv6 IP address for the IPv6 DNS queries. Select extended-capture in packet capture to allow more packets to be captured than only the one that triggered the signature. This value is defined under Device > Setup > Content-ID > Threat Detection Settings. Apply the Anti-Spyware Profile to a security rule and enable log at session end. Commit the configuration. Testing After the configuration is complete, validate if the traffic is captured and identify the malicious workstation. Open a test machine behind the firewall. Initiate DNS traffic for one of the Conficker domains (for this test fetyeq.net will be used). Note: To check for more Conficker domains, open the Antivirus Release Notes of the dynamic updates that have been installed on the Palo Alto Networks devices. Palo Alto Networks updates these domains on a regular basis and they can be found in the Release Notes for the Antivirus signatures. Go to Devices > Dynamic-Updates > Antivirus > Release Notes and search for “conficker." There should be around 1,000 domains to review. Check the threat logs for any logs with action sinkhole. If needed, check the packet capture. Generate a custom report using the "sinkhole action" as a filter in the query builder and schedule it to run daily. Check the report the following day to confirm it's collecting and displaying data. Following the steps above tracks and isolates malicious workstations in the designated network. owner: ialeksov
View full article
ialeksov ‎01-28-2014 03:33 PM
30,909 Views
10 Replies
1 Like
Overview This document describes how Antivirus can be checked without a license. Detail If the user is without an Antivirus (AV) license, Palo Alto Networks firewalls can check for AV updates. Cause This is the expected behavior, and generally does not cause any issues. If the firewall is deployed in such a way that it cannot reach the update server, there may be an event generated such as: Failed to check Antivirus content upgrade info due to generic communication error Resolution To disable AV updates altogether, enter the following commands in the CLI: > configure # delete deviceconfig system update-schedule anti-virus recurring # commit Note: The commands above will permanently disable the AV checks, even if a license is subsequently purchased. The checks must be re-enabled with the following commands if AV updates are desired: > configure # set deviceconfig system update-schedule anti-virus recurring daily at 05:00 # commit owner: gwesson
View full article
gwesson ‎09-11-2013 05:08 PM
4,649 Views
2 Replies
To ensure proper operation of service updates for your device, the update server field should be configured using either updates.paloaltonetworks.com or staticupdates.paloaltonetworks.com. IP addresses should not be used. owner: djipp
View full article
djipp ‎09-26-2012 01:02 PM
6,259 Views
3 Replies
Ask Questions Get Answers Join the Live Community