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


9

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!


poczekaj, więc jesteś czy nie blokujesz poleceń takich jak shell_exec
Michael Bailey

A raczej działa. Nie polecenia.
Michael Bailey,

1
Poprawnie - nie blokujemy tych poleceń. Ponieważ CageFS izoluje PHP w tak dużym stopniu, ograniczanie takich poleceń w ramach podejścia opartego na głębokiej obronie nie wydaje się tego warte, biorąc pod uwagę, że czasami wykorzystujemy je do uzasadnionych celów. Jeśli serwer byłby celem dla hakerów o wysokiej wartości (np. Przechowywane dane karty kredytowej lub coś w tym rodzaju), korzyści mogłyby przewyższyć wady, ale w naszym przypadku nie sądzę, aby ograniczenie było uzasadnione. Jest to jednak zdecydowanie warte rozważenia dla osób, które nie używają CageFS lub innego równoważnego rozwiązania.
sa289,

1
Niestety z powodu CPanel przeceniłeś dobre odpowiedzi - reszta to już historia.
user9517

2
Oto podsumowanie powodów, dla których „pominąłem” te odpowiedzi. Dedykowany Apache dla witryny lub kontenerów Docker - wymaga bardziej dedykowanych publicznych adresów IP lub dodatkowej złożoności odwrotnego proxy. Selinux - wymaga skonfigurowania i uruchomienia selinux w trybie wymuszania. Maszyny wirtualne - wymaga dodatkowych zasobów systemowych w porównaniu z konfiguracją inną niż maszyna wirtualna. Myślę, że wszystkie są dobrymi rozwiązaniami, ale nie bez wad, z którymi wolałbym nie korzystać.
sa289,

Odpowiedzi:


9

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.


Popraw mnie, jeśli się mylę, ale myślę, że rozwiązanie mod_lsapi + CageFS, które już planujemy dla PHP, jest co najmniej tak dobre, jeśli nie lepsze niż PHP-FPM, prawda? Dzięki
sa289,

Nie mam doświadczenia z mod_lsapi i miałbym zastrzeżenia ufające rozwiązaniu jednego dostawcy z zamkniętym źródłem. Ale według strony reklamowej powinno być tak samo dobre i tak szybkie, tak. - Chciałbym zbadać, w jaki sposób odradza się nowe procesy (na nowe żądania) i jak zmienia ich efektywny identyfikator użytkownika na użytkownika. Jeśli chodzi o bezpieczeństwo, to jest najsłabszy punkt; Dokumentacja suexec zawiera dobre wyjaśnienie rzeczy, na które należy zwrócić uwagę.
mschuett

Przypuszczam, że istnieje powód, by nie ufać hehe zamkniętemu lub open source (Shellshock odkrył 25 lat, Heartbleed 2 lata i kto wie o TrueCrypt). Na szczęście myślę, że mod_lsapi jest oparty na ofercie OpenSpeed ​​LiteSpeed, więc jest co najmniej kilku dostawców, którzy patrzą na niektóre z nich, a także ktokolwiek chce spojrzeć na otwarty kod źródłowy, na którym jest oparty. Szczególnie szukam wszelkich kluczowych rzeczy związanych z bezpieczeństwem, których mógłbym brakować w proponowanej konfiguracji (np. Powodowanie uruchamiania PHP jako użytkownika strony, ale zapominanie o suEXEC dla skryptów CGI). Dzięki
sa289,

Stosujemy to podejście (serwer WWW z php-fpm) na stronach internetowych o dużej skali (gdzie farma serwerów łączy się z farmą php-fpm za pomocą modułu równoważenia obciążenia). Piękno takiej konfiguracji, w której wirtualne hosty są oddzielone na poziomie systemu operacyjnego i że granica ta nie jest łatwo ominięta (po prostu upewnij się, że katalog domowy wirtualnego hosta ma uprawnienia takie jak 0710 z własnością użytkownika vhost i grupy procesu serwera WWW , to kwestia odpowiednich uprawnień - jeśli świat plików będzie czytelny, będzie dostępny dla serwera)
galaktyka

4

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.


Zgadzam się, że zapewniają one większe bezpieczeństwo i mają inne zalety, ale mają też wady, o których niektóre wspomniałeś. Założeniem tego pytania jest jednak wspólny Apache. Dzięki CageFS szanse na exploit roota powinny zostać zmniejszone - nie tak skutecznie jak VM, ale do poziomu, który dobrze oceniam, biorąc pod uwagę strony, które prowadzimy. Moim głównym celem jest unikanie wszelkich błędów we właściwym zabezpieczeniu, tak aby ktoś musiał uzyskać idealną burzę, aby uzyskać dostęp do roota. Na przykład z łatwością mogłem zauważyć, że w przeszłości nie wiedziałem o atakach z użyciem dowiązań symbolicznych i że był to poważny błąd. Thx
sa289

4

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.


Chciałbym to zrobić w ten sposób - robiliśmy to w przeszłości (bez chrootowania), ale niestety uniemożliwia nam to korzystanie ze standardowej konfiguracji panelu sterowania, a także zajmuje więcej dedykowanych adresów IP, chyba że robimy więcej -skomplikowana konfiguracja odwrotnego proxy z nasłuchiwaniem Apache na wewnętrznych adresach IP, jak udokumentowano na stronie Apache.
sa289

Ach tak, to dobra rzecz, o której tam wspomniałeś. Z pewnością będzie to wymagało posiadania adresu IP dedykowanego więcej niż IP lub powrotu do odwrotnego proxy.
Alpha01,

