Wskazówki, jak z wdziękiem przejąć serwer produkcyjny (UNIX)

Po miesiącach zaniedbań, płomieni e-mail i bitew zarządczych nasz obecny sysadmin został zwolniony i przekazał mi „poświadczenia serwera”. Takie dane uwierzytelniające obejmują hasło roota i nic więcej: brak procedur, dokumentacji, wskazówek, nic.

Moje pytanie brzmi: zakładając, że pozostawił miny pułapki, jak mogę z wdziękiem przejąć serwery przy jak najmniejszym przestoju?

Oto szczegóły:

• jeden serwer produkcyjny zlokalizowany na farmie serwerów w piwnicy; Serwer Ubuntu 9.x prawdopodobnie z łatkami Grsec (plotki, które słyszałem ostatnim razem, gdy zapytałem administratora)
• jeden wewnętrzny serwer, który zawiera całą wewnętrzną dokumentację, repozytorium plików, wiki itp. Ponownie, serwer ubuntu, kilka lat.

Załóżmy, że oba serwery są załatane i aktualne, więc wolałbym nie próbować włamać się, chyba że jest ku temu dobry powód (np. Można to wytłumaczyć wyższemu kierownictwu).

Serwer produkcyjny ma kilka hostowanych stron internetowych (standardowy apache-php-mysql), serwer LDAP, pakiet / serwer poczty e-mail ZIMBRA i, o ile wiem, kilka uruchomionych stacji roboczych vmware. Nie mam pojęcia, co się tam dzieje. Prawdopodobnie jednym z nich jest mistrz LDAP, ale zgaduje.

Serwer wewnętrzny ma wewnętrzny wiki / cms, podrzędny LDAP, który replikuje poświadczenia z serwera produkcyjnego, kilka innych stacji roboczych vmware i uruchomione kopie zapasowe.

Mógłbym po prostu pójść do administratora farmy serwerów, wskazać na serwer, powiedzieć im „ sudozamknij ten serwer, proszę”, zalogować się w trybie pojedynczego użytkownika i mieć z tym dostęp. To samo dotyczy serwera wewnętrznego. Oznaczałoby to jednak przestój, zdenerwowanie wyższej kadry kierowniczej, stary sysadmin odpychający mnie, mówiąc „rozumiesz? nie możesz wykonywać mojej pracy i innych uciążliwości, a co najważniejsze musiałbym stracić potencjalnie kilka tygodni nieopłaconego czasu.

Na drugim końcu spektrum mógłbym zalogować się jako root i cala przez serwer, aby spróbować zrozumieć, co się dzieje. Po całym ryzyku wywołania niespodzianek.

Szukam rozwiązania pośrodku: staraj się, aby wszystko działało tak, jak jest, jednocześnie rozumiejąc, co się dzieje i jak, a co najważniejsze, unikając wyzwalania pułapek .

Jakie są twoje sugestie?

Do tej pory myślałem o „ćwiczeniu” z wewnętrznym serwerem, odłączaniu sieci, ponownym uruchamianiu z Live CD, zrzucaniu głównego systemu plików na dysk USB i ładowaniu go na odłączoną, izolowaną maszynę wirtualną, aby zrozumieć dawny sysadmin myślenie (a-la „poznaj swojego wroga”). Mogłoby to zrobić to samo z serwerem produkcyjnym, ale pełny zrzut zwróciłby na to uwagę. Być może mogę po prostu zalogować się jako root, sprawdzić crontab, sprawdzić plik .profile pod kątem uruchomionych poleceń, zrzucić ostatni dziennik i cokolwiek, co przychodzi mi do głowy.

I dlatego tu jestem. Wszelkie wskazówki, bez względu na to, jak małe, byłyby bardzo mile widziane.

Problemem jest także czas: za kilka godzin lub za kilka tygodni mogą pojawić się czynniki uruchamiające. Czujesz się jak jeden z tych złych hollywoodzkich filmów, prawda?

Jak powiedzieli inni, wygląda to na sytuację luźno-luźną.

(Od końca)

• Całkowicie nowe wdrożenie

Oczywiście nie możesz po prostu zdjąć serwerów i pozwolić instalatorowi zrobić magii.

Ogólny proces

