Segurança no sistema Unix

1 – Introdução

Este artigo reúne uma série de informações sobre segurança de sistemas UNIX que foram retiradas de diversas fontes (ver referências). O propósito deste documento é enumerar alguns pontos básicos que devem ser vistos pelos administradores de sistemas. Veremos o checklist abaixo:

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.

Segurança dos dados

• Os backups devem ser armazenados em local seguro;
• Deve existir um esquema de recuperação dos dados;
• A rede deve possuir um sistema de no-break e ser estabilizada;
• Os cabos de rede devem ser protegidos com exposição (não ficar esparramado pela sala);
• Armários com informações sigilosas devem permanecer trancados;
• Fitas, listagens e outras mídias com informações sigilosas devem ser destruídos.

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;
• Cuidado ao usar xauth/xhost para que outros não leiam a tela;
• Não coloque mensagens de bem-vindo ao site (permitido somente acesso autorizado).

Segurança na rede

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;
• Filtrem 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;
• Qualquer serviço UDP que responda pacotes de entrada estão sujeitos 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 comandos “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 tomada 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 a partir 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 existência 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 patches no sistema (a instalação de patches pode alterar a configuração de alguns pontos do SO)

Prevenções contra spoofing
• No roteador
• Bloqueie soure routing
• Aplique filtros que bloqueie 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.

Segurança de FTP

• Tenha certeza que da existência do /etc/ftpusers com todas as contas dos sistemas
• 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
Segurança 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 conexões dial-up devem ser registradas (log)
• O programa SATAN pode encontrar vários destes problemas

Segurança de contas

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

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

Conta guest
• Limite o tempo de conexão
• Evite o uso de nome padrão como guest
• Use senha forte
• Use shell restrito
• Se possível a umask deve ser 077
Segurança de sistemas de arquivos

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

Segurança de device
• /dev/null, /dev/tty e /dev/console devem ter direito de leitura para todos, mas nunca de execução
• As maiorias 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

Segurança de script
• Nunca habilite SETUID/SETGID para shell script
• Scripts sempre devem ter o nome de arquivos completo
• Mínimo de sistemas de arquivos com permissão de escrita
• Use somente SETUID/SETGID onde for necessário
• Tenha certeza de que arquivos importantes são acessados somente por pessoas autorizadas
• O programa COPS pode encontrar muito destes problemas

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 regularmente os arquivos btmp, wtmp, syslog, sulog,…
8. Envie e-mail ou Pager automático para o administrado quando da ocorrência de qualquer incidente suspeito

Conclusão:

Um sistema Unix é totalmente orientado a arquivos, tudo nele é arquivo. Seus comandos são na verdade arquivos executáveis, que são encontrados em lugares previsíveis em sua árvore de diretórios, e até mesmo a comunicação entre entidades e processos é feita por estruturas parecidas com arquivos. O acesso a arquivos é organizado através de propriedades e proteções. Toda a segurança do sistema depende, em grande parte, da combinação entre a propriedade e proteções setadas em seus arquivos e suas contas de usuários.

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)

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

w

Conectando a %s

%d blogueiros gostam disto: