[+] Apache - VirtualHost - ochrona przed kompromitacją

Konfiguracja serwerów, usług, itp.
Awatar użytkownika
lol_ek
Posty: 43
Rejestracja: 17 października 2008, 11:00
Lokalizacja: G-ce

[+] Apache - VirtualHost - ochrona przed kompromitacją

Post autor: lol_ek »

Witam

Mam niewielki serwer z kilkoma stronami www (kilka vh). Jak się zabezpieczyć na ewentualność kompromitacji jednej z nich ? Zmierzam do tego, by taką problematyczną stronę odizolować od pozostałych witryn. Nie potrafię się precyzyjnie wyrazić, ale chciałbym stworzyć dla każdej z witryn odrębna piaskownicę (kontener ?), tak by problematyczna witryna nie oddziaływała na pozostałe.
Ostatnio zmieniony 02 maja 2020, 10:47 przez lol_ek, łącznie zmieniany 1 raz.
Awatar użytkownika
LordRuthwen
Moderator
Posty: 2305
Rejestracja: 18 września 2009, 21:45
Lokalizacja: klikash?

Re: Apache - VirtualHost - ochrona przed kompromitacją

Post autor: LordRuthwen »

Uruchom proces php dla każdej ze tron jako inny użytkownik.
Awatar użytkownika
Yampress
Administrator
Posty: 6366
Rejestracja: 09 sierpnia 2007, 21:41
Lokalizacja: PL

Re: Apache - VirtualHost - ochrona przed kompromitacją

Post autor: Yampress »

poza tym utrzymuj aktualny system i skrypty php, które uruchamiasz pod serwerem www
Awatar użytkownika
lol_ek
Posty: 43
Rejestracja: 17 października 2008, 11:00
Lokalizacja: G-ce

Re: Apache - VirtualHost - ochrona przed kompromitacją

Post autor: lol_ek »

@LordRuthwen - czyli zakładam, że masz na myśli php-fpm, tak jak o tym wspominałeś w innym wątku.

Sugestia @Yampress o ogólnej kondycji systemu jest dla mnie oczywista. Pytanie pojawiło się w związku z tym, że zasoby pod stronę na WP muszę udostępnić osobie trzeciej i już mam wyobrażenie co się stanie z taką witryną, która ostatecznie zostanie porzucona przez opiekuna.

Znajomy podrzucił mi takie tematy jak LXC / Docker, ale zastanawiam się czy powinienem brnąć w tym kierunku.
Awatar użytkownika
Yampress
Administrator
Posty: 6366
Rejestracja: 09 sierpnia 2007, 21:41
Lokalizacja: PL

Re: Apache - VirtualHost - ochrona przed kompromitacją

Post autor: Yampress »

raczej chodzi mu o narzedzia typu suPHP, suexec
poczytaj dodatkowo o mod-security
spróbuj zaimplementować jeden z mechanizmów dostępu selinux,rsbac,lub apparmor

powyłaczaj przedstawianie się wersji apache i php
wyłacz directoryindex jesli jest właczone, aby nie indexowało katalogu itp
ponadawaj uprawnienia chmod/chown do plików/katalogów dokładnie takie jakie zaleca dany skrypt
Awatar użytkownika
LordRuthwen
Moderator
Posty: 2305
Rejestracja: 18 września 2009, 21:45
Lokalizacja: klikash?

Re: Apache - VirtualHost - ochrona przed kompromitacją

Post autor: LordRuthwen »

Tak, miałem na myśli php-fpm. Wg mnie jest to bardzo fajna sprawa.
Jeżeli serwer masz skonfigurowany poprawnie, to wordpress aktualizuje się sam, ale tylko skrypt główny. Najwięcej włamów na tego cms-a jest przez nieaktualne wtyczki czy style, bo te trzeba aktualizować ręcznie. Poza tym jest baaardzo user-friendly.
Takie wynalazki jak modsecurity oczywiście poprawiają bezpieczeństwo wycinając bardzo dużo requestów. Dla standardowych konfiguracji to jest spoko, ale jak masz autorską i rozbudowaną aplikację, to to już trzeba spędzić trochę czasu przerabiając reguły, żeby nie blokowały ciebie samego (np blokuje wysyłanie jsonem).
Awatar użytkownika
lol_ek
Posty: 43
Rejestracja: 17 października 2008, 11:00
Lokalizacja: G-ce

Re: Apache - VirtualHost - ochrona przed kompromitacją

Post autor: lol_ek »

Puki co poszedłem w stronę PHP-FPM. Proszę mnie poprawić, jeśli moja koncepcja jest błędna.

Zakładam nowe konto w systemie dla wspominanej strony i tworzę osobne reguły dla php-fpm (zgodnie z szablonem site1.conf).
Konfiguruję virtualhosta tak by odwoływał się na unikalny soket, który powstał na potrzeby kontrolowanego użytkownika.
Uzupełniam wartości user, group podając nazwę utworzonego użytkownika (grupy), a listen.owner = www-data pozostawiam bez zmian.

