Jaká oprávnění by měly mít soubory/složky mých webových stránek na webovém serveru Linux?

Řešení 1:

Když se rozhodujete, jaká oprávnění použít, musíte přesně vědět, kdo jsou vaši uživatelé a co potřebují. Webový server komunikuje se dvěma typy uživatelů.

Ověřeno uživatelé mají na serveru uživatelský účet a mohou jim být poskytnuta specifická oprávnění. To obvykle zahrnuje systémové administrátory, vývojáře a servisní účty. Obvykle provádějí změny v systému pomocí SSH nebo SFTP.

Anonymní uživatelé jsou návštěvníci vašeho webu. Přestože nemají oprávnění k přímému přístupu k souborům, mohou požádat o webovou stránku a webový server jedná jejich jménem. Přístup anonymních uživatelů můžete omezit tím, že budete dávat pozor na to, jaká oprávnění má proces webového serveru. V mnoha distribucích Linuxu běží Apache jako www-data uživatel, ale může to být jinak. Použijte ps aux | grep httpd nebo ps aux | grep apache abyste viděli, jaký uživatel Apache ve vašem systému používá.

Poznámky k linuxovým oprávněním

Linux a další systémy kompatibilní s POSIX používají tradiční unixová oprávnění. Na Wikipedii je vynikající článek o oprávněních k souborovému systému, takže zde nebudu vše opakovat. Ale je pár věcí, kterých byste si měli být vědomi.

Prováděcí bit
Interpretované skripty (např. Ruby, PHP) fungují dobře i bez povolení ke spuštění. Spouštěcí bit potřebují pouze binární soubory a skripty shellu. Abyste mohli procházet (vstupovat) do adresáře, musíte mít v tomto adresáři oprávnění ke spuštění. Webový server potřebuje toto oprávnění, aby mohl vypsat adresář nebo obsluhovat jakékoli soubory v něm.

Výchozí nová oprávnění k souboru
Když je soubor vytvořen, obvykle zdědí ID skupiny toho, kdo jej vytvořil. Někdy však chcete, aby nové soubory zdědily ID skupiny složky, ve které byly vytvořeny, takže byste v nadřazené složce povolili bit SGID.

Výchozí hodnoty oprávnění závisí na vašem umasku. Umask odečítá oprávnění od nově vytvořených souborů, takže společná hodnota 022 má za následek, že soubory jsou vytvářeny s 755. Při spolupráci se skupinou je užitečné změnit umask na 002, aby soubory, které vytvoříte, mohli členové skupiny upravovat. A pokud chcete upravit oprávnění nahraných souborů, musíte buď změnit umask pro apache, nebo po nahrání souboru spustit chmod.

Problém s 777

Když chmod 777 vaše webové stránky, nemáte žádné zabezpečení. Každý uživatel v systému může změnit nebo smazat jakýkoli soubor na vašem webu. Ale vážněji si uvědomte, že webový server jedná jménem návštěvníků vašeho webu a webový server je nyní schopen měnit tytéž soubory, které spouští. Pokud jsou na vašem webu nějaké chyby zabezpečení, lze je zneužít k znehodnocení vašeho webu, vložení phishingových útoků nebo ke krádeži informací z vašeho serveru, aniž byste o tom věděli.

Kromě toho, pokud váš server běží na dobře známém portu (který by měl zabránit uživatelům bez oprávnění root vytvářet naslouchací služby, které jsou přístupné celému světu), znamená to, že váš server musí být spuštěn uživatelem root (ačkoli každý rozumný server okamžitě přestane fungovat). na méně privilegovaný účet, jakmile je port vázán). Jinými slovy, pokud provozujete webový server, kde je hlavní spustitelný soubor součástí správy verzí (např. aplikace CGI), ponecháváte jeho oprávnění (nebo v tomto případě oprávnění obsahujícího adresáře, protože uživatel může přejmenovat spustitelný soubor) na 777 umožňuje jakékoli uživateli spustit jakýkoli spustitelný jako root.

Definujte požadavky

