Sistema firewall baseado em netfilter

Transcrição

1 Instituto Polité cnico dé Lisboa Sistema firewall baseado em netfilter Projecto submetido para atribuição do título de Especialista Candidato Pedro António Marques Ribeiro Departamento de Sistemas de Informação e Comunicações Instituto Politécnico de Lisboa (pribeiro@net.ipl.pt) Área Departamental de Engenharia de Electrónica e Telecomunicações e de Computadores Instituto Superior de Eng enharia de Lisboa (pribeiro@deetc.isel.ipl.pt ) i

2 Resumo Confrontados com a crescente necessidade de capacidade e flexibilidade do sistema de delimitação da fronteira entre a rede de dados e comunicações do Instituto Politécnico de Lisboa e a Internet, foi desenvolvida uma solução completamente baseada em software de fonte aberta (open source). Este documento resume o processo de desenvolvimento, preparação e colocação em funcionamento dos sistemas que actualmente suportam a tarefa de delimitação de periferia da rede informática do IPL, englobando as funções principais de filtragem de tráfego e de conversão de endereços (NAT). São analisados em detalhe os diferentes componentes utilizados, a interacção entre estes e destes com os sistemas exteriores com que têm de se relacionar. Palavras chave firewall, netfilter, iptables, Linux, quagga, ospf ii

3 Índice 1. Antecedentes e Motivação O projecto netfilter.org... 3 Características principais... 3 Origens do netfilter Arquitectura... 3 Tabelas... 3 Chains... 3 Pontos de intercepção (chains base)... 5 Regras... 5 Acções possíveis Aplicações de gestão e manutenção Módulos de validação especializados Tráfego não sujeito ao netfilter Módulo de manutenção de estado conntrack... 8 Estados segundo o conntrack... 8 Actualização de estados... 9 Modulos de apoio (helper) Network Address Translation - NAT Particularidades do funcionamento da tabela nat... 9 Modulos de apoio (helper) ao NAT NAT de mensagens de erro ICMP netfilter segundo o STUN (Session Transversal Utilities for NAT) NAT usando DNETMAP Quando devidamente parametrizado: Extensibilidade Implementação do sistema Evolução da topologia para o novo sistema Hardware e sistema Linux de base Sistema operativo Optimizações do núcleo (kernel) Optimização de parâmetros de sistema Interrupts Memória Gestão de energia Armazenamento de sistema e dados Sistemas de ficheiros iii

4 3.5. Conectividade Encaminhamento de tráfego IPv4/IPv Tratamento dos eventos de sistema Ficheiros e directorias envolvidos Gestão do netfilter no sistema Actualização de tabelas Actualização de regras Ficheiros de suporte Endereçamento e uso de NAT Planos de endereçamento Estrutura base das chain utilizadas Variáveis BASH definidas em IN4Fw.sh para utilização nos scripts Chains de filtragem em IPv4 para INPUT e OUTPUT Chains de filtragem em IPv4 para FORWARD Chains de NAT em IPv Chains em IPv Variáveis BASH definidas em IN6Fw.sh para utilização nos scripts Chains de filtragem em IPv6 para INPUT e OUTPUT Chains de filtragem em IPv6 para FORWARDING Boas práticas em listas de acesso Optimizar listas e chains Reordenação de regras Monitorização e desempenho Usos paralelos para o sistema Evoluções futuras do sistema Conectividade plena a 10Gbit/s Elevada disponibilidade na transição activo/backup Encaminhamento de IP Multicast Aplicação de QoS Referências e Bibliografia iv

5 Índice de figuras Figura 1 - Percursos de tráfego, pontos de intercepção e tabelas... 4 Figura 2 Avaliação nos pontos de intercepção nas diferentes tabelas... 5 Figura 3 Situação original, o FWSM como firewall de IPv4 e o IPv6 filtrado nos routers Figura 4 - O sistema netfilter colocado em linha com o FWSM durante os testes Figura 5 - Estrutura final, após estabilizada a solução e removido o FWSM Figura 6 - PC ASUS RS120-E3/PA Figura 7 - Estrutura de partições nos discos rígidos Figura 8 - Interligação redundante do sistema aos switch Figura 9 - Percursos de tráfego IPv4 e IPv Figura 10 - Exemplo de plano de endereçamento IPv Figura 11 - Chains de INPUT e OUTPUT da tabela filter de IPv Figura 12 Chains de filtragem do tráfego em FORWARD Figura 13 - Chains de nat em IPv Figura 14 - Chains de filtragem para IPv Figura 15 - Carga de processamento (Itchy) Figura 16 - Tráfego de rede na porta de rede «inside» (Itchy) Figura 17 - Precisão do relógio Figura 18 - Uso de interrupts pelo hardware (Itchy) Figura 19 - Alocação de memória (Itchy) Figura 20 - Carga de processamento (Scratchy) Figura 21 - Tráfego na porta de rede «inside» (Scratchy) v

6 vi

7 1. Antecedentes e Motivação A filtragem da fronteira da rede informática do IPL (IPLNet) com a Internet passou ao longo dos anos por diversas fases. Quando a rede tomou forma no ano 2000, a Internet ainda era uma zona predominantemente pacifica sem grandes necessidades de muros de contenção mas já nessa altura a função foi assumida pelos routers que existiam, primeiro um Cisco 2503 e depois um Cisco 4500M. A filtragem era nesta altura bastante simples, apesar da reduzida capacidade de processamento dos routers mencionados, não se verificava impacto significativo dos filtros no desempenho da rede, no entanto há que lembrar que à altura os débitos da ligação Internet evoluíram entre 64kbit/s e 1,5Mbit/s. A filtragem em si era realizada por listas de acesso (Access Control List - ACL) do Cisco IOS que se limitavam a enumerar no sentido inbound (vindo da Internet) e outbound (destinado à Internet) as condições nas quais o tráfego era aceite, validando parâmetros nível 3 e nível 4 como endereços IP, portos TCP/UDP, tipos de mensagem ICMP, etc. Com os incrementos posteriores de débito a tarefa transitou para outro equipamento, um Cisco 7206VXR com a carta de CPU NPE400 e tal permitiu sustentar o serviço quer pelo crescimento do débito, quer pela complexidade que a filtragem começou a tomar com o crescimento imenso da rede interna, das aplicações mais especificas que nela foram criadas pela comunidade utilizadora e com a significativa adesão de interesses mal intencionados à Internet como veículo das suas actividades. À altura do projecto e-u/eduroam 1 em 2003 percebeu-se que o crescimento que a rede teria iria exigir um equipamento dedicado à tarefa, com o requisito de tornar amigável a gestão dos filtros que nesta altura tinham já várias centenas de regras cada e que, a cada alteração, implicava uma penosa análise da interacção das novas regras a inserir com as existentes bem como a riscos significativos de instabilidade nos momentos de actualização das listas. (nesta altura uma qualquer alteração numa lista implicava o apagar e refazer da mesma criando períodos de bloqueio ou promiscuidade total ao tráfego) A opção tomada foi a inclusão no router/switch (Multilayer Switch MLS) que se adquiriu para nó central da rede (Catalyst 6509), de um módulo FWSM (Firewall Switch Module) que é basicamente uma versão evoluída do clássico firewall PIX da Cisco, com a vantagem de ter uma ligação de elevada capacidade, teoricamente 3 x 1Gbit/s ao barramento do MLS. Os objectivos principais foram atingidos, a filtragem deixou de ser um entrave ao desempenho das ligações Internet que andavam agora na ordem das dezenas a centenas de Mbit/s. A gestão foi bastante simplificada com o apoio de uma aplicação gráfica integrada no equipamento e que permitia a gestão do sistema de uma forma bastante mais estruturada. Também será importante realçar o facto da implementação de filtragem do FWSM possuir a noção de estado (statefull) e conseguir de uma forma mais consciente tomar a decisão de aceitar tráfego associado a comunicações previamente aceites. Infelizmente o modelo de funcionamento do equipamento era deveras rígido, as funções de filtragem e de conversão de endereços (Network Address Translation NAT) eram frequentemente misturadas, algumas aplicações básicas da Internet (ex. FTP) simplesmente não funcionavam através dele pois não possuía a inteligência para filtragem baseada nas camadas superiores de rede. 1 Rede sem fios académica e internacional: 1

8 Outra limitação significativa deste equipamento foi a falta de suporte de IPv6, suporte este que só foi incluído tardiamente e deveras limitado quando comparadas as funcionalidades com as equivalentes de IPv4. À altura a solução foi manter a filtragem de IPv6 do lado do router de fronteira (usando IOS ACLs) criando uma ligação em paralelo com o FWSM exclusivamente para chegar com o tráfego IPv6 ao centro da rede saltando por cima do FWSM. O factor principal que ditou o abandono do FWSM foi no entanto, o débito. Quando a conectividade Internet passou para 1Gbit/s tornou-se evidente que algo pelo meio impedia que se usufruísse em pleno desta e testes realizados confirmaram que não se conseguia passar por este muito mais que 500Mbit/s. Nesta altura, também pesou na decisão a evolução da Internet IPv6 que cresceu significativamente dentro e fora do IPL e pelo volume de tráfego e complexidade da filtragem já se tornava incomportável ser suportada por IOS ACLs. A solução para esta actualmente crítica e rigorosa função é descrito adiante em muito maior detalhe e resume-se no título Sistema Firewall Baseado em Netfilter. 2

9 2. O projecto netfilter.org netfilter é o nome dado ao actual subsistema existente no Linux que dá suporte às facilidades de gestão, filtragem e manipulação de pacotes. Este inclui componentes ao nível do núcleo que executam as funções de baixo nível e componentes ao nível utilizador que realizam a gestão e consulta das listas e restantes parâmetros. Características principais Filtragem de pacotes com ou sem estado para IPv4 e IPv6 Todos os tipos comuns de alteração de endereços e portos, NAT/NATPT em IPv4 e IPv6 Arquitectura flexível e extensível Múltiplas APIs para extensões de terceiros Origens do netfilter O projecto foi iniciado em 1998 por Rusty Russell que já tinha sido também o autor do antecessor ipchains. Actualmente suportado pela chamada Netfilter Core Team ou simplesmente coreteam, equipa formada por diversas pessoas com grande reputação na área. As fontes de inspiração para o projecto remontam ao ipfw do BSD e aos antecessores no Linux ipfwadm e ipchains. A grande diferença do netfilter em relação aos antecessores está essencialmente na estruturação de funcionalidades e na criação de uma framework comum que funciona como base para todas as funções e aplicações desenvolvidas em torno desta Arquitectura Tabelas O netfilter define quatro tabelas dedicadas a diferentes funcionalidades, a por omissão (filter) para filtragem de pacotes, outra (nat) para as funções relacionadas com a alteração de endereços, portos e afins em trânsito (Network Address Translation - NAT), uma terceira (magle) para outros tipos de manipulação de parâmetros em pacotes, como mexidas de precedência ou ToS (Type of Service) ou tarefas mais complexas com ajustes nas extensões de cabeçalho TCP que realizam a negociação do MSS (Maximum Segment Size); finalmente a tabela raw permite manipulações que alteram o próprio comportamento do netfilter como excluir determinado tráfego do controlo de estado. Chains Ao contrário da maioria das implementações deste tipo de funcionalidades em que o processo de decisão é baseado numa simples pesquisa sequencial numa lista de regras, o netfilter expande o conceito, permitindo a existência de múltiplas chain (nome que aqui é dado a cada lista de regras) associadas a cada tabela e que podem ter regras e acções para além das típicas aceitar ou rejeitar. Nestas é possível a acção executada ser o salto para outra chain, resultando num encadeamento que tende a formar uma árvore de decisão, árvore esta que simplifica extraordinariamente a estruturação das regras e contribui significativamente para o encurtar do número de regras a validar até à decisão final, significando portanto maior clareza na gestão granular das regras e simultaneamente, melhor desempenho. 3

10 Na gestão das chain, as regras podem ser adicionadas à cauda da lista, inseridas em determinada posição de entre as existentes, removidas ou substituídas; as chains podem ser criadas, removidas ou removidas todas as suas regras. PREROUTING conntrack mangle IMQ nat QoS INGRESS INPUT INPUT ROUTING + PDBB mangle nat filter FORWARD mangle filter Local Process OUTPUT ROUTING OUTPUT ROUTING OUTPUT conntrack mangle POSTROUTING mangle nat IMQ nat filter QoS EGRESS Figura 1 - Percursos de tráfego, pontos de intercepção e tabelas A Figura 1 foi elaborada a partir das informações disponíveis nas referências [1, 2] consultadas. 4

11 Pontos de intercepção (chains base) Ao longo do normal percurso de um pacote pela pilha de protocolos TCP/IP, quer seja para uma tarefa de encaminhamento ou para o tráfego local do sistema, o netfilter criou diversos pontos de intercepção para realizar as diversas manipulações que disponibiliza. Os pontos de intercepção são implementados como listas de acesso (chains) base que existem de origem no sistema e não podem ser removidas, somente apagado o seu conteúdo. Outra característica única destas chain é o facto de possuírem uma acção por omissão, designada de política, acção esta que será aplicada a todo o tráfego que sendo submetido à avaliação do ponto de intercepção, atinja o fim da árvore de chains sem que tenha sido tomada qualquer decisão. Chains \ Tables raw mangle nat filter PREROUTING POSTROUTING 1 2 INPUT OUTPUT FORWARD 1 2 Figura 2 Avaliação nos pontos de intercepção nas diferentes tabelas A Figura 2 identifica a disponibilidade dos diferentes pontos de intercepção em cada uma das quatro tabelas, indicando também a ordem de processamento em cada ponto de intercepção. Genericamente pode-se afirmar que a ordem de processamento das tabelas em cada ponto de intercepção será sempre raw, mangle, nat e finalmente filter, de entre as tabelas presentes em cada ponto de intercepção. Esta ordem terá de ser tida em conta, por exemplo, se determinado tráfego for sujeito a NAT em OUTPUT, as regras de filtragem que existam nesse mesmo ponto de intercepção (OUTPUT) terão de ter em conta o tráfego após as alterações ocorridas na tabela nat. O diagrama da Figura 1 ajudará com certeza a de uma forma mais gráfica se perceber os percursos de tráfego possíveis e o posicionamento dos pontos de intercepção ao longo destes. Regras Cada regra de uma chain inclui um conjunto de validações a realizar, validações estas que podem ser realizadas directamente sob o cabeçalho de cada pacote ou validações mais complexas que envolvam a análise do estado conhecido do pacote no contexto das ligações em curso ou ainda validações sobre condições externas arbitrárias como por exemplo, se é Domingo. Caso o conjunto de validações realizadas se suceda (todas resultam em verdadeiro ), é realizada uma acção definida na regra. Um outro aspecto importante no processo de definição das regras é que as validações não possuem posições fixas dentro da regra, tendo apenas que se ter em atenção as dependências, por exemplo só é possível evocar uma validação de portos, após se ter indicado que o protocolo de transporte é TCP ou UDP. Acções possíveis ACCEPT Permitir o continuar do percurso do pacote, sem qualquer alteração. DROP Descartar o pacote sem qualquer mensagem de volta. Não é recomendada a utilização desta acção nas outras tabelas que não a filter. REJECT Descartar o pacote com o aviso conveniente gerado numa mensagem de volta, normalmente uma variante de ICMP Unrechable, ou TCP RESET se a regra explicitava aplicar-se a tráfego TCP. Acção só permitida na tabela de filter. 5

12 LOG Usada para gerar um evento descrevendo os parâmetros do pacote que foi validado pela regra (opcionalmente pode incluir alguns detalhes extra sobre o pacote e até 32 caracteres com uma etiqueta de texto). <chain> - Quando na acção é indicado o nome doutra chain, resultará no encadeamento da lista indicada, se as condições indicadas na regra sucederem todas. Se a chain para onde se saltou a execução for concluída sem decisão, a avaliação é retomada na regra seguinte (à que provocou o salto) da chain anterior. Existe a possibilidade do salto ser sem hipótese de retorno (tipo goto), mas é uma situação pouco utilizada. RETURN Tal como o nome indica, conclui a execução da chain em que se encontre, provocando ou o retorno para a chain anterior ou o fim da avaliação do ponto de intercepção e a execução da política definida, caso seja aplicada numa chain base. DNAT Acção possível na tabela nat, envolvendo alteração de parâmetros de destino, endereços, portos ou outros. Pode ser parametrizável para usar um bloco de endereços a distribuir pelos acessos activos, com ou sem garantia da manutenção dos endereços pós-nat em comunicações sucessivas do mesmo par origem/destino. Pode forçar a gama de portos a utilizar ou até alterar aleatoriamente o porto. A aplicação mais comum é na distribuição de ligações por um cluster ou na disponibilização pública de recursos que usem endereçamento interno. SNAT Acção disponível na tabela nat, agora envolvendo alteração de parâmetros de origem e com possibilidades idênticas às do DNAT. Sempre que possível (disponível) o porto origem é mantido, se for necessário alterar, é mantido dentro da gama original estando definidas: 0-511, e A aplicação mais comum desta acção é no fornecimento de conectividade a redes que usem endereçamento interno RFC1918. MASQUERADE Outra acção, exclusiva da tabela nat, é um caso particular de SNAT em que o endereço pós-nat é automaticamente seleccionado como sendo o endereço base da interface de saída. A aplicação mais comum desta acção é no fornecimento de conectividade a redes internas residenciais em que o endereço pós-nat é único e dinamicamente atribuído. Outras Para além destas acções de uso mais frequente, existem imensas outras, algumas que serão mencionadas em situações concretas noutros capítulos, outras encontram-se documentadas nas páginas de manual de sistema (man) associadas à ferramenta de gestão do netfilter, iptables Aplicações de gestão e manutenção iptables, ip6tables Ferramenta base para a manipulação individual de regras e chains. iptables-save Realiza a exportação do conjunto de regras e chains, incluindo os contadores de utilização e políticas por omissão. A exportação resultante permite repor de forma eficiente um estado anterior de parametrização de tabelas, utilizando o iptables-restore ou iptablesapply. iptables-restore Realiza a importação do resultado de um iptables-save armazenado. Tipicamente utilizado para repor o estado do netfilter durante o iniciar de um sistema. iptables-apply Ferramenta vocacionada para a aplicação remota de um conjunto de regras exportadas pelo iptables-save e que realiza a alterações após confirmação de que as alterações identificadas são aceites pelo utilizador. 2 Segundo man iptables-extensions 6

13 conntrack Ferramenta de consulta e manipulação da tabela de manutenção de estado conntrackd Aplicação residente para sincronização da tabela de conntrack entre máquinas que trabalhem em cluster [3] As aplicações de nome iniciado em ip6 são variantes idênticas das sem o 6 no nome e assumem por omissão a utilização das tabelas relativas a IPv Módulos de validação especializados Descrevem-se de seguida diversos módulos especializados de validação em utilização no sistema limit Retorna verdadeiro baseando-se no critério de filtragem tipo token bucket, permitindo que determinadas regras ocorram somente N vezes por período de tempo, com a possibilidade de definir um valor inicial de rajada em que dará sempre resultado verdadeiro. hashlimit Apresenta um comportamento base idêntico ao do módulo limit, no entanto, usa um contexto de filtragem para cada valor hashed, permitindo criar limitações individuais a grupos de máquinas ou portos, dependendo dos parâmetros que se seleccionem para o cálculo do hash. ttl Realiza comparações com o valor de TTL (Time To Live) presente no pacote, este módulo é específico para IPv4, para IPv6 existe o hl com funcionalidade idêntica. multiport Permite ultrapassar a limitação da validação base que apenas permite uma gama de valores de porto TCP/UDP presente num pacote. Com este é possível enumerar um conjunto de até 15 portos arbitrários, a existência de qualquer deles no pacote fará o módulo retornar verdadeiro. conntrack Confirma se o módulo de manutenção de estado conntrack atribui determinado estado ao pacote em análise. Este módulo de validação assume actualmente as funcionalidades do equivalente state actualmente descontinuado. recent Permite a criação dinâmica de listas de endereços e posterior validação sobre estas de diferentes formas. ipp2p Módulo de detecção de comunicações pertencentes a aplicações P2P (Peer-to-Peer), não muito fiável e com o desenvolvimento abandonado. string Valida a existência de determinado padrão de texto/binário no conteúdo dos pacotes. geoip Consulta uma base de dados estática para validação da região ou país a que determinado endereço pertence. Há que ter em conta a qualidade da base de dados usada e as limitações da sua natureza estática. connbytes Toma a decisão baseando-se na quantidade de tráfego da ligação ipv6header Valida a existência de determinados cabeçalhos de extensão no IPv6 statistic Permite associar à regra uma decisão estatística ou com determinada frequência time Valida o momento temporal da chegada do pacote, permitindo condicionar o suceder da regra a determinado período. set Permite validar pacotes contra grupos de endereços ou portos de elevada dimensão, fazendoo de uma forma extremamente eficiente. Os grupos de endereços são por este módulo organizados numa árvore de pesquisa, os grupos de portos em bitmaps. 7

14 2.4. Tráfego não sujeito ao netfilter Dada a existência no Linux de diversas interfaces de programação (API Application Programming Interface) de baixo nível que permitem o envio e recepção de pacotes, é importante notar que em alguns casos as aplicações conseguem gerar tráfego que não é filtrado na chain OUTPUT ou receber tráfego que seja descartado na chain INPUT. Uma situação onde se pode encontrar este tipo de comportamento é nas aplicações de BOOTP/DHCP, pela necessidade que têm enviar e receber pacotes em fases em que a pilha de protocolos TCP/IP ainda não se encontra parametrizada. Nas aplicações de análise de tráfego, a API usada pela biblioteca de captura PCAP [4] que é usada pela maioria das aplicações de sniffing como o tcpdump [4] e o wireshark/tshark [5] tem também acesso ao tráfego antes de este passar pelos pontos de intercepção Módulo de manutenção de estado conntrack Sem a existência ou a activação deste módulo, o netfilter só pode tomar decisões baseando-se no conteúdo de cada pacote que analisa ou de condições externas, considerando-se portanto, um packet filter sem a noção de estado das comunicações, o que se designa vulgarmente de stateless. O conntrack executa-se de uma forma independente das tabelas e chains e mantém em estruturas de dados optimizadas para a pesquisa, informações detalhadas sobre o estado das comunicações em curso como os endereços, protocolo, portos envolvidos, possível ocorrência de alterações de endereços (NAT), números de sequência TCP, etc. Dada a necessidade de manutenção de estado que a maioria das funcionalidades de NAT envolvem, este é um módulo obrigatório para o suporte de NAT. Usando o módulo de verificação conntrack numa regra, é possível confirmar se o pacote analisado pertence a alguma comunicação em curso, se está de alguma forma relacionado com uma comunicação em curso, se é novo, etc. Apesar de se considerar genericamente que este módulo mantém a informação numa única tabela, na realidade as tabelas envolvidas são duas. A tabela base (conntrack) que mantém o estado das comunicações conhecidas e uma segunda tabela designada de expectation que mantém a informação acerca de comunicações que o sistema deduz que venham a ocorrer mas, para as quais nunca foi processado qualquer pacote. A tabela de expectation é mantida pelos módulos helper e é essencial no apoio à filtragem de protocolos mais complexos que estabeleçam novas comunicações baseando-se em parâmetros negociados sobre as comunicações em curso, exemplos de protocolos que a usam são o SIP, PPTP, H323 e FTP. Se necessário, é possível realizar operações sobre estas tabelas, listando, adicionando, removendo, monitorizando eventos, consultando estatísticas ou apagando-as; recorrendo à ferramenta de linha de comandos com o mesmo nome do módulo, conntrack. Estados segundo o conntrack Segundo a classificação do conntrack, estes são os estados mais comuns ESTABLISHED O pacote pertence a uma comunicação para a qual já ocorreu troca bidireccional de mensagens. NEW O pacote não pertence a nenhuma comunicação conhecida previamente. 8

15 RELATED O pacote, apesar de não pertencer directamente a nenhuma comunicação em curso, o conntrack ou algum dos módulos auxiliares especializados em protocolos específicos, conseguese estabelecer uma associação que o identifique como associado a uma comunicação conhecida, sendo por exemplo uma mensagem de erro ICMP ou uma ligação adicional negociada pelo protocolo (ex. FTP DATA). DNAT Se o pacote pertence a uma comunicação que tenha sido sujeita localmente a alterações de parâmetros de destino (endereços ou portos). SNAT Se o pacote pertence a uma comunicação que tenha sido sujeita localmente a alterações de parâmetros de origem (endereços ou portos). INVALID Se o pacote não se encontra de forma alguma associado a uma comunicação conhecida e, ou tem algum parâmetro com um valor inválido, ou pertence a uma fase intermédia do protocolo que exigiria já a existência de estado conhecido. UNTRACKED Se explicitamente numa regra da tabela de raw se indicou que o tráfego em questão não seria sujeito à manutenção de estado Actualização de estados O processamento de actualização de estados na conntrack, dos contadores das comunicações em curso e as manipulações de NAT previamente decididas nas chain, é realizado antes da consulta de qualquer das tabelas, nos pontos de intercepção PREROUTING e OUTPUT (neste último somente para o tráfego gerado localmente). Modulos de apoio (helper) De origem, no núcleo, são incluídos diversos módulos que quando carregados apoiam o conntrack na manutenção do estado das comunicações em curso de protocolos que envolvam múltiplas ligações negociadas dinamicamente. De entre os suportados salientam-se: FTP, H.323, IRC, NETLINK, PPTP, GRE, UDPLite SIP e TFTP Network Address Translation - NAT Particularidades do funcionamento da tabela nat Ao contrário das restantes tabelas, a nat só é consultada (e seus pontos de intercepção) para o tráfego novo. Para todas as comunicações já conhecidas e sujeitas a NAT, o próprio módulo especializado no apoio ao NAT tratará de realizar as alterações de cabeçalho necessárias em qualquer dos sentidos. A situação relatada acima pode ser observada consultando os contadores de utilização das regras incluídas nas chains da tabela de NAT, estes irão incrementar muito menos do que as que lidam com o mesmo tráfego nas tabelas restantes. A implementação de NAT do netfilter tem também a particularidade de permitir realizar NAT para comunicações TCP/UDP, utilizando um endereço público que em simultâneo está em uso em determinada máquina. Esta funcionalidade permitirá, por exemplo, manter a visão virtual exterior de que corresponde a determinado endereço, mas depois internamente os acessos HTTP são suportados por uma máquina e os de HTTPS por outra. Em consequência desta versatilidade suportada sobre as informações de estado mantidas na conntrack, em situações relativamente raras, é possível que determinada máquina (detendo um endereço público e sem qualquer regra no firewall que obrigue este a usar NAT), veja algumas 9

16 comunicações serem sujeitas a NAT envolvendo a alteração de portos origem, se o porto por esta seleccionado já estava em uso por NAT nesse endereço. Modulos de apoio (helper) ao NAT De origem no núcleo são incluídos diversos módulos que quando carregados apoiam o NAT no ajuste de parâmetros dos protocolos de forma a maximizar a transparência destes à existência do NAT. De entre os suportados salientam-se: FTP, H.323, IRC, PPTP, GRE, UDPLite, SIP e IRC NAT de mensagens de erro ICMP O suporte básico de conntrack e NAT têm de realizar algumas tarefas fora do comum para que o sistema tenha a máxima transparência perante os protocolos das camadas acima de IP. Quando uma comunicação que atravessou o firewall (e da qual foi criado estado) provoca um erro durante o seu trânsito pela Internet ou ao atingir o destino, é normalmente gerada na volta uma mensagem ICMP Unrechable reportando o detalhe do erro. Chegada a mensagem de erro ao firewall, há que de alguma forma relacionar esta com a mensagem de lhe deu origem e encaminha-la para a máquina interna correcta, caso a comunicação envolvesse NAT. Para tal é realizada a análise da amostra do pacote original (que gerou o erro), que é incluída no corpo da mensagem de erro ICMP. No ICMPv4 as regras ditam que a amostra deve incluir o cabeçalho IP e os 8 bytes seguintes, no caso do ICMPv6, toda a mensagem sem que se exceda o mínimo MTU de 1460bytes. Endereços, portos e outros identificadores são então usados na comparação com os registos da conntrack e, caso seja realizada validação de estado e se encontre relação, o tráfego considerado RELATED. Caso a comunicação original tenha envolvido NAT, alguns ajustes para além dos básicos terão de ser realizados. No cabeçalho ICMP: O endereço destino alterado do pós-nat para o da máquina da rede interna que originou o pacote. O checksum corrigido para um valor consistente com as alterações realizadas No cabeçalho IP e 8 bytes adicionais incluídos no corpo da mensagem ICMP O endereço origem alterado do pós-nat para o da máquina da rede interna que originou o pacote. Repostos os portos ou identificadores originais que tinham sido alterados durante o NAT. O checksum IP corrigido para um valor consistente com as alterações realizadas. 10

17 netfilter segundo o STUN (Session Transversal Utilities for NAT) 3 Diversas aplicações dependem da detecção da existência e comportamento específicos de cada implementação de NAT, de forma a conseguirem ultrapassar as limitações de conectividade que este implicitamente provoca. A implementação de NAT do netfilter apresenta um comportamento não directamente classificado no RFC3489. Na recepção de novas comunicações exteriores destinadas a endereços pós-nat, estas são aceites desde que usem um porto origem usado anteriormente em NAT, no entanto o IP origem não é validado, colocando a sua classificação como um Port Restricted mais permissivo que o definido no RFC, por não realizar validação de se endereço origem da nova comunicação fora anteriormente alvo de alguma comunicação originada na rede interna ao NAT. Sempre que possível os valores de porto utilizados são mantidos durante o processo de NAT o que lhe atribui também a característica de preservar portos. O chamado hairpin não é de base suportado, isto é, duas máquinas na rede interna ao NAT não conseguirão comunicar entre si usando como endereço destino, o endereço pós-nat NAT usando DNETMAP A necessidade do estabelecimento de uma associação unívoca entre máquinas da rede interna e os endereços com que aparecem no exterior conduziu à utilização deste módulo especializado de NAT. As aplicações em geral, não contam com a possibilidade de múltiplas ligações envolvendo as mesmas máquinas terminais, poderem sofrer NAT e usar endereços pós-nat distintos, o que em algumas configurações de NAT pode ocorrer e impedir o correcto funcionamento. Quando um utilizador relatava um problema de comunicação e havia a necessidade de analisar as comunicações envolvidas, a filtragem do tráfego relevante para a análise era complicada pois múltiplas máquinas internas apareciam ao exterior com o mesmo endereço. Quando uma entidade judicial requer informações acerca de comunicações suspeitas de estarem relacionadas com um caso em investigação, solicitam-nas tipicamente com base nos endereços visíveis do exterior a determinado dia e hora. Sendo o endereço pós-nat partilhado por grupos significativos de máquinas internas, torna-se praticamente impossível manter registos que possam associar a origem interna da comunicação. O não prestar da informação torna-nos implicitamente como coniventes com o eventual acto realizado. Para resolução ou minimização dos problemas acima referidos, foi utilizado o módulo DNETMAP [6] que permite a partilha temporal de um bloco de endereços públicos pelos utilizadores de NAT. Quando devidamente parametrizado: Realiza uma associação dinâmica entre endereço IP interno e externo. Sempre que um novo IP tenta comunicar para o exterior, é utilizado um endereço público de entre os disponíveis e que só é libertado ao fim de determinado tempo sem uso. O NAT realiza-se de forma bidireccional mediante as regras de funcionamento do restante NAT do sistema. Cada cliente tem o seu IP externo exclusivo durante um período de tempo automaticamente renovável. É maximizada a persistência das relações já que os endereços públicos fora de uso, até esgotamento do bloco ficam reservados para o mesmo endereço interno. 3 RFC3489/RFC

18 As associações e o libertar de pares de endereço interno/externo são registadas para possível análise posterior. Actualmente cerca de (potenciais) endereços internos partilham um bloco de 1024 endereços públicos com uma taxa de ocupação máxima pouco acima dos 50% Ao longo do período em que está em uso este módulo, verificou-se que esporadicamente os utilizadores a quem era associado um endereço público com o byte de menor peso de valor 0 ou 255 tinham o acesso bloqueado a algumas organizações devido à visão distorcida de alguns firewall acerca do encaminhamento IP que consideram que tais endereços serão sempre de rede ou de broadcast (e portanto inválidos para como endereços de máquina) assumindo que todas as redes são CIDR /24. Para minimizar este problema, nas versões mais recentes do módulo é possível realizar associações estáticas que coloquem de quarentena os endereços do pool que se encontrem nestas condições Extensibilidade Tal como qualquer software de código aberto (open source), o netfilter pode ser melhorado por qualquer pessoa ou entidade, corrigindo falhas, adicionando funcionalidades ou módulos. Da experiencia de desenvolvimento do autor no passado, no desenvolvimento de um módulo similar ao de verificação de TTL, salienta-se o facto de toda a adição que afecte de alguma forma parâmetros da ferramenta iptables irá implicar o desenvolvimento em duas frentes distintas. O componente que executará a acção pretendida terá de ser desenvolvido em torno das fontes do núcleo do Linux, a componente que interpretará e validará os parâmetros será desenvolvida sob as fontes do iptables. Dentro do possível, se se considerar que o desenvolvimento realizado terá interesse para uma comunidade alargada, será de todo conveniente a submissão do trabalho realizado à equipa que realiza a manutenção dos pacotes de software envolvidos, para que este ganhe uma dinâmica própria, seja revisto e melhorado por outros e passe a fazer parte dos pacotes oficiais, dispensando a manutenção dos patch para cada versão de núcleo e iptables que entretanto sejam publicadas. 12

19 3. Implementação do sistema 3.1. Evolução da topologia para o novo sistema Dada a complexidade dos filtros envolvidos e da função critica desempenhada bem como a necessidade de manutenção da conectividade 24h/dia, toda a lógica de filtragem foi reestruturada e convertida para a nova sintaxe bem como exploradas as facilidades disponíveis no novo sistema. Este foi temporariamente configurado num modo passa-tudo, colocando todas as regras que rejeitariam tráfego a, ao invés disso, registarem o evento e aceitarem-no. VLAN5 Chassis Cat6500 VLAN1101 FCCN/Internet C7206 ALADDIN FWSM Cat6500 HULK CORE/Redes IPL IPv6 C7206 GADGET Cat4500 STINGRAY Figura 3 Situação original, o FWSM como firewall de IPv4 e o IPv6 filtrado nos routers O sistema netfilter foi integrado nos protocolos de encaminhamento usados nesta zona da rede e após verificado o correcto comportamento do encaminhamento, foi alterado o percurso do tráfego para transitar agora através dos dois firewall em série. Ao longo de algumas semanas o sistema netfilter foi refinado usando os registos de eventos gerados e analisando a legitimidade da prevista decisão de no futuro rejeitar tal tráfego, os falsos positivos (tráfego indevidamente bloqueado) resultaram em muitos casos na adição de novas regras ou correcção das existentes. Dada a política geral de tráfego seguida, de negação por omissão, com a enumeração explícita do tráfego a ser aceite, não foi dada especial atenção aos eventuais falsos negativos (tráfego erroneamente aceite). VLAN5 VLAN6 Chassis Cat6500 VLAN1101 FCCN/Internet C7206 ALADDIN PC/PentiumD ITCHY FWSM Cat6500 HULK CORE/Redes IPL IPv6 C7206 GADGET Cat4500 STINGRAY Figura 4 - O sistema netfilter colocado em linha com o FWSM durante os testes 13

20 Quando se considerou o sistema suficientemente estável e fiável, os percursos de tráfego foram de novo alterados, agora colocando fora de circuito o FWSM. VLAN5 VLAN6 FCCN/Internet C7206 ALADDIN PC/PentiumD ITCHY Cat6500 HULK CORE/Redes IPL C7206 GADGET PC/PentiumD SCRATCHY Cat4500 STINGRAY Figura 5 - Estrutura final, após estabilizada a solução e removido o FWSM 3.2. Hardware e sistema Linux de base O sistema actual é baseado em dois PCs de ASUS RS120-E3/PA4, usando cada; um processador PentiumD a 3,4GHz, 2GB de RAM com correcção de dados ECC e dois discos rígidos, um de 250GB e outro de 500GB. A conectividade é assegurada por duas portas Ethernet a 1Gbit/s (incluídas no chassis) e duas portas ópticas de 10Gbit/s (10GBaseSR) numa placa extra. Estes componentes, à excepção da placa de 10GBaseSR estão em funcionamento desde que o sistema entrou ao serviço em 2008 e para maior fiabilidade e capacidade será actualizado até ao final do ano para novas máquinas de geração recente, entretanto adquiridas. Figura 6 - PC ASUS RS120-E3/PA Sistema operativo Por ser uma distribuição de Linux muito versátil e já com alguns anos de utilização nos sistemas da IPLNet, o Gentoo 4 foi o escolhido para base do sistema de firewall. O Gentoo tem uma instalação base mínima com os componentes essenciais do sistema podendo após a instalação inicial ser complementado com os pacotes de software considerados convenientes, recorrendo a um repositório de software bastante rico. Todo o software adicionado é compilado no momento da instalação, utilizando parâmetros genéricos ou que optimizem a execução no processador e restante arquitectura usados. Ao nível dos pacotes também estes recorrem a um conjunto de variáveis de sistema que permitem activar ou excluir o suporte de determinados subsistemas. No caso, e para a maioria dos servidores 4 Gentoo Linux: 14

21 que são geridos em linha de comandos via consola SSH (Secure Shell), exclui-se desde logo todo o suporte gráfico e de XWindows, permitindo que todas as aplicações instaladas que tenham vertente gráfica sejam mais leves e com binários de menor dimensão Optimizações do núcleo (kernel) Para maximização do desempenho, estabilidade e segurança do sistema foi dedicada alguma atenção à parametrização do núcleo do sistema. Em geral foram desactivados todos os módulos e facilidades que não representassem utilidade para o sistema. Foram analisados os componentes de hardware disponíveis nas máquinas, recorrendo à enumeração dos dispositivos presentes nos barramentos PCI/PCIe e USB (usando os comandos lsusb, lspci e dmidecode) e, em função dos resultados, activado o suporte somente para os dispositivos existentes e para uns quantos outros componentes genéricos disponíveis em stock e que se previam vir poder a ser necessários, como placas de rede de substituição, em caso de avaria. Foram activadas diversas facilidades identificadas como contribuintes para o desempenho do sistema, em particular ao nível das placas de rede usadas, elemento crítico neste sistema, tirando-se partido do co-processamento (offloading) disponível localmente. A própria escolha das placas a usar também já fora alvo de análise ponderada tendo em conta as capacidades de processamento e memória locais disponíveis em cada modelo Optimização de parâmetros de sistema Interrupts Num sistema desta natureza, as placas de rede serão sem dúvida a maior fonte de interrupts e o minimizar da latência no tratamento destas terá um impacto significativo no desempenho global do sistema. Ao nível do sistema operativo, foi ponderado o uso de um daemon de balanceamento do atendimento de interrupts pelos dois core de CPU disponíveis (irqbalance), alguns artigos [7, 8] recomendam o não uso destes como forma de evitar que os contextos de atendimento de interrupt tenham de ser sucessivamente carregados para a cache de cada processador. Tendo-se confirmado que a frequência da reanálise efectuada pelo irqbalance era de vários segundos, não ocorrendo frequentes alterações da afinidade interrupt/cpu, optou-se por manter esta funcionalidade activa por globalmente se considerar vantajosa para o sistema. Também nesta área, tendo em conta diversos artigos disponíveis à altura da preparação do sistema, foram desactivados os interrupts baseados em mensagens (MSI Message Signaled Interrupts), por serem indicados como a origem de latência acrescida, no entanto várias referências posteriores [9, 10] advogam o inverso, justificando-o com as latências envolvidas no atendimento das linhas IRQs tradicionais partilhadas terem de executar código nos drivers de cada um dos dispositivos envolvidos. Dada a limitação do número de linhas de interrupt (quatro) disponíveis a cada dispositivo ligado aos slot PCI o que obriga à partilha. Com a abundância de interrupts distintos disponíveis em modo MSI (ou a sua evolução MSI-X), torna-se viável o fim da partilha de interrupts entre dispositivos e a existência de múltiplas filas de espera do lado das placas com interrupts MSI distintos e consequentemente tarefas individualmente mais simples resultando globalmente em melhores desempenhos. Memória Foram aplicadas diversas parametrizações para incremento da memória possível ou disponível para memórias temporárias usadas nas transferências de dados e outras estruturas de dados relevantes do núcleo. Foram seguidas especialmente as recomendações da ESnet [11] e IBM [12], há no 15

22 entanto que mencionar que vários destes refinamentos não terão particular efeito neste sistema já que se aplicam aos extremos de comunicações TCP/UDP, algo que tem pouco significado num sistema vocacionado para o encaminhamento de pacotes. Gestão de energia Sendo um sistema com uma variação significativa da carga ao longo do tempo, é de todo importante uma consciente gestão da energia consumida, minimizando consumos desnecessários que têm um impacto negativo em diversas vertentes, em particular as económicas e de climatização do centro de dados. Nas últimas gerações do Linux foram incluídas muitas funcionalidades para lidar com este aspecto, destacando-se a Intel como contribuidor nesta área, em particular promovendo o uso das facilidades do hardware que fabrica para uma utilização mais racional da energia. Baseado nas orientações de diversos artigos [13], foram alteradas parametrizações que contribuem nesta área, a análise de recomendações tiveram em grande parte origem na ferramenta PowerTOP. Ao nível do núcleo é necessário activar diversas facilidades de monitorização e controlo para que as aplicações e ferramentas de análise possam aferir os aspectos do sistema que mais poderão contribuir para a melhoria do desempenho energético. Os discos rígidos são relativamente pouco utilizados num sistema desta natureza, a colocação do barramento destes (SATA), sempre que possível, num estado de baixa energia é sem dúvida uma vantagem. A escrita em disco persistente dos dados em cache também não necessita ter a frequência por omissão, sendo esta reduzida. O factor sem dúvida com maior peso nesta área é a gestão da CPU em si, podendo este correr a um relógio reduzido quando não forem necessários todos os ciclos disponíveis à máxima velocidade. Foi para tal instalado o pacote de ferramentas CPUFreqUtils que tratará de parametrizar e carregar no núcleo o gestor de relógio de CPU que neste caso se seleccionou ser o ondemand por ter uma reacção mais rápida a picos de necessidade de processamento. No caso particular do hardware usado, a CPU poderá ao longo do tempo usar os relógios de 2,4GHz, 2,81GHz e 3,4GHz; confirmando-se nas ferramentas de monitorização que grande parte do tempo (>80%) é passado na mais baixa frequência disponível Armazenamento de sistema e dados Para suporte ao armazenamento persistente do sistema foram usados dois discos como solução de compromisso entre a capacidade de armazenamento, a fiabilidade e os componentes disponíveis. Os primeiros 250GB do disco de 500GB encontram-se organizados da mesma forma que o disco de 250GB, contendo ambos uma partição de arranque (boot) de 128MiB, uma partição de memória virtual (swap) de 512MiB, uma partição de sistema de 15GiB e uma partição de dados com o espaço restante, 220GiB. As partições de arranque, de sistema e de dados encontram-se replicadas entre ambos os discos com recurso a RAID1 (mirror) usando o suporte do sistema Linux para tal, realizado ao nível do núcleo (software RAID) [14, 15]. As partições de memória virtual de ambos os discos, sendo um recurso com necessidade de elevado débito e de conteúdo volátil, são adicionadas separadamente e utilizadas directamente pelo sistema de gestão de memória virtual disponibilizando a este cerca de 1GiB. O espaço restante de cerca de 234GiB do disco maior é utilizado directamente para armazenamento de dados não críticos como estudos e capturas de tráfego executadas para análise de problemas de conectividade ou optimizações. 16

23 Todos os dados com necessidade de tolerância à falha de disco como o registo de eventos de sistema, são guardados ou na partição de sistema ou na de dados que estão sobre RAID1. Cada uma das máquinas manterá o funcionamento caso um dos discos falhe. À altura da instalação inicial foram realizados testes com sucesso, simulando esta situação. Partições HDD 250GB boot swap system data HDD 500GB boot swap system data single Capacidade 128MiB (RAID1) 512MiB 15GiB (RAID1) 220GiB (RAID1) 234GiB Formato EXT2 SWAP EXT3 EXT4 EXT4 Figura 7 - Estrutura de partições nos discos rígidos Sistemas de ficheiros Os tipos de sistema de ficheiros utilizados são o EXT2, EXT3 e EXT4. Na partição de arranque o EXT2, já que não tem requisitos de tolerância a falha abruptas, por após arranque ficar desactivada. O sistema encontra-se com EXT3 por à altura da instalação inicial o EXT4 ainda não se encontrar suficientemente estável e suportado pela distribuição de Linux usada (Gentoo). Entretanto, nunca houve pressão de maior para ser actualizada, sê-lo-á quando o sistema for reinstalado de raiz. As partições de dados com e sem RAID, por poderem ser facilmente alteradas com o sistema em produção foram entretanto actualizadas para EXT4, para usufruírem das vantagens deste Conectividade De forma a minimizar os pontos de falha de rede em cada uma das duas máquinas envolvidas e facilitar a sua manutenção, nos equipamentos de rede que as rodeiam foram usadas diversas técnicas para garantir a continuidade operacional do sistema como um todo, mesmo que em alguns dos casos a capacidade fique degradada. Cada máquina possui 4 portas de rede, duas a 1Gbit/s e duas a 10Gbit/s (originalmente estas duas extra eram também a 1GBit/s). Ao nível do núcleo do sistema foi utilizado um módulo designado de bonding que permite a implementação de diversas soluções de elevada disponibilidade e escalabilidade. São suportados modos relativamente complexos envolvendo a distribuição de tráfego baseada em parâmetros de nível 2, 3 ou 4 e a negociação multilink LAPC/IEEE802.3ac (actualmente IEEE802.3ax), mas também soluções mais simples, como o modo Active-Backup usado [16]. No modo Active-Backup, as portas são associadas à interface virtual que as representará no sistema (bondx) e de entre estas identificada uma como a activa por omissão. Enquanto a ligação principal estiver com conectividade nível 2 (link), esta é usada, se falhar, usa-se uma das ligações alternativas. Existem imensas variantes da utilização deste módulo, incluindo a validação da conectividade IP com pedidos de ARP (Address Resolution Protocol), no entanto, considerou-se que tal não acrescia vantagem significativa e complicava a solução. Alguns dos restantes modos de bonding não são sequer opção por serem incompatíveis com a ligação a switch distintos. No caso, a ligação do lado da Internet é formada pelas portas eth1 (1Gbit/s) como BACKUP e eth3 (10Gbit/s) como ACTIVE resultando na interface nível 3 de sistema designada de bond1 e a ligação interna pelas portas eth0 (1Gbit/s) como BACKUP e eth2 (10Gbit/s) como ACTIVE sendo estas virtualizadas ao sistema como bond0 17

24 Todas as portas de rede de cada máquina do sistema encontram-se ligadas a switch distintos, sendo portanto tolerantes à falha de qualquer um destes. As portas BACKUP de uma das máquinas ligam no entanto aos mesmos switch que as portas ACTIVE da mesma zona da outra máquina do sistema. Encaminhamento de tráfego IPv4/IPv6 Switch 1K11 GALACTUS Switch HULK Gi0/6 Te0/9 eth3 eth2 Te1/5 Gi3/25 eth1 eth0 Ainda sem ligação Porta de 10Gbit/s indisponivel Gi0/13 eth3 eth1 ITCHY SCRATCHY eth0 eth2 Gi1/0/13 Te1/1 Switch 1I1 Switch 1K10 OUTSIDE Switch TERRI INSIDE Figura 8 - Interligação redundante do sistema aos switch O encaminhamento através das duas máquinas que constituem o sistema também teve em conta os aspectos de elevada disponibilidade e escalabilidade pretendidos. Foram cuidadosamente ajustadas as métricas do protocolo de encaminhamento por forma a garantir um percurso estável e bidireccionalmente simétrico do tráfego, algo essencial num sistema que realiza a inspecção de protocolos a vários níveis e que mantém e valida os estados das comunicações em curso (statefull packet inspection SPI). A forma mais simples de distribuir o tráfego pelas duas máquinas foi entregar, por omissão as funções associadas ao tráfego IPv4 a uma e IPv6 a outra. Em caso de falha uma das máquinas está apta e automaticamente assumirá a função da outra. 18

25 Para coordenação completa do sistema com os routers em volta foi utilizado o pacote de software (Quagga) [17] que implementa diversos protocolos de encaminhamento. Actualmente são usados o OSPFv2 (IPv4) e OSPFv3 (IPv6). O Quagga comporta-se como uma aplicação residente ao nível utilizador (daemon), comunica com os routers em sua volta e trata de manter a tabela de encaminhamento do núcleo com as melhores rotas disponíveis segundo o critério de cost (maior largura de banda é preferida). Custos OSPFv2 IPv4/OSPFv3 IPv FCCN/Internet C7206 ALADDIN PC/PentiumD ITCHY Cat6500 HULK CORE/Redes IPL C7206 GADGET PC/PentiumD SCRATCHY Cat4500 STINGRAY Figura 9 - Percursos de tráfego IPv4 e IPv Tratamento dos eventos de sistema Todos os eventos de sistema que são reportados através de SYSLOG 5 são processados pelo syslog-ng de sistema, este encontra-se configurado para separar os eventos por ficheiros de acordo com a facility. Em simultâneo, os eventos são enviados usando o modo fiável do protocolo (sobre TCP) para dois servidores remotos, geograficamente separados, servidores que realizam o arquivo de médio prazo dos registos e onde é possível a análise histórica das ocorrências. Os eventos gerados pelo núcleo, incluindo os do netfilter são associados à facility kern pelo que os registos, neste caso, irão ficar arquivados no ficheiro com o mesmo nome. Ficheiros e directorias envolvidos /etc/syslog-ng/syslog-ng.conf Configuração do syslog-ng /var/log/syslog/ - Arquivo local de eventos por ficheiros com o nome de cada facility 3.7. Gestão do netfilter no sistema Para garantir a maior disponibilidade possível do serviço foi desenvolvido um script em linguagem BASH. Este script executa de forma sequencial a actualização das diferentes tabelas. A actualização de cada tabela só é realizada se ocorreram alterações no ficheiro respectivo após a última actualização da mesma. Durante a actualização de cada tabela, para se conseguir que o processo decorra sem a interrupção do serviço, os nomes de todas as chain (excepto as nativas) são previamente alterados para um nome temporário, criadas as novas chain, culminando o processo com a mudança das chain base, que passam a apontar para as novas chain. 5 RFC

26 Finalmente, são removidas as chain temporárias da versão anterior. Caso se julgue necessário, existe disponível uma opção do script de actualização que força a actualização de todas as tabelas. O conjunto de ficheiros de regras e scripts encontram-se nas directorias de sistema /etc/fw4 os referentes a IPv4 e /etc/fw6 os de IPv6. Actualização de tabelas Para actualização das tabelas activas é executado o script IN4Fw.sh ou IN6Fw.sh dependendo do protocolo de rede para o qual se pretende a actualização. O script aceita um parâmetro que pode tomar os valores: start Iniciar ou actualizar as tabelas de forma automática, esta opção é a usada quando não se coloca parâmetro nenhum. stop Para repor o estado por omissão das tabelas, sem qualquer filtragem ou manipulação aplicada. fstart Para iniciar ou actualizar as tabelas mas forçando a execução da actualização de todas as tabelas independentemente dos ficheiros respectivos terem ou não sido actualizados desde a última execução. Os INxFw.sh tratam de realizar a definição das variáveis usadas nos scripts BASH, redimensionam as estruturas de dados de suporte ao conntrack, realizam o carregamento para o núcleo de todos os módulos de validação e manipulação que se encontrem disponíveis, de seguida, executam os scripts auxiliares de forma sequencial, ordenada pelo nome destes. Cada script auxiliar começa por carregar as funções de apoio ao controlo de versões, define localmente as funções que realizam a sequência de actualização das chains (quando usada), das funções que tratam do descarte e registo moderado de eventos, do carregamento das chains, da reposição do estado por omissão e do apontar das chain base de cada ponto de intercepção para a chain inicial de cada ramo. Na execução de inicialização (start) de cada um destes scripts auxiliares é primeiro verificada a necessidade de actualização, comparando as datas de modificação do próprio com a de um ficheiro auxiliar de referência, se é inferior, nada à fazer; senão, é chamada a função que trata do renomear de todas as chain para um nome temporário, chamadas as funções que criam e preenchem as novas chain e após, a que trata do apontar dos pontos de intercepção para as novas chain. Por último, as chain temporárias (antigas) são apagadas e actualizado o ficheiro de referência para actualizações. Actualização de regras Para validação prévia da sintaxe, como em situação normal de funcionamento o tráfego IPv4 é responsabilidade do servidor Itchy e o IPv6 do Scratchy, as alterações de regras devem ocorrer no servidor que está de reserva para o protocolo em questão, só após a aplicação do script com sucesso se realiza a replicação das alterações para os ficheiros do servidor principal e posterior execução do script. No procedimento de replicação de alterações é realizado também um arquivo do estado anterior de todos os ficheiros associados para que, caso seja detectada alguma consequência imprevista das alterações realizadas, se possa repor o estado anterior. O arquivo de versões permite ainda a análise da origem de problemas que só sejam detectados após algum tempo. 20

