Codeby Market от Сodeby

Мы запустили свой магазин CodebyMarket Equipment for InfoSec. Уже добавили RaspberryAlfa Long-RangeOrange PiArduino и многое другое. Купить Pentesting Devices


Перейти к содержанию книги Kali Linux Revealed

8.3 Дополнительная настройка и использование APT

Теперь пришло время погрузиться в более сложные темы. Во-первых, мы рассмотрим расширенную конфигурацию APT, которая позволит вам установить более постоянные параметры, которые будут применяться к инструментам APT. Затем мы покажем вам, как управлять приоритетами пакетов, что откроет нам дверь для дополнительной настройки, пользовательских обновлений и модернизаций. Мы также покажем, как обращаться с несколькими дистрибутивами, чтобы вы могли начать экспериментировать с пакетами, поступающими из других дистрибутивов. Затем мы рассмотрим, как отслеживать автоматически установленные пакеты, что позволит вам управлять пакетами, которые устанавливаются через зависимости. Мы также объясним, каким образом поддержка multiarch дает нам возможность запуска пакетов, созданных для различных аппаратных архитектур. И последнее, но не менее важное: мы обсудим криптографические протоколы и утилиты, которые позволят вам проверить подлинность каждого пакета.

8.3.1 Настройка APT

Перед тем как мы углубимся в изучение того, как настроить APT, давайте потратим немного времени и обсудим механизм конфигурации системы Debian. В течение длительного времени настройка проводилась специально заточенными под это файлами. Однако в современных Linux системах, вроде Debian и Kali, директории конфигурации с суффиксом .d используются все чаще и чаще. Каждая директория представляет собой файл конфигурации, который в свою очередь разбит на множество файлов. В этом смысле все файлы в /etc/apt/apt.conf.d/ используются для настройки APT. APT обрабатывает файлы в алфавитном порядке, таким образом, что более поздние файлы могут изменять элементы конфигурации, определенные в более ранних файлах.

Эта структура предоставляет определенную гибкость администратору и тем, кто занимается поддержкой пакетов, позволяя им производить изменения в настройках программного обеспечения с помощью добавления файлов без необходимости изменения уже существующего файла. Это особенно полезно для тех, кто занимается поддержкой пакетов, потому что они могут использовать этот подход для адаптации конфигурации другого программного обеспечения, чтобы гарантировать, что оно без проблем сможет сосуществовать с другим программным обеспечением, не нарушая политики Debian, которая в свою очередь строго запрещает изменение конфигурации файлов других пакетов. Благодаря механизму .d конфигурации вам не нужно вручную следовать множеству инструкций по настройке пакетов, которые обычно находятся в файле пакета /usr/share/doc/package /README.Debian , т.к. установщик может обращаться к файлу конфигурации.

Будьте осторожны с файлами конфигурации, которые были созданы в .d директории

Хотя APT имеет встроенную поддержку своего каталога /etc/apt/apt.conf.d, это не всегда так. Для некоторых приложений (например, для exim), директория .d является особым дополнением Debian, которое используется в качестве входа для динамического создания канонического файла конфигурации, используемого приложением. В таких случаях пакеты предоставляют команду «update-*» (например: update-exim4.conf), которая последовательно соединит файлы из .d директории и перезапишет основной файл конфигурации.

В подобных ситуациях вы ни в коем случае не должны вручную редактировать основной файл конфигурации, т.к. ваши изменения будут потеряны после следующего запуска команды update-*, а также вы никогда не должны забывать запускать предыдущую команду после редактирования файла из .d директории (или ваши изменения не будут использоваться).

Теперь вооружившись пониманием механизма .d конфигурации, давайте поговорим о том, как вы можете использовать это для настройки APT. Как мы уже обсудили, вы можете изменять поведение APT с помощью dpkg аргументов командной строки, как в этом примере, который выполняет принудительную перезапись установки zsh:

Очевидно, что это довольно громоздко, особенно если вы используете опции часто, но вы также можете использовать структуру конфигурации .d директории для настройки определенных аспектов APT, путем добавления директив в файлы в директории /etc/apt/apt.conf.d/ . Например, эта (и многие другие) директивы могут с легкостью быть добавлены к файлу в /etc/apt/apt.conf.d/ . Имя этого файла несколько произвольно, но общим условным обозначением является использование либо local , либо 991ocal :

Существует довольно много других полезных опций конфигурации и мы, к сожалению, не сможем затронуть их все. Тем не менее, одну из них мы обсудим. Ту, которая относится к связанности узлов в сети. Например, если вы имеете доступ к интернету только через прокси, добавьте строку вроде Acquire::http::proxy ''http-Hyourproxy:3128" . Для прокси FTP используйте Acquire::ftp::proxy ''ftp.Hyourproxy'' .

Чтобы узнать больше об опциях настройки, мы рекомендуем вам прочитать страницу руководства к apt.conf(5) с помощью команды man apt. conf (для получения больших деталей о странице руководства, смотрите раздел 6.1.1 «Страницы руководства»)

8.3.2 Управление приоритетами пакетов

Одним из самых важных аспектов в конфигурации APT является управление приоритетами, связанными с каждым источником пакетов. Например, вы можете захотеть расширить свою Kali Rolling систему на один или два более новых пакета Debian Unstable или Debian Experimental. Также возможно назначить приоритет для каждого доступного пакета (один и тот же пакет может иметь несколько приоритетов в зависимости от его версии или от дистрибутива, предоставившего его). Эти приоритеты будут влиять на поведение APT: для каждого пакета он всегда будет выбирать версию с наивысшим приоритетом (за исключением случаев, когда эта версия старше установленной, а ее приоритет меньше 1000).

APT определяет несколько приоритетов по умолчанию. Каждый установленная версия пакета обладает приоритетом равным 100. Неустановленная версия имеет приоритет 500 по умолчанию, но она может измениться на 990, если является частью целевого выпуска (определенной с помощью опции командной строки t  или APT::Default-Releas e директивой конфигурации).

Вы можете изменять приоритеты путем добавления записей в файл /etc/apt/preferences  с именами поврежденных пакетов, их версией, их производителем и их новым приоритетом.

APT никогда не установит более старую версию пакета (имеется ввиду пакет, чья версия является более старой по отношению к существующей версии установленного пакета) за исключением тех случаев, когда её приоритет выше 1000. APT всегда будет устанавливать пакет с самым высоким приоритетом, который выше указанной цифры. Если у двух пакетов одинаковый приоритет, APT установит самый новый (чей номер версии самый высокий). Если два пакета имеют одинаковую версию и приоритет, но отличаются своим содержанием, APT установит ту версию, которая еще не была установлена (это правило было создано для того, чтобы затрагивать случаи, когда пакет обновился, но не обновился номер его версии).

Более конкретно, пакет, приоритет которого меньше 0, никогда не будет установлен. Пакет с приоритетом в диапазоне от 0 до 100 будет установлен только в том случае, если другая версия пакета еще не была установлена. При приоритете от 100 до 500 пакет будет установлен только в том случае, если в другом дистрибутиве нет другой более новой версии, установленной или доступной. Пакет приоритетов между 501 и 990 будет установлен только в том случае, если новая версия не установлена ​​или недоступна в целевом дистрибутиве. Пакет с приоритетом от 990 до 1000 будет установлен в случае, если существующая версия является более старой. Приоритет, превышающий 1000, всегда приведет к установке пакета, даже если он заставит APT перейти на более раннюю версию.

Когда APT проверяет /etc/apt/preferences , он сначала учитывает наиболее конкретные записи (часто указывающие соответствующий пакет), затем более общие (в том числе, например, все пакеты дистрибутива). Если существует несколько общих записей, используется первое соответствие. Доступный критерий выбора включает в себя имя пакета и источник, который его предоставил. Каждый источник пакета идентифицирован информацией содержащейся в файле Release, который APT загружает вместе с файлами Packages. Эти файлы обычно указывают источник, «Kali» для пакетов с официальных зеркал Kali и «Debian »для пакетов с официальных зеркал Debian, но источником также может быть название организации, имя человека или же название каких-либо других репозиториев. Файл Release также предоставляет название дистрибутива вместе с его версией. Теперь, давайте познакомимся с его синтаксисом на примере реального случая, для более полного понимания механизма.

Приоритет Kali-Bleeding-Edge и Debian Experimental

Если вы указали kali-bleeding-edge  или Debian experimental  в вашем файле sources.list , то соответствующий пакет практически никогда не будет установлен, потому что их APT приоритет по умолчанию 1. Это, безусловно, особенный случай, который был задан специально для того, чтобы предотвратить пользователей от ошибочной установки bleeding edge  пакетов. Пакеты могут быть установлены только путем ввода apt install package/kali-bleeding-edge , предполагая, конечно, что вы полностью осознаете риски и потенциальные проблемы «жизни на краю» (life on the edge). По-прежнему возможно (хотя и не рекомендуется) обрабатывать пакеты kali-bleeding-edge/experimental , аналогично пакетам из других дистрибутивов, предоставляя им приоритет 500. Это делается с помощью конкретной записи в /etc/apt/preferences :

Давайте предположим, что вы всего лишь хотите использовать пакеты Kali и желаете, чтобы пакеты Debian устанавливались только при явном запросе. Вы можете написать следующую запись в файле /etc/apt/ preferences  (или в любом другом файле в /etc/apt/preferences.d/ ):

В последних двух примерах вы встречали a=kali-bleeding-edge , что обозначает имя выбранного дистрибутива, а также вы могли видеть o=Kali и o=Debian , что в свою очередь ограничивает сферу деятельности пакетов, чьим источником являются Kali и Debian, соответственно.

Теперь давайте предположим, что у вас есть сервер с несколькими локальными программами, которые находятся в зависимости от версии Perl 5.22 и вы, соответственно, хотите убедиться в том, что обновление не установит другую версию. Вы можете использовать следующую запись.

Справочная документация для этого файла конфигурации доступна на странице руководства apt_pref erences (5), которую вы можете вывести на экран с помощью команды man apt_preferences.

Добавление комментариев в /etc/apt/preferences

В /etc/apt/preferences  не существует официального синтаксиса для комментариев, но некоторые текстовые описания могут быть предоставлены путем добавления одного или нескольких полей Explanation в каждую запись:

8.3.3 Работа с несколькими дистрибутивами

Учитывая, что apt является таким замечательным инструментом, вы, скорее всего, захотите погрузиться и начать экспериментировать с пакетами, поступающими из других дистрибутивов. Например, после установки системы Kali Rolling, вы можете попробовать пакет программного обеспечения, доступный в Kali Dev, Debian Unstable или Debian Experimental, не слишком сильно отдаляясь от исходного состояния системы.

Даже если вы время от времени сталкиваетесь с проблемами, когда вы смешиваете пакеты из различных дистрибутивов, apt отлично справляется с такого рода сосуществованием и очень эффективно ограничивает риски (при условии, что зависимости пакетов точны). Сначала перечислите все дистрибутивы, используемые в /etc/apt/sources.list , и затем определите дистрибутив, на который вы ссылаетесь с помощью параметра APT::Default-Release  (смотри раздел 8.2.3, «Обновление Kali Linux»)

Давайте предположим, что Kali Rolling является вашим ссылочным дистрибутивом, но Kali Dev и Debian Unstable также указаны в вашем файле sources.list. В этом случае вы можете использовать apt install package/unstable  для установки пакета из Debian Unstable. Если установка была прервана ввиду некоторых неудовлетворяемых зависимостей, позвольте ей разрешить эти зависимости в Unstable путем добавления параметра -t unstable.


Paranoid - курс от Codeby Security School

Представляем вашему вниманию курс от команды codeby - "Комплекс мер по защите персональных данных, анонимности в интернете и не только" Подробнее ...


В данной ситуации, обновления (upgrade и full-upgrade) выполнены в пределах Kali Rolling за исключением пакетов, которые уже были обновлены в другом дистрибутиве: они будут продолжать следовать обновлениям, доступным в других дистрибутивах. Мы объясним это поведение с помощью приоритетов по умолчанию выставленных APT ниже. Не стесняйтесь использовать apt-cache policy (см. вставку «Использование apt-cache policy») для проверки заданных приоритетов.

Все опирается на то, что рассматривает лишь пакеты, которые выше или равны версии установленного пакета (при условии, что /etc/apt/preferences  не используется для форсирования приоритетов выше 1000 для некоторых пакетов).

Использование apt-cache policy

Для получения лучшего понимания механизма приоритетности, не стесняйтесь выполнять apt-cache policy для того, чтобы отобразить приоритетность по умолчанию связанную с каждым источником пакета. Вы также можете использовать apt-cache policy package для отображения приоритетов всех доступных версий заданного пакета.

Давайте предположим, что вы установили версию 1 первого пакета из Kali Rolling и что версия 2 и 3 доступны соответственно в Kali Dev и Debian Unstable. Установленная версия обладает приоритетом 100, а версия доступная в Kali Rolling (абсолютно такая же) обладает приоритетом 990 (ввиду того, что она является частью целевого выпуска). Пакеты в Kali Dev и Debian Unstable обладают приоритетом 500 (приоритет по умолчанию не установленной версии). Таким образом, победителем в этой ситуации выйдет версия 1 с приоритетом в 990. Пакет остается в Kali Rolling.

Давайте приведем другой пример с пакетов версии 2, который был установлен из Kali Dev. Версия 1 является доступной в Kali Rolling и версия 3 доступна в Debian Unstable. Версия 1 (с приоритетом 990 – таким образом ниже чем 1000) отбрасывается, потому что она обладает более низким приоритетом, чем установленная версия. Остаются две версии 2 и 3, обе с приоритетом 500. В таких случаях APT выбирает самую новую версию, ту которая доступна в Debian Unstable. Если вы не хотите чтобы пакет установленный с Kali Dev переместился в Debian Unstable, вам нужно назначить приоритет меньше 500 (например, 490) для пакетов, поступающих с Debian Unstable. Вы можете изменить /etc/apt/preferences  для этого эффекта:

8.3.4 Автоматическое отслеживание установленных пакетов

Одной из существенных функций apt является отслеживание пакетов, установленных только через зависимость. Такие пакеты называются автоматическими (automatic) и часто включают в себя библиотеки.

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

Очень полезная привычка отмечать как автоматический любой пакет, который вам не нужен напрямую, чтобы они автоматически удалялись, когда они больше не нужны. Вы можете использовать команду apt-mark auto package для маркировки данного пакета как автоматического, тогда как команда apt-mark manual package делает обратное. aptitude markauto и aptitude unmarkauto работают точно также, хотя они предлагают больше возможностей для маркировки сразу нескольких пакетов (см. раздел 8.2.7.1, «Aptitude»). Консольный интерактивный интерфейс aptitude также упрощает просмотр отметки «автоматический» на многих пакетах.

Возможно, вам захочется узнать, почему в системе присутствуют автоматически установленные пакеты. Чтобы получить эту информацию из командной строки, вы можете использовать aptitude why package  (apt и apt-get не имеют подобной функции):

8.3.5 Использование поддержки Multi-Arch Support

Все пакеты Debian имеют поле «Архитектура» (Architecture) в их управляющей информации. Это поле может содержать либо «все» («all» (для тех пакетов, которые не зависят от архитектуры систем)), либо имя архитектуры, на которую он нацелен (например, amd64 или armhf). В последнем случае, по умолчанию, dpkg будет устанавливать пакет только в том случае, если его архитектура соответствует архитектуре хоста, что видно на выводе команды dpkg -print-architecture .

