Servidor de Logs

O Servidor de Logs é um recurso bastante útil em uma rede onde necessitamos centralizar os logs de todos os servidores, para analisá-los melhor. Uma outra vantagem está relacionada à segurança da informação, porque um servidor invadido enviará logs para um sistema remoto, dificultando que o invasor apague seus rastros. Para que ele obtenha êxito em destruir esses dados, terá que invadir, também, o Servidor de Logs da sua rede. Uma boa prática de se montar um sistema como esse, é também saber como organizar os dados recebidos dos servidores e organizá-los de forma prática e de fácil acesso. Outra utilidade para esse sistema, seria para armazenar logs de uma caixa CGNAT BPA (Bulk Port Allocation). Não sabe o que é CGNAT BPA? Consulte aqui. Também para coletar logs IPv6 de sistemas que ainda não fazem isso 100% via Radius, por exemplo. Bem, existem diversas ideias para se utilizar um Servidor de Logs.

Para tanto, precisamos também dar um mínimo de segurança a esse servidor e também precisamos pensar em uma estratégia de rotacionamento desses logs, para que não acabe o espaço em disco e comprometa a coleta desses dados tão valiosos. Não é mesmo? Por que uma estratégia? Porque podem existir logs que necessitarão de serem armazenados entre 2 a 5 anos e outros que por apenas poucas semanas, meses, etc.

Sistema e recursos que usaremos nesse Servidor

• Debian 10 (Buster) - Sistema Operacional onde rodaremos os serviços.
• Rsyslog - serviço responsável por enviar e coletar os logs dos servidores.
• Logrotate - faz o rotacionamentos dos logs armazenados.
• OpenNTPd - para mantermos a data e hora do sistema corretos. Isso é muito importante em se tratando de logs.
• nftables - sucessor do Netfilter/IPTables onde criaremos os filtros de pacotes.
• SSD ou HDD (o espaço vai depender da necessidade de cada rede). Prefiro usar SSD pela performance e se possível em RAID10 para ter mais disponibilidade, mas vai da preferência de cada sysadmin. Também podemos usar virtualização.
• Processamento e memória não são requisitos altos.
• IPv6 - Porque precisamos ter consciência de sua importância para continuidade da Internet. Então por que não usarmos ele em nossa implementação?

Diagrama exemplo

Sim são redes distintas e interconectadas de alguma forma. Para demonstrar que o Servidor de Logs não necessita de estar na mesma rede lógica.

Configurando o Servidor

Para a instalação do servidor, basta ter em mãos um pendrive com o instalador do Debian Buster. Caso ainda não tenha, aqui vai um link que costumo usar. Esse link pode mudar conforme atualizações do sistema. Não iremos entrar em detalhes sobre a instalação do Debian, só tenha em mente que você precisará instalar o mínimo necessário e o servidor ssh para acessá-lo remotamente. Nada de ambientes gráficos!

O sistema não deve ter nenhum serviço rodando além do cron, ntpd e o rsyslogd. Desabilite e/ou remova qualquer serviço desnecessário. Isso melhora a segurança do seu sistema e uso de recursos.

Acertando a data/hora do sistema:

# apt install openntpd

Alterar o /etc/openntpd/ntpd.conf comentando a configuração atual e adicionando o novo Pool (pool.ntp.br) conforme abaixo:

# $OpenBSD: ntpd.conf,v 1.14 2015/07/15 20:28:37 ajacoutot Exp $
# sample ntpd configuration file, see ntpd.conf(5)

# Addresses to listen on (ntpd does not listen by default)
#listen on *
#listen on 127.0.0.1
#listen on ::1

# sync to a single server
#server ntp.example.org

# use a random selection of NTP Pool Time Servers
# see http://support.ntp.org/bin/view/Servers/NTPPoolServers
#servers pool.ntp.org
servers pool.ntp.br

# Choose servers announced from Debian NTP Pool
#servers 0.debian.pool.ntp.org
#servers 1.debian.pool.ntp.org
#servers 2.debian.pool.ntp.org
#servers 3.debian.pool.ntp.org

# use a specific local timedelta sensor (radio clock, etc)
#sensor nmea0

# use all detected timedelta sensors
#sensor *

Reiniciaremos o serviço e checaremos se a data e hora estão corretas:

# systemctl restart openntpd.service

# date
sex abr 23 17:25:29 -03 2021

Caso o fuso horário do servidor esteja errado, pode usar o seguinte comando para corrigir: dpkg-reconfigure tzdata

Agora partiremos para a configuração do Servidor de Logs em si. Vamos definir a seguinte estratégia baseada no diagrama acima: temos 3 tipos de casos, como exemplo, servidores comuns (serviços como http, smtp, dns, etc), caixas CGNAT e Mikrotiks fazendo, por exemplo, concentração PPPoE (BNG). Baseado nessas informações, separaremos o armazenamento em diretórios distintos, facilitando a organização e manipulação dos dados armazenados.

# mkdir /var/log/danos
# mkdir /var/log/servidores
# mkdir /var/log/mikrotiks

No primeiro serão armazenados os logs referentes aos servidores de CGNAT DANOS. No segundo logs de servidores comuns de Internet, por exemplo. Por último os relacionados com os Mikrotiks.

Precisamos habilitar o rsyslog para se tornar um servidor de logs; assim escutar em sua porta padrão 514/UDP ou outra porta que desejar e receber os dados. Para isso removeremos o comentário "#" das duas linhas abaixo, do arquivo /etc/rsyslog.conf.

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

Criaremos em /etc/rsyslog.d/ um arquivo chamado logserver.conf com o conteúdo abaixo. Todos os arquivos .conf, que forem criados nesse diretório, o rsyslog lerá em usa inicialização.

template (name="ServLinux" type="string" string="/var/log/servidores/%HOSTNAME%.log")
template (name="DANOS" type="string" string="/var/log/danos/%HOSTNAME%.log")
template (name="Mikrotiks" type="string" string="/var/log/mikrotiks/%HOSTNAME%.log")
:fromhost-ip, isequal, "2001:db8:face:b00c:192:168:10:25" ?ServLinux
:fromhost-ip, isequal, "2001:db8:c0ca:c01a:192:168:0:3" ?DANOS
:fromhost-ip, isequal, "2001:db8:dead::192:168:200:4" ?Mikrotiks

A configuração é bem simples. Se analisarmos, veremos que os templates definem onde serão armazenados os logs, cujos arquivos serão criados de acordo com o hostname de cada um. As linhas com fromhost-ip fazem o filtro por IP de servidor e enviam os logs para o template correto. Nesse caso temos 3 templates: ServLinux, DANOS e Mikrotiks. Bem simples não é mesmo? Vamos reiniciar o serviço e checar seu status desse jeito:

# systemctl restart rsyslog.service

# systemctl status rsyslog.service 
● rsyslog.service - System Logging Service
   Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2021-04-23 13:51:25 -03; 4h 35min ago
     Docs: man:rsyslogd(8)
           https://www.rsyslog.com/doc/
 Main PID: 19362 (rsyslogd)
    Tasks: 5 (limit: 4915)
   Memory: 18.7M
   CGroup: /system.slice/rsyslog.service
           └─19362 /usr/sbin/rsyslogd -n -iNONE

Definindo um rotacionamento dos Logs

Outro ponto que é necessário se criar uma estratégia; ter em mente por quanto tempo se quer manter os dados para depois descartá-los. Para o nosso exemplo vamos definir que os logs do CGNAT devem ser guardados pelo prazo de 1 ano, o mesmo para os logs do Mikrotik e 6 meses para os logs do servidor Linux do nosso exemplo.

Vamos criar os seguintes arquivos em /etc/logrotate.d/:

# cat danos 
/var/log/danos/*.log {
    monthly
    rotate 12
    missingok
    notifempty
    sharedscripts
    postrotate
                /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

# cat servidores 
/var/log/servidores/*.log {
    monthly
    rotate 6
    missingok
    notifempty
    sharedscripts
    postrotate
                /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

# cat mikrotiks 
/var/log/mikrotiks/*.log {
    monthly
    rotate 12
    missingok
    notifempty
    sharedscripts
    postrotate
                /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

Teremos 3 arquivos definidos: danos, servidores e mikrotiks. Cada um deles responsável pelo rotacionamento do seu diretório de logs. Sua syntax pode ser consultada via man logrotate.conf. Mas nos nossos exemplos temos o monthly, que diz que o rotacionamento vai ser mensal e o rotate que diz quantos arquivos serão mantidos, antes que se sobreponha algum dado. Ou seja, 12 arquivos mensais correspondem a 1 ano. Reinicie o logrotate para que ele carregue as novas configurações.

# systemctl restart logrotate.service

Podemos testá-los se está tudo OK rodando o logrotate em modo debug assim:

# logrotate --debug /etc/logrotate.d/danos
# logrotate --debug /etc/logrotate.d/mikrotiks
# logrotate --debug /etc/logrotate.d/servidores

Criando filtros para a proteção do Servidor de Logs

Para não deixarmos nosso tão valioso servidor aberto para o mundo, adicionaremos algumas regras de firewall nele, permitindo que apenas os servidores e sistemas autorizados possam enviar os logs para ele. O exemplo abaixo é um script utilizando syntax do nftables e por isso vamos precisar instalar o programa nftables. Pode ser feito com Netfilter/IPTables? Pode. Só seguir o mesmo raciocínio lógico.

# apt install nftables

Abaixo o exemplo do script /root/frw.sh:

#!/usr/sbin/nft -f
flush ruleset

define bogons_v4 = { 0.0.0.0/8, 100.64.0.0/10, 127.0.0.0/8, 169.254.0.0/16, 172.16.0.0/12, 192.0.2.0/24, 192.168.0.0/16, 198.18.0.0/15, 198.51.100.0/24, 203.0.113.0/24, 224.0.0.0/4, 240.0.0.0/4 }
define bogons_v6 = { ::/8, 0100::/64, 2001:2::/48, 2001:10::/28, 2001:db8::/32, 3ffe::/16, fc00::/7, fec0::/10, ff00::/8 }

add table netdev filter
add chain netdev filter ens192 { type filter hook ingress device ens192 priority 0; policy accept; }

# bloco pra bloqueio de alguns pacotes indesejados
add rule netdev filter ens192 tcp flags & (fin|syn|rst|psh|ack|urg) == 0x0 counter drop
add rule netdev filter ens192 tcp flags & (fin|syn) == fin|syn counter drop
add rule netdev filter ens192 tcp flags & (syn|rst) == syn|rst counter drop
add rule netdev filter ens192 tcp flags & (fin|rst) == fin|rst counter drop
add rule netdev filter ens192 tcp flags & (fin|ack) == fin counter drop
add rule netdev filter ens192 tcp flags & (ack|urg) == urg counter drop
add rule netdev filter ens192 tcp flags & (fin|ack) == fin counter drop
add rule netdev filter ens192 tcp flags & (psh|ack) == psh counter drop
add rule netdev filter ens192 tcp flags & (fin|syn|rst|psh|ack|urg) == fin|syn|rst|psh|ack|urg counter drop
add rule netdev filter ens192 tcp flags & (fin|syn|rst|psh|ack|urg) == 0x0 counter drop
add rule netdev filter ens192 tcp flags & (fin|syn|rst|psh|ack|urg) == fin|psh|urg counter drop
add rule netdev filter ens192 tcp flags & (fin|syn|rst|psh|ack|urg) == fin|syn|psh|urg counter drop
add rule netdev filter ens192 tcp flags & (fin|syn|rst|psh|ack|urg) == fin|syn|rst|ack|urg counter drop

# bloqueio de bogons
add rule netdev filter ens192 ip saddr $bogons_v4 counter drop
add rule netdev filter ens192 ip6 saddr $bogons_v6 counter drop

# liberacao de envio de logs dos servidores autorizados e na sequencia um bloqueio geral da porta 514/UDP
add rule netdev filter ens192 ip6 saddr { 2001:db8:face:b00c:192:168:10:25, 2001:db8:c0ca:c01a:192:168:0:3, 2001:db8:dead::192:168:200:4 } udp dport 514 counter accept
add rule netdev filter ens192 udp dport 514 counter drop

O script acima utiliza a netdev do nftables para fazer bloqueios. Ela é extremamente performática e bem mais eficiente que a table RAW do Netfilter/IPTables. Você deve substituir a interface ens192 pela interface do seu servidor. Os blocos estão bem separados e definimos duas variáveis bogons_v4 e bogons_v6 que dispensam comentários sobre suas finalidades. Temos o bloco que bloqueia alguns tipos de pacotes indesejados, temos o bloco que bloqueia os bogons e o último bloco é onde liberamos os servidores e equipamentos do nosso artigo, de enviarem seus logs. Por último bloqueamos a porta 514/UDP. Não esqueça de fazer as duas últimas linhas também para o seu acesso ssh. É claro que o script acima pode ser feito, perfeitamente, em iptables mas foi feito assim, para demonstrar um novo jeito de se implementar firewall nas Distribuições Linux mais recentes.

Configurando o envio de log nos servidores e equipamentos do nosso exemplo:

Estamos chegando quase no fim deste artigo. Agora serão mostrados exemplos de configuração para envio dos logs, para o Servidor de Logs. Em teoria quase todo sistema gera logs e em muitos casos, podem ser enviados remotamente para um agregador de logs. Aqui vamos ver 3 exemplos apenas, mas basta procurar como fazer no seu sistema, utilizando o recurso de envio de logs via servidor syslog.

No servidor Linux (2001:db8:face:b00c:192:168:10:25), incluiremos a seguinte linha no final do arquivo /etc/rsyslog.conf. Essa linha instrui o rsyslog, para enviar todos os logs para o Servidor de Logs. Bem simples.

*.* @[2001:db8:106::192:168:1:1]:514

Reinicie o serviço rsyslogd e cheque seu status:

# systemctl restart rsyslog.service
# systemctl status rsyslog.service
● rsyslog.service - System Logging Service
   Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2021-04-23 21:28:50 -03; 5min ago
     Docs: man:rsyslogd(8)
           https://www.rsyslog.com/doc/
 Main PID: 31056 (rsyslogd)
    Tasks: 4 (limit: 4915)
   Memory: 1.0M
   CGroup: /system.slice/rsyslog.service
           └─31056 /usr/sbin/rsyslogd -n -iNONE

Verifique se no Servidor de Logs, foi criado o arquivo de log. Se o arquivo não foi criado é porque algum dos passos acima foi executado de forma errada. Dê uma conferida.

Agora faremos a configuração em um servidor de CGNAT DANOS (2001:db8:c0ca:c01a:192:168:0:3). Para isso acesse seu servidor, entre em modo de configuração e execute o comando exemplo alterando para o IP do seu servidor:

set system syslog host '[2001:db8:106::192:168:1:1]:514' facility all level info

Por último a configuração de um RouterOS (2001:db8:dead::192:168:200:4). Primeiro vamos no Winbox em System/Logging e na aba Actions vamos criar uma ação do tipo remota. Nela vamos apontar para o IP do Servidor de Logs conforme abaixo:

Após criarmos a Action, iremos na aba Rules e criaremos as duas regras, que neste caso, serão usadas para enviar os logs de IPv6 para o Servidor de Logs:

Verifique se os logs estão sendo gerados no Servidor de Logs e finalizamos por aqui.

Espero que esse artigo seja útil, principalmente naqueles momentos quando se recebe uma ordem judicial para entrega de logs de conexão.

Autor: Marcelo Gondim