Niedawno (ale jest to również powtarzające się pytanie) zobaczyliśmy 3 interesujące wątki na temat hakowania i bezpieczeństwa:

Jak radzić sobie z zagrożonym serwerem? .
Znalezienie sposobu zhakowania zaatakowanego serwera
Pytanie o uprawnienia do pliku

Ten ostatni nie jest bezpośrednio związany, ale podkreśla, jak łatwo można zepsuć administrację serwera WWW.

Ponieważ jest kilka rzeczy, które można zrobić, zanim wydarzy się coś złego, chciałbym mieć twoje sugestie w zakresie dobrych praktyk, aby ograniczyć skutki wsteczne ataku i jak zareagować w smutnym przypadku.

Nie chodzi tylko o zabezpieczenie serwera i kodu, ale także o kontrolę, logowanie i środki zaradcze.

Czy masz listę dobrych praktyk, czy wolisz polegać na oprogramowaniu lub ekspertach, którzy stale analizują Twój serwer (serwery) WWW (lub wcale)?

Jeśli tak, czy możesz udostępnić swoją listę oraz swoje pomysły / opinie?

AKTUALIZACJA

Otrzymałem kilka dobrych i interesujących opinii.

Chciałbym mieć prostą listę, która może być przydatna dla administratorów bezpieczeństwa IT, ale także dla mistrzów internetowego factotum .

Nawet jeśli wszyscy udzielili dobrych i poprawnych odpowiedzi, w tej chwili wolę tę z Robertem, ponieważ jest ona najprostsza, jasna i zwięzła, a ta z sysadmin1138, ponieważ jest najbardziej kompletna i precyzyjna.

Ale nikt nie bierze pod uwagę perspektywy i postrzegania przez użytkownika, myślę, że to pierwszy, który należy wziąć pod uwagę.

Co użytkownik pomyśli, kiedy odwiedzi moją zhakowaną stronę, a nawet więcej, jeśli posiadasz rozsądne dane na ich temat. Nie chodzi tylko o to, gdzie gromadzić dane, ale o to, jak uspokoić wściekłych użytkowników.

Co z danymi, mediami, władzami i konkurentami?

Istnieją dwa duże obszary, na których należy się skoncentrować:

1. Trudno się dostać do środka.
2. Tworzenie zasad i procedur w celu spokojnego i skutecznego radzenia sobie z sytuacją, w której ktoś przekroczył punkt 1.

Trudno się dostać do środka

Jest to bardzo złożony temat i wiele z nich koncentruje się na upewnieniu się, że masz wystarczająco dużo informacji, aby dowiedzieć się, że WTF wydarzyło się po tym fakcie. Streszczenie punktorów dla uproszczenia:

• Zachowaj dzienniki (patrz także Zarządzanie zdarzeniami informacji o bezpieczeństwie)
  • Wszelkie próby autoryzacji, zarówno udane, jak i niepowodzenia, najlepiej z nienaruszonymi informacjami źródłowymi.
  • Dzienniki dostępu do zapory ogniowej (może to obejmować zapory ogniowe na serwer, jeśli są używane).
  • Dzienniki dostępu do serwera WWW
  • Dzienniki uwierzytelniania serwera bazy danych
  • Dzienniki użytkowania specyficzne dla aplikacji
  • Jeśli to możliwe, SIEM może wysyłać alerty dotyczące podejrzanych wzorców.
• Wymuszaj odpowiednią kontrolę dostępu
  • Upewnij się, że prawa są ustawione poprawnie wszędzie i unikaj „leniwych praw” („och, po prostu daj wszystkim czytać”) tam, gdzie to możliwe.
  • Okresowe audyty list ACL w celu upewnienia się, że procedury są rzeczywiście przestrzegane, a tymczasowe kroki rozwiązywania problemów („daj wszystkim do przeczytania, sprawdź, czy to wtedy działa”) zostały poprawnie usunięte po zakończeniu rozwiązywania problemów.
  • Wszystkie reguły przekazywania zapory muszą być uzasadnione i okresowo kontrolowane.
  • Kontroli dostępu do serwera WWW należy również poddać audyt, zarówno listy ACL serwera, jak i systemu plików.
• Wymuszaj zarządzanie zmianami
  • Wszelkie zmiany w środowisku bezpieczeństwa muszą być centralnie śledzone i przeglądane przez więcej niż jedną osobę.
  • W tym procesie należy uwzględnić łatki.
  • Posiadanie wspólnej kompilacji systemu operacyjnego (szablonu) uprości środowisko i ułatwi śledzenie i stosowanie zmian.
