Rootsh - Auditando/monitorando o root e demais usuários do GNU/Linux

Neste artigo, mostro como registrar tudo o que um usuário do GNU/Linux (inclusive o root) vê, digita e faz em seu terminal. Em outras palavras, quase uma funcionalidade de Keylogger, porém feito com o objetivo de ter uma auditoria, monitoramento e registro seguro do que cada usuário está realizando no terminal.

[ Hits: 12.164 ]

Por: Esli Silva em 16/07/2014 | Blog: http://www.esli-nux.com


Compilação / Configuração



Compilação e opções de instalação

A versão atual do Rootsh é a 1.5.3 (de 2008), apesar de um pouco antiga, funciona perfeitamente. Em meus testes, utilizei um Debian Wheezy (servidor WEB).

Como dependência, basicamente, é o compilador que você precisa para poder instalar o Rootsh.
Dependências:
  • gcc
  • gcc-multilib
  • make
  • sudo
  • bash

Faça o download do código-fonte e descompacte-o na pasta /usr/local (ou /opt preferivelmente).

Neste ponto, você tem que decidir algumas coisas importantes antes de começar a construir os binários. Leia o arquivo INSTALL no diretório do Rootsh, onde todas as escolhas estão documentadas.

Instaladas as dependências, a compilação é simples (./configure com a opções escolhidas, make e make install).

Basicamente, para a compilação, você precisa decidir de qual forma será utilizado o Rootsh, pois é nesta fase, onde por exemplo, se escolhe entre manter os logs dentro do servidor (no diretório padrão ou num específico) ou enviar para o syslog.

Optei por colocar os arquivos de log do Rootsh no diretório padrão (/var/log), criando lá, um diretório chamado rootsh (esta é a definição padrão na compilação). Informei na compilação para não usar o syslog e também para não numerar as linhas dos logs.

O diretório padrão para os logs é /var/log/rootsh.
Caso queira personalizar isto, coloque no parâmetro do ./configure: --with-logdir=/novo/caminho/para/logs.

Caso você vá utilizar o syslog, deverá desabilitar os logs locais: --disable-logfile.

Por default, esta opção não é usada, ou seja, os logs serão locais, caso não informe nada. Na documentação também pede para desabilitar os logs locais, caso você queira usar o Rootsh como interpretador de comandos (Shell) de algum usuário.

Caso não vá usar o syslog: --disable-syslog.

Obs.: ou você usa o syslog, ou deixa os logs locais. Nunca desabilite as duas opções.

Se você compilou Rootsh com as configurações padrão, as teclas e saída serão enviados linha a linha para o daemon syslog usando prioridade local5.info.

Mudar o nível default de level facility dos logs para syslog: --enable-syslog=LEVEL.FACILITY.
O default é: priority local5.notice.

Em cada linha do log é inserido o número desta linha, um contador formado por três dígitos (informado qual o número de linha em que o usuário ou o root digitou/visualizou).
Para desabilitar esta numeração, use: --disable-linenumbering.

Após instalar com sucesso, você precisa criar o diretório de logs.

Caso desabilitou o syslog e deixou que o Rootsh use o diretório padrão para os logs, você deverá criar o diretório rootsh dentro de /var/log:

# mkdir /var/log/rootsh

Dentro deste diretório, estará todos os logs de todos os usuários monitorados.

No meu exemplo, eu compilei da seguinte forma:

# ./configure --disable-syslog --disable-linenumbering
# make
# make install

Configuração e modos de uso

Ao instalar o Rootsh você, vai colocar dentro do sudoers a permissão para o usuário apenas rodar o Rootsh (o Rootsh vai abrir uma sessão como root, dando assim, todos os privilégios a este usuário).

Como na linha:

eslih ALL=/usr/local/bin/rootsh

Com isto, o usuário eslih vai digitar em seu terminal sudo rootsh (será o único comando que ele vai conseguir digitar com o sudo).

Ao inserir a sua senha (do usuário eslih), irá entrar no terminal com o root, irá abrir uma nova sessão logado como root (e todas as informações visualizadas, comandos dados e etc, serão gravados nos logs).

sudo su, "sudo qualquer outra coisa", não vão funcionar. Pode até tentar o su root, mas ele não vai ter a senha do root.

Com isto, todos que precisam usar o root, vão usar sudo rootsh e possuir acesso ao terminal do root, porém, tudo sendo monitorado/registrado.

Os que não necessitam de acesso ao root, não possuem este acesso. Obviamente, né? E também, tira aquele clichê de sempre os sysadmin colocarem um user ALL=ALL(ALL) dentro do sudoers e depois ficar com um pé atrás, desconfiado...

Obs.: desta maneira, logando com o su root (ou somente su), não estará sendo "monitorado" pelo Rootsh nos logs.

Dica nº1: "Tentar" monitorar o root sem ele saber.

Para que dificulte um pouco (quem for usar, não saber explicitamente que você está monitorando-o), pode-se criar um link simbólico do Rootsh com outro nome (por exemplo admin, ou simplesmente root).

Assim, no sudoers ficaria:

eslih ALL=/usr/local/bin/root

O usuário digitaria para usar o root, então: sudo root

OK, não é uma dica safada, pois ele vai estar como root (dããã), um cat, whereis e alguns outros comandinhos básicos, dão para sacar o que está sendo usado.

Dica nº2: Monitorar os usuários do GNU/Linux (todos)

No 7º campo do /etc/passwd consta a informação de qual interpretador (Shell) o usuário irá utilizar. Geralmente, está assim:

/bin/bash

Da linha toda:

eslih:x:1004:1004:Esli Silva:/home/eslih:/bin/bash

Apenas substitua-o por /usr/local/bin/rootsh (ou pelo nome do link simbólico que você criou).

Não se preocupe, pois na compilação padrão do Rootsh, ele aponta para o /bin/bash para usar, então, não haverá mudanças para o usuário comum.

eslih:x:1004:1004:Esli Silva:/home/eslih:/usr/local/bin/rootsh

Também coloque o caminho do binário Rootsh (ou do link simbólico) dentro do arquivo /etc/shells. Neste arquivo, está o caminho absoluto de todos os Shells existentes, apenas insira /usr/local/bin/rootsh no final. Se não inserir, a distro pode reclamar, falando que não é um Shell declarado.

O problema que pode ocorrer neste caso, é a falta de permissão para a criação do arquivo de log.

Neste caso, você pode dar mudar as permissões do diretório /var/log/rootsh para que todos os usuários tenham direito (mas aí perde a confiança no caso de uma auditoria, ou o risco do arquivo ser apagado existe), ou usar o syslog na compilação. Mandando para um servidor de logs centralizado, por exemplo.

Obviamente, usar esta opção, além de ser mais transparente (invisível) para o usuário, caso alguém logue como root (ou usando o sudo ou su), não precisará informar nada, implicitamente será chamado o Rootsh, já que ele está configurado como o Shell padrão do root também (caso faça isto).

Desta maneira é bem improvável (difícil, mas nem tanto) que seja percebido, onde o usuário só vai conseguir saber, se:
  • Achar o rootsh instalado (path);
  • Achar os logs no servidor (caso não esteja direcionando-os para um syslog);
  • Verificando os arquivos /etc/shells e /etc/passwd, mas se estiver usando link simbólico e ter alterado o nome do Rootsh na compilação, provavelmente qualquer usuário, um invasor no sistema ou até mesmo o root (sysadmin) não fique sabendo explicitamente do monitoramento.

Página anterior     Próxima página

Páginas do artigo
   1. Introdução
   2. Compilação / Configuração
   3. Logs / Otras opções / Fontes
Outros artigos deste autor

Guia SSD no Linux: tudo que você precisa saber e o que precisa esquecer!

Certificados e OpenSSL - A Sopa de Letras

DHCP no GNU/Linux - Guia para ISC-DHCP Server

Leitura recomendada

Segurança em seu Linux (parte 2)

PHPIDS - PHP Intrusion Detection System, deixe seu site livre de intrusos!

Travando qualquer máquina Linux

Instalação do ClamAV com DazukoFS

Como assinar digitalmente um documento criado no Br/OpenOffice

  
Comentários
[1] Comentário enviado por lcavalheiro em 16/07/2014 - 12:43h

Interessantíssimo! Favoritado, chapa!

[2] Comentário enviado por Tacioandrade em 17/07/2014 - 20:29h

Engraçado que passei um bom tempo pesquisando uma solução para fazer exatamente isso a mais de 6 meses atrás, porem por correrias tive que parar e essa semana, na terça feira um colega me indicou um artigo sobre a ferramenta e apareceu essa sua postagem.

Estava vendo esse programa e é uma pena ele estar abandonado a tanto tempo e não possuir pacotes .deb e .rpm, pois instalar em 1 ou 2 computadores manualmente é simples, porem instalar em 50 ou mais já se torna uma tarefa complexa. =(

[3] Comentário enviado por eslih em 18/07/2014 - 12:29h


[2] Comentário enviado por Tacioandrade em 17/07/2014 - 20:29h:
...
Estava vendo esse programa e é uma pena ele estar abandonado a tanto tempo e não possuir pacotes .deb e .rpm, pois instalar em 1 ou 2 computadores manualmente é simples, porem instalar em 50 ou mais já se torna uma tarefa complexa. =(


Olá @Tacioandrade, estou com alguns projetos em andamento, mas ao finaliza-los vou desenvolver os pacotes .deb e rpm e posto novamente. Ou melhor até, além do pacote padrão .deb, coloco o caminho das pedras para você criar o seu próprio porém já deixando dentro do .deb as configurações para enviar ao seu syslog, já que mesmo criando um .deb para melhorar o tempo de instalação, de toda forma teria que personalizar as configurações para o seu servidor de logs centralizado (mais que algumas maquinas seria absurdo deixar os logs em cada uma delas)....

Obrigado a você e o @lcavalheiro pelos comentários e a todos que visitaram este artigo.

[4] Comentário enviado por Tacioandrade em 18/07/2014 - 16:38h


[3] Comentário enviado por eslih em 18/07/2014 - 12:29h:
Olá @Tacioandrade, estou com alguns projetos em andamento, mas ao finaliza-los vou desenvolver os pacotes .deb e rpm e posto novamente. Ou melhor até, além do pacote padrão .deb, coloco o caminho das pedras para você criar o seu próprio porém já deixando dentro do .deb as configurações para enviar ao seu syslog, já que mesmo criando um .deb para melhorar o tempo de instalação, de toda forma teria que personalizar as configurações para o seu servidor de logs centralizado (mais que algumas maquinas seria absurdo deixar os logs em cada uma delas)....

Obrigado a você e o @lcavalheiro pelos comentários e a todos que visitaram este artigo.


Realmente não tinha pensado nisso de criar meu próprio .deb já com as configurações do syslog, ótima ideia mesmo caro amigo, uma vez a muito tempo criei meu pacote .deb, porem foi para uma aplicação que não tinha nenhum requisito, só desempacotava no diretório correto porem acho que da para criar meu próprio .deb mesmo. =D

Sobre o Syslog, você utiliza em algum local? Se sim, qual o sistema que você usa (syslog-ng ou rsyslg) e qual interface de gerenciamento, pois testei o logalizer, porem achei muito fraca. =(

Um forte abraço.

[5] Comentário enviado por Eslih em 19/07/2014 - 13:07h


[4] Comentário enviado por Tacioandrade em 18/07/2014 - 16:38h:

Realmente não tinha pensado nisso de criar meu próprio .deb já com as configurações do syslog, ótima ideia mesmo caro amigo, uma vez a muito tempo criei meu pacote .deb, porem foi para uma aplicação que não tinha nenhum requisito, só desempacotava no diretório correto porem acho que da para criar meu próprio .deb mesmo. =D

Sobre o Syslog, você utiliza em algum local? Se sim, qual o sistema que você usa (syslog-ng ou rsyslg) e qual interface de gerenciamento, pois testei o logalizer, porem achei muito fraca. =(

Um forte abraço.


Olá novamente @tacioandrade ;-)
Se no seu caso o hardware e o sistema for padronizado, pode-se facilitar tudo com o checkinstall (que na hora da compilação vai gerar o .deb, mas se instalar em outra maquina pode ter problemas)...
Tenho mais facilidade/afinidade com o syslog-ng (não que seja melhor ou pior que o rsyslog)... Agora sobre interface para logs (falando não só do rootsh, mas de qualquer log centralizado), creio que uma das melhores combinações seja usar o Logstash + Kibana + Elasticsearch, hoje trabalho uma multinacional que é um AS (Sistema autonomo de internet) e cuja infra há centenas de servidores e clusters GNU/linux e pra complicar um pouco, diversos routers e um range /24 de IP's válidos... Um projeto que em breve será feito é este trio (Logstach+Kibana e ElasticSearch), não conhecia muito sobre, mas quando fui estudar a fundo o que pode ser feito com isto, realmente é impressionante.

[6] Comentário enviado por marlonpso em 05/08/2014 - 22:00h

Ola .. antes de mais nada ...parabens pelo artigo .. muito bom mesmo ...
e agora sobre o rootsh ele parece ser mto bom mesmo .. mais e o sudosh2 alguem ja viu ?? ele é mesmo o que veio para substituir esse rootsh ??

desde ja muito obrigado ! =D


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner
Linux banner
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts