Гостеприимный: Странный код и repo во время обновления

Hy!

Прежде всего, tl; объяснение доктора проблемы:

IP Canonical 91.189.88.162 (один из security.ubuntu.com на шесть дюйм/с решает к) возвращает перенаправление HTTP 302 "http://179.184.158.89:80/pdata/05f7e7f89ba2302b/security.ubuntu.com/ubuntu/dists/xenial-security/InRelease". Тот IP не принадлежит никакому официальному зеркалу Ubuntu, и URI содержит своего рода идентификатор (это может быть код отслеживания, это изменяет каждый запрос). Расследование привело к заключению, что это не проблема software/OS-related (легко восстанавливаемый от другого ноутбука, загруженного от Живой карты с интерфейсом USB, соединенной проводом к модему Telefonica. Это не может быть воспроизведено больше нигде, по-видимому).

Репозитории Canonical, как предполагается, ведут себя как этот при каком-либо обстоятельстве вообще? Образец Pcap присоединяется в конце этого сообщения. Ручной Запрос 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

Теперь для долгой, всесторонней версии (полный анализ, ненужное чтение, если Вы выяснили что случилось на основе информации выше):

Во время плановой проверки в одном из моих VMs вчера, что-то нечетное привлекло мое внимание:

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" прибыло из, существует только один неофициальный repo, установленный в этом VM (winswitch), но гостеприимная безопасность - то, что называет этот 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

Ни один из установленных repos не решает к тому 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 не удается найти любой адрес FQDN, решающий к тому IP также.

О том 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.

Я пытался воспроизвести то поведение сразу после, но тот IP больше не обнаруживался во время Кв. - получают обновление.

Нет никакого прокси никакого вида в этом VM (в масштабе всей системы или специализирован). Этот VM соединяется с Интернетом через брандмауэр OPNSense, никакая исходящая фильтрация не является установкой. Я действительно делал попытку к tcpdump трафика, чтобы проверить, что HTTP-заголовки, отправленные и полученные Кв. - добираются, как только я заметил подозрительный адрес, но, так как я больше не смог воспроизвести то поведение, ничто не придумает его. К счастью, однако, я работал, Кв. - получают обновление снова вчера вечером и что странный IP обнаружился еще раз, хотя только в одной строке на этот раз.

В тот момент я разжег Wireshark и прошел все получение. Как оказалось, это не связанная с DNS аномалия (я ранее подтвердил это путем запросов каждого сопоставителя, который я настроил здесь, ни один из них не возвратил это "179.184.158.89"), по крайней мере один из шести дюйм/с, которые security.ubuntu.com разрешает к (91.189.88.162), возвращает тот неизвестный URI через HTTP 302. Вот список, против которого я протестировал:

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

Я могу теперь последовательно воспроизводить поведение вручную. Я установил Агент пользователя на "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

Все те пять остающийся HTTP 200 возврата дюйм/с, который является ожидаемым поведением для всех них насколько я знаю. Например:

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

Как Вы видите, IP Canonical 91.189.88.162 сам возвращает перенаправление HTTP 302 тому подозрительному IP. Так как эта аномалия восстанавливаема от любого из моих VMs, и даже от живой ОС на старом ноутбуке у меня есть наложение вокруг, в то время как включено прямо в модем Telefonica, я пришел к выводу, что это не связано с моим брандмауэром также. Даже при том, что механизм Telefonica находится в моей гостиной, это вне охраняемого периметра моей сети, таким образом, это не контролируется или ничто. Так или иначе я не полагаю, что это - преступник, так как это - очень дешевый DSL-2730E ADSL2 + Маршрутизатор без пользовательских настроенных статических маршрутов. Я попытаюсь соединить его мостом на днях, чтобы видеть, изменяются ли вещи.

Достаточно странно, то, что 302 ответа не несут подпись веб-сервера в отличие от всех запросов других к нему, которые привели меня полагать, что что-то промежуточное могло бы прерывать пакеты к тому конкретному 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 оба показывают ожидаемый маршрут, задержка HTTP в 5%-м поле по сравнению с 91.189.88.161 (который является одним те шесть и также расположен в Лондоне). 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

