This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.

You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Linux audit log parsing

tomaddox over 4 years ago

Hi, folks,

I have been asked to implement keylogging on our Linux servers in such a way that we can search the logs and see who ran what command. Step 1 of that seems pretty straightforward: implement auditd. Since we already own SEM, it seemed like a slam dunk to feeds the logs into SEM and have it parse them. We have duly configured auditd for maximum logging (and verified that audit.log contains the required data), installed the SEM agent, configured the Linux Sudo, Linux auditd, and Linux command connectors, and verified that SEM appears to be receiving the log data.

EDIT: I fixed an issue with our auditd config, so my previous message is no longer accurate. Now, what I'm seeing is that we get an entry with the following info:

Name: FileExecute

EVENT INFO: SYSCALL for "/bin/ls" succeeded

Unfortunately, one of the key pieces of data I want is buried in the inappropriately-named "ExtraneousInfo" field, which is only displayed when I click on the event. To wit, that's the field that contains the user and group ID fields. Is there a way to create a view or filter which displays the executing auid? Is there a way to map UIDs/GIDs to the associated names in /etc/passwd and /etc/group?

Top Replies

jhynds over 4 years ago +2

There appears to be a setting you can adjust in auditd.conf that will replace the UIDs with the actual username. SEM will not automatically lookup the passed/group files, we will only parse the information…

0 jhynds over 4 years ago

There appears to be a setting you can adjust in auditd.conf that will replace the UIDs with the actual username. SEM will not automatically lookup the passed/group files, we will only parse the information contained within the log data.
Under the FileExecute events, are the SourceAccount and SourceLogonID fields populated? If not, we can adjust our parsers to take the information out of ExtraneousInfo and populate in them the correct fields. Either way, you can build filters within the Events page based on either the SourceAccount or ExtraneousField.
Cancel
Vote Up +2 Vote Down

Cancel
0 tomaddox over 4 years ago in reply to jhynds

Thanks for the auditd information. Unfortunately, it looks like the version of auditd that we're running on our test server does not support the ENRICHED directive (it's a RHEL 6 box), so we'll have to make do with the raw data until we can upgrade. It's good info for our newer systems, though!
Under the FileExecute events, the SourceLogonID is populated, which is helpful. For the purposes of this task, we also need to see the auid because SourceLogonID will correspond with the user's effective rights (e.g. if the user is using sudo, the SourceLogonID will be 0, i.e. root), whereas the auid reflects the actual logged-in user. It looks like we can construct filters to display information based on auid filtering, so I think we've got most of what we need.
Thanks for the help!
Cancel
Vote Up 0 Vote Down

Cancel