Linux с нуля: с чего начать специалисту по ИБ

Привет, в  Академии Cyber Yozh решили разобрать основы работы с Linux для кибербезопасников. Linux часто советуют будущим безопасникам в формате: «поставь Kali, открой терминал и разбирайся». Совет звучит бодро, но новичку от него не легче. Kali предоставляет сотни готовых инструментов, а человек в этот момент еще не понимает, почему один файл открывается, другой отвечает Permission denied, что за процесс слушает порт 8080 и почему sudo иногда спасает, а иногда очень быстро ломает всю систему.

Мы решили пройти путь с самого начала: от установки обычного Linux до разбора незнакомого хоста. Все основные команды из статьи прогнали в изолированной Debian-среде. Там, где контейнер накладывал ограничения — например, не давал управлять systemd или сетевым фильтром, — отдельно отмечали. В итоге получился маршрут, пройдя  который на терминал вы начнете смотреть как на понятную систему, а не на черное окно с заклинаниями.

Материал рассчитан на человека, который идет в информационную безопасность, но пока с Linux на «вы». Здесь не будет пентеста чужих систем и магии из фильмов про хакеров. Будем разбираться с основами: как устроена собственная машина, где там пользователи, права, процессы, порты, журналы, SSH и простая автоматизация.

Не начинайте с Kali

Kali Linux действительно создан для тестирования на проникновение, цифровой криминалистики, обратной разработки и других задач безопасности. Но даже сами разработчики Kali отмечают, что документация предполагает знакомство с Linux и что дистрибутив рассчитан на опытных пентестеров. Kali основан на Debian и добавляет поверх него специализированные пакеты, настройки и инструменты. Поэтому сначала полезнее разобраться как работает обычный Linux, а уже потом переходить к дистрибутиву, где предустановлен инструментарий безопасности. Документация Kali предупреждает, что дистрибутив не рекомендуют как первую систему для знакомства с Linux. Кроме того из-за обилия установленного ПО, эта система страдает стабильностью особенно при обновлениях или когда нужно установить какое-то особенное программное обеспечение, которого не было в дистрибутиве.

Поэтому для первого стенда мы выбрали Debian. На момент подготовки материала стабильная ветка — Debian 13 trixie; актуальное обновление стабильной ветки — 13.7. Debian рекомендует stable как основную производственную ветку. Ubuntu для этого маршрута тоже подойдет: базовые команды, модель прав, процессы, systemd, apt, SSH и большая часть файловой системы будут знакомыми.

Главная идея следующая: сначала учимся видеть систему, а Kali и специализированные инструменты добавим позже.

Ставим Linux, не убивая рабочий ноутбук

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

Перед установкой лучше проверить образ. На Linux проверку криптографической контрольной суммы SHA-256, которая определяет целостность скачанного вами файла делаеют так:

sha256sum debian-13.7.0-amd64-netinst.iso

На macOS команда другая:

shasum -a 256 debian-13.7.0-amd64-netinst.iso

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

Понять смысл хеша можно с помощью простого эксперимента. У файла меняется один байт — SHA-256 становится другим целиком. Для специалиста по ИБ это первая встреча с идеей контроля целостности — да, еще до установки системы.

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

При установке Debian есть еще два решения, которые лучше не прокликивать автоматически. Первое — учетная запись root. Если не задавать отдельный пароль root, Debian отключает прямой вход в эту учетную запись, а первый обычный пользователь получит административные права через sudo — не надо так. Кстати, про такое поведение написали в официальном руководстве по установке Debian.

После этого можно приступить к созданию привилегированной учетной записи и задать ей пароль:

Второе — разметка. Пункт Guided - use entire disk действительно означает использование всего выбранного диска. Для пустой виртуальной машины это нормальная практика. Но для личного или рабочего ноутбука с важными данными — повод еще раз проверить, какой диск выбран, чтобы не убить случайно важную информацию.

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

Первый терминал: кто я и где я

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

