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