Подрядчик поставил панель управления и ушёл: чем это опасно для вас

MAATRIX

Подрядчик развернул сервер, поставил панель управления — ISPmanager, cPanel, VMmanager, Plesk — настроил сайты и почту, сдал работу и ушёл, потому что проект закончился или отношения прекратились. С этого момента панель на вашем сервере превращается в чёрный ящик: никто в компании не знает, какой у неё версии, на чей аккаунт оформлена лицензия и какой пароль у административного пользователя. Это не абстрактный технический долг — это три конкретных риска, каждый из которых способен обернуться простоем или взломом задолго до того, как на сервере закончится место на диске. Разберём, что именно опасно в брошенной панели и как провести аудит, не дожидаясь инцидента.

Панель — не сервер: почему это отдельная точка риска

Легко перепутать эту статью с вопросом о том, на чей аккаунт хостинг-провайдера оформлен сам сервер — это отдельная и тоже важная тема, разобранная в статье «Сервер оформлен на подрядчика: почему это бомба под вашим бизнесом». Там речь про юридическое владение инфраструктурой: чей договор с провайдером, чья карта привязана к оплате аренды сервера. Здесь — про другое.

Панель управления — это отдельный программный продукт со своей лицензией, своим циклом обновлений, своей учётной записью администратора и часто своим собственным личным кабинетом у вендора (ISPsystem для ISPmanager и VMmanager, cPanel L.L.C., Plesk International). Она может стоять на сервере, который полностью и однозначно принадлежит вашей компании — арендован на ваш аккаунт, оплачивается с вашей карты — и при этом оставаться такой же чёрной дырой, как если бы весь сервер был на чужом имени. Причина в том, что панель — это программа поверх сервера, а не сам сервер, и у неё своя, отдельная от SSH-доступа, система авторизации и лицензирования.

Именно поэтому «мы вернули контроль над сервером» и «мы вернули контроль над панелью» — два разных утверждения. Можно полностью владеть сервером, иметь root по SSH, и всё равно упереться в панель, которая просит логин и пароль, которых никто не знает, или лицензию, которая перестала действовать, потому что оплата шла с карты подрядчика.

Устаревшая версия без обновлений безопасности

Панели управления хостингом — это привилегированное программное обеспечение с доступом к файловой системе, базам данных, почтовым ящикам и часто к правам root на уровне отдельных операций. Уязвимость в панели — это не уязвимость в одном сайте, а потенциальный вход сразу ко всему серверу. У всех крупных панелей — ISPmanager, cPanel, Plesk, VMmanager — регулярно выходят обновления, закрывающие именно такие уязвимости, и у всех есть история реальных CVE с эксплуатацией в проде.

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

Отдельно стоит системный пакетный менеджер сервера: apt upgrade или dnf update обновляют ОС и системные библиотеки, но саму панель — как правило нет, потому что ISPmanager, cPanel и VMmanager используют собственный механизм обновлений, отдельный от системного репозитория. Проверка версии не занимает много времени и не требует входа в веб-интерфейс:

# ISPmanager / VMmanager (ISPsystem)
/usr/local/mgr5/sbin/mgrctl -m ispmgr core.info | grep -i version

# cPanel
/usr/local/cpanel/cpanel -V

# Plesk
plesk version

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

Лицензия панели висит на аккаунте подрядчика

Второй риск — не про безопасность, а про то, что панель однажды просто перестанет работать, причём без всякого взлома. ISPmanager и VMmanager от ISPsystem, платные редакции cPanel и Plesk — всё это коммерческое ПО с лицензией, которая привязывается к конкретному серверу (обычно по IP-адресу) и требует периодического подтверждения у лицензионного сервера вендора. Подтверждение оплачивает тот, на чьём личном кабинете у вендора оформлена лицензия — и очень часто это личный кабинет подрядчика, а не ваш, потому что подрядчику так удобнее: у него один аккаунт на десятки клиентских серверов, иногда с партнёрской скидкой.

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

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

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

Административный пароль от панели знает только подрядчик

Здесь легко попасть в ловушку смешения понятий: root-доступ по SSH к самому серверу — это одно, а логин и пароль администратора внутри панели — совсем другое, отдельное хранилище учётных данных. Можно провести полный аудит SSH-ключей, отозвать доступ подрядчика из authorized_keys, сменить пароль root операционной системы — и всё равно упереться в форму входа панели, где стоит логин admin и пароль, который знает только человек, который панель разворачивал.

