Ambiente de Aplicações WEB com banco de dados Progress

Divoney Krizonoski

Curso de Redes e Segurança de Sistemas

Pontífica Universidade Católica do Paraná

Curitiba, Novembro de 2010

Resumo

O objetivo deste trabalho é apontar ao leitor, todas as vulnerabilidades ou problemas que existiam no ambiente da empresa objeto de estudo deste artigo, com relação a serviços web disponibilizados a seus acionistas, clientes, corpo diretor e colaboradores, e mostrar quais foram as alternativas adotadas para garantir a segurança na disponibilização de informações aos seus usuários, bem como melhorar o desempenho, disponibilidade e controle de acesso das aplicações da empresa. Será abordado no decorrer deste artigo soluções como: Consolidação de Servidores, Máquinas Virtuais, Recursos embutidos na distribuição SUSE Linux Enterprise Server, e configuração de componentes Progress OpenEdge como App Server e Web Service. 1. Introdução A empresa objeto de estudo deste trabalho iniciou há alguns anos a portabilidade de aplicações para uso via intranet, para tal, foi adquirido um servidor HP Proliant ML110 com 1 GB de memória RAM e 2 discos para fazer RAID1. Instalou-se neste servidor o sistema operacional SUSE 10 SP1 para funcionar como Apache Web Server, com o passar do tempo, nasceram sistemas para acesso através da internet, e cada vez mais sistemas surgiram, componentes precisaram ser instalados neste servidor para funcionar os novos sistemas como TOMCAT, PHP, MYSQL, SAMBA, FTP, JAVA, Progress APPSERVER e WEBSPEED. A falha foi que as novas aplicações foram simplesmente instaladas, e não foi realizado nenhum estudo para verificar os riscos envolvidos na liberação das novas aplicações. Chegou-se ao ponto de existir na mesma máquina, aplicações de produção, testes e desenvolvimento, o que veio ocasionar sérios problemas de segurança, disponibilidade e desempenho, tendo em vista que as aplicações disponibilizadas neste servidor poderiam ser acessadas simultaneamente por públicos diversos como vendedores, funcionários, analistas desenvolvedores e empresas de consultoria que auxiliavam no desenvolvimento. Em determinado momento surgiu um novo projeto para liberar a consulta de informações financeiras para os acionistas através da internet, estas situações levaram a equipe de suporte a reestruturar o ambiente de forma que as aplicações pudessem ser acessadas de forma segura pelo público correto a qualquer momento. 2. Problemas Os maiores problemas encontrados no ambiente em questão estão detalhados abaixo: 2.1. Hardware:

O hardware utilizado para atender toda a demanda da empresa era uma máquina da marca HP modelo Proliant ML110 (Fig. Abaixo), e a resolução dos problemas de hardware foi tratado em um projeto de Consolidação de Servidores que determinou a extinção de servidores modelo torre ou mesa, visando redução de espaço, consumo de energia e geração de calor no datacenter.

Figura 1: Servidor HP Proliant ML110

2.2. Ambiente: Funcionavam juntos os ambientes de desenvolvimento, testes e produção das aplicações desenvolvidas utilizando tecnologia PHP, TOMCAT, JAVA, APPSERVER e WEBSPEED.

Figura 2: Cenário de Servidores com Aplicações WEB antes da reestruturação 2.3. Servidor Apache X PHP: O servidor Apache (ou Servidor HTTP Apache, em inglês: Apache HTTP Server, ou simplesmente: Apache) é o mais bem sucedido servidor web livre. Foi criado em 1995 por Rob McCool, então funcionário do NCSA (National Center for Supercomputing Applications). Numa pesquisa realizada em dezembro de 2007, foi constatado que a utilização do Apache representa 47.20% dos servidores ativos no mundo. Em maio de 2010, o Apache serviu mais de 54,68% de todos os sites e mais de 66% dos milhões de sites mais movimentados. É a principal tecnologia da Apache Software Foundation, responsável por mais de uma dezena de projetos envolvendo tecnologias de transmissão via web, processamento de dados e execução de aplicativos distribuídos. [1] PHP (um acrônimo recursivo para "PHP: Hypertext Preprocessor") é uma linguagem de script open source de uso geral, muito utilizada e especialmente guarnecida para o desenvolvimento de aplicações Web embútivel dentro do HTML. O que distingui o PHP de algo como Javascript no lado do cliente é que o código é executado no servidor, gerando

HTML que é então enviado para o cliente. O cliente receberia os resultados da execução desse script, mas não saberia como é o código fonte. Você pode inclusive configurar seu servidor para processar todos os seus arquivos HTML como PHP, e então não haverá nenhum modo dos usuários descobrirem se você usa essa linguagem ou não. [2] As falhas no que diz respeito ao PHP eram que muitas das alternativas para melhorar a segurança do servidor que deveriam ser implementadas no arquivo de configuração php.ini não podiam ser implementadas devido o fato de existirem várias aplicações feitas por diferentes desenvolvedores e sem padrão de desenvolvimento, ocasionando que recursos que não eram utilizados por uma aplicação eram utilizados por outra. 2.4. Aplicações Progress 2.4.1. AppServer

O AppServer é o núcleo da aplicação progress que fornece serviços de integração, sendo considerado como o motor para a execução da lógica de negócios que pode ser disponibilizado para aplicações clientes como um serviço.Essencialmente, o AppServer é um cliente em tempo de execução que não possui interface com o usuário, que fornece um meio para as aplicações cliente chamarem seus procedimentos e funções definidas pelo usuário remotamente.

O AppServer é freqüentemente usado em conjunto com o NameServer para prover conexão, facilitando a disponibilidade do serviço de aplicação. Com a ajuda de produtos adicionais e adaptadores, o AppServer torna seu serviço disponível para todos os tipos de clientes em muitas configurações diferentes.

Figura 3: Arquiterura do AppServer

A figura acima mostra os principais componentes em tempo de execução que compõem a arquitetura do AppServer e suas relações básicas. As setas pontilhadas indicam uma comunicação opcional para estabelecer uma conexão entre aplicações cliente e o AppServer.

A tabela abaixo identifica e descreve os componentes da arquitetura do AppServer.

Componente Descrição Client-Application Um processo que solicita a execução de procedimentos remotos no

contexto de uma sessão AppServer. Um aplicativo cliente pode ser: Webspeed; sessão Appserver; Aplicação Cliente .Net; Aplicação Cliente Java; Cliente Web Service

AppServer Agent Processo que executa procedimentos remotos requisitados por uma sessão cliente. Uma instancia AppServer normalmente contém vários agentes AppServer que se iniciam quando inicia um Appserver. Um agente AppServer pode atuar como um cliente de outro AppServer fazendo suas próprias chamadas a procedimentos remotos.

