Using the grep transform in ELSA to find HTTP logs where the site is an IP address

[Kurt Patzer]

Hello,
I'm trying to figure out an ELSA query that will return all entries where the program or class is bro_http and the site is an IP address (as opposed to a hostname).
This query works:
class=BRO_HTTP groupby:site
aggregating all HTTP transactions by the site field, and clearly shows some sites as IP addresses.
This query works:
class=BRO_HTTP | grep(site,a.c)
returning all HTTP transactions where the site has an a and a c separated by any other character somewhere in the site string. This makes me comfortable that the grep transform is working with the bro_http.site field using a very simple regular expression.
This query returns nothing:
class=BRO_HTTP | grep(site,10)
which baffles me. Some of the sites that are IP addresses have 10 as one of their octets. I'd expect this to match where the site equals, say, 10.10.10.10. But, it returns nothing. I've tried putting the 10 in single and double quotes with no change in behavior.
This query also returns nothing:
class=BRO_HTTP | grep(site,[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})
The logic in the above query is what I am trying to achieve, but it doesn't get any hits. I've tried variants on the regular expression such as using using \d for the [0-9] and \d?\d?\d? as an alternative to {1,3}.

It seems there is something strange going on with the combination of bro_http.site field, numeric characters and the grep transform. Does anyone have any pointers that can straighten me out?

Thanks,
Kurt

[Wes]

Kurt,

I can confirm this does not work with numeric characters.

Have you tried using srcip or dstip instead?

Thanks,
Wes

[Kurt Patzer]

Hi Wes,
Thanks for checking into this.
Working with srcip and dstip won't work. I believe Bro extracts those from the layer 3 IP header and they will always be dotted decimal octet style IP addresses (assuming IPv4, not 6). The bro_http.site field is taken from the Host: field of the http headers. 99ish% of the time this field is DNS hostname such as www.google.com. When it isn't a DNS hostname, but instead an IP address, it is interesting and potentially worth investigating. Users rarely browse by IP address. But, a low budget attacker who can't afford to register DNS domains may hard code IP addresses in malware for an HTTP reverse connection.
If I can't do this with Bro/ELSA, I'll try to figure out another way to perform this query. But the geek in me is curious as to why this doesn't work. The http header "host" field/bro_http.site field is string data. Why does parsing with the grep transform behave strangely when it's all dotted decimal? That's still ASCII string data... Hmm...
Thanks,
Kurt

[Doug Burks]

Hi Kurt,

Keep in mind that ELSA defaults to returning 100 results and so that's
all that's being passed to the grep transform. Have you tried
increasing your limit like this?
class=BRO_HTTP limit:9999 | grep(site,10)

> --
> Follow Security Onion on Twitter!
> https://twitter.com/securityonion
> ---
> You received this message because you are subscribed to the Google Groups "security-onion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
> To post to this group, send email to securit...@googlegroups.com.
> Visit this group at https://groups.google.com/group/security-onion.
> For more options, visit https://groups.google.com/d/optout.



--
Doug Burks

[Kurt Patzer]

Hi Doug,
Thanks for this. It was indeed the issue. I feel a bit silly for not considering truncated results being fed to grep as the root cause. Thanks for the help.
Kurt

[Kevin Branch]

If you are using Snort or Suricata, you might also have a look at the NIDS rules that catch dotted quad http requests.  With the ET Free rules at least, this will show you a number of good examples.

grep -i "dotted quad" /etc/nsm/rules/downloaded.rules

Kevin

> > To unsubscribe from this group and stop receiving emails from it, send an email to security-onion+unsubscribe@googlegroups.com.
> > To post to this group, send email to security-onion@googlegroups.com.

> > Visit this group at https://groups.google.com/group/security-onion.
> > For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> Doug Burks

Hi Doug,
    Thanks for this. It was indeed the issue. I feel a bit silly for not considering truncated results being fed to grep as the root cause. Thanks for the help.

Kurt

--
Follow Security Onion on Twitter!
https://twitter.com/securityonion
---
You received this message because you are subscribed to the Google Groups "security-onion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to security-onion+unsubscribe@googlegroups.com.
To post to this group, send email to security-onion@googlegroups.com.