Segurança do servidor remoto: manipulando ferramentas do compilador

6

Gostaria de remover ferramentas de compilação ( gcc , make , ...) de um servidor de produção remoto, principalmente por motivos de segurança.

Antecedentes:
O servidor executa um aplicativo da Web no Linux. Considere Apache preso. Caso contrário, somente o OpenSSHd está voltado para a rede pública. É claro que não há compilador dentro da cadeia, então é sobre o sistema operacional fora de qualquer cadeia.

Esta é a minha lista pessoal de PRO / CON (referente a remoção) até o momento:

PRO:

  • Eu estava lendo algumas sugestões para remover as ferramentas do compilador, a fim de inibir a criação personalizada de trojans, etc., de dentro do host, se um invasor obtivesse permissões de usuário não privilegiadas.

CON:

  • Eu não posso viver sem Perl / Python e um trojan / qualquer coisa que possa ser escrita em uma linguagem de script como essa, então por que se preocupar em remover o gcc et al. em tudo.
  • Há uma necessidade de construir novos kernels Linux, bem como algumas ferramentas de segurança da fonte diretamente no servidor, porque o servidor é executado no modo de 64 bits e (no meu entender) não consigo (cross-) compilar localmente / em outros lugares devido à falta de outro sistema de hardware de 64 bits.

OK, então aqui estão minhas perguntas para você:

(a) A minha avaliação PRO / CON está correta?

(b) Você conhece outros PROs / CONs para remover todas as ferramentas do compilador? Eles pesam mais?

(c) Quais binários devo considerar perigosos se a declaração PRO fornecida for válida? Apenas gcc , ou também make , ou o que mais? Devo remover os pacotes de software enitre que vêm com eles?

(d) Não há problema em mover esses binários para um diretório acessível apenas quando não são necessários? Ou há um ganho na segurança se eu "scp-los" toda vez?

Obrigado!

    
por chmeee 19.05.2010 / 15:02

2 respostas

6

Muitas pessoas removem compiladores e ferramentas de compilador porque eles podem, teoricamente, ser usados para explorações. Eu acho que é antiquado. Minha experiência ultimamente tem sido que, se eles puderem entrar, eles também poderão usar suas ferramentas, então remover coisas como compiladores e emacs, e lixo como esse, não adiciona muito à sua segurança geral.

Eu seria extremamente cuidadoso com os serviços que eu executava na máquina: tudo o que se conecta ao exterior é uma vulnerabilidade em potencial. Caso contrário, só removeria os compiladores para manter meus programadores honestos. Eu não acho que isso acrescente muita segurança hoje em dia.

    
por 19.05.2010 / 16:08
1

A sabedoria comum de "maneira correta de fazer as coisas" é colocar o mínimo necessário nos servidores. Se você não precisa dos compiladores, não os coloque lá. É mais uma coisa que, se quebrada, um cracker do sistema poderia potencialmente usar contra o seu sistema, e introduz mais binários que poderiam ter erros neles que podem ser aproveitados.

Também libera espaço no servidor.

Dito isso, há muitos pequenos escritórios e pequenas empresas (e pessoas que não analisam segurança ou práticas recomendadas) que deixam compiladores e ferramentas extras em seus servidores e não consideram um grande negócio.

Se você quiser jogar pelo seguro, remova-os. Instale binários que você pré-construa ou teste em outra máquina ou instale a partir de repositórios confiáveis. Isso também economizará espaço e otimizará seus backups um pouco.

Se for um servidor de produção crítico, você provavelmente não deveria estar jogando com configurações de kernel de teste desconhecidas nele. Você estaria construindo em outro hardware e depois migrando. Normalmente, usamos apenas os kernels "bons o suficiente" dos repositórios de escolha de nossa distro para nossa plataforma, então não há recompilação no nosso caso.

    
por 19.05.2010 / 15:40