Mudanças entre as edições de "Servidor de Logs"
(só Jesus salva e nós, se não quisermos perder o que fizemos.) |
|||
| Linha 1: | Linha 1: | ||
| − | 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. | + | 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 [https://wiki.brasilpeeringforum.org/w/CGNAT_Bulk_Port_Allocation_com_DPDK 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? | + | 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 == | + | == <big>Sistema e recursos que usaremos nesse Servidor</big> == |
* Debian 10 (Buster) - Sistema Operacional onde rodaremos os serviços. | * Debian 10 (Buster) - Sistema Operacional onde rodaremos os serviços. | ||
* Rsyslog - serviço responsável por enviar e coletar os logs dos servidores. | * Rsyslog - serviço responsável por enviar e coletar os logs dos servidores. | ||
| Linha 10: | Linha 10: | ||
* 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. | * 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. | * 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? | ||
| + | |||
| + | == <big>Diagrama exemplo</big> == | ||
| + | [[Arquivo:Servidor logs.io.png|esquerda|miniaturadaimagem|747x747px|'''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.''']] | ||
Edição das 16h53min 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 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.
- 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?