27 Ficheiros de suporte Em /etc/fw4 10-IN4FwIPSET.sh Mantém os IPSET utilizados. 20-IN4FwFilter.sh Mantém as regras da tabela filter. 40-IN4FwMangle.sh Mantém as regras da tabela mangle. 60-IN4FwNAT.sh Mantém as regras da tabela nat. 80-IN4FwRAW.sh Mantém as regras da tabela raw. 99-IN4FwPersist.sh Guarda as regras de forma persistente no script base do firewall de sistema para que este seja no essencial reposto na reiniciação do servidor. IN4Fw.sh Script base utilizado para a actualização das tabelas. allsets.ipset Repositório persistente dos grupos de endereços e portos que formam os IPSET. startstopupdate.fn Funções auxiliares do script usadas para controlo de que tabelas necessitam actualização. synccfg.sh Script que realiza o arquivo de versões e a actualização local (via protocolo RSYNC 6 ) dos ficheiros existentes no outro servidor. old/ - Pasta contendo o arquivo de versões Em /etc/fw6 20-IN6FwFilter.sh Mantém as regras da tabela filter. 40-IN6FwMangle.sh Mantém as regras da tabela mangle. 80-IN6FwRAW.sh Mantém as regras da tabela raw. 99-IN6FwPersist.sh Guarda as regras de forma persistente no script base do firewall de sistema para que este seja no essencial reposto na reiniciação do servidor. IN6Fw.sh Script base utilizado para a actualização das tabelas. startstopupdate.fn Funções auxiliares do script usadas para controlo de que tabelas necessitam actualização. synccfg.sh Script que realiza o arquivo de versões e a actualização local (via protocolo RSYNC) dos ficheiros existentes no outro servidor. old/ - Pasta contendo o arquivo de versões 6 RSYNC: 21

28 3.8. Endereçamento e uso de NAT Apesar do IPL possuir actualmente um número considerável de endereços IP públicos (6656 IPv4), existem, ainda assim, diversos motivos para a manutenção de endereçamento privado e consequentemente, para a realização de NAT na periferia. Existindo publicadas nas tabelas de encaminhamento internas 234 redes (mais existirão já que estas rotas já sofreram sumarização em alguns casos), baseando-nos nestes números daria um rácio de cerca de 28 endereços por rede o que é claramente insuficiente na maioria das redes. A utilização de um bloco de endereçamento de elevadas dimensões, só possível actualmente com endereçamento privado, permite uma melhor estruturação, facilitando todas as tarefas que envolvam o tratamento diferenciado por rede, permitindo ao nível de aplicações e sistema de packet filtering criar listas de acesso mais genéricas e que dispensam manutenção frequente. Torna-se possível a criação de perfis de rede e o agrupar destes, bastando uma simples comparação para saber se determinado endereço pertence a uma rede administrativa, de gestão de rede ou simplesmente académica. Assim, actualmente a política de distribuição de endereços rege-se pelas seguintes regras base: As redes centrais de servidores (core), trânsito e todas as redes de utilizador que mantenham registo detalhado da relação utilizador/endereço (wireless, VPNs); usam endereços públicos. As redes restantes usam endereçamento privado da gama /8 (RFC1918) Todo o endereçamento tem um perfil atribuído e na atribuição de novo endereçamento ele é alocado no bloco adequado à função a desempenhar. As redes que utilizem endereçamento privado obtêm conectividade Internet com recurso a NAT realizado no sistema de firewall, no entanto, existem regras que condicionam a permissão do uso de NAT e a forma de funcionamento deste, por forma a minimizar o caos de comunicações consideradas inúteis para a instituição e o consequente abuso dos recursos de rede disponíveis. Planos de endereçamento Um sistema desta complexidade gerido a um nível tão baixo (sem uma interface gráfica) assusta à partida, por se assumir a necessidade de alterações frequentes. Um aspecto em particular contribui para que tal não ocorra, a utilização de um plano de endereçamento orientado à função e estruturado com uma perspectiva de longo prazo. Os grandes blocos de endereço são afectos às funções seguintes: Servidores centrais Routers e comutadores nível 3 Servidores Web alojados Redes sem filtragem Redes de clientes (que não usam NAT) Redes usadas pelos sistemas VPN Redes internas 22

29 Tipo Bloco base Sub-Blocos Função /25 Servidores centrais do polo do ISEL /27 NAT /27 Servidores centrais do polo de Benfica / /27 Conectividade especial (ex. Videoconferencia) /27 Loopbacks dos routers (RID) /24 Ligações entre routers ponto a ponto e troços de transito /24 Redes exteriores ao perimetro de segurança (firewall), ligações entre border routers, firewall e routers de suporte aos roamers e-u Redes de servidores com conectividade exterior (essencialmente /24 PA servidores web das escolas e serviços) /24 Roamers e-u - Polo ISEL /24 Roamers e-u - Polo Benfica /25 Roamers e-u - Polo ISCAL /25 Roamers e-u - Polo ESTeSL / /26 Roamers e-u - Polo ESTC /26 Roamers e-u - Polo ESM /26 Roamers e-u - Polo ESD /27 Roamers e-u - Polo RDC /27 Tuneis GRE de encaminhamento e-u roamers /25 Servidores centrais /28 NAT Outbound / /27 NAT Inbound PI /28 NAT Inbound /28 Concentradores VPN /30 Testes de conectividade / /28 NAT Outbound /28 Concentradores VPN Desta forma, durante a preparação do firewall é aplicada uma parametrização genérica às comunicações de cada um dos grandes blocos, contemplando os protocolos essenciais para a função das máquinas que lá sejam colocadas. Só em situações muito específicas que o justifiquem, são aplicadas excepções a determinadas máquinas dentro de cada bloco, normalmente acrescentandolhe o suporte de alguma comunicação adicional que necessitem. O crescimento da rede em máquinas internas de clientes, servidores ou outros não implica um trabalho proporcional de gestão do firewall, esta fica limitada às tarefas correntes e à adição do suporte de novos protocolos e excepções Estrutura base das chain utilizadas Figura 10 - Exemplo de plano de endereçamento IPv4 As funcionalidades actualmente utilizadas nas tabelas de mangle e raw são reduzidas, encontramse essencialmente preparadas para alguma necessidade futura. Não são realizadas nenhumas manipulações de mangle, ao nível raw são aplicadas regras que excluem algum tráfego de ser mantido estado conntrack por se considerar que este não teria qualquer utilidade e iria consumir recursos; exemplo deste caso é o tráfego destinado a endereços multicast (bloco /4). $IPT 7 -t raw -A PREROUTING -d /4 -j CT notrack Nas tabelas filter e nat, as chain base FORWARD, INPUT e OUTPUT contém apenas uma regra que incondicionalmente passa a avaliação para uma chain base_forw, base_in ou base_out respectivamente. Tal justifica-se para dar suporte ao redireccionamento atómico da chain raiz de cada ponto de intercepção, durante os processos de actualização de regras. É nas chain de prefixo base_ que são desde logo tratados os casos gerais para a maioria do tráfego como a rejeição de tráfego considerado INVALID pelo conntrack e o aceitar do tráfego de comunicações previamente aceites. 7 $IPT é uma macro definida em INxFw.sh e que contém o caminho completo para o executável iptables. 23

30 Para apoio às chains de filtragem foi ainda desenvolvida uma função BASH (custom_logdrop_chain_fn) que é usada na maioria das chain para centralizar diversas tarefas comuns relacionadas com o tratamento de tráfego indesejado. Esta função tem como parâmetros o nome da chain onde se pretende aplicar, um conjunto de avaliações a realizar para que suceda e um curto texto de comentário. Durante o script de criação das chains a sua execução produz uma regra na chain com a avaliação indicada e que fará um salto para uma nova chain caso suceda. A nova chain é completamente produzida pela função e trata do processo de adição do endereço origem da anomalia à scanlist (do módulo de avaliação recent), do registo do evento no sistema e do descarte. O registo do evento no sistema é contudo, sujeito a uma limitação de ritmo que impede a geração de eventos consecutivos idênticos, tal é conseguido recorrendo ao módulo hashlimit limitando a chave IP origem/ip destino a um evento por segundo com um limite de rajada de 5. Em caso de registo de evento, o comentário passado à função é adicionado bem como o nome da chain e tal permitirá posteriormente a análise facilitada da origem do evento. As regras geradas por esta função são também apoiadas pela chain dropids que decide a inclusão ou não na scanlist, importante para evitar que alguns servidores críticos internos sejam temporariamente bloqueados. Nesta chain também é possível a geração de registo em formato PCAP, caso se pretenda a análise detalhada dos pacotes rejeitados. Para esta funcionalidade é usado o módulo de extensão ULOG e há a necessidade da execução de uma aplicação userspace 8 que recebe os pacotes do núcleo exportados pelo ULOG e os regista em ficheiro persistente. #$IPT -A pcaplog -m hashlimit --hashlimit 1/s --hashlimit-burst 5 \ # --hashlimit-mode dstip,srcip --hashlimit-name pcaplog \ # -j ULOG $ULOGOPT $IPT -A pcaplog -j RETURN $IPT -A dropids -s $NETPA1 -j DROP $IPT -A dropids -s $NETPI1 -j DROP $IPT -A dropids -s $NETADM -j DROP $IPT -A dropids -s $NETEU1 -d $NETPRV1 -j DROP # Leaking do NET100 $IPT -A dropids -p udp -d /31 -j DROP # Com o DNS memorizado mas fora $IPT -A dropids -p udp -d j DROP # Com o DNS memorizado mas fora $IPT -A dropids -j pcaplog $IPT -A dropids -p udp -d sport 1024: --dport 123 -j DROP #$IPT -A dropids -m conntrack! --ctstate NEW,UNREPLIED,INVALID -j DROP $IPT -A dropids -m conntrack --ctstate NEW \ -m recent --set --rsource --name scanlist -j DROP $IPT -A dropids -j DROP # $1 = calling chain, $2 = rulematch, $3 = comment custom_logdrop_chain_fn() { LDCHAIN=$(($LDCHAIN+1)) $IPT -N ld_$ldchain #$IPT -A ld_$ldchain -m limit --limit 5/s -j LOG $LOGOPT --log-prefix "$1 {$3}: " $IPT -A ld_$ldchain -m hashlimit --hashlimit 1/s --hashlimit-burst 5 \ --hashlimit-mode dstip,srcip --hashlimit-name logdrop \ -j LOG $LOGOPT --log-prefix "$1 {$3}: " $IPT -A ld_$ldchain -j dropids $IPT -A $1 $2 -j ld_$ldchain } Variáveis BASH definidas em IN4Fw.sh para utilização nos scripts Para além das variáveis com o caminho completo para a maioria dos executáveis usados, são definidas as variáveis BASH seguintes, algumas de forma dinâmica. NETPA1=" /23" NETPA2=" /24" NETPA3=" /24" NETPA4=" /20" NETEU1=" /22" NETPI1=" /24" NETPI2=" /24" NETPRV1=" /8" NETPA1a=" /24" NETPA1b=" /24" NETPREFW=" /25" NETADM=" /23" NETCOREPRIV=" /24" 8 ULOGD: 24

31 NETVPNBON=" /27" # NAT IPNATOVLPI=" " IPNATOVLPA=" " IPNATOVL=" " # PASVRANGE="59900:60000" RPCPORTSU=`/sbin/rpcinfo -p ${GREP} -E '\budp\b' \ /bin/awk '{print($4);}' \ ${GREP} '^[0-9]\+$' ${SORT} -n ${UNIQ} \ /bin/awk 'BEGIN {CNT=0;}\ {if(cnt) printf(",%s",$1); else printf("%s",$1); ++CNT;}'` RPCPORTSU=`/sbin/rpcinfo -p ${GREP} -E '\budp\b' \ /bin/awk '{print($4);}' \ ${GREP} '^[0-9]\+$' ${SORT} -n ${UNIQ} \ /bin/awk 'BEGIN {CNT=0;}\ {if(cnt) printf(",%s",$1); else printf("%s",$1); ++CNT;}'` RPCPORTST=`/sbin/rpcinfo -p ${GREP} -E '\btcp\b' \ /bin/awk '{print($4);}' \ ${GREP} '^[0-9]\+$' ${SORT} -n ${UNIQ} \ /bin/awk 'BEGIN {CNT=0;}\ {if(cnt) printf(",%s",$1); else printf("%s",$1); ++CNT;}'` EPRANGE=`/sbin/sysctl -n net.ipv4.ip_local_port_range /bin/sed 's/ /:/'` HOSTIPS=`${IP} -f inet addr ${GREP} -F 'inet ' ${GREP} -v -F 'inet 127.' \ sed 's/.*inet \([^\/]\+\)\/.*/\1/' ${SORT} -n` HOST=`/bin/uname -n $CUT -d '.' -f 1` LOGOPT="--log-tcp-options --log-ip-options --log-tcp-sequence" ULOGOPT="--ulog-nlgroup 1 --ulog-cprange 128" IFINT="bond0" IFEXT="bond1" Chains de filtragem em IPv4 para INPUT e OUTPUT O tráfego que chegue à máquina (firewall) e cujo endereço destino seja local ou em que ao nível NAT tenha sido redireccionado para atendimento local é avaliado na chain INPUT. Incondicionalmente o processamento é transferido para a base_in que trata de descartar o tráfego considerado INVALID e de aceitar todo o tráfego de comunicações em curso, seja este considerado ESTABLISHED ou RELATED pelo conntrack. Com esta acção a quase totalidade do tráfego fica tratado neste ponto. O tráfego que mesmo sendo NEW tenha origem na interface loopback é também aceite sem reservas. De seguida, recorrendo ao módulo de avaliação recent, é verificado se o endereço origem do tráfego se encontra na lista negra (scanlist) que enumera máquinas que geraram anomalias. Nesta lista estarão máquinas que tentaram comunicar com recursos inexistentes, indiciando pesquisas de portos e/ou máquinas para a descoberta de buracos por onde entrar. Se nos últimos 30 segundos a origem em questão gerou mais de 15 eventos do género, a ocorrência é enviada para o registo de sistema e o tráfego é descartado, evocando-se a chain ldidsin. $IPT -A base_in -m conntrack --ctstate INVALID -j DROP $IPT -A base_in -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT $IPT -A base_in -i lo -m conntrack --ctstate NEW -j ACCEPT $IPT -A base_in -m recent --update --hitcount 15 --seconds 30 --name scanlist -j ldidsin Caso o tráfego pertença aos protocolos OSPF ou ICMP, o tratamento é passado as chains específicas para cada um destes, ospfin e icmpin respectivamente. $IPT -A base_in -p ospf -j ospfin $IPT -A base_in -p icmp -j icmpin De seguida são aceites comunicações que tenham origem nas redes centrais de gestão e que tenham como destino um conjunto de portos dinâmicos associados aos serviços de NFS/RPC que são usados no suporte aos backups gerais de sistema. O facto dos portos TCP e UDP utilizados nestes serviços serem em grande parte dinâmicos obriga a que o seu valor seja obtido no momento da execução do script, sendo colocados em variáveis BASH que aqui são utilizadas no módulo de avaliação multiport. $IPT -A base_in -p tcp -s $NETPREFW -m multiport \ --destination-ports $RPCPORTST -j ACCEPT 25

32 $IPT -A base_in -p tcp -s $NETPA1 -m multiport \ --destination-ports $RPCPORTST -j ACCEPT $IPT -A base_in -p tcp -s $NETCOREPRIV -m multiport \ --destination-ports $RPCPORTST -j ACCEPT $IPT -A base_in -p udp -s $NETPREFW -m multiport \ --destination-ports $RPCPORTSU -j ACCEPT $IPT -A base_in -p udp -s $NETPA1 -m multiport \ --destination-ports $RPCPORTSU -j ACCEPT $IPT -A base_in -p udp -s $NETCOREPRIV -m multiport \ --destination-ports $RPCPORTSU -j ACCEPT As comunicações que cheguem a este ponto, que pertençam ao protocolo TCP, tenham a flag SYN activa e o porto origem da gama dos privilegiados (<1024), são rejeitados recorrendo à função custom_logdrop_chain_fn. custom_logdrop_chain_fn base_in "-p tcp --sport : syn" "SYN from lowport" A chain base_in fica concluída com três regras que permitem o acesso aos portos TCP 22 (SSH), 2001 (OVERCR 9 ) e 873 (RSYNC) a partir de um conjunto de redes enumeradas na chain mgmtnets para onde é passado o processamento neste caso. $IPT -A base_in -p tcp --dport 22 --syn -j mgmtnets $IPT -A base_in -p tcp --dport syn -j mgmtnets $IPT -A base_in -p tcp --dport syn -j mgmtnets É também aceite sem condições adicionais as ligações ao porto 5001 que é usado esporadicamente em testes de desempenho usando a aplicação IPERF 10. $IPT -A base_in -p tcp --dport syn -j ACCEPT # IPERF Todo o tráfego que tenha chegado à cauda da chain, não tendo sido de alguma forma atendido, é descartado, novamente recorrendo à função custom_logdrop_chain_fn. custom_logdrop_chain_fn base_in "" "END" A chain ospfin aceita tráfego com origem num conjunto de redes de confiança, mas somente se o endereço destino multicast é um dos bem conhecidos associados ao protocolo ou é um endereço associado localmente ao protocolo OSPF. $IPT -A ospfin -s $NETPREFW -d j ACCEPT $IPT -A ospfin -s $NETPA1b -d j ACCEPT $IPT -A ospfin -s $NETPREFW -d j ACCEPT $IPT -A ospfin -s $NETPA1b -d j ACCEPT $IPT -A ospfin -s $NETPA1 -d $NETPA1b -j ACCEPT $IPT -A ospfin -s $NETPA1 -d $NETPREFW -j ACCEPT $IPT -A ospfin -s $NETPREFW -d $NETPA1b -j ACCEPT $IPT -A ospfin -s $NETPREFW -d $NETPREFW -j ACCEPT A icmpin remete para a mgmtnets, para avaliação se a fonte é uma das aceites sem limites, senão aceita no máximo uma mensagem por segundo para as que requerem fragmentação, acrescido de uma mensagem por segundo para o ICMP restante. $IPT -A icmpin -p icmp -j mgmtnets $IPT -A icmpin -p icmp --icmp-type fragmentation-needed -m limit --limit 1/s -j ACCEPT $IPT -A icmpin -m limit --limit 1/s -j ACCEPT custom_logdrop_chain_fn icmpin "" "ICMP flood" $IPT -A mgmtnets -s $NETPA1 -j ACCEPT $IPT -A mgmtnets -s $NETPI1 -j ACCEPT $IPT -A mgmtnets -s $NETADM -j ACCEPT $IPT -A mgmtnets -s $NETPREFW -j ACCEPT $IPT -A mgmtnets -j RETURN 9 Usado pela monitorização NAGIOS: 10 iperf em: 26

33 O tráfego gerado localmente é avaliado na chain OUTPUT que também remete de imediato para a base_out, novamente para que seja possível a alteração de chains sem interrupção do serviço. $IPT -A OUTPUT -j base_out A chain base_out é das mais simples usadas, aceitando todos os envios via interface de loopback, alertando com evento de sistema para situações menos comuns do estabelecimento de ligações TCP que tenham origem num porto privilegiado. Remete para a chain icmpout a decisão de todo o tráfego ICMP e aceita o tráfego OSPF e restante. $IPT -A base_out -o lo -j ACCEPT $IPT -A base_out -p tcp! --sport $EPRANGE --syn -j LOG --log-prefix "EPRange violation! TCP: " $IPT -A base_out -p icmp -j icmpout $IPT -A base_out -p ospf -j ACCEPT $IPT -A base_out -j ACCEPT A icmpout irá restringir o ritmo do ICMP excepto para mensagens ECHO, TIMESTAMP e TIME- EXCEEDED, isto para minimizar o risco de induzir em erro as aplicações de análise básica de rede como o ping e traceroute. Todas as restantes mensagens ICMP serão limitadas a 5 por segundo e as que excedam este limite rejeitadas com o apoio da custom_logdrop_chain_fn. $IPT -A icmpout -p icmp --icmp-type echo-request -j ACCEPT $IPT -A icmpout -p icmp --icmp-type echo-reply -j ACCEPT $IPT -A icmpout -p icmp --icmp-type timestamp-reply -j ACCEPT $IPT -A icmpout -p icmp --icmp-type time-exceeded -j ACCEPT $IPT -A icmpout -m limit --limit 5/s -j ACCEPT custom_logdrop_chain_fn icmpout "" "ICMP flood" A Figura representa de forma resumida a estrutura das chain acima mencionadas Figura 11 - Chains de INPUT e OUTPUT da tabela filter de IPv Chains de filtragem em IPv4 para FORWARD A filtragem de FORWARD é sem dúvida, a mais complexa por envolver tratar de todas as situações previstas para os diferentes grupos de máquinas internas e externas. É aplicada a solução já explicada para a substituição rápida de chains, recorrendo à base_forw $IPT -A FORWARD -j base_forw Comunicações destinadas às redes públicas internas que sejam consideradas INVALID são descartadas, as consideradas RELATED, ESTABLISHED ou DNAT são aceites. O estado DNAT que não tinha anteriormente sido mencionado refere-se a tráfego que em fase PREROUTING tenha sido sujeito a NAT que envolva alterações de parâmetros de destino. Neste caso para evitar a duplicação de regras, assume-se que se a regra de NAT o processou, é implicitamente aceite neste ponto. 11 Imagem gerada a partir da ferramenta iptables2dot [29], tal como as restantes representando as árvores de decisão netfilter 27

34 $IPT -A base_forw -i $IFEXT! -d $NETPRV1 -m conntrack --ctstate INVALID -j DROP $IPT -A base_forw -m conntrack --ctstate RELATED,ESTABLISHED,DNAT -j ACCEPT Origens que tenham anteriormente despoletado eventos de descarte, se ocorreram mais de 5 referências nos últimos 30 segundos, voltam a ser descartadas realimentando a lista negra associada e gerando registos do evento. $IPT -A base_forw -i $IFEXT -m recent --update --hitcount 5 --seconds 30 --name scanlist -j ldbids A situação do uso de porto 0 não é contemplada nas API de sockets, significando tipicamente nestas o aceitar de qualquer porto ou o pedido ao sistema operativo de um porto disponível na gama Ephemeral Port Range, sendo assim uma situação anormal de comunicações em trânsito, é rejeitada. custom_logdrop_chain_fn base_forw "-p udp --sport 0" "SPort=0" As comunicações de TCP são remetidas para análise específica do protocolo na chain basic_tcp. O tráfego considerado NEW é tratado separadamente dependendo do sentido em que viaje, o restante tráfego é descartado nos moldes habituais. $IPT -A base_forw -p tcp -j basic_tcp $IPT -A base_forw -i $IFEXT -m conntrack --ctstate NEW -j inbound $IPT -A base_forw -o $IFEXT -m conntrack --ctstate NEW -j outbound custom_logdrop_chain_fn base_forw "" "END" A análise detalhada realizada em basic_tcp tenta identificar anomalias do protocolo como, à semelhança do realizado em UDP, do uso do porto 0. São detectadas combinações inválidas de flags, da comunicação ocorrer entre portos privilegiados, de chegar a esta fase como uma comunicação nova mas sem a flag SYN activa ou, finalmente, do uso de portos privilegiados como a origem de ligações, a não ser para redes que o justifiquem. Esta última situação ocorre frequentemente nos protocolos associados ao NFS e no FTP quando em modo activo. Esta chain (basic_tcp) nunca aceita tráfego, apenas rejeita ou devolve a avaliação à chain anterior para análise específica de portos e endereços. custom_logdrop_chain_fn basic_tcp "-p tcp --sport 0" "SPort=0" $IPT -A basic_tcp -p tcp -j tcpbadflags custom_logdrop_chain_fn basic_tcp "-p tcp --sport : dport :1023" "BOTH Low Ports" custom_logdrop_chain_fn basic_tcp "-i $IFEXT -p tcp! --syn" "Not SYN" $IPT -A basic_tcp -p tcp -s $NETCOREPRIV --sport :1023 -j RETURN # NFS Backups $IPT -A basic_tcp -p tcp -s $NETPA1 --sport :1023 -j RETURN # NFS Backups custom_logdrop_chain_fn basic_tcp "-p tcp --syn --sport :1023" "SYN SPort<1024" $IPT -A basic_tcp -j RETURN As chain inbound e outbound aceitam desde logo o tráfego envolvendo o bloco de endereços usado nas interfaces loopback 12 dos routers e a rede existente entre o firewall e os routers que ligam à Internet, a sua principal missão será distribuírem a avaliação das novas comunicações por chains especificas baseando-se no critério da rede interna envolvida. $IPT -A inbound -s $NETPA1 -j ACCEPT $IPT -A inbound -s $NETPREFW -j ACCEPT # Tratamento diferenciado por bloco $IPT -A inbound -d $NETPI1 -j inb_core $IPT -A inbound -d $NETPA1a -j inb_core $IPT -A inbound -d $NETPA1b -j inb_backbone $IPT -A inbound -d $NETPI2 -j inb_webs $IPT -A inbound -d $NETPA3 -j inb_fullip $IPT -A inbound -d $NETPA4 -j inb_nonatip $IPT -A inbound -s $NETVPNBON -j inb_vpnbon custom_logdrop_chain_fn inbound "" "END" 12 Os endereços das interfaces loopback não são necessariamente do bloco /8 28

35 $IPT -A outbound -d $NETPA1 -j ACCEPT $IPT -A outbound -d $NETPREFW -j ACCEPT # Tratamento diferenciado por bloco $IPT -A outbound -p tcp --syn -j outb_check_hhd $IPT -A outbound -s $NETPI1 -j outb_core $IPT -A outbound -s $NETPA1a -j outb_core $IPT -A outbound -s $NETPA1b -j outb_backbone $IPT -A outbound -s $NETPI2 -j outb_webs $IPT -A outbound -s $NETPA3 -j outb_fullip $IPT -A outbound -s $NETPA4 -j outb_nonatip $IPT -A outbound -s $NETPRV1 -j outb_privip custom_logdrop_chain_fn outbound "" "END" A fase seguinte de triagem realiza a separação por chains dedicadas a cada protocolo que corre sobre IP, para cada sentido do tráfego. $IPT -A inb_core -p tcp -j inb_core_tcp $IPT -A inb_core -p udp -j inb_core_udp $IPT -A inb_core -p gre -j inb_core_gre $IPT -A inb_core -p icmp -j inb_core_icmp custom_logdrop_chain_fn inb_core "" "END" $IPT -A outb_core -p tcp -j outb_core_tcp $IPT -A outb_core -p udp -j outb_core_udp $IPT -A outb_core -p gre -j outb_core_gre $IPT -A outb_core -p icmp -j outb_core_icmp custom_logdrop_chain_fn outb_core "" "END" Na entrada de ligações TCP para as redes centrais são rejeitadas as tentativas de acesso ao protocolo IDENT que, apesar de se encontrar obsoleto, algumas aplicações de servidor tentam utilizar para obter a identidade dos clientes que lhe ligam. Caso não seja recebido nada de volta a aplicação que esteja a usar o IDENT irá tentar realizar varias tentativas de ligação e com isso atrasar desnecessariamente a ligação dos clientes. Para os sub-blocos de endereçamento afectos aos diferentes protocolos e serviços é aceite a ligação se o porto é um dos preparados para a receber. As ligações TCP associadas ao protocolo DNS que são tipicamente utilizadas na replicação de zonas (domínios) entre servidores são ainda remetidas para validação do endereço origem noutra chain inb_core_dns_xfer, as restantes tentativas de acesso DNS (sobre TCP) são descartadas sem geração de registo por se tratar de uma situação algo frequente e sem utilidade identificada. Assume-se portanto a inexistência de mensagens DNS de elevada dimensão que exijam o transporte TCP nas correntes operações de resolução de nomes. $IPT -A inb_core_tcp -p tcp --dport 113 -j REJECT --reject-with tcp-reset # IdentSpeedUp $IPT -A inb_core_tcp -p tcp -d /30 --dport j ACCEPT # SIP $IPT -A inb_core_tcp -p tcp -d /31 --dport 25 -j ACCEPT # SMTP $IPT -A inb_core_tcp -p tcp -d /31 --dport 25 -j ACCEPT # SMTP $IPT -A inb_core_tcp -p tcp -d /31 --dport 465 -j ACCEPT # SSMTP Submit $IPT -A inb_core_tcp -p tcp -d dport 465 -j ACCEPT # SSMTP3 Submit $IPT -A inb_core_tcp -p tcp -d /31 --dport 587 -j ACCEPT # SMTP Submit $IPT -A inb_core_tcp -p tcp -d dport 587 -j ACCEPT # SMTP3 Submit $IPT -A inb_core_tcp -p tcp -d /31 -m multiport \ --destination-ports 110,995,143,993,4190 -j ACCEPT # POP3,SPOP3,IMAP4,SIMAP4,SIEVEMGR $IPT -A inb_core_tcp -p tcp -d /27 --dport 80 -j ACCEPT # WebsHTTP $IPT -A inb_core_tcp -p tcp -d /27 --dport 443 -j ACCEPT # WebsHTTPS $IPT -A inb_core_tcp -p tcp -d m multiport \ --destination-ports 80,554,1755 -j ACCEPT # Webcast HTTP,RTSP,MMST $IPT -A inb_core_tcp -p tcp -d /28 --dport 80 -j ACCEPT # Webs $IPT -A inb_core_tcp -p tcp --dport j ACCEPT # IPerf $IPT -A inb_core_tcp -p tcp -d dport 53 -j inb_core_dns_xfer # DNS XFER $IPT -A inb_core_tcp -p tcp -d /31 --dport 53 -j DROP # DNS XFER s/ LOG $IPT -A inb_core_tcp -p tcp -d /31 --dport 53 -j DROP # DNS XFER s/ LOG custom_logdrop_chain_fn inb_core_tcp "" "END" O estabelecimento de ligações TCP para o exterior a partir das redes centrais é bastante menos controlado, são aceites os envios de com origem em servidores controlados pela chain outb_smtp e aceites as ligações para um conjunto de portos pertencentes a serviços bem conhecidos e de utilização corrente, as restantes, apesar de serem aceites, geram um registo de sistema para facilitar a análise posterior da actividade não prevista nestas redes. $IPT -A outb_core_tcp -p tcp --dport 25 -j outb_smtp # SMTP $IPT -A outb_core_tcp -p tcp -m multiport \ 29

36 --destination-ports 21,53,80,443,2703,143,993,179 -j ACCEPT $IPT -A outb_core_tcp -m limit --limit 50/s -j LOG $LOGOPT \ --log-prefix "outb_core_tcp {TAIL ACCEPT}: " $IPT -A outb_core_tcp -j ACCEPT Continuando a análise da filtragem das redes centrais, agora, no caso da entrada de novas mensagens UDP; são contemplados os casos de acesso aos servidores autoritários de DNS, realizando-se uma validação de destinos na chain inb_core_dns, no caso do SIP (VoIP). No caso do RADIUS, a estratégia seguida é diferente sendo a triagem aqui realizada a partir do bloco de endereçamento destino atribuído a este grupo de servidores a validação detalhada de portos é só realizada na chain inb_core_radius. Outro tráfego é localmente aceite por não merecer um tratamento agregado específico. De notar uma situação pouco habitual, é aceite tráfego DHCP proveniente do exterior, exterior este que é relativo pois a intenção é servir as redes de visitantes eduroam que se encontram ao nível IP do lado de fora do firewall, contudo, para centralização do serviço de DHCP estas são servidas pelos servidores internos. É limitado o ritmo a que são aceites os pacotes UDP destinadas à gama de portos tipicamente utilizados pela aplicação traceroute para que esta funcione mas de forma moderada. $IPT -A inb_core_udp -p udp --dport 53 -j inb_core_dns $IPT -A inb_core_udp -d /30 -j inb_core_sip $IPT -A inb_core_udp -p udp -d /31 --dport 3478:3479 -j ACCEPT # STUN1/2 $IPT -A inb_core_udp -d /31 -j inb_core_radius $IPT -A inb_core_udp -p udp -d dport j ACCEPT # Webcast RTSPU $IPT -A inb_core_udp -p udp -d dport j ACCEPT # Webcast RTSPU $IPT -A inb_core_udp -p udp -d dport j ACCEPT # Webcast MMSU $IPT -A inb_core_udp -p udp -s $NETEU1 -d / \ --sport 67:68 --dport 67 -j ACCEPT # eduroam DHCP $IPT -A inb_core_udp -p udp --sport 1024: --dport j ACCEPT # IPerf $IPT -A inb_core_udp -p udp --sport 1024: --dport 33434: m limit \ --limit 5/s -j ACCEPT # Traceroute custom_logdrop_chain_fn inb_core_udp "" "END" A saída de tráfego UDP segue genericamente a mesma estratégia aplicada ao TCP, enumerando-se regras que lidam com o tráfego mais habitual iniciado pelos servidores e aceitando o restante com registo da ocorrência para que da análise de eventos possa resultar eventual optimização com a adição de regras específicas para lidar com casos de tráfego ainda não contemplado nas regras. $IPT -A outb_core_udp -p udp --dport 53 -j ACCEPT # DNS Resolvers $IPT -A outb_core_udp -p udp -s /31 \ --sport 3478: dport 1024: -j ACCEPT # STUN $IPT -A outb_core_udp -p udp --dport j ACCEPT # SPAM RAZOR2 $IPT -A outb_core_udp -p udp --sport $EPRANGE -j ACCEPT $IPT -A outb_core_udp -p udp -s $NETPA1a --sport dport 123 -j ACCEPT # NTP $IPT -A outb_core_udp -p udp --sport 1024: --dport 33434: j ACCEPT # Traceroute $IPT -A outb_core_udp -p udp -m limit --limit 50/s \ -j LOG $LOGOPT --log-prefix "outb_c_udp {TAIL ACCEPT}: " $IPT -A outb_core_udp -j ACCEPT O tratamento dado ao ICMP é relativamente genérico e independente dos endereços específicos envolvidos, são rejeitadas as mensagens transportadas sob fragmentos IP, situação que à partida não tem justificação e que no passado chegou a ser usada no abuso de falhas de programação em diversos sistemas operativos. É moderada a aceitação de mensagens ECHO REPLY para evitar abusos no uso da aplicação PING, o restante tráfego ICMP é também aceite com moderação mas numa regra distinta, para que as quotas de limite sejam distintas para qualquer dos casos. A saída de ICMP é tratada de forma similar, contudo, os limites são estendidos de forma a minimizar a possibilidade de terem impacto nas conclusões de ferramentas de análise de conectividade. custom_logdrop_chain_fn inb_core_icmp "-p icmp -f" "ICMP Frag" $IPT -A inb_core_icmp -p icmp --icmp-type echo-request -m limit --limit 5/s -j ACCEPT $IPT -A inb_core_icmp -p icmp --icmp-type echo-request -j DROP # Drop without log $IPT -A inb_core_icmp -p icmp -m limit --limit 5/s -j ACCEPT custom_logdrop_chain_fn inb_core_icmp "" "ICMP flood" $IPT -A outb_core_icmp -p icmp --icmp-type echo-request \ 30

