Configuração de segurança do Apache - Ubuntu 12

2

Estou executando uma pilha LAMP no Ubuntu 12, com a função principal de servir uma API baseada em PHP.

Existe apenas um arquivo que eu quero que seja exposto ao público chamado: api.php

Ele precisa fazer referência a um arquivo de configuração que possuo em /cfg/api-config.php , que contém senhas de db para que a API possa gravar no banco de dados, etc.

Por isso, só quero que o api.php seja "servido" pelo apache e tornado público.

O arquivo de configuração que eu coloquei no / cfg deve ser legível pelo api.php, mas não por qualquer pessoa que possa visitar o site.

Eu não tenho .htaccess , apenas um httpd.conf configurado conforme o abaixo.

<VirtualHost *:44448>
    DocumentRoot "/api"
    ServerName localhost:44448
    ServerAlias Server.local
    DirectoryIndex index.html
    CustomLog "/var/log/apache_access.log" combined
    ErrorLog "/var/log/apache_error.log"

    SetEnv APPLICATION_ENV development
    php_flag magic_quotes_gpc off

    <Directory "/api">
        Options Indexes MultiViews FollowSymLinks
        AllowOverride All
        Order allow,deny
        Allow from all
    </Directory>
</VirtualHost>

As permissões nas minhas pastas /cfg e /api são: drwxr-xr-x e permissões no meu arquivo de configuração confidencial com a senha do db, localizada em /cfg/api-config.php is -rw-r--r--

Eu queria saber se alguém pode me dizer se isso está configurado corretamente e seguro?

Por que:

A) Todos os arquivos que não sejam o /api/api.php não são públicos, e nenhum acesso pode ser obtido para os arquivos dos meus servidores.

B) O arquivo de configuração com as senhas para db (para a API) também não é legível por qualquer pessoa que visite o site?

Eu tentei testar isso criando uma nova pasta em /cfg com chmod 777 e não consigo acessá-la, o que é bom!

    
por Woodstock 17.12.2013 / 10:11

4 respostas

2

Você tem dois arquivos (suponha que estejam localizados em / var / www)

  • /var/www/api/api.php
  • /var/www/cfg/api-config.php

Primeiro, restrinja o acesso a / cfg com o apache (isso garante que ninguém possa acessá-lo de http) e permita acesso a / api:

<Directory /var/www/api>
    Options None
    AllowOverride None
    Order allow,deny
    Allow from all
<Directory>

<Directory /var/www/cfg>
    Options None
    AllowOverride None
    Order allow,deny
    Deny from all
<Directory>

Em seguida, restrinja seu php com open_basedir:

open_basedir = /var/www/api:/var/www/cfg

(adicione / tmp, sessão e outros diretórios aqui, se você precisar deles)

Em seguida, altere o modo de acesso do diretório / var / www / cfg e do arquivo /var/www/cfg/api-config.php (supondo que o usuário do apache seja www-data):

  chown -Rv root:root /var/www/{cfg,api}
  chmod -v 711 /var/www/cfg
  chmod -v 755 /var/www/api
  chmod -v 644 /var/www/api/api.php /var/www/cfg/api-config.php

Ao usar 711 on / cfg, você garante, então ninguém pode ler o conteúdo (lista) do diretório, enquanto ainda pode ler o arquivo api-config.php (você precisa disso para ler o arquivo pelo PHP )

    
por 27.12.2013 / 02:26
1

Primeiro, altero as permissões de arquivo do seu cfg e dos arquivos que residem nele. Se você armazenar as configurações do banco de dados, este é um acesso de leitura e o acesso para gravação deve ser removido. É bom ter seu Daemon HTTP Apache - ambiente configurado seguro, mas essa é outra camada de segurança. Seu PHP - Instalação é executado dentro do contexto de usuário do seu Daemon HTTP, então eu pessoalmente removerei o acesso de leitura para o grupo. Eu me pergunto sobre os testes que você realizou. A pasta cfg - parece não estar sob seu DocumentRoot, então parece ser inacessível pelo seu HTTP - Server à primeira vista. Mas as pessoas que tentam invadir sua instalação não contam com esse tipo de abordagem. Você tem AllowOverride All         Ordem permitir, negar         Permitir de todos na sua configuração, o que significa simplesmente: Nenhum controle de acesso em tudo. Você também declara o FollowSymLinks, que introduz outros impactos na segurança. Portanto, esta instalação está muito longe de ser segura. Você pode proteger sua pasta cfg - colocando um arquivo .htaccess - no DocumentRoot de suas instalações. As entradas nele podem proteger strongmente o acesso a arquivos e diretórios, por exemplo,

