Сервер к публикации готов

~60 мин

Не запущена Запускается обычно ~20 с

Ситуация

node1 — новый сервер заявок helpdesk: на порту 80 стоит nginx, за ним приложение — служба lab-helpdesk. Сервер вот-вот откроют для всей сети, но проверка безопасности завернула его и прислала список замечаний:

вход по SSH пускают по паролю;
на сервер пускают root;
из сети видны лишние порты, помимо сайта;
защиты от перебора паролей нет;
служба приложения работает от root без каких-либо ограничений.

node1 — твой терминал. node2 — рабочая машина администратора в той же сети; с неё на node1 ходят по ключу. Команды на node2 выполняй через SSH: ssh node2 'команда' или войди в оболочку — ssh node2, назад — exit. sudo на обеих машинах работает без пароля. Другого входа на node2 нет: не закрой себе SSH и не трогай его настройки.

Задача

Вход по SSH на node1 — только по ключу: учётная запись student входит с node2 своим ключом, а пароль сервер больше не предлагает.
Root по SSH на node1 не входит — даже с ключом, который работал раньше, — и пароль ему не предлагается.
Из сети на node1 открыты только порты 22 и 80; порты 8000 и 8080 закрыты. Правила остаются и после перезагрузки node1.
Перебор паролей по SSH ловится: fail2ban работает, запускается сам и следит за входами — jail sshd активен и умеет банить.
Служба lab-helpdesk работает не от root и ограничена средствами systemd (как минимум NoNewPrivileges и ProtectSystem), так что systemd-analyze security lab-helpdesk.service даёт оценку ниже 6.0. При этом сайт по-прежнему отвечает: curl http://localhost/ на node1 возвращает список заявок.

Ограничения

Меняй только node1. Настройки SSH, ключи и службы на node2 не трогай.
Правила межсетевого экрана и настройки служб должны пережить перезагрузку: храни их в файлах (/etc/...): живое состояние перезагрузку не переживёт.
Доступ администратора с node2 по ключу должен сохраниться — и для student, и после всех правок.

Интернета в лабе нет — только сеть между node1 и node2, всё нужное установлено. Иди по списку замечаний: какие порты слушают службы — sudo ss -tlnp; что видно с node2 — проверяй прямо оттуда. После каждой правки перечитывай состояние: sudo systemd-analyze security lab-helpdesk.service, sudo fail2ban-client status sshd, sudo nft list ruleset.

Цели лабы

0 из 5

С node2 вход на node1 — только по ключу (student входит своим ключом, пароль сервер не предлагает) — ещё не проверялась
Root по SSH на node1 не входит даже с прежде рабочим ключом, и пароль ему не предлагается — ещё не проверялась
С node2 на node1 открыты только 22 и 80, а 8000 и 8080 закрыты — и правила переживают перезагрузку — ещё не проверялась
fail2ban работает, запускается сам и следит за входами по SSH — jail sshd активен с действием бана — ещё не проверялась
Служба lab-helpdesk отвечает, работает не от root и ограничена (NoNewPrivileges, ProtectSystem), systemd-analyze security — ниже порога — ещё не проверялась

Подсказки

открыто 0 из 3 · открываются по одной

Подсказка 1

Показать решение после 3 неудачных проверок

Для запуска машины нужен вход

Машина запускается на твой аккаунт, там же хранится прогресс. Читать можно без входа.

После входа вернёшься на эту лабу.

Безопасность · подобрано по лабе

sshd — SSH-сервер

Шпаргалка

$_ — вставить в терминал

sudo sshd -t проверить синтаксис конфига
sudo sshd -T | grep -i permitroot действующее значение параметра
sudo systemctl reload ssh применить без разрыва сессий
ss -tlnp | grep :22 слушает ли порт
journalctl -u ssh -f логи подключений в реальном времени

Главный конфиг — /etc/ssh/sshd_config (+ сниппеты в /etc/ssh/sshd_config.d/). Безопасная база:

PermitRootLogin no
PasswordAuthentication no         # только ключи
PubkeyAuthentication yes
Port 22

Применить изменения безопасно (не обрывая текущую сессию):

bash

sudo sshd -t                      # проверить синтаксис конфига
sudo sshd -T | grep -i permitroot # показать ДЕЙСТВУЮЩИЕ значения (важно!)
sudo systemctl reload ssh         # применить (юнит ssh)

Важно. Меняя SSH-конфиг удалённо, держи второй открытый сеанс — так ошибка не закроет доступ к серверу. Страховка с авто-откатом по таймеру: sudo sh -c 'sleep 300 && systemctl restart ssh' &.

Хардненинг

Параметр	Зачем
`PermitRootLogin no`	не пускать root напрямую
`PasswordAuthentication no`	только ключи (главное против брутфорса)
`MaxAuthTries 3`	меньше попыток за коннект
`AllowUsers alice bob`	белый список пользователей
`AllowGroups sshusers`	белый список групп
`AllowTcpForwarding no`	запретить туннели (если не нужны)
`X11Forwarding no`	отключить проброс X
`ClientAliveInterval 300`	отключать мёртвые сессии

Гибко — через Match (для группы/адреса):

Match Group sftponly
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no

Команды

bash

systemctl status ssh              # состояние сервера
sshd -t                           # проверка sshd_config (синтаксис)
sudo sshd -T                      # эффективная конфигурация (все параметры)
ss -tlnp | grep :22               # слушает ли порт
journalctl -u ssh -f              # логи подключений/отказов
journalctl -u ssh | grep -i fail  # неудачные входы (брутфорс? см. fail2ban)
ssh -v user@host                  # отладка подключения с клиента

Permission denied (publickey)

Права на сервере: ~/.ssh=700, authorized_keys=600, владелец — сам пользователь. journalctl -u ssh → часто «Authentication refused: bad ownership or modes». См. ssh-keys.

Connection refused

Сервер не слушает порт: ss -tlnp | grep :22, systemctl status ssh. Либо порт закрыт файрволом — разреши 22/tcp (см. firewall).

Connection timed out

Сетевой/файрвол-уровень (не дошёл до sshd): маршрут, security group, nftables. Проверь nc -zv host 22.

Сменил порт — не пускает

SELinux/порт не разрешён, файрвол на старом порту, или клиент идёт на 22. Открой новый порт в firewall, проверь sshd -T | grep -i port.

Заблокировал себя сменой конфига

Зайди через консоль гипервизора/serial и откати sshd_config (или sshd -t показал бы ошибку до reload — всегда проверяй).

reload/restart применяют новый конфиг ко всем последующим подключениям сразу; ошибка в PermitRootLogin, AllowUsers или PasswordAuthentication может закрыть доступ, включая твой собственный. Правь конфиг только при открытом втором сеансе и проверяй sshd -t до перезапуска, а не после. Отключение PasswordAuthentication без предварительно установленного и проверенного ключа оставит сервер без единого рабочего способа входа.