• Vývojáři potřebují přístup pro čtení a zápis k souborům, aby mohli aktualizovat web
• Vývojáři potřebují číst/zapisovat/spouštět adresáře, aby mohli procházet.
• Apache potřebuje přístup pro čtení k souborům a interpretovaným skriptům
• Apache potřebuje přístup ke čtení/spouštění k obsluhovatelným adresářům
• Apache potřebuje přístup ke čtení/zápisu/spouštění k adresářům pro nahraný obsah

Spravováno jedním uživatelem

Pokud je za údržbu webu zodpovědný pouze jeden uživatel, nastavte jej jako vlastníka uživatele v adresáři webu a udělte uživateli plná oprávnění rwx. Apache stále potřebuje přístup, aby mohl obsluhovat soubory, takže nastavte www-data jako vlastníka skupiny a udělte skupině oprávnění r-x.

Ve vašem případě Eva, jejíž uživatelské jméno může být eve , je jediným uživatelem, který spravuje 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

Pokud máte složky, do kterých musí Apache zapisovat, stačí upravit hodnoty oprávnění pro vlastníka skupiny tak, aby www-data měla přístup pro zápis.

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

Výhodou této konfigurace je, že pro ostatní uživatele v systému je obtížnější (ale ne nemožné*) šmírovat, protože adresář vašeho webu mohou procházet pouze vlastníci uživatelů a skupin. To je užitečné, pokud máte v konfiguračních souborech tajná data. Dávejte pozor na svůj umask! Pokud zde vytvoříte nový soubor, budou pravděpodobně výchozí hodnoty oprávnění 755. Můžete spustit umask 027 takže nové soubory mají výchozí hodnotu 640 (rw- r-- --- ).

Spravováno skupinou uživatelů

Pokud je za údržbu webu zodpovědný více než jeden uživatel, budete muset vytvořit skupinu, kterou budete používat pro přidělování oprávnění. Je dobrým zvykem vytvořit samostatnou skupinu pro každý web a pojmenovat skupinu podle tohoto webu.

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

V předchozím příkladu jsme použili vlastníka skupiny k udělení oprávnění Apache, ale nyní se to používá pro skupinu vývojářů. Vzhledem k tomu, že vlastník uživatele už pro nás není užitečný, nastavení na root je jednoduchý způsob, jak zajistit, že nebudou unikat žádná oprávnění. Apache stále potřebuje přístup, takže poskytujeme přístup ke čtení zbytku světa.

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

Pokud máte složky, do kterých musí být možné zapisovat pomocí Apache, můžete Apache nastavit jako vlastníka uživatele nebo vlastníka skupiny. V každém případě bude mít veškerý přístup, který potřebuje. Osobně dávám přednost tomu, aby byl vlastníkem uživatele, aby vývojáři mohli stále procházet a upravovat obsah složek pro nahrávání.

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

Přestože se jedná o běžný přístup, má to své stinné stránky. Protože každý další uživatel v systému má stejná oprávnění k vašemu webu jako Apache, je pro ostatní uživatele snadné procházet váš web a číst soubory, které mohou obsahovat tajná data, jako jsou vaše konfigurační soubory.

Můžete si dát svůj dort a také ho sníst

Toto lze dále vylepšit. Je naprosto legální, aby vlastník měl menší oprávnění než skupina, takže místo toho, abychom plýtvali vlastníkem uživatele tím, že jej přiřadíme rootovi, můžeme Apache učinit vlastníkem uživatele v adresářích a souborech na vašem webu. Toto je obrácení scénáře jednoho správce, ale funguje stejně dobře.

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

Pokud máte složky, do kterých musí Apache zapisovat, stačí upravit hodnoty oprávnění pro vlastníka uživatele tak, aby www-data měla přístup pro zápis.

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

Jedna věc, na kterou je třeba dávat pozor u tohoto řešení, je, že uživatel, který je vlastníkem nových souborů, bude odpovídat tvůrci, místo aby byl nastaven na www-data. Takže žádné nové soubory, které vytvoříte, nebude Apache čitelný, dokud je nezvolíte.

*Oddělení oprávnění Apache

