PaloAlto firewall integration with OSSEC – Part 2

OSSEC + Palo-Alto

ossec-hidsOSSEC out of the box does not include any decoders or rules for Palo-Alto Networks Next-Generation firewalls. This is part 2 of PaloAlto firewall integration with OSSEC. Read part one to learn how to create the basic decoder, a threat decoder and rules. In this part we will learn how to decode SYSTEM and CONFIG event logs.

Decoding Palo-Alto syslog messages

paloalto_medium-300x68 The general decoder for PaloAlto firewalls is defined in part one. Now we need to decode SYSTEM and CONFIG event logs. Each type of logs has different arguments, but they still follow the same comma delimited format. We will use the following two log messages for our decoders.

Mar 19 18:05:17 192.168.1.1 1,2013/03/19 18:05:17,0016A102121,
CONFIG,0,0,2013/03/19 18:05:17,192.168.1.120,,commit,username,Web,Submitted,,993,0x0
Mar 19 18:34:27 192.168.1.1 1,2013/03/19 18:34:27,0016A102121,
SYSTEM,general,0,2013/03/19 18:34:27,,general,,0,0,general,high,
System restart requested by username,1261490,0x0

Identify the types of event and extract fields

Add the following decoders to your $OSSEC/etc/local_decoder.xml file.

CONFIG events:

<!-- Custom decoder for PaloAlto Firewalls CONFIG Events -->
<decoder name="paloalto-config">
 <parent>paloalto</parent>
 <prematch offset="after_parent">^CONFIG,</prematch>
 <regex offset="after_parent">^(CONFIG),\.*,\.*,\.*,(\d+.\d+.\d+.\d+),\.*,(\w+),(\w+),</regex>
 <order>id,srcip,action,srcuser</order>
</decoder>

Extracted fields are based on what can help for policy and correlation rules. The decoder will extract the required information and fill the OSSEC variables.

  • id of the event (CONFIG)
  • source IP
  • action that was submitted
  • source user of the action
<!-- Custom decoder for PaloAlto Firewalls SYSTEM Events -->
<decoder name="paloalto-system">
 <parent>paloalto</parent>
 <prematch offset="after_parent">^SYSTEM,</prematch>
 <regex offset="after_parent">^(SYSTEM,\w*),\.*,\.*,\.*,\.*,\.*,\.*,\.*,\.*,(\w+),(\.*),\.*,</regex>
 <order>id,status,action</order>
</decoder>

Extracted fields:

  • The id of system event (SYSTEM,sub-id)
  • The severity/status of the event (informational, low, medium, high, critical)
  • The action message including the username that generated the event

This last one is a bit problematic as both the message and the event are important, but they cannot easily be parsed, so we just group ’em together.

Creating rules for CONFIG events

Configuration events are more unique and need rules to target events that are matched to policies.

Add the rules to your $OSSEC/rules/local_rules.xml file.

NOTE : Rules cannot use the decoded_as to refer to a child decoder. argh. Feature request to come… I have updated the rules to reflect this and use the id to include the event identifier with the order tag. (CONFIG, SYSTEM or THREAT)

NOTE2 : <action>xxxx</action> seems to be broken in 2.8.x, use <match>xxxx</match> instead.

<group name="syslog,paloalto,config,">
  <rule id="101200" level="3">
    <decoded_as>paloalto</decoded_as>
    <id>^CONFIG</id>
    <description>PaloAlto Firewall Config Event</description>
  </rule>

  <rule id="101201" level="3">
    <if_sid>101200</if_sid>
    <action>commit</action>
    <group>config_changed</group>
    <description>Configuration changed and commited</description>
  </rule>

  <rule id="101202" level="10">
   <if_sid>101200</if_sid>
   <time>7:00 pm – 8:00 am</time>
   <description>Configuration changed outside business hours.</description>
   <group>policy_violation</group>
  </rule>

Other interesting events to consider :

  • Add/remove users
  • Change administrative privileges
  • Source IP doing the changes
  • Expected user doing changes (and type of changes)

 Creating rules for SYSTEM events

System events have a severity, let’s start by classifying them by severity.

Add the rules to your $OSSEC/rules/local_rules.xml file.

<group name="syslog,paloalto,system,">

  <rule id="101100" level="3">
    <decoded_as>paloalto</decoded_as>
    <id>^SYSTEM</id>
    <description>PaloAlto Firewall System Event</description>
  </rule>

  <rule id="101101" level="8">
    <if_sid>101100</if_sid>
    <status>critical</status>
    <description>Critical system event!</description>
  </rule>

  <rule id="101102" level="3">
    <if_sid>101100</if_sid>
    <status>high</status>
    <description>High system event!</description>
  </rule>

  <rule id="101103" level="2">
    <if_sid>101100</if_sid>
    <status>medium</status>
    <description>Medium system event!</description>
  </rule>

  <rule id="101104" level="2">
    <if_sid>101100</if_sid>
    <status>low</status>
    <description>Low system event!</description>
  </rule>

  <rule id="101105" level="0">
    <if_sid>101100</if_sid>
    <status>informational</status>
    <description>Informational system event!</description>
  </rule>

 

Some events are categorized as medium with a level=2, but really we want to raise their level.

  <rule id="101106" level="8">
    <if_sid>101103</if_sid>
    <id>server-no-free-ip</id>
    <description>DHCP server ran out of IPs in pool</description>
  </rule>

We used one of the extracted fields , “id”, from the decoding run to speed up processing instead of doing a match.

Discussion on rules

Up to now this has been very rule based. We did introduce time based policy validation. It gets interesting when combining multiple indicators. This is where the extracted fields gain their power. Attackers are more sophisticated and it is only when combining the network view (connections, data flows, duration, data access, users, time based controls, etc.) that one can catch bad behaviour or attackers soon enough to be able to respond to the attack.

In our next part we will see how to create some more advanced behavioural rules for our PaloAlto boxes.

 

 

Written by