Этот вводный урок не учит командам - он строит каркас, на который вы будете навешивать всё остальное. Задача администратора, которую мы решаем здесь: перестать защищать систему хаотично, набором случайных твиков с форумов, и начать мыслить моделью угроз и принципами. Экзамен 303-300 версии 3.0 (актуальная редакция, по которой сдают в 2026) проверяет именно зрелость инженера: вы должны понимать, от кого и что защищаете, какой контроль закрывает какой класс атак и какой ценой. Разберём структуру экзамена, ключевые принципы и карту всего курса.
Как это работает
Экзамен 303-300 состоит из пяти крупных тем. Тема 331 - криптография: симметричные и асимметричные шифры, X.509 и собственный удостоверяющий центр, ACME и Let's Encrypt, TLS на веб-сервере и в почте, DNSSEC, шифрование дисков (LUKS2, dm-crypt), eCryptfs и его наследие. Тема 332 - защита хоста: мандатный контроль доступа (SELinux, AppArmor), сетевая изоляция и фильтрация на уровне ядра, целостность файлов, разделение ресурсов. Тема 333 - контроль доступа: PAM глубоко, sudo, LDAP-аутентификация, Kerberos. Тема 334 - сетевая безопасность: VPN (WireGuard, OpenVPN, IPsec), обнаружение вторжений, сканеры. Тема 335 - угрозы и оценка уязвимостей: классы атак, инструменты аудита, реагирование.
Главное, что нужно усвоить до всех технических деталей, - три принципа, которые красной нитью идут через каждый объект экзамена.
Минимизация поверхности атаки. Чем меньше кода слушает порты, чем меньше пакетов установлено, чем меньше сервисов запущено - тем меньше того, что можно сломать. Удалённый демон не имеет уязвимостей по определению. Это не лозунг, а первая команда в любом харденинге.
Защита в глубину. Один рубеж всегда пробивают. Поэтому контроли ставят слоями: сетевой фильтр, потом аутентификация сервиса, потом мандатный контроль доступа ядра, потом аудит. Когда злоумышленник проходит TLS, его должен встретить SELinux, а когда он обходит SELinux - его действия должны остаться в журнале аудита. Ни один слой не считается достаточным.
Наименьшие привилегии. Процесс, пользователь и сервис получают ровно те права, без которых не работают, и ни единым больше. Веб-серверу не нужен root после привязки к порту 80 - он его сбрасывает. Контейнеру не нужны все capabilities - оставляют точечно нужные. Это принцип, который превращает мелкую дыру в локальную проблему вместо полного захвата хоста.
Роль инженера по безопасности здесь не оператор, нажимающий кнопки, а человек, который сначала описывает модель угроз (кто атакующий, что он хочет, какими ресурсами располагает), а потом подбирает контроли под конкретные угрозы, а не все подряд. Защита от соседа по дата-центру и защита от целевой APT-группы - это разные бюджеты и разные решения.
Команды и примеры
Базовая инвентаризация поверхности атаки - то, с чего начинается любой аудит. Смотрим, кто реально слушает сеть (ss заменил устаревший netstat):
Код: Выделить всё
# Открытые сокеты с процессами (нужен root для имён процессов)
ss -tulpnH
# Включённые юнит-файлы systemd - что стартует само
systemctl list-unit-files --state=enabled --type=service
Debian 13 / Ubuntu 24.04 LTS:
Код: Выделить всё
# Сколько всего установлено и поиск явно лишнего
dpkg-query -f '${binary:Package}\n' -W | wc -l
apt list --installed 2>/dev/null | grep -iE 'telnet|rsh|ftp'
Код: Выделить всё
# Аналог через rpm, dnf - это dnf5 в свежих Fedora
rpm -qa | wc -l
dnf list installed | grep -iE 'telnet|rsh|ftp'
Код: Выделить всё
# RHEL/Fedora
getenforce # ожидаем Enforcing
sestatus
# Debian/Ubuntu
aa-status
- Готовиться к старой версии целей. Версия 3.0 экзамена сместила акцент на nftables, WireGuard и современную криптографию. Конспекты под версию 2.0 будут учить вас iptables и устаревшим вещам как основным.
- Путать обязательное и наследие. TCP wrappers (hosts.allow/hosts.deny), xinetd, SysVinit-скрипты всё ещё мелькают в материалах, но в 2026 на проде это systemd, nftables и сетевые фильтры в самих юнитах. Учите легаси только чтобы узнать его на вопросе, не как рабочий инструмент.
- Учить команды без модели угроз. Зазубренный синтаксис sealert или setsebool без понимания, от чего вы защищаетесь, разваливается на сценарных вопросах экзамена и тем более в реальном инциденте.
- Считать, что один сильный слой заменяет остальные. Жёсткий фаервол не отменяет SELinux, а полнодисковое шифрование не защищает работающую систему от удалённого взлома. Слои закрывают разные угрозы.
- Игнорировать различия дистрибутивов. На экзамене и в жизни RHEL-семейство по умолчанию SELinux, Debian-семейство AppArmor. Команды, пути и пакеты расходятся - готовьтесь к обоим.
- Поднимите две виртуалки: одну на Debian 13 или Ubuntu 24.04, вторую на RHEL 10 или Fedora 41+ (это ваш постоянный стенд на весь курс).
- На каждой выполните ss -tulpnH и выпишите, какие сервисы слушают сеть. Для каждого ответьте себе - он точно нужен.
- Сравните число установленных пакетов через dpkg-query и rpm. Найдите хотя бы один заведомо лишний пакет на каждой машине.
- Проверьте статус MAC: getenforce на RHEL и aa-status на Ubuntu. Запишите, в каком режиме система из коробки.
- Остановите и замаскируйте один ненужный сервис: systemctl disable --now <имя> и systemctl mask <имя>. Объясните разницу между disable и mask.
- Составьте на бумаге короткую модель угроз для одной из машин: кто атакующий, какой у него доступ, что он хочет. Это ваша точка отсчёта для следующих уроков.
- Сформулируйте своими словами разницу между минимизацией поверхности атаки и наименьшими привилегиями. Приведите пример, где применяется именно второй принцип, а не первый.
- Почему защита в глубину не сводится к установке самого надёжного из доступных фаерволов? Какие угрозы фаервол не закрывает в принципе?
- Какие пять тем входят в экзамен 303-300 v3.0 и какой класс задач закрывает каждая?
- Чем команда systemctl mask отличается от systemctl disable и в каком сценарии безопасности нужна именно маскировка?
- Какой механизм мандатного контроля доступа активен по умолчанию в RHEL 10, а какой в Ubuntu 24.04, и как проверить его статус на каждой системе?
- Что такое модель угроз и почему без неё набор контролей превращается в случайный харденинг?
