[Oisf-users] testing rules using pcap file

Thu Jun 14 16:55:28 UTC 2018

Russell, I've updated the ET version of this sig to catch any order of
properties in the params json object, as well as found a bit of perf by
changing the fast_pattern. FWIW I couldn't find any with the different
order. The update will be in today's release.

Thanks!
-Travis

On Wed, Jun 13, 2018 at 4:12 PM, Russell Fulton <r.fulton at auckland.ac.nz>
wrote:

> Thanks Travis, that is *exactly” what I was after!  I wasI was trying (and
> failing) to test something very similar with my pcap.  I.e. drop the
> distance 0 on the content matches after “params:{“
>
> I’ll try adding this and let you know if it works!  We have a machine
> mining at the moment so testing should be fast ;).
>
> BTW I take it there is nothing obviously wrong with my test attempt?
>
> R
>
> > On 14/06/2018, at 9:00 AM, Travis Green <travis at travisgreen.net> wrote:
> >
> > Oops... After a more careful re-read, I think this is what you're
> looking for:
> >
> > 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;)
> >
> > On Wed, Jun 13, 2018 at 2:51 PM, Travis Green <travis at travisgreen.net>
> wrote:
> > Hey Russell,
> > 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.
> >
> > Here is a classic blog post from Joel Esler that touches on it (for
> Snort, but Suricata is the same in this regard).
> >
> > Hope that helps,
> > -Travis
> >
> > On Wed, Jun 13, 2018 at 2:39 PM, Russell Fulton <r.fulton at auckland.ac.nz>
> wrote:
> > Hi
> >
> > 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.
> >
> > 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:
> >
> > alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"ET POLICY
> Cryptocurrency Miner Checkin"; )
> >
> >
> > sensors at secmontst01:~$ suricata -c suri-test.yaml -r
> ~rful011/180612-zj4MWV_96udJEZLpZ-rqyYu9.pcap
> > Initialization syslog logging with format "[%i] <%d> -- ".
> > 13/6/2018 -- 15:20:23 - <Notice> - This is Suricata version 4.0.4 RELEASE
> > 13/6/2018 -- 15:20:23 - <Info> - CPUs/cores online: 16
> > 13/6/2018 -- 15:20:23 - <Info> - Protocol detection and parser disabled
> for smb protocol.
> > 13/6/2018 -- 15:20:23 - <Info> - Protocol detection and parser disabled
> for dcerpc protocol.
> > 13/6/2018 -- 15:20:23 - <Info> - Protocol detection and parser disabled
> for dcerpc protocol.
> > 13/6/2018 -- 15:20:23 - <Info> - No 'host-mode': suricata is in IDS
> mode, using default setting 'sniffer-only'
> > 13/6/2018 -- 15:20:23 - <Info> - 1 rule files processed. 1 rules
> successfully loaded, 0 rules failed
> > 13/6/2018 -- 15:20:23 - <Info> - Threshold config parsed: 0 rule(s) found
> > 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
> > 13/6/2018 -- 15:20:23 - <Info> - Syslog output initialized
> > 13/6/2018 -- 15:20:23 - <Info> - reading pcap file
> /home/rful011/180612-zj4MWV_96udJEZLpZ-rqyYu9.pcap
> > 13/6/2018 -- 15:20:24 - <Notice> - all 17 packet processing threads, 2
> management threads initialized, engine started.
> > 13/6/2018 -- 15:20:24 - <Info> - pcap file end of file reached (pcap err
> code 0)
> > 13/6/2018 -- 15:20:24 - <Notice> - Signal Received.  Stopping engine.
> > 13/6/2018 -- 15:20:24 - <Info> - time elapsed 0.402s
> > 13/6/2018 -- 15:20:24 - <Notice> - Pcap-file module read 36 packets,
> 5452 bytes
> > 13/6/2018 -- 15:20:24 - <Info> - Alerts: 0
> > 13/6/2018 -- 15:20:24 - <Info> - cleaning up signature grouping
> structure… complete
> >
> >
> > As ususal I appear to be missing something!   It is a long time since I
> dabbled in rule writing.
> >
> >
> > 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:
> >
> > {"id":"1","jsonrpc":"2.0","method":"login","params":{"
> agent":"MinerGateWin/8.1","login”: ……
> >
> > 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” …
> >
> > 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 ?
> >
> > Russell
> >
> > _______________________________________________
> > Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
> > Site: http://suricata-ids.org | Support: http://suricata-ids.org/
> support/
> > List: https://lists.openinfosecfoundation.org/
> mailman/listinfo/oisf-users
> >
> > Conference: https://suricon.net
> > Trainings: https://suricata-ids.org/training/
> >
> >
> >
> > --
> > PGP: ABE625E6
> > keybase.io/travisbgreen
> >
> >
> >
> > --
> > PGP: ABE625E6
> > keybase.io/travisbgreen
>
>

-- 
PGP: ABE625E6
keybase.io/travisbgreen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20180614/7a121446/attachment.html>