whoami

pwd

whoami показывает текущего пользователя. pwd — текущий рабочий каталог. Для обычного пользователя после входа это часто что-то вроде:

/home/student

Теперь смотрим содержимое каталога:

ls

Подробный вариант:

ls -la

-l включает подробный формат, -a показывает в том числе имена, начинающиеся с точки: .bashrc, .profile, .ssh и другие скрытые файлы и каталоги.

Перемещаемся по каталогам с помощью команды cd:

cd /etc

cd ~

cd ..

~ — означает домашний каталог текущего пользователя, .. — каталог на уровень выше.

У Linux нет привычного дерева C:\, D:\ и E:\ как в Windows. Файловая система начинается со знака / - это корень диска. Внутри нее есть директория /home с домашними каталогами пользователей, /etc с файлами конфигураций, /var с изменяемыми данными и журналами, /tmp со временными файлами, необходимыми для работы операционной системы, /proc с представлением процессов и состояния ядра.

Здесь легко запутаться в трех похожих словах. / — корень файловой системы. root — привилегированный пользователь с UID 0. /root — домашний каталог этого пользователя.

Создадим учебный каталог и файл:

mkdir linux-lab

Перейдем в него:

cd linux-lab

Создадим файл:

touch notes.txt

Запишем в файл фразу:

echo "first Linux lab" > notes.txt

Прочитаем содержимое:

cat notes.txt

Копирование, переименование и удаление:

cp notes.txt notes-copy.txt

mv notes-copy.txt evidence.txt

rm evidence.txt

rm особенно важно запомнить: в обычном терминальном сценарии он не обязан отправлять файл в привычную корзину. С rm -r команда рекурсивно работает с каталогом и его содержимым. Это важно! Добавление sudo к командам, особенно тем, что упали с ошибкой надо делать с осторожностью. С sudo команда будет выполнена по сути с правами root и может нанести вред системе, если вы еще с ней не так хорошо знакомы.

Создание, копирование, переименование и удаление файлов в нашей лаборатории.

Права: почему появляется Permission denied

Команда:

ls -l может показать строку вида: -rw-r----- 1 student soc 30 secret.txt

Самая важная часть здесь — rw-r-----. Девять символов делятся на три группы: права владельца, группы и остальных пользователей.

rw-  r--  ---

 │    │    │

 │    │    └─ остальные

 │    └────── группа

 └─────────── владелец

r означает чтение, w — изменение, x — выполнение. Для каталога x имеет практический смысл: разрешает пройти через каталог к объекту глубже в дереве.

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

В общей лабораторной папке файл с правами 640 выглядит так:

chmod 640 secret.txt

ls -l secret.txt

-rw-r----- 1 student soc ... secret.txt

Цифры складываются из прав: r=4, w=2, x=1. Поэтому 6 — чтение плюс запись, 4 — только чтение, 0 — отсутствие доступа.

600  rw-------

640  rw-r-----

644  rw-r--r--

700  rwx------

755  rwxr-xr-x

Популярное chmod 777 означает rwxrwxrwx: читать, менять и выполнять объект могут все. Иногда так быстро проверяют гипотезу в лаборатории, но как способ «починить права» на рабочей системе это оооочень плохая привычка и дыра в безопасности. Проблема чаще в неверном владельце, группе или модели доступа.

Владелец объекта меняется через chown, сначала указываем владельца, потом группу:

sudo chown student:soc secret.txt

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

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

Процессы: кто работает прямо сейчас

Программа на диске и работающий процесс — разные вещи. Запустим безобидную команду:

sleep 300

В другой сессии можно найти процесс:

pgrep -a sleep

или посмотреть подробности по PID (process ID или идентификатор процесса):

ps -p 1819 -o user,pid,ppid,stat,etime,cmd

Полезные поля: пользователь, PID, родительский PID, состояние и команда. Для общего обзора есть:

ps aux

top

Завершить запущенный процесс можно так, с указанием его PID:

kill 1819

По умолчанию kill отправляет сигнал SIGTERM, то есть просит процесс корректно и мягко завершиться. kill -9 отправляет SIGKILL - это принудительная остановка процесса без ожидания его корректного завершения. Поэтому привычка начинать с -9 тоже плохая: сначала важно понять, что за процесс перед нами и почему он вообще работает.

Есть еще каталог /proc, мы его упоминали. Для процесса с PID 1819 каталог /proc/1819/ предоставляет информацию, которую ядро формирует на лету:

grep -E '^(Name|State|Pid|PPid|Uid|Threads):' /proc/1819/status

tr '\0' ' ' < /proc/1819/cmdline

Для расследования инцидентов это весьма полезная привычка: сначала собрать данные, потом что-то останавливать.

Сеть: что значит «порт открыт»

Теперь свяжем процесс с сетью. Посмотреть сетевые интерфейсы и адреса машины можно так:

ip a

Маршруты:

ip route

Слушающие TCP-сокеты:

ss -lnt

Если хватает прав и система предоставляет сведения о процессе:

ss -lntp

Если нужно еще и UDP сокеты глянуть, то делаем так:

ss -tulpn

В лаборатории мы запустили простой HTTP-сервер:

python3 -m http.server 8765 --bind 127.0.0.1

ss показал:

LISTEN ... 127.0.0.1:8765 ...

А curl получит настоящий HTTP-ответ:

curl -I http://127.0.0.1:8765/

Теперь меняем адрес привязки:

python3 -m http.server 8766 --bind 0.0.0.0

или просто

python3 -m http.server 8766

Разница принципиальная. 127.0.0.1 — это адрес обратной петли или внутренний адрес любой современной операционной системы, то есть сервис принимает только подключения из самой операционной системы. 0.0.0.0 означает прослушивание всех IPv4-интерфейсов машины. Это еще не делает сервис доступным «из всего интернета»: дальше могут стоять локальный файрвол, NAT, облачные правила и внешние сетевые фильтры. Но поверхность доступности уже меняется.

Один процесс, один PID, один сокет и настоящий HTTP-запрос: так порт перестает быть абстрактным числом.

Файервол в современном Debian обычно связан с nftables; Debian называет его стандартным механизмом фильтрации пакетов. Посмотреть правила на машине, где установлен nft, можно командой:

sudo nft list ruleset

Debian Wiki по nftables напоминает, что слушающий сокет и доступность сервиса извне — разные вещи.

Еще полезнее научиться различать сетевые ошибки. curl может сказать: Could not resolve host, если имя не удалось превратить в IP-адрес. Может получить отказ в соединении, если адрес найден, но порт никто не слушает. А HTTP 404 означает, что DNS, TCP и веб-сервер уже отработали достаточно хорошо, чтобы приложение ответило: нужного ресурса нет.

DNS, закрытый TCP-порт и HTTP 404 — три разных неисправности, которые пользователь часто описывает одной фразой «сеть не работает».

ping, кстати, при этом не универсальный тест. ICMP может быть заблокирован, а контейнеру или процессу может не хватать прав на raw-сокеты. Хотя TCP-сервис в такой ситуации способен продолжать нормально работать.

Логи: сначала найти событие, потом делать выводы

Большая часть повседневной работы в Linux сводится к тексту: конфигурации, вывод команд, логи. Поэтому grep, tail, sort, uniq, wc и awk — реальный рабочий набор.

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

Поищем неудачные входы:

grep 'Failed password' auth-demo.log

Посчитаем их:

grep -c 'Failed password' auth-demo.log

А теперь ответим на более интересный вопрос: с каких адресов их было больше всего.

grep 'Failed password' auth-demo.log \

  | awk '{for(i=1;i<=NF;i++) if($i=="from") print $(i+1)}' \

  | sort \

  | uniq -c \

  | sort -nr

