После месяцев пренебрежения, переполоха электронной почты и управленческих битв наш нынешний системный администратор был уволен и передал мне «учетные данные сервера». Такие учетные данные состоят из пароля root и ничего больше: ни процедур, ни документации, ни советов, ничего.
Мой вопрос: если предположить, что он оставил мины-ловушки, как мне изящно взять под контроль серверы с минимальным временем простоя?
Вот подробности:
Предположим, что оба сервера обновлены и исправлены, поэтому я бы предпочел не пытаться взломать свой путь, если нет веской причины (т.е. это можно объяснить высшему руководству).
На производственном сервере размещено несколько веб-сайтов (стандартный apache-php-mysql), сервер LDAP, пакет / сервер электронной почты ZIMBRA и, насколько я могу судить, работает несколько рабочих станций vmware. Понятия не имею, что там происходит. Вероятно, один из них является мастером LDAP, но это дикая догадка.
На внутреннем сервере есть внутренний wiki / cms, подчиненное устройство LDAP, которое реплицирует учетные данные с рабочего сервера, еще несколько рабочих станций vmware и выполняются резервные копии.
Я мог бы просто пойти к администратору фермы серверов, указать на сервер и сказать им 'sudo выключите этот сервер, пожалуйста », войдите в систему в однопользовательском режиме и я могу с ним справиться. То же и для внутреннего сервера. Тем не менее, это будет означать простои, недовольство высшего руководства, ответный огонь старого системного администратора: «Видишь? ты не можешь выполнять мою работу »и другие неприятности, и, что наиболее важно, мне пришлось бы потенциально потерять несколько недель неоплачиваемого времени.
С другой стороны, я мог просто войти в систему как root и пройти через сервер, чтобы попытаться понять, что происходит. Со всеми рисками спровоцировать сюрпризы позади.
Я ищу решение посередине: постарайтесь, чтобы все работало, как есть, понимая, что и как происходит, и самое главное избегая срабатывания любых оставленных мин-ловушек.
Ваши предложения?
До сих пор я думал о «попрактиковаться» с внутренним сервером, отключении сети, перезагрузке с живого компакт-диска, сбросе корневой файловой системы на USB-накопитель и загрузке ее на отключенную изолированную виртуальную машину, чтобы понять прежний способ системного администратора мышление (а-ля «знай своего врага»). Можно было бы проделать то же самое с производственным сервером, но полный дамп заставит кого-нибудь заметить. Возможно, я могу просто войти в систему как root, проверить crontab, проверить .profile на наличие запущенных команд, выгрузить последний журнал и все, что придет в голову.
И поэтому я здесь. Мы будем благодарны за любой намек, даже самый маленький.
Время также является проблемой: триггеры могут сработать через несколько часов или несколько недель. Похоже на один из тех плохих голливудских фильмов, не так ли?
Как говорили другие, это выглядит как безвыходная ситуация.
(Начиная с конца)
Конечно, нельзя просто отключить серверы и позволить установщику творить чудеса.
rm -rf $service (звучит резко, но я имею в виду списание службы)Там было сделано, это совсем не весело :(
О, и представьте им общий план прежде чем ты начнешь, с некоторыми оценками того, что произойдет в худшем и лучшем случае.
Это воля стоить много времени независимо от повторного развертывания, если у вас нет документации. Нет необходимости думать о бэкдорах, ИМХО, если у вас нет документации, скользящая миграция - единственный способ достичь нормального состояния, которое принесет пользу компании.
Прежде всего, если вы собираетесь потратить на это дополнительное время, я бы посоветовал вам на самом деле получать деньги для этого. Судя по вашим словам, вы, кажется, приняли как факт неоплачиваемую сверхурочную работу - так быть не должно, на мой взгляд, тем более, когда вы находитесь в таком затруднительном положении из-за чужой вины (будь то руководство, старый системный администратор или, возможно, их комбинация).
Выключите серверы и загрузитесь в однопользовательском режиме (init = / bin / sh или 1 в grub), чтобы проверить наличие команд, которые выполняются при входе в систему root. Здесь необходимо время простоя, дайте понять руководству, что у него нет выбора, кроме некоторого простоя, если они хотят быть уверены, что смогут сохранить свои данные.
После этого просмотрите все cronjobs, даже если они выглядят законно. Также как можно скорее выполните полное резервное копирование, даже если это приведет к простою. Вы можете превратить ваши полные резервные копии в работающие виртуальные машины, если хотите.
Затем, если вы сможете заполучить новые серверы или подходящие виртуальные машины, я бы фактически перенес службы в новые, чистые среды один за другим. Вы можете сделать это в несколько этапов, чтобы минимизировать предполагаемое время простоя. Вы получите столь необходимые глубокие знания об услугах, вернув себе уверенность в базовых системах.
А пока вы можете проверить наличие руткитов с помощью таких инструментов, как chkrootkit. Бегать несус на серверах для поиска дыр в безопасности, которые может использовать старый администратор.
Изменить: я думаю, что я не ответил на «изящную» часть вашего вопроса, как мог. Первый шаг (переход в однопользовательский режим для проверки ловушек входа), вероятно, можно пропустить - старый системный администратор предоставит вам пароль root и настроит логин для выполнения rm -rf / будет почти то же самое, что удалить все файлы самостоятельно, так что, вероятно, нет смысла делать это. Согласно части резервного копирования: попробуйте использовать rsync решение на основе, поэтому вы можете делать большую часть первоначального резервного копирования в режиме онлайн и минимизировать время простоя.
Есть ли у вас основания полагать, что предыдущий админ оставил после себя что-то плохое, или вы просто смотрите много фильмов?
Я не прошу шутить, я пытаюсь понять, что за угроза, по вашему мнению, существует и насколько она вероятна. Если вы думаете, что действительно очень высока вероятность того, что действительно может существовать какая-то серьезная проблема, то я бы посоветовал ее вылечить. как если бы это было успешное вторжение в сеть.
В любом случае, ваше начальство не хочет прерывания простоя, пока вы занимаетесь этим - каково их отношение к запланированному времени простоя для наведения порядка в системах по сравнению с незапланированным временем простоя в случае неисправности в системе (будь то настоящая ошибка или мошенник админ), и если их отношение реалистично по сравнению с вашей оценкой вероятности того, что у вас действительно возникнут проблемы.
Что бы вы ни делали, учтите следующее:
Сделайте снимок систем rпрямо сейчас. Прежде чем делать что-нибудь еще. Фактически, возьмите два, отложите один в сторону и не трогайте его снова, пока не узнаете, что, если что-то, происходит с вашей системой, это ваша запись того, какой была система, когда вы ее взяли.
Восстановите «второй» набор образов на некоторых виртуальных машинах и используйте их для проверки того, что происходит. Если вы беспокоитесь о том, что что-то срабатывает после определенной даты, установите дату на год вперед на виртуальной машине.
Я потрачу время на изучение того, какие приложения работают на этих серверах. После того, как вы узнаете, что к чему, в любой момент вы можете установить новый сервер. Если вы чувствуете, что это может быть какой-то бэкдор, будет хорошей идеей просто загрузиться в одиночном режиме или установить межсетевой экран между серверами и внешней сетью.
Вы становитесь параноиком по поводу безопасности. Не нужно впадать в паранойю. (Кстати, вы говорите о минах-ловушках). Просмотрите список установленного программного обеспечения. Посмотрите, какие службы работают (netstat, ps и т. Д.), См. Задания cron. Отключите предыдущую учетную запись пользователя системного администратора, не удаляя учетную запись (легко сделать, указав оболочку на nologin). Просмотрите файлы журнала. Я думаю, что с помощью этих шагов и вашего знания потребностей компании, из которых вы можете догадаться об использовании серверов, я думаю, вы сможете поддерживать их без каких-либо серьезных ошибок.