Configuration Articles

Featured Article
 This article is deprecated.  All documentation is now available at http://pansplunk.readthedocs.io   Overview Splunk for Palo Alto Networks is a security reporting and analysis tool, and is the result of a collaboration between Palo Alto Networks and Splunk. This document describes how to configure Splunk for Palo Alto Networks, and covers most problems in configuring Splunk for the first time. Note: Download Splunk for Palo Alto Networks directly from the Splunk site at: http://apps.splunk.com/app/491/. Depending on the OS of the server that's running Splunk, follow the installation recommendations from the Splunk website.   If there are separate indexers and search head, install the application on all of them.   Steps On the Splunk Server: The Palo Alto Networks Next-generation Firewall uses udp/514 for syslog by default, but since this port is often used by other syslogs, we'll use udp/5514 in our examples. Choose any desired port. TCP and SSL syslogs are available in PAN-OS 6.0 and later.   Check the settings in the Splunk inputs.conf file and verify that no other configuration is using the UDP or TCP port you chose for syslogs from the firewall. Check the inputs.conf in the following directories: Note: See the "Configuration file precedence" section in the Splunk Enterprise Admin Manual for more on the way precedences are checked on Splunk. $SPLUNK_HOME/etc/apps/SplunkforPaloAltoNetworks/local/ $SPLUNK_HOME/etc/system/local/ In the inputs.conf file, add the following configuration. For UDP syslogs, make sure to include the line no_appending_timestamp = true . [udp://5514] index = pan_logs sourcetype = pan_log connection_host = ip no_appending_timestamp = true Reset the Splunk service on the server running the Splunk for Palo Alto Networks app.   After configuring the data input, access and configure the app.   The first time running the app from the WebUI, a setup screen displays. You need the credentials only if you want to use the custom commands pantag, panblock, and panupdate . The WildFire API is required only for WildFire subscribers who want Splunk to index WildFire analysis reports from the cloud when a malware sample is analyzed. These credentials are stored in Splunk using encryption the same way other Splunk credentials are stored.   If you don't want to use these extra features, skip the setup screen by clicking Save. Go to Apps > Splunk for Palo Alto Networks. Add the appropriate username/password credentials for the Palo Alto Networks firewall and the WildFire API key. Note: After logging into the WildFire Portal for WildFire subscribers, access the WildFire API key under the account. Copy and paste the key into the WildFire API Key (see example).   On the Palo Alto Networks device: After completing setup on the Splunk site, set up the Palo Alto Networks device to send syslogs to Splunk. Go to Device > Server Profiles > Syslog. Configure the details for the Splunk server, including the UDP port (5514, for this example). Note: Do not set a Custom Log Format. The logs must be in the default format or Splunk won't parse them. Configure a logging mechanism on the firewall to use the syslog server. For example, configure a security policy rule with a Log Forwarding Profile that uses the Splunk syslog server. Or configure the firewall to log config or system events to the Splunk syslog server. Security policy rules are under Policies > Security. Other configurable syslog events are under Device > Log Settings.   Test the configuration The easiest way to test that everything is working is to configure the firewall to syslog all config events. Go to Device > Log Settings > Config and commit. Make any configuration change and the firewall produces a config event syslog. You don't have to commit the change for the syslog to be produced--any uncommitted change to the configuration produces a log. You can verify the log reached Splunk by going to the Splunk for Palo Alto Networks app, click Search in the navigation bar, and enter:       index=pan_logs sourcetype=pan_config   If Splunk is getting the syslogs from the firewall and parsing them correctly, then you'll see the config event syslogs show up here from the changes you made on the firewall configuration.   Troubleshooting Steps 1.  Check that all initial configuration is complete Verify inputs.conf is set up per the instructions above inputs.conf must have the line "no_appending_timestamp = true" Check the other inputs.conf configurations for other inputs using the same port Check that the firewall is not using a Custom Log Format (must use default) Check that the firewall is set to log something like system events, config events, traffic events, and so on. Check that the clocks on the firewall and Splunk server are the same.  If they are different, logs will not show up correctly. If using a TCP or SSL port for syslogs, try UDP instead first, then switch to TCP or SSL once UDP is working   2.  Verify logs are indexed Use the method described in Test the configuration to produce some syslogs. Verify the logs are reaching the Splunk server by navigating to the Splunk for Palo Alto Networks app, click Search in the navigation bar, then enter:     index=pan_logs   If no logs show up, then the logs are not getting indexed correctly. Use these steps to find the problem: Verify the configuration from the Troubleshooting section above. Switch the search timeframe to All Time. If logs show up, verify the timestamp is correct on the logs. If time is wrong, check that the clocks on the Splunk server and firewall are the same. Use tcpdump or Wireshark on the Splunk server to verify the logs are actually reaching it. Also, verify that the pan_logs index exists.   3. Verify logs are parsed correctly Use the method described above in the section Test the configuration to produce some syslogs. Verify the logs are reaching the Splunk server by navigating to the Splunk for Palo Alto Networks app, click 'Search' in the navigation bar, and enter the following search:     index=pan_logs sourcetype=pan_config   If logs showed in step 2, but no logs show up now, then try sourcetype=pan_logs instead of sourcetype=pan_config .  If the logs start showing up after that change, then the logs are not getting parsed correctly: Check that you are not using a Custom Log Format in the syslog server setting on the firewall. Check that the inputs.conf file is configured with the line "no_appending_timestamp = true" If you're using a third-party syslog forwarder between the Palo Alto Networks device and Splunk, verify the forwarder isn't modifying the logs.   4.  Check acceleration and summary indexing Check that the dashboards are populating with data. The Overview dashboard doesn't use acceleration, so it should work at this point. If it doesn't show data, then go back to troubleshooting. For all the other dashboards, after 5-8 minutes of syslogging to the Splunk server, the dashboards should populate with data. If the dashboards are populating, then acceleration and summary indexing are working. If not, check the following:   App Version 4.0 and earlier:   Uses TSIDX for acceleration. Verify that saved searches for log collection are in the savedsearches.conf file. Check that they haven't been changed or overwritten.   App Version 4.1 and later:   Uses Data Model for acceleration. Check acceleration settings in the data model under Settings > Data Model > Palo Alto Networks Logs, then edit the Acceleration settings and verify they are enabled for a reasonably large timeframe. Click the arrow next to the Palo Alto Networks logs data model and check data model build percentage. It should be 100% or very close to it. If the build percentage is stuck at less than 90%, the cause might be limited resources on the Splunk server being consumed by other apps. Check if Splunk CIM or Splunk ES apps are running on the Splunk server. If they are, try disabling both apps, and see if the build percentage increases over 90%. If it does, open a case with Splunk support to report the resource contention issue between the apps and get advice on how to proceed.   owner: ialeksov
