<div dir="ltr"><div dir="ltr">Thanks, Andreas.  I created <a href="https://redmine.openinfosecfoundation.org/issues/2656">https://redmine.openinfosecfoundation.org/issues/2656</a> and attached pcaps to the ticket.<br clear="all"><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><span style="color:rgb(0,0,0);font-family:"Helvetica Neue",Helvetica,sans-serif;font-size:small;white-space:nowrap"><br></span></div><div dir="ltr"><span style="color:rgb(0,0,0);font-family:"Helvetica Neue",Helvetica,sans-serif;font-size:small;white-space:nowrap"><br></span></div><div dir="ltr"><span style="color:rgb(0,0,0);font-family:"Helvetica Neue",Helvetica,sans-serif;font-size:small;white-space:nowrap">-- </span></div><div dir="ltr"><span style="color:rgb(0,0,0);font-family:"Helvetica Neue",Helvetica,sans-serif;font-size:small;font-weight:bold;white-space:nowrap">Eric Urban</span><br></div><div dir="ltr"><span style="color:rgb(0,0,0);font-family:"Helvetica Neue",Helvetica,sans-serif;font-size:small;line-height:17.29px;white-space:nowrap">University Information Security | Office of Information Technology | </span><a href="http://it.umn.edu/" style="color:rgb(17,85,204);font-family:"Helvetica Neue",Helvetica,sans-serif;font-size:small;line-height:17.29px;white-space:nowrap" target="_blank">it.umn.edu</a><br style="color:rgb(0,0,0);font-family:"Helvetica Neue",Helvetica,sans-serif;font-size:small;line-height:17.29px;white-space:nowrap"><span style="color:rgb(0,0,0);font-family:"Helvetica Neue",Helvetica,sans-serif;font-size:small;line-height:17.29px;white-space:nowrap">University of Minnesota | </span><a href="http://umn.edu/" style="color:rgb(17,85,204);font-family:"Helvetica Neue",Helvetica,sans-serif;font-size:small;line-height:17.29px;white-space:nowrap" target="_blank">umn.edu</a><br style="color:rgb(0,0,0);font-family:"Helvetica Neue",Helvetica,sans-serif;font-size:small;line-height:17.29px;white-space:nowrap"><a href="mailto:eurban@umn.edu" style="color:rgb(17,85,204);font-family:"Helvetica Neue",Helvetica,sans-serif;font-size:small;line-height:17.29px;white-space:nowrap" target="_blank">eurban@umn.edu</a><font face="verdana, sans-serif" style="color:rgb(136,136,136);font-size:12.8px"><br></font></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 29, 2018 at 4:23 PM Andreas Herz <<a href="mailto:andi@geekosphere.org">andi@geekosphere.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Eric,<br>
<br>
sorry for the rather late reply. Would you mind creating a redmine issue<br>
with that? And are you able to share the pcap (maybe personal to one of<br>
the OISF)?<br>
<br>
It might be (just my guess) rather hard to determine the root cause of<br>
that and how to fix it.<br>
<br>
On 10/10/18 at 15:03, Eric Urban wrote:<br>
> Hello,<br>
> <br>
> I am trying to make sense of behavior we saw in our environment related to<br>
> alerts on a long running flow and am hoping for some input on what may be<br>
> going on.<br>
> <br>
> The somewhat short version of the story is that in our environment we have<br>
> two sensor sets that are configured to receive identical copies of<br>
> traffic.  The sets are identical in terms of hardware, OS, Suricata version<br>
> (4.0.5), and Suricata configuration.  This week we saw a large difference<br>
> in the number of alerts between sensor sets and these alerts were all<br>
> produced from a single flow of SMB traffic.<br>
> <br>
> I confirmed this flow to be going to both sensors in our connection logs,<br>
> and also captured traffic of this long running connection directly on the<br>
> sensor not producing alerts.  During my investigation, I ran into something<br>
> that could potentially explain what happened if there were a few packets<br>
> dropped on one side.  I found this while running the packet captures<br>
> through Suricata in offline/pcap mode.  It appears the point at which the<br>
> flow is captured determines whether or not subsequent alerts are<br>
> generated.  I understand that in many cases capturing midstream traffic can<br>
> determine whether alerts are triggered, especially where rules have content<br>
> modifiers that require content be at a specific point in the payload.<br>
> However, my confusion comes from a test where I ran these captures through<br>
> Suricata with the only difference of one packet at the beginning, which<br>
> ends up causing a different SMB message to start the capture.  In each of<br>
> these cases neither packet should match the particular SMB rule generating<br>
> these alerts.<br>
> <br>
> What I am seeing may be working as designed, but I am having trouble<br>
> feeling comfortable that something isn't wrong.<br>
> <br>
> Additional details of this situation are below, but a summary of some of<br>
> the things I am looking for are:<br>
> 1. Is the payload of a single connection always treated as one or are there<br>
> some cases where it is split into multiple payloads?  This is important<br>
> because it determines how rules may trigger alerts where keywords like<br>
> depth are used.<br>
> <br>
> 2. Does Suricata treat connections starting with SMB Close Response<br>
> messages in a special way?  I could not find anything in the code<br>
> indicating it does.<br>
> <br>
> 3. Does the problem as I have described it below sound like this is an<br>
> issue with the rule itself, how rules are used to inspect the traffic, or<br>
> something else?  The fact one sensor set saw the traffic and the other<br>
> didn't suggests dropped packets, but I am looking for things beyond just<br>
> environment based on what am I seeing running these captures through<br>
> Suricata.<br>
> <br>
> <br>
> Here is my long story about a long running connection:<br>
> <br>
> We had a long running connection of about 7 days generate as many as a few<br>
> thousand alerts per hour only on one of our sensor sets.  The connection<br>
> was being used to transfer data via SMB. It was being treated by Suricata<br>
> as a single flow so has the same flow id throughout.<br>
> <br>
> I gathered two separate packet captures that were run about 10 minutes<br>
> apart on the sensor not generating alerts. A host filter was used to<br>
> capture only the desired traffic.  Each capture ended up being about 500MB<br>
> in size.  When I ran the first capture through an instance of Suricata<br>
> using pcap/offline mode, it triggered a several hundred SMB alerts, which<br>
> were mostly for Emerging Threats SIDs 2025709<br>
> <<a href="http://doc.emergingthreats.net/bin/view/Main/2025709" rel="noreferrer" target="_blank">http://doc.emergingthreats.net/bin/view/Main/2025709</a>> "SMB2 Create Req for<br>
> DLL" and some also for 2025705<br>
> <<a href="http://doc.emergingthreats.net/bin/view/Main/2025705" rel="noreferrer" target="_blank">http://doc.emergingthreats.net/bin/view/Main/2025705</a>> "SMB2 Create Req for<br>
> .ps1".  When I ran the second capture through Suricata, to my surprise<br>
> there were zero alerts generated.  I inspected the second capture with<br>
> Wireshark to look for differences that might explain why it produced no<br>
> alerts and found there were definitely DLL files being transferred after an<br>
> SMB2 Create Request.  As a test I removed a chunk of packets from the<br>
> beginning of the second capture in case something was throwing it off and<br>
> ran it through again.  That did the trick and several hundred alerts were<br>
> generated.  I then removed only the first packet, which happened to be an<br>
> SMB2 Close Response.  I ran this modified capture through Suricata and sure<br>
> enough there were alerts.  So I decided to try this with a few other SMB2<br>
> Close Responses in case something was up with the first one and I was able<br>
> to reproduce the situation each time where that specific message type at<br>
> the start of the capture resulted in no alerts, even with several hundred<br>
> situations of DLL files being transferred from a Create Request.  I also<br>
> tested using another SMB message type at the start the capture in case it<br>
> wasn't just the Close Response ones affecting it.  I found a case where<br>
> trimming a single packet of a Close Response resulted in the capture<br>
> starting with a Read Request SMB message.  The capture starting with that<br>
> message produced all expected alerts when I ran it through Suricata.<br>
> <br>
> Here is the full Emerging Threats rule with SID 2025709 from<br>
> <a href="http://doc.emergingthreats.net/bin/view/Main/2025709" rel="noreferrer" target="_blank">http://doc.emergingthreats.net/bin/view/Main/2025709</a> (formatted for<br>
> readability):<br>
> alert tcp any any -> $HOME_NET 445<br>
> (msg:"ET POLICY SMB2 NT Create AndX? Request For a DLL File - Possible<br>
> Lateral Movement";<br>
> flow:established,to_server;<br>
> content:"SMB"; depth:8;<br>
> content:"|05 00|"; distance:8; within:2;<br>
> content:"|00 2E 00|d|00|l|00|l|00|"; nocase; distance:0;<br>
> metadata: former_category POLICY;<br>
> classtype:bad-unknown;<br>
> sid:2025709;<br>
> rev:2;<br>
> metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit,<br>
> attack_target SMB_Client, deployment Internal, signature_severity Minor,<br>
> created_at 2018_07_16, updated_at 2018_07_16;)<br>
> <br>
> The first Content has a depth content modifier of 8 which according to<br>
> Suricata documentation at<br>
> <a href="https://suricata.readthedocs.io/en/suricata-4.0.5/rules/payload-keywords.html#depth" rel="noreferrer" target="_blank">https://suricata.readthedocs.io/en/suricata-4.0.5/rules/payload-keywords.html#depth</a><br>
> means that "The number after depth designates how many bytes from the<br>
> beginning of the payload will be checked".  After that we see another<br>
> Content of |05 00| that must exist a distance of 8 bytes away and those<br>
> next 2 bytes should be the 05 and 00, which is looking for a Create<br>
> Response type SMB message,.  Finally, after that another Content exists<br>
> looking essentially for the string ".dll" that can exist at any point after<br>
> that in the payload since the distance is 0.<br>
> <br>
> A Close Response has the type of 0x06.  There is a reference of these at<br>
> <a href="https://github.com/OISF/suricata/blob/ec77632e84a106ddbcd0baef4e4368b4fe5c5f9e/src/app-layer-smb.h#L97" rel="noreferrer" target="_blank">https://github.com/OISF/suricata/blob/ec77632e84a106ddbcd0baef4e4368b4fe5c5f9e/src/app-layer-smb.h#L97</a><br>
> and another reference at <a href="https://wiki.wireshark.org/SMB2" rel="noreferrer" target="_blank">https://wiki.wireshark.org/SMB2</a>.  I had one<br>
> capture start with a Close Response and the other I trimmed only that frame<br>
> so the capture started with a Read Request.  A Read Request is of type<br>
> 0x08, so has a 08 at a distance of 8 away from "SMB".  Neither one of these<br>
> message types should match this rule, yet somehow starting the capture with<br>
> one or the other changes the behavior significantly.<br>
> <br>
> It is now not clear to me what constitutes a payload inside of a<br>
> connection.  If there is only one payload per connection, then how do any<br>
> of these situations have alerts triggered since SMB with the following 05<br>
> 00 bytes do not start any of these?  If there are multiple payloads per<br>
> connection, which I would assume is handled by the application layer<br>
> detectors, then why is this Close Response causing all detections to fail?<br>
> <br>
> I did try adjusting the rule signature protocol to use smb instead of tcp<br>
> in the hope that could make a difference, but it did not look to change<br>
> anything for me.<br>
> <br>
> I enabled debug with Suricata and searched for any log messages with smb<br>
> but did not see any differences.<br>
> <br>
> I also tried running the captures through 3.1 and the same behavior was<br>
> present.  I was able to recreate this using a vanilla config that only had<br>
> the HOME_NET, rule location, vlan.use-for-tracking values modified, so I<br>
> don't feel anything specific to our configuration is causing this to occur.<br>
> <br>
> Thank you for reading!<br>
> <br>
> -- <br>
> Eric Urban<br>
> University Information Security | Office of Information Technology |<br>
> <a href="http://it.umn.edu" rel="noreferrer" target="_blank">it.umn.edu</a><br>
> University of Minnesota | <a href="http://umn.edu" rel="noreferrer" target="_blank">umn.edu</a><br>
> <a href="mailto:eurban@umn.edu" target="_blank">eurban@umn.edu</a><br>
<br>
> _______________________________________________<br>
> Suricata IDS Users mailing list: <a href="mailto:oisf-users@openinfosecfoundation.org" target="_blank">oisf-users@openinfosecfoundation.org</a><br>
> Site: <a href="http://suricata-ids.org" rel="noreferrer" target="_blank">http://suricata-ids.org</a> | Support: <a href="http://suricata-ids.org/support/" rel="noreferrer" target="_blank">http://suricata-ids.org/support/</a><br>
> List: <a href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" rel="noreferrer" target="_blank">https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a><br>
> <br>
> Conference: <a href="https://suricon.net" rel="noreferrer" target="_blank">https://suricon.net</a><br>
> Trainings: <a href="https://suricata-ids.org/training/" rel="noreferrer" target="_blank">https://suricata-ids.org/training/</a><br>
<br>
<br>
-- <br>
Andreas Herz<br>
_______________________________________________<br>
Suricata IDS Users mailing list: <a href="mailto:oisf-users@openinfosecfoundation.org" target="_blank">oisf-users@openinfosecfoundation.org</a><br>
Site: <a href="http://suricata-ids.org" rel="noreferrer" target="_blank">http://suricata-ids.org</a> | Support: <a href="http://suricata-ids.org/support/" rel="noreferrer" target="_blank">http://suricata-ids.org/support/</a><br>
List: <a href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" rel="noreferrer" target="_blank">https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a><br>
<br>
Conference: <a href="https://suricon.net" rel="noreferrer" target="_blank">https://suricon.net</a><br>
Trainings: <a href="https://suricata-ids.org/training/" rel="noreferrer" target="_blank">https://suricata-ids.org/training/</a></blockquote></div>