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