Jakie uprawnienia powinny mieć moje pliki / foldery witryny na serwerze Linux?

To jest kanoniczne pytanie dotyczące uprawnień do plików na serwerze sieciowym z systemem Linux.

Mam serwer Linux z Apache2, który obsługuje kilka stron internetowych. Każda witryna ma własny folder w katalogu / var / www /.

/var/www/contoso.com/
/var/www/contoso.net/
/var/www/fabrikam.com/

Katalog podstawowy / var / www / jest własnością root: root. Apache działa jako www-data: www-data. Witryna Fabrikam jest prowadzona przez dwóch programistów, Alice i Boba. Obie strony Contoso są prowadzone przez jednego programistę, Eve. Wszystkie strony internetowe pozwalają użytkownikom na przesyłanie zdjęć. W przypadku naruszenia bezpieczeństwa witryny wpływ powinien być jak najbardziej ograniczony.

Chcę wiedzieć, jak najlepiej skonfigurować uprawnienia, aby Apache mógł obsługiwać zawartość, witryna była zabezpieczona przed atakami, a programiści mogli wprowadzać zmiany. Jedna ze stron ma następującą strukturę:

/var/www/fabrikam.com
    /cache
    /modules
    /styles
    /uploads
    /index.php

Jak ustawić uprawnienia do tych katalogów i plików? Przeczytałem gdzieś, że nigdy nie powinieneś używać uprawnień 777 na stronie, ale nie rozumiem, jakie problemy mogą powodować. Podczas zajętych okresów witryna automatycznie buforuje niektóre strony i przechowuje wyniki w folderze pamięci podręcznej. Cała zawartość przesłana przez odwiedzających witrynę jest zapisywana w folderze przesyłania.

Podejmując decyzję, jakich uprawnień użyć, musisz dokładnie wiedzieć, kim są Twoi użytkownicy i czego potrzebują. Serwer WWW współdziała z dwoma typami użytkowników.

Uwierzytelnieni użytkownicy mają konto użytkownika na serwerze i mogą mieć określone uprawnienia. Zwykle obejmuje to administratorów systemu, programistów i konta usług. Zwykle wprowadzają zmiany w systemie za pomocą SSH lub SFTP.

Anonimowi użytkownicy są użytkownikami Twojej witryny. Chociaż nie mają uprawnień do bezpośredniego dostępu do plików, mogą poprosić o stronę internetową, a serwer internetowy działa w ich imieniu. Możesz ograniczyć dostęp anonimowych użytkowników, uważając na to, jakie uprawnienia ma proces serwera WWW. W wielu dystrybucjach Linuksa Apache działa jako www-dataużytkownik, ale może być inny. Użyj ps aux | grep httpdlub, ps aux | grep apacheaby zobaczyć, jakiego użytkownika Apache używa w twoim systemie.

Uwagi na temat uprawnień do Linuksa

Linux i inne systemy zgodne z POSIX używają tradycyjnych uprawnień uniksowych. W Wikipedii znajduje się doskonały artykuł na temat uprawnień do systemu plików, więc nie powtórzę tutaj wszystkiego. Ale jest kilka rzeczy, o których powinieneś wiedzieć.

Skrypty bitowe zinterpretowane (np. Ruby, PHP) działają dobrze bez uprawnień do wykonywania. Tylko pliki binarne i skrypty powłoki wymagają bitu wykonania. Aby przejść (wejść) do katalogu, musisz mieć uprawnienia do wykonywania tego katalogu. Serwer sieciowy potrzebuje tego uprawnienia, aby wyświetlić katalog lub udostępnić zawarte w nim pliki.

Domyślne nowe uprawnienia do pliku
Po utworzeniu plik zwykle dziedziczy identyfikator grupy tego, kto go utworzył. Ale czasami chcesz, aby nowe pliki dziedziczyły identyfikator grupy folderu, w którym zostały utworzone, więc włączasz bit SGID w folderze nadrzędnym.