AppServer Broker Processo que cria, gerencia e aloca agentes AppServer para o acesso de aplicativos cliente. O AppServer Broker gerencia as requisições de conexão do cliente e dispara requisições de pedidos para os AppServer Agentes. Um AppServer Broker suporta uma instância de AppServer.

NameServer Processo que direciona as solicitações de conexão do cliente a um AppServer que suporta uma função de negócio especificada. Um cliente indica que instância do AppServer que deseja se conectar especificando um nome de serviço de aplicação que identifica a função de negócios necessários. Quando se inicia um AppServer que está configurado para uso com um NameServer, o AppServer registra os serviços suportados por aquele determinado NameServer. O NameServer com o qual registra um AppServer é o controle de servidor de nomes para essa instância AppServer.

Tabela 1: Componentes da arquitetura AppServer

2.4.2. Web Service Adapter (WSA)

Os Web Services Adapter (WSA) fornecem um gateway de comunicação e de transformação entre os clientes de serviços Web e serviços de aplicação AppServer. Usando o WSA, pode-se implantar um serviço Web, desenvolvido a partir de um serviço de aplicação AppServer existente e torná-lo disponível para clientes do serviço Web, utilizando Web Service Description Language (WSDL).

O WSA é executado como um servlet Java em quase qualquer Java Servlet Engine (JSE) ou em um JSE integrado a um servidor Web, o qual fornece acesso à Internet que os clientes do serviço Web requerem. Entretanto, além da comunicação HTTP e HTTPs fornecidos pelo JSE / servidor Web, o WSA compreende o Simple Object Access Protocol (SOAP) usado como um serviço de troca de mensagens entre clientes Web e os serviços Web que ele gerencia. Assim, o WSA traduz as requisições de serviço de clientes Web e respostas dos serviços de aplicações retornadas para os clientes a partir do AppServer.

2.5. TOMCAT O TOMCAT é um servidor web Java, mais especificamente, um container de servlets. O Tomcat possui algumas características próprias de um servidor de aplicação, porém não pode ser considerado um servidor de aplicação por não preencher todos os requisitos necessários. Por exemplo, o Tomcat não tem suporte a EJB. Desenvolvido pela Apache Software Foundation, é distribuído como software livre dentro do conceituado projeto Apache Jakarta, sendo oficialmente endossado pela Sun como a implementação de referência para as

tecnologias Java Servlet e JavaServer Pages (JSP). Ele cobre parte da especificação J2EE com tecnologias como servlet e JSP, e tecnologias de apoio relacionadas como Realms e segurança, JNDI Resources e JDBC DataSources. Ele tem a capacidade de atuar também como servidor web, ou pode funcionar integrado a um servidor web dedicado como o Apache ou o IIS. Como servidor web, ele provê um servidor web HTTP puramente em Java. O servidor inclui ferramentas para configuração e gerenciamento, o que também pode ser feito editando-se manualmente arquivos de configuração formatados em XML. [3] Existiam três aplicações que rodavam em cima do TOMCAT, uma era proprietária e só funcionava em cima de uma versão específica de Java (Versão seis), as outras estavam rodando em cima da versão cinco. Uma destas aplicações era uma ferramenta de BI (Business Intelligence) a qual fornecia informações estratégicas da empresa sem as mínimas condições de segurança, pois não solicitava nem autenticação, bastava ter instalado na estação do usuário um programa cliente do fabricante. 2.6. Rede: Não existia na rede da empresa uma DMZ, apenas um NAT de endereço privado para público no firewall. DMZ, em segurança da informação, é a sigla para de DeMilitarized Zone ou "zona desmilitarizada", em português. Também conhecida como Rede de Perímetro, a DMZ é uma pequena rede situada entre uma rede confiável e uma não confiável, geralmente entre a rede local e a Internet. A função de uma DMZ é manter todos os serviços que possuem acesso externo (tais como servidores HTTP, FTP, de correio eletrônico, etc) separados da rede local, limitando assim o potencial dano em caso de comprometimento de algum destes serviços por um invasor. Para atingir este objetivo os computadores presentes em uma DMZ não devem conter nenhuma forma de acesso à rede local. A configuração é realizada através do uso de equipamentos de Firewall, que vão realizar o controle de acesso entre a rede local, a internet e a DMZ (ou, em um modelo genérico, entre as duas redes a serem separadas e a DMZ). Os equipamentos na DMZ podem estar em um switch dedicado ou compartilhar um switch da rede, porém neste último caso devem ser configuradas Redes Virtuais distintas dentro do equipamento, também chamadas de VLANs (Ou seja, redes diferentes que não se "enxergam" dentro de uma mesma rede - LAN).[4]

Figura 4: Diagrama DMZ [5]

Em redes de computadores, NAT, Network Address Translation, também conhecido como masquerading é uma técnica que consiste em reescrever os endereços IP de origem de um pacote que passam por um router ou firewall de maneira que um computador de uma rede interna tenha acesso ao exterior (rede pública). [6]

2.7. Samba:

Samba é um programa de computador, utilizado em sistemas operacionais do tipo Unix, que simula um servidor Windows, permitindo que seja feito gerenciamento e compartilhamento de arquivos em uma rede Microsoft. Na versão 3, o Samba não só provê arquivos e serviços de impressão para vários Clientes Windows, como pode também integrar-se com Windows Server Domain, tanto como Primary Domain Controller (PDC) ou como um Domain Member. Pode fazer parte também de um Active Directory Domain. [7] Este recurso era utilizado pelos desenvolvedores para atualizarem as aplicações e pelo público que acessava o sistema de workflow para publicar documentos, a falha estava no sentido de que o controle de acesso era feito apenas pelo IP da estação, o que não garantia a autenticidade de quem estava acessando o conteúdo. 2.8. SSH: Secure Shell ou SSH é, simultaneamente, um programa de computador e um protocolo de rede que permite a conexão com outro computador na rede, de forma a executar comandos de uma unidade remota. Possui as mesmas funcionalidades do TELNET, com a vantagem da conexão entre o cliente e o servidor ser criptografada. [8] Este recurso também era utilizado pelos analistas para acessarem a console do servidor para start, stop e manutenção das aplicações quando necessário, o que chegou a ocasionar por algumas vezes a utilização inadequada do comando RM que causou transtornos sendo necessária restauração de backup´s para restabelecimento das aplicações apagadas. 2.9. Firewall: Firewall (em português: muro corta-fogo) é o nome dado ao dispositivo de uma rede de computadores que tem por objetivo aplicar uma política de segurança a um determinado ponto de controle da rede. Sua função consiste em regular o tráfego de dados entre redes distintas e impedir a transmissão e/ou recepção de acessos nocivos ou não autorizados de uma rede para outra. Este conceito inclui os equipamentos de filtros de pacotes e de proxy de aplicações, comumente associados a redes TCP/IP. Os primeiros sistemas firewall nasceram exclusivamente para suportar segurança no conjunto de protocolos TCP/IP. O termo inglês firewall faz alusão comparativa da função que este desempenha para evitar o alastramento de acessos nocivos dentro de uma rede de computadores a uma parede corta-fogo (firewall), que evita o alastramento de incêndios pelos cômodos de uma edificação. Existe na forma de software e hardware, ou na combinação de ambos (neste caso, normalmente é chamado de "appliance"). A complexidade de instalação depende do tamanho da rede, da política de segurança, da quantidade de regras que autorizam o fluxo de entrada e saída de informações e do grau de segurança desejado. [9]