Это ограничение гарантирует, что вы не получите исполняемые файлы, скомпилированные для неправильной архитектуры. Все было бы идеально, за исключением того, что (некоторые) компьютеры могут запускать исполняемые файлы для нескольких архитектур, как стандартным способом (система amd64 может запускать исполняемые файлы i386), так и через эмуляторы.

8.3.5.1 Включение Multi-Arch

Multi-arch поддержка dpkg позволяет пользователям определять внешние архитектуры, которые могут быть установлены в текущей системе. Это легко сделать с помощью dpkg --add-architecture , как в примере ниже, где архитектура i386 должна быть добавлена в систему amd64 для запуска приложений Windows с использованием Wine. Существует соответствующая команда dpkg --remove-architecture  для отказа от поддержки внешней архитектуры, но ее можно использовать только тогда, когда на вашей системе не осталось установленных пакетов, относящихся к этой архитектуры.

APT автоматически определит, когда dpkg был настроен для поддержки внешних архитектур и начнет скачивание соответствующих файлов пакетов на протяжении процесса обновления.

Затем могут быть установлены внешние пакеты с помощью команды apt install package-.architecture .

Использование патентованных i386 исполняемых файлов на amd64

Существует множество вариантов использования multi-arch, но наиболее популярным из них является возможность выполнения 32-разрядных бинарных файлов (i386) в 64-битных системах (amd64), в частности, благодаря тому, что несколько популярных фирменных приложений (таких как Skype) предоставляются только в 32 разрядных версиях.

8.3.5.2 Изменения, связанные с Multi-Arch

Чтобы сделать multi-arch реально полезным и удобным в использовании, библиотеки должны быть перепакетированы и перемещены в специальную директорию для архитектур таким образом, чтобы несколько экземпляров (ориентированных на разные архитектуры) могли успешно сосуществовать друг с другом. Такие обновленные пакеты содержат Multi-Arch: одно и то же поле заголовка для того, чтобы сообщить системе пакетирования, что различные архитектуры пакета могут безопасно сосуществовать (и что эти пакеты могут удовлетворять только зависимости пакетов такой же архитектуры).

Также стоит отметить, что в Multi-Arch одинаковые пакеты должны иметь названия в соответствии с их архитектурой для того, чтобы идентифицироваться без проблем. Эти пакеты также могут совместно использовать файлы с другими экземплярами одного и того же пакета; dpkg гарантирует, что все пакеты обладают одинаковыми поразрядными файлами, когда последние совместно используются. Также, все экземпляры пакета должны иметь одну и ту же версию, поэтому их необходимо обновлять вместе.

Поддержка Multi-Arch приносит некоторые интересные трудности, вызванные способом, которым обрабатываются зависимости. Удовлетворение зависимости требует либо пакета отмеченного как Multi-Arch: foreign или пакета, архитектура которого соответствует одному из пакетов, объявляющих зависимость (в этом процессе восстановления зависимостей предполагается, что независимые от архитектуры пакеты имеют такую же архитектуру что и хост). Зависимость также может быть ослаблена для того, чтобы позволить любой другой архитектуре выполнить её с помощью package:любой синтаксис, но внешние пакеты могут удовлетворить подобную зависимость, если они отмечены как Multi-Arch: allowed.

 

8.3.6 Проверка подлинности пакета

Обновление системы представляет собой очень уязвимую операцию, так что вы должны полностью убедиться, что вы устанавливаете пакеты лишь из официальных репозиториев Kali. Если зеркало Kali, которое вы использовали, было взломано, то человек, проделавший это, захочет добавить вредоносный код во вполне себе официальный пакет. Подобного рода пакет, в случае его установки, сможет делать абсолютно все, что в него было заложено взломщиком, включая хищение паролей или конфиденциальной информации. Для того чтобы обойти этот риск Kali предоставляет защищенный от злонамеренного вмешательства изолирующий слой – на время установки – который поможет удостовериться в том, что пакет реально происходит из официального источника и не был изменен кем-либо со стороны.

