Назад | Перейти на главную страницу

Безопасность Apache для веб-сервера многопользовательской разработки

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

Вот ситуация: у меня есть веб-сервер apache, на котором есть любое количество виртуальных сайтов, расположенных в / var / www / site1 / var / www / site2 и т. Д.

У меня есть разные разработчики, которым нужен полный доступ к ssh и vsFTP только к тому сайту, над которым они работают. Каков наилучший способ создать и поддерживать безопасность в этом сценарии. Моя мысль заключалась в том, чтобы создать нового пользователя для каждого кодировщика, поместить этого пользователя в тюрьму в каталог веб-сайта, в котором ему разрешено работать, добавить его пользователя в группу и установить владельца корневого веб-сайта в эту группу.

Есть предположения? Хорошо, плохо, некрасиво? Спасибо!

Для начала удалите vsFTP как можно скорее. Отправлять исходный код и пароли через Интернет в виде обычного текста - крайне плохая идея. FTP должен ТОЛЬКО Для анонимной передачи файлов следует использовать sftp или ftp + ssl и устранить избыточность. Наличие двух демонов делает вас вдвое более уязвимыми для эксплуатации. Подумайте о том, чтобы максимально уменьшить поверхность атаки.

Традиционная тюрьма Chroot, вероятно, излишняя, хотя она может выполнять свою работу. Есть 2 угрозы, о которых вам нужно беспокоиться. Во-первых, пользователь может загружать / изменять код с помощью ssh. От этого можно защититься, используя конфигурацию ChrootDirectory в вашем конфигурационном файле sshd:

ChrootDirectory Задает путь к chroot (2) после аутентификации. Этот путь и все его компоненты должны быть корневыми каталогами, которые не доступны для записи другим пользователям или группам. После chroot sshd (8) меняет рабочий каталог на домашний каталог пользователя.

Следующая угроза заключается в том, что программист может загрузить вредоносный код, например бэкдор PHP, чтобы получить доступ к вашей системе. Это гораздо более коварно, потому что бэкдор может состоять из простого добавления 2 символов или удаления 2 символов.

Самый безопасный подход к угрозе со стороны злоумышленника - использовать svn + ssh, заставить каждого программиста заниматься разработкой в ​​своей локальной системе, а затем просмотреть весь отправленный код. SVN будет отслеживать, кто какой код добавил в вашу систему. После того, как вы протестировали код на предмет уязвимостей, преднамеренных или случайных, вы развертываете «релизную» сборку на своем реальном сервере. Вести разработку на живом сервере - плохая идея, так как это приводит к случайным простоям во время разработки.

Вместо chroot модуль suexec от apache - отличный вариант для предотвращения злоупотреблений.

Иначе я бы повторил комментарий «неизвестного».