[Oisf-users] Suricata 1.4 http keywords in rule options, how does matching occur for http_header?

[Brian Rectanus]

Hi Anoop,

I just glanced at the patch and I think it is only looking in the HTTP
header for the "host" header, but this is incorrect. as the host can
be in the request line as well.  You should be looking at the
normalized hostname in the htp_tx_t structure:

tx->parsed_uri->hostname

Additional unit tests should be there to test these, where hostname
should be "www.foo.com" in all cases:

# HTTP/1.0 with no host header
GET http://www.foo.com/ HTTP/1.0

# HTTP/1.1 with correct host data in both url and header
GET http://www.foo.com/ HTTP/1.1
Host: www.foo.com

# HTTP/1.1 with mismatched host data (uri wins)
GET http://www.foo.com/ HTTP/1.1
Host: www.bar.com

# HTTP/1.1 without host header (illegal, but may work)
GET http://www.foo.com/ HTTP/1.1

In addition to those above, you can also have a port in there in each
above, but the hostname should still be "www.foo.com".  For example,
add a redundant port 80:

GET http://www.foo.com:80/ HTTP/1.1
Host: www.foo.com:80

And don't forget multiple host headers (also illegal, I think, but
probably will work for many servers) - still "www.foo.com":

GET http://www.foo.com:80/ HTTP/1.1
Host: www.bar.com
Host: another.bogus.host:1234

Cheers!
-B

On Fri, Jan 25, 2013 at 7:19 AM, Anoop Saldanha <anoopsaldanha at gmail.com> wrote:
> Try this patch out(you can apply the patch using "git am -3 <patch>")
>
> It introduces a new keyword + pcre modifier that would inspect just
> the host header.
>
> The keyword being "http_host" and the pcre modifier being "W"
>
> You can now use it in a rule like this -
>
> alert ip $HOME_NET any -> any any (msg:"pcre version rule fired";
> pcre:"/\.businessweek.com/W"; sid:1;)
> alert ip $HOME_NET any -> any any (msg:"http header rule fired";
> content:".businessweek.com"; http_host; sid:2;)
>
> Let me know how it works with the above rules.
>
> On Fri, Jan 25, 2013 at 8:47 AM, Anoop Saldanha <anoopsaldanha at gmail.com> wrote:
>> On Thu, Jan 24, 2013 at 10:29 PM, Vincent Fang <vincent.y.fang at gmail.com> wrote:
>>> Here's the new results, I will run the tests again to see if it's consistent
>>> but using the wireshark filter
>>>
>>> http contains "businessweek.com"
>>>
>>> there were 75 matches
>>>
>>> and in the fast.log there were 138 total alerts from the two new rules you
>>> specified
>>> grep -c "http header" fast.log -> 69 lines
>>> grep -c "pcre version" fast.log -> 69 lines
>>>
>>> so they're both the same. Ran suricata in offline mode and the results were
>>> the same so that's good since they're consistent.
>>>
>>> Here's a copy of the two rules
>>>
>>> alert ip $HOME_NET any -> any any (msg:"pcre version rule fired";
>>> pcre:"/\s.*?\.businessweek.com/H"; sid:1;)
>>>
>>> alert ip $HOME_NET any -> any any (msg:"http header rule fired";
>>> content:".businessweek.com"; http_header; sid:2;)
>>>
>>> In the next few runs I also plan to change the protocol to http instead of
>>> ip, and I technically should get the same numbers yes?
>>>
>>
>> Yes, you should.
>>
>> Keep in mind that the above rules can also match on other headers
>> containing businessweek.com, for example the referer header.
>>
>>>
>>> On Thu, Jan 24, 2013 at 9:44 AM, Anoop Saldanha <anoopsaldanha at gmail.com>
>>> wrote:
>>>>
>>>> Sound good.  Will open a feature request for "http_host" keyword;
>>>>
>>>> On Thu, Jan 24, 2013 at 7:45 PM, Matt <matt at somedamn.com> wrote:
>>>> > I would find that useful, especially if it increases efficiency in the
>>>> > same
>>>> > way as http_user_agent.  Among other things, I use Suricata to match
>>>> > blacklists of known bad URLs, and all those rules include a content
>>>> > match
>>>> > for the HTTP Host.
>>>> >
>>>> > Matt
>>>> >
>>>> > On 1/24/2013 3:13 AM, Peter Manev wrote:
>>>> >
>>>> >
>>>> >
>>>> > On Thu, Jan 24, 2013 at 9:11 AM, Anoop Saldanha
>>>> > <anoopsaldanha at gmail.com>
>>>> > wrote:
>>>> >>
>>>> >> On Thu, Jan 24, 2013 at 1:37 PM, Peter Manev <petermanev at gmail.com>
>>>> >> wrote:
>>>> >> >
>>>> >> >> However, any of the techniques mentioned above isn't a foolproof way
>>>> >> >> to match on the host header.  The right way would be to provide a
>>>> >> >> new
>>>> >> >> keyword called "http_host".
>>>> >> >>
>>>> >> > Anoop or Vincent would you please put in feature request for that?
>>>> >> >
>>>> >>
>>>> >> We should probably consult users/rule-writers if such a keyword would
>>>> >> be useful to them?
>>>> >>
>>>> >> --
>>>> >> Anoop Saldanha
>>>> >
>>>> > sure
>>>> >
>>>> >
>>>> > --
>>>> > Regards,
>>>> > Peter Manev
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > 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
>>>> > OISF: http://www.openinfosecfoundation.org/
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Anoop Saldanha
>>>> _______________________________________________
>>>> 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
>>>> OISF: http://www.openinfosecfoundation.org/
>>>
>>>
>>
>>
>>
>> --
>> Anoop Saldanha
>
>
>
> --
> Anoop Saldanha
>
> _______________________________________________
> 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
> OISF: http://www.openinfosecfoundation.org/