Pontifícia Universidade Católica do Paraná PUCPR. Curso de Especialização - Redes e Segurança de Sistemas

Transcrição

1 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

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

3 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 ou telefone visando auxiliar as lojas na resolução dos problemas listados abaixo: Velocidade extremamente baixa; Inviabilidade no envio de ; 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. Início Coleta de dados Análise de dados Implementar Soluções Não Controle Sim Fim Fluxograma de descrição do projeto

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

5 Figura 3: Acesso irrestrito a servidores e roteadores Figura 5: Acesso irrestrito a servidor e switch Figura 6 e 7: Local inadequado para servidores

6 2.2.2 Estrutura lógica Figura 8: Utilização de Hub s 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

7 2.3 Desenvolvimento 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 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 kbits Upload.

8 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 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;

9 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 ref 1 rigerada. * 20: 19 lojas + escritorio central

10 Figura 13: No-break Figura 14: Cabeamento estruturado Figura 15: Rack 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.

11 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. ( Sua instalação é muito simples, podendo ser acompanhada pelo tutorial disponibilizado no Portal Petri. ( Figura 16: Interfaces no Host

12 Figura 17: Console de gerenciamento 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=" " #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=" "

13 ######### SERVIDORES ########## export EC_SRVFW=" " export EC_SRV02=" " export EC_SRVMAIL=" " export EC_SRVMAIL2=" " export EC_SUP=" " export EC_SRVDEV=" " ########## REDES ############# export NET_DMZ=" /24" export NET_X=" /16" export NET_VPN=" /24" export NET_EC=" /24" export NET_CYBER=" /24" ######### SERVICOS ########### export CONECTIVIDADE=" " export CONECTIVIDADE_I=" " export CONECTIVIDADE_II=" " export ALCICAR=" " export RAISNET=" " export DeV=" " export DIF=" " export SINTEGRA=" " export SINTEGRA_I=" " export HIPERCARD=" " ######################### # # -- 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

14 $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 j ACCEPT ### Proxy (3128/tcp) $IPTABLES -A INPUT -m state --state NEW -p tcp -s $NET_EC --dport j ACCEPT $IPTABLES -A INPUT -m state --state NEW -p tcp -s $NET_EC --dport j ACCEPT $IPTABLES -A INPUT -m state --state NEW -p tcp -s $NET_EC --dport 25000: j ACCEPT ### MSSQL $IPTABLES -A FORWARD -m state --state NEW -p tcp -s $NET_EC -d $NET_X --dport j ACCEPT Para o tráfego de informações de e suporte remoto, utilizou-se a ferramenta OpenVPN, criando túneis das lojas para o escritório central e das lojas para o

15 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. ( Figura 18: Arquivos de configurações das lojas Figura 19: Túneis criados Figura 20: Roteamento entre VPN s

16 2.3.5 Segurança Visando minimizar os riscos de segurança encontrados em grandes ambientes, iniciouse 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 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

17 Tais políticas foram aplicadas pelo próprio editor de políticas interno do Windows, o GpEdit.msc, ( 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 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

18 3 Procedimentos de teste e avaliação Figura 24: Serviços monitorados 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 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. [ 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

19 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 ou msn; Relatórios de disponibilidade de serviços. Figura 25: Notificações via s 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

20 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, p. [2] COSTA, Felipe. Ambiente de rede monitorado com Nagios e Cacti. Rio de Janeiro: Ciência Moderna, 2008