Apt-d16r8ew072anqo.cloudfront.net에 대한 이상한 요청 : 80


17

토요일 (5 월 18 일)에 VM 중 하나를 시작했습니다 (Ubuntu 18.04 Server 실행).

놀랍게도 VM은 거의 즉시 연결을 시도했습니다. d16r8ew072anqo.cloudfront.net:80이전에는 보지 못했던 것입니다. 사용자 정의 apt저장소가없고 패키지가 몇 개 설치되어있는 우분투의 꽤 "원시"설치입니다 . 이전에는 의심스러운 대상, 주로 우분투 및 스냅 도메인에 연결되지 않았습니다. (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와의 이상한 연결에 대한 단서를 찾을 수 없었습니다.

내 질문은 : 아무도 무슨 일이 있었는지 또는 적어도 그들의 로그에서 동일한 연결을 발견 했습니까?

(그런데 우분투 팀이 CloudFront를 사용하여 서버를 완화하는 한 가지 예를 알고 있습니다. 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를 통해 저에게 이것이 예상되는 행동임을 확인했으며 더 많은 사람들이 과거에 그 행동을 눈치 채지 못한 것에 놀랐습니다.

ULTIMATELY : 악의적 인 행동이 아니라 예상 된 행동이며, 보관 서버에 과부하가 걸리지 않기 위해 필요했습니다. (이것은 그들이 처음으로 그렇게 했으므로 적어도 아무것도 터지지 않았습니다.)

Cloudfront로 오프로드하지 않는 표준 동작은 이제 제자리에 있어야합니다.


고맙습니다, 아주 좋은 소식입니다! 따라서 5 월 20 일 월요일에 CloudFront를 끈 후 시험이 발생하여 더 이상 (비) 문제를 재현 할 수없는 것 같습니다.
Tomasz Zieliński

데비안 (모든 배포판 중)은 2016 년부터 CloudFront 및 Fastly CDN을 사용해 왔으므로 Ubuntu도 이와 같은 일을하는 것은 새로운 일이 아닙니다.
user1686

우분투가 이것을 오프로드 할 필요가 없다는 것을 제외하고는 @grawity. 그러나 당신은 틀린 것이 아닙니다. 그것은 위대한 사물의 제도에서 '새로운 것이 아닙니다'.하지만 우분투에게는별로 이루어지지 않았습니다. (그리고 우분투에서는 비정형적인 관찰입니다.)
토마스 워드

이것은 예상되는 동작이 아닙니다. 서버와 클라이언트에 squid-deb-proxy 설정이 있는데이 호스트 이름은 화이트리스트에 허용되지 않으므로 결과적으로 403이 표시됩니다. 공식적인 반응을 얻기 위해 community.ubuntu.com 에 질문했습니다 .
N0rbert

@ N0rbert 이것은 일시적 일 뿐이다. 이것이 여전히 진행 중이라면 누군가가 우리에게 세부 사항을 알려주거나 저장소 동작 을 변경 하지 않았습니다 .
토마스 워드
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.