13.11.2017 10:22
ru_vds 0 6400 Источник
Загрузка Kali Linux со съёмного носителя информации полезна во многих ситуациях. В самом простом виде такой носитель, в формате DVD-диска или флэшки, создают, используя стандартный ISO-образ системы. Однако, куда больше возможностей даёт сборка собственных образов и создание загрузочных носителей с постоянным хранилищем данных. Кроме того, иногда могут пригодиться образы системы, настроенные особым образом. Всему этому посвящены третий и четвёртый разделы девятой главы книги «Kali Linux Revealed», перевод которых мы публикуем в этом материале.



9.3. Сборка собственных ISO-образов Kali Linux


Стандартный вариант Kali Linux отличается гибкостью и имеет немало возможностей. Сразу после его установки можно приступать к решению множества непростых задач. Конечно, тут не помешает некоторый уровень знания инструментов, включённых в дистрибутив, креативность, терпение и опыт. Однако, образ Kali можно настраивать, включая в него то, что нужно, или убирая лишнее, задавать автоматическое выполнение каких-либо действий в ходе загрузки системы.

Среди примеров таких вот особых образов — Kali ISO of Doom и Kali Evil Wireless Access Point — интереснейшие проекты, которые полагаются на специально настроенные реализации Kali Linux. Взглянем на процесс создания собственных ISO-образов Kali Linux.

Официальные образы Kali собраны с использованием live-build. Это — набор скриптов, который даёт возможность полной автоматизации и настройки всех аспектов создания ISO-образов. Набор live-buid использует, при формировании своей конфигурации, структуру директорий. Эту конфигурацию и некоторые связанные вспомогательные скрипты можно найти в Git-репозитории live-build-config. Мы будем пользоваться данным репозиторием как основой для построения образов, настроенных в соответствии с особыми требованиями.

Прежде чем продолжать, вы должны знать, что команды, показанные в этом разделе, предназначены для выполнения в актуальной версии Kali Linux. Если попытаться воспользоваться ими в ОС, отличной от Kali, или в устаревшей версии Kali, они, вероятнее всего, не будут нормально работать.

9.3.1. Установка необходимого ПО


Первый шаг в деле сборки собственного ISO-образа заключается в установке необходимых пакетов и в загрузке Git-репозитория с конфигурацией Kali live-build:

# apt install curl git live-build
[...]
# git clone git://git.kali.org/live-build-config.git
[...]
# cd live-build-config
# ls
auto  build_all.sh  build.sh  kali-config  README

После этого вы уже можете создавать обновлённые (но немодифицированные) ISO-образы Kali. Для этого достаточно воспользоваться командой ./build.sh --verbose. Сборка займёт немало времени, так как в её ходе будут загружаться все пакеты, которые необходимо включить в образ. После завершения этого процесса вы сможете найти новый ISO-образ в директории images.

9.3.2. Сборка Live-образа с различными окружениями рабочего стола


Стандартный скрипт build.sh из набора live-build ответственен за подготовку директории config. Её присутствия ожидает live-build. Скрипт помогает задавать различные конфигурации, что зависит от его опции --variant.

Скрипт создаёт директорию config, комбинируя файлы из kali-config/common и kali-config/variant-X, где X — это название варианта, заданного с помощью параметра --variant. Когда эта опция не задана явно, в качестве названия варианта используется default.

Папка kali-config содержит директории для наиболее популярных окружений рабочего стола:

  • e17 для Enlightenment;
  • gnome для GNOME;
  • i3wm для фреймового оконного менеджера i3;
  • kde для KDE;
  • lxde для LXDE;
  • mate для Mate Desktop Environment;
  • xfce для XFCE.

Вариант light — это особый случай. Он основан на XFCE и используется для создания официального облегчённого ISO-образа, который содержит урезанный набор приложений.

Вот, например, как создать Live-образ Kali, применяя в качестве окружения рабочего стола KDE:

# ./build.sh --variant kde --verbose

Вышеописанная концепция вариантов позволяет выполнять общую настройку системы, пользуясь наборами стандартных предустановок. Однако, на самом деле, образы поддаются гораздо более глубокой настройке. Почитать об этом можно в Debian Live System Manual. Там вы обнаружите множество других способов настройки образов, которые заключаются в изменении содержимого соответствующих поддиректорий в kali-config. Ниже мы рассмотрим несколько примеров.

9.3.3. Изменение набора установленных пакетов


