Como impedir que o apache sirva o diretório .git?


74

Comecei a usar o git para implantação de sites para teste. Como impedir que o apache sirva o conteúdo do diretório .git?

eu tentei

<Directorymatch "^/.*/\.svn/">
Order deny,allow
Deny from all
</Directorymatch>

sem sucesso.

Sei que posso criar um arquivo .htaccess em cada diretório .git e negar acesso, mas queria algo que pudesse colocar no arquivo de configuração principal que o torna global em todos os sites.


3
Depois de impedir que o apache atenda o diretório, também será necessário ocultar o diretório .git com "IndexIgnore .git" se você tiver os Índices ativados em seu diretório.
21915 Ryan

Respostas:


55

Não está funcionando porque você tem 'svn' e não 'git' na regra. Tudo que você precisa fazer é substituir o 'svn' por 'git'.

<Directorymatch "^/.*/\.git/">
Order deny,allow
Deny from all
</Directorymatch>

11
Quando crio um .htaccess contendo apenas seu código, recebo o erro: "<DirectoryMatch não permitido aqui"
Shoan

2
Tem que estar no conf. Apache. Veja: httpd.apache.org/docs/1.3/mod/core.html#directorymatch
sinping

2
O regex mais simples é<DirectoryMatch /\.git/>
Bachsau

Verifique isso para solução perfeita magento.stackexchange.com/questions/202840/...
Pratik Kamani

1º, graças ao canto / OP. Observe que no Apache 2.4 a "Ordem, negar" e a próxima linha foram substituídas por "Exigir tudo negado". Além disso, muitas instalações no arquivo chamado "Apache conf" acima são denominadas "httpd.conf" - o uso de cantar era apenas uma declaração casual, portanto, não procure pelo nome literal (provavelmente não é preciso dizer, mas você nunca sabe como as pessoas podem lê-lo).
Kevin_Kinsey

139

Isso tem o mesmo efeito que muitas das outras respostas, mas é muito mais simples:

RedirectMatch 404 /\.git

Isso pode entrar no .htaccessarquivo de configuração do servidor. Ele oculta qualquer arquivo ou diretório cujo nome comece .git(por exemplo, um .gitdiretório ou .gitignorearquivo) retornando um 404. Portanto, não apenas o conteúdo do seu repositório Git está oculto, mas também a sua existência.


2
Eu realmente gosto desta solução. É simples e elegante.
Shoan

2
Colocar isso no diretório raiz do htdocs também faz um trabalho global.
Jor

4
Também ame esta opção. Parece-me que é mais seguro retornar um 404 para solicitações como /.git ou /.gitignore, para que o fato de o git estar sendo usado não possa ser determinado de fora.
Ezra Free

2
Lembre-se de que, se você tiver as listagens de diretório ativadas, as .gitpastas ainda estarão visíveis, mas você obterá o 404 ao tentar acessá-las.
Andy Madge

11
@BennettMcElwee sim, concordou: quase nunca há um bom motivo para ter a listagem de diretórios ativada globalmente em um servidor de produção. Só pensei que merecia uma menção no caso de alguém pegar.
Andy Madge

13

Se você não usa arquivos .htaccess, mas deseja usar o /etc/apache2/httpd.conf (ou qualquer que seja o arquivo conf principal do servidor) para ocultar os diretórios .git e os arquivos .gitignore, você pode usar o seguinte. Encontrei a resposta acima para a configuração de configuração mestre não oculta o arquivo gitignore.

# do not allow .git version control files to be issued
<Directorymatch "^/.*/\.git+/">
  Order deny,allow
  Deny from all
</Directorymatch>
<Files ~ "^\.git">
    Order allow,deny
    Deny from all 
</Files>

11
Não bloqueie o www.example.com/.git/configarquivo no Apache httpd 2.4.27.
ilhan 18/09/17

12

Se você estiver em um serviço de hospedagem compartilhada e não tiver acesso ao apache.conf , ainda poderá fazê-lo no seu arquivo .htaccess, desta forma:

RewriteEngine On
RewriteRule "^(.*/)?\.git/" - [F,L]

graças isso funcionou para mim em uma situação de hospedagem compartilhada, onde a resposta de topo não fez
Platão

6
### never deliver .git folders, .gitIgnore
RewriteRule ^(.*/)?\.git+ - [R=404,L]

# 2nd line of defense (if no mod_rewrite)
RedirectMatch 404 ^(.*/)?\.git+

Isso funciona .htaccess, não é http.confnecessário acesso. Inclua isso como a primeira das regras de reescrita. Anexe, Rewrite Onse necessário.