37 -m limit --limit 100/s --limit-burst j ACCEPT $IPT -A outb_core_icmp -p icmp -m limit --limit 10/s -j ACCEPT custom_logdrop_chain_fn outb_core_icmp "" "ICMP Flood" Para lidar com a situação específica de uma VPN/Túnel suportada sobre o protocolo GRE que é utilizada no fornecimento de conectividade à rede interna num dos pólos que é servida por uma ligação ADSL de baixo débito, foram criadas as chain abaixo. $IPT -A inb_core_gre -d s j ACCEPT custom_logdrop_chain_fn inb_core_gre "" "END" # HULK2ISCAL2 $IPT -A outb_core_gre -s d j ACCEPT # HULK2ISCAL2 custom_logdrop_chain_fn outb_core_gre "" "END" Nos ramos seguintes da árvore de decisão aparecem chains que lidam com decisões já muito específicas para os serviços de rede, para o caso do SMTP corresponde a enumerar os servidores que podem enviar para o exterior. $IPT -A outb_smtp -s /31 -j ACCEPT $IPT -A outb_smtp -s /30 -j ACCEPT $IPT -A outb_smtp -s j ACCEPT $IPT -A outb_smtp -s /31 -j ACCEPT $IPT -A outb_smtp -s /31 -j ACCEPT custom_logdrop_chain_fn outb_smtp "" "END" # TEMP RBL # listas.ipl.pt Na entrada de pedidos de resolução DNS sobre transporte UDP, especificam-se os servidores acessíveis do exterior, adicionam-se ainda regras para a situação excepcional de se permitir acesso aos servidores forwarder a partir das redes de visitantes eduroam (que são locais, mas estão do lado de fora do firewall) bem como a rejeição sem direito a registo, dos pedidos restantes realizados aos forwarder. O tráfego anómalo contemplado por esta regra é bastante comum. Alguns equipamentos tendem a manter a informação dos servidores DNS persistente, após utilização de uma rede interna ao IPL, mesmo mudando-se para uma rede exterior (3G, ADSL, Cabo, etc.) continuam erroneamente a tentar usar os forwarder internos. $IPT -A inb_core_dns -d j ACCEPT $IPT -A inb_core_dns -d j ACCEPT $IPT -A inb_core_dns -d /31 -j ACCEPT $IPT -A inb_core_dns -d /31 -j ACCEPT $IPT -A inb_core_dns -s $NETEU1 -d /31 -j ACCEPT $IPT -A inb_core_dns -s $NETEU1 -d j ACCEPT $IPT -A inb_core_dns -d /31 -j DROP $IPT -A inb_core_dns -d /31 -j DROP custom_logdrop_chain_fn inb_core_dns "" "END" # NS1 # NS2 # NS1, NS4 # RNS1, RNS2 # FNS/NET100 # FNS/NET100 # FNS1, FNS2 # FNS1, FNS2 Os acessos de DNS sob transporte TCP são limitados às máquinas externas que suportam réplicas de domínios mantidos nos servidores internos. $IPT -A inb_core_dns_xfer -s j ACCEPT $IPT -A inb_core_dns_xfer -s j ACCEPT $IPT -A inb_core_dns_xfer -s j ACCEPT custom_logdrop_chain_fn inb_core_dns_xfer "" "END" # TEREDO # NRENUM # NRENUM/E164 As comunicações de SIP também necessitam de triagem adicional, contemplando-se regras para os fluxos de dados multimédia e para a sinalização. É usado o módulo de validação genérica de strings na detecção de uma aplicação usada na intrusão em sistemas VoIP, combinada com a função de rejeição e registo. $IPT -A inb_core_sip -p udp --sport 30000: dport 1024: -j ACCEPT # RTP $IPT -A inb_core_sip -p udp --sport 1024: --dport 30000: j ACCEPT # RTP $IPT -A inb_core_sip -p udp --sport dport 1024: -j ACCEPT # RTP custom_logdrop_chain_fn inb_core_sip "-p udp --dport m string --algo bm --string friendlyscanner --from to 250" "SIP SCAN" $IPT -A inb_core_sip -p udp --sport 1024: --dport j ACCEPT # SIP custom_logdrop_chain_fn inb_core_sip "" "END" 31

38 O universo das comunicações RADIUS, no estado actual de utilização deste protocolo em que a hierarquia é estática, merece também a limitação das maquinas de que é aceite este tráfego e para que portos. custom_logdrop_chain_fn inb_core_radius "! -s /24" "Not FCCN" $IPT -A inb_core_radius -p udp --sport 1024: --dport 1812:1813 -j ACCEPT $IPT -A inb_core_radius -p udp --sport 1812: dport j ACCEPT custom_logdrop_chain_fn inb_core_radius "" "END" Alguns serviços da rede utilizam endereços do bloco reservado para infra-estrutura, destacam-se nestes os de VPN do tipo PPTP e os de sincronização de relógios utilizando o protocolo NTP. $IPT -A inb_backbone -p tcp -d /29 --dport j ACCEPT # PPTP VPN $IPT -A inb_backbone -p tcp -d dport j ACCEPT # PPTP VoIPRCTS $IPT -A inb_backbone -p tcp -d dport j ACCEPT # PPTP VPN custom_logdrop_chain_fn inb_backbone "" "END" $IPT -A outb_backbone -p udp --sport dport 123 -j ACCEPT custom_logdrop_chain_fn outb_backbone "" "END" # NTP BRYANT Ao bloco de endereçamento destinado aos servidores web em regime de alojamento são genericamente abertos os portos HTTP/80, HTTPS/443 e HTTP/8080 (para suporte de webservices), adicionalmente, para suporte à gestão remota em alguns casos realizada por empresas externas, são abertos os portos e para os protocolos RDC (Remote Desktop) e SSH, para acesso às consolas de máquinas Windows e Linux. Não são usados os valores de porto por omissão para os protocolos de gestão remota, de forma a minimizar as tentativas de acesso baseadas em pesquisa de blocos de endereçamento. Os acessos a estes dois portos são registados no arquivo de sistema. Para alguns dos servidores alojados são abertos portos caso-a-caso, para suporte a serviços adicionais que o justifiquem. Curioso o caso do acesso FTP à máquina de alojamento partilhado SDWSites, para esta é necessária a abertura explicita dos portos para o acesso em modo passivo, tal é normalmente dispensável pois o módulo conntrack e o helper nf_conntrack_ftp tratariam de as considerar automaticamente como RELATED pelo que nunca chegariam a esta fase da avaliação e eram aceites logo no inicio, no entanto, como é usada a variante segura de FTP com cifra do canal de controlo, não é possível ao helper realizar o habitual apoio nesta classificação do tráfego. $IPT -A inb_webs -p tcp --dport 80 -j ACCEPT # HTTP $IPT -A inb_webs -p tcp --dport 443 -j ACCEPT # HTTPS $IPT -A inb_webs -p tcp --dport j ACCEPT # HTTPAlt $IPT -A inb_webs -p tcp --dport j LOG --log-prefix "inb_webs {RDCAlt}: " # RDCAlt $IPT -A inb_webs -p tcp --dport j ACCEPT # RDCAlt $IPT -A inb_webs -p tcp --dport j LOG --log-prefix "inb_webs {SSHAlt}: " # SSHAlt $IPT -A inb_webs -p tcp --dport j ACCEPT # SSHAlt $IPT -A inb_webs -p tcp -d m multiport \ --destination-ports 41112,8000 -j ACCEPT # HAM Misc $IPT -A inb_webs -p tcp -d dport 5000:5020 -j ACCEPT $IPT -A inb_webs -p tcp -d m multiport \ --destination-ports 1433,1144 -j ACCEPT $IPT -A inb_webs -p tcp -d /31 -m multiport \ --destination-ports 1935,5080,9000 -j ACCEPT $IPT -A inb_webs -p tcp -d dport 21 -j ACCEPT # FTPS SDWSites $IPT -A inb_webs -p tcp -d dport $PASVRANGE -j ACCEPT # FTPS PASSIVE & TLS $IPT -A inb_webs -p tcp -d dport 21 -j ACCEPT # FTP ISEL custom_logdrop_chain_fn inb_webs "" "END" $IPT -A outb_webs -p tcp -s dport 5000:5020 -j ACCEPT $IPT -A outb_webs -p tcp -s m multiport \ --destination-ports 443,1144,1433,8000,8001,8002,8003,8004,8005,8006 \ -j ACCEPT $IPT -A outb_webs -p tcp -s m multiport \ --destination-ports 41112,8000,7373,7300 -j ACCEPT $IPT -A outb_webs -p tcp -s sport 20 --dport 1024: \ -j ACCEPT # FTPS SDWSites custom_logdrop_chain_fn outb_webs "" "END" 32

39 Algumas redes, apesar de internas obrigam a uma filtragem minimalista, devido à impossibilidade de se gerirem de forma granular os protocolos permitidos, tal é usado para os sistemas de videoconferência e para a rede disponibilizada ao ISEL para os seus sistemas de rede autónomos dos do IPL. Os sistemas de videoconferência encontram-se numa fase de identificação do perfil de comunicações em que as ligações típicas que fazem são traduzidas em regras (por inspecção periódica aos eventos gerados), as restantes geram registo para posterior traçado do perfil. $IPT -A la_inb_fullip -m hashlimit --hashlimit 10/min --hashlimit-burst 10 \ --hashlimit-mode dstip --hashlimit-name inb_fullip \ -j LOG $LOGOPT --log-prefix "la_inb_fullip {OTHER}: " $IPT -A la_inb_fullip -j ACCEPT custom_logdrop_chain_fn inb_fullip_vc "-p tcp --dport :1023" "bad TCP port" $IPT -A inb_fullip_vc -p tcp --dport j ACCEPT # H.323 Call Setup $IPT -A inb_fullip_vc -p udp --dport j ACCEPT # SIP Call Setup $IPT -A inb_fullip_vc -d j la_inb_fullip # G VC SC $IPT -A inb_fullip_vc -d j la_inb_fullip # G VC ESCS $IPT -A inb_fullip_vc -d j la_inb_fullip # G VC ESTeSL $IPT -A inb_fullip_vc -p icmp -m limit --limit 1/sec -j ACCEPT $IPT -A inb_fullip_vc -p icmp --icmp-type echo-request -j DROP custom_logdrop_chain_fn inb_fullip_vc "" "END" $IPT -A inb_fullip -d j la_inb_fullip $IPT -A inb_fullip -d /28 -j inb_fullip_vc $IPT -A inb_fullip -d /28 p tcp -j la_inb_fullip $IPT -A inb_fullip -d /28 p udp -j la_inb_fullip $IPT -A inb_fullip -d /28 p icmp -j la_inb_fullip custom_logdrop_chain_fn inb_fullip "" "END" $IPT -A la_outb_fullip -m hashlimit --hashlimit 1/min --hashlimit-burst 2 \ --hashlimit-mode srcip --hashlimit-name outb_fullip -j LOG $LOGOPT --log-prefix "la_outb_fullip {OTHER}: " $IPT -A la_outb_fullip -j ACCEPT # G VIDEOCONF # ISEL-DIRECTO # ISEL-DIRECTO # ISEL-DIRECTO $IPT -A outb_fullip -s j la_outb_fullip $IPT -A outb_fullip -s j la_outb_fullip $IPT -A outb_fullip -s j la_outb_fullip $IPT -A outb_fullip -s j la_outb_fullip $IPT -A outb_fullip -s /28 p tcp -j la_outb_fullip $IPT -A outb_fullip -s /28 p udp -j la_outb_fullip $IPT -A outb_fullip -s /28 p icmp -j la_outb_fullip custom_logdrop_chain_fn outb_fullip "" "END" # G VC SC # G VC ESCS # G VC ESTeSL # ISEL-DIRECTO # ISEL-DIRECTO # ISEL-DIRECTO As redes internas que usam endereçamento público dispensando NAT são controladas com algum cuidado pois aplicam-se a diversas redes em que se ligam equipamentos dos utilizadores fora do controlo directo da gestão central da rede. Genericamente este bloco tem conectividade praticamente sem limites no sentido outbound, estando as comunicações inbound limitadas ao tráfego de retorno e a um bloco de portos para uso em aplicações que o exijam. É realizada uma tentativa de detecção de aplicações P2P a que é aplicada uma chain de descarte e registo. $IPT -A ldinnonatip -m hashlimit --hashlimit 6/hour --hashlimit-burst 2 \ --hashlimit-mode dstip --hashlimit-name innonatip \ -j LOG $LOGOPT --log-prefix "ldinnonatip {INBnoNAT-END}: " $IPT -A ldinnonatip -j pcaplog $IPT -A ldinnonatip -j DROP $IPT -A lainnonatip -m hashlimit --hashlimit 6/hour --hashlimit-burst 2 \ --hashlimit-mode dstip --hashlimit-name ainnonatip \ -j LOG $LOGOPT --log-prefix "lainnonatip {INBnoNAT-REV}: " $IPT -A lainnonatip -j ACCEPT $IPT -A inb_nonatip -p tcp --dport 40000: j ACCEPT $IPT -A inb_nonatip -p udp --dport 40000: j ACCEPT $IPT -A inb_nonatip -p tcp -m ipp2p --bit -j ldinnonatip $IPT -A inb_nonatip -p udp -m ipp2p --bit -j ldinnonatip $IPT -A inb_nonatip -j ldinnonatip $IPT -A inb_nonatip -j DROP $IPT -A ldpubp2p -m hashlimit --hashlimit 1/min --hashlimit-burst 1 \ --hashlimit-mode srcip --hashlimit-name pub_p2p \ -j LOG $LOGOPT --log-prefix "ldpubp2p {P2PviaPUBLIC}: " $IPT -A ldpubp2p -j pcaplog $IPT -A ldpubp2p -j DROP 33

40 $IPT -A outb_nonatip -p tcp --dport 25 -j REJECT --reject-with tcp-reset # SMTP SpeedUp $IPT -A outb_nonatip -p tcp -m ipp2p --bit -j ldpubp2p $IPT -A outb_nonatip -p udp -m ipp2p --bit -j ldpubp2p $IPT -A outb_nonatip -j ACCEPT Na chain outbound, a todos os segmentos de estabelecimento de ligação TCP é aplicado um salto de verificação à chain outb_check_hhd, verificação esta que tenta identificar valores de TTL fora do esperado em cada rede e com isto detectar a adição de saltos adicionais na rede com equipamentos trazidos para a infra-estrutura pelos utilizadores e que poderão potencialmente degradar o serviço para toda a comunidade servida. $IPT -A outb_check_hhd -s /11 -m ttl --ttl-eq 125 -j RETURN $IPT -A outb_check_hhd -s /11 -m ttl --ttl-eq 61 -j RETURN $IPT -A outb_check_hhd -s /24 -m ttl --ttl-eq 124 -j RETURN $IPT -A outb_check_hhd -s /24 -m ttl --ttl-eq 60 -j RETURN $IPT -A outb_check_hhd -s /11 -m ttl --ttl-eq 123 -j RETURN $IPT -A outb_check_hhd -s /11 -m ttl --ttl-eq 69 -j RETURN $IPT -A outb_check_hhd -s /24 -m ttl --ttl-eq 126 -j RETURN $IPT -A outb_check_hhd -s /24 -m ttl --ttl-eq 62 -j RETURN $IPT -A outb_check_hhd -s /24 -m ttl --ttl-eq 125 -j RETURN $IPT -A outb_check_hhd -s /24 -m ttl --ttl-eq 61 -j RETURN $IPT -A outb_check_hhd -s /24 -m ttl --ttl-eq 126 -j RETURN $IPT -A outb_check_hhd -s /24 -m ttl --ttl-eq 62 -j RETURN $IPT -A outb_check_hhd -s /20 -m ttl --ttl-eq 125 -j RETURN $IPT -A outb_check_hhd -s /20 -m ttl --ttl-eq 61 -j RETURN $IPT -A outb_check_hhd -s /24 -m ttl --ttl-eq 126 -j RETURN $IPT -A outb_check_hhd -s /24 -m ttl --ttl-eq 62 -j RETURN $IPT -A outb_check_hhd -s /24 -m ttl --ttl-eq 126 -j RETURN $IPT -A outb_check_hhd -s /24 -m ttl --ttl-eq 62 -j RETURN $IPT -A outb_check_hhd -s /24 -m ttl --ttl-eq 126 -j RETURN $IPT -A outb_check_hhd -s /24 -m ttl --ttl-eq 62 -j RETURN $IPT -A outb_check_hhd -s /24 -m ttl --ttl-eq 124 -j RETURN $IPT -A outb_check_hhd -s /24 -m ttl --ttl-eq 60 -j RETURN $IPT -A outb_check_hhd -s /28 -m ttl --ttl-eq 125 -j RETURN # GERAL VC $IPT -A outb_check_hhd -s /28 -m ttl --ttl-eq 61 -j RETURN $IPT -A outb_check_hhd -s /27 -m ttl --ttl-eq 124 -j RETURN # ISEL SRV $IPT -A outb_check_hhd -s /27 -m ttl --ttl-eq 60 -j RETURN $IPT -A outb_check_hhd -m hashlimit --hashlimit 1/min --hashlimit-burst 1 \ --hashlimit-mode srcip --hashlimit-srcmask 24 \ --hashlimit-name check_hhd -j LOG $LOGOPT \ --log-prefix "outb_check_hhd {WARNING}: " $IPT -A outb_check_hhd -j RETURN As comunicações para o exterior a partir do bloco de endereçamento interno utilizado nas redes académicas, administrativas e de gestão da rede também são controladas na tentativa de identificar o uso de aplicações P2P. O tráfego que passar neste ponto será ainda sujeito a uma segunda análise na tabela nat. $IPT -A ldprivp2p -m hashlimit --hashlimit 1/min --hashlimit-burst 1 \ --hashlimit-mode srcip --hashlimit-name priv_p2p \ -j LOG $LOGOPT --log-prefix "ldprivp2p {P2PviaNAT}: " $IPT -A ldprivp2p -j pcaplog $IPT -A ldprivp2p -j DROP $IPT -A outb_privip -p tcp -m ipp2p --edk --dc --kazaa --gnu --bit -j ldprivp2p $IPT -A outb_privip -p udp -m ipp2p --edk --dc --kazaa --gnu --bit -j ldprivp2p $IPT -A outb_privip -j ACCEPT # NAT em POSTROUTING Para lidar com algumas situações especiais em que os utilizadores estabelecem do exterior ligações VPN para equipamentos localizados numa rede do IPL exterior ao firewall e necessitam aceder a alguns recursos internos, foi criada a chain inb_vpnbon. Neste momento a situação aplica-se aos acessos à VPN de acesso à biblioteca online, b-on. $IPT -A inb_vpnbon -s $NETVPNBON -d j ACCEPT custom_logdrop_chain_fn inb_vpnbon "" "END" 34

41 Chains de NAT em IPv4 Figura 12 Chains de filtragem do tráfego em FORWARD Por omissão o tráfego que atravessa do sistema firewall não é sujeito a NAT, nos pontos de intercepção PREROUTING e POSTROUTING são aplicadas as chains que irão tratar o tráfego inbound (pre_inbound) e outbound (post_outbound). A troca rápida de chains no processo de actualização é também usada nestas. O processamento do tráfego de inbound é o mais simples, um endereço público é usado para multiplexar o acesso a vários serviços que só dispõem de endereços internos, estes são seleccionados com base no porto TCP destino, na chain pre_inb_mapp. $IPT -t nat -A pre_inbound -d j pre_inb_mapp $IPT -t nat -A pre_inbound -d j DNAT --to-destination # VPN $IPT -t nat -A pre_inbound -j ACCEPT $IPT -t nat -A pre_inb_mapp -p tcp --dport \ -j DNAT --to-destination :3389 $IPT -t nat -A pre_inb_mapp -p tcp --dport 49921:49999 \ -j DNAT --to-destination $IPT -t nat -A pre_inb_mapp -p tcp --dport \ -j DNAT --to-destination :43389 $IPT -t nat -A pre_inb_mapp -j ACCEPT 35

42 No sentido outbound verifica-se, em post_outb_srv, se, para os endereços públicos existe alguma situação extrema que exija o uso de NAT. Esporadicamente ocorrem intrusões nas caixas de correio dos utilizadores (normalmente facilitadas pelo uso de palavras-chave óbvias), estas intrusões têm tipicamente o objectivo de usar as caixas de correio para envio de SPAM. Quando tal ocorre com grande probabilidade os servidores são colocados em listas negras internacionais e impedidos do envio de legítimo. Para tornear o problema é activada esta regra para que as comunicações saiam com um endereço não incluído nas listas negras. Todo o restante tráfego de endereços fora do bloco privado /8 é aceite sem qualquer alteração de cabeçalhos. Comunicações destinadas a endereços públicos (do IPL) da zona exterior do firewall são excluídas de NAT, tráfego destinado aos portos TCP associados a serviços web são tratados na chain post_outb_web que tratará dos pormenores. Os equipamentos nas redes do bloco /13 usado em redes de gestão têm a decisão em post_outb_serv. Para as redes destino que o módulo de validação geoip identifique como nacionais é aceite o tratamento geral de NAT via a chain post_outb_natpool. O módulo utilizado em post_outb_natpool para a aplicação do NAT é o DNETMAP cujo funcionamento é analisado em detalhe em Para as restantes redes destino, para comunicações TCP ou UDP, são usadas duas chain específicas post_outb_tcp e post_outb_udp, estas usam o módulo de validação ipset aplicado a grupos de portos (usando bitmaps), para decidir se o porto/serviço destino pretendido se encontra no set dos considerados inóculos e com interesse para as actividades das redes académicas ou administrativas. Se o tráfego é ICMP do tipo ECHO-REQUEST, a chain post_outb_ping permitirá a alteração selectiva de endereços recorrendo ao módulo de verificação genérica de strings em pacotes. Irá permitir a selecção do endereço IP a usar no NAT, entre três hipóteses. Por omissão o trafego sairá com mesmo endereço das restantes comunicações, no entanto, se no início do corpo da mensagem ICMP aparecerem as letras PI, será usado um endereço da gama provider independent, se a palavra incluída for PA o endereço usado será da gama provider aggregatable. Esta funcionalidade foi preparada para permitir a despistagem de problemas de conectividade Internet que tratem de forma diferenciada os blocos de endereçamento devido a problemas na propagação das rotas no BGP do backbone da Internet. $IPT -t nat -A post_outbound! -s $NETPRV1 -j post_outb_srv $IPT -t nat -A post_outbound -d $NETPA1 -j ACCEPT $IPT -t nat -A post_outbound -d $NETPREFW -j ACCEPT $IPT -t nat -A post_outbound -p tcp --dport 80 -j post_outb_web $IPT -t nat -A post_outbound -p tcp --dport 443 -j post_outb_web $IPT -t nat -A post_outbound -p tcp --dport j post_outb_web # FCT $IPT -t nat -A post_outbound -s /13 -j post_outb_serv $IPT -t nat -A post_outbound -m geoip --dst-cc PT \ -j post_outb_natpool $IPT -t nat -A post_outbound -s /13 -j ACCEPT # Mais nenhum NAT para servicos $IPT -t nat -A post_outbound -p tcp -j post_outb_tcp $IPT -t nat -A post_outbound -p udp -j post_outb_udp $IPT -t nat -A post_outbound -p icmp --icmp-type echo-request -j post_outb_ping $IPT -t nat -A post_outbound -j ACCEPT $IPT -t nat -A post_outb_srv -p tcp -s dport 25 \ -j SNAT --to-source # RBL Hack ISEL $IPT -t nat -A post_outb_srv -j ACCEPT $IPT -t nat -A post_outb_serv -p tcp --dport 21 -j post_outb_web # FTP Update Emerge $IPT -t nat -A post_outb_serv -p tcp --sport 40000: j post_outb_web # Escape $IPT -t nat -A post_outb_web -s $NETPRV1 -j post_outb_natpool $IPT -t nat -A post_outb_web -j ACCEPT 36

43 $IPT -t nat -A post_outb_natpool \ -j DNETMAP --prefix /22 $IPT -t nat -A post_outb_natpool -j ACCEPT $IPT -t nat -A post_outb_tcp -p tcp \ -m set --match-set nat-tcp-ovl-hosts dst -j post_outb_natpool $IPT -t nat -A post_outb_tcp -j ACCEPT $IPT -t nat -A post_outb_udp -p udp \ -m set --match-set nat-udp-ovl-hosts dst -j post_outb_natpool $IPT -t nat -A post_outb_udp -j ACCEPT $IPT -t nat -A post_outb_ping -m string --algo bm --string PI --from 28 --to 40 \ -j SNAT --to-source $IPNATOVLPA $IPT -t nat -A post_outb_ping -m string --algo bm --string PA --from 28 --to 40 \ -j SNAT --to-source $IPNATOVLPI $IPT -t nat -A post_outb_ping -j post_outb_natpool $IPT -t nat -A post_outb_ping -j ACCEPT Chains em IPv6 Figura 13 - Chains de nat em IPv4 Como a dimensão dos blocos de endereçamento IPv6 permitem maiores folgas, é possível uma melhor estruturação das redes; adicionalmente a quantidade e complexidade dos serviços existentes e sua utilização pela comunidade é também significativamente reduzida comparativamente ao IPv4 pelo que tal se reflecte também na dimensão e complexidade das chains de tratamento deste tráfego. Apesar de já se encontrarem preparados os scripts para a actualização das tabelas mangle e nat, estes actualmente apenas realizam a inicialização e limpeza das tabelas respectivas estando preparados para quando for necessário o seu uso. Em raw à semelhança do realizado para IPv4, o script de actualização apenas faz a inicialização e limpeza das tabelas, estando aplicada uma única regra para excluir o tráfego de multicast do controlo do conntrack. $IP6T -t raw -A PREROUTING -d ff00::/8 -j CT notrack Variáveis BASH definidas em IN6Fw.sh para utilização nos scripts Para além das variáveis com o caminho completo para a maioria dos executáveis usados, são definidas as variáveis BASH seguintes, algumas de forma dinâmica. IPLNET6="2001:690:2008::/48" IPLNETREST6="2001:690:2008::/52" LINKLOCAL="fe80::/64" ADMNET6="2001:690:2008:E0C8::/61" SRVNET6="2001:690:2008:E000::/56" PASVRANGE="59900:60000" 37

44 EPRANGE=`/sbin/sysctl -n net.ipv4.ip_local_port_range /bin/sed 's/ /:/'` HOSTIPS=`${IP} -f inet6 addr grep -F 'inet6 ' grep -v -F 'inet6 fe80::' \ sed 's/.*inet6 \([^\/]\+\)\/.*/\1/' sort` HOST=`/bin/uname -n /bin/cut -d '.' -f 1` LOGOPT="--log-tcp-options --log-ip-options --log-tcp-sequence" IFINT="bond0" IFEXT="bond1" Chains de filtragem em IPv6 para INPUT e OUTPUT Para permitir a técnica de troca rápida de chains nas actualizações, à semelhança do realizado em IPv4, são usadas as chain base_in e base_out para as quais a única regra de INPUT e OUTPUT remetem. Na recepção de tráfego destinado localmente, é realizado o descarte do considerado INVALID pelo conntrack, aceite o considerado RELATED ou ESTABLISHED. O tráfego considerado NEW, se provir da interface loopback, também é aceite. Tráfego originado ou destinado a endereços do bloco link local também é aceite sem validações adicionais. Novas ligações TCP provenientes de portos privilegiados são rejeitadas com recurso a custom_logdrop_chain_fn, ligações aos portos TCP 22 (SSH) e 873 (RSYNC) e mensagens ICMP ECHO são permitidas mediante verificação adicional na chain mgmtnets. Todo o restante tráfego neste ponto é rejeitado via a custom_logdrop_chain_fn. $IP6T -A base_in -m conntrack --ctstate INVALID -j DROP $IP6T -A base_in -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT $IP6T -A base_in -i lo -m conntrack --ctstate NEW -j ACCEPT $IP6T -A base_in -s $LINKLOCAL -j ACCEPT $IP6T -A base_in -d $LINKLOCAL -j ACCEPT custom_logdrop_chain_fn base_in "-p tcp --sport : syn" "SYN from lowport" $IP6T -A base_in -p tcp --dport 22 --syn -j mgmtnets $IP6T -A base_in -p tcp --dport syn -j mgmtnets $IP6T -A base_in -p icmpv6 --icmpv6-type echo-request -j mgmtnets custom_logdrop_chain_fn base_in "" "END" $IP6T -A mgmtnets -s $IPLNETREST6 -j ACCEPT $IP6T -A mgmtnets -s $SRVNET6 -j ACCEPT $IP6T -A mgmtnets -s $ADMNET6 -j ACCEPT custom_logdrop_chain_fn mgmtnets "" "END" O tráfego gerado localmente via loopback ou usando o endereço link local não tem quaisquer limitações, se for usado um porto privilegiado no estabelecimento de ligações TCP, é registado um evento. O ICMPv6 tem validações adicionais na chain icmpout, nesta aceitam-se mensagens ECHO-REQUEST e ECHO-REPLY aplicando-se limitação de ritmo de uma por segundo às mensagens de PACKET-TOO-BIG, o restante ICMPv6 tem a mesma limitação de ritmo mas é tratado por outra regra para que as quotas sejam independentes. Caso o limite seja excedido o tráfego é rejeitado e registado o evento com a custom_logdrop_chain_fn. Todo o restante tráfego (não ICMPv6) é aceite partir desta fase. $IP6T -A base_out -o lo -j ACCEPT $IP6T -A base_out -s $LINKLOCAL -j ACCEPT $IP6T -A base_out -p tcp! --sport $EPRANGE --syn \ -j LOG --log-prefix "EPRange violation! TCP: " $IP6T -A base_out -p icmpv6 -j icmpout $IP6T -A base_out -j ACCEPT $IP6T -A icmpout -p icmpv6 --icmpv6-type echo-request -j ACCEPT $IP6T -A icmpout -p icmpv6 --icmpv6-type echo-reply -j ACCEPT $IP6T -A icmpout -p icmpv6 --icmpv6-type packet-too-big -m limit --limit 1/s -j ACCEPT $IP6T -A icmpout -m limit --limit 1/s -j ACCEPT custom_logdrop_chain_fn icmpout "" "ICMP flood" 38

45 Figura 14 - Chains de filtragem para IPv Chains de filtragem em IPv6 para FORWARDING No ponto de intercepção de FORWARDING de IPv6, é delegada a avaliação em base_forw, nesta é desde logo, realizado o descarte do tráfego que o conntrack considere INVALID, pacotes que contenham o cabeçalho de encaminhamento explícito (Routing Header) ou que não tenham cabeçalho de transporte (type 59, No Next Header) são descartados com registo apoiado pela custom_logdrop_chain_fn. Tráfego de comunicações pré-estabelecidas ou relacionado com estas é aceite. Pacotes de novas comunicações serão tratados em mais detalhe pelas chain de inbound e outbound, dependendo do sentido em que viajar. Para evitar o registo desnecessário de pedidos de aborte de ligação (RST) duplicados, é incluída uma regra que realiza o simples descarte. O restante tráfego é descartado e registado. $IP6T -A base_forw -i $IFEXT -m conntrack --ctstate INVALID -j DROP custom_logdrop_chain_fn base_forw "-m ipv6header --header route,59" "Invalid header" $IP6T -A base_forw -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT $IP6T -A base_forw -i $IFEXT -m conntrack --ctstate NEW -j inbound $IP6T -A base_forw -o $IFEXT -m conntrack --ctstate NEW -j outbound $IP6T -A base_forw -m conntrack --ctstate UNTRACKED -j ACCEPT $IP6T -A base_forw -o $IFEXT -p tcp --tcp-flags RST RST -j DROP # delayed dup RST custom_logdrop_chain_fn base_forw "" "END" Em inbound é, no início, realizada uma limpeza do tráfego proveniente do exterior, tratando de diversas situações inválidas ou fora do comum como o uso de endereços origem que não pertençam ao bloco global unicast, cujo destino não exista do lado interno ou que usem portos de valor zero. Pacotes de endereços locais que se encontrem na rede ou nos equipamentos adjacentes ao firewall do lado exterior são aceites. Tráfego ICMPv6 e TCP são remetidos para uma análise mais detalhada nas chain inb_icmp e tcpbadflags. É permitida a realização de traceroute baseado em UDP, desde que o ritmo das mensagens de teste não exceda as 5 por segundo. Tráfego TCP que atinja esta fase de avaliação e não seja um pedido de estabelecimento (SYN) ou que use porto origem privilegiado é descartado e registado com o apoio da custom_logdrop_chain_fn. Segue-se a distribuição da avaliação por chains dedicadas a blocos de endereçamento contemplando a rede central de servidores (inb_srv), a de alojamento (inb_hosting) e a utilizada no campus do ISEL (inb_isel). Para o caso especial dos endereços usados pelos sistemas Windows para o acesso a DNS em anycast (usando endereços do bloco Site-Local já descontinuado pelo IETF), é encaminhado o pedido para a chain inb_dns. 39

46 Para monitorização, o tráfego para os diversos blocos de endereçamento atribuídos a redes de clientes são descartados e registados com o apoio da custom_logdrop_chain_fn. Dada a funcionalidade atribuída a estes blocos, para a utilização comum actual não é de esperar ligações inbound com relevo. custom_logdrop_chain_fn inbound "! -s 2000::/3" "IETF reserved" custom_logdrop_chain_fn inbound "! -d $IPLNET6" "Not for IPLNet" custom_logdrop_chain_fn inbound "-p tcp --sport 0" "SPort=0" custom_logdrop_chain_fn inbound "-p udp --sport 0" "SPort=0" $IP6T -A inbound -s $IPLNET6 -j ACCEPT $IP6T -A inbound -p icmpv6 -j inb_icmp $IP6T -A inbound -p tcp -j tcpbadflags $IP6T -A inbound -p udp --sport 1024: --dport 33434: m limit --limit 5/s \ -j ACCEPT # Trace custom_logdrop_chain_fn inbound "-p tcp! --syn" "Not SYN" custom_logdrop_chain_fn inbound "-p tcp --sport :1023" "SPort<1024" $IP6T -A inbound -d 2001:690:2008::100:0/111 -j inb_srv $IP6T -A inbound -d 2001:690:2008:e120::100:5000/116 -j inb_hosting $IP6T -A inbound -d 2001:690:2008:df00::/56 -j inb_isel $IP6T -A inbound -d fec0:0:0:ffff::/126 -j inb_dns custom_logdrop_chain_fn inbound "-d 2001:690:2008::1000/116" "LoopIPs" custom_logdrop_chain_fn inbound "-d 2001:690:2008::/64" "CoreNets" custom_logdrop_chain_fn inbound "-d 2001:690:2008:2c0::/96" "LinkNets" custom_logdrop_chain_fn inbound "-d 2001:690:2008:cf00::/56" "LRCNets" custom_logdrop_chain_fn inbound "-d 2001:690:2008:e000::/56" "SrvOpNets" custom_logdrop_chain_fn inbound "-d 2001:690:2008:e100::/56" "IPLNetDiversos" custom_logdrop_chain_fn inbound "-d 2001:690:2008:e200::/56" "IPLNetInfra" custom_logdrop_chain_fn inbound "-d 2001:690:2008:e600::/56" "SAS" custom_logdrop_chain_fn inbound "-d 2001:690:2008:e700::/56" "SC" custom_logdrop_chain_fn inbound "-d 2001:690:2008:e800::/56" "ESCS" custom_logdrop_chain_fn inbound "-d 2001:690:2008:e900::/56" "ESD" custom_logdrop_chain_fn inbound "-d 2001:690:2008:ea00::/56" "ESELx" custom_logdrop_chain_fn inbound "-d 2001:690:2008:eb00::/56" "ESML" custom_logdrop_chain_fn inbound "-d 2001:690:2008:ec00::/56" "ESTC" custom_logdrop_chain_fn inbound "-d 2001:690:2008:ed00::/56" "ESTeSL" custom_logdrop_chain_fn inbound "-d 2001:690:2008:ee00::/56" "ISCAL" custom_logdrop_chain_fn inbound "-d 2001:690:2008:ef00::/56" "ISEL" custom_logdrop_chain_fn inbound "-d 2001:690:2008:e000::/52" "IPLNetAdmin" custom_logdrop_chain_fn inbound "" "END" Não é aceite tráfego ICMPv6 que seja sujeito a fragmentação, situação especialmente incomum em IPv6 por as regras imporem uma dimensão máxima de 1280 octetos às mensagens de erro o que lhes garante o trânsito da Internet sem necessidade de fragmentação. As mensagens ICMPv6 mais comuns e consideradas importantes para o normal funcionamento da rede são aceites com limitações de ritmo. O restante ICMPv6 é descartado com registo e o apoio de custom_logdrop_chain_fn, exceptua-se os pedidos ECHO-REQUEST que pela sua elevada frequência são descartados sem registo para evitar a manutenção de registos pouco relevantes. custom_logdrop_chain_fn inb_icmp "-m ipv6header --header frag" "ICMP Fragmented" $IP6T -A inb_icmp -p icmpv6 --icmpv6-type echo-request -m limit --limit 10/s -j ACCEPT $IP6T -A inb_icmp -p icmpv6 --icmpv6-type packet-too-big -m limit --limit 10/s -j ACCEPT $IP6T -A inb_icmp -p icmpv6 --icmpv6-type time-exceeded -m limit --limit 10/s -j ACCEPT $IP6T -A inb_icmp -p icmpv6 --icmpv6-type destination-unreachable \ -m limit --limit 10/s -j ACCEPT $IP6T -A inb_icmp -p icmpv6 --icmpv6-type echo-request -j DROP custom_logdrop_chain_fn inb_icmp "" "ICMP flood" A chain tcpbadflags, tal como em IPv4 detecta combinações inválidas de flags e descarta o tráfego moderando os registos com o apoio da chain ldtcpbf. $IP6T -A tcpbadflags -p tcp --tcp-flags ALL NONE -j ldtcpbf $IP6T -A tcpbadflags -p tcp --tcp-flags SYN,FIN SYN,FIN -j ldtcpbf $IP6T -A tcpbadflags -p tcp --tcp-flags SYN,RST SYN,RST -j ldtcpbf $IP6T -A tcpbadflags -p tcp --tcp-flags FIN,RST FIN,RST -j ldtcpbf $IP6T -A tcpbadflags -p tcp --tcp-flags ACK,FIN FIN -j ldtcpbf $IP6T -A tcpbadflags -p tcp --tcp-flags ACK,PSH PSH -j ldtcpbf $IP6T -A tcpbadflags -p tcp --tcp-flags ACK,URG URG -j ldtcpbf $IP6T -A tcpbadflags -j RETURN $IP6T -A ldtcpbf -m limit --limit 5/s \ -j LOG $LOGOPT --log-prefix "ldtcpbf {TCP BadFlags}: " $IP6T -A ldtcpbf -j DROP 40

47 inb_srv realiza a separação do tráfego destinado à rede central de servidores, encaminhando a avaliação para as chain que tratam dos pedidos DNS, dos acessos Web e . São também aqui aceites os acessos ao repositório de software livre sobre RSYNC e aos servidores RADIUS usados na validação por entidades externas dos acessos eduroam dos nossos utilizadores. $IP6T -A inb_srv -d 2001:690:2008::100:1000/116 -j inb_dns # DNS CORE $IP6T -A inb_srv -d 2001:690:2008::101:1000/116 -j inb_dns # DNS CORE $IP6T -A inb_srv -p tcp -d 2001:690:2008::100:5000/120 -m multiport \ --destination-ports 80,443 -j ACCEPT # Webs CORE $IP6T -A inb_srv -p tcp -d 2001:690:2008::101:5000/120 -m multiport \ --destination-ports 80,443 -j ACCEPT # Webs CORE $IP6T -A inb_srv -p tcp -d 2001:690:2008::100:2000/116 -j inb_mail $IP6T -A inb_srv -p tcp -d 2001:690:2008::100:500D --dport 873 -j ACCEPT # RSYNC Mirrors $IP6T -A inb_srv -p udp -d 2001:690:2008::100:3000/116 \ --dport 1812:1813 -j ACCEPT # RADIUS custom_logdrop_chain_fn inb_srv "" "END" Por existirem no interior da rede servidores DNS desempenhando papéis distintos, são realizadas validações adicionais incluindo os endereços e portos. Para minimizar o incómodo desnecessário causado pela persistência dos parâmetros de DNS em alguns sistemas operativos, é aceite o acesso aos servidores forwarder para máquinas que se estime estarem localizadas em redes próximas (em instituições congéneres de ensino superior). Esta heurística é realizada analisando o valor de hoplimit com que os pedidos chegam, assumindo que na origem terão o valor de 64 ou 128. Também é aceite nestas condições o tráfego originado no bloco de endereçamento usado pela maioria das instituições ligadas à rede nacional (RCTS) do ensino superior e I&D. $IP6T -A inb_dns -p udp -d 2001:690:2008::100:1000/118 --dport 53 -j ACCEPT # ns1, rns1 $IP6T -A inb_dns -p udp -d 2001:690:2008::101:1000/118 --dport 53 -j ACCEPT # ns2, rns2 $IP6T -A inb_dns -p udp -d 2001:690:2008::100:1400/120 --dport 53 \ -m hl --hl-gt 120 -m hl --hl-lt 128 -j ACCEPT # fns1, fns3 $IP6T -A inb_dns -p udp -d 2001:690:2008::101:1400/120 --dport 53 \ -m hl --hl-gt 120 -m hl --hl-lt 128 -j ACCEPT # fns2 $IP6T -A inb_dns -p udp -d 2001:690:2008::100:1400/120 --dport 53 \ -m hl --hl-gt 56 -m hl --hl-lt 64 -j ACCEPT # fns1, fns3 $IP6T -A inb_dns -p udp -d 2001:690:2008::101:1400/120 --dport 53 \ -m hl --hl-gt 56 -m hl --hl-lt 64 -j ACCEPT # fns2 $IP6T -A inb_dns -p udp -d 2001:690:2008::100:1400/120 --dport 53 \ -m limit --limit 1/s -j REJECT --reject-with adm-prohibited $IP6T -A inb_dns -p udp -d 2001:690:2008::101:1400/120 --dport 53 \ -m limit --limit 1/s -j REJECT --reject-with adm-prohibited $IP6T -A inb_dns -p udp -d 2001:690:2008::100:1400/120 --dport 53 -j DROP $IP6T -A inb_dns -p udp -d 2001:690:2008::101:1400/120 --dport 53 -j DROP $IP6T -A inb_dns -p tcp -s 2001:690::/32 -d 2001:690:2008::100:1000/118 \ --dport 53 -j ACCEPT $IP6T -A inb_dns -p tcp -s 2001:690:2009::/48 -d fec0:0:0:ffff::/126 \ --dport 53 -j ACCEPT custom_logdrop_chain_fn inb_dns "" "END" Em inb_mail, consoante o endereço e portos destino são aceites os pacotes associados aos diferentes protocolos que compõem o serviço. $IP6T -A inb_mail -p tcp -d 2001:690:2008::100:2000/120 --dport 25 -j ACCEPT # SMTP $IP6T -A inb_mail -p tcp -d 2001:690:2008::100:2100/120 --dport 465 -j ACCEPT # SMTP $IP6T -A inb_mail -p tcp -d 2001:690:2008::100:2100/120 --dport 587 -j ACCEPT # SMTPSubm $IP6T -A inb_mail -p tcp -d 2001:690:2008::100:2400/120 --dport 110 -j ACCEPT # POP3 $IP6T -A inb_mail -p tcp -d 2001:690:2008::100:2400/120 --dport 995 -j ACCEPT # SPOP3 $IP6T -A inb_mail -p tcp -d 2001:690:2008::100:2400/119 --dport 143 -j ACCEPT # IMAP4 $IP6T -A inb_mail -p tcp -d 2001:690:2008::100:2400/119 --dport 993 -j ACCEPT # SIMAP3 $IP6T -A inb_mail -p tcp -d 2001:690:2008::100:2400/119 --dport j ACCEPT # SieveMg custom_logdrop_chain_fn inb_mail "" "END" Para a rede de alojamento, os acessos aos portos que estão genericamente abertos para este serviço são aceites numa regra usando a validação multi-porto, adicionalmente são aceites as situações de servidores específicos com protocolos adicionais em funcionamento e que tenham acesso exterior. $IP6T -A inb_hosting -p tcp -m multiport \ --destination-ports 80,443,40022, j ACCEPT $IP6T -A inb_hosting -p tcp -d 2001:690:2008:e120::100: dport 21 -j ACCEPT # FTP $IP6T -A inb_hosting -p tcp -d 2001:690:2008:e120::100:5250 \ --dport $PASVRANGE -j ACCEPT # FTPS $IP6T -A inb_hosting -p tcp -d 2001:690:2008:e120::100:5019 -m multiport \ --destination-ports 8000, j ACCEPT # NRISEL custom_logdrop_chain_fn inb_hosting "" "END" 41

48 Para o bloco atribuído ao ISEL só se encontra actualmente disponível o serviço de DNS sobre IPv6. $IP6T -A inb_isel -p udp -d 2001:0690:2008:df00::100 --dport 53 -j ACCEPT # DNS ISEL custom_logdrop_chain_fn inb_isel "" "END" A saída de IPv6 para o exterior, tal como no IPv4 é relativamente simples, é negada a saída de tráfego que não tenha um endereço do bloco oficialmente atribuído ao IPL, o mesmo é feito ao tráfego destinado aos blocos de scope limitado que não possam transitar na Internet. São aceites sem condições os pacotes destinados aos equipamentos que usem o endereçamento do IPL na zona limítrofe entre o firewall e a Internet, o tráfego ICMPv6 é remetido para a chain outb_icmp que se limita a aceitar os pedidos ECHO-REQUEST com limitação de ritmo e a descartar com registo o restante. Para a Internet é aceite somente tráfego destinado ao bloco Global Unicast actualmente atribuído. custom_logdrop_chain_fn outbound "! -s $IPLNET6" "Not IPLNet" $IP6T -A outbound -d FEC0::/10 -j DROP # SiteLocal $IP6T -A outbound -d FC00::/7 -j DROP # UniqueLocal $IP6T -A outbound -d $IPLNET6 -j ACCEPT # Enderecos nossos fora $IP6T -A outbound -p icmpv6 -j outb_icmp $IP6T -A outbound -d 2000::/3 -j ACCEPT # Global Unicast custom_logdrop_chain_fn outbound "" "END" $IP6T -A outb_icmp -p icmpv6 --icmpv6-type echo-request -m limit --limit 100/s -j ACCEPT custom_logdrop_chain_fn outb_icmp "" "ICMP Flood" Boas práticas em listas de acesso Na elaboração de um sistema desta natureza é de todo conveniente a aplicação de diversas regras de boas práticas e de optimização do processamento. Dentro do possível deve-se conhecer o processamento envolvido nas operações a realizar, frequentemente existem diversas alternativas para a solução de cada requisito, há que ter a mínima noção do peso computacional de cada uma para que se possa optar. Algumas regras genéricas a seguir, dentro do possível: Conhecer a implementação do avaliador; As regras muito usadas não devem gerar registos; Gerar registos das situações inesperadas; Terminar as chain com regras que realizem o registo das situações não contempladas anteriormente; Analisar periodicamente os registos gerados, de preferência com o apoio de ferramentas que automatizem o processo na identificação de padrões de ocorrências; As regras que neguem tráfego devem ser tão genéricas quanto possível; As regras que aceitem tráfego devem ser tão específicas quanto possível. Optimizar listas e chains Juntar regras que sejam agregáveis, por exemplo referentes a blocos de endereçamento contíguos; Mover para o início das chains/árvore as regras que lidem com mais tráfego, que sejam mais simples ou que evoquem somente validações de camadas inferiores; Aceitar o tráfego de ligações previamente aceites (ESTABLISHED) nas primeiras avaliações; Evitar que listas temporárias (ex. recent) lidem com muitos identificadores distintos (endereços, portos e outros) que as faça crescer em dimensão; Analisar periodicamente os contadores de pacotes processados pelas regras e identificar regras não usadas ou que estão na sombra de outras (que são casos particulares de outras anteriores mais genéricas). 42

49 Reordenação de regras Há que garantir que o resultado final da avaliação se mantém, para não se alterar o comportamento originalmente pretendido. Podem-se trocar regras consecutivas cuja acção seja igual; podem-se trocar regras que não se intersectem no universo de valores que as tornam verdadeiras. Esta tarefa nem sempre tem resultados visíveis, frequentemente optimizadores e compiladores de baixo nível conseguem melhores resultados que o nosso esforço de reordenação. Alterações que aparentemente optimizariam resultam no inverso ou, não têm impacto notável no desempenho do sistema Monitorização e desempenho Para manutenção um registo histórico e consulta diária de diversos índices sobre o funcionamento do sistema foi usado o software Monitorix [18]. Consultando como amostra os gráficos actuais referentes ao registo dos sete dias anteriores é possível a extracção de algumas conclusões. Figura 15 - Carga de processamento (Itchy) O firewall que lida com o tráfego IPv4 (Itchy) teve picos de cerca de CPU de cerca de 28% (Figura 15) estando nessa altura a lidar com cerca de 325Mbit/s (Figura 16). Assumindo a linearidade da relação, cada 12Mbit/s exigiriam 1% da CPU actual sendo que no limite da capacidade o sistema conseguiria processar 1,2Gbit/s. Figura 16 - Tráfego de rede na porta de rede «inside» (Itchy) Este cálculo rápido sofre obviamente de precisão. Este sistema está a processar fundamentalmente dois tipos diferentes de tráfego, o que é simplesmente encaminhado e o que é sujeito a manipulações de alteração de endereços e portos (NAT), sendo que este segundo consome mais recursos. Como mencionado anteriormente, o sistema está a utilizar um módulo que varia dinamicamente a frequência de relógio da CPU pelo que ocorrerá também um factor de compressão deixando portanto a relação de ser linear. 43

50 A conclusão essencial que daqui se extrai é que dificilmente este sistema conseguirá lidar com o limite da capacidade das placas rede de 10Gbit/s pelo que se justifica a actualização de harware para a exploração de toda essa capacidade. Figura 17 - Precisão do relógio Um aspecto importante, para sistemas cujos registos poderão desempenhar um papel crucial na análise de abusos diversos que até podem ter implicações legais é a precisão do relógio de sistema de forma a assegurar a validade da datação dos registos de eventos. Conforme se pode observar na Figura 17, com o uso da sincronização de relógio em rede é possível assegurar desvios bastante reduzidos, não tendo no período de amostra ocorrido desvios superiores a 16ms. Figura 18 - Uso de interrupts pelo hardware (Itchy) As principais fontes de interrupções (interrupts) de processamento são obviamente as placas de rede que lidam com mais tráfego, de notar aqui a influência de se estarem a usar MSI das quais as placas de 10Gbit/s tiram partido atribuindo interrupts distintos a diversas das duas tarefas. Apesar de aqui não se incluir o detalhe do tratamento destes pedidos distribuído pelos dois core das CPU, este confirmou-se se bastante equilibrado, no entanto, seguindo as recomendações da ESnet [11], Figura 19 - Alocação de memória (Itchy) 44