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

А что, если решить задачу иначе?

(дисклеймер: всё ниженаписанное - сляпано тяп-ляп, в рамках теоретического решения задачи, и непригодно к продакшену)

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

Шифрование? Хорошо, но будет больно, и всё равно данные попадут не в те руки.
Удаление данных? "Лицом в пол, руки за голову!" - не успеете.
Значит, данных на флешке быть вообще не должно. Особенно, если данных много, 100500 секретных файлов с картинками.
Но при этом с ними надо работать, как?

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

Создадим под него место:

fallocate -l 1T bigdata.img
losetup -f --show bigdata.img
/dev/loop1
cryptsetup luksFormat /dev/loop1
cryptsetup open /dev/loop1 xxx
mkfs.ext4 /dev/mapper/xxx
cruptsetup close xxx
losetup -d /dev/loop1

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

apt install tgt
tgt-setup-lun -n games -d /.../bigdata.img 127.0.0.1
cd /etc/tgt/cond.d
tgt-admin --dump > games.conf

Теперь там в этом файле будет примерно такое:

default-driver iscsi

<target iqn.2001-04.com.server-games>
	backing-store /..../bigdata.img
	initiator-name 127.0.0.1
</target>

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

iptables -A INPUT -p tcp -d 127.0.0.1 --dport 3260 -j ACCEPT
iptables -A INPUT -p tcp --dport 3260 -j REJECT --reject-with tcp-reset

И заодно можно внести эти правила куда-нибудь в /etc/rc.local, чтобы они точно применились при перезагрузке.

Теперь создаем двух юзеров:

adduser guest
adduser ghost

chown ghost:ghost /.../bigdata.img

и два скрипта:

vim /usr/local/bin/idle
-------
#!/bin/sh

trap "exit 0" INT

while true; do
  sleep 1000;
done
-------

chmod 755 /usr/local/bin/idle
usermod -s /usr/local/bin/idle guest

vim /usr/local/bin/datakiller
-------
#!/bin/sh

export PATH=/usr/bin

nohup dd if=/dev/urandom of=/.../bigdata.img BS=10M count=100000 &
-------

chmod 755 /usr/local/bin/datakiller
usermod -s /usr/local/bin/datakiller ghost

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

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

apt install open-iscsi cryptsetup

Чтобы не оставить лишних следов - запрещаем сохранение истории для юзера, а лучше и для рута тоже:

vim ~/.profile
---------
.....
HISTFILE=/dev/null
HISTSIZE=0
HISTFILESIZE=0
unset HISTCONTROL

---------

Теперь не будет сохраняться, что там кто вводил.

Настраиваем подключение - запускаем в терминале такую конструкцию:

ssh -L 127.0.0.1:3260:127.0.0.1:3260 guest@server

Эта команда пробрасывает подключение к локальному порту на удаленный сервер, где на этом же порту слушает tgtd.
Запускать можно от обычного пользователя.
Запрет на сохранение истории нужен как раз для того, чтобы спрятать лишний раз guest@server

Теперь, не завершая ее, открываем во втором терминале (другое окно или Ctrl-Alt-F2) консоль рута, и ищем тагеты:

iscsiadm -m discovery -t st -p 127.0.0.1
127.0.0.1:3260,1 iqn.2001-04.com.server-games

iscsiadm -m node -l -T iqn.2001-04.com.server-games
... successfull

ls /dev/disk/by-path/ip-*
/dev/disk/by-path/ip-127.0.0.1\:3260-iscsi-iqn.2001-04.com.server-games-lun1

cryptsetup open /dev/disk/by-path/ip-127.0.0.1\:3260-iscsi-iqn.2001-04.com.server-games-lun1 xxx
mount /dev/mapper/xxx /mnt

