For this example, I am using HTTP log forwarding along with IFTTT to get a push notification on my iPhone every time there is a Critical Threat event.   Step 1 Install IFTTT and sign up for an account on your desktop at ifttt.com Once you are logged in through your browser, go to https://ifttt.com/maker and connect Maker to your account.  Next, click on the settings icon, and follow the link to your Maker URL Take note of the example URL, as it contains your API key.   Step 2 Create a new IFTTT applet   Click on the My Applets menu item, then click the New Applet button.  The first half of the applet is If This – click on “+this” and search for the Maker service.  Under the Maker service, select the Web Request Trigger and configure it as shown below   Complete your applet by setting the action to a Notification Step 3   Configure the firewall log forwarding settings   Create a new HTTP log server profile.  Add a new server, setting the Address to maker.ifttt.com.  Configure the server to use either HTTP or HTTPS, and set the HTTP Method to POST.  Under Payload Format, edit the Threat format as shown below     The URL format should be set to: trigger/Critical_Threat/with/key/<<YOUR KEY HERE>>   Note – this is from the URL you got from the Maker service settings in step 1.   Set the Payload to: value1="$device_name"&value2="$threatid"&value3="$receive_time"   Then send a Test log – your IFTTT app should notify you at this point.       Step 4 Configure a log profile for critical threats to use the push service   Create a new log forwarding profile, or edit your existing one to forward Threat logs with the Filter set to (severity eq critical), then add your new HTTP server under forwarding method.  Apply this log forwarding profile to any security policies with Threat Prevention to trigger push notifications automatically.     Created by Darren Rogers.

Configure Filtered Email Forwarding   Create a MailGun account   Go to mailgun.com. Sign up for a free account and complete the verification steps. (Note: there is no need to configure a custom domain, just continue to your control panel) After activating your account, scroll to the bottom of the mailgun.com page to the section titled “Sandbox Domains”. Click on the Authorized Recipients link to register and verify your email.   Click the domain name link (see picture above). Leave this page open. In a new browser window, navigate to the GUI for your firewall.   Create HTTP Server Profile In the firewall GUI, navigate to Device->Server Profiles->HTTP. Click Add at the bottom of the screen. Enter a name for the profile. On the Servers tab, click Add. Enter information for all of the following fields: Name: Enter a descriptive name (e.g. MailGun). Address: api.mailgun.net Protocol: HTTPS Port: 443 HTTP Method: POST Username: api Password: the API key listed on the mailgun site   Click the Test Server Connection button   On the Payload Format tab, click on the log type of interest, in this example: System. Enter a name for the format (e.g. mailgun system). In the URI Format field Enter the portion of the API Base URL following api.mailgun.net from the mailgun page, followed by /messages. For example:               This yields “/v3/sandbox7b79131630b8458eb3f13bcff9ff1ced.mailgun.org/messages” In the Parameters section, create the following parameter pairs: Parameter Value from admin@myfirewall.net (can be any from address) to <your verified email address> subject A $severity system log of type $subtype was received. text A system log of severity $severity says: $opaque   Your format should look similar to this:    Alternately, you can configure the text parameter in the payload text area.   Here is the example of a text in the payload for the email: text=A System log with the following data was received:   PAN-OS= $sender_sw_version subtype= $subtype type= $type severity= $number-of-severity Time= $cef-formatted-receive_time Serial= $serial Device Name= $device_name Module= $module Message= $opaque Sequence Number= $seqno Event Type= $eventid   Object= $object PanOSDGl1= $dg_hier_level_1 PanOSDGl2= $dg_hier_level_2 PanOSDGl3= $dg_hier_level_3 PanOSDGl4= $dg_hier_level_4 PanOSVsysName= $vsys_name Virtual System= $vsys   Click Send Test Log   Check to assure your email was received:     Click OK Click OK   Configure Log Forwarding for Desired Log Types For this example, we will configure the system log forwarding. Go to Device->Log Settings. Under System click Add. Enter a name in the Log Settings – System window (e.g. ‘fwd to email’). In the filter area, use the filter builder to create a filter for system logs that you would like forwarded to your inbox (e.g. ‘description contains commit’). Click OK, commit the changes.   Testing and Troubleshooting If you used the ‘description contains commit’ filter above, you can test your configuration by committing a change on your firewall.   Troubleshooting: Mailgun offers a set of logs displaying any successful emails sent:   If you have custom service routes, check to make sure the service route for “HTTP” is configured to allow the firewall or Panorama reach the API service:      Created by Jamie Fitz-Gerald