• Uzyskaj budżet na serwer kopii zapasowych (kopia zapasowa jak w magazynie danych)
• utwórz migawki danych i umieść je tam przed zrobieniem czegokolwiek
• Uzyskaj to podpisane przez kierownictwo!
• Zbierz listę wymagań (czy wiki jest potrzebne, kto korzysta z instancji VMWare, ...)
  • Z zarządzania i
  • Od użytkowników
• Uzyskaj to podpisane przez kierownictwo!
• Zamykaj niepubliczne usługi na tydzień (jedna usługa na raz - iptables może być twoim przyjacielem, jeśli chcesz po prostu zamknąć usługi zewnętrzne, ale podejrzewasz, że nadal można z nich korzystać z aplikacji na tym samym hoście)
  • Brak reakcji? -> końcowa kopia zapasowa, usuń z serwera
  • Odczyn? -> Porozmawiaj z użytkownikami serwisu
  • Zbierz nowe wymagania i Geet, które zostały podpisane przez kierownictwo!
• wszystkie usługi nienotowane przez miesiąc wyłączone i brak reakcji? -> rm -rf $service(brzmi ostro, ale mam na myśli wycofanie usługi)
• uzyskaj budżet na zapasowy serwer
• migruj jedną usługę na zapas
• uzyskaj to podpisane przez kierownictwo!
• zamknij migrowany serwer (wyłącz zasilanie)
• dowiedz się, że więcej ludzi krzyczy na ciebie -> tak, właśnie znalazłeś resztki
• zbierać nowe wymagania
• uruchom ponownie i migruj usługi
• powtarzaj ostatnie 4 kroki, aż przez miesiąc nie będzie żadnych osób
• ponownie wdróż serwer (i uzyskaj to podpisane przez kierownictwo!)
• spłucz i powtórz cały proces.
  • serwer, który został ponownie wdrożony, jest twoją nową częścią zapasową

Co zyskałeś

• Inwentaryzacja wszystkich usług (dla Ciebie i kierownictwa)
• Dokumentacja (w końcu musisz coś napisać do zarządzania, dlaczego nie zrobić tego właściwie i zrobić coś dla siebie i zarządu)