• Wyłącz konta gości.
• Upewnij się, że wszystkie hasła nie są ustawione na wartości domyślne.
  • Gotowe aplikacje mogą konfigurować użytkowników przy użyciu wstępnie zdefiniowanych haseł. Zmienić je.
  • Wiele urządzeń IT jest dostarczanych z bardzo dobrze znanymi parami użytkownik / hasło. Zmień je, nawet jeśli logujesz się w tym temacie tylko raz w roku.
• Ćwicz najmniejsze przywileje. Daj użytkownikom dostęp, którego naprawdę potrzebują.
  • Dla administratorów rozsądna jest konfiguracja dwóch kont. Jedno zwykłe konto używane do poczty e-mail i innych zadań biurowych, a drugie do pracy z podwyższonym poziomem uprawnień. Maszyny wirtualne ułatwiają to.
  • NIE zachęcaj do regularnego korzystania z ogólnych kont administratora / root, trudno jest śledzić, kto co robił, kiedy.

Tworzenie zasad i procedur w celu spokojnego i skutecznego radzenia sobie z sytuacją, gdy ktoś się dostanie

Polityka zdarzeń związanych z bezpieczeństwem jest obowiązkowa dla wszystkich organizacji. To znacznie zmniejsza fazę odpowiedzi „bieganie z odciętymi głowami”, ponieważ ludzie stają się irracjonalni w obliczu takich wydarzeń. Włamania są dużymi, przerażającymi sprawami. Wstyd z powodu wtargnięcia może spowodować, że sysadmini zorientowani w inny sposób zaczną niepoprawnie reagować.

Wszystkie poziomy organizacji muszą znać zasady. Im większy incydent, tym bardziej prawdopodobne jest, że wyższe kierownictwo w jakiś sposób się zaangażuje, a ustalenie procedur postępowania z rzeczami znacznie pomoże w odparciu „pomocy” z wysoka. Zapewnia również poziom ochrony dla techników bezpośrednio zaangażowanych w reakcję na incydent, w postaci procedur dla kierownictwa średniego szczebla w celu komunikacji z resztą organizacji.

Idealnie, twoja polityka odzyskiwania po awarii już określiła, jak długo niektóre usługi mogą być niedostępne przed uruchomieniem zasad odzyskiwania po awarii. Pomoże to w reagowaniu na incydenty, ponieważ tego rodzaju zdarzenia są katastrofami. Jeśli zdarzenie jest typu, w którym okno odzyskiwania NIE zostanie spełnione (przykład: witryna DR z funkcją tworzenia kopii zapasowej na gorąco otrzymuje kanał informacyjny o zmianach w czasie rzeczywistym, a intruzi usunęli kilka danych, które zostały skopiowane do witryny DR zauważono, dlatego konieczne będzie zastosowanie procedur odzyskiwania po przeziębieniu), a następnie kierownictwo wyższego szczebla będzie musiało wziąć udział w rozmowach dotyczących oceny ryzyka.

Niektóre elementy każdego planu reagowania na incydenty:

• Zidentyfikuj zagrożone systemy i ujawnione dane.
• Wczesne ustalenie, czy konieczne będzie przechowywanie dowodów prawnych w celu ewentualnego wniesienia oskarżenia.
  • Aby zachować dowody , nie dotykaj niczego w tym systemie, chyba że jest to absolutnie wymagane . Nie loguj się do niego. Nie przesiewaj plików dziennika. Robić. Nie. Dotknąć.
  • Aby zachować dowody, zaatakowane systemy należy pozostawić w trybie online, ale należy je rozłączyć do czasu, aż certyfikowany ekspert ds. Kryminalistyki komputerowej będzie mógł dokonać podziału systemu w sposób zgodny z zasadami postępowania z dowodami.
    • Wyłączenie zainfekowanego systemu może spowodować skażenie danych.
    • Jeśli system pamięci na to pozwala (dyskretne urządzenie SAN), wykonaj migawkę dotkniętych jednostek LUN przed rozłączeniem i oznacz je jako tylko do odczytu.
  • Zasady postępowania z dowodami są złożone i och, tak łatwe do zepsucia. Nie rób tego, chyba że przeszedłeś szkolenie na ich temat. Większość ogólnych SysAdminów NIE ma tego rodzaju szkolenia.
  • Jeśli zachowane zostaną dowody, traktuj utratę usługi jako katastrofę spowodowaną utratą sprzętu i rozpocznij procedury odzyskiwania z nowym sprzętem.
