Какие разрешения должны иметь файлы / папки моего веб-сайта на веб-сервере Linux?

Решая, какие разрешения использовать, вы должны точно знать, кто ваши пользователи и что им нужно. Веб-сервер взаимодействует с двумя типами пользователей.

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

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

Примечания к разрешениям Linux

Linux и другие POSIX-совместимые системы используют традиционные разрешения unix. В Википедии есть отличная статья о Разрешения файловой системы так что я не буду здесь все повторять. Но есть несколько вещей, о которых вам следует знать.

Бит выполнения
Интерпретируемые скрипты (например, Ruby, PHP) работают нормально без разрешения на выполнение. Бит выполнения нужен только для двоичных файлов и сценариев оболочки. Чтобы пройти (войти) в каталог, вам необходимо иметь разрешение на выполнение в этом каталоге. Веб-серверу требуется это разрешение, чтобы отображать каталог или обслуживать любые файлы внутри него.

Разрешения для новых файлов по умолчанию
Когда файл создается, он обычно наследует идентификатор группы того, кто его создал. Но иногда вы хотите, чтобы новые файлы наследовали идентификатор группы папки, в которой они созданы, поэтому вы можете включить бит SGID в родительской папке.

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

Проблема с 777

Когда ты chmod 777 ваш сайт, у вас нет никакой безопасности. Любой пользователь в системе может изменить или удалить любой файл на вашем сайте. Но если серьезно, помните, что веб-сервер действует от имени посетителей вашего веб-сайта, и теперь веб-сервер может изменять те же файлы, которые он выполняет. Если на вашем веб-сайте есть программные уязвимости, они могут быть использованы для искажения вашего веб-сайта, внедрения фишинговых атак или кражи информации с вашего сервера без вашего ведома.

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

Определите требования

• Разработчикам необходим доступ для чтения / записи к файлам, чтобы они могли обновлять веб-сайт.
• Разработчикам нужно читать / писать / выполнять в каталогах, чтобы они могли просматривать
• Apache необходим доступ для чтения к файлам и интерпретируемым скриптам
• Apache требуется доступ для чтения / выполнения к обслуживаемым каталогам
• Apache требуется доступ на чтение / запись / выполнение к каталогам для загруженного контента

Поддерживается одним пользователем

Если только один пользователь отвечает за обслуживание сайта, установите его в качестве владельца пользователя в каталоге веб-сайта и предоставьте пользователю полные разрешения rwx. Apache все еще нужен доступ, чтобы он мог обслуживать файлы, поэтому установите www-data в качестве владельца группы и дайте группе разрешения r-x.

В вашем случае Ева, имя пользователя которой может быть 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-data, поэтому любой процесс Apache может читать файлы со всех других веб-сайтов, настроенных на том же сервере, а иногда даже вносить изменения. Любой пользователь, который может заставить Apache запускать скрипт, может получить тот же доступ, что и сам Apache.

Для борьбы с этой проблемой существуют различные подходы к разделение привилегий в Apache. Однако каждый подход имеет свои недостатки в производительности и безопасности. На мой взгляд, любой сайт с более высокими требованиями к безопасности должен запускаться на выделенном сервере вместо использования VirtualHosts на общем сервере.

Дополнительные соображения

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

Если на вашем веб-сайте разрешены загрузки, которые не нужно обслуживать, эти загрузки следует хранить где-то за пределами корневого веб-сайта. В противном случае вы можете обнаружить, что люди загружают файлы, которые должны были быть секретными. Например, если вы разрешаете учащимся отправлять задания, они должны быть сохранены в каталог, который не обслуживается Apache. Это также хороший подход для файлов конфигурации, содержащих секреты.

Для веб-сайта с более сложными требованиями вы можете изучить использование Списки контроля доступа. Это обеспечивает более сложный контроль над привилегиями.

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

Мне интересно, почему так много людей используют (или рекомендуют) «другую» (o) часть прав Linux для управления тем, что может делать Apache (и / или PHP). Установив для этой правой части значение, отличное от «0», вы просто позволяете всему миру что-то делать с файлом / каталогом.

Мой подход следующий:

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

Сейчас:

• Чтобы контролировать, что может делать разработчик, мы можем поиграть с ты часть прав (но это примечание ниже).
• Чтобы контролировать, что могут делать Apache и PHP, мы можем поиграть с грамм часть прав.
• В о part всегда имеет значение 0, поэтому никто другой на сервере не может читать или редактировать веб-сайт.
• Нет проблем, когда боб пользователь создает новые файлы, так как он автоматически будет принадлежать его основной группе (боб).

Это резюме, но в этой ситуации боб разрешено SSH. Если пользователю не должно быть разрешено изменять веб-сайт (например, клиент изменяет веб-сайт только через панель администратора CMS и не имеет знаний о Linux), все равно создайте двух пользователей, но предоставьте /bin/false как оболочка для боб также и отключите его логин.

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

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

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

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

Учитывая рейтинг 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-пользователь с именем «leo», которому необходимо загрузить файлы в веб-каталог example.com, и вам также требуется, чтобы ваш пользователь «apache» мог создавать файлы uploa-files / sessions / cache в каталоге cache, выполните следующие действия:

Эта команда назначает 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

IMO следует учитывать:

• вы доверяете процессу, который читает ваши файлы? например. 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 - у него будет группа test-www из-за setgid в каталоге!)

Таким образом, если процесс веб-приложения будет поддельным, он просто будет читать определенные файлы, для которых будет выполняться групповое чтение, и сможет записывать в upload только реж. Я настоятельно рекомендую иметь это upload dir в файловой системе с noexec,nodev,nosuid mount параметры и иметь постоянный мониторинг любых новых файлов bizzare в этом каталоге, а также отслеживать любые новые процессы в test-www uid.

В Linux можно использовать ACL для лучшей настройки разрешений. Если более одного человека должны загружать веб-данные, было бы лучше отделить учетную запись человека от учетной записи, используемой для загрузки файлов веб-данных, т. Е. для создания новой учетной записи, например. test-upload, а тестовый пользователь будет управлять ключами ssh, чтобы ограничить доступ пользователей к ssh / sftp. sshd_config знает ExposeAuthInfo options, таким образом, его можно настроить для регистрации того, какой ключ ssh использовался для загрузки данных.

Я действительно сомневаюсь, что большинство сервисов веб-хостинга заботятся о разделении привилегий, когда они пишут «безопасно» без какой-либо информации, что вы получаете, я бы сказал, что они лгут.