MECANISMOS DE GESTÃO INTEGRADA PARA FIREWALL APPLIANCES

MECANISMOS DE GESTÃO INTEGRADA PARA FIREWALL APPLIANCES Bruno Colaço, Luís Pinto, Edmundo Monteiro, Paulo Simões colaco@student.dei.uc.pt, {lmpinto, edmundo, psimoes}@dei.uc.pt CISUC Dep. Eng. Informática Universidade de Coimbra, Pólo II 3030-290 Coimbra, Portugal RESUMO Nos últimos anos o número de firewalls em uso cresceu dramaticamente. Esse crescimento é justificado por duas vias distintas mas complementares: uma maior preocupação com a segurança das redes de computadores, por um lado; e a progressiva democratização resultante do surgimento de firewalls de muito baixo custo, por outro. No entanto, a presença de uma firewall não garante, por si só, uma rede mais segura, especialmente quando não existem técnicos qualificados que assegurem a sua configuração, gestão e monitorização. Infelizmente essa situação é cada vez mais frequente, pois em muitas situações não existe capacidade financeira para contratar técnicos especializados e, adicionalmente, os mecanismos de gestão de firewalls disponíveis não são ainda satisfatórios para uso por técnicos menos qualificados. Este problema torna-se especialmente crítico em redes de pequena e média dimensão, que apresentam já requisitos de segurança consideráveis mas que não justificam ainda, pela sua dimensão, soluções mais completas e dispendiosas. Nesta comunicação é apresentada uma plataforma de administração de firewalls concebida para este tipo de cenário. Quando comparada com as abordagens tradicionais esta plataforma reduz os custos de instalação e manutenção, optimizando em paralelo as condições de configuração e monitorização: as várias firewalls, ainda que geograficamente distantes, passam a poder ser instaladas, administradas, auditadas e monitorizadas num único ponto central. Além disso, a própria configuração é bastante simplificada, uma vez que passa a ser efectuada através de uma interface gráfica bastante intuitiva, por oposição aos mecanismos de configuração mais propícios a erros presentes em muitas das soluções open-source actualmente em uso. Outra vantagem da plataforma é a existência de uma base de dados central onde está registada e organizada toda a informação de gestão das firewalls: configuração, histórico de operações de manutenção, histórico de monitorização, e logs detalhados de funcionamento. PALAVRAS-CHAVE Gestão de Redes, Segurança, Gestão de Firewalls 1. Introdução Alguns anos atrás a aquisição de uma firewall representava um investimento bastante vultuoso. Hoje em dia o cenário é substancialmente diferente, pois estão disponíveis diversas solucões de firewalling de baixo custo que incluem a maior parte das funcionalidades básicas necessárias a redes de pequena e média dimensão/complexidade. As soluções baseadas em GNU/Linux ou BSD fornecem as bases necessárias para firewalls bastante funcionais (ainda que com interfaces de configuração pouco intuitivos e muito propícios a erros) e mesmo os routers de banda larga mais baratos já oferecem alguma capacidade básica de filtragem. No entanto, a proliferação destas soluções de baixo custo pode acarretar graves problemas: ao invés das soluções mais pesadas e complexas, estas firewalls são frequentemente instaladas e administradas por gestores menos especializados, aumentando a probabilidade de configurações inseguras e de monitorização menos cuidada. Perante este cenário, o gestor generalista tem duas alternativas: ou investe mais tempo na vertente de segurança tornandose gradualmente um especialista, à custa de uma menor produtividade nas restantes tarefas que lhe estão atribuídas ou ignora o problema, limitando-se a integrar as firewalls na rede e esperando que tudo corra pelo melhor. CRC2004 1/10

Constata-se assim que é necessário prosseguir com a democratização das firewalls, complementando a satisfatória funcionalidade dos sistemas open source com interfaces de administração mais eficazes. Essa eficácia passa por diversos níveis: maior facilidade de configuração (interfaces mais intuitivos); mecanismos de configuração remota; suporte para monitoria e auditoria remota; e redução dos tempos de paragem para manutenção do hardware e do software. Alguns dos produtos comerciais de gama superior tais como, por exemplo, as plataformas Checkpoint [1], NetScreen [2], Cisco [3] ou Clavister [4] satisfazem já uma parte destes requisitos por meio de interfaces de configuração e monitorização remota e centralizada. No entanto, o seu preço elevado só justifica o seu uso em redes de média e grande dimensão. Foi também a pensar nesse tipo de redes que surgiu o paradigma de Gestão Baseada em Políticas (Policy Based Networking, ou PBN [5]). A ideia chave deste paradigma é possibilitar que o gestor de sistemas possa definir políticas gerais de funcionamento da rede, sendo depois automatizado o processo de conversão dessas políticas de alto nível para a configuração efectiva de cada dispositivo da rede. É no entanto nossa opinião que ainda há muito trabalho a fazer nesta área antes de termos sistemas reais completamente geridos desta forma, apesar de toda a investigação feita neste campo, do recente aumento de interesse à volta desta área e das alegadas funcionalidades PBN de alguns produtos comerciais. Na gama mais baixa, constata-se que a maior parte dos routers domésticos de banda larga (cabo e ADSL) inclui um interface web para configurar remotamente os seus filtros de tráfego. Note-se no entanto que estes interfaces não correspondem a nenhuma tentativa séria de suporte de gestão remota integrada. Eles destinam-se apenas a substituir a sintaxe obscura típica, por exemplo, do software de filtragem opensource, tornando-se assim mais acessíveis ao utilizador comum. Existe no entanto uma vasta gama intermédia onde são necessárias soluções com flexibilidade e robustez consideráveis mas onde não se justifica ainda o investimento nas soluções comerciais mais dispendiosas. É este o território das firewalls open source, geralmente construídas sobre BSD ou GNU/Linux e tirando partido de aplicações como o iptables [10] e implementações VPN de domínio público [11-12]. Estes sitemas são populares não apenas pelos seus custos reduzidos, mas também pela sua reconhecida a flexibilidade e robustez. No entanto, nem tudo é positivo nestas soluções open source: estas firewalls são configuradas e monitorizadas de forma individual, por meio de interfaces bastante complexos e propícios a erros, aumentando os custos de manutenção e a probabilidade de falhas de segurança. Esta situação motivou iniciativas como o LRP [13], o SmoothWall [14] e o Leaf [15], que simplificam a construção de firewalls baseadas em BSD ou GNU/Linux e oferecem, nalguns casos, GUIs para configuração das regras de funcionamento. No entanto, o processo de instalação e configuração continua a ser inerentemente manual, pouco optimizado e efectuado caso a caso. O custo de manter um parque de firewalls torna-se assim bastante elevado, em especial quando estas se encontram separadas geograficamente. É para melhorar esta situação que foi por nós construída uma plataforma de gestão centralizada de firewalls opensource. Esta plataforma permite instalar, configurar e monitorizar estas firewalls de forma remota, automatizada, com um interface menos propenso a erros e com menores custos operacionais (menos intervenções on-site; instalação automatizada; gestão integrada de configurações, monitorização e auditorias). Esta comunicação encontra-se organizada da seguinte forma. Na Secção 2 é descrito o cenário de utilização que serviu de inspiração ao projecto e identificam-se os requisitos resultantes desse cenário. Na Secção 3 é apresentada a Arquitectura da Plataforma. A Secção 4 é dedicada à Estação de Gestão, enquanto a linguagem de configuração de alto-nível é apresentada na Secção 5. A Secção 6 é dedicada às firewalls propriamente ditas, e a Secção 7 apresenta as conclusões. 2. Cenário de Referência e Requisitos da Plataforma A plataforma aqui apresentada foi desenvolvida como resposta uma necessidade concreta da equipa de outsourcing do Instituto Pedro Nunes (que presta serviços de administração de redes a clientes), que tem a seu cargo cerca de duas dezenas de redes de dados distintas de pequena e média dimensão (cada CRC2004 2/10

uma delas com algumas dezenas ou centenas de nós) e que, na maior parte dos casos, necessitam também de segmentação interna por razões de segurança. A fim de optimizar os custos do serviço, as tarefas mais demoradas e menos complexas, tais como o helpdesk a utilizadores e a manutenção de desktops, são desempenhadas por gestores locais, enquanto tarefas mais específicas são apoiadas/asseguradas por gestores especializados em áreas como segurança, gestão de bases de dados. Esta organização fragmentada, bem como as características inerentes às firewalls GNU/Linux, provocava um risco demasiado elevado de erros involuntários de instalação e configuração, além de não incentivar uma monitorização adequada das firewalls. Além disso, apesar das tentativas de uniformizar as diversas firewalls espalhadas pelos clientes, os custos de instalação e configuração eram praticamente proporcionais ao número de firewalls instaladas. Mesmo diferenças mínimas de versões de software entre várias firewalls ou de configuração devido a factores humanos implicavam um esforço adicional de sincronização, podendo traduzir-se em ameaças de segurança e impedindo as desejadas economias de escala. Era assim necessária uma aproximação alternativa, que satisfizesse os seguintes requisitos: Funcionalidades de gestão remota que reduzissem o mais possível a necessidade de intervenções locais dos técnicos especializados (mesmo para a instalação inicial da firewall). Maior homogeneidade nas diversas firewalls. Redução da probabilidade de erros humanos. Isto implica a redução de intervenções, quer locais quer remotas, e a concentração de todas as interfaces para configuração num local central utilizando uma interface de alto nível mais fácil de utilizar e auditar; Armazenamento de todas as configurações num local central, de modo a facilitar auditorias de segurança e reparações de emergência, em caso de falha de hardware (instalação de novo equipamento transferindo automaticamente as configurações anteriores); Mecanismos de monitorização on-line (para avaliar em tempo real o estado das diversas firewalls) e off-line (recolha e posterior análise dos logs detalhados de cada firewall). 3. Arquitectura A plataforma desenhada para responder a estes requisitos apresenta uma arquitectura bastante tradicional (ver Figura 1), centrada numa Estação de Gestão que controla a configuração das firewalls geridas, está encarregue do armazenamento de toda a informação numa base de dados relacional (configurações individuais das firewalls, logs, configurações administrativas e de segurança, etc.), fornecendo ainda uma Consola de Gestão por meio de uma interface web. Figura 1: Arquitectura da Plataforma de Gestão de Firewalls CRC2004 3/10