• Wstępnie ustalone zasady dotyczące rodzajów katastrof wymagają zawiadomienia. Przepisy i regulacje różnią się w zależności od miejscowości.
  • Zasady dotyczące „narażenia” i „udowodnionego kompromisu” są różne.
  • Reguły powiadomień będą wymagały zaangażowania działu komunikacji.
  • Jeśli wymagane powiadomienie jest wystarczająco duże, konieczne będzie zaangażowanie kierownictwa najwyższego poziomu.
• Korzystając z danych DR, określ, ile czasu „WTF właśnie się wydarzyło”, zanim przywrócenie usługi do sieci stanie się wyższym priorytetem.
  • Czasy odzyskiwania usługi mogą wymagać pracy nad ustaleniem, co się stało z podporządkowanym. Jeśli tak, to po przywróceniu usług zrób zdjęcie dysku urządzenia, którego dotyczy problem, w celu przeprowadzenia analizy (nie jest to kopia dowodowa, tylko inżynierowie muszą dokonać inżynierii wstecznej).
  • Zaplanuj zadania odzyskiwania usługi, tak aby obejmowały całkowitą przebudowę systemu, którego dotyczy problem, a nie tylko usuwanie bałaganu.
  • W niektórych przypadkach czasy odzyskiwania usługi są na tyle krótkie, że obrazy dysku należy wykonać natychmiast po zidentyfikowaniu kompromisu i nie można przechowywać dowodów prawnych. Po przebudowaniu usługi można rozpocząć pracę nad ustaleniem, co się stało.
• Przeszukuj pliki dziennika, aby uzyskać informacje dotyczące sposobu, w jaki atakujący wszedł i co mógł zrobić od razu.
• Przeszukuj zmienione pliki, aby uzyskać informacje dotyczące tego, jak się dostali i co zrobili po wejściu.
• Przeszukuj dzienniki zapory, aby uzyskać informacje o tym, skąd pochodzą, skąd mogły wysłać dane i ile z nich mogło zostać wysłanych.

Posiadanie zasad i procedur przed kompromisem, dobrze znanych osobom, które będą je wdrażać w przypadku kompromisu, jest czymś, co należy po prostu zrobić. Zapewnia wszystkim ramy reakcji w czasie, gdy ludzie nie będą myśleć prosto. Wyższe kierownictwo może grzmotać i huczeć w związku z procesami sądowymi i oskarżeniami kryminalnymi, ale w rzeczywistości połączenie sprawy jest kosztownym procesem, a świadomość, że wcześniej może pomóc w tłumieniu furii.

Zauważam również, że tego rodzaju zdarzenia muszą być uwzględnione w ogólnym planie reagowania na katastrofy. Kompromis najprawdopodobniej uruchomi politykę „utraconego sprzętu”, a także reakcję „utraty danych”. Znajomość czasów odzyskiwania usługi pomaga ustalić, ile czasu może zająć zespół ds. Reakcji bezpieczeństwa na przelanie faktycznego zaatakowanego systemu (jeśli nie zachowuje dowodów prawnych), zanim będzie on potrzebny w trakcie odzyskiwania usługi.

Jak mogą pomóc odpowiednie procedury pomocy technicznej

Musimy zastanowić się, w jaki sposób traktowani są tutaj klienci (dotyczy to zarówno klientów wewnętrznych, jak i zewnętrznych kontaktujących się z działem pomocy technicznej).

Przede wszystkim ważna jest komunikacja ; użytkownicy będą źli z powodu zakłóceń w działalności gospodarczej, a także mogą być zaniepokojeni zakresem / konsekwencjami wszelkich naruszeń informacji, które mogły mieć miejsce w ramach ingerencji. Informowanie tych ludzi pomoże złagodzić ich gniew i troskę, zarówno z punktu widzenia dobrego dzielenia się wiedzą, jak iz nieco mniej oczywistego punktu widzenia, że ​​będą musieli usłyszeć, że kontrolujesz sytuacja.

