Czy zainstalować ponownie po naruszeniu zasad roota?

Po przeczytaniu tego pytania na temat kompromisu na serwerze zacząłem zastanawiać się, dlaczego ludzie nadal wierzą, że mogą odzyskać zainfekowany system za pomocą narzędzi do wykrywania / czyszczenia lub po prostu naprawiając lukę, która została wykorzystana do naruszenia bezpieczeństwa systemu.

Biorąc pod uwagę wszystkie różne technologie rootkitów i inne rzeczy, które haker może zrobić, większość ekspertów sugeruje, aby ponownie zainstalować system operacyjny .

Mam nadzieję, że uda mi się uzyskać lepszy pomysł, dlaczego więcej osób nie tylko zdejmuje i nuke systemu z orbity.

Oto kilka punktów, którymi chciałbym się zająć.

• Czy istnieją warunki, w których format / reinstalacja nie wyczyściłyby systemu?
• Jak myślisz, w jakich warunkach można wyczyścić system i kiedy należy przeprowadzić pełną ponowną instalację?
• Jakie masz uzasadnienie przeciwko przeprowadzeniu pełnej ponownej instalacji?
• Jeśli nie zdecydujesz się na ponowną instalację, to z jakiej metody korzystasz, aby mieć pewność, że został wyczyszczony i zapobiec ponownemu uszkodzeniu.

Decyzja bezpieczeństwa jest ostatecznie decyzją biznesową dotyczącą ryzyka, podobnie jak decyzja o tym, jaki produkt wprowadzić na rynek. Gdy obramiasz go w tym kontekście, decyzja o braku poziomowania i ponownej instalacji ma sens. Kiedy rozważasz to ściśle z technicznego punktu widzenia, tak nie jest.

Oto, co zwykle wiąże się z tą decyzją biznesową:

• Ile kosztują nasze przestoje w wymiernej wysokości?
• Ile będzie nas to potencjalnie kosztować, gdy będziemy musieli nieco ujawnić klientom, dlaczego nie byliśmy w stanie?
• Jakie inne działania będę musiał odciągnąć od ludzi, aby dokonać ponownej instalacji? Jaki jest koszt?
• Czy mamy odpowiednich ludzi, którzy wiedzą, jak uruchomić system bez błędów? Jeśli nie, ile mnie to kosztuje, gdy będą rozwiązywać problemy?

Dlatego po dodaniu takich kosztów można uznać, że kontynuacja „potencjalnie” wciąż zagrożonego systemu jest lepsza niż ponowna instalacja systemu.

Na podstawie postu, który napisałem przed wiekami, kiedy wciąż mogłem niepokoić się na blogu.

To pytanie jest ciągle zadawane przez ofiary hakerów włamujących się na ich serwer sieciowy. Odpowiedzi bardzo rzadko się zmieniają, ale ludzie wciąż zadają pytanie. Nie jestem pewien dlaczego. Być może ludzie po prostu nie lubią odpowiedzi, które zobaczyli, szukając pomocy, lub nie mogą znaleźć osoby, której ufają, by udzielić im porady. A może ludzie czytają odpowiedź na to pytanie i zbytnio skupiają się na 5% tego, dlaczego ich sprawa jest wyjątkowa i różni się od odpowiedzi, które mogą znaleźć w Internecie, i pomijają 95% pytania i odpowiedzi, gdy ich sprawa jest wystarczająco podobna jak ten, który czytają online.

To prowadzi mnie do pierwszego ważnego samorodka informacji. Naprawdę doceniam to, że jesteś wyjątkowym płatkiem śniegu. Doceniam to, że twoja strona internetowa też jest, ponieważ jest odzwierciedleniem ciebie i twojej firmy, a przynajmniej twojej ciężkiej pracy w imieniu pracodawcy. Ale dla kogoś z zewnątrz, bez względu na to, czy osoba zajmująca się bezpieczeństwem komputerowym patrzy na problem, aby spróbować pomóc tobie, czy nawet samemu napastnikowi, jest bardzo prawdopodobne, że twój problem będzie co najmniej w 95% identyczny z każdym innym przypadkiem kiedykolwiek spojrzałem.

