SISTEMAS OPERACIONAIS ABERTOS Prof. Ricardo Rodrigues Barcelar

Transcrição

1 - Módulo 6 - FIREWALL E PROXY O LINUX é um sistema operacional em desenvolvimento contínuo desde 1992, e atualmente é utilizado por diversas corporações, devido à sua reconhecida confiabilidade e segurança. Grandes corporações, como IBM, Novell, RedHat, e outras investem maciçamente no desenvolvimento deste sistema. Devido à sua tradição e utilização em aparatos de segurança, várias ferramentas relacionadas também foram desenvolvidas nos últimos anos, e encontram-se em estágio avançado de estabilidade, tais como filtros TCP/IP, roteamento, proxy, servidores WEB e outros. Devido ao crescimento da Internet, hoje é fundamental que os computadores estejam protegidos contra invasões para evitar grandes estragos nas empresas. Ameaças como as de spam, vírus e hackers são mais comuns em redes de computadores, que sem um conhecimento adequado é praticamente impossível eliminá-las. Além disso, o controle de acesso dos usuários é imprescindível para aumentar a produtividade e garantir o uso adequado do equipamento. O servidor proxy (cache) de acesso à páginas da web e download de arquivos, é responsável pela proteção de rede privada de acessos indevidos aos servidores e estações. É utilizado para controle através de autenticação dos usuários, com registro dos acessos, possibilitando extrair relatórios gerenciais sobre o uso da Internet pelos usuários. Já o firewall, permite o controle do acesso externo a rede interna. As vantagens de tais serviços são o acesso mais rápido a páginas da Internet e economia da banda do link da empresa. Uma informação é lida através do servidor e armazenada localmente no diretório de cache. Os acessos posteriores a esta informação serão obtidos localmente. Com relação à segurança da rede, toda e qualquer tentativa de acesso à rede privada é bloqueada, e estas tentativas são registradas. Figura 1 - Esquema de proteção com Firewall e Proxy 1

2 1. SERVIDOR PROXY O objetivo principal de um servidor proxy é possibilitar que máquinas de uma rede privada possam acessar uma rede pública, como a Internet, sem que para isto tenham uma ligação direta com esta. O servidor proxy costuma ser instalado em uma máquina que tenha acesso direto à Internet, sendo que as demais efetuam as solicitações através desta. Justamente por isto este tipo é chamado de Proxy, pois é um procurador, ou seja, sistema que faz solicitações em nome de outros. Em outras palavras, o Proxy é um servidor que atende a requisições repassando os dados do cliente à frente: um usuário (cliente) conecta-se a um servidor proxy, requisitando algum serviço, como um arquivo, conexão, página web, ou outro recurso disponível em outro servidor. Um servidor proxy pode, opcionalmente, alterar a requisição do cliente ou a resposta do servidor e, algumas vezes, pode disponibilizar este recurso mesmo sem se conectar ao servidor especificado. Pode também atuar como um servidor que armazena dados em forma de cache em redes de computadores. São instalados em máquinas com ligações tipicamente superiores às dos clientes e com poder de armazenamento elevado. Esses servidores têm uma série de usos, como filtrar conteúdo, providenciar anonimato, entre outros. Um proxy de cache HTTP ou em inglês caching proxy, permite por exemplo que o cliente requisite um documento na World Wide Web e o proxy procura pelo documento no seu cache. Se encontrado, a requisição é atendida e o documento é retornado imediatamente. Caso contrário, o proxy busca o documento no servidor remoto, entrega-o ao cliente e salva uma cópia no cache. Isto permite uma diminuição na latência, já que o servidor proxy, e não o servidor original, é requisitado, proporcionando ainda uma redução do uso da banda. O cache normalmente usa um algoritmo de expiração para remover documentos e arquivos de acordo com a idade, tamanho e histórico de acessos (previamente programado). Dois algoritmos simples são o Least Recently Used (LRU) e o Least Frequently Used (LFU). O LRU remove os documentos que passaram mais tempo sem serem usados, enquanto o LFU remove documentos menos frequentemente usados. Normalmente um Proxy direciona as requisições para uma porta em específico. No entanto para que este direcionamento fique transparente para o usuário é possível implementar o chamado Proxy Transparente. Um proxy transparente é um meio usado para obrigar os usuários de uma rede a utilizarem o proxy. Além das características de cache dos proxies convencionais, estes podem impor políticas de utilização ou recolher dados estatísticos, entre outras. A transparência é conseguida interceptando o tráfego HTTP (por exemplo) e reencaminhando-o para um proxy mediante a técnica do encaminhamento de portas, conhecida como port forwarding. Assim, independentemente das configurações explícitas do utilizador, a sua utilização estará sempre condicionada às políticas de utilização da rede. O RFC 3040 define este método como proxy interceptador. 2

