Я хочу, чтобы мой веб-сайт / сайты находились под контролем версий (в частности, Subversion) и использую svn co для его обновления, когда есть стабильные версии для обновления, но меня беспокоит безопасность этого, поскольку все папки .svn будут общедоступными, и они включают в себя всевозможные личные данные, не в последнюю очередь полный исходный код моего веб-сайта!
Что я могу сделать, чтобы предотвратить это?
Две вещи:
Не используйте IfModule для функций, которые вам необходимы. Это нормально сделать для автоиндекса, потому что он может отсутствовать и не имеет решающего значения для схемы. Но вы рассчитываете на присутствие перезаписи, чтобы защитить свой контент. Таким образом, лучше удалить директиву IfModule и позволить apache сообщать вам, когда перезапись отсутствует, чтобы вы могли ее включить (или, по крайней мере, знать, что вы не будете `` защищены '' и сознательно комментируете строки)
Нет необходимости использовать перезапись, если у вас есть доступ к основным файлам конфигурации, гораздо проще было бы использовать один из
<DirectoryMatch \.svn>
Order allow,deny
Deny from all
</DirectoryMatch>
который будет генерировать 403 Forbidden (что лучше с точки зрения соответствия HTTP), или, если вы хотите использовать безопасность путем скрытия маршрута, используйте AliasMatch
AliasMatch \.svn /non-existant-page
Если у вас нет доступа к основным файлам конфигурации, вам остается надеяться, что mod_rewrite включен для использования в .htaccess.
В той же ситуации я использовал RedirectMatch по двум причинам. В первую очередь, это был единственный метод, который я смог найти, разрешенный в .htaccess на этом сервере с довольно строгой конфигурацией, которую я не мог изменить. Также я считаю его самым чистым, потому что он позволяет мне сказать Apache, что да, там есть файл, но просто притвориться, что его нет при обслуживании, поэтому верните 404 (в отличие от 403, который раскрывает то, о чем посетители веб-сайта не должны знать. ).
Теперь я считаю стандартной частью моих .htaccess файлов:
## Completely hide some files and directories. RedirectMatch 404 "(?:.*)/(?:[.#].*)$" RedirectMatch 404 "(?:.*)~$" RedirectMatch 404 "(?:.*)/(?:CVS|RCS|_darcs)(?:/.*)?$"
Это может быть достигнуто на уровне сервера (рекомендуется), на основе одного виртуального хоста или даже внутри .htaccess файлов, если ваш сервер в некоторой степени разрешает то, что в них разрешено. Конкретная конфигурация, которая вам нужна:
RewriteEngine On
RewriteRule /\.svn /some-non-existant-404-causing-page
<IfModule autoindex_module>
IndexIgnore .svn
</IfModule>
Первый раздел требует mod_rewrite. Он заставляет любые запросы с «/.svn» в них (т. Е. Любой запрос каталога или что-либо внутри каталога) быть внутренне перенаправленными на несуществующую страницу вашего веб-сайта. Это полностью прозрачно для конечного пользователя и не поддается обнаружению. Это также вызывает ошибку 404, как если бы ваши .svn папки просто исчезли.
Второй раздел носит чисто косметический характер и скроет .svn папок из модуля автоиндекса, если он активирован. Это тоже хорошая идея, просто для того, чтобы любопытные души не догадывались.
Я использую следующее, которое возвращает пользователю простой 404, не показывая, что каталог системы управления версиями действительно существует:
RedirectMatch 404 /\.(svn|git)(/|$)
Я использую интересный подход: проверка (и обновление) выполняется в совершенно отдельном каталоге (возможно, на совершенно отдельной машине), а затем код копируется туда, где веб-сервер прочитает его с помощью rsync. Правило --exclude в командной строке rsync используется, чтобы не копировать директории .svn (и CVS), а --delete-excluded гарантирует, что они будут удалены, даже если они были скопированы ранее.
Поскольку и 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).
Скрытие каталогов, как говорит Винко, должно работать. Но, вероятно, было бы проще использовать экспорт svn вместо svn co. Это не должно создавать каталоги .svn.
Рассмотрите возможность развертывания живого кода с помощью инструментов управления пакетами вашей операционной системы, а не непосредственно из вашей VCS. Это позволит вам убедиться, что ваши живые пакеты не содержат каталогов метаданных или других потенциально конфиденциальных инструментов и данных.
