Hosting wielu witryn - brakuje ważnej luki w zabezpieczaniu witryn przed sobą?

EDYCJA nr 2, 23 lipca 2015 r .: Szukając nowej odpowiedzi, która identyfikuje ważny element bezpieczeństwa pominięty w poniższej konfiguracji lub może dać powód, by sądzić, że wszystko jest objęte gwarancją.

EDYCJA nr 3 29 lipca 2015 r .: Szczególnie szukam możliwej błędnej konfiguracji, takiej jak nieumyślne zezwolenie na coś, co można wykorzystać do obejścia ograniczeń bezpieczeństwa lub jeszcze gorzej, pozostawiając coś szeroko otwartego.

Jest to konfiguracja hostingu obejmująca wiele witryn / hostowania współdzielonego. Chcemy korzystać ze współużytkowanej instancji Apache (tzn. Działającej pod jednym kontem użytkownika), ale z PHP / CGI uruchomionym jako użytkownik każdej witryny, aby żadna strona nie mogła uzyskać dostępu do plików innej witryny, i chcemy upewnij się, że nic nie zostanie pominięte (np. jeśli nie wiedzieliśmy o zapobieganiu atakom z użyciem dowiązań symbolicznych).

Oto co mam do tej pory:

• Upewnij się, że skrypty PHP działają jako konto użytkownika i grupa Linuksa na stronie internetowej i są albo uwięzione (na przykład przy użyciu CageFS), albo przynajmniej odpowiednio ograniczone przy użyciu uprawnień systemu plików Linux.
• Użyj suexec, aby upewnić się, że skrypty CGI nie mogą być uruchamiane jako użytkownik Apache.
• Jeśli potrzebujesz obsługi po stronie serwera (np. W plikach shtml), użyj, Options IncludesNOEXECaby uniemożliwić uruchomienie CGI, gdy nie jest to oczekiwane (chociaż nie powinno to stanowić większego problemu, jeśli używasz suexec).
• Włącz ochronę przed atakami dowiązań symbolicznych, aby haker nie mógł nakłonić Apache'a do serwowania plików innej witryny w postaci zwykłego tekstu i ujawniania możliwych do wykorzystania informacji, takich jak hasła DB.
• Skonfiguruj AllowOverride/ AllowOverrideListzezwalaj tylko na te dyrektywy, których haker nie mógłby wykorzystać. Myślę, że to mniej niepokoi, jeśli powyższe elementy są wykonane poprawnie.

Wybrałbym MPM ITK, jeśli nie byłby tak wolny i nie działałby jako root, ale szczególnie chcemy korzystać z udostępnionego Apache, ale upewnij się, że jest bezpiecznie.

Znalazłem http://httpd.apache.org/docs/2.4/misc/security_tips.html , ale nie było wyczerpujące na ten temat.

Jeśli warto wiedzieć, planujemy używać CloudLinux z CageFS i mod_lsapi.

Czy jest coś jeszcze do zrobienia lub o czym wiedzieć?

EDYCJA 20 lipca 2015 r .: Ludzie przesłali kilka dobrych alternatywnych rozwiązań, które są ogólnie cenne, ale pamiętaj, że to pytanie dotyczy tylko bezpieczeństwa wspólnej konfiguracji Apache. W szczególności, czy jest coś, czego nie wymieniono powyżej, co mogłoby pozwolić jednej witrynie uzyskać dostęp do plików innej witryny lub w jakiś sposób narazić inne witryny na szwank?

Dzięki!

Całkowicie zgadzam się z przedmiotami, które do tej pory posiadałeś.

Kilka lat temu uruchomiłem taką konfigurację dla wielu użytkowników i zasadniczo znalazłem ten sam kompromis: mod_php jest szybki (częściowo dlatego, że wszystko działa w tym samym procesie), a suexec jest wolny, ale bezpieczny (ponieważ każde żądanie wymaga nowego proces). Poszedłem z suexec, ponieważ wymagana była izolacja użytkownika.

Obecnie istnieje trzecia opcja, którą możesz rozważyć: daj każdemu użytkownikowi własny demon php-fpm. To, czy jest to wykonalne, zależy od liczby użytkowników, ponieważ każdy z nich musi uzyskać co najmniej jeden proces php-fpm przy użyciu swojego konta użytkownika (następnie demon używa mechanizmu podobnego do korekty w celu skalowania żądań, więc liczba procesów i wykorzystanie pamięci może być czynnikiem ograniczającym). Będziesz także potrzebował automatycznego generowania konfiguracji, ale powinno to być wykonalne za pomocą kilku skryptów powłoki.