3 1.1. Squid Web Proxy O Squid é um servidor proxy que suporta HTTP, HTTPS, FTP e outros. Ele reduz a utilização da conexão e melhora os tempos de resposta fazendo cache de requisições freqüentes de páginas web numa rede de computadores. Ele suporta SSL, listas de acesso complexas e logging completo. Por utilizar o Internet Cache Protocol, o Squid pode ser configurado para trabalhar de forma hierárquica ou mista para melhor aproveitamento da banda. O Squid consiste em um programa principal, squid, um sistema de busca e resolução de nomes, dnsserver, e alguns programas adicionais para reescrever requests, fazer autenticação e gerenciar ferramentas de clientes. O Squid foi escrito originalmente para rodar em sistema operacional tipo Unix, mas ele também funciona em sistemas Windows desde sua versão 2.6.STABLE PROTOCOLOS UTILIZADOS - REDE E APLICAÇÃO O Squid busca por comunicação TCP (Transmission Control Protocol) e ICP (Internet Cache Protocol) em portas específicas. O TCP é usado para comunicação entre Web Servers e clientes, e o ICP para conversa entre servidores de cache. Para cada servidor (ou cliente), a configuração do Squid precisa fornecer uma única porta sobre a qual o Squid irá enviar as requisições (TCP ou ICP) e ouvir as respostas. Assim ele trabalha apenas com FTP, gopher e http. Existe uma confusão em achar que é possível, através do Squid, configurar acesso a s, ICQ, IRC, etc. Isso é totalmente equivocado, visto que não faz sentido criar caches de s pessoais, mensagens do ICQ, etc REQUISITOS A maior parte das configurações depende apenas do Squid. Já o Proxy transparente também depende do sistema operacional e do firewall. A instalação padrão do Squid, disponível na maior parte das distribuições, não consegue lidar com o controle de banda, sendo necessário recompilar o Squid INSTALAÇÃO O Squid pode ser instalado em uma imensa variedade de sistemas operacionais. Praticamente todos os sistemas Unix com um bom compilador C/C++ pode gerar binários do Squid. Os sistemas Linux derivados do Debian sempre prezaram pela facilidade de instalação ou atualização de pacotes com seu sistema APT, que facilita muito a vida dos administradores. Para instalar o squid basta executar o comando: # apt-get install squid3 3

4 Fontes das versões mais atuais do Squid podem ser encontradas no site CONFIGURAÇÕES a) Uma prática importante antes de começar as configurações é fazer uma cópia do arquivo original de configurações do Squid ou então simplesmente renomear o arquivo e criar um novo arquivo de configuração em branco. # cd /etc/squid # cp squid.conf squid.conf.original b) Partindo da premissa que se optou pelo arquivo em branco, adicionar as seguintes configurações no arquivo squid.conf: http_port 3128 visible_hostname servidor cache_mgr webmaster@localhost http_port: determina a porta que será usada pelo servidor. visible_hostname: define o nome de exibição do servidor. cache_mgr: define o do administrador para receber mensagem em casos graves. c) Para definir o idioma das páginas de mensagem de erros em português brasileiro, adicione a seguinte configuração: error_directory /usr/share/squid3/errors/portuguese Cache a) Cache - O cache é onde ficam armazenados os objetos (arquivos e páginas) quando se acessa as páginas ou se baixam arquivos pela Internet. Ao invés de toda vez que um usuário for acessar um site ter que esperar baixar a página toda e os arquivos direto da hospedagem, o servidor verifica se já existe no cache podendo baixar direto do servidor, melhorando o desempenho na navegação. Para configurar o cache no Squid é necessário adicionar as seguintes configurações: hierarchy_stoplist cgi-bin? cache_mem 32 MB maximum_object_size_in_memory 64 KB maximum_object_size 100 MB hierarchy_stoplist: define palavras que se forem encontradas na URL, a página irá ser carregada direto do cache. 4

5 cache_mem: define a quantidade de memória que o servidor irá usar para o cache. maximum_object_size_in_memory: define o tamanho máximo do objeto que poderá ser armazenado na memória, senão será armazenado no disco rígido. maximum_object_size: define o tamanho máximo do objeto que poderá ser armazenado no disco rígido, senão o objeto será descartado. b) Para especificar o diretório de cache, onde serão armazenados os objetos e atribuir 1GB de espaço de armazenamento, adicionar a seguinte configuração: cache_dir ufs /var/spool/squid Isto significa que será criada uma estrutura com 1024MB, 16 diretórios e 256 subdiretórios. c) Para definir o tempo de vida dos objetos no cache, para que quando o Squid for verificá-los, saber se é necessário atualizá-los ou não, adicionar a seguinte configuração: refresh_pattern ^ftp: % refresh_pattern -i (/cgi-bin/ \?) 0 0% 0 refresh_pattern. 0 20% ª coluna: defina o tempo em minutos, em cada acesso, quando deve verificar se houve modificação no objeto. 2ª coluna: defina a porcentagem mínima da modificação do objeto que deve ter para ser atualizado. 3ª coluna: defina o tempo em minutos, quando deve efetuar uma atualização mesmo não ter sido modificado. d) Por medida de segurança é importante não permitir que seja feito cache de páginas seguras: no_cache deny SSL_ports e) Atendendo a norma de segurança NBR ISO/IEC 17799, recomenda-se que sejam gerados registros de atividades dos usuários e que os mesmos sejam mantidos por tempo definido dentro da corporação, possibilitando investigações futuras, bem como a monitoração do controle de acesso. Para especificar o caminho do Log de acesso do Squid e o caminho do Log do cache, adicionar a seguinte configuração: access_log /var/log/squid3/access.log cache_log /var/log/squid3/cache.log 5

6 Controle de Acesso/Filtro de conteúdo com ACL s Um recurso motivador para o uso de um web-proxy é o conceito de filtro de conteúdo, que possibilita a filtragem do conteúdo web dos usuários. Na ACL ou Lista de Controle de Acesso, é onde são definidas as permissões de acesso à Internet. As seguintes ACL s podem ser criadas: - src: Filtro por rede ou endereço IP - time: Filtro por hora e dia da semana - urlpath_regex: Filtro de complemento de URL - url_regex: Filtro de uma string na URL - dstdomain: Filtro de uma URI - proxy_auth: Filtro por usuários autenticados - arp: Filtro por MAC Address - maxconn: filtro por conexões - proto: Filtro por protocolos - port: Filtro por porta As ACL s são listas que fazem o agrupamento dos objetos que serão negados ou liberados de acordo com as regras determinadas pelo administrador. Sintaxe: acl nome_da_acl tipo tipo_de_agrupamento Exemplo: acl almoco time 12:00-14: Permissionamento das ACS s Para uma rede corporativa é necessários definir o que é ou não permitido acessar. Para tanto o Squid define um poderoso mecanismo para atribuir permissões aos acessos baseados nas ACS s criadas. Sintaxe: http_access allow deny nome_da_acl Exemplo: acl maq1 src acl maq2 src acl maq3 src acl diurno time 08:00-18:00 acl almoco time 12:00-14:00 6

