PaloAlto Firewall Threat Monitoring Using OSSEC

Usually, I don’t speak or even try to give references to commercial security products on my blog. Why? Just because, my philosophy is the following: “First analyze the problems and then choose the right solution(s)“. The proposed solution could be commercial or free, hardware or software based, who cares? If it solves my problem and fulfill the requirements (in terms of budget, support, feaures, etc). I won’t present the PaloAlto Networks firewalls (they’re plenty of resource available online – Google is your best friend). The reputation of the next-generation firewalls quickly grew for the last months, that’s the reason why they are more and more deployed in organizations.

And, to be fully integrated in the infrastructure, they must be properly monitored. An interesting feature of the PaloAlto firewalls is the built-in threat detection. Suspicious traffic will generate specific log entries (of type “THREAT”). Those events are of a great interest and must be properly collected and processed. Of course, PaloAlto comes with its own management tools but it is much more efficient to centralize everything using a log management platform. Here again, there are commercial solutions but why not use OSSEC for this purpose? A PaloAlto firewall can be configured to send generated events to a Syslog server. Here is an example of threat event:

  Aug 26 13:56:07 192.168.0.5 1,2010/08/26 13:56:07,0003A100245,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

Honestly, the format used by PaloAlto is not easy to process via regular expressions. Why did they use comma-delimited fields!? But OSSEC is powerful and can “learn” new file formats using custom decoders. The goal will be to trigger an alert when a threat event is detected and to extract useful information like:

• The source IP address
• The destination IP address
• The source user (linked to the Active Directory)
• The destination user (linked to the Active Directory)
• The reported threat

Let’s go! The OSSEC decoders are stored in your existing “decoder.xml” file. Add the following code at the end of your existing file:

<!-- Custom decoder for PaloAlto Firewalls Threat Events -->
<decoder name="paloalto-threat">  
  <prematch>^\d,\d\d\d\d/\d\d/\d\d \d\d:\d\d:\d\d,\.+,THREAT,</prematch> 
  <regex>(\d+.\d+.\d+.\d+),(\d+.\d+.\d+.\d+),\d+.\d+.\d+.\d+,\d+.\d+.\d+.\d+,\.+,(\.*),(\.*),\.+,alert,\.+,(\.+),\.+$</regex>
  <order>srcip,dstip,srcuser,dstuser,extra_data</order>
</decoder>

The decoder will extract the required information and fill the OSSEC variables: “srcip”, “dstip”, “srcuser”, “dstuser” and “extra_data” (this one will contain the threat description). The second step will be to create one or more alerts to match all threat events. Here are some examples:

<group name="syslog,paloalto-threat,">
  <rule id="150000" level="0">
    <decoded_as>paloalto-threat</decoded_as>
    <description>PaloAlto Firewalls Threat Events</description>
  </rule>

  <rule id="150001" level="10">
    <if_sid>150000</if_sid>
    <match>NetBIOs</match>
    <description>Possible NetBIOS attack detected!</description>
  </rule>

  <rule id="150002" level="10">
    <if_sid>150000</if_sid>
    <user>domain\administrator</user>
    <description>Possible attack detected against Administrator!</description>
  </rule>
</group>

Once done, restart your OSSEC server to enable the newly created rules. This simple example reveals the power of OSSEC to detect suspicious activity occurring in non-standard applications and log formats. This article is a preliminary to the second annual week of OSSEC. An event initiated by Michael Starks. More to come!