'Installation'에 해당되는 글 3건

  1. 2009.03.12 Snort Installation by CEOinIRVINE
  2. 2008.10.14 [2] Snort Configuration : Rule Installation by CEOinIRVINE
  3. 2008.10.10 Snort Installation on CentOS 4.6 by CEOinIRVINE

Snort Installation

IT 2009. 3. 12. 04:45

To install from source, download it from the Snort web site (http://www.snort.org). Uncompress, unpack, compile, and install by using the following commands:

tar xzf snort-2.2.0.tar.gz
cd snort-2.2.0
./configure
make

And then as root:

make install

Discussion

Installing from source is nearly as easy as installing from precompiled packages, and it works across all Unix platforms. There is also a lot more flexibility in the options you can choose. First of all, you need to download the latest source tar file from snort.org. At this point, if possible, you should ensure that the source has not been meddled with; you can do this by verifying the checksum given using the MD5 utilities.

[simon@frodo downloads]$ md5sum snort-2.2.x.tar.gz
6194278217e4e3f733b046256a31f0e6 *snort-2.2.x.tar.gz

The source is a tarred gzip file; to extract it, enter the following at a command prompt:

[simon@frodo downloads]$ gunzip snort-2.2.x.tar.gz
[simon@frodo downloads]$ tar -xvf snort-2.2.x.tar

You'll then see the entire list of filenames scroll past as they are decompressed and extracted. This creates a directory structure under the current directory. In this case, with the base directory ./snort-2.2.0/. Change into this directory. At this point, if you wish to perform an ordinary installation, type the following:

[simon@frodo snort-2.2.x]$ ./configure

This will create the make file optimized for your architecture. There are a number of options that you can specify to configure. These are listed in Table 1-1. They include options for specifying switches for the compliers as well as turning on support for certain features.

 
Switch Action
--enable-debug

Turn on the debugging options.
--with-snmp

Enable SNMP alerting code.
--enable-smbalerts

Enable SMB alerting code.
--enable-flexresp

Enable the "Flexible Response" code.
--with-mysql=DIR

Turn on support for MySQL.
--with-odbc=DIR

Turn on support for ODBC databases.
--with-postgresql=DIR

Turn on support for PostgreSQL.
--with-oracle=DIR

Turn on support for Oracle.
--with-openssl=DIR

Turn on support for OpenSSL.
--with-libpq-includes=DIR

Set the support directories for PostgreSQL.
--with-libpq-libraries=DIR

Set the library directories for PostgreSQL.
--with-libpcap-include=DIR

Point the configure script in the right direction for the libpcap include files.
--with-libpcap-libraries=DIR

Point the configure script in the right direction for the libpcap library files.
--prefix=PATH

Set the install directory to PATH rather than /usr/local.
--exec-prefix=PATH

Set the install directory for the executables and libraries to PATH; install all other files in the usual place.
--help

Print out all the available options.


For further information on these switches, you should read through the INSTALL file included in the /doc directory. Also in this file are some of the known issues and fixes for compilation on different Unix operating systems. The configure script may warn you of missing dependencies (other applications or utilities that are required by Snort). Download and install the required files from their respective web sites and rerun the configure command. In the many installations we've done, we can only recall coming across two missing prerequisites. These were libpcap, the library for performing packet capture on Linux systems, available for download from http://www.tcpdump.org, and Perl Compatible Regular Expressions (PCRE), available for download from http://www.pcre.org/.

Then you need to compile it using the make command:

[simon@frodo snort-2.2.0]$ make

Now go and get the hot beverage of your choice. This can take some time, even on a pretty fast machine. There are no test cases to run, so at this point, you need to run the install as root:

[root@frodo snort-2.2.0]# make install

Provided at this point you see no error messages, your installation is complete.

Also ensure that the directory to which Snort writes logfiles exists and is writable by the user that Snort runs as. If Snort can't write its logfiles, it will fail during any attempt to run it.

The INSTALL document in the /doc directory of Snort

http://www.tcpdump.org

http://www.pcre.org/


'IT' 카테고리의 다른 글

iPhone OS Preview  (0) 2009.03.14
Running Snort as a Linux Daemon  (0) 2009.03.12
New iPod speaks names of artists and songs  (0) 2009.03.12
Palm Confident About Pre Phone  (0) 2009.03.11
Apple's Next Blockbuster  (0) 2009.03.10
Posted by CEOinIRVINE
l

Rule Installation

Snort comes with more than enough rules to satiate your diet. We’re always surprised to learn about new rules that inventive people have made from all over the world; many have been added to the public domain.

Our goals in building a well-tuned IDS installation is to first enable most, if not all, of the rules that come with Snort. This enabling produces a ton of output (most is likely irrelevant to your network environment), but it gives you a great introduction to the type and frequency of the alerts pounding on your front door. From there, tuning Snort is like Goldilocks faced with her choices: Start with the bed that’s way too big and then keep refining until it’s “jusssst right.”

This section delves into those messy-looking rules files.

How the rules files are organized

Snort’s rules directory sorts hundreds of rules into rules files according to their purpose. Although the rules are cataloged a few different ways and some of the rule categories have overlapping domains, there’s certainly a method to the madness.

Rules files fit into eight major categories:

  • Low-level protocols (icmp, netbios, tcp, udp)

  • High-level protocols (http, ftp, dns, pop3, imap)

  • Web server specific (web-attack, web-cgi, web-client)

  • Exploit specific (shellcode, backdoor, exploit)

  • Service impacting (dos, ddos)

  • Policy specific (policy, info, misc, porn)

  • Scanning and probing activities (scan, bad-traffic)

  • Viruses, worms, and other malware (virus)

An in-depth rule structure

The best way to find out how the whole rule system works is to get your hands dirty with a typical example:

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS 
(msg:"WEB-IIS CodeRed v2 root.exe access"; flow:to_server,established; 
uricontent:"/root.exe"; nocase; classtype:web application-attack; 
reference:url, www.cert.org/advisories/CA-2001 19.html; sid:1256;  rev:7;)

This rule demonstrates many of the options that you’re likely to encounter with your own setup. We picked the Code Red worm alert from the web-iis.rules file as our starting point.

 Tip  Here’s a piece-by-piece explanation of that Code Red worm rule, which appeared earlier in this section:

  • The alert directive (in bold in the following alert snippet) tells Snort that if the packet matches this rule, then the rule should send its output through the alert facility.

    alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS...

    The overwhelming majority of Snort’s rules use the alert facility, although optionally, you can use the log facility. Chapter 6 explains the difference between these two facilities.

  • The tcp keyword is an argument that identifies which network protocols the rule applies to. The following alert snipped shows the tcp keyword in bold:

    alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS...

    Because the tcp keyword is specified, Snort knows to match this rule only to network traffic using the TCP protocol (other protocols, such as UDP) will be ignored.

  • The network source and destination arguments are highlighted in bold in the following statement:

    alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS...

    The preceding network source and destination arguments (including port numbers) tell Snort to alert on any traffic that is either

    • From the $EXTERNAL_NET on any port

    • To any of our Web servers on the defined Web ports.

     Technical Stuff  The network source and destination arguments use the variables established at the beginning of the snort.conf file (the arguments beginning with the $). These substitutions provide convenience and readability for managing a large collection of rules, which can easily top a few thousand entries.

  • The last part of the rule gets even more granular with information the rule should match on, as well as what Snort should do if the rule does match . The following snippet shows what this looks like:

    (msg:"WEB-IIS CodeRed v2 root.exe access"; flow:to_server,established; 
    uricontent:"/root.exe"; nocase; classtype:web application-attack; reference:url, 
    www.cert.org/advisories/CA-2001-19.html; sid:1256;  rev:7;)
    • A few other tests tucked away in that last section must be passed before an alert is generated. The flow: and uricontent: keywords further refine the rule. In this case, if the uricontent (URI stands for universal resource identifier) contains the text "/root.exe". The flow says that the connection should be going to the server and should already be established. IP listed in your var HTTP_SERVERS section of snort.conf, then an alert is generated with the message "WEB-IIS CodeRed v2 root.exe access".

    Snort also identifies the type of attack by classifying it as a "web applications-attack." It further identifies the exact nature of the alert setting the "sid" (Snort IDentification) field to 1256. Sids are unique identifiers to Snort. They can nail down an offense to exactly one alert. The reference: keyword provides a log entry regarding any other information that’s known about the nature of the attack. References are often URLs to security-related Web sites, such as CERT, Whitehats, or SecurityFocus, which provide advisories on what the attack is and how to patch for it (if possible). In our Code Red example, we point to the CERT Web site with the following URL:

    http://www.cert.org/advisories/CA-2001-19.html

Figure 8-1 shows a graphical overview of how a Snort rule is laid out. In it, you see many of the bits and pieces of a rule.

Image from book
Figure 8-1: The Snort rules layout. Click to collapse

Flow or direction operators represent how traffic is traversing the network. Their use is pretty straightforward:

  • The > operator tells Snort that the network on the left should be regarded as the source, and the one on the right should be the destination.

     Technical Stuff  There isn’t a <- operator. All instances using it are written by flip-flopping the arguments around the > command.

  • The <> operator will match any traffic between the network on the left and the network on the right, regardless of which network originated the traffic.

     Warning   The directionless operator (<>) can sometimes cause a bit of confusion with its use. It seems to makes sense that you would inspect traffic flowing both ways from one computer or network to another, but that inspection happens infrequently. Most Snort rules look something like this:

    $EXTERNAL_NET any -> (internal host / port)

    A rule that matches too broadly (which the preceding rule would do if it contained <>) produces a huge Snort log and unduly burdens the processing engine as it inspects everything that passes by.

Elements of the rule header

Sifting through the directory of rules shows that all the rules contain header information, though most have a jumble of different items in their bodies. The header is just a front-end filter that separates out traffic by using five key sifting factors: source IP address, destination IP address, source port, destination port, and protocol.

Rule actions

Snort comes built-in with five different rule actions. Each gives you a lot of power in building your arsenal.

 Tip  Before changing the default behavior of your Snort rules, spend some time watching it operate in your environment and use its output to help you reduce noisy false positives.

Here are Snort’s five rule actions:

  • The log action merely logs the offending packets to the output logging that we set up when the Snort sensor was configured. The output plug-ins options are many and varied, giving you a rich set of choices. A per-rule log directive lets you customize logging down to a remarkable level.

  • The alert action can print a log entry and post a notification when some event is associated with a higher priority and probably needs a personal touch.

     Technical Stuff  The alert action is the default action for most rules that come with Snort. Snort’s job, after all, is to alert us of an attack on our network!

  • The pass action can ignore a matched packet and continue processing.

    The pass action is useful when you’re tuning your rules and need to disable some of the noisier ones so that you can actually see the output of what you’re working with.

  • The most powerful of the Snort actions is the activate keyword. Activate operates in concert with the dynamic action by triggering an alert and running what’s specified by the associated dynamic rule.

     Technical Stuff  The activate/dynamic pair is ideal for catching a complex series of attacks that may otherwise go unnoticed.

  • The dynamic action is associated with a rule that shouldn’t run until another event is encountered. You combine the dynamic action with the activate action to set up a second level of processing in certain circumstances.

     Technical Stuff  The activate/dynamic pair isn’t often used in common Snort setups, but it can be a handy tool for advanced intrusion detection.

Protocols

Snort, as a network IDS, must operate on the lowest level of the network to do its job. Snort grabs Ethernet frames directly from the wire. Inside of those frames are the four protocols that the free version of Snort normally scans: IP, ICMP, TCP, and UDP.

 Technical Stuff  Snort’s developers are attempting include other protocols, such as HTTP, 802.11, and ARP. The keywords for building your rules should include only one of the original four.

For example, let’s say employees aren’t allowed to use the eBay auction Web site on the job. A particular employee has been reprimanded for spending hours browsing eBay, and HR wants to monitor his behavior. The following rule logs all Web traffic that contains ebay.com coming from the host 192.168.1.18 with the message eBaying:

log tcp 192.168.1.18/32 any -> any 80 (msg:"eBaying"; uricontent:"ebay.com";)

Source/destination

The last part of a well-formed Snort rule is probably the most important piece of configuration data: The two IP address ranges that are involved with the communication. The source and destination networks are identified in a rule that takes this form:

(source network) (port) -> (destination network) (port)

 Tip  CIDR (Classless Inter Domain Routing) notation is used for the network arguments. CIDR notation is that funny way of expressing an IP address using a / and another number — for example, 10.35.24.0/24, which means a Class C network of 254 hosts on network 10.35.24.0 (plus the first and last addresses that are reserved for the network address and the broadcast address, namely 10.35.24.0 and 10.35.24.255).

For the Snort rules files, you really deal with only two types of entries:

  • Networks (which contain a /)

  • Hosts (which omit /)

    Omitting / is a shorthand way of saying, "Just the single IP address, if you please." For example, the address 10.35.24.66 indicates just one host for matching against.

You can also enter ranges of port numbers, similar to ranges of IP addresses. Most of the examples that we cover in this chapter are single ports, such as 80 for the Web port, 443 for the encrypted Web port, and 25 for sendmail. The entire range of available ports extends from 0 to 65535.

For a range of ports, you just place a colon between the two ports. The following rule looks for any traffic containing “ebay.com” occuring on any TCP port between 1 and 1023.

log tcp 192.168.1.18/32 any -> any 1:1023 (msg:"eBaying"; uricontent:
"ebay.com";)

You can also include the maximum and minimum ports ranges by simply leaving off a number. For example :1023 means a range of ports from 0–1023, and 1024: refers to a range of 1024–65535.

Wildcards

Wildcards simplify rules. Wildcards work just like those “splat” asterisks that you can type into a DOS window or Unix shell to list only certain files. In Snort, the any keyword is the most powerful wildcard — and it’s all over the place. You’re allowed to use the any wildcard in both the network and port configurations: any matches everything for the category you placed it in.

 Tip  In the preceding section, we used the any wildcard in a couple of places. When the host 192.168.1.18 tries to start a communication on any port with any host on ports 1–1023 with the text "ebay.com" as part of a URI, then . . . bingo! That’s a match, and the message eBaying appears in the logs.

Elements of the rule body

After being mangled by the pre-processors and whittled down by the filters of the rule’s header, the rule’s body contains a virtual cornucopia of tests.

The most powerful test is pattern-matching what slips through for either specific keywords, phrases, or strings of binary data. Often, this inspection is the most critical, because what’s being searched for is the “fingerprint” of the attack itself.

Many of the most powerful features of Snort’s detection engine reside in the body of the rule. Each feature has a different style, syntax, and set of options. This flexibility can make rule management somewhat complicated, but very worthwhile.

The layout of the rule body

Snort’s rule body must follow this specific structure:

  • The body section of a rule is always wrapped by one set of parentheses.

  • Body options (keywords, instructions, tests, and commands) are within the parentheses.

  • Each body option is separated by a semicolon.

  • Each body option usually conforms to this format (the value is wrapped in double quotes):

    item: "value";
  • The entire line is terminated with a semicolon.

While the structure contains a lot of punctuation, it helps keeps things straight for both Snort and the person managing it.

The “content” option

Content analysis flushes out specific attack signatures within the packet. The particulars of the content option is applied to each and every packet that matches the header of the rule and can be expressed in either plain text form (ASCII) or geek-speak (Hexadecimal).

Worms, viruses, and server cracks are normally transmitted onto your network as raw machine code, which, to the naked eye, looks like gobbledy-gook, but is in fact a series of instructions that harm your computers and servers.

 Tip  Content matching is typically done at the application layer (Layer 7) of the OSI networking model.

Text content matching (ASCII)

As a simple scenario for demonstration purposes, let’s say you’re concerned about employees trading computer hacking information within your organization. You can create a rule that generates an alert whenever an e-mail is sent to your primary mail server (the mail server’s IP address is 172.16.30.7) containing the word "hacking". The mail port is 25; most mail is transmitted using the TCP protocol, so the following rule illustrates how we can use the content keyword to craft a rule to meet our goal.

alert tcp $EXTERNAL_NET any -> 172.16.30.7 25 (msg:"Found hacking reference 
in e-mail"; content:"hacking";)

 Technical Stuff  Content analysis (by either text or hexadecimal matching) is used in more than two-thirds of the rules that come with Snort.

Hexadecimal content matching

Hexadecimal (hex) content, although expressed differently than ASCII text, is ultimately treated the same as ASCII by the Snort processing engine. In both cases, the text is reduced to what the computer deals with best: bits, which is then matched against the data streaming across your network. Hex is just a shorthand way of representing the zeros and ones of binary machine code.

 Tip  Hexadecimal is like a numerical alphabet that is 16 characters long, as compared with English (which has 26 letters) or decimal math (which has 10 numerals). Hexadecimal is often referred to as base-16 because the “alphabet” it uses has only 16 “letters” (0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F). Hexadecimal strings entered into a Snort rule body contain only those characters and none others. If you create a hexadecimal string with nonhex characters, expect that Snort will turn up its nose.

Here’s a real example right out of the rules directory:

alert tcp $EXTERNAL_NET any -> $HOME_NET 22 (msg:"EXPLOIT ssh CRC32 overflow 
filler"; flow:to_server,established; content:"|00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00|"; reference:bugtraq,2347; reference:cve,CVE-2001-0144; 
classtype:shellcode-detect; sid:1325;  rev:3;)

To use a hex match for content searching, wrap the hexadecimal characters to find with the pipe symbols (|). White space can separate out single bytes of hexadecimal data (“00 00”). Snort ignores the white space, which is only there to preserve the readability to the rule crafter.

The preceding rule is meant to watch for an attempted exploitation of the Secure Shell server application (sshd) by scanning traffic coming from anywhere on the external network and destined for your home network on port 22 (the sshd port). The content search is a long series of binary zeros (18 sets of two, to be exact). How can a pattern of zeros be unique? A pattern of zeros is frequently found in attack code and is often a give-away that someone is doing something you don’t like.

Mixing it up

You can mix and match the style of content searching without confusing Snort. As long as the binary data you want to search for has the bookends of the pipe characters, that block of text can be intermingled with other, plain ASCII text. What follows is a good example from the back-door.rules file.

alert tcp $EXTERNAL_NET any -> $HOME_NET 12345:12346 (msg:"BACKDOOR netbus 
getinfo"; flow:to_server,established; content:"GetInfo|0d|"; 
reference:arachnids,403; classtype:misc-activity; sid:110; rev:3;)

Notice how the content search string is constructed: GetInfo|0d|. This string tells Snort’s pattern matching subsystem to watch for the text phrase GetInfo with a carriage return at the end. Pretty nifty, eh? Inserting hex into a plain text string is useful for representing characters that can’t be represented by plain text, such as a carriage return. You can drift between text and binary content all within the same search string.

The “depth” option

It would be nice if malicious content always occurred at the beginning or end of a packet. Unfortunately, malicious content can occur almost anywhere in a packet. The depth option specifies how many bytes into a packet the Snort processor should look before moving on to the next rule.

The main reason for using the depth option is to restrict the search to the most likely places where a match is found, without wasting valuable processor resources to search the entire packet. For example, if you want to find the HTTP protocol version as part of a Web site communication, look in the first few hundred bytes. Because a packet may be as large as 1,500 bytes (less the header overhead), it makes a lot of sense to give Snort a break, especially if what it must look through are millions upon millions of packets.

The following rule from the web-misc.rules file reveals that you need only 15 bytes to catch the sadmind worm. Hence, the content GET x http/1.0 is always encountered at the very beginning of the packet.

web-misc.rules:alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS
 (msg:"WEB-MISC sadmind worm access"; flow:to_server,established; content:"GET x 
HTTP/1.0"; offset:0; depth:15; classtype:attempted-recon; 
reference:url,www.cert.org/advisories/CA-2001-11.html; sid:1375;  rev:5;)

The “nocase” option

The nocase option, which appears in more than a third of the rules that ship with Snort, basically says to ignore the case of the characters submitted for searching. Because the nocase directive takes no arguments, it’s normally just used with a terminating semicolon. The following example from the info.rules file finds the text LOGIN FAILED or LoGIn FaIlEd on a telnet session port.

alert tcp $HOME_NET 23 -> $EXTERNAL_NET any (msg:"INFO TELNET Bad Login"; 
content: "Login failed";  nocase; flow:from_server,established; 
classtype:bad-unknown; sid:492; rev:6;)

The “offset” option

Another tool that gives us a more precise scope on where in the packet to look is the offset option. Offset works by skipping over the number of bytes supplied to the right of the colon. So, offset:90 skips the first 90 bytes of the packet and then begins searching for the string given as part of the content keyword. Offset and depth work nicely together to make the search area of a packet limited to a window that is bracketed by the two. Basically, if you know where to look and what to look for, you can use these two options to help Snort get a fast grip on where to spend its time.

The Uniform Resource Identifier (URI) option

You can use the uricontent option to conduct a similar type of content searching. Its purpose is similar to the depth and offset options: to reduce the overall processing burden on Snort as it watches for more attacks to effectively do its job.

The uricontent option works much like the content one, except it restricts its searching to only URIs in the payload of the packet. URIs (Uniform Resource Identifiers) in Snort can specify other protocols than http, such as ftp, gopher, rsync, and https.

The uricontent option only searches for the given text in URIs that is found in the packet. If URIs aren’t present, no match occurs. URI searching is good for catching malicious commands that are readily evident as they often appear in the location request to a Web server. The following rule from the web-iis.rules file shows an exploit attempt against the IIS server using both content and uricontent analysis:

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-IIS 
.asa HTTP header buffer overflow attempt"; flow:to_server,established; content:
"HTTP|2F|"; nocase; uricontent:".asa"; nocase; content:"|3A|"; content:"|0A|"; 
content:"|00|"; reference:bugtraq,4476; classtype:web-application-attack; 
sid:1802; rev:4;)

A couple of interesting characteristics about this rule are worth discussing:

  • When nocase follows a string, its effect is upon the content string immediately prior.

  • The nocase option has no effect upon binary search strings. Leaving it off of those strings just helps the overall flow of the rule.

Classification

The classification options provide an overall description of a rule, along with other helpful information about the rule, that can be used by the Snort program itself and a system administrator. These options include the Snort ID, the alert message to appear in the alert log, the rule revision number, the alert priority, the alert classification, and external references for the exploit or vulnerability that triggered the alert.

Snort IDs

Quite a few options help organize and classify detected alerts. The Snort ID (sid) option is unique to the Snort system and a good way to get a handle on classifications.

The format of the Snort ID value is the same as it as other classification options. For example, a proper usage is as follows:

sid:<ID_VALUE>;

 Warning   When you get the hang of building your own sets of rules, assign each custom rule a unique sid number somewhere above the 1,000,000 mark. That way, updates to the Snort rule base won’t accidentally collide with your custom rule. Table 8-1 gives you a breakdown of the uses for sid ranges.

Table 8-1: Snort ID (sid) Values

Range of Values

Usage

1–100

Reserved for future use

100–1,000,000

For use within the www.snort.org distribution network

1,000,000 +

For use in customizing your own Snort rules

Priority

Snort has a built-in numerical rating for many of the rules that it ships with: The lower the priority number, the higher the risk posed by the attack that tripped the rule. By using the priority option, you can override Snort’s default level and rate how important or impacting a particular rule is to your unique environment. For example, the following command assigns the rule associated with it the highest priority: 1.

priority:1;
Classtype

The classtype option can organize rules into major groups. A few dozen different classification types are spread over three priority levels, which are described in Tables 8-2, 8-3 and 8-4. For inclusion in a rule, the syntax is

classtype:<CLASS_TYPE_NAME>;
Table 8-2: Priority 1 Classifications (Critical Severity)

classtype

Description

attempted-admin

Attempted privilege escalation to an Administrator level

attempted-user

Attempted privilege escalation to a User level

shellcode-detect

Discovered executable code

successful-admin

Achieved successful privilege escalation to an Administrator level

successful-user

Achieved successful privilege escalation to a User level

trojan-activity

Discovered software code of a Trojan Network Attack

unsuccessful-user

Failed privilege escalation to a User level

web application attack

Identified an attack upon a Web server’s application software

Table 8-3: Priority 2 Classifications (Intermediate Severity)

classtype

Description

attempted-dos

Attempted denial-of-service attack

attempted-recon

Attempted information collection (reconnaissance)

   

bad-unknown

Potentially bad traffic seen (malformed)

denial-of-service

Denial-of-service attack possibly underway

misc-attack

A catch-all category

non-standard-protocol

Detection or use of a nonstandard protocol

rpc-portmap-decode

Portmap decode detected

successful-dos

Denial of service detected

successful –recon- largescale

Large-scale information collection (reconnaissance)

successful –recon- limited

Limited information collection (reconnaissance)

suspicious-filename- detect

Strange or unusual filename was detected

suspicious-login

Strange username was found attempting to login

suspicious-call-detect

System call was detected

unusual-client-port- connection

A client was abnormally using a network port

web-application- activity

Access was made to a potentially vulnerable web-app

Table 8-4: Priority 3 Classifications (Low Severity)

classtype

Description

icmp-event

A “ping” packet was detected

misc-activity

Some behavior was detected that may be considered a policy warning

network-scan

A host or network was being scanned

non-suspicious

Regular usage activity was detected

protocol-command-decode

A protocol instruction was decoded

string-detect

A pattern of specific bytes was detected

unknown

Unknown or unclassified traffic

Revision and versions

The Snort people thought ahead and even included a way to keep a version tracking on each individual rule. The software industry uses many version management schemes because the field is so fluid and so dynamic that tight change control is almost a necessity. The format of the option is

rev:<#>;

 Technical stuff  Very few rules that come with Snort (less than 10 percent) have a revision number of only 1. Busy enterprise networks are sometimes hostile and fast-paced environments. Sometimes, rules are quickly added during the heat of a malicious event so that immediate visibility is provided to the security managers who must monitor the attack. After some analysis and a firmer understanding of the events takes shape, Snort’s rules are then revised (often only subtly) to reflect what’s known about the event.

Messaging and output

The mesg option creates a customized output message that can be included with any logs, alerts, and data dumps processed by the detection engine. By looking through the rules directory, you can see that the fabricators of the rules file have added messages to almost all the entries that they include. The following is an example of the format of the mesg directive in use:

alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 (msg:"SMTP sendmail 5.5.5
 exploit"; flow:to_server,established; content:"mail from|3a20227c|"; nocase; 
reference:arachnids,119; classtype:attempted-admin; sid:662; rev:4;)

See how cleverly the Snort makers had the output of this mail exploit attempt reported as “SMTP sendmail 5.5.5 exploit”? Describing the nature of an attack in plain English helps you in the long run (especially when you’re searching through logs at trying to track down a breach).

External references

The second most powerful (and widely used) feature within a Snort rule is the external reference option. You can reference Web-based resources that provide you with tons of additional data on an attack or probe right in the Snort logs.

A few different formats are used. Nearly all are Web site front-ends that look up an attack based on a unique identifier. For example, using the example in the preceding section, we find the following: reference:arachnids,119;

Thanks to this command, when Snort encounters this Sendmail attack, it provides a URL where the user can find out more about the Sendmail attack. Table 8-5 gives a list of Snort’s external references.

Table 8-5: Snort’s External References

Keyword

URL Base

bugtraq

http://www.securityfocus.com/bid/

cve

http://cve.mitre.org/cgi-bin/cvename.cgi?name=

arachNIDS

http://www.whitehats.com/info/IDS

McAfee

http://vil.nai.com/vil/content/v_

Nessus

http://cgi.nessus.org/plugins/dump.php3?id=

url

http:// (a general URL that’s passed straight through)

Proper use of the external keyword takes this form:

Reference: <SYSTEM> <VALUE>

 Technical Stuff  You can tie together any number of reference options as long as they’re separated by a semicolon.

Advanced options and deep dark secrets

The advanced options give you a peek into the dark side: the stuff of the geek-chic and the wizards of computer security.

Flow control

The flow control option lets you define the direction of a network stream. All network communications have two endpoints and a direction, so Snort can be configured to alert whenever one of many other triggers is tripped. Snort’s internal engine must do some fancier processing for the flow control (including some on-the-fly packet reconstruction), but it’s certainly worth the overhead because it lets you know whether an attack actually worked or not.

Regular expressions

A regular expression (regex in computer-nerd circles) is the incredibly powerful voodoo of using wildcards to match substrings within other strings. Without jumping into the deep end of this black art, a regular expression combined with a Snort rule makes for powerful mojo!

Protocol options

Because of Snort’s primary function to act as a low-level packet trap and filtering device, it can make lots of specific selections based on granular network protocol components. For example, sometimes hackers use specialized or fragmented packets to tease at the edge of networks for information about what they may find if they break in. These probing and recon expeditions may otherwise go unnoticed by a system administrator or a security package not configured to watch for such errant behavior. Snort’s native IP rules options put a huge amount of power at your fingertips.

How does Snort deal with all those rules?

Managing the files and their contents, let alone keeping a huge decision tree running, is a fine programmatic accomplishment.

Snort keeps track of all those intricate rules (some with more than 20 different options) with some fancy data processing internally. Without getting too bogged down, the process of reading in a particular rule is governed by a string parser, which cuts apart the rule into its component parts, which are then stored into a series of linked lists.

 Remember  Snort is a busy, complex, and low-level application. Every small or subtle error that goes undetected or that causes minor annoyances can snowball into a huge performance issue under certain circumstances. Although it doesn’t happen often, a misplaced command or configuration option can cause downtime or data loss.

'IT' 카테고리의 다른 글

[4] Snort Configuration: preprocessing punk packets : preprocessor  (0) 2008.10.14
[3] Snort Configuration : Refinement  (1) 2008.10.14
Snort Configuration [1]  (0) 2008.10.14
Snort Location  (0) 2008.10.14
Snort Installation on CentOS 4.6  (0) 2008.10.10
Posted by CEOinIRVINE
l

Snort Installation on CentOS 4.6

IT 2008. 10. 10. 08:20


php test : download http://shat.net/php/nqt/nqt.php.txt.
copy this file under /var/www/html
visit http://yourwebsite

if you see network query tool window and execute some command over there, your php works fine.


cd /root
mkdir snortinstall


!!!DO THE FOLLOWING AS ROOT!!!
download your snort
wget http://www.snort.org/dl/snort-2.8.3.1.tar.gz
install PCRE from source
wget http://downloads.sourceforge.net/pcre/pcre-7.8.tar.gz?modtime=1220617433&big_mirror=0
 
tar xvzf pcre-7.8.tar.gz
cd pcre-7.8
./configure
make
make install

cd back to your snortinstall dir
tar xvzf snort-2.8.3.1.tar.gz
cd snort-2.8.3.1
./configure --with-mysql --enable-dynamicplugin --with-libpcap-libraries=/usr/lib64 --with-libpcre-libraries=/usr/lib64 --with-libnet-libraries=/usr/lib64 --enable-stream4udp --enable-dynamicplugin LDFLAGS='-L/usr/lib64 -L/usr/lib64 -L/usr/lib64 -L/usr/lib64/mysql'

make
make install


groupadd snort
useradd -g snort snort -s /sbin/nologin


mkdir /etc/snort
mkdir /etc/snort/rules
mkdir /var/log/snort

cd /etc
cp * /etc/snort
wget http://www.snort.org/pub-bin/downloads.cgi/Download/vrt_pr/snortrules-pr-
2.4.tar.gz
or just download my previous uploaded snortrules-snapshot-2.8.tar.gz


tar xvzf snortrules-pr-2.4.tar.gz
or tar xvzf snortrules-snapshot-2.8.tar.gz


cd to rules and do the following command
cp -R * /etc/snort/rules


Modify your snort.conf file



edit snort.conf under /etc/snort by using vi or any other editor

change followings

var HOME NET 10.0.0.0/8 (for example)
var EXTERNAL_NET !$HOME_NET

var RULE_PATH ../rules to var RULE_PATH /etc/snort/rules

add or edit as followings
preprocessor stream5_global: max_tcp 8192, track_tcp yes, \
                             track_udp yes
preprocessor stream5_tcp: policy windows, use_static_footprint_sizes, \
                                                  ports client 21 23 25 42 53 80 135 136 137 139 143 110 111 445 465 513 691 1433 1521 2100 2301 3128 3306 8000 8080 8180 8888
preprocessor stream5_udp: ignore_any_rules


also, you need to tell snort to log to MySQL

output database: log, mysql, user=snort password=<the password you gave it>
dbname=snort host=localhost



cd /etc/init.d
wget http://internetsecurityguru.com/snortinit/snort/index.html
mv index.html snort
chmod 755 snot
chkconfig snort on

mysql -p
passwd:
(default: whatever password you wawnt to give it, remember what you assign.)


mysql
mysql> SET PASSWORD FOR root@localhost=PASSWORD('password');
>Query OK, 0 rows affected (0.25 sec)
mysql> create database snort;
>Query OK, 1 row affected (0.01 sec)
mysql> grant INSERT,SELECT on root.* to snort@localhost;
>Query OK, 0 rows affected (0.02 sec)
mysql> SET PASSWORD FOR snort@localhost=PASSWORD('password_from_snort.conf');
>Query OK, 0 rows affected (0.25 sec)
mysql> grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort.* to snort@localhost;
>Query OK, 0 rows affected (0.02 sec)
mysql> grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort.* to snort;
>Query OK, 0 rows affected (0.02 sec)
mysql> exit
>Bye

mysql -u root -p < ~/snortinstall/snort-2.4.3/schemas/create_mysql snort
Enter password: the mysql root password
mysql -p
>Enter password:
mysql> SHOW DATABASES;
(You should see the following)
+------------+
| Database
+------------+
| mysql
| Snort
| test
+------------+
3 rows in set (0.00 sec)

mysql> use snort
>Database changed
mysql> SHOW TABLES;
+------------------+
| Tables_in_snort
+------------------+
| data
| detail
| encoding
| event
| icmphdr
| iphdr
| opt
| reference
| reference_system
| schema
| sensor
| sig_class
| sig_reference
| signature
| tcphdr
| udphdr
+------------------+
16 rows
exit;




BASE-Install

yum install php-gd
It will ask you the following, choose Y
Transaction Listing:
Install: php-gd.i386 0:4.3.10-3.2
Is this ok [y/N]: y

download adodb
wget http://downloads.sourceforge.net/adodb/adodb505.tgz?modtime=1215766049&big_mirror=0

adodb505.tga

download attached above base file


cd /etc/sysconfig/
edit the iptables file
add the line “-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j
ACCEPT
And delete the lines:
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
Then change the line :
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
To :
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j REJECT
Then you will only be able to get to the site with HTTPS:// the reason you want to do this
is so you do not trigger more alerts from you reading alerts, and if something is able to be
encrypted then I usually do.
Then execute the command “service iptables restart” and you will see something like tee following:
[root@snort conf]# service iptables restart
Flushing firewall rules: [ OK ]
Setting chains to policy ACCEPT: filter [ OK ]
Unloading iptables modules: [ OK ]
Applying iptables firewall rules: [ OK ]
Then it will look like this when you do an “iptables –L”


Installing Adodb:
Go back to your download directory (~/snortinstall)
cp adodb462.tgz /var/www/
cd /var/www/
tar -xvzf adodb462.tgz
rm –rf adodb462.tgz

Go back to your download directory (~/snortinstall)
cp base-1.2.5.tar.gz /var/www/html
cd /var/www/html
tar xvzf base-1.2.5.tar.gz
rm -rf base-1.2.5.tar.gz
mv base-1.2.5 base

cd /var/www/html/base
cp base_conf.php.dist base_conf.php

edit the "base_conf.php" file and insert the following perimeters



$BASE_urlpath = "/base";
$DBlib_path = "/var/www/adodb/ ";
$DBtype = "mysql";
$alert_dbname = "snort";
$alert_host = "localhost";
$alert_port = "";
$alert_user = "snort";
$alert_password = "password_from_snort_conf";
/* Archive DB connection parameters */
$archive_exists = 0; # Set this to 1 if you have an archive DB


Now, go to a browser and access your sensor.
NOW: “chkconfig snort on” to make snort starts with the system
then type service snort start. It should give you an OK
https://<ip.address>/base
This will bring up the initial BASE startup banner.
Securing APACHE and the BASE directory:
mkdir /var/www/passwords
/usr/bin/htpasswd -c /var/www/passwords/passwords base
(base will be the username you will use to get into this directory, along with the password
you choose)
It will ask you to enter the password you want for this user, this is what you will have to
type when you want to view your BASE page
Edit the httpd.conf (/etc/httpd/conf). I put it under the section that has:
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
These are the lines you must add to password protect the BASE console, add it to
the httpd.conf file in /etc/httpd/conf/:

<Directory "/var/www/html/base">
AuthType Basic
AuthName "SnortIDS"
AuthUserFile /var/www/passwords/passwords
Require user base
</Directory>
Since you have removed the port 80 entry in the iptables script you will have to go to the
console on port 443, using HTTPS:/<ip_address>/base
Save the file and restart Apache by typing “service httpd restart” to make the password
changes effective.
After you’re done
Login as root and check everything important to see if it is running.
To check you can execute “ps –ef |grep <SERVICE>” where service is snort. httpd, or
mysql.
Or use “ps –ef |grep httpd && ps –ef |grep mysql && ps –ef |grep Snort”




or visit http://www.howtoforge.com/intrusion_detection_base_snort



'IT' 카테고리의 다른 글

Snort Configuration [1]  (0) 2008.10.14
Snort Location  (0) 2008.10.14
Apple's Brick: A Radical New Laptop?  (0) 2008.10.07
Samsung's Superior Series 6 LCD TV  (0) 2008.10.05
Tech Addicts  (0) 2008.10.04
Posted by CEOinIRVINE
l