Centralizando Logs com Rsyslog.

Configurando um Servidor de log Centralizado.

A ídeia é melhorar a segurança de uma rede, pense no seguinte ambiente, um cracker de uma forma não relevante agora comprometeu um servidor na rede. Um dos passos do ataque é o “post exploitation”, um dos passos da fase de pós-exploração é limpar os rastros. Isso sugere em manipulação de arquivos de log, remoção de entradas no log comprometedoras como IPv4, hora do ataque, tudo que diz respeito às ações do invasor.

Uma das formas de conseguir uma melhor integridade nos arquivos de log é descentralizando eles, isso é um pouco confuso porquê o título diz “centralizado” e agora eu estou falando “descentralizar”, mas é, o ambiente é o seguinte, se o sysadmin pegar os logs dos servidores e encaminhar para um servidor central de logs, teremos duas camadas de segurança. O invasor teria que comprometer o servidor central de logs também para poder forjar os logs, o que em segurança é sempre um prazer dificultar a vida do invasor.

Eu não pretendo explicar como funciona as facilidades.prioridades de logs nos sistemas linux porquê eu já expliquei isso em outro paper e esse paper nesse momento encontra-se em um HD corrompido na minha estante e eu me recuso a reescrever o paper, quando/se eu recuperar os dados do HD e se esse paper estiver intacto eu integro nesse paper e todo mundo fica feliz.

Preparando o ambiente

Para realizar a configuração vamos usar 2 servidores.

• Servidor de log Central: Debian
• Servidor comum que vai enviar logs: CentOS

Configurando a Central de Logs

Vamos começar configurando o Central Log Server, que vou chamar agora de (CLS) para economizar as tecla do teclado. (hue)

O daemon responsável pelo loggin é o rsyslog que provavelmente já vai estar instalado, se não estiver, providencie:

# apt-get install rsyslog rsyslog-doc

Então no arquivo de configuração /etc/rsyslog.conf será necessário descomentar o módulo e o listener referente à funcionalidade de receber logs. Note que são duas opções disponíveis de protolocos de transporte, o TCP e o UDP, lembre-se de que o UDP não é um protocolo que implementa confiabilidade e estamos falando de transmissão de arquivos de log, então faz mais sentido utilizar TCP do que UDP.

Antes de sairmos editando o arquivo vamos só construir mais um pouco de teoria. O arquivo de configuração do Rsyslog possui alguns blocos, no caso temos três: Modules, Global Directives e Rules.. O primeiro bloco referente á modules contém informações sobre módulos, um deles que nós precisamos descomentar é o que habilita o módulo imtcp e abre o listener na porta 514, descomente as linhas abaixo:
Descomente as seguintes linhas no arquivo de configuração:

module(load="imtcp")
input(type="imtcp" port="514")

O bloco Global Directives tem algumas informações sobre owner, permissão od arquivo etc. Vou salientar pra questão do template, os templates são importantes para definir o formato de forma dinamica(ou nao) de para onde os logs serão encaminhados, vamos adicionar a linha abaixo no arquivo de configuração:

$template log2Dir, "/root/logfiles/%fromhost-ip%/%$MONTH%-%$DAY%-%$YEAR%/LOG"

A linha acima vai criar um diretório dentro do diretório /root/logfiles/ com o endereço do IP do host que encaminhou o log e então vai criar um diretório com o nome definido pelo mês, dia e ano e dentro desse diretório ele vai criar um arquivo chamado “Log” e vai jogar tudo que for apontado pra esse template nesse formato. Então, com esse formato, vamos supor que você tenha 4 hosts disparando logs para você, então vai ter 5 diretórios dentro do diretório /root/logfiles. São cinco porquê existe um do localhost, que é o próprio servidor, nesse caso.

Feito isso, vamos ir pro ultimo bloco, o bloco de Rules, aqui são definidas as regras que dizem o que fazer com os logs, as linhas são separadas por facility.priority action, eu não vou explicar tudo sobre isso agora, como falei antes o meu HD ter corrompido é um bag pessoal e se eu recuperar lá eu atualizo esse post com as info do paper que ta lá perdido entre milhoes de bits mortos.

Então aqui é o seguinte, precisamos alterar a action, para dizer que quero todos os tipos de logs(facilitys) de todas as prioridades (prioritys) eu posso simplesmente colocar um * e então a action eu vou jogar pro template que foi criado acima. Então insira as seguintes linhas no seu arquivo de configuração no bloco rules:

 *.* ?log2Dir

Feito isso, o lado servidor está pronto de forma bem porca, ele só vai fazer o que precisa ser feito, sem nenhuma arte ou beleza, mas por hora é só isso que eu preciso, não preciso de miçangas agora.

Configurando o direcionador de logs no “cliente”

Agora do lado do servidor que vai encaminhar os logs, a configuração é relativamente simples também, com seu editor favorito, abra o arquivo de configuração: /etc/rsyslog.conf

O arquivo é a mesma coisa do outro arquivo, precisamos trabalhar apenas em cima do bloco rules aqui, basicamente você pode selecionar uma facilidade.prioridade que queria ou pode redirecionar tudo, no final das contas vai se resumir a isso:

*.info;mail.none;authpriv.none;cron.none                @@10.0.0.6:514

Repare que, no campo action, está sendo utilizado @@ DOIS arrobas, isso é bem louco, porque pode parecer um erro de digitação mas na verdade 2 arrobas significa utilizar TCP e apenas um arroba significa utilizar UDP, e mano, se você configurar na central como tcp e disparar como UDP, não vai prestar.

Algumas configurações interessantes que você pode querer fazer para deixar mais bonitu são as seguintes:

# ### begin forwarding rule ###
# The statement between the begin ... end define a SINGLE forwarding
# rule. They belong together, do NOT split them. If you create multiple
# forwarding rules, duplicate the whole block!
# Remote Logging (we use TCP for reliable delivery)
#
# An on-disk queue is created for this action. If the remote host is
# down, messages are spooled to disk and sent when it is up again.
$ActionQueueFileName fwdRule1 # unique name prefix for spool files
#$ActionQueueMaxDiskSpace 1g   # 1gb space limit (use as much as possible)
#$ActionQueueSaveOnShutdown on # save messages to disk on shutdown
$ActionQueueType LinkedList   # run asynchronously
$ActionResumeRetryCount -1    # infinite retries if host is down

Se você sabe inglês, é auto explicativo.

PoC

Para realizar uns testes marotos, você pode primeiramente no lado “servidor” utilizar o tcpdump para analisar as mensagens chegando dessa forma:

# tcpdump -i eth0 port 514

Onde eth0 é a interface ethernet e port é a porta configurada no listener para receber os logs.

Agora com o sniffer rolando na ponta que recebe, vamos na ponta que envia e criar uns logs marotos utilizando o comando logger

[root@masterslave-dns centos]# logger -p kern.emerg KERNEL PANIC, DONT LET ME DIE. just kiding bro

Quando executar esse comando, vai ser exibido uma mensagem na tela etc nos dois servidores, e no tcpdump deve ter interceptado os pacotes que fizeram o sistema exibir a mensagem na tela, é louco né.
Agora pra verificar o ultimo detalhe, vamos verificar o diretorio que a gente configurou naquele tamplate lá atrás que dizia dinamicamente aonde o log deveria ser armazenado:

root@logserver:/var/log# ls -l /root/logfiles/
total 8
drwxr-xr-x 3 root root 4096 jan  7 20:35 10.0.0.5
drwxr-xr-x 3 root root 4096 jan  7 17:57 127.0.0.1

Olosco, ta ai, o 10.0.0.5 é o servidor que está enviando os logs e o 127.0.0.1 é o próprio servidor, agora vamos ir more deep, vamos verificar o arquivo LOG:

root@logserver:/var/log# tail -n 3  /root/logfiles/10.0.0.5/01-07-2018/LOG 
Jan  7 23:01:01 masterslave-dns systemd: Removed slice User Slice of root.
Jan  7 23:01:01 masterslave-dns systemd: Stopping User Slice of root.
Jan  7 23:06:19 masterslave-dns centos: KERNEL PANIC, DONT LET ME DIE. just kiding bro

É isso, funciona, a hora só ta errada, essas imagens do Openstack vem com um horário troll, sempre esqueço de arrumar.

End Notes

Uma coisa que notei é que não utiliza autenticação, eu só simplesmente disparo os bag pro cara e ele vai armazenando, tipo, lolz, isso me deu umas ideias loucas, tipo, spoofar um ip e disparar logs criticos pro servidor, sei lá, imagina um cenário que tem um IDS analisando os logs, ou mandar logs de que ta tudo bem, ou sei lá, dar uma forma de obsfuscar um ataque. É, outra coisa importante é o logrotate, quando eu atualizar esse paper eu vou explicar de forma descente sobre o funcionamento dos logs em sistemas linux e como implementar o logrotate. Mas basicamente, o logrotate é um cara responsável por rotacionamento de logs, isso implica que ele vai dependendo da métrica configurada, pegar o arquivo de log, compactar e guardar e abrir outro arquivo de log novo, assim você teria logs compactados e sendo descartados periodicamente para evitar que os arquivos de log saiam de controle e lotem a partição do servidor.

O Rsyslog também tem a opção de armazenar os logs em um banco de dados atráves do action que nós vimos antes, é interessante pois abre um leque novo de possibilidades.

Um ultimo detalhe é se você for muito paranoico você pode ir além de apenas uma centra de log, você pode disparar para quantas quiser, seria um ambiente mais interessante, simplesmente adicionando outra linha com outro servidor no action.

Fontes:

http://www.rsyslog.com/receiving-messages-from-a-remote-system/
http://www.rsyslog.com/sending-messages-to-a-remote-syslog-server/
https://www.thegeekstuff.com/2012/01/rsyslog-remote-logging/