Xenial: code étrange et repo pendant la mise à jour
Hy!
Tout d'abord, l'explication de la question par le Dr.:
L’IP 91.189.88.162 de Canonical (l’un des six IP résolus par security.ubuntu.com) renvoie une redirection HTTP 302 vers " http://179.184.158.89:80/pdata/05f7e7f89ba2302b/security.ubuntu.com/ubuntu/dists/xenial-security/InRelease ". Cette adresse IP n'appartient à aucun miroir officiel Ubuntu et l'URI contient une sorte d'identifiant (il peut s'agir d'un code de suivi, il modifie chaque demande). L'enquête a permis de conclure qu'il ne s'agissait pas d'un problème lié au logiciel/système d'exploitation (facilement reproductible à partir d'un ordinateur portable différent, démarré à partir d'une clé USB Live connectée au modem de Telefonica. Il ne peut apparemment pas être reproduit ailleurs).
Les référentiels de Canonical sont-ils supposés se comporter de la sorte en quelque circonstance que ce soit? Exemple Pcap attaché à la fin de ce message. Requête HTTP manuelle imitant "apt-get update":
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
Passons maintenant à la version longue et complète (analyse approfondie, lecture inutile si vous avez compris ce qui ne va pas grâce aux informations ci-dessus):
Lors d'une vérification de routine effectuée sur l'un de mes ordinateurs virtuels hier, quelque chose d'étrange a attiré mon attention:
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
...
Je ne vois pas d'où venait ce "179.184.158.91", il n'y a qu'un seul dépôt non officiel installé dans ce VM (winswitch), mais xenial-security est ce qui appelle cette adresse IP. De plus, il semble porter des identifiants uniques tels que "03ee827eaa21046b".
Information additionnelle:
cat /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
cat /etc/apt/sources.list.d/*
root@workstation-03:~# cat /etc/apt/sources.list.d/*
deb http://winswitch.org/ xenial main
Aucun des dépôts installés ne se résout en 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
Les outils de recherche IP inversée ne parviennent pas non plus à trouver une adresse FQDN correspondant à cette adresse IP.
Cette adresse IP est annoncée par mon fournisseur de services Internet (Telefonica), mais semble être utilisée par un petit fournisseur dont je n'avais jamais entendu parler jusqu'à présent:
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.
J'ai essayé de reproduire ce comportement immédiatement après, mais cette adresse IP ne figurait plus lors de la mise à jour d'apt-get.
Il n'y a pas de proxy d'aucune sorte dans cette VM (spécifique au système ou à l'application). Cette VM se connecte à Internet via un pare-feu OPNSense. Aucun filtrage sortant n'est configuré. J'ai essayé de tcpdump le trafic afin de vérifier les en-têtes HTTP envoyés et reçus par apt-get dès que j'ai remarqué l'adresse suspecte, mais comme je n'étais plus en mesure de reproduire ce comportement, rien ne se produisait. Heureusement, cependant, j’ai lancé à nouveau une mise à jour d’apt-get la nuit dernière et cette adresse IP étrange est de nouveau apparue, bien qu’en une seule ligne cette fois-ci.
À ce moment, j'ai mis le feu à Wireshark et effectué toute la capture. Comme il s’avère que ce n’est pas une anomalie liée au DNS (je l’avais déjà confirmé en interrogeant tous les résolveurs que j’ai configurés ici, aucun d’entre eux n’a renvoyé "179.184.158.89"), au moins un des six IP de sécurité .ubuntu.com résout en (91.189.88.162) renvoyant cet URI inconnu via HTTP 302. Voici la liste que j'ai testée:
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
Je peux maintenant systématiquement reproduire le problème manuellement. J'ai défini User-Agent sur "Debian APT-HTTP/1.3 (1.2.24)" afin de détourner le moins du monde l'attention d'un faux pot de miel hypothétique qui pourrait se trouver quelque part entre les deux, juste au cas où:
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
Toutes les cinq adresses IP restantes renvoient HTTP 200, ce qui est le comportement attendu pour toutes, à ma connaissance. Par exemple:
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
Comme vous pouvez le constater, l'adresse IP 91.189.88.162 de Canonical renvoie elle-même une redirection HTTP 302 vers cette adresse IP suspecte. Comme cette anomalie est reproductible à partir de n'importe laquelle de mes machines virtuelles et même d'un système d'exploitation actif sur un vieil ordinateur portable que je traîne alors que je suis branché directement au modem de Telefonica, j'ai conclu que cela n'était pas lié à mon pare-feu. Même si l'équipement de Telefonica se trouve dans mon salon, il se trouve en dehors du périmètre sécurisé de mon réseau et n'est donc pas audité. Quoi qu'il en soit, je ne crois pas que ce soit le coupable puisqu'il s'agit d'un routeur ADSL2 + ADSL2 + DSL-2730E bon marché, sans route statique personnalisée configurée. Je vais essayer de faire le pont un de ces jours pour voir si les choses changent.
Curieusement, cette réponse 302 ne porte pas la signature du serveur Web, contrairement à toutes les autres demandes qui lui sont adressées, ce qui m'a amené à penser que quelque chose entre ces deux méthodes pourrait intercepter des paquets vers cette adresse IP et ce port. Voici un exemple tiré d'un serveur que je possède au Canada et qui montre clairement l'en-tête "Server":
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
Toutefois, pour résumer, de nouvelles tentatives d'empreinte de ce serveur derrière le numéro 91.189.88.162 n'ont pas permis de prouver que le trafic était falsifié. TCPtraceroute et mtr affichent tous les deux la route attendue, la latence HTTP est dans une marge de 5% par rapport à 91.189.88.161 (qui est un de ces six et est également située à Londres). Nmap probing suggère également que j'atteins le serveur Canonical (à moins qu'il ne s'agisse d'une attaque MITM très soigneusement conçue, ce qui ne semble pas être le cas). Je ne vois également aucune preuve de détournement de BGP et la route est bonne:
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
Tcptraceroute contre le port 80:
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
Alors que je commençais à creuser ce problème, le courant a été coupé dans mon quartier (ce qui est extrêmement rare en soi. Allez Murphy!). Une fois qu'il est revenu 3 heures plus tard, j'ai redémarré toutes mes machines virtuelles, à l'exception d'une machine qui n'a pas pu démarrer correctement. Devinez lequel? C'est vrai.
À propos, c’est le seul Ubuntu 16.04 VM que j’ai chez moi. Ce type d'échec est sans précédent pour aucun de mes ordinateurs virtuels, ce qui en fait une sacrée coïncidence. J'ai immédiatement procédé à la capture instantanée de son disque et ai mis hors service ledit VM pour une analyse médico-légale approfondie plus tard, juste pour être du bon côté. Apparemment, quelque chose s'est brisé sur le serveur X11, qui a été mis à jour pour la dernière fois le 2017-11-07. J'examinerai la question plus tard, mais je ne vois pas comment cette redirection à elle seule provoquerait cela.
Il convient de noter qu’une fois le courant rétabli, je n’étais plus confronté à ce problème, c’est-à-dire que chaque demande adressée aux six adresses IP renverrait HTTP 200 comme il se doit. Donc plus tôt dans la journée, j'ai continué à forcer mon modem à redémarrer son authentification PPPoE afin d'obtenir une nouvelle adresse IP dynamique, puis je vérifiais à nouveau ces 6 adresses IP pour voir si ce comportement se reproduirait. 11 se reconnecte plus tard, bingo! 91.189.88.162 a commencé à me lancer le HTTP 302. Voici la liste des adresses IP que j'utilisais après chaque reconnexion (au cas où il y aurait une ACL dans l'interface de Canonical qui manipule volontairement le comportement basé sur l'IP source, quelle qu'en soit la raison). Tous sauf le tout premier et dernier n'ont rencontré aucun problème avec 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)
J'ai interrogé les six adresses IP de Canonical d'un autre fournisseur d'accès au Brésil, ainsi que de plusieurs serveurs dans le monde, effectuant toujours 5 requêtes par adresse IP de destination afin d'éliminer les incohérences. Aucun d'entre eux n'a renvoyé HTTP 302. Jamais. Pas même une fois. Dans ma connexion à domicile, cependant, chaque tentative contre 91.189.88.162 génère HTTP 302 sauf si je continue à essayer à quelques secondes d'intervalle. Dans ce cas, il renverra HTTP 200 comme si je contournais une sorte de cache malgré le fait que "Cache- Contrôle: no-cache "est défini dans la réponse 302. Bizarre, hein?
J'invite tout le monde à essayer de reproduire ce comportement. Veuillez me prévenir si vous tombez sur cette redirection 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
Je dois réitérer que cette adresse IP de destination dans mon cas (179.184.158.89) n'appartient à aucune entreprise figurant sur la liste des miroirs d'Ubuntu. Je ne vois tout simplement pas pourquoi elle devrait me servir le fichier InRelease. . Cette adresse est allouée à un petit FAI dans un état différent à 400 km d'ici.
En bout de ligne, si cela est intentionnellement mis en place pour collecter des statistiques (ce qui n’aurait même pas beaucoup de sens), on peut affirmer que cela a été extrêmement mal mis en œuvre car il est assez erratique et ne fonctionne que pour un seul des 6 seront choisis au hasard ou à tour de rôle car ils ne peuvent pas gérer la façon dont le client DNS local les traitera et tous les enregistrements 6 A partagent le même TTL). Cela laisse beaucoup de place à la spéculation.
Au cas où quelqu'un voudrait le voir, voici le fichier pcap pris lors d'une mise à jour d'apt-get. J'ai filtré tout sauf les requêtes HTTP pour des raisons de simplicité, mais je serai heureux de télécharger le tout si nécessaire pour le débogage. Les paquets d'intérêt sont les n ° 6, n ° 7 et n ° 9:
https://mega.nz/#!NORi2ALA!njJRKZ4i26GHXaET_ZA6Z4ymWYKhccTGNiEBCcGtwbA
SHA256: 40fc995e505ee2dcaf9aa3e23961a757f628224e3fca83d0deed6374ba9a3fbe
Il me manque quelque chose ... PS: J'imagine qu'il s'agit d'un problème de confidentialité plutôt que d'un incident de sécurité. De toute façon, ce comportement n'est pas documenté (Google ne trouvera rien de semblable). J'ai donc décidé de vérifier auprès de vous. juste pour être sur le côté sécuritaire.
Toute aide est très appréciée! Merci de rester aussi loin! :)
Le type de service X-OC indique que la réponse provenait d'un nœud Open Cache.
Les fournisseurs de services utilisent les serveurs Open Cache fournis par des sociétés telles que Qwilt en tant que mandataires de mise en cache transparents sur leurs réseaux. Votre demande a été interceptée par leur nœud de routage et redirigée vers un nœud de cache. L'objet mis en cache n'était pas mis en cache dans le nœud de cache ('re' = relay for miss; ce serait 'lo' = local pour un hit), il est donc théoriquement allé vers l'hôte + le chemin que vous avez demandé d'obtenir l'objet.
Il est possible que ce soit en fait une sorte d'interception malveillante, mais je suppose que c'était simplement le proxy du FAI.