🐧 Linux · 20 вопросов · ~45 мин · ⏱ Таймер 45:00 · Сложный · 👥 1 прошёл

Защита Linux-сервера

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

Отвечено: 0 из 20

⏱ --:--

💡 Инструкция: Выбери один ответ из четырёх. На 20 вопросов отведено 45 минут. Не меньше половины заданий требуют разобрать команды, сценарий Bash, конфигурацию или диагностический вывод. После завершения откроются общий процент, четыре тематические шкалы, правильные ответы и краткий разбор каждого решения.

Вопрос 1 из 20

Сервер работает на выпуске дистрибутива, срок поддержки которого закончился. Почему обычный apt update не решает риск?

. /etc/os-release
printf '%s %s\n' "$PRETTY_NAME" "$VERSION_CODENAME"
apt-cache policy

Старый выпуск становится безопасным из-за стабильности apt update обновляет только ядро, а остальные пакеты после EOL ещё поддерживаются После EOL ядро перестаёт загружаться в тот же день Для этого выпуска уже не выходят исправления безопасности

Вопрос 2 из 20

Как разумнее расставлять приоритеты патчей?

Откладывать патч до следующего общего окна независимо от доступности уязвимого сервиса Учитывать реальную экспозицию, эксплуатацию уязвимости, критичность актива и последствия обновления Устанавливать только пакеты с самым длинным описанием CVE Обновлять сначала программы, которыми никто не пользуется

Вопрос 3 из 20

Почему «обновить всё и сразу перезагрузить» без проверки — слабый регламент?

apt-get -s full-upgrade
# затем список изменений, резервная копия и проверки

Перезагрузка запрещена Linux Любое обновление обязательно разрушает данные Пакеты нельзя обновлять группой Нет контрольных проверок, зависимостей и отката

Вопрос 4 из 20

После обновления OpenSSL сервис продолжает старый процесс. Что важно сделать?

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

Вопрос 5 из 20

Что лучше подтверждает успешное безопасностное обновление веб-службы?

dpkg-query -W openssl nginx
systemctl is-active nginx
curl -fsS --resolve app.example:443:127.0.0.1 https://app.example/health

Нулевой код пакетного менеджера без проверки состояния процесса Отсутствие новых записей уровня error сразу после обновления Только дата изменения файла библиотеки на диске Версия пакета, состояние службы и прикладные HTTP/TLS-проверки

Вопрос 6 из 20

Какой подход к firewall проще проверять?

table inet filter {
 chain input {
  type filter hook input priority 0; policy drop;
  ct state established,related accept
  iif lo accept
  tcp dport {22,443} ip saddr 192.0.2.0/24 accept
 }
}

Политика запрета по умолчанию с явными разрешениями нужных направлений Открыть диапазон 1-65535 для мониторинга Разрешить всё и надеяться на отсутствие слушателей Разрешить входящие соединения только на порты выше 1024

Вопрос 7 из 20

Внутренняя база нужна только приложению на том же хосте. Где безопаснее слушать?

На 0.0.0.0 с простым паролем На отдельном VLAN-интерфейсе без ограничений firewall На публичном IPv6 без firewall На loopback или Unix-сокете с точными правами

Вопрос 8 из 20

Почему ss -lnt показывает только часть фактической экспозиции?

sudo ss -lntup
sudo nft list ruleset
docker ps --format '{{.Ports}}'

Не видны правила фильтрации, публикация контейнерных портов и внешняя маршрутизация ss скрывает все порты, открытые процессами без прав root Отсутствие DNS-имени делает слушающий порт недоступным по IP LISTEN на 0.0.0.0 сам по себе доказывает доступность из любой внешней сети

Вопрос 9 из 20

Временное правило открывает SSH всему интернету «на час». Как уменьшить риск?

Отключить журнал SSH Ограничить источники и автоматически закрыть правило Разрешить root с паролем для удобства Сменить порт SSH, не ограничивая источники подключения

Вопрос 10 из 20

Как подтвердить, что порт не доступен из запрещённой сети?

# На узле из запрещённой сети:
nc -vz server.example 8443
# На сервере во время проверки:
sudo tcpdump -ni any 'tcp port 8443'
sudo nft list ruleset -a