Již dříve jsem zmínil, že je skutečně možné, aby ostatní uživatelé slídili po vašem webu bez ohledu na to, jaká oprávnění používáte. Ve výchozím nastavení běží všechny procesy Apache jako stejný uživatel www-data, takže jakýkoli proces Apache může číst soubory ze všech ostatních webových stránek nakonfigurovaných na stejném serveru a někdy dokonce provádět změny. Každý uživatel, který dokáže přimět Apache ke spuštění skriptu, může získat stejný přístup, jaký má samotný Apache.

Pro boj s tímto problémem existují různé přístupy k oddělení privilegií v Apache. Každý přístup však přináší různé nedostatky v oblasti výkonu a zabezpečení. Podle mého názoru by každý web s vyššími požadavky na zabezpečení měl být provozován na dedikovaném serveru namísto používání VirtualHosts na sdíleném serveru.

Další informace

Nezmínil jsem se o tom dříve, ale obvykle je špatný postup, když vývojáři upravují web přímo. Pro větší weby je mnohem lepší mít nějaký systém vydání, který aktualizuje webový server z obsahu systému správy verzí. Přístup jediného správce je pravděpodobně ideální, ale místo osoby máte automatizovaný software.

Pokud vaše webové stránky umožňují nahrávání, která není třeba poskytovat, měla by být tato nahrávání uložena někde mimo kořen webu. V opačném případě můžete zjistit, že lidé stahují soubory, které byly zamýšleny jako tajné. Pokud například studentům povolíte odevzdávat úkoly, měly by být uloženy do adresáře, který neobsluhuje Apache. Toto je také dobrý přístup pro konfigurační soubory, které obsahují tajemství.

U webových stránek se složitějšími požadavky se možná budete chtít podívat na používání seznamů řízení přístupu. Ty umožňují mnohem sofistikovanější kontrolu oprávnění.

Pokud má váš web složité požadavky, možná budete chtít napsat skript, který nastaví všechna oprávnění. Důkladně to otestujte a poté uschovejte. Mohlo by to mít cenu zlata, pokud byste někdy z nějakého důvodu potřebovali přestavět svůj web.

Řešení 2:

Zajímalo by mě, proč tolik lidí používá (nebo doporučuje) "jinou" (o) část práv Linuxu k ovládání toho, co umí Apache (a/nebo PHP). Nastavením této pravé části na něco jiného než "0" jen umožníte celému světu, aby se souborem/adresářem něco dělal.

Můj přístup je následující:

• Vytvářím dva oddělené uživatele. Jeden pro přístup SSH/SFTP (v případě potřeby), který bude vlastnit všechny soubory, a jeden pro uživatele PHP FastCGI (uživatel, pod kterým poběží web). Říkejme těmto uživatelům respektive bobe a bob-www .
• bobe bude mít plná práva (rwx ve složkách, rw- o souborech), aby mohl číst a upravovat celý web.
• Proces PHP FastCGI potřebuje r-x práva na složky a r-- práva na soubory, kromě velmi specifických složek jako cache/ nebo uploads/ , kde je také potřeba oprávnění k zápisu. Chcete-li dát PHP FastCGI tuto schopnost, poběží jako bob-www a bob-www bude přidán do automaticky vytvořeného bob skupina.
• Nyní se ujistíme, že vlastník a skupina všech adresářů a souborů jsou bob bob .
• Něco chybí:i když používáme FastCGI, ale Apache stále potřebuje přístup pro čtení pro statický obsah nebo soubory .htaccess, které se pokusí přečíst, pokud AllowOverride je nastaveno na něco jiného než None . Chcete-li se vyhnout použití o součástí práv přidávám www-data uživateli bob skupina.

Nyní:

• Chceme-li ovládat, co může vývojář dělat, můžeme si pohrát s u část práv (ale to je poznámka níže).
• Chceme-li ovládat, co Apache a PHP umí, můžeme si pohrát s g součástí práv.
• o část je vždy nastavena na 0, takže nikdo jiný na serveru nemůže web číst ani upravovat.
• Není žádný problém, když bobe uživatel vytváří nové soubory, protože budou automaticky patřit do jeho hlavní skupiny (bob ).

