To jest kanoniczne pytanie dotyczące bezpieczeństwa serwera - reagowanie na zdarzenia związane z naruszeniem bezpieczeństwa (włamanie)
Zobacz także:

• Wskazówki dotyczące zabezpieczania serwera LAMP
• Czy zainstalować ponownie po naruszeniu zasad roota?

Wersja kanoniczna
Podejrzewam, że haker, wirus lub inny mechanizm naraża jeden lub więcej moich serwerów:

• Jakie są moje pierwsze kroki? Czy po przybyciu na miejsce powinienem odłączyć serwer, zachować „dowody”, czy są jeszcze inne wstępne uwagi?
• Jak mogę odzyskać usługi online?
• Jak zapobiec ponownemu wystąpieniu tego samego problemu?
• Czy istnieją najlepsze praktyki lub metody wyciągania wniosków z tego incydentu?
• Gdybym chciał stworzyć plan reagowania na incydenty, od czego bym zaczął? Czy powinno to być częścią mojego planowania odzyskiwania po awarii lub ciągłości działania?

Orginalna wersja

2011.01.02 - Jadę do pracy o 21.30 w niedzielę, ponieważ nasz serwer został w jakiś sposób skompromitowany i spowodował atak DOS na naszego dostawcę. Dostęp serwerów do Internetu został zamknięty, co oznacza, że ​​ponad 5-600 witryn naszych klientów jest teraz niedostępnych. Teraz może to być hack FTP lub słabość kodu. Nie jestem pewien, dopóki się tam nie dostanę.

Jak mogę szybko to wyśledzić? Jesteśmy gotowi na wiele sporów, jeśli nie odzyskam serwera tak szybko, jak to możliwe. Każda pomoc jest mile widziana. Korzystamy z Open SUSE 11.0.

---

2011.01.03 - Dziękujemy wszystkim za pomoc. Na szczęście nie byłem jedyną osobą odpowiedzialną za ten serwer, tylko najbliższą. Udało nam się rozwiązać ten problem, chociaż może nie dotyczyć wielu innych osób w innej sytuacji. Opiszę szczegółowo, co zrobiliśmy.

Odłączyliśmy serwer od sieci. Przeprowadzał (próbując przeprowadzić) atak typu „odmowa usługi” na inny serwer w Indonezji, a tam również działała strona winna.

Najpierw próbowaliśmy ustalić, skąd pochodzi ten serwer, biorąc pod uwagę, że mamy na nim ponad 500 witryn, a od pewnego czasu spodziewamy się księżyca. Jednak nadal mając dostęp do SSH, uruchomiliśmy polecenie, aby znaleźć wszystkie pliki edytowane lub utworzone w momencie rozpoczęcia ataków. Na szczęście plik obrażeń został utworzony w czasie ferii zimowych, co oznaczało, że na serwerze nie utworzono jeszcze wielu innych plików.

Następnie byliśmy w stanie zidentyfikować niepoprawny plik, który był w folderze przesłanych zdjęć w witrynie internetowej ZenCart .

Po krótkiej przerwie na papierosa doszliśmy do wniosku, że ze względu na lokalizację plików musiał on zostać przesłany za pośrednictwem narzędzia do przesyłania plików, które nie zostało zabezpieczone. Po pewnym googlowaniu okazało się, że istnieje luka w zabezpieczeniach, która umożliwiła przesłanie plików w panelu administracyjnym ZenCart na zdjęcie dla wytwórni. (Sekcja, której tak naprawdę nigdy nie używał), publikując ten formularz, po prostu załadowałem dowolny plik, nie sprawdziłem rozszerzenia pliku, a nawet nie sprawdziłem, czy użytkownik jest zalogowany.

Oznaczało to, że można przesłać dowolne pliki, w tym plik PHP do ataku. Zabezpiecziliśmy lukę w ZenCart na zainfekowanej stronie i usunęliśmy niepoprawne pliki.

Praca została wykonana, a ja byłem w domu na 2 rano

---

