Mudanças entre as edições de "Servidor de Logs"
| Linha 64: | Linha 64: | ||
# mkdir /var/log/mikrotiks | # mkdir /var/log/mikrotiks | ||
</pre>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. | </pre>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'''. | |
| − | 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'''.<pre> | + | <pre> |
module(load="imudp") | module(load="imudp") | ||
input(type="imudp" port="514") | input(type="imudp" port="514") | ||
Edição das 19h08min de 23 de abril de 2021
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.
Índice
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
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.
