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


275
2018-02-06 01:50


Источник


Это должно быть канонический ответьте на все вопросы, которые мы получаем о разрешениях на веб-сайт. - Nic
«Я где-то читал, что вы никогда не должны использовать 777 разрешений на веб-сайте, но я не понимаю ...» - тогда читатель сможет понять или, по крайней мере, сравнить здесь достоинства ответов? Любое решение должно основываться на конкретных требованиях - требования здесь недостаточно конкретны (какова модель угрозы) - symcbean
Мне нравится, что вы спрашиваете об Apache, но используете домены, которые Microsoft обычно использует в качестве примеров. - gWaldo
Также см Каков наилучший способ обработки разрешений для www-данных apache2 в / var / www? - Gareth
Вы можете обратиться сюда для получения полной информации о разрешении, которое требуется разместить на файлах и папках веб-сайта в Linux serverfault.com/questions/124800/...


Ответы:


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

Заверенные пользователи имеют учетную запись пользователя на сервере и могут быть предоставлены с определенными привилегиями. Обычно это включает системных администраторов, разработчиков и учетных записей служб. Обычно они вносят изменения в систему с использованием 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-данные как владелец группы и предоставляйте права группы r-x.

В вашем случае Eve, чье имя пользователя может быть 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-данные имели доступ на запись.

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

Преимущество этой конфигурации заключается в том, что для других пользователей в системе становится сложнее (но не невозможно), так как только пользователи и владельцы групп могут просматривать ваш каталог веб-сайта. Это полезно, если у вас есть секретные данные в файлах конфигурации. Будьте осторожны с вашим umask! Если вы создадите новый файл здесь, значения разрешений, вероятно, будут по умолчанию равными 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-данные имели доступ на запись.

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. Это также хороший подход для файлов конфигурации, содержащих секреты.

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

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


308
2018-02-06 01:50



