Information Security, Privacy and Regulatory Compliance - Intrusion Detection

BART (Basic Audit and Reporting Tool) on Solaris 10/OpenSolaris

nospam@example.com (Keith Pachulski) — Fri, 30 Jul 2010 23:57:08 -0400

As a follow-up to a conversation regarding this; BART is one of those integrated features that is often overlooked in the Solaris 10/OpenSolaris distributions. BART at it's core function similar to other host file integrity check systems. While it is a nice tool for small shops, it is by no means well suited for large scale deployments. For mid to large scale system integrity verification and host level intrusion detection/prevention systems I`m of course still an advocate of OSSEC^[?]. For clarification, BART only performs file integrity checking and does not monitor log files or system processes etc...

Creating the BART Manifest

This would be an example of a simple manifest recording the attributes of all files within the /etc, /boot, /sbin and /usr directories and generate an md5 hash for each file.

bart create -R /etc /boot /sbin /usr > /bart/control

Included in the control file would contain single line entries for each file, link, etc

/X11/fontpath.d/misc:unscaled:pri=15 L 35 120777 - 4c50ebb0 0 0 ../../../usr/X11/lib/X11/fonts/misc
/X11/gdm/Init/Default F 2640 100755 owner@::deny,owner@:read_data/write_data/append_data/write_xattr/execute/write_attributes/write_
acl/write_owner:allow,group@:write_data/append_data:deny,group@:read_data/execute:allow,everyone@:write_data/append_data/write_xattr
/write_attributes/write_acl/write_owner:deny,everyone@:read_data/read_xattr/execute/read_attributes/read_acl/synchronize:allow 4a0c3
e11 0 3 bf7503995330dc79b078bdba2171d657

Each line will contain a notation defining what each entry is, these are as follows:

# Format:
#fname D size mode acl dirmtime uid gid
#fname P size mode acl mtime uid gid
#fname S size mode acl mtime uid gid
#fname F size mode acl mtime uid gid contents
#fname L size mode acl lnmtime uid gid dest
#fname B size mode acl mtime uid gid devnode
#fname C size mode acl mtime uid gid devnode

- B for a block device node
- C for a character device node
- D for a directory
- F for a file
- L for a symbolic link
- P for a pipe
- S for a socket

Further available attributes are as follows:

size - File size in bytes.
mode - Octal number that represents the permissions of the file.
acl - ACL attributes for the file. For a file with ACL attributes, this contains the output from acltotext().
uid - Numerical user ID of the owner of this entry.
gid - Numerical group ID of the owner of this entry.
dirmtime - Last modification time, in seconds, since 00:00:00 UTC, January 1, 1970, for directories.
lnmtime - Last modification time, in seconds, since 00:00:00 UTC, January 1, 1970, for links.
mtime - Last modification time, in seconds, since 00:00:00 UTC January 1, 1970, for files.
contents - Checksum value of the file. This attribute is only specified for regular files. If you turn off context checking, or if checksums cannot be computed, the value of this field is –.
dest - Destination of a symbolic link.
devnode - Value of the device node. This attribute is for character device files and block device files only.

Create the diff manifest and check for changes

To verify BART is functioning correctly, we'll create a test file in the /etc directory

keithp@opensolaris:/bart# touch /etc/thisisatest

Once the test file has been created we now need to run BART again to generate the differential manifest

keithp@opensolaris:/bart# bart create -R /etc /boot /sbin /usr > /bart/control-diff

After the diff manifest has generated, we then verify that any changes that have occurred, as well as checking for the test file being created.

keithp@opensolaris:/bart# bart compare control control-diff > bart-modifications
keithp@opensolaris:/bart# more bart-modifications
/thisisatest:
add

The test file we created was detected. No other modifications were found. The downside to BART is that if any changes were discovered that were legitimate. BART does not automatically update the control file. The control-diff would now become the primary file from which future checks are performed against. To automate the BART checks, add a cronjob to perform the creation of the new differential file as well as performing the compare jobs.

0 7,14,21 bart create -R /etc /boot /sbin /usr > /bart/control-diff
30 7,14,21 bart compare control control-diff > bart-modifications

Centralized BART Monitoring

With some creativity, through the NFS/automount, you can create a hub and spoke type design where the spoke systems individually create the control and diff files. The control files can be moved to the central server and the diff files remain on the spoke systems. Additional cronjobs would be created that would compare the manifest on the central server to the diff manifest located on the spoke systems. Bearing in mind of course that NFS is not encrypted by default but with some simple tweaks you can implement service level encryption to secure the NFS traffic between the central and spoke systems. But again, why recreate the wheel?

Again, it's nice to tinker with or act as a second line of auditing. But I would strongly urge a system like OSSEC be implemented to perform the centralized monitoring and reporting.

OSSEC - Part 2 - The OSSEC Configuration (ossec.conf)

nospam@example.com (Keith Pachulski) — Mon, 24 May 2010 20:16:00 -0400

In previous posts we've reviewed the basic server and client configuration as well as how to, using the external parser, insert the alerts into BASE. At this point we're going to delve a bit deeper into the server side configuration.

Email Alerting

This is really personal preference, if you like receiving a ton of email with events that are also being inserted into the database, feel free to make use of this.

At the top of the ossec^[?] configuration file located in /var/ossec/etc/ossec.conf, the first container specifies what types of alerts you want to receive as well as where the you want the specified alerts being sent to. This container may already be populated if you enabled email notification during setup.

<global>
<email_notification>yes</email_notification>
<email_to>you@yourdomain.com</email_to>
<smtp_server>someserverhere</smtp_server>
<email_from>ossecm@yourdomain.com</email_from>
</global>