As firewalls geridas pela infraestrutura consistem em sistemas GNU/Linux com software como o iptables, servidores de DNS, NTP e DHCP, proxies HTTP e software de VPN. A este software tradicional são adicionados dois módulos específicos: suporte para uma sintaxe de alto nível para configuração das regras de funcionamento (adaptada do shorewall, uma ferramenta open source) e uma Camada de Gestão Remota que oferece à estação de gestão o necessário interface de controlo da configuração e de monitorização. 4. Estação de Gestão A estação de gestão é o ponto central que fornece os serviços de gestão e monitorização a todas as firewalls. A instalação e configuração de uma nova firewall começa pela introdução da informação relevante na consola de gestão (interface Web). Essa informação inclui dados administrativos (localização física, descrição sumária do hardware, técnicos responsáveis, etc.), configurações IP, chaves de segurança, regras de filtragem IP (usando uma sintaxe de alto nível) e configuração de serviços (DNS, DHCP, NTP, FreeS/wan). A configuração é então armazenada na base de dados, disponível para ser transferida para a firewall. O passo seguinte é ligar a firewall pela primeira vez (fazendo boot do CDROM onde se encontra uma imagem completa do software necessário) e fornecer alguma configuração mínima (endereços IP e chave de acesso ao servidor central), para que a firewall possa aceder automaticamente ao servidor central e descarregar a sua configuração completa. A mesma interface web poderá mais tarde ser usada para modificar qualquer parâmetro da configuração da firewall. É também possível manter na base de dados várias versões alternativas de configuração para uma determinada firewall, facilitando por exemplo o teste de novas configurações e/ou a reposição automática de configurações anteriores. Na estação de gestão está também armazenada toda a informação acerca do estado actual de funcionamento e do histórico das firewalls (informação de estado das interfaces de rede, tráfego, logs), que como será analisado na Secção 6, é transferido regularmente das firewalls para a estação de gestão. Reflectindo a natureza multidisplinar da equipa de outsourcing já referida, o controlo de acesso à Estação de Gestão segue um modelo administrativo bastante flexível e granular, sendo possível definir autorizações por utilizador, por firewall e por tarefa. É assim possível ter técnicos locais responsáveis por uma única rede (e respectivas firewalls), técnicos responsáveis por um grupo mais alargado de firewalls, e técnicos apenas com permissão de monitorização de determinadas redes. A Estação de Gestão foi implementada sobre uma distribuição de GNU/Linux, utilizando o Apache[23] como servidor Web e MySQL[24] como motor de base de dados. A lógica de programação foi implementada usando Perl[20] e SOAP::Lite[22], à semelhança do que sucede com a camada de gestão remota das firewalls. 5. Linguagem de Configuração A configuração das firewalls e respectivos serviços é normalmente feita por edição directa de diversos ficheiros de texto (geralmente um por serviço), sendo necessário dominar diversas sintaxes de configuração (algumas delas não muito intuitivas, como é por exemplo o caso do iptables) e não existindo forma de verificar automaticamente a correcção e coerência dessas configurações. Sem modificar este cenário, a plataforma de gestão remota pouco mais faria que constituir um mero terminal remoto. Foi assim decidido usar uma interface gráfica para configuração dos diversos serviços, que é depois convertida numa sintaxe intermédia com a descrição da configuração da firewall. É esta sintaxe intermédia que é reconhecida e manipulada pela estação de gestão, seja para efeitos de auditoria, seja no armazenamento na base de dados, seja na descarga de configurações para a firewall. A conversão desta sintaxe intermédia para os ficheiros de configuração de cada serviço só tem lugar na própria firewall. Esta sintaxe foi desenvolvida de raíz para os serviços mais simples (DNS, NTP, DHCP, etc.), mas no caso do iptables optou-se por adaptar o Shorewall, uma ferramenta open-source que converte regras CRC2004 4/10