Domyślne wartości uprawnień zależą od twojego umask. Umask odejmuje uprawnienia od nowo tworzonych plików, więc wspólna wartość 022 powoduje, że pliki są tworzone za pomocą 755. Podczas współpracy z grupą warto zmienić umask na 002, aby tworzone przez Ciebie pliki mogły być modyfikowane przez członków grupy. A jeśli chcesz dostosować uprawnienia przesyłanych plików, musisz zmienić umask na apache lub uruchomić chmod po przesłaniu pliku.

Problem z 777

Kiedy chmod 777twoja strona internetowa nie ma żadnych zabezpieczeń. Każdy użytkownik w systemie może zmienić lub usunąć dowolny plik w witrynie. Ale co ważniejsze, pamiętaj, że serwer internetowy działa w imieniu odwiedzających twoją stronę, a teraz serwer internetowy może zmieniać te same pliki, które wykonuje. Jeśli w Twojej witrynie występują luki w programowaniu, można je wykorzystać do zniszczenia witryny, włożenia ataków phishingowych lub kradzieży informacji z serwera bez Twojej wiedzy.

Dodatkowo, jeśli twój serwer działa na dobrze znanym porcie (który powinien uniemożliwić użytkownikom innym niż root odradzanie się usług odsłuchowych, które są dostępne na całym świecie), oznacza to, że twój serwer musi być uruchomiony przez root (chociaż każdy rozsądny serwer natychmiast spadnie na konto mniej uprzywilejowane, gdy port zostanie powiązany). Innymi słowy, jeśli prowadzisz serwer WWW, na którym główny plik wykonywalny jest częścią kontroli wersji (np. Aplikacja CGI), pozostawiając jego uprawnienia (lub, w tym przypadku, uprawnienia do katalogu zawierającego, ponieważ użytkownik może zmienić nazwę plik wykonywalny) w 777 pozwala każdemu użytkownikowi uruchomić dowolny plik wykonywalny jako root.

Zdefiniuj wymagania

• Programiści potrzebują dostępu do odczytu / zapisu plików, aby mogli aktualizować witrynę
• Programiści potrzebują odczytu / zapisu / wykonania w katalogach, aby mogli przeglądać
• Apache potrzebuje dostępu do odczytu plików i interpretowanych skryptów
• Apache potrzebuje dostępu do odczytu / wykonywania do katalogów obsługiwanych
• Apache potrzebuje dostępu do odczytu / zapisu / wykonania do katalogów w celu przesłania treści

Obsługiwany przez jednego użytkownika

Jeśli tylko jeden użytkownik jest odpowiedzialny za utrzymanie witryny, ustaw go jako właściciela w katalogu witryny i nadaj mu pełne uprawnienia rwx. Apache nadal potrzebuje dostępu, aby mógł obsługiwać pliki, więc ustaw www-data jako właściciela grupy i daj grupie uprawnienia rx.

W twoim przypadku Ewa, której nazwa użytkownika może być eve, jest jedynym użytkownikiem, który utrzymuje contoso.com:

chown -R eve contoso.com/
chgrp -R www-data contoso.com/
chmod -R 750 contoso.com/
chmod g+s contoso.com/
ls -l
drwxr-s--- 2 eve      www-data   4096 Feb  5 22:52 contoso.com

Jeśli masz foldery, które Apache musi zapisywać, możesz po prostu zmodyfikować wartości uprawnień właściciela grupy, aby www-data miał dostęp do zapisu.

chmod g+w uploads
ls -l
drwxrws--- 2 eve      www-data   4096 Feb  5 22:52 uploads

Zaletą tej konfiguracji jest to, że staje się trudniejsze (ale nie niemożliwe *) dla innych użytkowników w systemie do węszenia, ponieważ tylko użytkownicy i właściciele grup mogą przeglądać katalog Twojej witryny. Jest to przydatne, jeśli masz tajne dane w swoich plikach konfiguracyjnych. Uważaj na swój umask! Jeśli utworzysz tutaj nowy plik, wartości uprawnień prawdopodobnie będą miały domyślną wartość 755. Możesz uruchomić umask 027, aby nowe pliki miały domyślną wartość 640 ( rw- r-- ---).

Obsługiwana przez grupę użytkowników

Jeśli za utrzymanie witryny odpowiada więcej niż jeden użytkownik, musisz utworzyć grupę, która będzie używana do przypisywania uprawnień. Dobrą praktyką jest utworzenie osobnej grupy dla każdej witryny i nadanie jej nazwy po tej stronie.

groupadd dev-fabrikam
usermod -a -G dev-fabrikam alice
usermod -a -G dev-fabrikam bob

W poprzednim przykładzie użyliśmy właściciela grupy, aby nadać uprawnienia Apache, ale teraz jest to używane dla grupy programistów. Ponieważ właściciel użytkownika nie jest już dla nas przydatny, ustawienie go jako root jest prostym sposobem na zapewnienie, że żadne uprawnienia nie zostaną ujawnione. Apache nadal potrzebuje dostępu, więc dajemy dostęp do odczytu reszcie świata.

chown -R root fabrikam.com
chgrp -R dev-fabrikam fabrikam.com
chmod -R 775 fabrikam.com
chmod g+s fabrikam.com
ls -l
drwxrwxr-x 2 root     dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

Jeśli masz foldery, które Apache może zapisywać, możesz ustawić Apache jako właściciela lub właściciela grupy. Tak czy inaczej, będzie miał dostęp do wszystkich potrzebnych danych. Osobiście wolę uczynić go właścicielem użytkownika, aby programiści mogli nadal przeglądać i modyfikować zawartość folderów przesyłania.

chown -R www-data uploads
ls -l
drwxrwxr-x 2 www-data     dev-fabrikam   4096 Feb  5 22:52 uploads

Chociaż jest to powszechne podejście, ma jednak pewną wadę. Ponieważ każdy inny użytkownik w systemie ma takie same uprawnienia do witryny, jak Apache, inni użytkownicy mogą łatwo przeglądać witrynę i czytać pliki, które mogą zawierać tajne dane, takie jak pliki konfiguracyjne.

Możesz mieć swoje ciasto i zjeść je

Można to później ulepszyć. Jest całkowicie legalne, że właściciel ma mniej uprawnień niż grupa, więc zamiast marnować właściciela użytkownika, przypisując go do konta root, możemy uczynić Apache właścicielem użytkownika w katalogach i plikach na twojej stronie. Jest to odwrócenie scenariusza pojedynczego opiekuna, ale działa równie dobrze.

chown -R www-data fabrikam.com
chgrp -R dev-fabrikam fabrikam.com
chmod -R 570 fabrikam.com
chmod g+s fabrikam.com
ls -l
dr-xrwx--- 2 www-data  dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

Jeśli masz foldery, które Apache musi zapisywać, możesz po prostu zmodyfikować wartości uprawnień dla właściciela użytkownika, aby www-data miał dostęp do zapisu.

chmod u+w uploads
ls -l
drwxrwx--- 2 www-data  dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

Jedną z rzeczy, na które należy uważać przy tym rozwiązaniu, jest to, że użytkownik nowych plików będzie pasował do twórcy, zamiast być ustawiony na www-data. Dlatego wszelkie nowe pliki, które utworzysz, nie będą czytelne dla Apache, dopóki ich nie przejrzysz.

* Separacja uprawnień Apache

Wspomniałem wcześniej, że inni użytkownicy mogą węszyć w Twojej witrynie bez względu na to, jakiego rodzaju uprawnień używasz. Domyślnie wszystkie procesy Apache działają jako ten sam użytkownik danych www, więc każdy proces Apache może odczytywać pliki ze wszystkich innych stron internetowych skonfigurowanych na tym samym serwerze, a czasem nawet dokonywać zmian. Każdy użytkownik, który może zmusić Apache do uruchomienia skryptu, może uzyskać taki sam dostęp, jak sam Apache.

Aby zwalczyć ten problem, istnieją różne podejścia do rozdzielania uprawnień w Apache. Jednak każde podejście ma różne wady wydajności i bezpieczeństwa. Moim zdaniem każda witryna o wyższych wymaganiach bezpieczeństwa powinna być uruchomiona na serwerze dedykowanym zamiast używać VirtualHosts na serwerze współdzielonym.

Dodatkowe uwagi