Результат в лаборатории выглядел так:

6 203.0.113.44

4 198.51.100.27

1 192.0.2.88

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

Здесь важен не столько awk, сколько | (он же пайп). Он передает стандартный вывод одной программы на стандартный ввод следующей. grep отбирает строки, awk вытаскивает адрес, sort группирует значения, uniq -c считает повторы, второй sort ставит самые частые источники наверх.

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

Для просмотра конца файла есть команда tail:

tail -n 50 auth-demo.log

Для слежения за новыми строками в реальном времени можно делать так с флагом f:

tail -f auth-demo.log

На системах с systemd важен еще один источник — журнал journalctl. Например: journalctl -u ssh -n 50 покажет последние записи службы SSH, если она управляется systemd и события попадают в журнал.

Пакеты и службы: от файла к работающему сервису

Debian и Ubuntu используют пакеты .deb и семейство инструментов APT. Базовый цикл выглядит так:

sudo apt update

sudo apt install curl

apt update обновляет индексы, или проще говоря сведения о доступных пакетах, а не весь Linux. Обновление системы и установленных в нее пакетов делается через:

sudo apt upgrade

Посмотреть информацию о пакете можно так, например об утилите curl:

apt show curl

Понять, какому пакету, какой команде в системе принадлежит файл:

dpkg -S /usr/bin/curl

После установки программы появляется второй вопрос: кто и как ее запускает. На обычной Debian-машине службами часто управляет systemd.

Посмотреть статус службы, например ssh, и перезапустить ее можно командами:

systemctl status ssh

sudo systemctl restart ssh

Автозапуск и запуск «прямо сейчас» — разные действия. systemctl start запускает службу в текущем сеансе, systemctl enable настраивает запуск при загрузке системы. Команда:

sudo systemctl enable --now ssh

выполняет оба действия сразу.

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

systemctl status ssh

journalctl -u ssh -n 50

В нашей контейнерной лаборатории systemctl честно не работал: PID 1 занимал supervisord, а не systemd. Это пример того, почему наличие команды systemctl еще не означает, что именно она управляет текущей системой.

SSH: ключи, права и удаленный доступ

SSH — один из первых сервисов, с которым безопасник встречается постоянно. На сервере Debian его обычно устанавливают так:

sudo apt install openssh-server

systemctl status ssh

ss -lntp | grep ':22'

В системе мы можем создать пару ключей ssh. Генерируется одновременно приватный и публичный ключ:

ssh-keygen -t ed25519

Приватный ключ обычно записывается как:

~/.ssh/id_ed25519

Публичный имеет расширение .pub :

~/.ssh/id_ed25519.pub

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

~/.ssh/authorized_keys

OpenSSH документирует эти файлы и формат ключей в руководствах `ssh-keygen` и `sshd`.

chmod 700 ~/.ssh

chmod 600 ~/.ssh/id_ed25519

chmod 600 ~/.ssh/authorized_keys

chmod 644 ~/.ssh/id_ed25519.pub

В нашей лаборатории мы специально открыли копию приватного ключа правами 644. Второй пользователь смог прочитать начало файла. После выставили права chmod 600 и пользователь уже получил Permission denied.

Приватный SSH-ключ с правами 644 читает другой пользователь; после 600 доступ пропадает.

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

При первом подключении: ssh student@server.example клиент может попросить подтвердить контрольный отпечаток ключа самого сервера. Это уже другая пара ключей: пользователь своим приватным ключом доказывает, кто он, а клиент по ключу сервера проверяет, к какому серверу подключается. Слепо писать yes на рабочей инфраструктуре при подключении — тоже не лучшая привычка. Если вы ранее подключались по ssh к серверу и теперь система просит снова подтвердить его идентичность, это может означать, что сервер мог быть скомпрометирован.

Root и sudo: права на одну команду

root имеет UID 0. Учетная запись обладает очень широкими системными правами, поэтому sudo лучше воспринимать именно как механизм делегирования привилегий.

