SidReporter Install Instructions

INTRODUCTION

SidReporter is a tool that will help feedback information to the community about a number of things. Primarily we hope to improve rule quality and to give each rule a ranking of improtance. We hope to also be able to beging to obsolete older rules after they no longer hit.

Most importantly we hope to be able to feed information back to the community about attack trends, resurgences of old attacks, and new unknown sources of attack traffic, very similar to the Dshield project for firewall logs.

All information submitted will be kept in strict confidence. however you may use the obfuscation tools to alter any local IP addresses. This tool will report the SID, time and dat information, iand attacker and victim IP addresses. No payload data will ever be reporterd, and you may review the information being submitted before it is sent.

All data sent will be PGP encrypted.

INSTALLATION

SidReporter consists of a Perl script with two support modules: SnortDB?.pm and SidReportEvent?.pm. You may leave the modules in the same directory as the sidreport.pl script and execute the script from that directory, or you can copy the modules to a place Perl will know where to find them, such as /usr/lib/perl5/

SidReporter needs a number of Perl modules to be installed. Please install these by hand. These modules are listed below:

DBI

GnuPG?

Net::IP

Net::SMTP

File::Temp

Getopt::Std

Date::Manip

Note: Gnupg is BROKEN in CPAN!! DO NOT USE CPAN FOR TO INSTALL Gnupg!!! Each distribution has it's own fixed version of Gnupg, or you may alternatively use Crypt::OpenPGP in it's Gnupg compatibility mode.

See http://prlmnks.org/html/575793.html for more information on the Gnupg bugs.

Installing libgnupg-perl on many linux distributions will also provide the required GnuPG?.pm for SidReporter.

INITIAL SETUP

The first step in setting up SidReporter is adapting the configuration file, sidreport.conf, to your needs and environment. In this file you can setup the data to connect to your Snort event database, setup the email settings and IP address obfuscation settings (see below for detail).

When you first run the script you will be guided through the setup of a GPG key pair that will be used for secure submission of event data. In this process you will need to set a passphrase on your key (the script will prompt for this). YOU MUST PUT THE PASSPHRASE CHOSEN INTO YOUR sidreport.conf AFTER INITIAL SETUP!

DAILY USAGE

We suggest putting the script in a hourly cron task as soon as you feel comfortable doing so. The fewer events to be reported on each run the lesser the database load will be,. However running sidreporter once a day is fine as well.

SECURITY & PRIVACY

Sharing IDS/IPS information is something that will make many organizations nervous. We recognize that so we have done a number of things to make the process as transparant, anonymous and safe as possible.

First, the script allows you to be prompted with a confirmation step for every email with events that is sent out. This prompt is enabled by default. Once you feel confident everything works as you want, you can choose to disable the prompting in the configuration file. (CONFIRM=0)

Second, all emails are encrypted using Gpg. This ensures no one can read the emails containing the events except you and us.

Third, you can setup detailed ip address obfuscation. While we are committed to protecting all data and will not share with any other party, you still may have reasons for some ipaddresses not to be reported to us. Thats fine, we understand and have done a lot of work to make this possible and easy for you. See the separate section on ip address obfuscation for details on how to set this up.

Fourth, you can use the CC option to receive a copy of all emails SidReporter sends out to the database. This way you can keep an eye on it even if you choose to run it in an automated way.

IP ADRRESS OBFUSCATION

The concept of IP address obfuscation is simple. Instead of submitting an event with the real IP addresses, your sidreporter will send bogus local IP addresses. The client will tell us the IP address is bogus, so we don't treat it like a real one.

Lets look at an example. Say you have a host 1.2.3.4 that for which you don't want the IP address to appear in event reports. Add a entry like this to your configuration file:

[1.2.3.4] obfuscate=^1.2/10.10

Lets dissect this example. It startes with [1.2.3.4]. This indicates that the config below it applies to the host 1.2.3.4. Then there is the configuration directive 'obfuscate'. The value is used in a search/replace statement in Perl. If the first part (^1.2) matches, it is replaced by the second part (10.10). So in this case the reported IP address would be "10.10.3.4".

Instead of a single host you can also use networks, including with CIDR notation. Example:

[192.168.0.0/16] obfuscate=^192.168/10.10

This will replace all IP addresses starting with 192.168 with 10.10.

The value of the obfuscate directive is actually a comma separated list. So the following is also supported:

[192.168.0.0/16] obfuscate=^192.168.0/1.2.3,^192.168.1/3.2.1

This gives you the power to exactly control the obfuscation the way you want!

Thankyou for reporting events to Emerging Threats. The data will improve the rulesets for us all!!!

Emerging Threats

-- MattJonkman - 04 Aug 2008

Topic revision: r4 - 2008-11-05 - MattJonkman
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © Emerging Threats