Nie wspominałem o tym wcześniej, ale zwykle jest to zła praktyka, gdy programiści edytują stronę bezpośrednio. W przypadku większych witryn znacznie lepiej jest mieć system wydań, który aktualizuje serwer WWW z zawartości systemu kontroli wersji. Podejście jednego opiekuna jest prawdopodobnie idealne, ale zamiast osoby masz zautomatyzowane oprogramowanie.

Jeśli Twoja witryna zezwala na przesyłanie plików, które nie muszą być obsługiwane, pliki te powinny być przechowywane gdzieś poza katalogiem głównym. W przeciwnym razie może się okazać, że ludzie pobierają pliki, które miały być tajne. Na przykład, jeśli pozwalasz uczniom na przesyłanie zadań, należy je zapisać w katalogu, który nie jest obsługiwany przez Apache. Jest to również dobre podejście do plików konfiguracyjnych zawierających sekrety.

W przypadku witryny o bardziej złożonych wymaganiach warto zapoznać się z listami kontroli dostępu . Umożliwiają one znacznie bardziej zaawansowaną kontrolę uprawnień.

Jeśli Twoja witryna ma złożone wymagania, możesz napisać skrypt, który konfiguruje wszystkie uprawnienia. Przetestuj to dokładnie, a następnie zachowaj bezpieczeństwo. Może być na wagę złota, jeśli z jakiegoś powodu będziesz musiał odbudować swoją stronę.

Zastanawiam się, dlaczego tak wiele osób używa (lub poleca) „inną” (o) część praw Linuksa do kontrolowania tego, co potrafi Apache (i / lub PHP). Ustawiając tę ​​prawą część na coś innego niż „0”, pozwalasz całemu światu na zrobienie czegoś w pliku / katalogu.

Moje podejście jest następujące:

• Tworzę dwóch oddzielnych użytkowników. Jeden dla dostępu SSH / SFTP (w razie potrzeby), który będzie właścicielem wszystkich plików, i jeden dla użytkownika PHP FastCGI (użytkownik, który witryna będzie działać jako). Nazwijmy tych użytkowników odpowiednio bob i bob-www .
• bob będzie miał pełne prawa ( rwx do folderów, rw- on files), aby mógł czytać i edytować całą stronę internetową.
• Proces PHP FastCGI musi rx uprawnienia folderów i r-- praw na plikach, za wyjątkiem ściśle określonych folderów, jak cache/i uploads/, gdzie konieczne jest również „zapis” pozwolenie. Aby dać PHP FastCGI tę możliwość, będzie działać jako bob-www , a bob-www zostanie dodany do automatycznie utworzonej grupy bob .
• Teraz upewniamy się, że właściciel i grupa wszystkich katalogów i plików to bob bob .
• Czegoś brakuje: nawet my używamy FastCGI, ale Apache nadal potrzebuje dostępu do odczytu, dla zawartości statycznej lub plików .htaccess, które spróbuje odczytać, jeśli AllowOverridejest ustawiony na coś innego niż None. Aby uniknąć używania o, część praw, dodam www-danych użytkownika do bob grupy.

Teraz:

• Aby kontrolować, co programista może zrobić, możemy bawić się u części praw (ale to poniższa uwaga).
• Aby kontrolować, co potrafią Apache i PHP, możemy grać z częścią g praw.
• Część o jest zawsze ustawiona na 0, więc nikt inny na serwerze nie może czytać ani edytować strony internetowej.
• Nie ma problemu, gdy użytkownik bob utworzy nowe pliki, ponieważ automatycznie będzie należeć do swojej głównej grupy ( bob ).

Jest to podsumowanie, ale w tej sytuacji bob ma prawo do SSH. Jeśli żaden użytkownik nie powinien mieć prawa do modyfikowania strony (np. Klient modyfikuje stronę tylko za pomocą panelu administracyjnego CMS i nie ma wiedzy o Linuksie), i tak stwórz dwóch użytkowników, ale daj /bin/falseteż powłokę dla boba , i wyłącz jego logowanie.

    adduser --home /var/www/bobwebsite --shell /bin/bash bob
    adduser --no-create-home --shell /bin/false --disabled-login --ingroup bob bob-www
    adduser www-data bob
    cd /var/www/bobwebsite
    chown -R bob:bob .
    find -type d -exec chmod 750 {} \;
    find -type f -exec chmod 640 {} \;