While this is the base configuration, there are a few additional options you may want to use here.

Enable throttling, this is highly recommended. If the systems you are monitoring become targeted by a high rate attack and ossec is configured to generate an email on every alarm. You can effectively cause a denial of service condition on your own systems. This is set with the following:

- <email_maxperhour>X</email_maxperhour>

X would be the maximum number of emails that ossec will generate in a given hour. Keep in mind, by setting this option, if you are relying on email alerts you may miss events with the high level threshold you set. The events are queued however once they reach the X limit you set, the queue is cleared 20 alerts at a time until cleared.

In addition to the global email alerting, we can also create targeted email groups based on server names, as they have been named when the client was configured when using ./manage_agents

<email_alerts>
<email_to>null@protectors.cc</email_to>
<event_location>servers1|server2</event_location>
</email_alerts>

Tweaking the email alerts

The default email alert configuration within OSSEC^[?] is as follows:

<alerts>
<log_alert_level>1</log_alert_level>
<email_alert_level>7</email_alert_level>
</alerts>

The alert levels are based on severity of the events ranging from 0 to 15. With 0 being information and 15 being high severity. The alert levels themselves are defined within the ossec rule files located in /var/ossec/rules. When modifying this log and email alert levels, ensure events you deem as important are not going to be missed during this tuning process. An example of the alert level in an ossec definition would be as follows:

<rule id="12109" <strong>level="12"</strong>>
<if_sid>12100</if_sid>
<match>exiting (due to fatal error)</match>
<description>Named fatal error. DNS service going down.</description>
<group>service_availability,</group>
</rule>

In this example, OSSEC will log all events level 1 and higher. Level 0 alerts are those that we have defined that we are not interested in being reported on. In the above example of email_alert_level, only events level 7 or higher would generate email alerts. This is only applicable if you have enabled email alerting that is.

Receiving and Processing Alerts from Remote System/Devices

With this portion, we are concerned with the receipt and processing of events from remote systems. We will receive these events in one of two manners. The first is syslog being configured on the remote device to send events to the OSSEC server, these will typically be networking devices or servers with syslog support. The second method is using the ossec agent on a remote system to send log events via a secure channel to the ossec server.

Configuring Standard Syslog and OSSEC to Monitor

In this example, we have our OSSEC server also running as a central log collector. All events received from remote system are received on Local6.info and are inserted into /var/log/messages.

The typical syslog configuration will appear as follows in /etc/syslog.conf

local6.* /var/log/messages

For the OSSEC configuration on the server, we define the following:

<localfile>
<log_format>syslog</log_format>
<location>/var/log/messages</location>
</localfile>

Now, on networking equipment such as switches and routers, we need to define the logging facility and host to log events to. The following would be an example for a Cisco Router:

logging facility local6
logging source-interface <interface facing the ossec server>
logging <ip address of the ossec server>
do wr
exit

As long as syslog is correctly configured on the server, messages from the device will begin to populate the /var/log/messages file. To start OSSEC processing the events, restart ossec after adding the above (note: /var/log/messages is typically added to most configuration by default on linux based systems).

OSSEC has the ability to monitor several including syslog, snort, squid, IIS, Windows event logs, mysql, postgresql and apache. However, the important thing to to remember with OSSEC is that the log formatting is completely customizable and can support nearly any type of logging.

Syscheck Configuration Options

My typical Linux syscheck template is along these lines depending on the installation and the purpose of the server:

<syscheck>
<frequency>14400</frequency>
<directories realtime="yes" >/var/www</directories>
<directories check_all="yes">/opt,/bin,/usr/bin,/usr/local/bin,/usr/local/sbin,/sbin,/boot,/etc,/home</directories>

<alert_new_files>yes</alert_new_files>
<scan_on_start>no</scan_on_start>
<auto_ignore>no</auto_ignore>


<ignore>/etc/mtab</ignore>
<ignore>/etc/mnttab</ignore>
<ignore>/etc/hosts.deny</ignore>
<ignore>/etc/mail/statistics</ignore>
<ignore>/etc/random-seed</ignore>
<ignore>/etc/adjtime</ignore>
<ignore>/etc/httpd/logs</ignore>
<ignore>/etc/utmpx</ignore>
<ignore>/etc/wtmpx</ignore>
<ignore>/etc/cups/certs</ignore>
<ignore>/etc/dumpdates</ignore>
<ignore>/etc/svc/volatile</ignore>
</syscheck>

Breaking this down piece by piece; when we specify the directory to monitor we have the following options available to us:

- realtime - provides realtime monitoring of the specified directories
- check_all - performs all of the below checks on the specified directories
- check_sum - checks for changes to the md5/sha1 hash of the files
- check_size - checks for changes to the sizes of the files
- check_owner - check for changes to the owner of the files
- check_group - check for changes to the group ownership
- check_perm - check for changes to the permissions

It would be my recommendation that either check_all by the default with realtime as the alternate option for those highly critical directories.

Frequency defines the amount of time, in seconds, that OSSEC will fire to perform the checks on the specified directories. Makes sure to tune this to an acceptable level. While 100 seconds may seem sexy, it's not realistic and may end up crushing your servers.

Alert_new_files - by default this is not in the configuration. I strongly recommend this be added and set to yes. When ossec makes its run, anything new it finds it will generate an alarm on, otherwise you`ll never know when someone uploads the c99.php file if you're not doing realtime checking of /var/www/html

Scan_on_start - by default this is set to yes, I would recommend this be set to no and let it run on against the frequency setting. I`m not sure if its a feature of a bug but on some rare occasions when I've restarted ossec it's caused scans an hosts to restart and when making several changes to the local_rules and restarting several times..it brought a system to a dead halt for a short time period.