Live-build, после запуска, устанавливает все пакеты, перечисленные в файлах package-lists/*.list.chroot. Стандартная конфигурация включает в себя файл package-lists/kali.list.chroot, в котором имеется запись о пакете kali-linux-full (это — базовый метапакет, использование которого приводит к включению в образ всех пакетов Kali). Строку с упоминанием этого пакета можно закомментировать и использовать другой метапакет или составить собственный список из других пакетов. Кроме того, можно скомбинировать оба подхода, начав с метапакета и добавляя дополнительные необходимые пакеты.

Используя package-lists, включать в образ можно только те пакеты, которые уже доступны в официальном репозитории Kali. Однако, если у вас есть собственные пакеты, включить их в Live-образ можно, поместив соответствующие .deb-файлы в директорию packages.chroot (например, в kali-config/config-gnome/packages.chroot, если вы, при сборке, используете вариант графического окружения GNOME).

Метапакеты — это пустые пакеты, которые используют лишь потому что они включают в себя множество зависимостей от других пакетов. Как результат, они упрощают установку наборов пакетов, которые обычно устанавливают вместе. Пакет с исходным кодом kali-meta отвечает за сборку всех метапакетов, предоставляемых Kali Linux:

  • kali-linux: базовая система (она используется во всех остальных метапакетах).
  • kali-linux-full: стандартная установка Kali Linux.
  • kali-linux-all: метапакет, объединяющий в себе все остальные метапакеты, равно как и другие пакеты (тут — практически всё, что есть в Kali, так что это просто огромный пакет!).
  • kali-linux-sdr: инструменты для программно-определяемого радио (Software Defined Radio, SDR).
  • kali-linux-gpu: средства, использующие видеокарту (GPU) для выполнения тяжёлых вычислений.
  • kali-linux-wireless: средства для исследования и анализа беспроводных сетей.
  • kali-linux-web: средства для исследования веб-приложений.
  • kali-linux-forensic: инструменты цифровой криминалистики (их используют для поиска улик при расследовании различных инцидентов).
  • kali-linux-voip: инструменты VoIP (Voice Over IP).
  • kali-linux-pwtools: средства для взлома паролей.
  • kali-linux-top10: десять самых популярных инструментов.
  • kali-linux-rfid: средства для работы с RFID.

Вы можете использовать эти метапакеты при создании собственного списка пакетов для live-build. Полный список доступных метапакетов и программных средств, которые они включают в себя, можно найти здесь.

?Автоматизация настройки установленных пакетов


Для автоматизации настройки установленных пакетов вы можете воспользоваться файлами ответов Debconf (подробнее об этом смотрите в разделе 4.3.2., «Создание файла ответов»), размещая их в preseed/*.cfg. Они будут применены для настройки пакетов, используемых при создании Live-образа.

9.3.4. Использование хуков для тонкой настройки содержимого образа


Работая с live-build, можно пользоваться хуками, которые выполняются на различных этапах процесса сборки. Хуки chroot — это исполняемые скрипты, которые устанавливают как hooks/live/*.chroot в дереве конфигурации, и которые выполняются с использованием chroot. В то время, как chroot — это команда, которая позволяет временно изменить корневую директорию операционной системы на выбранную директорию, она также используется live-build для назначения директории, содержащей полное (альтернативное) дерево файловой системы. В случае с live-build, chroot-директория — это директория, где готовится файловая система для Live-образа. Так как приложения, запущенные с использованием chroot, не имеют доступа за пределы выбранной директории, то же самое справедливо и для chroot-хуков: использовать и модифицировать можно лишь то, что доступно в окружении chroot. Мы полагаемся на эти хуки для выполнения множества настроек, специфичных для Kali (взгляните на kali-config/common/hooks/live/kali-hacks.chroot).

Бинарные хуки (hooks/live/*.binary) исполняются в контексте процесса сборки, в конце этого процесса. Их не вызывают в ходе сборки с использованием chroot. С их помощью можно модифицировать содержимое сборки ISO-образа, но не Live-файловую систему, так как к этому моменту она уже создана. Мы используем эту возможность в Kali для выполнения некоторых изменений в стандартной конфигурации isolinux, созданной live-build. Например, взгляните на config/common/hooks/live/persistence.binary, где мы добавляем пункты загрузочного меню, предназначенные для включения постоянного хранилища данных.

9.3.5. Добавление файлов в ISO-образ или в Live-файловую систему


Ещё один весьма распространённых способ настройки образов заключается в добавлении файлов либо в Live-файловую систему, либо в ISO-образ.

Добавлять файлы в файловую систему можно, помещая их туда, где они должны быть, в конфигурационной директории includes.chroot. Например, есть стандартный файл kali-config/common/includes.chroot/usr/lib/live/config/0031-root-password, который в итоге оказывается расположенным в Live-файловой системе по адресу /usr/lib/live/config/0031-root-password.

?Хуки live-boot


Скрипты, установленные в /lib/live/config/XXXX-name выполняются скриптом init пакета live-boot. Они перенастраивают многие аспекты системы так, чтобы они подходили для работы в Live-режиме. Сюда вы можете добавить собственные скрипты для настройки своей Live-системы во время работы. В частности, их используют, например, для реализации собственных параметров загрузки.

Добавлять файлы в ISO-образ можно, размещая их в конфигурационной директории includes.binary, в тех местах, где они должны быть. Например, есть стандартный файл kali-config/common/includes.binary/isolinux/splash.png, который переопределяет фоновое изображение, используемое загрузчиком isolinux (оно хранится в файле /isolinux/splash.png в файловой системе ISO-образа).

9.4. Добавление постоянного хранилища в Live-ISO при использовании USB-диска


9.4.1. Особенности постоянного хранилища


Тут мы рассмотрим шаги, необходимые для добавления постоянного хранилища информации на USB-флэшку с записанной на ней Kali. Сущность Live-файловой системы заключается в её эфемерности. Все данные, сохранённые при работе с такой системой, исчезают после перезагрузки, то же самое касается и настроек системы. Для того, чтобы этого избежать, можно использовать возможность live-boot, называемую постоянным хранилищем информации (persistence). Эта возможность активируется в том случае, если параметры загрузки включают в себя ключевое слово persistence.

Так как модификация загрузочного меню — непростая задача, Kali по умолчанию имеет два пункта меню, позволяющие включить постоянное хранилище. Это, как показано на следующем рисунке, Live USB Persistence и Live USB Encrypted Persistence.


Рис. 9.1. Пункты меню для включения постоянного хранилища

Когда эта функция включена, live-boot просканирует все разделы в поисках файловых систем, помеченных как persistence (это можно изменить с помощью параметра загрузки persistence-label=value), и установщик создаст хранилище для директорий, которые перечислены в файле persistence.conf, обнаруженном в этом разделе (каждая директория указывается в отдельной строке). Особый параметр / union позволяет включить полное сохранение всех директорий с использованием каскадно-объединенного монтирования (union mount). При таком подходе создаётся дополнительный уровень файловой системы, в котором сохраняются лишь изменения, вносимые в данные базовой файловой системы. Данные директорий, не теряющиеся после перезагрузки, хранятся в файловой системе, которая содержит соответствующий файл persistence.conf.

9.4.2. Создание незашифрованного хранилища на USB-диске


Тут предполагается, что вы подготовили USB-флэшку с Live-системой, следуя инструкциям, которые можно найти в разделе 2.1.4., «Копирование образа на DVD-ROM или на USB-флэшку», и что размера носителя достаточно для хранения образа (около 3 Гб) и для хранения данных директорий, которые попадут в постоянное хранилище. Кроме того, мы исходим из предположения, что Linux видит USB-флэшку как /dev/sdb, и что она содержит лишь два раздела, являющихся частью стандартного ISO-образа (/dev/sdb1 и /dev/sdb2). Делая то, о чём речь пойдёт ниже, будьте очень осторожны. Дело в том, что если вы случайно переразобъёте не тот диск, это может окончиться потерей важных данных.

Для того, чтобы добавить на диск новый раздел, необходимо знать размер образа, который уже имеется на флэшке. Это даст вам возможность сделать так, чтобы новый раздел начинался сразу после Live-образа. Затем нужно воспользоваться командой parted для создания раздела. Команды, приведённые ниже, выполняют анализ ISO-образа kali-linux-2016.1-amd64.iso, присутствие которого ожидается на USB-флэшке:

# parted /dev/sdb print
Model: SanDisk Cruzer Edge (scsi)
Disk /dev/sdb: 32,0GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type     File system  Flags
 1      32,8kB  2852MB  2852MB  primary               boot, hidden
 2      2852MB  2945MB  93,4MB  primary
# start=$(du --block-size=1MB kali-linux-2016.1-amd64.iso | awk '{print $1}')
# echo "Size of image is $start MB"
Size of image is 2946 MB
# parted -a optimal /dev/sdb mkpart primary "${start}MB" 100%
Information: You may need to update /etc/fstab.

# parted /dev/sdb print
Model: SanDisk Cruzer Edge (scsi)
Disk /dev/sdb: 32,0GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type     File system  Flags
 1      32,8kB  2852MB  2852MB  primary               boot, hidden
 2      2852MB  2945MB  93,4MB  primary
 3      2946MB  32,0GB  29,1GB  primary

Когда новый раздел /dev/sdb3 создан, отформатируйте его в файловой системе ext4 и назначьте ему метку persistence с помощью команды mkfs.ext4 (и её опции -L для назначения метки). Затем раздел монтируется в директорию /mnt и туда добавляют файл persistence.conf. Как и при форматировании любого диска, соблюдайте осторожность. Если вы отформатируете не тот раздел или не тот диск, вы можете потерять что-нибудь важное.

# mkfs.ext4 -L persistence /dev/sdb3
mke2fs 1.43-WIP (15-Mar-2016)
Creating filesystem with 7096832 4k blocks and 1777664 inodes
Filesystem UUID: dede20c4-5239-479a-b115-96561ac857b6
Superblock backups stored on blocks:
	
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
	
4096000

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
# mount /dev/sdb3 /mnt
# echo "/ union" >/mnt/persistence.conf
# ls -l /mnt
total 20
drwx------ 2 root root 16384 May 10 13:31 lost+found
-rw-r--r-- 1 root root     8 May 10 13:34 persistence.conf
# umount /mnt

Теперь USB-флэшка готова к тому, чтобы с неё можно было загрузиться с использованием пункта меню Live USB Persistence.

9.4.3. Создание зашифрованного хранилища на USB-флэшке


Если нужно, постоянное хранилище данных можно организовать и на зашифрованном разделе, live-boot это поддерживает. Такой подход позволяет защитить данные путём создания зашифрованного раздела LUKS, на котором они и хранятся.

Создание зашифрованного хранилища начинается с тех же действий, которые мы выполняли раньше. Однако сейчас, вместо форматирования раздела в файловой системе ext4, используйте cryptsetup для инициализации раздела в виде LUKS-контейнера. Затем откройте этот контейнер и настройте файловую систему ext4 так же, как делали это при создании незашифрованного хранилища, но вместо использования раздела /dev/sdb3 воспользуйтесь виртуальным разделом, созданным cryptsetup. Этот виртуальный раздел представляет собой расшифрованное содержимое зашифрованного раздела, который доступен в /dev/mapper под именем, которое вы ему назначили. В нижеприведённом примере мы будем использовать имя kali_persistence. Напомним, что при выполнении подобных операций стоит проявить бдительность и не отформатировать случайно не тот диск или раздел.

# cryptsetup --verbose --verify-passphrase luksFormat /dev/sdb3

WARNING!
========
This will overwrite data on /dev/sdb3 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter passphrase:
Verify passphrase:
Command successful.
# cryptsetup luksOpen /dev/sdb3 kali_persistence
Enter passphrase for /dev/sdb3:
# mkfs.ext4 -L persistence /dev/mapper/kali_persistence
mke2fs 1.43-WIP (15-Mar-2016)
Creating filesystem with 7096320 4k blocks and 1774192 inodes
Filesystem UUID: 287892c1-00bb-43cb-b513-81cc9e6fa72b
Superblock backups stored on blocks:
	
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
	
4096000

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

# mount /dev/mapper/kali_persistence /mnt
# echo "/ union" >/mnt/persistence.conf
# umount /mnt
# cryptsetup luksClose /dev/mapper/kali_persistence

9.4.4. Использование нескольких постоянных хранилищ информации


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

Предположим, что вы — профессиональный пентестер. Работая у клиента, вы используете постоянное хранилище, расположенное на зашифрованном разделе. Поступаете вы так для защиты данных на тот случай, если USB-флэшку украдут или взломают. В то же время, вам хочется иметь возможность продемонстрировать Kali и какие-нибудь рекламные материалы, хранящиеся на незашифрованном разделе на том же диске. Так как вам не хотелось бы вручную редактировать параметры при каждой загрузке, вы решаете собрать собственный Live-образ с отдельными пунктами загрузочного меню.

Первый шаг заключается в сборке собственного Live-ISO (в соответствии с разделом 9.3., «Сборка собственных ISO-образов Kali Linux», и, в частности, с разделом 9.3.4., «Использование хуков для тонкой настройки содержимого образа»). Самое важное, что надо сделать на этом этапе — модифицировать файл kali-config/common/hooks/live/persistence-menu.binary, приведя его к примерно такому виду (обратите внимание на параметры persistence-label):

#!/bin/sh

if [ ! -d isolinux ]; then
    cd binary
fi

cat >>isolinux/live.cfg <<END
label live-demo
    menu label ^Live USB with Demo Data
    linux /live/vmlinuz
    initrd /live/initrd.img
    append boot=live username=root hostname=kali persistence-label=demo persistence
label live-work
    menu label ^Live USB with Work Data
    linux /live/vmlinuz
    initrd /live/initrd.img
    append boot=live username=root hostname=kali persistence-label=work persistence-encryption=luks persistence
END

Далее мы собираем ISO-образ и копируем его на USB-флэшку. Затем создаём и инициализируем два раздела и файловые системы, которые будут использоваться для организации постоянных хранилищ информации. Первый раздел, с меткой demo, создан без шифрования, второй, с меткой work, зашифрован. Тут, исходя из предположения, что USB-диск виден в системе как /dev/sdb, и размер нашего ISO-образа составляет 3000 Мб, нужно выполнить следующую последовательность действий:

# parted /dev/sdb mkpart primary 3000 MB 55%
# parted /dev/sdb mkpart primary 55% 100%
# mkfs.ext4 -L demo /dev/sdb3
[...]
# mount /dev/sdb3 /mnt
# echo "/ union" >/mnt/persistence.conf
# umount /mnt
# cryptsetup --verbose --verify-passphrase luksFormat /dev/sdb4
[...]
# cryptsetup luksOpen /dev/sdb4 kali_persistence
[...]
# mkfs.ext4 -L work /dev/mapper/kali_persistence
[...]
# mount /dev/mapper/kali_persistence /mnt
# echo "/ union" >/mnt/persistence.conf
# umount /mnt
# cryptsetup luksClose /dev/mapper/kali_persistence

Вот и всё. Теперь можно загружаться с USB-диска и выбирать необходимые пункты из нового загрузочного меню.

?Установка пароля самоуничтожения для повышения уровня безопасности системы


В Kali имеется модифицированный cryptsetup для реализации новой возможности. А именно, можно установить так называемый пароль самоуничтожения (nuke password), который, при использовании, уничтожит все ключи, применяемые для работы с зашифрованным разделом.

Это может оказаться полезным, когда вы много путешествуете и вам нужен быстрый способ обеспечить невозможность доступа к вашим данным. При загрузке просто введите пароль самоуничтожения вместо настоящего пароля, и никто (включая вас) не сможет получить доступ к данным.

Прежде чем использовать эту возможность, весьма полезно будет сделать резервную копию ключей шифрования и сохранить её в надёжном месте.

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

$ cryptsetup luksAddNuke /dev/sdb4
Enter any existing passphrase: 
Enter new passphrase for key slot: 
Verify passphrase:

Подробности об этой возможности смотрите здесь.

Итоги


Сегодня мы рассказали о том, как создавать собственные ISO-образы, настраивать постоянные хранилища на USB-дисках, используемых для загрузки системы в Live-режиме, и защищать данные, хранящиеся на съёмных носителях с использованием шифрования разделов и пароля самоуничтожения. В следующий раз мы займёмся подведением итогов девятой главы «Kali Linux Revealed» и поделимся с вами упражнениями к ней.

Уважаемые читатели! Попадали ли вы в ситуации, когда вам пригодилось бы нечто вроде пароля самоуничтожения Kali Linux?

Предыдущие части:

> Часть 1. Kali Linux: политика безопасности, защита компьютеров и сетевых служб
> Часть 2. Kali Linux: фильтрация трафика с помощью netfilter
> Часть 3. Kali Linux: мониторинг и логирование
> Часть 4. Kali Linux: упражнения по защите и мониторингу системы
> Часть 5. Kali Linux: оценка защищённости систем
> Часть 6. Kali Linux: виды проверок информационных систем
> Часть 7. Kali Linux: формализация исследований и типы атак
> Часть 8. Kali Linux: контрольные вопросы по исследованию защищённости систем
> Часть 9. Kali Linux: модификация пакетов
> Часть 10. Kali Linux: сборка ядра

Комментарии (0)