Nie stosowałem tej metody w dużych środowiskach, ale IMHO to dobre rozwiązanie, aby zapewnić dobrą wydajność strony PHP, jednocześnie izolując użytkowników na poziomie procesu.

Wszystko, co do tej pory masz, wydaje się dobrze przemyślane. Jedyną rzeczą, którą mogłem postrzegać jako problem, jest fakt, że większość exploitów stara się uzyskać dostęp do roota w taki czy inny sposób. Więc nawet jeśli każda witryna oraz odpowiadające jej procesy i skrypty są poprawnie osadzone w więzieniu, a wszystko ma własnego użytkownika i uprawnienia, których haker z rootem nie mógł się tym przejmować, po prostu ominą wszystko, co skonfigurowałeś.

Moją sugestią byłoby użycie jakiegoś oprogramowania VM (VMware, VirtualBox, Qemu itp.), Aby dać każdej witrynie osobne więzienie systemu operacyjnego. Dzięki temu, jako administrator systemu, nie musisz się martwić o jedną zainfekowaną witrynę. Jeśli haker zdobędzie root za pomocą php (lub innego oprogramowania) na maszynie wirtualnej witryny, po prostu zatrzymaj maszynę wirtualną i przeanalizuj ją później, zastosuj poprawki lub przywróć do stanu nieprzerwanego. Pozwala to również administratorom witryny zastosować określone oprogramowanie lub ustawienia zabezpieczeń w określonym środowisku witryny (co może uszkodzić inną witrynę).

Jedynym ograniczeniem jest sprzęt, ale z przyzwoitym serwerem i prawidłowymi rozszerzeniami jądra łatwo sobie z tym poradzić. Z powodzeniem uruchomiłem tego typu konfigurację na Linode, zarówno gospodarz, jak i gość byli bardzo rzadcy. Jeśli czujesz się komfortowo z linią poleceń, którą zakładam, że nie jesteś, nie powinieneś mieć żadnych problemów.

Ten typ konfiguracji zmniejsza liczbę wektorów ataków, które należy monitorować, i pozwala skupić się na bezpieczeństwie komputerów hostów i zająć się wszystkim innym w witrynie według lokalizacji.

Sugerowałbym, aby każda strona działała pod własnym demonem Apache i chrootowała Apache. Wszystkie systemowe funkcje php zawiodą, ponieważ środowisko chroot Apache nie będzie miało dostępu do / bin / sh. Oznacza to również, że funkcja mail () php również nie będzie działać, ale jeśli używasz zewnętrznego dostawcy poczty do wysyłania poczty z aplikacji e-mail, nie powinno to stanowić problemu.

SELinux może być pomocny mod_selinux. Szybkie howto znajduje się tutaj:

Jak mogę używać SELinux do ograniczania skryptów PHP?

Ponieważ instrukcje są trochę przestarzałe, sprawdziłem, czy to działa na RHEL 7.1:

Użyłem wersji Fedory 19 i skompilowałem z próbą przeciwko RHEL 7.1 + EPEL.

YMMV, jeśli używasz podstawowej konfiguracji próbnej epel, jest dostarczany z:

[mockbuild@fedora mod_selinux]$ mock -r rhel-7-x86_64 --rebuild \
    mod_selinux-2.4.3-2.fc19.src.rpm

Najpierw zaktualizuj system docelowy, aby upewnić się, że selinux-policyjest aktualny.

Zainstaluj w polu docelowym (lub najpierw włóż do lokalnego serwera lustrzanego):

yum localinstall mod_selinux-2.4.3-2.el7.x86_64.rpm

Teraz musisz przypisać każdemu wirtualnemu hostowi w apache kategorię. Odbywa się to poprzez dodanie wiersza takiego jak w poniższym przykładzie o nazwie selinuxDomainVal.

<VirtualHost *:80>
    DocumentRoot /var/www/vhosts/host1
    ServerName host1.virtual
    selinuxDomainVal *:s0:c0
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot /var/www/vhosts/host2
    ServerName host2.virtual
    selinuxDomainVal *:s0:c1 
</VirtualHost>

Następnie, w katalogu głównym dokumentu dla każdego hosta, ponownie oznacz ich katalogi główne tą samą kategorią, co te oznaczone w konfiguracji httpd.

chcon -R -l s0:c0 /var/www/vhosts/host1
chcon -R -l s0:c1 /var/www/vhosts/host2

Jeśli chcesz, aby etykieta została uhonorowana, jeśli wykonasz etykietę systemową, lepiej zaktualizuj również lokalne zasady!

semanage fcontext -a -t httpd_sys_content_t -r s0-s0:c0 '/var/www/vhosts/host1(/.*)?' 
semanage fcontext -a -t httpd_sys_content_t -r s0-s0:c1 '/var/www/vhosts/host2(/.*)?'

Podano już wiele dobrych technicznych odpowiedzi (proszę również zajrzeć tutaj: https://security.stackexchange.com/q/77/52572 i Wskazówki dotyczące zabezpieczania serwera LAMP ), ale nadal chciałbym tu wspomnieć ważny punkt (z jeszcze innej perspektywy) na temat bezpieczeństwa: bezpieczeństwo to proces . Jestem pewien, że już to rozważyłeś, ale nadal mam nadzieję, że czasem przydatne (również dla innych czytelników) będzie przemyślenie tego.

Np. W swoim pytaniu koncentrujesz się głównie na środkach technicznych: „to pytanie dotyczy tylko bezpieczeństwa wspólnej konfiguracji Apache. W szczególności, czy są jakieś kroki bezpieczeństwa, które należy podjąć, ale których nie ma na powyższej liście podczas uruchamiania udostępnionego Apache i PHP ”.

Prawie wszystkie odpowiedzi tutaj i na 2 pozostałe pytania, o których wspomniałem, również wydają się mieć charakter czysto techniczny (z wyjątkiem zalecenia, aby być na bieżąco). Z mojego punktu widzenia może to sprawić, że niektórzy czytelnicy wprowadzą w błąd, że jeśli raz skonfigurujesz serwer zgodnie z najlepszą praktyką, pozostaniesz bezpieczny na zawsze. Proszę więc nie zapominać o punktach, w których brakuje mi odpowiedzi:

1. Przede wszystkim nie zapominaj, że bezpieczeństwo to proces, a zwłaszcza cykl „Planuj-sprawdzaj-działaj”, zgodnie z zaleceniami wielu norm, w tym ISO 27001 ( http://www.isaca.org/ Journal / archives / 2011 / Volume-4 / Pages / Planning-for-and-Implementing-ISO27001.aspx ). Zasadniczo oznacza to, że musisz regularnie weryfikować środki bezpieczeństwa, aktualizować je i testować .

2. Regularnie aktualizuj swój system. Nie pomoże to w ukierunkowanych atakach wykorzystujących luki zero-day, ale pomoże w prawie wszystkich automatycznych atakach.

3. Monitoruj swój system. Naprawdę brakuje mi tego punktu w odpowiedziach. Z mojego punktu widzenia niezwykle ważne jest jak najwcześniejsze powiadomienie o problemach z systemem.

   Tak mówią o tym statystyki: „Średni czas od infiltracji do odkrycia wynosi 173,5 dnia” ( http://www.triumfant.com/detection.html ), „205 mediana liczby dni przed wykryciem” ( https: // www2 .fireeye.com / rs / fireye / images / rpt-m-trend-2015.pdf ). I mam nadzieję, że te liczby nie są tym, co wszyscy chcemy mieć.

   Istnieje wiele rozwiązań (w tym darmowych) nie tylko do monitorowania stanu usługi (takich jak Nagios), ale także systemów wykrywania włamań (OSSEC, Snort) i systemów SIEM (OSSIM, Splunk). Jeśli stanie się to zbyt skomplikowane, możesz przynajmniej włączyć coś takiego jak „fail2ban” i / lub przekierować logi do oddzielnego serwera syslog i otrzymywać powiadomienia e-mail o ważnych zdarzeniach.

   Ponownie, najważniejszym punktem tutaj nie jest wybór systemu monitorowania, najważniejsze jest to, że masz pewne monitorowanie i regularnie je poprawiasz zgodnie z cyklem „Planuj-Wykonaj-Sprawdź-Działaj” .

4. Uważaj na luki w zabezpieczeniach. To samo co monitorowanie. Po prostu zasubskrybuj listę luk w zabezpieczeniach, aby otrzymywać powiadomienia, gdy zostanie wykryta krytyczna luka w Apache lub innej usłudze ważnej dla twojej konfiguracji. Celem jest otrzymanie powiadomienia o najważniejszych rzeczach, które pojawią się przed następną planowaną aktualizacją.

5. Przygotuj plan postępowania w razie incydentu (i regularnie go aktualizuj i koryguj zgodnie z cyklem „Zaplanuj-Wykonaj-Sprawdź-Działaj”). Jeśli zadajesz pytania dotyczące bezpiecznej konfiguracji, oznacza to, że bezpieczeństwo twojego systemu staje się dla Ciebie ważne. Co jednak należy zrobić w przypadku włamania do systemu pomimo wszystkich środków bezpieczeństwa? Ponownie nie mam tu na myśli wyłącznie środków technicznych, takich jak „ponowna instalacja systemu operacyjnego”: Gdzie należy zgłosić wypadek zgodnie z obowiązującym prawem? Czy wolno ci natychmiast wyłączyć / odłączyć serwer (ile to kosztuje dla twojej firmy)? Z kim należy się skontaktować, jeśli główna osoba odpowiedzialna jest na urlopie / choruje?

6. Mieć serwer kopii zapasowych, archiwizacji i / lub serwera zastępczego / replikacji. Bezpieczeństwo oznacza również dostępność Twojej usługi. Regularnie sprawdzaj swoją kopię zapasową / archiwum / replikację, a także regularnie testuj procedury przywracania.

7. Testy penetracyjne? (ponownie zobacz cykl „Planuj-Wykonaj-Sprawdź-Działaj”). Jeśli wydaje Ci się, że to za dużo, możesz przynajmniej spróbować darmowych narzędzi online, które skanują twoje usługi sieciowe w poszukiwaniu złośliwego oprogramowania i problemów z bezpieczeństwem.

Twój futerał jest idealny do kontenerów dokerów.

Każdy kontener może reprezentować klienta lub klienta, a unikalne identyfikatory użytkowników są przypisane do każdej grupy kontenerów Apache jako dodatkowe zabezpieczenie. Kluczem byłoby zrzucenie uprawnień roota podczas uruchamiania kontenera, przed uruchomieniem stosu apache. Każdy klient otrzymuje własną usługę DB z własnymi unikalnymi hasłami, bez kłopotów ze stawianiem dziesiątek maszyn wirtualnych, z których każde wymaga własnego jądra ze specjalnym płatkiem śniegu i innych kosztów ogólnych. W końcu w sercu dokera jest chroot. Właściwie administrowany, przejmowałbym to typowe wirtualne klastry każdego dnia.

Wiele dobrych sugestii już tutaj. Jednak do tej pory w dyskusji brakowało rzeczy.

Zwróć uwagę na procesy poza tymi uruchamianymi w ramach wyświetlania stron internetowych. tzn. upewnij się, że wszystkie zadania cron, które dotykają niezaufanych danych, działają jako odpowiedni użytkownik i w odpowiednim więzieniu, niezależnie od tego, czy zadania te są zdefiniowane przez użytkownika, czy nie.

Z mojego doświadczenia wynika, że ​​takie analizy dzienników, gdy są dostarczane przez usługę hostingową, są uruchamiane tak samo jak root, a oprogramowanie do analizy dzienników nie jest poddawane tak dużej kontroli bezpieczeństwa, jak byśmy chcieli. Robienie tego dobrze jest trochę trudne i zależy od konfiguracji. Z jednej strony nie chcesz, aby proces apache należący do użytkownika root (tj. Proces nadrzędny) zapisywał w dowolnym katalogu, który użytkownik mógłby naruszyć. To prawdopodobnie oznacza, że ​​nie można bezpośrednio pisać do więzienia. Z drugiej strony musisz udostępnić te pliki procesom w więzieniu do analizy, a chcesz, aby były one jak najbardziej zbliżone do czasu rzeczywistego. Jeśli możesz dać swoim więzcom dostęp do montowania systemu plików tylko do odczytu za pomocą dzienników, powinno to być dobre.

Aplikacje PHP zazwyczaj nie obsługują własnych plików statycznych, a jeśli masz wspólny proces apache, to zgaduję, że twój proces apache czyta rzeczy prosto z więzień ze środowiska hosta? Jeśli tak, to rodzi to szereg obaw.

.htaccesspliki są oczywiste, dlatego musisz bardzo uważać na to, na co zezwalasz. Wiele, jeśli nie najistotniejsze aplikacje php, są bardzo zależne od aranżacji plików .htaccess, na co prawdopodobnie nie można pozwolić bez obalenia planowanego schematu.

Mniej oczywiste jest to, w jaki sposób apache decyduje, co to jest plik statyczny. np. co robi z plikiem *.php.giflub *.php.en? Jeśli ten lub inny mechanizm oszukuje rozróżnienie co do tego, co jest plikiem statycznym, czy apache może w ogóle uruchomić php spoza więzienia? Skonfigurowałbym osobny lekki serwer WWW dla treści statycznych, który nie jest skonfigurowany z żadnymi modułami do wykonywania treści dynamicznych, a moduł równoważenia obciążenia decyduje, które żądania wysłać do serwera statycznego, a które do dynamicznego.

Jeśli chodzi o sugestię Dockera Stefana, możliwe jest posiadanie jednego serwera WWW, który znajduje się poza kontenerem i który komunikuje się z demonami php w każdym kontenerze w celu uzyskania zawartości dynamicznej, a także drugi serwer WWW, który znajduje się w kontenerze dokera, i który dzieli woluminy, z których każdy korzysta ze swojej zawartości, i w ten sposób może obsłużyć treść statyczną, która jest bardzo podobna jak w poprzednim akapicie. Polecam okno dokowane wśród różnych podejść do więzienia, ale przy takim lub innym podejściu do więzienia będziesz musiał rozwiązać wiele innych problemów. Jak działa przesyłanie plików? Czy umieszczasz demony transferu plików w każdym kontenerze? Czy stosujesz podejście oparte na git PAAS? Jak sprawić, by dzienniki wygenerowane w kontenerze były dostępne, i obrócić je? Jak zarządzasz i uruchamiasz zadania cron? Czy zamierzasz dać użytkownikom dostęp do powłoki, a jeśli tak, to czy jest to kolejny demon w kontenerze? itd itd.

Pierwszą rzeczą, której nie widzę, jest zarządzanie procesami, więc jeden proces nie może zagłodzić innego procesora lub pamięci RAM (lub We / Wy, jeśli chodzi o tę sprawę, chociaż system plików może być tak zaprojektowany, aby temu zapobiec). Jedną z głównych zalet podejścia „kontenerów” do instancji PHP w porównaniu z próbą uruchomienia ich wszystkich na jednym obrazie „OS” jest to, że można lepiej ograniczyć wykorzystanie zasobów. Wiem, że to nie twój projekt, ale to jest coś do rozważenia.

W każdym razie wracając do przypadku użycia PHP działającego za Apache, działającego zasadniczo jako serwer proxy. suexec nie przeszkadza, aby coś działało jako użytkownik apache - zapewnia możliwość działania jako inny użytkownik. Tak więc jednym problemem będzie upewnienie się, że wszystko zostało wykonane poprawnie - strona z dokumentami wywołuje to potencjalne niebezpieczeństwo: https://httpd.apache.org/docs/2.2/suexec.html . Wiesz, ziarno soli i tak dalej.

Z punktu widzenia bezpieczeństwa to może być pomocne mieć ograniczony zestaw plików binarnych użytkownika do pracy z (co cagefs dostaw), zwłaszcza jeśli są one zestawiane w różny sposób lub przeciwko innej biblioteki (np taki, który nie zawiera funkcje, które są niepożądane) ale istnieje niebezpieczeństwo, że w tym momencie nie będziesz już śledził znanej dystrybucji aktualizacji, tylko inną dystrybucję (cagefs) dla swoich instalacji PHP (przynajmniej w odniesieniu do narzędzi przestrzeni użytkownika). Chociaż prawdopodobnie korzystasz już z konkretnej dystrybucji za pomocą cloudlinux, jest to ryzyko przyrostowe, niekoniecznie samo w sobie interesujące.

Pozostawiłbym AllowOverride w miejscu, w którym mógłbyś to zaplanować. Podstawową ideą głębokiej obrony jest nie poleganie na jednej warstwie w celu ochrony całego stosu. Zawsze zakładaj, że coś może pójść nie tak. Łagodź, kiedy to się stanie. Powtarzaj tę czynność, dopóki nie złagodzisz tego, jak możesz, nawet jeśli masz tylko jedno ogrodzenie przed swoimi miejscami.

Kluczem będzie zarządzanie logami. Ponieważ wiele usług działa w izolowanych systemach plików, integracja działań w celu skorelowania w przypadku wystąpienia problemu może być niewielkim problemem, jeśli nie skonfigurowano go od samego początku.

To zrzut mojego mózgu. Mam nadzieję, że jest tam coś niejasno przydatnego. :)