Dział pomocy technicznej i kierownictwo IT muszą w tym momencie działać jako „parasol”, chroniąc ludzi wykonujących pracę, aby określić zakres włamania i przywrócić usługi przed niezliczonymi zapytaniami, które zakłócają tę pracę.

1. Staraj się publikować realistyczne aktualizacje dla klientów i współpracuj z nimi, aby określić pilność przywrócenia usługi do trybu online. Świadomość potrzeb klientów jest ważna, ale jednocześnie nie pozwól im dyktować ci niewykonalnego harmonogramu.
2. Upewnij się, że Twój zespół pomocy technicznej wie, jakie informacje mogą, a których nie mogą być udostępniane, i że nie powinien zachęcać do plotek i spekulacji (i absolutnie nie powinien omawiać niczego, co mogłoby zaszkodzić działaniom prawnym, które Twoja organizacja może podjąć lub spotkać).
3. Jedną pozytywną rzeczą, którą powinien zrobić dział pomocy technicznej, jest rejestrowanie wszystkich połączeń związanych z wtargnięciem - może to pomóc zmierzyć zakłócenia spowodowane zarówno samym włamaniem, jak i procesami, które nastąpiły, aby sobie z tym poradzić. Nakładanie czasu i kosztów na włamanie i łagodzenie może być bardzo pomocne zarówno przy dopracowywaniu przyszłych strategii, jak i oczywiście może okazać się przydatne przy wszelkich czynnościach prawnych. Pomaga tutaj rejestrowanie incydentu ITIL vs. problem - zarówno sam włamanie, jak i ograniczenie mogą być rejestrowane jako osobne problemy, a każdy rozmówca śledzony jako incydent jednego lub obu problemów.

W jaki sposób standardy wdrażania mogą pomóc

Wdrażanie do zestawu szablonów (lub przynajmniej listy kontrolnej) również pomaga, wraz z ćwiczeniem kontroli / zarządzania zmianami nad wszelkimi dostosowaniami / uaktualnieniami do szablonu wdrażania. Możesz mieć kilka szablonów do rozliczenia serwerów wykonujących różne zadania (np. Szablon serwera poczty, szablon serwera WWW itp.).

Szablon powinien działać zarówno w systemie operacyjnym, jak i aplikacjach i obejmować nie tylko zabezpieczenia, ale wszystkie używane ustawienia, i najlepiej powinien być skryptowany (np. Szablon), a nie stosowany ręcznie (np. Lista kontrolna), aby w jak największym stopniu wyeliminować błąd ludzki.

Pomaga to na wiele sposobów:

• Umożliwia szybsze przywracanie / odbudowywanie w przypadku włamania (pamiętaj, że nie należy wdrażać z tego szablonu „tak jak jest”, ponieważ wiesz, że jest podatny na atak, ale pozwala wrócić do „ostatniej znanej dobrej konfiguracji” „ który musi ulec dalszemu zaostrzeniu przed wdrożeniem na żywo ... i nie zapomnij zaktualizować szablonu wdrożenia, gdy masz pewność, że jest on odpowiednio zablokowany)
• Daje ci „linię bazową” do porównania zhakowanego serwera
• Zmniejsza niepotrzebne błędy, które mogą prowadzić do włamania
• Pomaga w zarządzaniu zmianami i poprawkami, ponieważ gdy staje się oczywiste, że potrzebujesz poprawki / aktualizacji lub zmiany proceduralnej ze względów bezpieczeństwa (lub innych przyczyn tego rodzaju), łatwiej jest zobaczyć, które systemy wymagają zmiany, ułatwia pisanie testów aby sprawdzić, czy zmiana została zastosowana poprawnie itp.).
• Jeśli wszystko jest tak spójne, jak to możliwe i rozsądne, pomaga to, aby niezwykłe i podejrzane zdarzenia nieco dalej się rozchodziły.

W przypadku większości naszych serwerów polegamy na zaporach hosta i sieci, oprogramowaniu antywirusowym / spyware, IDS sieci i IDS hosta przez większość naszego zapobiegania. To wraz ze wszystkimi ogólnymi wytycznymi, takimi jak minimalne uprawnienia, odinstalowane nieistotne programy, aktualizacje itp. Stamtąd używamy produktów takich jak Nagios, Cacti i rozwiązania SIEM do różnych podszewek bazowych i powiadomień o zdarzeniach. Nasz HIDS (OSSEC) wykonuje również wiele rejestrowania typu SIEM, co jest miłe. Zasadniczo staramy się blokować rzeczy jak najwięcej, ale logujemy się centralnie, więc jeśli coś się stanie, możemy to przeanalizować i skorelować.

