Linux Server Configuration for Enabling Honeycomb File Integrity Monitoring Services

Technical documentation detailing how to enable Honeycomb File Integrity Monitoring services on a Linux Server

Linux Server Configuration for
Enabling Honeycomb File Integrity
Monitoring Services
System Requirements
• Linux kernel v2 or higher
• Audited service installed and enabled
• Visudo sudoers editor installed and enabled
• SSH installed and enabled
Procedure Overview
The purpose of the configuration steps outlined here is to allow Honeycomb’s remote File Integrity Monitor
for UNIX to access and retrieve file system audit data from remote LINUX servers.
Honeycomb’s UNIX FIM uses SSH to access remote machines using secured credentials, and to query the
systems’ auditd system for relevant file system activity.
The steps below should be carried out on each Linux server you wish to monitor.
Make sure auditd is installed,enabled and unlocked
Run this command (as root or sudo) to check the status of auditd:
auditctl -s
If auditing is installed and running, you should see output from this command similar to this:
AUDIT_STATUS: enabled=1 flag=1 pid=999 rate_limit=0 backlog_limit=32 lost=0
If you get a ‘command not found’ or similar message, auditd is not installed. Install auditd for the chosen OS
before continuing.
If the portion of the above output does not show ‘enabled=1’ (i.e. it shows enabled=2 or enabled=0,the status
of auditd needs to be changed by running this command:
auditctl -e 1
NOTE: Changing the running status of auditd will require a reboot of the system.
© Copyright 2015 Honeycomb Technologies Ltd. All Rights Reserved.
Account Access
1. Create a local user service account.
Create an account to be used by Honeycomb’s remote monitoring service.
This account can be a normal user account, and typically will have a non-expiring, very complex password.
Implementation Note: When configuring multiple systems for monitoring, it is a good idea to use a
consistent username and password on each system. This will make policy management of data collection
simpler to manage.
2. Add permissions to sudoers via visudo.
Using the visudo utility, add permissions for the created user account.
Here are the configurations on items to be added (Note: these examples assume the username is ‘lexicon’):
lexicon ALL=(ALL:ALL) ALL
Cmnd_Alias AUDIT = /sbin/auditctl, /sbin/ausearch
User_Alias GRP_LEXICON=lexicon
Note: Some Linux environments may have a global NOPASSWD disabling directive at the end of the
sudoers file or in an included file (e.g. /etc/sudoers.d). In these cases, it is necessary to place this line:
3.Once configured and saved using visudo, your sudoers file should look similar to this (the precise entries will
vary across systems, but the commands added should look the same):
# This file MUST be edited with the ‘visudo’ command as root.
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
# See the main page for details on how to write a sudoers file.
Defaults env_reset
Defaults mail_badpass
Defaults secure_path=”/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin”
# Host alias specification
# User alias specification
# Cmnd alias specification
# User privilege specification
# START Honeycomb Lexicon sudoers permissions
# This section adds the relevant permissions/settings for allowing the
# agentless Honeycomb Lexicon UNIX FIM to perform auditing on the UNIX host.
# The only parameter in this section that can/should be changed is:
# User_Alias GRP_LEXICON
# This line can include a different username relevant for the environment on the UNIX
lexicon ALL=(ALL:ALL) ALL
Cmnd_Alias AUDIT = /sbin/auditctl, /sbin/ausearch
User_Alias GRP_LEXICON=lexicon
# END Honeycomb Lexicon sudoers permissions
# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL
# Allow members of group sudo to execute any command
# See sudoers(5) for more information on “#include” directives:
#includedir /etc/sudoers.d
© Copyright 2015 Honeycomb Technologies Ltd. All Rights Reserved.
1. Check SSH is configured and running.
As root or sudo user, run this command:
service sshd status
You should see something similar to this:
openssh-daemon (pid 999) is running…
If you see output such as unrecognized service, the ssh package is not installed. Install sshd before
If you don’t see the ‘is running’ part in the output, the service is not enabled and/or not running. Enable the
service, set it to auto start, and start the service before continuing. SSH is required to be running in order to
be able to connect and monitor the device.
1. The Linux Firewall, iptables, needs to be configured to allow ssh sessions. For production machines, it is
recommended to only allow ssh from specific source addresses, and these addresses will be specified in
iptables. Here, we need to allow ssh sessions from the address of the remote machine running the
Honeycomb File Integrity Monitor policy.
As root or sudo user, add a rule to iptables to allow ssh from the remote machine.
In this example, the remote ip address is 192,and the SSH port is 22 (the default).
iptables -I INPUT -s 192 -p tcp -m tcp –dport 22 -j ACCEPT
This rule should go towards the end of your INPUTS section, but before any rules that would otherwise block
this rule.
Verification and Testing
It’s generally prudent to test each of the above steps as they are performed to minimize troubleshooting later
As a final connectivity test, once all the steps are completed, to check everything is in working order, here are a
few simple tests to perform:
Using Putty or similar SSH terminal utility, logon to the remote machine from the source device that is/will run
he Honeycomb File Integrity Monitoring Policy.
You should be able to successfully logon as the user created above with the associated credentials.
Once logged on to the SSH session,run the following commands to ensure the user has the correct access:
auditctl test:
sudo auditctl -s
You should see output similar to this:
AUDIT_STATUS: enabled=1 flag=1 pid=999 rate_limit=0 backlog_limit=320 lost=0
ausearch test:
sudo ausearch -k _lexfim
You should see this output:
<no matches>
Note: If the Honeycomb FIM Policy has previously monitored this machine, you may see data results. If
so, this is also considered a pass for this test.
stat test:
sudo stat /etc/services
You should see file properties in the output.
If you encounter any errors running these commands, there may be an access, permissions or other problem
that will need addressing.
© Copyright 2015 Honeycomb Technologies Ltd. All Rights Reserved.