Tutorial

How To Install and Configure OSSEC on FreeBSD 10.1

Published on February 6, 2015
How To Install and Configure OSSEC on FreeBSD 10.1

Introduction

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.

Prerequisites

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.

Optional

Neither of these next two changes are required but they’re commonly suggested to make FreeBSD more user friendly for those new to it.

  • Install and enable Bash.

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.

  • Install nano.

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 Vi.

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

Step 1 - Update the System

Log in and apply available security and package updates to the system. If you’ve not logged in already, do so by typing:

ssh freebsd@111.111.111.111

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.

Step 2 - Install and Enable OSSEC

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 chroot into /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 /etc/rc.conf again.

sudo nano /etc/rc.conf

Append the following lines:

# For OSSEC HIDS

ossechids_enable="YES"

Finally, save and close the file.

Step 3 - Set Email Credentials for OSSEC Notifications

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 /usr/local/ossec-hids/etc.

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>daniel.cid@xxx.com</email_to>
    <smtp_server>smtp.xxx.com.</smtp_server>
    <email_from>ossecm@ossec.xxx.com.</email_from>
</global>

###Sendmail

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>sammy@example.com</email_to>
    <smtp_server>localhost</smtp_server>
    <email_from>sammy@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 /etc/rc.conf.

# 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>sammy@example.com</email_to>
    <smtp_server>mail.example.com.</smtp_server>
    <email_from>sammy@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.

Step 4 - Configure syscheck

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

Adjust the syscheck Interval

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.

Specify Directories to Monitor

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.

Note: The /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.

Specify Files or Directories to be Ignored

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, its .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.

Step 5 - Configure Rootcheck

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.

Step 6 - Specify Log Files to be Monitored

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 /var/log directory.

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 /proc, /dev or /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/authlog and /var/log/security is FreeBSD’s equivalent of /var/log/secure.

Now open 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>

Adding Log File Entries with util.sh

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.

Step 7 - Alert on New Files

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.

Set syscheck

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.

Modify the Rule’s Classification Level

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.

Open ossec_rules.xml in nano.

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.

Now open local_rules.xml This is where all user-modified OSSEC rules should go; you should not make changes to ossec_rules.xml.

sudo nano /usr/local/ossec-hids/rules/local_rules.xml

Use 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 ossec_rules.xml.

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

Conclusion

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 93.50.186.75 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 : 93.50.186.75 : deny

Old md5sum was: 'f8ba903734ee1bd6afae641974a51522'
New md5sum is : '56dfbd3922cf7586b81b6575f6564196'
Old sha1sum was: 'a7a9886aa90f2f6aaa7660490809d6a0717b8d76'
New sha1sum is : '6a0bf14c4614976d2c2e1157f157ae513f3f9cfc'

 --END OF NOTIFICATION

The file ngx.txt was created in /home/freebsd.

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.

Learn more about our products

About the authors
Default avatar
finid

author



Still looking for an answer?

Ask a questionSearch for more help

Was this helpful?
 
2 Comments


This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

I don’t know if it the package for FreeBSD or OSSec in general, however for it to work properly on a standard installation (I made the installation recently on a new droplet) you need to make several changes for it to actually work if you want it to deny ip addresses. It does not tell you that it is not working, it seem to be however the tables are not updated unless you do the following.

You will have two options, however the easiest is to use the /etc/hosts.allow file, but you need to change it, because as it is it will not work. Easiest is to just remove everything that is inside the file (rename the current file, and create a new blank one). You may need to edit the host-deny.sh file as well because there are some spaces (some shells are not forgiving in syntax, and the lines which starts with TMP_FILE = … have to be changed to TMP_FILE=…

The OSSEC also supports IPFW and IPF, and you must choose whichever suits you the most. As the linked tutorial install IPFW, you will need to either copy ipfw.sh to the firewall-drop.sh (In /usr/local/ossec-hids/active-response/bin/ ) or change the command section in the ossec.conf to point to ipfw.sh instead of firewall-drop.sh. By default it seem to have support for IPF, maybe if you install IPFW before OSSEC it will detect correct shell script.

Awesome how-to article!!! Easy to read,understand and follow. I wish more tutorials were written this way,

Just one suggestion; in the util.sh file, the path to the ossec.conf file needs to be changed before you can actually use the ‘addfile’ command. For example.

sudo /usr/local/ossec-hids/bin/util.sh addfile /var/log/httpd-access.log

/usr/local/ossec-hids/bin/util.sh: cannot create /var/ossec/etc/ossec.conf: No such file or directory /usr/local/ossec-hids/bin/util.sh: File /var/log/httpd-access.log added.

There are actually several places that path needs to be changed in the util.sh file.

Try DigitalOcean for free

Click below to sign up and get $200 of credit to try our products over 60 days!

Sign up

Join the Tech Talk
Success! Thank you! Please check your email for further details.

Please complete your information!

Become a contributor for community

Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.

DigitalOcean Documentation

Full documentation for every DigitalOcean product.

Resources for startups and SMBs

The Wave has everything you need to know about building a business, from raising funding to marketing your product.

Get our newsletter

Stay up to date by signing up for DigitalOcean’s Infrastructure as a Newsletter.

New accounts only. By submitting your email you agree to our Privacy Policy

The developer cloud

Scale up as you grow — whether you're running one virtual machine or ten thousand.

Get started for free

Sign up and get $200 in credit for your first 60 days with DigitalOcean.*

*This promotional offer applies to new accounts only.