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


66

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?



11
Ubuntu tem ufw Debian não;) eu estava woundering se as pessoas estavam configurar iptables eles próprios ou usando algum software como FireHol
Thomaschaaf

Eu sempre tendi a escrever as regras do iptables. Eu tenho uma placa de caldeira que faz coisas como soltar todos os fragmentos, pacotes de natal, etc. Qualquer coisa além disso é específica do sistema e geralmente é bastante pequena. Eu não posso estressar fragmentos largos o suficiente ao usar o iptables, btw. Por alguma razão que ainda não pesquisei, o iptables apenas verifica o primeiro fragmento e passa cegamente o resto sem verificar. Na minha opinião, isso faz dos fragmentos uma responsabilidade.
Scott Pacote

3
Uhm ... O Debian tem ufw. packages.debian.org/ufw
womble

Respostas:


50

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

4
Depois de fazer tudo isso, execute o BASTILLE no sistema para procurar qualquer outra coisa. Eu também recomendaria fazer uma verificação completa e insegura do sistema Nessus; em seguida, corrija o que quer que seja alertado.
Scott Pacote

13
Compilar um kernel personalizado não fornece vantagens de segurança, a menos que você realmente saiba o que está fazendo. Você também deixará de mantê-lo atualizado, a menos que o coloque no sistema de gerenciamento de pacotes, o que resultaria em pior segurança.
Adam Gibbins

3
-1 para segurança através da obscuridade. Caso contrário, uma resposta decente.
Dwc 23/05/09

@ Adam - sim, eu sei disso, ainda prefiro ter um núcleo monolítico que consiste apenas em partes que eu preciso. isso provavelmente é muito atrasado, mas ainda assim eu faço. @dwc - é apenas mais um passo que é apenas uma cereja ou, como dizemos cereja, no topo da pilha de coisas desagradáveis ​​e fedorentas.
PQD

11
E você quer dizer sudo não su -
LapTop006

18

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 :)


"... um pequeno número de olhos vs uma terra cheia de olhos." - Eu gostaria que "corporações" percebessem isso, mas a segurança através da obscuridade parece ser a tendência mais seguida. Sim, executar um serviço, como ssh, em uma porta não padrão não impedirá um invasor determinado. Terá, no entanto manter o script kiddies de distância - alguém correndo um ataque de dicionário sobre uma faixa de endereços IP na porta 22.
L0neRanger

12
  • 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)

Você recebe um voto positivo por desativar a autenticação de senha.
Derobert 03/06/2009


6

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.


5

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.


+1 para uma boa resposta. Devo salientar que a negação padrão não é chata de gerenciar, se você a abordar corretamente. Certamente você deve saber o que está permitindo, certo? De fato, isso deve ser escrito em linguagem simples como uma declaração de política. Se você não está fazendo isso como rotina normal, não está fazendo seu trabalho como administrador. Se você é, é simples atualizar as regras do firewall.
Dwc 23/05/09

Muito bons pontos. Toda organização deve ter uma declaração de política de segurança em linguagem simples. À medida que as necessidades da organização mudam, a declaração de política deve ser atualizada. Se apenas o administrador planejasse a implementação de regras de firewall e o CYA, um administrador inteligente manteria essa declaração de política mesmo que o gerenciamento da organização não se preocupe em pensar em segurança.
Pcapademic 23/05/2009

4

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.)


3

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.


4
Ugh. Você me teve até "mudar a porta SSH". Não há sentido. Especialmente quando um Joe Schmoe com tempo suficiente nas mãos pode digitalizar sua porta e descobrir instantaneamente em que porta o SSH está sendo executado. Ele declara o nome do serviço (e a versão do servidor) assim que você se conectar.
Matt Simmons

3
Sim, eu sei que qualquer um pode digitalizar sua porta e descobrir a porta certa. Mas a maioria dos ataques ocorre na porta padrão. Apenas tente obter algumas estatísticas alterando a porta.
Vihang D
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.