Linux Security Cookbook [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Linux Security Cookbook [Electronic resources] - نسخه متنی

Daniel J. Barrett, Robert G. Byrnes, Richard Silverman

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید










Recipe 9.23 Decoding Snort Alert Messages



9.23.1 Problem


You want to
understand a Snort alert message.


9.23.2 Solution


Consult the Snort signature database at http://www.snort.org/snort-db, using the
signature ID as an index, or searching based on the text message.
Most alerts are described in detail, and many include links to other
NIDS databases with even more information, such as the arachNIDS
database at http://www.whitehats.com.


9.23.3 Discussion


Let's decode an alert message produced when Snort
detects a port scan by
nmapRecipe 9.13]:

Mar 18 19:40:52 whimsy snort[3115]: [1:469:1] ICMP PING NMAP [Classification: 
Attempted Information Leak] [Priority: 2]: <eth1> {ICMP} 10.120.66.1 -> 10.22.33.106

Breaking apart this single line, we first have the usual
syslog information:

Mar 18 19:40:52 whimsy snort[3115]:

which includes a timestamp, the hostname where Snort was running, and
the Snort identifier with its process ID. Next we have:

[1:469:1] ICMP PING NMAP

In this portion of the alert, the first number, 1, is a
generator ID, and identifies the Snort
subsystem that produced the alert. The value 1 means Snort itself.
The next number, 469, is a signature ID that identifies the alert,
and corresponds to the subsequent text message (ICMP PING
NMAP
). The final number, 1, is a version for the alert.

If the alert were produced by a Snort
preprocessor, it would
have a higher value for the generator ID, and the name of the
preprocessor would be listed in parentheses before the text message.
For example:

[111:10:1] (spp_stream4) STEALTH ACTIVITY (XMAS scan) detection

Signature IDs are assigned by each preprocessor: to learn more about
these alerts, see the snort.conf file, and the

Snort User's Manual .
Continuing our example, we see the classification of the alert:

[Classification: Attempted Information Leak] [Priority: 2]:

Each alert is classified into one of a set of broad categories: see
the file classification.config in the rules
directory. Alerts are also assigned

priority levels, with lower values
meaning more severe events. Finally, the alert identifies the
receiving network interface and lists the IP protocol, source
address, and destination address:

<eth1> {ICMP} 10.120.66.1 -> 10.22.33.106

It's optional to identify the receiving network
interface: use the -I option to enable this
feature, say, if your system is connected to multiple networks.
Finally, even though the source address is listed, you cannot trust
it in general: attackers often use spoofed addresses to implicate
innocent third parties.

If you are replaying a network trace
using snort -r, you probably
don't want to send alerts to the system logger: use
the -A fast or -A full options
to write the alerts to a file called alert in
the logging directory. The fast alert format is very similar to
syslog's. Full alerts provide
more protocol details, as well as cross-references like:

[Xref => arachnids 162]

These usually correspond to links in the Snort signature database.
See the file reference.config in the rules
directory to convert the ID numbers to URLs to obtain more
information for each alert.

Use the -A console option to write alerts (in the
fast alert format) to the standard output instead of the
alert file.


9.23.4 See Also


snort(8). The Snort home page is http://www.snort.org.

/ 247