После нескольких месяцев игнорирования, переписки по электронной почте и управленческих баталий наш нынешний сисадмин был уволен и передал мне «полномочия сервера». Эти полномочия состоят из пароля root и ничего больше: никаких процедур, никакой документации, никаких советов, ничего.
Мой вопрос: если он оставил за собой ловушки, как мне изящно взять на себя управление серверами с минимально возможным временем простоя?
Вот детали:
Один рабочий сервер, расположенный в серверной ферме; ubuntu server 9.x, вероятно, с патчами grsec (слухи, которые я слышал в последний раз, когда спрашивал администратора).
Один внутренний сервер, который содержит всю внутреннюю документацию, хранилище файлов, вики и т. д. Опять же, сервер ubuntu.
Предполагается, что оба сервера пропатчены и обновлены, поэтому я бы не хотел пытаться сломать свой путь, если нет веской причины (т. е. такой, которую можно объяснить высшему руководству).
На рабочем сервере размещено несколько веб-сайтов (стандартный apache-php-mysql), LDAP-сервер, почтовый набор/сервер ZIMBRA и, насколько я могу судить, несколько рабочих станций vmware. Понятия не имею, что там происходит. Возможно, одна из них является LDAP-мастером, но это предположение.
На внутреннем сервере есть внутренняя wiki/cms, ведомый LDAP, который копирует учетные данные с производственного сервера, еще несколько рабочих станций vmware и резервное копирование.
Я могу просто пойти к администратору серверной фермы, указать на сервер, войти в систему в режиме одного пользователя и все сделать по-своему. То же самое для внутреннего сервера. Тем не менее это означало бы простои, недовольство высшего руководства, увольнение старого сисадмина со словами "вот видишь, ты не можешь выполнять свою работу" и прочие неприятности, а самое главное — мне пришлось бы потерять потенциально несколько недель неоплачиваемого времени.
С другой стороны, я мог бы просто войти в систему как root и «пошарить» по серверу, пытаясь понять, что происходит. Со всеми рисками спровоцировать неожиданности.
Я ищу решение посередине: попытаться сохранить все как есть, в то же время понимая что и как происходит, и, самое главное, избегая срабатывания любых оставленных ловушек (если они есть).
Какие у вас есть предложения?
Пока что я думал о том, чтобы «потренироваться» на внутреннем сервере, отключив сеть, перезагрузившись с live cd, сбросив корневую файловую систему на USB-накопитель и загрузив ее на отключенную, изолированную виртуальную машину, чтобы понять образ мышления бывшего сисадмина (a-ля «знай своего врага»). Можно проделать то же самое с рабочим сервером, но полный дамп заставит кого-нибудь обратить внимание. Возможно, я могу просто войти в систему как root, проверить crontab, проверить .profile на наличие запущенных команд, сбросить lastlog и все, что придет в голову.
И именно поэтому я здесь. Любая подсказка, какой бы маленькой она ни была, будет очень признательна. Время также является проблемой: триггеры могут сработать через несколько часов или через несколько недель…
Ответ 1
Полностью новое развертывание
Конечно, вы не можете просто отключить серверы и позволить программе установки делать свою «магию».
Общий процесс
Получите бюджет на резервный сервер (резервное копирование как хранение данных).
Создайте снимки данных и поместите их туда, прежде чем что-либо делать.
Получите подпись руководства!
Соберите список требований (нужна ли вики, кто использует экземпляры VMWare, ...):
от руководства;
от пользователей.
Получите подпись руководства!
Отключите не включенные в список службы на неделю (по одной службе за раз — iptables может быть вашим другом, если вы хотите просто отключить внешние службы, но подозреваете, что они все еще могут использоваться приложением на том же хосте).
Нет реакции? -> последняя резервная копия, удалить с сервера
Реакция? -> Поговорите с пользователями сервиса.
Соберите новые требования и подпишите их у руководства!
Все не включенные в список сервисы не работают в течение месяца и никакой реакции? -> rm -rf $service (звучит грубо, но я имею в виду вывод сервиса из эксплуатации).
Получите бюджет на свободный сервер.
Перенесите на запасной сервер по одной службе за раз.
Получите одобрение руководства!
Выключите перенесенный сервер (отключите питание).
Соберите новые требования.
Снова запустите сервер и мигрируйте службы.
Повторите последние 4 шага, пока в течение месяца к вам не будут приходить люди.
Передислоцируйте сервер (и заручитесь подписью руководства!)
Передислоцированный сервер — это ваш новый запасной.
Что у вас получилось?
Инвентаризация всех услуг (для вас и руководства).
Документация (в конце концов вам нужно что-то записать для руководства, почему бы не сделать это правильно и не сделать что-то для вас и руководства).
Почему вам нужно, чтобы это было подписано руководством?
Сделать проблемы видимыми.
Быть уверенным, что вас не уволят.
Возможность объяснить риски.
И представьте им общий план до того, как вы начнете миграцию, с некоторыми оценками того, что произойдет в худшем и лучшем случае.
Если у вас не будет документации, это будет стоить много времени независимо от передислокации. Не нужно думать о бэкдорах, если у вас нет документации, скользящая миграция — единственный способ достичь вменяемого состояния, которое принесет пользу компании.
Ответ 2
Есть ли у вас основания полагать, что предыдущий администратор оставил после себя что-то плохое, или вы просто оцениваете предыдущие риски?
Я спрашиваю не для того, чтобы пошутить, я пытаюсь понять, какого рода угроза, по вашему мнению, существует и насколько она вероятна. Если вы считаете, что шансы на то, что какая-то серьезная разрушительная проблема действительно существует, тогда я бы предложил относиться к ней так, как если бы это было успешное вторжение в сеть.
В любом случае, ваше начальство не захочет нарушать режим простоя, пока вы с этим разбираетесь — каково их отношение к запланированным простоям для приведения систем в порядок по сравнению с незапланированными простоями, если в системе возникнет сбой (будь то реальный сбой или неавторизованный администратор), и насколько реалистично их отношение по сравнению с вашей оценкой вероятности того, что у вас действительно возникнет проблема. Что бы вы ни делали, подумайте о следующем:
Сделайте снимок систем прямо сейчас. Прежде чем делать что-либо еще. На самом деле, сделайте два снимка, отложите один в сторону и не трогайте его, пока не узнаете, что, если что, происходит с вашей системой, это ваша запись того, какой была система, когда вы ее приняли.
Восстановите «второй» набор образов на несколько виртуальных машин и используйте их для исследования происходящего. Если вы беспокоитесь о том, что что-то может сработать после определенной даты, установите дату на год или около того вперед в виртуальной машине.
Ответ 3
Прежде всего, если вы собираетесь потратить на это дополнительное время, я бы посоветовал вам действительно получить за это деньги. Похоже, вы приняли неоплачиваемую сверхурочную работу как факт, судя по вашим словам — на мой взгляд, так быть не должно, и особенно не тогда, когда вы в таком затруднительном положении по чьей-то вине (будь то руководство, старый сисадмин или, возможно, комбинация обоих).
Выключите серверы и загрузитесь в однопользовательском режиме (init=/bin/sh или 1 в grub), чтобы проверить команды, которые выполняются при входе root. Время простоя здесь необходимо, дайте понять руководству, что нет другого выбора, кроме некоторого времени простоя, если они хотят быть уверены, что смогут сохранить свои данные.
После этого просмотрите все cronjobs, даже если они выглядят корректными. Также выполните полное резервное копирование как можно скорее — даже если это означает простой системы. При желании можно превратить полные резервные копии в работающие виртуальные машины. Затем, если вы сможете получить в свои руки новые серверы или работоспособные виртуальные машины, я бы действительно перенес службы в новые, чистые среды одну за другой. Вы можете сделать это в несколько этапов, чтобы минимизировать предполагаемое время простоя. Вы получите столь необходимые углубленные знания о службах, одновременно восстанавливая уверенность в базовых системах.
Тем временем вы можете проверить наличие руткитов с помощью таких инструментов, как chkrootkit. Запустите nessus на серверах, чтобы найти дыры в безопасности, которые мог использовать старый администратор.
Ответ 4
Вы становитесь параноиком в вопросах безопасности. Нет необходимости в этом. (Потому что вы говорите о минах-ловушках). Просмотрите список установленного программного обеспечения. Посмотрите, какие службы запущены (netstat, ps и т. д.), посмотрите задания cron. Отключите предыдущую учетную запись пользователя sys admin, не удаляя ее (это легко сделать, указав в оболочке nologin). Просмотрите файлы журналов. Я думаю, что с помощью этих шагов и на основе ваших знаний о потребностях компании, из которых вы можете предположить использование серверов, я думаю, вы сможете поддерживать их без каких-либо серьезных ошибок.
Security