Toto je rekapitulace, ale v této situaci bobe má povoleno SSH. Pokud by žádný uživatel neměl mít právo upravovat web (např. zákazník upravuje web pouze prostřednictvím panelu CMS admin a nemá znalosti Linuxu), vytvořte dva uživatele, ale uveďte /bin/false jako shell pro boba také a zakázat jeho přihlášení.

    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 {} \;

Poznámka: lidé mají tendenci zapomínat na omezení u práva (vlastníka) jsou většinou k ničemu a nejsou bezpečná, protože vlastník souboru může spustit chmod i práva jsou 000.

Řekněte mi, jestli má můj přístup nějaké bezpečnostní problémy, protože si nejsem 100% jistý, ale právě to používám.

Myslím, že tato konfigurace má problém:když PHP/Apache vytvoří nový soubor (např. upload), bude patřit bob-www:bob a bobe bude moci pouze číst. Možná setuid v adresáři může problém vyřešit.

Řešení 3:

Vzhledem k hodnocení google na výše uvedené vynikající odpovědi si myslím, že je tu jedna věc, kterou je třeba poznamenat, a zdá se, že po odpovědi nemohu zanechat poznámku.

Pokračujeme-li v příkladu, pokud plánujete používat www-data jako vlastníka a dev-fabrikam jako skupinu s oprávněními 570 k adresáři (nebo souboru), je důležité si uvědomit, že Linux ignoruje setuid , takže všechny nové soubory budou ve vlastnictví uživatele, který je vytvořil. To znamená, že po vytvoření nových adresářů a souborů budete muset použít něco podobného jako:

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

V Ubuntu 12.04 pro Rackspace OpenStack jsem měl zvláštní problém, kdy jsem nemohl získat oprávnění 570 k práci, dokud jsem nerestartoval server, což problém magicky vyřešilo. Kvůli zdánlivě jednoduchému problému padaly vlasy stále častěji...

Řešení 4:

Pokračuji v této konfiguraci:

1. Všechny adresáře kromě nahrání jedné sady vlastníkovi root a skupina root , oprávnění k 0755 .
2. Všechny soubory nastaveny na vlastníka root a skupina root , oprávnění k 0644 .
3. Adresář pro nahrávání je nastaven na vlastníka root , skupina www-data , oprávnění k 1770 . Sticky bit neumožňuje vlastníkovi skupiny odstranit nebo přejmenovat adresář a soubory uvnitř.
4. Uvnitř složky pro nahrávání je nový adresář s www-data uživatel a skupina vlastníka a 0700 oprávnění pro každé www-data uživatele, který nahrává soubory.
5. Konfigurace Apache:

Zamítnout AllowOverride a Index v adresáři uploads, aby Apache nečetl .htaccess a uživatel Apache nemůže indexovat obsah složky pro nahrávání:

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

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

6. php.ini konfigurace:

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

S touto konfigurací www-data uživatel se nebude moci dostat do jiných adresářů než siteDir/ /tmp a /usr/share/phpmyadmin . Můžete také ovládat maximální velikost souboru, maximální velikost příspěvku a maximální počet souborů k nahrání ve stejné žádosti.

Řešení 5:

Pokud uživatel FTP s názvem „leo“ potřebuje nahrát soubory do webového adresáře example.com a také požadujete, aby uživatel „apache“ mohl vytvářet soubory uploa-files/sessions/cache v adresáři cache, postupujte následovně:

Tento příkaz přiřadí lea jako vlastníka a skupinu jako apache k example.com, uživatel apache je součástí skupiny apache, takže zdědí oprávnění skupiny apache

chown -R leo:apache example.com

Další příkaz, který zajišťuje správná oprávnění a také naplňuje bezpečnostní požadavky.

chmod -R 2774 example.com

Zde první číslo 2 je pro adresář a zajišťuje, že každý nově vytvořený soubor zůstane ve stejné skupině a oprávnění vlastníka. 77 je pro vlastníka a skupinu znamená, že mají plný přístup. 4 pro ostatní znamená, že mohou číst pouze prostřednictvím.

následující je užitečné pro pochopení čísel oprávnění

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