Esta é uma pergunta canônica proposta sobre a compreensão e depuração do firewall de software em sistemas Linux.
Em resposta à resposta da EEAA e ao comentário de @Shog de que precisamos de uma sessão de perguntas e respostas canônica adequada para encerrar questões comuns relativamente simples sobre o iptables .
O que é um método estruturado para depurar problemas com o firewall de software Linux, a estrutura de filtragem de pacotes netfilter , comumente chamada de interface de usuário iptables ?
Quais são as armadilhas comuns, perguntas recorrentes e coisas simples ou um pouco mais obscuras para verificar que um administrador de firewall ocasional pode ignorar ou se beneficiar de saber?
Mesmo quando você usa ferramentas como UFW , FirewallD (aka firewall-cmd), Shorewall ou similar, você pode se beneficiar olhando sob o capô sem a camada de abstração que essas ferramentas oferecem.
Esta questão não pretende ser um tutorial para construir firewalls: verifique a documentação do produto para isso e, por exemplo, contribua com receitas para iptables Trips & Tricks ou pesquise as perguntas marcadas iptables ufw firewalld firewall-cmd para obter pontuações altas frequentes e bem consideradas Perguntas e respostas.
No geral:
A visualização e modificação da configuração do firewall requer privilégios de administrador (
root), assim como a abertura de serviços no intervalo de número de porta restrito. Isso significa que você deve estar logado comorootou, alternativamente, usarsudopara executar o comando como root. Vou tentar marcar esses comandos com o opcional[sudo].Conteúdo:
-Ie-Aiptables -L -v -n1. A ordem é importante ou a diferença entre
-Ie-ALembre-se de que as regras de firewall são verificadas na ordem em que estão listadas. O kernel parará de processar a cadeia quando uma regra for acionada, permitindo ou não um pacote ou conexão.
Acho que o erro mais comum dos administradores de firewall iniciantes é seguir as instruções corretas para abrir uma nova porta, como a abaixo:
e então descobrir que não surtirá efeito.
A razão para isso é que a
-Aopção adiciona essa nova regra, depois de todas as regras existentes e já que muitas vezes a regra final no firewall existente era aquela que bloqueava todo o tráfego que não é explicitamente permitido, resultando emOu equivalente em iptables-save:
e a nova regra que abre a porta TCP 8080 nunca será alcançada. (como evidenciado pelos contadores teimosamente permanecendo em 0 pacotes e zero bytes).
Ao inserir a regra com
-Ia nova regra teria sido a primeira da cadeia e funcionará.2. Exibir a configuração atual do firewall
Minha recomendação para o administrador do firewall é observar a configuração real que o kernel do Linux está executando, em vez de tentar diagnosticar problemas de firewall a partir de ferramentas amigáveis. Muitas vezes, depois de entender os problemas subjacentes, você pode resolvê-los facilmente em um assunto suportado por essas ferramentas.
O comando
[sudo] iptables -L -v -né seu amigo (embora algumas pessoas gostemiptables-savemais). Muitas vezes, ao discutir configurações, é útil usar a--line-numbersopção também para numerar linhas. A referência à regra #X torna a discussão um pouco mais fácil.Observação: as regras NAT estão incluídas na
iptables-savesaída, mas devem ser listadas separadamente adicionando a-t natopção, por exemplo,[sudo] iptables -L -v -n -t nat --line-numbers.Executar o comando várias vezes e verificar os contadores incrementados pode ser uma ferramenta útil para ver se uma nova regra realmente é acionada.
Como alternativa, a saída de
iptables-savefornece um script que pode regenerar a configuração de firewall acima:É uma questão de preferência o que você achará mais fácil de entender.
3. Interpretando a saída de
iptables -L -v -nA política define a ação padrão que a cadeia usa quando nenhuma regra explícita corresponde. Na
INPUTcadeia que está definida para ACEITAR todo o tráfego.A primeira regra na cadeia INPUT é imediatamente interessante, ela envia todo o tráfego (origem 0.0.0.0/0 e destino 0.0.0.0/0) destinado à porta TCP 22 (
tcp dpt:22) a porta padrão para SSH para um destino personalizado (fail2ban-SSH) . Como o nome indica, esta regra é mantida pelo fail2ban (um produto de segurança que, entre outras coisas, verifica os arquivos de log do sistema em busca de possíveis abusos e bloqueia o endereço IP do agressor).Essa regra teria sido criada por uma linha de comando iptables semelhante
iptables -I INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSHou encontrada na saída de iptables-save as-A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH. Freqüentemente, você encontrará qualquer uma dessas notações na documentação.Os contadores indicam que esta regra correspondeu a 784.000 pacotes e 65 Megabytes de dados.
O tráfego que corresponde a esta primeira regra é então processado pela
fail2ban-SSHcadeia que, como uma cadeia não padrão, é listada abaixo da cadeia OUTPUT.Essa cadeia consiste em duas regras, uma para cada abusador (endereço IP de origem 117.253.221.166 ou 58.218.211.166) que está bloqueado (com um
reject-with icm-port-unreachable).Os pacotes SSH que não são desses hosts bloqueados não são permitidos nem proibidos ainda e, agora que a cadeia personalizada foi concluída, serão verificados em relação à segunda regra na cadeia INPUT.
Todos os pacotes que não foram destinados à porta 22 passaram pela primeira regra na cadeia INPUT e também serão avaliados na regra INPUT #2.
A regra INPUT número 2 significa que se destina a ser um firewall completo , que rastreia as conexões. Isso tem algumas vantagens, apenas os pacotes para novas conexões precisam ser verificados em relação ao conjunto de regras completo, mas uma vez permitido, pacotes adicionais pertencentes a uma conexão estabelecida ou relacionada são aceitos sem verificação adicional.
A regra de entrada nº 2 corresponde a todas as conexões abertas e relacionadas e os pacotes correspondentes a essa regra não precisarão ser avaliados posteriormente.
Observação: alterações de regras na configuração de um firewall com monitoramento de estado afetarão apenas as novas conexões, não as conexões estabelecidas.
Em contraste, um simples filtro de pacotes testa cada pacote em relação ao conjunto de regras completo, sem rastrear o estado da conexão. Em tal firewall, nenhuma palavra-chave de estado seria usada.
A regra de ENTRADA nº 3 é bastante chata, todo o tráfego conectado à interface de loopback (
loou 127.0.0.1) é permitido.As regras INPUT 4, 5 e 6 são usadas para abrir as portas TCP 22, 80 e 443 (as portas padrão para resp. SSH, HTTP e HTTPS) concedendo acesso a NOVAS conexões (as conexões existentes já são permitidas pela regra INPUT 2).
Em um firewall sem estado, essas regras apareceriam sem os atributos de estado:
ou
A regra INPUT final, nº 7, é uma regra que bloqueia todo o tráfego que NÃO teve acesso nas regras INPUT 1-7. Uma convenção bastante comum: tudo o que não é permitido é negado. Em teoria, essa regra poderia ter sido omitida definindo a POLÍTICA padrão como REJECT.
Sempre investigue toda a cadeia.
4. Conheça seu ambiente
4.1 . As configurações em um firewall de software não afetarão as configurações de segurança mantidas em outro lugar na rede, ou seja, apesar de abrir um serviço de rede com
iptablesas listas de controle de acesso não modificadas em roteadores ou outros firewalls em sua rede ainda podem bloquear o tráfego...4.2 . Quando nenhum serviço estiver escutando, você não conseguirá se conectar e obterá um erro de conexão recusada , independentemente das configurações do firewall. Portanto:
[sudo] netstat -plnutou, alternativamente, usess -tnlp.[sudo] nc -l -p 123ouopenssl s_server -accept 1234 [options]se você precisar de um ouvinte TLS/SSL (verifiqueman s_serveras opções).telnet <IP of Server> 123ouecho "Hello" | nc <IP of Server> 123ou ao testar o serviço protegido por TLS/SSLopenssl s_client -connect <IP of Server>:1234, antes de tentar o mesmo em um host remoto.4.3 . Entenda os protocolos usados pelos seus serviços. Você não pode habilitar/desabilitar corretamente serviços que não entende suficientemente. Por exemplo:
/etc/servicesnão correspondem necessariamente ao serviço real que está usando uma porta.4.4 . O filtro de pacotes do kernel não é a única coisa que pode restringir a conectividade de rede:
getenforceconfirmará se o SELinux está em execução.ldd /path/to/service |grep libwrape os/hosts.[allow|deny]arquivos de controle.5.
INPUTouFORWARDCorrentesO conceito de cadeias é explicado mais detalhadamente aqui, mas o resumo é:
A
INPUTcadeia é onde você abre e/ou fecha portas de rede para serviços executados localmente, no host onde você emite os comandos iptables.A
FORWARDcadeia é onde você aplica regras para filtrar o tráfego que é encaminhado pelo kernel para outros sistemas, sistemas reais, mas também contêineres Docker e servidores virtuais convidados quando sua máquina Linux está agindo como uma ponte, roteador, hipervisor e/ou endereço de rede tradução e encaminhamento de porta.Um equívoco comum é que, como um contêiner docker ou convidado KVM é executado localmente, as regras de filtro aplicáveis devem estar na cadeia INPUT, mas geralmente não é o caso.
6. Módulos do kernel
Como o filtro de pacotes é executado no kernel do Linux, ele também pode ser compilado como módulo dinâmico, na verdade vários módulos. A maioria das distribuições inclui netfilter como módulos e os módulos netfilter necessários serão carregados no kernel conforme necessário, mas para alguns módulos, um administrador de firewall precisará garantir manualmente que sejam carregados. Isso diz respeito principalmente aos módulos de rastreamento de conexão, como os
nf_conntrack_ftpque podem ser carregados com arquivosinsmod.Os módulos atualmente carregados no kernel em execução podem ser exibidos com
lsmod.O método para garantir que os módulos sejam carregados persistentemente nas reinicializações depende da distribuição do Linux.
Iptables/Firewall "introdução"
Um firewall é basicamente um filtro de rede baseado em políticas. Os firewalls do Linux são construídos em torno do Netfilter; a estrutura de processamento de pacotes de rede do kernel, que é composta por vários módulos do kernel que executam tarefas específicas:
Os usuários configuram a estrutura do Netfilter para atender às suas necessidades de firewall usando iptables na linha de comando. Com o iptables, definimos regras que instruem o kernel sobre o que fazer com os pacotes IP quando eles chegam, passam ou saem de nossa caixa Linux. Cada processo principal do Netfilter é representado por uma TABELA (FILTER, NAT, MANGLE) na linguagem do iptables. Eles têm vários pontos de gancho específicos no mapa de fluxo de pacotes de rede, onde são chamados pelo kernel para desempenhar suas funções. Certas sequências de chamadas TABLE localizadas especificamente são chamadas genericamente de CHAINS incorporadas recebendo os nomes de PREROUTING, INPUT, FORWARD, OUTPUT e POSTROUTING. É fácil lembrar se associarmos uma TABELA a um "tipo de processo" e uma CADEIA à "localização" no mapa de fluxo de pacotes de rede onde as instâncias desses processos são invocadas.
Since an IP packet is received on a network interface, or created by a local process, until it is finally delivered or discarded the Netfilter engine will sequentially test and apply the rules contained along the network packet flow map. At each block identified by a TABLE@CHAIN pair the user can add one or more of these consecutive rules containing an IP packet matching criteria and a corresponding course of action. There are actions (i.e. ACCEPT, DROP, etc.) that can be performed by more than one TABLE and other actions (i.e. SNAT, DNAT, etc.) that are TABLE specific.
i.e. when an IP packet arrives from a network interface it is first processed by the PREROUTING chain invoking the MANGLE table user defined rules if any. If there are not rules that match the current packet the corresponding MANGLE@PREROUTING default course of action or "policy" applies. At this point if the packet was not dropped the process will continue now invoking the rules of the NAT table at the PREROUTING chain (see the map) and so on. In order to facilitate the rules layout, users can also create their own custom chains and "jump" into them from different points of the map as they wish.
While built-in chains can have user defined policies of either ACCEPT or DROP packets, user defined chains have allways an unchangeable default policy of RETURN to the caller to continue the process.
Iptables commands
The iptables main commands populate the network packet flow map with the required processing rules.
The generic iptables rule can be written as:
# iptables <table> <Add/Insert/Delete> <CHAIN> <PKT_MATCHING_CRITERIA> <ACTION>It could be read like:
The iptables auxiliary commands complete the scenario setting default conditoins, listing rules, flushing rules, etc.
Iptables loads our commands into Netfilter engine at runtime, Netfilter inmediatelly enforces the loaded rules and settings but they are not persistant. Afeter reboot all previously loaded Netfilter rules and settings will be lost. For this reason there are iptables utilities that allow to save the currently active ruleset to a file and to reload it later.
Iptables Summary
Netfilter is an extremely flexible and powerful framework but there is a price to pay for it; Iptables is complex. From an user point of view certain terms like TABLE, CHAIN, TARGET do not really match very well the concept they represent and do not make much sense at first. The topic is long, commands seem to have an endless list of parameters. To make things worse there is not a single book that really masters Iptables. They mostly fall into two categories: "recipe book" or "manpage book". I think this introduction gives you a snapshot of the Netfilter/Iptables landscape plus the necessary dose of pre-digested manpage stuff. If you are new at iptables, after reading these paragraphs a couple of times you will be ready to read iptables examples. With some practice you will soon find yourself writting your own rules.
Firewalls
A firewall is mainly designed to dynamically permit or deny network traffic based upon a set of rules. At this point it is easy to understand why the Linux Netfilter/Iptables framework is perfect for firewall construction. Looking at the network packet flow map we find two particularly interesting spots on the FILTER table at the INPUT and FORWARD chains; We can decide there upon IP source address, IP protocol (UDP/TCP), destination port (80, 21, 443, etc), etc, if we ACCEPT, REJECT, or just DROP a particular IP packet. This is what a firewall does 80% of the time when i.e. protects a web server from unauthorized network requests. The other 20% of the time is manipulating (NAT, MANGLE) network packets.
Firewalls Scenarios
There are hundreds of different firewall layouts addresing different needs but 3 of them could be considered the most typical firewall scenarios.
Eu escrevi isso para: http://www.vercot.com/~jeoss/howto/JeossEasyFirewall.html
Problemas comuns com diferentes protocolos
DNS: o DNS usa a porta 53 UDP por padrão, mas as mensagens que não cabem em um único datagrama UDP serão transmitidas usando TCP (normalmente transferências de zona e outros) exigindo que a porta 53 TCP também seja aberta quando você executa um servidor de nomes .
E-mail: muitos ISPs do consumidor bloqueiam o tráfego SMTP (ou pelo menos a porta padrão TCP 25), impossibilitando o recebimento ou envio direto de e-mails e seus clientes são forçados a usar a retransmissão SMTP do ISP para todos os e-mails enviados e, às vezes, também para os e-mails recebidos. . Relaciona-se com §1.1.
FTP: FTP é um protocolo estranho no que diz respeito ao uso de duas conexões. A primeira é a conexão de controle, por padrão um servidor FTP escutará na porta TCP 21 para isso. A conexão de controle é usada para autenticação e emissão de comandos. As transferências de arquivos reais e coisas como a saída de uma listagem de diretório passam por uma segunda conexão TCP, a conexão DATA. No FTP ativo, essa conexão de DADOS seria iniciada no servidor FTP da porta TCP 20 e conectada ao cliente FTP. O FTP ativo não funciona muito bem com usuários protegidos por firewalls e gateways NAT, por isso caiu em desuso. A maioria dos servidores FTP suporta FTP passivo. Com o FTP passivo, o servidor FTP abre um ouvinte para a conexão DATA em uma segunda porta, à qual o cliente FTP pode se conectar. O problema para um firewall é que a porta DATA pode ser qualquer porta não privilegiada disponível entre 1024-65536.
Em um firewall sem estado, isso normalmente é resolvido pela restrição do número de portas passivas que o servidor FTP pode atribuir e pela abertura explícita dessas portas. ou seja
Em um firewall stateful, você não precisa abrir explicitamente a porta DATA, o módulo auxiliar netfilter reconhecerá a porta dinâmica atribuída e abrirá dinamicamente essa porta para o cliente correto, marcando a conexão DATA como
RELATEDapós o que corresponderá à regra genérica :Isso requer que o módulo correto do kernel seja carregado, no caso do FTP manualmente, executando por exemplo
insmod nf_conntrack_ftp, tornando essa dependência persistente entre a reinicialização depende da distribuição.Nota: O módulo de rastreamento de conexão FTP falhará quando o FTP for usado com SSL, pois a conexão de controle será criptografada e o nf_conntrack_ftp não poderá mais ler a resposta PASV.
NFS e serviços RPC semelhantes : O problema com os serviços RPC é que, por design, eles não usam uma porta fixa específica. Eles podem escolher qualquer porta disponível aleatoriamente, que será então registrada com o daemon RPC Portmap. Um cliente tentando se conectar consultará o daemon do Portmap e então se conectará diretamente à porta correta. Isso resolveu o problema de ficar sem portas reservadas...
Do ponto de vista do firewall, a porta TCP/UDP 111 precisa ser aberta e a porta real que o serviço RPC está usando no momento. O problema de abrir uma porta aleatória em um firewall geralmente é resolvido restringindo o serviço RPC, como o servidor NFS, para usar uma porta fixa predefinida.