Note: As of July 1, 2022, DigitalOcean no longer supports FreeBSD Droplets through the Control Panel or API. However, you can still spin up FreeBSD Droplets using a custom image. Learn how to import a custom image to DigitalOcean by following our product documentation.
OSSEC is an open source, host-based intrusion detection system (HIDS) that performs log analysis, integrity checking, Windows registry monitoring, rootkit detection, time-based alerting, and active response.
It’s one of the most important security applications you could install on your server and it can be used to monitor one machine or thousands in a client/server or agent/server fashion. If properly configured, OSSEC can give you a view into what’s happening on your server via email alerts to any number of configured email addresses.
This tutorial will show you how to install and configure OSSEC to monitor a server running FreeBSD 10.1. In addition to OSSEC’s default rulesets for user access and integrity checking, we will configure additional rules so that if a file is modified or added to the system, OSSEC will notify you by email.
Here’s an example of the type of alert OSSEC sends:
OSSEC HIDS Notification. 2015 Jan 25 11:42:49 Received From: liniverse->syscheck Rule: 551 fired (level 7) -> "Integrity checksum changed again (2nd time)." Portion of the log(s): Integrity checksum changed for: '/usr/local/etc/ssmtp/ssmtp.conf' Size changed from '1367' to '1384' What changed: 36c36,37 < UseTLS=YES --- #UseTLS=YES UseSTARTTLS=YES Old md5sum was: '39f219a7db9987c3623d5a2f7511dfc1' New md5sum is : '9971ecc1b0c744ee3f744255248e7c11' Old sha1sum was: 'fc945ffc84b243cd36f8dd276f99c57f912f902b' New sha1sum is : '1289fe0008a3d8bf74db8f73c09bf18db09572cc' --END OF NOTIFICATION
Note: OSSEC is currently capable of alerting in realtime only on Linux and Windows. Realtime alerting on FreeBSD is still in progress and because of that, alerting on file deletions does not work on FreeBSD.
OSSEC needs a firewall active on the system for its active response feature. It’s also important that the server keeps accurate time which calls for NTP to be enabled. Finally, the server’s time zone needs to be set – by default it’s UTC.
So, for this tutorial, you will need:
A new server running FreeBSD 10.1.
A firewall enabled, NTP enabled, and the time zone configured. You can do this by following the instructions in Recommended Steps for New FreeBSD 10.1 Servers. Ignore the section setting extra swap space.
Note: UDP firewall permissions are not necessary for OSSEC to function but depending on the services you’re running on your server, you may need to allow UDP traffic for them.
When you’re finished enabling NTP, you can confirm that it’s running by typing:
sudo service ntpd onestatus
The ouput will be similar to what’s below but with a different process ID (pid).
ntpd is running as pid 581.
You can also confirm that the time zone is set correctly by typing
date. The time zone you chose will be in the output.
Neither of these next two changes are required but they’re commonly suggested to make FreeBSD more user friendly for those new to it.
tsch is the default shell in FreeBSD 10.1. If you prefer to use Bash, you can install it by following the instructions under Changing the Default Shell in How To Get Started with FreeBSD 10.1. This will permanently set your default shell to Bash, including all future login sessions.
The default terminal editor in FreeBSD is
Vi and though powerful, it can be unintuitive for new users.
nano is modeless which eliminates some of the complexity for new users compared to
You can use the editor of your choice, but
nano will be used throughout this tutorial. It can be installed by entering into the terminal:
sudo pkg install nano
Log in and apply available security and package updates to the system. If you’ve not logged in already, do so by typing:
Replace the IP address in the above command with your server’s real IP address. FreeBSD’s default user is freebsd and it has
sudo privileges. Once logged in, query for and install available security updates by typing:
sudo freebsd-update fetch install
After that’s completed, install the available package updates.
sudo pkg upgrade
If there were any kernel updates from those commands, reboot the server, then log back in.
On FreeBSD, there are three methods that you can employ to install OSSEC: By downloading the latest binary from the project’s website, from the ports tree, or by installing a pre-made binary from the FreeBSD repository. The last method is by far the simplest and it’s the one we’ll use for this tutorial. It also makes it painless to update OSSEC.
To see which OSSEC binary packages are available in FreeBSD 10.1, type:
sudo pkg search ossec
The output should read something like:
ossec-hids-client-2.8.1_1 ossec-hids-local-2.8.1_1 ossec-hids-server-2.8.1_1
Because the objective is to use OSSEC to monitor just the server it’s being installed on (a local installation), the binary package to install is
ossec-hids-local-2.8.1_1 or whatever the version of the local package is. The client binary will allow you to install an OSSEC agent, which reports to an OSSEC server, if the server binary is installed on a different server.
To install the local binary, type:
sudo pkg install ossec-hids-local-2.8.1_1
Per the installation output, OSSEC will
/usr/local/ossec-hids, so its configuration file and directories will be found under that directory.
Now that you’ve installed OSSEC, it has to be enabled so that it can start on boot. To enable it. open
sudo nano /etc/rc.conf
Append the following lines:
# For OSSEC HIDS ossechids_enable="YES"
Finally, save and close the file.
Since we installed OSSEC from the repository, the email settings in its configuration file are dummy settings. It has to be supplied with real email credentials for you to receive notifications. To rectify that, you need to modify the
ossec.conf file located in
ossec.conf is a very important configuration file for OSSEC so before you start editing it, make a backup copy.
sudo cp /usr/local/ossec-hids/etc/ossec.conf /usr/local/ossec-hids/etc/ossec.conf.00
Now open the original file.
sudo nano /usr/local/ossec-hids/etc/ossec.conf
The first part which needs to be modified is at the very top of the file and shown below. These settings tell OSSEC where to send alerts and what SMTP server it should use.
<global> <email_notification>yes</email_notification> <email_to>firstname.lastname@example.org</email_to> <smtp_server>smtp.xxx.com.</smtp_server> <email_from>email@example.com.</email_from> </global>
FreeBSD 10.1 ships with Sendmail by default and if you wish to use it for OSSEC’s email notifications, then smtp_server should be set to localhost as shown below.
<global> <email_notification>yes</email_notification> <email_to>firstname.lastname@example.org</email_to> <smtp_server>localhost</smtp_server> <email_from>email@example.com</email_from> </global>
Note: Sendmail can handle both inbound and outbound mail. If you don’t need the inbound services of Sendmail, append the lines below to
# For Sendmail sendmail_enable="NO"
###Third-Party SMTP Server
If, however, you wish to specify a third-party SMTP server and not use the local instance of Sendmail, the email notification area of
ossec.conf should look something like this:
<global> <email_notification>yes</email_notification> <email_to>firstname.lastname@example.org</email_to> <smtp_server>mail.example.com.</smtp_server> <email_from>email@example.com</email_from> </global>
When you’ve specified all the necessary email settings, save and close the file. To verify that OSSEC can now send alerts, start it by typing:
sudo /usr/local/ossec-hids/bin/ossec-control start
If all is well, you should receive an email at the configured address of this sort:
OSSEC HIDS Notification. 2015 Jan 23 23:08:32 Received From: liniverse->ossec-monitord Rule: 502 fired (level 3) -> "Ossec server started." Portion of the log(s): ossec: Ossec started. --END OF NOTIFICATION
If you did not receive an email, check your Spam folder.
From here, we will continue working in
ossec.conf. Configuration edits will be presented in the order they appear in the file.
sudo nano /usr/local/ossec-hids/etc/ossec.conf
syscheck is OSSEC’s integrity checking process and we can tell syscheck how often to scan and checksum the filesystem for evidence of unauthorized changes.
Scroll down to the syscheck section. The first two lines should read:
<syscheck> <!-- Frequency that syscheck is executed -- default every 20 hours --> <frequency>17200</frequency>
That setting tells OSSEC performs system checks once every 17200 seconds. That’s a good frequency interval for a production system. However, because realtime notification is not supported in a binary installation of OSSEC on FreeBSD, it is recommended that you reduce that value to something like 900 seconds. Then you can receive notifications within a shorter time frame as you test OSSEC. After testing, you may change it back to the default.
A default installation of OSSEC is Linux-leaning, so the default monitored files and directories reflect those typically found on a Linux system. They, therefore, have to be modified to suit a FreeBSD installation. Those directories are listed just below the previous setting that you modified, and the defaults are:
<!-- Directories to check (perform all possible verifications) --> <directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories> <directories check_all="yes">/bin,/sbin</directories>
As stated earlier, those settings are good for a Linux server, but they need modification for a FreeBSD server. Here’s a suggested setting for a FreeBSD 10.1 server.
<!-- Directories to check (perform all possible verifications) --> <directories report_changes="yes" check_all="yes">/etc,/usr/bin,/usr/sbin</directories> <directories report_changes="yes" check_all="yes">/bin,/sbin</directories> <directories report_changes="yes" check_all="yes">/usr/local/etc,/usr/local/bin,/usr/local/sbin</directories> <directories report_changes="yes" check_all="yes">/home/freebsd,/usr/local/www</directories>
The two extra lines in red were added. The first addition is specific to a FreeBSD server and the second informs OSSEC that we want freebsd’s home directory monitored. If you’re operating under a different username, change
/home/freebsd to match that.
/usr/local/www directory is where Web server data are stored in FreeBSD. If you intend to host a website, the website’s data will all be in that directory. That makes it an important directory to keep a watchful eye on.
The next section of
ossec.conf is a list of files that OSSEC should ignore because they tend to change very often and would create too many false positives. The default file list is shown below.
<!-- Files/directories to ignore --> <ignore>/etc/mtab</ignore> <ignore>/etc/hosts.deny</ignore> <ignore>/etc/mail/statistics</ignore> <ignore>/etc/random-seed</ignore> <ignore>/etc/adjtime</ignore> <ignore>/etc/httpd/logs</ignore>
Again the default list is specific to a Linux system. For example, FreeBSD 10.1 does not use an
mtab file or a
hosts.deny file by default.
So which files should you configure OSSEC to ignore on a FreeBSD 10.1 server? For the most part, that’s something you have to figure out as you go because it depends on what you’ve installed on the server.
For example, the
hosts.deny file has been merged with the
hosts.allow file. So it might be something you would like to ignore. However, keeping an eye on the
hosts.allow file can keep you informed as to who’s throwing stones at your server because that’s where all the IP addresses whose connection attempts have been denied are kept.
If you installed Bash, the
.bash_profile is a good candidate to ignore, though alerting on that file gives you an insight into what commands are being executed on your server. If you installed sSMTP, a send-only email server, its
dead.letter file is another that can be ignored. Also, after installing
.lsof_HOSTNAME file can be ignored.
The general point is this: After installing an application, check if it created a hidden directory in your
/home. That hidden file might be a good candidate to ignore. If in doubt, you may leave the Files/directories to ignore section unchanged. Just keep an eye on the alerts that OSSEC sends. Their contents will give you an idea which files you should configure OSSEC to ignore.
To help you further with this section, here’s what it looks like on the test server used for this tutorial with the default user freebsd.
<!-- Files/directories to ignore --> <ignore>/home/freebsd/dead.letter</ignore> <ignore>/home/freebsd/.bash_profile</ignore> <ignore>/home/freebsd/.lsof_liniverse</ignore> <ignore>/etc/dumpdates</ignore> <ignore>/usr/local/ossec-hids/logs</ignore> <ignore>/usr/local/ossec-hids/queue</ignore> <ignore>/usr/local/ossec-hids/var</ignore> <ignore>/usr/local/ossec-hids/tmp</ignore> <ignore>/usr/local/ossec-hids/stats</ignore>
As you can see, that list ignores several directories under the OSSEC install tree. Not ignoring those directories could cause the system to run out of disk space within a very short time.
The next stop in
ossec.conf is the rootcheck section. Rootcheck is a component of OSSEC which scans the system for rootkits. By default, it reads:
<rootcheck> <rootkit_files>/var/ossec/etc/shared/rootkit_files.txt</rootkit_files> <rootkit_trojans>/var/ossec/etc/shared/rootkit_trojans.txt</rootkit_trojans> </rootcheck>
OSSEC on FreeBSD 10.1 is not installed in
/var/ossec, but in
/usr/local/ossec-hids so modify those lines to reflect that. Afterward, that section should read:
<rootcheck> <rootkit_files>/usr/local/ossec-hids/etc/shared/rootkit_files.txt</rootkit_files> <rootkit_trojans>/usr/local/ossec-hids/etc/shared/rootkit_trojans.txt</rootkit_trojans> </rootcheck>
That is all you need to change in
ossec.conf - for now. Save and close it; we’ll come back to it later. To make sure everything was set correctly, try restarting OSSEC.
sudo /usr/local/ossec-hids/bin/ossec-control restart
The restart should be successful. If it returns a configuration error, double check your entries for Steps 4 and 5.
A default installation of OSSEC is configured to monitor log files whose locations are specific to a Linux system. On FreeBSD 10.1, some of those files have a slightly different name though they are still located in the same
If you look in OSSEC’s log file (
/var/log/ossec-hids/logs/ossec.log), you’ll see entries like these:
ossec-logcollector(1950): INFO: Analyzing file: '/var/log/messages' ossec-logcollector(1103): ERROR: Unable to open file '/var/log/authlog' ossec-logcollector(1103): ERROR: Unable to open file '/var/log/secure' ossec-logcollector(1950): INFO: Analyzing file: '/var/log/xferlog'
An entry that contains ERROR: Unable to open file indicates a file that OSSEC could not find because it does not exist, or possibly the permissions are wrong. Verify which is the case on your system before drawing a conclusion.
Here is how can you determine the location of the log files OSSEC should monitor on FreeBSD 10.1. We’ll use
lsof to list open files which the system is using during runtime.
lsof is not installed by default, so first install it:
sudo pkg install lsof
Then to run the log file check, use the following command:
lsof | grep log | grep -v ".so" | egrep -v "ossec|proc|dev|run"
All that command is doing is fishing for all open files, keeping log files that are of interest to us and jettisoning the rest. We definitely don’t want to monitor files in OSSEC’s installation directory, or in
/var/run. You should get an output that contains a listing of log files. The following code block shows part of the output on the test system used for this tutorial:
syslogd ... root ... /var/log/messages syslogd ... root ... /var/log/security syslogd ... root ... /var/log/auth.log syslogd ... root ... /var/log/maillog syslogd ... root ... /var/log/lpd-errs
If you compare the names in that output with those in the output of OSSEC’s log file, it’s easy to see that
/var/log/auth.log is the same as
/var/log/security is FreeBSD’s equivalent of
ossec.conf again and modify the names of the log files to match the names used in FreeBSD 10.1.
sudo nano /usr/local/ossec-hids/etc/ossec.conf
The code block below shows an example of what the modified lines should be. You will want to add log locations for the specific services you’ve installed and are running on the server; services like Nginx, Apache, etc.
<!-- Files to monitor (localfiles) --> <localfile> <log_format>syslog</log_format> <location>/var/log/auth.log</location> </localfile> <localfile> <log_format>syslog</log_format> <location>/var/log/security</location> </localfile>
If long after you’ve installed OSSEC you have a log file in a custom directory that you wish to monitor, you can use OSSEC’s
util.sh command to add it or open
ossec.conf with nano and add it manually.
For example, if you installed Nginx and its access and error log files are in the
/var/log/nginx directory, you may add them to
ossec.conf by using
util.sh like so:
/usr/local/ossec-hids/bin/util.sh addfile /var/log/nginx/access.log /usr/local/ossec-hids/bin/util.sh addfile /var/log/nginx/error.log
Note: If you run those two commands as they’re presented and you don’t have Nginx installed, you’ll get an error saying the log files don’t exist.
At this point, we have one last change to make in
ossec.conf, so leave the file open as you move on the next step.
By default, OSSEC does not alert when new files are created in the system so we will change that behavior. There are two components to this change.
Scroll back up to the
syscheck area os of
ossec.conf and add an alert_new_files line just under the frequency check interval.
The result should read:
<syscheck> <!-- Frequency that syscheck is executed -- default every 20 hours --> <frequency>17200</frequency> <alert_new_files>yes</alert_new_files>
Now you can save and close
ossec.conf. We’re finished with it.
Although we’ve told
syscheck to watch for newly created files, OSSEC won’t actually notify us about them yet. For that we need to modify a default OSSEC rule.
sudo nano /usr/local/ossec-hids/rules/ossec_rules.xml
The rule that fires when a file is added to a monitored directory is rule 554. Here’s what it looks like:
<rule id="554" level="0"> <category>ossec</category> <decoded_as>syscheck_new_entry</decoded_as> <description>File added to the system.</description> <group>syscheck,</group> </rule>
OSSEC does not send an alert if a rule has a level set to 0, so you have to copy that rule to
local_rules.xml and modify it so that it will trigger an alert. You can use a mouse or touchpad to highlight the rule in
nano, copy and temporarily paste it into a text editor on your host machine.
local_rules.xml This is where all user-modified OSSEC rules should go; you should not make changes to
sudo nano /usr/local/ossec-hids/rules/local_rules.xml
CONTROL+SHIFT+V to paste the rule from your host machine’s text editor into
nano. Make sure you paste it within the group tags. We’ll change the notification level to
7 and tell OSSEC that this rule overwrites rule 554 from
When done, the end of your
local_rules.xml file should look like below. The first line is all that was changed from the original rule.
<rule id="554" level="7" overwrite="yes"> <category>ossec</category> <decoded_as>syscheck_new_entry</decoded_as> <description>File added to the system.</description> <group>syscheck,</group> </rule> </group> <!-- SYSLOG,LOCAL --> <!-- EOF -->
When all is done, save and close the file, then restart OSSEC by typing:
sudo /usr/local/ossec-hids/bin/ossec-control restart
Shortly after restarting OSSEC, you should receive an alert indicating that OSSEC has started, just like you did in Step 3 when configuring the SMTP server. It would be a good idea to become familiar with the different rule levels and the severity they imply. You can read about them in the OSSEC documentation.
And after OSSEC performs the next system check, you should also receive standard alerts you could expect from a new system. Here are some notifications you’ll likely see (or see variations of) shortly after you’ve configured on your server.
First time the user freebsd has run a sudo command.
OSSEC HIDS Notification. 2015 Jan 24 07:10:56 Received From: liniverse->/var/log/auth.log Rule: 5403 fired (level 4) -> "First time user executed sudo." Portion of the log(s): Jan 24 02:10:56 liniverse sudo: freebsd : TTY=pts/1 ; PWD=/usr/home/freebsd ; USER=root ; COMMAND=/usr/sbin/pkg install namp --END OF NOTIFICATION
OSSEC has blocked the IP address 18.104.22.168 in hosts.allow.
OSSEC HIDS Notification. 2015 Jan 25 02:06:47 Received From: Freebsd->syscheck Rule: 552 fired (level 7) -> "Integrity checksum changed again (3rd time)." Portion of the log(s): Integrity checksum changed for: '/etc/hosts.allow' Size changed from '3408' to '3434' What changed: 93a94 ALL : 22.214.171.124 : deny Old md5sum was: 'f8ba903734ee1bd6afae641974a51522' New md5sum is : '56dfbd3922cf7586b81b6575f6564196' Old sha1sum was: 'a7a9886aa90f2f6aaa7660490809d6a0717b8d76' New sha1sum is : '6a0bf14c4614976d2c2e1157f157ae513f3f9cfc' --END OF NOTIFICATION
ngx.txt was created in
OSSEC HIDS Notification. 2015 Jan 24 20:08:38 Received From: liniverse->syscheck Rule: 554 fired (level 7) -> "File added to the system." Portion of the log(s): New file '/home/freebsd/ngx.txt' added to the file system. --END OF NOTIFICATION
Hopefully this has given you a taste of what OSSEC has to offer. As stated earlier, realtime alerts and alerts on file deletions are not yet supported on FreeBSD. However, a feature request pertaining to those has been made on the project’s GitHub page. For more information on OSSEC, visit the project’s website at http://www.ossec.net/.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.