Centralização de Logs
-
Upload
jader-lima -
Category
Documents
-
view
318 -
download
0
Transcript of Centralização de Logs
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 1/42
FACULDADE SANTA MARIA
PÓS-GRADUAÇÃO EM SEGURANÇA DE REDES E SISTEMAS
TRABALHO FINAL DA DISCIPLINA
Centralização de Logs
ALUNOS: DANIEL PEREIRA DE MELO
EDUARDO KROPNICZKI AZEVEDO
FÁBIO IRAKTAN
GLEUDSON PINHEIRO VAREJÃO JUNIOR
KLEBER ALVES LEAL
DATA: 26/08/2010
DISCIPLINA: ARQUITETURA DE REDES E FERRAMENTAS DE AUDITORIA
PROFESSOR: JOÃO PAULO CAMPELLO
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 2/42
Índice1 INTRODUÇÃO.....................................................................................................................................32 RESUMO EXECUTIVO.......................................................................................................................43 IMPLEMENTAÇÃO TÉCNICA...........................................................................................................6
3.1 Instalando e Configurando o Firewall............................................................................................63.1.1 Configuração da Rede.............................................................................................................63.1.2 Política do Firewall.................................................................................................................8
3.2 Serviços da DMZ..........................................................................................................................133.2.1 Proxy Reverso.......................................................................................................................133.2.2 SQUID..................................................................................................................................173.2.3 Servidor de VPN...................................................................................................................23
3.3 Serviços de Produção...................................................................................................................323.3.1 Aplicação WEB vulnerável...................................................................................................323.3.2 Configurando Log4J para enviar logs para o Syslog............................................................34
3.4 Log Host.......................................................................................................................................363.5 Log Clients...................................................................................................................................373.6 Rotacionamento de Logs..............................................................................................................38
4 TERMINOLOGIA...............................................................................................................................405 CONCLUSÕES...................................................................................................................................416 REFERÊNCIAS...................................................................................................................................42
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 3/42
1 INTRODUÇÃO
Este documento tem como objetivo documentar uma solução de centralização de logs gerados pelos
diversos serviços em uma rede de computadores. Para demonstrar a solução tomamos como exemplo
configuração de alguns serviços frequentemente utilizados em redes corporativas, como firewall,
servidores de aplicações java e um proxy.
O público alvo deste documento são administradores de rede que pretendem montar uma solução de
armazenamento de logs centralizado, facilitando a autidoria e evitando que invasores apaguem os
rastros deixados em suas ações. Para a execução do conteúdo aqui descrito é necessário que o leitor
tenha conhecimento sobre administração do sistema operacional Linux, conhecimento básico sobretomcat, rede e firewall.
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 4/42
2 RESUMO EXECUTIVO
Virtualmente todos os serviços computacionais geram informações de auditoria chamadas Logs. Vários
desafios podem ser apontados para os administradores de sistemas para executar a tarefa principal, queé extrair informações relevantes da massa de dados gerada:
a) Descentralização: Normalmente os serviços estão distribuídos pelo parque tecnológico,
em máquinas fisicamente separadas e com arquiteturas heterogêneas.
b) Formato: Os sistemas geram os seus próprios logs em formatos diferentes, o que
dificulta bastante a tarefa de consolidação e extração de informação.
c) Limiar (Threshold) dos Logs: Configurar os diversos serviços de modo que a
quantidade de dados gerado atinja dois objetivos: Evitar o armazenamento de conteúdo
desnecessário; e , por outro lado, garantir que nenhum dado importante para a extração de
informação seja gerado.
Este trabalho objetiva endereçar o primeiro, e, em menor grau, o segundo desafio. A proposta é criar
um ambiente de Centralização de Logs, composto por um segmento de rede isolado dos demais e de
um Servidor de Logs, chamado de Log Host.
Este ambiente de rede isolado abrigará o software Syslog-ng, que atuará fazendo o recebimento dos
logs dos diversos hospedeiros situados na rede corporativa, que se conectarão a ele através de uma
Virtual Private Network.
Os serviços que serão incluídos no processo de centralização dos logs foram escolhidos por serem
essenciais ao funcionamento do negócio. Eles incluem: Servidor Proxy Squid, Servidor de Aplicações
Java Apache Tomcat e Servidor Web Apache em modo Proxy Reverso.
As dificuldades encontradas concentraram-se na forma de comunicação dos serviços computacionais
com o Log Host, já que, dada sua heterogeneidade, foi necessário um esforço de pesquisa eimplementação considerável.
A execução deste trabalho trouxe como resultado o fornecimento de uma ferramenta de extração de
informação bastante útil aos administradores, uma vez que estes podem agora recorrer a um único
servidor que irá centralizar todos os logs. Algumas possibilidades se abrem com esse cenário. Uma
delas é a facilidade de implementação de uma ferramenta automação do processo de análise dos logs.
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 5/42
Por outro lado, não se descuidou da questão da segurança da informação, já que o ambiente de
centralização está praticamente isolado dos demais.
A figura abaixo detalha o cenário da solução proposta:
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 6/42
3 IMPLEMENTAÇÃO TÉCNICA
3.1 Instalando e Configurando o Firewall
Nesta sessão trataremos da instalação e configuração do Firewall, que será empregado para
aplicar uma política de segurança nos diversos segmentos da rede, seguindo a descrição da topologia
concebida no inicio desse documento, realizando também a regulação do trafego de dados entre os
segmentos e impedindo a transmissão e, ou, recepção de acessos maliciosos e não autorizados de uma
rede para outra. Para implementação deste serviço, utilizaremos o Firewall Iptables. A escolha do
Iptables se deve ao fato dele ser Software Livre, por ser nativo na maioria das atuais distribuições
Linux, bem como pela grande escala de utilização no mercado, fazendo com que o mesmo possua uma
constante atualização das falhas e mantenha um suporte efetivo através da vasta documentação
disponível.
Com havíamos mencionado, o Iptables é uma ferramenta nativa do Kernel Linux e está disponível na
maioria das atuais distribuições Linux. No nosso caso em especificado, implementaremos o Firewall
sob a distribuição Ubuntu Server 9.10 que é derivada do GNU/Debian.
Como premissa básica, consideramos que o sistema operacional está completamente instalado,
necessitando então da configuração das redes para os seus respectivos segmentos, da configuração de
regras para o acesso a internet e das regras para a implantação da política de segurança definida durante
o planejamento
3.1.1 Configuração da Rede
O Firewall deve possuir 05(quatro) interfaces de rede, conforme mostrado na topologia da rede.
Para realizar a configuração das interfaces devemos editar e modificar o arquivo interfaces encontrado,
para esta distribuição, no diretório /etc/network/ . Para tanto, vamos rodar em um terminal os
respectivos comandos:
# cd /etc/network/# vim interfaces
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 7/42
Agora devemos adicionar as seguintes linhas no arquivo: interfaces. Elas darão conta da configuração
de cada interface de rede para cada segmento da nossa topologia:
#---------------------------------------
#Autor: Gleudson Junior#Data: 11/09/2010#---------------------------------------
#-------------------------------------------------#CONFIGURA ÇÃ O DA REDE EXTERNA (INTERNET)#-------------------------------------------------auto eth0iface eth0 inet dhcp
#---------------------------------------------------#CONFIGURA ÇÃ O DA REDE DMZ
#---------------------------------------------------auto eth1iface eth1 inet static
address 192.168.1.1network 192.168.1.0netmask 255.255.255.0broadcast 192.168.1.255
#----------------------------------------------------#CONFIGURA ÇÃ O DA REDE DE LOG#----------------------------------------------------auto eth2iface eth2 inet static
address 192.168.2.1network 192.168.2.0netmask 255.255.255.0broadcast 192.168.2.255
#------------------------------------------------------------#CONFIGURA ÇÃ O DA REDE DE PRODUÇÃ O#------------------------------------------------------------auto eth3iface eth3 inet static
address 192.168.3.1network 192.168.3.0netmask 255.255.255.0broadcast 192.168.3.255
#------------------------------------------------------------#CONFIGURA ÇÃ O DA REDE CORPORATIVA #------------------------------------------------------------auto eth4iface eth4 inet static
address 192.168.4.1network 192.168.4.0netmask 255.255.255.0broadcast 192.168.4.255
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 8/42
#SALVA E FECHAR:x
Vamos reiniciar a configuração da rede para que as interfaces recebam as devidas alterações. Rode
então o comando abaixo:
# /etc/init.d/networking restart
3.1.2 Política do Firewall
Chegou o momento de configurarmos as regras para a política de segurança estabelecida para rede,
bem como a liberação do acesso a internet para os segmentos. Para realizar a configuração das regras
precisamos primeiro entender o conceito básico sobre o Firewall Iptables, descrevendo a função
especifica que cada tabela exerce e como estas são aplicadas.
Seguem abaixo alguns desses conceitos:
As regras do Iptables são como filtros aplicados para que o mesmo implemente o que chamamos defiltro de pacote de acordo com o endereço IP/porta de origem/destino, interface de origem/destino, etc.
As regras são armazenadas dentro dos chamados chains e processadas na ordem que são inseridas.
Estas mesmas regras são armazenadas no kernel do Linux, o que significa que quando o sistema é
reinicializado as mesmas são perdidas.
A sintaxe básica de uma regra é a seguinte:
# iptables comando parâmetros extensões
• Comandos principais
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 9/42
Basicamente o Iptables tem as seguintes regras:
• DROP: nega pacotes sem envio de um flag Reset - R
• ACCEPT: aceita pacotes.
• REJECT: nega pacotes mas envia um flag Reset - R
O envio de um flag reset pode facilitar a detecção por um scanner de uma porta aberta em um sistema,
por isso utilizamos normalmente a política DROP.
•
Tabelas (tables)
As tabelas são áreas na memória usadas para armazenar as regras (chains). Elas podem utilizar a
seguinte sintaxe:
# iptables -opções -t tabela
Existem 03 tabelas disponíveis no Iptables. São elas:
a) Tabela filter: considerada a tabela padrão. Contém 03 chains básicas:
• INPUT: utilizada para pacotes que chegam à própria máquina;
• OUTPUT: utilizada a para pacotes que saem da própria máquina;
• FORWARD: utilizada para pacotes que são redirecionados para outra interface de rede. É
também utilizada para mascaramento de pacotes.
b) Tabela Nat: usada para passagem de pacotes que podem gerar outra conexão. Um exemplo
clássico é o mascaramento (MASQUERADE), nat, port forwarding e proxy transparente são
alguns. Contem 03 chains básicas:
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 10/42
• PREROUTING: utilizada quando os pacotes precisam ser redirecionados logo que chegam;
• OUTPUT: utilizada quando os pacotes gerados localmente precisam ser redirecionados antes de
serem roteados;
• POSTROUTING: utilizada quando os pacotes precisam ser modificados após o tratamento de
roteamento.
c) Tabela mangle: utilizada para alterações especiais de pacotes como, por exemplo, modificar o
tipo de serviço (TOS) de um pacote. Ideal para produzir informações falsas para scanners
Possui 02 chains padrões:
• PREROUTING: utilizada quando os pacotes precisam ser redirecionados logo que chegam;
• OUTPUT: utilizada quando os pacotes gerados localmente precisam ser redirecionados antes de
serem roteados.
Bem, agora chega a hora de configurar o Iptables de verdade. Antes devemos criar um arquivo que
alocará todas as regras do Firewall, vamos chamá-lo de meu_firewall, ele deverá ficar nodiretório /etc/network/if-up.d/ , isso fará com que o sistema leia todas as regras sempre que for
levantando. Para tanto, vamos rodar os respectivos comandos em um terminal:
# cd /etc/network/if-up.d# vim meu_firewall
Agora devemos adicionar as seguintes linhas no arquivo: meu_firewall. Elas darão conta da
configuração das regras definidas para cada segmento da topologia:
!#/Bin/sh#---------------------------------------#Autor: Gleudson Junior#Data: 11/09/2010#---------------------------------------
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 11/42
#--------------------------------------#CARREGANDO MÓDULOS#--------------------------------------modprobe ip_conntrack_ftpmodprobe ip_nat_ftp
#--------------------------------------------------------------------#ATIVANDO O REDIRECIONAMENTO DE PACOTES#--------------------------------------------------------------------echo 1 > /proc/sys/net/ipv4/ip_forward
#-------------------------------------------------------#REMOVENDO REGRAS DAS TABELAS#-------------------------------------------------------iptables –Fiptables –t nat –Fiptables –t mangle –F
#---------------------------------------------------#APAGANDO CHAINS DAS TABELAS#---------------------------------------------------iptables –Xiptables –t nat –Xiptables –t mangle –X
#--------------------------------------------------------#ZERANDO CONTADORES DAS TABELAS#--------------------------------------------------------iptables –Ziptables –t nat –Ziptables –t mangle –Z
#----------------------------------------------------------------#POLITICA PADRÃ O (FECHANDO O FIREWALL)
#----------------------------------------------------------------iptables –P INPUT DROPiptables -P OUTPUT DROPiptables –P FORWARD DROP
#----------------------------------------------------------#LIBERANDO A INTERFACE DE LOOPBACK#----------------------------------------------------------iptables –A INPUT –i lo –j ACCEPT
#---------------------------------------------------------#MANTENDO O ESTADO DAS CONEXÕES#---------------------------------------------------------
iptables –A INPUT –m state --state ESTABLISHED,RELATED –j ACCEPTiptables –A OUTPUT –m state --state ESTABLISHED,RELATED –j ACCEPTiptables –A FORWARD –m state --state ESTABLISHED,RELATED –j ACCEPT
#----------------------------------------------------------------------#ATIVANDO O MASCARAMENTO – LIBERANDO ACESSO EXTERNO AOS SEGMENTOS#----------------------------------------------------------------------iptables –t nat –A POSTROUTING –s 192.168.1.0/24 –o eth0 –j MASQUERADEiptables –t nat –A POSTROUTING –s 192.168.2.0/24 –o eth0 –j MASQUERADEiptables –t nat –A POSTROUTING –s 192.168.3.0/24 –o eth0 –j MASQUERADEiptables –t nat –A POSTROUTING –s 192.168.4.0/24 –o eth0 –j MASQUERADE
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 12/42
#-----------------------------------------------------#LIBERANDO A PORTA PARA CONEXÃ O NO SERVIDOR DE VPN#-----------------------------------------------------iptables -A FORWARD -d 192.168.1.11 -p udp --dport 1194 -j ACCEPT
#--------------------------------------------------------------#PROTEÇÃ O CONTRA ATAQUES CONHECIDOS#--------------------------------------------------------------iptables –A INPUT –m state –state INVALID –j DROP#SYNiptables -A FORWARD -p tcp –syn -m limit –limit 1/s -j ACCEPT#SCANSiptables -A FORWARD -p tcp –tcp-flags SYN,ACK,FIN,RST RST -m limit –limit 1/s -jACCEPT#PING DA MORTEiptables -A FORWARD -p icmp –icmp-type echo-reply -m limit –limit 1/s -j RETURN
#SALVA E FECHAR:x
Devemos também atentar para determinar a permissão correta no arquivo meu_firewall, nesse caso será
a permissão de execução. Vamos dá essa permissão com o comando abaixo:
# chmod +x meu_firewall
Após realizar todas as configurações é hora de rodar o script e iniciar o Firewall. Para tanto utilize o
comando abaixo:
# ./meu_firewall
Pronto, após realizar todos os passos conforme descritos nesse documento, terão o Firewall Iptables em
produção, executando as devidas regras para a política de segurança planejada para a rede. Falta apenas
testar se realmente as configurações foram válidas e funcionam, para isso, levante uma maquina cliente
com as configurações de rede do segmento que ela pertence.
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 13/42
3.2 Serviços da DMZ
3.2.1 Proxy Reverso
Nesta sessão trataremos da instalação e configuração do Proxy Reverso, que será instalado nas
imediações dos servidores da DMZ, ou seja, ele será colocado como o primeiro servidor que a internet
enxergará, ficará incumbido de efetuar o repasse do trafego de rede recebido para o conjunto de
servidores da DMZ. Para implementação deste servidor de Proxy Reverso utilizaremos o Apache. A
escolha se deve ao fato do Apache ser Software Livre, por estar presente nos repositórios oficiais das
principais distribuições Linux e também por possuir uma grande fatia do mercado em servidores Web,
fazendo com que o mesmo possua uma constante atualização das falhas e mantenha um suporte efetivo
através da vasta documentação disponível. Outro ponto importante na escolha no Apache, foi a
facilidade na sua implementação. Nos estudos realizados tínhamos também o Squid e o Varnish como
opções, porem os resultados não foram tão satisfatórios quanto no Apache.
O Apache está disponível para instalação em uma grande variedade de sistemas operacionais, incluindo
Linux e Windows. Neste documento trataremos da instalação sob o sistema operacional Linux, mais
especificamente na distribuição CentOS 5.4 que é derivado do Red Hat .
Como premissa básica, consideramos que o sistema operacional está completamente instalado, com a
rede configurada de acordo com as faixas de IP definidas no Firewall e também que o servidor possui
acesso à Internet para realizar o acesso aos repositórios de pacotes.
• Instalação e Configuração do Apache
Primeiro vamos instalar o Apache 2.2.3 através do comando abaixo:
# yum install httpd httpd-devel
Com o Apache devidamente instalado, vamos partir para sua configuração. Como nosso intuito é
disponibilizar um servidor de Proxy Reverso, vamos tratar apenas da configuração dos módulos
específicos do servidor Apache.
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 14/42
Agora precisamos especificar nosso cenário, o que facilitará no entendimento ao decorrer da
implementação. Então:
• Teremos a pagina principal da empresa: www.posdeseguranca.com
• Teremos uma aplicação denominada alunos da empresa: sca.posdeseguranca.com
A intenção é tornar todos os serviços da empresa acessíveis somente pela pagina principal:www.posdeseguranca.com.
Por tanto, após efetuar a configuração e iniciar o serviço, teremos:
• Aplicação sca (Sistema de Controle de Alunos) em: www.posdeseguranca.com/sca
Vamos partir para configuração dos módulos do Proxy Reverso no Apache, acessando o arquivo: /etc/httpd/conf/httpd.conf . Devemos verificar se as seguintes linhas estão comentadas no arquivo. É
necessário tirar os comentários (#).Nota: é preferencial fazer um backup do arquivo original httpd.conf antes de qualquer modificação,assim se ocorrer algum problema durante a implementação poderemos recuperar a configuração inicialdo Apache.
Vamos rodar os seguintes comandos em um terminal:
# cd /etc/httpd/conf# cp httpd.conf httpd.conf.ORIG# vim httpd.conf
LoadModule rewrite_module modules/mod_rewrite.soLoadModule proxy_module modules/mod_proxy.soLoadModule proxy_http_module modules/mod_proxy_http.soLoadModule disk_cache_module modules/mod_disk_cache.soLoadModule deflate_module modules/mod_deflate.soLoadModule headers_module modules/mod_headers.so
Agora vamos adicionar e salvar as seguintes linhas no final do arquivo: /etc/httpd/conf/httpd.conf
<VirtualHost *:80>ServerName www.posdeseguranca.com ProxyPreserveHost onProxyPass /sca http://sca.posdeseguranca.com/scaProxyPassReverse /sca http://www.podeseguranca.com/sca
<Location /sca>Order deny,allow
</Location>
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 15/42
#SALVA E FECHA :x
• Configuração dos Hosts
Chegou o momento de configurar o arquivo: /etc/hosts, para que o mesmo processe a tradução dos ips
para os nomes escolhidos (cenário). Para tanto, devemos rodar os comandos:
# cd /etc# vim hosts
Agora vamos inserir e salvar as seguintes linhas no arquivo: hosts:
192.168.1.10 www.posdeseguranca.com 192.168.1.10 sca.posdeseguranca.com
#SALVA E FECHAR:x
Hora de mudar o nome do servidor para o nome que escolhemos e especificamos no cenário da
implementação: www.posdeseguranca.com. Vamos editar e salvar o arquivo abaixo:
# vim /etc/sysconfig/network
Altere o valor, conforme descrito abaixo:
HOSTNAME= www.posdeseguranca.com
#SALVA E FECHAR:x
Após a execução de todos os passos mencionados acima, o servidor de Proxy Reverso está configuradoe pronto para entrar em produção. Para iniciá-lo execute o comando abaixo:
# service httpd start
Se todas as configurações foram realizadas com sucesso deverá ser exibida a seguinte mensagem:
* Starting web server apache2 [ OK ]
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 16/42
• Configuração do apache para enviar os logs para o LogHost
Primeiramente vamos configurar o arquivo httpd.conf, que fica localizado no diretório
/etc/http/conf/httpd.conf , fazendo com que o mesmo envie os logs do servidor httpd para o syslog. Abraum terminal e digite os seguintes comandos:
# cd /etc/http/conf/# vim httpd.conf
Dentro do arquivo vamos localizar as seguintes linhas: ErrorLog e CustomLog. Vamos precisar
comentar algumas regras pré-definidas e criar novas logo abaixo. Obs.: para localizar essas linhas
usando o vim, por exemplo, basta digitar “/” e a descrição da sua busca:
Vamos comentar as regras:
ErrorLog logs/error_logCustomLog logs/access_log combined
Agora vamos acrescentar as seguintes regras, bem abaixo da sua respectiva linha:
ErrorLog syslog:local1CustomLog syslog:local1 combined
Após a execução de todos os passos, devemos restartar o Proxy Reverso:
# service httpd restart
Agora vamos configurar o arquivo syslog.conf, que fica localizado no diretório /etc/ , fazendo com que
o mesmo envie os logs do servidor para o Servidor de LogHost . Abra um terminal digite os seguintes
comandos:
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 17/42
# cd /etc/# vim syslog.conf
No final do arquivo vamos acrescentar as seguintes linhas:
#----------------------------# RECEBE OS LOGS DO APACHE#----------------------------local1.* /var/log/apache.log
#-----------------------------------------# ENVIA OS LOGS DO APACHE PARA O LOGHOST#-----------------------------------------local1.* @10.8.0.90
Após a execução de todos os passos, devemos reiniciar o syslog:
# service syslog restart
3.2.2 SQUID
O servidor Squid Web Proxy Cache é gratuito e funciona em código aberto para Unix e Linux. Ele
permite que os administradores implementem um serviço de proxy caching para Web, acrescentem
controles de acesso (regras), e armazenem até mesmo consultas de DNS.
O Squid originou-se de um programa desenvolvido pelo projeto Harvest chamado cached (Cache
Daemon). A National Science Foundation (NSF) financia o desenvolvimento do Squid através do
National Laboratory of Network Research (NLANR).
O Squid é um Web proxy cache que atende à especificação HTTP 1.1. É utilizado somente por clientes
proxy, tais como navegadores Web que acessem à Internet utilizando HTTP, Gopher e FTP. Além disso,
ele não trabalha com a maioria dos protocolos Internet. Isto significa que ele não pode ser utilizado
com protocolos que suportem aplicativos como vídeo-conferência, newsgroups, RealAudio, ouvideogames como o Quake ou Counter Strike. O principal motivo destas limitações é que o Squid não é
compatível com programas que utilizem UDP. O Squid usa o UDP somente para comunicação inter-
cache.
Qualquer protocolo de cliente suportado pelo Squid deve ser enviado como um pedido de proxy no
formato HTTP. A maioria dos navegadores suporta esta função, portanto, os protocolos FTP, HTTP,
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 18/42
SSL (Secure Socket Layer), WAIS (Wide Area Information Server) são suportados na maioria das redes
que utilizam o Squid.
Os protocolos funcionarão se você os solicitar utilizando o seu navegador e se ele estiver configurado
como um cliente proxy para o servidor Web proxy cache.
O Squid também suporta protocolos internos e de administração. Tais protocolos são usados entre os
caches que puderem existir em outros no mesmo ou em outros servidores de proxy-caching, ou para a
administração de um proxy cache.
• Requisitos de Sistema Específicos para o Proxy Caching
O Squid utiliza mais recursos de sistema do que outros aplicativos. Os dois principais subsistemas de
hardware que o Squid utiliza e deve ter um bom desempenho é o tempo de busca aleatória e aquantidade de memória no sistema.
Tempo de busca aleatória em disco – Para um proxy cache, o tempo de busca aleatória deve ser o mais
baixo possível. O problema é que os sistemas operacionais procuram aumentar a velocidade de acesso
em disco utilizando vários métodos que geralmente reduzem o desempenho do sistema;
Quantidade de memória do sistema – A memória RAM é extremamente importante para a utilização de
um proxy cache. O Squid mantém uma tabela na memória RAM sobre os seus objetos. Se uma parte
dessa tabela tiver que sofrer swapping, o desempenho do Squid será bastante degradado. O Squid é um
processo, então qualquer swapping tornará o programa mais lento. Por exemplo, se você tiver 16 GB
armazenados no cache, precisará de 96 MB (aproximadamente) de RAM para o indíce de objetos.
Outros requisitos do sistema, como velocidade de CPU, não são tão importantes assim. A velocidade do
processador somente será notado durante o início do sistema (durante a criação do indíce de objetos).
Um sistema multiprocessado não constuma fazer diferença no desempenho do proxy cache, pois o
Squid contém uma pequena porção de código encadeado.
• Instalando o Squid
Podemos fazer uso dos repositórios para isto.
Como root, digite os seguintes comandos:
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 19/42
# aptitude update# aptitude upgrade# aptitude install squid
• Configuração do Squid
O arquivo de configuração padrão do squid está em /etc/squid/squid.conf. vamos configurar o
Squid. Este arquivo define as configurações, tais como o número da porta HTTP em que o Squid ouvirá
os pedidos HTTP, pedidos de entrada e saída, informações de timeout e dados de acesso ao firewall. O
arquivo foi criado durante a instalação do Squid.
O arquivo squid.conf é definido com as configurações padrão do Squid e pode ser utilizado após váriasmodificações. É necessário realizar as alterações, pois por padrão, o squid.conf nega o acesso a todos
os navegadores. O Squid será completamente inútil até que você faça as alterações no arquivo.
Cada opção de configuração no squid.conf é identificada como uma tag. Cada tag é uma configuração
do Squid. Por exemplo, a definição de porta de pedido de cliente HTTP é identificada pela tag
http_port . O arquivo squid.conf estará localizado no diretório /usr/local/squid/etc (no meu exemplo), se
você instalar através de um pacote binário o arquivo pode estar no diretório /etc ou /etc/squid. O
arquivo de configuração do squid é auto-documentável, ou seja, todas as tags possuem uma explicaçãosobre a configuração. Veja o exemplo:
# TAG: http_port# Usage: port# hostname:port# 1.2.3.4:port## The socket addresses where Squid will listen for HTTP client# requests. You may specify multiple socket addresses.# There are three forms: port alone, hostname with port, and# IP address with port. If you specify a hostname or IP# address, then Squid binds the socket to that specific# address. This replaces the old 'tcp_incoming_address'# option. Most likely, you do not need to bind to a specific# address, so you can use the port number alone.## The default port number is 3128.## If you are running Squid in accelerator mode, then you# probably want to listen on port 80 also, or instead.## The -a command line option will override the *first* port
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 20/42
# number listed here. That option will NOT override an IP# address, however.## You may specify multiple socket addresses on multiple lines.## If you run Squid on a dual-homed machine with an internal# and an external interface then we recommend you to specify the# internal address:port in http_port. This way Squid will only be# visible on the internal address.## Default:# http_port 3128
Por padrão, todas as linhas do Squid estão desabilitadas. Para habilitar, devemos retirar o caracter # que
aparece antes da tag. Se você não modificar o arquivo de configuração, o Squid rodará com as
configurações padrões.
• Tag HTTP_PORT
Esta tag configura a porta HTTP onde o Squid ouve os clientes proxy. A porta padrão é a 3128. A porta
8080 também costuma ser utilizada. É possível configurar as duas portas para o Squid aceitar as
requisições.
Abra o arquivo squid.conf procure a tag para realizar a configuração.
# internal address:port in http_port. This way Squid will only be# visible on the internal address.##Default:# http_port 3128
Mude para:
http_port 3128 8080
• Tag CACHE_DIR
Esta tag define onde os dados do cache serão armazenados. Você poderá definir outros diretórios,
bastando para tal, incluir novas tags cache_dir.
O padrão é:
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 21/42
# ones with no max-size specification last.##Default:# cache_dir ufs /usr/local/squid/var/cache 100 16 256
Caso não seja necessário mexer nesta configuração, não é necessário habilitar a linha
Valor da Tag Descrição
cache_dir Define os valores do diretório de cacheutilizado pelo Squid.
ufs O Squid assume a utilização de um sistema dearquivos Unix (ufs) para o sistema dearmazenamento do cache.
/usr/local/squid/var/cache O diretório de todos os objetos armazenadosno cache será neste diretório.
100 Quantidade de dados armazenados que oSquid colocará no diretório de cache. Otamanho padrão do cache é de 100 MB.
16 Define o número de subdiretórios a seremcriados no cache. O Squid divide os objetosarmazenados no cache entre essessubdiretórios para agilizar o acesso aos dados.Por exemplo, o Squid encontrará um objetomuito mais rapidamente buscando em
diversos diretórios no cache, em vez de buscarem um único diretório com centenas demilhares de objetos.
256 Define o número de subdiretórios secundáriosa serem criados no cache. Se o seu cache forextremamente grande, você deverá aumentarestes valores. Para a maioria dasimplementações, estes valores de subdiretóriosão suficientes.
• Tag LOG_ACCESS
O diretorio onde se encontram os arquivos gerados estão em: /var/log/squid
O registro de toda atividade como URLS acessadas, e falhas na autenticação estão em:
/var/log/squid/access.log
O registro das informações do cache estão em: /var/log/squid/cache.log
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 22/42
O registro de atividade dos objetos gravados e retirados do cache: /var/log/store.log
Se desejarmos enviar os logs para um servidor remoto é preciso alterar o caminho do access_log dentrodo arquivo de configuração /etc/squid/squid.conf e enviar para o syslog.
access_log syslog:LOG_LOCAL:4 squid
• Tag ACL
Esta tag permite a definição de uma lista de acesso. A lista de acesso pode conter endereços de IP declientes, uma faixa de endereços, o endereço de um servidor de URL, endereço de uma máquina localou domínios. Qualquer lista de acesso que você definir utilizando esta tag poderá ser utilizada maistarde para permitir ou negar pedidos ao servidor de cache.
Para permitir o acesso da rede local inclua:
acl redelocal src 192.168.4.0/24
* onde 192.168.4.0/24 é o IP da rede local.
• Tag HTTP_ACCESS
Esta tag permite ou nega o acesso ao Squid. Você pode permitir ou negar todos os pedidos. Também é
possível permitir ou negar pedidos baseados em uma lista de acesso pré-definida. Se for removido
todas as entradas http_access, todos os pedidos serão permitidos por padrão.
Os clientes proxy não serão capazes de usar o servidor Squid proxy-caching até que você modifique as
tags http_acess. Observe que recomenda-se algum nível de controle de acesso, por isso não remova
todas as tags http_access.
É necessário permitir o acesso da rede local. Inclua a seguinte linha:
http_access allow redelocal
• Carregando e Testando o Squid
Para saber se está funcionando, você deverá iniciar o serviço Squid e depois usar o programa cliente do
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 23/42
Squid no servidor local para verificar se os dados da página Web estão sendo gravados no cache. O
cliente do Squid apresenta dados à medida que são gravados no cache, e é extremamente útil no teste
do funcionamento do cache proxy e na solução de problemas.
Inicie o proxy cache Squid com o seguinte comando:
# /etc/init.d/squid start
Se aparecer alguma mensagem de erro, verifique os arquivos de logs.
Configurado o squid, agora é necessário configurar o syslog-ng para enviar os logs para o servidor.
Para isso edite o arquivo /etc/syslog-ng.conf conforme abaixo:
destination df_user { file(“/var/log/user.log”); };destination df_uucp { file(“/var/log/uucp.log”); };destination df_loghost { udp(“10.8.0.90”); };
log {source(s_all);filter(f_syslog);destination(df_loghost);
};
Reinicie o syslog-ng para efetivar as configurações.
3.2.3 Servidor de VPN
Esta seção trata da instalação e configuração de um servidor de VPN, que será utilizado para o
estabelecimento de uma comunicação segura contra sniffing, arp spoofing e outros tipos de ataques,
entre os servidores que irão fornecer cada serviço descrito na topologia e o loghost. Para a
implementação deste servidor de VPN utilizaremos o OpenVPN1
. A escolha do OpenVPN ocorreu poreste ser software livre, por estar presente nos repositórios oficiais das principais distribuições de Linux
da atualidade e também por possuir uma grande fatia do mercado em servidores de VPN.
O OpenVPN está disponível para instalação em uma grande variedade de sistemas operacionais,
incluindo Linux e Windows. Neste documento trataremos da instalação sob o sistema operacional
1 Site do OpenVPN em http://www.openvpn.net
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 24/42
Linux, mais especificamente nas distribuições Debian ou Ubuntu Server.
Como premissa consideramos que o sistema operacional está completamente instalado, com a rede
configurada e também que o servidor possui acesso à Internet para realizar o acesso aos repositórios de
pacotes.
Antes de iniciar a instalação do OpenVPN nas distribuições Debian ou Ubuntu Server é necessário
sincronizar os metadados com informações sobre quais pacotes e versões estão disponíveis nos
repositórios, para isso executamos o comando aptitude conforme mostrado abaixo:
# aptitude update
Com a listas de pacotes atualizada inciamos o procedimento de instalação do OpenVPN conforme
comando mostrado abaixo:
# aptitude install openvpn
Aguarde enquanto o sistema baixa os pacotes necessários e realiza a instalação de cada um deles. O
tempo necessário para esta atividade pode variar de acordo com a banda de download disponível ou a
carga nos servidores de repositório da distribuição.
• O Servidor
Concluída a instalação é necessário configurar o OpenVPN. Para isso colocamos um arquivo, com
extensão .conf, no diretório /etc/openvpn. Neste documento criaremos um arquivo com o nome
server.conf . Para a construção do referido arquivo utilizaremos como base o arquivo disposto no
diretório de exemplos (examples), existente no diretório de documentação, no caminho
/usr/share/doc/openvpn.
Para a configuração do OpenVPN também será necessária a utilização de uma Autoridade Certificadora
para assinatura dos Certificados Digitais do servidor e também de cada cliente da VPN. Uma
Autoridade Certificadora de exemplo também está disponível no diretório de documentação do
OpenVPN, no subdiretório examples/easy-rsa/2.0 .
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 25/42
Vamos agora criar a nossa Autoridade Certificadora a partir do exemplo citado acima. Para isso copie o
diretório /usr/share/doc/openvpn/examples/easy-rsa/2.0 para o diretório /opt . Em seguida renomeie o
diretório copiado para AC .
# cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0 /opt# cd /opt; mv 2.0 AC
Uma vez copiada a Autoridade Certificadora precisamos definir as configurações como: País, Estado,
Cidade, Organização e E-mail. Estas informações ficarão armazenadas em cada certificado digital
emitido pela Autoridade Certificadora. Para isto devemos editar o arquivo vars encontrado no diretório
/opt/AC definindo os valores das variáveis localizadas no final do arquivo, conforme mostrado abaixo:
export KEY_COUNTRY=”BR”export KEY_PROVINCE=”Pernambuco”export KEY_CITY=”Recife”export KEY_ORG=”Sua Organizacao”export KEY_EMAIL=”[email protected]”
É necessário também inicializar a Autoridade Certificadora, para isso execute os comandos abaixo:
# cd /opt/AC
# source vars# ./clean-all# ./build-ca
Confirme as informações solicitadas durante a execução do comando ./build-ca. Como as variáveis já
foram configurados editando-se o arquivos vars, os valores padrão já refletirão ao seu ambiente, sendo
necessário somente informar o campo Name com o valor “ Autoridade Certificadora VPN ”.
Também será necessário gerar a chave Diffie-Hellman, que será utilizada para realizar a troca segura de
chaves de criptografia em um canal não confiável, e gerar o certificado digital do servidor de VPN.
Durante a criação do certificado digital do servidor, confirme todas os valores pressionando < Enter> e
ao final confirme a assinatura do certificado digital pela Autoridade Certificadora criada anteriormente.
# ./build-dh# ./build-key-server vpn.seudominio.com.br
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 26/42
Após a execução dos passos até este ponto, teremos no diretório keys os certificados digitais e chaves
privadas da Autoridade Certificadora e também do servidor de VPN. Com estes certificados criados,
precisamos agora configurar o OpenVPN. Para isso vamos iniciar o procedimento descrito nas linhas
que seguem. Tenha um cuidado especial com as chaves privadas, pois elas deverão ser mantidas em
total sigilo, mantendo sempre o usuário root como proprietário e as permissões de leitura apenas para ousuário proprietário.
Vamos agora copiar o arquivo de configuração de exemplo encontrado no diretório de documentação
do OpenVPN para o diretório /etc/openvpn. Como o arquivo de configuração copiado está compactado,
será necessário decompactá-lo com o aplicativo gunzip.
# cd /etc/openvpn
# cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz .# gunzip server.conf.gz
Conforme configurado no arquivo server.conf, o certificado digital da autoridade certificadora deverá
estar localizado no diretório /etc/openvpn. O certificado digital do servidor e a chave privada
correspondente, criado anteriormente, estão armazenados nos arquivos vpn.seudominio.com.br.crt e
vpn.seudominio.com.br.key também deverão ser copiados para o diretório /etc/openvpn.
# cd /etc/openvpn# cp /opt/AC/keys/ca.crt .# cp /opt/AC/keys/vpn.seudominio.com.br.{crt,key} .# cp /opt/AC/keys/dh1024.pem .
Com o arquivo de configuração do servidor no devido diretório, será necessário ajustar as
configurações para refletir as configurações desejadas. Então, utilizando o seu editor preferido, edite o
arquivo server.conf localizado no diretório /etc/openvpn e faça as alterações conforme mostrado abaixo:
cert vpn.seudominio.com.br.crtkey vpn.seudominio.com.br.keyclient-config-dir ccdclient-to-client
O servidor de VPN, no nosso caso, deverá fornecer sempre os mesmos endereços para os clientes,
possibilitando a aplicação de regras de firewall de forma individual e também permitir o roteamento
entre clientes. Para isso faz-se necessário descomentar a linha client-config-dir e client-to-client ,
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 27/42
localizadas no arquivo server.conf. Realizado o procedimento, será necessário criar o diretório ccd,
dentro do diretório /etc/openvpn. Para criar o diretório ccd execute o comando abaixo:
# mkdir /etc/openvpn/ccd
A fixação do endereço IP de cada host é realizada criando-se um arquivo com o nome igual ao
Common Name (CN) do seu certificado digital no diretório ccd do servidor. Outras configurações
também podem de forma seletiva serem enviados aos clientes da VPN utilizando-se o mesmo arquivo.
Maiores detalhes sobre a utilização destes arquivos serão vistos na seção sobre os clientes da VPN.
Para evitar ataques do tipo DoS2 e UDP 3 port flooding será necessário descomentar a linha tls-auth
ta.key 0 no arquivo server.conf e também criar esta chave executando o comando abaixo:
# openvpn --genkey --secret ta.key
Da mesma forma que foi mencionado para guardar as chaves privadas da autoridade certificadora e do
servidor de VPN, guarde esta chave com permissões de leitura mais restritas.
Para ilustrar como deverá estar o diretório /etc/openvpn foi incluída uma listagem de diretório.
# ls -l /etc/openvpntotal 40-rw-r--r-- 1 root root 1476 2010-09-06 17:58 ca.crtdrwxr-xr-x 1 root root 4096 2010-09-06 17:58 ccd-rw-r--r-- 1 root root 245 2010-09-06 18:04 dh1024.pem -rw-r--r-- 1 root root 10318 2010-09-06 18:35 server.conf-rw------- 1 root root 636 2010-09-06 18:24 ta.key-rwxr-xr-x 1 root root 1352 2010-09-06 10:45 update-resolv-conf-rw-r--r-- 1 root root 4231 2010-09-06 17:58 vpn.seudominio.com.br.crt-rw------- 1 root root 887 2010-09-06 17:58 vpn.seudominio.com.br.key
Observe com atenção as permissões dos arquivos ta.key e vpn.seudominio.com.br.key. Eles possuem
acesso de leitura somente para o usuário proprietário. O comprometimento dos arquivos de chaves do
servidor ou de algum cliente da VPN poderá comprometer serviços disponibilizados através da VPN ou
toda a VPN.
Após a execução de todos os passos descritos acima o servidor de VPN está configurado e pronto para
2 DoS na Wikipedia em http://en.wikipedia.org/wiki/Denial-of-service_attack3 UDP flood attack na Wikipedia em http://en.wikipedia.org/wiki/UDP_flood_attack
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 28/42
entrar em operação. Para iniciá-lo execute o comando abaixo:
# /etc/init.d/openvpn start
Se todas as configurações foram realizadas com sucesso deverá ser exibida a mensagem:
* Starting virtual private network daemon(s)...* Autostarting VPN 'server' [ OK ]
Após o início do serviço é possível verificar se o serviço está “ouvindo” a porta 1194 através do
comando netstat conforme mostrado abaixo:
# netstat -upan
Também é possível observar uma nova interface de rede no servidor com o nome tun0. Para isto, utilize
o comando ifconfig.
# ifconfig
Uma vez configurado o servidor será necessário configurar agora os clientes da VPN. Para isto leia a
seção abaixo.
• Os Clientes
A instalação do OpenVPN nos clientes Linux segue o mesmo procedimento da instalação do servidor,
mudando-se apenas o procedimento de configuração. Havendo a necessidade da instalação do cliente
de VPN em algum servidor Windows, acesse o site do OpenVPN e baixe o instalador disponibilizado
na seção Community Software/Downloads do site4. A configuração no ambiente Windows é igual ao
procedimento de configuração no ambiente Linux, mudando-se apenas o caminho do arquivo de
configuração, que neste sistema está localizado no diretório C:\Program Files\OpenVPN\config.
Durante o procedimento de configuração será necessário criar os certificados digitais de cada cliente,
4 http://www.openvpn.net
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 29/42
este procedimento deverá ser realizado no servidor, utilizando a Autoridade Certificadora criada
durante a configuração do servidor.
Iniciando agora a configuração devemos, da mesma forma que foi feito para o servidor, copiar o
arquivo de configuração de exemplo localizado no diretório /usr/share/doc/openvpn/examples para o
diretório /etc/openvpn.
# cd /etc/openvpn# cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf .
Copiado o arquivo, precisamos ajustar as configurações para refletir ao nosso ambiente. Para
configurar o cliente, edite o arquivo client.conf copiado no passo anterior utilizando o editor de textos
de sua preferência. A primeira diretiva a ser configurada é a remote, que define o endereço IP ou
hostname do servidor de VPN. Para o nosso ambiente considere que o endereço IP do servidor de VPN
é 192.168.1.2.
remote 192.168.10.2 1194
Nas próximas linhas do arquivo de configuração são definidos os arquivos onde estão armazenados os
certificados digitais da Autoridade Certificadora e do cliente, bem como a chave privada do cliente e a
chave TLS. A linha referente à chave TLS é necessário apenas descomentar a linha já existente noarquivo.
ca ca.crtcert client1.crtkey client1.keytls-auth ta.key 1
Estes arquivos deverão estar localizados no diretório /etc/openvpn dos servidores Linux ou no diretório
C:\Program Files\OpenVPN\config em servidores Windows. O arquivo ca.crt é o mesmo localizado no
diretório /etc/openvpn do servidor, mas os arquivos client1.crt e client1.key ainda não existem e devem
ser criados no servidor.
Para criar o certificado digital e a chave privada correspondente para o cliente devemos acessar o
diretório /opt/AC no servidor e executar o seguinte procedimento:
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 30/42
# cd /opt/AC# source vars# ./build-key client1
Confirme todas as perguntas realizadas pelo script de criação do certificado (build-key). Após a
conclusão deste procedimento os arquivos estarão localizados no diretório /opt/AC/keys. Para facilitar o
transporte dos arquivos, sugiro que seja criado um pacote .zip contendo todos os arquivos que serão
copiados do servidor para o cliente. Então para isso execute a sequência de comandos abaixo:
# cp /etc/openvpn/ta.key /opt/AC/keys# cd /opt/AC/keys# zip client1.zip ca.crt client1.crt client1.key dh1024.pem ta.key
Certifique-se de que o utilitário zip esteja instalado. Caso não esteja, faça a instalação utilizando o
comando aptitude, da mesma forma que foi utilizado para instalar o pacote openvpn.
Copie o arquivo client1.zip do servidor para o cliente utilizando a forma que desejar.
Com o arquivo client1.zip no cliente, faça a descompactação deste no diretório /etc/openvpn, ou
C:\Program Files\OpenVPN\config caso seja Windows.
Para ilustrar como deverá estar o diretório /etc/openvpn do cliente foi incluída uma listagem de
diretório.
# ls -l /etc/openvpntotal 28-rw-r--r-- 1 root root 1476 2010-09-06 17:58 ca.crt-rw-r--r-- 1 root root 4079 2010-09-07 10:35 client1.crt-rw------- 1 root root 887 2010-09-07 10:35 client1.key-rw-r--r-- 1 root root 3427 2010-09-07 10:35 client.conf-rw-r--r-- 1 root root 245 2010-09-06 18:04 dh1024.pem -rw------- 1 root root 636 2010-09-06 18:24 ta.key-rwxr-xr-x 1 root root 1352 2010-09-06 10:45 update-resolv-conf
Observe com atenção as permissões dos arquivos ta.key e client1.key. Eles possuem acesso de leitura
somente para o usuário proprietário.
Terminada a execução dos passos citados acima precisamos iniciar o serviço openvpn para que as
configurações sejam carregadas. Assim, execute o comando abaixo:
# /etc/init.d/openvpn start
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 31/42
Se todas as configurações foram realizadas com sucesso deverá ser exibida a mensagem:
* Starting virtual private network daemon(s)...* Autostarting VPN 'client' [ OK ]
Após o início do serviço deverá ser possível executar um ping para o endereço IP do servidor de VPN,
que no nosso ambiente é 10.8.0.1.
Iremos criar configurações específicas para um determinado cliente, assim será possível definir o
endereço IP de cada cliente da VPN de forma manual, possibilitando a configuração de regras de
firewall mais seletivas. Para definir um endereço IP fixo para um dado cliente, crie um arquivo no
diretório /etc/openvpn/ccd com o nome igual ao campo CN do certificado digital do cliente e insira a
configuração de endereço IP do cliente, conforme exemplificado abaixo:
Nome do arquivo: client1Conteúdo do arquivo:ifconfig-push 10.8.0.90 10.8.0.89
A escolha de endereços não deve ser aleatória. Para a configuração padrão do OpenVPN são criadas
diversas redes com máscara 255.255.255.252, e devemos escolher para o cliente o primeiro endereço
válido de cada rede e para o IP remoto o endereço IP seguinte.
Com a configuração mostrada acima o cliente, cujo certificado digital possui o campo CN com o valor
client1 receberá sempre o endereço 10.8.0.90.
Concluídos os passos até este ponto, concluímos a configuração do cliente de VPN.
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 32/42
3.3 Serviços de Produção
3.3.1 Aplicação WEB vulnerável
Esta seção detalha uma aplicação Web Java suscetível a SQL Injection, e como essa vulnerabilidade
poderá ser corrigida através do uso de um Web Application Firewall como o Mod-Security5
A aplicação Web Java utiliza o servidor de aplicações Apache Tomcat6, e Banco de Dados
PostgreSQL7. Trata-se de um Sistema de Controle de Alunos utilizado em uma Universidade fictícia, e
o seu formulário de login está afetado por vulnerabilidade a ataques do tipo SQL Injection.
Ataques de SQL Injection consistem em aproveitar falhas em aplicações que interagem com Bancos deDados Relacionais através da entrada de valores inválidos em campos de formulários. Um atacante
pode utilizar-se de instruções SQL maliciosas passadas em campos cujo conteúdo não é filtrado pela
aplicação antes de concatená-lo com a operação a ser efetuada.
Abaixo segue a página de login do Sistema de Controle de Alunos.
Também abaixo está o código Java utilizado para a operação de login, destacando o trecho de código
mal-utilizado, que causou a vulnerabilidade em questão:
5 Site do Mod-Security em http://www.modsecurity.org/6 Site do Apache Tomcat em http://tomcat.apache.org/7 Site do PostgreSQL em http://www.postgresql.org/
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 33/42
PreparedStatement pstmt = conn.prepareStatement("SELECT count(*) FROM usuario WHERE login = '"
+ login + "' AND senha = '" + senha + "'");
As variáveis login e senha são concatenadas à String da consulta SQL sem passar por nenhum tipo de
filtragem de conteúdo. Os valores que vem na requisição HTTP são integralmente utilizados. Umusuário mal-intencionado pode anexar comandos maliciosos, que podem, dependendo das permissões
do usuário da conexão JDBC, executar até mesmo comandos DDL, como apagar tabelas inteiras.
Em muitos cenários do mundo real, por diversos motivos, pode não ser possível efetuar a correção
desta vulnerabilidade através de alteração de código. O código-fonte pode não ser de propriedade da
empresa, ou mesmo que seja, pode não ser possível aguardar esta correção pela equipe de
desenvolvimento.
Neste cenário, pode-se utilizar um Web Application Firewall, que efetuaria a filtragem dos parâmetros
HTTP, aplicando padrôes e expressões regulares para detectar tentativas de ataques de SQL Injection.
O Mod-Security é um Web Application Firewall Open-Source distribuído pela empresa Breach
Security8, que funciona em modo Embedded (em conjunto com o servidor Web/servidor de aplicações),
ou em modo Standalone (como um proxy reverso). Neste último modo, caso a empresa já possua um
proxy reverso (como é o cenário proposto neste trabalho), o uso do Mod-Security não irá requerer
nenhuma mudança na topologia da rede.
Um engine de regras padrão, mas configurável e extensível ( Mod-Security Core Rules Set ), e uma
linguagem específica para escrita dessas regras ( Mod-Security Rules Language) formam a base de
funcionamento do Mod-Security, que atua em diversas fases de processamento durante a filtragem de
tráfego HTTP/HTTPS, como está descrito na figura a seguir:
8 http://www.breach.com/
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 34/42
3.3.2 Configurando Log4J para enviar logs para o Syslog
O Sistema de Controle de Alunos usa um framework de logging bastante difundido no mundo Java,
Log4J9. Para auxiliar no processo de centralização e padroninzação dos logs corporativos, é adequado o
uso do padrão de logs da IETF chamado Syslog.
O Log4J já disponibiliza um Appender(terminologia dada às diversas formas de escrever logs, como
Console, Arquivos, etc) que envia os logs diretamente a um servidor de Syslog. Segue abaixo um
trecho do arquivo log4j.properties, que explicita a configuração do envio para Syslog:
log4j.rootLogger=WARN, file, SYSLOG
log4j.appender.file=org.apache.log4j.RollingFileAppenderlog4j.appender.file.append=true
log4j.appender.file.File=/var/logs/apache/tomcat.loglog4j.appender.file.MaxFileSize=5MBlog4j.appender.file.maxBackupIndex=10log4j.appender.file.layout=org.apache.log4j.PatternLayoutlog4j.appender.file.layout.ConversionPattern=%d{DATE} - [%t] - %C{1}.%M(%L) - %p:
%m%n
log4j.appender.SYSLOG=org.apache.log4j.net.SyslogAppenderlog4j.appender.SYSLOG.SyslogHost=10.8.0.90
9 Site do Log4J em http://logging.apache.org/log4j/
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 35/42
log4j.appender.SYSLOG.Facility=LOCAL0log4j.appender.SYSLOG.layout=org.apache.log4j.PatternLayoutlog4j.appender.SYSLOG.layout.ConversionPattern=%-4r %-5p %c{2} %M.%L %x - %m\nlog4j.appender.SYSLOG.threshold=DEBUG
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 36/42
3.4 Log Host
Esta seção trata da instalação e configuração de um servidor de Logs, que será utilizado para o o
recebimento e armazenamento de logs de todos os servidores da rede. Para a implementação desteservidor utilizaremos o Syslog-ng10, que está presente na maior parte das maiores distribuições de Linux
da atualidade.
Como premissa consideramos que o sistema operacional está completamente instalado, com a rede
configurada, que o firewall está bloqueando todas as conexões de entrada e também que o servidor
possui acesso à Internet para realizar o acesso aos repositórios de pacotes.
Antes de iniciar a instalação do Syslog-ng nas distribuições Debian ou Ubuntu Server é necessário
sincronizar os metadados com informações sobre quais pacotes e versões estão disponíveis nosrepositórios, para isso executamos o comando aptitude conforme mostrado abaixo:
# aptitude update
Com a listas de pacotes atualizada inciamos o procedimento de instalação do Syslog-ng conforme
comando mostrado abaixo:
# aptitude install syslog-ng
Aguarde enquanto o sistema baixa os pacotes necessários e realiza a instalação de cada um deles. O
tempo necessário para esta atividade pode variar de acordo com a banda de download disponível ou a
carga nos servidores de repositório da distribuição.
Por padrão o servidor Syslog-ng não aceita logs de outras máquinas. Para ativar esta funcionalidade é
necessário ativá-la no arquivo de configuração /etc/syslog-ng/syslog-ng.conf . Editando-se o arquivo
referido com o editor de textos de sua preferência, descomente a linha udp(); localizada na seção
source s_all. Note que no syslogd esta função era ativada especificando a opção -R durante a chamada
o serviço.
Após a execução deste passo é necessário reiniciar o serviço. Para isto, execute o comando abaixo:
10 Site do Syslog-ng em http://www.balabit.com/network-security/syslog-ng/
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 37/42
# /etc/init.d/syslog-ng restart
Após o reinício do serviço você poderá verificar se são aceitos logs advindos de servidores remotos
utilizando o comando netstat e confirmando se a porta UDP 514 está ativa.
# netstat -unaProto Recv-Q Send-Q Local Address Foreign Address Stateudp 0 0 0.0.0.0:514 0.0.0.0:*
É necessário ajustar as regras de firewall do loghost para permitir somente pacotes destinados ao
loghost sejam permitidos somente aqueles que chegarem através da VPN.
# iptables -A INPUT -i tun0 -p udp -i tun0 --dport 514 -j ACCEPT
3.5 Log Clients
Com o servidor de logs configurado precisamos configurar os clientes para enviarem seus logs para o
servidor. Para configurar o cliente também é necessário que seja instalado o Syslog-ng em cada cliente.
Para instalá-lo em um cliente Debian ou Ubuntu Server utilize o mesmo procedimento utilizado parainstalar o servidor.
A configuração do cliente é realizada através da edição do arquivo /etc/syslog-ng/syslog-ng.conf
utilizando o editor de textos de sua preferência.
No cliente o nosso objetivo de configurar o arquivo syslog-ng.conf é configurá-lo para que as
mensagens de log sejam enviadas para o nosso loghost configurado no servidor de endereço IP
10.8.0.90.
Antes de iniciar a configuração vamos construir uma visão superficial sobre a configuração do arquivo
syslog-ng.conf para permitir o entendimento das configurações que serão mostradas nas linhas
seguintes.
O arquivo possui cinco diretivas, que através de sua utilização iremos definir toda a configuração do
Syslog-ng. Começamos com a diretiva [1] options, que faz definições gerais do serviço. Em seguida
temos a diretiva [2] sources, que define possíveis origens dos logs. Depois temos a diretiva [3]
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 38/42
destination, que define para onde os logs serão enviados, como arquivos em disco ou servidores
remotos. A diretiva [4] filters, que define filtros para melhor classificar os logs por fim a diretiva [5]
log, que faz o relacionamento entre as diretivas anteriores, indicando de acordo com a origem e filtro
aplicado, onde mas mensagens de log serão armazenadas.
Para configurarmos o nosso cliente para enviar os logs para o loghost 10.8.0.90 precisamosprimeiramente definir um destino, através da diretiva destination, conforme exemplo mostrado abaixo:
destination df_user { file(“/var/log/user.log”); };destination df_uucp { file(“/var/log/uucp.log”); };destination df_loghost { udp(“10.8.0.90”); };
Definido o destino para onde as mensagens podem ser enviadas, precisamos configurar a diretiva log
para utilizá-lo. Para isso, mais uma vez editamos o arquivo syslog-ng.conf e na diretiva log devemos
alterar opção destination informando o destino desejado. No exemplo abaixo estamos encaminhando
para o nosso loghost todas as mensagens que antes eram enviadas para o arquivo /var/log/messages
através da opção destination(df_loghost); .
log {source(s_all);filter(f_messages);#destination(df_messages);destination(df_loghost);
};
3.6 Rotacionamento de Logs
O rotacionamento de logs é necessário para evitar o esgotamento do espaço em disco através da
geração excessiva de logs. Através do logrotate11 podemos definir a frequência na qual os logs serão
rotacionados, quantos arquivos já rotacionados deverão ser preservados no servidor, se será utilizada
compressão destes arquivos, procedimentos executado antes ou depois do rotacionamento e algumas
outras opções.
No nosso laboratório iremos configurar o rotacionamento dos logs para ser executado semanalmente e
guardá-los por 52 semanas, ou seja, um ano. Também utilizaremos compressão para uma melhor
utilização do espaço em disco, uma vez que é esperada uma grande quantidade de logs recebidos de
todos os serviços em execução em toda a rede.
O logrotate é configurado através de arquivos localizados no diretório /etc/logrotate.d. Em cada
11 Site do logrotate em https://fedorahosted.org/logrotate/
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 39/42
arquivo são definidas regras de rotacionamento de cada serviço ou grupo de serviços. O Syslog-ng das
distribuições Debian e Ubuntu já possuem uma configuração básica do rotacionamento de logs, que
podem ser utilizadas como base para criação de suas próprias políticas de rotacionamento de logs.
/var/log/auth.log {rotate 4missingoknotifempty
weeklycompress
}
No exemplo mostrado acima rotate 4 indica que serão rotacionadas 4 versões do arquivo auth.log. A
opção missingok que não haverá erro na execução do rotacionamento se o referido arquivo não for
econtrado. A opção notifempty indica que o arquivo não será rotacionado caso esteja vazio. A opção
weekly indica que o rotacionamentos será semanal e compress que será utilizada compressão do
arquivo com o aplicativo gzip.
Para ajustarmos para manter os arquivos rotacionados por um ano precisamos apenas fazer a alteração
na opção rotate indicando o valor 52, conforme apresentado no exemplo abaixo:
/var/log/auth.log {rotate 52missingoknotifempty
weeklycompress
}
Após os ajustes necessário não é necessário reiniciar qualquer serviço para que as configurações entre
em vigor, bastando para isso que o arquivo de configuração esteja salvo.
Você poderá testar o rotacionamento dos logs manualmente, através da execução do comando logrotate
conforme mostrado abaixo:
# logrotate -f /etc/logrotate.d/syslog-ng
Executado o comando acima, os arquivos especificados no arquivo de configuração
/etc/logrotate.d/syslog-ng deverão possuir novas versões com a presença do um número e a extensão
.gz. Este número indica a posição do log dentro do intervalo de rotacionamento. O primeiro log do
histórico possui o maior número e será excluído após ultrapassar a posição 52 e o último log
rotacionado possui o número 1.
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 40/42
4 TERMINOLOGIA
Termo Descrição
Syslog-ng Serviço de gerenciamento de logs presente na maioria das distribuições deLinux
Tomcat Servidor de aplicações web java
Log4j Biblioteca para Logging para aplicações escritas em Java
JDBC Java Data Base Connectivity
API Application Programing Interface
VPN Virtual Private Network - Rede Virtual Privada
ACL Access Control List – Lista de Controle de Acesso
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 41/42
5 CONCLUSÕES
A centralização de logs em um grande parque computacional é essencial para conhecer o
comportamento de aplicações e serviços. Através dela é possível a utilização de ferramentas deauditoria que montem relatórios consolidados que podem ser utilizados para tomada de decisões e
também para fazer correlacionamento de ocorrências de falhas ou tentativas de invasão.
Melhorias no assunto aqui abordado seria a implementação de mecanismos de análise de logs continuo
que pudessem gerar alertas em consoles para que problemas de mau funcionamento ou incidentes de
segurança da informação fossem rapidamente identificados e permitissem ações proativas ou reativas.
5/12/2018 Centralização de Logs - slidepdf.com
http://slidepdf.com/reader/full/centralizacao-de-logs 42/42
6 REFERÊNCIAS
• Servidor Web Apache: http://httpd.apache.org
• Squid: http://www.squid-cache.org
• Tomcat: http://tomcat.apache.org
• Iptables: http://www.netfilter.org
• Postgresql: http://www.postgresql.org
• Syslog-ng: http://www.balabit.com/network-security/syslog-ng/
•
OpenVPN: http://www.openvpn.net