Relatório apresentado para a prova de Especialista de

Transcrição

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
Departa men to de Sis temas de Informação e Comunicações
I ns tituto Politécnico de Lis boa
(pribeiro@net .ipl. pt)
Área Departa men tal de En gen haria de Electrónica e Telecomunicações e de Computadores
I ns titu to Superior de Eng enharia de Lis boa
(pribeiro@deetc. isel. ipl. pt )
i
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
Índice
1. Antecedentes e Motivação ......................................................................................................................................... 1
2. O projecto netfilter.org ................................................................................................................................................ 3
Características principais ..................................................................................................................................... 3
Origens do netfilter................................................................................................................................................. 3
2.1. Arquitectura ........................................................................................................................................................... 3
Tabelas ........................................................................................................................................................................ 3
Chains.......................................................................................................................................................................... 3
Pontos de intercepção (chains base) ................................................................................................................ 5
Regras.......................................................................................................................................................................... 5
Acções possíveis ...................................................................................................................................................... 5
2.2. Aplicações de gestão e manutenção............................................................................................................... 6
2.3. Módulos de validação especializados ............................................................................................................ 7
2.4. Tráfego não sujeito ao netfilter........................................................................................................................ 8
2.5. Módulo de manutenção de estado conntrack ............................................................................................. 8
Estados segundo o conntrack.............................................................................................................................. 8
Actualização de estados ........................................................................................................................................ 9
Modulos de apoio (helper)............................................................................................................................... 9
2.6. Network Address Translation - NAT .............................................................................................................. 9
2.6.1.
Particularidades do funcionamento da tabela nat ...................................................................... 9
Modulos de apoio (helper) ao NAT ............................................................................................................ 10
NAT de mensagens de erro ICMP ................................................................................................................... 10
2.6.2.
netfilter segundo o STUN (Session Transversal Utilities for NAT) ....................................... 11
2.6.3.
NAT usando DNETMAP ....................................................................................................................... 11
Quando devidamente parametrizado: .......................................................................................................... 11
2.7. Extensibilidade................................................................................................................................................... 12
3. Implementação do sistema ..................................................................................................................................... 13
3.1. Evolução da topologia para o novo sistema.............................................................................................. 13
3.2. Hardware e sistema Linux de base .............................................................................................................. 14
3.3. Sistema operativo.............................................................................................................................................. 14
3.3.1.
Optimizações do núcleo (kernel) .................................................................................................... 15
3.3.2.
Optimização de parâmetros de sistema ........................................................................................ 15
Interrupts................................................................................................................................................................ 15
Memória .................................................................................................................................................................. 15
Gestão de energia ................................................................................................................................................. 16
3.4. Armazenamento de sistema e dados .......................................................................................................... 16
Sistemas de ficheiros........................................................................................................................................... 17
iii
3.5. Conectividade ..................................................................................................................................................... 17
Encaminhamento de tráfego IPv4/IPv6 ....................................................................................................... 18
3.6. Tratamento dos eventos de sistema............................................................................................................ 19
Ficheiros e directorias envolvidos .................................................................................................................. 19
3.7. Gestão do netfilter no sistema ...................................................................................................................... 19
Actualização de tabelas ...................................................................................................................................... 20
Actualização de regras ........................................................................................................................................ 20
Ficheiros de suporte ............................................................................................................................................ 21
3.8. Endereçamento e uso de NAT ....................................................................................................................... 22
Planos de endereçamento ................................................................................................................................. 22
3.9. Estrutura base das chain utilizadas ......................................................................................................... 23
Variáveis BASH definidas em IN4Fw.sh para utilização nos scripts ................................................ 24
3.9.1.
Chains de filtragem em IPv4 para INPUT e OUTPUT............................................................. 25
3.9.2.
Chains de filtragem em IPv4 para FORWARD .......................................................................... 27
3.9.3.
Chains de NAT em IPv4.................................................................................................................... 35
3.9.4.
Chains em IPv6 ................................................................................................................................... 37
Variáveis BASH definidas em IN6Fw.sh para utilização nos scripts ................................................ 37
3.9.5.
Chains de filtragem em IPv6 para INPUT e OUTPUT ........................................................... 38
3.9.6.
Chains de filtragem em IPv6 para FORWARDING................................................................... 39
3.10. Boas práticas em listas de acesso.............................................................................................................. 42
Optimizar listas e chains ................................................................................................................................ 42
Reordenação de regras ....................................................................................................................................... 43
3.11. Monitorização e desempenho .................................................................................................................... 43
3.12. Usos paralelos para o sistema .................................................................................................................... 46
3.13. Evoluções futuras do sistema ..................................................................................................................... 46
Conectividade plena a 10Gbit/s ...................................................................................................................... 46
Elevada disponibilidade na transição activo/backup .............................................................................. 46
Encaminhamento de IP Multicast ................................................................................................................... 46
Aplicação de QoS .................................................................................................................................................. 46
4. Referências e Bibliografia ....................................................................................................................................... 47
iv
Í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 .................. 13
Figura 4 - O sistema netfilter colocado em linha com o FWSM durante os testes ...................................... 13
Figura 5 - Estrutura final, após estabilizada a solução e removido o FWSM .............................................. 14
Figura 6 - PC ASUS RS120-E3/PA4 ........................................................................................................................... 14
Figura 7 - Estrutura de partições nos discos rígidos .......................................................................................... 17
Figura 8 - Interligação redundante do sistema aos switch ............................................................................... 18
Figura 9 - Percursos de tráfego IPv4 e IPv6........................................................................................................... 19
Figura 10 - Exemplo de plano de endereçamento IPv4 ..................................................................................... 23
Figura 11 - Chains de INPUT e OUTPUT da tabela filter de IPv4 ......................................................... 27
Figura 12 – Chains de filtragem do tráfego em FORWARD............................................................................... 35
Figura 13 - Chains de nat em IPv4 ............................................................................................................................ 37
Figura 14 - Chains de filtragem para IPv6 .......................................................................................................... 39
Figura 15 - Carga de processamento (Itchy) ......................................................................................................... 43
Figura 16 - Tráfego de rede na porta de rede «inside» (Itchy) ....................................................................... 43
Figura 17 - Precisão do relógio .................................................................................................................................. 44
Figura 18 - Uso de interrupts pelo hardware (Itchy) ......................................................................................... 44
Figura 19 - Alocação de memória (Itchy)............................................................................................................... 44
Figura 20 - Carga de processamento (Scratchy) .................................................................................................. 45
Figura 21 - Tráfego na porta de rede «inside» (Scratchy) ................................................................................ 45
v
vi
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/eduroam1 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: http://www.eduroam.org/
1
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
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.
2.1. 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
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 ROUTING
+ PDBB
INPUT
mangle
nat
filter
FORWARD
mangle
filter
Local Process
OUTPUT ROUTING
OUTPUT ROUTING
POSTROUTING
OUTPUT
mangle
conntrack
nat
mangle
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
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
1
2
3
POSTROUTING
1
2
INPUT
1
2
3
OUTPUT
1
2
3
4
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
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, 512-1023 e
1024-655362. 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.
2.2. 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
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 IPv6.
2.3. 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
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.
2.5. 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
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.
2.6. Network Address Translation - NAT
2.6.1. 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 www.ipl.pt 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
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
2.6.2. 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.
2.6.3. 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/RFC5389
11
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 30000 (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.
2.7. 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
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
C7206
C7206
ALADDIN
ALADDIN
Cat6500
Cat6500
HULK
HULK
FWSM
FCCN/Internet
FCCN/Internet
CORE/Redes
CORE/Redes IPL
IPL
IPv6
Cat4500
Cat4500
STINGRAY
STINGRAY
C7206
C7206
GADGET
GADGET
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
C7206
C7206
ALADDIN
ALADDIN
FCCN/Internet
FCCN/Internet
PC/PentiumD
PC/PentiumD
ITCHY
ITCHY
Cat6500
Cat6500
HULK
HULK
FWSM
CORE/Redes
CORE/Redes IPL
IPL
IPv6
C7206
C7206
GADGET
GADGET
Cat4500
Cat4500
STINGRAY
STINGRAY
Figura 4 - O sistema netfilter colocado em linha com o FWSM durante os testes
13
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
C7206
C7206
ALADDIN
ALADDIN
FCCN/Internet
FCCN/Internet
C7206
C7206
GADGET
GADGET
VLAN6
PC/PentiumD
PC/PentiumD
ITCHY
ITCHY
PC/PentiumD
PC/PentiumD
SCRATCHY
SCRATCHY
Cat6500
Cat6500
HULK
HULK
CORE/Redes
CORE/Redes IPL
IPL
Cat4500
Cat4500
STINGRAY
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/PA4
3.3. 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 Gentoo4 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: https://www.gentoo.org/
14
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.
3.3.1. 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.
3.3.2. 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
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.
3.4. 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
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.
swap
swap
system
system
Partições
data
data
128MiB
(RAID1)
512MiB
15GiB
(RAID1)
220GiB
(RAID1)
234GiB
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.
EXT2
SWAP
EXT3
EXT4
EXT4
HDD 250GB
HDD 500GB
boot
boot
Capacidade
Formato
single
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.
3.5. 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
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
Switch 1K11
1K11
GALACTUS
GALACTUS
Gi0/6
Switch
Switch
HULK
HULK
Te0/9
eth3
eth2
eth1
eth0
Te1/5
Gi3/25
ITCHY
ITCHY
Ainda sem ligação
Porta de 10Gbit/s
indisponivel
Gi1/0/13
Gi0/13
Switch
Switch 1K10
1K10
OUTSIDE
eth3
eth0
eth1
eth2
Switch
Switch
1I1
1I1
Te1/1
SCRATCHY
SCRATCHY
Switch
Switch
TERRI
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
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 IPv6
2
4
C7206
ALADDIN
1
3
Cat6500
HULK
PC/PentiumD
ITCHY
FCCN/Internet
4
2
C7206
GADGET
CORE/Redes IPL
3
1
PC/PentiumD
SCRATCHY
Cat4500
STINGRAY
Figura 9 - Percursos de tráfego IPv4 e IPv6
3.6. Tratamento dos eventos de sistema
Todos os eventos de sistema que são reportados através de SYSLOG5 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
RFC5424
19
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
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
RSYNC6) dos ficheiros existentes no outro servidor.

