Quais etapas você toma para proteger um servidor Debian? [fechadas]

Estou instalando um servidor Debian conectado diretamente à Internet. Obviamente, quero torná-lo o mais seguro possível. Gostaria que vocês adicionassem suas idéias para protegê-lo e quais programas você usa para isso.

Quero que parte desta pergunta cubra o que você usa como firewall? Apenas o iptables é configurado manualmente ou você usa algum tipo de software para ajudá-lo? Qual o melhor caminho? Bloquear tudo e permitir apenas o que é necessário? Existem talvez bons tutoriais para iniciantes neste tópico?

Você muda sua porta SSH? Você usa software como o Fail2Ban para evitar ataques de força bruta?

Obrigatório:

• instalação do sistema com modo especialista, apenas pacotes que eu preciso
• firewall escrito à mão com política padrão no iptables'input: drop, permitindo acesso ao SSH, HTTP ou qualquer outro servidor em execução
• Fail2Ban para SSH [e algumas vezes FTP / HTTP / outro - dependendo do contexto]
• desativar logins raiz, forçar o uso de usuário e sudo normais
• kernel personalizado [apenas velho hábito]
• atualização agendada do sistema

Dependendo do nível de paranóia adicionalmente:

• política de queda na saída, exceto alguns destinos / portas permitidos
• integritpara verificar se algumas partes do sistema de arquivos não foram modificadas [com a soma de verificação mantida fora da máquina], por exemplo, Tripwire
• verificação agendada pelo menos com nmap do sistema de fora
• verificação automatizada de registros em busca de padrões desconhecidos [mas principalmente para detectar mau funcionamento do hardware ou algumas falhas menores]
• execução agendada do chkrootkit
• atributo imutável para /etc/passwdadicionar novos usuários é um pouco mais difícil
• / tmp montado com noexec
• aldrava de porta ou outra maneira não padrão de abrir portas SSH [por exemplo, visitar a página da Web 'secreta' no servidor da Web permite a conexão SSH de entrada por um período limitado de tempo a partir de um endereço IP que visualizou a página. Se você se conectar, -m state --satete ESTABLISHEDcuida de permitir o fluxo de pacotes desde que você use uma única sessão SSH]

Coisas que eu não faço, mas faz sentido:

• grsecurity para kernel
• syslog remoto para que os logs não possam ser substituídos quando o sistema for comprometido
• alertando sobre logins SSH
• configure o rkhunter e configure-o para executar de tempos em tempos

Apenas uma observação sobre o firewall da sua máquina ...

• Use uma lista de permissões, não uma lista negra - ou seja, bloqueie tudo e permita apenas o que você precisa, negue tudo o mais.
• Não use GUIs / ncurses ou qualquer outro software que tente executar a tarefa de escrever seu firewall para você. Se o fizer, permitirá que o software faça suposições para você - você não precisa correr esse risco e não deveria. Configure você mesmo, se não tiver certeza, desative-o - você descobrirá em breve, se necessário. Se já é um sistema em funcionamento e você não pode interromper o tráfego (bloqueando-o acidentalmente), execute tcpdump (dump to file) e colete amostras - estude-as mais tarde e descubra o que é válido e o que não é.
• Pessoalmente, não vejo sentido em executar um serviço em uma porta não padrão, hoje em dia, as ferramentas não são tão estúpidas em supor que, como algo está sendo executado na porta 22, por exemplo, ele deve ser ssh e não o contrário - por exemplo. exemplo amap, e nmap's -Aopção. Dito isso, você pode (e provavelmente deveria, se estiver preocupado) modificar seus serviços para se esconder de olhares indiscretos, por exemplo, o seguinte informa ao invasor a versão exata do OpenSSHque você está executando, e então pode procurar explorações para essa versão exata. Se você esconder essas coisas, estará dificultando para elas.

    [root @ ud-olis-1 uhtbin] # telnet localhost 22
    Tentando 127.0.0.1 ...
    Conectado ao localhost.localdomain (127.0.0.1).
    O caractere de escape é '^]'.
    SSH-2.0-OpenSSH_3.9p1

• Mantenha todos os seus serviços públicos atualizados e atualizados com os mais recentes patches de segurança.
• Não armazene nenhum DADO no próprio servidor de gateway, pelo menos você ganhará tempo quando eles conseguirem invadir esta máquina e perderá um serviço ou dois, e algum tempo, mas não dados.

Resumindo, você nunca conseguirá fazer algo 100% seguro - o que não é possível -, portanto, o objetivo é torná-lo o mais seguro possível - se houver muito esforço para interromper o sistema, é bom o suficiente e mais lamer o script-kiddies passará para o próximo sistema.

• iptables é o caminho a seguir para qualquer sistema Linux - mas configure-o você mesmo.

Nunca use nenhum "software de segurança" que não seja baseado em padrões abertos - eles estão fadados a serem mal escritos e serão invadidos (não é uma questão de "se", mas "quando"). O código-fonte aberto e os protocolos abertos são abertos ao escrutínio público e convergem para se tornar um produto maduro e confiável; O software de código fechado confia principalmente na autoconfiança dos autores de quão grande / seguro é um produto que eles pensam que é - isto é, um pequeno número de olhos versus um mundo cheio de olhos.

Espero que ajude :)

• desativar login raiz
• desativar o login por senha (permitir apenas o login por chave pública)
• mudar porta SSH

• use denyhosts (ou similar)

• escreva seu próprio script iptbles (assim você controla exatamente o que permitir e pode eliminar todo o resto)

• forçar o uso de comunicações seguras SSL / TLS e garantir certificados válidos, não expirados e assinados

• ativar a verificação estrita de certificado para todos os serviços externos (por exemplo, ao autenticar usuários com um servidor LDAP em outra máquina)

Começa aqui:

http://www.debian.org/doc/manuals/securing-debian-howto/

Como ponto de partida geral, sigo as referências / guias do Center for Internet Security , que são compilações abrangentes das melhores práticas de segurança. Não parece que o benchmark Debian tenha sido atualizado há algum tempo, mas uma visão geral das etapas é:

• Aplique os patches / pacotes mais recentes do SO
• Habilite a contabilidade do sistema / kernel / processo.
• Habilite o MAC (por exemplo, SELinux ou AppArmor).
• Habilite o firewall baseado em host (iptables).
• Verifique o arquivo sources.list do APT (as chaves estão corretas, as fontes são confiáveis).
• Minimize os serviços de rede, desative tudo o que não é necessário e faça o firewall do que é.
• Use TCPWrappers para restringir ainda mais o acesso ao sistema.
• Use apenas protocolos de rede criptografados, desative serviços não criptografados (telnet, ftp, etc.).
• Configure o acesso remoto apenas ao SSH.
• Desabilite as senhas de login do usuário e exija autenticação baseada em chave.
• Desative o compartilhamento do sistema de arquivos (NFS, SMB).
• Habilite o registro remoto / centralizado do sistema (e revise regularmente os registros!).
• Defina uma senha no nível do BIOS / firmware.
• Defina uma senha do carregador de inicialização.
• Configure os backups do sistema, tenha um plano de recuperação de desastres e TESTE que os backups são válidos e que a equipe conheça os procedimentos de recuperação de desastres!

Existem muitos recursos em todas essas várias configurações, incluindo os comandos e arquivos de configuração específicos a serem implementados no sistema nos benchmarks do CISecurity.

Eu sugeriria não conectar uma máquina diretamente à Internet. Coloque algum tipo de firewall entre a máquina e a Internet. Isso permite que você faça monitoramento de segurança e rede sem sobrecarregar o servidor. Pessoalmente, acho que a segmentação de rede e função frequentemente simplifica a solução de problemas da rede, embora, ocasionalmente, a complexidade adicional torne a análise mais difícil.

A política de firewall mais segura, mas mais irritante de gerenciar, é negar tudo e permitir explicitamente apenas o tráfego que você deve permitir. Isso é irritante, porque é necessário atualizar com freqüência a política de firewall, pois a rede precisa mudar.

Eu também sugeriria o uso de algum tipo de firewall de interface no servidor - a defesa em profundidade é a chave. O uso de portas não padrão para serviços relacionados à administração não prejudica. fail2ban está bem. Responda às perguntas mais específicas sobre aplicativos de segurança no Serverfault para encontrar mais idéias.

A segurança é como a piada sobre os dois caminhantes e o urso - embora nunca se possa alcançar uma segurança perfeita, é útil ser um alvo mais difícil do que os outros caras.

Algumas pessoas apontaram para o Manual de Segurança do Debian . Isso deve ser perfeitamente adequado para tudo, exceto requisitos militares.

Muitas pessoas pensam que ser ridiculamente paranóico é legal ou profissional ou algo assim. É não , é apenas irritante para outros administradores e outright repressivo para seus usuários. A maioria das coisas que você verá recomendadas são apenas trabalhos falsos para se sentirem úteis para o administrador paranóico, mas não realmente úteis, pois a violação de segurança real provavelmente será causada por um sistema não suficientemente atualizado e / ou por uma fonte interna.

Dito isto, considero um dos meus princípios não confiar em nada na rede local, mais do que em qualquer coisa da Internet. Portanto, eu configuro tudo para exigir autenticação, mesmo na rede local. Criptografo e autentico todo o tráfego entre todos os computadores usando IPsec.

Estou no processo de conversão para criptografia de disco completo para todos os meus servidores.

Eu instalo apenas os serviços que eu uso. Eu não tenho um firewall; Eu configuro os serviços necessários para exigir autenticação ou limitá-los (pela própria configuração do programa ou pelos TCP-wrappers) a determinados IPs. A única coisa que eu preciso bloquear usando o iptables foi memcached, pois ele não tinha arquivo de configuração e não utilizava TCP-wrappers.

Uso boas senhas geradas aleatoriamente para minhas contas e confio no meu servidor SSH (e em todos os outros serviços) para manter aqueles que não sabem a senha. fail2bané apenas para aqueles com espaço limitado para arquivos de log, IMO. (Você deve ter senhas boas o suficiente para poder confiar nelas.)

Veja este bom manual em www.debian.org/doc/manuals/securing-debian-howto/

Pessoalmente, mudo a porta ssh e uso fail2ban + denyhosts. E bloqueio tudo o que não é necessário. Quanto mais você bloqueia, menos se preocupa.