Planejamento e Implantao de Firewall

Andr Ruiz Renato R. Santana

Conectiva S.A. (http://www.conectiva.com.br) Suporte Rede Conectiva de Servios sup-rcs@conectiva.com.br

ndice
1. Objetivos da Soluo............................................................................................................................................................ 5 2. Caractersticas Tcnicas...................................................................................................................................................... 5 3. Clientes Potenciais ............................................................................................................................................................... 6 4. Cases e Cenrios Tpicos ..................................................................................................................................................... 7 5. Vantagens para o Cliente..................................................................................................................................................... 8 6. Operao e Administrao da Soluo .............................................................................................................................. 8 7. Atualizaes dos Sistemas ................................................................................................................................................... 8 8. Gerenciamento da Soluo.................................................................................................................................................. 9 9. Treinamento.......................................................................................................................................................................... 9 10. Solues Relacionadas ..................................................................................................................................................... 10 11. Metodologia de Implantao........................................................................................................................................... 11 12. Requisitos de Tempo e Recursos Humanos ................................................................................................................... 12 13. Anlise Tcnica................................................................................................................................................................. 12 14. Implantao ...................................................................................................................................................................... 14 15. Documentao .................................................................................................................................................................. 20 16. ANEXO 1 - Guidelines para estudo das necessidades do cliente................................................................................. 21 17. Referncias........................................................................................................................................................................ 23 Bibliograa de Referncia..................................................................................................................................................... 24

Informaes Gerais
Este documento descreve a soluo Planejamento e Implantao de Firewall, apresentando seus conceitos bsicos, objetivos, clientes potenciais, aspectos comerciais e aspectos tcnicos de planejamento e/ou implantao. Este documento teve base sobre uma variada fonte informaes. Dentre as fontes destacam-se artigos e o livro Firewall Design de D. Brent Chapman e Elizabeth D. Zwicky, alm do HOWTO de ltragem de pacotes para o kernel 2.4. Veja a seo de bibliograa para outras referncias detalhadas. Este documento pode ser encontrado online no site da Diretoria de Servios (http://dir-serv.conectiva) Comentrios sobre este documento devem ser enviados para a equipe de Suporte RCS (mailto:sup-rcs@conectiva.com.br). Este documento de uso interno da Conectiva S.A. (http://www.conectiva.com.br) e da Rede Conectiva de Servios (RCS). A equipe de Suporte RCS responsvel pelas atualizaes deste documento. As sugestes e crticas devem ser enviadas diretamente para a equipe de Suporte RCS (mailto:sup-rcs@conectiva.com.br).

1. Objetivos da Soluo
O Planejamento e Implantao de Firewall tem como objetivo aumentar a segurana de uma dada instituio que tenha conexes com redes consideradas inseguras, como por exemplo a Internet. A soluo de rewall usada para se criar uma barreira entre uma rede insegura (por exemplo, a Internet) e a rede local da empresa. Desta forma, no deixando passar o trfego indesejado de informaes e garantindo que certos servios ou dados sero acessados somente a partir da rede privativa e/ou por pessoas autorizadas. Isto feito com o estabelecimento de regras (ltros) colocados estrategicamente na mquina que ser usada como porta de sada/entrada para a(s) rede(s) insergura(s). Em casos onde necessrio oferecer servios para o pblico em geral (por exemplo, www), a soluo de rewall poder separar estes servios em uma outra rede, uma rea chamada de zona no militarizada (DMZ). Isto permitir um controle no sobre o acesso aos servios pblicos sem prejudicar a rede interna. Alm de proporcionar os ltros mencionados, a soluo tambm tem a funo de manter registro de eventuais tentativas de violao das regras de segurana j existentes. Diariamente enviado ao administrador do sistema um email contendo as estatsticas e registros de quaisquer violaes das regras estabelecidas. A anlise destas informaes ser de grande valia para o administrador. possvel a deteco em ante-mo de possveis tentativas de ataques em andamento e/ou eventuais problemas de trfego que possam existir.

2. Caractersticas Tcnicas
A soluo de rewall proposta aqui utiliza os recursos da srie 2.4 do kernel do linux, como ltro de pacotes, Stateful Packet Filtering (SPF) ou Connection Track, NAT e Mangle. Estes recursos permitem que se analise, altere e ltre cada pacote de rede em trnsito pela mquina do rewall e observar as conexes respecitivas aos mesmos, segundo a poltica de segurana da empresa. So criadas regras que denem o que deve acontecer com este pacote ou conexo, se devem ser aceitos, rejeitados ou redirecionados para outra mquina. Os recursos permitem ainda a criao de regras de ltragem muito mais simples e seguras que os rewalls tradicionais, minimizando a possibilidade de erros ou falhas.

Aos pacotes que no se encaixarem em nenhuma das regras de ltro, ser negada a passagem e um registro disso ser feito. O administrador ou operador da soluo receber diariamente, via email, um relatrio sobre as estatsticas e sobre os registros feitos pela soluo nas ltimas vinte e quatro horas. Alm disto, estes registros podem ser sempre vericados em tempo real atravs dos logs do sistema se assim for desejado. Em grande parte dos sistemas de fornecimento de acesso Internet h a necessidade do uso de proxies com cache. Isso mais verdadeiro para dois servios comumente conhecidos como HTTP e FTP. A soluo de rewall integra-se perfeitamente com o uso de proxies. A soluo pode garantir ainda que determinados servios s venham a ser utilizados atravs desse(s) proxy(ies) existente(s), por meio de redirecionamento forado. Quando a soluo de rewall utilizada em conjunto com a soluo de proxy (vide soluo 3.3. Planejamento e Implantao de Proxy WWW e FTP) cria-se um servio transparente e seguro. O resultado um poderoso sistema de acesso a Internet que simultaneamente pode proporcionar segurana, controle, superviso, alm de economizar banda do link. Nesta nova verso, possvel que o proxy que em outra maquina, mesmo transparente (usando Destination NAT). Em casos onde exista a zona desmilitarizada (DMZ), a soluo reduzir ao mnimo necessrio o uxo de dados entre a rede interna e as mquinas dessa zona considerada de risco. A DMZ normalmente contm servios disponibilizados para a Internet, de onde vem os riscos. Os limites da soluo em termos de nmero de usurios simultneos esto diretamente ligados aos recursos de hardware e do sistema operacional utilizados. Utilizando o equipamento recomendado aqui, a soluo suportar at 1500 estaes de trabalho. Veja a seo de anlise tcnica para maiores detalhes sobre os requisitos da soluo. A gura abaixo ilustra um tipo arquitetura, que de uma forma genrica, supre todas as necessidades na maioria dos casos.

Resumo das caractersticas:

SPF: Filtragem avanada de pacotes usando Stateful Packet Filtering, Isto se traduz em regras de ltragem mais simples e maior segurana. Relatrios: Relatrios dirios com as violaes das regras de ltragem e estatsticas de uso do dia anterior. NAT: Recurso de Network Address Translation completo, tanto para origem (source NAT) como para destino (destination NAT), podendo ser usado para conectar uma rede inteira Internet usando apenas um endereo IP, bem como prover redirecionamentos transparentes para servios na DMZ e proxies.

3. Clientes Potenciais
A soluo de rewall destina-se ao uso em qualquer instituio que tenha ligaes de rede TCP/IP e que tenha a necessidade de estabelecer ltros de segurana nessas redes. So candidatos aquisio da soluo:

Uma empresa que tenha uma conexo com um distribuidor. Muitas empresas optam em ter um link direto com determinado fornecedor, visando maior agilidade e maior controle quanto a disponibilidade dos produtos. Na maioria desses casos, as empresas que fazem uso deste tipo de servio so concorrentes entre si. Considerando que as empresas concorrentes esto ligadas a rede do mesmo fornecedor, ento, essas conexes trazem riscos s empresas envolvidas. Ser necessrio um rewall entre a rede do fornecedor e a rede da empresa que utiliza o servio, visando ltrar o trfego entre essas duas 6

pontas.

Empresas concorrentes que estejam trabalhando num projeto em comum. Nesses casos, onde as empresas envolvidas precisam ter algum tipo de interligao de redes, se faz necessrio a existncia de um mecanismo que proteo. A empresa precisar se garantir de que no haver nenhum uxo de informao no relacionada com o dito projeto em comum. Universidades, faculdades e escolas. Neste tipo de ambiente, as mquinas de laboratrios, salas de aula e dormitrios so consideradas mquinas inseguras. O uxo de informaes vindo ou indo para essas mquinas precisa ser ltrado e controlado. Qualquer entidade que tenha uma conexo com a Internet. Onde houver um link com a Internet haver o risco do uxo indesejado de informaes/conexes. Este perl, embora de uma forma generalizada, abrange a maioria dos possveis clientes. Ou seja, uma empresa de pequeno ou mdio porte que possui um link dedicado com a Internet, para fornecer acesso seus funcionrios e disponibilizar seu website. Este perl de cliente cresce a cada dia e o principal alvo para a soluo. Empresa que utilize um rewall comercial cujo custo com licenas seja muito alto. tpico da licena de rewalls comerciais ser limitada por nmero de conexes simultneas ou endereos IP. Este tipo de limitao inexistente nesta soluo de rewall. Tambm bastante provvel que esse rewall comercial utilize SPF, algo que agora podemos oferecer.

4. Cases e Cenrios Tpicos

De uma forma geral, qualquer ambiente dotado de uma nica conexo com a Internet poder ser cenrio para instalao do a soluo de rewall, como j dito. No entanto, vamos nos conter com uma congurao constituda de uma rede interna, uma zona DMZ e uma conexo com a Internet. Vamos supor uma empresa de pequeno/mdio porte possuindo poucas estaes de trabalho em sua rede interna. A empresa tambm estar hospedando seu website na prpria sede, o que vai exigir a presena de no mnimo um servidor web (WWW), um servidor de nomes (DNS), um servidor de correio eletrnico (SMTP/POP3). Ela possui instalado um link dedicado de 64Kbps com a Internet. Via este link a empresa pretende disponibilizar o seu servidor web, receber/enviar e-mails e prover acesso Internet para as mquinas da rede interna. Uma vez que a disponibilizao de servios tais como servidor de nomes (DNS), web (WWW) e email (SMTP) trazem consigo riscos segurana da rede interna, esses servios caro numa rea denominada DMZ, quase isolada da rede interna. Como o uxo de informaes de todos esses servios ser pequeno (no caso desta empresa), tudo ser colocado num nico servidor. Ento, at agora, temos as mquinas na rede interna e uma mquina servidora na zona DMZ. Quando a suposta empresa contratou o link, foi instalado um roteador o qual est conectado a um modem, o qual faz o link para a Internet. Embora o roteador faa parte da rede e ele seja a porta de sada para Internet, ele no includo na rea a ser protegida, por razes bvias. A nica mquina que ter contato direto com ele ser a mquina que hospedar o rewall. Ento, para a rede interna e para a DMZ, o rewall ser o ponto de sada para a Internet (ou o seu gateway). Conforme a ilustrao seguir, podemos visualizar novamente as mquinas da rede interna, a mquina do rewall (no centro), a mquina da DMZ e o roteador externo. Note que cada um dos 3 segmentos esto conectados mquina do rewall via adaptadores fsicos de rede distintos.

A Conectiva tem tido importante atuao no mercado corporativo, e uma lista de cases sobre esta e outras solues pode ser 7

encontrada no pgina de cases (http://www.conectiva.com.br/cases/) da Conectiva. Seguindo a idia da necessidade de existir uma relao de todos os cases Conectiva, imprescindvel que propostas comerciais e contratos contenham os termos de Autorizao para Divulgao do Case, bem como o Certicado de Qualidade na Prestao de Servios. Estes documentos so essenciais como argumentos de venda em negociaes com clientes.

5. Vantagens para o Cliente

A soluo que a Conectiva oferece totalmente baseada em produtos free-software e de cdigo aberto, sem abrir mo da excelncia em qualidade e segurana. A vantagem disso o fato de que milhes de programadores e tcnicos tem acesso ao cdigo-fonte do produto. Isso tende a garantir que qualquer eventual problema de segurana com os softwares utilizados, seja descoberto e resolvido muito rapidamente. Esse diferencial faz com que a empresa receba um produto amplamente utilizado e atualizado. Alm de todas as vantagens acima, pode se dizer que a soluo de rewall que a Conectiva oferece tem um custo mais baixo e ao mesmo tempo tende a ser mais eciente e livre de bugs do que as solues comerciais. O acrscimo da capacidade de fazer ltragem de pacotes baseada em estado de conexes (SPF) um grande ganho em termos de segurana e simplicidade de administrao, e no h as limitaes impostas pelas licenas dos produtos comerciais, ou seja, no haver custo adicional em termos de licenas para o cliente quando a sua rede crescer. Uma soluo de rewall baseada em linux extremamente eciente, pois da natureza deste sistema ser modular. Ou seja, apenas instalado na mquina o que efetivamente utilizado, o que garante a mxima ecincia. No necessria a instalao de ambiente grco, a administrao remota por natureza e as regras podem ser criadas em outra mquina, com a ajuda de clientes grcos se desejado. A mquina do rewall possui apenas o que ela necessita para cumprir sua obrigao e ela se dedica 100% do tempo a isso.

6. Operao e Administrao da Soluo

A operao da soluo de rewall deve ser feita (at o momento) diretamente com a ferramenta iptables (substituto do ipchains) e o auxlio de scripts. O programa de administrao Linuxconf, na sua verso atual (1.25r3), ainda no trabalha com os recursos mais avanados disponveis no novo cdigo de ltragem de pacotes do kernel 2.4 e portanto no deve (ou pode) ser usado. Esta soluo fornece um script bsico de ltragem de pacotes utilizando os recursos novos do kernel 2.4. O script em questo j vem com as regras mais comuns para uma situao de uma rewall com trs interfaces de rede, sendo uma interna, uma externa e uma DMZ. O tcnico poder recorrer como documentao deste novo formato, alm deste documento, pgina de manual do comando iptables, que pode ser acessada com o comando "man iptables". Ela est em portugus e explica em detalhes cada opo do comando. Isto ser de grande valia para o administrador, j que atualmente a soluo deve ser operada diretamente atravs de modicaes no script do rewall.

7. Atualizaes dos Sistemas

A soluo, como j dito, baseada no recurso de ltragem de pacotes o qual est embutido no kernel. O recurso de ltro de pacotes dependente de uma srie de sub-mdulos IP do kernel. As atualizaes iro certamente implicar em atualizao do kernel e das ferramentas de administrao da soluo ou mesmo a completa reinstalao do sistema operacional. Devido ao gnero da soluo (segurana), qualquer atualizao que eventualmente se faa necessria deve ser considerada emergencial e precisar ser aplicada o mais rpido possvel. Negligncias nesse sentido podero estar comprometendo o objetivo da soluo, que o de garantir a segurana da empresa.

8. Gerenciamento da Soluo
O processo de gerenciamento est diretamente ligado aos registros feitos pela prpria soluo no decorrer de seu uso. Com base nesses registros o administrador poder ser advertido sobre tentativas de invases e/ou eventual necessidade de quaisquer mudanas na poltica de segurana da empresa. Am de facilitar o gerenciamento, a soluo encaminha diariamente ao administrador do sistema um email com as advertncias e estatsticas do rewall. Isso evita a necessidade de ltragem manual dos logs. A soluo deve ser complementada com outra soluo de monitoramento. A segurana e todos os outros servios relacionados Internet estaro dependentes da mquina do rewall. Com base nisso, de extrema importncia um monitorimento completo de todos os recursos desta mquina. Gatilhos emergenciais devero ser instalados de forma a avisar um tcnico de prontido sobre qualquer problema com o sistema ou tentativas de invases em andamento (soluo de gerenciamento de redes, 5.2). Tambm recomendada a instalao de uma soluo de IDS (Sistema de Deteco de Intruso) para acompanhar esta soluo. Considerando que os logs so o centro do gerenciamento da soluo, recomendado se fazer os registros em um servidor de log remoto. Isso d um certo alvio mquina do rewall e garante maior segurana ao servio de log. Mais informaes sobre isto podem ser obtidas no manual do syslog.

9. Treinamento
Um tcnico de nvel avanado necessrio para operar a soluo. O tcnico dever ter, no mnimo, conhecimentos bsicos sobre roteamento no Linux, noes bsicas sobre sockets e conhecimentos em segurana de redes, alm de estar familiarizado com a ferramenta iptables e a nova estrutura de ltragem de pacotes do kernel 2.4. Esta parte muito, muito importante. Houveram mudanas drsticas na forma de ltragem de pacotes entre o kernel 2.2 e o kernel 2.4, e necessrio que o tcnico esteja familiarizado com este novo formato. Para garantir a boa administrao da soluo, uso correto dos seus recursos e procedncia adequada em eventuais casos de emergncia, o tcnico designado pelo cliente dever ter tambm conhecimentos avanados de segurana. Caso o tcnico designado no tenha os conhecimentos em segurana de redes necessrios, o mesmo dever ser submetido ao treinamento Servios de Rede e Segurana, dado pela Conectiva. O objetivo geral passar ao tcnico designado conhecimentos avanados sobre segurana de redes. Alm de dar a aptido 9

necessria para a administrao da soluo, o curso ir prepar-lo quanto s tcnicas de invases mais utilizadas, quanto aos cuidados necessrios com os servidores disponibilizados na Internet, quanto as ferramentas de segurana disponveis e noes sobre criptograa e autenticao. Veja o Treinamento em Segurana (http://treinamento.conectiva/prossional/seguranca/rewall/index.html) que a Conectiva oferece.

10. Solues Relacionadas

Para um melhor aproveitamento do rewall e para aumentar ainda mais a sua ecincia, recomenda-se o uso de pelo menos duas outras solues em conjunto com a mesma:

RCS-SOL-1.1. Instalao do Servidor Conectiva Linux Base do sistema operacional. A soluo de rewall contempla apenas as modicaes no sistema para que sirva como rewall. necessrio que o sistema j esteja instalado, e esta soluo cuida disso.

RCS-SOL-5.2. Planejamento e Implantao de Gerenciamento de Redes Planejamento e Implantao de Monitoramento de Redes. Conforme visto na seo de gerenciamento, a soluo torna-se muito mais poderosa quando adicionado a ela um sistema de monitoramento constante. A soluo de monitoramento, alm de manter o administrador informado sobre as condies da mquina que hospeda o rewall, poder alert-lo sobre eventuais tentativas de invases e/ou falhas no sistema.

RCS-SOL-1.4. Implantao do Servio de Resoluo de Nomes DNS Esta soluo bsica em quase todos os projetos e clientes. Ela no necessria diretamente pelo rewall, mas se o rewall existe para proteger uma rede de computadores, que por sua vez precisa do DNS.

RCS-SOL-5.4. Planejamento e Auditoria de Segurana em Sistemas de Computao (IDS) A soluo de IDS importantssima em conjunto com esta. A soluo de rewall tima em realizar a segurana (ltrar pacotes, etc.), mas na rea de gerao de relatrios no chega aos ps daquela. Sempre que possvel o cliente deve considerar fortemente adquirir ambas (apesar de no ser abosultamente necessrio).

RCS-SOL-2.3. Planejamento e Implantao de VPN VPNs servem para interligar intranets atravs de redes pblicas ou consideradas inseguras e manter sua privacidade atravs de criptograa. Para maiores informaes consulte a soluo especca. As VPNs so em quase a sua totalidade instaladas na mesma mquina do rewall, para facilitar e centralizar a administrao. Estas duas solues casam perfeitamente.

RCS-SOL-3.3. Planejamento e Implantao de Proxy WWW e FTP Nos casos em que o cliente tenha um grau elevado de uso dos servios WWW e/ou necessite de um controle rigoroso quanto ao acesso esses servios por parte da rede interna, ento, ele tambm poder fazer uso da soluo de proxy com cache. Alm de aumentar a perfomance de servios WWW e FTP essa soluo tambm garante segurana e controle minucioso sobre o uso desses servios. No caso prtico de que o cliente tenha mais do que 15 estaes de trabalho na rede interna e um link com a Internet igual ou inferior a 64Kbps, bem possvel que ele tenha a necessidade da soluo de proxy.

10

RCS-SOL-4.2. Planejamento e Implantao de Servios com Alta Disponibilidade A soluo de rewall pode ter sua disponibilidade padro melhorada com o auxlio da soluo de Alta Disponibilidade da Conectiva. Veja no captulo especco as particularidades desta soluo em relao alta disponibilidade.

11. Metodologia de Implantao

Os seguintes passos so necessrios para a implantao da soluo: 1. Levantamento sobre o endereamento de todas as mquinas que estaro envolvidades com a soluo de uma ou outra maneira, a saber: o roteador externo, as mquinas da rede interna e a DMZ. 2. Anlise sobre os servios da DMZ. Neste ponto, voc dever saber do cliente se ele est hospedando ou ir hospedar o prprio domnio, website, servidor de email, DNS, etc. Identique quais sero os IPs e o mascaramento dessas mquinas da DMZ. 3. Levantamento do nmero de adaptadores de rede necessrios e instalao dos mesmos. Este passo se refere instalao fsica das placas de rede. Note que sero necessrios trs adaptadores. Lembre-se de instalar os adapatadores necessrios antes da instalao do sistema operacional. Aquela ordem agilizar esta tarefa. 4. Instalao do sistema operacional. Esse passo se refere ao servio RCS-SOL-1.1 Instalao do Servidor Conectiva Linux. Contudo, pelo fato de que a mquina ser utilizada para hospedar a soluo, somente devero ser instalados os pacotes bsicos, utilizando-se de um perl que melhor se encaixe com rewall. Somente instale os pacotes que sero realmente utilizados! Por exemplo, nada de compilador C, pacotes de documentao, HOWTOs, daemons desnecessrios, etc. 5. Congurao dos parmetros da rede. Nesta etapa, faz-se a congurao lgica das interfaces de rede, designando-as endereos IP, de acordo com as subredes com as quais elas estaro diretamente conectadas. 6. Segurana do prprio rewall. Logo aps a instalao do sistema operacional, e antes de conectar a mquina alguma rede, inicia-se o processo de segurana da prpria mquina do rewall. Aqui se fazem as tarefas tais como garantir que o super usurio s far logons via console, desabilitar conexes remotas no X (/root/.Xauthority), desabilitar os servios no utilizados do inetd e desabilitar scripts init de servios no requeridos. Tambm dever ser feita uma checagem de todos os pacotes instalados, um por um, para ver se sero realmente necessrios e remover os supruos. 7. Instalao dos pacotes adicionais. Aqui vericamos e instalamos os pacotes necessrios para a soluo. Veja a lista de requisitos de software. Tambm neste momento que devemos vericar se h alguma atualizao de segurana disponvel para algum dos pacotes que for utilizado nesta soluo. 8. Levantamento dos servios que tero passagem pelo rewall. Listar todos os servios que podero passar livremente pelo rewall considerando-se a origem e destino dos pacotes, onde origem ou destino poder ser a rede interna, a Internet ou a DMZ. Fazer um planejamento das regras necessrias segundo a poltica de segurana desejada pelo cliente. 9. Insero das regras. Inserir as regras julgadas necessrias no item anterior, via ferramenta adequada. 10. Testes. Aps a implantao das regras, faz-se testes de acesso do maior nmero possvel de pontas envolvidas nas regras. Atravs do uso de log possvel identicar-se quaisquer ajustes necessrios que no estejam bem visveis na prtica. muito importante que tambm sejam feitos testes a partir de endereos externos, ou seja, no pertencentes rede do 11

cliente. Apenas esta a verdadeira viso externa dessa rede, assim como o mundo externo a enxerga. 11. Documentao da Implantao. Aps a concluso dos passos anteriores, necessrio que tudo seja documentado. Na seo de documentao voc encontra um formulrio especco, o qual abrange a maioria dos itens que precisam ser documentados. Com estes registros em mos, as coisas sero mais fceis para o prprio tcnico, quando em visitas futuras ao cliente.

12. Requisitos de Tempo e Recursos Humanos

Tabela 1. Cronograma de Implementao da soluo

Tarefa Levantamentos de endereos/mscaras das redes envolvidas Anlise sobre os servios da DMZ. Levantamento do nmero e instalao dos adaptadores de rede Instalao do sistema operacional Congurao dos parmetros da rede Vericao/instalao de pacotes Levantamento dos servios que tero passagem pelo rewal Insero das regras

Tempo 30 minutos 20 minutos 30 minutos 1 hora 40 minutos 30 minutos 1 hora 2 horas

Recu

Con

Con

Tcn

Tcn

Tcn

Tcn

Con

Tcn

13. Anlise Tcnica

Nesta seo vamos levantar as questes tcnicas que precisam car claras antes da implantao. Veremos quais os requisitos da soluo e o que precisa ser analisado. Esta anlise ir facilitar e fazer o prximo passo muito mais eciente.

13.1. Levantamento de Pr-Requisitos

seguir temos uma lista dos itens necessrios para a instalao da soluo. Antes de dar o primeiro passo no incio da instalao verique bem cada um desses itens:

12

Hardware. As caractersticas da mquina a ser usada para hospedar o rewall podero variar de acordo com o volume de trfego que ter passagem pelo rewall. Uma forma de prever-se o hardware necessrio levantar o nmero de usurios da rede interna e qual a frequncia de uso dos servios da DMZ. O mnimo recomendado um Pentium 200Mhz, 64Mb RAM, 4 Gb de HD. Lembre-se que bom utilizar um hardware com recursos alm do necessrio, prevendo-se possveis expanses no uso da soluo. Adaptadores de rede. Embora os adaptadores estejam dentro dos requisitos de hardware, eles dependem de outro fator que a arquitetura a ser usada. Basicamente, a existncia ou no da zona desmilitarizada. Com a DMZ, teremos trs barramentos, logo trs adaptadores. E sem a DMZ s iremos utilizar dois. Escolha prioritariamente adaptadores de rede que tenham alto desempenho no linux. Algumas sugestes esto na tabela de requisitos de hardware. Cabos e conexes de rede. Verique cada um dos pontos que faro conexo com o rewall. Verique se para cada segmento de rede os cabos esto de acordo. Por exemplo, se o cabo que ligar o rewall ao roteador externo dever ser do tipo crossover. O mesmo poder ser diferente para a rede interna e para a DMZ. Aterramento e no-break. A mquina que hospedar o rewall ser constantemente utilizada e provavelmente car no ar 24 horas por dia. Com o uso de aterramento e no-break nesta mquina, as chances de indisponibilidades sero menores e alm disso podero aumentar a vida do equipamento. recomendado que a autonomia do no-break seja de pelo menos 4 horas. O aterramento precisa ser feito por um eletricista capacitado, seguindo-se os padres eltricos adequados. Software. Os seguintes so os requisitos de software:

CDs do Conectiva Linux 7.0 ou superior O pacote iptables. Esta a ferramenta backend utilizada para operao do rewall. Pacote cftk. Este pacote constitudo por um script init, um script analisador de logs e um script shell com regras prdenidas. Ele agiliza bastante a construo das regras necessrias pelo fato de j trazer prontas aquelas que so mais utilizadas. O pacote encontrado como anexo da soluo. Veja a seo de referncias, no nal deste documento. Pacote nmap. O nmap ser uma ferramenta de teste importante. Ela poder ajudar tanto no levantamento de servios existentes quanto na procura de vulnerabilidades aps a instalao.

Recursos humanos. necessrio no mnimo uma pessoa bem capacitada para fazer a implantao da soluo. O perl da pessoa a ser designada dever ser no mnimo a de um tcnico pleno. Este tcnico dever conhecer na teoria e na prtica o funcionamento de redes TCP/IP. Dever conhecer os protocolos bsicos, ter familiaridade com os conceitos de socket, portas TCP, uxo dos pacotes de rede no kernel 2.4 e endereamento IP. O tcnico ou consultor dever ter um bom nvel de conhecimento sobre segurana de redes; tcnicas de ataque, IP spoong, etc. Acesso s informaes necessrias. Devido ao fato de que o rewall envolver mudanas nos parmetros de toda a rede, se o cliente j tiver sua rede em funcionamento, possivelmente ser necessrio que implementao seja feita fora do horrio de expediente da empresa. Garanta que no momento da implementao voc ter em mos as informaes sobre a poltica de segurana da empresa, ou seja, quais servios a rede interna pode utilizar da Internet ou da DMZ, quais servios da DMZ estaro disponveis Internet, etc. Voc precisa ter uma lista de todas as mquinas da(s) rede(s) do cliente que faro uso ou que estaro num dos barramentos do rewall. Obtenha tambm as senhas de cada mquina que voc precisar efetuar logins (servidores, roteadores, etc). Informaes incompletas podero fazer com que voc tenha que interromper o trabalho e voltar outro dia.

13

13.2. Atividades de Planejamento

Antes de iniciar a implantao propriaments dita, necessria a anlise sobre sobre alguns tens importantes. So eles:

Poltica de segurana desejada. Umas das coisas que voc deve ter em mos, a poltica de segurana do cliente, de uma forma clara e completa. A poltica ser formada pela lista de servios que a empresa vai conceder mais a lista de servios que devero ser bloqueados. Naturalmente, o ideal a se fazer, assumir que todos os servios sero bloqueados, somente sero liberados aqueles que o cliente desejar como tal. Infelizemente comum que essa poltica ainda no exista e que seja criada exatamente no momento da instalao do rewall. Se esse for o caso, esta poltica de segurana "recm-criada" deve ser anexada ao relatrio de ps-instalao que tambm ser assinado pelo cliente.

Servios de risco. Alguns tipos de servios apresentam mais riscos para todo o sistema do que outros. Desse modo, em alguns casos ser necessria alguma mudana na utilizao de certos servios. O servio de DNS merece destaque, sendo que hoje em dia ele o mais explorado para invases. Procure saber se o servidor DNS que existe ou ser instalado est de acordo com os padres de segurana recomendados. Veja as recomendaes da soluo 1.4. - Implantao do Servio de Resoluo de Nomes DNS. Redes/mquinas existentes. Faa um levantamento dos dados de todas as subredes e seus dados que existam no sistema do cliente. Levante dados como os endereos IPs, mscaras, DNS e rota padro. Faa um desenho da topologia existente. O utilitrio nmap poder se de grande ajuda quando vericando as maquinas/servios existentes. Por exemplo, um nmap -sP 192.168.0.0/24 poder levantar em segundos as mquinas que esto ligadas na rede. Tambm bastante provvel que sejam encontrados servios desnecessrios nesta etapa rodando em outra mquinas da DMZ ou mesmo da rede interna. Deve-se tomar o cuidado de no se desviar muito do trabalho que se tem pela frente, que instalar o rewall, mas pode ser necessrio desativar servios em outras mquinas para completar a segurana da rede. Tambm bastante comum se encontrar redes "bagunadas", que s funcionaram at o momento por pura sorte. Este pode ser o momento de oferecer mais um servio para o cliente.

Mquinas especiais. Procure saber se haver qualquer mquina com menos restries de acesso do que outras. Liste os servios que estas mquinas podero acessar e que no sero cobertos pelas regras destinadas as redes as quais esta(s) mquina(s) pertencem.

14. Implantao
Aqui inicia-se o processo de instalao da soluo. Esse processo comea com uma preparao do ambiente seguido da insero das regras propriamente ditas. A preparao consiste na instalao fsica das das placas de rede, instalao do Conectiva Linux, congurao e certicao de segurana da prpria mquina do rewall. Para inserir as regras podemos utilizar o script cftk, que por sua vez faz uso da ferramenta iptables. O cftk um conjunto de regras pr-fabricadas que so inseridas atravs de parmetros variveis. Note porm que no basta simplesmente rodar o script, ele precisa ser adaptado para cada situao particular! As regras de rewall que iro compor a poltica de segurana sendo implantada dependero bastante da congurao que o 14

cliente possui. Por este motivo, quaisquer regras sugeridas aqui tero que ser modicadas de modo a se encaixarem com o sistema do cliente. O pacote cftk j traz regras pr-denidas que se adaptam a sistemas que utilizam ou no a DMZ, mas o tcnico instalador que possui a palavra nal.

14.1. Procedimentos de Instalao e Congurao.

Instalao fsica das placas de rede. Antes de iniciar o procedimento de instalao do sistema operacional recomendado instalar-se sicamente as placas de rede. Isso poder facilitar as coisas para os prximos passos. Instalao do sistema operacional. Instale o Conectiva Linux 7.0 escolhendo o perl Roteador/Firewall ou Servidor bsico e optando por um kernel da srie 2.4 ao invs da verso 2.2. Veja a documentao da soluo 1.1. Instalao do Servidor Conectiva Linux para mais informaes. Aps a instalao certique-se de que no que instalada nenhuma ferramenta de desenvolvimento e nem pacotes de servios desnecessrios como WWW, FTP, documentao, etc. A mquina do rewall servir exclusivamente como um roteador interno e ltro de pacotes, nem devendo ter ambiente grco instalado. Recomenda-se que sejam listados todos os pacotes instalados (rpm -qa) para vericar se so realmente necessrios. Lembre-se que a instalao do sistema operacional constitui uma soluo independente, e deve ser considerada como tal. O ato de instalar o sistema operacional, aqui solicitado, na verdade sugere que o cliente antes compre a soluo de instalao do sistema operacional (1.1) e depois a de rewall. Instalao dos pacotes requeridos. Aqui instalamos todos os pacotes que podero ser utilizados como ferramentas de operao/implantao da soluo. Primeiro instale o pacote iptables: [root@firewall RPMS]# rpm -ivh iptables*.i386.rpm iptables ################################################## [root@firewall RPMS]#

Agora o pacote cftk. Note que este pacote no se encontra nas verses 7.0 ou anteriores do Conectiva Linux. O pacote poder ser obtido como anexo da soluo. Veja a seo de referncias, no nal deste documento. [root@firewall RPMS]# rpm -ivh cftk-*.noarch.rpm cftk ################################################## [root@firewall RPMS]#

Por favor, tenha certeza de que ler o arquivo LEIAME contido no diretrio de documentos, em /usr/share/doc/cftk*. Ele contm informaes importantes sobre o pacote e seus utilitrios. Nmap. Para levantamento de informaes sobre mquinas da rede, servios e testes ps-implantao. [root@firewall RPMS]# rpm -ivh nmap-*.i386.rpm 15

nmap [root@firewall RPMS]#

##################################################

No Conectiva Linux 7.0 em diante, a instalao dos pacotes tambm pode ser feita por meio do utilitrio apt-get. Veja: Para fazer uma atualizao da lista de pacotes disponveis faa um: [root@firewall RPMS]# apt-get update

Para instalar o pacote iptables: [root@firewall RPMS]# apt-get install iptables

Procedimentos para garantir a segurana da mquina do rewall. Sigas os passos abaixo: Verique o contedo do arquivo /etc/securetty. Este arquivo dever conter somente os teminais de console (tty1, tty2, ...). Por padro, as verses recentes do CL j vem congurados dessa forma. [root@firewall /root]# cat /etc/securetty tty1 tty2 tty3 tty4 tty5 tty6

Desabilite a possibilidade de conexes remotas no X. Remova o arquivo /root/.Xauthority. Em realidade, o X Window System no dever ser instalado na mquina do rewall. Ele no ser necessrio. [root@firewall /root]# rm /root/.Xauthority

Execute o ntsysv e desabilite a iniciliazao de todos os servios exceto: syslogd, random, network, linuxconf-setup, crond, cftk e keytable. Parmetros de segurana do kernel. As verses mais novas do kernel possuem parmetros de segurana que merecem especial ateno. No Conectiva Linux 7.0 elas podem ser editadas/visualizadas no arquivo /etc/sysctl.conf. O arquivo j 16

traz as variveis de forma a otimizar a segurana. Os parmetros so inseridos no kernel automaticamente durante o incio do sistema. Se voc zer alguma alterao, use a seguinte linha de comando para reinserir os parmetros no kernel: [root@firewall /root]# sysctl -p /etc/sysctl.conf

Os itens importantes do arquivo esto a seguir. No necessrio apagar tudo o que j est l, apenas conra se as variveis listadas aqui tem os valores corretos, caso contrrio faa os ajustes. net.ipv4.ip_forward = 1 net.ipv4.conf.all.rp_filter = 1 net.ipv4.ip_always_defrag = 0 net.ipv4.conf.all.log_martians = 1 net.ipv4.ip_dynaddr = 1 net.ipv4.icmp_echo_ignore_broadcasts = 1 net.ipv4.conf.all.accept_source_route = 0 net.ipv4.icmp_echo_ignore_all = 0 net.ipv4.icmp_echoreply_rate = 200 net.ipv4.icmp_paramprob_rate = 200 net.ipv4.icmp_timeexceed_rate = 200 net.ipv4.icmp_destunreach_rate = 200 net.ipv4.tcp_syncookies = 1 net.ipv4.conf.all.accept_redirects = 0

Congure as interfaces de rede. Usando o Linuxconf, congure os parmetros de rede necessrios para cada uma das interfaces: [root@fierewall /root] netconf

Evite ao mximo conectar esta mquina internet enquanto as regras de ltragem no estiverem prontas ou pelo menos razoavelmente seguras. A internet muito grande e est cheia de gente de frias sem nada mais importante para fazer, portanto todo cuidado pouco. V em "nome da mquina e dispositivos de rede". Selecione como ativo o nmero de interfaces necessrias, preenchendo os campos como endereo IP e mscara de acordo com os dados levantados na seo de anlise tcnica. No esquea de mencionar o mdulo do kernel correto para cada interface. Saia do Linuxconf aplicando as mudanas.

Com o comando ifcong verique se as interfaces esto ativas. Faa um ping em pelo menos um IP de cada um dos barramentos de rede envolvidos.

17

[root@firewall /root]# ping 192.168.0.2 PING 192.168.0.2 (192.168.0.2): 56 data bytes 64 bytes from 192.168.0.2: icmp_seq=0 ttl=255 time=0.3 ms 64 bytes from 192.168.0.2: icmp_seq=1 ttl=255 time=0.2 ms 64 bytes from 192.168.0.2: icmp_seq=2 ttl=255 time=0.3 ms -- 192.168.0.2 ping statistics -3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.2/0.2/0.3 ms

Nota: se a mquina alvo do ping for um CL, normal que passe a ignorar os pings recebidos a partir de um certo nmero. Este um dos parmetros congurados no arquivo /etc/sysctl.conf. Se algo sair errado, verique novamente os mdulos necessrios foram detectados e ativados, se a placa de rede suportada, se no h um conito nos recursos de hardware, etc.

Insero/edio das regras. Uma vez que a rede j esteja no ar e a mquina do rewall j esteja sendo utilizada como rota padro na DMZ e na rede interna, ento j hora de inserirmos as regras. Usando o ipchains/cftk. Edite o script /usr/bin/cftk e modique as variveis que esto logo no incio: (...) IP_int=192.168.0.1 IP_ext=192.168.0.1 IP_dmz=192.168.1.6 NET_int=192.168.0.0/24 NET_dmz=192.168.5.0/24 IF_int=eth0 IF_ext=eth2 IF_dmz=eth1 (...)

Essas variveis sero substitudas ao longo do script de forma a facilitar a administrao das regras. Faa uso destas variveis quando inserindo novas regras. No use "/32" quando for apenas um IP. Veja a funo de cada uma delas: 1. As variveis IP_int, IP_ext e IP_dmz devero conter os endereos IP usados nas interfaces que conectam a mquina s redes interna, externa e dmz, respectivamente. 2. NET_int e NET_dmz se referem aos endereos/mscaras das redes interna e dmz, respectivamente. O prximo passo remover do script as referncias aos servios que no sero disponibilizados na DMZ e os que a rede interna no poder acessar. Verique mais de uma vez se as regras que restaram no script corresponde quelas da poltica de segurana levantada anteriormente. Tambm ser necessrio acrescentar regras no script, j que ele no pode prever 18

todas as situaes possveis. Aps todas modicaes serem feitas no script, use o script init do cftk para inserir/reinserir as regras no sistema: [root@firewall root]# service cftk start Configurando regras do firewall:

OK

Note que isto no precisa ser feito cada inicializao, o script init automaticamente ativa o servio na ordem adequada. Edite o script cftkwatcher e edite as duas variveis que esto logo no comeo, conforme mostrado seguir: (...) sysadmin_mail="root@localhost" CC= (...)

sysadmin_mail Dever conter o email do administrador do sistema, para onde sero enviados as advertncias e as estatsticas dos logs do rewall. CC Esta varivel poder, opcionalmente, conter um email secundrio para onde ser enviada uma cpia carbono do contedo enviado ao email acima. O cftkwatcher ser executado pelo cron todas as noites, analisando os logs sempre do dia anterior.

14.2. Testes Ps-Instalao

Aps a implantao, precisamos seguir alguns procedimentos para garantir que tudo esteja de acordo com o desejado inicialmente.

Portas abertas na mquina do rewall. Um fator que se deve ter sempre em mente a segurana da prpria mquina do rewall. recomendado que no se tenha nenhum servio em escuta na interface da DMZ ou da rede externa. Por meio do comando netstat -ln verique se algum servio est em escuta, atentando para qual(ais) interface(s) o servio est anexado. Note que se um servio estiver em escuta no endereo 0.0.0.0 isto signica que uma conexo poderia ser estabelecida a partir de qualquer uma das redes as quais a mquina est conectada sicamente. No deixe nenhum servio desnecessrio em escuta na mquina do rewall. Alguns servios, como por exemplo ssh, podem ser congurados para s escutar em uma certa interface de rede. Use este recurso. Continuando no exemplo do ssh, a congurao dada pela diretiva Listen do arquivo de congurao do servidor. O padro "0.0.0.0", o que indica que ele deve escutar em todas as interfaces. Basta colocar ali o endereo IP da interface interna para que ele passe a escutar somente nesta interface. Testes de acesso. A partir de uma ou mais mquinas da rede interna, faa acesso aos servios que deveriam estar acessveis desta rede. Teste tambm servios que no deveriam estar acessveis. Na maioria dos casos, os testes envolvero o acesso 19

 Internet e aos servios da DMZ. Verique tambm se alguma mensagem aparece no log durante estas tentativas.

Testes de servios disponibilizados. Com o uso da arquitetura proposta, os servios disponibilizados para a Internet estaro na rede DMZ. partir de pontos que estejam alm do roteador externo, faa testes de acesso aos servios disponveis na DMZ. Se possvel, por meio do nmap verique quais portas esto abertas nestas mquinas, criando uma relao com os servios que se deseja disponibilizar. Evite deixar servios desnecessrios nesta rede. Teste de logs. Tente fazer acessos os quais no deveriam passar pelos ltros do rewall. Logo aps, verique se estas tentativas foram registradas nos logs. Note que o formato padro do script cftk no faz o registro de todas os pacotes que foram negados. Lembre-se que o rewall tem por objetivo aumentar a segurana dentro do possvel, mas no a prova de falhas. A ecincia na deteco de intrusos ou tentativas de intruso to importante quanto os ltros que o rewall em si proporciona. Ento, a ecincia do rewall s ser mais completa se as tentativas falhas de acesso estiverem sendo registradas e monitoradas corretamente.

14.3. Backup de Conguraes

Em caso de eventual problema com a mquina do rewall, por exemplo, um problema com o disco rgido, precisaremos recorrer a cpias de segurana dos arquivo de conguraes. Nas situaes em que for conrmada uma invaso a esta mquina, ento, nada do seu contedo poder ser considerado ntegro e quase tudo dever ser descartado. Deve-se tentar descobrir qual foi a falha e em seguida reinstalar todo o sistema. Novamente, o backup ser de grande ajuda para a reconstruo da soluo. Prestar muita ateno, aps descobrir o problema que possibilitou a invaso, se os backups tambm esto contaminados. Se o cliente demorou para descobrir o ataque provvel que os ltimos backups estejam. Providencie backup do seguinte:

Script cftk (/usr/bin/cftk). Voc precisar fazer um backup do prprio script, pelo motivo bvio de que as regras se encontram nele mesmo. Conguraes das interfaces (ifcong > /etc/ifcong.txt). Salve o arquivo /etc/ifcong.txt. Isso resumir rapidamenta todas as conguraes das interfaces existentes. Congurao das rotas. Execute "route > /etc/route.txt" e salve este arquivo.

Lembre-se de manter este backup em domnio da Conectiva, incentivando, desta forma, que o cliente faa uso de eventuais contratos de manuteno que foram ou sero oferecidos ao cliente, considerando que a restaurao da soluo ser rpida quando em poder destes arquivos.

15. Documentao
Preecha o formulrio ps-instalaao da soluo Planejamento e Implantao de Firewall que se encontra no arquivo sob nome 20

form-posinst.txt como anexo desta documentao. Este formulrio dever ser preechido pelo tcnico instalador da soluo. O objetivo deste formulrio o de manter um registro das informaes bsicas sobre as conguraes feitas, as quais sero teis ao cliente e ao prprio tcnico em visitas posteriores. O formulrio dever ser assinado pelo tcnico instalador e pelo cliente, sendo que ambos caro com uma cpia do mesmo. Alm do formulrio citado nos pargrafos acima, dever existir uma documentao contratual que fale sobre as garantias da soluo. O cliente precisa estar ciente de que a soluo de rewall no garante a segurana abosoluta de seu sistema. Deixar claro que o objetivo da soluo o de proteger, sendo que isto siginica minimizar ao mximo possvel os riscos de invases e registar quaisquer tentativas. Veja a seo de objetivos da soluo para maiores detalhes sobre este assunto. importante tambm, deixar claro em documento formal que, se o cliente zer alteraes na soluo por sua prpria conta, e a soluo tenha que ser reinstalada/recongurada, o prprio cliente ter que arcar com os encargos provenientes destes servios.

16. ANEXO 1 - Guidelines para estudo das necessidades do cliente

Esta soluo contempla a instalao da soluo de rewall em si, e no exatamente o ambiente onde ela ser instalada. Como estes ambientes tendem a ser bastante heterogneos, seria complicado contemplar os casos possveis, ou mesmo os mais comuns. Portanto, ca na incumbncia do cliente dizer exatamente o que ele quer que seja protegido, e do tcnico que zer a instalao de arrancar esta informao dele. Como sabemos que o mundo no perfeito, e muito menos os clientes sabem dizer o que querem, aqui vo algumas guidelines que podero ajudar na aquisio destas informaes, e na estruturao do rewall como um todo. importante lembrar que esta tarefa bastante subjetiva, e no a inteno nem obrigao deste documento levar o assunto exausto. Portanto, use as informaes contidas aqui, mas obtenha outras fontes de pesquisa voc mesmo, principalmente porque a rea de segurana muda com frequncia mais alta do que conseguimos atualizar este documento. Isto posto, tente seguir estes passos:

Desenhe a rede do cliente. Dena as redes que sero usadas, os IPs que estaro nas interfaces do rewall, as netmasks, as rotas entre as redes. Cada interface do rewall deve estar conectada a uma nica rede. Nunca, nunca coloque duas redes no mesmo barramento ou uma mesma rede em dois barramentos (por falta de IPs?). Talvez seja preciso criar subnets da rede original, para que parte dela que entre o rewall e o roteador externo, e a outra parte que na DMZ (sim, a DMZ precisa de uma rede vlida se voc espera que mquinas da internet consigam alcan-la). Se o cliente tiver apenas 1 IP vlido (o do prprio rewall), ou uma rede to pequena que no d para fazer subnets, ou que depois de criadas as subnets no existiro IPs sucientes na DMZ, ento o cliente precisa adquirir mais IPs vlidos junto ao seu fornecedor de acesso (backbone). No existe milagre, apesar de os clientes acharem que sim. Prepare-se para argumentar sobre isto. Qual a conectividade atual do cliente com a internet?

J est conectado internet, diretamente, sem nenhum rewall. Esta uma situao complicada. O cliente j est conectado, portanto j usa os servios da rede e j tem costumes e vcios quanto estrutura. Alm disso bastante provvel que ele tenha distribudo IPs vlidos entre as estaes que acessam a Internet, que esto em um barramento diretamente conectado no roteador que as liga com o backbone. Sem discutir o risco que estas mquinas j estavam correndo numa situao destas, voc ainda vai ter o trabalho de ter 21

que inserir um rewall no meio de uma rede j existente, modicando a estrutura geral, necessariamente. Os usurios devero ser avisados do tempo que isso levar, pois no ser possvel fazer tudo em poucas horas, ou mesmo em um dia. Estes usurios tambm devero ser alertados do que passar a ser proibido deste momento em diante (antes eles tinham acesso livre). Tome cuidado com o TTL do DNS do cliente. Provavelmente os IPs iro mudar, e se o TTL era alto, ele pode car inacessvel por at uma semana ou mais at que os caches externos expirem. Diminua o TLL para menos de 24h antes de comear a fazer a mudana, de preferncia at uma semana antes. Depois volte ao normal.

No est conectado internet ainda (nenhum tipo de conexo, completamente isolado). Esta a situao mais fcil de se lidar! Planeje tudo do zero, e faa um bom trabalho!

J possui um rewall e est migrando para o novo. Esta situao deveria ser, a princpio, simples de se lidar. O sucesso ir estar relacionado ao estudo das habilidades atuais do rewall, para que elas possam ser mantidas aps a migrao. Qualquer tipo de impacto na mudana provavelmente vir de diferenas nos servios existente anteriormente e nos novos. Tome cuidado com isso.

Determine, com a ajuda do cliente, os protocolos que iro circular atravs rewall, e em que direes as conexes podero ser iniciadas. Os usurios da rede tambm devem ser consultados. Leve em conta todas as possibilidades. Considere que estamos preocupados (a princpio) apenas com a direo que as conexes so iniciadas. Se uma regra permitiu que uma certa conexo fosse inciada, parece sem sentido impedir os prximos pacotes desta mesma conexo de passar pelo rewall.

Da rede interna para a externa (internet): Normalmente passa tudo, mas verique se o cliente realmente quer que passe tudo. Ele pode querer que os funcionrios no consigam usar alguns protocolos como o do napster por exemplo. Numa situao bastante paranica, a rede interna tambm insegura e tambm deve car isolada da rede externa. Hoje em dia, os vrus conseguem entrar na rede interna atravs de emails, e uma vez numa estao Windows da intranet, ele pode atacar mquinas aleatrias da internet, e voc (ou o cliente) vai levar a culpa pois o ataque partiu dos seus IPs. Nesse caso, libere apenas HTTP, FTP, SMTP, POP, e outros. Ainda assim, use proxys desses protocolos na DMZ ao invs de instal-los no rewall. O rewall pode possivelmente ter um server de DNS que aceite consultas recursivas, e a rede interna tem um server de DNS que faz forward para o do rewall. Esse server de DNS do rewall deve atender requisies apenas na interface interna. Da rede externa (internet) para a interna: Normalmente no passa nada. Ningum quer conexes externas entrando na rede interna, onde tudo considerado seguro por denio. E no h um motivo que justique a quebra desta regra. Se o cliente quiser permitir conexes na rede interna, convena-o do contrrio. Isto acaba com toda a teoria de rewalls. Se ele tem algo que o mundo externo precisa acessar, coloque este servio na DMZ, pra isso que ela serve. Alm do mais, normalmente as redes internas tm IPs reservados, e no teriam rota mesmo que quisessem. Mesmo assim, ainda possvel fazer NAT reverso do servidor pra dentro. Contenha-se e no faa isso. Mesmo que exista um banco de dados na rede interna que um server de WWW l da DMZ precise acessar, arrume outra soluo, como por exemplo replicar o banco l pra fora (mquina interna se replica num server na DMZ) e o server de WWW usa a base externa replicada. Da rede interna para a DMZ: Normalmente passa tudo, e sem NAT (rota direta). Esta a congurao padro. A rede interna segura por denio e pode ir at a DMZ fazer o que bem entender. Novamente, no modo parania, apenas os protocolos que realmente precisam passar devem ser permitidos. Caso a rede interna seja comprometida (por qualquer que seja o mtodo), a DMZ ser entregue de bandeija se tudo estiver aberto. A princpio o protocolo POP ser necessrio, para a rede interna poder buscar emails no servidor de emails que est na DMZ. Da DMZ para a rede interna: Aqui o inverso, normalmente no se deixa passar nada. Nada mesmo. Cabe a mesma 22

teoria de que nada entra na rede interna, no interessa de onde venha. A DMZ, apesar de protegida pelo rewall, est passvel de ser comprometida pois est provendo servios para o mundo externo, e caso acontea, a rede interna ser a prxima. Sempre, sempre, as mquinas de rede interna devem acessar a DMZ e nunca o contrrio. Naquele caso do banco de dados se replicar l fora, a mquina interna que deve iniciar a conexo com a da DMZ. Sob hiptese alguma, por mais que o cliente insista (e acredite, ele vai insistir), permita que conexes entrem da DMZ para a rede interna.

Da rede externa (internet) para a DMZ: Esta a congurao mais crtica do rewall. Abra aos poucos apenas o necessrio. Se no tiver certeza do que ser necessrio, comece com tudo fechado e v abrindo conforme os logs mostrem que pacotes importantes esto sendo descartados. Deve passar o estritamente necessrio. Normalmente se deixa passar HTTP, HTTPS, SMTP, FTP, e outros servios particulares do cliente. Da DMZ para a rede externa (internet): Nada deve passar alm de SMTP e algum outro protocolo que o cliente necessite em particular. A DMZ cai no mesmo problema da rede interna: caso seja comprometida, no deve servir de base do invasor para ataques externos a terceiros.

Esta soluo tem como requisito bsico o uso de IPs reservados na rede interna. Isto na verdade deveria ser apenas uma recomendao, que foi imposta como regra nesta soluo em especco. Mesmo que o cliente possua IPs reais aos montes, no os use para a rede interna. Isto vai, alm de aumentar a segurana, fazer com que as mudanas de estrutura na rede interna nunca afetem o rewall nem as regras existentes. Eduque os usurios. Eles devem saber o que est acontecendo, e porque. Devem entender que eles estaro mais seguros desta forma, e que eles devem fazer parte da soluo de segurana, e no parte do problema. Usurios podem se tornar uma dor de cabea se no forem convencidos de que isto importante. Acompanhe pelos logs quem est fazendo o que, e advirta-os sempre que necessrio.

A maior parte das regras acima no so exatamente para o instalador do rewall, mas sim para o administrador. O tcnico instalador deve expor estes pontos ao administrador da rede, e deix-lo ciente da sua importncia.

17. Referncias
17.1. Links e Documentos
Filtragem de pacotes com o kernel 2.4 (em ingls) (http://netlter.gnumonks.org/unreliable-guides/packet-ltering-HOWTO.txt) Firewall HOW TO (em ingls) (http://ldp.conectiva.com.br/HOWTO/Firewall-HOWTO.html) NAT HOWTO, incluindo o caso particular de masquerade, com o kernel 2.4 (em ingls) (http://netlter.gnumonks.org/unreliableguides/NAT-HOWTO.txt) Treinamento em Segurana (em portugus) (http://treinamento.conectiva/prossional/cert-1-5/index.html)

23

17.2. Arquivos Anexos da Soluo

Pacote cftk (../arquivos/cftk-1.0-3cl.noarch.rpm) Formulrio ps-instalao. (../arquivos/form-posinst.txt)

Bibliograa de Referncia

D. B. Chapman e Elizabeth D. Zwicky, Building Internet Firewalls, 2a. Edicao, OReilly & Associates, 1995, ISBN 1-56592124-0.

24