Considere o cenário proposto em um incidente de segurança ocorrido na “Fábrica de Brinquedos – Gift & Gift Ltda.”, onde o administrador de um servidor DNS achou estranho o acesso ao disco, uma vez que já eram mais de 23h de uma sexta-feira, e o acesso está muito grande. Naquela hora não havia ninguém mais na empresa, além dele, que estava acompa- nhando uma migração de um dos servidores de bancos de dados.
Ao consultar a máquina, o administrador percebeu que, além da porta 53 do DNS e 25 do MTA Exim, destinado a mensagens internas do sistema, havia uma outra porta ativa, a porta 666, como indicado na tabela 4.1.
Conexões Internet Ativas (sem os servidores)
Proto Recv-Q Send-Q EndLocal EndRemoto Estado PID/Program name tcp 0 0 0.0.0.0:53 0.0.0.0:* OUÇA 2747/portmap
tcp 0 0 127.0.0.1:25 0.0.0.0:* OUÇA 3106/exim4 tcp 0 0 0.0.0.0:666 0.0.0.0:* OUÇA 3628/inetd Command Pid User FD Type Device Size Node Name bind 2747 daemon 3u IPv4 10629 UDP *:dns
exim4 3106 Debian-exim 3u IPv4 12046 TCP localhost:smtp (LISTEN) bind 3323 root 6u IPv4 12845 UDP *:dns
inetd 3676 root 4u IPv4 20467 TCP *:sombra (LISTEN) Conexões Internet Ativas (servidores e estabelecidas) Proto Recv-Q Send-Q EndLocal EndRemoto Estado tcp 0 0 0.0.0.0:111 0.0.0.0:* OUÇA
tcp 0 0 127.0.0.1:25 0.0.0.0:* OUÇA tcp 0 0 0.0.0.0:666 0.0.0.0:* OUÇA
tcp 4234 0 92.168.0.150:666 212.168.0.171:32776 ESTABELECIDA tcp 0 978 212.168.0.171:32776 92.168.0.150:666 ESTABELECIDA
Intrigado com a porta 666, o administrador resolveu consultar mais detalhes sobre o processo que estava ativo na respectiva porta. Buscou mais informações com o comando lsof – a saída do comando lsof é mostrada na tabela 4.2.
Notou um nome estranho e muito sugestivo para o respectivo serviço, o que estava notoria- mente qualificando como uma possível backdoor. Com essa identificação, a prova de uma violação do sistema está qualificada, caracterizando um incidente de segurança crítico.
Figura 4.1 Tabela de serviços TCP em estado ‘Listen’. Figura 4.2 Tabela de saída do comando ‘lsof’. Tabela 4.3 Tabela de saída do comando ‘netstat’.
Ca pí tu lo 4 - S er vi ço s d e R ed es – P ar te 1
Diante dessas informações, o administrador resolveu coletar mais informações das atividades de conexões estabelecidas com o servidor, buscando identificar se a suposta Backdoor estava sendo utilizada. Usou novamente o comando netstat, objetivando ter todas as informações sobre as conexões estabelecidas. A saída do comando netstat é mostrada na tabela 4.3. Antes de tomar qualquer ação reativa, o administrador precisava saber que aplicação estava ativa na respectiva porta. Então, habilmente recorre novamente ao shell do sistema, mas dessa vez usou o comando fuser para ter mais informações.
Ao usar o comando fuser, como é ilustrado na figura 4.1, ficou claro que o processo vinculado ao deamon inetd na realidade é a shell bash, o que deixava notório que aquela porta era uma clássica backdoor implementada no inetd.conf, o que também ratificava o fato de o servidor em questão estar comprometido.
xninja# fuser -v 666/tcp USER PID ACCESS COMMAND 666 root 2321 f . . . . inetd root 2321 f . . . . bash xninja#
Diante do que foi relatado, assinale V (verdadeiro) ou F (falso):
( ) Uma Backdoor como a ilustrada pode ser instalada por um invasor, mas também por um insider (empregado mal-intencionado) ou um gray hat (pseudo consultor prestador de serviço). ( ) Uma backdoor dessa categoria é tão engenhosa que não é detectável no sistema, mesmo por um administrador experiente que realize o procedimento de checklist de serviços de rede, relacionando os processos e serviços ativos.
( ) É muito comum em uma invasão de sistemas o invasor instalar rootkits que, além de implementarem backdoors no sistema, adulteraram binários de comandos clássicos (netstat, fuser, ps, lsof e outros) para evitar que o administrador as identifique. Entretanto, a backdoor encontrada foi implementada utilizando recursos do próprio sistema.
Runlevel
Depois de terem sido realizadas todas as checagens e elencados todos os serviços que estão ativos no nosso sistema, é importante avaliar se realmente é necessário que todos os serviços inicialmente identificados como ativos deveriam estar ativos. Caso não, podemos desativar os que não são necessários, melhorando a performance e a segurança do sistema. No Debian, podemos consultar os diretórios dos níveis de execução (run level), baseados no System V, que é onde ficam todos os programas que serão ativados na inicialização do sistema. O nível de execução padrão do Debian é o nível 2. Cada distribuição Linux organiza seu sistema de níveis de execução de uma maneira diferente. Para identificar como cada uma delas trabalha, podemos consultar o arquivo /etc/inittab, que controla o processo init, o primeiro processo a ser iniciado no sistema. Consultando o diretório do nível de execução padrão do Debian para identificar os serviços inicializados por padrão:
# ls -l /etc/rc2.d
Figura 4.1
Saída do comando ‘fuser
H ar de ni ng e m L inu x
Repare que são todos links simbólicos que apontam para o diretório /etc/init.d, diretório onde ficam todos os scripts que controlam os daemons do sistema. Caso não queira que determinado serviço seja ativado na execução, basta apagar o link simbólico dele do dire- tório do nível de execução que está sendo utilizando, que nesse exemplo é o runlevel 2. Como exemplo, podemos remover o link simbólico do exim4, um servidor de e-mail padrão do Debian. Todavia, em muitos casos um MDA interno é relevante para os serviços que ficaram ativos, tudo é uma questão de qual a finalidade do servidor. Imagine que a finalidade nesse exemplo é de J em um servidor firewall: não existe necessidade de deixarmos um servidor de e-mail rodando com um MTA, o que deixa sua porta SMTP (25) aberta, possibilitando que um cracker aproveite-se dela, mas em muitos casos com MDA interno pode ser interessante.
# rm -f S20exim4
ou
# mv S20exim4 K20exim4
Com isso, quando o sistema iniciar no nível 2 padrão, o exim4 não iniciará mais. É possível fazer isso com todos os serviços que forem classificados como desnecessários e persona- lizar também os outros níveis de execução.
Não deve-se esquecer também de verificar o diretório /etc/rcS.d, pois nele ficam os links simbólicos dos serviços que são iniciados antes dos serviços do nível de execução padrão. Mesmo que esses serviços sejam primordiais para o funcionamento do seu sistema, é uma boa prática verificar se não existe algum serviço que seja considerado desnecessário para essa ocasião.