7 http_access deny all http_access allow maq1 diurno http_access allow maq2 diurno http_access allow maq2 almoco http_access allow maq3 almoco É importante lembrar que o principio básico de funcionamento é que o Squid faz a leitura do arquivo squid.conf de cima para baixo. Sendo assim imagine que tivéssemos as seguintes ACL s e suas respectivas regras: acl diretoria src "/etc/squid/diretoria " acl usuarios src "/etc/squid/usuarios" acl sites_bloqueados url_regex -i "/etc/squid/sites_bloqueados" http_access allow diretoria http_access deny sites_bloqueados http_access allow usuarios Isso significa que quando liberamos por primeiro a ACL diretoria, essa ACL terá acesso total mesmo tendo abaixo uma ACL bloqueando sites. Já a ACL usuários não conseguirá acessar os sites contidos na ACL sites_bloqueados, porque o bloqueio vem primeiro. Vamos supor que precisamos bloquear uma palavra que esteja no meio de outra, como por exemplo, deputados, a qual contém uma string não permitida. Uma maneira de trabalhar com essa situação é criando duas listas de palavras: uma com as palavras permitidas e outra com as palavras não permitidas: - lista_negra - lista_branca A configuração ficaria, então, da seguinte forma: acl lista_negra url_regex i /etc/squid/lista_negra acl lista_branca url_regex i /etc/squid/lista_branca Observação: A url_regex trata a string dentro de uma URL completa. Por exemplo, se dentro do arquivo lista_negra conter a palavra boy e qualquer parte da URL contiver a palavra boy, como o acesso será bloqueado. O parâmetro i diz que qualquer palavra dentro do arquivo sofrerá tratamento de case sensitive. O permissionamento ficará como a seguir: http_access allow whitelist http_access deny blacklist 7

8 Para construção do servidor Proxy serão aplicadas as seguintes ACL s e seus respectivos permissionamentos: a) Criar 2 (duas) ACL s com o tipo SRC (IP de origem) e adicionar o IP do servidor e o IP da rede: acl localhost src /32 acl rede_local src /8 b) Crie uma ACL com o tipo proto (protocolo) e adicione o protocolo "cache_object": acl manager proto cache_object O protocolo "cache_object" é usado para obter informações sobre o estado do Squid. c) É recomendável que permita apenas o servidor obter as informações do Squid, então adicione a seguinte regra: http_access allow manager localhost http_access deny manager d) Crie uma ACL do tipo method (método de requisição) e adicione o método PURGE: acl purge method PURGE cache. O método de requisição PURGE serve para limpar/excluir objetos armazenados no d) Para permitir que apenas o servidor possa exclua objetos, adicione a seguinte regra: http_access allow purge localhost http_access deny purge e) Crie uma ACL do tipo port (porta) e adicione as portas que serão liberadas: acl Safe_ports port f) Para bloquear o acesso em portas que não foram liberadas, adicione a seguinte regra: http_access deny!safe_ports O sinal de! significa negação. No caso acima, serão negadas todas as portas diferentes das listadas na ACL Safe_ports 8

9 g) Crie uma ACL do tipo method (método de requisição) e adicione o método CONNECT, que permite fazer conexão direta: acl connect method CONNECT h) Crie uma ACL do tipo port (porta) e adicione as portas dos protocolos com SSL que foram adicionadas na ACL "Safe_ports" e devem ser liberadas para conexão direta: acl SSL_ports port 443 acl SSL_ports port 563 acl SSL_ports port 873 # https # nntps # rsync i) Para bloquear o acesso em portas que não foram liberadas para conexão direta, adicione a seguinte regra: http_access deny connect!ssl_ports j) Crie uma ACL do tipo dstdomain (domínio de destino) e adicione um domínio iniciando com o ponto: acl domains dstdomain.twitter.com k) Se no caso forem vários domínios de destino, definir o caminho do arquivo que serão adicionados os domínios: acl domains dstdomain "/etc/squid/dominios" Para tanto é necessário criar o arquivo domínios como definido na ACL. Para tanto, crie o arquivo usando o seguinte comando # nano /etc/squid/dominios E adicione os seguintes domínios para teste:.twitter.com.youtube.com.vimeo.com l) Para bloquear o acesso nos domínios de destino, adicione a seguinte regra: http_access deny dominios m) Crie uma ACL do tipo url_regex (expressão regular na URL) e adicione uma expressão regular: 9

