<div dir="ltr">Oops... After a more careful re-read, I think this is what you're looking for:<br><br>alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"ET POLICY Cryptocurrency Miner Checkin"; flow:established,to_server; content:"|7b 22|id|22 3a|"; nocase; depth:6; fast_pattern; content:"|22|jsonrpc|22 3a|"; nocase; distance:0; content:"|22 2c 22|method|22 3a 22|login|22 2c 22|params|22 3a|"; content:"|22|login|22 3a 22|"; nocase; content:"|22 2c 22|pass|22 3a 22|"; nocase; content:"|22 2c 22|agent|22 3a 22|"; nocase; content:!"<title"; nocase; content:!"<script"; nocase; content:!"<html"; nocase; classtype:policy-violation; sid:10000;)<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 13, 2018 at 2:51 PM, Travis Green <span dir="ltr"><<a href="mailto:travis@travisgreen.net" target="_blank">travis@travisgreen.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hey Russell, <div>Content match order does not matter unless you use distance:0; on subsequent matches. A quick look at ET rules shows 2024792 to be either what you're looking for or close to it.</div><div><br></div><div><a href="http://blog.joelesler.net/2010/03/offset-depth-distance-and-within.html" target="_blank">Here</a> is a classic blog post from Joel Esler that touches on it (for Snort, but Suricata is the same in this regard).</div><div><br></div><div>Hope that helps,</div><div>-Travis</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Wed, Jun 13, 2018 at 2:39 PM, Russell Fulton <span dir="ltr"><<a href="mailto:r.fulton@auckland.ac.nz" target="_blank">r.fulton@auckland.ac.nz</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div style="word-wrap:break-word;line-break:after-white-space">
<div dir="auto" style="word-wrap:break-word;line-break:after-white-space">Hi<div><br></div><div>I have been trying to modify an existing rule for crypto miners to cope with traffic from what is presumably a related mining script.   The issue is that the json has items in a different order.</div><div><br></div><div>I have a pcap of the new traffic from Moloch and I have created a cut down config file which loads a single file with the new rule in it:</div><div><br></div><div>alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"ET POLICY Cryptocurrency Miner Checkin"; )</div><div><br></div><div><br></div><div><font face="Menlo">sensors@secmontst01:~$ suricata -c suri-test.yaml -r ~rful011/180612-zj4MWV_96udJEZ<wbr>LpZ-rqyYu9.pcap <br></font></div><div><font face="Menlo">Initialization syslog logging with format "[%i] <%d> -- ".<br>13/6/2018 -- 15:20:23 - <Notice> - This is Suricata version 4.0.4 RELEASE<br>13/6/2018 -- 15:20:23 - <Info> - CPUs/cores online: 16<br>13/6/2018 -- 15:20:23 - <Info> - Protocol detection and parser disabled for smb protocol.<br>13/6/2018 -- 15:20:23 - <Info> - Protocol detection and parser disabled for dcerpc protocol.<br>13/6/2018 -- 15:20:23 - <Info> - Protocol detection and parser disabled for dcerpc protocol.<br>13/6/2018 -- 15:20:23 - <Info> - No 'host-mode': suricata is in IDS mode, using default setting 'sniffer-only'<br>13/6/2018 -- 15:20:23 - <Info> - 1 rule files processed. 1 rules successfully loaded, 0 rules failed<br>13/6/2018 -- 15:20:23 - <Info> - Threshold config parsed: 0 rule(s) found<br>13/6/2018 -- 15:20:23 - <Info> - 1 signatures processed. 0 are IP-only rules, 0 are inspecting packet payload, 0 inspect application layer, 0 are decoder event only<br>13/6/2018 -- 15:20:23 - <Info> - Syslog output initialized<br>13/6/2018 -- 15:20:23 - <Info> - reading pcap file /home/rful011/180612-zj4MWV_96<wbr>udJEZLpZ-rqyYu9.pcap<br>13/6/2018 -- 15:20:24 - <Notice> - all 17 packet processing threads, 2 management threads initialized, engine started.<br>13/6/2018 -- 15:20:24 - <Info> - pcap file end of file reached (pcap err code 0)<br>13/6/2018 -- 15:20:24 - <Notice> - Signal Received.  Stopping engine.<br>13/6/2018 -- 15:20:24 - <Info> - time elapsed 0.402s<br>13/6/2018 -- 15:20:24 - <Notice> - Pcap-file module read 36 packets, 5452 bytes<br>13/6/2018 -- 15:20:24 - <Info> - Alerts: 0<br>13/6/2018 -- 15:20:24 - <Info> - cleaning up signature grouping structure… complete<br><br></font></div><div><br></div><div>As ususal I appear to be missing something!   It is a long time since I dabbled in rule writing.</div><div><br></div><div><br></div><div>Related to this can I have a bunch of content items that will match even if the items occur in a different order in the traffic?  For example:</div><div><br></div><div><span style="font-size:14.666666984558105px"><font face="Menlo">{"id":"1","jsonrpc":"2.0","met<wbr>hod":"login","params":{"agent"<wbr>:"MinerGateWin/8.1","login”: …</font></span><font face="Menlo"><span style="font-size:14.666666984558105px"><wbr>…</span></font></div><div><span style="font-size:14.666666984558105px"><font face="Menlo"><br></font></span></div><div><span style="font-size:14.666666984558105px">the current rule expects the “login” before the “agent” in the params hash.   In the original rule the content after “params” is “login”; distance 0 then content “agent” …</span></div><div><span style="font-size:14.666666984558105px"><br></span></div><div><span style="font-size:14.666666984558105px">From my reading of the manual I can’t see a way of writing a single rule which will match when to params are in any order.  I.e.  anchor all the searches at the beginning of hash.   My understanding is that distance always relates to previous match.  Correct ?</span></div><span class="m_4709150495693820810HOEnZb"><font color="#888888"><div><span style="font-size:14.666666984558105px"><br></span></div><div><span style="font-size:14.666666984558105px">Russell</span></div></font></span></div></div><br></div></div>______________________________<wbr>_________________<br>
Suricata IDS Users mailing list: <a href="mailto:oisf-users@openinfosecfoundation.org" target="_blank">oisf-users@openinfosecfoundati<wbr>on.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/suppor<wbr>t/</a><br>
List: <a href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" rel="noreferrer" target="_blank">https://lists.openinfosecfound<wbr>ation.org/mailman/listinfo/<wbr>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/train<wbr>ing/</a><span class="HOEnZb"><font color="#888888"><br></font></span></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div class="m_4709150495693820810gmail_signature" data-smartmail="gmail_signature">PGP: ABE625E6<br><a href="http://keybase.io/travisbgreen" target="_blank">keybase.io/travisbgreen</a></div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">PGP: ABE625E6<br><a href="http://keybase.io/travisbgreen" target="_blank">keybase.io/travisbgreen</a></div>
</div>