2014-12-10 01:05 PM
Recently we noticed that some sessions (not all) that contain HTTP requests with an IP address in the "Host" header are not getting populated with the alias.host meta. My question is: how does the HTTP parser decide what value to assign to that meta? Also, is this common or expected behavior?
If it helps, many of the sessions with this issue are very simple. A completely fabricated, but syntactically accurate example:
POST / HTTP/1.0
Accept: */*
Content-Type: application/octet-stream
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Win32)
Host: 1.2.3.4
Content-length: 90
Connection: Keep-Alive
something://hostname.domain.tld/secretkey
All of this is happening on the latest 9.8 stack. Not all sessions on each decoder are affected. Thanks in advance for your help.
2014-12-11 02:46 PM
Short answer: it is expected.
Long answer:
The native OOTB parser 'HTTP' will register whatever is in a HOST: header as alias.host meta - whether it is or not. That can cause problems down the line with feeds, app rules, etc. Even the TLD parser would get an ip address in an alias.host meta and register the last quad as tld meta - which caused many calls to Support.
So that was corrected in http-flex. It determines if the value of a host header is a hostname, IPv4, or IPv6 and registers it appropriately (alias.host, alias.ip, or alias.ipv6, respectively). HTTP_lua does the same.
So for the session above, you should see alias.ip meta containing "1.2.3.4"
2014-12-11 02:23 PM
Is with the native HTTP parser or the http.lua parser?
2014-12-11 02:46 PM
Short answer: it is expected.
Long answer:
The native OOTB parser 'HTTP' will register whatever is in a HOST: header as alias.host meta - whether it is or not. That can cause problems down the line with feeds, app rules, etc. Even the TLD parser would get an ip address in an alias.host meta and register the last quad as tld meta - which caused many calls to Support.
So that was corrected in http-flex. It determines if the value of a host header is a hostname, IPv4, or IPv6 and registers it appropriately (alias.host, alias.ip, or alias.ipv6, respectively). HTTP_lua does the same.
So for the session above, you should see alias.ip meta containing "1.2.3.4"
2014-12-11 03:20 PM
awesome, thanks for replying. For what it's worth, it might be helpful for this parser to indicate somehow (if not with the alias.host meta, somewhere else) that the Host: header contained an IP address. We can definitely write a parser to do this ourselves, but it seems more efficient for this one to do it. Some food for thought for a future release.
thanks again!
2014-12-11 03:31 PM
HTTP_lua will register a risk.info "http direct to ip request"
http-flex doesn't. But there is a separate flex parser ("http_header") in Live that registers the same as well risk meta for many other HTTP anomalies - most all of which are were also included in HTTP_lua.
2014-12-11 03:57 PM
just to clarify - everything you said applies to 9.8?
2014-12-11 04:11 PM
9.8 can't use HTTP_lua. So you'll want to use http_header to get the "direct to ip" alert.
Once you're at 10.2 or higher, you'll want to use HTTP_lua instead of HTTP, http-flex, http_header, et al.