[Snort-users] Getting alerts for every file Snort detects and File Services preprocessor

Pablo Cantos Polaino pcantos at ...16842...
Thu Apr 16 10:52:45 EDT 2015


Hi Victor,

I hope you're doing well.

I've found the reason:

###################################################
# Per packet and rule latency enforcement
# For more information see README.ppm
###################################################

# Per Packet latency configuration
config ppm: max-pkt-time 150, \
   fastpath-expensive-packets
   #pkt-log

# Per Rule latency configuration
config ppm: max-rule-time 100, \
   threshold 3, \
   suspend-expensive-rules, \
   suspend-timeout 20

I was using this configuration above in my snort.conf. This explains the
alert drops in a non deterministic number.

Best Regards,

Pablo Cantos
redborder.org / pcantos at ...16842...

2015-04-09 13:59 GMT+02:00 Pablo Cantos Polaino <pcantos at ...16842...>:

> Sure, here they are:
>
> pcap:
> http://download.netresec.com/pcap/maccdc-2012/maccdc2012_00001.pcap.gz
> snort.conf: (If you don't mind, I will attach you in a separated mail)
>
> Best Regards,
>
> Pablo Cantos
> redborder.org / pcantos at ...16842...
>
> 2015-04-08 19:04 GMT+02:00 Victor Roemer <viroemer at ...589...>:
>
>> Pablo, can you send me a pcap and the snort.conf(s) that show the
>> inconsistent alert count?
>>
>>
>> On 04/07/15 5:36, Pablo Cantos Polaino wrote:
>>
>>> Hi Victor,
>>>
>>> I've tried it again after configuring max_queue 100 and log 100 and
>>> adding
>>> the flag "-H", getting the same result. I still get a volatile number of
>>> alerts less than the total number of detected files.
>>>
>>> In any case, and please tell me if I'm wrong, since I'm just using 10
>>> rules
>>> and, in our test, is highly unlikely that more than one rule could affect
>>> one single packet (a packet wouldn't contain more than one file), I think
>>> maybe altering the "event_queue" configurable options wouldn't change
>>> anything here.
>>>
>>> If we don't manage to solve this issue related to the number of alerts,
>>> we
>>> will disable the signature and capture options and use the preprocessor,
>>> and just in case we will need signature or capture options we will try to
>>> do a workaround to not lose any functionality.
>>>
>>> Thanks for your help!
>>>
>>> Best Regards,
>>>
>>> Pablo Cantos
>>> redborder.org / pcantos at ...16842...
>>>
>>> 2015-04-02 9:52 GMT+02:00 Pablo Cantos Polaino <pcantos at ...16842...>:
>>>
>>>  Thanks Victor! From today I will be out of the office until Monday. I'll
>>>> try it then and let you know!
>>>> El 1/4/2015 16:56, "Victor Roemer" <viroemer at ...589...> escribió:
>>>>
>>>>  Ok, I'm guessing that this is due to internal default's for event_queue
>>>>> and the
>>>>> RNG in rule evaluation ordering.
>>>>>
>>>>> Try adding the following to your snort.conf
>>>>>
>>>>> config event_queue: max_queue 100 log 100
>>>>>
>>>>> and adding the flag "-H" when running Snort.
>>>>>
>>>>>
>>>>> The -H removes the RNG in Snort runtime, so using it in production
>>>>> would
>>>>> not be
>>>>> a good idea; we only use it for testing on our side.
>>>>>
>>>>>
>>>>> On 04/01/15 9:18, Pablo Cantos Polaino wrote:
>>>>>
>>>>>  Hi Victor,
>>>>>>
>>>>>> Since there is no PDF files in my PCAP file, I've tried what you
>>>>>> propose
>>>>>> for the following file types: MSEXE, ZIP, GZ, SWF, GIF, PNG, JPEG, BMP
>>>>>> and
>>>>>> ICO.
>>>>>>
>>>>>> Using the file types below (getting from file_magic.conf) and the
>>>>>> rules
>>>>>> below I've got something quite coherent, but every time
>>>>>> I run snort I get a different number of alerts, lower or equal to the
>>>>>> right
>>>>>> number or files. For instance, there are 566 files inside the PCAP
>>>>>> file
>>>>>> (constant number got from the File preprocessor) and I've got volatile
>>>>>> number of alerts like 558, 556, 557, ...
>>>>>>
>>>>>> File types:
>>>>>> file type:MSEXE; id:21; category:Executables,Dynamic Analysis Capable;
>>>>>> msg:"Windows/DOS executable file "; rev:1; content:| 4D 5A|; offset:0;
>>>>>> file type:ZIP; id:29; category:Archive; msg:"PKZIP archive file";
>>>>>> rev:1;
>>>>>> content:| 50 4B 03 04 |; offset:0;
>>>>>> file type:GZ; id:33; category:Archive; msg:"GZ"; rev:1; content:| 1F
>>>>>> 8B
>>>>>> 08
>>>>>> |; offset:0;
>>>>>> file type:SWF; id:52; category:Multimedia; msg:"Flash file "; rev:1;
>>>>>> content:| 43 57 53 |; offset:0;
>>>>>> file type:GIF; id:62; category:Graphics; msg:"GIF"; rev:1; content:|
>>>>>> 47
>>>>>> 49
>>>>>> 46 38 37 61 |; offset:0; group:multimedia;
>>>>>> file type:GIF; id:63; category:Graphics; msg:"GIF"; rev:1; content:|
>>>>>> 47
>>>>>> 49
>>>>>> 46 38 39 61 |; offset:0; group:multimedia;
>>>>>> file type:PNG; id:69; category:Graphics; msg:"Portable Network
>>>>>> Graphics
>>>>>> file"; rev:1; content:| 89 50 4E 47 0D 0A 1A 0A |; offset:0;
>>>>>> group:multimedia;
>>>>>> file type:JPEG; id:70; category:Graphics; msg:"JPEG/JFIF graphics
>>>>>> file";
>>>>>> rev:1; content:| FF D8 FF E0 |; offset:0; group:multimedia;
>>>>>> file type:BMP; id:148; category:Graphics; msg:"Bitmap image file";
>>>>>> rev:1;
>>>>>> content:|42  4D |; offset:0; group:multimedia;
>>>>>> file type:ICO; id:149; category:Graphics; msg:"Windows icon file";
>>>>>> rev:1;
>>>>>> content:| 00 00 01 00 |; offset:0;
>>>>>>
>>>>>> Rules:
>>>>>> alert tcp any any -> any any (msg:"MSEXE: MZ"; content:"|4D 5A|";
>>>>>> offset:0;
>>>>>> file_type:MSEXE; sid:5000001;)
>>>>>> alert tcp any any -> any any (msg:"ZIP: PK"; content:"|50 4B 03 04|";
>>>>>> offset:0; file_type:ZIP; sid:5000002;)
>>>>>> alert tcp any any -> any any (msg:"GZ: "; content:"|1F 8B 08|";
>>>>>> offset:0;
>>>>>> file_type:GZ; sid:5000003;)
>>>>>> alert tcp any any -> any any (msg:"SWF: "; content:"|43 57 53|";
>>>>>> offset:0;
>>>>>> file_type:SWF; sid:5000004;)
>>>>>> alert tcp any any -> any any (msg:"GIF: GIF87a"; content:"|47 49 46
>>>>>> 38 37
>>>>>> 61|"; offset:0; file_type:GIF; sid:5000005;)
>>>>>> alert tcp any any -> any any (msg:"GIF: GIF89a"; content:"|47 49 46
>>>>>> 38 39
>>>>>> 61|"; offset:0; file_type:GIF; sid:5000006;)
>>>>>> alert tcp any any -> any any (msg:"PNG: "; content:"|89 50 4E 47 0D
>>>>>> 0A 1A
>>>>>> 0A|"; offset:0; file_type:PNG; sid:5000007;)
>>>>>> alert tcp any any -> any any (msg:"JPEG: "; content:"|FF D8 FF E0|";
>>>>>> offset:0; file_type:JPEG; sid:5000008;)
>>>>>> alert tcp any any -> any any (msg:"BMP: "; content:"|42 4D|";
>>>>>> offset:0;
>>>>>> file_type:BMP; sid:5000009;)
>>>>>> alert tcp any any -> any any (msg:"ICO: "; content:"|00 00 01 00|";
>>>>>> offset:0; file_type:ICO; sid:5000010;)
>>>>>>
>>>>>> If I use the rules below (going through the File preprocessor) I
>>>>>> always
>>>>>> get
>>>>>> the same number of alerts that's equal to the number of files (566).
>>>>>>
>>>>>> alert (msg: "MSEXE file"; gid:146; sid:21;)
>>>>>> alert (msg: "ZIP file"; gid:146; sid:29;)
>>>>>> alert (msg: "GZ file"; gid:146; sid:33;)
>>>>>> alert (msg: "SWF file"; gid:146; sid:52;)
>>>>>> alert (msg: "GIF(62) file"; gid:146; sid:62;)
>>>>>> alert (msg: "GIF(63) file"; gid:146; sid:63;)
>>>>>> alert (msg: "PNG file"; gid:146; sid:69;)
>>>>>> alert (msg: "JPEG file"; gid:146; sid:70;)
>>>>>> alert (msg: "BMP file"; gid:146; sid:148;)
>>>>>> alert (msg: "ICO file"; gid:146; sid:149;)
>>>>>>
>>>>>> I've also tried to detect just one type of files and the results are
>>>>>> similar, when I use the way I get a volatile number of alerts, but I
>>>>>> manage
>>>>>> to get the same number of alerts if I follow the second way.
>>>>>>
>>>>>> To us the second way is more reliable since we don't want to skip any
>>>>>> file
>>>>>> detected by File preprocessor. On the other hand, we have also
>>>>>> managed to
>>>>>> log these alerts to unified2, so this would not be a disadvantage.
>>>>>>
>>>>>>  Ok, for some reason I believed that u2 logging would be possible.
>>>>>
>>>>> If you would like to use the preprocessor events that is fine; but as
>>>>> you've already identified, the
>>>>> file type events do not work when signature or capture is enabled.
>>>>> Until
>>>>> we fix that, you'd have
>>>>> to resolve that in your own version of the file_inspect preprocessor or
>>>>> wait for us to address it.
>>>>> (The bug was written, but is currently unknown when we will work on it)
>>>>>
>>>>>   Best Regards,
>>>>>
>>>>>> Pablo Cantos
>>>>>> redborder.org / pcantos at ...16842...
>>>>>>
>>>>>> 2015-03-31 17:54 GMT+02:00 Victor Roemer <viroemer at ...589...>:
>>>>>>
>>>>>>   Pablo,
>>>>>>
>>>>>>> Yes, your right. Flowbits apply per-session so the rule would only be
>>>>>>> capable of alerting 1x (per-session).
>>>>>>>
>>>>>>> In that case, you could also just do a rule like so:
>>>>>>>
>>>>>>> file type:PDF; content:|25 50 44 46 2d|; offset:0; id:1;
>>>>>>> alert tcp any any -> any any (msg:"PDF"; content:"%PDF-"; offset:0;
>>>>>>> file_type:PDF; sid:1000002;)
>>>>>>>
>>>>>>> What I've done is removed the flowbits and added offset:0; from the
>>>>>>> previous rule. By matching
>>>>>>> the content that triggers the file rule to identify PDF, this rule
>>>>>>> should
>>>>>>> alert on the start of every
>>>>>>> PDF file seen.
>>>>>>>
>>>>>>> On 03/31/15 7:19, Pablo Cantos Polaino wrote:
>>>>>>>
>>>>>>>   Hi Victor,
>>>>>>>
>>>>>>>> We already thought about using flowbits, but (and please correct me
>>>>>>>> if
>>>>>>>> I'm
>>>>>>>> wrong) we didn't considered it effective since once a bit is set
>>>>>>>> after
>>>>>>>> detecting a file, this rule will never trigger any alert. I've
>>>>>>>> launched
>>>>>>>> some tests following your proposals and the numbers I got are not
>>>>>>>> much
>>>>>>>> coherent. For these tests I've used a capture with 107 GIF files
>>>>>>>> inside.
>>>>>>>> The file preprocessor is able to detect these 107 files and below
>>>>>>>> you
>>>>>>>> could
>>>>>>>> find the number of alerts I get using the following rules:
>>>>>>>>
>>>>>>>> Rules:
>>>>>>>> alert (msg: "GIF(62) file"; gid:146; sid:62;)
>>>>>>>> alert (msg: "GIF(63) file"; gid:146; sid:63;)
>>>>>>>> Number of alerts: 107
>>>>>>>>
>>>>>>>> Rule:
>>>>>>>> alert tcp any any -> any any (msg: "GIF file"; file_type:GIF;
>>>>>>>> sid:3000011;
>>>>>>>> rev:1;)
>>>>>>>> Number of alerts: 111 (4 alerts more than the number of files
>>>>>>>> detected.
>>>>>>>> Possibly due to one or more than one file takes up one or more
>>>>>>>> packet)
>>>>>>>>
>>>>>>>> Rule:
>>>>>>>> alert tcp any any -> any any (msg: "GIF file";
>>>>>>>> flow:to_client,established;
>>>>>>>> file_type:GIF; sid:3000013; rev:1;)
>>>>>>>> Number of alerts: 24 (much less alerts than the number of files
>>>>>>>> detected.
>>>>>>>> Possibly due to the direction flow, but as you can see below,
>>>>>>>> adding 24
>>>>>>>> and
>>>>>>>> 25 we don't get the total number of files)
>>>>>>>>
>>>>>>>> Rule:
>>>>>>>> alert tcp any any -> any any (msg: "GIF file";
>>>>>>>> flow:to_server,established;
>>>>>>>> file_type:GIF; sid:3000014; rev:1;)
>>>>>>>> Number of alerts: 25
>>>>>>>>
>>>>>>>> Rule:
>>>>>>>> alert tcp any any -> any any (msg: "GIF file flowbits";
>>>>>>>> flowbits:isnotset,gif; file_type:GIF; flowbits:set,gif; sid:4000011;
>>>>>>>> rev:1;)
>>>>>>>> Number of alerts: 2
>>>>>>>>
>>>>>>>> Rule:
>>>>>>>> alert tcp any any -> any any (msg: "GIF file flowbits";
>>>>>>>> flowbits:isnotset,gif; flow:to_client,established; file_type:GIF;
>>>>>>>> flowbits:set,gif; sid:4000013; rev:1;)
>>>>>>>> Number of alerts: 20
>>>>>>>>
>>>>>>>> Rule:
>>>>>>>> alert tcp any any -> any any (msg: "GIF file flowbits";
>>>>>>>> flowbits:isnotset,gif; flow:to_server,established; file_type:GIF;
>>>>>>>> flowbits:set,gif; sid:4000014; rev:1;)
>>>>>>>> Number of alerts: 20
>>>>>>>>
>>>>>>>> As you can see, just using the two first rules which employ directly
>>>>>>>> the
>>>>>>>> File preprocessor (rules with gid:146) gives us just one alert per
>>>>>>>> file,
>>>>>>>> and this is what we are interested in. This way we can be sure that,
>>>>>>>> through the alerts, we are getting information from every file
>>>>>>>> detected in
>>>>>>>> File preprocessor. The only thing we have to put care into is
>>>>>>>> configuring
>>>>>>>> properly the preprocessor like this below:
>>>>>>>>
>>>>>>>> preprocessor file_inspect: type_id
>>>>>>>>
>>>>>>>> and await the related bug could be fixed.
>>>>>>>>
>>>>>>>> In a previous mail you said "The "file_identify" preprocessor is
>>>>>>>> designed
>>>>>>>> to work more as a "reputation" based system. I think you will get
>>>>>>>> better
>>>>>>>> millage by using the new "file_type" rule keyword in a plain-old
>>>>>>>> snort
>>>>>>>> rule". Our conclusion is quite opposite to your recommendation,
>>>>>>>> whose
>>>>>>>> grounds we didn't understand, I mean, why is preferable using the
>>>>>>>> file_type
>>>>>>>> keyword in a plain-old snort rule instead of using a rule with
>>>>>>>> gid:146?
>>>>>>>>
>>>>>>>> I hope I explained my self.
>>>>>>>>
>>>>>>>>   * Because it doesn't work the way you want it to is 'one' reason.
>>>>>>>>
>>>>>>> * Text rules are more managable and less error prone than custom
>>>>>>> preprocessors.
>>>>>>> * You can take advantage of logging to unified2 vs the one-the-side
>>>>>>> mechanism currently employed
>>>>>>>      by the file preprocessor.
>>>>>>>
>>>>>>> But specifically, your intentions were not known to me when I sent
>>>>>>> that. :/
>>>>>>>
>>>>>>>
>>>>>>>   Best Regards,
>>>>>>>
>>>>>>>> Pablo Cantos
>>>>>>>> redborder.org / pcantos at ...16842...
>>>>>>>>
>>>>>>>> 2015-03-30 19:22 GMT+02:00 Victor Roemer <viroemer at ...589...>:
>>>>>>>>
>>>>>>>>    The solution too the "too many alerts" can be resolved with the
>>>>>>>>
>>>>>>>>  application of "flowbits".
>>>>>>>>>
>>>>>>>>> For example:
>>>>>>>>>
>>>>>>>>> file type:PDF; content:|25 50 44 46 2d|; offset:0; id:1;
>>>>>>>>> alert tcp any any -> any any (msg:"PDF"; flowbits:isnotset,pdf;
>>>>>>>>> file_type:PDF; flowbits:set,pdf; sid:1000000;)
>>>>>>>>>
>>>>>>>>> However, it is also recommended that you add a "content" option too
>>>>>>>>> the
>>>>>>>>> rule so that you may take advantage of the fast pattern matcher.
>>>>>>>>> This may seem odd, but it will be faster. In the next rule, the
>>>>>>>>> content
>>>>>>>>> being matched "mirrors" the content in the "file" rule above
>>>>>>>>> exactly.
>>>>>>>>>
>>>>>>>>> alert tcp any any -> any any (msg:"PDF"; flowbits:isnotset,pdf;
>>>>>>>>> content:"%PDF-"; file_type:PDF; flowbits:set,pdf; sid:1000001;)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ~Victor
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 03/30/15 5:53, Pablo Cantos Polaino wrote:
>>>>>>>>>
>>>>>>>>>    Hi Victor,
>>>>>>>>>
>>>>>>>>>  First of all, thanks for your reply!
>>>>>>>>>>
>>>>>>>>>> Regarding your proposal below:
>>>>>>>>>>
>>>>>>>>>> The "file_identify" preprocessor is designed to work more as a
>>>>>>>>>> "reputation"
>>>>>>>>>>
>>>>>>>>>>    based system. I think you will get better millage by using the
>>>>>>>>>> new
>>>>>>>>>>
>>>>>>>>>>  "file_type" rule keyword in a plain-old snort rule.
>>>>>>>>>>> Something like this:
>>>>>>>>>>> alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"GIF file
>>>>>>>>>>> downloaded";
>>>>>>>>>>> flow:to_client,established; file_type:GIF; sid:1000000;)
>>>>>>>>>>> alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"GIF file
>>>>>>>>>>> downloaded";
>>>>>>>>>>> flow:to_client,established; file_type:PNG; sid:1000001;)
>>>>>>>>>>>
>>>>>>>>>>>    We already tried that and we got a lot of alerts. The sizer
>>>>>>>>>>> the
>>>>>>>>>>> file
>>>>>>>>>>>
>>>>>>>>>>>  is
>>>>>>>>>> the
>>>>>>>>>> more alerts are fired, and this is not the behavior we expected
>>>>>>>>>> since we
>>>>>>>>>> would overpopulate the disk with repeated events. For instance,
>>>>>>>>>> after
>>>>>>>>>> downloading a BZ file with size of 7,5MB, we've got 855 alerts
>>>>>>>>>> from
>>>>>>>>>> one
>>>>>>>>>> just rule:
>>>>>>>>>>
>>>>>>>>>> alert tcp any any -> any any (msg: "BZ file";
>>>>>>>>>> flow:to_client,established;
>>>>>>>>>> file_type:BZ; sid:3000033;)
>>>>>>>>>>
>>>>>>>>>> And we get just one alert if we use the rule below and the
>>>>>>>>>> following
>>>>>>>>>> configuration:
>>>>>>>>>>
>>>>>>>>>> Conf (just type_id, neither signature nor capture)
>>>>>>>>>>
>>>>>>>>>> preprocessor file_inspect: type_id
>>>>>>>>>>
>>>>>>>>>> Rule:
>>>>>>>>>>
>>>>>>>>>> alert (msg: "BZ file"; gid:146; sid:32;)
>>>>>>>>>>
>>>>>>>>>> This is why we discarded some weeks ago the way of writing the
>>>>>>>>>> rule
>>>>>>>>>> as
>>>>>>>>>> you
>>>>>>>>>> proposed now. If it were a way to get just one alert per file it
>>>>>>>>>> would
>>>>>>>>>> be
>>>>>>>>>> great. Meanwhile, we await the bug can be fixed.
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>>
>>>>>>>>>> Pablo Cantos
>>>>>>>>>> redborder.org / pcantos at ...16842...
>>>>>>>>>>
>>>>>>>>>> 2015-03-27 22:46 GMT+01:00 Jaime Nebrera <jnebrera at ...16842...
>>>>>>>>>> >:
>>>>>>>>>>
>>>>>>>>>>     Hi Víctor,
>>>>>>>>>>
>>>>>>>>>>   I'm not that technical ;) Pablo will coment on your ideas, I
>>>>>>>>>> just
>>>>>>>>>>
>>>>>>>>>>> tried
>>>>>>>>>>> to
>>>>>>>>>>> give you a deeper context of what Pablo (as part of my team) was
>>>>>>>>>>> doing
>>>>>>>>>>> but
>>>>>>>>>>> for sure, they are welcomed. I let them continue
>>>>>>>>>>> El 27/03/2015 21:25, "Victor Roemer" <viroemer at ...589...>
>>>>>>>>>>> escribió:
>>>>>>>>>>>
>>>>>>>>>>>     Jamie,
>>>>>>>>>>>
>>>>>>>>>>>   That's neat, I'll keep an eye on it. :)
>>>>>>>>>>>
>>>>>>>>>>>> Reviewing over how the "file_identify" works currently, when
>>>>>>>>>>>> doing
>>>>>>>>>>>> capture or signature
>>>>>>>>>>>> its not possible to also get the file type event via the
>>>>>>>>>>>> preprocessor.
>>>>>>>>>>>> I'll open an bug for this.
>>>>>>>>>>>>
>>>>>>>>>>>> In order to get the file type events with these further
>>>>>>>>>>>> settings,
>>>>>>>>>>>> more
>>>>>>>>>>>> sophisticated tracking
>>>>>>>>>>>> needs to be in-place in the file_identify preproc; the tricky
>>>>>>>>>>>> bits
>>>>>>>>>>>> being
>>>>>>>>>>>> that the file service code
>>>>>>>>>>>> is generating the events in question; however once a verdict is
>>>>>>>>>>>> passed
>>>>>>>>>>>> to
>>>>>>>>>>>> file service- an
>>>>>>>>>>>> action will be taken at that time.
>>>>>>>>>>>>
>>>>>>>>>>>> To clarify the verdicts -
>>>>>>>>>>>> As I understand it, passing FILE_VERDICT_UNKNOWN is how
>>>>>>>>>>>> processing
>>>>>>>>>>>> continues further.
>>>>>>>>>>>> The FILE_VERDICT_PENDING when passed to file service api, should
>>>>>>>>>>>> cause
>>>>>>>>>>>> the packet to be
>>>>>>>>>>>> dropped, in-order to give the interfacing code time to retrieve
>>>>>>>>>>>> a
>>>>>>>>>>>> true
>>>>>>>>>>>> verdict when the re-transmitted
>>>>>>>>>>>> packet is seen.
>>>>>>>>>>>>
>>>>>>>>>>>> On 03/27/15 16:04, Jaime Nebrera wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>     Hi Víctor,
>>>>>>>>>>>>
>>>>>>>>>>>>   Pablo's work is geared towards a more ambitious goal:
>>>>>>>>>>>>
>>>>>>>>>>>>> 1) Intercept the file and send it to a S3 based storage
>>>>>>>>>>>>> platform
>>>>>>>>>>>>> for
>>>>>>>>>>>>> further analysis or whatever
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2) Provide as much context about such interception as possible,
>>>>>>>>>>>>> like
>>>>>>>>>>>>> from
>>>>>>>>>>>>> were to whom, URL, email, etc
>>>>>>>>>>>>>
>>>>>>>>>>>>> This we hope to open source and make it public as soon as it is
>>>>>>>>>>>>> usable
>>>>>>>>>>>>> in
>>>>>>>>>>>>> our repository www.github.com/redborder
>>>>>>>>>>>>> El 27/03/2015 20:50, "Victor Roemer" <viroemer at ...589...>
>>>>>>>>>>>>> escribió:
>>>>>>>>>>>>>
>>>>>>>>>>>>>        Pablo,
>>>>>>>>>>>>>
>>>>>>>>>>>>>    Sorry for the delay. The "file_identify" preprocessor is
>>>>>>>>>>>>> designed to
>>>>>>>>>>>>>
>>>>>>>>>>>>>  work
>>>>>>>>>>>>>> more as a "reputation" based system. I think you will get
>>>>>>>>>>>>>> better
>>>>>>>>>>>>>> millage by
>>>>>>>>>>>>>> using the new "file_type" rule keyword in a plain-old snort
>>>>>>>>>>>>>> rule.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Something like this:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"GIF file
>>>>>>>>>>>>>> downloaded";
>>>>>>>>>>>>>> flow:to_client,established; file_type:GIF; sid:1000000;)
>>>>>>>>>>>>>> alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"GIF file
>>>>>>>>>>>>>> downloaded";
>>>>>>>>>>>>>> flow:to_client,established; file_type:PNG; sid:1000001;)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You'll still need to have "file_magic.conf" included in your
>>>>>>>>>>>>>> Snort
>>>>>>>>>>>>>> configuration, but you will not need the file_identify
>>>>>>>>>>>>>> preprocessor.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ~Victor
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 03/17/15 4:57, Pablo Cantos Polaino wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hello all,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I already sent this issue to snort-devel with the same subject
>>>>>>>>>>>>>> since I
>>>>>>>>>>>>>> am
>>>>>>>>>>>>>> not sure if either I am configuring Snort in the right way or
>>>>>>>>>>>>>> there
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>> an
>>>>>>>>>>>>>> internal malfunction to fix.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have been testing the new experimental preprocessor called
>>>>>>>>>>>>>> File
>>>>>>>>>>>>>> Services
>>>>>>>>>>>>>> in order to get an event every time a file go through our
>>>>>>>>>>>>>> network.
>>>>>>>>>>>>>> To
>>>>>>>>>>>>>> carry
>>>>>>>>>>>>>> on these tests I have used two pcap files. The first one is a
>>>>>>>>>>>>>> 1GB-size
>>>>>>>>>>>>>> pcap
>>>>>>>>>>>>>> with a great number of files and the second one is a short
>>>>>>>>>>>>>> pcap
>>>>>>>>>>>>>> generated
>>>>>>>>>>>>>> on my computer when I downloaded a GIF file.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> My snort.conf file is configured like this at the end:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> include file_magic.conf
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>       preprocessor file_inspect: type_id, signature, \
>>>>>>>>>>>>>>                   capture_queue_size 5000, \
>>>>>>>>>>>>>>                   capture_disk /home/file_capture/tmp/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In both cases files are captured by the preprocessor, as you
>>>>>>>>>>>>>> can
>>>>>>>>>>>>>> see
>>>>>>>>>>>>>> below
>>>>>>>>>>>>>> (1GB pcap output):
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ============================================================
>>>>>>>>>>>>>> ===================
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>       Action Stats:
>>>>>>>>>>>>>>           Alerts:            0 (  0.000%)
>>>>>>>>>>>>>>           Logged:            0 (  0.000%)
>>>>>>>>>>>>>>           Passed:            0 (  0.000%)
>>>>>>>>>>>>>> Limits:
>>>>>>>>>>>>>>            Match:            0
>>>>>>>>>>>>>>            Queue:            0
>>>>>>>>>>>>>>              Log:            0
>>>>>>>>>>>>>>            Event:            0
>>>>>>>>>>>>>>            Alert:            0
>>>>>>>>>>>>>> Verdicts:
>>>>>>>>>>>>>>            Allow:      8418451 ( 97.482%)
>>>>>>>>>>>>>>            Block:            0 (  0.000%)
>>>>>>>>>>>>>>          Replace:            0 (  0.000%)
>>>>>>>>>>>>>>        Whitelist:       217492 (  2.518%)
>>>>>>>>>>>>>>        Blacklist:            0 (  0.000%)
>>>>>>>>>>>>>>           Ignore:            0 (  0.000%)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ============================================================
>>>>>>>>>>>>>> ===================
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ============================================================
>>>>>>>>>>>>>> ===================
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>       File Preprocessor Statistics
>>>>>>>>>>>>>>        Total file type callbacks:            576
>>>>>>>>>>>>>>        Total file signature callbacks:       578
>>>>>>>>>>>>>>        Total files would saved to disk:      574
>>>>>>>>>>>>>>        Total files saved to disk:            320
>>>>>>>>>>>>>>        Total file data saved to disk:        483039    bytes
>>>>>>>>>>>>>>        Total files duplicated:               254
>>>>>>>>>>>>>>        Total files reserving failed:         2
>>>>>>>>>>>>>>        Total file capture min:               0
>>>>>>>>>>>>>>        Total file capture max:               2
>>>>>>>>>>>>>>        Total file capture memcap:            0
>>>>>>>>>>>>>>        Total files reading failed:           0
>>>>>>>>>>>>>>        Total file agent memcap failures:     0
>>>>>>>>>>>>>>        Total files sent:                     0
>>>>>>>>>>>>>>        Total file data sent:                 0
>>>>>>>>>>>>>>        Total file transfer failures:         0
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ============================================================
>>>>>>>>>>>>>> ===================
>>>>>>>>>>>>>> File type stats:
>>>>>>>>>>>>>>               Type              Download   (Bytes)      Upload
>>>>>>>>>>>>>>     (Bytes)
>>>>>>>>>>>>>>                GZ( 33)          2          5580056      0
>>>>>>>>>>>>>>    0
>>>>>>>>>>>>>>               SWF( 52)          1          65991        0
>>>>>>>>>>>>>>    0
>>>>>>>>>>>>>>               GIF( 62)          7          16516        0
>>>>>>>>>>>>>>    0
>>>>>>>>>>>>>>               GIF( 63)          275        151718       0
>>>>>>>>>>>>>>    0
>>>>>>>>>>>>>>               PNG( 69)          266        256724       0
>>>>>>>>>>>>>>    0
>>>>>>>>>>>>>>              JPEG( 70)          2          35566        0
>>>>>>>>>>>>>>    0
>>>>>>>>>>>>>>               BMP(148)          2          4204         0
>>>>>>>>>>>>>>    0
>>>>>>>>>>>>>>               ICO(149)          21         187894       0
>>>>>>>>>>>>>>    0
>>>>>>>>>>>>>>                  Total          576        6298669      0
>>>>>>>>>>>>>>    0
>>>>>>>>>>>>>> File signature stats:
>>>>>>>>>>>>>>               Type              Download   Upload
>>>>>>>>>>>>>>                GZ( 33)          2          0
>>>>>>>>>>>>>>               SWF( 52)          1          0
>>>>>>>>>>>>>>               GIF( 62)          7          0
>>>>>>>>>>>>>>               GIF( 63)          275        0
>>>>>>>>>>>>>>               PNG( 69)          266        0
>>>>>>>>>>>>>>              JPEG( 70)          2          0
>>>>>>>>>>>>>>               BMP(148)          2          0
>>>>>>>>>>>>>>               ICO(149)          21         0
>>>>>>>>>>>>>>                  Total          576        0
>>>>>>>>>>>>>> File type verdicts:
>>>>>>>>>>>>>>              UNKNOWN:           576
>>>>>>>>>>>>>>                  LOG:           0
>>>>>>>>>>>>>>                 STOP:           0
>>>>>>>>>>>>>>                BLOCK:           0
>>>>>>>>>>>>>>               REJECT:           0
>>>>>>>>>>>>>>              PENDING:           0
>>>>>>>>>>>>>>         STOP CAPTURE:           0
>>>>>>>>>>>>>>                Total:           576
>>>>>>>>>>>>>> File signature verdicts:
>>>>>>>>>>>>>>              UNKNOWN:           578
>>>>>>>>>>>>>>                  LOG:           0
>>>>>>>>>>>>>>                 STOP:           0
>>>>>>>>>>>>>>                BLOCK:           0
>>>>>>>>>>>>>>               REJECT:           0
>>>>>>>>>>>>>>              PENDING:           0
>>>>>>>>>>>>>>         STOP CAPTURE:           0
>>>>>>>>>>>>>>                Total:           578
>>>>>>>>>>>>>> Total files processed:             68985
>>>>>>>>>>>>>> Total files data processed:        97156439  bytes
>>>>>>>>>>>>>> Total files buffered:              576
>>>>>>>>>>>>>> Total files released:              574
>>>>>>>>>>>>>> Total files freed:                 2
>>>>>>>>>>>>>> Total files captured:              574
>>>>>>>>>>>>>> Total files within one packet:     561
>>>>>>>>>>>>>> Total buffers allocated:           641
>>>>>>>>>>>>>> Total buffers freed:               64
>>>>>>>>>>>>>> Total buffers released:            577
>>>>>>>>>>>>>> Maximum file buffers used:         64
>>>>>>>>>>>>>> Total buffers free errors:         0
>>>>>>>>>>>>>> Total buffers release errors:      0
>>>>>>>>>>>>>> Total memcap failures:             0
>>>>>>>>>>>>>> Total memcap failures at reserve:  0
>>>>>>>>>>>>>> Total reserve failures:            0
>>>>>>>>>>>>>> Total file capture size min:       0
>>>>>>>>>>>>>> Total file capture size max:       0
>>>>>>>>>>>>>> Total capture max before reserve:  2
>>>>>>>>>>>>>> Total file signature max:          0
>>>>>>>>>>>>>> Maximum buffers can allocate:      3196
>>>>>>>>>>>>>> Number of buffers in use:          0
>>>>>>>>>>>>>> Number of buffers in free list:    2619
>>>>>>>>>>>>>> Number of buffers in release list: 577
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ============================================================
>>>>>>>>>>>>>> ===================
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Following the instructions given as examples inside the file
>>>>>>>>>>>>>> README.file, I
>>>>>>>>>>>>>> have included the following rules to get an alert every time
>>>>>>>>>>>>>> Snort
>>>>>>>>>>>>>> detects
>>>>>>>>>>>>>> a file:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> alert (msg: "GIF file"; gid:146; sid:63; rev:1; metadata:
>>>>>>>>>>>>>> rule-type
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>       preproc;)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> After that, no alert showed up.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I went deep inside the code to find out what the reason is and
>>>>>>>>>>>>>> found
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> following piece of code that confused me:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> snort/src/dynamic-preprocessors/file/file_agent.c:601-614
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>        * File type callback when file type is identified
>>>>>>>>>>>>>>       *
>>>>>>>>>>>>>>       * For file capture or file signature,
>>>>>>>>>>>>>> FILE_VERDICT_PENDING
>>>>>>>>>>>>>> must
>>>>>>>>>>>>>> be
>>>>>>>>>>>>>> returned
>>>>>>>>>>>>>>       */
>>>>>>>>>>>>>> static File_Verdict file_agent_type_callback(void* p, void*
>>>>>>>>>>>>>> ssnptr,
>>>>>>>>>>>>>>              uint32_t file_type_id, bool upload, uint32_t
>>>>>>>>>>>>>> file_id)
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>          file_inspect_stats.file_types_total++;
>>>>>>>>>>>>>>          if (file_signature_enabled || file_capture_enabled)
>>>>>>>>>>>>>>              return FILE_VERDICT_UNKNOWN;
>>>>>>>>>>>>>>          else
>>>>>>>>>>>>>>              return FILE_VERDICT_LOG;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You can read on the description that FILE_VERDICT_PENDING
>>>>>>>>>>>>>> must be
>>>>>>>>>>>>>> returned
>>>>>>>>>>>>>> when file capture OR file signature is enabled, but what
>>>>>>>>>>>>>> really
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> code
>>>>>>>>>>>>>> does is to return FILE_VERDICT_UNKNOWN when capture or
>>>>>>>>>>>>>> signature
>>>>>>>>>>>>>> are
>>>>>>>>>>>>>> enabled.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> After see that, I have modified the snort.conf by carrying on
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> following
>>>>>>>>>>>>>> changes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Replace this:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> preprocessor file_inspect: type_id, signature, \
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                    capture_queue_size 5000, \
>>>>>>>>>>>>>>                   capture_disk /home/file_capture/tmp/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> By:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> preprocessor file_inspect: type_id
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This way I forced to go through the ELSE and return a
>>>>>>>>>>>>>> FILE_VERDICT_LOG.
>>>>>>>>>>>>>> After this change, and using the same two alert rules, we run
>>>>>>>>>>>>>> snort,
>>>>>>>>>>>>>> getting alerts like these below:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 03/16-12:50:22.350000  [**] [146:63:1] GIF [**] [Priority: 0]
>>>>>>>>>>>>>> {TCP}
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>       192.168.202.78:80 <http://192.168.202.78/> <
>>>>>>>>>>>>>> http://192.168.202.78/
>>>>>>>>>>>>>> -> 192.168.203.61:38976
>>>>>>>>>>>>>> 03/16-12:50:22.350000  [**] [146:63:1] GIF [**] [Priority: 0]
>>>>>>>>>>>>>> {TCP}
>>>>>>>>>>>>>> 192.168.202.78:80 <http://192.168.202.78/> <
>>>>>>>>>>>>>> http://192.168.202.78/>
>>>>>>>>>>>>>> ->
>>>>>>>>>>>>>> 192.168.203.61:38976
>>>>>>>>>>>>>> 03/16-12:50:22.350000  [**] [146:63:1] GIF [**] [Priority: 0]
>>>>>>>>>>>>>> {TCP}
>>>>>>>>>>>>>> 192.168.202.78:80 <http://192.168.202.78/> <
>>>>>>>>>>>>>> http://192.168.202.78/>
>>>>>>>>>>>>>> ->
>>>>>>>>>>>>>> 192.168.203.61:38977
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>       and getting the following output at the end:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ============================================================
>>>>>>>>>>>>>> ===================
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>       Action Stats:
>>>>>>>>>>>>>>           Alerts:          275 (  0.003%)
>>>>>>>>>>>>>>           Logged:          275 (  0.003%)
>>>>>>>>>>>>>>           Passed:            0 (  0.000%)
>>>>>>>>>>>>>> Limits:
>>>>>>>>>>>>>>            Match:            0
>>>>>>>>>>>>>>            Queue:            0
>>>>>>>>>>>>>>              Log:            0
>>>>>>>>>>>>>>            Event:            0
>>>>>>>>>>>>>>            Alert:            0
>>>>>>>>>>>>>> Verdicts:
>>>>>>>>>>>>>>            Allow:      8418514 ( 97.482%)
>>>>>>>>>>>>>>            Block:            0 (  0.000%)
>>>>>>>>>>>>>>          Replace:            0 (  0.000%)
>>>>>>>>>>>>>>        Whitelist:       217429 (  2.518%)
>>>>>>>>>>>>>>        Blacklist:            0 (  0.000%)
>>>>>>>>>>>>>>           Ignore:            0 (  0.000%)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ============================================================
>>>>>>>>>>>>>> ===================
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ============================================================
>>>>>>>>>>>>>> ===================
>>>>>>>>>>>>>> File Preprocessor Statistics
>>>>>>>>>>>>>>        Total file type callbacks:            576
>>>>>>>>>>>>>>        Total file signature callbacks:       0
>>>>>>>>>>>>>>        Total files would saved to disk:      0
>>>>>>>>>>>>>>        Total files saved to disk:            0
>>>>>>>>>>>>>>        Total file data saved to disk:        0         bytes
>>>>>>>>>>>>>>        Total files duplicated:               0
>>>>>>>>>>>>>>        Total files reserving failed:         0
>>>>>>>>>>>>>>        Total file capture min:               0
>>>>>>>>>>>>>>        Total file capture max:               0
>>>>>>>>>>>>>>        Total file capture memcap:            0
>>>>>>>>>>>>>>        Total files reading failed:           0
>>>>>>>>>>>>>>        Total file agent memcap failures:     0
>>>>>>>>>>>>>>        Total files sent:                     0
>>>>>>>>>>>>>>        Total file data sent:                 0
>>>>>>>>>>>>>>        Total file transfer failures:         0
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ============================================================
>>>>>>>>>>>>>> ===================
>>>>>>>>>>>>>> File type stats:
>>>>>>>>>>>>>>               Type              Download   (Bytes)      Upload
>>>>>>>>>>>>>>     (Bytes)
>>>>>>>>>>>>>>                GZ( 33)          2          0            0
>>>>>>>>>>>>>>    0
>>>>>>>>>>>>>>               SWF( 52)          1          0            0
>>>>>>>>>>>>>>    0
>>>>>>>>>>>>>>               GIF( 62)          7          0            0
>>>>>>>>>>>>>>    0
>>>>>>>>>>>>>>               GIF( 63)          275        0            0
>>>>>>>>>>>>>>    0
>>>>>>>>>>>>>>               PNG( 69)          266        0            0
>>>>>>>>>>>>>>    0
>>>>>>>>>>>>>>              JPEG( 70)          2          0            0
>>>>>>>>>>>>>>    0
>>>>>>>>>>>>>>               BMP(148)          2          0            0
>>>>>>>>>>>>>>    0
>>>>>>>>>>>>>>               ICO(149)          21         0            0
>>>>>>>>>>>>>>    0
>>>>>>>>>>>>>>                  Total          576        0            0
>>>>>>>>>>>>>>    0
>>>>>>>>>>>>>> File signature stats:
>>>>>>>>>>>>>>               Type              Download   Upload
>>>>>>>>>>>>>>                  Total          0          0
>>>>>>>>>>>>>> File type verdicts:
>>>>>>>>>>>>>>              UNKNOWN:           0
>>>>>>>>>>>>>>                  LOG:           576
>>>>>>>>>>>>>>                 STOP:           0
>>>>>>>>>>>>>>                BLOCK:           0
>>>>>>>>>>>>>>               REJECT:           0
>>>>>>>>>>>>>>              PENDING:           0
>>>>>>>>>>>>>>         STOP CAPTURE:           0
>>>>>>>>>>>>>>                Total:           576
>>>>>>>>>>>>>> File signature verdicts:
>>>>>>>>>>>>>>              UNKNOWN:           0
>>>>>>>>>>>>>>                  LOG:           0
>>>>>>>>>>>>>>                 STOP:           0
>>>>>>>>>>>>>>                BLOCK:           0
>>>>>>>>>>>>>>               REJECT:           0
>>>>>>>>>>>>>>              PENDING:           0
>>>>>>>>>>>>>>         STOP CAPTURE:           0
>>>>>>>>>>>>>>                Total:           0
>>>>>>>>>>>>>> Total files processed:             68987
>>>>>>>>>>>>>> Total files data processed:        42751396  bytes
>>>>>>>>>>>>>> Total files buffered:              0
>>>>>>>>>>>>>> Total files released:              0
>>>>>>>>>>>>>> Total files freed:                 0
>>>>>>>>>>>>>> Total files captured:              0
>>>>>>>>>>>>>> Total files within one packet:     0
>>>>>>>>>>>>>> Total buffers allocated:           0
>>>>>>>>>>>>>> Total buffers freed:               0
>>>>>>>>>>>>>> Total buffers released:            0
>>>>>>>>>>>>>> Maximum file buffers used:         0
>>>>>>>>>>>>>> Total buffers free errors:         0
>>>>>>>>>>>>>> Total buffers release errors:      0
>>>>>>>>>>>>>> Total memcap failures:             0
>>>>>>>>>>>>>> Total memcap failures at reserve:  0
>>>>>>>>>>>>>> Total reserve failures:            0
>>>>>>>>>>>>>> Total file capture size min:       0
>>>>>>>>>>>>>> Total file capture size max:       0
>>>>>>>>>>>>>> Total capture max before reserve:  0
>>>>>>>>>>>>>> Total file signature max:          0
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ============================================================
>>>>>>>>>>>>>> ===================
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> As you can see, in the "File type verdicts" section I got all
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> files
>>>>>>>>>>>>>> with verdict LOG. Also, I got 275 alerts that match the 275
>>>>>>>>>>>>>> GIF
>>>>>>>>>>>>>> files
>>>>>>>>>>>>>> detected by Snort.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am not sure if this is the expected behavior of this
>>>>>>>>>>>>>> feature or
>>>>>>>>>>>>>> maybe
>>>>>>>>>>>>>> I
>>>>>>>>>>>>>> am not configuring Snort properly.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Am I doing something wrong or configuring the preprocessor in
>>>>>>>>>>>>>> a
>>>>>>>>>>>>>> wrong
>>>>>>>>>>>>>> way?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks for your help and best Regards,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Pablo Cantosredborder.org / pcantos at ...16842...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This body part will be downloaded on demand.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This body part will be downloaded on demand.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>>>>>> ------------------
>>>>>>>>>>>>>> Dive into the World of Parallel Programming The Go Parallel
>>>>>>>>>>>>>> Website,
>>>>>>>>>>>>>> sponsored
>>>>>>>>>>>>>> by Intel and developed in partnership with Slashdot Media, is
>>>>>>>>>>>>>> your
>>>>>>>>>>>>>> hub
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>> all
>>>>>>>>>>>>>> things parallel software development, from weekly thought
>>>>>>>>>>>>>> leadership
>>>>>>>>>>>>>> blogs
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>> news, videos, case studies, tutorials and more. Take a look
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> join
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> conversation now. http://goparallel.sourceforge.net/
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> Snort-users mailing list
>>>>>>>>>>>>>> Snort-users at lists.sourceforge.net
>>>>>>>>>>>>>> Go to this URL to change user options or unsubscribe:
>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/snort-users
>>>>>>>>>>>>>> Snort-users list archive:
>>>>>>>>>>>>>> http://sourceforge.net/mailarchive/forum.php?forum_
>>>>>>>>>>>>>> name=snort-users
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please visit http://blog.snort.org to stay current on all the
>>>>>>>>>>>>>> latest
>>>>>>>>>>>>>> Snort news!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20150416/6c0e6d08/attachment.html>


More information about the Snort-users mailing list