Опасность использования ненадежного зеркального отображения или прокси
Мое смутное понимание механизмов аутентификации, связанных с упаковкой debian / ubuntu, говорит о том, что должно быть безопасно устанавливать пакеты, загруженные с ненадежного сервера или прокси, если apt может их проверить, не выдавая предупреждающие сообщения.
Правильно ли это?
Например, скажем, я пытаюсь подключиться к стандартным серверам ubuntu для обновления безопасности (например, security.ubuntu.com). Чтобы уменьшить потребление полосы пропускания, я просматриваю локальный прокси-сервер apt-cacher, но возможно, что кто-то может подделать пакеты, кэшированные на этом прокси-сервере. Или может быть даже прозрачный apt-прокси вдоль линии где-то. Получу ли я предупреждение, если пакеты не являются правильными? Как влияет на мой apt-кеш (sudo aptitude update)?
5 ответов
Возможно, вам придется рассмотреть следующую ситуацию, когда дело доходит до безопасности хранилища apt. Вы найдете свой ответ ниже.
Вы добавляете ненадежный репозиторий
. Поскольку каждый может создать пару с открытым ключом, так что просто проверяйте загруженное содержимое или apt-index с помощью открытый ключ не решит проблему, когда автор репозитория и владелец ключа помещают вредоносное программное обеспечение в репозиторий.
Он создал пару ключей. Подпишите содержимое своим личным ключом, затем загрузите содержимое в репозиторий, а затем загрузите его открытый ключ
. Затем вы добавляете репозиторий, загружаете его открытый ключ и затем пытаетесь проверить. Apt проверит его, не выдавая предупреждающие сообщения. Вы можете чувствовать себя в безопасности, но это не так. Вы уверены, что верите тому, кто загрузил контент?
Вы добавляете ненадежный репозиторий
Это может показаться безопасным. Вы знаете имя человека и видите, что он подписал содержимое репозитория, а также индекс. В этом случае вы тоже небезопасны. Любой может олицетворять имя.
В этом случае вам нужно проверить открытый ключ. Вы должны знать открытый ключ этого человека и быть уверенным в этом. Если вы знаете человека и видите, что для репозитория необходим другой открытый ключ для проверки содержимого, вам не следует доверять этому репозиторию.
Вы должны знать имя человека и его пару с открытым ключом для проверки подлинности репозитория. Если это не так, не доверяйте репозиторию.
Именно по этой причине в кругах разработчиков и хакеров есть участники, подписавшие ключевые слова, где они встречаются лично, обучают друг другу действительное удостоверение личности, а затем устанавливают trust
Вы знаете человека, имеете правильный открытый ключ, но apt показывает предупреждения
Это может быть так, когда вы пытаетесь добавить репозиторий, но ваш компьютер не получает правильный URL-адрес. Это может быть ситуация, когда ваш DNS не работает должным образом, и кто-то пытается обмануть вас в добавлении неправильного репозитория с помощью сторон подписывания клавиш .
Если вы получаете предупреждение, даже если у вас есть правильный открытый ключ, тогда ABORT. Не идите вперед. Этот третий случай, как правило, очень редок, и вы не должны беспокоиться об этом.
Вы знаете человека, имеете правильный открытый ключ, но apt показывает предупреждения
Если вы хотите добавить репозиторий, и хотите быть уверенным, что вы добавляете правильный репозиторий, вам нужно знать человека, который загрузил его, и должен быть уверен в своей публике ключ. Проверять репозиторий только на его открытый ключ, а не на тот, который владелец репозитория запрашивает у вас. Это самый безопасный механизм. Как упоминалось выше, он НЕ безопасен, даже если apt не дает предупреждений при добавлении репозитория. Содержимое может быть вредоносным. Даже если вы используете хорошо известный репозиторий, а затем apt жалуетесь, значит, вы не добавляете правильный репозиторий. Вы НЕ БЕЗОПАСНЫ.-
1Поэтому я в основном думаю о вашем третьем случае. Например, скажем, я пытаюсь подключиться к стандартным серверам ubuntu для выполнения обновлений безопасности (то есть security.ubuntu.com). Чтобы уменьшить потребление полосы пропускания, я просматриваю локальный прокси-сервер apt-cacher, но возможно, что кто-то может подделать пакеты, кэшированные на этом прокси-сервере. Или может быть даже прозрачный apt-прокси вдоль линии где-то. Получу ли я предупреждение, если пакеты не являются правильными? Как влияет на это обновление моего apt cache (sudp aptitude update)? – intuited 10 August 2011 в 02:58
-
2Вы можете использовать зеркало. APT не должен жаловаться в этом случае, если ВСЕ файлы в репозитории находятся там, и все файлы не повреждены. AFAIK файл индекса хранилища подписан. Любые изменения в файлах в репозитории не совпадают с контрольной суммой. Если индексный файл подделан, то apt будет жаловаться – Manish Sinha 10 August 2011 в 03:01
-
3How does updating my apt cache affect this? Возможно, это возможно. Когда вы добавили, что ваш кеш DNS может быть отравлен. Теперь, когда вы пытаетесь, это, вероятно, указывает на правильный IP. В этом случае обновление кэша apt будет работать – Manish Sinha 10 August 2011 в 03:08
-
4Итак ... если я использую прокси-сервер, то update поступает из прокси-сервера. Итак, вы говорите, что индекс обновления подписан, что гарантирует его получение из реального репозитория ubuntu? – intuited 11 August 2011 в 16:39
-
5@ntuited: Да. Если прокси-сервер является клоном реального репозитория, то проблем не так много. Apt будет жаловаться только при изменении содержимого – Manish Sinha 11 August 2011 в 18:58
Возможно, вам придется рассмотреть следующую ситуацию, когда дело доходит до безопасности хранилища apt. Вы найдете свой ответ ниже.
Вы добавляете ненадежный репозиторий
. Поскольку каждый может создать пару с открытым ключом, так что просто проверяйте загруженное содержимое или apt-index с помощью открытый ключ не решит проблему, когда автор репозитория и владелец ключа помещают вредоносное программное обеспечение в репозиторий.
Он создал пару ключей. Подпишите содержимое своим личным ключом, затем загрузите содержимое в репозиторий, а затем загрузите его открытый ключ
. Затем вы добавляете репозиторий, загружаете его открытый ключ и затем пытаетесь проверить. Apt проверит его, не выдавая предупреждающие сообщения. Вы можете чувствовать себя в безопасности, но это не так. Вы уверены, что верите тому, кто загрузил контент?
Вы добавляете ненадежный репозиторий
Это может показаться безопасным. Вы знаете имя человека и видите, что он подписал содержимое репозитория, а также индекс. В этом случае вы тоже небезопасны. Любой может олицетворять имя.
В этом случае вам нужно проверить открытый ключ. Вы должны знать открытый ключ этого человека и быть уверенным в этом. Если вы знаете человека и видите, что для репозитория необходим другой открытый ключ для проверки содержимого, вам не следует доверять этому репозиторию.
Вы должны знать имя человека и его пару с открытым ключом для проверки подлинности репозитория. Если это не так, не доверяйте репозиторию.
Именно по этой причине в кругах разработчиков и хакеров есть участники, подписавшие ключевые слова, где они встречаются лично, обучают друг другу действительное удостоверение личности, а затем устанавливают trust
Вы знаете человека, имеете правильный открытый ключ, но apt показывает предупреждения
Это может быть так, когда вы пытаетесь добавить репозиторий, но ваш компьютер не получает правильный URL-адрес. Это может быть ситуация, когда ваш DNS не работает должным образом, и кто-то пытается обмануть вас в добавлении неправильного репозитория с помощью сторон подписывания клавиш .
Если вы получаете предупреждение, даже если у вас есть правильный открытый ключ, тогда ABORT. Не идите вперед. Этот третий случай, как правило, очень редок, и вы не должны беспокоиться об этом.
Вы знаете человека, имеете правильный открытый ключ, но apt показывает предупреждения
Если вы хотите добавить репозиторий, и хотите быть уверенным, что вы добавляете правильный репозиторий, вам нужно знать человека, который загрузил его, и должен быть уверен в своей публике ключ. Проверять репозиторий только на его открытый ключ, а не на тот, который владелец репозитория запрашивает у вас. Это самый безопасный механизм. Как упоминалось выше, он НЕ безопасен, даже если apt не дает предупреждений при добавлении репозитория. Содержимое может быть вредоносным. Даже если вы используете хорошо известный репозиторий, а затем apt жалуетесь, значит, вы не добавляете правильный репозиторий. Вы НЕ БЕЗОПАСНЫ.-
1Поэтому я в основном думаю о вашем третьем случае. Например, скажем, я пытаюсь подключиться к стандартным серверам ubuntu для выполнения обновлений безопасности (то есть security.ubuntu.com). Чтобы уменьшить потребление полосы пропускания, я просматриваю локальный прокси-сервер apt-cacher, но возможно, что кто-то может подделать пакеты, кэшированные на этом прокси-сервере. Или может быть даже прозрачный apt-прокси вдоль линии где-то. Получу ли я предупреждение, если пакеты не являются правильными? Как влияет на это обновление моего apt cache (sudp aptitude update)? – intuited 10 August 2011 в 02:58
-
2Вы можете использовать зеркало. APT не должен жаловаться в этом случае, если ВСЕ файлы в репозитории находятся там, и все файлы не повреждены. AFAIK файл индекса хранилища подписан. Любые изменения в файлах в репозитории не совпадают с контрольной суммой. Если индексный файл подделан, то apt будет жаловаться – Manish Sinha 10 August 2011 в 03:01
-
3How does updating my apt cache affect this? Возможно, это возможно. Когда вы добавили, что ваш кеш DNS может быть отравлен. Теперь, когда вы пытаетесь, это, вероятно, указывает на правильный IP. В этом случае обновление кэша apt будет работать – Manish Sinha 10 August 2011 в 03:08
-
4Итак ... если я использую прокси-сервер, то update поступает из прокси-сервера. Итак, вы говорите, что индекс обновления подписан, что гарантирует его получение из реального репозитория ubuntu? – intuited 11 August 2011 в 16:39
-
5@ntuited: Да. Если прокси-сервер является клоном реального репозитория, то проблем не так много. Apt будет жаловаться только при изменении содержимого – Manish Sinha 11 August 2011 в 18:58
Возможно, вам придется рассмотреть следующую ситуацию, когда дело доходит до безопасности хранилища apt. Вы найдете свой ответ ниже.
Вы добавляете ненадежный репозиторий
. Поскольку каждый может создать пару с открытым ключом, так что просто проверяйте загруженное содержимое или apt-index с помощью открытый ключ не решит проблему, когда автор репозитория и владелец ключа помещают вредоносное программное обеспечение в репозиторий.
Он создал пару ключей. Подпишите содержимое своим личным ключом, затем загрузите содержимое в репозиторий, а затем загрузите его открытый ключ
. Затем вы добавляете репозиторий, загружаете его открытый ключ и затем пытаетесь проверить. Apt проверит его, не выдавая предупреждающие сообщения. Вы можете чувствовать себя в безопасности, но это не так. Вы уверены, что верите тому, кто загрузил контент?
Вы добавляете ненадежный репозиторий
Это может показаться безопасным. Вы знаете имя человека и видите, что он подписал содержимое репозитория, а также индекс. В этом случае вы тоже небезопасны. Любой может олицетворять имя.
В этом случае вам нужно проверить открытый ключ. Вы должны знать открытый ключ этого человека и быть уверенным в этом. Если вы знаете человека и видите, что для репозитория необходим другой открытый ключ для проверки содержимого, вам не следует доверять этому репозиторию.
Вы должны знать имя человека и его пару с открытым ключом для проверки подлинности репозитория. Если это не так, не доверяйте репозиторию.
Именно по этой причине в кругах разработчиков и хакеров есть участники, подписавшие ключевые слова, где они встречаются лично, обучают друг другу действительное удостоверение личности, а затем устанавливают trust
Вы знаете человека, имеете правильный открытый ключ, но apt показывает предупреждения
Это может быть так, когда вы пытаетесь добавить репозиторий, но ваш компьютер не получает правильный URL-адрес. Это может быть ситуация, когда ваш DNS не работает должным образом, и кто-то пытается обмануть вас в добавлении неправильного репозитория с помощью сторон подписывания клавиш .
Если вы получаете предупреждение, даже если у вас есть правильный открытый ключ, тогда ABORT. Не идите вперед. Этот третий случай, как правило, очень редок, и вы не должны беспокоиться об этом.
Вы знаете человека, имеете правильный открытый ключ, но apt показывает предупреждения
Если вы хотите добавить репозиторий, и хотите быть уверенным, что вы добавляете правильный репозиторий, вам нужно знать человека, который загрузил его, и должен быть уверен в своей публике ключ. Проверять репозиторий только на его открытый ключ, а не на тот, который владелец репозитория запрашивает у вас. Это самый безопасный механизм. Как упоминалось выше, он НЕ безопасен, даже если apt не дает предупреждений при добавлении репозитория. Содержимое может быть вредоносным. Даже если вы используете хорошо известный репозиторий, а затем apt жалуетесь, значит, вы не добавляете правильный репозиторий. Вы НЕ БЕЗОПАСНЫ.-
1Поэтому я в основном думаю о вашем третьем случае. Например, скажем, я пытаюсь подключиться к стандартным серверам ubuntu для выполнения обновлений безопасности (то есть security.ubuntu.com). Чтобы уменьшить потребление полосы пропускания, я просматриваю локальный прокси-сервер apt-cacher, но возможно, что кто-то может подделать пакеты, кэшированные на этом прокси-сервере. Или может быть даже прозрачный apt-прокси вдоль линии где-то. Получу ли я предупреждение, если пакеты не являются правильными? Как влияет на это обновление моего apt cache (sudp aptitude update)? – intuited 10 August 2011 в 02:58
-
2Вы можете использовать зеркало. APT не должен жаловаться в этом случае, если ВСЕ файлы в репозитории находятся там, и все файлы не повреждены. AFAIK файл индекса хранилища подписан. Любые изменения в файлах в репозитории не совпадают с контрольной суммой. Если индексный файл подделан, то apt будет жаловаться – Manish Sinha 10 August 2011 в 03:01
-
3How does updating my apt cache affect this? Возможно, это возможно. Когда вы добавили, что ваш кеш DNS может быть отравлен. Теперь, когда вы пытаетесь, это, вероятно, указывает на правильный IP. В этом случае обновление кэша apt будет работать – Manish Sinha 10 August 2011 в 03:08
-
4Итак ... если я использую прокси-сервер, то update поступает из прокси-сервера. Итак, вы говорите, что индекс обновления подписан, что гарантирует его получение из реального репозитория ubuntu? – intuited 11 August 2011 в 16:39
-
5@ntuited: Да. Если прокси-сервер является клоном реального репозитория, то проблем не так много. Apt будет жаловаться только при изменении содержимого – Manish Sinha 11 August 2011 в 18:58
Возможно, вам придется рассмотреть следующую ситуацию, когда дело доходит до безопасности хранилища apt. Вы найдете свой ответ ниже.
Вы добавляете ненадежный репозиторий
. Поскольку каждый может создать пару с открытым ключом, так что просто проверяйте загруженное содержимое или apt-index с помощью открытый ключ не решит проблему, когда автор репозитория и владелец ключа помещают вредоносное программное обеспечение в репозиторий.
Он создал пару ключей. Подпишите содержимое своим личным ключом, затем загрузите содержимое в репозиторий, а затем загрузите его открытый ключ
. Затем вы добавляете репозиторий, загружаете его открытый ключ и затем пытаетесь проверить. Apt проверит его, не выдавая предупреждающие сообщения. Вы можете чувствовать себя в безопасности, но это не так. Вы уверены, что верите тому, кто загрузил контент?
Вы добавляете ненадежный репозиторий
Это может показаться безопасным. Вы знаете имя человека и видите, что он подписал содержимое репозитория, а также индекс. В этом случае вы тоже небезопасны. Любой может олицетворять имя.
В этом случае вам нужно проверить открытый ключ. Вы должны знать открытый ключ этого человека и быть уверенным в этом. Если вы знаете человека и видите, что для репозитория необходим другой открытый ключ для проверки содержимого, вам не следует доверять этому репозиторию.
Вы должны знать имя человека и его пару с открытым ключом для проверки подлинности репозитория. Если это не так, не доверяйте репозиторию.
Именно по этой причине в кругах разработчиков и хакеров есть участники, подписавшие ключевые слова, где они встречаются лично, обучают друг другу действительное удостоверение личности, а затем устанавливают trust
Вы знаете человека, имеете правильный открытый ключ, но apt показывает предупреждения
Это может быть так, когда вы пытаетесь добавить репозиторий, но ваш компьютер не получает правильный URL-адрес. Это может быть ситуация, когда ваш DNS не работает должным образом, и кто-то пытается обмануть вас в добавлении неправильного репозитория с помощью сторон подписывания клавиш .
Если вы получаете предупреждение, даже если у вас есть правильный открытый ключ, тогда ABORT. Не идите вперед. Этот третий случай, как правило, очень редок, и вы не должны беспокоиться об этом.
Вы знаете человека, имеете правильный открытый ключ, но apt показывает предупреждения
Если вы хотите добавить репозиторий, и хотите быть уверенным, что вы добавляете правильный репозиторий, вам нужно знать человека, который загрузил его, и должен быть уверен в своей публике ключ. Проверять репозиторий только на его открытый ключ, а не на тот, который владелец репозитория запрашивает у вас. Это самый безопасный механизм. Как упоминалось выше, он НЕ безопасен, даже если apt не дает предупреждений при добавлении репозитория. Содержимое может быть вредоносным. Даже если вы используете хорошо известный репозиторий, а затем apt жалуетесь, значит, вы не добавляете правильный репозиторий. Вы НЕ БЕЗОПАСНЫ.-
1Поэтому я в основном думаю о вашем третьем случае. Например, скажем, я пытаюсь подключиться к стандартным серверам ubuntu для выполнения обновлений безопасности (то есть security.ubuntu.com). Чтобы уменьшить потребление полосы пропускания, я просматриваю локальный прокси-сервер apt-cacher, но возможно, что кто-то может подделать пакеты, кэшированные на этом прокси-сервере. Или может быть даже прозрачный apt-прокси вдоль линии где-то. Получу ли я предупреждение, если пакеты не являются правильными? Как влияет на это обновление моего apt cache (sudp aptitude update)? – intuited 10 August 2011 в 02:58
-
2Вы можете использовать зеркало. APT не должен жаловаться в этом случае, если ВСЕ файлы в репозитории находятся там, и все файлы не повреждены. AFAIK файл индекса хранилища подписан. Любые изменения в файлах в репозитории не совпадают с контрольной суммой. Если индексный файл подделан, то apt будет жаловаться – Manish Sinha 10 August 2011 в 03:01
-
3How does updating my apt cache affect this? Возможно, это возможно. Когда вы добавили, что ваш кеш DNS может быть отравлен. Теперь, когда вы пытаетесь, это, вероятно, указывает на правильный IP. В этом случае обновление кэша apt будет работать – Manish Sinha 10 August 2011 в 03:08
-
4Итак ... если я использую прокси-сервер, то update поступает из прокси-сервера. Итак, вы говорите, что индекс обновления подписан, что гарантирует его получение из реального репозитория ubuntu? – intuited 11 August 2011 в 16:39
-
5@ntuited: Да. Если прокси-сервер является клоном реального репозитория, то проблем не так много. Apt будет жаловаться только при изменении содержимого – Manish Sinha 11 August 2011 в 18:58
Возможно, вам придется рассмотреть следующую ситуацию, когда дело доходит до безопасности хранилища apt. Вы найдете свой ответ ниже.
Вы добавляете ненадежный репозиторий
. Поскольку каждый может создать пару с открытым ключом, так что просто проверяйте загруженное содержимое или apt-index с помощью открытый ключ не решит проблему, когда автор репозитория и владелец ключа помещают вредоносное программное обеспечение в репозиторий.
Он создал пару ключей. Подпишите содержимое своим личным ключом, затем загрузите содержимое в репозиторий, а затем загрузите его открытый ключ
. Затем вы добавляете репозиторий, загружаете его открытый ключ и затем пытаетесь проверить. Apt проверит его, не выдавая предупреждающие сообщения. Вы можете чувствовать себя в безопасности, но это не так. Вы уверены, что верите тому, кто загрузил контент?
Вы добавляете ненадежный репозиторий
Это может показаться безопасным. Вы знаете имя человека и видите, что он подписал содержимое репозитория, а также индекс. В этом случае вы тоже небезопасны. Любой может олицетворять имя.
В этом случае вам нужно проверить открытый ключ. Вы должны знать открытый ключ этого человека и быть уверенным в этом. Если вы знаете человека и видите, что для репозитория необходим другой открытый ключ для проверки содержимого, вам не следует доверять этому репозиторию.
Вы должны знать имя человека и его пару с открытым ключом для проверки подлинности репозитория. Если это не так, не доверяйте репозиторию.
Именно по этой причине в кругах разработчиков и хакеров есть участники, подписавшие ключевые слова, где они встречаются лично, обучают друг другу действительное удостоверение личности, а затем устанавливают trust
Вы знаете человека, имеете правильный открытый ключ, но apt показывает предупреждения
Это может быть так, когда вы пытаетесь добавить репозиторий, но ваш компьютер не получает правильный URL-адрес. Это может быть ситуация, когда ваш DNS не работает должным образом, и кто-то пытается обмануть вас в добавлении неправильного репозитория с помощью сторон подписывания клавиш .
Если вы получаете предупреждение, даже если у вас есть правильный открытый ключ, тогда ABORT. Не идите вперед. Этот третий случай, как правило, очень редок, и вы не должны беспокоиться об этом.
Вы знаете человека, имеете правильный открытый ключ, но apt показывает предупреждения
Если вы хотите добавить репозиторий, и хотите быть уверенным, что вы добавляете правильный репозиторий, вам нужно знать человека, который загрузил его, и должен быть уверен в своей публике ключ. Проверять репозиторий только на его открытый ключ, а не на тот, который владелец репозитория запрашивает у вас. Это самый безопасный механизм. Как упоминалось выше, он НЕ безопасен, даже если apt не дает предупреждений при добавлении репозитория. Содержимое может быть вредоносным. Даже если вы используете хорошо известный репозиторий, а затем apt жалуетесь, значит, вы не добавляете правильный репозиторий. Вы НЕ БЕЗОПАСНЫ.-
1Поэтому я в основном думаю о вашем третьем случае. Например, скажем, я пытаюсь подключиться к стандартным серверам ubuntu для выполнения обновлений безопасности (то есть security.ubuntu.com). Чтобы уменьшить потребление полосы пропускания, я просматриваю локальный прокси-сервер apt-cacher, но возможно, что кто-то может подделать пакеты, кэшированные на этом прокси-сервере. Или может быть даже прозрачный apt-прокси вдоль линии где-то. Получу ли я предупреждение, если пакеты не являются правильными? Как влияет на это обновление моего apt cache (sudp aptitude update)? – intuited 10 August 2011 в 02:58
-
2Вы можете использовать зеркало. APT не должен жаловаться в этом случае, если ВСЕ файлы в репозитории находятся там, и все файлы не повреждены. AFAIK файл индекса хранилища подписан. Любые изменения в файлах в репозитории не совпадают с контрольной суммой. Если индексный файл подделан, то apt будет жаловаться – Manish Sinha 10 August 2011 в 03:01
-
3How does updating my apt cache affect this? Возможно, это возможно. Когда вы добавили, что ваш кеш DNS может быть отравлен. Теперь, когда вы пытаетесь, это, вероятно, указывает на правильный IP. В этом случае обновление кэша apt будет работать – Manish Sinha 10 August 2011 в 03:08
-
4Итак ... если я использую прокси-сервер, то update поступает из прокси-сервера. Итак, вы говорите, что индекс обновления подписан, что гарантирует его получение из реального репозитория ubuntu? – intuited 11 August 2011 в 16:39
-
5@ntuited: Да. Если прокси-сервер является клоном реального репозитория, то проблем не так много. Apt будет жаловаться только при изменении содержимого – Manish Sinha 11 August 2011 в 18:58