Как скрыть каталоги в Apache, в частности, контроль версий?

Question

Я хочу сохранить свой веб-сайт (ы) в системе контроля версий (в частности, в Subversion) и использовать svn co для обновления, когда есть стабильные версии для обновления, но я обеспокоен безопасностью этого, так как все * Папки 1002 * будут общедоступными, и они включают в себя все виды личных данных, не в последнюю очередь это полный исходный код моего сайта!

Что я могу сделать, чтобы предотвратить это?

Answer 1

Две вещи:

1. Не используйте IfModule для функциональности, которую вы должны присутствовать. Это нормально делать для автоиндекса, потому что он может отсутствовать и не имеет решающего значения для схемы. Но вы рассчитываете перезаписать присутствие, чтобы защитить свой контент. Таким образом, лучше удалить директиву IfModule и позволить apache сообщить вам, когда перезаписи нет, чтобы вы ее включили (или хотя бы знали, что вы не будете «защищены» и сознательно комментируете строки)

2. Нет необходимости использовать перезапись там, если у вас есть доступ к основным файлам конфигурации, гораздо проще будет один из

   <DirectoryMatch \.svn>
      Order allow,deny
      Deny from all
   </DirectoryMatch>
   

, который сгенерирует 403 Forbidden (что лучше с точки зрения соответствия HTTP) или, если вы хотите принять защиту по неизвестному маршруту, используйте AliasMatch

    AliasMatch \.svn /non-existant-page

Если у вас нет доступа к основным файлам конфигурации, у вас остается надежда, что mod_rewrite включен для использования в .htaccess.

Answer 2

В той же ситуации я использовал RedirectMatch по двум причинам. Во-первых, это был единственный метод, который я смог найти, который был разрешен в .htaccess на этом сервере с довольно ограничивающей конфигурацией, которую я не мог изменить. Кроме того, я считаю его наиболее чистым, потому что он позволяет мне сказать Apache, что да, там есть файл, но просто притвориться, что он не при обслуживании, поэтому верните 404 (в отличие от 403, который раскрывает вещи, о которых зрители веб-сайта не должны знать ).

Теперь я рассматриваю в качестве стандартной части моих .htaccess файлов следующее:

## Completely hide some files and directories.
RedirectMatch 404 "(?:.*)/(?:[.#].*)$"
RedirectMatch 404 "(?:.*)~$"
RedirectMatch 404 "(?:.*)/(?:CVS|RCS|_darcs)(?:/.*)?$"

Answer 3

Это может быть достигнуто для всего сервера (рекомендуется), для отдельного виртуального хоста или даже внутри .htaccess файлов, если ваш сервер несколько допускает то, что разрешено в них. Конкретная конфигурация, которая вам нужна:

RewriteEngine On
RewriteRule /\.svn /some-non-existant-404-causing-page

<IfModule autoindex_module>
    IndexIgnore .svn
</IfModule>

Для первого раздела требуется mod_rewrite. Это заставляет любые запросы с "/.svn" в них (то есть любой запрос на каталог или что-либо внутри каталога) перенаправлять внутренне на несуществующую страницу на вашем сайте. Это полностью прозрачно для конечного пользователя и необнаружимо. Это также вызывает ошибку 404, как будто ваши папки .svn просто исчезли.

Второй раздел носит чисто косметический характер и скрывает папки .svn из модуля автоиндексирования, если он активирован. Это тоже хорошая идея, просто чтобы любопытные души не получали никаких идей.

Answer 4

Я использую следующее, которое возвращает простое 404 пользователю, не показывая, что каталог управления исходным кодом действительно существует:

RedirectMatch 404 /\.(svn|git)(/|$)

Answer 5

Я использую интересный подход: извлечение (и обновление) выполняется в совершенно отдельном каталоге (возможно, на совершенно отдельной машине), а затем код копируется туда, где веб-сервер будет читать его с помощью rsync. Правило --exclude в командной строке rsync используется, чтобы запретить копирование любых каталогов .svn (и CVS), тогда как --delete-exclusive гарантирует, что они будут удалены, даже если они были скопированы ранее.

Поскольку svn update и rsync выполняют инкрементную передачу, это довольно быстро даже для больших сайтов. Это также позволяет вам иметь свой репозиторий за брандмауэром. Единственное предостережение заключается в том, что вы должны переместить все каталоги с файлами, сгенерированными на сервере (например, каталогами files / на Drupal), в место за пределами целевого каталога rsync (rsync перезапишет все при использовании таким способом) и символическую ссылку на него. должен быть создан в исходном каталоге rsync . В исходном каталоге rsync могут быть и другие не версионные файлы (например, машинные файлы конфигурации).

Полный набор параметров rsync, который я использую:

rsync -vv --rsh='ssh -l username' -rltzpy --exclude .svn/ --exclude CVS/ --exclude Attic/ --delete-after --delete-excluded --chmod=og-w,Fa-x

Даже в этом случае для избыточности у меня все еще есть правило конфигурации, запрещающее доступ к .svn, копируемый из правила по умолчанию Debian, которое запрещает доступ к .ht * (.htaccess, .htpasswd).

Answer 6

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

Answer 7

Скрытие каталогов, как говорит Винко, должно сработать. Но, вероятно, было бы проще использовать svn export вместо svn co. Это не должно генерировать каталоги .svn.