10 acl palavras url_regex sexo A ACL do tipo url_regex percorre url em busca de expressões regulares. A ACL é casesensitive, se no caso estiver procurando a expressão "sexo" e tiver "Sexo", serão consideradas diferentes. n) Para adicionar várias expressões, definir o caminho do arquivo que serão adicionadas às expressões. Usar a opção "-i" para tornar a ACL em case-insensitive: acl palavras url_regex -i "/etc/squid/palavras" Crie o arquivo "/etc/squid/palavras" como definido na ACL e adicione as expressões regulares: jogo blog msn regra: o) Para bloquear o acesso em URL s com as expressões regulares, adicione a seguinte http_access deny palavras p) Criar uma ACL do tipo urlpath_regex (expressão regulares no caminho da url) e definir o caminho do arquivo que será adicionado às expressões regulares: acl extensions urlpath_regex -i "/etc/squid/extensoes" A ACL do tipo urlpath_regex é semelhante a url_regex, só que é ignorado o domínio e protocolo. Por exemplo, a url " irá fazer a busca da expressão regular apenas nessa parte "/blog/invasao.html": Crie o arquivo "/etc/squid/extensoes" como definido na ACL e adicione as expressões regulares: # nano /etc/squid/extensoes Adicione as seguintes linhas: \.bat($ \? \&) \.exe($ \? \&) \.scr($ \? \&) q) Para bloquear o acesso em URL s path com expressões regulares, adicione a seguinte regra: 10

11 http_access deny extensoes r) Sem mais ACL para criar, adicione a seguinte regra para permitir que apenas as máquinas da rede e o servidor sejam liberados para acessar a Internet: http_access allow rede_local http_access allow localhost http_access deny all s) Com as ACL definidas, a sequência das regras deverá estar na ordenação correta, independente da ACL ser criada junto com a regra. É importante que a ACL seja criada antes de definir a regra. Aqui vai uma amostra de como deve está ordenado às regras: http_access allow manager localhost http_access deny manager http_access allow purge localhost http_access deny purge http_access deny!safe_ports http_access deny connect!ssl_ports http_access deny dominios http_access deny words http_access deny extensoes http_access allow rede_local http_access allow localhost http_access deny all Procedimentos Finais a) Recarregar as configurações do Squid: # /etc/init.d/squid3 reload ou # /etc/init.d/squid3 stop # /etc/init.d/squid3 start b) Configurar o navegador para acessar web via Proxy, apontando para o endereço do servidor Proxy pela porta Material complementar Referência completa do Squid pode ser encontrada no site oficial: 11

12 2. FIREWALL Firewall é o nome dado ao dispositivo de uma rede de computadores que tem por objetivo aplicar uma política de segurança a um determinado ponto de controle da rede. Sua função consiste em regular o tráfego de dados entre redes distintas e impedir a transmissão e/ou recepção de acessos nocivos ou não autorizados de uma rede para outra. Este conceito inclui os equipamentos de filtros de pacotes e de proxy de aplicações, comumente associados a redes TCP/IP. Figura 2 - Firewall na rede Os primeiros sistemas firewall nasceram exclusivamente para suportar segurança no conjunto de protocolos TCP/IP. O termo inglês firewall faz alusão comparativa da função que este desempenha para evitar o alastramento de acessos nocivos dentro de uma rede de computadores à uma parede corta-fogo (firewall), que evita o alastramento de incêndios pelos cômodos de uma edificação. Existe na forma de software e hardware, ou na combinação de ambos (neste caso, normalmente é chamado de "appliance"). A complexidade de instalação depende do tamanho da rede, da política de segurança, da quantidade de regras que autorizam o fluxo de entrada e saída de informações e do grau de segurança desejado. Existem basicamente dois tipos de firewalls: a) Nível de Aplicação - Este tipo de firewall analisam o conteúdo do pacote para tomar suas decisões de filtragem. Firewalls deste tipo são mais intrusivos (pois analisam o conteúdo de tudo que passa por ele) e permitem um controle relacionado com o conteúdo do tráfego. Alguns firewalls em nível de aplicação combinam recursos básicos existentes em firewalls em nível de pacotes combinando as funcionalidade de controle de tráfego/controle de acesso em uma só ferramenta. Servidores proxy, como o Squid, são um exemplo deste tipo de firewall. b) Nível de Pacotes - Este tipo de firewall toma as decisões baseadas nos parâmetros do pacote, como porta/endereço de origem/destino, estado da conexão, e outros parâmetros do 12

