Monitor file and directory activity with incron
Automatic Apache
A more serious use for incron would be to monitor a server's configuration files and order a reboot if anything changes, such as a modified Apache web server httpd.conf
or apache2.con
file. Begin by finding out which user has privileges to stop and restart Apache on your system and edit their incrontab.
For this exercise, assume that user is root, become superuser, and open root's incrontab for editing:
$ su # incrontab -e
If you get an error that reads user 'root' is not allowed to use incron, edit /etc/incron.allow
and add root
to the list of allowed users. Then, insert the following line into root's incrontab file:
/etc/apache2/apache2.conf IN_MODIFY /etc/init.d/apache2 restart
After modifying httpd.conf
, or apache2.conf
(e.g., by changing the Timeout
value), and saving the file, look at /var/log/apache2/error.log
(Figure 1). You'll see that Apache was restarted automatically when you hit the Save button (or typed :wq
).
However, you probably know that it's been a long time since Apache has had only one configuration file. Apache's configuration has been modularized and sometimes approaches tens of files spread out over several nested directories. To monitor the whole lot, you can add the following to your root's incrontab:
/etc/apache2/conf.d/ IN_CREATE /etc/init.d/apache2 restart
This method is not very subtle, but, again, it'll work. You've probably figured out that this code restarts the web server every time a new file is added to the /etc/apache2/conf.d/
directory. It doesn't check whether it is a *.conf
file or not, but because Apache's conf.d
directory was created for those kinds of files, it doesn't really matter.
Furthermore, you're going to want to monitor the files within the conf.d
directory to see whether any of the files change. To do that, you can modify the incrontab to:
/etc/apache2/conf.d/ IN_CREATE,IN_CLOSE_WRITE /etc/init.d/apache2 restart
As you can see, if you want to monitor more than one event, you have to separate the triggers with commas. In this case, you are monitoring for both the IN_CREATE
and IN_CLOSE_WRITE
events, because you also want to restart Apache when a configuration file closes after it has been modified.
Note that your root's incrontab file is now two lines long, one for each directory. You're probably thinking that using two lines for a directory and one of its subdirectories is inefficient, and that it would be more elegant if you had a way to monitor the upper directory and then drill down.
You'd be wrong.
Incron does not support recursive directory monitoring, nor are there any plans for it to do so, and there's a good reason for this decision: infinite recursive loops.
To Infinity and Beyond
Imagine that you want to monitor the files in a directory and write an entry in a log each time a file is modified. You save the log for convenience in the same directory you're monitoring.
The incrontab could look like this:
</path/to/directory/> IN_CLOSE_WRITE log_changes $#
where log_changes
is the following Bash script:
#!/bin/bash echo "`date` File $1 modified" >> </path/to/directory/>my.log
Do you start to see the problem? You've created an infinite loop.
When you finish writing the entry in my_log
, the IN_CLOSE_WRITE
event fires because, you know, my_log
is a file in the monitored directory, which was closed after being written to. A new entry is written in my_log
, and the IN_CLOSE_WRITE
event fires again, because my_log
is a file in the monitored directory, which was closed after being written to. IN_CLOSE_WRITE
fires again and … . You get the picture. Bad things would happen if you let something like that run unchecked.
To avoid this kind of situation, every sys admin worth his salt has two tools available: (1) common sense and (2) the IN_NO_LOOP
wildcard event. This element blocks the incrontab instruction until it's completely finished, avoiding the other event from firing in the same iteration, and thus avoiding loops.
Although the following is a lousy, lazy, shoddy solution (the best move would be to store your logfile elsewhere), you can solve the problem described above with the following incrontab line:
</path/to/directory/> IN_CLOSE_WRITE, IN_NO_LOOP log_changes $#
So, you can see that drilling down into subdirectories of subdirectories of subdirectories (including soft-linked directories), if it were implemented in incron, would increase significantly the chances of infinite loops, so no recursive monitoring is allowed in incron.
Silent Alarm
In the next example, I'm going to implement a security system against intruders who try to access the system and directories containing sensitive documents. I'm not talking about that folder called secret_CIA_documents
that everybody has in their home directory.
If you have learned anything from the likes of the NSA, LulzSec, and Anonymous, it is that the files most coveted by attackers are email messages. Email contains usernames, passwords, bank accounts, credit card numbers, personal images, business contracts, and on and on. A frequently used email folder is a true treasure trove for your friendly neighborhood snooper.
However, monitoring a real email folder would be a nightmare, with so many writes, rewrites, deletions, and changes making it impossible to filter out false positives. Also, are you sure you want an attacker to get as far as being able to read your messages? No, you don't. What you'll do instead is construct a honeypot by creating a .Mail
directory hanging off your home directory and filling it with messages culled from, say, your spam folder. That should make for fun reading. If your email client already points to that folder to store messages, CHANGE IT! It's way too exposed.
Incron will monitor your honeypot directory as before, but with a twist: Your action will depend on what the intruder does. If the intruder opens a file for reading, you'll activate the silent alarm and warn the system administrator. However, if the intruder starts writing in files, you'll disconnect the machine from the network with, for example
ifconfig eth0 down
The problem with this solution is that, apparently, you need two lines to call two different scripts, depending on the triggered event. Something like:
/home/<user>/.Mail IN_ACCESS warn_admin.sh /home/<user>/.Mail IN_CLOSE_WRITE close_connection.sh
But that won't work because incron doesn't allow you to monitor the same thing twice. If you try to run these lines to trigger one of the events, you will get an error in /var/log/cron
that says:
Jul 24 21:17:54 host incrond[9454]: cannot create watch for user root: (16) Device or resource busy
To solve this problem, you can combine both events onto one line and use the predefined incron variable $%
:
/home/paul/.Mail IN_ACCESS, IN_CLOSE_WRITE access_control.sh $%
The $%
wildcard is passed to your script as an argument, telling it which event was triggered, so you can then deal with it as shown in Listing 1.
Listing 1
Incron Event Decisions
« Previous 1 2 3 Next »
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
Canonical Releases Ubuntu 24.04
After a brief pause because of the XZ vulnerability, Ubuntu 24.04 is now available for install.
-
Linux Servers Targeted by Akira Ransomware
A group of bad actors who have already extorted $42 million have their sights set on the Linux platform.
-
TUXEDO Computers Unveils Linux Laptop Featuring AMD Ryzen CPU
This latest release is the first laptop to include the new CPU from Ryzen and Linux preinstalled.
-
XZ Gets the All-Clear
The back door xz vulnerability has been officially reverted for Fedora 40 and versions 38 and 39 were never affected.
-
Canonical Collaborates with Qualcomm on New Venture
This new joint effort is geared toward bringing Ubuntu and Ubuntu Core to Qualcomm-powered devices.
-
Kodi 21.0 Open-Source Entertainment Hub Released
After a year of development, the award-winning Kodi cross-platform, media center software is now available with many new additions and improvements.
-
Linux Usage Increases in Two Key Areas
If market share is your thing, you'll be happy to know that Linux is on the rise in two areas that, if they keep climbing, could have serious meaning for Linux's future.
-
Vulnerability Discovered in xz Libraries
An urgent alert for Fedora 40 has been posted and users should pay attention.
-
Canonical Bumps LTS Support to 12 years
If you're worried that your Ubuntu LTS release won't be supported long enough to last, Canonical has a surprise for you in the form of 12 years of security coverage.
-
Fedora 40 Beta Released Soon
With the official release of Fedora 40 coming in April, it's almost time to download the beta and see what's new.