Odpowiedzi:
Przede wszystkim należy pamiętać, że każda zdolność skryptowa w Apache (php, cgi, ruby, ...) jest potencjalnym ekwiwalentem konta powłoki z uprawnieniami użytkownika uruchamiającego skrypt.
Jeśli serwer jest współużytkowany przez wielu użytkowników, możesz pomyśleć o użyciu suexec (- lub ITK MPM - sugerowane przez Davida Schmitta ), aby nie każdy skrypt działał jako ten sam użytkownik Apache.
Apache wirtualizuj lub chroot, tak aby każdy kompromis był przynajmniej częściowo zawarty w dodatkowej warstwie bezpieczeństwa. Pamiętaj, że podczas chrootowania apache, konserwacja może stać się trudniejsza, ponieważ w końcu przenosisz biblioteki do więzienia itp. Jeśli korzystasz z FreeBSD, możesz zamiast tego użyć więzienia, co jest o wiele łatwiejsze w utrzymaniu, ponieważ możesz po prostu zainstalować apache z portów i uruchamiaj portaudit z jego wnętrza, nie martwiąc się o zależności bibliotek i ręczne przenoszenie plików, co zawsze staje się brzydkim bałaganem. W więzieniach BSD możesz po prostu nadal korzystać z systemu zarządzania pakietami (portów). (W systemie GNU / Linux można także używać VServera do wirtualizacji. - Sugerowane przez Davida Schmitta )
(oczywiście) Bądź na bieżąco z aktualizacjami i łatkami, nie tylko dla Apache, ale także PHP, Ruby, Perla itp. ... nie ufaj tylko swojemu systemowi, że dostarczy wszystkie aktualizacje. Niektóre dystrybucje są bardzo wolne z ich łatkami. Ogranicz czas ekspozycji do podatności na 0 dni w jak największym stopniu. Przykleić milw0rm kanał do swojego czytnika RSS, subskrybować insecure.org listach dyskusyjnych, itp ... Nie tylko to pomoże Ci dowiedzieć się o luki zanim OS omija się wydaje poprawkę, można również dowiedzieć się o lukach w pewnym php na przykład aplikacje cms, które mogą nie być w ogóle zarządzane lub łatane przez system operacyjny.
Użyj czegoś takiego jak tripwire / aide, audit lub mtree (na BSD), aby śledzić zmiany w systemie plików. Ten jest naprawdę ważny. Regularnie przesyłaj do Ciebie zmiany, sprawdzaj je ręcznie codziennie. Jeśli jakikolwiek plik się zmieni, który nie powinien się zmienić, sprawdź, dlaczego. Jeśli jakiś złośliwy javascript w jakiś sposób zostanie wstawiony na twoje strony za pomocą dowolnej metody, ZRÓBISZ to w ten sposób. Oszczędza to nie tylko serwer, ale także użytkowników, ponieważ własne strony internetowe mogą być wykorzystywane do infekowania użytkowników. (Jest to bardzo powszechna taktyka, napastnicy często nawet nie dbają o twój serwer, chcą jedynie zainfekować jak najwięcej odwiedzających, dopóki nie zostaną odkryci. Ci atakujący również nawet nie zadają sobie trudu, aby ukryć swoje ślady. Bardzo ważne jest szybkie osiągnięcie takiego kompromisu).
Używanie rzeczy takich jak suhosin do ochrony php pomaga. Naucz się też go rozumieć, dostosuj konfigurację do oczekiwanych parametrów aplikacji.
Użycie poprawki jądra, takiej jak PaX, może pomóc w ochronie przed wieloma lukami w zabezpieczeniach przed przepełnieniem bufora. Nawet jeśli twoje oprogramowanie jest podatne na ataki. (To nie czyni cię niewrażliwym, to tylko kolejna, drobna warstwa.)
Nie bądź zbyt pewny siebie podczas korzystania z jakiegoś narzędzia bezpieczeństwa. Zrozum, jakich narzędzi używasz i kieruj się zdrowym rozsądkiem. Czytaj, ucz się, bądź na bieżąco z jak najwięcej.
Rozważ zastosowanie obowiązkowej kontroli dostępu (np .: SELinux ). Pozwala bardzo szczegółowo określić dla każdej aplikacji, co może robić. Do jakich plików ma dostęp. To, co wywołuje jądro, jest dozwolone, itp. Jest to bardzo zaangażowany proces i wymaga dużo zrozumienia. Niektóre dystrybucje dostarczają gotowe polityki SELinuksa dla swoich pakietów (np .: Gentoo ). Ta sugestia jest swego rodzaju sprzecznością z poniższą, ale mimo to wciąż aktualna.
Uprość wszystko. Złożona strategia bezpieczeństwa może działać przeciwko tobie.
W Apache skonfiguruj bardzo restrykcyjne reguły domyślne (Opcje Brak, Odmów od wszystkich itp.) I zastąp w razie potrzeby dla określonych VirtualHostów.
Odmawiaj dostępu do wszystkich plików Dotfiles (co natychmiast obejmuje również pliki .htaccess)
Zawsze używaj protokołu https wszędzie tam, gdzie istnieje jakakolwiek metoda uwierzytelniania hasła.
Zapora sieciowa powinna być zasadą domyślnie zabronioną. Zbuduj określone reguły w zaporze, aby rejestrować określony ruch.
Skonfiguruj skrypty analizujące dzienniki, aby skanować dzienniki w poszukiwaniu anomalii. ( pakiet IDS preludium może to zrobić, ale szczerze mówiąc, zalecam tworzenie własnych skryptów w miarę upływu czasu, ponieważ pomoże to lepiej zrozumieć własne narzędzia i reguły).
Niech serwer codziennie wysyła raporty o ostatnio zalogowanych użytkownikach, aktywnych połączeniach, używanej przepustowości itp.
Przeprowadź skanowanie cron w poszukiwaniu plików binarnych suid, plików do zapisu na świecie i podobnych rzeczy oraz prześlij je pocztą.
Dla każdego skonfigurowanego elementu, który jest wysyłany do Ciebie pocztą, powinieneś stworzyć listę wyjątków w miarę upływu czasu. (foldery, aby zignorować zmiany w systemie plików, 777 plików, aby zezwolić, suid binaria, aby zezwolić). Ważne jest, aby otrzymywać powiadomienia tylko o rzeczach, które nie powinny się zdarzyć. Jeśli codziennie otrzymujesz pocztę z trywialnymi rzeczami, zaczniesz je ignorować, a one staną się bezcelowe.
Mają dobrą, nadmiarową, zbędną strategię tworzenia kopii zapasowych. I nie zakładaj tylko, że tworzenie obrazu lub kopii wszystkiego działa. Na przykład, jeśli MySQL jest w trakcie zapisywania do tabeli podczas tworzenia kopii zapasowej, pliki binarne MySQL mogą zostać uszkodzone podczas przywracania kopii zapasowej. Potrzebujesz więc crona, który mysqldump przechowuje twoje bazy danych na zwykłych obrazach lub nocnych plikach tar lub kontroli wersji lub cokolwiek innego, co masz skonfigurowane. Pomyśl o swojej strategii tworzenia kopii zapasowych. Mam na myśli, NAPRAWDĘ o tym pomyśl.
Nie polegaj na takich listach dla bezpieczeństwa :) Poważnie! Znajdziesz ich wiele w Internecie, przeczytaj je wszystkie, zbadaj każdą sugestię i wykorzystaj zdrowy rozsądek i doświadczenie, aby podjąć decyzję. Ostatecznie doświadczenie i zdrowy rozsądek to jedyne rzeczy, które cię ocalą. Nie ma list ani narzędzi. Czytaj, ale nie kopiuj bez zrozumienia.
Polecam Linuksową listę kontrolną bezpieczeństwa z SAN. Korzystam z tego, plus inne wewnętrzne procedury. Lista kontrolna może być nieco przestarzała, ale wiele kluczowych punktów jest prawdą.
Zawsze będą niezliczone uprawnienia do sprawdzania, niezliczone listy kontrolne, nigdy niekończące się odkrywanie nowych błędów / słabych punktów. Bezpieczeństwo Nie sądzę, że to coś, co włączasz lub wyłączasz, to coś, co robisz stale.
Biorąc pod uwagę „nieuniknioną awarię” oprogramowania, SELinux pomaga rozwiać pewne obawy (ponownie nie ma srebrnej kuli dla bezpieczeństwa). zakładając, że aplikacja w przestrzeni użytkownika zostanie naruszona, poprawne zasady SELinuksa uniemożliwiają jej działanie przy zwykłych (tj. jeśli SELinux został wyłączony lub zezwolenie). Będzie to oczywiście wymagać monitorowania dzienników kontroli i analizowania zainstalowanych zasad i modyfikowania ich w razie potrzeby, aby umożliwić działanie aplikacji.
Nie powiedziałbym, że domyślna polityka nie pomogłaby, ale osobiście lubię wiedzieć, na co pozwala.