PAN-OS 8.0 HTTP Log Integration with Slack   This document assumes that you have already created a Slack team. This sample integration was done with a free Slack account.    Once you have created your Slack team, login to your slack account and add an “Incoming Webhooks” custom integration on the slack website.  During that configuration, you will select the channel where the message will be broadcast (#general in this example).  You will also receive a Webhook URL, and an opportunity to customize the Name and Icon for the source of the message.    Here’s a screenshot of the Incoming Webhooks configuration on the slack website:         Next, configure an HTTP Server Profile in PAN-OS 8.0.  Use the first part of the Webhooks URL in the “Address” field.  In this example, it is “hooks.slack.com” using HTTPS on 443 with the POST HTTP method.  Username/Password are not required for this particular integration.     Personally, I was interested in specific “system” events, so this document focuses on the system-level logs.  Similar integrations could easily be done with traffic, threat, and/or URL logs.     This is what the System format looks like:     In the URI Format box, provide the URI portion of the Slack-provided Incoming Webhooks URL, beginning with /service   The content-type must be application/json   Leave the Parameters field blank.   The Payload input box accepts the default Slack-preferred JSON format as documented here:  https://api.slack.com/incoming-webhooks   No additional escaping is required to add the PAN-OS provided variables to the payload.  In this example, I’m using a rich-formatted “attachments” message from Slack, although the basic format works perfectly as well.    Here are two samples that you should be able to cut and paste:   Rich Format Message:   {     "attachments": [         {             "fallback": "$time_generated $device_name reports $severity $subtype event:\n $opaque\n--------",             "text": "$time_generated: <https://pa0.example.com|pa0> reports $severity $subtype event:\n$opaque",             "color": "danger"         }     ] }     Simple Format Message:   {     "text": "$time_generated $device_name reports $severity $subtype event:\n $opaque\n--------" }   Since I was mainly interested in system-level events, I tied it all together in the Device / Log Settings tab.  I haven’t narrowed-down exactly what I want to see in the slack channel, but for the purposes of this test, I wanted to see non-informational ha or crypto events, so used the following system log filter:   (( subtype eq ha ) or (subtype eq crypto)) and ( severity neq informational )   I matched that with the “Slack System Event 1” created earlier.  The configuration looks like this:   Here’s what I see on my desktop in the Slack app when I initiate a manual HA state change via the PAN-OS GUI:     Looks good on the phone too: Created by Jared Valentine - Systems Engineer

Philips Hue Light Integration with Palo Alto Networks   Firewall configuration         So this payload makes the light blink for 15 seconds in the red color (hue:0) and afterwards stay on.   There are other alternatives possible, you can also make it blink one time in red and afterwards stay on.: {"on":true,"hue":0,"bri_inc":254,"transitiontime":0,"alert":"select”}   The advantage is that even if you’re not there, you come back and you see that the light is on in red, you know that a severe threat was detected. And if another threat is detected, it will blink again so you see this.   But other alternatives are possible of course as well as you can use the entire Philips Hue API.   And then you attach the HTTP Server Profile to the Log Forwarding Profile(s):   Here I attached it to the critical and high severity threats, as well as when WildFire saw a malicious file.   Phillips Hue Setup   You need to discover the IP address of the bridge on your network. Multiple methods exist (check out https://www.developers.meethue.com/documentation/getting-started) Once you have the address load the test app by visiting the following address in your web browser http://<bridge ip address>/debug/clip.html                                                                                                                                                                  You should see an interface like this:     We’re going to create a username, fill in the info below: Address http://<bridge ip address>/api Body {"devicetype":"my_firewall#PA-220"} Method POST Press the button Execute again the POST button You get     This is the username that you have to use in the API request "/api/<username above>/lights/1/state" that you should use in the payload format.     Each light has its own URL. You can get information about the different lights through the API, or you can go through the different id’s if it aren’t that many. Configure according to the screenshots above Commit / Done / Happy blinking Written by Steven De Pauw / SE Belgium & Luxemburg

Disclaimer This document is intended as an easy example on how to leverage action oriented and selective log forwarding in PAN-OS 8.0, not as a comprehensive solution document.   Goal This document summarizes the information and relevant steps to integrate Palo Alto Networks Next-Generation Firewalls with Aruba Instant Access Points to automatically disconnect and blacklist a device from the wireless network based on something detected by the firewall (use of an application, access to a honeypot, C&C, vulnerability exploits, etc). This can be done with Panorama and Aruba ClearPass to apply to larger implementations, but for simplicity I used a single firewall with a single IAP.   Action-Oriented Log Forwarding using HTTP To enable better integration between your firewall and IT infrastructure, PAN‐OS 8.0 gives you the ability to trigger an action or initiate a workflow to an external HTTP‐based service, when a log is generated on the firewall. You can now forward logs from the firewall or Panorama to an HTTP(S) destination to accomplish the following task more easily.   Send an HTTP‐based API request directly to a third‐party service to trigger an action based on the attributes in a firewall log. You can configure the firewall to work with any HTTP‐based service that exposes an API, and modify the URL, HTTP header, parameters, and the payload in the HTTP request to meet your integration needs. This capability when used with the Selective Log Forwarding Based on Log Attributes allows you to forward logs that match a defined criteria so that you can automate a workflow or an action; you do not need to rely on an external system to convert syslog messages or SNMP traps to an HTTP request. 
   ARUBA IAP API ArubaOS allows you to set up customized external captive portal user management using its native XML API interface. The XML API interface allows you to create and execute user management operations seamlessly onbehalf of the clients or users. You can use the XML API interface to add, delete, authenticate, or query a user or a client.   Create an XML request with an appropriate authentication command and send it to the controller via HTTPS post. The format of the URL to send the XML request is:   https://<controller-ip/auth/command.xml   In which, controller-ip is the IP address of the controller that will receive the authentication request xmlis the XML request that contains the details of authentication. The format of the XML API request is: xml=<aruba command="<authentication_command>"> <options>Value</options> ... <options>Value</options> </aruba>   You can specify any of the following commands in the XML request: Table 1 XML API Authentication Command Authentication Command Description user_add This command adds the user to the controllers user table. user_delete This command deletes the user from the controller user_authenticate This command will authentication the user based on the authentication rules defined in the controllers configuration. user_blacklist This command will block a user from connection to your network. user_query This command will display the current status of the user connected to your network.   The authentication command requires certain mandatory options to successfully execute the authentication tasks. The list of all available options are: Table 2 Authentication command options Options Description Range / Defaults ipaddr IP address of the user in A.B.C.D format. — macaddr MAC address of the user aa:bb:cc:dd:ee:ff format. Enter MAC address with colon. user Name of the user. 64 character string role Role name assigned after authenticating. 64 character string password The password of the user used for authentication. — session_timeout Session time-out in minutes. User will be disconnected after this time. — authentication Authentication method used to authenticate the message and the sender. You can use any of MD5, SHA-1 or clear text methods of authentication. This option is ignored if shared secret is not configured. It is, however, mandatory if it is configured. — key This is the encoded SHA1/MD5 hash of shared secret or plaintext shared secret. This option is ignored if shared secret is not configured on the switch. The actual MD5/SHA-1 hash is 16/20 bytes and consists of binary data. It must be encoded as an ASCII based HEX string before sending. It must be present when the controller is configured with an xml-api key for the server. Encoded hash length is 32/40 bytes for MD5/SHA-1.   version The version of the XML API interface available in the controller. This field is mandatory is all requests. Current version 1.0   Palo Alto Networks Next-Generation Firewall Configuration Steps Follow the firewall quick start guide to get a working environment where traffic from wireless users is traversing the firewall and logs are being generated. Create an HTTP Server Profile and add the IAP IP address with protocol HTTPS, port 443 and HTTP Method POST                             Define the payload format for all relevant log types   xml=<aruba command="user_blacklist"> <ipaddr>$src</ipaddr> <authentication>cleartext</authentication> <key>shared-key</key> <version>1.0</version> </aruba>   Create a Log Forwarding Profile with a match list and select the HTTP server profile created earlier. Create a filter and assign it to the Log Forwarding Profile. In the example I have used a URL match to simplify the testing. Once it is working you can define an appropriate filter to match what is required on your environment. Apply the log forwarding profile to the rule/s that allow traffic from the wireless network   Aruba Instant Access Point Configuration Steps Follow Aruba instructions to get a working IAP with at least one SSID Enable Blacklisting on the SSID   Configure the XML API server from More – Services – Network Integration, using the firewall management IP address and the shared-key. The Palo Alto Network firewall integration is optional and not required (but recommended) Configure the blacklisting timeouts Assign a certificate to the IAP captive portal that is trusted by the firewall (you can create a trusted CA in the firewall and generate the certificate for the IAP)   Testing the Integration You can send a test log from the http server profile payload format definition $src won’t resolve to the actual source IP address, but $src can be manually replaced with a testing client IP (a commit is required before sending the test log) A blacklisted client is immediately disconnected from the wireless and it will show under Info   Created by Mauricio Sabena

Build your own visual alert DUCKhickey that integrates with the Palo Alto Networks platform using the HTTP Log Forwarding feature in PAN-OS 8.X and above. I configured the SOC Duck in the Black Hat NOC to trigger and light up with threat alerts. The alerts are configurable for how and when the SOC Duck is triggered.

Disclaimer This document is intended as an easy example on how to leverage action oriented and selective log forwarding in PAN-OS 8.0, not as a comprehensive solution document.   Goal In this document I’ll summarize the information and relevant steps to integrate Palo Alto Networks Next Generation Firewalls with Twilio to send SMS mssages based on something detected by the firewall (use of an application, access to a honeypot, C&C, vulnerability exploits, etc).   Action‐Oriented Log Forwarding using HTTP To enable better integration between your firewall and IT infrastructure, PAN‐OS 8.0 gives you the ability to trigger an action or initiate a workflow to an external HTTP‐based service, when a log is generated on the firewall. You can now forward logs from the firewall or Panorama to an HTTP(S) destination to accomplish the following task more easily. Send an HTTP‐based API request directly to a third‐party service to trigger an action based on the attributes in a firewall log. You can configure the firewall to work with any HTTP‐based service that exposes an API, and modify the URL, HTTP header, parameters, and the payload in the HTTP request to meet your integration needs. This capability when used with the Selective Log Forwarding Based on Log Attributes allows you to forward logs that match a defined criteria so that you can automate a workflow or an action; you do not need to rely on an external system to convert syslog messages or SNMP traps to an HTTP request. 
   Getting Started with Twilio Twilio allows you to add capabilities like voice, video and messaging to our applications. Through a native REST API, Twilio can send messages that we generate from our firewall to network adminstrators.   First, sign up with an account on twilio.com.   Under “Which product do you plan to use first?” choose SMS.   Under “Choose your language” choose Python.   Under “What are you building?” choose IT Service Alerts.   Under monthly interactions choose “Not a production app”.                     Once you have completed the signup page, Twilio will now prompt you to enter your phone number. Make sure this is a number that can receive text messages.     Once you have completed the sign-up, your screen should now look like this.     Select “Get a number” or if that’s not available, go to this URL: https://www.twilio.com/console/phone-numbers/trial-number/modal?capability[]=sms   Twilio will suggest a number for you, if you don’t like it, click “Search for a different number”.   Once you have your number, note it down. In this guide, I’ll be using my number +16693337828, but whenever you see that number replace it with yours.   Note that Twilio starts you off with a trial account with $14.50 in credit. While you are on a trial account, Twiio can only send messages to numbers verified on Twilio. In addition, Twilio prepends all messages sent by trial accounts with “Sent from your Twilio trial account - ”.   In your twilio console, navigate to the dashboard (https://www.twilio.com/console/sms/dashboard). Here’s how mine looks:       If you can’t see your API credentials don’t worry! On the top right, below the black bar, click “Show API Credentials”.   Click the eye to unhide your Auth Token. Now your console should display both your SID and your Auth Token, here’s how mine looks.             Note both of these down. By now you should have stored your Account SID, Auth Token, and Twilio Phone Number somewhere safe.   Palo Alto Networks Next Generation Firewall Configuration Steps - Follow the firewall quick start guide to get a working environment where traffic from users is traversing the firewall and logs are being generated. Create a HTTP Server Profile, use address “api.twilio.com”, protocol “HTTPS”, port “443” and HTTP Method “POST”. Use your account sid and auth token for username and password respectively. Test Server Connection should return “https://api.twilio.com:443 succeeded”. Define the payload format for whichever logs you’d like to forward. I want to forward threat logs to Twilio so, I’ll just edit the Threat Log Payload. In URI format, copy and paste the following string “/2010-04-01/Accounts/{YOUR SID}/Messages”, except where it says YOUR SID, post the SID you got from Twilio before. For example, my SID was “AC4e43865b1e0e705950b7600686135898” so my URL becomes:   /2010-04-01/Accounts/AC4e43865b1e0e705950b7600686135898/Messages   Next, in Payload, copy and paste:   To="YOUR NUMBER"&From="TWILIO NUMBER"&Body=”Body Format Here"   except replace YOUR NUMBER with your personal number and TWILIO NUMBER with the number Twilio gave you. Note that you must prepond the numbers with +1, otherwise this won’t work. In the body, you can choose what you want Twilio to send, here I just want to send the sequence number of the log. Here’s how my completed Payload looks like:   To="+14692345456"&From="+16693337828"&Body="$seqno"   Here are some payload formats you can use for each log type:   Note: Change the {RECEIVER} with your phone number(prepend 1), ex: +14669134345 Change the {TWILIO#} with your twilio number(prepend 1), ex: +15421341368   System To=“{RECEIVER}”&From=“{TWILIO#}”&Body="$time_generated $severity $module $opaque”   Threat To=“{RECEIVER}”&From=“{TWILIO#}”&Body="$time_generated $severity $threatid $thr_category From: $src $srcuser To:$dst"   Traffic: To=“{RECEIVER}”&From=“{TWILIO#}”&Body="$time_generated From: $src $srcuser To: $dst $app"   URL To=“{RECEIVER}”&From=“{TWILIO#}”&Body="$time_generated $category $url_idx From $src $srcuser To: $dst $dstuser with $app"   Data To=“{RECEIVER}”&From=“{TWILIO#}”&Body="$time_generated $category $filedigest $filetype From: $src $srcuser To:$dst $app"   Wildfire To=“{RECEIVER}”&From=“{TWILIO#}”&Body="$time_generated $severity $action $filedigest From:$src To:$dst $dstuser thru: $app"   Once this is all finished, click ok and commit this to panorama. Once it’s finished committing, go back to the HTTP profile you created, select the log type you were just editing in Payload Format. Your URI and payload should pop up. Click “Send Test Log”. If everything was set up correctly, you can expect a text message on your phone!   Now you can create a Log Forwarding Profile with a match list and select the HTTP server profile(in my case “Twilio”) created earlier.   Create a filter and assign it to the Log Forwarding Profile. I used a URL match to simplify the testing. Once it is working you can define an appropriate filter to match what is required on your environment.   Apply the log forwarding profile to the rule/s you want.