13 pacote. O firewall então pode negar o pacote (DROP) ou deixar o pacote passar (ACCEPT). O iptables é um excelente firewall que se encaixa nesta categoria. Os dois tipos de firewalls podem ser usados em conjunto para fornecer uma camada dupla de segurança no acesso as suas máquinas/máquinas clientes Tipo de Proteção O firewall vem com a finalidade de oferecer proteção a serviços que devem ter acesso garantido a usuários externos e serviços os quais serão bloqueados a todas/determinadas máquinas. É recomendável bloquear o acesso a todas as portas menores que 1024 por executarem serviços que rodam com privilégio de usuário root, e autorizar somente o acesso as portas que realmente deseja (configuração restritiva nesta faixa de portas). É também função do firewall analisar que tipo de conexões podem passar e quais bloquear. Serviços com autenticação em texto plano e potencialmente inseguros como rlogin, telnet, ftp, NFS, DNS, LDAP, SMTP RCP, X-Window são serviços que devem ser ter acesso garantido somente para máquinas/redes que você confia. Estes serviços podem não ser só usados para tentativa de acesso ao seu sistema, mas também como forma de atacar outras pessoas aproveitando-se de problemas de configuração. Outra tarefa do firewall é analisar e controlar quais máquinas terão acesso livre e quais serão restritas: - Que serviços deverão ter prioridade no processamento. - Que máquinas/redes nunca deverão ter acesso a certas/todas máquinas. - O volume de tráfego que o servidor manipulará. Através disso é possível balancear o tráfego entre outras máquinas, configurar proteções contra DoS, syn flood, etc. - O que tem permissão de passar de uma rede para outra (em máquinas que atuam como roteadores/gateways de uma rede interna). A análise destes pontos pode determinar a complexidade do firewall, custos de implementação, prazo de desenvolvimento e tempo de maturidade do código para implementação. Existem muitos outros pontos que podem entrar na questão de desenvolvimento de um sistema de firewall, eles dependem do tipo de firewall que está desenvolvendo e das políticas de segurança de sua rede. Existem três grandes grupos que fazem as funções de firewall: - Físicos - Filtros de pacotes - Firewall de aplicação Como firewall físico podemos citar roteadores que comutam protocolos, portanto, fazem o vinculo entre duas redes podendo ser elas diferente uma de outra. Para fazer o roteamento, o micro roteador deve possuir uma placa de rede em cada sub-rede. Também é necessário informar em cada máquina quem será o micro responsável pelo roteamento. O nome técnico desse micro é gateway. 13

14 Figura 3 Gateway Como firewall por pacotes refere-se ao que se restringe a trabalhar nas camadas TCP/IP, decidindo quais pacotes de dados podem passar e quais não. Tais escolhas são regras baseadas nas informações endereço IP remoto, endereço IP do destinatário, além da porta TCP usada. Quando devidamente configurado, esse tipo de firewall permite que somente "computadores conhecidos troquem determinadas informações entre si e tenham acesso a determinados recursos". Um firewall assim, também é capaz de analisar informações sobre a conexão e notar alterações suspeitas, além de ter a capacidade de analisar o conteúdo dos pacotes, o que permite um controle ainda maior do que pode ou não ser acessível. Firewalls de controle de aplicação (exemplos de aplicação: SMTP, FTP, HTTP, etc) são instalados geralmente em computadores servidores e são conhecidos como proxy. Este tipo não permite a comunicação direta entre a rede e a Internet. Tudo deve passar pelo firewall, que atua como um intermediador. O proxy efetua a comunicação entre ambos os lados por meio da avaliação do número da sessão TCP dos pacotes. Em linux, até a versão de kernel 2.2.x o firewall embutido era o IPChains. Em Versões de kernel maiores foi substituído pelo IPTables. Tanto um como outro trata endereços de IP, Serviços e portas com relação ao que deve ser trancado e ao que pode ser liberado IPTABLES No kernel do Linux 2.4, foi introduzido o firewall iptables (também chamado de netfilter) que substitui o ipchains dos kernels da série 2.2. Este firewall tem como vantagem ser muito estável (assim como o ipchains e ipfwadm), confiável, permitir muita flexibilidade na programação de regras pelo administrador do sistema, mais opções disponíveis ao administrador para controle de tráfego, controle independente do tráfego da rede local/entre redes/interfaces devido à nova organização das etapas de roteamento de pacotes. O iptables é um firewall em nível de pacotes e funciona baseado no endereço/porta de origem/destino do pacote, prioridade, etc. Funciona através da comparação de regras para 14

