Поради щодо витонченого переходу на (UNIX) виробничий сервер

Після місяців зневаги, полум’я електронної пошти та боїв управління, наш нинішній сидсмін був звільнений та переданий мені "серверні дані". Такі облікові дані складаються з кореневого пароля і нічого іншого: ні процедур, ні документації, ні підказок, нічого.

Моє запитання: якщо припустити, що він залишив завантажувачі позаду, як я витончено переймаю сервери з якомога меншим простоєм?

Ось деталі:

• один виробничий сервер, розташований на серверній фермі в підвалі; ubuntu сервер 9.x, ймовірно, з grsec патчами (чутки, які я чув останній раз, коли я запитав адміністратора)
• один внутрішній сервер, який містить всю внутрішню документацію, сховище файлів, вікі тощо. Знову ж, сервер ubuntu, кілька років.

Припустимо, що обидва сервери є виправленими та сучасними, тому я б не намагався зламати собі шлях, якщо немає вагомих причин (тобто це можна пояснити вище керівництву).

На виробничому сервері розміщено декілька розміщених веб-сайтів (стандартний apache-php-mysql), LDAP-сервер, набір / сервер електронної пошти ZIMBRA і, наскільки я можу сказати, кілька запущених робочих станцій vmware. Поняття не маю, що там відбувається. Ймовірно, хтось є магістром LDAP, але це дика здогадка.

Внутрішній сервер має внутрішню wiki / cms, підлеглий LDAP, який копіює облікові дані з виробничого сервера, ще кілька робочих станцій vmware та запущені резервні копії.

Я міг би просто зайти до адміністратора ферми сервера, вказати на сервер, сказати їм " sudoвимкніть цей сервер, будь ласка", увійдіть в режимі одиночного користувача та попросіть його. Те саме для внутрішнього сервера. Тим не менш, це означатиме простої, засмучення вищого керівництва, старий сисадмін відстрілюється у мене, кажучи: "бачите? ти не можеш робити мою роботу та інші неприємності, а найголовніше, що мені доведеться потенційно втратити кілька тижнів неоплаченого часу.

На іншому кінці спектру я міг просто увійти як корінь і дюйм через сервер, щоб спробувати зрозуміти, що відбувається. Коли всі ризики викликати сюрпризи залишилися позаду.

Я шукаю рішення в середині: намагайтеся тримати все так, як є, розуміючи, що відбувається і як, і найголовніше уникати запуску будь-яких пасток, що залишилися .

Які ваші пропозиції?

Поки я думав про "практику" з внутрішнім сервером, відключення мережі, перезавантаження з живим компакт-диском, скидання кореневої файлової системи на USB-накопичувач і завантаження її на відключену, ізольовану віртуальну машину, щоб зрозуміти колишній спосіб управління системою. мислення (а-ля «пізнай свого ворога»). Міг би виконати той самий подвиг із виробничим сервером, але повний дамп змусить когось помітити. Можливо, я можу просто увійти як root, перевірити crontab, перевірити .profile на будь-які запущені команди, скинути останній журнал і все, що спадає на думку.

І тому я тут. Будь-який натяк, який би малий не був, буде дуже вдячний.

Час також є проблемою: можуть виникнути тригери через кілька годин або кілька тижнів. Відчуває себе одним із тих поганих голлівудських фільмів, чи не так?

Як вже говорили інші, це виглядає як ситуація, що розгортається.

(Починаючи з кінця)

• Зовсім нове розгортання

Звичайно, ви не можете просто зняти сервери і дозволити інсталятору робити це магія.

Загальний процес

• Отримайте бюджет для резервного сервера (резервне копіювання, як у сховищі даних)
• створити знімки даних і розмістити їх там, перш ніж робити що- небудь
• Підпишіть це керівництво!
• Зберіть список вимог (потрібна вікі, хто використовує екземпляри VMWare, ...)
  • Від управління та
  • Від користувачів
• Підпишіть це керівництво!
• Вимкніть сервіси, що не потрапляють до списку, на тиждень (одна послуга за раз - iptables може бути вашим другом, якщо ви хочете просто закрити зовнішні служби, але у вас є підозра, що вони все ще можуть використовуватися з програми на тому ж хості)
  • Ніякої реакції? -> остаточне резервне копіювання, видаліть із сервера
  • Реакція? -> Поговоріть із користувачами сервісу
  • Збирайте нові вимоги та Geet, які підписали керівництво!
• всі послуги, які не були зареєстровані, за місяць і жодної реакції? -> rm -rf $service(звучить суворо, але що я маю на увазі - виведення з експлуатації послуги)
• отримати бюджет на запасний сервер
• перенести по одній службі за раз на запасні
• підпишіть це керівництво!
• вимкнути перенесений сервер (вимкнено живлення)
• дізнайся, що більше людей кричить на тебе -> так, ти щойно знайшов залишки
• зібрати нові вимоги
• запустити знову і перенести служби
• повторюйте останні 4 кроки, поки протягом місяця не буде людей, які приходять за вами
• перерозподіліть сервер (і підпишіть це керівництво!)
• промити і повторити весь процес.
  • перерозподілений сервер - це ваша нова запасна частина

Що ти здобув?

• Інвентаризація всіх послуг (для вас та менеджменту)
• Документація (адже вам потрібно щось записати для управління, чому б не зробити це належним чином і зробити щось для вас і менеджменту)

