PaloAlto Firewall integration with OSSEC
OSSEC + Palo-Alto
OSSEC currently does not include any decoders or rules for Palo-Alto Networks Next-Generation firewalls. I just happen to have access to one of these devices and wished to get some logs into OSSEC. A little search on the interwebs only turned up a single relevant link. Xavier Mertens wrote a quick blog post during the second edition of OSSEC week in 2010. Thanks Xavier for putting it out there and getting people to see how it can be done. So let’s go about making it a cleaner and more comprehensive example.
OSSEC is a LIDS that acquires, categorizes, filters, correlates and takes action on logs. It is very elegant in solving many thorny problems related to cross-platform lightweight secure log acquisition. It also integrates wonderfully with other tools for search (ElasticSearch, Splunk for OSSEC) or even full blown SIEM solutions.
Having used these firewalls for a while now (and free time away from reading vintage Dragon magazines) I wanted to get these things truly integrated with a security process. It pings, it forwards, it filters! The rules, filters, vulnerability/intrusion/threat detection and other nobs are tuned. This things is impervious as it can be now. All done, right? Not really…
Your mind wanders thinking about Kelly in accounting hmmm.. Sweet thought. All of a sudden, the office romance squirts out of mind and is replaced with a vague sense of unease. You remember something about security policy documents, best practices and internal auditor visits for one of those Pissy Eye or NERD compliance audits. oh yeah… answering questions like
- Who last changed something in the firewall
- Do threats get flagged to administrators
- Who tried to login to the firewall and succeeded (or failed)
- Have I just run out of IP addresses in the DHCP pool
- Did an internal client just port scan the firewall
- Did that internal client also do failed logins against another device
- Is a domain admin account surfing on the internet?
Logging in to the device and answering the questions is a fail. If it is not automated, the process is doomed to fail or be inconsistently followed. Lucky for us, OSSEC can do the hard work, keep the bosses (and auditors happy) and have the security admin on top of things.
Decoding Palo-Alto format syslog messages
The first step is to look at what type of log message would be generated by the device. Let’s use the log entry from the linked article.
Aug 26 13:56:07 192.168.0.5 1,2010/08/26 13:56:07,0003Z100245,THREAT,\ vulnerability,8,2010/08/26 13:56:01,10.0.0.1,10.0.0.2,0.0.0.0,\ 0.0.0.0,rule2,domain\user,,netbios-ns,vsys1,TAP-ZONE,TAP-ZONE,ethernet1/1,\ ethernet1/1,Logger,2010/08/26 13:56:07,136674,3,137,137,0,0,0x8000,udp,\ alert,"",NetBIOS nbtstat query(31707),any,low,client-to-server
Okay, it is a comma delimited, the date format is okay, it has fixed numbers of fields and lots of information. The Palo-Alto can also be customized to add or substract fields in the syslog profile settings. Do not do this unless you want to customize all your rules!!! So this is actually a pretty easy format to work with in OSSEC.
Second is to create a generic decoder for all Palo-Alto devices. To do this create a local_decoder.xml file in your ./ossec/etc/ directory. This file will contain anything that is specific to your installations. This file will not be overwritten during an upgrade!
OSSEC decoder tree entry point – it’s a Palo Alto Firewall
Lets go and identify what is unique about PaloAlto devices. Add this to your local_decoders.xml file.
<!-- Custom decoder for PaloAlto Firewalls Events --> <decoder name="paloalto"> <prematch>^\d,\d\d\d\d/\d\d/\d\d \d\d:\d\d:\d\d,\w\w\w\w\w\w\w\w\w\w\w+,</prematch> </decoder>
[Editors note, an issue slipped by in the original prematch, as the id number is now 12 digits with newer version of PAN-OS!]
The unique key here, is the series of \w, which are the serial number of the device.
For regex purists, OSSEC only has the basics and is not as greedy. Learn more about OSSEC regex syntax here.
Identify the type of event and extract fields
Next, we want to identify a type of event which in our example above is THREAT.
<!-- Custom decoder for PaloAlto Firewalls THREAT Events --> <decoder name="paloalto-threat"> <parent>paloalto</parent> <prematch offset="after_parent">^THREAT,</prematch> <regex offset="after_parent">^(THREAT,\w+),\.*,\.*,(\d+.\d+.\d+.\d+),(\d+.\d+.\d+.\d+),\d+.\d+.\d+.\d+,\d+.\d+.\d+.\d+,\.+,(\w*\\*\w*),(\w*\\*\w*),(\w*),\.+,(\.*),\w*,(\w*),\w*$</regex> <order>id,srcip,dstip,srcuser,dstuser,protocol,action,status</order> </decoder>
Extracted fields are based on what can help for policy and incident response. The decoder will extract the required information and fill the OSSEC variables.
- The type of threat
- The source IP address
- The destination IP address
- The source user (when linked to the Active Directory or auth portal)
- The destination user (when linked to the Active Directory or auth portal)
- The reported protocol implicated
- The action taken by the firewall (alert, deny, block-ip, allow, drop-all-packets)
- The severity of the detection threat (informational, low, medium, high, critical)
Classify events based on severity of the event
Now we want to classify some of these events. We will use the severity of the alert for this. This makes it easy to capture all events and filter as desired. Notice we go from the general to the specific.
Syslog (not shown) -> Device Decoder -> Event Type Decoder -> Categories for that type
<group name="syslog,paloalto,threat,">
<rule id="101000" level="0">
<decoded_as>paloalto</decoded_as>
<id>^THREAT</id>
<description>PaloAlto Firewall Event</description>
</rule>
<rule id="101001" level="12">
<if_sid>101000</if_sid>
<status>critical</status>
<description>Critical threat event!</description>
</rule>
<rule id="101002" level="12">
<if_sid>101000</if_sid>
<status>high</status>
<description>High threat event!</description>
</rule>
<rule id="101003" level="8">
<if_sid>101000</if_sid>
<match>medium</match>
<description>Medium threat event!</description>
</rule>
<rule id="101004" level="8">
<if_sid>101000</if_sid>
<match>low</match>
<description>Low threat event!</description>
</rule>
<rule id="101005" level="5">
<if_sid>101000</if_sid>
<match>informational</match>
<description>Informational threat event!</description>
</rule>
Using security policy to drive creation of further rules
Next steps would be based on your security policy. What critical assets are being protected, what systems are involved, what data and how can it be logged or tracked. Use OSSEC to identify anomalies to your normal baseline. What events can also be dropped from being alerted on for things liked low severity blocked threats from outside to inside.
Example anomalies that would differ from an expected baseline :
- Time based anomalies for data or system access (success or failure)
- Credential based anomalies for data or system access (success or failure)
- Quantity based anomalies for data or system access (success or failure)
- Protocol based anomalies
- Traffic direction based anomalies
- Statistical anomalies of network traffic or system characteristics or data access patterns
- Policy based anomalies (ex. a domain admin account browsing the internet)
Composite rules to alert on actionable events
Finally composite rules of anomalies with external complimentary data are the automation golden cup. Covering sources like vulnerability data, server data, known bad domains or bad IPs. For example these sources can be correlated to attack vectors seen by the firewall so that they are raised as very critical events (if a successful attack is detected or possible).
Next steps – Decoding more Palo-Alto firewall event types
OSSEC and PaloAlto integration Part 2 covers other types of logs that a Palo-Alto can generate like CONFIG and SYSTEM events. As well as identifying a general categorization and specific events of interest that need to be tracked for actionable security.