15 saber se um pacote tem ou não permissão para passar. Em firewalls mais restritivos, o pacote é bloqueado e registrado para que o administrador do sistema tenha conhecimento sobre o que está acontecendo em seu sistema. Ele também pode ser usado para modificar e monitorar o tráfego da rede, fazer NAT (masquerading, source nat, destination nat), redirecionamento de pacotes, marcação de pacotes, modificar a prioridade de pacotes que chegam/saem do seu sistema, contagem de bytes, dividir tráfego entre máquinas, criar proteções anti-spoofing, contra syn flood, DoS, etc. O tráfego vindo de máquinas desconhecidas da rede pode também ser bloqueado/registrado através do uso de simples regras. As possibilidades oferecidas pelos recursos de filtragem iptables como todas as ferramentas UNIX maduras dependem de sua imaginação, pois ele garante uma grande flexibilidade na manipulação das regras de acesso ao sistema, precisando apenas conhecer quais interfaces o sistema possui, o que deseja bloquear, o que tem acesso garantido, quais serviços devem estar acessíveis para cada rede, e iniciar a construção de seu firewall. O iptables ainda tem a vantagem de ser modularizável, funções podem ser adicionadas ao firewall ampliando as possibilidades oferecidas. Um firewall não funciona de forma automática (instalando e esperar que ele faça as coisas automaticamente), é necessário pelo menos conhecimentos básicos de rede TCP/IP, roteamento e portas para criar as regras que farão a segurança de seu sistema. A segurança do sistema depende do controle das regras que serão criadas INSTALAÇÃO Em sistemas Linux derivados do Debian a instalação pode ser feita pelo comando aptget, como se segue: # apt-get install iptables É importante lembrar que é necessário que o kernel tenha sido compilado com suporte ao iptables. O requerimento mínimo de memória necessária para a execução do iptables é o mesmo do kernel 2.4 (4MB). Dependendo do tráfego que será manipulado pela(s) interface(s) do firewall ele poderá ser executado com folga em uma máquina 386 SX com 4MB de RAM. Como as configurações residem no kernel não é necessário espaço extra em disco rígido para a execução deste utilitário. Para certificar-se que o iptables está instalado execute o seguinte comando: # modprobe iptables O pacote iptables contém o utilitário iptables (e ip6tables para redes ipv6) necessários para inserir as regras no kernel PACOTES IPTABLES - iptables - Sistema de controle principal para protocolos ipv4 15

16 - ip6tables - Sistema de controle principal para protocolos ipv6 - iptables-save - Salva as regras atuais em um arquivo especificado como argumento. Este utilitário pode ser dispensado por um shell script contendo as regras executado na inicialização da máquina. - iptables-restore - Restaura regras salvas pelo utilitário iptables-save REGRAS As regras no iptables são como comandos passados para que ele realize uma determinada ação (como bloquear ou deixar passar um pacote) de acordo com o endereço/porta de origem/destino, interface de origem/destino, etc. As regras são armazenadas dentro dos chains e processadas na ordem que são inseridas. As regras são armazenadas no kernel, o que significa que quando o computador for reiniciado tudo o que fez será perdido. Por este motivo elas deverão ser gravadas em um arquivo para serem carregadas a cada inicialização. Exemplo: iptables -A INPUT -s j DROP CHAINS Os Chain são locais onde as regras do firewall definidas pelo usuário são armazenadas para operação do firewall. Existem dois tipos de chains: - Os embutidos (como os chains INPUT, OUTPUT eforward) - Os criados pelo usuário. Os nomes dos chains embutidos devem ser especificados sempre em maiúsculas (note que os nomes dos chain são case-sensitive, ou seja, o chain input é completamente diferente de INPUT) TABELAS Tabelas são os locais usados para armazenar os chains e conjunto de regras com uma determinada característica em comum. As tabelas podem ser referenciadas com a opção -t tabela e existem três tabelas disponíveis no iptables: Filter Esta é a tabela padrão, contém três chains padrões: - INPUT: Consultado para dados que chegam a máquina - OUTPUT: Consultado para dados que saem da máquina - FORWARD: Consultado para dados que são redirecionados para outra interface de rede ou outra máquina. 16