old/ - Pasta contendo o arquivo de versões
Em /etc/fw6
6

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
RSYNC: http://rsync.samba.org/
21
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 10.0.0.0/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
Tipo
Bloco base
Sub-Blocos
193.137.220.0/25
193.137.220.128/27
193.137.220.160/27
193.137.220.0/23
193.137.220.192/27
193.137.220.224/27
193.137.221.0/24
193.137.237.0/24
PA
193.137.100.0/24
193.137.128.0/24
193.137.129.0/24
193.137.130.0/25
193.137.130.128/25
193.137.128.0/22 193.137.131.0/26
193.137.131.64/26
193.137.131.128/26
193.137.131.192/27
193.137.131.224/27
192.104.48.0/25
192.104.48.128/28
192.104.48.0/24 192.104.48.192/27
192.104.48.224/28
PI
192.104.48.240/28
192.68.221.0/30
192.68.221.0/24 192.68.221.128/28
192.68.221.240/28
Função
Servidores centrais do polo do ISEL
NAT
Servidores centrais do polo de Benfica
Conectividade especial (ex. Videoconferencia)
Loopbacks dos routers (RID)
Ligações entre routers ponto a ponto e troços de transito
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
servidores web das escolas e serviços)
Roamers e-U - Polo ISEL
Roamers e-U - Polo Benfica
Roamers e-U - Polo ISCAL
Roamers e-U - Polo ESTeSL
Roamers e-U - Polo ESTC
Roamers e-U - Polo ESM
Roamers e-U - Polo ESD
Roamers e-U - Polo RDC
Tuneis GRE de encaminhamento e-U roamers
Servidores centrais
NAT Outbound
NAT Inbound
NAT Inbound
Concentradores VPN
Testes de conectividade
NAT Outbound
Concentradores VPN
Figura 10 - Exemplo de plano de endereçamento IPv4
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.
3.9. Estrutura base das chain utilizadas
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 224.0.0.0/4).
$IPT7 -t raw -A PREROUTING -d 224.0.0.0/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
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 userspace8 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 193.137.220.18/31 -j DROP # Com o DNS memorizado mas fora
$IPT -A dropids -p udp -d 193.137.220.20 -j DROP # Com o DNS memorizado mas fora
$IPT -A dropids -j pcaplog
$IPT -A dropids -p udp -d 193.137.220.224 --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="193.137.220.0/23"
NETPA2="193.137.237.0/24"
NETPA3="193.137.100.0/24"
NETPA4="194.210.192.0/20"
NETEU1="193.137.128.0/22"
NETPI1="192.104.48.0/24"
NETPI2="192.68.221.0/24"
NETPRV1="10.0.0.0/8"
NETPA1a="193.137.220.0/24"
NETPA1b="193.137.221.0/24"
NETPREFW="193.137.237.128/25"
NETADM="10.100.254.0/23"
NETCOREPRIV="10.4.0.0/24"
8
ULOGD: http://rlworkman.net/howtos/ulogd.html
24
NETVPNBON="193.137.131.0/27"
# NAT
IPNATOVLPI="192.68.221.255"
IPNATOVLPA="193.137.220.255"
IPNATOVL="193.137.221.240"
#
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' | \
${GREP} '^[0-9]\+$' | ${SORT} -n | ${UNIQ} | \
RPCPORTST=`/sbin/rpcinfo -p | ${GREP} -E '\btcp\b' | \
${GREP} '^[0-9]\+$' | ${SORT} -n | ${UNIQ} | \
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"
3.9.1. 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
$IPT
$IPT
$IPT
-A
-A
-A
-A
base_in
base_in
base_in
base_in
-m
-m
-i
-m
conntrack --ctstate INVALID -j DROP
conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
lo -m conntrack --ctstate NEW -j ACCEPT
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
$IPT -A base_in -p tcp -s $NETPA1 -m multiport \
$IPT -A base_in -p tcp -s $NETCOREPRIV -m multiport \
$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 \
$IPT -A base_in -p udp -s $NETCOREPRIV -m multiport \
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 :1023 --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 (OVERCR9) 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
É também aceite sem condições adicionais as ligações ao porto 5001 que é usado esporadicamente
em testes de desempenho usando a aplicação IPERF10.
$IPT -A base_in -p tcp --dport 5001 --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
$IPT
$IPT
$IPT
$IPT
$IPT
$IPT
$IPT
-A
-A
-A
-A
-A
-A
-A
-A
ospfin
ospfin
ospfin
ospfin
ospfin
ospfin
ospfin
ospfin
-s
-s
-s
-s
-s
-s
-s
-s
$NETPREFW -d 224.0.0.5 -j ACCEPT
$NETPA1b -d 224.0.0.5 -j ACCEPT
$NETPREFW -d 224.0.0.6 -j ACCEPT
$NETPA1b -d 224.0.0.6 -j ACCEPT
$NETPA1 -d $NETPA1b -j ACCEPT
$NETPA1 -d $NETPREFW -j ACCEPT
$NETPREFW -d $NETPA1b -j ACCEPT
$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
$IPT
$IPT
$IPT
$IPT
9
-A
-A
-A
-A
-A
mgmtnets
mgmtnets
mgmtnets
mgmtnets
mgmtnets
-s
-s
-s
-s
-j
$NETPA1 -j ACCEPT
$NETPI1 -j ACCEPT
$NETADM -j ACCEPT
$NETPREFW -j ACCEPT
RETURN
Usado pela monitorização NAGIOS: http://www.nagios.org/
iperf em: https://github.com/esnet/iperf
10
26
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
$IPT
$IPT
$IPT
$IPT
-A
-A
-A
-A
-A
base_out
base_out
base_out
base_out
base_out
-o
-p
-p
-p
-j
lo -j ACCEPT
tcp ! --sport $EPRANGE --syn -j LOG --log-prefix "EPRange violation! TCP: "
icmp -j icmpout
ospf -j ACCEPT
ACCEPT
A icmpout irá restringir o ritmo do ICMP excepto para mensagens ECHO, TIMESTAMP e TIMEEXCEEDED, 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 11 11 representa de forma resumida a estrutura das chain acima mencionadas
Figura 11 - Chains de INPUT e OUTPUT da tabela filter de IPv4
3.9.2. 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.
Imagem gerada a partir da ferramenta iptables2dot [29], tal como as restantes representando as árvores
de decisão netfilter
11
27
$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 :1023 --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 loopback12 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 127.0.0.0/8
28
$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 192.104.48.24/30 --dport 5060 -j ACCEPT # SIP
$IPT -A inb_core_tcp -p tcp -d 192.104.48.8/31 --dport 25 -j ACCEPT
# SMTP
# SMTP
# SSMTP Submit
$IPT -A inb_core_tcp -p tcp -d 193.137.220.15 --dport 465 -j ACCEPT
# SSMTP3 Submit
# SMTP Submit
$IPT -A inb_core_tcp -p tcp -d 193.137.220.15 --dport 587 -j ACCEPT
# SMTP3 Submit
$IPT -A inb_core_tcp -p tcp -d 192.104.48.12/31 -m multiport \
--destination-ports 110,995,143,993,4190 -j ACCEPT # POP3,SPOP3,IMAP4,SIMAP4,SIEVEMGR
# WebsHTTP
# WebsHTTPS
$IPT -A inb_core_tcp -p tcp -d 192.104.48.75 -m multiport \
--destination-ports 80,554,1755 -j ACCEPT
# Webcast HTTP,RTSP,MMST
# Webs
$IPT -A inb_core_tcp -p tcp --dport 5001 -j ACCEPT
# IPerf
$IPT -A inb_core_tcp -p tcp -d 193.137.220.1 --dport 53 -j inb_core_dns_xfer # DNS XFER
$IPT -A inb_core_tcp -p tcp -d 192.104.48.18/31 --dport 53 -j DROP
# DNS XFER s/ LOG
$IPT -A inb_core_tcp -p tcp -d 193.137.220.18/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 e-mail 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
--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
$IPT
$IPT
$IPT
$IPT
$IPT
$IPT
$IPT
-A
-A
-A
-A
-A
-A
-A
-A
inb_core_udp -p udp --dport 53 -j inb_core_dns
inb_core_udp -d 192.104.48.24/30 -j inb_core_sip
inb_core_udp -p udp -d 192.104.48.28/31 --dport 3478:3479 -j ACCEPT # STUN1/2
inb_core_udp -d 192.104.48.112/31 -j inb_core_radius
inb_core_udp -p udp -d 193.137.220.55 --dport 5004 -j ACCEPT
# Webcast RTSPU
# Webcast RTSPU
# Webcast MMSU
inb_core_udp -p udp -s $NETEU1 -d 193.137.220.2/255.255.255.251 \
--sport 67:68 --dport 67 -j ACCEPT
# eduroam DHCP
$IPT -A inb_core_udp -p udp --sport 1024: --dport 5001 -j ACCEPT
# IPerf
$IPT -A inb_core_udp -p udp --sport 1024: --dport 33434:33499 -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 192.104.48.28/31 \
--sport 3478:3479 --dport 1024: -j ACCEPT
# STUN
$IPT -A outb_core_udp -p udp --dport 6277 -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 123 --dport 123 -j ACCEPT # NTP
$IPT -A outb_core_udp -p udp --sport 1024: --dport 33434:33499 -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
-m limit --limit 100/s --limit-burst 1000 -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 193.137.220.246 -s 195.23.253.211 -j ACCEPT
custom_logdrop_chain_fn inb_core_gre "" "END"
# HULK2ISCAL2
$IPT -A outb_core_gre -s 193.137.220.246 -d 195.23.253.211 -j ACCEPT
custom_logdrop_chain_fn outb_core_gre "" "END"
# HULK2ISCAL2
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 e-mail para o exterior.
$IPT -A outb_smtp -s 192.104.48.14/31 -j ACCEPT
$IPT -A outb_smtp -s 192.104.48.90 -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
$IPT -A inb_core_dns -s
$IPT -A inb_core_dns -s
custom_logdrop_chain_fn
193.137.220.1 -j ACCEPT
193.137.220.12 -j ACCEPT
192.104.48.16/31 -j ACCEPT
192.104.48.20/31 -j ACCEPT
$NETEU1 -d 193.137.220.18/31 -j ACCEPT
$NETEU1 -d 193.137.220.20 -j ACCEPT
192.104.48.18/31 -j DROP
193.137.220.18/31 -j DROP
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 194.210.30.212 -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
scanner --from 100 --to
udp --sport 30000:30100 --dport 1024: -j ACCEPT # RTP
udp --sport 1024: --dport 30000:30100 -j ACCEPT # RTP
udp --sport 5060 --dport 1024: -j ACCEPT
# RTP
inb_core_sip "-p udp --dport 5060 -m string --algo bm --string friendly250" "SIP SCAN"
udp --sport 1024: --dport 5060 -j ACCEPT
# SIP
inb_core_sip "" "END"
31
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.
$IPT -A inb_core_radius
$IPT -A inb_core_radius
inb_core_radius "! -s 193.136.192.0/24" "Not FCCN"
-p udp --sport 1024: --dport 1812:1813 -j ACCEPT
-p udp --sport 1812:1813 --dport 1647 -j ACCEPT
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 193.137.221.248/29 --dport 1723 -j ACCEPT # PPTP VPN
tcp -d 193.137.221.243 --dport 1723 -j ACCEPT
# PPTP VoIPRCTS
tcp -d 193.137.221.9 --dport 1723 -j ACCEPT
# PPTP VPN
inb_backbone "" "END"
$IPT -A outb_backbone -p udp --sport 123 --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 43389 e 40022 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
$IPT
$IPT
$IPT
$IPT
$IPT
$IPT
$IPT
-A
-A
-A
-A
-A
-A
-A
-A
inb_webs -p tcp --dport 80 -j ACCEPT
# HTTP
# HTTPS
inb_webs -p tcp --dport 8080 -j ACCEPT # HTTPAlt
inb_webs -p tcp --dport 43389 -j LOG --log-prefix "inb_webs {RDCAlt}: " # RDCAlt
# RDCAlt
inb_webs -p tcp --dport 40022 -j LOG --log-prefix "inb_webs {SSHAlt}: " # SSHAlt
# SSHAlt
inb_webs -p tcp -d 192.68.221.227 -m multiport \
--destination-ports 41112,8000 -j ACCEPT
# HAM Misc
$IPT -A inb_webs -p tcp -d 192.68.221.36 --dport 5000:5020 -j ACCEPT
$IPT -A inb_webs -p tcp -d 192.68.221.40 -m multiport \
$IPT -A inb_webs -p tcp -d 192.68.221.248/31 -m multiport \
--destination-ports 1935,5080,9000 -j ACCEPT
$IPT -A inb_webs -p tcp -d 192.68.221.250 --dport 21 -j ACCEPT
# FTPS SDWSites
$IPT -A inb_webs -p tcp -d 192.68.221.250 --dport $PASVRANGE -j ACCEPT # FTPS PASSIVE & TLS
$IPT -A inb_webs -p tcp -d 192.68.221.51 --dport 21 -j ACCEPT
# FTP ISEL
custom_logdrop_chain_fn inb_webs "" "END"
$IPT -A outb_webs -p tcp -s 192.68.221.36 --dport 5000:5020 -j ACCEPT
$IPT -A outb_webs -p tcp -s 192.68.221.40 -m multiport \
--destination-ports 443,1144,1433,8000,8001,8002,8003,8004,8005,8006 \
-j ACCEPT
$IPT -A outb_webs -p tcp -s 192.68.221.227 -m multiport \
--destination-ports 41112,8000,7373,7300 -j ACCEPT
$IPT -A outb_webs -p tcp -s 192.68.221.250 --sport 20 --dport 1024: \
-j ACCEPT # FTPS SDWSites
custom_logdrop_chain_fn outb_webs "" "END"
32
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 1720 -j ACCEPT
# H.323 Call Setup
$IPT -A inb_fullip_vc -p udp --dport 5060 -j ACCEPT
# SIP Call Setup
$IPT -A inb_fullip_vc -d 193.137.100.181 -j la_inb_fullip
# G VC SC
# G VC ESCS
# 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 193.137.100.161 -j la_inb_fullip
$IPT -A inb_fullip -d 193.137.100.176/28 -j inb_fullip_vc
$IPT -A inb_fullip -d 193.137.100.224/28 –p tcp -j la_inb_fullip
$IPT -A inb_fullip -d 193.137.100.224/28 –p udp -j la_inb_fullip
$IPT -A inb_fullip -d 193.137.100.224/28 –p icmp -j la_inb_fullip
custom_logdrop_chain_fn inb_fullip "" "END"
#
#
#
#
G VIDEOCONF
ISEL-DIRECTO
ISEL-DIRECTO
ISEL-DIRECTO
$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
$IPT -A outb_fullip -s 193.137.100.161 -j la_outb_fullip
$IPT -A outb_fullip -s 193.137.100.224/28 –p tcp -j la_outb_fullip
$IPT -A outb_fullip -s 193.137.100.224/28 –p udp -j la_outb_fullip
$IPT -A outb_fullip -s 193.137.100.224/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
$IPT
$IPT
$IPT
$IPT
$IPT
-A
-A
-A
-A
-A
-A
inb_nonatip
inb_nonatip
inb_nonatip
inb_nonatip
inb_nonatip
inb_nonatip
-p
-p
-p
-p
-j
-j
tcp --dport 40000:40999 -j ACCEPT
udp --dport 40000:40999 -j ACCEPT
tcp -m ipp2p --bit -j ldinnonatip
udp -m ipp2p --bit -j ldinnonatip
ldinnonatip
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
$IPT
$IPT
$IPT
$IPT
-A
-A
-A
-A
outb_nonatip
outb_nonatip
outb_nonatip
outb_nonatip
-p
-p
-p
-j
tcp --dport 25 -j REJECT --reject-with tcp-reset # SMTP SpeedUp
tcp -m ipp2p --bit -j ldpubp2p
udp -m ipp2p --bit -j ldpubp2p
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
$IPT
$IPT
$IPT
$IPT
$IPT
$IPT
$IPT
$IPT
$IPT
$IPT
$IPT
$IPT
$IPT
$IPT
$IPT
$IPT
$IPT
$IPT
$IPT
$IPT
$IPT
$IPT
$IPT
$IPT
$IPT
$IPT
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
outb_check_hhd -s 10.32.0.0/11 -m ttl --ttl-eq 125 -j RETURN
outb_check_hhd -s 193.137.100.176/28 -m ttl --ttl-eq 125 -j RETURN # GERAL VC
outb_check_hhd -s 193.137.100.224/27 -m ttl --ttl-eq 124 -j RETURN # ISEL SRV
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 10.62.73.102 -j ACCEPT
custom_logdrop_chain_fn inb_vpnbon "" "END"
34
Figura 12 – Chains de filtragem do tráfego em FORWARD
3.9.3. Chains de NAT em IPv4
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 193.137.221.241 -j pre_inb_mapp
$IPT -t nat -A pre_inbound -d 193.137.100.239 -j DNAT --to-destination 10.88.19.1 # VPN
$IPT -t nat -A pre_inbound -j ACCEPT
$IPT -t
-j DNAT
$IPT -t
-j DNAT
$IPT -t
-j DNAT
$IPT -t
nat -A pre_inb_mapp -p tcp --dport 41389 \
--to-destination 10.34.17.101:3389
nat -A pre_inb_mapp -p tcp --dport 49921:49999 \
--to-destination 10.100.255.99
nat -A pre_inb_mapp -p tcp --dport 42389 \
--to-destination 10.4.1.103:43389
nat -A pre_inb_mapp -j ACCEPT
35
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 e-mail 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 10.0.0.0/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 10.0.0.0/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 2.6.3.
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
$IPT
$IPT
$IPT
$IPT
$IPT
$IPT
$IPT
-t
-t
-t
-t
-t
-t
-t
-t
$IPT
$IPT
$IPT
$IPT
$IPT
-t
-t
-t
-t
-t
nat -A post_outbound
-j post_outb_natpool
! -s $NETPRV1 -j post_outb_srv
-d $NETPA1 -j ACCEPT
-d $NETPREFW -j ACCEPT
-p tcp --dport 80 -j post_outb_web
-p tcp --dport 443 -j post_outb_web
-p tcp --dport 8181 -j post_outb_web # FCT
-s 10.0.0.0/13 -j post_outb_serv
-m geoip --dst-cc PT \
-s
-p
-p
-p
-j
10.0.0.0/13 -j ACCEPT # Mais nenhum NAT para servicos
tcp -j post_outb_tcp
udp -j post_outb_udp
icmp --icmp-type echo-request -j post_outb_ping
ACCEPT
$IPT -t nat -A post_outb_srv -p tcp -s 193.137.100.226 --dport 25 \
-j SNAT --to-source 193.137.237.3 # 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:40100 -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
$IPT -t nat -A post_outb_natpool \
-j DNETMAP --prefix 194.210.196.0/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
Figura 13 - Chains de nat em IPv4
3.9.4. Chains em IPv6
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
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"
3.9.5. 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 :1023 --syn" "SYN from lowport"
$IP6T -A base_in -p tcp --dport 22 --syn -j mgmtnets
$IP6T -A base_in -p tcp --dport 873 --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
$IP6T -A icmpout -m limit --limit 1/s -j
custom_logdrop_chain_fn icmpout "" "ICMP
echo-request -j ACCEPT
echo-reply -j ACCEPT
packet-too-big -m limit --limit 1/s -j ACCEPT
ACCEPT
flood"
38
Figura 14 - Chains de filtragem para IPv6
3.9.6. 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
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:33499 -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
$IP6T
$IP6T
$IP6T
$IP6T
$IP6T
$IP6T
$IP6T
-A
-A
-A
-A
-A
-A
-A
-A
tcpbadflags
tcpbadflags
tcpbadflags
tcpbadflags
tcpbadflags
tcpbadflags
tcpbadflags
tcpbadflags
-p
-p
-p
-p
-p
-p
-p
-j
tcp --tcp-flags
tcp --tcp-flags
tcp --tcp-flags
tcp --tcp-flags
tcp --tcp-flags
tcp --tcp-flags
tcp --tcp-flags
RETURN
ALL NONE -j ldtcpbf
SYN,FIN SYN,FIN -j ldtcpbf
SYN,RST SYN,RST -j ldtcpbf
FIN,RST FIN,RST -j ldtcpbf
ACK,FIN FIN -j ldtcpbf
ACK,PSH PSH -j ldtcpbf
ACK,URG URG -j ldtcpbf
$IP6T -A ldtcpbf -m limit --limit 5/s \
-j LOG $LOGOPT --log-prefix "ldtcpbf {TCP BadFlags}: "
$IP6T -A ldtcpbf -j DROP
40
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 e-mail. 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 \
# Webs CORE
$IP6T -A inb_srv -p tcp -d 2001:690:2008::101:5000/120 -m multiport \
# 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
# fns2
# fns1, fns3
# fns2
-m limit --limit 1/s -j REJECT --reject-with adm-prohibited
-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
custom_logdrop_chain_fn inb_mail "" "END"
--dport
--dport
--dport
--dport
--dport
--dport
--dport
--dport
25 -j ACCEPT # SMTP
465 -j ACCEPT # SMTP
587 -j ACCEPT # SMTPSubm
110 -j ACCEPT # POP3
995 -j ACCEPT # SPOP3
143 -j ACCEPT # IMAP4
993 -j ACCEPT # SIMAP3
4190 -j ACCEPT # SieveMg
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,43389 -j ACCEPT
$IP6T -A inb_hosting -p tcp -d 2001:690:2008:e120::100:5250 --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 \
# NRISEL
custom_logdrop_chain_fn inb_hosting "" "END"
41
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"
3.10. 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
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.
3.11. 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
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
assim que possível serão realizados testes criando afinidades estáticas entre as principais fontes de
interrupções e as CPU e avaliando se é significativa a melhoria de desempenho.
Curioso também nesta análise, é o gráfico do uso da memória (Figura 19), exibindo uma forma
dentes-de-serra correspondente provavelmente à manutenção em cache das escritas de registos de
sistema que são realizados e aquando da rotação diária dos ficheiros para arquivo, a memória é
libertada.
Essencial nesta análise, é a conclusão de que a memória não é actualmente um factor limitativo do
desempenho. O grande utilizador da memória (cache de disco) é apenas um uso oportunista e se
esta não estivesse disponível, a degradação de desempenho a que função firewall iria sofrer seria
negligenciável.
Figura 20 - Carga de processamento (Scratchy)
A observação dos gráficos correspondentes à carga de processamento (Figura 20) e tráfego (Figura
21) do sistema Scratchy que lida fundamentalmente com o tráfego de IPv6, também nos permite
atingir algumas conclusões; especialmente comparando estes gráficos com os equivalentes
retirados do sistema gémeo (Itchy) que trata do IPv4.
Nestes temos picos de carga da CPU de aproximadamente 6% durante os quais o tráfego tratado é
de cerca de 90Mbit/s o que nos dá um rácio de 15Mbit/s para cada 1% de CPU o que se
compreende por o IPv6 ter sido especificamente desenhado para dispensar algum processamento
considerado actualmente desnecessário no IPv4 bem como a inexistência das ineficientes funções
de NAT que ocorrem em parte do IPv4.
Figura 21 - Tráfego na porta de rede «inside» (Scratchy)
Globalmente, nas condições actuais, o sistema formado pelas duas máquinas estima-se ter
capacidade para lidar com 2Gbit/s de tráfego.
45
3.12. Usos paralelos para o sistema
Dada a capacidade folgada do sistema e o ponto estratégico que representa perante a rede, este já
foi também utilizado na análise de protocolos, em situações extremas em que não seja possível a
identificação da origem de problemas de conectividade de e para a Internet. Nestas situações foram
utilizadas ferramentas como tcpdump, wireshark/tshark, ngrep e dsniff.
Para apoio a estudos de tráfego e de utilização de redes foram também disponibilizados dados
diversos acerca dos fluxos de dados usando ferramentas como pmacct e nfacct. Obviamente que
por questões de segurança os dados foram exportados com a anonimização de todas as informações
relevantes neste aspecto.
3.13. Evoluções futuras do sistema
Encontram-se previstos para breve diversos desenvolvimentos do sistema. Dada a idade da
instalação base do sistema e o envelhecimento natural do hardware, para assegurar o nível de
estabilidade e capacidade exigido, será realizada uma nova instalação sobre máquinas de maior
capacidade e geração mais recente.
Conectividade plena a 10Gbit/s
Apesar do fornecedor de conectividade (FCCN/RCTS) nos disponibilizar actualmente uma
capacidade de 10Gbit/s+1Gbit/s (ligações base e de reserva) e de grande parte da rede central
suportar a exploração desta capacidade, os routers de fronteira limitam a utilização a
1Gbit/s+1Gbit/s, para ultrapassar esta limitação encontra-se prevista a existência de uma ligação
directa do firewall ao fornecedor, tal implicará a reestruturação das redes em volta deste e a
activação das funcionalidades associadas ao protocolo de encaminhamento BGP necessárias ao
anuncio das redes locais (públicas) ao operador e para selecção do percurso óptimo de saída para a
Internet.
Elevada disponibilidade na transição activo/backup
No pacote das ferramentas de manipulação manual das tabelas de conntrack encontra-se
disponível uma aplicação residente (conntrackd) para a sincronização de tabelas de conntrack
entre máquinas, tal permite que no caso de falha da máquina activa, a máquina de backup possa de
imediato assumir todo o seu tráfego sem a necessidade da instabilidade de alguns segundos para a
construção de estados, situação que em alguns casos irá mesmo obrigar ao reinício de ligações TCP.
À altura da instalação inicial este software não se revelou muito estável daí a opção de não se
utilizar. No decurso da reinstalação do sistema, serão realizados novos testes para verificar se esta
funcionalidade cumpre os requisitos de qualidade para que seja colocado no sistema em produção.
Encaminhamento de IP Multicast
As funções locais associadas ao uso de IP multicast encontram-se activas e em funcionamento quer
em IPv4 (IGMP) quer em IPv6 (ICMP/MLD), no entanto, não existindo actualmente justificação para
o suporte do encaminhamento de tráfego multicast, esta vertente não foi explorada no projecto,
contudo, no processo de preparação dos diferentes componentes, sempre que possível foram
evitados comprometimentos que dificultassem a futura funcionalidade de encaminhamento IP
multicast quando for considerada necessária.
Aplicação de QoS
Apesar de nunca ter sido explorada a funcionalidade neste sistema, encontram-se preparados para
utilização os componentes associados à vertente de qualidade de serviço (QoS), permitindo a
classificação de fluxos e a aplicação de estruturas complexas de filas de espera e de escalonamento.
46
4. Referências e Bibliografia
[1] L.
Balliache,
"Kernel
Packet
Traveling
Diagram,"
[Online].
Available:
http://www.docum.org/docum.org/kptd/. [Accessed 2013].
[2] O.
Andreasson,
"Iptables
Tutorial
1.2.2,"
[Online].
Available:
https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html. [Accessed 2013].
[3] P. Neira Ayuso e R. Gasca, “Demystifying cluster-based fault-tolerant Firewalls,” IEEE Internet
Computing, vol. 13, n.º 6, pp. 31-38, 2009.
[4] tcpdump.org,
“TCPDUMP/LIBPCAP
public
repository,”
[Online].
Available:
http://www.tcpdump.org/. [Acedido em 2014].
[5] Wireshark.org, [Online]. Available: http://www.wireshark.org/.
[6] M.
Kierdelewicz,
“DNETMAP
netfilter
module,”
2012.
[Online].
Available:
http://cat.piasta.pl/dnetmap/. [Acedido em 2014].
[7] Intel, "Improving Network Performance in Multi-Core Systems," 2007. [Online]. Available:
http://www.intel.com/content/dam/doc/white-paper/improving-network-performancein-multi-core-systems-paper.pdf. [Accessed 2013].
[8] Intel, "Intel® 82598 10 Gigabit Ethernet Controller," 2007. [Online]. Available:
http://www.intel.com/content/dam/www/public/us/en/documents/productbriefs/82598-10-gigabit-ethernet-controller-brief.pdf. [Accessed 2013].
[9] Intel, "Reducing Interrupt Latency Through the Use of Message Signaled Interrupts," 01 2009.
[Online].
Available:
http://www.intel.co.kr/content/dam/www/public/us/en/documents/whitepapers/msg-signaled-interrupts-paper.pdf. [Accessed 2013].
[10] Emulex, "MSI and MSI-X: New Interrupt Handling Improves System Performance ...," [Online].
Available:
http://www.emulex.com/artifacts/2f88b2af-b1cb-436e-bef57c43fec5bebe/msi-hp.pdf. [Accessed 2013].
[11] ESnet; Lawrence Berkeley National Laboratory, "Host Tuning," [Online]. Available:
http://fasterdata.es.net/host-tuning/. [Accessed 2013].
[12] B. Leitão and IBM, "Tuning 10Gb network cards on Linux," [Online]. Available:
http://landley.net/kdocs/ols/2009/ols2009-pages-169-184.pdf. [Accessed 2013].
[13] Intel and Various, "PowerTop Community mailling list," [Online]. Available:
https://01.org/powertop/community. [Accessed 2013].
[14] Gentoo Linux; Various, "Gentoo Linux x86 with Software Raid and LVM2 Quick Install Guide,"
[Online].
Available:
http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2quickinstall.xml. [Accessed 2013].
[15] kernel.org
and
Various,
"Linux
Raid,"
[Online].
Available:
https://raid.wiki.kernel.org/index.php/Linux_Raid. [Accessed 2013].
[16] T. Davis, “Linux Ethernet Bonding Driver HOWTO,” 2011. [Online]. Available:
https://www.kernel.org/doc/Documentation/networking/bonding.txt. [Acedido em
2014].
[17] K. Ishiguro and e. al., "Quagga, A routing software package for TCP/IP networks," 01 2013.
[Online]. Available: http://www.nongnu.org/quagga/docs/quagga.pdf. [Accessed 2013].
[18] J. Sanfeliu, “Monitorix,” [Online]. Available: http://www.monitorix.org/. [Acedido em 2014].
[19] R. Russell and H. Welte, "Linux netfilter Hacking HOWTO," 02 07 2002. [Online]. Available:
http://www.netfilter.org/documentation/HOWTO//netfilter-hacking-HOWTO.html.
[Accessed 2013].
[20] R. Russel, "Linux 2.4 NAT HOWTO," 14 01 2002. [Online]. Available:
http://www.netfilter.org/documentation/HOWTO//NAT-HOWTO.html. [Accessed 2013].
[21] Gentoo Linux; Various, "Gentoo Linux x86 Handbook," [Online]. Available:
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml. [Accessed 2013].
[22] Wikipedia; Various, "Netfilter," [Online]. Available: http://en.wikipedia.org/wiki/Netfilter.
47
[Accessed 2013].
[23] Y.-F.
Li,
"The
Double
NAT
MINI-HOWTO,"
[Online].
Available:
http://www.netfilter.org/documentation/HOWTO//netfilter-double-nat-HOWTO.html.
[Accessed 2013].
[24] R. Russell, "Linux 2.4 Packet Filtering HOWTO," 24 01 2002. [Online]. Available:
http://www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO.html.
[Accessed 2013].
[25] W. Cheswick, S. Bellovin and A. Rubin, Firewalls and Internet Security: Repelling the Wily
Hacker, Addison-Wesley, 2002.
[26] E. Zwicky, S. Cooper and D. Chapman, Building Internet Firewalls, 2nd Edition, O'Reilly, 2000.
[27] F. Monteiro e F. Boavida, Engenharia de Redes Informáticas, FCA, 2011.
[28] F. Boavida, M. Bernardes e P. Vapi, Administração de Redes Informáticas, FCA, 2011.
[29] J. Granjal, Gestão de Sistemas e Redes em Linux, FCA, 2013.
[30] M. Weidner, “App-Iptables2Dot,” 2012. [Online]. Available: http://search.cpan.org/dist/AppIptables2Dot/. [Acedido em 2014].
48

Relatório apresentado para a prova de Especialista de

Transcrição

Documentos relacionados

Integrantes: Fabíola Dias, Jordan Gonçalvez, Lucas Rossales

esta.ipt ~K Escola Superior de Tecnologia de Abrantes

COMUNICAÇÃO TÉCNICA 171653 Gaseificação de biomassa

Trabalho de Revisão – UNIRIO – FRC 2014/1 Prof.: Sidney C. de

Inverted Pen Technology

COMUNICAÇÃO TÉCNICA Nº 173774 Production of O/W

Modelos BIA-IN, BIR-IN e BIE-IN

Untitled

Festa Junina - Tênis Clube Paulista

PROCESSO SELETIVO PÚBLICO DE ESTAGIÁRIOS - NOVOS