Зробив це, це зовсім не весело :(

Чому вам потрібно це підписати керівництву ?

• Зробіть видимими проблеми
• Будьте впевнені, що вас не звільнять
• Можливість пояснення ризиків
  • Це добре, якщо вони не хочуть, щоб ви це робили, але врешті-решт, це рішення, яке вони мають зробити після того, як вони отримають достатній внесок для того, щоб оцінити, чи варто інвестування.

О, і представіть їм загальний план перед початком роботи , з деякими оцінками того, що буде в гіршому і найкращому випадку.

Це буде коштувати багато часу , незалежно від того, передислокації , якщо у вас немає документації. Не потрібно думати про те, що на задньому плані, IMHO, якщо у вас немає документації, перехідна міграція - це єдиний спосіб досягти розумного стану, який принесе цінність для компанії.

Чи є у вас підстави вважати, що попередній адміністратор залишив позаду щось погане, чи ви просто переглядаєте багато фільмів?

Я не прошу бути вибагливим, я намагаюся скласти уявлення про те, яка загроза, на вашу думку, існує і наскільки це ймовірне. Якщо ви вважаєте, що шанси дійсно дуже високі, що якась серйозна деструктивна проблема дійсно може існувати, то я б запропонував розглянути це як би вдале вторгнення в мережу .

У будь-якому випадку, ваші начальники не хочуть зриву простоїв, поки ви займаєтесь цим - яке їх ставлення до запланованого простою до охайних систем проти запланованого простою, якщо в системі є несправність (чи справжня помилка чи негідник адмін) і якщо їхнє ставлення реалістичне порівняно з вашою оцінкою ймовірності того, що у вас дійсно виникнуть проблеми.

Що б ви ще не зробили, врахуйте наступне:

Сфотографуйте систему, яку я отримав зараз . Перш ніж робити щось інше. Справді, візьміть два і відкладіть одну вбік і не торкайтеся її знову, поки ви не дізнаєтесь, що, якщо що, відбувається з вашою системою, це ваш запис про те, якою була система, коли ви її перейняли.

Відновіть "2-й" набір зображень на деяких віртуальних машинах і використовуйте їх для перевірки того, що відбувається. Якщо ви турбуєтесь про те, що запускаються після певної дати, то встановіть дату на рік або близько того у віртуальній машині.

Перш за все, якщо ви збираєтесь вкласти додатковий час у це, я б радив вам фактично за це заплатити . Здається, ви сприйняли неоплачувану понаднормову роботу як факт, судячи з ваших слів, - на мою думку, це не повинно бути таким, а особливо не, коли ви в такому ключі через чужу вину (будь то управління, старий системдмін або, мабуть, комбінація обох).

Спустіть сервери вниз і завантажтеся в режимі єдиного користувача (init = / bin / sh або 1 при grub), щоб перевірити, чи немає команд, які виконуються в системі root. Тут необхідний час простою, дайте зрозуміти керівництву, що немає іншого вибору, окрім простою, якщо вони хочуть бути впевненими, що зможуть зберегти свої дані.

Після цього перегляньте всі кронштейни, навіть якщо вони виглядають законно. Також виконайте повне резервне копіювання якомога швидше - навіть якщо це означає простої. Ви можете перетворити ваші повні резервні копії у запущені віртуальні віртуальні машини.

Тоді, якщо ви можете отримати свої руки на нових серверах або здатних VM, я фактично перенесуть сервіси в нове, чисте середовище, по одному. Це можна зробити в кілька етапів, щоб мінімізувати сприйнятий час простою. Ви отримаєте дуже потрібні поглиблені знання про послуги, відновивши довіру до базових систем.

Тим часом ви можете перевірити наявність руткітів за допомогою інструментів як chkrootkit . Запустіть nessus на серверах, щоб шукати отвори в безпеці, якими може користуватися старий адміністратор.

Редагувати: Я думаю, я не звертався до «витончено» частини вашого питання так добре, як міг. Перший крок (перехід в єдиний користувальницький режим для перевірки пасток для входу), ймовірно, може бути пропущений - старий sysadmin, що дає вам корінний пароль та налаштовує вхід, щоб зробити a, rm -rf /був би майже таким самим, як видалення всіх файлів сам, тому є певно, немає сенсу робити це. Відповідно до частини резервного копіювання: спробуйте використовувати rsyncбазовані рішення, щоб ви могли зробити більшість початкових резервних копій в Інтернеті та мінімізувати час простою.

Я вкладу час у вивчення того, які програми працюють на цих серверах. Після того, як ви дізнаєтеся, що таке, у будь-який час ви можете встановити новий сервер. Якщо ви відчуваєте, що це може бути якийсь задній пристрій, буде непоганою ідеєю просто завантажитися в одному режимі або мати між собою брандмауер між серверами та зовнішньою мережею.

Ви отримуєте параноїзм щодо безпеки. Не потрібно отримувати параної. (бо ви говорите про пастки-бубі). Пройдіть встановлений список програмного забезпечення. Перегляньте, на чому працює служба (netstat, ps тощо), див. Завдання cron. Вимкніть попередній обліковий запис користувача sys admin без видалення облікового запису (це легко зробити, вказавши оболонку на nologin). Прогляньте файли журналу. Я думаю, що з цих кроків і з ваших знань про потреби компанії, з яких ви можете здогадатися про використання серверів, я думаю, ви повинні мати можливість підтримувати їх без будь-яких серйозних помилок.