To, czego naprawdę chcesz, można podzielić na 3 podstawowe obszary:

1. Standardowa konfiguracja systemu
2. Monitorowanie systemu / aplikacji
3. Reagowania na incydenty

Jeśli masz jakikolwiek personel informacyjny (zapewniający | bezpieczeństwo), zdecydowanie powinieneś z nim porozmawiać. Chociaż reakcja na incydent jest często wyłącznym zadaniem tego biura, reszta powinna być wspólnym wysiłkiem rozwojowym wszystkich zainteresowanych stron.

Na ryzyko samodzielnego sikania ta odpowiedź na powiązane pytanie powinna zaindeksować wiele przydatnych zasobów: Wskazówki dotyczące zabezpieczania serwera LAMP.

Idealnie, powinieneś mieć najmniejszą liczbę obsługiwanych systemów operacyjnych i zbudować każdy z nich za pomocą obrazu podstawowego. Należy odbiegać od podstawy tylko w takim stopniu, w jakim jest to wymagane do świadczenia wszelkich usług świadczonych przez serwer. Odchylenia powinny być udokumentowane lub mogą być wymagane, jeśli musisz spełnić wymagania PCI / HIPAA / itp. lub inne zgodności. Korzystanie z systemów zarządzania wdrażaniem i konfiguracją może bardzo pomóc w tym zakresie. Specyfika zależy w dużej mierze od Twojego systemu operacyjnego, szewca / marionetki / Altiris / DeployStudio / SCCM itp.

Zdecydowanie powinieneś wykonać jakiś regularny przegląd dziennika. Biorąc pod uwagę tę opcję, SIEM może być bardzo pomocny, ale ma również tę wadę, że jest drogi zarówno pod względem ceny zakupu, jak i kosztów budowy. Sprawdź to pytanie ze strony IT Security SE, aby uzyskać komentarze na temat analizy logów: Jak sobie radzisz z analizą logów? Jeśli jest to nadal zbyt ciężkie, nawet popularne narzędzia, takie jak LogWatch, mogą zapewnić dobry kontekst dla tego, co się dzieje. Ważnym elementem jest jednak poświęcenie czasu na sprawdzenie dzienników. Pomoże ci to zapoznać się z tym, co stanowi normalne zachowanie, abyś mógł rozpoznać nieprawidłowość.

Oprócz przeglądania dziennika ważne jest również monitorowanie stanu serwera. Wiedza o tym, kiedy nastąpią zmiany, niezależnie od tego, czy są planowane, czy nie, ma kluczowe znaczenie. Korzystanie z lokalnego narzędzia do monitorowania, takiego jak Tripwire, może ostrzegać administratora o zmianach. Niestety, podobnie jak SIEM i IDSes ma tę wadę, że jest drogie w strojeniu i / lub zakupie. Co więcej, bez dobrego strojenia progi alarmowe będą tak wysokie, że wszelkie dobre wiadomości zostaną utracone w hałasie i staną się bezużyteczne.

Odpowiednie zasady bezpieczeństwa informacji i zarządzania zdarzeniami (SIEM) znacznie przyczynią się do ułatwienia życia w zakresie bezpieczeństwa.

Nie jestem ekspertem od bezpieczeństwa, więc głównie im się poddaję; ale począwszy od Principal of Least Privilege prawie zawsze ich praca jest znacznie łatwiejsza. Zastosowanie tego jak maści leczniczej działa dobrze w wielu aspektach bezpieczeństwa: uprawnienia do plików, użytkownicy wykonawczy, reguły zapory ogniowej itp. KISS też nigdy nie boli.

Większość wymienionych tutaj rozwiązań ma zastosowanie na poziomie hosta i sieci, ale często zapominamy o niepewnych aplikacjach internetowych. Aplikacje internetowe to najczęściej wyglądana dziura w zabezpieczeniach. Za pomocą aplikacji internetowej osoba atakująca może uzyskać dostęp do bazy danych lub hosta. Żadna zapora ogniowa, IDS, zapora ogniowa nie ochronią Cię przed nimi. OWASP utrzymuje listę 10 najważniejszych luk w zabezpieczeniach i oferuje poprawki dla nich.

http://www.scribd.com/doc/19982/OWASP-Web-Security-Guide