Segurança é uma das preocupações básicas quando uma organização conecta sua rede privada à Internet. Independente do negócio, um número cada vez maior de usuários em redes privativas estão querendo ter acesso a serviços da Internet como a WWW (World Wide Web), Internet mail, Telnet e FTP (File Transfer Protocol). Além disso, as empresas querem estar presentes na Internet através de páginas na WWW e servidores de FTP para os usuários (navegadores) da Internet.
Os administradores de rede tŠm que se preocupar cada vez mais com a seguran‡a de suas redes quando dados privativos da organiza‡ƒo e a infra-estrutura da rede sƒo expostos a "piratas" da Internet. Uma organiza‡ƒo precisa de uma poltica de seguran‡a para prevenir que usußrios nƒo autorizados acessem recursos da rede privada e para evitar o envio de informa‡es privadas, para tanto deve ser fornecido um determinado nvel de prote‡ƒo. Mesmo quando uma organiza‡ƒo nƒo estß conectada € Internet, a mesma pode querer estabelecer uma poltica interna de seguran‡a para gerenciar os acessos dos usußrios a certas ßreas da rede e proteger informa‡es estrat‰gicas ou secretas.
Internet Firewalls
Um Internet firewall ‰ um sistema ou grupo de sistemas que refor‡a a poltica de seguran‡a entre a rede organizacional e a Internet. O firewall determina que servi‡os internos podem estar acessveis pelo mundo exterior, que usußrios de fora sƒo autorizados a acessar a rede interna, e que servi‡os externos podem ser acessados pelos usußrios internos da rede privativa. Para que um firewall funcione eficientemente todo o trßfego para e da Internet deve passar pelo firewall, onde o mesmo serß inspecionado. O firewall deve permitir passar apenas o trßfego autorizado e o firewall em si deve ser imune a penetra‡ƒo (nƒo ser suscetvel a entradas nƒo autorizadas).
Ð importante visualizar um Internet firewall nƒo apenas como um roteador, um bastion host ou uma combina‡ƒo de dispositivos que forne‡am seguran‡a para a rede. O firewall deve ser parte de um poltica global de seguran‡a que cria um permetro de defesa projetado para proteger as informa‡es da organiza‡ƒo. Esta poltica de seguran‡a deve ser constituda de diretrizes de seguran‡a para informar os usußrios sobre suas responsabilidades, polticas corporativas com
defini‡es de acesso a rede (interna/externa), acesso a servi‡os, autentica‡es locais e remotas, criptografia de dados, medidas de prote‡ƒo a ataques de vrus; e treinamento dos funcionßrios/usußrios. Todos os pontos potenciais de ataque da rede devem ser protegidos com o mesmo nvel de seguran‡a de rede. Estabelecer um Internet firewall sem uma completa poltica de seguran‡a ‰ o mesmo que colocar uma porta de ferro numa barraca de camping.
Benefcios de um Internet Firewall
Internet firewalls gerenciam o trßfego entre a Internet e a rede privada da organiza‡ƒo. Sem um firewall cada host do sistema da rede interna ‰ exposto a ataques de outros hosts na Internet. Isto significa que a seguran‡a da rede interna depende do nvel de seguran‡a implementado em cada host e a mesma seria tƒo segura quanto o mais frßgil (suscetvel a ataques) host.
Internet firewalls permitem que o administrador da rede defina um "gargalo" que mantenha usußrios nƒo autorizados como hackers, crackers, v‚ndalos e espies fora da rede protegida (rede interna), evitando que servi‡os vulnerßveis entrem ou saiam da rede protegida e forne‡a prote‡ƒo a vßrios tipos de ataques de roteamento. Um Internet firewall simplifica o gerenciamento de seguran‡a, jß que a seguran‡a da rede estß localizada em um sistema de firewall (o bastion host) em vez de estar distribuda em cada host da rede interna inteira.
Firewalls fornecem um ponto conveniente onde a seguran‡a (em rela‡ƒo € Internet) pode ser monitorada e alarmes podem ser gerados. Deve ser observado que para organiza‡es conectadas € Internet a questƒo nƒo ‰ se mas quando os ataques ocorrerƒo. Um firewall eficiente, aliado a uma poltica de seguran‡a global, evitarß que estes ataques obtenham Šxito.
Um Internet firewall ‰ o local ideal para a disponibiliza‡ƒo de servidores WWW e FTP. O firewall pode ser configurado para permitir acesso (de usußrios da Internet) a estes servi‡os, enquanto bloqueia o acesso externo aos demais sistemas existentes na rede protegida.
Limita‡es de um Internet Firewall
Um Internet firewall nƒo pode proteger contra ataques que nƒo venham atrav‰s do firewall. Por exemplo, se um acesso (dial-out) irrestrito ‰ permitido de dentro da rede protegida, usußrios internos podem fazer conexes diretas com a Internet. Usußrios experientes que tornam-se irritados com a autentica‡ƒo adicional requerida pelos servidores de proxy podem ser tentados a driblar o sistema de seguran‡a para conseguir uma conexƒo SLIP ou PPP direta para um ISP
(provedor de acesso € Internet). Os usußrios devem ser conscientizados de que estes tipos de conexƒo nƒo sƒo permitidas devido € arquitetura de seguran‡a global estabelecida na organiza‡ƒo.
Internet firewalls nƒo podem proteger contra os tipos de amea‡as vindos de traidores ou de usußrios "desastrados". Firewalls nƒo proibem traidores ou espies de copiar dados estrat‰gicos em disquetes ou cartes PCMCIA e removendo-os do pr‰dio. Firewalls nƒo protegem de um ataque quando um hacker, fingindo ser um supervisor ou um novo funcionßrio confuso, persuade um usußrio mais humilde a revelar uma senha ou dar um acesso "temporßrio" € rede. Funcionßrios (usußrios internos) devem ser educados sobre os vßrios tipos de ataques e sobre a
necessidade de guardar e periodicamente mudar suas senhas de acesso.
Internet firewalls nƒo podem proteger contra a transferŠncia de softwares ou arquivos infectados por vrus. Uma vez que hß tantos diferentes vrus, sistemas operacionais, e modos de codifica‡ƒo e compressƒo de arquivos binßrios, um Internet firewall nƒo pode examinar minuciosamente cada e todo arquivo a procura de vrus potenciais. A organiza‡ƒo deve fornecer uma cpia de um software anti-vrus para cada mßquina, evitando a entrada dos mesmos atrav‰s de disquetes ou quaisquer outras fontes.
Arquitetura Bßsica de um Firewall
Quando se constri um firewall de rede, a primeira decisƒo de configura‡ƒo que deve ser feita ‰ qual dos modelos de seguran‡a seguir:
Packet Filter Firewalls x Proxy Server Firewalls
Os packet filters sƒo implementados utilizando as facilidades dos roteadores, o que torna o processo de configura‡ƒo difcil. Um dos maiores problemas que surgem ‰ certificar-se que o conjunto de regras nƒo escondem vulnerabilidades. Por exemplo, a utiliza‡ƒo do endere‡o fonte para determinar se um pacote ‰ ou nƒo confißvel, pode levar a falhas de seguran‡a, pois um hacker habilidoso pode forjar um endere‡o fonte de um pacote.
Como o packet filter examina cada pacote como uma entidade separada, ele s pode filtrar pacotes baseados nos seguintes crit‰rios: endere‡o fonte e destino; tipo de servi‡o de rede; ou se o pacote estß tentando estabelecer uma nova conexƒo na rede.
Os proxy servers por sua vez, examinam o fluxo como uma conexƒo para um servi‡o da rede, e podem prover muitas fun‡es adicionais de seguran‡a como autentica‡ƒo de usußrios, encripta‡ƒo de dados fim-a-fim, etc.
Os proxy servers tratam os dados para cada tipo de servi‡o da rede separadamente, utilizado aplica‡es conhecidas como proxies. Para cada nova sessƒo de comunica‡ƒo estabelecida um novo proxy ‰ iniciado, de maneira que para cada servi‡o pode haver vßrios proxies, cada um examinando fluxos de trßfegos diferentes.
Como nƒo hß nenhuma conexƒo direta entre hosts internos e externos, uma rede interna protegida por um firewall ‰ "escondida" do mundo externo, o que aumenta a seguran‡a em rede e reduz o esfor‡o exigido para proteger os hosts internos de um ataque externo.
Vßrios fatores levaram a escolha de um proxy server para implementar o Firewall-DI, dentre elas destacam-se:
Softwares Utilizados no Projeto
Para a implementa‡ƒo do nosso firewall foram utilizados alguns utilitßrios do TIS Internet Firewall Toolkit, que roda sobre a plataforma UNIXÒ usando TCP/IP; o CERN-httpd, e os arquivos fonte dos clientes telnet e ftp que foram modificados em parte para ficarem de acordo com nossas necessidades.
O toolkit ‰ composto de mdulos que podem ser usados sozinhos ou em combina‡ƒo com outros componentes de firewall.
Filosofia de Design do TIS Firewall
O TIS Firewall foi projetado para ter sua corretude verificada como um todo ou por componente utilizado. Isto parece ser uma percep‡ƒo bastante "leve" para um firewall de rede, mas como vßrios sistemas de firewall existentes confiam em que "o que ‰ conhecido ser bom" ou que ‰ considerado de confian‡a por ser largamente utilizado por muito tempo. Um problema com "sabido ser bom" ‰ que historicamente isto nƒo ‰ muito confißvel. Alguns componente como "mailers" sƒo freq’entemente "quebrados", sem importar o quƒo cuidadosamente eles sejam mantidos. Como um passo adiante para este aspecto, o Firewall Toolkit ‰ projetado para operar sobre os seguintes princpios bßsicos:
Prßticas de Configura‡ƒo
Anßlises de Risco
Antes de come‡ar o projeto de firewall, ‰ importante ter uma id‰ia clara do que o firewall resultante irß prover prote‡ƒo contra, como irß cumprir os padres organizacionais/corporativos existentes, e como ele se ajusta em toda a arquitetura de seguran‡a da rede. Para que um bom firewall seja projetado ‰ preciso antes que os objetivos de seguran‡a do firewall tenham sido enumerados, requisitos dos usußrios e prßticas de negcios sido considerados.
Permetro de Defesa
Uma importante considera‡ƒo a ser feita no momento de estabelecimento do firewall ‰ o permetro de defesa. Firewalls nƒo provŠm qualquer prote‡ƒo uma vez que o atacante ("hacker") tenha conseguido ultrapassß-los. Ter um firewall ‰ como ter uma grande porta de ferro como porta frontal de um edifcio - fornece uma excelente prote‡ƒo contra ataques frontais. Para prosseguir a analogia, se uma poltica de seguran‡a ‰ tal que uma porta de ferro frontal ‰ requerida, deveria tamb‰m possuir venezianas de ferro nas janelas, e deveria nƒo possuir portas de conexƒo com os pr‰dios vizinhos a nƒo ser que eles tamb‰m possussem
portas e venezianas de ferro tamb‰m. Em termos prßticos de rede, isto se equipara com as medidas bßsicas tais como assegurar "modem pools" com senhas, publicar padres de seguran‡a que informam claramente aos usußrios suas responsabilidades, e examinar quaisquer outras redes que compartilham (estƒo "dentro" da rede) o permetro de seguran‡a. Um usußrio que decide comprar uma conexƒo serial de rede (SLIP) para um provedor de servi‡os de Internet pode nƒo intencionalmente burlar um sistema de seguran‡a muito caro. Tendo um firewall que usa mecanismos de autentica‡ƒo fortes tais como senhas descartßveis ou
calculadoras "criptogrßficas" enquanto possuem um acesso via modem que nƒo requer senhas indica uma prßtica inconsistente de seguran‡a. Quando estabelecer um permetro de seguran‡a, o administrador deve executar primeiro uma anßlise de riscos, e entƒo ter certeza que todos os pontos de entrada para a rede estƒo igual e fortemente protegidos. Se duas redes estƒo sendo conectadas e compartilham um permetro de seguran‡a comum, entƒo ambas redes devem ser
protegidas no mesmo nvel, com uma poltica de seguran‡a compartilhada solidamente refor‡ada.
Arquitetura do TIS Firewall
O toolkit foi projetado para suportar usußrios que querem implementar firewalls baseados na abordagem "aquilo que nƒo ‰ expressamente permitido ‰ proibido". Geralmente quando se constri tal firewall ‰ importante ter boas ferramentas para fornecer controle de acesso e servi‡os seguros para os poucos servi‡os disponveis. Os componentes do software do toolkit implementam seguran‡a para os mais comuns servi‡os de rede usados.
Topologia de Firewall Utilizada
Hß diversas configura‡es de arqu‰tipos de firewall que o toolkit foi projetado para suportar. Os tipos bßsicos de firewall que o toolkit suporta sƒo: dual-homed gateways, screened host gateways e screened subnet gateways. Nossa escolha para implementa‡ƒo foi o primeiro: o dual-homed gateway. Em todos estes firewalls o fator comum mais importante ‰ um host, o bastion host, que atua como um "fowarder" de aplica‡es, um "logger" de trßfego e um provedor de servi‡os. Manter seguran‡a no bastion host ‰ de suma import‚ncia, e ‰ nele onde a maior parte do esfor‡o de estabelecimento (montagem) do firewall ‰ focado.
Em uma configura‡ƒo dual-homed gateway, o software do toolkit ‰ instalado em um host com duas interfaces de rede. O toolkit fornece servi‡os de proxy para aplica‡es comuns como FTP e TELNET, e seguran‡a para o mail SMTP. Desde que o bastion host ‰ um ponto crucial para seguran‡a da rede, ‰ importante que a configura‡ƒo do software naquele host seja tƒo segura quanto possvel.
Dual-homed gateway ‰ um um tipo atraente de firewall devido a sua simplicidade de implementa‡ƒo, requerendo um mnimo de hardware e podendo ser facilmente verificßvel. A maioria das implementa‡es de UNIX baseadas em Berkeley tŠm uma varißvel de kernel chamada _ipforwarding, a qual indica para o sistema operacional que nƒo deveria rotear trßfego entre redes, mesmo se a mßquina estß conectada a duas redes (o que normalmente leva o sistema a agir como um roteador de gateway). Desabilitando completamente roteamento, o
administrador pode ter um alto grau de confian‡a de que qualquer trßfego entre a rede protegida e a rede nƒo confißvel estß de alguma forma passando atrav‰s de uma aplica‡ƒo que estß executando no firewall. Desde que nƒo hß trßfego sendo transferido diretamente entre a rede interna e a rede externa (nƒo confißvel), nƒo ‰ necessßrio mostrar quaisquer rotas da rede interna sobre a rede externa. Isto realmente torna a rede protegida "invisvel" para quaisquer sistemas com exce‡ƒo do bastion host. A ”nica desvantagem deste tipo de firewall ‰ que ele ‰
implicitamente um firewall do tipo "o que nƒo ‰ expressamente permitido ‰ proibido" - e ‰ impossvel enfraquecer a seguran‡a do firewall para deixar passar um servi‡o mesmo se mais tarde algu‰m decida que o quer. Todos os servi‡os devem ser suportados no firewall via proxies.
Configura‡ƒo Idealizada
Servi‡o FTP
O gateway de aplica‡ƒo FTP ‰ um processo ”nico que intermedia conexes FTP entre duas redes. Como nƒo faz nenhum acesso a disco al‰m da leitura de seu arquivo de configura‡ƒo e ‰ um programa relativamente simples e descomplicado. (Ð passvel de discussƒo se ele ‰ capaz de comprometer a seguran‡a do sistema.) O gateway de aplica‡ƒo roda como um usußrio sem privil‰gios, depois de "chrooting" (uma chamada do sistema que cria um pseudo diretrio raiz e
faz com que a aplica‡ƒo em questƒo s "enxergue" a partir deste diretrio) em um diretrio privado no sistema. Para controlar o acesso FTP, o gateway de aplica‡ƒo lŠ o arquivo de configura‡ƒo, contendo uma lista de comandos ftp que devem ser registrados em um arquivo (arquivo de "log"), e uma descri‡ƒo de quais sistemas estƒo autorizados € entrar no trßfego Internet. Todo o trßfego pode ser registrado em arquivo (logged) e sumarizado. O Firewall-DI permite o trßfego da Internet para a rede privada atrav‰s de uma determinada porta, para usußrios que se autenticarem previamente no sistema.
Fizemos a op‡ƒo por utilizar apenas uma mßquina permitindo ftp e somente ftp anŸnimo.
Tamb‰m foram realizadas algumas altera‡es nos arquivos fonte relacionados ao servi‡o ftp para melhor adequß-los ao nosso sistema e a nossas mßquinas (customiza‡ƒo).
Servi‡o TELNET
O gateway de aplica‡ƒo TELNET ‰ uma aplica‡ƒo simples e pequena e assim como o FTP, o ”nico arquivo que acessa ‰ o arquivo de configura‡ƒo que ‰ lido na inicializa‡ƒo. Logo aps o arquivo de configura‡ƒo ser lido, o gateway de aplica‡ƒo TELNET ‰ "chrooted" (direcionado para um diretrio restrito), onde ele roda como um processo sem privil‰gios. O arquivo de configura‡ƒo do gateway de TELNET permite a especifica‡ƒo de quais sistemas ou redes podem ser usadas, e para quais sistemas ou redes ele permitirß conexƒo. O arquivo de configura‡ƒo foi configurado para permitir que a nossa rede privada utilize o gateway para
conectar-se € Internet, quanto ao servi‡o TELNET de fora da nossa rede privada para dentro, este exige que seja feita uma pr‰-autentica‡ƒo, para posteriormente, conectß-lo ao host nicarßgua. Todas as conexes e suas dura‡es sƒo registradas em arquivo de "log".
Foram realizadas algumas altera‡es nos arquivos fonte relacionados ao servi‡o telnet para melhor adequß-los ao nosso sistema e a nossas mßquinas (customiza‡ƒo). Para acessos de dentro para fora o programa executado ‰ o programa cliente adaptado (customizado). Para acessos de fora para dentro primeiro ‰ feito uma pr‰-autentica‡ƒo e depois ‰ o programa pede uma conexƒo para nicaragua. Tamb‰m usamos uma determinada porta (diferente da de FTP)
para o servi‡o TELNET.
Por fim, criamos tamb‰m a possibilidade de ser usado um proxy com criptografia, para ser utilizado em uma pßgina na WWW; atrav‰s da utiliza‡ƒo de programas em Java na mßquina cliente.
Autentica‡ƒo de Usußrios
O servidor de autentica‡ƒo da rede authsrv provŠ um servi‡o de autentica‡ƒo gen‰rico para os proxies de FTP e de TELNET. O authsrv mant‰m internamente informa‡es sobre a ”ltima vez que um usußrio autenticou-se no servidor e quantas tentativas falhas foram feitas de cada usußrio em particular. Um "log" (registro) ‰ guardado para todas as transa‡es do authsrv. Como o seu banco de dados deve ser protegido, o authsrv deve ser executado em uma mßquina segura, por isso o prprio bastion host foi escolhido para sua execu‡ƒo.
Servi‡o MAIL
Hß o daemon smap que guarda todas as mails em um diretrio temporßrio e isolado do restante do sistema e o smapd que as envia em seguida.
Logging
Os eventos de seguran‡a relevantes e os registros de auditoria sƒo registrados em um arquivo de "log" e sƒo armazenados no bastion host (por motivos de seguran‡a), utilizando o syslogd. A versƒo do syslogd que o toolkit utiliza no BSD "net 2". Para termos acesso aos "logs" usamos o comando: tail -f firewall/tmp/teste.
CERN HTTP
O protocolo HTTP permite a dissemina‡ƒo de informa‡es atrav‰s da WWW. Uma URL ‰ utilizada para especificar o host, o n”mero da porta e o seletor. Quandose passa pelo firewall, o proxy obt‰m o destino final da informa‡ƒo (host e n”mero da porta) atrav‰s do seletor e reescreve todas as URLs contidas no documento para que as mesmas tamb‰m passem atrav‰s do firewall. O gateway tamb‰m pode restringir os m‰todos HTTP permitidos.
Usamos apenas uma determinada porta para o servi‡o HTTP. E o endere‡o do HTTP Proxy ‰ 150.161.42.40
Bibliografia
Internet Firewalls; Chapman, D. Brent & Zwicky, Elizabeth D.; O'Reilly & Associates, 1995
Thinking About Firewalls V2.0: Beyond Perimeter Security; Ranum,
Marcus J.
http://www.clark.net/pub/mjr/pubs/think/index.html
Internet Firewall and Security - A Technology Overview; Semeria,
Chuck
http://www.3com.com/nsc/500619.html
A Toolkit and Methods for Internet Firewalls; Ranum, Marcus J. & Avolio, Frederick M.
http://www.tis.com./docs/products/gauntlet/Usenix.html
Quando se implementa um firewall seguindo a primeira abordagem, se identifica os servi‡os que serƒo fornecidos, enfoca-se a seguran‡a destes servi‡os, bloqueia todos os demais servi‡os e trßfego, e entƒo habilita os servi‡os selecionados s depois de terem sido testados e se acredita serem seguros. Na segunda abordagem, se identifica todos os servi‡os que apresentam riscos e os desabilita. A primeira abordagem ‰ mais conservadora, aceitando que "o que nƒo conhecemos pode nos machucar", mas tende a impor limites nos tipos e n”meros de servi‡os que podem ser fornecidos atrav‰s do firewall. A segunda abordagem ‰ mais versßtil, desde que mais servi‡os sƒo suportados, mas esbarra em uma luta de bra‡o entre o administrador e os "hackers". Outra importante considera‡ƒo ‰ o tamanho da comunidade de usußrios na rede protegida. Como a medida que a rede protegida cresce ‰ mais trabalhoso monitorß-la completamente, torna-se cada vez mais difcil para um administrador verificar que membros da comunidade de usußrios nƒo estƒo eles mesmos fornecendo servi‡os na rede que burlam a seguran‡a do firewall. Um exemplo do problema seria um usußrio decidir fornecer o servi‡o de
FTP em uma porta diferente da porta padrƒo porque a porta de servi‡o de FTP estß bloqueada pelo firewall, mas a porta alternativa nƒo estß.
Estes princpios podem ser efetivamente aplicados a qualquer arquitetura de firewall de rede.
