FEDORA PRELUDE HOWTO
This document is to show how to install and configure prelude and the
audit plugins that use it for threat monitoring. IF YOU ARE UPGRADING FROM
audit-1.6.6 TO audit-1.6.7 (or higher) AND YOU ALREADY HAVE PRELUDE SETUP,
YOU MUST RE-REGISTER THE PLUGIN. Go to step 5 and do just that one. If you
never used the prelude plugin from 1.6.6, then don't worry about the caution
above.
1) Packages
Make sure you install the right pieces (for simple testing make the client
and server the same machine):
Client (sensor install):
audispd-plugins
libprelude
Server (master event repository):
libprelude
libprelude-python
libpreludedb
libpreludedb-mysql
libpreludedb-python
prelude-manager
prelude-manager-db-plugin
prewikka
prelude-correlator (new)
prelude-notify (new)
mysql
mysql-libs
mysql-server
httpd
Additional components covered:
snort
pads
2) libprelude
Libprelude is the library that does all the communicating between various
prelude components. It needs to have a couple things setup so that sensors
show up with the right info in prewikka. Open the file
/etc/prelude/default/global.conf
Find the line with node-name and uncomment it. Fill it in with your hostname.
Then find the line node-location. Uncomment it and fill it in with a
description. You could use an IP address, domain name, or any naming
convention you want. But this will affect how sensors are grouped in the
prewikka display and you'll want to have a consistent scheme for your whole
network.
3) Prelude Manager
The Prelude Manager is the daemon that receieves the events from various
sensors. It needs to be configured to work correctly. The default value is for
it to listen on localhost. This is good if you want to have a manager per
machine. If this is not the case and you would like one manager for a data
center, then you will need to make it listen on an external address and punch
it through the firewall. This is done by editing
/etc/prelude-manager/prelude-manager.conf and changing the listening line. You
will of course need to do something about the firewall.
You might want to change the uid that the daemon runs under. This howto will
assume that the daemon is going to run under root for now. I'll update it
when I've checked it all out. (If you want to experiment, uncomment the user
and group setting. Then add a prelude user like this: useradd -r prelude)
Next, you need it to use a database. For example purposes, we'll do mysql,
though it supports sqlite and postgresql, too. Edit
/etc/prelude-manager/prelude-manager.conf and uncomment the lines with
[ db ], type, host, port, name, user, and pass. The defaults should be
good - except the password. Make sure that is changed.
You will want the prelude-manager to run whenever the system is booted. Use:
chkconfig --levels 345 prelude-manager on
to enable it.
prelude-manager is linked against tcp_wrappers, so you can edit
/etc/hosts.allow and make an entry for prelude-manager and set the hosts that
you expect to be receiving events from.
4) Setting up the database
Assuming you installed mysql-server, you will need to tell it to be on each
time you boot the machine. This is fixed by
chkconfig --levels 345 mysqld on
You also probably want to restrict mysql to listening on localhost only. If
so, then edit the /etc/my.cnf file and add a line in the [mysqld] section like
this:
bind-address=127.0.0.1
Go ahead and start the daemon with "service mysqld start"
You will need to create the initial database. Log into the root account like
this:
mysql -u root
Then create the prelude database like this:
CREATE database prelude;
Next you need to create a user to access this database by entering the
following:
GRANT ALL PRIVILEGES ON prelude.* TO prelude@'localhost' IDENTIFIED BY
'passwd';
of course do not use 'passwd' for your password.
Next you need to setup the tables. Exit the database shell. Run the following
command:
mysql -u prelude prelude -p < /usr/share/libpreludedb/classic/mysql.sql
Go back into /etc/prelude-manager/prelude-manager.conf and make sure the
password matches for the prelude user you just created.
5) Final prelude-manager configuration
At this point, you need to create the prelude manager user.
prelude-admin add prelude-manager --uid 0 --gid 0
It could take a little while for it to generate the keys. If you don't have a
very active system and this appears to hang forever, you may need to generate
a little disk activity for the kernel's random number generator. I usually
do something like "find / -name '*.so'" in another window.
When it finishes, you are ready to test the daemon. Start it by:
service prelude-manager start
You should see the OK message if everything is working.
6) Registering the audisp-prelude sensor
We will start by running the registration for the audisp-prelude sensor by
typing the following:
prelude-admin register auditd "idmef:w" localhost --uid 0 --gid 0
Then in another window, run
prelude-admin registration-server prelude-manager
The second app will generate a one time password. You will need to copy and
paste that to the first window when it prompts for the password.
You should be ready to use the new plugin.
7) Enabling audisp-prelude
You will need to edit the file /etc/audisp/plugins.d/au-prelude.conf
find the line that says "active = no" change that to a yes.
If you are in an environment where you have many machines reporting to a
single prelude-manager, you will probably want your audit logs to include the
node information. Go into /etc/audit/auditd.conf change name_format to
something that makes sense to your environment. Look at the auditd.conf man
page. For this howto, just change it to "name_format = hostname".
The default configuration of the audit daemon is a best effort delivery of
events to the event dispatcher. If you want to make sure all events get
reviewed, change disp_qos to lossless. You should also probably set the
priority_boost to 4 or 5 to make sure auditd and its children get higher
priority in the scheduler.
It also might be a good idea to bump up the internal queue size of audispd.
This is done by editing /etc/audisp/audispd.conf. You want to change q_depth
to something like 512.
Then run "service auditd restart"
8) prewikka setup
Prewikka is the disply piece to prelude. It uses its own database. To set it
up, you need to log into mysql again. Run:
mysql -u root
At its prompt, type:
CREATE database prewikka;
You next need to setup a user that accesses that database. Type:
GRANT ALL PRIVILEGES ON prewikka.* TO prewikka@'localhost' IDENTIFIED BY
'password';
except change password to something of your own choosing. Go ahead and exit
from mysql so that we can setup the tables. Use:
mysql -u prewikka prewikka -p < /usr/share/prewikka/database/mysql.sql
At this point you need to edit the prewikka program's configuration. Open up
/etc/prewikka/prewikka.conf in an editor. Find the line with "place" and change it to something that describes that machine or location. Locate the
"idmef_database" section of the file. You will likely need to just change
the password. Next, locate the "database" section (should be immediately
below). Update the password and change the database user to prewikka, but
the rest should be fine. Save and exit.
9) Testing the whole system
We can now start up prewikka and see what it shows us. As root in one window,
run /usr/sbin/prewikka-httpd. It will continue to run. If you see it error
out, odds are that nasd has the port its trying to use.
Run "service nasd stop". Then open a browser to http://localhost:8000/ You
should see a login prompt. The initial username/password is admin for both.
Be sure to change this right away.
In any event, the prewikka-httpd program is simply for a quick check. You
should use apache for any real/production use of prewikka.
10) Setting up prewikka to run from apache
You can edit /etc/httpd/conf/httpd.conf and add these lines:
Alias /prewikka/ /usr/share/prewikka/htdocs/
ScriptAlias /prewikka /usr/share/prewikka/cgi-bin/prewikka.cgi
This does not protect it in any way except via account and passwords. You
could add a Location section to limit access:
Order deny,allow
Deny from all
Allow from localhost, 127.0.0.1
Allow from .my.isp.net
If you would rather use virtual hosting:
ServerName my.server.org
Setenv PREWIKKA_CONFIG "/etc/prewikka/prewikka.conf"
AllowOverride None
Options ExecCGI
AddHandler cgi-script .cgi
Order allow,deny
Allow from all
Alias /prewikka/ /usr/share/prewikka/htdocs/
ScriptAlias /prewikka /usr/share/prewikka/cgi-bin/prewikka.cgi
Then "service httpd restart". You can check your work by:
konqueror http://localhost/prewikka
You should see a login prompt. If you want apache to run each time the machine
is booted, run:
chkconfig --levels 345 httpd on
11) Installing prelude-lml
This is an optional prelude-sensor that gets its information from various log
files. You will need to open 2 windows. In one window type:
prelude-admin register prelude-lml "idmef:w admin:r" localhost --uid 0 --gid 0
You may need to generate some system activity to get it to finish generating
its key. Then in the other window type
prelude-admin registration-server prelude-manager
It will give you a password that you need to paste in the first window twice.
In the second window type "y" to confirm the registration.
Edit /etc/prelude-lml/prelude-lml.conf. In that file find the section that is
for syslog and add these lines after /var/log/messages
file = /var/log/maillog
file = /var/log/named_security.log
file = /var/log/secure
if you have mod_security installed, add:
file = /var/log/httpd/modsec_audit.log
Comment out the metalog section since Fedora does not ship it.
In the apache section, change the file to this:
file = /var/log/httpd/access_log
If you want to get warnings about missing pages, add another line like this:
file = /var/log/httpd/error_log
Next, you should tune the rules that prelude-lml uses. Edit the file:
/etc/prelude-lml/ruleset/pcre.rules and add a '#' in front of any subsystem
that you do not have installed or if this is a syslog aggregator, any
subsystem not installed on the network somewhere.
Save and exit. Next we need to enable the daemon.
chkconfig --levels 345 prelude-lml on
You can start it up with "service prelude-lml start"
12) Prelude-Correlator
This is an optional prelude analyzer that gets its information from prelude
manager and looks at the relationships of events. You will need to open 2
windows. In one window type:
prelude-admin register prelude-correlator "idmef:rw" localhost --uid 0 --gid 0
You may need to generate some system activity to get it to finish generating
its key. Then in the other window type
prelude-admin registration-server prelude-manager
It will give you a password that you need to paste in the first window twice.
In the second window type "y" to confirm the registration.
You shouldn't need to do any configuring of the daemon unless you have an
external prelude manager.
Next we need to enable the daemon.
chkconfig --levels 345 prelude-correlator on
You can start it up with "service prelude-correlator start"
13) snort
This is an optional sensor, too. If you use this, be sure to get
version 2.8.1-3 or higher since that is the one where prelude support was
enabled in Fedora. Snort sniffs a network connection for events. It is most
effective when run on a machine connected to a hub or managed switch where it
can see all network traffic. If it cannot sniff all network traffic, it will
be limited to reporting attacks on just the machine its installed on. It is
not necessary to run this on every machine. Maybe one per subnet if you are
so inclined.
First install the basic snort package. If you want a database backend, choose
that one instead. But for this demo, we will assume that prelude display is
enough.
yum install snort
edit /etc/snort/snort.conf
set your HOME_NET and other variables. When you get to RULE_PATH, make that
/etc/snort/rules. There is also a correction to make for dynamicengine. Its
path should be: /usr/lib/snort/dynamicengine/libsf_engine.so
When you get to section 4, enable the prelude output (its got its own area,
you can search for prelude to find it quickly). It should be something like:
output alert_prelude: profile=snort
You can also rename the profile to whatever you want. Next you need to
register the snort sensor. You will need to open 2 windows. In one
window type:
prelude-admin register snort "idmef:w admin:r" localhost --uid 0 --gid 0
You may need to generate some system activity to get it to finish generating
its key. Then in the other window, type
prelude-admin registration-server prelude-manager
It will give you a password that you need to paste in the first window twice.
In the second window type "y" to confirm the registration.
The next step is to make sure that snort will listen on the right interface.
Open /etc/sysconfig/snort. Change INTERFACE to correct it if necessary. There
should also be a SNORT_OPTIONS variable. If you don't see it, skip to the next
paragraph. In the SNORT_OPTIONS variable, you need to remove the "-A fast"
portion from it.
If you have an older version of snort, meaning that the sysconfig file does
not have SNORT_OPTIONS, then you need to edit /etc/rc.d/init.d/snortd. You
need to remove the "-A fast" from the deamon start line.
Fedora does not ship any snort rules. So, you will need to go visit snort.org
and get some rules. Put them in /etc/snort/rules
Next we need to enable the daemon.
chkconfig --levels 345 snortd on
You can start it up with "service snortd start"
14) PADS - Passive Asset Detection System
Pads is a program that listens on a raw socket and listens to all the traffic.
It uses this to monitor what services are located on what machines. This can
be useful to spot equipment being plugged in to the network that shouldn't be
there or spotting a new service that wasn't previously known. This program
needs to be run on a machine connected to a hub or managed switch where it
can see all network traffic.
To register this app, you will need to open 2 windows. In one window type:
prelude-admin register pads "idmef:w" localhost --uid 0 --gid 0
You may need to generate some system activity to get it to finish generating
its key. Then in the other window type
prelude-admin registration-server prelude-manager
It will give you a password that you need to paste in the first window twice.
In the second window type "y" to confirm the registration.
The next step is to configure the daemon. Open /etc/pads.conf and look for the
line assigning the interface. Set that to eth0 or whatever is appropriate for
your machine. Then update the line that sets the network. This is the network
that you want monitored for changes. Next, uncomment the prelude output line.
If you want to set a profile name, change the word pads to whatever you need.
Next we need to enable the daemon.
chkconfig --levels 345 pads on
You can start it up with "service pads start"
15) Prelude-Notify
This is an optional prelude alerting subsystem that can pop up notifications
on your desktop when significant events occur. You will need to open 2
windows. Assuming your desktop login uid is 500, in one window type:
prelude-admin register prelude-notify "idmef:r" localhost --uid 500 --gid 500
You may need to generate some system activity to get it to finish generating
its key. Then in the other window type
prelude-admin registration-server prelude-manager
It will give you a password that you need to paste in the first window twice.
In the second window type "y" to confirm the registration.
Next we want to start it up. You should find it in the gnome menu:
Applications|System Tools|prelude-notify. You should notice a green or red
ant with binoculars in the notification area at the top right part of the
screen. Right clicking on it will let you configure it.
16) Deployment Tips
a) SE Linux forms the behavorial model that is the second line of
defense should an intruder get past configuration and gcc/glibc based
defenses. Therefore, you should run "aureport --start today --summary --avc"
everyday and work through all the SE Linux AVCs. Use audit2why to help
identify booleans that may need to be changed, use "semanage fcontext -a ..."
to add the correct file context if you keep things in non-standard locations.
File bugs against selinux policy for AVCs against programs that are a standard
part of the distribution. And you should learn how to generate policy for
custom apps with system-config-selinux (its in policycoreutils-gui package).
b) You should trim your prelude database periodically. The database has 2
kinds of entries, heartbeats and alerts. To get rid of heartbeats, use
something like:
preludedb-admin delete heartbeat "type=mysql name=prelude user=prelude
pass=$password" --criteria "heartbeat.create_time < $DATE" --count $limit
and to get rid of old alerts, use something like:
preludedb-admin delete alert "type=mysql name=prelude user=prelude
pass=$password" --criteria "alert.create_time < $DATE
where $password is the prelude db password from the config files of step 4.
The $DATE can be 7 days ago, 1st of the month or whatever you want it to be.
The $limit is the maximum number of events to include in 1 transaction. 200000
is a good general number. If too many events are in one transaction, MySQL
will complain.
c) If you see failed login attempts for root, admin, system, etc. You probably
ought to consider using IPTables or tcp_wrappers to limit the accessibility of
your server. You can find those in your logs by running "aureport --start
this-month --login --failed -i"
d) If you see anomalies in the audit logs, you should check into those. You
can find them by running "aureport --start this-month --anomaly -i". If you
see ANOM_ABEND as the type, that is an application segfault. That would either
be a programming mistake or a failed attack against that application. If the
program is: network facing, processing data from unauthenticated remote users,
setuid, or setgid, you should think about filing a bug report to fix whatever
bug is allowing the segfault and whether or not you can or should limit access
to the faulting application while awaiting a bug fix.
e) Install some basic audit rules to gather extra information about your
system. The DISA stig.rules file distributed with the audit package is a good
starting point. All rules in the stig.rules file have keys assigned to the
rules. You should periodically look at the keys to see if you are getting too
many audit events of a certain kind. This would indicate that you either have
users that do bad things or if these all appear to be normal, understood, and
explainable you may need to change the audit rules to be a little less
aggressive. You can get a feeling for the system activity by running:
"aureport --start this-week --key --summary". You will want to customize these
rules by adding a second ids key, such as "-k ids-file-med" as explained in
the audisp-prelude man page.
17) References
If you want to learn more about prewikka and all the prelude architecture,
please look at these resources:
Detailed docs:
https://trac.prelude-ids.org/wiki/PreludeHandbook
This is the home page for prelude:
http://www.prelude-ids.org/
Feature matrix:
http://prelude-ids.org/rubrique.php3?id_rubrique=24
Architecture:
https://trac.prelude-ids.org/wiki/PreludesArchitecture
The RFC that defines the IDMEF standard:
http://tools.ietf.org/rfc/rfc4765.txt