Jeśli ktoś, kto czyta tę odpowiedź, jest zainteresowany dokumentacją konfiguracji odwrotnego proxy, sprawdź wiki.apache.org/httpd/DifferentUserIDsUsingReverseProxy
sa289,

4

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(/.*)?'

Podoba mi się ten pomysł, ale musiałbym włączyć selinux na serwerze, co może powodować inne trudności. +1, ponieważ uważam, że może to być świetne rozwiązanie dla osób, którym to nie przeszkadza.
sa289,

4

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.


1
Dobry dodatek dla osób, o których należy pamiętać. W przypadku, gdy jest to pomocne dla kogoś, spędziłem dużo czasu na przeglądaniu dwóch pierwszych opublikowanych linków i ich linków, aby sprawdzić, czy mogę znaleźć coś ważnego, co przeoczyłem. Zasoby związane z tym, że myślałem, że były najbardziej pomocne były benchmarks.cisecurity.org/downloads/show-single/... i iase.disa.mil/stigs/app-security/web-servers/Pages/index.aspx , choć między nimi zachodziło przyzwoite nakładanie się. Nie natknąłem się na nic ważnego, ale nadal warto przeczytać, jeśli bezpieczeństwo jest najważniejsze.
sa289,

3

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.


Czy to oznaczałoby, że dla każdego klienta istniałby dedykowany demon Apache? Jeśli tak, myślę, że wada byłaby podobna do odpowiedzi Alpha01.
sa289

Tak, jest bardzo podobny do Alpha01, chociaż dokowanie aplikacji powoduje uciążliwość związaną z konfiguracją hosta. To powiedziawszy, twój problem z panelem sterowania utrzymuje się, niezależnie od tego, czy używasz metody chroot / container, czy podejścia z jedną maszyną wirtualną na klienta.
Stephan

Dzięki. Nawet bez panelu sterowania wolałbym raczej unikać odwrotnego proxy lub wymagać więcej publicznych adresów IP, chyba że nie rozumiem, jak ta konfiguracja działałaby.
sa289,

1
Większość sklepów, które widziałem (duże i małe), stosuje podejście odwrotnego proxy. Używam HAProxy osobiście, idealnie nadaje się do rodzaju izolacji na dużą skalę, której szukasz. Jest wysoce wydajny i pozwala na bardzo wydajne skalowanie w poziomie i nie wymaga tego rodzaju egzotycznej złożoności, która wydaje się widoczna w rozwiązaniu mschuett.
Stephan

2

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.


Dzięki. Aby odpowiedzieć na twoje pytanie - PHP nie może działać poza więzieniem, nawet jeśli o ile wiem, używane jest inne rozszerzenie pliku z powodu CageFS. Próbowałem zarówno SetHandleri AddTypezrobić nowe rozszerzenie być przetwarzane jak PHP i został uwięziony. Nie wiem, czy jest jakoś na to poradzić, ale mam nadzieję, że ktoś wskaże, jeśli coś przegapię. Tak, Apache czyta prosto z więzień. Warto spojrzeć na zadania crona - wygląda na to, że różne rzeczy uruchamiane jako root są źródłem wielu zgłoszonych luk.
sa289,

RE: .htaccessw konf użyłem AllowOverrideList aby umożliwić takie: Add{Charset,DefaultCharset,Encoding,Handler,OutputFilter,OutputFilterByType,Type} Allow Auth{GroupFile,Name,Type,UserFile} Deny DirectoryIndex ErrorDocument Expires{Active,ByType,Default} FileETag ForceType Header IndexIgnore Order php_flag php_value Redirect RedirectMatch Remove{Handler,Type} RequestHeader Require Rewrite{.various.} Satisfy Set{Env,EnvIf,EnvIfNoCase,Handler} SSLRequireSSL. Moje obawy dotyczą AddType, AddHandler i SetHandler, ale Drupal używa SetHandler do głębokiej obrony na przykład w katalogach przesyłania plików.
sa289,

Jeśli pozwalasz ludziom majstrować przy przewodnikach, musisz przejść przez wszystkie zdefiniowane działania i upewnić się, że są bezpieczne, a nie tylko php.
mc0e

Słuszna uwaga! Potwierdziłem SetHandler server-infolub SetHandler server-statusw pliku htaccess jest jednym ze sposobów, w jaki ktoś może ułatwić atak lub ujawnić informacje, które idealnie nie zostałyby ujawnione, takie jak wszystkie VirtualHosts na serwerze (które mogłyby być wykorzystane na przykład do phishingu typu spear) lub bieżący ruch do innych witryn . Być może będę musiał uciekać się do usunięcia niektórych z tych Handler / Type z mojego AllowOverrideList. Czy znasz jakiś sposób, aby wyświetlić listę wszystkich możliwych działań / procedur obsługi? Próbowałem szukać w Internecie, ale nie znalazłem dobrej odpowiedzi.
sa289

1
Przyznaliśmy Ci nagrodę, ponieważ nasza dyskusja doprowadziła do podatności na ujawnienie informacji, której nie opisałem. Daj mi znać, jeśli masz odpowiedź na temat wyświetlania działań / procedur obsługi. Thx
sa289,

1

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


Dzięki. Aby pomóc rozwiązać problem z zasobami, o którym wspomniałeś CloudLinux ma coś o nazwie Lightweight Virtual Environment (LVE) i MySQL Governor.
sa289

To jest bardzo fajne.
Mary,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.