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



Í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



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.



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.



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:



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



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


#------------------------------------------------------------#CONFIGURA ÇÃ O DA REDE DE PRODUÇÃ O#------------------------------------------------------------auto eth3iface eth3 inet static


#------------------------------------------------------------#CONFIGURA ÇÃ O DA REDE CORPORATIVA #------------------------------------------------------------auto eth4iface eth4 inet static




#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



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:



• 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#---------------------------------------



#--------------------------------------#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



#-----------------------------------------------------#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.



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.



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>

http://www.posdeseguranca.com.br/


http://www.alunos.posdeseguranca.com.br/


http://www.posdeseguranca.com/alunos

http://www.alunos.posdeseguranca.com.br/


http://www.posdeseguranca.com/alunos




#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 ]

http://www.posdeseguranca.com/







• 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:



# 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,



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:



# 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



# 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 é:



# 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



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



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



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 .



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



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 ,



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



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



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:



# 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



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.



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/



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/



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/



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



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/



# /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]



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/



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.



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 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.



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

centralização de logs

Documents