Nie bierz ataku osobiście i nie bierz zaleceń podanych tutaj lub otrzymanych osobiście od innych osób. Jeśli czytasz to po tym, jak po prostu stałeś się ofiarą włamania na stronę internetową, naprawdę przepraszam i naprawdę mam nadzieję, że znajdziesz tu coś pomocnego, ale nie jest to czas, aby pozwolić swojemu ego przeszkodzić w tym, co musisz zrobić.

Właśnie dowiedziałeś się, że twoje serwery zostały zhakowane. Co teraz?

Nie panikuj. Absolutnie nie działaj w pośpiechu i absolutnie nie próbuj udawać, że rzeczy nigdy się nie wydarzyły i nie działaj wcale.

Po pierwsze: zrozum, że katastrofa już się wydarzyła. To nie czas na zaprzeczenie; nadszedł czas, aby zaakceptować to, co się wydarzyło, być realistą i podjąć kroki w celu zarządzania konsekwencjami tego wpływu.

Niektóre z tych kroków będą boleć i (chyba że twoja strona zawiera kopię moich danych) naprawdę nie obchodzi mnie, czy zignorujesz wszystkie lub niektóre z tych kroków, ale w końcu poprawi to sytuację. Lek może smakować okropnie, ale czasami musisz przeoczyć to, jeśli naprawdę chcesz, aby lekarstwo zadziałało.

Powstrzymaj problem przed pogorszeniem się:

1. Pierwszą rzeczą, którą powinieneś zrobić, to odłączyć zainfekowane systemy od Internetu. Niezależnie od innych problemów, pozostawienie systemu podłączonego do sieci pozwoli jedynie na kontynuację ataku. Mam na myśli to dosłownie; poproś kogoś, aby fizycznie odwiedził serwer i odłączył kable sieciowe, jeśli tego właśnie potrzebuje, ale odłącz ofiarę od jej włamywaczy, zanim spróbujesz zrobić cokolwiek innego.
2. Zmień wszystkie hasła do wszystkich kont na wszystkich komputerach w tej samej sieci, co zaatakowane systemy. Nie naprawdę. Wszystkie konta Wszystkie komputery Tak, masz rację, może to być przesada; z drugiej strony może nie. Tak czy inaczej nie wiesz, prawda?
3. Sprawdź swoje inne systemy. Zwróć szczególną uwagę na inne usługi internetowe oraz te, które przechowują finansowe lub inne poufne dane handlowe.
4. Jeśli system przechowuje czyjeś dane osobowe, dokonaj pełnego i szczerego ujawnienia każdemu, kogo potencjalnie dotyczy ten problem. Wiem, że to trudne. Wiem, że to będzie bolało. Wiem, że wiele firm chce zamiatać ten problem pod dywan, ale obawiam się, że będziesz musiał sobie z tym poradzić.

Wciąż wahasz się przed zrobieniem tego ostatniego kroku? Rozumiem, rozumiem. Ale spójrz na to tak:

W niektórych miejscach możesz być prawnie zobowiązany do poinformowania władz i / lub ofiar o tego rodzaju naruszeniu prywatności. Niezależnie od tego, jak denerwują Cię klienci, gdy każesz im mówić o problemie, będą o wiele bardziej zirytowani, jeśli im nie powiesz, i dowiedzą się sami, gdy ktoś obciąży towary o wartości 8 000 USD, korzystając z danych karty kredytowej ukradł z twojej strony.

Pamiętasz, co powiedziałem wcześniej? Zła rzecz już się wydarzyła . Pytanie tylko, jak sobie z tym poradzisz.

Zrozum w pełni problem:

1. NIE przełączaj ponownie dotkniętych systemów z powrotem do trybu online, dopóki ten etap nie zostanie całkowicie ukończony, chyba że chcesz być osobą, której post był punktem zwrotnym dla mnie, faktycznie decydującym się na napisanie tego artykułu. Nie zamieszczam linku do postu, aby ludzie mogli się tani śmiać; Łączę się, aby ostrzec cię przed konsekwencjami nieprzestrzegania tego pierwszego kroku.
2. Sprawdź „zaatakowane” systemy, aby zrozumieć, w jaki sposób ataki skutecznie naruszyły Twoje bezpieczeństwo. Dołóż wszelkich starań, aby dowiedzieć się, skąd pochodzą „ataki”, aby zrozumieć, jakie masz problemy i które należy rozwiązać, aby Twój system był bezpieczny w przyszłości.
3. Przeanalizuj ponownie „zaatakowane” systemy, tym razem, aby zrozumieć, dokąd poszły ataki, aby zrozumieć, które systemy zostały zaatakowane podczas ataku. Upewnij się, że postępujesz zgodnie ze wskazówkami sugerującymi, że zagrożone systemy mogą stać się odskocznią do dalszego atakowania systemów.
4. Upewnij się, że „bramy” używane w każdym ataku są w pełni zrozumiałe, abyś mógł zacząć prawidłowo je zamykać. (np. jeśli twoje systemy zostały naruszone przez atak wstrzykiwania SQL, to nie tylko musisz zamknąć konkretną wadliwą linię kodu, w której się włamali, ale chcesz sprawdzić cały kod, aby sprawdzić, czy ten sam typ błędu jest błędny został zrobiony gdzie indziej).
5. Zrozum, że ataki mogą się powieść z więcej niż jednej wady. Często ataki kończą się niepowodzeniem nie poprzez znalezienie jednego poważnego błędu w systemie, ale poprzez połączenie kilku problemów (czasem drobnych i trywialnych) w celu naruszenia bezpieczeństwa systemu. Na przykład za pomocą ataków typu SQL injection do wysyłania poleceń do serwera bazy danych, odkrywanie atakowanej witryny / aplikacji działa w kontekście użytkownika administracyjnego i korzystanie z praw tego konta jako pomostu w celu narażenia innych części system. Lub, jak hakerzy lubią to nazywać: „kolejny dzień w biurze, wykorzystując typowe błędy, które popełniają ludzie”.

Przygotuj plan odzyskiwania i przywróć swoją witrynę do trybu online i trzymaj się jej:

Nikt nie chce być offline dłużej niż musi. To jest pewne. Jeśli ta strona internetowa jest mechanizmem generującym przychody, presja, aby szybko przywrócić ją do sieci będzie silna. Nawet jeśli jedyną stawką, o którą chodzi w grę, jest reputacja Twojej / Twojej firmy, nadal będzie to generować dużą presję, aby szybko przywrócić do poprzedniego stanu.

