[Snort-devel] memory leak or .. ?

Pascal Bouchareine pb at ...858...
Wed Oct 3 05:45:13 EDT 2001


Hi,

Love your thingie. It's running almost very fine on a distributed
sensors architecture and handles totally around 200Mb/s of traffic
with great results.

However, I have some noticeable problems with it :)

First, i use some of snort's rules to handle "flux enforcement". This is,
i have a *lot* of ip addresses/classes and the like, put in some variables,
and i have rules such as:

alert tcp !$MYSQL 3306 -> any any (msg: "new mysql 3 server"; \
                   flags: A+; content: "|2e 00 00 00 0a 33 2e|"; offset: 0; \
                   depth: 7; classtype: policy;)

I had to "patch" snort to be able to handle very-long-lines (>1024 chars)
and very-long-variables (>256 IIRC). I did as in [1]. I though maybe you
would like to know.


My second problem is a bit complicated for me. Snort eats around 2/4k of memory
per second, which sounds normal since you are caching data, but at some point,
it comes out with:

Oct  2 11:01:02 snoop3 snort: Ran out of space 
Oct  2 11:01:02 snoop3 snort: Ran out of space 
Oct  2 11:01:02 snoop3 snort: Got NULL *froot in ReassembleIP(), please tell Dragos 


Oops. I'm guessing this is my fault - but i want to be sure. The system handles
around 80Mb/s on the following configuration:

Bi intel pIII-800 (some va-linux hw), FreeBSD 4.2-RELEASE, 512Mb of RAM.
Snort is 1.8.1-RELEASE, the preprocessors are configured as follow:

preprocessor defrag
preprocessor stream4: detect_scans, noinspect
preprocessor stream4_reassemble: clientonly, ports 21 23 25 53 80 110 111 143
preprocessor telnet_decode
preprocessor http_decode: 80 -unicode
preprocessor rpc_decode: 111
preprocessor bo: -nobrute
 
Which, IIRC, should be able to handle 65535 simultaneous TCP flows, not
more - is the Ran out of space is linked to this fact ?

With the stream2 preprocessor, i had the same kind of memory problem but
it ended up dumping core - If you want me to, i can send you the 
"ldd/bt/disas $pc" analysis of the core produced by a -g compiled binary.

Sorry for that long email, if you need any more testings on this case,
i'm totally available.

(i'm attaching the test rules/config we're currently using with snort)

[1 - patch for snort to handle long variables]
<diff -u>
--- snort-1.8.1-RELEASE/rules.c Wed Aug 15 07:54:35 2001
+++ snort-1.8.1-RELEASE-new/rules.c     Mon Sep 17 16:24:01 2001
@@ -67,6 +67,7 @@
 int cmpcount;           /* compare counter */
 #endif
 
+#define STD_BUF 32768
 
 /****************************************************************************
  *
@@ -2036,7 +2037,7 @@
         enbracket = strrchr(tmp, (int)']'); /* null out the en-bracket */
         if(enbracket) *enbracket = '\x0';
 
-        toks = mSplit(tmp+1, ",", 128, &num_toks, 0);
+        toks = mSplit(tmp+1, ",", 512, &num_toks, 0);
 
 #ifdef DEBUG
         printf("mSplit got %d tokens...\n", num_toks);
</diff>


-- 
Kalou.
              You must run this as root or "chmod 666 /dev/mem"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rules.tgz
Type: application/x-tar-gz
Size: 3392 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20011003/e2e2a1a9/attachment.bin>


More information about the Snort-devel mailing list