Какие разрешения должны иметь файлы /папки веб-сайта на веб-сервере 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.

273 голоса | спросил Nic 6 FebruaryEurope/MoscowbMon, 06 Feb 2012 05:50:32 +0400000000amMon, 06 Feb 2012 05:50:32 +040012 2012, 05:50:32

5 ответов


307

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

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

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

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

ответил Nic 6 FebruaryEurope/MoscowbMon, 06 Feb 2012 05:50:45 +0400000000amMon, 06 Feb 2012 05:50:45 +040012 2012, 05:50:45
12

Мне интересно, почему так много людей используют (или рекомендуют) «другую» (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 прав.
  • Часть o всегда установлена ​​в 0, поэтому никто на сервере не может читать или редактировать веб-сайт.
  • Нет проблем, когда пользователь bob создает новые файлы, так как он будет автоматически принадлежать его основной группе ( bob ).

Это резюме, но в этой ситуации для SSH разрешено bob . Если пользователю не разрешено изменять веб-сайт (например, клиент только модифицирует веб-сайт с помощью панели администрирования 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 создает новый файл (например, upload), он будет принадлежать bob-www: bob и bob сможет только прочитать его. Возможно, setuid в каталоге может решить проблему.

ответил Fox 20 J000000Saturday13 2013, 01:42:37
9

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

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

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

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

ответил Paul 14 Jam1000000amMon, 14 Jan 2013 02:03:57 +040013 2013, 02:03:57
3

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

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

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

ответил Manolo 23 +04002013-10-23T13:54:48+04:00312013bEurope/MoscowWed, 23 Oct 2013 13:54:48 +0400 2013, 13:54:48
3

Когда у вас есть пользователь 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
ответил Krishan Gopal 9 AM000000100000004731 2016, 10:15:47

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132