Figura 5: Firewall separando redes LAN e WAN

O firewall existente era um firewall da marca Aker e suas funções de IPS/IDS eram limitadas e com pouca atualização pelo fabricante, o que dificultava a eficiência na detecção de intrusos e causava também muito falso positivo o que levou a empresa a não utilizar este recurso no firewall existente. Um sistema de prevenção de intruso (em inglês: Intrusion Prevention System) é um dispositivo de segurança de rede que monitora o tráfego e/ou atividades dos sistema em busca de comportamentos maliciosos ou não desejáveis, em tempo real, para bloquear ou prevenir essas atividades. Um IPS baseado em rede, por exemplo, vai operar em linha para monitorar todo o tráfego em busca de códigos maliciosos ou ataques. Quando um ataque é detectado, é possível bloquear os pacotes danosos enquanto o tráfego normal continua seu caminho. [10] Sistema de detecção de intrusos ou simplesmente IDS ( em inglês: Intrusion detection system) refere-se a meios técnicos de descobrir em uma rede quando esta está tendo acessos não autorizados que podem indicar a ação de um cracker ou até mesmo funcionários mal intencionados. [11] 2.10. Atualização de Fontes Qualquer desenvolvedor possuía acesso para atualizar os sistemas de produção o que poderia ocasionar que programas não autorizado fossem compilados como sendo programas de produção. O Impacto deste problema é que o código poderia ser de origem duvidosa e a única informação que existiria era o IP da estação que fez a mudança. 2.11. Acesso Remoto de Consultores Não existia nenhum controle de acesso para os consultores que auxiliam no desenvolvimento das aplicações existentes quando estes estavam trabalhando fora da empresa (Home Office). 2.12. Criptografia HTTPS (HyperText Transfer Protocol secure), é uma implementação do protocolo HTTP sobre uma camada SSL ou do TLS. Essa camada adicional permite que os dados sejam transmitidos através de uma conexão criptografada e que se verifique a autenticidade do servidor e do cliente através de certificados digitais. A porta TCP usada por norma para o protocolo HTTPS é a 443. O protocolo HTTPS é utilizado, em regra, quando se deseja evitar que a informação transmitida entre o cliente e o servidor seja visualizada por terceiros, como por exemplo no caso de compras online. A existência na barra de tarefas (normalmente do lado direito) de um cadeado demonstra a certificação de página segura (SSL). Nas URLs dos sites o início ficaria 'https://'. Geralmente os navegadores mais atuais indicam um site seguro, atráves das barras de endereço que ficam verde. Consulte a ajuda do seu navegador para mais informações de como ele avisa sobre sites seguros. [12] Nenhuma das aplicações existentes na empresa utilizava o protocolo https e portanto as informações trafegadas poderiam ser capturadas por terceiros. 3. Soluções e ou Alternativas Encontradas: 3.1 Hardware

Para resolução do problema de Hardware foi adquirido uma solução que contempla um Blade System C7000 da HP com capacidade para 16 lâminas com total redundância de fontes, ventiladores, rede e SAN, tal solução contemplou a aquisição de duas lâminas para realização de virtualização de servidores, com capacidade adequada para atender a demanda atual e futura pelos próximos três anos fazendo uso do software gratuito de virtualização VMware. As máquinas virtuais estão armazenadas em uma área do storage e replicadas de forma assíncrona para um storage backup que fica em outro local, com o objetivo de garantir a continuidade dos negócios em caso de desastre. Está previsto para os próximos anos investimentos no intuito de garantir alta disponibilidade para as máquinas virtuais com recursos de balanceamento de carga e tolerância a falhas.

Figura 6: BladeSystem HP C7000

3.2. Ambiente Para resolução do problema de ambiente definiu-se que deveriam existir máquinas para desenvolvimento, testes e os sistemas de produção deveriam funcionar separadamente considerando as características de plataforma de desenvolvimento, público de utilização e sua criticidade, Várias máquinas virtuais foram necessárias para realizar tal separação e garantir que uma aplicação não sofresse impacto de outra com isso melhorando o desempenho, disponibilidade e segurança.

Figura 7: Cenário de Servidores com Aplicações WEB após a reestruturação 3.3. Servidores WEB e Aplicações

3.3.1. Software Básico para os servidores WEB que ficarão na DMZ. a) Os servidores deverão possuir Sistema Operacional SUSE Linux 10 SP3 ou superior; b) Os servidores Web Server deverão ter instalado o servidor web Apache versão 2 ou

superior. Para fins de entendimento, o diretório de configuração do apache utilizado é o /etc/apache2;

c) Para entendimento, chamaremos o servidor web que receberá as solicitações externas de MV36;

No cenário que foi criado, todo acesso ao servidor será realizado através do apache (somente porta 443), que redirecionará as conexões ao TOMCAT, quando for o caso, este, por sua vez, redirecionará as conexões ao WSA, conforme figura abaixo.

Figura 8: Fluxo de Conexão as aplicações

Após as configurações terem sido realizadas e os serviços funcionando, na segunda semana de utilização do sistema aconteceu um fato novo que passou despercebido, fato foi que o link para a aplicação estava na página principal da empresa, armazenada em outro servidor com desempenho comprometido e com sistema operacional Netware 6.5, o qual estourava o cache de memória e o serviço apache parava de responder, necessitando intervenção técnica para reinicialização do sistema operacional. Tal problema precisou ser resolvido imediatamente e a solução foi colocar o site em uma nova máquina virtual com as mesmas características dos outros servidores web e mais alguns ajustes de segurança no arquivo php.ini. Para atualizar o conteúdo, foi criada uma conta FTP onde a empresa responsável por fazer a atualização do web site da companhia possa postar as atualizações, e, via rsync, os arquivos correspondentes, são atualizados no servidor web em horários determinados via crontab. Abaixo algumas configurações que foram realizadas no servidor Web. Conteúdo do arquivo: /etc/apache2/listen.conf definindo acesso apenas na porta 443 <IfDefine SSL> <IfDefine !NOSSL> <IfModule mod_ssl.c> Listen 443 </IfModule> </IfDefine> </IfDefine> Listen 192.168.1.1:443 Listen 192.168.1.2:443