Uwaga: ludzie mają tendencję do zapominania, że ograniczenie ù (Właściciel) prawa jest większość czasu bezużyteczne i niepewny, ponieważ właściciel pliku można uruchomić chmodpolecenie, nawet te prawa są 000.

Powiedz mi, czy moje podejście ma pewne problemy z bezpieczeństwem, ponieważ nie jestem w 100% pewien, ale tego właśnie używam.

Myślę, że ta konfiguracja ma problem: gdy PHP / Apache utworzy nowy plik (np. Upload), będzie należeć do bob-www: bob i bob będzie mógł go tylko odczytać. Może setuid w katalogu może rozwiązać problem.

Biorąc pod uwagę pozycję Google w powyższej doskonałej odpowiedzi, myślę, że jest jedna rzecz, na którą należy zwrócić uwagę i nie mogę zostawić notatki po odpowiedzi.

Kontynuując przykład, jeśli planujesz używać www-data jako właściciela i dev-fabrikam jako grupy z 570 uprawnieniami do katalogu (lub pliku), ważne jest, aby pamiętać, że Linux ignoruje setuid , więc wszystkie nowe pliki będą własnością użytkownik, który je utworzył. Oznacza to, że po utworzeniu nowych katalogów i plików będziesz musiał użyć czegoś podobnego do:

chown -R www-data /newdirectory/
chmod -R 570 /newdirectory/

W Ubuntu 12.04 dla Rackspace OpenStack miałem dziwny problem, w którym nie mogłem uzyskać uprawnień 570 do pracy, dopóki nie zrestartowałem serwera, co magicznie naprawiło problem. Coraz częściej tracił włosy w porównaniu z tym pozornie prostym problemem ...

Idę z tą konfiguracją:

1. Wszystkie katalogi oprócz przesyła jeden zestaw do właściciela rooti grupy root, uprawnienia do 0755.
2. Wszystkie pliki ustawione na właściciela rooti grupę root, uprawnienia do 0644.
3. Przesyła katalog ustawiony na właściciela root, grupę www-data, uprawnienia do 1770. Lepki bit nie pozwala właścicielowi grupy na usunięcie ani zmianę nazwy katalogu i plików w nim zawartych.
4. Wewnątrz folderu przesyłania nowy katalog z www-datawłaścicielem użytkownika i grupą oraz 0700uprawnieniami dla każdego www-dataużytkownika, który przesyła pliki.
5. Konfiguracja Apache:

Odmów AllowOverridei Indexw katalogu uploads, aby Apache nie czytał .htaccessplików, a użytkownik Apache nie mógł indeksować zawartości folderu uploads:

<Directory /siteDir>
   Options -Indexes
</Directory>

<Directory /siteDir/uploadDir>
   AllowOverride none
</Directory>

6. php.inikonfiguracja:

open_basedir = /siteDir:/tmp:/usr/share/phpmyadmin
post_max_size = 5M
file_uploads = On
upload_max_filesize = 3M
max_file_uploads = 20

Przy tej konfiguracji www-dataużytkownik nie będzie mógł dostać się do katalogów innych niż siteDir/ /tmpi /usr/share/phpmyadmin. Możesz także kontrolować maksymalny rozmiar pliku, maksymalny rozmiar postu i maksymalny rozmiar plików do przesłania w tym samym żądaniu.

Jeśli masz użytkownika FTP o nazwie „leo”, musisz przesłać pliki do katalogu web example.com, a także potrzebujesz, aby użytkownik „apache” mógł tworzyć pliki uploa / session / cache w katalogu cache, a następnie wykonaj następujące czynności:

To polecenie przypisuje Leo jako właściciela i grupę jako apache do example.com, użytkownik apache jest częścią grupy apache, więc odziedziczy uprawnienia grupy apache

chown -R leo: apache example.com

Kolejne polecenie, które zapewnia odpowiednie pozwolenie i spełnia również obawy dotyczące bezpieczeństwa.

