Is it possible to get accounting data with Splunk Add-on for CP OPSEC LEA?

[btiggemann]

Hi Splunkers,

we are looking for accounting data in the Check Point traffic log (sourcetype=opsec). For example send and received bytes per session.

Currently we don't see this information:

sourcetype=opsec

loc=12029517|time=22Jul2016  7:37:33|action=accept|orig=8.8.8.8|i/f_dir=inbound|i/f_name=eth2-07|has_accounting=0|uuid=<5791b11d,0000000d,82ec14ac,c0000003>|product=VPN-1 & FireWall-1|inzone=Internal|outzone=Internal|rule=1378|rule_uid={C56C9FDC-A90F-4527-870A-E8F851CFDDDE}|service_id=domain-udp|src=1.1.1.1|s_port=64101|dst=11.22.33.216|service=53|proto=udp|user=Jimmy, Carter (pc12)(+)|src_user_name=Jimmy,Carter(pc12)(+)|snid=67e4d890|__policy_id_tag=product=VPN-1 & FireWall-1[db_tag={821C6959-613E-C347-9268-4C2729ACFCFF};mgmt=dummy;date=1469115508;policy_name=010_dummy]|origin_sic_name=CN=gateway1,O=dummy..w25isr

Is the TA able to pull this information, if enabled at the Smart Center?
Does anybody know what to do one Check Point site?

Thanks in advance.

[mnatkin_splunk · Accepted solution]

Hi @btiggemann

When configuring the connection, I recommend using "non_audit" as the data type, as this grabs all non-audit information. A little background may be in store at this point...

Check Point maintains two (2) distinct and separate active log files at any one time:

• activity logs ($FWDIR/log/fw.log)
• and audit logs ($FWDIR/log/fw.adtlog)

LEA theoretically supports the ability to filter which types of logs in the activity log we receive, such as:

• Firewall Events: Collects firewall events only.
• SmartDefense: Collects IPS (the artist formerly known as Smart Defense) events only.
• VPN (Virtual Private Network): Collects VPN events only

The filtered log types map to the sourcetypes we recognize, as listed in our documentation here: http://docs.splunk.com/Documentation/AddOns/released/OPSEC-LEA/Sourcetypes

As I mentioned, I generally recommend against using this mechanism to filter what's ingested into Splunk, and strongly recommend customers stick with "non-audit." The reason for this is there's a bit of fluidity in the sourcetypes, especially as related to IPS and protocol handlers. If I'm only collecting SmartDefense type log information, I may miss logs of traffic dropped against the protocol inspection engine (Application Intelligence). I'd rather bring it all in and filter later.

Accounting logging is a native feature for the Check Point Logging software blade. I am not aware of any additional license required to activate it -- you can confirm whether the Monitoring software blade is required for accounting information with your friendly neighborhood Check Point account team or Check Point support. The examples provided above are off my lab R77.20 SmartCenter or my NGSE SmartEvent log server (I do own the Monitoring SoftwareBlade and have it active on my gateways). I've produced results similar to what I depicted above using R77.20 (with the SHA hotfix), R77.30, NGSE, and R80. In short, if Check Point is producing the accounting log, you should be receiving it via LEA.

I suggest the following:

1. Log into SmartDashboard, and verify the rule or rules for which you want accounting information. If you've enabled hit counting, you should see a non-zero value for the hit count if the rule has been used. Remember, first rule match wins. If you have a rule above your accounting rule that matches the traffic pattern, it will use the logging method noted on that rule, and not your accounting rule. Once you've confirmed that the configuration looks good, push (install) policy to the gateway(s) -- for good measure. You can confirm that the gateway received the policy by typing "fw stat" or "cpstat fw" on the gateway.
2. Log into SmartView Tracker, and filter either on the rule number in question and/or for accounting logs only (by default, the 7th column in Tracker)

Alternatively, if you're using SmartLog, you can filter for accounting logs there by specifying "type:Account" in the search bar

If you don't see any accounting logs natively, then there's an issue with your Check Point configuration.

I hope this helps.

[btiggemann]

Hi @mnatkin,
this helps of course a lot. Thanks, for this details again.
We have deactivated the non_audit data_type because we are not interested in the VPN logs.
But now I will change that and filter it out later on.
I will ask our customer if he is able to verify the accounting filter in his Smart Center.
I will give you feedback, as soon we have tested it.
regards
Benjamin

[btiggemann]

Hi mnatkin,

thanks a lot. With your help, we have solved the problem.
We have changed the connection to non_audit and we have updated the Checkpoint TA.
I found out, that we where have used an older version of it. Version 4.1.0 is working better.
Unfortunately the switch from 3.1 ot 4.1 was very time consuming because the configuration file naming and maybe the syntax of the config files was changed. So we had to reconfigure the whole app and we have added some filter to props.conf to filter out all encrypt and decrypt events as well.
But that's not a big deal.

best regards
Benjamin

[btiggemann]

Hi mnatkin,

thanks for your detailed answer. This is exactly what we are looking for. We have verified the LEA document and then we tried the following on a Check Point environment on version R77.30:

1. We have switched the track option on a security policy rule from LOG to ACCOUNT.
2. Then we have generated a communication that hits this rule.
3. After that we have verified, that the session was ended correctly. (I believe the accounting event is only generated if the session is closed.

At last we have looked at Splunk to verify if there is a event containing the bytes and packets field you have shown above.

The result: We have only seen one event per session without accounting information.

Now I have some additional questions:
Can you tell us the source that you have used to get your accounting values? You know there are different config entities... non_audit, audit, ips and so on....
What version of CP is running at your site?
Could it be, that accounting needs to be licensed additionaly?

Thanks in advance for your great help, we had the same topic at several customers. Hopefully we can fix it now.

best regards
Benjamin

[mnatkin_splunk]

LEA natively will include accounting information if the rule is configured to support it - this is part of the LEA "standard."

From the 2011 LEA Update document:

When a user specifies Account as the Track option, in a Security Policy rule for instance, byte information is included in the log record.
Note: In NG log records are composed of fragments and fragments of the same chain might be spread over the log file and sometimes even across file boundaries. When the file read mode is Unified updates in the form of record fragments like accounting bytes are not available in LEA_ONLINE mode. When the file read mode is not Unified then record fragment updates should not be counted as separate connections.

The thing that can be very confusing about accounting is that not every log entry for a rule with accounting enabled with include accounting data. The reason for this is that Check Point will often generate two log entries for any rule hit with accounting enabled

The following are the fields included in accounting logs:

• bytes (LEA_VT_INT) - The number of bytes transmitted in the connection.
• elapsed (LEA_VT_DURATION_TIME) - the duration of the connection
• has_accounting (LEA_VT_INT) - When 1, this indicates that the log record has a matching record in the accounting log
• packets (LEA_VT_INT) The number of packets in the session
• segment_time (LEA_VT_TIME) - Presence of this field indicates the connection has closed.
• start_time (LEA_VT_TIME) - The date and time the connection started. Use the elapsed field to calculate the time the connection ended.

From personal experience, I can tell you that I have never seen the "has_accounting" field populated with anything but "0". Here, however, is an example of a log event from my Splunk environment at home being fed by Check Point:

time=1478265919|loc=105729|fileid=1478231941|action=accept|orig=192.168.1.1|i/f_dir=inbound|i/f_name=eth0|has_accounting=0|uuid=<581c8c3f,00000001,0101a8c0,c0000000>|product=VPN-1 & FireWall-1|inzone=Internal|outzone=DMZ|rule=33|rule_uid={0AD23AF3-7991-405D-A22B-BFB88BBE0B1A}|rule_name=Misc Out|src=192.168.1.153|s_port=50134|dst=198.51.100.7|service=8000|proto=tcp|__policy_id_tag=product=VPN-1 & FireWall-1[db_tag={1C2E2384-57BA-5B4C-9F2A-2C0A4EDABE04};mgmt={obfuscated};date=1473349961;policy_name=Main_FW]|origin_sic_name=CN={obfuscated}|start_time= 4Nov2016  9:25:19|segment_time= 4Nov2016  9:25:19|elapsed=0:00:00|packets=2|bytes=104|client_inbound_packets=1|client_outbound_packets=1|server_inbound_packets=1|server_outbound_packets=1|client_inbound_bytes=64|client_outbound_bytes=40|server_inbound_bytes=40|server_outbound_bytes=64|client_inbound_interface=eth0|server_outbound_interface=eth3|__pos=7|__nsons=0|__p_dport=0

and here is the corresponding initial hit in the log: (note "has_accounting=0"):

time=1478265919|loc=235290|fileid=1478032508|action=accept|orig=192.168.1.1|i/f_dir=inbound|i/f_name=eth0|has_accounting=0|uuid=<581c8c3f,00000001,0101a8c0,c0000000>|product=VPN-1 & FireWall-1|inzone=Internal|outzone=DMZ|rule=33|rule_uid={0AD23AF3-7991-405D-A22B-BFB88BBE0B1A}|rule_name=Misc Out|src=192.168.1.153|s_port=50134|dst=198.51.100.7|service=8000|proto=tcp|__policy_id_tag=product=VPN-1 & FireWall-1[db_tag={1C2E2384-57BA-5B4C-9F2A-2C0A4EDABE04};mgmt={obfuscated};date=1473349961;policy_name=Main_FW]|origin_sic_name={obfuscated}

In short, it's in there, you just need to know what to look for.

HTH

[jcoates_splunk]

It doesn't, that would be useful though.