cd /mnt
tar cf - /usr/* | tar xf -
tar cf - /home/* | tar xf -

mount -o bind /mnt/usr /usr
mount -o bind /mnt/home /home

И вот у нас "на флешке" целый терабайт места.
Точнее, в /home и /usr, но можно точно так же добавить еще и /var c /etc

Осталось записать это в скрипт:

#!/bin/sh

iscsiadm -m node -l -T iqn.2001-04.com.server-games
cryptsetup open /dev/disk/by-path/ip-127.0.0.1\:3260-iscsi-iqn.2001-04.com.server-games-lun1 xxx
mount /dev/mapper/xxx /mnt
mount -o bind /mnt/usr /usr
mount -o bind /mnt/home /home

Который нужно выполнять после подключения первого скрипта, с SSH.

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

Доступно будет на любом компьтере, на котором удалось загрузиться с флешки, ввести ssh-команду и потом скрипт коннекта.

Если какие-то нехорошие люди захотят это похитить - достаточно выдернуть флешку из компьютера, и она обнулится, ведь без подключенного диска она фактически пустая.
А для диска нужен пароль ssh и пароль luks.

Если они очень настойчивые - у нас есть юзер ghost, можно даже подсказку положить, чтобы сами, всё сами...

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

Всем удачных выходных!

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


  1. alice160nokia
    24.10.2025 15:30

    progorodsamara.ru/news/view/samarec-licno-podaril-svou-beskonecnuu-flesku-dmitriu-medvedevu

    "У меня не получилось": российской "бесконечной флэшки" больше не будет

    Создатель проекта, который подарил флэшку Медведеву, признал, что не всегда принимал правильные решения

    Самарский изобретатель, Алексей Чуркин объявил о закрытии стартапа Flashsafe. "Бесконечную флэшку" он пытался вместе со своей командой раскрутить три года, но признал, что не достиг успеха и больше не может соревноваться с облачными платформами крупных IT-гигантов. Свой стартап - флешку, которая предоставляла доступ к зашифрованным обалчным хранилищам данных - самарский предприниматель презентовал и Президенту Владимиру Путину, и председателю Правительства РФ Дмитрию Медведеву.

    • Момент был упущен, я признаю что сам во всем виноват, нужно было уделять больше внимания команде, быть скромнее, и не принимать не верные кадровые решения, поэтому прошу у всех прощения за свои действия, - написал Алексей Чуркин на странице своего проекта. И рассказал всю историю борьбы за рынок хранения информации.

    Теперь Алексей намерен взяться за новые проекты. В течение долгого времени он жил в США, но теперь намерен стать полезным у себя на Родине.

    ничего личного - но уже было


    1. JBFW Автор
      24.10.2025 15:30

      Но я не предлагаю стартап и тем более через госструктуры )

      Это так, пятничное...


    1. ru1z
      24.10.2025 15:30

      доступ к зашифрованным обалчным хранилищам данных

      Интересные хранилища и презентованы верно.


      1. alice160nokia
        24.10.2025 15:30

        usb-ключ был этой безлим-флэшекой


        1. ru1z
          24.10.2025 15:30

          Ключ тоже алчный с подпиской?

          ЗЫ, вроде у героя новости с обалчными хранилищами все сложилось, если не ошибся с тезкой, так что https://habr.com/ru/companies/oleg-bunin/articles/903552/


          1. outlingo
            24.10.2025 15:30

            Тезки


  1. max9
    24.10.2025 15:30

    ничто так не выдавало бывшего freebsd-шника как пути вида /usr/local/bin

    если вы зануляете хистори, то все равно спалитесь на заходе по ssh, его историю входов тоже надо занулять


    1. JBFW Автор
      24.10.2025 15:30

      О, это отдельная история, почему есть /bin, /usr/bin и /usr/local/bin, надо будет как-нибудь написать )


      1. max9
        24.10.2025 15:30

        та уже нету истории, точнее ушло в аналы истории. если раньше был FHS, то с выходом systemd все развалилось и стандарт стал неактуальным. и не то чтобы в линуксе его сильно соблюдали и ранее


    1. ThingCrimson
      24.10.2025 15:30

      Ну почему только freebsd-шника? В старом линуксе вполне себе /usr/local/* популярен был, да и сейчас я его использую (пример с домашнего нано-сервера под дебианом):

       $ du -sh /usr/local/*
      104K	/usr/local/bin
      160K	/usr/local/etc
      4.0K	/usr/local/games
      4.0K	/usr/local/include
      160K	/usr/local/lib
      0	/usr/local/man
      4.0K	/usr/local/sbin
      3.0M	/usr/local/share
      3.1M	/usr/local/src
      

      А против лишней истории ещё полезно в /etc/fstab добавить
      tmpfs /var/log tmpfs size=128m,rw,nodev,noexec,nosuid,auto 0 1


      1. max9
        24.10.2025 15:30

        В старом линуксе вполне себе /usr/local/*

        ух ты. чекнул на бубунте 24, и вправду живое.

        А против лишней истории ещё полезно в /etc/fstab добавить

        ну тут палка о 2х концах. если у вас ооо с 1.5 человеками и вы занимаетесь этим или льете логи в сием с большой компанией, ИБ и вот это все.


        1. ThingCrimson
          24.10.2025 15:30

          Да я не о том, что оно «живое» (то есть формально существует) в некоем дистрибутиве — а что я его реально использую! В /usr/local/src разворачиваю и собираю софт, которого нет в дистрибутиве (или мне нужна более свежая версия, я сижу на дебиане oldstable и иногда oldoldstable); плюс в /usr/local/[s]bin ложатся всякие специфичные для сайта скрипты.

          А про палку о двух концах — вроде как предполагается, что если человек использует загрузочную флешку с монтированием в далёко и под шифром, то тут речь не идёт о логах в SIEM (не говоря уже о корпоративной ИБ).


  1. kt97679
    24.10.2025 15:30

    Если в качестве транспорта используется ссш, то почему просто не использовать ссшфс?


    1. JBFW Автор
      24.10.2025 15:30

      Потому что тут разделение: чтобы получить доступ к данным нужен доступ к серверу (физический или ссш) И доступ к паролю шифрования luks. Одного недостаточно.

      Использование sshfs или других видов сетевого монтирования каталогов исключает один из элементов, т.е. получив доступ к серверу получаем и доступ к данным сразу. Что в случае физически неподконтрольного сервера неприемлемо - по условию задачи информация не должна попасть не в те руки (админам сервера тоже нельзя).

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