Byłem tam zrobiony, to wcale nie jest zabawne :(

Dlaczego musisz go podpisać przez kierownictwo ?

• Pokaż problemy
• Upewnij się, że nie zostaniesz zwolniony
• Możliwość wyjaśnienia ryzyka
  • W porządku, jeśli nie chcą, żebyś to zrobił, ale w końcu to ich decyzja jest podejmowana po uzyskaniu wystarczającego wkładu, aby ocenić, czy inwestycja jest tego warta.

Och, i przedstaw im ogólny plan, zanim zaczniesz , z kilkoma szacunkami na temat tego, co wydarzy się w najgorszym i najlepszym przypadku.

Będzie to kosztowało dużo czasu, niezależnie od ponownej instalacji, jeśli nie masz dokumentacji. Nie musisz myśleć o tylnych drzwiach, IMHO, jeśli nie posiadasz dokumentacji, migracja na bieżąco jest jedynym sposobem na osiągnięcie rozsądnego stanu, który zapewni wartość dla firmy.

Czy masz powody sądzić, że poprzedni administrator zostawił coś złego za sobą, czy po prostu oglądasz dużo filmów?

Nie chcę być żartobliwy, staram się dowiedzieć, jakie zagrożenie istnieje i jakie jest prawdopodobne. Jeśli uważasz, że szanse są naprawdę bardzo duże, że może istnieć jakiś poważnie zakłócający problem, sugeruję potraktowanie go tak, jakby był udanym włamaniem do sieci .

W każdym razie Twoi szefowie nie chcą zakłócania przestojów, kiedy sobie z tym radzisz - jakie jest ich podejście do planowanego przestoju w celu uporządkowania systemów w porównaniu z nieplanowanymi przestojami, jeśli występuje awaria systemu (czy to prawdziwa awaria, czy nieuczciwy administrator) i jeśli ich postawa jest realistyczna w porównaniu z twoją oceną prawdopodobieństwa, że ​​naprawdę będziesz mieć problem.

Cokolwiek jeszcze zrobisz, weź pod uwagę następujące kwestie:

Zrób zdjęcie systemów już teraz . Zanim zrobisz cokolwiek innego. W rzeczywistości, weź dwa i odłóż jeden na bok i nie dotykaj go ponownie, dopóki nie dowiesz się, co, jeśli w ogóle, dzieje się z twoim systemem, to jest twój zapis tego, jak system był, kiedy go przejąłeś.

Przywróć „2.” zestaw obrazów na niektórych maszynach wirtualnych i użyj ich do zbadania, co się dzieje. Jeśli obawiasz się, że po określonym dniu zostaną uruchomione jakieś rzeczy, ustaw datę o około rok na maszynie wirtualnej.

Przede wszystkim, jeśli zamierzasz zainwestować w to dodatkowy czas, radzę ci za to faktycznie zapłacić . Wygląda na to, że zaakceptowałeś nieopłacone nadgodziny jako fakt, sądząc po twoich słowach - moim zdaniem nie powinno tak być, a szczególnie nie, kiedy jesteś w takiej szczypliwości z powodu winy kogoś innego (czy to zarządzania, stary sysadmin lub prawdopodobnie połączenie obu).

Rozłącz serwery i uruchom system w trybie pojedynczego użytkownika (init = / bin / sh lub 1 w grub), aby sprawdzić komendy uruchamiane przy logowaniu użytkownika root. Konieczne są tutaj przestoje, wyjaśnij kierownictwu, że nie ma wyboru, ale pewne przestoje, jeśli chcą mieć pewność, że zatrzymają swoje dane.

Następnie przejrzyj wszystkie cronjobs, nawet jeśli wyglądają legalnie. Wykonuj także pełne kopie zapasowe tak szybko, jak to możliwe - nawet jeśli oznacza to przestój. Możesz zmienić swoje pełne kopie zapasowe w działające maszyny wirtualne, jeśli chcesz.

Jeśli więc możesz zdobyć nowe serwery lub zdolne maszyny wirtualne, migrowałbym usługi do nowych, czystych środowisk, jeden po drugim. Możesz to zrobić w kilku etapach, aby zminimalizować postrzegane przestoje. Zdobędziesz bardzo potrzebną dogłębną wiedzę na temat usług, jednocześnie przywracając zaufanie do systemów podstawowych.

W międzyczasie możesz sprawdzić rootkity za pomocą narzędzi takich jak chkrootkit . Uruchom nessus na serwerach, aby znaleźć dziury w zabezpieczeniach, których może użyć stary administrator.

Edycja: Wydaje mi się, że nie odniosłem się do „wdzięcznej” części twojego pytania tak dobrze, jak mogłem. Pierwszy krok (przejście do trybu pojedynczego użytkownika w celu sprawdzenia pułapek logowania) można prawdopodobnie pominąć - stary sysadmin podający hasło roota i skonfigurowanie logowania do zrobienia rm -rf /byłoby prawie tym samym, co usunięcie wszystkich plików samemu, więc jest prawdopodobnie nie ma sensu tego robić. Zgodnie z częścią dotyczącą kopii zapasowej: spróbuj użyć rsyncrozwiązania opartego na oprogramowaniu, aby wykonać większość początkowej kopii zapasowej online i zminimalizować przestoje.

Poświęcę czas na naukę, jakie aplikacje działają na tych serwerach. Po tym, jak wiesz, co jest w dowolnym momencie, możesz zainstalować nowy serwer. Jeśli uważasz, że może to być backdoor, dobrym pomysłem będzie po prostu uruchomienie w trybie pojedynczym lub posiadanie zapory ogniowej między serwerami a siecią zewnętrzną.

Masz paranoję na punkcie bezpieczeństwa. Nie ma potrzeby paranoi. (bo mówisz o pułapkach). Przejrzyj listę zainstalowanych programów. Zobacz, jakie usługi są uruchomione (netstat, ps itp.), Zobacz zadania cron. Wyłącz poprzednie konto użytkownika admin sys bez usuwania konta (łatwo to zrobić, kierując powłokę na nologin). Przejrzyj pliki dziennika. Myślę, że dzięki tym krokom i na podstawie Twojej wiedzy o potrzebach firmy, na podstawie których możesz odgadnąć użycie serwerów, myślę, że powinieneś być w stanie je utrzymać bez większych udarów.