Call now: (800) 766-1884  



 Home


 SQL Server Tips
 SQL Server Training

 SQL Server Consulting
 SQL Server Support
 SQL Server Remote DBA



 Articles
 Services
 SQL Server Scripts
 Scripts Menu



 

 

 

   
  SQL Server Tips by Gama and Naughter


 

Snort

 

Snort is used mostly as a network intrusion detection system (NIDS) but it can be configured to run as a packet sniffer. It can run in two different modes as a sniffer: which reads the packets onto the console or packet logger: which captures all packets to disk.

 

Snort is a very effective network intrusion detection system; its strength relies on preprocessors and rules. Preprocessors are plug-ins that can detect certain patterns such as a multiple port scan or data fragmented in order to defeat the rules; they can also format the data packets before being matched against the rules. Rules are read into chains and then matched against all packets.

 

There are two sections in a rule, the first one is the rule header, describing the action, protocol and source IP address and port and corresponding destination. Next is the rule options which consists of an informative message and other meta-data options plus optional and configurable payload, non-payload options and post-detection options.

You can download Snort: from http://www.snort.org/dl/. For simplicity let us assume that Snort is installed in the default “C:\Snort” folder. A folder is necessary to store captured packets, for example a folder named “tmp” under “C:\Snort”.

 

For this test, a file should be created in the “rules” directory named _test.rules. A plain test file is ok. The first thing to do for testing a rule is to see if Snort accepts it or generates an error message. In the “etc” directory there is a file named snort.conf that contains all the configuration settings like configuring output to a database, etc. At the bottom there is a list of included rules, # is a comment. This is where to add include $RULE_PATH/_test.rules to the top of that list so that Snort will load it when restarted.

 

In snort.conf it is a good idea to change the HOME_NET variable, which contains the network mask for the local network, with the current network mask.

 

Original:

 

#Home network

var HOME_NET any

 

Replace with:

 

#Home network

var HOME_NET 10.0.0.0/24

 

10.0.0.0/24 or whatever the network mask is.

 

The /24 terminology is equivalent to 255.255.255.0, just count the set bits from the left (8+8+8=24). This will avoid some false positives because some rules fire when certain traffic has an exterior source or destination but "any" will not allow such distinction.

 

Snort can run as a service but for this test it is easier to run it in console mode, it's faster to start and stop and the output is immediate. Checking the output from files or a database requires more work and time.

 

This is how to run Snort in console mode (from snort\bin):

 

snort -c ..\etc\snort.conf -l ..\tmp -A console

 

The -c switch specifies the file name and path of the configuration file, -l defines the location of the temporary folder and -A is the alert mode.

 

Let us create an UDP packet with source 10.0.0.175, port 43981, destination 10.0.0.250, port 80 and the data Hello\0\0\0.

 

IPv4 header

4

5

0

0

0

0

2

4

1

F

B

3

0

0

0

0

Version

IHL

TOS

Total length

Identification

Flags

(3_bits)

Fragment offset

2

E

1

1

5

7

6

E

0

A

0

0

0

0

A

F

TTL

Protocol

Header checksum

Source IP address

0

A

0

0

0

0

F

A

 

Destination IP address

 

UDP header

A

B

C

D

0

0

5

0

0

0

1

0

1

A

3

6

Source Port

Destination Port

Length

Checksum

4

8

6

5

6

C

6

C

6

F

0

0

0

0

0

0

H

e

l

l

O

0

0

0

 

Table 24.3 – UDP packet structure

 

XP_RAWIP can immediately create this packet:

 

EXEC XP_RAWIP 450000241FB300002E11576E0A0000AF0A0000FAABCD

005000101a3648656C6C6F000000

 

In _test.rules the following should be typed in one line or more than one line with \ at the end of each line:

 

alert udp any any -> any any (msg:"UDP Hello packet

detected!"; content:"Hello"; classtype:string-detect;

sid:1234567; rev:1;)

 

In this example the rule is in one single line of text and line terminators “\” are not necessary, for simplicity.

After starting Snort and executing XP_RAWIP this is the result:

 

09/24-11:48:13.591786  [**] [1:1234567:1] UDP Hello

packet detected! [**] [Classification: A suspicious string was detected] [Priority: 3] {UDP} 10.0.0.175:43981 -> 10.0.0.250:80

 

This output is proof that the rule works fine.

 

A similar packet but ICMP:

 

EXEC XP_RAWIP 4500003c750400008001b02f0A0000AF0A0000FA

0800cd2d0200050048656c6c6f

 

IPv4 header

4

5

0

0

0

0

3

C

7

5

0

4

0

0

0

0

Version

IHL

TOS

Total length

Identification

Flags

(3_bits)

Fragment offset

8

0

0

1

B

0

2

F

0

A

0

0

0

0

A

F

TTL

Protocol

Header checksum

Source IP address

0

A

0

0

0

0

F

A

 

Destination IP address

 

ICMP header

0

8

0

0

C

D

2

D

0

2

0

0

0

5

0

0

Type

Code

ICMP header checksum

4

8

6

5

6

C

6

C

6

F

 

H

e

l

l

o

 

 

Table 24.4 – IP v4 packet structure

 

This would be the rule to detect it:

 

alert icmp any any -> any any (msg:"ICMP Hello packet detected!"; content:"Hello"; classtype:string-detect; sid:1234567; rev:1;)

 

And the result:

 

09/24-11:54:43.184653  [**] [1:1234567:1] ICMP Hello packet detected! [**] [Classification: A suspicious string was detected] [Priority: 3] {ICMP} 10.0.0.175 -> 10.0.0.250


The above book excerpt is from:

Super SQL Server Systems
Turbocharge Database Performance with C++ External Procedures

ISBN: 0-9761573-2-2
Joseph Gama, P. J. Naughter

 http://www.rampant-books.com/book_2005_2_sql_server_external_procedures.htm
 

 

Burleson Consulting Remote DB Administration


 

 


 

 

 

 

 
Burleson is the America's Team

Note: The pages on this site were created as a support and training reference for use by our staff of DBA consultants.  If you find it confusing, please exit this page.

Errata?  SQL Server technology is changing and we strive to update our SQL Server support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:and include the URL for the page.
 


Burleson Consulting
SQL Server database support

 

Copyright © 1996 -  2013 by Vaaltech Web Services. All rights reserved.

Hit Counter