chmod -R 2774 przyklad.com

Tutaj pierwsza cyfra 2 dotyczy katalogu i gwarantuje, że każdy nowy plik pozostanie w tej samej grupie i uprawnieniach właściciela. 77 jest dla właściciela i grupy oznacza, że ​​mają pełny dostęp. 4 jest dla innych oznacza, że ​​mogą czytać tylko koryta.

poniższe informacje pomagają zrozumieć numery uprawnień

Number  Octal Permission Representation
0   No permission
1   Execute permission
2   Write permission
3   Execute and write permission: 1 (execute) + 2 (write) = 3
4   Read permission
5   Read and execute permission: 4 (read) + 1 (execute) = 5
6   Read and write permission: 4 (read) + 2 (write) = 6
7   All permissions: 4 (read) + 2 (write) + 1 (execute) = 7

IMO należy wziąć pod uwagę:

• czy ufasz procesowi, który czyta twoje pliki? na przykład. PHP?

Załóżmy, że masz serwer, na którym różne dane są testowane przez użytkownika.

Użytkownik „testowy” ma tam:

• jego dane w $HOMEDIR
• jego poczta w $MAIL
• jego dane do internetu w /var/www/test

Pomyślmy teraz o:

• aplikacja internetowa działa pod kontrolą testużytkownika (PHP-FPM) - może usunąć dowolny z jego plików!
• aplikacja internetowa działa w testgrupie (PHP-FPM) - może usuwać dowolne z jego plików, w których katalog ma „w” dla grupy, i może modyfikować dowolny plik, który ma „r” dla grupy; i nadal może je odczytać - na przykład twoje klucze ssh!

Załóżmy, że PHP jest błędne i czy wierzysz w to open_basedir? Czy korzystasz chrootz PHP? Czego nie chcesz, czy chcesz, aby indeksowało się przez cały system plików?

Twój proces aplikacji internetowej, np. PHP-FPM, a następnie powinien:

• ograniczyć się do określonej ścieżki przez chroot
• nie powinien działać na podstawie uprawnień głównego użytkownika lub grupy podstawowej właściciela danych

W ten sposób możesz:

• użytkownik testowy to: test:test
• użytkownik testowy należy do grupy drugorzędnej, np. test-www
• działa aplikacja internetowa (PHP-FPM) test-www:test-www
• użytkownik testowy, jeśli chce, aby aplikacja internetowa mogła odczytać jego pliki, wykona: chmod u=rwX,g=rX,o= /var/www/test/public
• użytkownik testowy, jeśli chce, aby aplikacja internetowa mogła zapisać w swojej internetowej ścieżce danych: chmod u=rwX,g=rwXs,o= /var/www/test/public/upload (w ten sposób aplikacja utworzy nowe pliki, ponieważ: test-www:test-www- będzie miała grupę test-www z powodu setgid w katalogu!)

Tak więc, jeśli proces aplikacji internetowej byłby fałszywy, po prostu czytałby określone pliki, które byłyby czytane grupowo, i byłby w stanie pisać uploadtylko do katalogu . Zdecydowanie poleciłbym mieć ten katalog uploadw systemie plików z noexec,nodev,nosuid mountopcjami i stale monitorować wszelkie nowe pliki bizzare w tym katalogu, a także monitorować wszelkie nowe procesy w test-wwwUID.

W systemie Linux można użyć ACL do lepszego dostrojenia uprawnień. Jeśli więcej niż jeden człowiek powinien przesyłać dane internetowe, lepiej byłoby oddzielić konto ludzkie od konta używanego do przesyłania plików danych internetowych, tj. aby utworzyć nowe konto np. test-upload, a użytkownik testowy zarządzałby kluczami ssh, aby ograniczyć, który człowiek może tam ssh / sftp. sshd_configzna ExposeAuthInfoopcje, dzięki czemu można go skonfigurować do rejestrowania, który klucz ssh został użyty do przesłania danych.

Naprawdę wątpię, aby większość usług hostingowych dbała o rozdzielenie uprawnień, kiedy piszą „bezpieczne” bez żadnych informacji o tym, co otrzymujesz, powiedziałbym, że kłamią.