View full article
ialeksov ‎05-19-2017 07:00 AM
63,342 Views
6 Replies
2 Likes
Issue After upgrading Panorama to PAN-OS 7.0, the ACC (Application Command Center) Summary data is no longer being populated.   Cause In PAN-OS 7.0, the ACC uses summary data rather than appstats data.   Prior to PAN-OS 7.0, the appstat data was forwarded to Panorama to populate the ACC, even if logs were not explicitly configured to forward.   Resolution Under the new system, managed firewalls need to be running PAN-OS 7.0, as well as Panorama. The datasource can then be changed to the remote device. If a managed firewall is a pre PAN-OS 7.0, then log forwarding must be turned on. If you would like to view ACC log source as "Panorama" and not "Remote Device" then log forwarding must be turned on.    
View full article
jperry1 ‎05-13-2016 02:24 PM
4,003 Views
0 Replies
1 Like
PAN-OS 6.0   Details This document describes how to setup log forwarding from Log Collector in logger mode to Syslog Server. An M-100 log collector is always managed by a Panorama managment server. The Panorama managment server can either be a VM or an M-100 in Panorama mode.   To access the Panorama Management server, perform the steps outlined below: Create a Syslog Profile, go to Panorama > Server Profiles > Syslog, click Add and create a syslog profile, as shown below: Add a Collector Group, go to Panorama > Collector Groups and click Add. There are four tabs in the Collector Group window, but for this configuration go to Collector Log Forwarding. For details on adding devices to Collector Group and adding collectors to the group, please refer to this document How to Configure an M-100 to Function as Both a Log Collector and Panorama. The Syslog Server profile can also be associated with Config, HIP Match, Traffic, Threat and WildFire. After the above step is done, proceed with the commit. First commit the changes to Panorama and then commit to the Collector Group. This is shown in the screenshot below.            owner: sodhegba
View full article
sodhegba ‎04-20-2016 02:17 AM
11,864 Views
4 Replies
2 Likes
Symptoms   Custom Reports that have the Scheduled option unchecked cannot be included in the PDF Summary Report.   For example: Create a custom report under Monitor > Manage Custom Reports with the  Scheduled option unchecked.     Next, create another custom report with the Scheduled option checked.     In the PDF summary report, only the Custom Report with the Scheduled option enabled can be selected.       Diagnosis   When the Scheduled option is enabled, the report runs automatically every night at 2 AM device time. When the Scheduled option is unchecked, the Custom Report does not run automatically, so there's no current data to generate a PDF summary.   Without a PDF summary, the Custom Report with the Scheduled option unchecked doesn't produce a report to select from the summary PDF Report list. Solution   Enable the Scheduled option when the Custom Report needs to be included in the PDF Summary Report.   Also note that when  Last Calendar Week and Last Calendar Month are selected in the Time Frame option, Custom Report cannot be included in the PDF summary because  Last Calendar Week and Last Calendar Month reports run only once a week or month and aren't considered appropriate for the PDF Summary Report, which should contain current data.   So make sure the Scheduled option is enabled and the options  Last Calendar Week and Last Calendar Month are not selected in the Time Frame to include the Custom report in the PDF summary.  
View full article
rashobana ‎10-06-2015 10:04 AM
3,238 Views
0 Replies
1 Like
Overview This document describes the steps to create, run, and schedule a custom report.   Steps Create a custom report by going to Monitor > Manage Custom Reports. Click 'Add' and configure the report. Choose from the following options: Enable the 'Scheduled' option to run a report each night and make the results available in Reports list on the side menu. Click 'Run Now' to run the report immediately and display the results in the new tab names 'untitled' on the page. Note: Custom reports are intended to be run automatically on a scheduled basis. However, the option to run the custom report enables the immediate viewing of the results, and the output can be exported to an .xml, .csv or a .pdf file:   owner: sdarapuneni
View full article
nrice ‎08-24-2015 07:13 PM
9,240 Views
2 Replies
To receive notification via email about custom reports, do the following: Create E-mail Server Profile Go to Monitor > Custom reports to set report settings Go to Monitor > PDF Reports > Report Groups, to add the custom report to the report group Go to Monitor > PDF reports > Email Scheduler for recurrence settings   Email Server Profile Go to Device > Server Profile > Email, Click Add and complete the required information (see example): Name: Enter a name for the email settings Server: Enter a name to identify the server (1-31 characters) Display name: Email Server From: Enter the From email address To: Enter the email address of the recipient Cc: Optionally, enter the email address of another recipient Gateway: Enter the IP address or host name of the Simple Mail Transport Protoco l     Custom Reports Go to Monitor > Manage Custom Reports  and complete the required information (see example): Name: Enter a name for the custom report Database: Choose the database to use as the data source Scheduled: Enable this option Time Frame: Choose a fixed time frame Select the columns that need to appear in the custom report Set the query builder, if necessary   Report Group Go to Monitor > PDF Reports > Report group and add the custom report to the Report group (see example):     Email Scheduler Go to Monitor > PDF reports > Email Scheduler and complete the required information. Name: Enter a name for the email scheduler profile. Choose the report group and email profile created from the above steps. Set the recurrence event according to the requirement.   Commit the configurations. The custom reports are mailed to you, depending upon the preferences set.   owner: ppatel    
View full article
ppatel ‎08-24-2015 04:00 PM
15,562 Views
5 Replies
PAN-OS 6.0 and later Overview Every PAN-OS distribution has around 40 predefined reports that are automatically generated and available to administrators. These reports make up a helpful tool, and allows traffic visibility in the network. It also gives the designated recipients the most common reports to manage threats that are targeting the network. Details In some scenarios, it may be desirable to disable the predefined reports that are on the Palo Alto Networks devices. For example, the device may be busy and the predefined reports generate more management plane (MP) CPU usage. Another reason to disable the predefined reports is the configuration and use of custom reports. In PAN-OS 6.0, all reports (predefined reports, specific reports, a group of reports) can be disabled by a Palo Alto Networks firewall administrator. Steps The predefined reports can be disabled from the web UI or from the CLI, and the process is the same for Palo Alto Networks firewall and Panorama. On the web UI: Go to Device > Setup > Management on the firewall, or Panorama > Setup > Management on Panorama Select Logging and Reporting Settings and go to the Log Export and Reporting tab Uncheck the reports that are not needed, or choose Deselect All to stop all predefined report generation Commit the changes On the CLI: Enter a configuration mode > configure Disable the automatic generation of unwanted reports # set deviceconfig setting management disable-predefined-reports <name-of-report> Note: Use the tab key at the end of the command to see the full list of reports that can be disabled. If some of the disabled predefined reports are included in a Report Group (under Monitor > Report Groups), the named report will be empty. It is recommended to remove the report from the list in the Report Group. Commit the configuration # commit owner: ialeksov
View full article
ialeksov ‎02-02-2014 04:16 PM
6,933 Views
0 Replies
1 Like
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,907 Views
10 Replies
1 Like
Overview In custom reports, the WildFire reports can be generated from the data filtering log and the device threat summary using actions as wildfire-upload-skip and wildfire-upload-success. Steps Go to Monitor > Manage Custom Reports and add a new report Select "Data filtering log" for the Database Columns can be selected as desired. In the example screenshot below, the selected column fields are Filename, Threat/ Content Name, Action and Repeat Count: Under Query Builder, configure the query as "(action eq wildfire-upload-skip) or (action eq wildfire-upload-success)", as shown in the example above. Applying the above template will produce a report similar to the following: Note: This report can be exported in PDF, CSV and XML format. owner: kadak
View full article
kadak ‎12-24-2013 06:16 PM
3,944 Views
0 Replies
To configure email alerts Create a profile for your email server: Go to Device > Server Profiles > Email then click Add. Name your profile, determine the appropriate VSYS if applicable, fill in the Servers tab and Custom Log Format tab if desired.  Click ? for help with information on the form. To apply the email server profile, go to: Device > Log Settings > System and choose the email server you have just configured from the drop-down menu for each log notification type (Critical, High, Medium, Low, Informational) To schedule emailed reports: First select the types of reports you'd like to receive: Monitor > PDF Reports > Report Groups Select the report group and schedule the email: Monitor > PDF Reports > Email Scheduler owner: panagent
View full article
panagent ‎01-12-2012 02:26 PM
16,773 Views
5 Replies
Ask Questions Get Answers Join the Live Community