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.
- Trudno jest ustalić, kiedy doszło do włamania.
- 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ę:
- 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.
- 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?
- Sprawdź swoje inne systemy. Zwróć szczególną uwagę na inne usługi internetowe oraz te, które przechowują finansowe lub inne poufne dane handlowe.
- 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:
- 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.
- 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.
- 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.
- 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).
- 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).
- 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.
- 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.
- 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.
- 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.
- 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:
- 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?
- 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.
- 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 ).
- 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.
- 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ę.
- 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.
- 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?
- 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.
- 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.
- 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.
- 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.
- 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.