É iptables segurança suficiente, se a porta 80 é a única porta desbloqueada e o apache está configurado corretamente?

4

Estamos usando PHP, MySQL, SVN e Apache. Eu quero saber se eu suponho que a sub-rede local seja confiável e permita que todas as portas em nossa sub-rede usem iptables, então permita somente a porta 80 como aberta para "qualquer pessoa". Se for "boa segurança" considerar que a sub-rede é confiável como premissa. Isso também está assumindo um bom código PHP, etc., e esse apache está configurado corretamente.

Isso está usando o CentOS 5.

    
por Joshua Enfield 07.04.2010 / 22:53

5 respostas

4

Não, não desafiadoramente. Na verdade, a porta 80 é provavelmente a porta mais perigosa que você pode abrir em um sistema moderno. Também não ter https: // (tcp 443) significa que todos os seus ids de sessão estão sendo vazados. Não usar https é uma clara violação do A3: "Autenticação quebrada e gerenciamento de sessão" no OWASP top 10 para 2010.

Uma coisa boa que você pode fazer para se proteger é executar um WAF (Web Application Firewall) como Mod_Secuirty . Um WAF é muito diferente de um "firewall de filtro de pacotes" como o iptables.

Também recomendo a execução de uma varredura de vulnerabilidades no seu sistema, como o Acunetix ou o wapiti. Verifique se seu sistema é atualizado regularmente: yum upgrade . Execute o PhpSecInfo e configure seu php.ini de forma que nenhum RED apareça. A configuração padrão do PHP é terrivelmente insegura, ficou melhor (desativando o arquivo remoto inclui e register_globals por padrão), mas ainda é muito ruim.

    
por 08.04.2010 / 01:16
3

Eu diria que o problema está em:

"Assumindo um bom código PHP".

Você não pode tomar isso como garantido. Idealmente, esse servidor entrará em um DMZ onde a LAN pode acessá-lo, mas o DMZ não pode acessar a LAN. A ideia é que você assuma que seu servidor voltado para o público será comprometido e, em seguida, deseja limitar o dano. Ao ter um firewall separado entre sua LAN e a DMZ, você provavelmente limita o dano. Portanto, com uma configuração DMZ, o subversion provavelmente não estará no servidor voltado para o público. Se você não puder pagar por esse servidor extra, criar uma máquina virtual e ter o servidor voltado para o público pode ser uma espécie de DMZ do homem pobre.

Eu também daria o passo extra para abrir apenas as portas para a sub-rede local que são necessárias (você provavelmente precisará confiar mais em sua LAN, mas ainda assim limitá-la, se puder). Provavelmente não será muito se você estiver usando o módulo de estado (configuração padrão do redhat / centos).

Além disso, não se esqueça das atualizações de segurança para o sistema operacional e os aplicativos.

    
por 08.04.2010 / 00:06
1

Se tudo estiver seguro, você terá segurança suficiente. Infelizmente, a primeira parte dessa frase raramente é verdadeira. Abra apenas as portas necessárias, mesmo para uma rede confiável.

    
por 08.04.2010 / 00:04
1

bem .. não apenas limita as conexões de entrada. filtrar a saída também. e filtrá-los localmente na tabela OUTPUT, mas também no roteador.

existem tantos buracos nos scripts populares ... minimizam as baixas no caso de o seu servidor ser propriedade.

permitir saída ESTABELECIDA, RELACIONADA [obviamente], provavelmente a poucos hosts com atualizações do SO, talvez ao seu servidor de retransmissão SMTP ... e pronto. então você evita que a caixa faça o download de carga maliciosa, espalhe spam etc.

    
por 08.04.2010 / 00:20
1
Concordo com a @The Rook sobre isso - o perigo real é toda aquela grande e gorda funcionalidade oculta atrás de 80. Se você está escrevendo código de aplicativo da Web, independentemente do idioma, eu recomendo que você aprenda rapidamente como escrever código seguro e crie projetos seguros. Nenhuma quantidade de defesa de firewall protege você de um aplicativo da web de baixa qualidade.

    
por 08.04.2010 / 18:48