/etc/php5/fpm/pool.d/site1.conf
[site1]
user = site1
group = site1
listen = /var/run/php5-fpm-site1.sock
listen.owner = www-data
listen.group = www-data
php_admin_value[disable_functions] = exec,passthru,shell_exec,system
php_admin_flag[allow_url_fopen] = off
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

Aby przetestować skuteczność tego rozwiązania, na utworzone konto wrzuciłem kilka plików php. Bawiłem się uprawnieniami, zmieniając właściciela plików. Ku mojemu zdziwieniu, plik przez www mogłem nadal wyświetlać więc podejrzewałem, że blokada nie działa, a ja popełniłem błędy w konfiguracji. Ostatecznie zauważyłem, że wyświetlenie strony poprzedzone przeładowaniem php-fpm i apacza, w końcu dały pożądany efekt i w przeglądarce uzyskałem oczekiwane "access denied".

Czy moje przypuszczenia są słuszne, że taki plik jest gdzieś keszowany i dopiero po większym upływie czasu, zmiany uprawnień przynoszą skutek ? Jeśli tak czy da się to gdzieś korygować i czy jest to sensowne działanie. W ramach mojej symulacji uprawnienia zmieniałem z poziomu roota, a wspominana osoba będzie miała dostęp jedynie poprzez ftp (konto użytkownika)

Czy jest sens blokowania uprawnienia "odczytywany przez innych" ? Początkowo zakładałem by wadliwa strona jedynie nie nadpisała mi innych plików (stron), ale może sensowniej będzie zablokować nawet wywołanie takiego pliku jeśli właściciel nie będzie się zgadzał.

W ramach testu wgrałem sobie skrypt w php, który wyszukuje pliki na koncie. Czy da się jakoś wymusić działaniami po stronie serwera, by pokazał on jedynie pliki z konta użytkownika ?
Awatar użytkownika
LordRuthwen
Moderator
Posty: 2305
Rejestracja: 18 września 2009, 21:45
Lokalizacja: klikash?

Re: Apache - VirtualHost - ochrona przed kompromitacją

Post autor: LordRuthwen »

A uruchom listena jako innego użytkownika.
przykład:

Kod: Zaznacz cały

[web6]

listen = /var/lib/php7.4-fpm/web6.sock
listen.owner = web6
listen.group = www-data
listen.mode = 0660

user = web6
group = client1

pm = dynamic
pm.max_children = 10
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 5
pm.max_requests = 0

chdir = /

env[HOSTNAME] = $HOSTNAME
env[TMP] = /var/www/clients/client1/web6/tmp
env[TMPDIR] = /varwww/clients/client1/web6/tmp
env[TEMP] = /var/www/clients/client1/web6/tmp
env[PATH] = /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

php_admin_value[session.save_path] = /var/www/clients/client1/web6/tmp
php_admin_value[upload_tmp_dir] = /var/www/clients/client1/web6/tmp
php_admin_value[sendmail_path] = "/usr/sbin/sendmail -t -i -f webmaster@domena.tld"
Awatar użytkownika
lol_ek
Posty: 43
Rejestracja: 17 października 2008, 11:00
Lokalizacja: G-ce

Re: Apache - VirtualHost - ochrona przed kompromitacją

Post autor: lol_ek »

Zastosowałem się do Twojego przykładu, analogicznie podmieniając na użytkownika zgodnego z przydziałem do konta dla VH / FTP.
Konkluzja z przeprowadzonych przez mnie testów jest taka, że blokada działa. Należy natomiast zwrócić uwagę, że jeśli plik zostanie już załadowany i wyświetlony w przeglądarce, to późniejsze nakładanie kagańca np. poprzez ujmowanie uprawnień nawet do zera, czy też zmiany właściciela pliku na niezgodnego z przydziałem, nic nie daje. Odświeżanie strony, nawet z innego urządzenia powoduje dalsze wyświetlanie się treści. Wspominałem wcześniej, że przeładowanie php-fpm powoduje, że nowo nadane uprawnienia na plikach mają zastosowanie. Ponadto, zmiana zawartości tego pliku, a nawet otwarcie i ponowne zapisanie bez dokonania edycji powoduje, że skorygowane uprawnienia wchodzą w życie.

Wychodzi z tego, że pliki faktycznie leci do jakiegoś keszu jeśli tylko ma prawo załadować plik. Z jednej strony zastanawiam się czy powinienem się tym martwić w kontekście bezpieczeństwa, a z drugiej strony ciekawi mnie ile wymości taka latencja i czy można ją w jakiś sposób edytować lub na jakich zasadach te dane są korygowane.

Wyobrażam sobie, że interwencyjnie z konsoli zmieniam uprawnienia, a wychodzi na to, że apach ma to gdzieś.
Awatar użytkownika
LordRuthwen
Moderator
Posty: 2305
Rejestracja: 18 września 2009, 21:45
Lokalizacja: klikash?

Re: Apache - VirtualHost - ochrona przed kompromitacją

Post autor: LordRuthwen »

A jakie masz moduły w php? Od wersji chyba 7.2 domyślnie włączony jest opcache. Co prawda trzeba go jawnie wywołać, ale on trzyma kod php aż do jawnego wyczyszczenia.
Zablokowany