apt-d16r8ew072anqo.cloudfront.net:80への奇妙なリクエスト


17

土曜日(5月18日)に、VMの1つ(Ubuntu 18.04サーバーを実行)を開始しました。

驚いたことに、VMはほとんどすぐに接続しようとしましたがd16r8ew072anqo.cloudfront.net:80、これまで見たことのないものです。これは、Ubuntuの非常に「純粋な」インストールであり、カスタムaptリポジトリもインストールされていません。以前は疑わしいものに接続したことはありませんでした-ほとんどはUbuntuおよびSnapドメインです。(Little Snitchを使用してネットワークトラフィックを監視しているため、リアルタイムで接続が表示され、接続を拒否することもできます。)

何が起こったのかを理解しようとして少し時間を費やし、unattended-upgradesセキュリティパッチのインストールに絞ったと思います。具体的には、intel-microcode:amd64パッケージを手動で再インストールしたときに、CloudFrontへの奇妙な接続を再現することができました(偶然かもしれませんが)。

その後、月曜日に、同様のことが再び発生した場合に備えて問題を文書化したかったのですが、驚いたことに、奇妙な接続をもう再現できませんでした。

そして、月曜日に観察できる唯一の違いは、sudo apt-get install --reinstall intel-microcode:amd64[1] からの出力 にIgn:1行がなかったことです。

私は、以下を含むウェブ、検索http://archive.ubuntu.com/ubuntuをgrepVMのディスクを-ed、その他のDNSレコードをチェックします。ubuntu.comサブドメイン、wget疑わしいドメインへのリダイレクトを見つけるためにさまざまなURLを試しましたが、CloudFrontへの奇妙な接続についての手がかりを見つけることができませんでした。

私の質問は次のとおりです。誰が何が起こったのかを知っていますか、少なくともログで同じ接続に気付きましたか?

(ところで、UbuntuチームがCloudFrontを使用してサーバーを解放した1つの例を知っています: 私の12.04 ISOでのMD5の不一致、何が起こっているのでしょうか? -これが似たようなケースになることを望んでいますか? )


[1]:

$ sudo apt-get install --reinstall intel-microcode:amd64
Reading package lists... Done
Building dependency tree       
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 1,801 kB of archives.
After this operation, 0 B of additional disk space will be used.
Ign:1 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 intel-microcode amd64 3.20190514.0ubuntu0.18.04.2
Get:1 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 intel-microcode amd64 3.20190514.0ubuntu0.18.04.2 [1,801 kB]
Fetched 1,801 kB in 20s (89.2 kB/s)          
(Reading database ... 107477 files and directories currently installed.)
Preparing to unpack .../intel-microcode_3.20190514.0ubuntu0.18.04.2_amd64.deb ...
Unpacking intel-microcode (3.20190514.0ubuntu0.18.04.2) over (3.20190514.0ubuntu0.18.04.2) ...
Setting up intel-microcode (3.20190514.0ubuntu0.18.04.2) ...
update-initramfs: deferring update (trigger activated)
intel-microcode: microcode will be updated at next boot
Processing triggers for initramfs-tools (0.130ubuntu3.7) ...
update-initramfs: Generating /boot/initrd.img-4.15.0-50-generic

回答:


24

これが予期される動作であるかどうかの信頼できる情報源であるため、セキュリティチームとアーカイブチームにいくつかの質問をしました。以下は、彼らが私と共有したものの要約です。

この観察された動作は、アーカイブミラーからCloudfrontにトラフィックの負荷をオフロードすることであり、特にカーネルとマイクロコードの更新のために、アーカイブサーバーからの負荷を軽減するために5月15日水曜日から5月20日月曜日に行われました。

それらのチームによると、このようなオフロードがCloudFrontを介して行われたのはこれが初めてであり、この特定のケースでは予想される動作でした。


疑わしいように見えますが、チームはこれが予想される動作であることをIRCで確認しており、過去にこの動作に気付いていない人が増えたことに驚いています。

究極:悪意のある動作ではなく、予想される動作であり、アーカイブサーバーに負荷がかからないようにするために必要でした。(彼らがこれをしなければならなかったのは初めてだったので、少なくとも何も爆破されなかった)

Cloudfrontにオフロードしないという標準的な動作は、現在適切に戻っているはずです。


ありがとう、それは非常に良いニュースです!5月20日月曜日に、CloudFrontがオフになった後に試用が行われたため、(非)問題を再現できなくなったと思います。
トマス・ジエリスキ

(すべてのディストリビューションの)Debianは2016年からCloudFrontとFastly CDNを使用しているため、Ubuntuで同じことを行うことは新しいことではありません...
grawity

@grawityは、Ubuntuがこれをオフロードする必要がないように見えることを除いて。しかし、あなたはそれが物事の壮大な計画では「新しいものではない」ことは間違いありませんが、Ubuntuにとってはあまり行われていません。(また、Ubuntuでの非定型観測です。)
Thomas Ward

これは予期された動作ではありません。サーバーとクライアントでsquid-deb-proxyをセットアップしていますが、このホスト名はホワイトリストで許可されていないため、結果として403になります。公式の反応を得るために、community.ubuntu.comで質問しました。
N0rbert

@ N0rbertこれは一時的なものである必要があります。これがまだ続いている場合、誰かが詳細を教えたり、リポジトリの動作を変更したりしません。
トーマスウォード
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.