auto_ignore - by default this is set to yes, this meaning after the 3rd time the file has changed in some way and you have not acknowledged the change it will simply ignore it. Not the best approach in my opinion for a noisy system that requires monitoring.

As for the ignores, those are some general noisy files, feel free to add more to the list as you see fit.

Additional options include scanning specific directories on certain days or at specific times if you do not want to rely on the general frequency directive.

scan_day - specifies the day or days you want the scan to run (scan_day sunday, wednesday, friday)

scan_time - specifies the time of the day you want the scan to run ( scan_time 12pm)

Ignoring sub-directories with syscheck

There may be on occasion you want to monitor for example /var/www/html and all directories contained with it, but you do not want to monitor sarg/

<directories check_all="yes">/var/www/html<directories>
<ignore>/var/www/html/sarg</ignore>

This will effectively ignore all files and directories contained within the /var/www/html/sarg directory.

Rootcheck Configuration Options

Again, my typical linux template..feel free to customize it as you see fit Something to bear in mind though, the rootcheck portion can be very resource intensive. This module will scan the entire operating system by default looking for both rootkits as well as common system configuration issues. While I personally let it scan the entire system, it can be disabled with the scanall no option.

<rootcheck>
<frequency>86400</frequency>
<rootkit_files>/var/ossec/etc/shared/rootkit_files.txt</rootkit_files>
<rootkit_trojans>/var/ossec/etc/shared/rootkit_trojans.txt</rootkit_trojans>
<system_audit>/var/ossec/etc/shared/system_audit_rcl.txt</system_audit>
<system_audit>/var/ossec/etc/shared/cis_rhel5_linux_rcl.txt</system_audit>
</rootcheck>

Frequency I define as daily, and as I use CentOS5 I leave in the rhel5 file and remove the cis_rhel_linux_rcl.txt. If you are running a non 5 release, feel free to add or replace cis_rhel_linux_rcl.txt as needed.

While most of this specifically addresses the server side configuration, the syscheck, rootcheck, and localfile parameters are portable to the client side ossec.conf configuration files.

Going to wrap it up with this, next section will likely be on OSSEC Reporting as I'm on a reporting and metrics kick as of late..

Any questions feel free to shoot me an email..

Integrating OSSEC into BASE

nospam@example.com (Keith Pachulski) — Thu, 25 Feb 2010 22:21:00 -0500

This is the quick and dirty for integrating OSSEC^[?] alerting into BASE so you can have your snort and OSSEC alerts alarms residing in the same interface.

Install snort and BASE, if you`re not sure how to do this refer to the previous posting on this topic found here.

Once you have snort and base installed, have imported the sql schema's for both snort and acid, import the OSSEC schema into the snort and snort_archive databases; the mysql schema files for ossec^[?] can be found in the contrib directory:

# mysql -u snort < ossec2mysql.sql snort
# mysql -u snort < ossec2mysql.sql snort_archive

Move the following three files from the contrib directory to /usr/local/bin/

# mv ossec2mysql.pl /usr/local/bin/
# mv ossec2mysqld.pl /usr/local/bin/
# mv compile_alerts.pl /usr/local/bin/

Modify ossec2mysql.conf adding the correct database information, chmod the file 600, chown the file root.root then move it to /etc/

If you do not already have a signatures directory under BASE, create it now (I`ll be bringing this up again during the initial snort/BASE install for those who do not have it yet).

# mkdir /var/www/html/secure/base/signatures && chown apache.apache /var/www/html/secure/base/signatures

At this point you want to import all current OSSEC alarms into the snort database which BASE is querying from:

# zcat /var/ossec/logs/alerts/2010/Feb/ossec-alerts-*.gz | /usr/local/bin/ossec2mysql.pl --conf /etc/ossec2mysql.conf --interface manualfeed

After you've imported all the current events manually into the snort database, launch the ossec process to continuously monitor and import OSSEC events into the snort database:

# /usr/local/bin/ossec2mysqld.pl --conf /etc/ossec2mysql.conf -d

Now log into BASE and you should have all your archived OSSEC alerts, as well as all future alarms being inserted into BASE.

Introduction to OSSEC - Server/Client and OSSEC WUI

nospam@example.com (Keith Pachulski) — Fri, 19 Feb 2010 22:35:28 -0500

In this episode we'll be reviewing the OSSEC^[?] Host Intrusion Detection System (HIDS^[?]). We will cover the basic steps to installing and configuring both the server and client applications. Additionally, we'll be covering installing and configuring the OSSEC Web User Interface (WUI). We will not be covering how to integrate OSSEC into the BASE management console. That will be addressed in another blog post, to be released shortly.

OSSEC, for those of you who aren't aware of what it is exactly, is a software based system that monitors the host operating system. Like traditional integrity check based systems (tripwire, aide, osiris), ossec^[?] performs file and user/group monitoring. One of the major differences between OSSEC and other traditional systems, is that OSSEC can perform the monitoring in real time on designated files and directories. In addition to the file monitoring capabilities, OSSEC has the ability to monitor the registry on Windows systems for alteration to registry keys.

