Registo de Todos os Comandos Executados num Sistema Informático

Este relatório descreve a análise efetuada a quatro ferramentas que permitem o registo de todos os comandos efetuados num sistema informático. Nota-se, mais uma vez, que não existe segurança absoluta, por um lado, e por outro, que as ferramentas que possibilitam maiores níveis de segurança são igualmente as que têm maiores custos, a nível de trabalho humano e computacional.

Introdução

O objetivo principal deste projeto é estudar, de um ponto de vista da segurança do sistema, a possibilidade de registar (log) todos os comandos executados por um utilizador. A segurança (correspondendo ao inglês security e não safety) será abordada quer pela perspetiva de um ataque intencional ao sistema, quer pela possibilidade de uma utilização negligente poder permitir explorar vulnerabilidades existentes ou criar novas.

Objetivos e motivação

A primeira questão que se poderá colocar, de um ponto de vista da segurança de todo o sistema, é se faz sentido fazer um registo exaustivo de todos comandos executados, por oposição ao registo de apenas alguns comandos, ou de alguns utilizadores. Este trabalho não vai aprofundar esta questão, dado que fica muito além do seu escopo analisar a melhor forma de implementar toda a segurança de um sistema informático.

Bastará assim como motivação para estudar o registo de todos os comandos um regra prática da segurança informática e a abordagem que foi acima descrita, que engloba quer um ataque intencional, quer uma atuação negligente. Se num ataque intencional ainda se poderá (pelo menos em teoria) pretender ter uma lista das atuações potencialmente importantes a registar, na vertente de uma atuação negligente, essa possibilidade por natureza não existe, pois a própria definição de uma atuação negligente (mais ou menos grosseira) pressupõe a respetiva aleatoriedade resultante de ser uma atuação não planeada ou imprevista.

Software analisado

A lista de software que permite realizar o objetivo deste estudo não é extensa. Contudo, com uma exceção, nenhum se destina especificamente a esta tarefa, tendo aplicabilidade mais vasta. Naturalmente, dado o âmbito deste estudo, apenas iremos focar a possibilidade de registar os comandos executados.

grsecurity

O grsecurity é um conjunto de patches para o kernel Linux que visa melhorar globalmente toda a segurança do sistema. As suas funcionalidades são múltiplas e abrangem áreas muito distintas. Citando apenas as mais relevantes, podemos encontrar: Role Based Access Control, PAX (que implementa algumas técnicas para impedir a execução de código arbitrário, como a marcação de páginas de memória somente para leitura quando contenham código (read only), ou a randomização do espaço de endereçamento da memória), limitações de acesso a parte do sistema de ficheiros e proteção de executáveis, rede e kernel. Entre esta miríade de possibilidades, existe igualmente a opção de registar todos os comandos executados.

Este registo é efetuado a partir de código que é adicionado ao próprio kernel, de modo a registar as chamadas efetuadas à função de sistema execve.

Linux Auditing System

O Linux Auditing System (LAuS) é uma ferramenta desenvolvida e mantida pela Red Hat e que se encontra presente no kernel do Linux desde a versão 2.6. O objetivo do LAuS é registar todas as chamadas de sistema (system calls) realizadas. No entanto, pode ser configurado para registar apenas a chamadas execve, de modo a cumprir os objetivos previstos neste projeto.

Esta ferramenta tem dois módulos, normalmente designados por servidor e cliente. O servidor foi a parte incluído no Linux Kernel v.2.6, enquanto a parte cliente pode ser usada para configuração e acesso aos dados.

O funcionamento desta ferramenta é muito fácil de explicar: dado que parte do código é executado dentro kernel, o LAuS consegue registar todas as chamadas de sistema efetuadas.

The GNU Accounting Utilities

As GNU Accounting Utilities são um conjunto de ferramentas criadas há vários anos, num momento em que o tempo de processamento era um bem raro. O objetivo inicial era apenas saber quem estava a usar o tempo de processamento do (único) computador disponível e o que estava a fazer com o mesmo.

Entre as cerca de seis ferramentas disponíveis encontra-se o lastcomm que permite listar os comandos executados.

