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.
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/
needs a number of Perl modules to be installed. Please install these by hand. These modules are listed below:
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.
for more information on the Gnupg bugs.
Installing libgnupg-perl on many linux distributions will also provide the required GnuPG?
.pm for SidReporter
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!
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 188.8.131.52 that for which you don't want the IP address to appear in event reports. Add a entry like this to your configuration file:
Lets dissect this example. It startes with [184.108.40.206]. This indicates that the config below it applies to the host 220.127.116.11. 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:
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:
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!!!
- 04 Aug 2008