Tcptraceroute против порта 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

В то время как я начинал рыть в эту проблему, питание вышло в моем окружении (который чрезвычайно редок отдельно. Пойдите Murphy!). После того как это возвратилось 3 часа спустя, я загрузил весь свой VMs назад, кроме того, которому не удалось загрузиться правильно. Предположить который?Верно.

Между прочим, это, оказывается, единственная Ubuntu 16.04 VM, который я имею дома. Этот тип отказа беспрецедентен для любого из моих VMs, который делает его одним адским совпадением. Я сразу продолжил создавать снимки его диск и списал упомянутый VM для всестороннего судебного анализа позже только, чтобы быть на безопасной стороне. По-видимому, что-то повредило X11-сервер, который обновился 07.11.2017. Я изучу его позже, но я не вижу, как одно только это перенаправление заставило бы это происходить.

Нужно отметить, что, после того как питание возвратилось, я больше не сталкивался с той проблемой, то есть, каждый запрос к шести дюйм/с возвратит HTTP 200, как это должно. Таким образом, ранее сегодня я продолжал вынуждать свой модем перезапустить свою аутентификацию PPPoE для получения нового динамического IP, и затем я проверю снова по тем 6 дюйм/с, чтобы видеть, возвратилось ли то поведение. 11 снова соединяется позже, бинго! 91.189.88.162 начал бросать меня они HTTP 302. Вот список дюйм/с, которого я использовал после того, как каждый снова соединяется (в случае, если существует ACL в frontend Canonical, который, оказывается, целеустремленно управляет поведением на основе исходного 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)  

Я запросил шесть дюйм/с Canonical от другого ISP в Бразилии, а также нескольких серверов во всем мире, всегда выполняя 5 запросов на целевой IP для исключения несоответствий. Ни один из них не возвратил тот HTTP 302. Когда-либо. Даже однажды. В моем домашнем соединении, однако, каждой попытке против 91.189.88.162 HTTP 302 урожаев, если я не продолжаю пробовать на расстоянии в несколько секунд, в этом случае это возвратит HTTP 200, как будто я обходил своего рода кэш несмотря на то, что "Управление Кэша: без кэшей" установлен в 302 ответах. Странный, ха?

Я приглашаю любого пытаться воспроизвести то поведение, сообщите мне, сталкиваетесь ли Вы с теми 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. Этот адрес выделяется маленькому ISP в другом состоянии 400 км + далеко отсюда.

Нижняя строка, Если бы это намеренно настраивается для собирания статистических данных (который даже не имел бы большого смысла), смело можно сказать, это было чрезвычайно плохо реализовано, так как это довольно ошибочно и только работает на одно из 6 дюйм/с (Который будет выбран случайным образом или циклический алгоритм, так как они не могут справиться, как локальный клиент DNS обработает их, и все записи на 6 А совместно используют тот же TTL). Это оставляет много комнаты для предположения.

В случае, если кто-то хочет видеть его, вот он, pcap файл, взятый во время Кв. - получает обновление. Я отфильтровал что-либо кроме Запросов HTTP ради простоты, но я буду рад загрузить все это при необходимости для отладки. Пакеты интереса являются № 6, № 7 и № 9:

https://mega.nz/#! NORi2ALA! njJRKZ4i26GHXaET_ZA6Z4ymWYKhccTGNiEBCcGtwbA

SHA256: 40fc995e505ee2dcaf9aa3e23961a757f628224e3fca83d0deed6374ba9a3fbe

Я должен пропускать что-то... PS: Я предполагаю, что это - больше беспокойства конфиденциальности, а не инцидент безопасности, так или иначе это поведение не документировано (Google ничто не найдет подобным ему), таким образом, я решил согласовать с Вами люди только, чтобы быть на безопасной стороне.

Любая справка очень ценится! Спасибо за то, чтобы придерживаться настолько далеко!:)