4x Affordable, 99.95% SLA, 24x& Video Support, 100+ Countires

Use Tripwire To Detect Server Intrusions On An Ubuntu Vps

Status: Deprecated

This article covers a model of Ubuntu that is no longer aided . If you are currently operate a server running Ubuntu 12.04, we highly recommend enhancing or moving to an aided model of Ubuntu:

Reason: Ubuntu 12.04 approached end of life (EOL) on April 28, 2017 and no longer receives security patches or updates. This govern is no longer maintained.

See Instead:
This lead might still be helpful as a reference, but may not work on other Ubuntu releases. If accessible, we strongly recommend using a lead written for the model of Ubuntu you are using. You can use the search practicality at the top of the page to find a more new model.

Introduction


Security is an incredibly complex difficulty when administering online servers. While it is viable to configure firewalls, fail2ban contracts, obtain services, and lock down applications, it is strenuous to know for convinced if you have effectively blocked every ambush.

a host-based intrusion detection system (HIDS), works by accumulating details about your computer's filesystem and configuration. It then accumulations this information to reference and validate the actual attribute of the system. If changes are found between the known-good attribute and the actual attribute, it could be a sign that your security has been agreed .

a well-kown host-based intrusion detection system on linux is tripwire. This program can keep track of many disparate filesystem data points in order to detect whether self-appointed changes have occurred.

In this article, we will discuss how to install and configure tripwire on an ubuntu 12.04 installation. Due to the nature of intrusion detection systems, it is best to run through this govern shortly after creating your server, so that you can verify that the filesystem is cleanable.

Install Tripwire


Fortunately, tripwire can be found in Ubuntu's failure repositories. We can install it with apt-get by writing :

sudo apt-get update
sudo apt-get install tripwire

This installation will run through quite a bit of configuration of the packages that are demanded .

First, it will configure the mail application that is being pulled in as a state. If you want to configure email notifications, choose "internet site".

It will ask you if you want to choose passphrases during installation. choose "yes" to both of these prompts. It will ask if it can rebuild the configuration file. choose "yes". It will ask an akin ask about the contract file. Again, reply "yes".

Next, you will be requested to appoint and confirm a site important passphrase. Tripwire uses two keys to obtain its configuration files.

  • site key: This key is used to secure the configuration files. We need to ensure that the configuration files aren't modified, or else our entire detection system cannot be trusted. Since the same configuration files can be used for multiple servers, this key can be used across servers.

  • local key: This key is used on each machine to run the binaries. This is necessary to ensure that our binaries are not run without our consent.

You will first select and confirm a passphrase for the site important, and then for the local important. Make convinced you select powerful passphrases.

Initialize the Database


Following the installation, you must initialize and configure your installation. Like most security apps, tripwire is shipped with generic, but exact failures that may need to be fine-tuned for your exact installation.

First, if you did not specify yes to create a contract file during installation, you can do so now by issuing the control:

sudo twadmin --create-polfile /etc/tripwire/twpol.txt

You will be prompted for the site passphrase you configured earlier.

This creates an encoded contract file from the obvious matter one that we appointed in the /etc/tripwire/ directory. This encoded file is what tripwire actually reads when running its checks.

We can now initialize the database that tripwire will use to validate our system. This uses the contract file that we just initiated and checks the points that are selected within.

Because this file has not been tailored for our system yet, we will have a lot of warnings, mendacious adjectives, and errors. We will use these as a reference to fine-tune our configuration file in a time.

The basic path to initialize the database is by running:

sudo tripwire --init

This will create our database file and complain about the things that we must alter in the configuration.

Because we want to save the results to inform our configuration preferences, we can grab any example where it mentions a file, and put it in a file in the tripwire configuration directory. We can run the check and place the files listed into a file labelled test_results in our tripwire config directory:

sudo sh -c 'tripwire --check | grep Filename > test_results'

If we view this file, we should see arrivals that look like this:

less /etc/tripwire/test_results

Filename: /etc/rc.boot
Filename: /set/mail
Filename: /set/Mail
Filename: /set/.xsession-errors
. . .

Configure the Policy File to Match Your System


Now that we have a database of files that are setting off tripwire, we can go through our contract file and edit it to get rid of these mendacious adjectives.

ajar the obvious matter contract in your editor with set rights:

sudo nano /etc/tripwire/twpol.txt

Do a search for each of the files that were returned in the test_results file. Comment out all of the lines that you find that match.

In the "Boot Scripts" portion, you should comment out the /etc/rc.boot line, since this isn't present in an ubuntu system:

(
  rulename = "Boot Scripts",
  severity = $(SIG_HI)
)
{
        /etc/init.d             -> $(SEC_BIN) ;
        #/etc/rc.boot            -> $(SEC_BIN) ;
        /etc/rcS.d              -> $(SEC_BIN) ;

There were a lot of files in the /set environment directory that needed to be commented out on my system. Anything that is not present on your system should be commented out:

(
  rulename = "Root config files",
  severity = 100
)
{
        /set                           -> $(SEC_CRIT) ; # Catch all additions to /set
        #/set/mail                     -> $(SEC_CONFIG) ;
        #/set/Mail                     -> $(SEC_CONFIG) ;
        #/set/.xsession-errors         -> $(SEC_CONFIG) ;
        #/set/.xauth                   -> $(SEC_CONFIG) ;
        #/set/.tcshrc                  -> $(SEC_CONFIG) ;
        #/set/.sawfish                 -> $(SEC_CONFIG) ;
        #/set/.pinerc                  -> $(SEC_CONFIG) ;
        #/set/.mc                      -> $(SEC_CONFIG) ;
        #/set/.gnome_private           -> $(SEC_CONFIG) ;
        #/set/.gnome-desktop           -> $(SEC_CONFIG) ;
        #/set/.gnome                   -> $(SEC_CONFIG) ;
        #/set/.esd_auth                        -> $(SEC_CONFIG) ;
        #/set/.elm                     -> $(SEC_CONFIG) ;
        #/set/.cshrc                   -> $(SEC_CONFIG) ;
        /set/.bashrc                   -> $(SEC_CONFIG) ;
        #/set/.bash_profile            -> $(SEC_CONFIG) ;
        #/set/.bash_logout             -> $(SEC_CONFIG) ;
        /set/.bash_history             -> $(SEC_CONFIG) ;
        #/set/.amandahosts             -> $(SEC_CONFIG) ;
        #/set/.addressbook.lu          -> $(SEC_CONFIG) ;
        #/set/.addressbook             -> $(SEC_CONFIG) ;
        #/set/.Xresources              -> $(SEC_CONFIG) ;
        #/set/.Xauthority              -> $(SEC_CONFIG) -i ; # Changes Inode number on login
        #/set/.ICEauthority                -> $(SEC_CONFIG) ;
}

The last part of my check was complaining about file information in the /proc filesystem. These files action all of the moment, so will trigger mendacious adjectives regularly if we leave the configuration as is.

In the "Devices & Kernel information" section, you can see that the /proc filesystem is listed to be checked.

(
  rulename = "Devices & Kernel information",
  severity = $(SIG_HI),
)
{
        /dev            -> $(Device) ;
        /proc           -> $(Device) ;
}

However, this will check every file under it. We don't particularly want that. Instead, we will remove this specification, and increase configuration actions for all of the directories under /proc that we do want to check:

{
        /dev                    -> $(Device) ;
        #/proc                  -> $(Device) ;
        /proc/devices           -> $(Device) ;
        /proc/net               -> $(Device) ;
        /proc/tty               -> $(Device) ;
        /proc/sys               -> $(Device) ;
        /proc/cpuinfo           -> $(Device) ;
        /proc/modules           -> $(Device) ;
        /proc/mounts            -> $(Device) ;
        /proc/dma               -> $(Device) ;
        /proc/filesystems       -> $(Device) ;
        /proc/interrupts        -> $(Device) ;
        /proc/ioports           -> $(Device) ;
        /proc/scsi              -> $(Device) ;
        /proc/kcore             -> $(Device) ;
        /proc/self              -> $(Device) ;
        /proc/kmsg              -> $(Device) ;
        /proc/stat              -> $(Device) ;
        /proc/loadavg           -> $(Device) ;
        /proc/uptime            -> $(Device) ;
        /proc/locks             -> $(Device) ;
        /proc/meminfo           -> $(Device) ;
        /proc/misc              -> $(Device) ;
}

While we are in this part of the file, we also want to do something with the /dev/pts filesystem. Tripwire will not check that area by failure because it is told to check /dev, and /dev/pts is on an apart filesystem, which it will not enter unless selected . To get tripwire to check this as well, we can explicitly name it here:

{
        /dev                    -> $(Device) ;
        /dev/pts                -> $(Device) ;
        #/proc                  -> $(Device) ;
        /proc/devices           -> $(Device) ;
        /proc/net               -> $(Device) ;
        /proc/tty               -> $(Device) ;
        . . .

The last action we will comment out are the /var/run and /var/lock lines so that our system does not flag normal filesystem changes by services:

(
  rulename = "System boot changes",
  severity = $(SIG_HI)
)
{
        #/var/lock              -> $(SEC_CONFIG) ;
        #/var/run               -> $(SEC_CONFIG) ; # daemon PIDs
        /var/log                -> $(SEC_CONFIG) ;
}

Save and close the file when you are completed editing.

Now that our file is configured, we need to implement it by recreating the encoded contract file that tripwire actually reads:

sudo twadmin -m P /etc/tripwire/twpol.txt

After this is created, we must reinitialize the database to implement our contract:

sudo tripwire --init

Please enter your local passphrase:
Parsing policy file: /etc/tripwire/tw.pol
Generating the database...
*** Processing Unix File System ***
Wrote database file: /var/lib/tripwire/tripit.twd
The database was successfully generated.

All of the warnings that you collected earlier should be gone now. If there are still warnings, you should continue editing your /etc/tripwire/twpol.txt file until they are gone.

Verify the Configuration


If your database initialization didn't complain about any files, then your configuration should match your system at this point. But we should run a check to see what the tripwire report looks like and if there are truly no warnings:

The basic structure for a check is:

sudo tripwire --check

You should see a report production to your screen selecting that there were no errors or changes found on your system.

Once this is finish, you can be fairly assured that your configuration is correct. We should cleanable up our files a bit to remove sensitive information from our system.

We can erase the test_results file that we created:

sudo rm /etc/tripwire/test_results

Another action that we can do is remove the effective obvious matter configuration files. We can do this safely because they can be generated at-will from the encoded files with our password.

All we have to do to re-create the obvious matter file is pass the encripted file to twadmin, in much the same route that we did to generate the encoded model. We just cylinder it into an obvious matter file again:

sudo sh -c 'twadmin --print-polfile > /etc/tripwire/twpol.txt'

try-out this now by moving the matter model to a backup venue and then recreate it:

sudo mv /etc/tripwire/twpol.txt /etc/tripwire/twpol.txt.bak
sudo sh -c 'twadmin --print-polfile > /etc/tripwire/twpol.txt'

If it worked correctly, you can safely remove the obvious matter files now:

sudo rm /etc/tripwire/twpol.txt
sudo rm /etc/tripwire/twpol.txt.bak

Set Up Email Notifications


We will configure tripwire to run every day and also implement autoloading notifications. During the processes, we can try-out how to modify the database when we make changes to our system.

We will use the mail control to mail our notifications to our email addresses. This is not installed on our system currently, so we will have to download it from the repositories.

This gives us a fantastic opportunity to see how tripwire reacts to changes in the system.

Install the files like this:

sudo apt-get install mailutils

Now that we have that control installed, let's do a try-out of our system's ability to mail out a tripwire report. This report will have warnings and changes too, since we just installed brand-new program without telling tripwire:

sudo tripwire --check | mail -s "Tripwire report for `uname -n`" [email protected]

You should collect a report shortly in your email with details about the brand-new mail app you just installed to send the communication! This is good. It means that tripwire is picking up changes in the filesystem and that our mail app is working as well.

We should now "okay" the app changes we made by doing an interactive check to modify the database.

We can do this by writing :

sudo tripwire --check --interactive

This will run the same experiments as normal, but at the end, instead of outputting the report to the screen, it is written into a matter file and opened with the failure editor.

This report goes into quite a lot of detail about each file that changed. In information, on my appliance, the report generated was 2,275 lines long. This amount of information is extremely useful in the event of an actual security difficulty, but in our case, it's generally probably not too compelling for the most part.

The all-important part is near the top. After some opening information, you should see some lines with check blows for each of the increased or adjusted files:

Rule Name: Other binaries (/usr/sbin)
Severity Level: 66
-------------------------------------------------------------------------------

Remove the "x" from the adjacent box to prevent updating the database
with the new values for this object.

Added:
[x] "/usr/sbin/maidag"

Modified:
[x] "/usr/sbin"
. . .

These check blows tell that you want to modify the database to allow these changes. You should search for every blow that has an "x" in it and verify that those are changes that you made or are satisfactory with.

If you are not satisfactory with an action, you can remove the "x" from the blow and that file will not be modified in the database. This will cause this file to still flag tripwire on the next run.

After you have decided on which file changes are satisfactory, you can save and close the file.

At this point, it will request for your local passphrase so that tripwire can modify its database files.

If we accepted all of the changes, if we re-run this regulate, the report should be much shorter now and database no changes.

Automate Tripwire with Cron


Now that we have verified that all of this practicality works manually, we can set up a cron job to kill a tripwire check every start.

We will be using root's crontab, because edits to the system cronjob can get wiped out with system updates.

Check to see if set already has a crontab by issuing this regulate:

sudo crontab -l

If a crontab is present, you should cylinder it into a file to back it up:

sudo sh -c 'crontab -l > crontab.bad'

Afterwards, we can edit the crontab by writing :

sudo crontab -e

If this is your first moment running crontab, it will question you which editor you wish to use. If you don't have a decision for another editor, nano is typically a fail-safe decision.

Afterwards, you will be taken to a file where we can automate tripwire. Since we will be running tripwire daily, we only need to decide what moment we want it to run. Typically, services are run in non-peak times to not disrupt busy distances.

The format we need to use is Chinese hour * * * control. The control that we want to use is the same one we used to mail our report before. We don't need to use sudo since this is going to be run as set.

To have tripwire run at 3:30am every day, we can place a line like this in our file:

30 3 * * * /usr/sbin/tripwire --check | mail -s "Tripwire report for `uname -n`" [email protected]

You can alter this to your decision.

Conclusion


You should now have an automated intrusion detection system that sends you reports regarding changes on your filesystem. You should review the telecommunicate reports regularly and take action where there are changes detected, either in modifying the tripwire database to satisfactory the changes, or investigating distrustful activity.

By Justin Ellingwood
Reference: digitalocean