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 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.