OSSEC also monitors log files in real time, this functionality is typically referred to as a Log Based Intrusion Detection (LIDS^[?]) system. The LIDS portion of the application is enabled by default as part of the basic server and client installation. OSSEC exports the client system logs to the central OSSEC server via a secure channel. The server OSSEC then analyzes all entries for questionable entries or known designated "bad" entries. This includes Windows Security, Event and Application logs, IIS logs, database logs, Apache, SQUID, firewalls, routers, switches, snort as well as a slew of others. For a complete list of all supported log files please see the OSSEC list, bearing in mind however that you can use the generic module to inspect log files or create your own to monitor custom log files. In addition to monitoring for known and questionable "bad" traffic, it will also generate alarms for anything it does not understand or underlying operating system errors such as process failures, disk full errors, raid failures to name but a few.

But wait...there's more..

In the typical OSSEC installation, as with most traditional file integrity check based systems, you need to install some type of agent on the client systems. OSSEC has a very useful feature for those systems which may not support a client to be installed. For these you can utilize the agentless configuration for monitoring virtually any type of system, be it a Cisco ASA firewall or an OS/400 system.

The entire OSSEC system is extremely flexible.

In all examples from this point forward, I am basing the installation of both the client and server on the CentOS 5 operating system. The basic setup and design however is generally the same on all *nix based systems. I am also basing the installation on the current version of OSSEC which is v2.3 as of the time I'm writing this. When doing the installation yourself, you may want to refer to the ossec.net website if you are unable to retrieve the packages using the links I've provided.

Log Samples for various OSSEC Alerts

New User logging into the system

** Alert 1267052622.246237: mail - syslog,fts,authentication_success
2010 Feb 24 18:03:42 keithpachulski -> /var/log/secure
Rule: 10100 (level 4) -> 'First time user logged in.'
Src IP: (71.185.192.3)
User: bernie
Feb 24 18:03:41 keithpachulski sshd[9304]: Accepted password for
bernie from 71.185.192.3 port 57905 ssh2

Yum updates on the system

** Alert 1266983791.268245: mail - syslog,yum,config_changed,
2010 Feb 23 22:56:31 keithpachulski -> /var/log/messages
Rule: 2933 (level 7) -> 'Yum package updated.'
Src IP: (0.0.0.0)
User: (none)
Feb 23 22:56:31 keithpachulski yum: Updated:
systemtap-runtime-0.9.7-5.el5_4.1.i386

Douchebags attempting directory traversal attacks on my server and failing

** Alert 1267064964.272533: - web,accesslog,attack,
2010 Feb 24 21:29:24 keithpachulski -> /var/log/httpd/access_log
Rule: 31104 (level 6) -> 'Common web attack.'
Src IP: (195.93.200.219)
User: (none)
195.93.200.219 - - [24/Feb/2010:21:29:23 -0500] "GET
/%22%20%20target=%22_blank/index.php?option=com_communitypolls&controller=./../../../../../../../../proc/self/environ%00
HTTP/1.1" 404 235 "-" "-"

Obtain the OSSEC application and the OSSEC WUI

$ wget http://www.ossec.net/files/ossec-hids-2.3.tar.gz
$ wget http://www.ossec.net/files/ui/ossec-wui-0.3.tar.gz

Untar both the ossec-hids and ossec-wui packages

$ tar zxvf ossec-wui-0.3.tar.gz && tar -zxvf ossec-hids-2.3.tar.gz

Install the OSSEC HIDS application

$ cd ossec-hids-2.3
$ su or sudo ./install.sh
$ Select [en] as the default language

Hit -Enter- after the install script displays the host information

1- What kind of installation do you want (server, agent, local or help)?

Enter "server"

2- Setting up the installation environment.

- Choose where to install the OSSEC HIDS [/var/ossec]:

Leave it as the default /var/ossec by selecting [Enter]

3- Configuring the OSSEC HIDS.

3.1- Do you want e-mail notification? (y/n) [y]:

If you want OSSEC to send you emails on alert, select y - if you do not want it to send you emails on alerts select n

If you select yes, you'll be prompted for your email server information.

3.2- Do you want to run the integrity check daemon? (y/n) [y]:

Select y as the default as we want the server and agent processes to perform file integrity checking.

3.3- Do you want to run the rootkit detection engine? (y/n) [y]:

Select y as the default as we want the server and agent processes to check for known malicious software and perform basic checks on our application installations.

3.4- Active response allows you to execute a specific
command based on the events received. For example,
you can block an IP address or disable access for
a specific user.
More information at:
http://www.ossec.net/en/manual.html#active-response

- Do you want to enable active response? (y/n) [y]:

If you want the OSSEC software to actively respond to suspected intrusion, enable this. Otherwise select n for it to operate in a passive monitoring and reporting mode.

3.5- Do you want to enable remote syslog (port 514 udp)? (y/n) [y]:

Enter n here (entering n assumes you already have syslog listening for remote entries - check your syslog conf to be sure), later on in the configuration we'll be specifying the syslog files we want OSSEC to monitor on both the server and client installations.

After entering y or n on the last entry, OSSEC will scan all default log locations for all system log files and automagically begin tailing those files. While OSSEC tails the files, it will be comparing all entries against known malicious or questionable traffic patterns being entered into the logs.

If there are additional logs you want monitored, simply modify the ossec.conf file after the installation has completed. We'll cover this more later.

Once the installation has completed, you'll need to modify the default configuration file to reflect your system configuration and remove some unnecessary lines from the configuration.

If you installed OSSEC to the default location, the configuration file can be found in /var/ossec/etc

To view my sample server configuration template for OSSEC running on CentOS5 or RHEL5, go here

The above configuration will enable the following options:
- file integrity checks to be performed on the server every 14400 seconds
- file integrity checks for all files located in the following location:
-- <directories check_all="yes">/bin,/usr/bin,/usr/local/bin,/usr/local/sbin,/sbin,/boot,/etc,/home</directories>

The check_all options tells OSSEC to watch all attributes of the file including permission, owner, group etc. There is an additional option to continuously, in real-time, monitor the specific file or directory by using the "realtime" option.

-- <directories realtime="yes" check_all="yes">/bin,/usr/bin,/usr/local/bin,/usr/local/sbin,/sbin,/boot,/etc,/home</directories>

Other optional fields that are recommended to add are as follows:

- alert_new_files: This is not a default option and designates that when new files are created, OSSEC will generate alerts for each new file created. This option should be set to "yes".

- scan_on_start: This option should be disabled. It can be disabled by setting the field to "no". If this option is not disabled, each time OSSEC is restarted on the system, OSSEC will rescan the entire file system.

- auto_ignore: By default OSSEC will auto-ignore files that change often and are not acknowledged. In certain environments, this type of behavior is not acceptable and this should be disabled. Disabling this option is accomplished by setting the field to "no".

Rootkit checks and system audits, I perform every 86400 seconds. This can be tuned to whatever value you are comfortable with. Bear in mind however that the rootkit and system level audit checks can be resource intensive.

Once the server configuration has been completed, start the OSSEC process: /var/ossec/bin/ossec-control start

With the OSSEC server portion operating, we will configure the OSSEC WUI before moving onto installing, configuring and integrating a client into the OSSEC syste,

Installing and Configuring the OSSEC WUI

As root, move, rename and change the owner/group of the ossec-wui-0.3 directory as follows:

# mv ossec-wui-0.3 /var/www/html/ossec && chown -R ossec.ossec /var/www/html/ossec
#cd /var/www/html/ossec

Run the setup script in the ossec directory:

# ./setup.sh

Afer entering the requested information during the setup.sh script execution, add the "user" apache runs as to the ossec group

#usermod -G ossec apache

Modify the permission on the tmp/ directory in the ossec directory to allow apache to access the contents of tmp

# chmod 770 /var/www/html/ossec/tmp && chgrp apache /var/www/html/ossec/tmp

Restart Apache

By default, OSSEC will authenticate access to the OSSEC directory using Basic htaccess authentication. If you have BASE installed and want to use MySQL authentication from the BASE system, modify the .htaccess directory to use the following:

AuthName "Access Restricted to Authorized Users Only"
AuthType Basic
AuthMySQLEnable on
AuthMySQLHost localhost
AuthMySQLUser snort
AuthMySQLPassword (yoursnortMySQLpasswordhere)
AuthMySQLDB snort
AuthMySQLUserTable base_users
AuthMySQLNameField usr_login
AuthMySQLPasswordField usr_pwd
AuthMySQLPwEncryption md5
require valid-user

Authenticating users from the BASE MySQL table will allow you to permit access to everyone who has access to the BASE console access to OSSEC, without the need for continuously modifying the .htpasswd file each time you want to add a new user.

The OSSEC WUI configuration is now completed, you should now be able to access it via your web broswer by going to https://ipofserver/ossec

-- Note: If you don't have this running under HTTPS, it would be in your best interest to do so.

At this point, you should have the OSSEC server operating as well as the OSSEC WUI, we will now add our first client to the system.

Installing the client is exactly the same except that instead of installing it as a server, we'll be installing it as an agent.

Installing the OSSEC Client

$ tar -zxvf ossec-hids-2.3.tar.gz
$ cd ossec-hids-2.3

su to root to install the software and modify the configuration

# ./install.sh

Select en as the default language and enter agent for the install type.

Once you enter agent, take the default installation location which will be /var/ossec

You will then be asked for the IP address of the OSSEC HIDS Server, enter it and hit enter

3- Configuring the OSSEC HIDS.

3.1- What's the IP Address of the OSSEC HIDS server?:

3.2- Do you want to run the integrity check daemon? (y/n) [y]:

Accept the default of "y" here

3.3- Do you want to run the rootkit detection engine? (y/n) [y]:

Accept the default of "y" here

3.4 - Do you want to enable active response? (y/n) [y]:

Select "n" here, at this point OSSEC will now install the agent application on the system.

As with the server side installation, the ossec configuration file needs to be modified. I have made a template available for *nix based systems available by clicking here

Once you've completed the client side configuration we now need to add the client to the server configuration.

Introducing the Client to the Server

All communications between the client and server are encrypted. If for whatever reason the communication path between the client and server becomes interrupted, the client side will queue messages until the server becomes reachable again. At which time it will export all queued messages to the server.

On the server we first need to add the client system, export the encryption key for the client, then restart the ossec process. This all needs to be performed as root or via sudo, whichever method you typically use.

# cd /var/ossec/bin
# ./manage_agents

Select "A" to add an agent
- enter the name of the agent
- enter the ip of the agent
- accept the default value for the ID

Select "E" to extract the key
- enter the ID of the system

Copy the entire key, if any portion of the key is missing, the client will not be able to connect to the server.

Exit from the manage_agents application and restart OSSEC

# /var/ossec/bin/ossec-control restart

On the client, run the manage_agents application. Unlike the server, you will only have the option to import a key via "I" on the client.

Once you enter the IP and paste in the key, exit from the manage_agents application and start the ossec application:

# /var/ossec/bin/ossec-control start

As long as the agent and the server have a clear communication path, the client will begin its first operating system integrity, audit and rootkit checks as well as beginning to export all system logs designated in the client OSSEC configuration file to the server.

To add more systems, simply repeat the "Installing the OSSEC Client" and "Introducing the Client to the Server" steps.

That's all for now folks...check back soon for "How to Integrate OSSEC into BASE"

