information on mod_usertrack, akamai, and caching proxies

I found the following information to be missing from the mod_usertrack docs. I’m putting it here so I don’t forget this semi-useful information. Hopefully it will also save someone else the need to read through the source code to figure this stuff out. (as a side note, I dislike reading through C code)

This information applies to the current releases of apache httpd (2.2.8, 2.0.63, and 1.3.4). Considering mod_usertrack hasn’t seen any signficant changes in years, I can’t imagine this will be outdated anytime soon.

  • mod_user track generates cookie whose contents are IP + timestamp. I.E. if the IP which generates the request is 10.0.0.1 and the current unix time is 120658819, the cookie will contain: 10.0.0.1.120658819

  • mod_usertrack generates this string for the cooking by calling ap_get_remote_host() and concatenating the results with apr_time_now()
  • ap_get_remote_host() will returns the DNS name or the IP address of the remote host. It determines this IP based on the TCP/IP connection and NOT from the HTTP headers at Layer 7.
  • As a result, if users access your web server via akamai’s content delivery network, a caching proxy, or some other intermediary the IP that returned by ap_get_remote_host() will not be the IP of the user. It will be the IP of the the intermediary (ie akamai edge server, proxy server, etc). You should therefore not count on this being the actual users IP. Get that information from the HTTP headers if you can. This will often be preserved in X-Forwarded-For, as well as other places.
  • I REPEAT DO NOT COUNT ON THIS TO BEING THE ACTUAL USERS IP ADDRESS. People seem to do this quite often, even though the documentation DOES NOT say you can count on it being the users IP, or even that the cookie will contain the users IP.
  • If enough users are accessing your server via the same proxy/akamai edge server/other intermediary it is possible that 2 users will end up with the same cookie value. Therefore it is theoretically possible for this value to not be unique to an individual user. Not to mention that even if it were the remote users IP, it could still be non-unique if multiple users are located behind a nat.

With all of the above items in mind, there are patches which exist to have mod_usertrack make use of X-Forwarded-For and/or mod_uuid to generate the cookie value. I’m currently working on a patch to make this a configuration directive via the apache config file. However, considering that these other patches have existed for years and have not been integrated, I have little to no hope that our patch would be.

3 Responses to “information on mod_usertrack, akamai, and caching proxies”

  1. ripper234 says:

    For anyone finding this post in the year 2013 and beyond:

    Don’t bother with mod_usertrack for this. Just switch to using an external module – https://github.com/jib/mod_cookietrack/

    I’ve tested this with apache 2.2, it simply works. Super easy compile, install & configure, well documented, fully support the same config syntax as CookieTrack.

    Esentially, it’s CookieTrack++.

  2. Ilan says:

    Thanks for the tip. Looks interesting.

  3. Bess Villano says:

    Neat article, I’ve been interested in web security mechanisms for a few years now.

Leave a Reply