CRS-LNX-01
Практическое администрирование Linux, ограничение полномочий служб и защита серверного узла
Любой веб-сервер, система управления базами данных или соединитель языковой модели исполняется как обычный процесс операционной системы со своими идентификаторами пользователя, открытыми дескрипторами и сетевыми сокетами. Уверенное владение базовыми средствами диагностики Linux позволяет инженеру собственными глазами увидеть открытые порты, избыточные привилегии и доступные на запись каталоги до запуска внешних сканеров.
1. Разграничение полномочий процесса в ядре Linux и правила сетевого экрана
nftables отсекает внешние обращения к внутренним портам, а пространство монтирования systemd переводит системные разделы в режим чтения вокруг единственной рабочей папки службы.2. Проверка сетевых сокетов, ключей удалённого входа и паспортов служб
Нередко внутренняя база данных, очередь сообщений или отладочный сервис по ошибке привязывается ко всем сетевым интерфейсам машины через адрес 0.0.0.0 вместо локальной петли 127.0.0.1. Вызов утилиты ss -tulpen мгновенно выводит полный перечень открытых сокетов с указанием протокола, числового идентификатора владельца и имени процесса.
Защита удалённого управления по протоколу SSH начинается с отключения парольной аутентификации и запрета прямого входа суперпользователя в файле /etc/ssh/sshd_config при переходе на ключи Ed25519. Перед перезапуском фоновой службы инженер обязательно проверяет корректность директив командой sshd -t при открытом резервном окне терминала.
Штатный диспетчер служб systemd позволяет жёстко ограничить любую прикладную программу средствами пространств имён ядра без установки дополнительных систем контейнеризации. Параметры NoNewPrivileges=yes, ProtectSystem=strict, ProtectHome=yes и пустой набор CapabilityBoundingSet= лишают процесс возможности изменить системные файлы даже при успешной ошибке в парсере входных данных.
| Команда, фильтр или режим | Наблюдаемый технический артефакт | Прикладной вывод для инженера |
|---|---|---|
ss -tulpen | Таблица открытых портов TCP и UDP с именами процессов и номерами учётных записей | Показывает внутренние базы и служебные порты, случайно выставленные на внешний сетевой интерфейс |
sshd -T | grep -E 'permitroot|passwordauth' | Итоговые действующие правила аутентификации демона OpenSSH | Подтверждает фактический запрет входа по паролю и прямого подключения от имени root |
systemd-analyze security app.service | Численная оценка открытости службы и перечень пропущенных ограничений | Выявляет доступные на запись разделы диска, лишние привилегии ядра и открытые системные вызовы |
nft list ruleset | Действующая таблица цепочек и правил межсетевого экрана nftables | Подтверждает режим сброса всех входящих пакетов кроме явно разрешённых рабочих портов |
find / -perm -4000 -type f 2>/dev/null | Перечень исполняемых файлов с установленным битом повышения прав SUID | Позволяет обнаружить сторонние утилиты, способные повысить привилегии локального процесса |
3. Лабораторный практикум и связь со стендом автоматической верификации
OpenSSH на криптографические ключи, запуск прикладного демона в песочнице systemd и закрытие лишних входящих соединений в nftables.На учебной виртуальной машине инженер создаёт непривилегированную учётную запись службы, подключает приведённый ниже файл ограничений и перепроверяет оценку защищённости через systemd-analyze security, убеждаясь в переводе корневой файловой системы в режим только для чтения.
# 1. Осмотр открытых сетевых сокетов и привязки к интерфейсам
sudo ss -tulpen
# 2. Файл ограничений /etc/systemd/system/api-worker.service.d/hardening.conf
[Service]
User=api-worker
Group=api-worker
NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
PrivateDevices=yes
ProtectKernelTunables=yes
ProtectControlGroups=yes
ReadWritePaths=/var/lib/api-worker
CapabilityBoundingSet=
SystemCallFilter=@system-service
SystemCallErrorNumber=EPERM
# 3. Перечитывание конфигурации и приборный замер ограничений службы
sudo systemctl daemon-reload && systemd-analyze security api-worker.serviceРучная настройка задаёт базовую защиту отдельного сервера, а при регулярных выкладках конфигурационные файлы проверяются автоматически. На платформе INDRA бесплатный анализатор TOOL-COD-05 разбирает сценарии сборки контейнеров и настройки веб-серверов, а разделы INJ-CMD и CLD-K8S-06 описывают перехват опасных команд до сокета.
4. Инженерные ответы по модулю CRS-LNX-01
Способ исключить потерю удалённого доступа при ужесточении настроек OpenSSH
Перед применением новых правил администратор проверяет синтаксис файла командой sudo sshd -t, сохраняет текущую открытую сессию в первом окне и проверяет вход по ключу во втором независимом терминале.
Отличие обычного запуска службы от непривилегированного пользователя от режима ProtectSystem=strict
Обычный непривилегированный процесс сохраняет чтение общедоступных файлов в /etc, запись в общий каталог /tmp и вызов системных утилит с битом SUID, тогда как ProtectSystem=strict вместе с NoNewPrivileges=yes монтирует дерево операционной системы в режиме только для чтения внутри отдельного пространства имён.
Привязка прикладного процесса к привилегированному порту 443 без запуска от имени root
Вместо запуска всей программы с правами суперпользователя в паспорте службы выдаётся единственная точечная привилегия AmbientCapabilities=CAP_NET_BIND_SERVICE либо приём внешнего шифрованного трафика выносится на обратный прокси перед локальным сокетом 127.0.0.1.
Назначение директивы SystemCallErrorNumber=EPERM при фильтрации системных вызовов ядра
Возврат стандартного кода отказа EPERM вместо аварийного уничтожения процесса оставляет разборчивую запись в системном журнале, помогая инженеру на стенде точно увидеть запрещённый вызов без внезапного обрыва соединений.
Три пакета корпоративного пилота и автономной поставки
Периметр, шифрование и локализация по № 152-ФЗ
Автономная верификация прикладных шлюзов пакетом indra-core
OpenAPI и изолированный тестовый стенд; заказчик получает парную проверку по тридцати классам атак с нулевым числом ложных тревог, защитные правила для mcp-sentinel и сто пять квитанций криптожурнала.Защита автономных агентов и шлюз MITR (приказ № 117)
mcp.json и схемы инструментов агента; заказчик получает формальные политики допустимости и перехват опасных вызовов до открытия сокета.Получить автономный комплект или согласовать пилот
--no-index --find-links) и скрипты независимой перепроверки выдаются по запросу для лабораторных и пилотных испытаний. Оставьте рабочую почту в форме ниже без перезагрузки страницы или напишите напрямую на адрес af@isslab.ai.
Институт-разработчик и оператор стенда
1267700083617, ИНН 9731161602, КПП 773101001, 121352, город Москва, улица Давыдковская, дом 18, помещение VIII). По научно-инженерной программе ИБ 3.0 институт разрабатывает и сопровождает пограничный шлюз MITR и верификационный стенд INDRA, выпускает монографию «Доказанное действие» и открытые программные пакеты под лицензией Apache-2.0 без привлечения сторонних субподрядчиков.