There is no point of not using the hosts.deny and hosts.allow files for blacklisting some people, and giving others the right to connect to the system. The hosts.allow file (located at /etc/hosts.allow) describes the names of the hosts which are allowed to use the local INET services, as decided by the '/usr/sbin/tcpd' server (for instajnce telnet, finger, ftp, exec, rsh, ssh, tftp, talk...). The hosts.deny file is doing just the opposite thing and is self explanatory. In most of the books I read about security on Linux systems, authors have this proposition regarding usage of mentioned hosts.* files.

First add all:all into your host.deny list, which doesn't allow anyone to connect to your INET services, and then edit hosts.allow with all the hostnames which should be able to connect. This is the bottom line what should be done on the Linux system that is connected to the Internet, but let's say Murphy's Law strikes - When you add all:all to host.deny list and save the configuration, your Internet connection just crashes and you are not able to connect to the system which is physically thousands of miles from your home. Because of this I prefer first editing hosts.allow and then the hosts.deny list.

Checking the integrity

While you can use Tripwire or any other similiar solution for checking the integrity of files that reside on your system, there is another way of doing this. To tell you the truth, it is not as powerful, but it is usable. Let's consider this seven liner:

----------------cut-here-------------------
#!/bin/bash
for rpmlist in `rpm -qa | sort`
do
echo " __ $rpmlist __"
rpm -V $rpmlist
done > /tmp/123.out
cat /tmp/123.out | mail -s "RPM Check `date +%T %A %d.%m.%Y`" admin@yoursystem.net
----------------cut-here-------------------

This shell script basically makes a list of RPM files on your system, sorts them in an easily viewable format and verifies them to see what has changed. After that it mails the whole list to the administrative mailbox. Everything can of course be re-configured to suite your needs the best.


This is the snapshop of one of the e-mails sent as the result of this shell script:



Also it would be suitable to add this script in CRON, so you can receive a daily snapshot of the RPM's on your system. In this exaple is starts every day at 10 am.

[admin@pilatus]# crontab -l
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/crontab.1759 installed on Tue Apr 16 16:06:48 2002)
00 10 * * * /usr/local/etc/rpmcheck.sh

Checking the logs

Usually you should periodically check the logs on your system. All the vital things about the current status of your system can be seen from the logs. While manually checking all the files takes some time, and time is precious, there are a few tools that help you automate the process of checking your system logs.

I like to use LogSentry, a freeware product by Psionic Technologies.

As can be seen from the product description: "LogSentry automatically monitors your system logs and mails security violations to you on a periodic basis. It is based on a program that ships with the TIS Gauntlet firewall but has been improved upon in many ways to make it work nicely for normal system auditing."