Изолирующий слой работает с цепочкой криптографической хэш-функции и подписью. Подписанный файл является Release файлом, предоставленным зеркалами Kali. Он содержит список файлов файловых пакетов (включая из сжатые формы, Packages.gz and Packages.xz, и инкрементные версии) вместе с их MD5, SHA1, и SHA256 хэшами, что в свою очередь гарантирует, что файлы еще не были подвергнуты вмешательству. Эти файлы пакетов содержат список пакетов Debian, доступных на зеркале, вместе с их хэшами, которые гарантируют в свою очередь, что пакеты сами по себе еще не были изменены.

Доверенные ключи управляются командой apt-key, которая находится в apt пакете. Эта программа поддерживает общественные ключи keyring GnuPG, которые используются для проверки подписей в файле Release.gpg, доступном на зеркалах. Он может использоваться для добавления новых ключей вручную (когда вам необходимы неофициальные зеркала). Однако, как правило, нужны только официальные ключи. Эти ключи автоматически поддерживаются в актуальном состоянии пакетом kali-archive-keyring  (который помещает соответствующий keyrings в /etc/apt/trusted.gpg.d ). Однако, первая установка отдельных пакетов, требует особого внимания: даже если пакет подписан как любой другой, подпись не может быть проверена извне. Осторожный администратор должен всегда идентифицировать импортируемые ключи, перед тем как доверять им и начинать установку новых пакетов.

Когда в sources.list добавляется пакет из неофициального источника, APT должен быть уведомлен о том, что он может доверять соответствующему GPG ключу аутентификации (в противном случае он будет продолжать жаловаться, что он не может гарантировать подлинность пакетов, поступающих из этого репозитория). Первым шагом, безусловно, является получение публичного ключа. Чаще всего ключ будет предоставлен в виде небольшого текстового файла, который мы будем называть key.asc в следующих примерах.

Для того чтобы добавить ключ к доверенному keyring, администратор должен запустить run apt-key add < key.asc . Другим способом является использование графического интерфейса synaptic: его вкладка Authentication в меню Settings — Repositories предоставляет возможность импорта ключей из файла key.asc.

Для людей, которые предпочитают специализированное приложение и более подробную информацию о доверенных ключах, можно использовать gui-apt-key (в пакете с тем же именем), небольшой пользовательский графический интерфейс, который управляет доверенным ключом.

После того, как соответствующие ключи находятся в keyring, APT проверит сигнатуры перед любой рискованной операцией, чтобы интерфейсы отображали предупреждение, если было предложено установить пакет, подлинность которого не может быть установлена.

Перейти к содержанию книги Kali Linux Revealed

Это интересно:


Безопасная сделка с гарантом Сodeby

Гарант является доверенным посредником между Участниками при проведении сделки.​ Услуга сайта «Проведение сделок через Гаранта» предоставляется всем зарегистрированным пользователям codeby.net Подробнее ...


Похожие темы

Codeby OS. Чего стоит ждать от проекта, сроки и об... Многие слышали о том, что скоро должен выйти дистрибутив на базе ArchLinux, а именно - CodebyOS, бетта-тест должен был начаться еще 5 марта. К сожал...
Проверка уязвимостей, обнаруженных Nexpose... Перейти к содержанию полного руководства пользователя Metasploit на русском языке. Валидация уязвимостей с Nexpose Мастер проверки уязвимостей предо...
Автоматический анализ памяти с AUMFOR... AUMFOR - автоматизированная программа для анализа содержимого памяти - основанная на графическом интерфейсе, она лучше всех поможет товарищу майор...
Устранение проблем с Kali Linux 1) Не могу записать на флешку 2) Не могу запустить 3) Не могу поставить дрова. 4) Не могу ничего, я Выложу коротенький мануал по этим 3 пробл...
Пускаем весь трафик Kali через TOR с помощью torgh... Вечером лазая по борду наткнулся на статью по тому как пустить в кали через TOR с помощью Proxychain-ng. (не могу сново найти статью, если кто читал...