Segurança do firewall - Honey pots e Drip pans - pensamentos?

Question

Eu configurei um esquema de batida de porta para proteger a porta 22 usando regras de iptable. Além disso, configurei algumas regras de "pote de mel" para desativar a batida de porta do cliente por vários minutos, caso atinjam portas comuns que não são usadas (porta 21, por exemplo) ou portas ao redor da seqüência de batida. Isso parece funcionar bem (eu acredito que é uma opção melhor do que mudar a porta para algo obscuro). No momento, os logins de senha do SSHD são desabilitados - uma combinação de chave privada / pública criptografada é necessária.

Em esta página , há um esquema de "drip pan" que, se portas não utilizadas forem atingidas, o cliente não poderá se comunicar com nada (mesmo portas abertas) por 60 segundos. Minha maior preocupação é que "--hitcount 3" parece ser acionado por qualquer solicitação simples para uma única porta.

Então, minha pergunta é: o que você acha desse tipo de configuração? A "bandeja de gotejamento" é demais em um servidor da Web, ou apenas certo? Além de manter uma política de drop-out-out e apenas abrir o que é necessário, vocês têm algum outro conselho de segurança de firewall?

Editar: estou usando o CentOS 5.7. Estamos assumindo como "seguro quanto possível dentro da razão". Um servidor teria que passar por conformidade com PCI / SAS (e outros padrões semelhantes). O foco seria o firewall, não necessariamente vulnerabilidades com serviços individuais que poderiam ser descobertos (isso é outro tópico). Tudo o que eu sinto falta está relacionado ao firewall ou qualquer coisa do lado de fora. Deseja tornar o mais difícil possível para um invasor obter acesso.

    

Answer 1

Completamente opinião subjetiva aqui, mas eu nunca estive tão interessado em bater no porto.

Parece um pouco como uma kluge e eu sempre me preocupei que haverá aquele momento em que o flat out pare de funcionar como esperado ou eu descubra um caso extremo que me tire do meu sistema.

Eu acho que com a autenticação de senha desativada e apenas os pares de chaves SSH, raramente vejo o mesmo bot tentar a porta mais do que algumas vezes. Só não é prático quando há tantos outros anfitriões por aí para tentar e possuir. Até que as pessoas parem de permitir logins de SSH root e desistam da autenticação de senha, os frutos mais baratos ainda estão lá e prontos para a escolha dos criminosos cibernéticos.

No firewall, eu geralmente deixo conexões com o TCP 22, exceto em alguns locais, já que raramente estou em qualquer lugar onde eu precise acessar uma caixa diretamente (eu vou apenas VPN para um local que possa ).

Estou assumindo que este é um servidor da Web, sim? Invista algum tempo para entender os requisitos de seus aplicativos da Web. Seu firewall stateful típico é quase inútil para se defender contra ataques que ocorrem na porta 80, como injeção de SQL, XSS e afins.

Também configurei um registro robusto (registre todas as suas consultas SQL se você estiver executando um banco de dados; configure um syslog remoto para seus logs de firewall, logs do servidor web, auth.log, logs do sistema, logs do servidor web, etc. )

Eu configuraria um servidor proxy em outro host (se possível) e deixaria de fora tudo do seu servidor Web no firewall. Quando / se sua caixa for adquirida, o invasor não poderá fazer uma conexão TCP / UDP direta na Internet (geralmente uma das primeiras coisas que um invasor desejará fazer é obter um shell em seu sistema) e, se você está alertando está no lugar, você saberá imediatamente.

O único tráfego HTTP de saída que deve ser permitido deve sair por meio do servidor proxy e você deve (pelo menos para um servidor) ter uma lista de permissões de domínios ok (como repositórios de gerenciamento de pacotes).

Fazer isso irá percorrer um longo caminho; suponha que você vai se apossar e planejar e defender em conformidade.