«chmod -R 775 fabrikam.com». Очень мало файлов на большинстве веб-сайтов должно быть исполняемым; например, php-скрипт может быть 0640, пока веб-сервер может их прочитать. chmod -R a + X fabrikam.com предоставит исполняемые права всем только по каталогам.
красивое описание! - RNA
Заметьте, что Apache работает как пользователь apache на основе систем Red Hat. - Michael Hampton♦
Это превосходно, но я не понял одну вещь: я не понимаю цели или преимущества стратегии создания apache пользователем / владельцем каталога файла, если он уже имеет групповое владение над файлом. - idiotprogrammer
Это отличный пост. Вот мой вклад: недостаток использования www-данных в качестве владельца и dev-fabrikam как группы (упоминается в Вы можете получить свой торт и съесть его тоже также применяется (в обратном порядке) к сценарию, предложенному в Поддерживается одним пользователем, В этом случае, всякий раз, когда Apache создает папку или файл, у пользователя нет доступа к нему, поэтому файлы должны быть возвращены исходному пользователю. Я не обновил ответ, так как я не уверен на 100% в своем заявлении. Я предпочел бы, чтобы другие подтвердили это, прежде чем исправлять ответ.


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

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

  • Я создаю двух отдельных пользователей. Один для доступа SSH / SFTP (если необходимо), который будет владеть всеми файлами, и один для пользователя PHP FastCGI (пользователь, на котором будет работать веб-сайт). Давайте назовем этих пользователей соответственно боб а также боб-WWW,
  • боб будут иметь полные права (RWX по папкам, rw- на файлы), чтобы он мог читать и редактировать весь сайт.
  • Процесс PHP FastCGI требует г-х права на папки и р-- права на файлы, за исключением очень конкретных папок, таких как cache/ или uploads/, где также требуется разрешение на запись. Чтобы дать PHP FastCGI эту возможность, она будет работать как боб-WWW, а также боб-WWW будет добавлено автоматически созданное боб группа.
  • Теперь мы убеждаемся, что владелец и группа всех каталогов и файлов Боб Боб,
  • Что-то не хватает: даже мы используем FastCGI, но для Apache по-прежнему нужен доступ для чтения, для статического контента или файлов .htaccess, которые он попытается прочитать, если AllowOverride установлено на что-то еще, чем None, Чтобы избежать использования о часть прав, я добавляю WWW-данные пользователя к боб группа.

Теперь:

  • Чтобы контролировать то, что может сделать разработчик, мы можем играть с U часть прав (но это примечание ниже).
  • Чтобы контролировать, что могут делать 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 {} \;

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

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

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


13
2017-07-19 21:42



Linux игнорирует setuid, Новые файлы всегда принадлежат создателю. - Paul
Я ничего не понимаю. Это, похоже, не отражает ситуацию, когда все больше разработчиков работают на веб-сайте, поскольку единственным пользователем является bob, Как ты с этим справляешься? Например. через ssh, оба пользователя регистрируются как bob. bob (1) чувствует, что он / она не может запомнить пароль и изменяет его на другой, но все же защищен. bob (2) пытается войти в следующий раз, и он / она не может. - n611x007
@naxa Любая незначительно хорошая система никогда не должна иметь ни одного из разработчиков, непосредственно изменяющих сайт. В идеале веб-сайт находится под контролем версий, так что учетная запись пользователя «bob» автоматически запускает и развертывает каждую (стабильную) версию. Таким образом, разработчики делают разработку за пределами предприятия, а изменения развертываются после их перемещения на сервер развертывания. «bob» - системный пользователь, который должен иметь очень ограниченные сетевые разрешения, которые не включают удаленный вход в систему; iptables на самом деле позволяет вам фильтровать по UID для таких вещей. - Parthian Shot
«Мне интересно, почему так много людей используют (или рекомендуют)« другую »(о) часть» - тогда, возможно, вы должны были разместить это как вопрос, а не ответ. Нередко можно преднамеренно запустить веб-сервер (как наиболее уязвимую часть системы) с самым низким уровнем привилегий, в то время как поддержка, разработка, учетные записи администратора также требуют другого доступа - symcbean


Учитывая рейтинг google на вышеупомянутом отличном ответе, я думаю, что есть одна вещь, которую следует отметить, и я не могу оставить комментарий после ответа.

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

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

В Ubuntu 12.04 для Rackspace OpenStack у меня была странная проблема, когда я не мог получить разрешения 570 для работы до тех пор, пока не перезагрузил сервер, что волшебным образом устранило проблему. Постепенно терял волосы по этой, казалось бы, простой проблеме ....


9
2018-01-13 22:03



Пожалуйста, пусть это будет googled: в Raspbian (ака на малине pi, если вы хотите изменить право собственности на / var / www под lighttpd (или другим веб-браузером), вы ДОЛЖНЫ перезагружаться. - gbronner
@gbronner Если это сложная проблема, чтобы найти решение, вы можете рассмотреть вопрос о публикации в качестве вопроса и дать ответ на вопрос. Тем не менее, это, вероятно, более уместно на другом сайте SE Q & A. Мое предположение Unix & Linux может быть хорошим местом для этого. - Paul
Также есть raspberrypi.stackexchange.com; кажется, что сайты SE немного фрагментируют знания. - gbronner
@gbronner lol. Я не знал об этом! Тег Raspbian на U & L имеет примерно 120 вопросов. - Paul


Я собираюсь с этой конфигурацией:

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

Отрицать AllowOverride а также Index в каталоге uploads, чтобы Apache не читал .htaccess файлы, и пользователь Apache не может индексировать содержимое папки uploads:

<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, Также вы можете контролировать максимальный размер файла, максимальный размер сообщения и максимальные файлы для загрузки в том же запросе.


3
2017-10-23 09:54





Когда у вас есть пользователь FTP, который называется «leo», необходимо загружать файлы в веб-каталог 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

3
2017-08-09 07:15