Conteúdo do arquivo: /etc/apache2/vhosts.d/yast2_vhosts.conf onde configura-se os sites virtuais; <VirtualHost 192.168.1.1> DocumentRoot /srv/www/htdocs/site1/ ServerName www.site1.com.br ErrorLog /var/log/apache2/site1-error_log CustomLog /var/log/apache2/site1-access_log common ServerAdmin administrador@site1.com.br <Directory /srv/www/htdocs/site1/> AllowOverride None Order allow,deny Allow from all </Directory> </VirtualHost> <VirtualHost 192.168.1.2> DocumentRoot /srv/www/htdocs/site2/ ServerName www.site2.com.br ErrorLog /var/log/apache2/site2-error_log CustomLog /var/log/apache2/site2-access_log common ServerAdmin administrador@site2.com.br <Directory /srv/www/htdocs/site2/> AllowOverride None Order allow,deny Allow from all </Directory> </VirtualHost>

Alterar os arquivos padrões de erro no servidor Apache Web Server para os erros 403 (acesso proibido), 404 (página não encontrada) e 500 (erro interno do servidor) no caminho /usr/share/apache2/error: HTTP_FORBIDDEN.html.var HTTP_NOT_FOUND.html.var HTTP_INTERNAL_SERVER_ERROR.html.var p2-bg-topo.png p2-logo.png

A configuração de SSL será abordada na seção 3.12 deste artigo. 3.4. Configuração Web Service Adapter 3.4.1. Software básico para os servidores de aplicação Progress a) Os servidores deverão possuir Sistema Operacional Suse Linux 10 SP3 ou superior. b) Os servidores de aplicação progress deverão ter instalado o servidor de aplicações

TOMCAT versão 5 ou superior e podem ficar na mesma rede que os servidores de banco de dados. Para fins de entendimento, o diretório de instalação do tomcat utilizado é o /usr/share/tomcat.

c) Os servidores de aplicação progress deverão ter instalado o servidor de aplicações progress WSA versão 10.1B ou superior. Para fins de entendimento, o diretório de instalação do WSA é o /sistemas/progress/dlc101b

d) Para entendimento chamaremos o servidor que executará as aplicações progress de MV37 3.4.2. Configuração do AppServer e Web Services Adapter (mv37)

a) Parar a execução do tomcat; b) Realizar a cópia do diretório mv37:/sistemas/progress/dlc101b/servlets/wsa no caminho /usr/share/tomcat5/webapps/ (apenas se o diretório não existir no caminho especificado). c) Copiar o conteúdo do diretório wsa na pasta webservices; d) Criar o diretório wsa no caminho: mv37:/usr/share/tomcat5/webapps/webservices # mkdir wsa

e) Abrir o arquivo web.xml que se encontra no diretório /webservices/WEB-INF/ e efetuar o replace de todas as ocorrências do texto “wsa1” por “wsa”; f) Acessar o Progress Explorer Tool; g) Conectar o servidor mv37 (porta 20931); h) Se houver problema na conexão, verificar se o proadsv está sendo executado (no servidor mv37) proadsv –q

i) Se ainda houver problema de conexão, alterar o encrypting level de usuários do servidor para DES via yast2. Em seguida, alterar a senha do root através do comando passwd. j) Através da ferramenta Progress Explorer Tool, criar o appServer “Aplicativo” conforme imagens abaixo.

Figura 9: Configuração de modo operacional e autenticação do Broker

Figura 10: Configuração Name Server e Application Service

Figura 11: Configuração do arquivo de log e Recursos avançados do Broker

Figura 12: Configuração geral do agente

Figura 13: Parâmetros de conexão do agente

Figura 14: Configuração de segurança do App Server

k) Após a inclusão do broker “Aplicativo”, criar o Web Services Adapter “wsa” conforme imagens abaixo.

Figura 15: Janela de criação do WebService

Figura 16: Configuração de local e proxy server do WebService

Figura 17: Configuração de WSDL e Log do Web Service

Figura 18: Configuração de segurança e recursos avançados do WebService

Carregue o tomcat e verifique se o recém criado adapter está em execução.

Figura 19: Status de execução do WebService

3.4.3. Efetuando o deploy do WebService “Aplicativo”

a) Copiar o diretório mv37:/sistemas/aplicativo/web/ws/wsa para o disco local; b) Abrir a ferramenta Proxy Generator

Figura 20: Criação projeto de deploy

Figura 21: Configuração geral do projeto de deploy

Figura 22: Execução deploy do projeto

Figura 23: Habilitação do WebService

Figura 24: Geração de Proxy para WebService

3.4.7. Aspectos de segurança AppServer™ e WebSpeed™ a) Parar o progress admin server (proadsv –stop). b) Certifique-se de que o diretório mv37:/sistemas/webspeed/config contenha os arquivos: -rw-r--r-- 1 root root 18 Nov 17 2009 aplicativo .ips.allow -rw-r--r-- 1 root root 31 May 12 2009 aplicativo .procedures.deny -rw-r--r-- 1 root root 18 Nov 17 2009 wsbroker1. ips.allow -rw-r--r-- 1 root root 31 May 12 2009 wsbroker1. procedures.deny -rw-r--r-- 1 root root 18 Nov 17 2009 wsdynamics 1.ips.allow -rw-r--r-- 1 root root 31 May 12 2009 wsdynamics 1.procedures.deny

Estes são arquivos de configuração criados na empresa para definir quais aplicativos que podem ou não ser requisitados. c) A partir do diretório mv37:/sistemas/progress/dlc101b, remover os arquivos listados abaixo, os programas substitutos customizados serão executados de /sistemas/webspeed. /src/web/objects/web-disp.p /tty/web/objects/web-disp.r

d) Cada nova instância de um WebSpeed Transaction Server deve-se obrigatoriamente adicionar em seu propath o diretório /sistemas/webspeed. Segue exemplos de configuração do broker: • campo ‘Parâmetros de inicialização do agente’ -pf /sistemas/aplicativo/scripts/parametrosconexao. pf -p web/objects/web-disp.p –weblogerror

• campo ‘PROPATH’ /sistemas/aplicativo:/:/sistemas/webspeed:${PROPATH }:${WRKDIR}

e) Remover arquivos desnecessários em ambiente de produção.

A partir do diretório mv37:/sistemas/progress/dlc101b, exclua os arquivos/diretórios da lista que segue: /bin/_debugConfig* /bin/_debugEnable* /bin/proDebugConfig* /bin/proDebugEnable* samples/ servlets/ sports/ sports2000trgs/ src/ demo*.* empty.* isports*.* sports*.*

f) Os itens que seguem abaixo têm base na documentação on-line progress.

• Não utilizar portas ou nomes padrões para Name Server, Broker e Agents/Servers; • Apagar as configurações padrões WSBROKER1, ASBROKER1, NS1; • Recriar os brokers apropriados não usando portas padrões; • Não utilizar a porta 5162 para o Name Server ou chamá-lo de NS1 por exemplo; • Apagar todos os serviços/apps que não forem ser usados em ambiente de produção.

- Para o deployment host chamaremos o Name Server de NSconn habilitado na porta 15000.

Figura 25: Progress Explorer Tool (Ferramenta de Administração e configuração AppServer e

WebService)

Figura 26: Modo de aplicação do agente

Figura 27: Aspectos de segurança do agente AppServer

Figura 28: Propriedades de segurança do WebService

g) Acesse as propriedades do Adapter wsa, seção WSDL. Desabilite as opções ‘Enable

WSDL Retrieval’ e ‘Enable WSDL Listing Retrieval’ h) Inicie o AdminServer (proadsv –start) i) Restart o tomcat e tente recuperar o wsdl. O browser deve exibir a página:

Figura 29: WSDL desabilitado

Não é aconselhável deixar o recurso WSDL habilitado, pois o mesmo mostra propriedades do WebService. 3.5. Tomcat

3.5.1. Configuração de conexão entre o apache e o tomcat (mv36 e mv37) a) Configuração do mod_jk, que é o conector entre o apache e o tomcat (redireciona as

conexões recebidas pelo apache para o tomcat (mv36). Criar o arquivo /etc/apache2/mod_jk.conf:

# Load mod_jk module # Update this path to match your modules location LoadModule jk_module /usr/lib/apache2/mod_jk2.s o # Declare the module for <IfModule directive> (remo ve this line on Apache 2.x) #AddModule mod_jk.c # Where to find workers.properties # Update this path to match your conf directory loc ation (put workers.properties next to httpd.conf) JkWorkersFile /etc/apache2/workers.properties # Where to put jk shared memory # Update this path to match your local state direct ory or logs directory JkShmFile /var/log/apache2/mod_jk.shm # Where to put jk logs # Update this path to match your logs directory loc ation (put mod_jk.log next to access_log) JkLogFile /var/log/apache2/mod_jk.log # Set the jk log level [debug/error/info] JkLogLevel info # Select the timestamp log format JkLogStampFormat "[%a %b %d %H:%M:%S %Y] " # Send everything for context /examples to worker n amed worker1 (ajp13) JkMount /webservices/* worker1

b) Alterar a configuração do apache, para incluir o arquivo /etc/apache2/mod_jk.conf

(mv36). No /etc/apache2/httpd.conf, incluir na última linha:

Include /etc/apache2/mod_jk.conf

c) Configuração do workers.properties, que é o arquivo que configura as portas de conexão com o tomcat (mv36).

Criar o arquivo /etc/apache2/workers.properties.

#Define 1 real worker using ajp13 worker.list=worker1 # Set properties for worker1 (ajp13) worker.worker1.type=ajp13 worker.worker1.host=192.168.1.2 worker.worker1.port=8009

d) Configuração do jk2.properties, que é o arquivo que configura o tomcat para permitir as

conexões via apache (mv37). Editar o arquivo /usr/share/tomcat5/conf/jk2.properties, descomentando a última linha

## THIS FILE MAY BE OVERRIDEN AT RUNTIME. MAKE SURE TOMCAT IS STOPED ## WHEN YOU EDIT THE FILE. ## COMMENTS WILL BE _LOST_ ## DOCUMENTATION OF THE FORMAT IN JkMain javadoc. # Set the desired handler list # handler.list=apr,request,channelJni # # Override the default port for the socketChannel # channelSocket.port=8019 # Default: # channelUnix.file=${jkHome}/work/jk2.socket # Just to check if the the config is working # shm.file=${jkHome}/work/jk2.shm shm.file=/var/log/apache2/mod_jk.shm # In order to enable jni use any channelJni directi ve # channelJni.disabled = 0 # And one of the following directives: # apr.jniModeSo=/opt/apache2/modules/mod_jk2.so # If set to inprocess the mod_jk2 will Register nat ives itself # This will enable the starting of the Tomcat from mod_jk2 apr.jniModeSo=inprocess

e) Parar os serviços do Apache e Tomcat /etc/init.d/apache2 stop (mv36) /usr/share/tomcat5/bin/shutdown.sh (mv37)

f) editar o /etc/apache2/vhosts.d/mv36-ssl.conf e incluir na última linha do VirtualHost (mv36)

JkMount /webservices/* worker1

g) Iniciar os serviços do Apache e Tomcat (nesta ordem) /etc/init.d/apache2 start (mv36) /usr/share/tomcat5/bin/startup.sh (mv37)

h) Testar o acesso via browser (se o certificado não estiver assinado, o browser vai informar que o certificado não é confiável) https://aplicativo.site.com.br/webservices/wsa

3.5.2. Criação do context ‘spool’ no tomcat a) Parar os serviços do Tomcat; b) Tornar visível no ambiente do Tomcat o path da pasta temporária utilizada pelas aplicações web. Para isso, crie o arquivo: /usr/share/tomcat5/conf/Catalina/localhost/spool.xm l editar o arquivo spool.xml inserindo o seguinte con teúdo:

<Context path="/spool" docBase="/sistemas/aplicativ o/spool" debug="0" privileged="false"> <!-- Link to the user database we will get roles from --> <!-- ResourceLink name="users" global="UserDataba se" type="org.apache.catalina.UserDatab ase"/ -->

</Context>

c) Iniciar os serviços do Tomcat; 3.5.3. Aspectos de segurança Tomcat a) Acesse o Tomcat Web Application Manager < http://192.168.1.1:8080/manager/html> e efetue o undeploy das aplicações marcadas com * . Efetue um stop no app antes de removê-lo.

Figura 30: Gerenciamento Web do Tomcat

b) Parar os serviços do Tomcat; c) Edite o arquivo mv37:/usr/share/tomcat5/conf/Catalina/localhost/admin.xml, alterando o conteúdo da tag Context para: <Context docBase="" privileged="true" antiResourceLocking="false" antiJARLocking ="false"> <!-- Uncomment this Valve to limit access to the Admin app to localhost for obvious security reasons. Allow may be a com ma-separated list of hosts (or even regular expressions). --> <Valve className="org.apache.catalina.valves.Remo teAddrValve" allow="127.0.0.1"/> </Context>

d) Edite o arquivo mv37:/usr/share/tomcat5/conf/Catalina/localhost/manager.xml, alterando o conteúdo da tag Context para: <Context docBase="" privileged="true" antiResourceLocking="fal se" antiJARLocking="false"> <Valve className="org.apache.catalina.valves.Remo teAddrValve" allow="127.0.0.1"/> <!-- Link to the user database we will get roles from --> <ResourceLink name="users" global="UserDatabase" type="org.apache.catalina.UserDatab ase"/> </Context>

e) Abra o arquivo mv37:/usr/share/tomcat5/conf/tomcat-users.xml e certifique-se de que nenhum username esteja vinculado à role manager ou admin; <?xml version='1.0' encoding='utf-8'?> <tomcat-users> <role rolename="tomcat"/> <role rolename="role1"/> <user username="tomcat" password="tomcat" roles=" tomcat"/> <user username="role1" password="tomcat" roles="r ole1"/> <user username="both" password="tomcat" roles="to mcat,role1"/> </tomcat-users>

f) Iniciar os serviços do Tomcat; g) Certifique-se de que as aplicações abaixo não estejam sendo executadas: ROOT --> http://172.16.3.37:8080/ Tomcat Administration --> http://172.16.3.37:8080/ admin Tomcat Manager --> http://172.16.3.37:8080/ manager/html balancer --> http://172.16.3.37:8080/ balancer jsp-examples --> http://172.16.3.37:8080/ jsp-examples/ servlets-examples --> http://172.16.3.37:8080/ servlets-examples/ tomcat-docs --> http://172.16.3.37:8080/ tomcat-docs webdav --> http://172.16.3.37:8080/ webdav/

h) Certifique-se de que o WebService que foi criado esteja no ar: http://192.168.1.1:8080/webservices/wsa

3.6. Rede

Para proteger o banco de dados de acessos indevidos criou-se a DMZ utilizando uma interface física no firewall onde os servidores WEB com apache ficam nesta DMZ conforme mostrado na figura 4. 3.7. Samba Optou-se por eliminar este tipo de acesso tendo em vista que a empresa já utilizava a suíte de produtos Novell para controlar acesso a diretórios o qual é totalmente integrado ao eDirectory (Serviços de Diretório), criou-se então um servidor de arquivos para armazenar os programas fontes, produção e testes e passou-se a utilizar o eDirectory para definir quem acessa qual diretório na rede, garantindo autenticidade ao processo. (Mais detalhes na seção 3.10) 3.8. SSH Para proteção dos servidores e evitar que incidentes voltassem a acontecer foi alterado a senha do root em todos os servidores Linux da empresa para uma senha forte e após esta alteração apenas duas pessoas tem conhecimento da mesma e também foi guardada uma cópia com a senha em envelope lacrado no cofre da empresa. Para permitir que atividades básicas de manutenção aos servidores aconteçam de forma mais controlada optou-se em construir um menu em Script Shell que está em desenvolvimento e seguirá a idéia do exemplo abaixo:

a) Criar usuário com id de root porém com outro login:

useradd -c "Usuario para operacao de comandos contr olados" -d /home/operador -g 0 -m -o -u 0 -s /bin/bash operado r

-c = comentário -d = home directory -g = grupo (0-root) -m = criar home directory -o = permitir id duplicado -u = id do usuário (0=root) -s = shell do usuário

b) Criar arquivo /etc/skel/.bashrcoperacoes c) Remover /home/operador/.bashrc d) Criar link simbólico cd /home/operador ln -s /etc/skel/.bashrcoperacoes .bashrc

Exemplo do script Shell; function showmenu() { clear echo " F U N C O E S H A B I L I T A D A S " echo " -------------------------------------- " echo "" echo "" echo " 1 - Lista todos os processos em execuc ao" echo " 2 - pesquisa em todos os processos em execucao" echo " 3 - Lista espaco dos file systems" echo " 4 - Top" echo " 5 - Lista arquivo/diretorio" echo " 6 - Lista conteudo de arquivo" echo " 7 - Lista primeiras n linhas de arquiv o" echo " 8 - Lista ultimas n linhas de arquivo" echo "" echo " 99 - Fim " echo "" } function psef() { ps -ef |more echo "Fim da consulta - pressione ENTER" read } function psefgrep() { clear echo "Digite a expressao a ser pesquisada:" read palavra echo "Ignora maiuscula/minuscula (s/n):" read cases if [ "$cases" = "s" -o "$cases" = "S" ]; then ps -ef|grep -i $palavra|more else ps -ef|grep $palavra|more fi echo "Fim da consulta - pressione ENTER" read

} function lsl() { clear echo "Digite o arquivo/diretorio a ser listado:" read palavra ls -l $palavra|more echo "Fim da consulta - pressione ENTER" read } function catfile() { clear echo "Digite o arquivo a ser listado:" read palavra if [ -f "$palavra" ]; then cat $palavra|more else if [ -d "$palavra" ]; then echo "$palavra e um diretorio!" else echo "Arquivo $palavra nao encontrado" fi fi echo "Fim da consulta - pressione ENTER" read } function headfile() { clear echo "Digite o arquivo a ser listado:" read palavra if [ -f "$palavra" ]; then echo "Digite a quantidade de linhas:" read linhas head -$linhas $palavra|more else if [ -d "$palavra" ]; then echo "$palavra e um diretorio!" else echo "Arquivo $palavra nao encontrado" fi fi echo "Fim da consulta - pressione ENTER" read } function tailfile() { clear echo "Digite o arquivo a ser listado:" read palavra if [ -f "$palavra" ]; then echo "Digite a quantidade de linhas:" read linhas tail -$linhas $palavra|more else if [ -d "$palavra" ]; then echo "$palavra e um diretorio!" else echo "Arquivo $palavra nao encontrado" fi fi echo "Fim da consulta - pressione ENTER" read }

function dfk() { df -k |more echo "Fim da consulta - pressione ENTER" read } function otop() { top echo "Fim da consulta - pressione ENTER" read } # Desabilita ctrl+c # ----------------- trap "" 1 2 3 20 # leitura do menu # --------------- while true do showmenu printf 'Digite a opcao: ' read option case $option in 1) psef ;; 2) psefgrep ;; 3) dfk ;; 4) otop ;; 5) lsl ;; 6) catfile ;; 7) headfile ;; 8) tailfile ;; 99) exit ;; ?) echo "showmenu" ;; *) echo "opcao invalida" ;; esac done

Figura 31: Exemplo do menu de operações controladas

3.9. Firewall O firewall aker foi substituído por outro da marca Juniper com capacidade superior e recursos de administração mais avançados. Todas as regras foram revisadas e instituiu-se um comitê de Segurança onde este avalia o impacto de qualquer alteração nas regras do firewall, ou seja, toda e qualquer alteração de segurança deve passar por este comitê.

3.10. Atualização de Fontes Para resolver o problema de atualização de fontes, devido à retirada dos acessos a console dos servidores, desativação do serviço samba e a diversidade de servidores que passou a existir, utilizou-se recursos embutidos no sistema operacional Linux (Rsync) e algumas alterações de procedimento. 3.10.1. Procedimento: Criou-se um grupo no serviço de diretório denominado “Gerente_Mudanças_TI” composto por duas pessoas que ficaram responsáveis por atualizarem todos os programas em produção quando necessário. Definiram-se também os acessos ao restante da equipe para os diretórios de desenvolvimento e testes.

Figura 32: Controle de Acesso a Diretórios

Para utilização deste recurso é necessário um servidor com a distribuição Linux Suse 10 Sp2 ou superior e o produto OES2 (Open Enterprise Server) da Novell instalado como produto acessório dentro do SUSE. Para instalar o OES no SUSE pode-se utilizar o Yast dentro da console gráfica ou instalar os pacotes RPM via linha de comando. Figura 33: Instalação de Produto Acessório Figura 34: Serviços Disponíveis para instalação

Figura 35: iManager (Ferramenta de Administração dos Produtos Produtos Novell)

Através do iManager é possível administrar todos os serviços configurados nos servidores com o OES instalado. 3.10.2. Atualização de Fontes: Para atualizar as aplicações nos servidores a partir de uma única origem (Fonte) utilizou-se o rsync rodando em horários determinados na crontab do servidor. Tal atividade necessitou de alterações de chaves SSH a fim de que não fosse solicitada senha no momento em que o script do RSYNC estivesse sendo executado. A) Criar um script em /bin do servidor destino (192.168.3.11) referente a qual diretório se deseja sincronizar. vi /bin/script_rsync.sh #!/bin/sh rsync -av --delete root@192.168.1.12:/diretorio/ /d iretorio/.

B) Configuração crontab, no exemplo abaixo o script do rsync será executado de cinco em 5 minutos e gravará sua atividade em um arquivo de log. */5 * * * * /bin/script_rsync.sh >> /var/log/script _rsync.log

C) Para não solicitar senha no momento de execução do script deve-se criar uma chave de segurança na máquina que será acessada para a máquina que está acessando. Iniciar os comandos na máquina que irá acessar Neste exemplo o servidor 192.168.3.11 (Destino) acessará o servidor 192.168.3.12 (Origem) via ssh sem pedir senha. ## Acessar o servidor 192.168.3.11 ssh-keygen -b 1024 -t rsa scp /root/.ssh/id_rsa.pub root@192.168.3.12:/root

## Acessar o servidor 192.168.3.12

cd /root cat id_rsa.pub >> .ssh/authorized_keys cat id_rsa.pub >> .ssh/know_hosts rcsshd restart

## Acessar o servidor 192.168.3.11 e testar a conexão ssh 192.168.3.12

O resultado deve ser a conexão ao servidor sem solicitar senha, conforme exemplo abaixo.

Figura 36: Exemplificação dos comandos acima

3.11. Acesso Remoto de Consultores Para garantir mobilidade aos consultores envolvidos nos projetos em desenvolvimento ficou estabelecido que eles devem acessar um servidor de terminal (Windows Terminal Service) configurado com todas as aplicações necessárias ao desenvolvimento com a ressalva de que o acesso externo deve ocorrer através de conexão segura utilizando um client de VPN (Secure Roaming) e autenticação LDAP no serviço de diretório. No serviço de diretório foi criado um grupo de pessoas autorizadas a conectar via VPN. 3.12. Criptografia Para assegurar que as informações trocadas entre a sessão do usuário e o servidor apache não fossem legíveis caso fossem capturadas foi criado um certificado digital que foi assinado por uma entidade certificadora e configurado no servidor apache. Os passos para configurar uma comunicação segura no SUSE Linux estão descritos abaixo: a) Criar um diretório no servidor para armazenar os certificados; mkdir /etc/apache2/certificados cd /etc/apache2/certificados

b) Gerar uma chave privada que será utilizada para o certificado;

openssl genrsa -des3 -out nomedocertificado.key 204 8

Vai pedir para criar uma passphrase (senha). Para fins de entendimento, a senha será “teste” (A senha para o certificado sugere-se colocar uma senha forte com vários dígitos, caracteres especiais e números, a complexidade desta senha é que garantirá que as informações trafegadas não serão violadas). c) Gerar uma requisição de assinatura de certificado: openssl req -new -nodes -key nomedocertificado.key -out nomedocertificado.csr Enter pass phrase for nomedocertificado.key: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Dis tinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:BR State or Province Name (full name) [Some-State]:PAR ANA Locality Name (eg, city) []:Guarapuava Organization Name (eg, company) [Internet Widgits P ty Ltd]:Nome da Empresa Organizational Unit Name (eg, section) []:Departame nto de Informatica Common Name (eg, YOUR name) []:www1.dominio.com.br Email Address []:administrador@dominio.com.br Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:Empresa

d) Após a confirmação dos dados acima, é gerado na pasta um arquivo nomedocertificado.csr, o qual deve ser enviado para uma entidade certificadora assinar. A vantagem de assinar o certificado é que qualquer pessoa que acesse a aplicação não receberá a informação que o certificado é inválido, do contrário a informação de certificado inválido é mostrada e fica a critério dos usuários instalarem o certificado manualmente em seus computadores. e) Para teste, o certificado deverá ser auto-assinado openssl x509 -req -days 365 -in nomedocertificado.c sr -signkey nomedocertificado.key -out nomedocertificado.crt

f) Editar o arquivo /etc/sysconfig/apache2 Editar a seguinte linha e incluir ssl: APACHE_MODULES="authz_host actions alias auth_basic authz_groupfile authn_file authz_user autoindex cgi dir include log _config mime negotiation setenvif status userdir asis imagemap php5 authz_de fault ssl"

Editar a seguinte linha e incluir SSL: APACHE_SERVER_FLAGS="SSL"

g) Entrar no diretório /etc/apache2/vhosts.d e copiar o arquivo vhost-ssl.template: cp -p vhost-ssl.template nomedoservidor-ssl.conf

h) Editar o arquivo nomedoservidor-ssl.conf (para o teste, todo o diretorio /srv/www/htdocs está configurado para https) SSLCertificateFile /etc/apache2/certificados/nomedo certificado.crt SSLCertificateKeyFile /etc/apache2/certificados/nom edocertificado.key Substituir <VirtualHost_default_:443> por <VirtualH ost www1.dominio.com.br:443>

i) Configurar arquivo /etc/apache2/listen.conf comentando a linha “Listen X.X.X.X:80 ”. j) Configurar o firewall do servidor para permitir acesso via porta 443 (interno e externo) e porta 22 (interno) para administração k) Reiniciar o apache: /etc/init.d/apache2 restart

Vai pedir a passphrase (senha do certificado) l) Testar o acesso via browser (se o certificado não estiver assinado, o browser vai informar que o certificado não é confiável) https://www1.dominio.com.br

m) Para não pedir a passphrase no start do apache deve-se: cd /etc/apache2/certificados

Fazer backup do arquivo de chave privada: cp -p nomedocertificado.key nomedocertificado.key.b ackup

Embutir a passphrase no arquivo: openssl rsa -in nomedocertificado.key -out nomedoce rtificado.key.novo

Renomear o arquivo gerado: mv nomedocertificado.key.novo nomedocertificado.key

Reiniciar o apache: /etc/init.d/apache2 restart

Após estas alterações não vai pedir a passphrase (senha do certificado) n) Para continuar pedindo passphrase no Apache, será necessário aumentar o tempo de timeout da sua inicialização para que seja possível a digitação da senha. No arquivo /etc/sysconfig/apache2 APACHE_START_TIMEOUT=”10”

o) Se o certificado for assinado por uma CA autorizada, pode ser necessário importar no apache o caminho inteiro dos certificados. No caso de certificados da verisign (certisign) ir para o passo Q. Exemplo SERPRO: Fazer o download dos certificados intermediários e colocar no /etc/apache2/certificados: ICP-Brasil Autoridade Certificadora do SERPRO v1

Autoridade Certificadora do SERPROACF v1 cd /etc/apache2/certificados cat certificado.cer >> caminho.pem cat SERPROACFv1.cer >> caminho.pem cat SERPROv1.cer >> caminho.pem cat ICP-Brasil.cer >> caminho .pem

p) Ao receber o e-mail com o certificado digital, você deverá copiar o conteúdo existente desde a linha -----BEGIN CERTIFICATE----- até a linha -----END CERTIFICATE----- e salvá-lo em sua máquina .CRT. Não utilize o Microsoft Word ou outro programa de processamento de textos, pois eles podem acrescentar caracteres ocultos ao arquivo de texto. Salve o arquivo .CRT no diretório desejado. Por exemplo, /etc/apache2/certificados q) Editar o arquivo mv36-ssl.conf e incluir (No caso de certificados da verisign (certisign) não é necessário seguir este passo): SSLCertificateChainFile /etc/apache2/certificados/c aminho.pem

Para mais informações sobre certificado digital acesse: http://www.certisign.com.br/suporte/certificados-para-servidores-web/certificado-para-servidor-web-site-seguro/instalacao [13] É totalmente recomendado armazenar em local seguro um backup dos certificados, no caso de servidor virtual recomendado também manter um backup dos servidores após a realização de todas as configurações. 4. Conclusão É importante comentar que a necessidade inicial da empresa era apenas disponibilizar aos acionistas informações financeiras através da internet, mas tal serviço não poderia ser oferecido com segurança e a disponibilidade ideal na estrutura que existia. Para garantir o sucesso na implantação de um projeto de sistemas foi necessário realizar grandes investimentos na infra-estrutura da empresa. A experiência para implantação desde ambiente veio em parte do conhecimento adquirido ao longo de um ano e meio de especialização na área de Segurança de Redes e Sistemas, e também do conhecimento do negócio das pessoas da área de TI da empresa. A implantação de ferramentas de monitoramento como CACTI e NESUS foram fundamentais no sentido de identificar os problemas existentes no ambiente para que posteriormente fossem realizadas as adequações necessárias. Uma das principais alterações que era a separação das máquinas por público alvo e sua criticidade foi concluída em 30/06/2010 e as aplicações passaram a funcionar nas novas máquinas, após esta data não se registrou nenhuma interrupção nos serviços e nenhum problema foi registrado, o que era uma constante no ambiente antigo. Uma das lições que pode ser extraída deste artigo é que qualquer alteração por menor que seja em servidores deve ser estudada e planejada ao máximo. Quando houver necessidade de configuração de novos sistemas crie um ambiente para homologação da ferramenta, jamais configure o novo sistema junto com algum que já esteja em funcionamento. Os ganhos para a empresa foram significativos, pois já existe uma padronização de ferramentas e soluções que pode e devem ser continuados para novas funcionalidades ou sistemas. Os riscos de segurança foram reduzidos e o ambiente está controlado, existem pontos de melhoria que precisam ser melhorados, tendo em vista que a preocupação com assunto “Segurança da Informação” deve ser constante, e o que é muito seguro hoje, poderá ser uma vulnerabilidade amanhã.

5. Referências bibliográficas [1] Descrição do servidor HTTP Apache. URL=http://pt.wikipedia.org/wiki/Servidor_Apache (Acesso em 11/10/2010) [2] Descrição da linguagem PHP. URL=http://apostilas.fok.com.br/manual-do-php/introduction.php (Acesso em 11/10/2010) [3] Descrição do servidor Tomcat. URL=http://pt.wikipedia.org/wiki/Tomcat (Acesso em 16/10/2010) [4] Descrição de Zona Desmilitarizada. URL=http://pt.wikipedia.org/wiki/DMZ_(computação) (Acesso em 11/10/2010) [5] Diagrama de Zona Desmilitarizada. URL=http://upload.wikimedia.org/wikipedia/commons/1/17/Diagrama_DMZ.png (Acesso em 11/10/2010) [6] Descrição de NAT. URL=http://pt.wikipedia.org/wiki/NAT (Acesso em 11/10/2010) [7] Descrição de Samba Server. URL=http://pt.wikipedia.org/wiki/Samba_(servidor) (Acesso em 11/10/2010) [8] Descrição de SSH. URL=http://pt.wikipedia.org/wiki/SSH (Acesso em 11/10/2010) [9] Descrição de Firewall. URL=http://pt.wikipedia.org/wiki/Firewall (Acesso em 16/10/2010) [10] Descrição de IPS. URL=http://pt.wikipedia.org/wiki/Sistema_de_preven%C3%A7%C3%A3o_de_intrusos (Acesso em 16/10/2010) [11] Descrição de IDS. URL=http://pt.wikipedia.org/wiki/IDS (Acesso em 16/10/2010) [12] Descrição de Criptografia. URL=http://pt.wikipedia.org/wiki/HTTPS (Acesso em 16/10/2010) [13] Descrição de Certificado Digital. URL=http://www.certisign.com.br/suporte/certificados-para-servidores-web/certificado-para-servidor-web-site-seguro/instalacao (Acesso em 19/10/2010)