< arquivos RELEASE_NOTES.txt >
        encomendar permitir, negar
        negar de todos os
    < / Ficheiros > (tirado de um magento - instalação)

Se você quer saber dos impactos de segurança do FollowSymLinks: Lembre-se que o PHP está rodando no contexto da sua instalação do Apache HTTP Daemon e que o PHP pode executar o Write-Operations no seu sistema de arquivos. Se o PHP - Code for inserido em seu aplicativo criando links simbólicos nele para que alguém possa espionar seu sistema de arquivos criando apenas links simbólicos para as partes do sistema em que ele ou ela está interessado. Colocando um simples .htaccess - Arquivo no seu diretório cfg - do formulário Ordem permitir, negar Negar de tudo irá remover a capacidade de navegar neste diretório através do seu Daemon HTTP. Se o seu api.php é o front controller do seu PHP - Installation / Webapp, você deve considerar o uso do mod_rewrite do Apache para reescrever todas as URLs solicitadas para apontar para o seu api.php, por exemplo,

RewriteCond% {REQUEST_FILENAME}! -f
  RewriteCond% {REQUEST_FILENAME}! -D
  RewriteCond% {REQUEST_URI}! = / Favicon.ico
  RewriteRule ^ api.php [L]

em um arquivo .htaccess - você coloca no diretório / api -, que irá encaminhar todos os pedidos para o seu api.php. por exemplo. localhost: 44448 / someURL? id = 988 vai se tornar um pedido localhost: 44448 / api.php? id = 988 internamente.
Para esclarecer:
Reescrever - regras não devem ser usadas para controle de acesso, elas têm principalmente o propósito de alterando como as solicitações são processadas.
Muitos PHP - Frameworks ou CMS usam o RewriteRules para ter um ponto de entrada central para o aplicativo da web no qual os componentes do aplicativo são carregados, os componentes de roteamento podem ser chamados, e traduções de URL - paramters para estruturas internas são executadas.
Por exemplo. Symfony2 traduz Query / e Post - parameters para uma estrutura mais orientada a objeto, encapsulando - a em um objeto.
O Symfony2 também utiliza conceitos de segurança lendo roteamento - informações e configurações antes de gerar a resposta HTTP, então, por exemplo, garantindo que uma autenticação tenha sido executada ou que um usuário tenha a função de usuário correta para acessar um caminho de URL.

    
por 20.12.2013 / 09:03
1

Você parece ter feito a única coisa importante, que é colocar /cfg/api-config.php fora do seu DocumentRoot. Se /cfg não estiver no espaço da URL, os usuários do site não poderão lê-lo. Esta é a precaução mais básica que você pode tomar.

É possível que os usuários ainda possam ler esse arquivo? Claro, se você quebrar a configuração em outro lugar (configurando um Alias ou RewriteRule para o arquivo, por exemplo), ou se o aplicativo fizer algo estúpido como exibir o conteúdo do arquivo. As vulnerabilidades de aplicativos são a preocupação real: o aplicativo precisa ler o arquivo e, quanto mais complexo o aplicativo, maior a probabilidade de ter uma vulnerabilidade oculta nele. Mas no que diz respeito à configuração do Apache, acho que você está pronto.

    
por 20.12.2013 / 10:19
1

Além das sugestões acima, eu recomendaria a remoção do acesso de gravação a quaisquer arquivos / pastas no DocumentRoot de seu usuário do Apache. (por exemplo, seu arquivo api.php) Isso pressupõe que api.php (ou qualquer coisa que ele chama) não precise gravar nada no servidor web local. Isso deve ajudar a evitar que arquivos indesejados sejam gravados em seu servidor da Web

    
por 23.12.2013 / 17:59