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:


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:


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:


Da linha toda:


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.


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.