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