Morał - Zawsze stosuj łatki bezpieczeństwa dla ZenCart lub innego systemu CMS. Podobnie jak po wydaniu aktualizacji zabezpieczeń, cały świat jest informowany o tej luce. - Zawsze wykonuj kopie zapasowe i twórz kopie zapasowe. - Zatrudnij lub zorganizuj dla kogoś, kto będzie tam w takich czasach. Aby uniemożliwić komukolwiek poleganie na paskudnym wpisie dotyczącym błędu serwera.

Trudno jest udzielić konkretnej porady z tego, co tu opublikowałeś, ale mam kilka ogólnych porad na podstawie postu, który napisałem przed wiekami, kiedy wciąż mogłem niepokoić się na blogu.

Nie panikuj

Po pierwsze, nie ma „szybkich poprawek” oprócz przywracania systemu z kopii zapasowej wykonanej przed włamaniem, a to ma co najmniej dwa problemy.

1. Trudno jest ustalić, kiedy doszło do włamania.
2. Nie pomaga ci zamknąć „dziury”, która pozwoliła im włamać się po raz ostatni, ani nie radzi sobie z konsekwencjami „kradzieży danych”, które mogły mieć miejsce.

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 witryna zawiera kopię moich danych) naprawdę nie obchodzi mnie, czy zignorujesz wszystkie lub niektóre z tych kroków, to zależy od Ciebie. Ale prawidłowe ich przestrzeganie ostatecznie poprawi 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, natychmiast powiadom osobę odpowiedzialną za ochronę danych (jeśli to nie ty) i URGE pełne ujawnienie. Wiem, że to trudne. Wiem, że to będzie bolało. Wiem, że wiele firm chce zamiatać ten problem pod dywan, ale firma będzie musiała sobie z tym poradzić - i musi to zrobić, mając na uwadze wszelkie odpowiednie przepisy dotyczące 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 zamierzam linkować do tego postu, aby ludzie mogli się tani śmiać, ale prawdziwa tragedia ma miejsce, gdy ludzie nie uczą się na swoich błędach.
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 naruszone 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”.

Dlaczego nie „naprawić” wykrytego exploita lub rootkita i przywrócić system do trybu online?

W takich sytuacjach problem polega na tym, że nie masz już kontroli nad tym systemem. To już nie twój komputer.

Jedynym sposobem, aby upewnić się , że masz kontrolę nad systemem, jest jego przebudowa. Chociaż znalezienie i usunięcie exploita włamującego się do systemu ma dużą wartość, nie możesz być pewien, co jeszcze zrobiono w systemie, gdy intruzi przejęli kontrolę (zresztą nie jest to niespotykane u hakerów rekrutujących się systemy w botnecie w celu łatania exploitów, których sami użyli, aby zabezpieczyć „swój” nowy komputer przed innymi hakerami, a także zainstalować rootkita).

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 zhakowany może zostać uznany 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ęć czas, 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.

... 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.

Wygląda na to, że masz nieco nad głową; W porządku. Zadzwoń do szefa i zacznij negocjować budżet na awaryjne środki bezpieczeństwa. 10 000 $ może być dobrym miejscem na rozpoczęcie. Następnie musisz poprosić kogoś (PFY, współpracownika, kierownika), aby zaczął dzwonić do firm specjalizujących się w reagowaniu na incydenty związane z bezpieczeństwem. Wielu może odpowiedzieć w ciągu 24 godzin, a czasem nawet szybciej, jeśli mają biuro w twoim mieście.

Potrzebujesz także kogoś, aby segregować klientów; Niewątpliwie ktoś już jest. Ktoś musi rozmawiać przez telefon, aby wyjaśnić, co się dzieje, co jest robione, aby poradzić sobie z sytuacją i odpowiedzieć na ich pytania.

Następnie musisz ...

