Які дозволи повинні мати файли / папки мого веб-сайту на веб-сервері Linux?

Це канонічне запитання щодо дозволів файлів на веб-сервері Linux.

У мене на веб-сервері Linux працює Apache2, на якому розміщено кілька веб-сайтів. Кожен веб-сайт має власну папку в / var / www /.

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

Базовий каталог / var / www / належить root: root. Apache працює як www-data: www-data. Веб-сайт Fabrikam підтримують два розробники, Аліса та Боб. Обидва веб-сайти Contoso підтримує один розробник, Eve. Усі веб-сайти дозволяють користувачам завантажувати зображення. Якщо веб-сайт порушений, вплив повинен бути максимально обмеженим.

Я хочу знати найкращий спосіб налаштування дозволів, щоб Apache міг обслуговувати вміст, веб-сайт захищений від атак, а розробники все ще можуть вносити зміни. Один із веб-сайтів структурований так:

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

Як слід встановлювати дозволи для цих каталогів та файлів? Я десь читав, що ви ніколи не використовуєте 777 дозволів на веб-сайті, але не розумію, які проблеми можуть спричинити. У періоди зайнятості веб-сайт автоматично кешує деякі сторінки та зберігає результати в папці кешу. Весь вміст, поданий відвідувачами веб-сайту, зберігається у папці завантажень.

Вирішуючи, які дозволи використовувати, ви повинні точно знати, хто ваші користувачі та що їм потрібно. Веб-сервер взаємодіє з двома типами користувачів.

Аутентифіковані користувачі мають обліковий запис користувача на сервері і можуть мати певні привілеї. Зазвичай це включає системні адміністратори, розробники та облікові записи служб. Зазвичай вони вносять зміни в систему за допомогою SSH або SFTP.

Анонімні користувачі - відвідувачі вашого веб-сайту. Хоча вони не мають дозволу на прямий доступ до файлів, вони можуть надіслати запит на веб-сторінку, а веб-сервер діє від їх імені. Ви можете обмежити доступ анонімних користувачів, уважно ставлячись до того, які дозволи має процес веб-сервера. У багатьох дистрибутивах Linux Apache працює як www-dataкористувач, але він може бути різним. Використовуйте ps aux | grep httpdабо ps aux | grep apacheщоб побачити, що користувач Apache використовує у вашій системі.

Примітки щодо прав доступу до Linux

Linux та інші POSIX-сумісні системи використовують традиційні дозволи Unix. У Вікіпедії є чудова стаття про дозволи Filesystem, тому я не повторю все тут. Але є кілька речей, про які слід пам’ятати.

Біт виконання
інтерпретованих сценаріїв (наприклад, Ruby, PHP) працює нормально без дозволу на виконання. Тільки бінарні файли та сценарії оболонки потребують біт виконання. Щоб перейти (ввести) каталог, потрібно мати дозвіл на виконання цього каталогу. Цей веб-сервер потребує цього дозволу, щоб перелічити каталог або обслуговувати будь-які файли всередині нього.

Нові дозволи файлів за замовчуванням
Коли файл створюється, він зазвичай успадковує ідентифікатор групи того, хто його створив. Але іноді потрібно, щоб нові файли успадкували ідентифікатор групи папки, в якій вони створені, тож ви б увімкнули біт SGID у батьківській папці.

Значення дозволів за замовчуванням залежать від вашого umask. Umask віднімає дозволи з новостворених файлів, тому загальне значення 022 призводить до того, що файли створюються з 755. Під час співпраці з групою корисно змінити umask на 002, щоб створені вами файли могли бути змінені членами групи. І якщо ви хочете налаштувати дозволи завантажених файлів, вам потрібно змінити umask на apache або запустити chmod після завантаження файлу.

Проблема з 777