de filtragem de alto nível em ficheiros de configuração do iptables, e cuja sintaxe se ajusta mais facilmente ao armazenamento em bases de dados, à transferência por rede (no nosso caso usando XML) e à manipulação por parte de administradores de redes. Para as regras de filtragem são definidas no Shorewall algumas entidades: interfaces correspondem às interfaces de rede de cada firewall; zones representam as diversas zonas lógicas na firewall: rede interna, zona desmilitarizada, internet, etc.; policies definem políticas genéricas de estabelecimento de ligações entre as diversas zonas. As opções disponíveis são accepted, denied, ou rejected; rules permitem expecificar excepções às políticas definidas anteriormente, por exemplo, para permitir tráfego de uma rede insegura para uma determinada máquina de uma rede interna. Masquerading definem regras para IP Masquerading e Source Network Address Translation (SNAT), permitindo o acesso de redes privadas a outras zonas usando translação de endereços. Tunnels definem túneis, usando IPSec, OpenVPN, PPTP ou Ipv6 para Ipv4. A linguagem extendida é a base de toda a comunicação no sistema. A Estação de Gestão cria um array associativo em Perl com toda a configuração de uma firewall, transforma-a em XML, e envia-a para a firewall correspondente usando HTTPS. A Figura 2 mostra um excerto de uma sessão de SOAP[21] entre a Estação de Gestão e a Firewall. <conf xsi:type="namesp2:soapstruct"> <zones xsi:type="soap-enc:array" SOAP-ENC:arrayType="xsd:string[2]"> <item xsi:type="xsd:string"> In.Intranet.Internal Zone </item> <item xsi:type="xsd:string"> Out.Internet.External </item> </zones> <dhcpd.conf xsi:type="soap-enc:array" SOAP-ENC:arrayType="xsd:string[4]"> <item xsi:type="xsd:string"> option domain-name "fd.uc.pt"; </item> <item xsi:type="xsd:string"> option domain-name-servers "193.136.212.2"; </item> <item xsi:type="xsd:string"> option domain-name-servers "193.136.212.22"; </item> </dhcpd.conf> </conf> Figura 2: Excerto de uma sessão de SOAP Para facilitar o debugging, o administrador pode verificar toda a informação textual (na sintaxe intermédia já mencionada) que será enviada para cada firewall, mas nunca a altera directamente: todos os ajustes de configuração são feitos por meio da Consolada de Gestão (Figura 3). 6. Firewalls As firewalls desta plataforma são firewalls comuns, baseadas em GNU/Linux, às quais foram adicionados três componentes específicos: o procedimento de distribuição/instalação remota; o suporte para uma sintaxe de configuração de alto nível; e a Camada de Gestão Remota que assegura a comunicação com a Estação de Gestão. CRC2004 5/10

