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

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

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

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

Источник

6 ответов

Решение

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

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

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-данных был доступ для записи.

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

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

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

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

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

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

Источник

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

Мой подход заключается в следующем:

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

Сейчас:

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

Это резюме, но в этой ситуации Бобу разрешен 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), он будет принадлежать bob-www: bob, и 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 / session / 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
Источник

ИМО нужно учитывать:

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

Предположим, у вас есть сервер, на котором различные данные находятся под тестом пользователя.

Там у "тестового" пользователя:

  • его данные в $HOMEDIR
  • его почта в $MAIL
  • его данные для сети в /var/www/test

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

  • веб-приложение работает под test Пользователь (PHP-FPM) - он может удалить любой из своих файлов!
  • веб-приложение работает под test group (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,nosuidmount параметры и постоянный мониторинг любых новых файлов Bizzare в этом каталоге, а также отслеживать любые новые процессы в test-www UID.

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

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

Источник
Другие вопросы по тегам