[Oisf-users] testing rules using pcap file

Wed Jun 13 22:12:38 UTC 2018

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