嗨！
首先，该问题的具体解释如下：
Canonical 的 IP 91.189.88.162（security.ubuntu.com 解析到的六个 IP 之一）返回 HTTP 302 重定向到“http://179.184.158.89:80/pdata/05f7e7f89ba2302b/security.ubuntu.com/ubuntu/dists/xenial-security/InRelease“。该 IP 不属于任何官方 Ubuntu 镜像，并且 URI 包含某种标识符（它可能是跟踪代码，它会在每个请求中改变）。调查得出结论，这不是一个与软件/操作系统相关的问题（可以通过连接到 Telefonica 调制解调器的 Live USB 启动设备轻松重现。显然，它无法在其他任何地方重现）。
Canonical 的存储库在任何情况下都应该表现得如此吗？Pcap 示例附在本消息末尾。模仿“apt-get update”的手动 HTTP 请求：
george@workstation-04:~$ GET -USed -H "Host: security.ubuntu.com" -H "User-Agent: Debian APT-HTTP/1.3 (1.2.24)" http://91.189.88.162/ubuntu/dists/xenial-security/InRelease
GET http://91.189.88.162/ubuntu/dists/xenial-security/InRelease
Host: security.ubuntu.com
User-Agent: Debian APT-HTTP/1.3 (1.2.24)
302 Found
Cache-Control: no-cache
Connection: close
Location: http://179.184.158.89:80/pdata/05f4cdcfbada50fc/security.ubuntu.com/ubuntu/dists/xenial-security/InRelease
Content-Length: 0
Content-Type: text/html
Client-Date: Sat, 25 Nov 2017 20:44:04 GMT
Client-Peer: 91.189.88.162:80
Client-Response-Num: 1
X-Content-Type-Options: nosniff
GET http://179.184.158.89:80/pdata/05f4cdcfbada50fc/security.ubuntu.com/ubuntu/dists/xenial-security/InRelease
User-Agent: Debian APT-HTTP/1.3 (1.2.24)
200 OK
Cache-Control: max-age=1144, s-maxage=3300, proxy-revalidate
Connection: close
Date: Sat, 25 Nov 2017 20:13:04 GMT
Accept-Ranges: bytes
ETag: "18ef2-55ed440fdb600"
Server: nginx
Content-Length: 102130
Expires: Sat, 25 Nov 2017 21:05:00 GMT
Last-Modified: Sat, 25 Nov 2017 20:10:00 GMT
Client-Date: Sat, 25 Nov 2017 20:44:05 GMT
Client-Peer: 179.184.158.89:80
Client-Response-Num: 1
X-OC-Service-Type: re
现在来看看长而全面的版本（彻底的分析，如果你根据以上信息已经弄清楚了哪里出了问题，就没有必要阅读了）：
昨天在对我的一台虚拟机进行例行检查时，一些奇怪的事情引起了我的注意：
root@workstation-03:/# apt-get update ; apt-get upgrade -y
Hit:1 http://br.archive.ubuntu.com/ubuntu xenial InRelease
Get:2 http://br.archive.ubuntu.com/ubuntu xenial-updates InRelease [102 kB]
Get:3 http://br.archive.ubuntu.com/ubuntu xenial-backports InRelease [102 kB]
Get:5 http://br.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages [668 kB]
Ign:6 http://winswitch.org xenial InRelease
Get:7 http://br.archive.ubuntu.com/ubuntu xenial-updates/main i386 Packages [630 kB]
Hit:8 http://winswitch.org xenial Release
Get:10 http://br.archive.ubuntu.com/ubuntu xenial-updates/main amd64 DEP-11 Metadata [307 kB]
Get:11 http://br.archive.ubuntu.com/ubuntu xenial-updates/main DEP-11 64x64 Icons [227 kB]
Get:4 http://179.184.158.91:80/pdata/03ee5d7e461a5049/security.ubuntu.com/ubuntu xenial-security InRelease [102 kB]**
Get:12 http://br.archive.ubuntu.com/ubuntu xenial-updates/universe amd64 Packages [555 kB]
Get:13 http://br.archive.ubuntu.com/ubuntu xenial-updates/universe i386 Packages [527 kB]
Get:14 http://br.archive.ubuntu.com/ubuntu xenial-updates/universe amd64 DEP-11 Metadata [185 kB]
Get:16 http://br.archive.ubuntu.com/ubuntu xenial-updates/universe DEP-11 64x64 Icons [263 kB]
Get:17 http://br.archive.ubuntu.com/ubuntu xenial-updates/multiverse amd64 DEP-11 Metadata [5.888 B]
Get:18 http://br.archive.ubuntu.com/ubuntu xenial-backports/main amd64 DEP-11 Metadata [3.324 B]
Get:19 http://br.archive.ubuntu.com/ubuntu xenial-backports/universe amd64 DEP-11 Metadata [4.588 B]
Get:15 http://179.184.158.91:80/pdata/03ee827eaa21046b/security.ubuntu.com/ubuntu xenial-security/main amd64 DEP-11 Metadata [60,3 kB]
Get:20 http://179.184.158.91:80/pdata/03ee977e21229dae/security.ubuntu.com/ubuntu xenial-security/main DEP-11 64x64 Icons [57,6 kB]
Get:21 http://179.184.158.91:80/pdata/03eeaa7e9723e1be/security.ubuntu.com/ubuntu xenial-security/universe amd64 DEP-11 Metadata [51,4 kB]
Get:22 http://179.184.158.91:80/pdata/03eef57e5c24a1d6/security.ubuntu.com/ubuntu xenial-security/universe DEP-11 64x64 Icons [85,1 kB]**
Fetched 3.937 kB in 3s (1.115 kB/s)
Reading package lists... Done
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
...
我不知道“179.184.158.91”来自哪里，此虚拟机中只安装了一个非官方存储库（winswitch），但 xenial-security 调用了此 IP 地址。此外，它似乎带有唯一标识符，如“03ee827eaa21046b”。
附加信息：
猫/etc/apt/sources.list
deb http://br.archive.ubuntu.com/ubuntu/ xenial main restricted
deb-src http://br.archive.ubuntu.com/ubuntu/ xenial main restricted
deb http://br.archive.ubuntu.com/ubuntu/ xenial-updates main restricted
deb-src http://br.archive.ubuntu.com/ubuntu/ xenial-updates main restricted
deb http://br.archive.ubuntu.com/ubuntu/ xenial universe
deb-src http://br.archive.ubuntu.com/ubuntu/ xenial universe
deb http://br.archive.ubuntu.com/ubuntu/ xenial-updates universe
deb-src http://br.archive.ubuntu.com/ubuntu/ xenial-updates universe
deb http://br.archive.ubuntu.com/ubuntu/ xenial multiverse
deb-src http://br.archive.ubuntu.com/ubuntu/ xenial multiverse
deb http://br.archive.ubuntu.com/ubuntu/ xenial-updates multiverse
deb-src http://br.archive.ubuntu.com/ubuntu/ xenial-updates multiverse
deb http://br.archive.ubuntu.com/ubuntu/ xenial-backports main restricted universe multiverse
deb-src http://br.archive.ubuntu.com/ubuntu/ xenial-backports main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu xenial-security main restricted
deb-src http://security.ubuntu.com/ubuntu xenial-security main restricted
deb http://security.ubuntu.com/ubuntu xenial-security universe
deb-src http://security.ubuntu.com/ubuntu xenial-security universe
deb http://security.ubuntu.com/ubuntu xenial-security multiverse
deb-src http://security.ubuntu.com/ubuntu xenial-security multiverse
猫/etc/apt/sources.list.d/*
root@workstation-03:~# cat /etc/apt/sources.list.d/*
deb http://winswitch.org/ xenial main
所有已安装的存储库都无法解析该 IP：
george@workstation-03:~$ dig A security.ubuntu.com +short
91.189.91.23
91.189.88.149
91.189.91.26
91.189.88.152
91.189.88.162
91.189.88.161
george@workstation-03:~$ dig A winswitch.org +short
78.129.163.65
反向 IP 查找工具也无法找到任何可解析该 IP 的 FQDN 地址。
该 IP 由我的 ISP（Telefonica）公布，但似乎被一家我从未听说过的小型提供商使用：
george@workstation-03:~$ whois 179.184.158.91 | grep owner:
owner: TELEFÔNICA BRASIL S.A
george@workstation-03:~$ host 179.184.158.91
91.158.184.179.in-addr.arpa domain name pointer imaxima.static.gvt.net.br.
我尝试立即重现该行为，但在 apt-get 更新期间该 IP 不再出现。
此虚拟机中没有任何类型的代理（系统范围或特定于应用程序）。此虚拟机通过 OPNSense 防火墙连接到互联网，未设置出站过滤。我确实尝试 tcpdump 流量，以便在注意到可疑地址后立即检查 apt-get 发送和接收的 HTTP 标头，但由于我不再能够重现该行为，因此什么也找不到。不过幸运的是，我昨晚再次运行了 apt-get update，那个奇怪的 IP 再次出现，尽管这次只有一行。
那时我启动了 Wireshark 并进行了整个捕获。事实证明这不是与 DNS 相关的异常（我之前已经通过查询我在这里设置的每个解析器确认了这一点，没有一个解析器返回“179.184.158.89”），security.ubuntu.com 解析到的六个 IP 中至少有一个（91.189.88.162）通过 HTTP 302 返回了该未知 URI。这是我测试的列表：
security.ubuntu.com. 383 IN A 91.189.88.149
security.ubuntu.com. 383 IN A 91.189.88.162 X
security.ubuntu.com. 383 IN A 91.189.88.152
security.ubuntu.com. 383 IN A 91.189.91.26
security.ubuntu.com. 383 IN A 91.189.91.23
security.ubuntu.com. 383 IN A 91.189.88.161
现在，我可以手动一致地重现该行为。我将 User-Agent 设置为“Debian APT-HTTP/1.3 (1.2.24)”，以转移对可能位于中间的假想蜜罐的注意力，以防万一：
george@workstation-04:~$ GET -USed -H "Host: security.ubuntu.com" -H "User-Agent: Debian APT-HTTP/1.3 (1.2.24)" http://91.189.88.162/ubuntu/dists/xenial-security/InRelease
GET http://91.189.88.162/ubuntu/dists/xenial-security/InRelease
Host: security.ubuntu.com
User-Agent: Debian APT-HTTP/1.3 (1.2.24)
302 Found
Cache-Control: no-cache
Connection: close
Location: http://179.184.158.89:80/pdata/05f4cdcfbada50fc/security.ubuntu.com/ubuntu/dists/xenial-security/InRelease
Content-Length: 0
Content-Type: text/html
Client-Date: Sat, 25 Nov 2017 20:44:04 GMT
Client-Peer: 91.189.88.162:80
Client-Response-Num: 1
X-Content-Type-Options: nosniff
GET http://179.184.158.89:80/pdata/05f4cdcfbada50fc/security.ubuntu.com/ubuntu/dists/xenial-security/InRelease
User-Agent: Debian APT-HTTP/1.3 (1.2.24)
200 OK
Cache-Control: max-age=1144, s-maxage=3300, proxy-revalidate
Connection: close
Date: Sat, 25 Nov 2017 20:13:04 GMT
Accept-Ranges: bytes
ETag: "18ef2-55ed440fdb600"
Server: nginx
Content-Length: 102130
Expires: Sat, 25 Nov 2017 21:05:00 GMT
Last-Modified: Sat, 25 Nov 2017 20:10:00 GMT
Client-Date: Sat, 25 Nov 2017 20:44:05 GMT
Client-Peer: 179.184.158.89:80
Client-Response-Num: 1
X-OC-Service-Type: re
其余五个 IP 均返回 HTTP 200，据我所知，这是所有 IP 的预期行为。例如：
george@core-workstation:~$ GET -USed -H "Host: security.ubuntu.com" -H "User-Agent: Debian APT-HTTP/1.3 (1.2.24)" http://91.189.88.161/ubuntu/dists/xenial-security/InRelease
GET http://91.189.88.161/ubuntu/dists/xenial-security/InRelease
Host: security.ubuntu.com
User-Agent: Debian APT-HTTP/1.3 (1.2.24)
200 OK
Cache-Control: max-age=1271, s-maxage=3300, proxy-revalidate
Connection: close
Date: Sun, 26 Nov 2017 23:34:48 GMT
Accept-Ranges: bytes
ETag: "18ef2-55eeac2604300"
Server: Apache/2.4.18 (Ubuntu)
Content-Length: 102130
Expires: Sun, 26 Nov 2017 23:56:00 GMT
Last-Modified: Sun, 26 Nov 2017 23:01:00 GMT
Client-Date: Sun, 26 Nov 2017 23:33:34 GMT
Client-Peer: 91.189.88.161:80
Client-Response-Num: 1
如您所见，Canonical 的 IP 91.189.88.162 本身正在返回指向该可疑 IP 的 HTTP 302 重定向。由于此异常可从我的任何一台虚拟机中重现，甚至可以从我放在旁边的旧笔记本电脑上的实时操作系统中重现，该笔记本电脑直接插入 Telefonica 的调制解调器，因此我得出结论，这也与我的防火墙无关。尽管 Telefonica 的设备位于我的客厅中，但它位于我网络的安全范围之外，因此不会受到审计或其他任何影响。无论如何，我不认为这是罪魁祸首，因为它是一台非常便宜的 DSL-2730E ADSL2+ 路由器，没有配置自定义静态路由。我将在某天尝试桥接它，看看情况是否会有所改变。
奇怪的是，与所有其他请求不同，该 302 响应不带有 Web 服务器签名，这让我相信中间的某个东西可能正在拦截发往该特定 IP 和端口的数据包。以下是从我在加拿大拥有的服务器中获取的示例，其中清楚地显示了“服务器”标头：
root@server-1:~# GET -USed -H "Host: security.ubuntu.com" -H "User-Agent: Debian APT-HTTP/1.3 (1.2.24)" http://91.189.88.162/ubuntu/dists/xenial-security/InRelease
GET http://91.189.88.162/ubuntu/dists/xenial-security/InRelease
Host: security.ubuntu.com
User-Agent: Debian APT-HTTP/1.3 (1.2.24)
200 OK
Cache-Control: max-age=0, s-maxage=3300, proxy-revalidate
Connection: close
Date: Mon, 27 Nov 2017 05:48:29 GMT
Accept-Ranges: bytes
ETag: "18ef2-55eef9eebc700"
Server: Apache/2.4.18 (Ubuntu)
Content-Length: 102130
Expires: Mon, 27 Nov 2017 05:48:29 GMT
Last-Modified: Mon, 27 Nov 2017 04:49:00 GMT
Client-Date: Mon, 27 Nov 2017 05:48:29 GMT
Client-Peer: 91.189.88.162:80
Client-Response-Num: 1
但是，简而言之，进一步尝试对 91.189.88.162 后面的服务器进行指纹识别未能证明流量被篡改。TCPtraceroute 和 mtr 都显示预期的路由，与 91.189.88.161（这六个中的一个，也位于伦敦）相比，HTTP 延迟在 5% 以内。Nmap 探测也表明我正在访问 Canonical 的服务器（除非这是一次精心策划的 MITM 攻击，但似乎并非如此）。我也没有看到 BGP 劫持的证据，路由没有问题：
show route protocol bgp 91.189.88.162 | no-more
inet.0: 688953 destinations, 2269968 routes (688942 active, 0 holddown, 4860 hidden)
+ = Active Route, - = Last Active, * = Both
91.189.88.0/24 *[BGP/170] 2w0d 17:19:51, MED 0, localpref 85, from 94.142.108.190
AS path: 3356 41231 I, validation-state: unverified
to 5.53.3.85 via ae11.0
to 5.53.3.79 via ae17.0
> to 5.53.3.223 via et-9/3/0.0
[BGP/170] 2w0d 17:20:31, MED 0, localpref 85, from 94.142.108.210
AS path: 3356 41231 I, validation-state: unverified
to 5.53.3.85 via ae11.0
to 5.53.3.79 via ae17.0
> to 5.53.3.223 via et-9/3/0.0
[BGP/170] 5d 02:34:24, MED 0, localpref 85, from 94.142.108.193
AS path: 3356 41231 I, validation-state: unverified
to 5.53.3.85 via ae11.0
to 5.53.3.79 via ae17.0
> to 5.53.3.223 via et-9/3/0.0
针对端口 80 的 Tcptraceroute：
george@workstation-04:/$ tcptraceroute -w1 91.189.88.162 80
Selected device enp0s3, address 10.4.4.119, port 47917 for outgoing packets
Tracing the path to 91.189.88.162 on TCP port 80 (http), 30 hops max
1 10.4.4.200 0.295 ms 0.220 ms 0.306 ms
2 192.168.25.1 1.938 ms 2.106 ms 1.883 ms
3 gvt-b-sr01.cta.gvt.net.br (179.184.120.13) 20.106 ms 22.429 ms 19.890 ms
4 201.22.69.21.dynamic.adsl.gvt.net.br (201.22.69.21) 20.087 ms 20.514 ms 20.716 ms
5 201.22.64.99.dynamic.dialup.gvt.net.br (201.22.64.99) 27.391 ms 28.520 ms 28.410 ms
6 213.140.39.82 27.475 ms 28.178 ms 27.646 ms
7 5.53.3.143 143.486 ms 142.026 ms 142.533 ms
8 * * *
9 ae-126-3512.edge5.london1.Level3.net (4.69.166.45) 271.503 ms 268.769 ms 268.715 ms
10 SOURCE-MANA.edge5.London1.Level3.net (212.187.138.82) 291.886 ms 271.616 ms 273.050 ms
11 yukinko.canonical.com (91.189.88.162) [open] 281.588 ms 273.400 ms 273.496 ms
当我开始研究这个问题时，我家附近停电了（这种情况本身就非常罕见。加油，墨菲！）。3 小时后，电力恢复，我重新启动了所有虚拟机，但有一个虚拟机无法正常启动。猜猜是哪一个？没错。
顺便说一句，这恰好是我家里唯一的 Ubuntu 16.04 VM。这种故障对于我的任何 VM 来说都是前所未有的，这真是一个天大的巧合。为了安全起见，我立即对其磁盘进行快照，并停用该 VM 以便稍后进行深入的取证分析。显然是 X11-Server 出了问题，它上次更新是在 2017-11-07。我稍后会研究一下，但我看不出这个重定向本身如何会导致这种情况发生。
值得注意的是，一旦电源恢复，我不再面临该问题，也就是说，对这六个 IP 的每个请求都会返回 HTTP 200，这是应该的。所以今天早些时候，我一直强制我的调制解调器重新启动其 PPPoE 身份验证，以获得新的动态 IP，然后我会再次检查这 6 个 IP，看看这种行为是否会再次出现。11 次重新连接后，宾果！91.189.88.162 开始向我抛出 HTTP 302。这是我每次重新连接后使用的 IP 列表（以防 Canonical 的前端中有一个 ACL 恰好出于某种原因故意操纵基于源 IP 的行为）。除了第一个和最后一个之外，其他都没有遇到 security.ubuntu.com 的任何问题：
191.250.187.149 (The one I was using when I started this topic)
177.132.10.0
187.112.57.37
186.212.197.62
177.132.109.6
187.112.135.18
201.86.5.226
201.86.5.226
201.86.5.226
189.115.80.207
177.133.196.249
177.16.143.235
177.204.139.117
179.182.184.0/24 (The IP I'm using now belongs to this subnet)
我从巴西的另一家 ISP 以及全球的几台服务器查询了 Canonical 的六个 IP，始终对每个目标 IP 执行 5 次查询，以排除不一致的情况。它们都没有返回 HTTP 302。从来没有。一次也没有。但是，在我的家庭连接中，每次针对 91.189.88.162 的尝试都会产生 HTTP 302，除非我每隔几秒钟继续尝试，在这种情况下它会返回 HTTP 200，就好像我绕过了某种缓存，尽管 302 响应中设置了“Cache-Control: no-cache”。很奇怪吧？
我邀请任何人尝试重现该行为，如果您遇到 302 重定向，请告诉我：
GET -USed -H "Host: security.ubuntu.com" -H "User-Agent: Debian APT-HTTP/1.3 (1.2.24)" http://91.189.88.162/ubuntu/dists/xenial-security/InRelease
我必须重申，我的情况中的这个目标 IP（179.184.158.89）不属于 Ubuntu 镜像列表中的任何公司，我只是不明白为什么它应该为我提供 InRelease 文件。这个地址分配给了距离这里 400 多公里的另一个州的一家小型 ISP。
底线是，如果这是故意设置的，用于收集统计数据（这甚至没有多大意义），那么可以肯定地说，这个实现得非常糟糕，因为它相当不稳定，并且只对 6 个 IP 中的一个有效（将随机或循环选择，因为它们无法管理本地 DNS 客户端如何处理它们，并且所有 6 个 A 记录共享相同的 TTL）。这留下了很多猜测的空间。
如果有人想看，这是 apt-get 更新期间获取的 pcap 文件。为了简单起见，我过滤掉了除 HTTP 请求之外的所有内容，但如果需要进行调试，我很乐意上传整个内容。感兴趣的数据包是 #6、#7 和 #9：
https://mega.nz/#!NORi2ALA!njJRKZ4i26GHXaET_ZA6Z4ymWYKhccTGNiEBCcGtwbA
SHA256：40fc995e505ee2dcaf9aa3e23961a757f628224e3fca83d0deed6374ba9a3fbe
我一定是忽略了一些东西... PS：我认为这更多的是一个隐私问题，而不是安全事件，无论如何这种行为都是没有记录的（谷歌找不到任何类似的东西）所以我决定和你们核实一下以确保安全。
任何帮助都非常感谢！感谢您坚持到现在！:)
答案1
X-OC-Service-Type 表示响应来自 Open Cache 节点。
ISP 使用 Qwilt 等公司提供的 Open Cache 服务器作为其网络上的透明缓存代理。您的请求被其路由节点拦截，并重定向到缓存节点。缓存节点没有缓存对象（“re”= 中继表示未命中；“lo”= 本地表示命中），因此理论上它会转到您请求的原始主机 + 路径来获取对象。
这实际上有可能是某种恶意拦截，但我猜测这只是 ISP 的代理。