1. Zachowaj spokój. Jeśli odpowiadasz za reagowanie na incydenty, musisz teraz wykazać się najwyższym profesjonalizmem i przywództwem. Dokumentuj wszystko, co robisz, i informuj swojego kierownika i zespół wykonawczy o najważniejszych działaniach, które podejmujesz; obejmuje to współpracę z zespołem reagowania, wyłączanie serwerów, tworzenie kopii zapasowych danych i ponowne przełączanie do trybu online. Nie potrzebują krwawych szczegółów, ale powinni otrzymywać od ciebie co około 30 minut.

2. Bądź realistą. Nie jesteś specjalistą od bezpieczeństwa i są rzeczy, których nie wiesz. W porządku. Logując się do serwerów i przeglądając dane, musisz zrozumieć swoje ograniczenia. Stąpaj delikatnie. W trakcie dochodzenia upewnij się, że nie depczesz ważnych informacji ani nie zmieniasz czegoś, co może być potrzebne później. Jeśli czujesz się niekomfortowo lub zgadujesz, to dobre miejsce, aby zatrzymać się i poprosić doświadczonego specjalistę o przejęcie.

3. Zdobądź czystą pamięć USB i zapasowe dyski twarde. Zbierzesz tutaj dowody. Twórz kopie zapasowe wszystkiego, co uważasz za istotne; komunikacja z usługodawcą internetowym, zrzuty sieciowe itp. Nawet jeśli organy ścigania nie będą zaangażowane, w przypadku procesu sądowego będziesz potrzebować tych dowodów, aby udowodnić, że Twoja firma poradziła sobie z incydentem związanym z bezpieczeństwem w profesjonalny i odpowiedni sposób.

4. Najważniejsze jest zatrzymanie straty. Identyfikuj i odcinaj dostęp do zagrożonych usług, danych i maszyn. Najlepiej jest wyciągnąć kabel sieciowy; jeśli nie możesz, wyciągnij moc.

5. Następnie musisz usunąć atakującego i zamknąć dziurę. Przypuszczalnie atakujący nie ma już dostępu interaktywnego, ponieważ wyciągnąłeś sieć. Musisz teraz zidentyfikować, udokumentować (za pomocą kopii zapasowych, zrzutów ekranu i własnych notatek obserwacyjnych; a najlepiej nawet przez usunięcie dysków z serwerów, których dotyczy problem i zrobienie pełnej kopii obrazu dysku), a następnie usunięcie kodu i procesów, które pozostawił . Następna część będzie do kitu, jeśli nie masz kopii zapasowych; Możesz spróbować ręcznie uwolnić atakującego z systemu, ale nigdy nie będziesz pewien, że masz wszystko, co zostawił. Rootkity są złośliwe i nie wszystkie są wykrywalne. Najlepszą odpowiedzią będzie zidentyfikowanie podatności, której użył, wykonanie kopii obrazów dotkniętych dysków, a następnie wyczyszczenie dotkniętych systemów i ponowne załadowanie ze znanej dobrej kopii zapasowej. Don' t ślepo ufaj swojej kopii zapasowej; sprawdź to! Napraw lub zamknij lukę, zanim nowy host ponownie wejdzie do sieci, a następnie przełącz ją w tryb online.

6. Uporządkuj wszystkie swoje dane w raporcie. W tym momencie luka jest zamknięta i masz trochę czasu na oddychanie. Nie kusz się, aby pominąć ten krok; jest to nawet ważniejsze niż reszta procesu. W raporcie musisz określić, co poszło nie tak, jak zareagował Twój zespół i jakie kroki podejmujesz, aby zapobiec ponownemu wystąpieniu tego incydentu. Podaj jak najwięcej szczegółów; nie jest to tylko dla ciebie, ale dla twojego kierownictwa i obrony w potencjalnym procesie sądowym.

To niebotyczny przegląd tego, co robić; większość pracy to po prostu obsługa dokumentacji i tworzenia kopii zapasowych. Nie panikuj, możesz to zrobić. Ja zdecydowanie polecam Ci profesjonalną pomoc zabezpieczeń. Nawet jeśli potrafisz poradzić sobie z tym, co się dzieje, ich pomoc będzie nieoceniona i zwykle są wyposażone w sprzęt ułatwiający i przyspieszający proces. Jeśli twój szef nie zgadza się z kosztem, przypomnij mu, że jest bardzo mały w porównaniu z postępowaniem sądowym.