Nie poddawaj się jednak pokusie szybkiego powrotu do trybu online. Zamiast tego poruszaj się tak szybko, jak to możliwe, aby zrozumieć, co spowodowało problem, i rozwiąż go, zanim wrócisz do sieci. W przeciwnym razie niemal na pewno padniesz ofiarą włamania i pamiętaj: „raz włamanie się może zostać uznane za nieszczęście; ponowne zhakowanie od razu wygląda jak niedbalstwo ”(z przeprosinami dla Oscara Wilde'a).

1. Zakładam, że zrozumiałeś wszystkie problemy, które doprowadziły do ​​udanej ingerencji, zanim jeszcze zacząłeś ten rozdział. Nie chcę przeceniać sprawy, ale jeśli nie zrobiłeś tego wcześniej, to naprawdę musisz. Przepraszam.
2. Nigdy nie płać pieniędzy za szantaż / ochronę. Jest to znak łatwego znaku i nie chcesz, aby to wyrażenie kiedykolwiek cię opisywało.
3. Nie ulegaj pokusie, aby przełączyć te same serwery z powrotem do trybu online bez pełnej przebudowy. Powinno być o wiele szybsze zbudowanie nowego urządzenia lub „odgrodzenie serwera od orbity i wykonanie czystej instalacji” na starym sprzęcie, niż audyt każdego rogu starego systemu, aby upewnić się, że jest czysty przed ponownym włożeniem ponownie online. Jeśli się z tym nie zgadzasz, prawdopodobnie nie wiesz, co to tak naprawdę oznacza, że ​​system jest w pełni wyczyszczony, lub procedury wdrażania witryny są niecnym bałaganem. Prawdopodobnie masz kopie zapasowe i testowe wdrożenia witryny, których możesz użyć do zbudowania witryny na żywo, a jeśli nie, włamanie się nie będzie twoim największym problemem.
4. Zachowaj ostrożność przy ponownym wykorzystywaniu danych, które były „aktywne” w systemie w momencie włamania. Nie powiem „nigdy tego nie rób”, ponieważ po prostu mnie zignorujesz, ale szczerze mówiąc, myślę, że musisz wziąć pod uwagę konsekwencje przechowywania danych, gdy wiesz, że nie możesz zagwarantować ich integralności. Najlepiej jest przywrócić to z kopii zapasowej wykonanej przed włamaniem. Jeśli nie możesz lub nie możesz tego zrobić, powinieneś bardzo uważać na te dane, ponieważ są one skażone. Należy szczególnie pamiętać o konsekwencjach dla innych, jeśli dane te należą do klientów lub odwiedzających witrynę, a nie bezpośrednio do Ciebie.
5. Uważnie monitoruj system (systemy). Powinieneś zdecydować się na zrobienie tego jako ciągłego procesu w przyszłości (więcej poniżej), ale dokładasz wszelkich starań, aby zachować czujność w okresie bezpośrednio po powrocie online do witryny. Intruzi prawie na pewno wrócą, a jeśli zauważysz, że próbują się ponownie włamać, z pewnością będziesz w stanie szybko zobaczyć, czy naprawdę zamknąłeś wszystkie dziury, których wcześniej użyli, oraz wszelkie zrobione dla siebie, i możesz zebrać przydatne informacje, które możesz przekazać lokalnym organom ścigania.

Zmniejszenie ryzyka w przyszłości.

Pierwszą rzeczą, którą musisz zrozumieć, jest to, że bezpieczeństwo jest procesem, który musisz stosować przez cały cykl życia projektu, wdrażania i utrzymywania systemu z dostępem do Internetu, a nie czymś, co możesz później poklepać o kilka warstw kodu, jak tanie farba. Aby zapewnić odpowiednie bezpieczeństwo, od samego początku należy zaprojektować usługę i aplikację, mając na uwadze, że jest to jeden z głównych celów projektu. Zdaję sobie sprawę, że to nudne i słyszałeś już o tym wcześniej i że „po prostu nie zdaję sobie sprawy z presji” związanej z wprowadzeniem usługi beta web2.0 (beta) do statusu beta w sieci, ale faktem jest, że powtarzanie się, ponieważ było to prawdą za pierwszym razem, gdy zostało powiedziane, i nie stało się jeszcze kłamstwem.

Nie możesz wyeliminować ryzyka. Nie powinieneś nawet próbować tego robić. Należy jednak zrozumieć, które zagrożenia bezpieczeństwa są dla Ciebie ważne, oraz zrozumieć, jak zarządzać i zmniejszać zarówno wpływ ryzyka, jak i prawdopodobieństwo wystąpienia ryzyka.

Jakie kroki możesz podjąć, aby zmniejszyć prawdopodobieństwo powodzenia ataku?

Na przykład:

1. Czy wada, która pozwoliła ludziom włamać się na twoją stronę, była znanym błędem w kodzie dostawcy, dla którego łatka była dostępna? Jeśli tak, to czy musisz przemyśleć swoje podejście do sposobu poprawiania aplikacji na serwerach internetowych?
2. Czy wada, która pozwoliła ludziom włamać się na twoją stronę, była nieznanym błędem w kodzie dostawcy, dla którego łata nie była dostępna? Z pewnością nie zalecam zmiany dostawców, ilekroć coś takiego cię gryzie, ponieważ wszyscy mają swoje problemy, a platformy zabraknie co najwyżej za rok, jeśli zastosujesz takie podejście. Jeśli jednak system ciągle Cię zawodzi, powinieneś albo przenieść się na coś bardziej niezawodnego, albo przynajmniej przebudować swój system, aby wrażliwe elementy pozostały owinięte watą i jak najdalej od wrogich oczu.
3. Czy błąd był błędem w kodzie opracowanym przez Ciebie (lub pracującego dla Ciebie kontrahenta)? Jeśli tak, to czy musisz przemyśleć swoje podejście do sposobu zatwierdzania kodu do wdrożenia w działającej witrynie? Czy błąd mógł zostać wykryty dzięki ulepszonemu systemowi testowemu lub zmianom w „standardowym” kodowaniu (na przykład, chociaż technologia nie jest panaceum, można zmniejszyć prawdopodobieństwo udanego ataku wstrzykiwania SQL, stosując dobrze udokumentowane techniki kodowania ).
4. Czy usterka wynikała z problemu z wdrożeniem oprogramowania serwera lub aplikacji? Jeśli tak, to czy używasz zautomatyzowanych procedur do budowania i wdrażania serwerów tam, gdzie to możliwe? Stanowią one doskonałą pomoc w utrzymaniu spójnego stanu „podstawowego” na wszystkich serwerach, minimalizując ilość niestandardowej pracy, którą należy wykonać na każdym z nich, a tym samym, miejmy nadzieję, minimalizując możliwość popełnienia błędu. To samo dotyczy wdrażania kodu - jeśli potrzebujesz czegoś „specjalnego”, aby wdrożyć najnowszą wersję swojej aplikacji internetowej, spróbuj zautomatyzować ją i upewnij się, że zawsze odbywa się to w spójny sposób.
5. Czy włamanie mogło zostać wykryte wcześniej dzięki lepszemu monitorowaniu twoich systemów? Oczywiście 24-godzinny monitoring lub system „na telefon” dla pracowników może nie być opłacalny, ale istnieją firmy, które mogą monitorować twoje usługi internetowe i ostrzegać cię w razie problemu. Możesz zdecydować, że nie możesz sobie na to pozwolić lub nie potrzebujesz go i to jest w porządku ... po prostu weź to pod uwagę.
6. Używaj narzędzi, takich jak tripwire i nessus, w razie potrzeby - ale nie używaj ich na ślepo, ponieważ tak powiedziałem. Poświęć trochę czasu, aby nauczyć się korzystać z kilku dobrych narzędzi bezpieczeństwa odpowiednich dla twojego środowiska, aktualizuj te narzędzia i używaj ich regularnie.
7. Rozważ zatrudnienie ekspertów ds. Bezpieczeństwa w celu regularnego „kontrolowania” bezpieczeństwa witryny. Ponownie, możesz zdecydować, że nie możesz sobie na to pozwolić lub nie potrzebujesz go i to jest w porządku ... po prostu weź to pod uwagę.

Jakie kroki możesz podjąć, aby zmniejszyć konsekwencje udanego ataku?

Jeśli zdecydujesz, że „ryzyko” zalania niższego piętra twojego domu jest wysokie, ale niewystarczająco wysokie, aby uzasadnić przeprowadzkę, powinieneś przynajmniej przenieść niezastąpione pamiątki rodzinne na górę. Dobrze?

1. Czy możesz zmniejszyć liczbę usług bezpośrednio udostępnianych w Internecie? Czy potrafisz utrzymać jakąś lukę między usługami wewnętrznymi a usługami dostępnymi w Internecie? Zapewnia to, że nawet jeśli zagrożone są systemy zewnętrzne, szanse na wykorzystanie ich jako odskoczni do ataku na systemy wewnętrzne są ograniczone.
2. Czy przechowujesz informacje, których nie musisz przechowywać? Czy przechowujesz takie informacje „online”, gdy można je zarchiwizować gdzie indziej. Istnieją dwa punkty do tej części; oczywistym jest to, że ludzie nie mogą ukraść od ciebie informacji, których nie masz, a po drugie, im mniej przechowujesz, tym mniej musisz utrzymywać i kodować, a więc jest mniej szans na włożenie błędów twój kod lub projekt systemu.
3. Czy używasz zasad „najmniejszego dostępu” do swojej aplikacji internetowej? Jeśli użytkownicy muszą tylko czytać z bazy danych, upewnij się, że konto używane przez aplikację internetową do obsługi ma tylko dostęp do odczytu, nie zezwalaj na dostęp do zapisu, a na pewno nie na poziomie systemu.
4. Jeśli nie masz zbyt dużego doświadczenia i nie ma to kluczowego znaczenia dla Twojej firmy, rozważ outsourcing. Innymi słowy, jeśli prowadzisz małą stronę internetową, która mówi o pisaniu kodu aplikacji komputerowej i zdecydujesz się zacząć sprzedawać małe aplikacje komputerowe ze strony, rozważ „outsourcing” swojego systemu zamówień kartami kredytowymi dla kogoś takiego jak Paypal.
5. Jeśli to w ogóle możliwe, uczyń odzyskiwanie z zainfekowanych systemów częścią planu odzyskiwania po awarii. Jest to prawdopodobnie kolejny „scenariusz katastrofy”, który można napotkać, po prostu taki, który ma własny zestaw problemów i problemów, które różnią się od zwykłego „zapalenia serwerowni” / ”został zaatakowany przez gigantyczne serwery jedzące furbies. (edycja, według XTZ)

... I w końcu

Prawdopodobnie nie pominąłem końca rzeczy, które inni uważają za ważne, ale powyższe kroki powinny przynajmniej pomóc Ci zacząć porządkować rzeczy, jeśli masz pecha, by stać się ofiarą hakerów.

Przede wszystkim: nie panikuj. Pomyśl, zanim zrobisz. Działaj stanowczo po podjęciu decyzji i zostaw komentarz poniżej, jeśli masz coś do dodania do mojej listy kroków.

Zawsze nuke z orbity. To jedyny sposób, aby się upewnić.

_{(źródło: flickr.com )}

Większość systemów to całościowe podmioty, które mają wewnętrzne, ukryte zaufanie. Ufanie zaatakowanemu systemowi jest niejawnym stwierdzeniem, że ufasz każdemu, kto naruszył system na początku. Innymi słowy:

Nie możesz temu ufać. Nie przejmuj się czyszczeniem. Natychmiast odłącz i odizoluj urządzenie. Przed kontynuowaniem zapoznaj się z naturą naruszenia, w przeciwnym razie ponownie zaprosisz to samo. Spróbuj, jeśli to możliwe, uzyskać datę i godzinę naruszenia, aby uzyskać ramy odniesienia. Potrzebujesz tego, ponieważ w przypadku przywracania z kopii zapasowej musisz upewnić się, że sama kopia zapasowa nie zawiera kopii kompromisu. Wyczyść przed przywróceniem - nie używaj skrótów.

Praktycznie rzecz biorąc, większość ludzi tego nie robi, ponieważ uważa, że ​​potrwa to zbyt długo lub będzie zbyt destrukcyjne. Poinformowałem niezliczonych klientów o prawdopodobieństwie kontynuacji problemów, ale decydent często znika z powodu ponownej instalacji.

Biorąc to pod uwagę, w systemach, w których jestem pewien, że znam metodę wprowadzania i pełen zakres szkód (solidne dzienniki poza maszyną, zwykle z IDS, być może SELinux lub coś podobnego ograniczającego zakres włamania), I wykonali porządki bez ponownej instalacji bez poczucia winy.

Najprawdopodobniej nie mają procedury odzyskiwania po awarii, która byłaby wystarczająco przetestowana, aby czuli się pewnie w przeprowadzaniu odbudowy, lub nie jest jasne, ile czasu to zajmie lub jaki będzie wpływ ... lub kopie zapasowe są niewiarygodne lub ich analitycy ryzyka nie rozumiem zakresu skompromitowanego systemu. Mogę wymyślić wiele powodów.

Powiedziałbym, że w większości jest to coś złego w podstawowych procedurach i zasadach i nie jest to coś, co chciałbyś przyznać otwarcie - zamiast tego przyjmujesz postawę obronną. Przynajmniej nie widzę ani nie bronię, nie wycierając skompromitowanego systemu, bez względu na to, pod jakim kątem na niego patrzysz.

Wcześniej nie nukowałem systemu, abym mógł przeprowadzić analizę wektora, w którym się pojawiły, a następnie dokonać analizy użycia i sprawdzić, gdzie dostali się do środka.

Po zrootowaniu masz honeypota na żywo i może on zaoferować znacznie więcej niż tylko hack. - szczególnie dla policji.

• że powiedziałem, że jestem już przygotowany, aby uzyskać czysty system w trybie gotowości w trybie gotowości i móc zaoferować szybkie zwiększone bezpieczeństwo sieci w celu odizolowania zrootowanego urządzenia.