On Thu, Sep 27, 2012 at 8:50 AM, Willy Tarreau <[email protected]> wrote:
> OK but is there always only one XFF header when this happens or do you
> notice a second XFF header ? The difference is important, not from an
> HTTP point of view but due to how the captures work in haproxy, since
> they take a full header line only. What I suspect is that you have one
> XFF header with 3-4 IPs and another header with a single IP which gets
> logged.
you suspected correctly :) looks like a misconfigured or otherwise
misbehaving Squid (or Squid derivative) in the mix somewhere:
====
User-Agent: Mozilla/4.5 (compatible; HTTrack 3.0x; Windows 98)
Accept: image/png, image/jpeg, image/pjpeg, image/x-xbitmap,
image/svg+xml, image/gif;q=0.9, */*;q=0.1
Accept-Language: en, *
Accept-Charset: iso-8859-1, iso-8859-*;q=0.9, utf-8;q=0.66, *;q=0.33
Accept-Encoding: gzip, identity;q=0.9
Via: 1.1 172.19.134.2:3128 (squid/2.6.STABLE14)
X-Forwarded-For: 127.0.0.1
Cache-Control: max-age=259200
X-Forwarded-For: 12.130.106.102
X-Forwarded-For: 10.1.253.2
====
surprisingly, Apache was able to correctly reassemble that mess into a
reasonable-looking log message (this log message doesn't correspond
exactly to the pcap above, but it's representative):
====
127.0.0.1, 12.130.106.102, 10.1.253.2, 10.1.5.16 127.0.0.1 -
[30/Sep/2012:04:04:05 +0000] "GET / HTTP/1.0" 200 837 "-" "Mozilla/4.5
(compatible; HTTrack 3.0x; Windows 98)"
====
turns out that we were already getting somewhat better information in
the Apache logs, so I decided to just have Apache log to a local
syslog-ng, apply a filter, and send the results to a central server
(just as I'd been doing with haproxy).
thanks for helping me think through this.
--
Scott Francis | darkuncle(at)darkuncle(dot)net | 0x5537F527
Less and less is done
until non-action is achieved
when nothing is done, nothing is left undone.
-- the Tao of Sysadmin