Посмотреть счётчик правил, но не отправлять контрольный трафик Проверить только соединение с localhost и состояние процесса Проверить с узла запрещённой сети и сопоставить результат с firewall и tcpdump Проверить наличие DNS-имени для сервиса из запрещённой сети

Вопрос 11 из 20

Почему отдельная учётная запись для каждой службы лучше общего пользователя app?

Один пользователь не может запускать два процесса одновременно Разделение ограничивает последствия взлома одной службы Общий пользователь не способен читать файлы нескольких служб Разные UID получают отдельные очереди процессорного времени

Вопрос 12 из 20

Как безопаснее отключить интерактивный вход неиспользуемой служебной учётной записи?

sudo usermod -L -s /usr/sbin/nologin legacyapp
getent passwd legacyapp

Оставить обычную оболочку, но удалить домашний каталог пользователя Удалить запись из /etc/passwd, сохранив работающие процессы с неизвестным UID Добавить пользователя в sudo и запретить только парольный SSH-вход Назначить nologin, заблокировать пароль и проверить способы запуска службы

Вопрос 13 из 20

Почему PermitRootLogin no после проверки персональных sudo-аккаунтов улучшает аудит?

Host key сервера заменяет учёт имени пользователя при повышении прав sudo автоматически подписывает журнал каждой команды личным сертификатом Общий вход root остаётся, но команды связываются с владельцем SSH-ключа Вход и последующее повышение прав связываются с конкретной персональной учётной записью

Вопрос 14 из 20

Какое sudo-правило наиболее опасно скрыто расширяет полномочия?

alice ALL=(root) NOPASSWD: /usr/bin/vim *

Право запускать редактор, способный читать и изменять произвольные файлы от root Право запустить ping до одного фиксированного адреса Право выполнить systemctl status одной заранее заданной службы Право читать журнал только собственного пользовательского unit

Вопрос 15 из 20

Файлы принадлежат UID 1002, но такого имени больше нет. Что это означает?

find /srv -xdev -nouser -ls
getent passwd 1002

UID больше не участвует в проверке доступа Файлы недоступны, пока UID 1002 снова не получит имя Файлы стали общедоступными Имя исчезло, но права продолжают действовать по UID 1002

Вопрос 16 из 20

Почему пароль в аргументе command --password secret опасен?

ps -eo user,pid,args | grep '[c]ommand --password'

Аргументы видны только root и владельцу процесса, поэтому подходят для секретов Аргумент виден только в истории текущей оболочки владельца процесса Программа не получает аргументы после --password Аргументы могут быть видны другим процессам и попадать в аудит или историю

Вопрос 17 из 20

Файл /etc/app/secret.env имеет 0644. В чём проблема?

Переменные окружения перестанут загружаться без режима 0777 Бит 0644 разрешит запуск файла как программы всем пользователям Любой локальный пользователь сможет прочитать секрет, если ему доступен путь Служба потеряет чтение файла, потому что владелец имеет только rw-

Вопрос 18 из 20

Почему маскирование секретов только в основном app.log недостаточно?

grep -RIl --exclude-dir=proc --exclude-dir=sys 'TOKEN=' /etc/app /var/log/app 2>/dev/null

Правило маскирования journald автоматически применяется к дампам и резервным копиям Секрет может попасть в stderr, журнал прокси, дамп памяти, метрики или резервную копию Секретные значения нельзя включать ни в одну резервную копию, даже в зашифрованную Секрет хранится только в основном журнале, остальные каналы получают уже маскированное значение

Вопрос 19 из 20

Что должно входить в ротацию скомпрометированного ключа API?

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

Вопрос 20 из 20

Как резервировать зашифрованный секрет так, чтобы копия оставалась восстанавливаемой?

restic backup /etc/app/secret.enc
# ключ репозитория и процедура доступа хранятся отдельно

Шифровать только имя файла, оставляя содержимое секрета открытым Не проводить пробное восстановление, чтобы лишний раз не обращаться к ключу Хранить ключ расшифрования в том же незашифрованном архиве для удобства восстановления Раздельно защищать зашифрованную копию и резервный путь получения ключа, проверяя восстановление

Ответьте на все 20 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу