Embed Size (px)
Citation preview
Pontifícia Universidade Católica do Paraná – PUCPR
Curso de Especialização - Redes e Segurança de Sistemas
Proposta de otimização para o ambiente de rede da empresa “x”
Marcos Roberto Wessler :
Coleta de dados
Virtualização
Fiirewall + VPN
Monitoramento
Políticas
Joinville, novembro de 2009
Proposta de otimização para o ambiente de rede da empresa “x”
Curso de especialização Redes e Segurança de Sistemas
Pontifícia Universidade Católica do Paraná
Curitiba, novembro de 2009
Resumo
Este trabalho tem como objetivo propor uma melhoria na infra-estrutura da empresa
“x”, procurando maximizar o uso dos valores investidos com o auxílio de ferramentas livres
e ou não pagas, visando assim escalabilidade a um baixo custo, pois, a empresa em questão
vinha-se mostrando insatisfeita com o desempenho de sua rede. Para isto, inicialmente, foi
efetuada uma coleta de dados a fim de identificar a atual topologia da rede e verificar se a
mesma estava ou não em conformidade com os padrões e normas para redes cabeadas e na
seqüência uma análise de desempenho do tráfego de dados. Constatou-se então que a rede
estava fora das especificações recomendadas, sendo assim, iniciou-se o processo de
adequação da estrutura física aos padrões recomendados. Realizada esta etapa, foi dado
início á análise do tráfego de dados e dos links onde também foram constatados e
identificados alguns problemas. Com base neste cenário procurou-se traçar um projeto que
apontasse soluções e ferramentas adequadas de modo a satisfazer e atender as necessidades
da empresa com relação aos custos.
1 Descrição do Contexto.
Num primeiro contato com a empresa notou-se certa insatisfação com o
produto recém adquirido (ERP), o qual prometia total compatibilidade com outras ferramentas
do mercado além de poder ser utilizado em grandes redes.
Para acesso, o sistema utiliza o protocolo HTTP e suas páginas foram desenvolvidas
em ASP. Todas as informações são armazenadas em um banco de dados SQL Server, portanto
todas as tecnologias são proprietárias.
A empresa está situada no estado de Santa Catarina e atualmente está com 25 lojas
além de seu DC (Depósito Central) e EC (Escritório Central). Todos esses locais acessam o
mesmo sistema para emitir relatórios, executar novas funções, entre outras atividades; ou seja,
todos serviços estão sendo direcionados para um único banco de dados resultando em uma
alta taxa de IO’s nos servidores centrais. Visando amenizar este problema, a empresa que
vendeu o sistema de ERP desenvolveu uma solução OFF-LINE na qual cada loja teria um
servidor com cópia parcial do sistema ON-LINE, reduzindo os IO’s dos servidores centrais.
Estes estão localizados no estado do Paraná dentro do Cyber-Datacenter da empresa de
telecomunicações Oi.
Para o acesso ao sistema cada loja possui dois link’s, que também foram vendidos
como forma de redundância, sendo eles Interlan e uma Adsl com IP fixo. A Interlan possui
uma velocidade contratada de 128 kbits sendo 64 kbits garantidos e a Adsl 400 kbits de
download e 200 de upload com 10% de garantia.
O suporte as lojas é realizado a partir do Escritório Central onde se localiza a área de
TI. O atendimento aos usuários do sistema é feito via e-mail ou telefone visando auxiliar as
lojas na resolução dos problemas listados abaixo:
Velocidade extremamente baixa;
Inviabilidade no envio de e-mail;
Suporte remoto inexistente;
Retrabalho nas lojas, pois todos têm acesso aos dispositivos de TI;
Alta taxa de re-sincronização dos servidores OFF-LINE;
Reatividade nos serviços de TI (Não há monitoramento dos serviços prestados).
Diante este cenário, propõe-se uma reestruturação de toda a parte de infra-estrutura,
procurando resolver e ou amenizar todos os problemas apresentados no ambiente da rede,
tornando-o estável e apto a ser monitorado com a ajuda de ferramentas livres, acompanhando
as regras definidas pela empresa de minimizar gastos.
2 Descrição do projeto.
Não Sim
Fluxograma de descrição do projeto
Início
Coleta
de
dados
Análise de dados
Implementar
Soluções
Controle Fim
2.1 Coleta
A coleta de informações sobre a estrutura da rede foi realizada em duas etapas,
estrutura física e lógica. Na primeira etapa realizou-se uma vistoria na parte física da rede,
onde constatram-se várias inconformidades de acordo com os padrões e normas para redes
cabeadas; na segunda etapa ou etapa lógica constatou-se um elevado tráfego de dados.
2.2 Análise
2.2.1 Estrutura física
Tendo em vista a instabilidade apresentada no ambiente e após uma vistoria no local,
constatou-se que o ambiente não estaria em conformidade nos seguintes aspectos:
Cabos de baixa qualidade;
Acesso físico total aos servidores;
Roteadores dispersos.
Figura1: Cabo sem capa já destrançado
Figura 2: Rack desorganizado e desestruturado
Figura 3: Acesso irrestrito a servidores e roteadores
Figura 5: Acesso irrestrito a servidor e switch
Figura 6 e 7: Local inadequado para servidores
Figura 8: Utilização de Hub’s
2.2.2 Estrutura lógica
Com relação ao alto consumo de banda apresentado, constatou-se uma alta repetição
da sincronização do servidor OFF-LINE para o ON-LINE devido a tráfegos de softwares ou
aplicativos de terceiros ou mesmo até problemas com o link, “quedas e ou interrupções”.
Figura 9: Relatório de sincronização
Figura 10: Tráfego de aplicativos maliciosos
2.3 Desenvolvimento
2.3.1 Links
Devido à ocorrência de muitos problemas na sincronização gerados por quedas e ou
tráfego de aplicativos maliciosos constatados pela a análise concluiu-se que o aumento da
velocidade do link se mostraria ineficiente, pois além do cabo utilizado ser incompatível, sua
instalação estaria fora das normas interligando equipamentos em até 120 metros de distância
acarretando em reenvios freqüentes de pacotes e com isso o desperdício de banda e recursos
físicos de firewalls e roteadores.
Durante este projeto a empresa iniciou uma adequação de sua infra-estrutura partindo
do escritório para as lojas. No escritório todos os cabos e pontos foram trocados e
padronizados em Cat5e e Cat6 na sala dos servidores.
Figura 11: Racks padronizados (EC)
Nas lojas além dos problemas na estrutura física, havia problemas com a lógica, pois
existiam muitas máquinas com instalações antigas e infectadas por vírus devido ao livre
acesso de dispositivos móveis. Para solucionar este problema, resolveu-se projetar instalações
personalizadas, tópico que será abordado no item 2.3.5.1 de políticas.
Fazendo referência aos links, como medida de precaução contra falhas, na aquisição
do sistema foram adquiridos dois links por loja. Atualmente desnecessários devido à
utilização de servidores OFF-LINE por loja, além do que o SLA contratado para cada link
interlan era de 12 horas, incompatível com o mercado varejista.
Suas velocidades eram:
Interlan: 128Kbits com garantia de 64Kbits
Adsl + Ip-Fixo: 400 Kbits Download + 200 kbits Upload.
A topologia física de uma rede interlan é do tipo estrela, deve-se então
obrigatoriamente ter um ponto central de comunicação e esse ponto está localizado no Cyber-
Datacenter da Oi em Curitiba.
Seu roteador principal é um Cisco 1700 com três interfaces seriais:
1. 2 Mbits => Escritorio Central
2. 2 Mbits => Lojas
3. 128 Kbits => TEF (Transações de cartões)
Constatou-se nesse momento o primeiro problema da rede, a limitação do
crescimento dos links interlan. Isso ocorreu devido a limitação de velocidade de cada porta
serial estar limitada a 2 Mbits, sendo assim:
19 lojas com links de 128 Kbits
19 * 128 = 2432 Kbits
De posse dos dados pode-se constatar que o tráfego na sincronização estaria elevado,
indicando assim que a rede havia atingido seu limite. Tendo como consequencia o
desbalanceamento do tráfego servidor-lojas, causando atrasos no processo de sincronização
como um todo.
Figura 12: Atraso na sincronização
Para solucionar o problema duas soluções foram apresentadas, a primeira seria a troca
da interface do roteador por uma mais rápida ou de maior capacidade de banda e a segunda
seria a troca da tecnologia empregada, pois a interlan tornou-se um tipo de rede de pacotes
obsoleta.
Para manter o link de interlan ativo para as lojas, são necessários:
Aluguel do roteador central;
Link de 2 Mb;
Link de cada Loja;
Aluguel de roteador de cada Loja.
Como o valor para cada tipo de link estaria variando de acordo com a sua localização
de instalação, a fim de comparar valores, efetuou-se uma média.
Link interlan lojas c/ Roteador : R$ 355,09
Link 2 Mbits Interlan: R$ 3150,00
Aluguel roteador central: R$ 496,00
Link ADSL lojas c/ Roteador : R$ 179,03
Link dedicado 512 Kbits c/ Roteador: R$ 479,00
Cada loja estaria gastando então o equivalente a:
3150 / 19 = 165,8
496 / 20* = 24,8
Loja
Parte link 2Mb 165,8
Parte Aluguel Roteador 24,8
Link Interlan Loja + Rot. 355,09
Link ADSL Loja + Rot. 179,03
Total 724,72
Após esses cálculos, decidiu-se trocar de tecnologia buscando um melhor custo
benefício. O tipo de circuito escolhido foi o Link dedicado de 512 Kbits Full (Down e Up de
512 Kbits), com um SLA de 8 horas.
Gastos com interlan: R$ 724,72
Gastos com Link dedicado: R$ 479,00
Resultando em uma padronização para as novas lojas e um inicio na reestruturação das
atuais, adotando alguns itens na infra-estrutura:
Cabeamento Furukawa Cat5e;
Rack;
Switch 3 Com;
No-break;
Sala ref1rigerada.
* 20: 19 lojas + escritorio central
Figura 13: No-break
Figura 14: Cabeamento estruturado
Figura 15: Rack
2.3.2 Virtualização
Em cada loja havia dois servidores (1) HP ML 110 e (1) Máquina montada que era
utilizada como firewall para o ambiente.
Devido ao livre acesso a estrutura da rede, identificou-se nas lojas uma prática que
aparentemente havia se tornado rotina, cada vez que o sistema apresentava uma queda,
qualquer funcionário da loja reinicializava o firewall pois segundo eles era a única forma do
sistema ser restabelecido.
O fato se tornou verídico quando fora realizada uma inspeção interna da máquina,
onde foi encontrada muita sujeira devido ao fato de estar localizada em um ambiente
incompatível, muitas vezes no próprio piso do estabelecimento, e devido a diversas
reinicializações o disco rígido do “servidor” apresentava constantemente erros de leitura e
gravação.
Com relação ao servidor este se apresentou estável em todos os testes físicos
realizados. O sistema operacional utilizado é o Windows Server 2003 com a aplicação ASP
sendo fornecida pelo IIS 6.0, os discos físicos estão configurados em modo Raid 1
(espelhamento). Sendo assim, decidiu-se virtualizar o firewall dentro do Windows, alterando
sua distribuição Linux de Gentoo para Debian, ficando de acordo com os padrões da rede.
Para a virtualização, adicionaram-se primeiramente duas placas de rede ao servidor,
totalizando três, uma para ser utilizada pelo host e duas pelo firewall virtual. Para controle
utilizou-se uma ferramenta proprietária, no entanto aberta para utilização, o VMware Server.
(http://www.vmware.com/products/server/)
Sua instalação é muito simples, podendo ser acompanhada pelo tutorial
disponibilizado no Portal Petri. (http://www.petri.co.il/virtual_install_vmware_server.htm)
Figura 16: Interfaces no Host
Figura 17: Console de gerenciamento
2.3.4 Firewall e VPN
Com a padronização da distribuição, buscou-se o mesmo resultado com as regras do
firewall IPTABLES facilitando assim futuras alterações ou analises do ambiente. Para que
isso fosse possível foram utilizados scripts de inicialização.
Script Inicial:
# !/bin/bash # Implementacao de Firewall - IPTABLES echo Inicializando o firewall... # --- Inicio - Variaveis --- # echo Definindo variaveis do firewall... ################################## ######### IPTABLES ########### ################################## export IPTABLES=/sbin/iptables ################################## ######### INTERFACES ########## ################################## #Lan export INT_INT="eth0" export IP_INT_INT="192.168.70.1" #DMZ export INT_DMZ="eth1" export IP_INT_DMZ="X.X.X.X" #Net export INT_EXT="eth2" export IP_INT_EXT="X.X.X.X" export IP_INT_EXT2="X.X.X.X" #Localhost export LO_I="lo" export LO_IP="127.0.0.1"
################################## ######### SERVIDORES ########## ################################## export EC_SRVFW="192.168.70.1" export EC_SRV02="192.168.70.2" export EC_SRVMAIL="192.168.70.253" export EC_SRVMAIL2="192.168.70.254" export EC_SUP="192.168.70.8" export EC_SRVDEV="192.168.70.6" ################################## ########## REDES ############# ################################## export NET_DMZ="172.16.1.0/24" export NET_X="192.168.0.0/16" export NET_VPN="10.7.0.0/24" export NET_EC="192.168.70.0/24" export NET_CYBER="10.0.10.0/24" ################################## ######### SERVICOS ########### ################################## export CONECTIVIDADE="200.201.173.68" export CONECTIVIDADE_I="200.201.174.207" export CONECTIVIDADE_II="200.201.174.204" export ALCICAR="200.138.217.230" export RAISNET="161.148.185.46" export DeV="200.140.109.240" export DIF="200.215.13.90" export SINTEGRA="200.19.215.11" export SINTEGRA_I="200.215.4.5" export HIPERCARD="189.21.29.22" ######################### # # -- Fim - Variaveis --- # # ######################### ################################# ##### Definindo regras padroes ##### ################################# echo Preparando tabela de regras... # Limpa todas regras $IPTABLES -F $IPTABLES -t nat -F $IPTABLES -t mangle -F # Regras default $IPTABLES -P INPUT DROP $IPTABLES -P OUTPUT ACCEPT $IPTABLES -P FORWARD DROP # Localhost $IPTABLES -A INPUT -i $LO_I -j ACCEPT
$IPTABLES -A OUTPUT -o $LO_I -j ACCEPT # Deixa passar qualquer conexao ja estabelecida $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT ################################## # --- Final - Regras Padroes --- # ################################## echo "Aplicando regras para pacotes TCP..." /etc/init.d/fwrules/tcp.rules echo "Aplicando regras para pacotes UDP..." /etc/init.d/fwrules/udp.rules echo "Aplicando regras para pacotes ICMP..." /etc/init.d/fwrules/icmp.rules echo "Aplicando regras para NAT..." /etc/init.d/fwrules/nat.rules ############################## # --- Liberando acesso a internet --- # ############################## $IPTABLES -t nat -A POSTROUTING -o $INT_EXT -d ! $NET_MILIUM -j SNAT --to $IP_INT_EXT echo "Finalizando aplicação das regras de Firewall!"
O script finaliza chamando quatro arquivos com regras TCP, UDP, ICMP e NAT.
Segue um trecho do arquivo TCP:
### LIBERACOES TCP ###
### SMTP (25/tcp)
$IPTABLES -A FORWARD -m state --state NEW -p tcp -d $EC_SRVMAIL -m multiport --dports 25,80,143 -j
ACCEPT
$IPTABLES -A FORWARD -m state --state NEW -p tcp -d $EC_SRVMAIL2 -m multiport --dports 25,80,143 -j
ACCEPT
### HTTP (80/tcp)
$IPTABLES -A FORWARD -m state --state NEW -p tcp -s $NET_EC -d $IP_CU --dport 80 -j ACCEPT
$IPTABLES -A INPUT -m state --state NEW -p tcp -s $NET_EC -d $IP_INT_INT --dport 8080 -j ACCEPT
### Proxy (3128/tcp)
$IPTABLES -A INPUT -m state --state NEW -p tcp -s $NET_EC --dport 3128 -j ACCEPT
$IPTABLES -A INPUT -m state --state NEW -p tcp -s $NET_EC --dport 1863 -j ACCEPT
$IPTABLES -A INPUT -m state --state NEW -p tcp -s $NET_EC --dport 25000:30000 -j ACCEPT
### MSSQL
$IPTABLES -A FORWARD -m state --state NEW -p tcp -s $NET_EC -d $NET_X --dport 1433 -j ACCEPT
Para o tráfego de informações de e-mail e suporte remoto, utilizou-se a ferramenta “OpenVPN”, criando túneis das lojas para o escritório central e das lojas para o
CyberDatacenter (Lojas com os links dedicados). Provendo assim uma estrutura idêntica a que existia com os dois links, evitando a necessidade de alterar o código fonte da aplicação. A instalação da ferramenta está descrita no site Vivaolinux, um fórum bastante conhecido por trocas de experiências e tutoriais. (http://www.vivaolinux.com.br/artigo/VPN-em-Linux-com-OpenVPN/).
Figura 18: Arquivos de configurações das lojas
Figura 19: Túneis criados
Figura 20: Roteamento entre VPN’s
2.3.5 Segurança
Visando minimizar os riscos de segurança encontrados em grandes ambientes, iniciou-
se um processo de atualização de todos os servidores e formatação das máquinas da rede,
como também a implementação de antivírus corporativo, adquirido durante o processo.
2.3.5.1 Políticas
As máquinas dos caixas das lojas são utilizadas exclusivamente para o acesso ao
sistema, logo não foram instalados softwares cliente de antivírus, contudo definiu-se um perfil
restrito à aplicação buscando minimizar a instalação de aplicativos, impedir o acesso a
programas não relacionados a empresa e a dispositivos removíveis.
Figura 20: Tela do usuário final
Figura 21: Bloqueio de acessos
Tais políticas foram aplicadas pelo próprio editor de políticas interno do Windows, o
GpEdit.msc, (http://support.microsoft.com/kb/307882), e foram necessárias pois certas
funções do sistema não funcionariam com um usuário restrito do windows.
2.4 Controle
Os softwares de monitoração são responsáveis por checar, a todo o momento, a
disponibilidade dos equipamentos em todo ambiente de TI da empresa, tendo como objetivo
alertar via e-mail ou SMS sobre a queda de qualquer serviço ou a indisponibilidade de algum
servidor, com isso se pode corrigir falhar antes mesmo de algum usuário notar, além de
também aumentar o índice de disponibilidade total dos itens monitorados. [2]
A escolha da ferramenta foi feita analisando a sua eficácia, facilidade de uso e o
constante desenvolvimento por parte dos criadores dos softwares. Por esses motivos o
software Nagios foi escolhido.
Algumas características do Nagios são:
Monitoramento dos serviços;
Monitoramento dos recursos dos computadores ou equipamentos de rede;
Monitoração remota suportada através de túneis encriptados SSH ou SSL;
Capacidade de definir a rede hierarquicamente;
Notificação por diversos meios;
Rotação automática de log;
Interface amigável.
O Nagios mostrou-se poderoso e flexível, porém, exigindo bons conhecimentos em
sistemas operacionais Linux no momento da instalação e configuração.
Para realizar a instalação e configuração do software utilizou-se como fonte de
pesquisa o livro “Ambiente de rede monitorado com Nagios e Cacti” de autoria de Felipe
Costa.
Para o ambiente proposto procurou-se identificar quais serviços eram essenciais para o
faturamento de cada loja da rede.
Figura 23: Servidores monitorados
Figura 24: Serviços monitorados
3 Procedimentos de teste e avaliação
Para ter acesso as informações dos sistemas Windows, como processos, serviços,
carga, etc., é necessário utilizar um cliente desenvolvido especialmente para essa finalidade, o
nsclient. Sua instalação é feita copiando sua estrutura para raiz do servidor ou máquina
montada, acessar o mesmo caminho por meio do prompt de comando e efetuar o seguinte
comando:
pNSClient /install
Isso fará com que o programa seja instalado como serviço no sistema, a partir de então
o processo entrará em estado de “listenning” na porta TCP 1248.
Outros dispositivos de rede sendo eles “inteligentes” ou servidores com o serviço de
monitoramento ativado podem ter suas informações extraídas pelo próprio protocolo de
monitoramento (SNMP) na porta UDP (161), com a ajuda de plugins extras disponibilizados
no site do Nagios. [http://www.nagios.org]
Neste projeto o estado dos serviços e links eram as informações mais desejadas logo a
utilização de plugins extras tornou-se desnecessária. Procurou-se então, adaptar os códigos
fonte do programa para a estrutura criada, definindo servidores e serviços a serem
monitorados. Segue alguns exemplos de pesquisas:
Pesquisa SNMP
define service{ use generic-service host_name roteador-curitiba service_description Interlan LJ08 check_command check_snmp!-C public -o ifOperStatus.33 -r 1 -m IF-MIB
Pesquisa por NSclient:
define service{ use generic-service host_name lj01-srvoff service_description Servico SQL check_command check_nt!SERVICESTATE!-d SHOWALL -l MSSQLSERVER
}
O software Nagios em sua estrutura de configuração apresenta quarto arquivos que
devem ser configurados, sendo assim de acordo com a quantidade de serviços e ou hosts a
serem monitorados, os arquivos se tornam extensos e complexos, demandando um maior grau
de atenção por parte do administrador.
Após sua implementação, o sistema mostrou-se bastante eficiente, atendendo as
necessidades da equipe de TI de empresa, tais como:
Notificações via e-mail e ou msn;
Relatórios de disponibilidade de serviços.
Figura 25: Notificações via e-mails
4 Conclusão
O projeto apresentado atendeu as necessidades da empresa de modo satisfatório.
Realizadas todas as mudanças, constatou-se uma melhoria em todos os serviços da
rede, tornando-a mais confiável e escalavel, por conseguinte, satisfazendo as necessidades da
empresa relacionada aos custos devido ao uso de uma ferramenta de software livre. Dentro
das melhorias pode-se citar:
Padronização do ambiente;
Melhor utilização do link;
Velocidade no acesso ao Sistema;
Tempo reduzido na sincronização;
Redução do índice de retrabalho;
Melhoria no atendimento de suporte;
Monitoramento e controle da rede;
5 Referências bibliográficas
[1] STATO FILHO, André. Linux: Controle de Redes. Florianópolis: Visual Books,
2009. 352 p.
[2] COSTA, Felipe. Ambiente de rede monitorado com Nagios e Cacti. Rio de Janeiro:
Ciência Moderna, 2008