6.1. Instalação Figura 3: Uma das vistas da Consola de Gestão Conforme foi já mencionado, um dos problemas a resolver era a existência de pequenas diferenças entre as firewalls, quer no variado software instalado, quer mesmo nas diferentes versões. Tornava-se difícil manter a homogeneidade nas várias instalações, dificultando upgrades e aumentando a probabilidade de problemas de segurança (por exemplo exploits detectados/corrigidos tardiamente). Além disso, a instalação manual de uma firewall era uma tarefa demorada e minuciosa, propícia a erros humanos. Desde a instalação do sistema operativo, incluindo a selecção do sofware a instalar, bem como respectivos updates, à escolha e correcta configuração dos serviços a executar, bem como os testes finais, havia muitos pontos de falha. Estas razões motivaram-nos a seguir uma via menos tradicional: dispensar o uso de discos rígidos, arrancando as firewalls directamente de um CD-ROM que contém o sistema operativo e o software adicional. Este CDROM foi feito a partir de uma distribuição Debian[16], com algumas alterações para suportar o arranque por CDROM e a os serviços adicionais para administração remota. A informação específica de cada firewall é guardada em disquete, e os logs são enviados directamente para a Estação de Gestão. Assim, para além das vantagens em termos de homogeneidade, temos ainda a vantagem de um filesystem menos atreito a corrupção ou a falhas na instalação. Adicionalmente, muitos ataques tornam-se impossíveis ou inúteis num filesystem que só permite leitura. A própria instalação fica também bastante mais facilitada: tudo o que o técnico local tem de fazer é inserir o CDROM, e fornecer a informação básica (endereços de rede e chaves de segurança). Claro que esta abordagem não é isenta de problemas, sendo o pior deles a necessidade de intervenções locais quando há necessidade de fazer upgrades de software. No cenário apresentado, dado que existe quase sempre um técnico local (ainda que nem sempre especializado em segurança), isso não é preocupante. Outro ponto que suscita algumas dúvidas é a fiabilidade dos CDROMs. Apesar de não termos encontrado estudos que comparem a fiabilidade de CDROMS com a de discos rígidos, acreditamos que sejam comparáveis. Apesar disso, falhas num CDROM são mais fáceis de detectar e corrigir, ao contrário de falhas num disco rígido, que se podem traduzir na gradual corrupção do filesystem, por vezes detectada muito tempo depois de se ter manifestado. Outros cenários poderão eventualmente justificar o uso de sistemas que suportem leitura e escrita e fiabilidade acrescida, utilizando por exemplo memórias FLASH ou RAM drives, bem como gestão com mecanismos PreOS [17] que suportem updates dinâmicos, possivelmente com suporte de hotswapping[18]. CRC2004 6/10

