tickets #105807
closed2001:db8:: clients on pontifex ?
Added by pjessen over 2 years ago. Updated over 2 years ago.
100%
Description
This was originally described in #104712, but I thought it best to have a separate ticket.
The IPv6 prefix 2001:db8::/32 is reserved for documentation purposes, see RFC3849.
Nonetheless, I see such addresses logged in the apache logs on pontifex, steady rate of 300-500 per day.
Updated by pjessen over 2 years ago
- Related to tickets #104712: pontifex apache logs - why are there ipv4 client addresses in the ipv6 logs? added
Updated by pjessen over 2 years ago
- Private changed from Yes to No
A tcpdump on 'net 2001:db8::/32' shows nothing.
I have now added the following to the Apache config:
<RequireAll>
Require all granted
Require not ip 2001:db8::/32
</RequireAll>
2001:db8::/32 is most definitely not supposed to be seen 'in the wild', so in principle the above ought to change nothing.
Updated by pjessen over 2 years ago
Well, a few blocked requests already: (slightly edited):
Address User-Agent X-ZYpp-DistributionFlavor
2001:db8:5b2b:daae:5e6e:61b:b39:f1c8 "ZYpp 17.11.4 (curl 7.60.0) openSUSE-Leap-15.1-x86_64" "dvd"
2001:db8:5b2b:daae:5e6e:61b:b39:f1c8 "ZYpp 17.11.4 (curl 7.60.0) openSUSE-Leap-15.1-x86_64" "dvd"
2001:db8:74f7:7077:1b33:688e:b39:f1c8 "ZYpp 17.11.4 (curl 7.60.0) openSUSE-Leap-15.1-x86_64" "dvd"
2001:db8:74f7:7077:1b33:688e:b39:f1c8 "ZYpp 17.11.4 (curl 7.60.0) openSUSE-Leap-15.1-x86_64" "dvd"
2001:db8:ac:a76d:5852:43b9:b39:f1c8 "ZYpp 17.11.4 (curl 7.60.0) openSUSE-Leap-15.1-x86_64" "dvd"
2001:db8:ac:a76d:5852:43b9:b39:f1c8 "ZYpp 17.11.4 (curl 7.60.0) openSUSE-Leap-15.1-x86_64" "dvd"
A leap 15.1 system ? Only part of the address seems to change, the b39:f1c8 part remains the same.
Updated by pjessen over 2 years ago
Since midnight (when the log was rotated), I see 252 requests having been given a 403, due to my Require. In a way that is fine, but I had a tcpdump running all of last night, "tcpdump -n -i any net 2001:db8::/32" and it showed nothing.
Currently the last such request was at 09:57:30 UTC, I have added a DROP of 2001:db8::/32 to the firewall, although I can't see how it will help when I can't catch anything with tcpdump.
Updated by pjessen over 2 years ago
- Assignee set to pjessen
pjessen wrote:
Currently the last such request was at 09:57:30 UTC, I have added a DROP of 2001:db8::/32 to the firewall, although I can't see how it
will help when I can't catch anything with tcpdump.
Yep, that did nothing. So, those 2001:db8 addresses must be put there by Apache, maybe from some proxy field or something like that.
Updated by pjessen over 2 years ago
pjessen wrote:
So, those 2001:db8 addresses must be put there by Apache, maybe from some proxy field or something like that.
I wonder if this might be where they are coming from:
<IfModule mod_remoteip.c>
RemoteIPHeader X-Forwarded-For
</IfModule>
Updated by pjessen over 2 years ago
By adding some logging, specifically to log the original client IP address with '%{c}a', I see loads of address using X-Forwarded-For, but specifically to 2001:db8 :
2001:db8:6d2b:5e5:7539:7680:496f:6c13 - 168.149.167.59
2001:db8:49f9:9278:5c10:82b7:496f:6c13 - 168.149.166.133
2001:db8:a76:1fcf:239e:1bbc:6552:a63d - 148.64.12.119
However, there are many other addresses that use X-Forwarded-For - I count 386 sofar.
Updated by pjessen over 2 years ago
There appears to be a number of clients that specify 2001:db8 in their X-Forwarded-For, from a couple of hours of log today:
148.64.12.119 - Avago Technologies U.S. Inc
148.64.12.133
148.64.12.58
148.64.15.192
168.149.146.109 - Avago Technologies U.S. Inc
168.149.166.133
168.149.166.43
168.149.167.59
199.247.45.220 - Avago Technologies U.S. Inc
For the time being, I am going to lift my client restriction, see comment#2 above.
I don't think it makes sense for us to use 'X-Forwarded-For' when it comes from other clients, in particular not when the contents are rubbish.
Updated by pjessen over 2 years ago
- Status changed from New to Resolved
- % Done changed from 0 to 100
Problem fixed - the 2001:db8 addresses were due to us accepting 'X-Forwarded-For' from anyone, and obviously there are some poorly configured clients out there.
I tried changing the haproxy config on anna and elsa to remove 'X-Forwarded-For' (using http-request del-header), but somehow it did not work. Instead I changed 'X-Forwarded-For' to 'X-Forwarded-999' in both haproxy and in apache@pontifex, and that has done the job.