Вопросы Теги

Стандарты безопасности разрешения папок сервера [дубликат]

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

344
задан 18 December 2013 в 21:41
2 ответа

Если у вас есть 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
3
ответ дан 4 January 2021 в 10:00

Необходимо принять во внимание IMO:

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

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

У «тестового» пользователя есть:

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

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

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

Предположим, PHP содержит ошибки, и вы доверяете его open_basedir ? Вы chroot свой PHP-процесс? Что у вас нет, вы хотите, чтобы он сканировал всю файловую систему?

Процесс вашего веб-приложения, например. PHP-FPM, тогда должен:

  • быть ограничен определенным путем через chroot
  • не должен запускаться с правами основного пользователя или основной группы владельца данных

Таким образом, вы можете сделать:

  • тестовый пользователь: тест: тест
  • тестовый пользователь находится во вторичной группе, например. 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 . Я настоятельно рекомендую загрузить каталог в файловую систему с параметрами noexec, nodev, nosuid mount и иметь постоянный мониторинг любых новых файлов bizzare в этом каталоге, а также отслеживать любые новые процессы под test-www uid.

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

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

1
ответ дан 4 January 2021 в 10:00

Теги

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