Создаём изменяемую копию каталога без полного копирования через OverlayFS!

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

Обычный подход потребует скопировать всё содержимое каталога независимо от того, сколько файлов фактически будет изменено:

cp -a /opt/app /tmp/app-test

В Linux для такой задачи можно использовать OverlayFS: исходный каталог подключается как нижний слой lowerdir, а все изменения, выполняемые через объединённое дерево, записываются в отдельный верхний слой upperdir.

Подготовим каталоги для writable-слоя, служебного workdir и итоговой объединённой точки монтирования:

mkdir -p /tmp/overlay/{upper,work,merged}

Для writable OverlayFS каталоги upperdir и workdir должны находиться на одной файловой системе. Файловая система верхнего слоя также должна поддерживать необходимые OverlayFS extended attributes и корректный d_type.

Монтируем /opt/app как нижний слой:

sudo mount -t overlay overlay \
  -o lowerdir=/opt/app,upperdir=/tmp/overlay/upper,workdir=/tmp/overlay/work \
  /tmp/overlay/merged

После монтирования /tmp/overlay/merged представляет объединённое дерево: неизменённые объекты читаются из lowerdir, а новые и изменённые объекты обслуживаются верхним слоем.

Работать с каталогом можно как с обычным writable-деревом:

echo "test=true" >> /tmp/overlay/merged/config.ini

При первой модификации существующего файла OverlayFS выполняет copy_up: файл копируется из lowerdir в upperdir, после чего операция записи применяется уже к верхней копии. Поэтому OverlayFS не исключает копирование отдельных изменяемых файлов, но устраняет необходимость заранее копировать весь каталог.

В результате изменённая версия файла будет находиться в верхнем слое:

/tmp/overlay/upper/config.ini

Запись через /tmp/overlay/merged при этом не изменяет исходный файл:

/opt/app/config.ini

Важно то, что сам каталог /opt/app от этого физически read-only не становится. Другой процесс по-прежнему может изменить его напрямую. Изменять содержимое используемого lowerdir напрямую во время работы смонтированного OverlayFS не следует — это может привести к неопределённому поведению overlay.

Для завершения работы достаточно размонтировать объединённое представление:

sudo umount /tmp/overlay/merged

Размонтирование не удаляет содержимое upperdir: накопленные изменения сохраняются там до явной очистки каталога. Если слой действительно нужен только на время эксперимента, после успешного umount его можно удалить:

rm -rf /tmp/overlay

🔥 OverlayFS полезен, когда исходное дерево велико, а изменяется только небольшая его часть: дисковое пространство расходуется преимущественно на новые и модифицированные объекты, а запись через объединённое дерево не затрагивает исходные файлы lowerdir. Этот же механизм copy-on-write лежит в основе многих работ с контейнерными слоями и изолированными файловыми окружениями.

🚪 Linux Ready | #практика

📂 Как атакуют пароли и учётные записи!

Например, Brute Force перебирает возможные комбинации пароля, а Credential Stuffing проверяет уже утёкшие учётные данные на других сервисах.

На схеме — 6 распространённых техник, шпаргалка для системных администраторов и DevOps-инженеров: помогает понимать основные векторы компрометации учётных записей и учитывать их при настройке SSH, IAM, MFA и политик доступа.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

Восстанавливаем удалённый файл через /proc, пока процесс держит его открытым!

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

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

rm /var/log/app.log

Найти открытые файлы с нулевым количеством жёстких ссылок можно через lsof. Опция +L1 выбирает открытые файлы, у которых link count меньше 1:

sudo lsof +L1

Для удалённого лога вывод может выглядеть так:

app  4217  root  5w  REG  ...  /var/log/app.log (deleted)

Здесь 4217 — PID процесса, 5 — номер файлового дескриптора, а w означает, что он открыт на запись.

Соответствующий FD доступен через procfs:

sudo ls -l /proc/4217/fd/5

Символическая ссылка будет указывать на уже удалённый pathname:

/proc/4217/fd/5 -> /var/log/app.log (deleted)

Хотя имени файла в каталоге уже нет, открытый файловый дескриптор всё ещё связан с файловым объектом. Пока последний такой FD не закрыт, содержимое можно скопировать через /proc:

sudo cp /proc/4217/fd/5 /tmp/app.log.recovered

Проверяем восстановленную копию:

ls -lh /tmp/app.log.recovered

При необходимости сравниваем размеры:

sudo stat /proc/4217/fd/5
stat /tmp/app.log.recovered

Это не классический undelete — cp создаёт новый файл с новым inode и копирует доступное содержимое. Если процесс продолжает запись, копия не гарантирует консистентный snapshot. Доступ через /proc/<PID>/fd/<FD> также может быть ограничен правами и настройками системы. Восстановить данные нужно до закрытия последнего FD: после этого при нулевом link count ядро сможет освободить inode и блоки файла.

🔥 Поэтому после случайного rm активного файла не спешите перезапускать процесс — сначала проверьте: sudo lsof +L1. Пока FD открыт, данные ещё могут быть доступны через /proc/<PID>/fd/<FD>.

🚪 Linux Ready | #практика

🔄 Безопасный арсенал практических инструкций, курсов и инструментов

👩‍💻 Linux & Bash

🤔 Хакинг & ИБ

🖥 Курсы & GitHub

📱 Python

🥷 OSINT

📂 Сохрани подборку и начни с того, что пригодится тебе уже сегодня.

Проверяем состояние соединений через conntrack!

Linux firewall работает не только с отдельными пакетами. Подсистема Netfilter connection tracking ведёт таблицу отслеживаемых соединений, в которой хранится состояние TCP, UDP и других потоков. Это полезно при диагностике NAT, firewall и асимметричной маршрутизации.

Установим утилиту для работы с таблицей conntrack:

sudo apt update && sudo apt install conntrack -y

Текущие соединения можно вывести через -L и сразу отфильтровать по протоколу и адресу назначения:

sudo conntrack -L -p tcp --dst 203.0.113.10

(адреса в примерах документационные — при повторении замените их на свои)

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

tcp  6 431999 ESTABLISHED
src=10.0.0.20 dst=203.0.113.10 sport=52144 dport=443
src=203.0.113.10 dst=198.51.100.5 sport=443 dport=52144

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

sudo conntrack -E -p tcp

Фильтр можно ограничить адресом и портом назначения:

sudo conntrack -E -p tcp \
  --dst 203.0.113.10 \
  --dport 443

Состояние таблицы важно контролировать на загруженных шлюзах:

sysctl net.netfilter.nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max

Если nf_conntrack_count приближается к nf_conntrack_max, таблица близка к заполнению. При переполнении новые соединения могут перестать нормально отслеживаться, а в журнале ядра обычно появляются сообщения conntrack:

journalctl -k -g 'nf_conntrack'

Время хранения записи для установленного TCP-соединения можно проверить отдельно:

sysctl net.netfilter.nf_conntrack_tcp_timeout_established

Удалять записи вручную следует только при понимании последствий. Для удаления конкретного TCP-потока укажем параметры его исходного направления:

sudo conntrack -D -p tcp \
  --src 10.0.0.20 \
  --dst 203.0.113.10 \
  --sport 52144 \
  --dport 443

🔥 conntrack позволяет увидеть состояние соединения с точки зрения Netfilter, включая оба направления потока и результат NAT. Это полезный уровень диагностики между tcpdump и анализом правил nftables.

🚪 Linux Ready | #практика