Ситуация усугубляется тем, что у многих панелей встроена собственная двухфакторная аутентификация, отдельная от любой корпоративной SSO-системы — TOTP-приложение на личном телефоне подрядчика. Живой пример того, к чему это приводит на практике, разобран в статье «Админ в отпуске, пароля от панели ни у кого: пять часов простоя» — там второй фактор оказался недоступен в критичный момент у собственного сотрудника, но механика для ушедшего подрядчика ровно та же, только без надежды, что он ответит на звонок.

Хорошая новость в том, что раз у вас есть root на уровне ОС, пароль администратора панели восстанавливается без участия подрядчика — у всех основных панелей есть консольная утилита сброса, которая работает локально на сервере и не требует знания старого пароля:

• ISPmanager / VMmanager — управляются консольной утилитой mgrctl из /usr/local/mgr5/sbin/, через которую с root можно создать нового пользователя-администратора или сбросить пароль существующего; точный синтаксис команды зависит от версии панели, актуальный вызов стоит смотреть в документации ISPsystem для вашей ветки.
• cPanel/WHM — пароль root-пользователя WHM сбрасывается через /scripts/resetpass вручную из консоли сервера, без входа в веб-интерфейс.
• Plesk — предусмотрена команда plesk bin admin --set-admin-password НОВЫЙ_ПАРОЛЬ, доступная только под root.

После сброса пароля первым делом отключите TOTP-факторы, привязанные к телефонам, которых у вас нет — иначе после смены пароля вы упрётесь во второй запрос, который снова закрыт для вас, — и заведите 2FA заново на устройство, которое контролирует ваша компания, а не конкретный человек.

Панель открыта в интернет и настроена «на скорую руку»

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

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

# пример для ufw: разрешить порт панели только с вашего офисного/VPN IP
ufw delete allow 1500/tcp
ufw allow from 203.0.113.10 to any port 1500 proto tcp

# проверить, кто вообще слушает порт панели прямо сейчас
ss -tlnp | grep -E '1500|2083|2087|8443'

Стандартные порты у крупных панелей разные: у ISPmanager и VMmanager это обычно 1500, у cPanel — 2083 (пользовательский интерфейс) и 2087 (WHM), у Plesk — 8443. Если в выводе ss вы видите 0.0.0.0 или * рядом с портом панели — она слушает все интерфейсы сервера и доступна из интернета всем, у кого есть браузер и IP-адрес вашего сервера, а не только вам.

Как провести аудит панели за один вечер

Если панель осталась от подрядчика и никто в компании не может с уверенностью ответить на вопросы «какая версия», «чья лицензия», «кто знает пароль» — стоит один раз пройти по короткому чек-листу, а не откладывать до инцидента:

1. Определите панель и версию. Зайдите на сервер по SSH под root и командой из раздела про обновления посмотрите, что установлено и какая версия — не полагайтесь на память о том, что «вроде ставили ISPmanager».
2. Проверьте актуальность версии у вендора. Сравните с текущим релизом на официальном сайте продукта. Отставание больше чем на пару минорных версий или больше года — повод обновляться в ближайшее плановое окно, а не «когда будет время».
3. Найдите, чья лицензия. В разделе «О программе»/«Лицензия» панели посмотрите ID лицензии и привязанный email. Если это не ваш домен — свяжитесь с вендором для переоформления на аккаунт компании.
4. Сбросьте пароль администратора панели через консольную утилиту с root, даже если старый пароль вроде бы «известен» — вы не можете быть уверены, что его не помнит кто-то ещё, кроме нужных вам людей.
5. Пересоздайте вторые факторы на устройствах, которые контролирует компания (корпоративный менеджер паролей или служебный телефон), а не личный телефон бывшего подрядчика.
6. Ограничьте сетевой доступ к порту панели через firewall или VPN — правило из раздела выше занимает пару минут и радикально сокращает поверхность атаки.
7. Зафиксируйте итог в внутренней базе доступов — версия панели, дата лицензии, кто отвечает за продление, где хранится пароль администратора. Смысл этого шага не в бумажной формальности, а в том, чтобы следующий такой аудит не пришлось делать с нуля вслепую.

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

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