Коли ви перебуваєте на chmod 777своєму веб-сайті, у вас немає ніякої безпеки. Будь-який користувач у системі може змінити або видалити будь-який файл на вашому веб-сайті. Але якщо серйозніше, пам’ятайте, що веб-сервер діє від імені відвідувачів вашого веб-сайту, і тепер веб-сервер може змінити ті самі файли, що і виконуються. Якщо на вашому веб-сайті є якісь вразливості програмування, їх можна використовувати, щоб знекровити ваш веб-сайт, вставити фішинг-атаки або викрасти інформацію з вашого сервера без того, щоб ви ніколи про це знали.

Крім того, якщо ваш сервер працює на відомій порту (що повинно запобігати некористувальним користувачам нерестувати послуги прослуховування, які є доступними у всьому світі), це означає, що ваш сервер повинен бути запущений root (хоча будь-який нормальний сервер негайно випаде до менш привілейованого облікового запису, коли порт буде зв'язаний). Іншими словами, якщо ви використовуєте веб-сервер, де основний виконуваний файл є частиною контролю версій (наприклад, програма CGI), залишаючи свої дозволи (або, з цього приводу, дозволи довідника, що містить, оскільки користувач може перейменувати виконуваний файл) на рівні 777 дозволяє будь-якому користувачу запускати будь-який виконуваний файл як root.

Визначте вимоги

• Розробникам потрібен доступ для читання / запису до файлів, щоб вони могли оновити веб-сайт
• Розробникам потрібно читати / писати / виконувати в каталогах, щоб вони могли переглядати
• Apache потребує доступу для читання до файлів та інтерпретованих сценаріїв
• Apache потребує читання / виконання доступу до справних каталогів
• Apache потребує читання / запису / виконання доступу до каталогів для завантаженого вмісту

Обслуговується одним користувачем

Якщо за підтримку сайту відповідає лише один користувач, встановіть їх як власника користувача у каталозі веб-сайтів та надайте користувачеві повний дозвіл rwx. Apache все ще потребує доступу, щоб він міг обслуговувати файли, тому встановіть www-data як власника групи та надайте дозволу групи rx.

У вашому випадку Єва, чиє ім'я користувача eve, є єдиним користувачем, який підтримує 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

Якщо у вас є папки, які потрібно записувати Apache, ви можете просто змінити значення дозволу для власника групи, щоб www-data мали доступ до запису.

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

Перевага цієї конфігурації полягає в тому, що іншим користувачам у системі стає важче (але це не неможливо *), оскільки лише користувач та власники груп можуть переглядати каталог вашого веб-сайту. Це корисно, якщо у файлах конфігурації є секретні дані. Будьте уважні до свого умаска! Якщо ви створите тут новий файл, значення дозволу, ймовірно, становлять 755. Ви можете запустити umask 027так, що нові файли за замовчуванням становлять 640 ( rw- r-- ---).

Обслуговується групою користувачів

Якщо за підтримку сайту відповідає не один користувач, вам потрібно буде створити групу, яка використовуватиметься для призначення дозволів. Рекомендується створити окрему групу для кожного веб-сайту та назвати групу після цього веб-сайту.

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

У попередньому прикладі ми використовували власника групи, щоб надати привілеї Apache, але тепер це використовується для групи розробників. Оскільки власник користувача вже не корисний для нас, встановити його на root - це простий спосіб забезпечити те, що жодні привілеї не просочуються. Apache все ще потребує доступу, тому ми надаємо доступ для читання іншому світу.

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

Якщо у вас є папки, для яких Apache потрібно писати, ви можете зробити Apache або власником користувача, або власником групи. Так чи інакше, він матиме весь необхідний йому доступ. Особисто я вважаю за краще зробити його власником, щоб розробники могли переглядати та змінювати вміст завантажуваних папок.

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

Хоча це загальний підхід, є і зворотний бік. Оскільки кожен інший користувач у системі має ті ж привілеї до вашого веб-сайту, що й Apache, іншим користувачам легко переглядати ваш сайт та читати файли, які можуть містити секретні дані, наприклад ваші файли конфігурації.

Ви можете мати свій торт і з'їсти його теж

Це може бути покращено. Цілком законно, щоб власник мав менше привілеїв, ніж група, тому замість того, щоб витрачати власника користувача, призначивши його для root, ми можемо зробити Apache власником користувача у каталогах та файлах вашого веб-сайту. Це повернення сценарію єдиного технічного обслуговування, але воно працює однаково добре.

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

Якщо у вас є папки, які потрібно записувати Apache, ви можете просто змінити значення дозволу для власника користувача, щоб www-data мали доступ для запису.

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

При цьому слід бути обережним, що власник нових файлів користувача буде відповідати творцю, а не встановлювати його на www-data. Отже, будь-які нові файли, які ви створюєте, Apache не будуть читатими, поки ви їх не порушите.

* Розділення привілеїв Apache

Раніше я згадував, що насправді іншим користувачам можна проглядати ваш веб-сайт незалежно від того, якими привілеями ви користуєтесь. За замовчуванням всі процеси Apache працюють як один і той же користувач www-даних, тому будь-який процес Apache може читати файли з усіх інших веб-сайтів, налаштованих на одному сервері, а іноді навіть вносити зміни. Будь-який користувач, який може змусити Apache запустити сценарій, може отримати той самий доступ, що і сам Apache.

Для боротьби з цією проблемою існують різні підходи до поділу привілеїв в Apache. Однак кожен підхід має різні недоліки продуктивності та безпеки. На мою думку, будь-який сайт з більш високими вимогами до безпеки повинен працювати на спеціальному сервері, а не використовувати VirtualHosts на спільному сервері.

Додаткові міркування

Я раніше не згадував про це, але зазвичай це погана практика, щоб розробники редагували веб-сайт безпосередньо. Для великих сайтів вам набагато краще мати якусь систему випусків, яка оновлює веб-сервер із вмісту системи контролю версій. Підхід до єдиного технічного обслуговування, мабуть, ідеальний, але замість людини у вас є автоматизоване програмне забезпечення.

Якщо ваш веб-сайт дозволяє завантажувати файли, які не потрібно розміщувати, їх слід зберігати десь за межами кореня веб-сторінки. В іншому випадку ви можете виявити, що люди завантажують файли, які мали бути секретними. Наприклад, якщо ви дозволяєте студентам подавати завдання, вони повинні бути збережені в каталозі, який не обслуговується Apache. Це також хороший підхід для файлів конфігурації, які містять секрети.

Для веб-сайту з більш складними вимогами, можливо, ви захочете вивчити використання списків контролю доступу . Вони дозволяють набагато складніше контролювати привілеї.

Якщо ваш веб-сайт має складні вимоги, ви можете написати сценарій, який встановлює всі дозволи. Тестуйте його ретельно, а потім зберігайте. Це може вартувати ваги золота, якщо вам з якихось причин виникне необхідність відновити веб-сайт.

Мені цікаво, чому так багато людей використовують (або рекомендують) "іншу" (o) частину прав Linux для контролю того, що може робити Apache (та / або PHP). Встановивши цю праву частину на щось інше, ніж "0", ви просто дозволите всьому світу щось зробити з файлу / каталогу.

Мій підхід такий:

• Я створюю двох розділених користувачів. Один для доступу до SSH / SFTP (при необхідності), який буде володіти всіма файлами, і один для користувача PHP FastCGI (користувач, веб-сайт буде працювати як). Давайте назвемо цих користувачів відповідно bob та bob-www .
• bob матиме повні права ( rwx на папки, rw- на файли), так що він / вона може читати та редагувати весь веб-сайт.
• Процес PHP FastCGI потребує права rx на папки та r-- прав на файли, за винятком дуже специфічних папок, таких як cache/або uploads/, де також потрібен дозвіл на запис ". Щоб надати PHP FastCGI цю здатність, вона працюватиме як bob-www , а bob-www буде доданий до автоматично створеної групи bob .
• Тепер ми впевнені, що власник і група всіх каталогів і файлів є bob bob .
• Щось не вистачає: навіть ми використовуємо FastCGI, але Apache все ще потребує доступу для читання для статичного вмісту або файлів .htaccess, який він намагатиметься прочитати, якщо AllowOverrideвстановлено щось інше, ніж None. Щоб уникнути використання o частини прав, я додаю користувача www-data до групи bob .

Зараз:

• Щоб контролювати те, що може зробити розробник, ми можемо грати з частиною прав u (але це примітка нижче).
• Щоб контролювати те, що можуть робити Apache та PHP, ми можемо грати з g частиною прав.
• Про частини завжди встановлюється в 0, так що ніхто на сервері не може прочитати або змінити веб - сайт.
• Немає проблем, коли користувач bob створює нові файли, оскільки він автоматично належить до його основної групи ( bob ).

Це резюме, але в цій ситуації bob дозволений до SSH. Якщо не повинно бути жодного користувача, який може змінювати веб-сайт (наприклад, клієнт модифікує веб-сайт лише через адміністраторську панель CMS і не має знань Linux), все одно створіть двох користувачів, але також надайте /bin/falseяк оболонку для bob , і вимкнути його логін.

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

Примітка: люди, як правило, забувають, що обмеження прав u (власника) в більшості випадків марно і небезпечно, оскільки власник файлу може виконувати chmodкоманду, навіть права є 000.

Скажіть, чи є у мого підходу якісь проблеми безпеки, тому що я не впевнений на 100%, але це те, що я використовую.

Я думаю, що в цьому конфігурації є проблема: коли PHP / Apache створює новий файл (наприклад, завантаження), він буде належати bob-www: bob , і bob зможе його прочитати тільки. Можливо, налаштування в каталозі може вирішити проблему.

Враховуючи рейтинг google за вищезазначеною відмінною відповіддю, я думаю, що є одне, що слід зазначити, і я не можу залишити записку після відповіді.

Продовжуючи приклад, якщо ви плануєте використовувати www-data як власника та dev-fabrikam як групу з 570 дозволами в каталозі (або файлі), важливо зазначити, що Linux ігнорує setuid , тому всі нові файли будуть належати користувач, який їх створив. Це означає, що після створення нових каталогів та файлів вам доведеться використовувати щось подібне до:

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

У Ubuntu 12.04 для Rackspace OpenStack у мене виникла незвичайна проблема, в якій я не міг отримати дозволи 570 працювати, поки не перезавантажив сервер, який магічно виправив проблему. Втрачала волоски зі швидкістю у зв'язку з цим, здавалося б, простим питанням ....

Я збираюся з цією конфігурацією:

1. Усі довідники, за винятком завантажень одного набору для власника rootта групи root, дозволів на 0755.
2. Усі файли, встановлені власником rootі групою root, дозволу на 0644.
3. Завантажує каталог, встановлений власником root, групою www-data, дозволом на 1770. Клейкий біт не дозволяє власнику групи видаляти або перейменувати каталог і файли всередині.
4. Всередині папки завантажується новий каталог із www-dataвласником користувача та групи та 0700дозволами для кожного www-dataкористувача, який завантажує файли.
5. Конфігурація Apache:

Забороняти AllowOverrideта Indexв каталозі завантажень, щоб Apache не читав .htaccessфайли, а користувач Apache не міг індексувати вміст папки завантажень:

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

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

6. php.iniконфігурація:

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

При такій конфігурації www-dataкористувач не зможе потрапити до каталогів, окрім siteDir/ /tmpта /usr/share/phpmyadmin. Також ви можете контролювати максимальний розмір файлу, максимальний розмір публікації та максимальний розмір файлів для завантаження в одному запиті.

Якщо у вас є FTP-користувач під назвою "лео", вам потрібно завантажувати файли у веб-каталог example.com, а також потрібно, щоб ваш користувач "apache" мав змогу створювати файли uploa-файлів / сеансів / кешу в каталозі кешу, виконайте наступне:

Ця команда призначає leo власнику, а групу - apache до example.com, користувач apache є частиною групи apache, тому він буде успадковувати дозволи групи apache

chown -R leo: apache example.com

Ще одна команда, яка страхує правильний дозвіл і також виконує питання безпеки.

chmod -R 2774 example.com

Тут перший номер 2 призначений для каталогу та гарантує, що кожен створений новий файл буде залишатися в одній групі та власниках. 77 призначений для власника та групи означає, що вони мають повний доступ. 4 для інших означає, що вони можуть читати лише корита.

Далі корисно зрозуміти номери дозволів

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

ІМО потрібно враховувати:

• чи довіряєте ви процесу, який читає ваші файли? напр. PHP?

Припустимо, у вас є сервер, який містить різні дані під тестом користувача.

Користувач "тесту" має:

• його дані в $HOMEDIR
• його пошта в $MAIL
• його дані для веб в /var/www/test

Тепер давайте подумаємо про:

• веб-додаток працює під testкористувачем (PHP-FPM) - він може видалити будь-які його файли!
• веб-додаток працює під testгрупою (PHP-FPM) - він може видалити будь-який з його файлів, де каталог має "w" для групи, і може змінити будь-який файл, який має "r" для групи; і він ще може їх читати - наприклад, ваші ssh-ключі!

Припустимо, PHP баггі, і це, чи довіряєте ви цьому open_basedir? У вас chrootпроцес PHP? Що ви цього не робите, чи хочете, щоб вона проскакувала через всю файлову систему?

Ваш веб-додаток, наприклад, PHP-FPM, тоді повинен:

• бути обмеженим певним шляхом через chroot
• не має працювати за дозволом основного користувача власника даних або первинної групи

Таким чином ви можете зробити:

• Користувач тесту: test:test
• Користувач тесту перебуває у вторинній групі, наприклад. test-www
• веб-додаток (PHP-FPM) працює під test-www:test-www
• перевірити користувача, якщо він хоче, щоб веб-додаток міг читати його файли: chmod u=rwX,g=rX,o= /var/www/test/public
• тестовий користувач, якщо він хоче, щоб веб-додаток міг записати у свій шлях веб-даних: chmod u=rwX,g=rwXs,o= /var/www/test/public/upload (таким чином додаток створить нові файли у вигляді: test-www:test-www- у нього буде тестова група www через setgid в каталозі!)

Таким чином, якщо процес веб-додатків був блудним, він би просто читав конкретні файли, які мали б групову читання, і він був би в змозі записати uploadлише в dir. Я настійно рекомендую мати цей uploaddir у файловій системі з noexec,nodev,nosuid mountпараметрами та постійно контролювати будь-які нові файли bizzare у цьому каталозі, а також слідкувати за будь-якими новими процесами в test-wwwuid.

У Linux можна використовувати ACL для кращої настройки дозволів. Якщо для завантаження веб-даних має бути більше однієї людини, було б краще розділити обліковий запис людини від облікового запису, який використовується для завантаження файлів веб-даних, тобто. створити новий рахунок, наприклад. test-upload, і тестовий користувач керує ssh клавішами, щоб обмежити, хто може там ssh / sftp. sshd_configзнає ExposeAuthInfoваріанти, таким чином він може бути налаштований для реєстрації, який ssh ​​ключ використовувався для завантаження даних.

Я дійсно сумніваюся, що більшість веб-служб хостингу піклуються про розмежування привілеїв, коли вони пишуть "безпечно" без будь-якої інформації, що ви отримуєте, я б сказав, що вони брешуть.