Masz moje pociechy za swoją sytuację. Powodzenia.

CERT ma dokument Kroki odzyskiwania z kompromisu systemu UNIX lub NT, który jest dobry. Szczegółowe szczegóły techniczne tego dokumentu są nieco nieaktualne, ale wiele ogólnych wskazówek nadal ma bezpośrednie zastosowanie.

Oto krótkie podsumowanie podstawowych kroków.

• Zapoznaj się z polityką bezpieczeństwa lub zarządzaniem.
• Przejmij kontrolę (wyłącz komputer)
• Przeanalizuj włamanie, uzyskaj dzienniki, ustal, co poszło nie tak
• Napraw rzeczy
  • Zainstaluj czystą wersję swojego systemu operacyjnego !!! Jeśli system został przejęty, nie możesz mu ufać, kropka.
• Zaktualizuj systemy, aby to się nie powtórzyło
• Wznów operacje
• Zaktualizuj swoje zasady na przyszłość i dokumentuj

Chciałbym szczególnie wskazać wam część E.1.

E.1 Należy pamiętać, że w przypadku naruszenia bezpieczeństwa komputera wszystko w tym systemie mogło zostać zmodyfikowane, w tym jądro, pliki binarne, pliki danych, uruchomione procesy i pamięć. Ogólnie rzecz biorąc, jedynym sposobem na zaufanie, że maszyna jest wolna od tylnych drzwi i modyfikacji intruzów, jest ponowna instalacja systemu operacyjnego

Jeśli nie masz jeszcze systemu takiego jak tripwire, nie ma możliwości uzyskania 100% pewności, że wyczyściłeś system.

1. Zidentyfikuj problem. Przeczytaj dzienniki.
2. Zawierać . Serwer został odłączony, więc gotowe.
3. Wykorzenienia . Najprawdopodobniej zainstaluj ponownie system, którego dotyczy problem. Nie usuwaj jednak dysku twardego zhakowanego, użyj nowego. Jest bezpieczniejszy i może być potrzebny stary, aby odzyskać brzydkie hacki, których nie utworzono kopii zapasowej, i zrobić kryminalistykę, aby dowiedzieć się, co się stało.
4. Odzyskać . Zainstaluj wszystko, co potrzebne i odzyskaj kopie zapasowe, aby połączyć klientów z Internetem.
5. Follow-up . Dowiedz się, na czym polegał problem, i nie dopuść do ponownego wystąpienia problemu.

Odpowiedź „gorzkiej pigułki” Roberta jest trafna, ale całkowicie ogólna (cóż, tak jak twoje pytanie). Wygląda na to, że masz problem z zarządzaniem i pilnie potrzebujesz pełnoetatowego sysadmina, jeśli masz jeden serwer i 600 klientów, ale to ci teraz nie pomaga.

Prowadzę firmę hostingową, która zapewnia trochę trzymania się ręki w tej sytuacji, więc mam do czynienia z wieloma zhakowanymi komputerami, ale także z najlepszymi praktykami dla naszych. Zawsze informujemy naszych skompromitowanych klientów o przebudowie, chyba że nie są absolutnie pewni co do natury kompromisu. W dłuższej perspektywie nie ma innej odpowiedzialnej trasy.

Jednak prawie na pewno jesteś tylko ofiarą skrypciarza, który chciał mieć podkładkę startową do ataków DoS, bramkarzy IRC lub coś zupełnie niezwiązanego z witrynami i danymi klientów. Dlatego jako tymczasowy środek podczas przebudowy, możesz rozważyć wprowadzenie ciężkiej wychodzącej zapory ogniowej na swoim urządzeniu. Jeśli możesz zablokować wszystkie wychodzące połączenia UDP i TCP, które nie są absolutnie niezbędne do funkcjonowania twoich witryn, możesz łatwo uczynić swoje zaatakowane urządzenie bezużytecznym dla każdego, kto go pożyczy, i złagodzić wpływ na sieć twojego dostawcy do zera.

