Xenial: странный код и amp; репо во время обновления

хы!

во-первых, TL;д-р объяснение этого вопроса:

каноническое ИС 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 содержит какой-то идентификатор (это может быть код отслеживания, оно меняется каждый запрос). Расследование привело к выводу, что это не программное обеспечение/ОС-связанный с этим вопрос (легко воспроизводимый с другой ноутбук, загрузился с живой флешки USB проводной модем Телефоника это. Она не может быть воспроизведена нигде, видимо).

являются хранилищами канонических должен вести себя в каких-либо обстоятельствах? Подгонянный образец, прилагаемый в конце этого сообщения. Руководство по http-запросов, имитирующих "apt-получить обновление":

теперь на долго, полная версия (тщательный анализ, ненужно читать, если ты разобрался, что на основе описанного выше):

в ходе плановой проверки в одной из моих виртуальных машин вчера, что-то странное привлекло мое внимание:

я не вижу где это "179.184.158.91" взялись, есть только один официальный РЕПО установлен в виртуальной машине (winswitch), но xenial-безопасности является то, что вызов этого IP-адреса. Кроме того, это, кажется, носить уникальные идентификаторы, как "03ee827eaa21046b".

Дополнительная информация:

, что IP не принадлежит какой-либо официальное зеркало Ubuntu и URI содержит какой-то идентификатор (это может быть код отслеживания, оно меняется каждый запрос).

кошка /и т. д./кв/источников.список.д/*

ни один из установленных РЕПО разрешения на этот адрес:

инструменты Обратный поиск IP не удается найти любой адрес, доменное имя, решив, что IP, а также.

, что ИС-это сообщил мой провайдер (Телефоника), но вроде бы в маленького провайдера я никогда не слышал до сих пор:

[dиода d17]я попытался сразу же воспроизвести это поведение после, но этого IP больше не появился во время apt-получить обновление.[!dиода d17]

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

в этот момент я запустил wireshark и прошел всю захватить. Как выясняется, это не DNS-аномалия (я уже подтвердил это, запрашивая каждый арбитр поставил я здесь, никто из них не вернулся, что "179.184.158.89"), по крайней мере, один из шести IP-адресов, которые security.ubuntu.com решает (91.189.88.162) возвращается, что неизвестные Ури через http 302. Вот список я проверялась:

теперь я могу воспроизвести поведение вручную. Я установил агента пользователя в "Debian в apt-протокол http/1.3 (1.2.24)" для того, чтобы отвлечь внимание от какой-либо гипотетической приманки, которые может быть сидят где-то посередине, на всякий случай:

все эти пять оставшихся ИПС вернет http 200, который является ожидаемым поведением для всех из них, насколько я знаю. Например:

[F9] и

как вы можете видеть, ИС канонические 91.189.88.162 себя возвращает http 302 редирект на эту подозрительных IP. Поскольку эта аномалия является воспроизводимым от любого из моих виртуальных машин и даже с видео ОС на старом ноутбуке у меня валяться, пока подключен прямо в модем "Телефоника", я пришел к выводу, что это не связано с моей брандмауэра либо. Хотя шестерни Телефоника сидит в моей гостиной, это за пределами защищенного периметра сети, так это не проверенные или ничего. В любом случае, я не верю, что это преступник, так как это самый дешевый ДСЛ-2730E маршрутизатор ADSL2+ с пользовательскими статические маршруты настраиваются. Я буду стараться наводить ее в один из этих дней, чтобы увидеть, если что-то изменится.

как ни странно, ответ на 302 не несет вебсервер подпись, в отличие от всех остальных запросов к ней, который привел меня к чему-то верить в между может перехватывать пакеты, что конкретный IP и порт. Вот пример взятый с сервера я сама в Канаде, где четко видно Заголовок "сервер":

однако, коротко, дальнейшие попытки отпечатков пальцев, что сервер за 91.189.88.162 удалось доказать, что движение-это подделки. TCPtraceroute и ССО как показывают ожидаемого маршрута, задержки http-это в пределах 5% маржи по сравнению с 91.189.88.161 (который является одним из тех шести и тоже находится в Лондоне). Nmap использует наводящие также предполагает, что я достигнув сервер канонические (если только это очень тщательно mitm атаки, которые, кажется, не тот случай). Я также не вижу никаких доказательств протокола BGP Перехват и путь:

Tcptraceroute против порт 80:

кошка /и т. д./кв/источников.список.д/*

кстати, что бывает только виртуальную машину Ubuntu 16.04 у меня дома. Этот тип ошибки является беспрецедентным для любой из моих виртуальных машин, что делает его одним из ада случайно. Я сразу же приступил к снимок своего диска и списанные сказал ВМ для углубленного анализа, позже, только чтобы быть на безопасной стороне. Видимо, что-то сломалось Х11-сервера, который последний раз был обновлен 2017-11-07. Я займусь этим позже, но я не понимаю, как только это перенаправление может это вызвать.

следует отметить, что как только власть вернулась, я больше не сталкивается с этой проблемой, то есть, каждый запрос к шести ИПС вернется кодом http 200, как надо. Так что сегодня я держал заставляя мой модем, чтобы перезагрузить его подлинности PPPoE в целях получения нового динамического IP, а потом я бы снова проверить против тех, 6 IPS, чтобы увидеть, если это поведение вернется. 11 подключается позже, Бинго! 91.189.88.162 начал бросать мне эти http 302. Здесь находится список IP-адресов я использую после каждого повторного подключения (в случае, если есть ACL в интерфейсе каноническим, что, случается, целенаправленно манипулируя поведением на основе исходного IP по какой-то причине). Все, кроме первого и последнего не возникли проблемы с security.ubuntu.com:

[от f13]

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

я приглашаю всех, чтобы попытаться воспроизвести это поведение, пожалуйста, дайте мне знать, если вы столкнетесь с тем, что 302 редирект:

я должен повторить, что этот IP-адрес назначения в моем случае (179.184.158.89) не принадлежит какой-либо компании в список зеркал убунту, я просто не понимаю, почему это должно служить мне файл InRelease. Этот адрес выделяется в небольшом ISP в другом государстве 400км+ отсюда.

суть в том, что если это намеренно создана для сбора статистики (которая даже не имеет особого смысла), можно с уверенностью сказать, это было крайне плохо реализован, потому что он довольно непредсказуем и работает только на одном из 6 IP-адресов (которые будут выбраны случайным образом или циклическим, поскольку они не могут управлять, как локальный DNS-клиент будет обрабатывать их и все 6 записей одинаковые ТТЛ). Это оставляет много места для спекуляций.

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

http://179.184.158.89:80/pdata/05f7e7f89ba2302b/security.ubuntu.com/ubuntu/dists/xenial-security/InRelease

и sha256: 40fc995e505ee2dcaf9aa3e23961a757f628224e3fca83d0deed6374ba9a3fbe

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

[и D40]любая помощь будет высоко ценится! Спасибо, что так далеко! :)[!и D40]