manual.html

This piece of software was written as a replacement and extension for Tripwire. Tripwire is an exce

files.  It will also be a good idea to include directories you don't
often look in like /dev /usr/man/.*usr/.  Of course you'll want to
include as many files as practical, but think about what you include.        
</p>
<p>
#############For example if
you have a block device whose owner keeps changing you can just 
record the attributes that do not normally change (inode,number of
links,ctime).
</p>
<p>
Note that if you are referring to a single file you should add $ to
the end of the regexp. This matches to the name of the file exactly
and does not include any other files that might have the same
beginning. In the example if there were no dollar sign at the 
end of the last line it would mean that all filenames beginning with
/var/adm/utmp would be ignored. An intruder could then create a
directory called  /var/adm/utmp_root_kit and place all the files
he/she/they wanted there and they would be ignored by AIDE.
</p>
<h3>Troubleshooting your config</h3>
<p>Making a config file is a lot of hard work and must be done on a case
by case  bases. Don't give up simply because you don't get it right
the first time around. This section gives you a few hints howto debug
your config. 
</p>
<p>
You can use <code>aide --verbose=255</code> to generate a lot of debug 
output to help you see which files get added and which are discarded. 
To really understand Aide's rule matching you should probably read a
good book about regexps and the following section.
</p>
<h4>Understanding Aide rule matching</h4>
<p>
Before reading this you should have basic understanding of how regular
expressions work. There are several good books about this. Several
Perl-books have also decent explanations about this subject. Just
remember that Perl has some extensions to the standard regexps.
There are also some differences in how different platforms handle
regexps if you are using your platforms own regexp implementation.
For example GNU regexps have their own extensions. Try reading the
manual page of your system in this case. It might be a pain to read
but it is worth it.
</p>
<p>
In the initialisation process Aide creates a tree of the regexp
rules. Each type of rule is placed in a separate list for each node in
the tree. So we have an equals rule list,a select rule list and a
negative selection rule list for all nodes. These lists may be empty.
The node in which a rule is placed is determined by the first special
regexp character in the rule. For example <code>!/proc</code> would be
placed in the root node. While <code>!/proc/.*</code> would be placed
in /proc node. Also in front of each rule Aide adds an implicit ^.
</p>
<p>
When Aide does rule matching it uses the following algorithm.
The following is a pseudocode adaptation from src/gen_list.c.
<code>
<pre>
check_node_for_match(node,filename)
	if(no deeper match found)
		check(equals list for this node)

	if(no deeper match found)
		check(select list for this node)

	check_node_for_match(nodes parent,filename)

	if(this file is about to be added)
		check(negative select list for this node) 
	
	return (info about whether this file should be added or not and how)
</pre>
</code>
</p>
<h5>Pitfalls</h5>
<p>
There are some side-effects from this algorithm that might seem
strange at first. For example if you have the following rules:
<code>
<pre>
/ R
=/etc R+a
!/etc/ppp/logs
</pre>
</code>
The result would be that /etc and all files in it and in /etc/ppp
except /etc/ppp/logs would be added to the database. This is perfectly
normal. This happens because the =/etc matches not only /etc but all
the files under it. Remember that regexps match always just the part
they are referring to. The rest of the line is included by default.
So <code>=/etc$ R+a</code> would be the correct form. If you don't
have the <code>!/etc/ppp/logs</code> you would get the results that
you are looking for because. There is no node /etc in the regexp
tree and there for it is not checked when Aide constructs the list of
files to add to the database. But when you have the negative rules the
nodes /etc and /etc/ppp get created and they get checked when the file
list is generated. So the =/etc is used to find a match in those nodes
and it succeeds.
</p>
<p>
Consider the following rules:
<code>
<pre>
/ R
=/var/log/messages$ R+a
!/var/log/messages.*
</pre>
</code>
This is what you might write if you want to check /var/log/messages
but not /var/log/messages.0 and /var/log/messages.1 etc. However since
the negative selection rules are checked last and .* can match to an
empty string /var/log/messages is not added to the database. The
following is a more correct way of doing it.
<code>
<pre>
/ R
=/var/log/messages$ R+a
!/var/log/messages\.[0-9]$
</pre>
</code>
Now only messages files ending in number 0-9 and not included in the
database. Note an intruder could disguise a rootkit by creating a
directory called messages.9. If messages.9 does not already exist that
is.
</p>
<a name=usage></a>
<h2>Usage</h2>
<p>
First you must create a database against which future checks are
performed. This should be done immediately after the operating system
and applications have been installed, before the machine is plugged
into a network. You can do this by giving the command 
<code>aide --init</code>. 
This creates a database that contains all of the files that you
selected in your config file. The newly created database should now be 
moved to a secure location such as read-only media. You should also
place the configuration file and the Aide binary and preferably the
manual pages and this manual on that media also. Please remember to
edit the configuration file so that the input database is read from
that read-only media. The config file should not be kept on the 
target machine. The attacker could read the config file and alter it
or even if he does alter it he could place his rootkit to place that
Aide does not check. So the read-only media should be accessible only 
during the check.</p>
<p>
Now you are all set to go. You can now check the integrity of the
files. This can be done by giving the command
<code>aide --check</code>.
Aide now reads the database and compares it to the files found on
disk. Aide may find changes in places that might not expect. For
instance tty devices often change owners and permissions. You may want
to read long reports and that is up to you to decide. But most of us
do not have the time or the inclination read through tons of garbage
every day. So you should trim the config file to include only the
files and attributes of certain files that should not change. But keep
in mind that you should not ignore too much as that leaves you open
for an attack. An intruder might place his/her/its/their root kit in a
directory that you have ignored completely. One good example is
/var/spool/lp or something similar. This is the place that lp daemon
stores its temporary files. You should not ignore it completely
however. You should only ignore the format of files that you lp daemon
keeps creating. And remember to use the $-sign at the end of your
regexps. This stops someone from creating a directory that is ignored
along with its contents.</p>
<p>
Now that you have trimmed your config file you should update the
database this can be done 
<code>aide --update</code>
command. The update command also does the same thing as check but it
also creates a new database. This database should now be placed on
that read-only media along with the new config file. The check, trim,
update cycle should be repeated as long as necessary. I recommend that
the config file should be reviewed once in a while. The definition of 
"a while" depends on your paranoia. Some might want do it daily after
each check. Some might want to do it weekly.</p>
<p>
There is usually some drift in the databases. What I mean by drift is
that new files are created, config files of applications are edited,
tons of small changes pile up until the report becomes
unreadable. This can be avoided by updating the database once in a
while. I myself run the update every night. But, I don't replace the
input database nearly as often. The replacement of the input datbase
should always be a manual operation. This should not be automated.
</p>
<p>
There is also an alternative way of doing this. This method may be
preferable for people that have lots of machines that run aide.
You can run 
<code>aide --init</code> 
on all of the hosts and move the generated databases to a central host
where you compare different versions of the databases with 
<code>aide --compare</code>
This has the benefit of freeing up resources on the monitored
machines.

<a name=misc></a>
<h2>Miscellaneous</h2>
<p>
The Aide database can be used to find the real names and places of
files that have been moved to lost+found directory by fsck.
</p>
<a name=general></a>
<h2>General guidelines for security</h2>
<ol>
<li>Do not assume anything
<li>Trust no-one,nothing
<li>Nothing is secure
<li>Security is a trade-off with usability 
<li>Paranoia is your friend
</ol>

</body>
</html>