Достался сервер от уволившегося админа: что делать в первый час

MAATRIX

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

Первые 10 минут: смотрим, ничего не трогаем

Первое правило первого часа — не запускать apt upgrade, не перезапускать сервисы «для профилактики» и не удалять ничего, что выглядит лишним. Вы пока не знаете, что из этого держит рабочий процесс, а что действительно мусор — и различить это за десять минут невозможно.

Зайдите на сервер по SSH и просто осмотритесь, не меняя состояние:

# сколько сервер живёт без перезагрузки — подсказка, насколько давно его трогали
uptime

# кто сейчас залогинен и кто заходил недавно
who
last -20

# базовая информация: ОС, ядро, архитектура
cat /etc/os-release
uname -a

Если uptime показывает сотни дней без перезагрузки — это не обязательно плохо, но означает, что накопившиеся обновления ядра не применялись очень давно, и перезагрузка (когда до неё дойдёт очередь) может преподнести сюрпризы: не поднимется какой-то сервис, не смонтируется диск, который держался на старом ядре. Держите это в уме, но не бросайтесь перезагружать прямо сейчас.

Заведите текстовый файл — черновой журнал разбора — и сразу фиксируйте туда всё, что узнаёте. Через неделю вы забудете половину деталей, а этот файл станет основой документации, которой у сервера явно не было.

mkdir -p ~/server-handover-$(date +%Y%m%d)
cd ~/server-handover-$(date +%Y%m%d)
echo "Сервер принят $(date). Прежний админ: [имя]. Доступ получен через: [как именно]." > journal.txt

Кто имеет доступ прямо сейчас

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

SSH-ключи и пароли на уровне ОС. Пройдитесь по всем пользователям с шеллом и посмотрите их authorized_keys:

# пользователи, у которых вообще есть шелл (не /nologin и не /false)
awk -F: '$7 !~ /nologin|false/ {print $1, $7}' /etc/passwd

# ключи каждого такого пользователя
for u in $(awk -F: '$7 !~ /nologin|false/ {print $1}' /etc/passwd); do
  echo "== $u ==";
  sudo cat /home/$u/.ssh/authorized_keys 2>/dev/null || sudo cat /root/.ssh/authorized_keys 2>/dev/null;
done

# разрешён ли вход по паролю вообще (если да — это отдельный риск)
grep -E "^PasswordAuthentication|^PermitRootLogin" /etc/ssh/sshd_config

Один authorized_keys может содержать несколько строк — это несколько разных ключей с разных машин, не обязательно принадлежащих одному человеку. Сопоставить конкретный ключ с конкретным человеком по одному файлу нельзя, но сам факт «здесь пять ключей, а мы знаем только про одного бывшего админа» — уже повод спросить у коллег, кто ещё имел доступ.

Sudo и права. Проверьте, кто может выполнять команды от root:

cat /etc/sudoers
ls -la /etc/sudoers.d/
cat /etc/sudoers.d/* 2>/dev/null

Доступ к панели хостинга и облачному аккаунту. Это часто важнее доступа по SSH: если у прежнего админа остались права владельца в личном кабинете провайдера (AWS IAM, DigitalOcean, консоль вашего хостера), он теоретически может остановить или удалить сервер удалённо, даже не заходя внутрь по SSH. Загляните в раздел управления пользователями кабинета — если такой раздел есть и виден вам как владельцу — и проверьте список привязанных email и API-ключей.

Домен и DNS. Кто владелец аккаунта в регистраторе, на какой email он оформлен, кто управляет DNS-зоной — это может быть третья, совершенно отдельная система, не связанная напрямую с сервером. Проверить снаружи, не имея доступа к личному кабинету, можно так:

whois vashdomen.ru
dig NS vashdomen.ru +short

Если доступ к части систем оказался заблокирован — прежний админ не отвечает, а пароли и 2FA привязаны к его личному телефону — это уже не вопрос первого часа, а отдельная задача восстановления контроля. Организационную сторону такого разговора разбирали в статье «Админ уволился и унёс доступы: как вернуть контроль над своей инфраструктурой», а пошаговую техническую процедуру возврата доступа у каждого провайдера — в статье «Администратор ушёл и забрал доступы: возвращаем контроль над своей инфраструктурой».

Что вообще работает: быстрый снимок, не полный аудит

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

# что слушает порты снаружи
ss -tulpn

# сервисы systemd, которые запущены прямо сейчас
systemctl list-units --type=service --state=running

# то же самое, но что стартует при загрузке — даже если сейчас не работает
systemctl list-unit-files --type=service | grep enabled

# если используется docker — отдельный слой сервисов, легко пропустить
docker ps 2>/dev/null

Отдельно посмотрите, какие домены и сайты реально обслуживает веб-сервер — это самый быстрый способ понять, для чего сервер вообще существует:

# nginx
ls /etc/nginx/sites-enabled/ 2>/dev/null
grep -r "server_name" /etc/nginx/sites-enabled/ 2>/dev/null

# apache
ls /etc/apache2/sites-enabled/ 2>/dev/null

И проверьте плановые задачи — часто именно в cron спрятана логика, без которой всё «внезапно перестаёт работать» через день-два после смены админа:

crontab -l
for u in $(cut -f1 -d: /etc/passwd); do echo "== $u =="; crontab -u $u -l 2>/dev/null; done
ls /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/ 2>/dev/null

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

Горящие сроки: домен, SSL, лицензии, оплата хостинга

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

Домен. Дата окончания регистрации видна в whois:

whois vashdomen.ru | grep -i "expir\|paid-till"

SSL-сертификат. Проверьте срок действия прямо с сервера, не заходя в панель:

echo | openssl s_client -connect vashdomen.ru:443 -servername vashdomen.ru 2>/dev/null | openssl x509 -noout -dates

Если сертификат от Let's Encrypt и настроен certbot, проверьте, что автопродление реально работает, а не просто стоит в cron и падает молча уже полгода:

certbot certificates
certbot renew --dry-run
systemctl status certbot.timer 2>/dev/null

--dry-run не продлевает сертификат по-настоящему, а лишь проверяет, что процедура пройдёт успешно — это безопасно выполнить в первый час, в отличие от реального продления вслепую.

Оплата хостинга и VPS. Зайдите в личный кабинет провайдера (или попросите доступ у того, кто платит) и посмотрите дату следующего списания и привязанную карту — если карта принадлежала лично ушедшему сотруднику, при следующем списании платёж может просто не пройти.

Лицензии стороннего ПО. Панели управления (ISPmanager, cPanel, Plesk), коммерческие плагины CMS, антивирус на сервере — у всего этого есть свой цикл продления, отдельный от хостинга и домена. Поищите файлы лицензий и конфиги с датами:

find / -iname "*license*" -o -iname "*.lic" 2>/dev/null | grep -v proc

Таблица того, что стоит проверить в первую очередь и куда смотреть:

Всё, что найдёте с истечением ближе трёх-четырёх недель, сразу заносите в календарь с напоминанием за неделю до даты — не полагайтесь на память в первую неделю после смены админа, когда информации и так слишком много.

Бэкапы: есть ли они и когда снимались в последний раз

Отсутствие бэкапов — не редкость на серверах без документации, и узнать об этом в первый час критично важнее, чем разобраться в архитектуре сервисов: если бэкапов нет, любое дальнейшее действие (даже осторожное) становится рискованнее на порядок.

Поищите очевидные места и признаки автоматического бэкапа:

# скрипты с "backup" в имени — частая практика самодельных решений
find / -iname "*backup*" -type f 2>/dev/null | grep -v proc | head -50

# резервные копии баз данных рядом со стандартными путями
find / -iname "*.sql.gz" -o -iname "*.dump" 2>/dev/null | grep -v proc

# cron уже проверили выше — но специально поищите "backup", "rsync", "dump" в задачах
crontab -l | grep -iE "backup|rsync|dump"

# настроен ли рабочий облачный синк (rclone — частый выбор для бэкапов на S3-совместимое хранилище)
which rclone && rclone listremotes 2>/dev/null

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

Если бэкап найден — не доверяйте ему на слово, посмотрите дату последнего файла:

ls -lt /path/to/backups/ | head -5

Разница между «бэкап есть» и «бэкап пятимесячной давности» огромна: формально пункт закрыт, а по факту вы всё ещё без защиты. Если бэкапов нет вообще или последний безнадёжно устарел — первое реальное действие, которое стоит сделать в конце первого часа (уже не «смотрим», а «делаем»): снять хотя бы один ручной снапшот прямо сейчас, до всех остальных изменений.

# быстрый дамп всех баз MySQL/MariaDB одним архивом
mysqldump --all-databases | gzip > ~/emergency-backup-$(date +%Y%m%d).sql.gz

# снапшот диска средствами хостинг-провайдера — обычно доступен из панели без входа на сервер

Полная проверка того, восстанавливается ли бэкап на самом деле (а не просто существует), — это уже задача не первого часа, а первого дня: подробный разбор доверия к унаследованной машине, включая проверку восстановления, есть в статье «Сервер достался по наследству: проверка чужой машины перед боем».

Что можно сделать сразу, а что подождёт до полного аудита

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

Сделать сразу, без риска что-то сломать:

• Добавить собственный SSH-ключ как независимый способ попасть на сервер, не удаляя чужие ключи — на случай, если единственный оставшийся доступ вдруг перестанет работать.
• Снять внеплановый снапшот/бэкап, если штатных не нашлось (см. предыдущий раздел) — это не меняет ничего в работающих сервисах.
• Записать в журнал разбора всё, что узнали: список сервисов, найденные cron-задачи, сроки истечения, наличие или отсутствие бэкапов.
• Поставить напоминания по всем горящим срокам из предыдущего раздела.

Отложить до полного аудита, даже если руки чешутся:

• Не удалять «бесхозные» cron-задачи и процессы — то, что выглядит забытым, может быть единственным, что держит интеграцию со сторонним сервисом.
• Не менять пароли и не отзывать все чужие ключи одним махом — если прежний админ ещё частично сотрудничает или если какая-то автоматизация использует его учётные данные (например, деплой-скрипт с его SSH-ключом), резкий отзыв доступа сломает рабочий процесс раньше, чем вы найдёте, что именно сломалось.
• Не запускать apt upgrade или обновление ядра — сначала нужно понять зависимости и убедиться, что бэкап действительно есть и восстанавливается.
• Не отключать сервисы, назначение которых неясно, «на всякий случай» — сначала выясните, что это, хотя бы через lsof на слушающий порт и содержимое рабочей директории процесса.

Разделение на «сразу» и «подождёт» — это не про осторожность ради осторожности, а про то, что необратимые решения в первый час почти никогда не нужны: сервер, скорее всего, простоял без присмотра и до вас какое-то время, лишний день на осторожный разбор не увеличит риск критически, а поспешное действие — вполне может.

Частые вопросы