6.2. Suporte para Configuração de Alto Nível Tal como foi já mencionado, a tradução da sintaxe de alto nível usada pela estação de gestão para descrever a configuração da firewall só é traduzida para os clássicos ficheiros de configuração de cada serviço na própria firewall, por meio de um módulo especifico desenvolvido em Perl e aproveitando, no caso específico das regras de iptables, algum código do Shorewall. 6.3. Camada de Gestão Remota A camada de gestão remota das firewalls está encarregue de receber a configuração vinda da Estação de Gestão e de a converter na configuração de cada serviço. Essa mesma configuração é escrita na disquete é lida a cada arranque. Se não houver uma configuração na disquete ou se existirem diferenças entre a configuração local e a configuração armazenada no servidor central, as configurações remotas são recebidas e aplicadas. Durante a utilização normal, os updates são despoletados a intervalos regulares pela Estação de Gestão. A Camada de Gestão Remota também está encarregue do envio de dados de monitorização para a estação central, incluindo informação sobre o estado de funcionamento das firewalls, verificação da respectiva integridade, logs relativos a toda a actividade nas firewalls e medições de tráfego. A transferência de configurações da Estação Central para a firewall e o envio de dados de monitorização de alto nível, no sentido inverso, são efectuados usando SOAP/XML sobre HTTPS. A transferência dos logs não processados é efectuada por meio de um túnel SSL. Uma vez que os túneis SSL se restringem ao transporte sobre TCP, e que o tradicional syslog[1] não suporta este protocolo de transporte, optou-se pelo syslog-ng[2]. No servidor central existe um directório para cada firewall que contém um ficheiro para cada log facility. Utilitários como o logrotate podem assim ser usados para gerir, na estação central, os logs recebidos das diversas firewalls. 6.4. Verificação de configuração As configurações de uma dada firewall são armazenas na base de dados relacional da Estação Central à medida que são editadas. No momento do envio para a firewall, estas são traduzidas da base de dados para ficheiros de configuração escritos na linguagem intermédia já mencionada. Como foi já mencionado, a conversão final nos ficheiros de configuração de cada serviço é ocorre apenas na própria firewall. A Estação de Gestão executa periodicamente um script que verifica a configuração efectiva de cada firewall, de modo a garantir a coerência entre a configuração armazenada na base de dados e a configuração em uso na firewall. Se o servidor detectar divergências entre as duas configurações tenta repôr a configuração original e alerta o administrador para investigar as razões dessa divergência. Figura 4: Histórico de polling CRC2004 7/10

Para optimizar o tráfego de rede, esta verificação é feita com base na comparação de dois hash MD5, um gerado pela firewall com base na configuração disponível e outro pela Estação de Gestão com base na informação mantida na base de dados. Os resultados desta monitorização (incluindo a impossibilidade de contactar as firewalls para solicitar o hash da configuração) são armazenados no histórico de polling na base de dados (Figura 4). 6.5. Tráfego Para não degradar o desempenho das firewalls e da própria rede, a monitorização de tráfego das firewalls é bastante simplista, servindo apenas para que os administradores tenham uma percepção da da largura de banda ocupada em cada um dos interfaces da firewall. Em cada firewall é executado periodicamente um script que regista o tráfego enviado e recebido em cada interface, possibilitando o posterior envio dessa informação para a Estação de Gestão, para consulta por parte dos administradores (Figura 5). Esta camada consiste também em vários scripts em Perl[20], usando uma interface em XML/SOAP[21] sobre HTTPS, recorrendo ao SOAP::Lite [22]. Figura 5: Gráfico de Tráfego CRC2004 8/10

6.6. Redes Privadas Virtuais Uma das funcionalidades mais interessantes da plataforma é a simplificação do processo de definição de redes privadas virtuais (VPNs) entre firewalls, usando IPSEC (implementação FreeS/WAN). Para definir uma VPN entre duas firewalls geridas pela plataforma basta seleccionar na consola Web a rede protegida pela firewall que está a ser configurada, a firewall remota e a rede protegida por essa firewall, nas configurações de ambas firewalls. Podem ser definidas várias VPNs entre as várias redes das várias firewalls do sistema, existindo também a possibilidade de configurar uma rede privada virtual entre uma rede protegida por uma firewall do sistema e qualquer outro tipo de rede com suporte IPSEC no seu gateway, indicando os vários parâmetros de configuração do FreeS/WAN. 7. Conclusão Figura 5: Configuração de VPNs Nesta comunicação foi apresentada uma plataforma para gestão integrada de firewalls. Esta plataforma constitui uma extensão às firewalls open-source tradicionais, adicionando-lhes funcionalidades de configuração e monitorização remotas, um interface de configuração mais intuitivo e menos propício a erros, e redução dos custos de manutenção. Ainda que esteja relativamente próxima de algumas soluções comerciais, e apesar das semelhanças com algumas abordagens de Policy-based Networking, esta plataforma distingue-se pelo pragmatismo das suas soluções. Simplificando na redução dos custos de gestão e na facilidade de utilização, sacrifica a heterogeneidade e uma maior abstracção na linguagem configuração mas possibilita a construção de uma plataforma simples e barata com um esforço relativamente baixo. A plataforma está neste momento a ser testada em ambientes de produção, com resultados satisfatórios, quer em termos de redução de custos operacionais quer na melhoria da segurança das redes geridas. REFÊRENCIAS [1] Checkpoint Software Technologies, http://www.checkpoint.com/ [2] NetScreen Firewall, http://www.netscreen.com/products/firewall/ [3] Cisco Secure Policy Manager, http://www.cisco.com [4] Clavister Firewall-SW Series, http://www.clavister.com/ [5] D. Kosiur, Understanding Policy-Based Networking (Willey, 2001). [6] F. Caldeira & E. Monteiro, A Policy-Based Approach to Firewall Management, Proc. of NetCon2002, Network Control and Engineering for QoS, Security and Mobility with focus on Policy-based Networking, Kluwer Academic Publishers, Paris, 2002. CRC2004 9/10

[7] V. Kurland & V. Zaliva, Firewall Builder Project, http://www.fwbuilder.org [8] Filter Language Compiler, http://coombs.anu.edu.au/~avalon/ [9] S. Chudley & U. Ultes-Nitsche, An XML-based Approach to Modeling and Implementing Firewall Configurations, Proc. of ISSA 2002 Information Security Conference, África do Sul, Julho de 2002. [10] netfilter/iptables Homepage, www.netfilter.org/ [11] Linux FreeS/Wan Project, http://www.freeswan.org/ [12] OpenVPN Project, http://openvpn.sourceforge.net/ [13] Linux Router Project, http://www.linuxrouter.org/ [14] SmoothWall Project, http://www.smoothwall.org [15] Leaf, Linux Embedded Appliance Firewall, http://leaf.sourceforge.net [16] Debian Project, http://www.debian.org/ [17] T. Cruz, P. Simões, Enabling PreOS Desktop Management, Proc. of the 8th IFIP/IEEE International Symposium on Integrated Network Management (IM'2003), Kluwer Academic Press, Março de 2003. [18] N. Feng, A. Gang, T. White and B. Pagurek, Dynamic Evolution of Network Management Software by Software Hot-Swapping, Proc. of the 7th IFIP/IEEE International Symposium on Integrated Network Management (IM 2001), Maio de 2001. [19] Shorewall Project Homepage, http://www.shorewall.net/ [20] Perl, http://www.perl.com [21] Simple Object Access Protocol (SOAP) 1.1, http://www.w3.org/tr/soap/ [22] SOAP::Lite, http://www.soaplite.com [23] Apache Software Foundation, http://www.apache.org [24] MySQL Database Server, http://www.mysql.com [25] HLFL, High Level Firewall Language, http://www.hlfl.org/ CRC2004 10/10