sigma
sigma copied to clipboard
SigmaHQ
Direct IP Request detection rule
nice. i would recommend tweaking this to be accomplished with just ends in an integer. a domain never ends in an integer and so this is a more efficient way
Yes, please use a regex that is simpler. We could even use strings, don't we?
cs-host|endswith:
- '1'
- '2'
- '3'
- '4'
- '5'
- '6'
- '7'
- '8'
- '9'
- '0'
i would recommend tweaking this to be accomplished with just ends in an integer.
I think this could introduce false positives as same-domain hosts can end with numbers (i.e. https://PROXY01) if the local DNS can resolve them. I am hence more in favor of a regex which detects either (digits and dots) or (hexadecimal and colons) (i.e. ^([\d.]+|[\da-fA-F:]+)$) this would also support the alternate IP notations such as those observed in this sample.
@0xThiebaut are you referring to how a domain would look browser side? where the possibilities are endless, the browser/client side converts it to a reasonable HTTP HOST/domain - so browser side https://proxy01 gets converted to HTTP HOST field of whatever proxy01 resolves to.
You bring up a point though about IPv6, how about writing it as:
detection:
ip_v4:
cs-host|endswith:
- '1'
- '2'
- '3'
- '4'
- '5'
- '6'
- '7'
- '8'
- '9'
- '0'
ip_v6:
cs-host|contains: ':'
condition: ip_v4 or ip_v6
So I changed the regex to be more readable, and supporting the alternate notations that @0xThiebaut brought up. There's also the matching for IPv6 now.
I also noticed that Elasticsearch doesn't do the anchor symbols (^, %) and always expects a full match, but I'll create an issue for that one later today.
sounds good, can you cc me if you create an issue? yeah (Elasticsearch) lucene regex is not pcre 😩
Why not
detection:
ip_v4_end:
cs-host|endswith:
- '1'
- '2'
- '3'
- '4'
- '5'
- '6'
- '7'
- '8'
- '9'
- '0'
ip_v4_dot:
cs-host|contains:
- '.'
ip_v6:
cs-host|contains: ':'
condition: ( ip_v4_end and ip_v4_dot) or ip_v6
Is the search for a dot . too expensive?
I thing this is indeed a less-expensive approach than relying on regex matches, however this wouldn't match decimal-noted IPv4 addresses as just a number is valid too.
But then again, there can be a balance between performances and matches.
I just encountered a case that would give a false positive with the proposed (regex-less) rule:
<redacted>.router_w_921v_1_46_000.
Having said that; It's rare for naming schemes to end with a number, much less have those show up frequently. Is it worth the performance loss by using a regex to avoid these special cases? I don't know yet. The IPv6 part of the rule I've not encountered any possible issues with yet, thanks for the suggestion. I've change the rule to use that instead, commenting out the regex.
I'll see if I get any more examples during the week, otherwise I may concede and accept the occasional FP caused by exotic internal DNS/hostname schemes.
I think the rule is best kept as it currently is; The search for "ending with a number and containing a dot" doesn't seem as semantically correct as having an expression that requires the whole destination to be numbers and dots. It may only give false positives in rare cases, but it still doesn't sit very right with me.
just to double check and confirm here, we are talking about HTTP Host Header correct?