Snoopy Logger e outras ferramentas

O Snoopy Logger é uma ferramenta open source destinada especificamente a registar todos os comandos executados. No entanto, de acordo com as instruções dos autores (e não só), não é uma ferramenta que vise a área da segurança, sendo um dos motivos o facto de não ser difícil escapar ao respetivo registo (como veremos).

Esta ferramenta funciona como um wrapper da função execve que, além de chamar a mesma, regista os argumentos dessa chamada.

Existem outras ferramentas open source que permitem igualmente registar todos os comandos executados numa shell, sendo dois exemplos o sudosh e o rootsh. Estas não serão analisadas, pois além da sua menor divulgação e documentação, têm uma aplicabilidade bastante mais limitada, não permitindo registar todos comandos executados num sistema, mas apenas no sistema de shell, que terá de ser substituído por estar versão com a funcionalidade adicional de registar os comandos do utilizador. Este tipo de ferramentas além de apresentarem um campo de aplicação mais limitado, reduzem as opções de shell disponíveis (e logo, as opções disponibilizadas aos utilizadores) e criam ainda uma vulnerabilidade adicional, resultante da eventual possibilidade de o atacante conseguir correr outra shell.

Os testes realizados

Além do estudo do funcionamento e documentação das ferramentas selecionadas, foram realizados alguns testes com vista a aferir, por um lado, da respetiva segurança ou fiabilidade, e por outro, das perdas em termos de desempenho que o sistema sofre com a operação adicional de registo.

Os testes foram todos realizados numa máquina com CPU Intel i5 760, a 2.8GHz, com 8 GB de RAM, a correr a versão 7 do Debian (Wheezy).

Os testes de fiabilidade

Dado que a maioria das ferramentas selecionadas se encontram em produção há vários anos e sendo todas open source, não houve a pretensão de encontrar falhas de segurança óbvias, principalmente num trabalho com as limitações temporais e objetivos que o presente texto apresenta. No entanto, foram feitas algumas verificações de situações limite. Desde simples utilização de alias para chamar executáveis e que todas as ferramentas ultrapassaram, facilmente registando o executável realmente chamado, até à utilização de sudo para mudar de um utilizador normal (user) para administrador (root), facto que permitiu esconder a algumas aplicações a verdadeira identidade de quem invocou certo comando.

Foi igualmente investigado se seria possível ocultar um comando ou o respetivo utilizador, pela utilização de aplicações intermediárias. Assim, dentro do cliente de correio eletrónico de linha de comandos Alpine foi invocado o editor de texto Vi para a elaboração de uma nova mensagem. Foi então utilizada a funcionalidade do Vi para executar um comando de shell e retornar o resultado para dentro deste editor.

Os testes de desempenho

Dadas as ferramentas selecionadas terem modos de funcionamentos algo distintos, e de modo a fazer uma avaliação correta do desempenho do sistema foram elaborados três testes bastantes distintos:

  1. Compilação de software
    Optou-se, em razão do tempo de compilação e estabilidade do código, pelo openssh-client v.1.6.0.
  2. Sequência de vários comandos de utilização corrente por qualquer utilizador normal
    Para este teste foi especificamente elaborado um pequeno script em bash:

    #! /bin/bash 
    
    mkdir teste
    cd teste
    for dir in d1 d2 d3 d4 d5
    do 
      echo -e "\n** Making dir ${dir}"
      mkdir $dir
      cd $dir
    
      for file in f1 f2 f3 f4 f5
      do
        echo -e "\n Making file ${file}"
        dd if=/dev/urandom of=${file} count=1M bs=1 > /dev/null
      done
      ls -lA > /dev/null
      cd ..
    done
    echo -e "\n Cating all files"
    cat $(find -type f) > /dev/null
    cd ..
    echo -e "\n Compressing"
    tar cf compressed.tar teste
    rm -r teste
  3. Por fim, foi efetuado um teste de processamento intensivo.

Este teste foi efetuado com recurso a um outro projeto pessoal que realiza a análise de um ficheiro de dados numéricos, imprimindo no ecrã o resultado. A análise consiste em variados cálculos que a aplicação distribui por todos os cores disponíveis na máquina. Pretendeu-se, ao utilizar especificamente esta aplicação, obter resultados mais fiáveis nos atuais ambientes multicore.

Os testes de desempenho foram todos realizados com um utilizador normal, sem privilégios especiais.

Análise

A segurança de um sistema é, regra geral, o resultado de um conjunto de opções de ponderação entre segurança e custo. Na análise deste binómio considerou-se que seria relevante, além dos custos de processamento—de análise mais quantificável—realizar igualmente uma análise mais subjetiva, sobre a facilidade ou dificuldade de configuração e utilização do software. A ferramenta mais segura, mas cuja instalação exija um técnico especializado só será acessível a um pequeno público e foi, por isso, considerado que este aspeto, embora não sendo tão facilmente mensurável como a diminuição de desempenho, devia ser tido em consideração.

Para esta avaliação foi utilizada uma escala igualmente menos quantitativa que pode ser vista na Tabela 1.

Tabela 1: Análise de aspetos administrativos
 grsecurityLAuSGNU AUSL
Facilidade de Instalação+++++
Facilidade de Configuração+++++
Documentação+++++

Instalação, configuração, utilização e documentação

Todas as ferramentas, com exceção do grsecurity, foram instaladas através do repositório oficial Debian e não apresentam qualquer dificuldade na respetiva instalação. O grsecurity, dado que consiste num conjunto de patches ao kernel, requer conhecimentos avançadas para ser instalado. No caso do Debian (e outras distribuições nas mesmas condições) o kernel recebe já alguns patches, pelo que não é possível aplicar os patches do grsecurity diretamente, sendo necessário aplicá-los à versão original do kernel, compilá-lo e instalá-lo.

As dificuldades no grsecurity transmitem-se igualmente à configuração, que é necessário fazer no momento da configuração do kernel, através das ferramentas disponíveis para tal.

O LAuS está vastamente documentado e selecionar a opção para registar todos os comandos executados requer adicionar apenas duas linhas aos ficheiros de configuração. No entanto, dado o enorme leque de possibilidades que esta ferramenta oferece, descobrir as opções corretas requer algum investimento na leitura da documentação e conhecimentos técnicos avançados.

No extremo opostos, quer as GNU Accounting Utilities, quer o Snoopy Logger não requerem qualquer configuração. Pelo que foi possível perceber, numa distribuição menos “pró-ativa” que o Debian, além da instalação apenas seria necessário executar os comandos para iniciar as respetivas ferramentas—procedimento que, em ambos os casos, se encontra devidamente documentado.

A utilização fundamental destas aplicações passa pela consulta dos registos realizados, que será objeto de análise no próximo ponto.

Os registos (logs)

Aspetos formais

Localização

Os registos criados nem sempre foram criados onde seria de esperar. Embora sempre de acordo com a Filesystem Hierarchy Standard1 a pasta escolhida seja /var/log, o Snoopy Logger gera os seus relatórios dentro do ficheiro auth.log e o gsecurity dentro do syslog. Embora tal não seja, à partida um problema, não foi fácil encontrar tal aspeto na documentação.

Formatos

À exceção das GNU Accounting Utilities, todas as ferramentas guardam os relatórios em formato de texto, facilmente acessível. As Accounting Utilities incluem as aplicações necessárias para aceder ao formato binário que lhes é específico.

Legibilidade

As GNU Accounting Utilities disponibilizam, de longe, o conteúdo mais legível e fácil de interpretar. Todos as outras ferramentas registam demasiada informação para que possam ter uma leitura fácil. Isto não deve ser visto como um aspeto negativo. Trata-se tão somente de uma consequência do volume de informação que é registado.

Embora o facto de os registos serem demasiado verbosos possa ser visto como potenciador de alguma insegurança, no sentido que ao dificultarem a leitura irão impedir a respetiva consulta e diminuir a respetiva utilidade, tanto o grsecurity como o LAuS, estão conscientes desse problema e fornecem ferramentas que permitem filtrar a informação relevante. O Snoopy Logger é uma exceção neste caso.

Aspetos de Conteúdo

O conteúdo dos registos é bastante variável, em consonância com o que atrás ficou dito, relativamente à legibilidade. Os registos mais legíveis, das GNU Accounting Utilities, são igualmente os mais incompletos, listando apenas a data, o comando, o nome do utilizador, a consola em que o comando foi executado e uma indicação adicional com informações de sistema. Um elemento com bastante importância, e que é omitido, são os parâmetros (ou argumentos) com que o comando foi executado.

Tanto o Snoopy Logger como o LAuS registam bastante mais informação, nomeadamente ID e GID (group ID). As GNU Accounting Utilities são aliás únicas no aspeto em que apresentam o nome do utilizador e não apenas um número. O grsecurity apresenta o maior volume de informação, tornando-se quase ininteligível numa primeira abordagem. Para este estudo interessa-nos especialmente que tanto o grsecurity como o LAuS conseguem manter o registo do utilizador mesmo que ele altere a sua identificação, nomeadamente usando o comando sudo. O LAuS, utiliza um elemento que designa por AUID (abreviatura de audit uid) e que permite identificar um utilizador que nas GNU Accounting Utilities surge apenas como root. Esta é uma possibilidade sem paralelo nas restantes duas ferramentas e que dá uma vantagem indiscutível à grsecurity e à LAuS, principalmente em casos de negligência, onde é possível, mesmo que várias pessoas tenham acesso a uma consola administrativa (onde possam utilizar o comando sudo) identificar quem realizou determinada tarefa (ou, neste caso, quem executou quais comandos).

O Snoopy Logger regista um SID (Session ID) que pode ser usado com o mesmo efeito, no entanto os seus resultados não são tão fidedignos, até porque resultam de cada sessão que é iniciada, ao contrário do AUID.

Outro aspeto essencial—desta feita, em que todos as ferramentas conseguiram alcançar um bom resultado—é a capacidade para não serem induzidas em erro pela utilização de outras aplicações (intermédias) para chamar os comandos. Nenhuma das ferramentas foi “enganada” por este ardil, registando corretamente a aplicação e o utilizador.

Acesso aos registos

Todas as ferramentas estudadas utilizam exclusivamente o sistema de ficheiros como proteção para limitar o acesso aos ficheiros de registos. O LAuS apenas permite a leitura e escrita ao administrador (root), sendo que as restantes ferramentas permitem igualmente a leitura ao grupo administrador.

Esta opção, quando usada para registar potenciais ataques e nomeadamente ataques bem sucedidos com privilegie escalation (ou seja, em termos grosseiros, qualquer exploit que permita a um utilizador comum fazer sudo) elimina qualquer fiabilidade concedida a estes registos. Na prática, para a situação mais perigosa, e talvez aquela que faria todo o sentido manter um registo: quanto um atacante consegue ter acesso incondicional a uma máquina, as ferramentas estudadas revelam-se completamente ineficientes.

A alternativa neste tipo de situações é, numa abordagem clássica, ter um sistema de registo externo à própria máquina, presumindo-se que o atacante não conseguirá ser bem sucedido no ataque a ambas as máquinas simultaneamente. Esta estratégia tem por fito atingir um dos objetivos principais de um registo seguro: a sua inalterabilidade (incluindo a respetiva eliminação). No entanto, o atacante poderá a qualquer momento cessar a produção de registos. Este parece ser um problema verdadeiramente insolúvel, uma vez que a partir de determinado ponto, um atacante com suficientes permissões poderá fazer tudo o que um administrador legítimo também pode fazer2.

Contornar o registo

Dado que as três primeiras ferramentas funcionam com base em código que já existe (ou é necessário adicionar) no kernel do sistema, não será uma tarefa nada fácil conseguir escapar ao respetivo registo. Potenciais vulnerabilidades existentes só estarão ao alcance de alguém com conhecimentos técnicos muito avançados.

A exceção, como aliás já tinha ficado indiciado, é o Snoppy Logger. Ao utilizar somente um wrapper para uma biblioteca, permite a existência de várias estratégias para contornar os registos que realiza3.

Eficiência e perdas de performance

Como se poderá verificar no gráfico de desempenho e na tabela de valores apresentados (contabilizadas com base nos valores totais), as diferenças de desempenho são, respetivamente de 8%, 3%, 0,1% e 3%, para o grsecurity, o LAuS, as GNU Accounting Utilities e o Snoppy Logger. Tal como esperado, uma maior produção de conteúdos tem como contrapartida um maior impacto no desempenho geral do sistema.

Tabela 2: Tempo em segundos dos testes de desempenho
 originalgrsecurityLAuSGNU Accounting UtilitiesSnoopy Logger
a) compilação59,83153,9860,259,9663,93
b) script55,88274,38660,755,80857,28
c) computação intensiva58,42660,89258,858,57958,84

Registo de Comandos: gráfico de desempenho

Como panorâmica geral, não se retiram aqui mais conclusões que as que resultam do estudo global da Segurança de Sistemas Informáticos: há sempre um equilíbrio a considerar entre a segurança e o custo, que neste caso é refletido quer em tempo de configuração e instalação, quer em performance. A solução com mais dados, que, tal como ficou exposto a propósito do objetivo deste trabalho se presumirá que seja a mais completa, ou mais segura (independentemente do contributo que tenha na segurança global do sistema, que como já mencionado, não cabe aqui analisar) é igualmente a que tem os maiores custos.

Conclusões

Este projeto procurou identificar um conjunto de soluções para um problema muito específico, a saber, o registo de todos os comandos executados num sistema informático. Após alguma investigação e teste de várias ferramentas que foram selecionadas por disponibilizarem tal funcionalidade, acabou por se concluir que existe sempre uma situação, em que o atacante obtém permissões administrativa, em que nenhuma ferramenta se mostrou capaz de minorar os danos. Nos restantes casos existe um equilíbrio entre a informação registada e os custos de utilização da ferramenta. Como mera opinião pessoal, parece-nos que o LAuS é a opção mais equilibrada (entre custo e benefício). No entanto, como em qualquer questão de segurança, a opção correta é exclusivamente a opção correta para o sistema em análise, pelo que cada Administrador de Sistemas terá de fazer a sua própria opção com base nos respetivos requisitos de segurança.

Referências

  1. Schneier, Bruce, and Kelsey, John, Secure Audit Logs to Support Computer Forensics, ACM Transactions on Information and System Security, v. 1, n. 3, 1999.
  2. Snoppy Logger website. https://github.com/a2o/snoopy
  3. Documentação oficial das GNU Accounting Utilities. http://www.gnu.org/software/acct
  4. Documentação oficial do grsecurity. http://en.wikibooks.org/wiki/Grsecurity
  5. Man page das ferramentas do LAuS: http://manpages.debian.net/cgi-bin/man.cgi?query=auditd&apropos=0&sektion=0&manpath=Debian+7.0+wheezy&format=html&locale=en (auditd), http://manpages.debian.net/cgi-bin/man.cgi?query=auditctl&apropos=0&sektion=0&manpath=Debian+7.0+wheezy&format=html&locale=en (auditctl) e http://manpages.debian.net/cgi-bin/man.cgi?query=auditd.conf&sektion=5&apropos=0&manpath=Debian+7.0+wheezy&locale= (auditd.conf)

Notas

  1. http://www.pathname.com/fhs/
  2. Para um estudo bastante interessante sobre a possibilidade de uma máquina apenas garantir a inalterabilidade dos seus registos ver [1]. Notar, no entanto, que mesmo os autores acabam por concluir por algumas vulnerabilidades no modelo proposto—dir-se-ia inerentes a tentar guardar um objeto do seu próprio possuidor (legítimo ou ilegítimo).
  3. Ver, por exemplo, o interessante artigo de Chapman, que incluí uma explicação detalhada do funcionamento do Snoopy Logger, de como o detetar e ainda um exemplo em C (proof of concept) de como evitar o respetivo registo: http://blog.rchapman.org/post/4921812115/bypassing-snoopy-logging (consultado por último a 13/12/2013).