Quick Reference Guide: Snort and BASE Installation and Setup

nospam@example.com (Keith Pachulski) — Mon, 15 Feb 2010 17:05:20 -0500

This is the quick and dirty guide to compiling, configuring and installing snort to log to a mysql database, then installing BASE to view those alerts. We`ll be using this basic setup again later as we integrate OSSEC^[?] into BASE for centralized reporting of all network and host based intrusion alarms.

For snort you'll need to obtain the following for this install:

PCRE
libpcap
snort

Compiling and Installing PCRE

$ tar zxvf pcre-8.01.tar.gz
$ ./configure && make

su to root and install: make install

Compiling and Installing libpcap
$ tar zxvf libpcap-1.0.0.tar.gz
$ ./configure && make

su to root and install: make install

Compiling and Installing Snort

If possible, do not have the MySQL server running on the snort sensor server, the two functions should be seperated.

$ tar zxvf snort-2.8.5.2.tar.gz
$ ./configure --with-mysql --enable-perfprofiling --enable-reload

su to root and install: make install

Create a new user for snort to run under, snort should NOT be run as root

# useradd -c "snort nids" -s /sbin/nologin snort

Create the directory to store the snort signature files

# mkdir /home/snort/sigs

Move the preprocessor rules to the snort directory

[root@cent snort-2.8.5.2]# mv preproc_rules/ /home/snort/sigs/

Move the snort init script and logrotate scripts to their correct locations

# mv rpm/snortd /etc/rc.d/init.d/
# ln -s /etc/rc.d/init.d/snortd /etc/rc3.d/S99snort
# chmod 755 /etc/rc.d/init.d/snortd
# mv rpm/snort.logrotate /etc/logrotate.d/snort
# mv rpm/snort.sysconfig /etc/sysconfig/snort
# mv etc/snort.conf /home/snort/
# mv etc/ /home/snort/sigs/

Add the snort libraries to the ld.so.conf file and run ldconfig

# echo /usr/local/lib/snort_dynamicrules >> /etc/ld.so.conf
# /usr/bin/ldconfig

We'll come back configuring the rest of snort once we have BASE running

Create the MySQL database to be used by snort for event logging, to be used later by BASE

mysqladmin create snort
mysqladmin create snort_archive

From the schema directory, execute the following:

mysql -u root -p < create_mysql snort
mysql -u root -p < create_mysql snort_archive

Create the snort user and grant permissions on the snort. and snort_archive. databases

$ mysql -u root -p
mysql> create user 'snort'@'localhost' identified by 'password_goes_here';
mysql> create user 'snort'@'ip_of_the_remote_snort_sensor' identified by 'password_goes_here';
mysql> grant CREATE,INSERT,SELECT,DELETE,UPDATE on snort. to 'snort'@'localhost';
mysql> grant CREATE,INSERT,SELECT,UPDATE on snort. to 'snort'@'ip_of_the_remote_snort_sensor';
mysql> flush privileges;

Installing and Configuring BASE

Upgrade pear and all installed pear packages, this will be needed for some of the BASE modules

If php-gd is not installed, install it now

yum install php-gd

pear upgrade PEAR-1.x.x (whatever the most recent is)
pear install Image_Color
pear install --alldeps --force Log
pear install Numbers_Roman
pear install --alldeps --force Image_Graph-0.7.2
pear install --alldeps mail
pear upgrade-all

Download and install adodb

$ tar zxvf adodb510.tgz

su to root, change the owner and group then move to /var/www/

# chown -R apache.apache adodb5/ && mv adodb5/ /var/www/

Download and install BASE

$ tar zxvf base-1.4.4.tar.gz

su to root, change the owner and group then move to /var/www/html/

# chown -R apache.apache base-1.4.4/ && mv base-1.4.4/ /var/www/html/base

Modify php.ini to not expose php and set the error logging to the recommended level

expose_php = Off

error_reporting = E_ALL & ~E_NOTICE

Modify the BASE configuration file to reflect the username, password and adodb location

# cd /var/www/html/base
# cp base_conf.php.dist base_conf.php && chown apache.apache base_conf.php

$BASE_urlpath = '/base';
$DBlib_path = '/var/www/adodb5';
$alert_dbname = 'snort';
$alert_host = 'localhost';
$alert_port = '';
$alert_user = 'snort';
$alert_password = 'mypassword';
$archive_exists = 1;
$archive_dbname = 'snort_archive';
$archive_host = 'localhost';
$archive_port = '';
$archive_user = 'snort';
$archive_password = 'mypassword';
$refresh_all_pages = 1;
$show_previous_alert = 1;
$refresh_all_pages = 1;
$show_expanded_query = 1;
$colored_alerts = 1;
$IP2CC = "/usr/bin/ip2cc";

Make sure to set all the correct information in the SMTP portion of the configuration so you can email yourself or others copies of the alerts from BASE.

Install the Geography:Countries Perl module for map generation

tar zxvf Geography-Countries-2009041301.tar.gz && cd Geography-Countries-2009041301
perl Makefile.PL && make

su to root and install the perl module: make install

Install the IP-Country Perl module for map generation

tar zxvf IP-Country-2.27.tar.gz && cd IP-Country-2.27
perl Makefile.PL && make

Start apache:

/etc/rc.d/init.d/httpd start

Open your web browser and navigate to the BASE URL:

http://ip.address.here/base

If you've modified all fields correctly, you'll be presented with a page saying:

"The underlying database snort@localhost appears to be incomplete/invalid. "

Click the "setup page" link then click the Create BASE AG button.

Click on the "Main page" link, click on the "Use Archive Database" link

Click the "setup page" link then click the Create BASE AG button.

Return to the primary database by clicking the "Use Alert Database" link.

Now that snort is installed, the mysql schema for snort has been loaded and the ACID AG schema for base has been loaded, we return to the final portion of this which is finalizing the actual snort configuration file, loading the signatures and starting snort while logging alerts to the mysql database.

Download the most recent signature file from snort.org, you`ll need to generate an account to get the file.

mkdir temp
mv snortrules-snapshot-2.8.tar.gz temp/ && cd temp/
tar zxvf snortrules-snapshot-2.8.tar.gz

Move the plain text signature descriptors to the BASE directory, this must be done as root as the BASE directory is owned by apache

# mv doc/signatures /var/www/html/base/ && chown -R apache.apache /var/www/html/base/signatures

Move the signature files to the snort sigs directory which we created earlier:

# mv rules/ /home/snort/sigs/ && chown -R snort.snort /home/snort/sigs/

Modify the snort.conf file to reflect the network to be monitored, the variables noted are ones that should be modified, feel free to experiement though:

$ cd /home/snort
$ vi snort.conf

var HOME_NET 192.168.0.0/8 (enter the correct network with mask here of the network you are monitoring)
var DNS_SERVERS [192.168.0.1,192.168.0.2] (enter your actual DNS servers here)

same follows with all the variables, if you can define it please do so..the more specific you are the better the results

var RULE_PATH /home/snort/sigs
var PREPROC_RULE_PATH /home/snort/sigs/preproc_rules

The snort decoders you'll have to experiment with, personally I find them very noisy and typically disable them on all installations.

Locate the line containing the following:

iis_unicode_map unicode.map 1252

and change it to:

iis_unicode_map /home/snort/sigs/unicode.map 1252

The ftp_telnet preprocessor works well in some area's, horrible in others..it requires some heavy tuning outside the scope of this blog post.

Locate the following string, uncomment it and correct the information with your actual database information:

output database: log, mysql, user=snort password= dbname=snort host= sensor_name=

Locate the following two lines and modify them to appear as follows:

include classification.config
include reference.config

include $RULE_PATH/classification.config
include $RULE_PATH/reference.config

Once you`ve modified all the needed fields, test the config with the following string:

# snort -c /home/snort/snort.conf -i eth0 -T

If everything is correct and snort can connect to the database, you`ll be presented with the following:

Snort successfully loaded all rules and checked all rule chains!
database: Closing connection to database "snort"
Snort exiting

Now for the final part, modifying the snort sysconfig file so we can actually start/stop/restart/stats the snort process. Modify the following lines as needed:

vi /etc/sysconfig/snort
CONF=/home/snort/snort.conf
INTERFACE=eth0 (set the correct interface name of set ALL for snort to listen on all interfaces)
PRINT_INTERFACE=1
#PASS_FIRST=) (comment this out, the option no longer exists, the default behavior is pass first now)
BINARY_LOG=1 (by default snort will generate pcap dumps of all alerts, this will require much disk space and manual/scripted removal of the files as it will chew up disk space, set it to 0 if you do not want pcap generated files of alerts)

Modify the snort init script to remove an option that no longer exists but for whatever reason in 2.8.5.1 the init still references it:

#if [ "$PASS_FIRST"X = "1X" ]; then
# PASS_FIRST="-o"
#else
# PASS_FIRST=""
#fi

Create a symlink to snort for the location in the snort init script or edit the snort init script to reflect the actual location:

# ln -s /usr/local/bin/snort /usr/sbin/snort

Now just start snort up:

# /etc/rc.d/init.d/snortd start

Enjoy...

Squid as a Passive Web Content Filtering System

nospam@example.com (Keith Pachulski) — Tue, 09 Feb 2010 17:32:00 -0500

The goal here is simple, have a content filtering system in place that is transparent to the end users that will simply terminate their web browsing sessions when they attempt to access sites deemed as malicious or in violation of company policy, or home restrictions. This setup is based on CentOS 5.4 with Squid installed via yum and iptables along with a Cisco Router, though the WCCP configuration could easily be ported over to an ASA with WCCP support.

At the time of this writing, GRE tunneling as needed in this setup is not supported on either OpenSolaris or Solaris 10.

Configuring the Router for WCCP v2

? Connect to the device via console/ssh/telnet and enter into configuration mode
o enable
o conf t

? Define ?interesting traffic? via an extended access list
o ip access-list extended filter
o permit tcp 192.168.1.0 0.0.0.255 any eq 80
o exit

? Enable WCCP v2 and apply the filter list to WCCP
o ip wccp version 2
o Once you enter this command, WCCP is enabled but doing a show run does not display this command in the configuration
o ip wccp web-cache redirect-list filter
o This command tells the router to forward all traffic to the Squid server once it has connected to the router/switch
o On the outbound interface (the one connected to the internet feed) enter the following
o Interface
o ip wccp web-cache redirect out
? This command tells the router to redirect all outbound traffic as defined by the filter access list.
o Write the configuration before moving onto the Squid server configuration
o ctrl+z
o wr mem

Configuring the Squid Server for WCCP v2

By default Squid, if installed from an rpm which it should be, stores its configuration files in /etc/squid/.

Before beginning the configuration of squid, backup the original configuration file by doing the following:

? cd /etc/squid
? cp squid.conf squid.conf.original
o This command will rename the original squid.conf to squid.conf.original

Create the new squid configuration file and insert the base configuration information for Squid to support WCCP v2 content filtering:

? su
o enter root password
? cd /etc/squid
? vi squid.conf
? Hit the 'i' key to enter into insert mode then paste in the following:

#Enable transparent mode on the default Squid service port of 3128

http_port 3128 transparent
#Default stuff Squid needs to function
icp_port 0
hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin \?
cache deny QUERY
acl apache rep_header Server ^Apache
broken_vary_encoding allow apache
access_log /var/log/squid/access.log squid
ftp_passive on
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern . 0 20% 4320
client_lifetime 1 day
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443 7004
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

#Define the networks to be filtered and the WCCP device which will be using the server
#Define networks here, this MUST mirror the filter access-list created on the router/ASA
acl our_networks src 192.168.1.0/24

#Add the squid access list files here
acl blocksites dstdomain "/etc/squid/deniedsites.acl"

#Define how we deny the traffic matching the blocked sites list - Any web traffic matching the destination domains will generate a TCP reset to the client
deny_info TCP_RESET blocksites
http_access deny blocksites

#Define traffic we will allow which has not been blocked by the previous
http_access allow our_networks
http_access allow localhost
http_access deny all
http_reply_access allow all
icp_access allow all
visible_hostname squid

#Define WCCP router/switch information here
wccp2_router 192.168.1.254
wccp_version 4
wccp2_rebuild_wait on
wccp2_forwarding_method 1
wccp2_return_method 1
wccp2_assignment_method 1
wccp2_service standard 0
coredump_dir /var/spool/squid

? Once this has been posted into the configuration file, hit escape then type :wq and hit enter ? this will write and exit from the file
? Type exit and hit enter to leave the root account.

Configuring the CentOS Server for GRE Tunneling and traffic forwarding

Load the ip_gre module, make sure you load the correct gre module for the current kernel loaded. If the kernel is updated you should remove and reload the updated module

? insmod /lib/modules/2.6.18-164.11.1.el5/kernel/net/ipv4/ip_gre.ko

Creating the GRE interface on the server

? NOTE: Be careful when manually creating the GRE interface, editing the wrong file or inserting incorrect characters into the interface configuration file may render the system useless.
? su
o Enter the root password
? vi /etc/sysconfig/network-scripts/ifcfg-gre0
o NOTE: This is an example of how the interface is configured, correct the following fields with the IP information reflecting the network where the device is being installed

#The IP Address of the interface should be the same as the primary interface on the server
DEVICE=gre0
BOOTPROTO=static
BROADCAST=192.168.1.255
IPADDR=192.168.1.1
NETMASK=255.255.255.0
NETWORK=10.5.0.0
ONBOOT=yes
TYPE=Ethernet

? Once this has been posted into the configuration file, hit escape then type :wq and hit enter ? this will write and exit from the file
? Turn the interface up by typing the following
? ifconfig gre0 up
? Type exit and hit enter to leave the root account.

Enable IP Forwarding within the server operating system

? su
o Enter the root password
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 0 > /proc/sys/net/ipv4/conf/default/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/lo/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/gre0/rp_filter

Creating the IP GRE Tunnel from the Squid Server to the WCCP router/switch

? su
o Enter the root password
? /usr/sbin/iptunnel add wccp mode gre remote 192.168.1.254 local 192.168.1.1 dev eth0
o Note: correct the remote and local address to reflect the correct IP of the remote WCCP device and the local address of the Squid server.
? vi /etc/rc.local
o hit 'i' to enter into insert mode and paste in the following
o /usr/sbin/iptunnel add wccp mode gre remote 192.168.1.254 local 192.168.1.1 dev eth0
? Once this has been posted into the configuration file, hit escape then type :wq and hit enter ? this will write and exit from the file
? Type exit and hit enter to leave the root account.

Modifying the static iptables rule set and adding the port redirection

? su
o Enter the root password
? vi /etc/sysconfig/iptables
o hit 'i' to enter insert mode and add the following lines into the firewall configuration
o -A RH-Firewall-1-INPUT -p gre -j ACCEPT
o Allows GRE traffic to the Squid server
o -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 2048 -j ACCEPT
o Allows WCCP traffic to the server
o -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 3128 -j ACCEPT
o Allows traffic to the Squid service port
? Once this has been posted into the configuration file, hit escape then type :wq and hit enter ? this will write and exit from the file
? Type the following to enable port redirection for traffic coming into the GRE interface to the Squid service
o /usr/bin/iptables -t nat -I PREROUTING -i gre0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
? vi /etc/rc.local
o hit 'i' to enter into insert mode and paste in the following
o /usr/bin/iptables -t nat -I PREROUTING -i gre0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
? Once this has been posted into the configuration file, hit escape then type :wq and hit enter ? this will write and exit from the file
? Type exit and hit enter to leave the root account.

Starting the Squid service and verifying WCCP connection from the Squid server to the router/switch

WCCP Router
? Console/ssh to the WCCP router and enter the following commands
o enable
o conf t
o logging on
o logging monitor debug
o exit
o debug ip wccp event
o debug ip wccp packets
o terminal monitor
Squid Server
? Start the Squid service
? su
o Enter the root password
? /etc/rc.d/init.d/squid start

Once the squid service has started, you should start seeing messages on the router/switch saying new WCCP router detected and then a flurry of ?Here_I_Am? and ?I_See_You? messages on the console. Once you see these, the squid server has successfully connected to the WCCP service on the router/switch.

Populating the deniedsite.acl

Sites that you want to deny access to should be added to the file mentioned previously in the configuration at /etc/squid/deniedsites.acl

These should be added in same top-level structure as the user accessed the site. For example, the user goes to www.playboy.com - We want to deny access to the top level as well as all subdomains of .playboy.com so in the deniedsites.acl file we add the following: