Introdução
O principal objetivo deste artigo é a configuração do Rsyslog de forma que máquinas distintas com sistemas operacionais distintos enviem seus logs do sistema para um servidor centralizado através da rede.
Logs são arquivos de texto gerados pelo sistema e que podem ajudar a descobrir problemas na execução de softwares, problemas de hardware, tentativas de invasão, acessos indevidos, entre outras coisas.
É muito importante manter estes arquivos seguros e intactos. Em uma auditoria de sistemas, estes logs poderão e serão bastante importantes, portanto, a sua integridade e disponibilidade são importantíssimas para um administrador de rede.
Com a atual abrangência das redes e de suas complexidades, a administração tornou-se uma tarefa que exige o máximo de recursos que sejam disponibilizados para que torne mais fácil esta tarefa.
A utilização de ferramentas que unifiquem a administração viabiliza a administração de redes complexas.
Utilizando o Rsyslog, que tem suporte à maioria dos sistemas operacionais utilizados no mercado, a centralização dos logs torna-se possível e de fácil configuração, com grande capacidade de configuração e customização de acordo com a necessidade, sem causar impacto na rede.
Logs são arquivos de texto gerados pelo sistema e que podem ajudar a descobrir problemas na execução de softwares, problemas de hardware, tentativas de invasão, acessos indevidos, entre outras coisas.
É muito importante manter estes arquivos seguros e intactos. Em uma auditoria de sistemas, estes logs poderão e serão bastante importantes, portanto, a sua integridade e disponibilidade são importantíssimas para um administrador de rede.
Com a atual abrangência das redes e de suas complexidades, a administração tornou-se uma tarefa que exige o máximo de recursos que sejam disponibilizados para que torne mais fácil esta tarefa.
A utilização de ferramentas que unifiquem a administração viabiliza a administração de redes complexas.
Utilizando o Rsyslog, que tem suporte à maioria dos sistemas operacionais utilizados no mercado, a centralização dos logs torna-se possível e de fácil configuração, com grande capacidade de configuração e customização de acordo com a necessidade, sem causar impacto na rede.
O que é o Rsyslog
O Rsyslog é um syslog com foco na segurança e confiabilidade, oferecendo suporte para várias operações como bufferização sob demanda, syslog confiável para TCP, SSL e TLS, gravando em diversos banco de dados diferentes (MySQL, PostgreSQL, Oracle,...), e-mails de alerta, formatos de saída totalmente configuráveis, sendo possível filtrar qualquer parte da mensagem, compressão de mensagem, conversão de arquivos textos para o Rsyslog.
Existem versões avançadas que permitem a customização para o ambiente corporativo, como proteção por criptografia. Um ponto forte é a facilidade de configuração para usuários novatos e inexperientes.
O objetivo do projeto Rsyslog é fornecer um daemon syslog com características mais ricas e confiáveis, mantendo altas as suas capacidades de reposição de estoque syslogd.
Por ser "confiável", isto significa que possui suporte para modos de transmissão confiáveis como TCP ou RFC 3195 (syslog-confiável). O Rsyslog também trabalha muito bem com infraestrutura de logs centralizados, implementando criptografia no tráfego, verificação na perda de dados e gerenciamento de banco de dados.
Como funciona
É necessário que se instale o Rsyslog em todos os nós que deverão ser monitorados e no servidor central.
Uma vez configurado o servidor e o cliente, o agente do cliente irá comunicar-se com o agente do servidor central.
O banco de dados no qual o Rsyslog do servidor central irá inserir os logs poderá ser qualquer um, sendo que o utilizado neste cenário será o PostgreSQL 9.1.
Instalação do Rsyslog
Esta instalação será dirigida à distribuição CentOS 6.0, via YUM.
Antes de instalar o Rsyslog, deverá ser verificado se há o serviço syslog. Caso haja, o syslog deverá ser desinstalado para que o Rsyslog seja instalado.
Para instalar o Rsyslog:
# yum install rsyslog
Com o serviço do Rsyslog instalado, agora será necessário configurar para iniciar a utilização.
Configuração do servidor
Rsyslog é configurado através do arquivo rsyslog.conf, normalmente encontrado em /etc.Mas, antes de inciar a configuração do arquivo rsyslog.conf, que será direcionada a um banco de dados, será necessário que haja um banco de dados instalado e ativo, para que seja criado o banco e suas tabelas default.
O script de criação do banco de dados original, que vem no pacote durante a instalação, está disponível no arquivo /usr/share/doc/rsyslog-versão/createDB.sql:
CREATE DATABASE 'Syslog' WITH ENCODING 'SQL_ASCII';
\c Syslog;
CREATE TABLE SystemEvents
(
ID serial not null primary key,
CustomerID bigint,
ReceivedAt timestamp without time zone NULL,
DeviceReportedTime timestamp without time zone NULL,
Facility smallint NULL,
Priority smallint NULL,
FromHost varchar(60) NULL,
Message text,
NTSeverity int NULL,
Importance int NULL,
EventSource varchar(60),
EventUser varchar(60) NULL,
EventCategory int NULL,
EventID int NULL,
EventBinaryData text NULL,
MaxAvailable int NULL,
CurrUsage int NULL,
MinUsage int NULL,
MaxUsage int NULL,
InfoUnitID int NULL ,
SysLogTag varchar(60),
EventLogType varchar(60),
GenericFileName VarChar(60),
SystemID int NULL
);
CREATE TABLE SystemEventsProperties
(
ID serial not null primary key,
SystemEventID int NULL ,
ParamName varchar(255) NULL ,
ParamValue text NULL
);
Este arquivo está na linguagem SQL padrão, logo, é compatível com qualquer banco que trabalhe com essa linguagem.
Um ponto importante a ressaltar é quanto a codificação do banco utilizado pelo Rsyslog, que é por padrão SQL_ASCIII.
Por padrão, de instalação do PostgreSQL, caso não seja setado uma codificação padrão, a "LATIN1" é considerada default por conter todos os caracteres das línguas européias (o português está incluso nesse grupo), mas a maioria dos bancos utilizam "UTF-8", pela interoperabilidade dos símbolos (podendo conter caracteres de todas línguas).
Ao tentar criar um banco na codificação "SQL_ASCII" numa instalação que já possui um padrão de codificação diferente dessa, apresentará erros.
Para sanar este erro, basta que crie o banco "SYSLOG" (conforme arquivo de criação do banco createDB.sql) em outra template que não a principal (onde foi criado o banco postgres).
Na instalação, por default, são criados mais duas templates: a "template0" e a "template1". Crie o banco em uma delas.
A modificação sugerida para o PostgreSQL 9.1 segue abaixo:
CREATE DATABASE 'Syslog' WITH ENCODING 'SQL_ASCII' TEMPLATE=template0;
\c Syslog;
CREATE TABLE SystemEvents
(
ID serial not null primary key,
CustomerID bigint,
ReceivedAt timestamp without time zone NULL,
DeviceReportedTime timestamp without time zone NULL,
Facility smallint NULL,
Priority smallint NULL,
FromHost varchar(60) NULL,
Message text,
NTSeverity int NULL,
Importance int NULL,
EventSource varchar(60),
EventUser varchar(60) NULL,
EventCategory int NULL,
EventID int NULL,
EventBinaryData text NULL,
MaxAvailable int NULL,
CurrUsage int NULL,
MinUsage int NULL,
MaxUsage int NULL,
InfoUnitID int NULL ,
SysLogTag varchar(60),
EventLogType varchar(60),
GenericFileName VarChar(60),
SystemID int NULL
);
CREATE TABLE SystemEventsProperties
(
ID serial not null primary key,
SystemEventID int NULL ,
ParamName varchar(255) NULL ,
ParamValue text NULL
);
Após criar o banco e as tabelas, algumas configurações deverão ser feitas no arquivo rsyslog.conf. Inicialmente iremos habilitar o suporte a banco de dados.
Suporte de banco de dados em Rsyslog é integrado por módulos (plugin) carregáveis. Para usar a funcionalidade de banco de dados, o plugin do banco de dados deve ser habilitado no arquivo de configuração antes que a primeira tabela do banco de dados seja usada.
Isto é feito através da configuração da diretiva abaixo, no inicio do arquivo de configuração:
$ModLoad ompgsql
Neste caso estaremos habilitando o suporte ao banco de dados PostgreSQL, escolhido como padrão. Vários bancos de dados são suportados.
Em seguida nós precisamos dizer ao Rsyslogd para gravar dados no banco de dados. Como usamos o esquema padrão, não precisamos definir um modelo para isso.
Podemos usar a hardcoded (rsyslogd lida com o modelo adequado de um link). Então, tudo o que precisamos fazer, por exemplo, para o PostgreSQL, é adicionar uma linha simples seletor para /etc/rsyslog.conf:
Podemos usar a hardcoded (rsyslogd lida com o modelo adequado de um link). Então, tudo o que precisamos fazer, por exemplo, para o PostgreSQL, é adicionar uma linha simples seletor para /etc/rsyslog.conf:
*.* :ompgsql:database-server,database-name,database-userid,database-password
Onde:
database-server : É o nome ou o endereço IP do servidor;
database-name : É o nome do banco onde as tabelas foram criadas;
database-userid : É o nome do usuário que tem acesso ao banco;
database-password : É é a senha do usuário.
database-server : É o nome ou o endereço IP do servidor;
database-name : É o nome do banco onde as tabelas foram criadas;
database-userid : É o nome do usuário que tem acesso ao banco;
database-password : É é a senha do usuário.
Com estas configurações feitas, basta iniciar o serviço do Rsyslog e verificar a entrada de dados na tabela do banco de dados.
Toda esta entrada de dados pode ser configurada de acordo com a necessidade e do ambiente em questão. Neste caso, os logs serão originados de dois sistemas operacionais distintos, sendo um Windows Server 2003 e um GNU/Linux Red Hat 5.5 Enterprise Edition.
Os principais logs do GNU/Linux serão enviados ao servidor centralizado, como o /var/log/messages, e outros específicos como do DHCP, Squid e Apache.
No Windows serão enviados os logs do "System Events Reports".
Continua Parte 2...
Toda esta entrada de dados pode ser configurada de acordo com a necessidade e do ambiente em questão. Neste caso, os logs serão originados de dois sistemas operacionais distintos, sendo um Windows Server 2003 e um GNU/Linux Red Hat 5.5 Enterprise Edition.
Os principais logs do GNU/Linux serão enviados ao servidor centralizado, como o /var/log/messages, e outros específicos como do DHCP, Squid e Apache.
No Windows serão enviados os logs do "System Events Reports".
Continua Parte 2...
Postado no Fórum da Brutal Security por Natan, sem identificação da fonte original.
0 comentários:
Postar um comentário