[Oisf-users] testing rules using pcap file

[Travis Green]

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
<http://blog.joelesler.net/2010/03/offset-depth-distance-and-within.html>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20180613/3c9361ad/attachment-0001.html>