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 seria? 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 o 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.

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