Security

Hey Danny,

This is great!  We've set it up here, but are having dictionary related issues with the Palo Alto.  I have a ticket open and am using the PANW-Threat-Syslog-C provided by TAC, but it's not working.  I've also tried the original PANW-Threat-Syslog and this shows event logs in the tracker between the Palo Alto and Clearpass, but no specific data is being logged.  

Any thoughts?

Thanks 

Sorry to hear your havif issues. Can you try these dictionaries please. We might also have to review your syslog setup on the PANW.

Here is the PANW syslog for THREAT.... and TRAFFIC in that order......

CEF:0|Palo Alto Networks|PAN-OS|6.0.6|$subtype|$type|$number-of-severity|rt=$cef-formatted-receive_time deviceExternalId=$serial src=$src dst=$dst sourceTranslatedAddress=$natsrc destinationTranslatedAddress=$natdst cs1Label=Rule cs1=$rule suser=$srcuser duser=$dstuser app=$app cs3Label=Virtual System cs3=$vsys cs4Label=Source Zone cs4=$from cs5Label=Destination Zone cs5=$to deviceInboundInterface=$inbound_if deviceOutboundInterface=$outbound_if cs6Label=LogProfile cs6=$logset cn1Label=SessionID cn1=$sessionid cnt=$repeatcnt spt=$sport dpt=$dport sourceTranslatedPort=$natsport destinationTranslatedPort=$natdport flexString1Label=Flags flexString1=$flags proto=$proto act=$action request=$misc cs2Label=URL Category cs2=$category flexString2Label=Direction flexString2=$direction externalId=$seqno requestContext=$contenttype cat=$threatid filePath=$cloud fileId=$pcap_id fileHash=$filedigest

CEF:0|Palo Alto Networks|PAN-OS|6.0.6|$subtype|$type|1|rt=$cef-formatted-receive_time deviceExternalId=$serial src=$src dst=$dst sourceTranslatedAddress=$natsrc destinationTranslatedAddress=$natdst cs1Label=Rule cs1=$rule suser=$srcuser duser=$dstuser app=$app cs3Label=Virtual System cs3=$vsys cs4Label=Source Zone cs4=$from cs5Label=Destination Zone cs5=$to deviceInboundInterface=$inbound_if deviceOutboundInterface=$outbound_if cs6Label=LogProfile cs6=$logset cn1Label=SessionID cn1=$sessionid cnt=$repeatcnt spt=$sport dpt=$dport sourceTranslatedPort=$natsport destinationTranslatedPort=$natdport flexString1Label=Flags flexString1=$flags proto=$proto act=$action flexNumber1Label=Total bytes flexNumber1=$bytes in=$bytes_sent out=$bytes_received cn2Label=Packets cn2=$packets PanOSPacketsReceived=$pkts_received PanOSPacketsSent=$pkts_sent start=$cef-formatted-time_generated cn3Label=Elapsed time in seconds cn3=$elapsed cs2Label=URL Category cs2=$category externalId=$seqno

 HTH

Sure, I'll look this over.  I did get the threat dictionary working to some extent.  Traffic is logging, but not matching my specific application enforcement policy.  

Thanks!

So I tried using the CEF format you linked and it didn't work for me.  I am able to get threat traffic to pass with the default log format on the PA, but for some reason I can't use any of the attributes to match an enforcement policy.  I've tried:

- rule_name

- Application

- sourceuser

I'm only using the PANW-Threat-Syslog-c dictionary, because that's the only one that works.  I tried bulding a Traffic dictionary using the Threat-Syslog-c as a reference, but it won't bring in any attirbutes in the access tracker just event and date, not PA attributes.

If I understand correctly I should be able to use the Threat dictionary for general traffic classification as well, because it is passing my application level traffic in the access tracker.  I'm not actually generatic threat traffic right now on the Palo Alto.    

In my screenshots, for testing, I have log forwarding set up on a specifc PA firewall rule that matches just my username.  I'm then trying to take a traffic classification (google-base) and add an attribute to my endpoint as a result.  As you can see from the screenshots all of my traffic is just being classified under the default enforcement profile, which is just a placeholder, of pan-update-node.  

Is this intended behavior or should I have a traffic dictionary on the CPPM side to process this ingress information?

Thanks for your help Danny!

OK - Great. All we are really only interested in seeing  'Does the Event Service, parse the inbound syslog?", and we can clearly see that it does. 

Do me a favour, do a (Event:PANW-Threat:category  EXISTS   ), and see if it triggers.....please.

Okay so I changed the enforcement profile to your requested settings.  I'm just using pan-update as my default profile and pan-enforcement for my enforcement profile for testing.  If Event:PANW-Threat:category EXISTS it should return PAN-Enforcement and so far it's not, even though the acccess tracker shows the traffic is passing the category attribute.  I'm wondering if there is some sort of issue with the dictionary matching the rule?  

I'll have more time to test this on Tuesday.  Thank you so much for your help and quick response! I do have a TAC case open on this and will be talking to them on Tuesday.  I'll update them on what we've found.

Thanks again!

Truly what a bummer..!!!!!

I'm going to ask two more favours, at some point go to Admin/Sys Manager/Server Config.... disable / enable the Ingress Event Processing.

and I want you in the services to stop/start the Ingress jobs.

Went ahead and ran through these steps.  Events stopped coming in all together.  I'm not sure why.  I had this happen the other night as well and it started back up.  I've double checked ingress processing is enabled along with the services.  Also made sure my Palo Alto is set to forward logs.  It seems like sometimes the events just stop coming in, even though I'm passing plenty of traffic through my Palo Alto.  One thing I had to do to get this working at all is add two event sources.  It will not process traffic with the syslog-c dictionary unless both are enabled.  I've tested with one or the other and restarted services several times. 

It seems as though I have things working intermittendly.  I bet I'll have logs coming through tomorrow at some point, but they may stop again.  Particularly when I turned ingress processing off then on.

Thanks for all of your help.  I'll keep testing this, espeically when I'm back at work next week!  Very cool feature and some awesome possibilites we can do with this.

Thanks!

Okay traffic is passing now and still not matching the enforcement profile.  I went ahead and tested this with my Publisher server as well (because I'm doing ingress on subscriber as it has lower CPU usage).  I ran into the same issues.  

I tested using Event:username EXISTS and was able to trigger the enforcement condition, but using any of the EVENT:PANW-threat attributes will not trigger the rule.  I'm still wondering if it's dictionary related, or maybe the pre-build EVENT:PAWN-threat enforcement rule attributes don't match whats coming through on the access tracker exactly?  

I'll keep testing different things as I can.  I'll also look at a PAN 7.1 custom CEF log filter.

Thanks again for the help!

Scott,

I don't think you have ANYTHING wrong with the dictionary of the PANW setup. We getting the Syslog and we are achieving the important step, parsing the inbound Syslog into the CPPM fields under the correct namespaces.

From your last email, do I understand correctly that you were able to trigger a passive action and update an endpoint with some context?

I've never myself tried this on a SUB, I've only ever done this on a PUB and I'm going to look into that tomorrow.

Hi Danny,

That is correct.  I can trigger an update except the completed attributes related to the Event:PANW-Threat.  So I can trigger from username or regular EVENT/DATE attributes, but when I try to trigger PANW events I get no match.  Even if it's something simple like category EXISTS like you suggested previously.  I haven't had as much time to test this as I'd like so I'll work on it a lot tomorrow when I'm back at work.

As always I appreciate the help!

Hi Danny,

Today I moved our Ingress processing onto our Publisher for testing and am experiencing the same results.  I did some additional testing to show you exactly what's happening.  Event:PANW attributes are not matching my enforcement conditions, but if I try to use other attributes like Event they work.  

I tested triggering an action based off of Event:Destination-IP-Address.  My enforcement profile is PAN-Enforcement:

Configuration

Completed Attributes for Event

Policies Used

The conditions match triggers the enfrocement profile as expected.

When I try the exact same thing using Event:PANW-threat category EXISTS or any other Event:PANW attribues, the conditions don't match and instead the default enfrocement profile of PAN-update-node is used.  

Configuration

Completed Attribute for Event

Policies used

Hopefully this better explains what I'm encountering.  

Thanks Danny!

Danny,

Got some more info.  There is a mismatch from the exact completed attributes Palo Alto sends from the dictionary attributes.  I'm going to play with the XML and see if I can get them to trigger.  Not all of the attributes are mismatched, but many are.  For example the completed attribute for category is "Category" in access tracker but lowercase "category" in the dictionary.  I noticed "rule" is "rule_name" and many oher similary mismatches.  I tested using "data1" which had matching attributes in the access tracker completed attributes.  When testing data1 EXISTS it worked fine.  The screenshots below show the access tracker completed attributes followed by the dictionary attribute.  The dictionary attribute is what shows up when I'm building the enforcement profile conditions:

rule

category

data1

data1 matches.  

When I test the matching attributes my conditions are triggered, but when I test the attributes that are not matching they don't.  

Configuration using data1

Successful result

Tomorrow morning I'm going to play with the XML file and see how it goes.  I apologize for the excess information, but I hope it'll help anyone else running into the same set of issues.

Thanks again!

Hi Danny,

I made some changes to the XML file field mappings to match what I was seeing in the attribute trackers completed attributes.  I then tested many of the attributes with a simple enforcement profile and they are now matching.  I went ahead and changed every attribute I could identify as incorrect, but I could have missed some.  

Here is the XML dictionary file (in .txt format) I modified along with some XML and log screenshots showing the new attributes.  I compared the "Completed attribute log.jpg" and the XML Dictionary new fixed.jpg"  to build the new field mappings.  Notice attributes like "Application" and "Rule" have been changed from the original file which was "application and "rule_name."  I've made several other changes as well.

Thanks for your help and pointing me in the right direction!

Attachment(s)

Event Dictionary-D.txt   8 KB 1 version