Ten proces może potrwać kilka godzin, jeśli nie zrobiłeś tego wcześniej i nigdy nie rozważałeś zapory ogniowej, ale może pomóc w przywróceniu usługi klienta z ryzykiem dalszego zapewniania atakującemu dostępu do danych klientów . Ponieważ mówisz, że masz setki klientów na jednym komputerze, domyślam się, że prowadzisz małe witryny z broszurami dla małych firm, a nie 600 systemów e-commerce z numerami kart kredytowych. W takim przypadku może to stanowić akceptowalne ryzyko i przywrócić system do trybu online szybciej niż audyt 600 witryn pod kątem błędów bezpieczeństwa, zanim cokolwiek przywrócisz. Będziesz jednak wiedział, jakie dane tam są i jak wygodnie podejmowałbyś tę decyzję.

Nie jest to absolutnie najlepsza praktyka, ale jeśli nie tak było do tej pory u twojego pracodawcy, machasz na nich palcem i prosisz o dziesiątki tysięcy funtów dla zespołu SWAT za coś, co mogą czuć, to twoja wina (jakkolwiek nieuzasadniona! ) nie brzmi jak praktyczna opcja.

Pomoc twojego dostawcy będzie tutaj bardzo ważna - niektórzy dostawcy dostarczają serwer konsoli i sieciowe środowisko rozruchowe (podłącz, ale przynajmniej wiesz, jakiego rodzaju narzędzia szukać), które pozwolą ci administrować serwerem, gdy nie będziesz podłączony do sieci. Jeśli jest to w ogóle opcja, poproś o nią i skorzystaj z niej.

Ale w dłuższej perspektywie powinieneś zaplanować przebudowę systemu na podstawie postu Roberta oraz audytu każdej witryny i jej konfiguracji. Jeśli nie możesz dodać sysadmina do swojego zespołu, poszukaj oferty hostingu zarządzanego, w której płacisz swojemu dostawcy usług internetowych za pomoc sysadminningu i 24-godzinną odpowiedź na tego rodzaju rzeczy. Powodzenia :)

Musisz ponownie zainstalować. Zapisz to, czego naprawdę potrzebujesz. Pamiętaj jednak, że wszystkie pliki, które można uruchomić, mogą zostać zainfekowane i przerobione. W pythonie napisałem: http://frw.se/monty.py, który tworzy MD5-sumbs wszystkich twoich plików w danym katalogu i przy następnym uruchomieniu, sprawdza, czy coś zostało zmienione, a następnie wypisuje co pliki się zmieniły i co się zmieniło w plikach.

Może to być przydatne, aby sprawdzić, czy dziwne pliki są regularnie zmieniane.

Ale jedyne, co powinieneś teraz robić, to usunąć komputer z Internetu.

UWAGA: To nie jest zalecenie. Mój konkretny protokół reagowania na incydenty prawdopodobnie nie miałby zastosowania niezmodyfikowany w przypadku Granta unwina.

W naszych placówkach akademickich mamy około 300 badaczy, którzy wykonują tylko obliczenia. Masz 600 klientów z witrynami, więc Twój protokół prawdopodobnie będzie inny.

Pierwsze kroki w naszym protokole Gdy serwer otrzymuje zaatakowany protokół to:

1. Zidentyfikuj, że osoba atakująca mogła uzyskać uprawnienia roota (podwyższone uprawnienia)
2. Odłącz zagrożone serwery. Sieć czy moc? Zobacz osobną dyskusję .
3. Sprawdź wszystkie inne systemy
4. Uruchom zagrożone serwery z Live CD
5. (opcjonalnie) Chwyć obrazy wszystkich dysków systemowych za pomocądd

6. Zacznij robić post-mortem forensics. Przejrzyj dzienniki, ustal czas ataku, znajdź pliki zmodyfikowane w tym czasie. Spróbuj odpowiedzieć w jaki sposób? pytanie.

   • Równolegle zaplanuj i uruchom odzyskiwanie.
   • Zresetuj wszystkie hasła roota i hasła użytkownika przed wznowieniem usługi