Do ponto de vista da segurança, prefiro um 404 falso ao invés de um 403, mais informativo do que o invasor. Comente um dos dois, para garantir que o outro funcione para você também.

Btw, boas mudanças são, seu teste lititológico para os dois são:

http://localhost/.gitignore
http://localhost/.git/HEAD

Por que ter as duas regras? O RedirectMatch mais simples é suficiente por si só. (Além disso, as expressões regulares não parecem muito bem - por que o plus no final?)
Bennett McElwee

Paranoia pessoal / segurança dobrada. Se o RewriteEngine for desativado (alterações na configuração central, má comunicação da equipe, "azar" do servidor, ... você escolhe :-) O + está obsoleto ou deve ser um bom ponto $! (sem tempo para testes, desculpe.)
Frank Nocke

Se você está preocupado com o fato de o RewriteEngine estar desativado, basta colocar RewriteEngine Onantes da RewriteRule. Mas de qualquer maneira é tautológico e redundante porque o RedirectMatch mais simples é suficiente por si só. Embora até isso possa ser simplificado. Basicamente, estou recomendando minha resposta . :)
Bennett McElwee

+1 para o teste decisivo.

5

Para proteger o diretório .git e outros arquivos, como .gitignore e .gitmodules usando .htaccess, use:

RewriteEngine On
RewriteRule ^(.*/)?\.git+ - [F,L]
ErrorDocument 403 "Access Forbidden"

4
Funciona para mim, no entanto, o ErrorDocument à direita não tem impacto. De um ângulo de segurança, eu gosta de uma falsa 404 sobre um informativo 403 para o atacante ...
Frank Nocke

11
Essa é uma péssima idéia, porque divulga informações para hackers. Um 403 significa que está lá, um 404 significa que não está. Todo fato na configuração de um servidor é útil para um hacker. Eu consideraria revisar isso.
GerardJP

3

Eu sempre adiciono a seguinte linha no modelo vhost

RedirectMatch 404 /\\.(svn|git|hg|bzr|cvs)(/|$)

Apenas para ter certeza de que ninguém pode acessar dados específicos do VCS. Funciona perfeito.


1

Supondo que seu servidor da Web esteja usando um usuário diferente daquele que você usa para acessar o repositório .git, você poderá desativar o bit de execução para outras pessoas no diretório .git.

Isso deve funcionar com outros servidores da Web e não depende de arquivos .htaccess que consomem desempenho.


1

Para aqueles que procuram simplesmente negar todos os arquivos e diretórios "ocultos" em uma distribuição Linux (geralmente todos os arquivos que começam com "."), Eis o que funciona no Apache 2.4 quando colocado no contexto conf do servidor:

<FilesMatch "^\.(.*)$">
    Require all denied
</FilesMatch>
<DirectoryMatch "/\.(.*)">
    Require all denied
</DirectoryMatch>

E aqui está o estilo antigo do Apache 2.2 (o mesmo regex, apenas diretivas de autenticação diferentes):

<FilesMatch "^\.(.*)$">
    Order deny,allow
    Deny from all
</FilesMatch>
<DirectoryMatch "/\.(.*)">
    Order deny,allow
    Deny from all
</DirectoryMatch>

Então você não precisa se preocupar .gitou .svnespecificamente. Isso também corresponderia a coisas como .htaccesse .htpasswdinerentemente.

Pessoalmente, eu gosto de emitir 403s para essas solicitações em vez de 404s, mas você pode facilmente usar um RewriteRule em vez de negação de autenticação, assim:

<FilesMatch "^\.(.*)$">
    RewriteRule "^(.*)$" - [R=404,L]
</FilesMatch>
<DirectoryMatch "/\.(.*)">
    RewriteRule "^(.*)$" - [R=404,L]
</DirectoryMatch>

0

Você provavelmente quer negar servir .gitignoretambém.

Arquivos começando com um ponto estão ocultos no linux.

Portanto, apenas 404 qualquer coisa que comece com um ponto:

RedirectMatch 404 /\.


0

É um pouco tarde, mas minha resposta é um pouco diferente, então pensei em adicioná-la. Isso deve estar no arquivo httpd.conf. O <Files "*">aninhado dentro da <Directory>tag irá bloquear todos os arquivos no diretório.

# GitHub Directory
<Directory /var/www/html/yoursite/.git>
   Order Deny,Allow
   Deny from all
   <Files "*">
     Order Deny,Allow
     Deny from all
   </Files>
</Directory>
# GitHub files
<Files .gitignore>
  order Deny,Allow
  Deny from all
</Files>
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.