17 Os chains INPUT e OUTPUT somente são atravessados por conexões indo/se originando de localhost. Observação: Para conexões locais, somente os chains INPUT e OUTPUT são consultados na tabela filter Nat Usada para dados que gera outra conexão (masquerading, source nat, destination nat, port forwarding, proxy transparente são alguns exemplos). Possui três chains padrões: - PREROUTING: Consultado quando os pacotes precisam ser modificados logo que chegam. É o chain ideal para realização de DNAT e redirecionamento de portas. - OUTPUT : Consultado quando os pacotes gerados localmente precisam ser modificados antes de serem roteados. Este chain somente é consultado para conexões que se originam de IPs de interfaces locais. - POSTROUTING: Consultado quando os pacotes precisam ser modificados após o tratamento de roteamento. É o chain ideal para realização de SNAT e IP Masquerading Mangle Utilizada para alterações especiais de pacotes (como modificar o tipo de serviço (TOS) ou outros detalhes que serão explicados a frente. Possui dois chains padrões: - INPUT: Consultado quando os pacotes precisam ser modificados antes de serem enviados para o chain INPUT da tabela filter. - FORWARD: Consultado quando os pacotes precisam ser modificados antes de serem enviados para o chain FORWARD da tabela filter. - PREROUTING: Consultado quando os pacotes precisam ser modificados antes de ser enviados para o chain PREROUTING da tabela nat. - POSTROUTING: Consultado quando os pacotes precisam ser modificados antes de serem enviados para o chain POSTROUTING da tabela nat. - OUTPUT: Consultado quando os pacotes precisam ser modificados antes de serem enviados para o chain OUTPUT da tabela nat CONFIGURAÇÃO Com as regras a seguir será configurado um servidor básico para firewall. a) Inicialmente é preciso verificar se o IPTables está instalado. Para isso execute o seguinte comando: #iptables v 17

18 b) Criar um arquivo chamado firewall dentro do diretório /etc/init.d e dar a ele permissão de execução: #touch /etc/init.d/firewall (criação do arquivo) #chmod +x /etc/init.d/firewall (dando permissão de execução) #vi /etc/init.d/firewall(abrindo o arquivo para edição) Para agilizar esta tarefa, o arquivo firewall pode ser baixado no link downloads do site. Sendo assim, ignorar o primeiro e o último comando: #cd /etc/init.d #wget #chmod +x /etc/init.d/firewall (Permissão de execução) Com estas simples configurações está instalado e configurado um firewall. c) Em se tratando de um firewall é recomendável bloquear respostas ao comando ping, mantendo o servidor escondido. Para isso, edite o arquivo /etc/sysct1.conf : # vi /etc/sysct1.conf E adicione as seguintes linhas: net.ipv4.icmp_echo_ignore_all = 1 Em situações reais é recomendável instalar outros recursos que darão maior flexibilidade, segurança e opções de administração para o responsável pela rede. Dentre ela destaca-se: Layer7 É um excelente plugin para o netfilter/iptables que trabalha na camada de aplicação, dando maior flexibilidade ao firewall. SARG SARG - Squid Analysis Report Generator é uma ferramenta que permite ver o que o usuário faz na Internet. Provê muitas informações sobre as atividades, tais como: tempos, bytes trafegados, sites acessados, etc. MRTG O MRTG é um programa feito em perl muito útil para analisar o tráfego utilizado em sua rede/link. Ele gera gráficos que te mostram o uso da banda em termos de velocidade. Firewall Admin Solução web que permite o gerenciamento do IPTables através de uma página web. Pode ser obtido através do comando: #cd /var/www #wget firewalladmin/ firewalladmin-0.3.tar.gz #chmod a+w config.php 18

19 Abrir um navegador web e digitar o endereço: Muito cuidado com esta ferramenta, pois se configurada incorretamente permite o acesso as configurações do firewall, através da Internet, por qualquer pessoa. Existem outras ferramentas que podem ser implementadas, bem como outras distribuições de firewall s, como o Endian, por exemplo. No entanto optamos por utilizar as ferramentas aqui demonstradas. De igual forma, as configurações aqui descritas não são suficientes para implementação comercial da solução. Tais configurações são somente para efeitos didáticos. Outras configurações muito interessantes para aprendizado podem ser encontradas em: REFERÊNCIAS Básica Complementar SILVA, Cesar Augustus - Instalando o Servidor Squid no Linux UBUNTU Documentation 19