Linux in Brazil (Bastion Host )

Talvez na tentativa de tornar a vida dos Administradores mais fácil, a maioria das distribuições de Linux já define um conjunto de contas de usuários e grupos. No nosso caso, isso pode ser um alvo para um ninho de atacantes.

Antes de mais nada, vasculhe os arquivos /etc/passwd e /etc/shadow e delete os usuários que não serão utilizados no sistema.

Evite que contas de usuários não possuam senha. O seguinte comando perl denuncia as contas sem senha.

[root@darkstar]# perl -F: -ane 'print if not $F[1];' /etc/shadow


games::11459:0:99999:7:::

Temos de fazer o mesmo com o arquivo /etc/group .

Nota: Cuidado ao deletar usuários ou grupos que têm arquivos associados aos mesmos.

Política de senhas

Não é necessário dizer que todas as senhas de contas de usuários deveriam ter um cuidado especial. Pelo menos com 8 caracteres e que não sejam alguma palavra de dicionário. Alguns programas, como o Crack, uma ferramenta desenvolvida por Alec D.E. Muffett possui algumas técnicas de quebra de senhas. (ftp.cert.org)

Além disso, vamos forçar os usuários a mudarem de senha em um período de tempo que deve ser estipulado em /etc/login.defs . Quando deveríamos mudar a senha?

- Pelo menos a cada 3 meses;

- Toda vez que algum empregado do sistema saia do mesmo;

- Toda vez que haja suspeita do sistema estar comprometido;

Smart Account

Iremos criar uma segunda conta com UID 0. Pode parecer estranho , mas uma grande maioria dos atacantes menos habilidosos (script kiddies) podem ser descobertos dessa maneira. Portanto, utilizaremos a nova conta com UID 0 que chamaremos de admin para as tarefas normais de administração do root. Logins e ações com o usuário root serão um sinal de alerta de que algo está pode estar errado.

Em /etc/passwd e /etc/shadow, respectivamente:

admin:x:0:0:admin:/home/admin:/bin/bash
admin:$1$LLjA1aTW$FSjjsJS/SAhshas:11459:0:99999:7:::

Programas SETUID

Programas que executam setuid, especialmente aqueles com setuid de root, são um grave problema de segurança. Os programas com SETUID distribuidos são 'teoricamente' seguros; no entanto, várias vulnerabilidades ja foram descobertas no passado e com certeza serão descobertos novos problemas no futuro.

A maneira mais fácil de se evitar esse tipo de problema é minimizar o número de programas com setuid. Pense duas vezes antes de instalar um programa que precisa executar com setuid em um bastion host.

Vamos vasculhar o sistema procurando programas que contenham setuid de root - os mais problemáticos.

[root@darkstar]# find / -user root -perm -4000\
   -exec ls -las {} \; > setuidfiles

Como podemos perceber, a grande maioria dos arquivos não serão utilizados. Portanto podemos retirar o setuid ou mudar as permissões para que somente root tenha acesso a elas. Portanto, iremos retirar o setuid de todos os arquivos e depois manualmente adicionar aqueles que iremos usar.

[root@darkstar]# for I in `cat setuidfiles`;do chmod u-s $I;done

Agendando processos com CRON

Periodicamente, o serviço CRON executa comandos agendados pelos usuários. Normalmente, todos os usuários podem submeter arquivos crontab (cron table). Isso pode ser restringido nos arquivos cron.allow e cron.deny . É importante edita-los para mantermos um controle de quem está agendando comandos e quais são eles. O ideal seria permitir somente as contas root e admin criar contrab files,para administração de logs, eventos de segurança, etc. No entanto, a política e necessidade de cada site pode variar.

Super serviço INETD

O serviço inetd gerencia outros serviços, sendo que muitos são um ponto crítico de segurança, como rlogin e rsh, portanto merece uma maior atenção.

Atualmente as máquinas em geral podem trabalhar com 2 variantes:

- inetd (Internet services daemon) ou

- xinetd (extended Internet services daemon)

O intuito do texto não é apontar as diferenças dos dois serviços, mas ajudar na configuração de ambas.

Inetd

Consulta o arquivo /etc/inetd.conf . Somente comente as linhas dos serviços que não deseja utilizar.

Xinetd

Não mais utiliza o arquivo /etc/inetd.conf para definir os serviços. Agora o diretório /etc/xinetd.d contém uma série de arquivos destinados a definir as caracteristicas de cada serviço. (cat /etc/xinetd.d/* | grep disable)

Definindo Daemons

Diversos daemons são inicializados pelos scripts de boot localizados em /etc/rc.d/ . No entanto, muitos deles não iremos utilizar, e como ja foi dito, não é nada prudente rodar aplicativos que podem ser futuramente explorados. Em diversas distribuições o usuário pode utilizar ferramentas que auxiliam na configuração dos daemons a serem inicializados (como o linuxconf, YaST, ...). Para cobrir de uma forma mais geral, vamos deletar os links simbólicos dentro do diretório /etc/rc.d/rcX.d/ - onde X é o RunLevel. Caso futuramente seja necessário algum serviço, podemos resolver de 2 maneiras: criando nossos próprios scripts ou criando novamente os links. Se você deseja manter a ordem estabelecida pela distribuição:

[root@darkstar]# ls /etc/rc.d/rc3.d/ > ~/rc3Backup

Considerando que não iremos rodar routed em nosso bastion:

[root@darkstar]# rm /etc/rc.d/rc3.d/K55routed

E fazemos o mesmo para o resto.

Caso futuramente ocorra necessidade de um script de boot de um serviço qualquer, digamos o sendmail, faríamos:

[root@darkstar]# ln -s /etc/rc.d/SendmailScript /etc/rc.d/rc3.d/S58Sendmail

É bom lembrar que a ordem especificada no número (no exemplo acima 58) é de extrema importância. Caso algum script esteja com uma ordem incoerente, erros irão aparecer.

Depois da limpeza, o combo ps ax & netstat -nat mostra que nosso sistema está muito melhor do que antes:

  PID TTY      STAT   TIME COMMAND
    1 ?        S      0:05 init
    2 ?        SW     0:00 [kflushd]
    3 ?        SW     0:00 [kupdate]
    4 ?        SW     0:00 [kpiod]
    5 ?        SW     0:00 [kswapd]
    6 ?        SW<    0:00 [mdrecoveryd]
   48 ?        SW     0:00 [khubd]
  334 ?        S      0:00 syslogd -m 0
  344 ?        S      0:00 klogd
  370 ?        S      0:00 /usr/sbin/atd
  385 ?        S      0:00 xinetd -reuse -pidfile /var/run/xinetd.pid
  426 ?        S      0:00 crond
  452 tty1     S      0:00 login -- root
  453 tty2     S      0:00 /sbin/mingetty tty2
  454 tty3     S      0:00 /sbin/mingetty tty3
  460 tty1     S      0:00 -bash
  768 tty1     R      0:00 ps ax

Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State

Syslog

Syslog é um serviço responsável por gravar em arquivos diversas informações geradas pelo kernel e outros programas. Bem configurado, ele pode ser uma poderosa ferramenta para nos alertar contra intrusos. No entanto, o ideal seria que existisse outro bastion host responsável em ser um centro de logs, ja que, uma vez que o atacante tome controle de nosso bastion (isso *pode* acontecer e é melhor estar preparado..) ele terá privilégios para deletar qualquer log que considere alarmante. Portanto, caso nosso bastion caia, ainda teríamos um último grito de alerta em outra máquina indicando o perigo.

O arquivo de configuração é /etc/syslog.conf . Daremos 1 exemplo de arquivo de configuração para um bastion client syslog.

#Bastion client - scream out our last hope  :-)
#

# Emergências - avise todos logados no sistema

*.emerg;user.none *

# Enviar mensagens importantes ao nosso bastion log center

*warning;lpr,local1.none @logcenterbastion daemon,auth.info @logcenterbastion

# Enviar informações locais ao nosso bastion log center

local2.info;local0,local7.debug @logcenterbastion

# Manter possíveis erros de empresora local lpr.debug /var/adm/lpd-errs

# sudo info para local 2 - manter local local2.info /var/adm/sudolog

# mensagens do kernel - locais kern.info /var/adm/kern.log

Syslog-ng

Uma nova opção de sistema de logs é syslog-new generation. Ele é um sistema aperfeiçoado que, além de ordenar mensagens baseados no par prioridade/serviço , também é possível filtar com expressões regulares. Portanto, conseguimos maior pode na admistração de logs, evitando lixo e considerando somente as mensagens realmente importantes.

http://www.balabit.hu/en/products/syslog-ng/

Montando as partições Read-only

Um sistema em produção deve montar somente as partições /var e /tmp write-read, sempre recebendo arquivos gerados por daemons. Deixando as demais partições read-only impossibilita a alteração de arquivos, instalação de root kits, worms e trojans.

Editando o arquivo /etc/fstab :

LABEL=/1      /      ext2    auto,ro,nouser               1 1
LABEL=/home   /home  ext2    auto,ro,nouser               1 2
LABEL=/tmp    /tmp   ext2    defaults,nosuid,noexec       1 2
LABEL=/usr    /usr   ext2    auto,ro,suid,exec,nouser     1 2
LABEL=/var    /var   ext2    defaults,nosuid              1 2
/dev/hda5     swap   swap    defaults                     0 0

As alterações do arquivo devem se adequar as partições do seu sistema.

Compiladores e interpretadores

Após todas as devidas instalações e configurações é necessário que o sistema possua compiladores? Essa é uma discussão delicada. Um atacante que conseguisse uma conta de um usuário não privilegiado poderia utilizar algum furo de aplicativo para eventualmente compilar algum exploit e conseguir uma shell de root. No entanto, além da maioria dos "root kits" (texto adiante) conter somente binários, os bastions em geral necessitam de constante upgrade. A cada nova versão ou patch fix seria necessário instalar os compiladores para realizar o serviço. Ainda assim, o atacante poderia ele mesmo instala-los, caso precisasse. Portanto, estamos na dúvida entre maior comodidade ou segurança total.

No caso, pode-se seguir 2 passos:

- setar os modos dos compiladores e interpretadores somente para root; ou

- remover todos os compiladores e interpretadores e quando precisarmos de upgrade, compile externamente e depois faça o transporte;

Segurança no protocolo TCP/IP

O protocolo utilizado na internet TCP/IP foi codificado para ser dinâmico e tolerante a falhas. No entanto, na época os desenvolvedores não tinham idéia do crescimento da internet e que o problema de segurança seria tão grave. A pilha TCP/IP possui algumas deficências como: incapaz de autenticação, não garante integridade e privacidade dos dados. Portanto, icmp redirects, source routing, entre outros, costumam ser "honrados". Ambos foram ( e continuam ) utilizados largamente para desferir ataques contra sites.

Essa seção tem como objetivo tentar cobrir os parâmetros mais famosos, que geralmente se encontram em /proc/sys/net/ipv4/ .(linux)

Desativar Ip forwarding

echo 0 > /proc/sys/net/ipv4/ip_forward

- Não há motivos para transmitir pacotes entre interfaces. O default é desabilitado.

Desativar icmp redirects

echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects

- Impedimos que um atacante possa maliciosamente alterar alguma rota

Desativar source_route

echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route

- Utilizado em diversos ataques, isso possibilita que o atacante determine o "caminho" que seu pacote vai percorrer (roteadores) até seu destino. Junto com spoof, isso se torna muito perigoso.

Bogus response

echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses

- Proteção contra responses bogus

Syn flood

echo 1 > /proc/sys/net/ipv4/tcp_syncookies

- Proteção contra ataques de syn flood (inicio da conexão TCP). Tenta conter ataques de DoS.

Outro ponto crítico é: não utilizar de forma alguma RPC (remote procedure call), utilizado por exemplo pelo NFS, em seu sistema! Esse protoloco utiliza uma forma dinâmica de alocação de portas, sendo portanto muito difícil de adequar às regras de firewall. Além disso, tomar extremo cuidado com os pacotes UDP. Eles não tem garantem de forma alguma a origem genuína do pacote, sendo um grave ponto de segurança. Algumas exceções são os serviços de DNS, NTP e syslog.

Guerra contra Root Kits & Worms

Muitas das vezes, nossos atacantes serão pessoas jovens, com ego elevado, cheia de más intenções, mas que na verdade não possuem muito conhecimento real além de executar algumas receitas de bolo fabricadas por terceiros. Mais conhecidos como "Root kits", esses programas além de possuirem exploits para uma ou outra versão de um serviço qualquer, também levam scanners e trojans.

O inconveniente é que muitos deles possuem características próprias que diferem um aos outros e seria realmente muito desgastante ter conhecimento de todos para vereficar se existe algum trojan em uma máquina.

Como exemplo, os componentes do pacote l1on.tar.gz - Worm Lion

addlen    cui220  gpm         install   ps      rpc.statd  syslogd
bnc       cui221  ifconfig    mingetty  pstree  slice2     tcpd
bnc.conf  fix     in.rlogind  netstat   pt07    synscan

Um conjunto de scripts chamado chkrootkit (http://www.chkrootkit.org/) foi criado no intuito de denunciar a existência de diversos rootkits, interfaces em modo promíscuo, logs recentemente deletados entre outros.

TripWire

Tripwire é um sistema de checagem de integridade que compara as propriedades de arquivos e diretórios com informações geradas à priori. Qualquer mudança nesses arquivos é flagrada e logada, incluindo aqueles que foram adicionados ou deletados.

Snort - detectando scans

Snort é um sistema de detecção de intrusos que realiza análise de tráfego de pacotes na tentativa de acusar scans, probes e alguns ataques como buffer overflow, CGI, SMB probes, tentativas de OS fingerprinting, etc. Ele trabalha com vários plugins de alerta e log para: syslog, arquivos de texto ASCII, UNIX sockets, mensagens winpopup para clientes windows usando smbclient, banco de dados (Mysql/PostgreSQL/Oracle/ODBC) ou XML.

Invasão

O que fazer se seu site foi invadido? A primeira atitude é manter a calma. Não entre em pânico. Frequentemente, quando o administrador descobre uma invasão, ja se passou tempo suficiente para que o atacante tenha feito boa parte do que pretendia. Em outras palavras, é necessário pensar cuidadosamente em uma estratégia para definir suas ações a partir desse ponto e principalmente não alertar o atacante sobre sua descoberta até que todas ações de limpeza sejam efetuadas. É nessa hora que os logs e backups fazem a diferença e mostram-se essenciais. Vale a pena lembrar que boa parte dos ataques são *internos*. Seja cuidadoso com quem você irá comunicar sobre o incidente.

Nove passos que podem auxiliar nesse momento:

1-) Não entre em pânico. A diferença entre atitudes desesperadas e atitudes racionais, além de mais segura e eficaz, poupa bastante tempo.

2-) Decida quem deve saber do incidente. Contate um grupo seleto para auxiliar na tarefa.

3-) Verifique logs e backups. Tente definir aonde o falha ocorreu. Faça backup de outros bastions.

4-) Determine o dano causado pelo atacante e como repara-lo. (se possível)

5-) Desconecte a máquina. Se necessário e apropriado, desconecte a máquina. Boas dicas e sugestões de onde seu sistema pode ter sido comprometido pode ser encontrado no FAQ que ISS possui: http://xforce.iss.net/security_library/faqs/compromise.php

6-) Crie um plano para restaurar o sistema.

7-) Comunique as pessoas envolvidas sobre o incidente, quais foram os danos causados e o que se pretende fazer para sanar o problema e não deixa-lo acontecer novamente. Seja honesto com o grupo.

8-) Execute o plano.

9-) Se o atacante era realmente alguem de fora, comunique as autoridades. Envie um email para cert@cert.org ou visite a página http://www.cert.org que contém informações sobre os procedimentos.

Repositório do autor

www.dcc.unicamp.br/~pub/seg/

Bibliografia

Building bastion host: http://www.securityportal.com/topnews/solaris_hardening20000523.html, http://people.hp.se/stevesk/bastion11.html

Bastille Linux: http://bastille-linux.sourceforge.net/

Marcus Ranum's HP: http://pubweb.nfr.net/~mjr/

Livros:
Unix System Administration Handbook - Evi N.,Garth S.,Scott S.,Trent R. H.
Pratical UNIX and Internet Security - Sesbastopol: O'Reilly & Associates. 1996

PDF sobre segurança de redes - Professor Paulo Lício: http://www.dcc.unicamp.br/~paulo/cursos/seg/

Problema de DoS: http://grc.com/dos/grcdos.htm

Syslog-ng: http://www.balabit.hu/products/syslog-ng/

Tripwire: http://www.sourceforge.net/projects/tripwire/

Snort: http://www.snort.org

Cert: http://www.cert.org

Crack: ftp.cert.org

O Arquivo Histórico do BR-Linux.org mantém no ar (sem alteração, exceto quanto à formatação) notícias, artigos e outros textos publicados originalmente no site na segunda metade da década de 1990 e na primeira década do século XXI, que contam parte considerável a história do Linux e do Open Source no Brasil. Exceto quando indicado em contrário, a autoria dos textos é de Augusto Campos, e os termos de uso podem ser consultados na capa do BR-Linux.org. Considerando seu caráter histórico, é provável que boa parte dos links estejam quebrados, e que as informações deste texto estejam desatualizadas.