Nawet jeśli „wszystkie backdoory i rootkity zostaną wyczyszczone”, nie ufaj temu systemowi - zainstaluj ponownie od zera.

Z mojego ograniczonego doświadczenia, kompromisy systemowe w Linuksie bywają bardziej „kompleksowe” niż w systemie Windows. Zestawy root mają znacznie większe szanse na zastąpienie binariów systemowych dostosowanym kodem w celu ukrycia złośliwego oprogramowania, a bariera związana z łataniem jądra jest nieco niższa. Ponadto jest to domowy system operacyjny wielu autorów złośliwego oprogramowania. Ogólne wytyczne to zawsze przebudowa serwera, którego dotyczy problem, od zera, i to ogólne wytyczne z jakiegoś powodu.

Sformatuj tego szczeniaka.

Ale jeśli nie możesz odbudować (lub potencjalne moce nie pozwolą ci go odbudować wbrew mężnemu uporowi, że tego potrzebuje), czego szukasz?

Ponieważ wygląda na to, że minęło trochę czasu od odkrycia wtargnięcia i przywrócenia systemu, bardzo prawdopodobne jest, że ślady po tym, jak dostali się, zostały zdeptane w pośpiechu w celu przywrócenia usługi. Niefortunny.

Nietypowy ruch sieciowy jest prawdopodobnie najłatwiejszy do znalezienia, ponieważ nie wymaga to uruchamiania niczego na urządzeniu i można to zrobić, gdy serwer jest uruchomiony i robi cokolwiek innego. Zakładając oczywiście, że twój sprzęt sieciowy pozwala na łączenie portów. To, co znajdziesz, może być diagnostyczne, ale przynajmniej jest to informacja. Uzyskanie nietypowego ruchu będzie mocnym dowodem na to, że system jest nadal zagrożony i wymaga spłaszczenia. Może być wystarczające przekonanie TPTB, że przeformatowanie naprawdę, naprawdę, jest warte przestoju.

W przeciwnym razie weź kopię dd partycji systemowych i zamontuj je na innym urządzeniu. Zacznij porównywać zawartość z serwerem na tym samym poziomie łatek, co zainfekowany. Powinno to pomóc w określeniu, co wygląda inaczej (te sumy md5) i może wskazywać na przeoczone obszary na zaatakowanym serwerze. Jest to DUŻO przesiewania katalogów i plików binarnych i będzie raczej pracochłonne. Może to być nawet bardziej pracochłonne niż przeformatowanie / przebudowa, a może być kolejną rzeczą, aby przekonać TPTB o faktycznym przeprowadzeniu przeformatowania, którego naprawdę potrzebuje.

Powiedziałbym, że @Robert Moir, @Aleksandr Levchuk, @blueben i @Matthew Bloch są w swoich reakcjach bardzo trafieni.

Jednak odpowiedzi na różne plakaty różnią się - niektóre są bardziej na wysokim poziomie i mówią o tym, jakie procedury powinieneś zastosować (ogólnie).

Wolałbym podzielić to na kilka oddzielnych części 1) Triage, AKA Jak radzić sobie z klientami i implikacjami prawnymi, i wskazywać, gdzie się udać (Wymienione bardzo dobrze przez Roberta i @blueben 2) Łagodzenie wpływu 3 ) Reakcja na incydent 4) Sekcja zwłok 5) Środki zaradcze i zmiany architektury

(Wstaw tutaj oświadczenie potwierdzone certyfikatem SANS GSC) W oparciu o wcześniejsze doświadczenia powiedziałbym, co następuje:

Niezależnie od tego, jak zajmujesz się odpowiedziami klientów, powiadomieniami, planami prawnymi i planami na przyszłość, wolę skupić się na głównym omawianym problemie. Oryginalne pytanie OP dotyczy tak naprawdę bezpośrednio tylko # 2 i # 3, w zasadzie, jak zatrzymać atak, jak najszybciej przywrócić klientów do sieci w oryginalnym stanie, co zostało dobrze ujęte w odpowiedziach.

Pozostałe odpowiedzi są świetne i obejmują wiele zidentyfikowanych najlepszych praktyk i sposobów zapobiegania zarówno przyszłości, jak i lepszego reagowania na nie.

To naprawdę zależy od budżetu PO i od tego, w jakim sektorze przemysłu się znajdują, jakie jest ich pożądane rozwiązanie itp.

Może muszą wynająć dedykowanego SA na miejscu. Może potrzebują pracownika ochrony. A może potrzebują w pełni zarządzanego rozwiązania, takiego jak Firehost lub Rackspace Managed, Softlayer, ServePath itp.

To naprawdę zależy od tego, co działa dla ich firmy. Być może ich podstawowa kompetencja nie leży w zarządzaniu serwerami i nie ma sensu, aby próbowali to rozwijać. A może są już dość techniczną organizacją i mogą podejmować właściwe decyzje dotyczące zatrudnienia oraz zatrudnić oddany zespół w pełnym wymiarze godzin.

Po przejściu do pracy i spojrzeniu na serwer udało nam się rozwiązać problem. Na szczęście niepoprawne pliki zostały przesłane do systemu w niedzielę, kiedy biuro jest zamknięte i nie należy tworzyć żadnych plików oprócz dzienników i plików pamięci podręcznej. Za pomocą prostego polecenia powłoki, aby dowiedzieć się, które pliki zostały utworzone w tym dniu, znaleźliśmy je.

Wszystkie obraźliwe pliki znajdują się w folderze / images / na niektórych naszych starszych stronach zencart. Wygląda na to, że istniała luka w zabezpieczeniach, która pozwalała (przy użyciu curl) każdemu idiocie na przesyłanie obrazów innych niż obrazy do sekcji przesyłania obrazów w sekcji administratora. Usunęliśmy obraźliwe pliki .php i poprawiliśmy skrypty przesyłania, aby nie zezwalały na przesyłanie plików, które nie są obrazami.

Patrząc wstecz, było to dość proste i zadałem to pytanie na iPhonie w drodze do pracy. Dziękuję wszystkim za pomoc.

Dla odniesienia każdego, kto odwiedza ten post w przyszłości. Bym nie polecam wyciągając wtyczkę z gniazdka.

Nie mam wiele do powiedzenia na obszerne odpowiedzi techniczne, ale proszę również zwrócić uwagę na niektóre z nich:

Działania nietechniczne:

• Zgłoś incydent wewnętrznie.
  Jeśli nie masz jeszcze planu reagowania na incydenty, który może wydawać się techniką CYA, ale dział IT nie jest jedynym i często nawet najlepszym miejscem do określenia wpływu biznesowego zainfekowanego serwera.
  Wymagania biznesowe mogą przeważyć Twoje wątpliwości techniczne. Nie mów „tak ci mówiłem”, a priorytetem problemów biznesowych jest powód, dla którego masz ten zagrożony serwer. („ Pozostaw to w raporcie po działaniu. ”)

• Ukrywanie incydentów związanych z bezpieczeństwem nie wchodzi w grę.

• Zgłaszanie do władz lokalnych.
  ServerFault NIE jest miejscem porad prawnych, ale jest to coś, co powinno zostać uwzględnione w planie reagowania na incydenty.
  W niektórych miejscowościach i / lub branżach podlegających przepisom obowiązkowe jest zgłaszanie (niektórych) incydentów bezpieczeństwa lokalnym organom ścigania, organom regulacyjnym lub informowaniu klientów / użytkowników.
  Niezależnie od tego, ani decyzja o zgłoszeniu, ani faktyczny raport nie są podejmowane wyłącznie w dziale IT. Oczekuj zaangażowania ze strony kierownictwa oraz działu prawnego i komunikacji korporacyjnej (marketingu).
  Prawdopodobnie nie należy oczekiwać zbyt wiele, Internet to duże miejsce, w którym granice mają niewielkie znaczenie, ale działy cyberprzestępczości istniejące w wielu departamentach policji rozwiązują przestępstwa cyfrowe i mogą pociągnąć winnych do odpowiedzialności.