Полезная команда:

sudo -l

Она показывает, что текущему пользователю разрешено запускать через sudo.

Если выполнить: sudo id сама команда может отработать с UID 0, но следующий обычный whoami снова покажет исходного пользователя. Это и есть важная модель: повышение прав можно дать конкретному действию, не превращая весь сеанс в постоянную root-сессию.

Полноценная root-сессия через sudo -i или su - иногда нужна, но для новичка она повышает цену любой опечатки. В терминале символ # часто служит визуальной подсказкой, что перед нами root, а $ — обычный пользователь. Это полезный сигнал для администратора системы. На кали это выглядело бы так:

Еще один связанный механизм — $PATH. Когда мы пишем ls, оболочка ищет исполняемый файл по каталогам из переменной PATH.

Информацию о команде можно посмотреть с помощью command, например:

command -v ls

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

echo $PATH                                                                                                                                                                 

/usr/lib/jvm/java-11-openjdk-amd64/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games

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

Кстати еще полезная команда which (аналог command -v). Она может показать где именно находится исполняемый бинарник для выполняемой в терминале команды:

which bash                                                                                                                                                                                                                                               

/usr/bin/bash

История командной оболочки тоже оставляет следы

Bash может сохранять введенные команды в ~/.bash_history. Поэтому запись секретной информации прямо в командную строку — плохая идея:

some-command --password super-secret

или:

curl -H "Authorization: Bearer REAL_TOKEN" https://example.com/api

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

История командной оболочки при этом не является полноценным аудитом. Пользователь может менять ее настройки, удалять файл, а часть команд при определенной конфигурации вообще не записывается. Для расследования ~/.bash_history — полезный артефакт, но отсутствие команды там не доказывает, что ее никогда не выполняли.

Bash: перестаем копировать команды по одной

После нескольких часов в терминале возникает естественный вопрос: зачем каждый раз вручную запускать stat, find и ss, если проверка повторяется?

Начинается автоматизация с кода возврата. $? содержит статус выполнения предыдущей команды. В Unix-системах 0 обычно означает успех, ненулевое значение — другой результат, смысл которого определяет сама программа.

test -f evidence.txt

echo $?

0

Для существующего файла получим 0, для отсутствующего — 1.

Есть и разделители команд, например && запускает следующую команду после успеха:

mkdir backup && cd backup

Сначала будет создан каталог backup, потом будет осуществлен переход в него.

|| — после неуспеха:

test -f config.yml || echo "config is missing"

Будет выведена запись config is missing, если тест файла завершится неуспешно.

Теперь небольшой скрипт, который проверяет файл и TCP-порт:

#!/usr/bin/env bash

FILE=${1:-./evidence.txt}

PORT=${2:-65530}

WARNINGS=0

echo "Checking file: $FILE"

if [[ -f "$FILE" ]]; then

    echo "[OK] file exists"

    stat -c '     owner=%U group=%G mode=%a (%A)' "$FILE"

else

    echo "[WARN] file does not exist"

    WARNINGS=$((WARNINGS + 1))

fi

if [[ -f "$FILE" ]] && \

   find "$FILE" -maxdepth 0 -perm -0002 -print -quit | grep -q .; then

    echo "[WARN] file is writable by others"

    WARNINGS=$((WARNINGS + 1))

fi

echo "Checking TCP port: $PORT"

if ss -H -lnt "( sport = :$PORT )" | grep -q .; then

    echo "[INFO] TCP port $PORT is listening"

else

    echo "[OK] TCP port $PORT is not listening"

fi

if (( WARNINGS > 0 )); then

    exit 1

fi

exit 0

Этот скрипт мы проверили через bash -n и запускали на тестовых файлах и локальном сервисе. Важная деталь обнаружилась именно во время проверки: сама ss может завершиться с кодом 0, даже если фильтр не нашел слушающий порт, потому что команда успешно выполнила запрос и вернула пустой результат. Поэтому скрипт проверяет наличие строки через grep -q ., а не делает вывод по коду ss в одиночку.

