Checklist de seguranca para sistemas UNIX 

Tradutor/autor: Verdade @bsoluta
Palavras Chave: UNIX  -  checklist  -  segurança  -  seguranca fisica  -  seguranca de rede 
Ultima atualização: 08/10/98 - CONTINUA...
 
  1. Introdução
  2. Seguraça Física
  3. Seguraça de Rede
  4. Segurança de Contas
  5. Segurança de Sistemas de Arquivos
  6. Testes de Segurança
  7. Referências
1 - Introdução
Este documento reune uma série de informações sobre segurança de sistemas UNIX que foram retiradas de diversas fontes (ver referências) além de contar com dicas vistas pelo autor durante o seu dia-a-dia em empresas. O propósito deste documento é enumerar alguns pontos básicos que devem ser vistos pelos administradores de sistemas. 

2 - Segurança Física

  1.  Segurança da console
    • Deve estar em uma sala fechada (com número limitado de cópias das chaves)
    • A sala não deve possuir entradas alternativas
    • Se possível deixar os servidores sem teclado (eu faço isso :)
  2. Segurança dos Dados
    • Os backups devem ser armazenados em local seguro
    • Deve existir um esquema de reculperação dos dados
    • A rede deve possuir um sistema de no-brack e ser estabilizada
    • Os cabos de rede devem ser protegidos com expossição (não ficar esparamado pela sala)
    • Armários com informações sigilosas devem permanecer trancados
    • Fitas, listagems e outas mídias com informações sigilosas devem ser destruidos
  3. Medidas de Segurança para Usuários
    • Usar protetor de tela ou sair do sistema quando estiver ausente
    • Não escrever a senha na mesa ou monitor (isso acontece :)
    • Cuidado ao usar xauth/xhost para que outros não leiam a tela
  4. Não coloque mensagens de bem-vindo ao site ( permitido somente acesso autorizado )
3 - Seguraça de Rede
  1. Filtragem
    • Não habilite serviços que não serão utilizados ( inetd.conf )
    • Crie uma lista de controle de acesso /var/adm/inetd.sec para dizer quais hosts podem conectar
    • Filtre no roteador os serviços desnecessários
    • Instale o TCPwrapper para controle de login
    • Se sua rede estiver na Internet, instale um firewall
    • Tenha certeza de que somente os serviços requeridos são permitidos através dos filtros do seu roteador. Em particular se os serviços abaixo não forem requeridos, filtre-os em seu roteador
    NOME PORTA PROTOCOLO NOME PORTA PROTOCOLO
    echo 7 TCP/UDP login 513 TCP
    systat 11 TCP shell 514 TCP
    netstat 15 TCP printer 515 TCP
    bootp 67 UDP biff 512 UDP
    tftp 69 UDP who 513 UDP
    link 87 TCP syslog 514 UDP
    supdup 95 TCP uucp 540 TCP
    sunrcp 111 TCP/UDP route 520 UDP
    NeWS 144 TCP openwin 2000 TCP
    snmp 161 UDP NFS 2049 UDP/TCP
    xdmcp 177 UDP X11 6000 a 6000+n TCP
    exec 512 TCP n é o número máxino se sevidores X permitido
    • Qualquer serviço UDP que responda pacotes de entrada estão sugeitos a ataques  DoS (Denial of Service). Veja o aviso do CERT CA-95.01 para maiores detalhes.
    • Filtros são difíceis de serem implementados corretamente. Para maiores informações sobre filtros de pacote, veja na referência (Firewall an Internet Security  e Building Internet Firewalls)
    • Comandos "r"
      • Se não for necessário a utilização de comandos "r"
        • Desabilite todos os comandor "r" (rlogin, , rsh, rcp, etc), isso talvez aumente o risco de captura de senhas com sniffer, mas os comandos "r" são uma verdadeira mina de insegurança e ataques.
      • Se os comando "r" forem realmente necessários
        • Use versões mais seguras dos comandos "r" (O pacote logdaemon de Wietse Venema conte versões mais seguras de comandos "r", estas versões podem ser configuradas para consultar somente o arquivo /etc/hosts.equiv e não o  $HOME/.rhosts. Ele possui uma opção para desabilitar o uso de  coringas '+')
        • Filtre as portas TCP 512, 513 e 514 no roteador no caso de usar comandos "r" (isto evita que pessoas de fora do seu domínio explorem estes comandos, mas não evita que pessoas dentro do domínio explorem os comandos, para isso é necessário desabilitar os comandos :)
        • Use tcp_wrappers para delegar direito de acesso e login aos serviços de rede
    • /etc/hosts.equiv
      • É recomendável que a seguinte ação seja tomado usando ou não os comandos "r"
        • Verifique se o arquivo /etc/hosts.equiv é necessário, se estiver usando comandos "r", este arquivo permite que seu computador confie em outros computadores, em outras palavras, a autenticação será por IP e não por senha. Programas como rlogin, podem ser usados para logar com uma conta semelhante na sua máquina apartir de um computador declarado como confiável, sem a solicitação se senha. Se não existe a necessidade do uso de comandos "r" ou se não existe a relação de confiança com outros hosts, este arquivo deve ser removido do sistema. Se o arquivo não existir, você não terá problemas caso algum comando "r" seja habilitado acidentalmente
      • Se houver a necessidade do uso do arquivo /etc/hosts.equiv
        • Tente manter um pequeno número de relações de confiança
        • Use netgroups para facilitar o gerenciamento, caso os serviços NIS (YP) ou NIS+ estejam rodando
        • Mantenha relação de confiança somente com hosts do seu domínio ou sobre seu gerenciamento
        • Tenha certeza de usar o nome completo da máquina (Ex. curupira.absoluta.org)
        • Tenha certeza da não existencia de coringa '+' em qualquer parte do arquivo
        • Nunca use ! ou # neste arquivo, este não são caracteres de comentário para este arquivo
        • Tenha certeza de que o primeiro caracter deste arquivo não seja '-', para maiores informações veja o aviso CERT CA-91:12
        • Configure a permissão do arquivo para 600
        • Tenha certeza de que o dono do arquivo é o root
        • Cheque estes pontos após a instalação de patchs no sistema ( a instalação de  patches pode alterar a configurção de alguns pontos do SO)
  2. Prevenções contra spoofing
    • No roteador
      • Bloqueie soure routing
      • Aplique filtros que bloquei a entrada de pacotes com endereço de origem igual ao da rede interna
    • Use o nome completo do host em qualquer sistema de arquivos (NFS, hosts.equiv, ...)
    • Se possível não utilizar hosts.equiv ou .rhosts (ative um shell via cron para remover estes arquivos automaticamente)
    • Arquivos .rhosts e .netrc (se necessários), devem ter permissão 600
  3. Segurança de FTP
    • Tenha certeza que da existência do /etc/ftpusers com todas as contas dos sistema
    • Mínimo de permissões e mínimo de contas
    • Sempre log as transações de FTP e olhe os logs :)
    • Se possível tire a permissão de gravação para os diretórios
  4. Segurança de MODEM
    • Todos os MODEMs devem possuir uma senha adicional de dial-up
      • Tenha certeza que /etc/d_passwd não pode ser quebrado usando CRACK
      • Uma senha por usuário
      • Usuários que não precisam de acesso devem ser bloqueados
    • Todas as conecxões dial-up devem ser registradas (log)
  5. O programa SATAN pode encontrar vários destes problemas
4 - Segurança de Contas
  1. Segurança de Senhas
    • Toda conta deve ter o campo passwd preenchido
    • Somente o root deve ter UID 0
    • Evitar o uso de arquivos .netrc
    • Contas com várias tentativas de login inválidas devem ser desativadas
  2. Conta root
    • root deve logar somente da console (/etc/securtty)
    • O path do usuário root nunca dever ter um ponto (.)
    • Número de pessoas que usam root deve ser limitado
    • Use uma senha forte
    • Nunca deixa o shell de root logado (terminou o servico faça logout)
    • Troque a senha de root a cada três meses
    • Faça login com um usuário comum depois de "su" para root
    • Se possível a umask deve ser 077
    • Sempre use o caminho completo, quando não estiver na console
    • Não permita que outros usuários tenham permissão de escrita nos diretórios que estão no PATH do root
    • Se possível o diretório tmp deve ter restrições de gravação
  3. Conta guest
    • Limite o tempo de conecxão
    • Evite o uso de nome padrão como guest
    • Use senha forte
    • Use shell restrito
    • Se possível a umask dve ser 077
5 - Segurança de Sistemas de Arquivos
  1. Segurança de NFS
    • Somente use NFS se necessário, aplique os últimos patchs
    • Cuidado ao utilizar /etc/exports ou ( /etc/dfs/dfstab em SUN )
    • Somente permissão de leitura se possível
    • Não use SUID se possível
    • Nome de host deve ser informa completo
  2. Segurança de device
    • /dev/null, /dev/tty e /dev/console devem ter direito de leitura para todos, mas nunca de execução
    • A maioria dos outros arquivos não devem ter direito de leitura e execução para usuários mortais
    • /dev/kmem, /dev/dmem e /dev/mem deve ter permissões somente para o root
  3. Segurança de script
    • Nunca habilite SETUID/SETGID para shell script
    • Scripts sempre devem ter o nome de arquivos completo
  4. Mínimo de sistemas de arquivos com permissão de escrita
  5. Use somente SETUID/SETGID onde for necessário
  6. Tenha certeza de que arquivos importantes são acessados somente por pessoas autorizadas
  7. O programa COPS pode encontrar muitos destes problemas
6 - Testes de Segurança
  1. Sempre tenha o ultimo patche instalado
  2. Inscreva-se em listas de segurança
  3. Use o SATAN para teste de segurança de rede
  4. Use o COPS para checagem de sistema
  5. Use TIGER para ver como anda a conta do root
  6. Use CRACK para checagem de senhas
  7. Verifique regularmenet os arquivos btmp, wtmp, syslog, sulog, ...
  8. Envie e-mail ou pager automático para o administrado quando da ocorrência de qualquer insidente suspeito 
7 - Referências
  • http://www.idiom.com/~lorraine/securecheck.html
  • Pratical Unix and Internet Security (Simson Garfinkel e Gene Spafford)
  • Firewall and Internet Security: Repelling the Wily Hacker (William R. Cheswick e Steven M. Bellovin)
  • Computer Security (Deborah F. Russell e G. T. Gangemi)
  • Building Internet Firewall (Brent Chapman e Elizabeth D. Zwicky)
  • Computer Crime: A crimefighter's Handbook - Computer Security (David J. Icove, David Seger, Karl Icove e Vonstorch)

<=

http://www.absoluta.org      ---oOo---      verdade@absoluta.org

Copyright © 1998 - 1999  Verdade @bsoluta