Myślę, że wszystko sprowadza się do tego:

Jeśli cenisz swoją pracę, lepiej mieć plan i regularnie go weryfikować.

Niepowodzenie w planowaniu to porażka i nie jest to bardziej nigdzie indziej niż bezpieczeństwo systemu. Kiedy <redacted> trafi w wentylator, lepiej bądź gotowy, aby sobie z tym poradzić.

Jest jeszcze jedno (nieco stuknięte) powiedzenie, które ma tutaj zastosowanie: lepiej zapobiegać niż leczyć .

Przedstawiono tu szereg zaleceń, aby zachęcić ekspertów do przeprowadzenia audytu istniejących systemów. Myślę, że to zadaje pytanie w niewłaściwym czasie. To pytanie powinno zostać zadane, kiedy system został wprowadzony, a odpowiedzi udokumentowane. Ponadto pytanie nie powinno brzmieć: „Jak możemy powstrzymać ludzi przed włamaniem?” Powinno brzmieć: „Dlaczego ludzie w ogóle powinni się włamać?” Inspekcja kilku dziur w sieci będzie działać tylko do momentu znalezienia i wykorzystania nowych dziur. Z drugiej strony sieci, które są projektowane od podstaw tak, aby reagowały tylko w określony sposób na niektóre systemy w starannie choreograficznym tańcu, w ogóle nie skorzystają z audytu, a fundusze będą marnotrawstwem.

Zanim umieścisz system w Internecie, zadaj sobie pytanie - czy musi to być w 100% Internet? Jeśli nie, nie rób. Rozważ umieszczenie go za zaporą ogniową, w której możesz zdecydować, co widzi internet. Co więcej, jeśli wspomniana zapora ogniowa pozwala przechwytywać transmisje (za pośrednictwem odwrotnego proxy lub pewnego rodzaju filtru przechodzącego), spójrz na użycie jej, aby umożliwić tylko prawidłowe działanie.

Dokonano tego - gdzieś jest (lub była) konfiguracja bankowości internetowej, która ma serwer proxy równoważący obciążenie skierowany do Internetu, którego zamierzali użyć do wektorowych ataków z dala od puli serwerów. Specjalista ds. Bezpieczeństwa, Marcus Ranum, przekonał ich, aby przyjęli odwrotne podejście, używając odwrotnego proxy, aby zezwalać tylko na znane prawidłowe adresy URL i wysyłać wszystko inne na serwer 404 . Zaskakująco dobrze przetrwał próbę czasu.

System lub sieć oparta na domyślnym zezwoleniu jest skazana na niepowodzenie, gdy nastąpi nieoczekiwany atak. Domyślna odmowa daje ci znacznie większą kontrolę nad tym, co wchodzi, a co nie, ponieważ nie pozwolisz, aby cokolwiek wewnątrz było widoczne z zewnątrz, chyba że jest to cholernie konieczne .

To powiedziawszy, to wszystko nie jest powodem do samozadowolenia. Nadal powinieneś mieć plan na pierwsze kilka godzin po naruszeniu. Żaden system nie jest idealny, a ludzie popełniają błędy.

Miły onliner pomógł mi ostatnio dowiedzieć się, w jaki sposób atakujący może naruszyć system. Niektórzy crackerzy próbują ukryć swoje ślady, wykuwając czas modyfikacji plików. Zmiana czasu modyfikacji powoduje aktualizację czasu zmiany (ctime). możesz zobaczyć ctime ze statystykami.

Ta jedna linijka zawiera listę wszystkich plików posortowanych według ctime:

find / -type f -print0 | xargs -0 stat --format '%Z :%z %n' | sort -nr > /root/all_files.txt

Jeśli więc z grubsza znasz czas kompromisu, możesz zobaczyć, które pliki zostały zmienione lub utworzone.