Один скрипт дает разные результаты для нормального и слишком открытого файла.

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

Что смотреть на незнакомом Linux-хосте

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

Сначала собираем контекст:

whoami

id

cat /etc/os-release

uname -srmo

uptime

Потом сеть и процессы:

ip -brief addr

ip route

ss -lntp

ps aux

Пользователи и административные права:

who

w

sudo -l

Место на диске:

df -h

df -i

du -sh /var/* 2>/dev/null

Автозапуск и расписания, если они используются системой:

crontab -l

systemctl list-timers --all

Локальный файрвол, если установлен nftables:

sudo nft list ruleset

Не каждая команда будет доступна в каждом окружении. В контейнере может не быть systemd, crontab или nft; непривилегированный пользователь может не увидеть владельца чужого сокета; ping может быть запрещен. Это не повод дорисовывать результат в голове. Ограничение само по себе часть контекста.

Дальше любой сигнал нужно проверять. 0.0.0.0:8766 — не автоматически уязвимость. Файл 777 — не автоматический след атаки. Пять ошибок входа — не означает компрометацию. Правильный вопрос звучит так: должен ли объект вообще выглядеть именно так, кто его создал, кто может менять, что происходило рядом по времени и какие еще источники это подтверждают.

Где самостоятельного обучения уже хватает

Базовый Linux вполне можно начать осваивать самостоятельно. Для этого не нужно сначала становиться программистом или системным администратором.

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

На этом этапе будет полезным специально ломать учебную систему: получить Permission denied, запустить процесс и найти его, занять порт и диагностировать Address already in use, выставить плохие права тестовому файлу, затем исправить их и проверить результат. Такие ошибки запоминаются лучше таблицы команд.

Когда курс действительно экономит время

Но не со всем можно быстро разобраться самостоятельно. Курс — это не просто попытка обучить вас еще десятку команд. Справка man, документация и поисковик прекрасно с этим справятся.

А вот связать команды в рабочую модель — уже задачка со звездочкой. Почему сервис слушает порт, но клиент до него не доходит? Почему файл разрешает чтение, а пользователь все равно получает Permission denied? Почему процесс исчез после kill, а через минуту появился снова? Что безопасно менять на боевой машине, а что сначала нужно зафиксировать? Какие данные действительно подтверждают гипотезу, а какие просто выглядят подозрительно?

В кибербезопасности к этому добавляется безопасная практика. Учебный стенд можно сломать, восстановить и повторить эксперимент. На рабочей инфраструктуре «попробую chmod 777, вдруг поможет» и «сейчас включу policy drop по SSH» могут привести к весьма плачевному финалу.

Если цель — системно перейти в ИБ, имеет смысл искать программу, где Linux идет не отдельной лекцией про двадцать команд, а связан с сетями, журналами, Bash/Python, администрированием и безопасностью. Например, в текущей программе CyberYozh Academy Специалист по кибербезопасности» с треком от пентеста до мониторинга и расследования инцидентов под системное администрирование Linux выделен отдельный восьминедельный курс, после которого программа переходит к Python и следующим задачам ИБ. Это как раз тот случай, когда курс нужен не ради синтаксиса ls, а ради последовательности и лабораторной практики.

Что дальше

После этого маршрута можно переходить к Kali, но уже без ожидания, что сам дистрибутив чему-то научит. Kali — это дистрибутив на основе Debian с большим набором специализированных инструментов. Когда понятны пользователи, права, процессы, порты, SSH, журналы и Bash, эти специализированные инструменты уже становятся понятнее.

Linux вообще лучше не учить как словарь команд. Полезнее постоянно связывать уровни:

пользователь

    ↓

права

    ↓

файл или процесс

    ↓

служба

    ↓

сокет и порт

    ↓

сеть

    ↓

журнал

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