Hugo Leonardo Prado Ribeiro Vuurmuur: Firewall sem complicações

Transcrição

1 Hugo Leonardo Prado Ribeiro Vuurmuur: Firewall sem complicações Maringá Julho/2005

2 Hugo Leonardo Prado Ribeiro Vuurmuur: Firewall sem complicações Professor Orientador: Flávio Arnaldo Braga da Silva Cesumar - Centro Universitário de Maringá Maringá Julho/2005

3 This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike License. To view a copy of this license, visit or send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA.

4 Ao meu lho Gustavo, que deu por si o maior presente que um homem pode ganhar. À minha alma-gêmea Fer, que conseguiu fazer de mim a pessoa mais feliz do mundo.

5 Agradecimentos Primeiramente a Deus, que me deu a capacidade e esperança necessária para chegar até aqui. À Fer, que entendeu todo meu stress durante a produção deste documento. Aos meus pais, por terem me dado a formação responsável pelo que sou hoje. Ao fundão, por termos proporcionado suporte um ao outro para chegarmos até aqui, e pelos encontros diários mais `produtivos' da face da terra. Ao meu professor orientador Flávio, por sugestões e observações vitais para a boa composição deste trabalho. A todos os professores que passaram, com exceção de alguns. À Márcia Pascutti, por ter entendido minha mudança de proposta na última hora. Ao Victor Julien, pelas 2 imagens que eu não tinha, pelo amplo suporte na solução de dúvidas na elaboração deste, e por ter feito o Vuurmuur, possibilitando que eu escrevesse tudo isto. Ao Adi Kriegisch, pelas imagens cedidas para a criação da seção Finalmente, à Joseph Schumpeter (o original), por facilitar tanto a forma de chamar os amigos.

6 Watching the sky while I try to stay on solid ground. Raised Fist

7 Resumo Este trabalho é sobre o Vuurmuur, um front-end para Iptables que adiciona inúmeras funcionalidades ao mesmo. Iremos ver toda sua forma de funcionamento e sua losoa de objetos, além de abordar, de forma fácil e explicativa, todos os passos necessários para se montar um rewall decente, sem precisar dos conhecimentos especícos do Iptables.

8 Abstract This study is about Vuurmuur, an Iptables front-end that adds many new functions to it. We will look at the way of Vuurmuur works and your object philosophy. Also, we will see, in an easier and explicative way, all the necessary steps to make a decent rewall, but without need specic Iptables knowledge.

9 Sumário Lista de Figuras Lista de Tabelas 1 Introdução p Objetivos p Gerais p Especícos p Estrutura p Firewall p Vuurmuur p Justicativa p Firewall p Filtro de Pacotes p Iptables p Evolução dos mecanismos de ltragem p A ltragem tradicional p Novas implementações do iptables p Extensões de controle de protocolos p Novos alvos p Novas associações p Regras p. 22

10 Forma culta: Iptables-save, Iptables-restore..... p Forma prática: script p Vuurmuur p Conhecendo p Entendendo p Interfaces p Serviços p Hosts p Grupos p Redes p Zonas p Juntando tudo isto p Pequenos detalhes p Instalando p A partir do código fonte p Autopackage e binários diversos p Conhecendo menus e opções p vuurmuur p vuurmuur_log p vuurmuur_script p vuurmuur_conf p Vuurmuur Cong p Logview p Status p Connections p Bandwidth p. 63

11 Vuurmuur_conf Settings p Sobre os idiomas p Montando o cenário-exemplo p Elaborando o projeto p Interfaces p Services p Zones p Blocklist p Rules p Limitações e Contribuição p Conclusão p. 109 Referências p. 111

12 Lista de Figuras 1 Rede simples p Rede simples com Zonas p Rede simples com Zonas e Redes p Rede simples com Host p Rede simples com Host, Redes e Zonas p Descompactando o código-fonte p Opções do install.sh p Instalação em andamento p Binários do Vuurmuur p Opções do daemon vuurmuur p Primeira tela: vuurmuur_conf p Avisos do vuurmuur_conf p Criação de regras p Lista de bloqueados p Criação de zonas, redes, grupos e hosts p Criação e manipulação de interfaces p Criação de serviços p Opções do Vuurmuur p Vuurmuur Cong: General p Vuurmuur Cong: Connections p Vuurmuur Cong: Interfaces p Vuurmuur Cong: System Protection p. 51

13 23 Vuurmuur Cong: Logging p Vuurmuur Cong: Modules p Vuurmuur Cong: Plugins p Vuurmuur Cong: Aviso sobre módulos não presentes p Vuurmuur Cong: Capabilities p Logview p Logview: vuurmuur.log p Logview: trac.log p Vuurmuur_conf: Status p Connections: Visualização em tempo real p Connections: in/out/fw p Connections: connect status p Connections: group unknown p Connections: campo `status' aparecendo p Trac Log Volume p Vuurmuur_conf: Settings p Vuurmuur_conf em Português do Brasil p Interfaces: Atribuindo um nome p Interfaces: Denindo propriedades p Interfaces criadas p Serviços: grande quantidade de serviços pré-denidos p Serviços: Adicionando um novo serviço p Serviços: Diálogo de propriedades p Serviços: Denindo portas p Serviços: Portas de Origem e Destino p Serviços: Portranges denidos p. 76

14 49 Zonas: Denindo um nome p Zonas: Adicionando p Zonas: Projeto simples p Zonas: Redes p Redes: Adicionando p Redes: Adicionando rede Internet p Redes: Atribuindo interfaces p Redes: Criando a rede `servers' p Redes: Criando a rede `clientes' p Zonas: Duas redes em uma mesma zona p Hosts: Adicionando p Hosts: Amanda.clientes.interno p Hosts: Lista de hosts p `Hosts' na Internet p Grupos p Grupos: Informatica p Grupos: Simples e objetivos p Grupos: Criação p Grupos: Seleção de membros p Grupos: Agrupamento de semelhanças p Blocklist: Endereço IP, host ou grupo p Blocklist: Bloqueio simples e fácil p Rules: Criação de regras no Vuurmuur p Rules: Inserindo uma regra p Rules: target DROP p Rules: Hosts, grupos, redes e zonas p. 94

15 75 Rules: Primeira regra p accept any from informatica.clientes.interno to any p Rules: Duas regras p Linha separadora p Regra três p Regra quatro p Regra cinco p Regra seis p Regra sete p Regra oito p Regra nove p Encaminhamento de portas p Rules: portforward simples p Rules: IBM ping p Rules: SSH p SNAT p Liberação de regras para o rewall p Snat no topo das regras p About p. 108

16 Lista de Tabelas 1 Clientes: Hosts, Ips e Departamento p Servidores: Hosts e Ips p. 68

17 16 1 Introdução Atualmente, o quesito segurança têm-se tornado grande preocupação dos usuários de computadores, no que diz respeito à exposição de seus dados, uma vez que, cada vez mais, o computador se torna ferramenta essencial na produção de documentos que virão a se tornar condenciais ou importantes. Neste contexto, a Internet se mostra um dos principais pontos desta preocupação, pois é onde se encontram os maiores perigos, e também o maior número de usuários conectados entre si. Além da Internet, a segurança de dados também se aplica a diversos outros fatores, como a própria LAN 1, onde os usuários estão sujeitos à más intenções de outros, além de possíveis danos na segurança causados por fatores físicos, que vão desde o bom funcionamento do hardware, até a invasão do local físico onde está situado o equipamento (roubo da máquina, por exemplo). Com a grande popularização da Internet nos últimos anos, o número de pessoas conectadas à grande rede aumentou exponencialmente, fazendo com que cada vez mais fosse possível encontrar de tudo com poucos cliques. Ao mesmo tempo, crescia de forma oculta uma legião de pessoas mal intencionadas, que veio a resultar neste grandiosíssimo problema que temos hoje, o da segurança. Hackers, crackers, curiosos e bisbilhoteiros cada vez mais se interessam pela descoberta de falhas de segurança, falhas de administradores de rede ou qualquer outro fator que possa se tornar uma brecha para qualquer tipo de ação ofensiva, seja ela um simples ood, a exploração de uma falha, o comprometimento de um serviço ou a tomada completa de um sistema. Com isto, na intenção de implementar uma possibilidade de controle sobre o que entra e sai de uma rede/host, surgiram os ltros de pacotes, dentre quais podemos citar os três mais bem-sucedidos: ipfwadm (Linux kernel 2.0.x), ipchains (Linux kernel 2.2.x), e o atual iptables (Linux kernels 2.4.x e 2.6.x). Filtros de pacotes são, de modo grosseiro, funções de registro implantadas no kernel 2, que permitem-no saber cada pacote que passa por ele, podendo então, com base em uma lista de regras, autorizá-lo ou não a seguir seu destino pré-especicado, bem como alterar 1 Local Area Network 2 Núcleo principal do sistema Linux

18 1.1 Objetivos 17 alguns de seus valores. O iptables é uma ótima ferramenta para isto, sendo padrão na grande maioria das implementações de rewall feitas em Linux. Apesar da grande habilidade do netlter/iptables em manusear os pacotes de acordo com as regras estabelecidas, ele não fornece nenhuma interface amigável para a criação e manuseio destas regras, bem como o acompanhamento de registros em tempo real do que está sendo processado pelo rewall. 1.1 Objetivos Gerais Este trabalho tem como foco a apresentação geral da ferramenta chamada Vuurmuur, que se trata de um front-end 3 para o iptables, e que implementa várias funcionalidades e facilidades num nível mais alto do que a fornecida pelo mesmo, visando facilitar a vida do administrador de redes, e ao mesmo oferecer-lhe novas possibilidades com suas funções, que serão devidamente apresentadas adiante Especícos Os objetivos especícos deste trabalho se resumem única e exclusivamente à: a) Apresentar a ferramenta, com suas funções, capacidades e limitações; b) Abordar a sua instalação (a partir de código-fonte), com todas as opções e possibilidades; c) Exemplicar sua forma de conguração e demonstrar seus recursos, criando um cenário-exemplo que suporte tal objetivo. Não é objeto do escopo deste trabalho pôr em prova o sucesso de funcionamento das ferramentas Vuurmuur e Iptables, cando assim claro o objetivo deste trabalho, que é o de apresentação da ferramenta Vuurmuur. 3 Interface que coleta dados, geralmente de forma facilitada em relação ao programa original, formataos segundo os padrões desse programa, e repassa-os a ele.

19 1.2 Estrutura Estrutura Para que se possa causar um melhor dimensionamento deste trabalho, o mesmo será segmentado em 2 grandes grupos distintos: Firewall Neste capítulo, estaremos apresentando um breve descritivo sobre ltros de pacotes e o próprio iptables, necessários para o entendimento da forma de funcionamento de um rewall Vuurmuur Esta parte do trabalho será exclusivamente dedicada ao objeto do trabalho: apresentação, implementação, conguração e criação do cenário-exemplo para o Vuurmuur. 1.3 Justicativa Atualmente, tantos são os problemas do administrador de redes, tantas são suas preocupações, que acabam fazendo do tempo uma preciosidade, que deve ser muito bem aproveitada. Neste contexto, uma ferramenta que facilita tanto a administração do rewall, especialmente em grandes redes, e que, especialmente, poupa tempo do administrador, consta de grande utilidade. Além disto, é uma ferramenta relativamente nova, mas que já faz por merecer destaque dentre as semelhantes em sua categoria.

20 19 2 Firewall Firewall, em inglês, signica "Parede de Fogo", e atualmente é um item indispensável de segurança para empresas, redes corporativas e usuários domésticos. Os rewalls usam um ltro de pacotes para tomarem suas decisões, podendo até ter como base de escolha análises complexas de propriedades de protocolos. 2.1 Filtro de Pacotes Um ltro de pacotes é um software que analisa o cabeçalho (header) dos pacotes que processa, e decide o que fazer com ele (1). De acordo com a análise feita, variadas ações poderão ser tomadas, como descartar completamente o pacote, sem sequer avisar o remetente, rejeitá-lo, enviando uma mensagem ao remetente, deixá-lo passar, entre muitas outras opções, também conhecidas, ao menos nos ltros de pacotes Linux, como targets. No Linux, o ltro de pacotes pode estar disponível de duas formas: compilado diretamente no kernel ou como módulo. Ou, até mesmo, ter parte compilada diretamente no kernel, e algumas funções compiladas como módulos. 2.2 Iptables Conforme relatado por Russel (1), os kernels Linux têm tido ltros de pacotes desde a série 1.1. A primeira geração, baseada no ipfw do BSD, foi portada por Alan Cox no nal de Essa implementação foi melhorada por Jos Vos e outros para o Linux 2.0, gerando a `ipfwadm', que controlava as regras de ltragem do kernel. Em meados de 1998, Rusty Russel e Michael Neuling reescrevem novamente linhas de código do kernel, e introduzem a ferramenta `ipchains', com vários aprimoramentos, para o kernel 2.2. Finalmente, a ferramenta da quarta geração, o `iptables', após mais um árduo trabalho de reedição do

21 2.2 Iptables 20 kernel, é introduzida em meados de 1999 para o Linux 2.4, e consta até hoje, nos kernels 2.6. O iptables introduziu várias novas funções, como a já mencionada modularização de recursos, a inspeção de estados de pacotes (Statefull Inspection), dentre outras opções sosticadas de ltragem. Para tal, é necessário um kernel que possua a infra-estrutura netlter 1 implementada. Isso signica que você precisa do kernel ou posteriores, e responder 'Y (SIM)' para CONFIG_NETFILTER na sua conguração do kernel. A ferramenta iptables se comunica diretamente com o kernel (através do netlter)e indica, segundo suas regras, quais pacotes deverão ser ltrados, e quais ações deverão ser tomadas para eles Evolução dos mecanismos de ltragem Conforme composto no trabalho de Vianna(2), a evolução dos mecanismos de ltragem para os ltros de pacotes do Linux se deu da seguinte forma: A ltragem tradicional A ltragem de pacotes implementada desde o kernel 2.0 dispõe de três listas de regras na tabela lter (módulo especíco do kernel para ltragem de pacotes); tais listas são denominadas rewall chains (ou simplesmente chains). As três chains básicas são INPUT, OUTPUT e FORWARD. Quando o pacote atinge uma chain no diagrama, a chain é examinada a m de que seja decidido o destino do pacote. Se a chain aponta para descartar (DROP) o pacote, ele é descartado, mas se a chain aponta para aceitar o pacote (ACCEPT). Uma chain é uma lista de regras. Cada regra pode ser interpretada como uma condição do tipo: `se o cabeçalho do pacote se parece com isso, aqui está o que deve ser feito com o pacote'. Se a regra não se associa com o pacote, então a próxima regra na chain é consultada. Não havendo mais regras a consultar, o kernel analisa a política da chain para decidir o que fazer. Como apresentado anteriormente a chain pode ter 2 tipos de política: `Tudo o que não for expressamente proibido é permitido' ou `Tudo o que não for expressamente permitido é proibido'. Quando o pacote chega ao computador, pela placa ethernet, por exemplo, o kernel analisa o seu destino, num processo denominado roteamento (routing). Segue-se então a decisão de roteamento, onde é realizado o repasse (FORWARD), ou, caso o pacote se destine à própria máquina, o encaminhamento à chain INPUT. Ao chegar nestas chains, o pacote passa por regras especícas que decidirão o seu destino (aceitar ou descartar). 1 Netlter é um framework dentro do kernel Linux com o qual outras coisas (como o módulo do iptables) podem conectar-se.

22 2.2 Iptables Novas implementações do iptables Além dos recursos das soluções de ltragem de pacotes que o antecederam, o iptables (com o suporte do Netlter) é extensível, isto é, dispõe de suporte a módulos adicionais, proporcionando várias outras funcionalidades. Estes módulos podem ser carregados `por demanda', de acordo com a necessidade de ltragem. Estas extensões são classicadas em três tipos: - Extensões de controle de protocolos (-p) - Novos alvos (-j) - Novas associações (-m) Extensões de controle de protocolos Extensões TCP As extensões TCP são automaticamente carregadas quando especicada a opção -p tcp e dispõe das seguintes opções: --tcp-flags: Permite que sejam ltradas ags TCP especícas. --source-port: Indica uma porta ou conjunto (range) de portas TCP de origem. --destination-port:indica uma porta ou conjunto (range) de portas TCP de destino. --tcp-option: Utiliza-se de números especícos para controlar (e eventualmente descartar) pacotes com a opção TCP igual ao do número informado. Um pacote que não tem um cabeçalho TCP completo é automaticamente descartado se há uma tentativa de examinar suas opções TCP. Extensões UDP Essas extensões são automaticamente carregadas se a opção -p udp é especicada. Permite as opções --destination-port e --source-port. Extensões ICMP Essas extensões são automaticamente carregadas se a opção -p icmp é especicada. Possui uma só opção diferente das demais extensões: --icmp-type: Controla o tipo de conexão ICMP baseado no nome de tipo ou tipo numérico comumente utilizado em conexões deste tipo Novos alvos Os alvos (targets) indicam `o que fazer' com o pacote caso coincida com as condições da regra. Os alvos padrões embutidos no iptables são: DROP (descartar) e ACCEPT (aceitar). Se a regra se associa com o pacote e seu alvo é um desses dois, nenhuma outra regra é consultada: o destino do pacote já foi decidido. Há dois tipos de alvos diferentes dos descritos acima: as chains denidas por usuários e as extensões. 1. Chains denidas por usuários Uma funcionalidade que o iptables herdou do ipchains é a possibilidade da criação de novas chains, além das três disponíveis (INPUT, FORWARD e OUTPUT). Quando um pacote associa-se com uma regra cujo alvo é uma chain denida pelo usuário, o pacote passa a ser analisado pelas regras dessa nova chain.

23 2.2 Iptables Extensões ao iptables: Novos alvos (targets) O outro tipo de alvo é a extensão. Uma extensão-alvo consiste em um módulo do kernel, opcional ao iptables, para prover opções de linha de comando. As extensões na distribuição padrão do netlter são: LOG: Esse módulo provê o registro em logs dos pacotes submetidos, possuindo as seguintes opções adicionais: log-level: Seguido de um número de nível ou nome. log-prex: Seguido de uma string de até 29 caracteres, que será adicionada no início da linha de registro de log (syslog), permitindo melhor identicação da mesma. REJECT: Esse módulo tem o mesmo efeito do alvo `DROP', porém, retorna uma mensagem de erro ao remetente, rejeitando o pacote. O REJECT era um alvo nativo no ipchains. Porém, pela semelhança com o DROP, (além da pouca utilização), foi disponibilizado no iptables como uma extensão opcional Novas associações Estes tipos de extensões, no pacote netlter, podem ser habilitadas com a opção -m. Estas funcionalidades adicionais permitem um controle mais detalhado dos pacotes, não se detendo ao cabeçalho, analisando informações em seu conteúdo. mac: Utilizado para associar a regra com o endereço Ethernet (MAC) da máquina de origem do pacote (--mac-source). limit: Utilizado para restringir a taxa de pacotes, e para suprimir mensagens de log. owner: Associa a regra a várias características do criador do pacote gerado localmente. state: Interpreta a análise do controle da conexão feita pelo módulo ip_conntrack Regras Não será abordado aqui a sintaxe de criação de regras do iptables, uma vez que isto é uma das facilidades oferecidas pelo programa a ser abordado neste trabalho, ou seja, a não-obrigação do usuário em saber exatamente a sintaxe do programa. Entretanto, vale observarmos a forma em que o iptables trabalha com as regras, de forma a entendermos exatamente o que acontece quando `informamos' as regras ao iptables. Quando você digita um comando do iptables na linha de comando, ele, através do netlter, `implanta' esta regra diretamente no kernel, que passa a aplicá-la para cada

24 2.2 Iptables 23 pacote que passar por ali. Por este motivo, cada vez que a máquina é reiniciada, as regras são automaticamente apagadas. Para que, ao criar e denir suas regras de rewall, você não necessite fazê-la novamente caso seja preciso reiniciar a máquina, ou até mesmo para que você não que com sua máquina exposta caso ela, por qualquer motivo, reinicie durante algum período em que você não está por perto, você deve arrumar alguma forma de dizer para o iptables recarregar estas regras no boot da máquina. Mas como isto é feito? Forma culta: Iptables-save, Iptables-restore A partir do iptables (mas não em seu início), foram introduzidas as ferramentas iptables-save e iptables-restore. Essas duas ferramentas vieram para `resolver' o problema citado anteriormente. A ferramenta iptables-save, como se auto explica, salva as regras num arquivo texto indicado, usando a seguinte sintaxe: iptables-save > regras.iptables (poderia ser qualquer nome) Este comando gera um arquivo, com uma formatação própria, para ser utilizado com iptables-restore. A sintaxe do iptables-restore é igualmente simples: iptables-restore regras.iptables ou iptables-restore < regras.iptables Simples, não? Montamos nossas regras, através da digitação das mesmas diretamente no console, salvamo-as utilizando o iptables-save e, após isso, colocamos o iptables-restore na inicialização do sistema, recuperando o arquivo salvo de regras Forma prática: script O caso que acabou de ser citado é fácil de se fazer, e as duas ferramentas funcionam muito bem. Porém, vamos considerar o seguinte exemplo:

25 2.2 Iptables 24 Em uma rede, constantes mudanças podem acontecer em relação às regras de rewall, como inclusão/exclusão de hosts autorizados/proibidos, mudanças de encaminhamento de portas, enm, alterações de regras diversas. Neste caso, o que o administrador de redes fará? Se ele quiser utilizar o conjunto iptables-save + iptables-restore, ele deverá listar as regras, apagar as que não servirem mais, inserir as novas regras na ordem correta, e salvar o arquivo novamente, para poder ser utilizado no próximo boot. Na prática, quase nenhum administrador se dá a este trabalho. A solução mais comum é desenvolver um script (geralmente em bash 2 ) que, quando executado, limpe todas as regras, e aplique as novas, que estarão listadas neste mesmo script. 2 Bourne Again Shell, a shell mais utilizada no Linux.

26 25 3 Vuurmuur Como foi mencionado, as ferramentas iptables/netlter formam um excelente conjunto de ltro de pacotes, que podem ser usadas de forma extremamente eciente como rewall. Entretanto, o iptables não oferece uma forma amigável de criação e manipulação destas regras, no que diz respeito à forma de entrada das mesmas junto ao netlter/kernel, à praticidade de mudanças, e o estabelecimento de padrões que facilitem a vida do administrador. Da vontade de se projetar uma forma de criar ambientes mais complexos e práticos de regras, juntamente com a vontade de se oferecer um programa que também fosse acessível à pessoas que não tem conhecimento da complexa linguagem do iptables, surgiu o Vuurmuur, que é o objeto principal deste trabalho. Tentaremos cobrir ao máximo a explicação de seus recursos, bem como instalação e conguração, de forma a montar um ambiente seguro, porém de forma prática, dinâmica e facilitada. 3.1 Conhecendo Vuurmuur é uma palavra alemã que signica, que surpresa, rewall. Foi idealizado e criado pelo holandês Victor Julien, que o mantém até hoje, com a contribuição de pessoas da comunidade. É um programa feito em C para o sistema operacional Linux e utiliza a biblioteca ncurses para o GUI 1. É um projeto open-source do portal Sourceforge, e é disponibilizado sob a GNU GPL. No momento em que está sendo escrito este trabalho, ele se encontra em sua versão beta , porém são lançadas novas versões constantemente. Todas as informações sobre o Vuurmuur podem ser encontradas em sourceforge.net/. Segundo as próprias descrições do criador, o Vuurmuur é um middle-end/front-end 1 Graphical User Interface, ou `Interface Gráca para o Usuário'

27 3.1 Conhecendo 26 para iptables para o administrador de redes que precisa de um rewall decente, mas não possui os conhecimentos especícos do iptables. Na verdade, o Vuurmuur, como já foi mencionado, ultrapassou este objetivo, e conquistou também administradores de rede que têm conhecimentos de iptables, mas viram em suas funcionalidades possibilidades de criação (e também alteração) de ambientes de forma simples, rápida e prática. Alguns recursos do Vuurmuur: - Novos conceitos para a manipulação de objetos, como a criação de hosts, grupos, redes e zonas - Pré-denição de serviços/portas de forma fácil - Criação de regras de forma intuitiva, simples e organizada - Visualização de logs e pacotes sendo processados em tempo real - Fácil mudança de regras, necessárias em eventuais casos onde é preciso agir na hora - Extensa exibilidade para personalizações - Disponível atualmente em 5 diferentes línguas 2. O Vuurmuur é dividido atualmente em três partes principais (que são também os binários executáveis): - vuurmuur_conf: o front-end, onde é feita a administração do rewall, criação de hosts/grupos/redes/zonas, criação de regras, denição de opções, aplicação de alterações, enm, a maioria das coisas relacionadas diretamente com o iptables; - vuurmuur: o middle-end, que se encarrega de processar todas as inclusões e modi- cações feitas no vuurmuur_conf: converter o esquema de regras/serviços/objetos em regras no formato do iptables e aplicá-los; e carregar arquivos auxiliares ao funcionamento do iptables, como módulos adicionais; - vuurmuur_log: o terceiro componente, que faz a conversão do log do iptables para um formato de fácil leitura, que condiz com os objetos criados no vuurmuur_conf. 2 Inglês, holandês, russo, alemão e português do Brasil, para o módulo de conguração.

28 3.2 Entendendo 27 Adicionalmente temos também, ainda em fase de desenvolvimento, o utilitário chamado vuurmuur_script, feito para possibilitar alterações através da linha de comando, podendo assim ser usado para automatizar tarefas em outros programas. 3.2 Entendendo Antes que se possa iniciar o uso do Vuurmuur, é necessário que se entenda sua losoa, podendo assim aproveitar todos seus recursos, am de evitar confusões em seus conceitos e na criação de regras, que podem facilmente acontecer caso não se projete seu cenário antes da criação de regras. O Vuurmuur trabalha com 6 objetos, que são a base para a criação de todas as regras. São eles: 1. Interfaces 2. Serviços 3. Hosts 4. Grupos 5. Redes 6. Zonas. Antes de explicarmos estes objetos, vale lembrar que, para todos, o nome atribuído à ele na hora da criação, será o mesmo referenciado para a criação da regra. Portanto, é sempre interessante a idéia de se utilizarem nomes intuitivos Interfaces Interfaces: são as interfaces de rede propriamente ditas do computador, as interfaces físicas. Exemplo: eth1, ppp0, tun0, eth0:0. Note que foi citada uma interface virtual no exemplo, a eth0:0. O Vuurmuur aceita normalmente interfaces virtuais, porém, na hora de sua nomeação, não poderá ser usado o ":" no nome. Veremos isso na montagem do cenário-exemplo. O Vuurmuur também aceita o uso de interfaces em que o IP é dinâmico; neste caso, o vuurmuur monitorará a interface em um tempo pré-especicado de tempo para possíveis

29 3.2 Entendendo 28 mudanças de endereço. Um exemplo bastante prático para esta opção são as máquinas que recebem um IP válido dinâmico do modem ADSL Serviços Serviços podem ser daemons especícos rodando em sua própria máquina, como sshd, apache, samba, ou também serviços que estão disponíveis fora de sua rede, como IRC, cvs, jabber, etc. Serviços nada mais são do que denições de portas e protocolos utilizados para determinado m. Sendo assim, para cada porta utilizada, esta deverá ter um serviço associado à ela Hosts Hosts são os computadores da rede, ou cada dispositivo que tenha um endereço IP, como impressoras, switches, roteadores. Na conguração dos hosts, informamos apenas um nome, seu endereço IP e, opcionalmente, seu endereço MAC. Com o uso do endereço MAC, aumentamos o nível da segurança, dicultando IP Spoongs Grupos Grupos são uma mera forma de referenciarmos vários hosts de uma vez. Em sua conguração, apenas informamos seu nome, e seus membros. Vale a observação de que um host poderá estar em mais de um grupo Redes Aqui as coisas começam a mudar em relação à forma de agir no iptables. Na denição de uma rede, você deverá informar o endereço de rede propriamente dito, a máscara de rede e ao menos uma interface. É aqui que está o segredo do Vuurmuur para o controle: a adição de hosts é feito sob alguma rede, ou seja, todo host só pode ser cadastrado como pertencendo à determinada rede, e então é vericado se o endereço do 3 Caso isto aconteça, é importante que se tenha maior atenção na criação das regras, para que não se bloqueie e autorize o mesmo host.

30 3.2 Entendendo 29 host é compatível com o endereço da rede, que por sua vez, deve ser compatível com o endereço da Interface. Exemplo: Você adiciona uma rede, lan, por exemplo, que tem o endereço e máscara Você somente poderá atachar à ela uma interface com um endereço que esteja dentro deste intervalo. Da mesma forma, na hora de adicionar os hosts, só serão permitidos hosts que façam parte da rede / Veremos que os endereços fora da sua rede e a Internet formam um caso à parte. Neste caso, a Rede `internet', por exemplo, tem o endereço Sendo assim, será possível cadastrar qualquer endereço da Internet como sendo um host Zonas Zonas são como recipientes globais para redes. Da mesma forma que os hosts, toda Rede deve ser cadastrada como sendo pertencente à uma Zona. Obviamente, poderemos ter várias Redes dentro de uma mesma zona. Exemplo: em uma empresa, existem 3 segmentos de rede diferentes: uma para os servidores de , outra para os servidores de arquivo, e uma outra para os usuários. Sendo assim, seria conveniente que você tivesse 2 zonas: uma Zona `servidores' contendo as redes `mailservers' e `leservers', por exemplo, e uma segunda zona, `lan'. Note que estas combinações de grupos, redes e zonas dão uma enorme exibilidade ao administrador de redes para a organização de seus hosts, segundo seus ilimitados critérios de separação. Mais à frente, veremos como isso se torna útil e importante no projeto da elaboração de um rewall bem congurado Juntando tudo isto Para que não quem dúvidas à respeito da losoa de objetos do Vuurmuur, vamos analisar o seguinte exemplo, simples, mas suciente para que se entenda melhor a idéia adaptado da própria página do Vuurmuur (3): Vamos considerar este exemplo da gura 1: Figura 1: Rede simples

31 3.2 Entendendo 30 Este é um exemplo simples, onde temos a Internet e a nossa rede separada pelo nosso rewall. Iremos, agora, denir duas Zonas: `int' e `ext', que poderiam signicar `interno' e `externo', respectivamente. Note na gura 2 a representação através das linhas vermelhas. Como mencionado na subseção (p.29), observe que elas agem como grandes recipientes, sendo a `maior entidade' de nossos objetos: Figura 2: Rede simples com Zonas Vamos adicionar duas redes, uma em cada zona: iremos chamar estas redes de `lan` e `inet`, e serão representadas pelas linhas laranja: Figura 3: Rede simples com Zonas e Redes Temos agora, a Rede `lan' dentro da Zona `int', e a rede `inet' dentro da Zona 'ext'. Podemos imaginar como minha rede local dentro da zona interna, e a `rede' Internet dentro da zona externa. Atenção: é de primordial importância que se entenda a nomenclatura introduzida a partir deste ponto, pois será assim que iremos referenciar os objetos. O Vuurmuur mostra estes objetos no formato rede.zona, portanto, em nosso exemplo, ele seria referenciado como lan.int e inet.ext. Fácil. Para exemplicarmos o host, vamos adicionar o `Server' ao nosso primeiro exemplo, como pode ser conferido na gura 4. Na gura 5 podemos ver como caria nosso cenário,

32 3.2 Entendendo 31 com um host, redes e zonas. Figura 4: Rede simples com Host Figura 5: Rede simples com Host, Redes e Zonas Ficaria a referência, portanto, como server.lan.int. É realmente intuitivo este método de referenciação, e é assim que o Vuurmuur irá mostrar os objetos na hora da criação de regras. Novamente, ca a observação do motivo para o uso de nomes intuitivos Pequenos detalhes Vale observar aqui pequenos detalhes que podem intrigar a cabeça do usuário: IP's vs. Nomes: Note que, em todos os exemplos citados até agora, sempre nos referenciamos à IP's, e nunca à nomes. No Vuurmuur, não é possível, por exemplo, cadastrar um host externo como sendo ` Ao invés disto, deve-se observar qual é o IP que responde por este endereço, e cadastrá-lo no devido lugar. A explicação para isto é que recomenda-se nunca usar nomes no lugar de endereços IP, devido à grande facilidade de se fazer spoof de DNS. Uma questão óbvia, mas que vale a pena ser lembrada: na seção de montagem do cenário-exemplo, teremos a oportunidade de perceber que, no Vuurmuur, temos de autorizar explicitamente tudo que poderá entrar/sair/atravessar o rewall. Isto se deve ao fato de o Vuurmuur implementar uma política séria de rewall, portanto,

33 3.3 Instalando 32 todas as suas políticas padrão 4 são denidas para DROP, sendo assim necessário fazer a especicação de todos os serviços autorizados. Antes de sair cadastrando regras, é importante que se entenda os exemplos da subseção 3.2.7, na página 29, e que se monte uma estrutura organizada e denida. Desta forma, o trabalho na hora da elaboração das regras cará muito mais simples e intuitivo. 3.3 Instalando A partir de agora, se dá o início do que poderíamos chamar de `mão-na-massa'. Encerra-se o referencial teórico, e passaremos a apresentar, nesta e nas próximas duas seções, screenshots e comentários diretamente sobre as opções do programa em si A partir do código fonte Nesta forma de distribuição, o Vuurmuur vem compactado utilizando os utilitários GNU tar e gzip, resultando no arquivo Vuurmuur tar.gz. Para descompactarmos o código-fonte do Vuurmuur, podemos utilizar o seguinte comando: # tar xvzf Vuurmuur tar.gz Teremos algo assim: 4 Default Policies. Figura 6: Descompactando o código-fonte

34 3.3 Instalando 33 Na instalação com o código-fonte, o Vuurmuur vem com um utilitário de instalação chamado install.sh. Vejamos quais são suas opções, digitando #./install.sh --help: Figura 7: Opções do install.sh Vamos analisar qual é a função de cada opção: - Main Options: São as opções principais, é obrigatório informar uma delas (e apenas uma.) --install: Esta opção dará início à instalação interativa, e irá perguntar os caminhos em que o usuário deseja instalar os arquivos. --upgrade: Esta opção é utilizada quando estamos fazendo atualização de versões. O setup do Vuurmuur irá instalar todos os arquivos, com exceção dos arquivos de conguração. Após a atualização, o Vuurmuur estará pronto para rodar a versão nova, e já interpretará as regras antigas. --uninstall: Mesmo caso da opção acima, porém utilizado para remover o programa. Todos os arquivos serão removidos, com exceção dos arquivos de

35 3.3 Instalando 34 conguração, que permanecerão no local onde estão, para caso seja necessário usá-los posteriormente, ou caso o administrador deseje efetuar um backup disto. --unpack: Esta opção é destinada a quem deseja efetuar a compilação dos pacotes na mão. Após a descompactação do arquivo Vuurmuur tar.gz, são criados mais 3 arquivos com a mesma extensão, são eles: libvuurmuur tar.gz vuurmuur tar.gz vuurmuur_conf tar.gz Estes arquivos poderiam ser usados para a compilação manual. Em nosso caso, iremos utilizar a facilidade do instalador. - Sub Options: São as opções auxiliares. Nenhuma delas é obrigatória. Porém, para utilizarmos uma dessas funções, devemos utilizar juntamente alguma das Opções Principais: --defaults: Esta opção fará com que o programa não pergunte pelos locais desejados de instalação. Ao invés disto, ele irá adotar os seguintes locais como padrão: /etc/vuurmuur para os arquivos de conguração, /usr/bin para os arquivos binários, /usr/share/vuurmuur para arquivos diversos e /var/log/vuurmuur para os logs. --debug: Esta opção é utilizada em caso de problemas na instalação. Quando ativada, gerará mais detalhes e informações, para o log de instalação. --nounpack: Esta opção diz ao programa para não descompactar os três arquivos citados acima; ao invés disso, utilizar os que já estão descompactados na pasta. É óbvio que deverão existir estes arquivos para que isto funcione. Conhecidas as devidas opções, iremos iniciar a instalação, utilizando o seguinte comando: #./install.sh --install --defaults: Isto informa ao instalador para instalar o Vuurmuur, e não perguntar pelos locais de instalação, utilizando os locais padrão. A instalação se inicia. Dependendo da velocidade do seu computador, a instalação demorará aproximadamente de 5 a 10 minutos. Em casos normais, geralmente o básico do sistema Linux instalado já fornece todas os requisitos do Vuurmuur. Portanto, não costumam ocorrer problemas aqui. Durante a instalação, ele irá informando sobre o status da instalação, como na gura 8:

36 3.3 Instalando 35 Figura 8: Instalação em andamento Após o término da instalação, podemos vericar os binários que foram criados: Figura 9: Binários do Vuurmuur O Vuurmuur fornece, junto com sua instalação, um script de inicialização, que poderá

37 3.3 Instalando 36 ser usado para iniciar o Vuurmuur durante o boot. Este script está formatado para o estilo `Red Hat like', porém pode ser usado em qualquer distribuição, como o SLACKWARE, com poucas adaptações. Se houver sido utilizado o caminho padrão durante a instalação, o script estará em /usr/share/vuurmuur/scripts/vuurmuur-initd.sh. Com isso, terminamos o processo de instalação e sua abordagem a partir do código fonte. A partir da próxima seção, tudo o que se for abordado já faz parte da conguração do Vuurmuur em si, em seus diversos módulos Autopackage e binários diversos Como citado na subseção (p.17), a abordagem de instalação neste trabalho é a feita a partir do código-fonte, e não iremos entrar em detalhes especícos sobre procedimentos de instalação de pacotes binários de distribuições especícas, apesar de o site do Vuurmuur manter pacotes para algumas destas distribuições em seus releases. Nossa justicativa para tal é a de que a instalação a partir do código-fonte é extensivamente mais abrangente, uma vez que, teoricamente, deverá funcionar em qualquer distribuição Linux, salvo restrições especícas de distribuições. Entretanto, gostaríamos de citar brevemente uma nova forma em que o Vuurmuur começou a ser distribuído: o Autopackage. Autopackage é um formato novo que tem, entre outras intenções, prover um pacote que seja independente de distribuições, adaptando-se assim ao ambiente em que estiver sendo executado. É um projeto que está começando a se popularizar agora, e o Vuurmuur já está testando, a nível de versões alpha, o release de versões utilizando esta forma de empacotamento. Para a próxima versão do Vuurmuur, é provável que já se tenha este suporte de forma ocial. Maiores informações sobre o Autopackage poderão ser encontradas em autopackage.org/

38 3.4 Conhecendo menus e opções Conhecendo menus e opções Nesta seção, iremos abordar as diversas opções de todos os binários do Vuurmuur. A maior parte estará localizada justamente no módulo vuurmuur_conf, a nossa `interface gráca'. Entretanto, veremos úteis opções nos outros módulos também, que poderão ser usados para as mais diversas nalidades, desde ajustes nos até resolução de problemas vuurmuur Este é o módulo `core' 5 do Vuurmuur. É ele o responsável pela conversão de opções informadas no vuurmuur_conf para o formato nativo do iptables, bem como o manuseio de tarefas indiretas ao mesmo. Algumas funções do módulo vuurmuur: - Converter as regras do vuurmuur_conf para o formato do iptables, e injetá-las no próprio iptables; - Em caso de mudanças nas regras, quando clicamos em `Aplly' (Aplicar), será ele quem fará também a atualização destas regras no iptables; - Vericar mudanças em interfaces dinâmicas, para readequar as regras, de acordo com o novo endereço adquirido; - Carregar módulos adicionais do iptables (caso esta opção esteja ativada). Esta e outras tarefas são realizadas por este módulo. Na inicialização do vuurmuur_conf, se o daemon vuurmuur não estiver rodando, é informado um status de erro, e as regras não poderão ser aplicadas. Portanto, este módulo deverá estar sempre carregado antes de entrarmos no vuurmuur_conf 6, pois só assim seremos capazes de por em prática todas as congurações feitas lá dentro. A imagem 10 nos mostra as opções do vuurmuur, obtidas com o seguinte comando: # vuurmuur -h 5 Módulo principal, módulo-base. 6 Na primeira vez em que for executar o Vuurmuur, é aconselhável que se rode primeiramente o vuurmuur_conf+, denam as regras, e só depois se inicie o vuurmuur. Caso isto seja feito em ordem inversa, seu rewall não permitirá mais nenhuma conexão com ele, até que se denam as regras.

39 3.4 Conhecendo menus e opções 38 Figura 10: Opções do daemon vuurmuur Vamos às opções: # vuurmmur -b: Se este parâmetro for especicado, o vuurmuur, ao invés de injetar as regras lidas no vuurmuur_conf e convertidas para o iptables, irá mostrar na tela os comandos que utilizaria para fazer isso, imprimindo o bashscript que seria executado para tal tarefa. É bastante útil para quem tem curiosidade em saber como o Vuurmuur forma sua lista de regras (que é, por sinal, bastante extensa e complexa, mesmo para os casos mais simples). # vuurmuur -d [1-3]: Isto habilita e dene o nível de informação que será gravado no arquivo debug.log. Quanto mais alto o número, mais detalhado será o log. Isto é extremamente útil para resolução de problemas, onde você começa denindo um número baixo, e vai aumentando, até que apareça sua mensagem de erro. # vuurmuur -h: Exibe o conteúdo da gura 10, a que estamos analisando neste momento.

40 3.4 Conhecendo menus e opções 39 # vuurmuur -V: Exibe a versão do programa. # vuurmuur -D: Inicia o vuurmuur, e ca em modo daemon. Isto quer dizer que ele fará todo seu trabalho junto ao iptables, mas continuará executando em background, aguardando pela comunicação do vuurmuur_conf. Normalmente, esta será sempre a opção utilizada no startup; desta forma, poderemos fazer nossas alterações no vuurmuur_conf, e aplicá-las sem mesmo ter de sair do programa. 7 # vuurmuur -L: Especica o nível do log para ser usado nas mensagens enviadas ao syslog. 8 # vuurmuur -v: Em condições normais, o vuurmuur age silenciosamente, gravando apenas suas mensagens nos arquivos de log. Caso esta opção seja especicada, o vuurmuur imprimirá também na tela as mensagens de início. # vuurmuur -n: Como citado, é utilizado para usar juntamente com o parâmetro `- D'. Neste caso, o vuurmuur faz o que tem de fazer e entra em loop, mas não passa ao modo daemon, e também não vai para background, continuando sua execução em primeiro plano. # vuurmuur -C: Este comando é utilizado para zerar todas as regras do iptables, e deixá-lo como se não houvesse sido carregado regra alguma para ele. Adicionalmente, seta todas as default policies para ACCEPT. Cuidado com este comando, ele deixará seu rewall completamente exposto para qualquer tipo de conexão. # vuurmuur -t: Como citado, uma das funções do vuurmuur é carregar os módulos adicionais necessários para as regras. Mesmo que esta opção esteja ativada no vuurmuur_conf, pode-se mandá-lo ignorar isto com este parâmetro. Desta forma, tentará injetar as regras no iptables, mesmo que este possa não suportar parte delas. Use somente se souber o que está fazendo. 7 Se o vuurmuur for iniciado sem nenhum parâmetro, ele irá simplesmente fazer a conversão das regras, injetá-las no iptables, e nalizar. Seria equivalente ao nosso script citado na subseção Para maiores informações, consulte man syslog.

41 3.4 Conhecendo menus e opções vuurmuur_log O vuurmuur_log é o módulo mais simples do Vuurmuur. Ele apenas lê os logs do iptables (por padrão, em /var/log/messages), e os converte para o formato do Vuurmuur. Nesta conversão, o vuurmuur_log usará todos os nomes de objetos denidos no vuurmuur_conf. O log gerado por este módulo será muito útil, e amplamente utilizado no vuurmuur_conf, para o acompanhamento de logs (inclusive em tempo real). O formato dos logs gerados pelo Vuurmuur é extremamente fácil de se entender e visualizar, pois segue o mesmo padrão `humano-intuitivo' usado na criação de regras. Para iniciá-lo, apenas digite: # vuurmuur_log Obs: o vuurmuur_log deverá ser iniciado no processo de startup juntamente com o vuurmuur vuurmuur_script O vuurmuur_script é o `lho mais novo' dos módulos do Vuurmuur, e ainda está apenas em fase de testes, inclusive com uma quantidade signicativa de bugs. Porém, foi uma das maiores novidades das ultimas versões, e será com certeza, em breve, um recurso muito utilizado pelos administradores de rede para a automatização de funções. O vuurmuur_script é um programa para a linha de comando que têm como função interagir nas congurações do vuurmuur_conf, porém sem a necessidade de estar dentro dele. A vantagem disto é que você poderá incluir, por exemplo, comandos em seus próprios programas que façam as alterações ou inclusões necessárias no Vuurmuur e, quando você entrar no vuurmuur_conf, encontrará tudo da forma como foi alterado. Como exemplo, poderíamos citar um script que teria a função de vericar de tempo em tempo as máquinas ativas da rede(através de um simples ping, por exemplo), compará-las com a lista do Vuurmuur e, se fosse necessário, adicionar as máquinas que não tem regras associadas à ela. Isto seria útil, por exemplo, para manter atualizada uma rede onde saem e entram muitos clientes. Este é apenas um exemplo simples. As possibilidade de uso para o vuurmuur_script são innitas, só dependerá dos recursos do programa para o qual ele estiver fazendo interface.

42 3.4 Conhecendo menus e opções 41 O vuurmuur_script trabalha com alguns códigos de retorno, úteis para sabermos se nosso comando foi concluído com sucesso ou se houver erro. Esta característica deixa claro a justa intenção de se utilizar chamadas para o vuurmuur_script a partir de outros programas ou scripts. Os códigos de retorno implementados até o momento são: 0 ok 1 commandline option error 2 command failed 3 object supplied with -n does not exist 4 object supplied with -n already exists 254 internal program error O código 0 indica que o comando foi concluído com sucesso. O código 1 indica que há um erro na sintaxe informada. O código 2 indica uma falha não-especíca na execução do comando. O código 3 indica que um dos objetos informados não existe, no caso de se estar tentando fazer alguma ação com ele. O código 4 indica que um dos objetos informados já existe, no caso de se estar querendo criar um objeto com o mesmo nome. O código 254 indica um erro interno do programa. As possíveis ações denidas até agora são: -C --create: Cria um novo objeto. -D --delete: Apaga um objeto. -R --rename: Renomeia um objeto. O novo nome deve ser informado com a opção --set. -M --modify: Modica uma variável de objeto informada com a opção --variable. Use também o --set para denir o novo valor. -L --list: Lista objetos. -P --print: Imprime o valor de um determinado objeto. Use a opção --variable para imprimir apenas uma variável. Com este set de opções, já conseguimos realizar grande parte das opções disponíveis dentro do próprio vuurmuur_conf. Como objetos, teremos os já conhecidos 6 objetos padrão do Vuurmuur, e mais um

43 3.4 Conhecendo menus e opções 42 sétimo objeto, que é a regra em si: -o <nome> --host <nome>: Nome de host. -g <nome> --group <nome>: Nome de grupo. -n <nome> --network <nome>: Nome de rede. -z <nome> --zone <nome>: Nome de zona. -s <nome> --service <nome>: Nome de serviço. -i <nome> --interface <nome>: Nome de interface. -r <nome> --rule <nome>: Nome da set de regras.(para uso futuro) Valor padrão: rules Temos duas opções adicionais: -A --append: Adiciona, ao invés de sobrescrever, quando estiver usando a opção --modify. -O --overwrite: Sobrescreve, quando estiver usando a opção --modify (default) vuurmuur_conf Este é o módulo principal do ponto de vista da interação com o administrador de redes. É nele que normalmente o administrador estará a maior parte do tempo em que estiver `dedicando tempo' ao seu rewall. Um exemplo atual de cenário típico do Vuurmuur seriam o vuurmuur e o vuurmuur_log rodando em background e, a partir daí, toda a interação do usuário a partir do vuurmuur_conf. Veremos que, sem ao menos sair de sua interface, é possível aplicar todas as regras e mudanças feitas no rewall, facilitando assim imensamente o trabalho. Para acessarmos este módulo, digitamos na linha de comando: # vuurmuur_conf Obs: Para efeitos de exemplo, iremos iniciar o vuurmuur_conf sem o vuurmuur e o vuurmuur_log estarem rodando em background. É iniciado o programa e, num breve processo de inicialização, são vericados alguns itens, dentre eles a comunicação com o vuurmuur e o vuurmuur_log. Após o término deste processo, teremos algo semelhante à isto:

44 3.4 Conhecendo menus e opções 43 Figura 11: Primeira tela: vuurmuur_conf Esta é sua `cara'; sempre estarão presentes as duas barras de informações: uma na parte superior, e outra na parte inferior. A barra da parte superior nos mostra as opções possíveis para cada menu ou função que estivermos. A barra inferior geralmente nos dá um descritivo de qual a função da opção em que estivermos `focados'. Apesar de gráca, esta interface não faz uso do mouse em momento algum 9, portanto, todos os comandos, sem exceção, são executados pelo teclado. Nos próximos screenshots, estaremos descrevendo todas as opções encontradas aqui, e suas respectivas nalidades. No meio, temos a lista vertical de opções e, ao lado dela, temos um quadro de avisos, que nos avisa sobre possíveis erros que tenha vericado. Os avisos mostrados neste quadro podem ser de 3 tipos: OK: Indica que, para este item, tudo está correndo bem. 9 Característica comum de aplicações de linha de comando, para facilitar o uso remotamente, através de SSH, por exemplo.

45 3.4 Conhecendo menus e opções 44 Warn: Algum aviso útil sobre algum item ou conguração que possa ter uma divergência, ou algo que limite determinadas funções do sistema. Fail: Indica algum item que falhou, e não passou nos testes necessários. Apertando <F5> temos a lista completa de avisos e erros. Todos os itens desta lista deverão apresentar sempre OK, caso contrário, pode ser necessário descobrir a causa do problema e resolvê-lo, na intenção de não por em risco a segurança e demais serviços dos utilizadores do rewall. Em nosso caso, temos diversos itens que não estão marcados com OK, e alguns avisos. Vejamos quais são eles: Figura 12: Avisos do vuurmuur_conf - No primeiro aviso, do tipo WARN, o vuurmuur_conf nos diz que não há interfaces denidas, e pede para denirmos uma ou mais delas. - O segundo aviso, igualmente do tipo WARN, trata-se também das interfaces, e nos diz que não há interfaces ativas (óbvio, neste caso, pois não existem interfaces denidas).

46 3.4 Conhecendo menus e opções 45 - O terceiro item (WARN) avisa que a rede `internet.ext' 10 não possui nenhuma interface atachada à ela. Note a nomenclatura apresentada na subseção 3.2.7, na página 29, utilizando o formato rede.zona. - O quarto item trata de uma questão já abordada, e diz que não foi possível estabelecer uma conexão com o vuurmuur, e pede para assegurarmos de que ele esteja rodando. É do tipo FAIL, e, se ele não estiver rodando, não conseguiremos aplicar as opções escolhidas aqui. - O último item é semelhante ao anterior, mas avisa sobre o não-sucesso na comunicação com o vuurmuur_log. É do tipo WARN, porque conseguimos aplicar as regras sem ele, mas caremos inaptos a acompanhar os logs em tempo real no formato do Vuurmuur. Vamos conhecer os menus do Vuurmuur agora: para voltarmos à tela anterior, a tecla é <F10>. Em todas as partes do Vuurmuur, esta é a tecla para sairmos do menu atual e voltarmos para o anterior. Temos também a tecla <F12>, que irá mostrar uma ajuda sobre o item/menu/função focado sempre que disponível. Estas próximas guras mostram menus que serão tratados todos na próxima seção (3.5, página 67). Não iremos, portanto, entrar em detalhes sobre eles agora. Figura 13: Rules: Criação de regras 10 No Vuurmuur, 4 zonas já vem previamente cadastradas, juntamente com a rede `internet', que já vem dentro da zona `ext'.

47 3.4 Conhecendo menus e opções 46 Figura 14: Blocklist: Lista de bloqueados Figura 15: Zones: Criação de zonas, redes, grupos e hosts

48 3.4 Conhecendo menus e opções 47 Figura 16: Interfaces: Criação e manipulação de interfaces Figura 17: Services: Criação de serviços

49 3.4 Conhecendo menus e opções Vuurmuur Cong O vuurmuur_conf tem dois menus distintos de congurações: um para as congurações do Vuurmuur, ou seja, do programa em si, e outro somente para as congurações do vuurmuur_conf (onde estamos agora). A gura 18 nos mostra as opções da seção Vuurmuur Config: Figura 18: Vuurmuur Config: Opções gerais do Vuurmuur As opções: - General: Congurações gerais, caminhos do iptables e outros. - Connections: Congurações para limites de conexões, bastante usadas nos scripts manuais de rewall. - Interfaces: Congurações sobre a vericação de interfaces dinâmicas. - System Protection: Algumas proteções... - Logging: Congurações dos logs, caminhos, etc. - Modules: Congurações para o carregamento dos módulos adicionais do iptables, necessários para o funcionamento de algumas funções.

50 3.4 Conhecendo menus e opções 49 - Plugins: O Vuurmuur utiliza plugins para a comunicação e armazenamento de dados. Atualmente só existe um plugin, o textdir; portanto é ele que deverá estar nestas congurações. - Capabilities: Neste item, são apontadas os recursos do iptables disponíveis na máquina, de acordo com os módulos carregados ou o suporte compilado no kernel. General Figura 19: Vuurmuur Cong: General Nesta parte, possíveis congurações que temos são as seguintes: Iptables location: Aqui deve-se denir o caminho completo para o executável do iptables, usualmente em /usr/sbin/iptalbes. Iptables-restore location: O mesmo, porém para o iptables-restore. Observe que esta ferramenta tem também sua utilidade com o Vuurmuur ;) Scripts location: O Vuurmuur utiliza scripts para algumas operações, e aqui deve-se informar o caminho onde estarão armazenados estes scripts.

51 3.4 Conhecendo menus e opções 50 Old rule creation method: A partir da versão , foi introduzida uma nova forma de criação de regras, utilizando justamente o iptables-restore. Esta opção deverá ser usada caso surja algum problema com o novo método, ou caso o usuário, por alguma razão, ache-a melhor. Connections Figura 20: Vuurmuur Cong: Connections Quando usamos scripts com regras para rewall, e também nos scripts prontos que encontramos pela Internet, geralmente existem regras para limitar o número de conexões TCP e UDP por segundo. No Vuurmuur, isto aparece como uma opção, pois a parte de regras se destina estritamente à regras relacionadas aos objetos já explanados. Você apenas marca para qual tipo de protocolo de conexão você quer seja aplicada a limitação (TCP ou UDP), e coloca os valores para número de pacotes/conexões por segundo, e `burst-rate', para as duas. Interfaces Quando temos interfaces com IP's dinâmicos interfaces que recebem um IP válido dinâmico da Internet, por exemplo, determinadas regras podem parar de funcionar caso o IP da interface mude, e as regras não forem atualizadas. O Vuurmuur se encarrega de vericar mudanças em interfaces dinâmicas 11, e atualizar as regras que utilizem o endereço desta interface. 11 É necessário que a interface esteja marcada como `dynamic' em sua conguração.

52 3.4 Conhecendo menus e opções 51 Aqui, apenas informamos se queremos que o Vuurmuur cheque atualizações nestas interfaces, e o intervalo que esta checagem deve acontecer. Figura 21: Vuurmuur Cong: Interfaces System Protection Figura 22: Vuurmuur Cong: System Protection O Vuurmuur oferece proteção automática contra ataques Syn-ood e echo-broadcast. A proteção contra este tipo de ataque é altamente recomendável. Para ativá-la, apenas marque as caixas.

53 3.4 Conhecendo menus e opções 52 Logging Figura 23: Vuurmuur Cong: Logging Na gura acima, vemos as opções relacionadas à criação de logs em geral. Vejamos o que cada uma faz: Vuurmuur logfiles location: Indique aqui o caminho onde deverão ser salvos os arquivos de log criados pelo próprio Vuurmuur. São eles: - debug.log: Onde são gravadas informações de depuração geradas pelo Vuurmuur. - traffic.log: Aqui são registradas todas as informações de tráfego convertidas pelo vuurmuur_log, geradas a partir do próprio log do iptables. A visualização deste arquivo é bastante freqüente pelos administradores que utilizam o Vuurmuur, pois o tráfego é exibido de uma forma bastante intuitiva, a mesma forma de criação de regras. - error.log: Quando acontecem erros com o Vuurmuur especicamente, sejam eles na inicialização ou durante sua execução, esses erros são gravados neste arquivo.

54 3.4 Conhecendo menus e opções 53 - vuurmuur.log: Aqui são gravadas informações que o Vuurmuur gera em sua inicialização, e também as alterações feitas no vuurmuur_conf. Loglevel: Informe o nível de detalhes que o syslog 12 irá gerar as mensagens para o log do iptables. Systemlog filename: Especique aqui onde o vuurmuur_log deverá buscar os logs do iptables para fazer a conversão. É aconselhável que se crie um arquivo à parte para os logs do iptables, pois este arquivo pode car consideravelmente grande. Log the default policy?: Como já mencionado, a política padrão que o Vuurmuur usa para o iptables é DROP. Marque esta opção se quiser que o Vuurmuur também registre os pacotes que não tenham se encaixado em nenhuma regra. Adicionalmente, a próxima opção, Limit of the number of logs per second, permite que se dena um limite de registros por segundo para esses registros. Log tcp options: O Vuurmuur em si não usa isto, mas pode gerar essas informações para serem usados com o PSAD, um portascan detector muito eciente. Log blocklist violations: Este último item deverá ser marcado caso queira que sejam registradas as tentativas de acesso pelos itens cadastrados na Blocklist (veremos à frente). Cabe aqui uma importante observação, sobre os logs gerados pelo Vuurmuur: dependendo do número de regras que você tenha, e do tráfego em sua rede, os arquivos de log poderão atingir tamanhos muito grandes. O Vuurmuur fornece, junto com sua instalação padrão, um script para ser utilizado com o logrotate, para que seja feita a manutenção destes logs, de modo a evitar que eles cresçam indenidamente. Se o Vuurmuur tiver sido instalado em seus diretórios padrões, o script poderá ser encontrado em: /usr/share/vuurmuur/scripts/vuurmuur-logrotate. Congure-o de acordo com os padrões de sua distribuição. Modules Nesta parte, denimos se queremos que o próprio Vuurmuur carregue os módulos necessários (ou apenas os que ainda não tiverem sido carregados, caso já seja feita esta carga durante a inicialização) do iptables para o correto suporte de todas as funções cobertas por ele (Vuurmuur). Vejamos suas opções na gura 24: 12 Para maiores informações, consulte man syslog.

55 3.4 Conhecendo menus e opções 54 Figura 24: Vuurmuur Cong: Modules A primeira opção, Modprobe location, pede o caminho completo para o utilitário modprobe, responsável pelo carregamento dos módulos. Logo abaixo, temos a caixa de seleção load modules, que serve justamente para dizermos se queremos que o Vuurmuur carregue os módulos ou não. A opção waittime after loading a module serve para informarmos qual será o tempo (em décimos de segundos) entre a carga de um módulo e outro. Plugins O Vuurmuur foi projetado de uma forma modularizada. Isto quer dizer que utiliza `backends' internos para o armazenamento e manuseio de registros de serviços, zonas, interfaces e regras. Atualmente, só existe apenas um plugin, o textdir, do próprio Vuurmuur. Entretanto, o fato de ter sido estruturado dessa forma já possibilita que, no futuro, sejam adicionados e desenvolvidos plugins que possam interagir com o Vuurmuur, de modo a facilitar ainda mais a administração de redes, e fazer a interação com outros programas.

56 3.4 Conhecendo menus e opções 55 Figura 25: Vuurmuur Cong: Plugins Capabilities Este item é de extrema importância para o aproveitamento total das funcionalidades do Vuurmuur, e do próprio iptables. O iptables e seus recursos podem estar disponíveis de duas formas: ou compilados diretamente no kernel, ou como módulos, que podem ser carregados com o modprobe 13, já citado anteriormente. Normalmente, os recursos mais comuns estão compilados diretamente no kernel, e as funcionalidade `extras' estão disponíveis através de módulos. Para o iptables poder se utilizar destes recursos, os módulos têm de estar carregados quando da utilização do iptables, ou seja, assim que o rewall entrar em funcionamento, em nosso caso. No caso do Vuurmuur, temos duas formas de fazer isso: ou através do script de inicialização, que tem a opção para informarmos os módulos que queremos que sejam carregados, ou através do Vuurmuur, que pode carregar automaticamente os módulos, como acabamos de ver, na opção `Modules'. Esta parte nos mostra quais são as `capacidades' atuais do rewall, ou seja, que tipo de operações denidas pelo iptables ele consegue fazer. Na 13 Para maiores informações, consulte man modprobe.

57 3.4 Conhecendo menus e opções 56 primeira vez em que entramos nesta tela, pode ser que grande parte dos módulos necessários ainda não tenham sido carregados. Neste caso, o Vuurmuur irá dar uma mensagem dizendo que algumas capacidades não foram carregadas, e perguntará se gostaríamos de tentar carregar esses módulos, conforme mostra a gura 26: Figura 26: Vuurmuur Cong: Aviso sobre módulos não presentes Após isso, poderemos ver quais funções estão disponíveis em nosso sistema. Figura 27: Vuurmuur Cong: Capabilities

58 3.4 Conhecendo menus e opções Logview Esta seção é um dos grandes diferenciais do Vuurmuur, e proporciona uma grande vantagem em relação à utilização de scripts, por exemplo. Aqui podemos visualizar os 4 logs gerados pelo Vuurmuur, debug.log, traffic.log, error.log e vuurmuur.log. Ao entrarmos na seção `Logview', escolhemos qual arquivo desejamos visualizar: Figura 28: Logview Vamos pegar, por exemplo, o arquivo vuurmuur.log: Figura 29: Logview: vuurmuur.log

59 3.4 Conhecendo menus e opções 58 É exibido o conteúdo do arquivo. Porém, temos, para todos os arquivos visualizados, algumas opções bastante úteis: <F12>: Mostra a ajuda, bastante completa e presente em praticamente todas as partes do programa. s:search: Utilize isto para fazer buscas, dentro do arquivo escolhido ou do resultado que estiver em buer, no caso de um arquivo que esteja sendo exibido em temporeal, como o traffic.log costuma ser. Na janela de busca, não é permitido o uso de espaços. Após digitado o desejado, o Vuurmuur retorna apenas os resultados que contenham o critério de busca. Após nalizado, aperte <espaço> para voltar à visão original. f:filter: Não confundir esta função com a função de busca: a busca é utilizada para resultados estáticos que estão apresentados na tela. O ltro é mais utilizado para o traffic.log, que é visualizado em tempo real. Desta forma, só é mostrado o que estiver no ltro. Muitas vezes queremos ver apenas o que determinado host está fazendo, por exemplo, e desta forma temos, em tempo real, toda a atividade. É realmente útil e impressionante o que esta combinação logview + ltro pode fazer. p:pause: Normalmente, quando estamos visualizando o log de tráfego em tempo real, dependendo do tráfego que passa por nosso rewall, as `linhas' passam muito rápido, principalmente se não tivermos nenhum ltro denido. o pause serve justamente para `congelar' a rolagem. Tanto o que está a frente do ponto de pausa, como a quantidade de linhas que se pode voltar, é denida pelo tamanho de buer, que iremos ver na seção (p.64). c:clear: Limpa a tela. 1-7:hide: Mostra ou esconde as colunas que aparecem na visualização, podendo adequar as suas necessidades. Para o error.log e o debug.log, a operação é semelhante, pois o log é geralmente mais estático. O traffic.log é um caso à parte: como dito, é a `arma-secreta' do administrador do rewall. Com esta ferramenta, é muito fácil acharmos o que quisermos, ltrarmos qualquer host, qualquer serviço ou qualquer evento que esteja passando pelo rewall. Veja um exemplo do Logview em ação com o traffic.log:

60 3.4 Conhecendo menus e opções 59 Figura 30: Logview: trac.log Status Figura 31: Vuurmuur_conf: Status A seção Status nos mostra diversas informações do sistema: Nome da máquina

61 3.4 Conhecendo menus e opções 60 Versão do kernel Uptime Carga do processador e memória Número de conexões estabelecidas Informações relacionadas às interfaces, como a velocidade de banda total passante naquele momento, e o total de tráfego de entrada e saída, bem como a contagem do tráfego encaminhado. Em alguns casos, especialmente nas informações relacionadas ao tráfego de rede, esta seção pode ser muito útil Connections Esta parte é também muito especial, assim como o Logview para o traffic.log. Aqui, vemos todas as conexões que estão sendo processadas pelo rewall, em tempo real. Veja este exemplo na gura 32: Figura 32: Connections: Visualização em tempo real Temos também algumas opções úteis aqui:

62 3.4 Conhecendo menus e opções 61 i:in/out/fw: Esta opção faz a segmentação da exibição em três partes: as conexões que estão entrando no rewall (incoming), as conexões que estão saindo (outgoing), e as conexões que estão sendo encaminhadas (forwarded). s:status: Isto mostra ou esconde o campo de status de conexões, que pode ser `conectando' (connecting), `desconectando' (disconnecting), ou `conectado' (connected)). c:connect: Esta função é semelhante à in/out/fw, porém esta separa as conexões em conexões estabelecidas (established), conexões inicializando (initializing) ou conexões encerrando (closing). u:grp unknow: Esta opção nos diz se deverão ser exibidas aqui linhas que contenham hosts que não pertencem a nenhum grupo. Caso ativada, só aparecerão as linhas em que o host é `conhecido' pelo Vuurmuur. Neste caso, o nome cadastrado para ele é que aparecerá. Vejamos alguns exemplos das diversas congurações da seção Connections: Figura 33: Connections: in/out/fw

63 3.4 Conhecendo menus e opções Figura 34: Connections: connect status Figura 35: Connections: group unknown 62

64 3.4 Conhecendo menus e opções 63 Figura 36: Connections: campo `status' aparecendo Bandwidth Todo o `conteúdo' desta seção é gerado não pelo Vuurmuur, mas sim por outro programa, o Ip Tra c Volume 14. Esta seção nos mostra dados relacionados ao consumo de banda do rewall, de um modo geral, em diversos períodos de tempo. Para todas as categorias, é listado o volume de tráfego de todas as interfaces, tanto na entrada, quanto na saída. São apresentadas as seguintes categorias: - Today: - Yesterday: - 7-days: É apresentado o tráfego corrente do dia atual. É exibido a contagem do tráfego do dia anterior. Aqui é exibido a soma do tráfego dos últimos 7 dias, ou seja, de 1 semana atrás em diante. - This month: Mesma coisa, mas para o mês inteiro. - Last month: Exibe todo o tráfego do mês anterior. Bastante útil para as compara- ções com o mês atual. 14 Saiba mais sobre este interessante projeto em

65 3.4 Conhecendo menus e opções 64 Através do script iptrafvol.pl fornecido com o IP Trac Volume, o Vuurmuur lê os dados gerados pelo programa, e os apresenta de forma organizada para a conferência do usuário. A imagem 37 nos dá uma noção da ferramenta: Figura 37: Trac Log Volume Vuurmuur_conf Settings opções: Aqui são tratadas as congurações do vuurmuur_conf especicamente. Vejamos suas Figura 38: Vuurmuur_conf: Settings