Ver Feed RSS

The JEdi lair's

Netfilter/Iptables - Parte 1

Avaliação: 3 votos, 4,67 média.
Bom dia galera, uma breve introdução sobre minha pessoa e depois o que interessa de verdade!

Sou usuário GNU/Linux desde 1998 e venho dedicado meu tempo ao estudo de segurança da informação. Atualmente atuo como administrador de segurança de redes. Pronto!

Vejo que um assunto muito comum no UnderLinux Forums é Netfilter/Iptables. Vou tentar esclarecer um pouco sobre o assunto nesse primeiro post. Não pretendo criar um guia definitivo, porém quem tiver palpites sobre melhora do conteúdo do post por favor me envie.

1 - Mais do que breve conceito do Netfilter/Iptables

O Netfilter/Iptables é o filtro de pacotes padrão do kernel GNU/Linux desde as versões 2.4. Por filtro de pacotes entendemos um mecanismo que faz a verificação dos cabeçalhos TCP/IP dos pacotes de rede e toma decisão em relação ao seu conteúdo. Alguns módulos adicionam funcionalidades relacionadas as camadas mais altas, L7 por exemplo, porém esse não é a utilização mais adequada de um filtro de pacotes.

O funcionamento do Netfilter/Iptables é dividido em chains, tables, matches e targets.

2 - Tables
As tables determinam que tipo de decisão será feita nos pacotes. Exemplificando, a table mangle, da qual falarei mais detalhadamente, pode alterar o conteúdo dos pacotes enquanto a tabela filter pode somente tomar decisões quanto a passagem ou não do pacote através do sistema de filtro.

O Netfilter/Iptables trabalha com quatro tabelas distintas, a saber:

filter: Essa tabela é utilizada para tomada de decisão quanto a passagem ou não de um pacote através do filtro. Essa é a tabela padrão.

nat: Essa tabela é consultada quando um pacote que cria uma nova conexão, seja de entrada ou saída, é encontrado. Esta é a tabela usada para "compatilhar a conexão" e/ou "rotear os pacotes".

mangle: Essa tabela poder realizar alterações especiais de forma a auxiliar os mecanismos de filtro de pacotes, fair queueing e packet routing.

raw: Esta tabela é usada, principalmente, para configurar excessões no mecanismo de connection tracking do kernel (ativado através do módulo ip_conntrack).

A ordem de avaliação das tabelas é a seguinte:

raw ->> mangle ->> nat ->> filter

Agora surge o questionamento: tá, e como eu faço a tomada de decisões? Calma!

3 - Chains
As chains são usadas para o controle de fluxo dos pacotes dentro das tabelas, por exemplo entrada na filter, saída na nat, etc. Existem cinco chains principais:

INPUT (mangle, filter)
Essa chain é utilizada para verificar pacotes destinados a máquina filtro de pacotes.

OUTPUT (raw, mangle, nat, filter)
Essa chain é utilizada para verificar pacotes originados da máquina filtro de pacotes.

FORWARD (mangle, filter)
Essa chain é utilizada para verificar pacotes que irão atravesar duas interfaces de rede.

PREROUTING (raw, mangle, nat)
Essa chain é utilizada para verificar pacotes destinados a máquina filtro de pacotes mas com foco na tomada de decisão de roteamento tais como o redirecionamento dos pacotes. Todos os pacotes de entrada são verificados pelas regras desta chain antes de passar pela avaliação da chain INPUT.

POSTROUTING (mangle, nat)
Essa chain é utilizada para verificar pacotes que tem como endereço uma rede diferente de sua rede de origem. Tentando esmiuçar, quando um cliente dentro de uma rede local tenta acessar o conteúdo da Internet através da máquina filtro de pacotes (gateway).

4 - Comandos
Bem, o comando básico para o uso da userspace tool Netfilter/Iptables é o iptables!!! Incrível!!! O iptables possui os seguintes comandos:

-t ou --table table
Especifica a tabela a qual desejamos utilizar. Por padrão, se o -t não for especificado, a tabela filter será usada.

-L ou --list [chain]
Exibe as regras presentes em todas as chains, caso não seja especificado uma chain. Podemos utilizar os modificadores --line-numbers (exibe o número da regra), -v ou --verbose (modo verbose), -n ou --numeric (todas as informações são exibidas em formato númerico) e -x ou --exact (todos os valores serão exibidos em bytes).

ex: iptables -t nat -L
|
\-> Lista todas as regras presentes nas chains da tabela nat

ex: iptables -t mangle -L OUTPUT
|
\-> Lista todas as regras presentes na chain OUTPUT da tabela mangle.

-F ou --flush [chain]
Apaga todas as regras de todas as chains ou uma chain específica.

ex: iptables -F
|
\-> Apaga todas as regras de todas as chains da tabela filter (Lembre-se: tabela filter é padrão!).

ex: iptables -t nat -F PREROUTING
|
\-> Apaga todas as regras da chain PREROUTING da tabela nat.

-Z ou --zero [chain]
Zera os contadores de bytes de todas as chains ou de uma chain específica.

ex: iptables -t mangle -Z FORWARD
|
\-> Zera os contadores da chain forward da tabela mangle.

ex: iptables -t raw -Z
|
\-> Zera os contadores de todas as chains da tabela raw.

-N ou --new-chain new-chain
Cria uma chain definida pelo usuário. A nova chain não pode ter o mesmo nome de um target ou target extension. Posteriormente falaremos de chains definidas pelo usuário.

-X ou --delete-chain [chain]
Apaga todas as chains definidas pelo usuário ou uma chain específica.

ex: iptables -X
|
\-> Apaga todas as chains definidas pelo usuário na tabela filter.

ex: iptables -t nat -X banidos
|
\-> Apaga a chain banidos da tabela nat.

obs: As chains precisam estar vazias (-F)!

-A ou --append chain [regra]
Adiciona uma regra no final de uma chain.

ex: iptables -A INPUT
|
\-> Adiciona regra vazia após a ultima regras presente na chain INPUT da tabela filter.

-I ou --insert chain [numregra] [regra]
Adiciona uma regra no inicio da chain ou na posição especificada por numregra.

ex: iptables -t mangle -I INPUT 1
|
\-> Adiciona regra vazia na posição 1 da chain INPUT da tabela mangle.

obs: As regras posteriores a numregra serão alocadas na próxima posição.

-R ou --replace chain numregra regra
Repõe a regra presente em numregra com regra.

ex: iptables -t raw -R OUTPUT 3
|
\-> Repõe a regra presente na terceira posição da chain OUTPUT da tabela raw com uma regra nula.

-D ou --delete chain regra
-D ou --delete chain numregra
Apaga a regra que contém regra ou a regra na posição numregra.

ex: iptables -D INPUT
|
\-> Apaga uma regra nula da chain INPUT da tabela filter.

ex: iptables -t mangle -D FORWARD 4
|
\-> Apaga a regra presente na quarta posição da chain FORWARD da tabela mangle.

-P ou --policy chain target
Define o policiamento padrão de uma chain. Apenas as chains padrões podem ter policiamento. Na secção targets veremos quais os targets válidos para policiamento.

5 - Parâmetros
Bom pessoal, na secção anterior tentei trabalhar com regras nulas para não atropelar a explicação dos parâmetros. Parâmetros são os mecanismos usados para verificar o conteúdo dos cabeçalhos dos pacotes. Além dos parâmetros existem as match extensions que adicionam funcinalidades ao Netfilter/Iptables porém dedicarei uma secção exclusiva nesse post para explica-las.

-p, --protocol [!] proto
Verifica o protocolo do pacote. Os valores aceitos para proto são tcp, udp, icmp ou all.

ex: iptables -t raw -A PREROUTING -p tcp
|
\-> Essa regra irá conferir com todos os pacotes que passarão pelo firewall que utilizem o protocolo TCP.

ex: iptables -A INPUT -p ! icmp
|
\-> Essa regra irá conferir com todos os pacotes que estão entrando no filtro de pacotes que não utilizam o protocolo ICMP. ! significa não!

-s ou --source ou --src [!] origem
Verifica a origem do pacote.

ex: iptables -t mangle -I FORWARD -p udp -s 192.168.0.1
|
\-> Essa regra irá conferir com os pacotes atravesando duas interfaces de rede através do protocolo udp e que tenha como origem o endereço 192.168.0.1.

ex: iptables -t nat -A PREROUTING -p icmp -s 10.1.0.0/16
|
\-> Essa regra irá conferir com os pacotes chegando numa interface de rede através do protocolo ICMP e que tenha como origem a rede 10.1.0.0 com máscara de sub-rede 255.255.0.0.

-d ou --destination ou --dst [!] destino
Verifica o destino do pacote.

ex: iptables -A FORWARD -s 10.1.0.2 -d 192.168.55.1
|
\-> Essa regra irá conferir com todos os pacotes atravesando o filtro de pacotes com origem do host 10.1.0.2 e destino 192.168.55.1

ex: iptables -t nat -A POSTROUTING -d 192.168.100.0/24
|
\-> Essa regra irá conferir com todos os pacotes que tentarão deixar a rede através do filtro de pacotes com destino a rede 192.168.100.0 com máscara de sub-rede 255.255.255.0.

-i ou --interface
Verifica a interface na qual o pacote foi recebido. Essa match só existe nas chains INPUT, FORWARD, PREROUTING e em chains criadas pelo usuário.

ex: iptables -t nat -A PREOUTING -i ppp0 -s 192.168.25.25
|
\-> Essa regra irá conferir com pacotes que chegam ao filtro através da interface ppp0 e que tenham como host de origem 192.168.25.25.

ex: iptables -A INPUT -p udp -i eth+
|
\-> Essa regra irá conferir com todos os pacotes destinados ao filtro de pacotes que tenham como interfaces de entrada eth0, eth1, ... , ethN, ou seja todas as interfaces prefixadas por eth.

Por equanto é só...
Continua no próximo post... Limitação de 10000 caracteres!

Comentários

  1. Avatar de benezinha
    Olá,

    Parabens pela iniciativa. Excelente material!
  2. Avatar de PEdroArthurJEdi
    Muito obrigado!
  3. Avatar de Duca
    Putz!
    Muito bom!
    Para não ter limitação de caracteres é só usar o wiki.
    Logo, eu irei colocar seu Tutorial lá.
    Parabéns mesmo!
  4. Avatar de Magnun
    Muito bom cara... É por iniciativas como essa que o Under-Linux cresce cada dia mais!
    Parabéns!!
  5. Avatar de MarcusMaciel
    Duca acho que a limitacao é boa pra nao ficar muito extenso o artigo... Sobre o Wiki o objetivo dele é colocar artigos já existentes para que possam ser completados por outras pessoas. Pois sempre existem lacunas a serem completadas
  6. Avatar de PEdroArthurJEdi
    @Duca

    Pô cara, o que eu gosto aqui nos blogs é a possibilidade de se usar drafts... Esses quatro posts eu venho produzindo desde novembro de 2008. Um assunto muito extenso e precisa ler a documentação pra entender melhor e não falar besteira.

    A verdadeira iniciativa seria tentar conscientizar a galera que o trabalho de documentação leva ao aprendizado. Imagina o quanto eu aprendi sobre o Netfilter/iptables para criar os textos.

    @Magnun

    Complementando o que citei acima, uma da etapas do aprendizado é o repasse. Devemos aproveitar melhor os espaços dos fóruns, dos wikis, dos blogs, seja lá o que for, para disseminar o conhecimento. O que seria da ciÊncia se grandes pesquisadores do passado não tivessem a preocupação de repassar seus conhecimentos? Será que estariamos a milhas de distância discutindo Linux e software livre?
  7. Avatar de Duca
    @Scorpion

    Concordo com a limitação.

    @PEdroArthurJEdi

    A idéia do wiki, é justamente essa que o Scorpion disse. Contudo, é bom colocar os tutoriais aqui postados no wiki, pois existirá mais uma referência e o bom do wiki (minha opinião) é que fica bem formatado.
    Você pode continuar postando seus tutoriais aqui no blog, que estes serão copiados para o wiki também.
    A idéia do Under-wiki, é transformá-lo no nosso centro de documentação.

    E parabéns pelo trabalho, se todo portal tivesse usuários como você a qualidade destes subiriam e muito.
    E graças as Deus, Alá e Buda, temos muitos no Under.
    Ab, Duca.
    Atualizado 12-01-2009 em 11:23 por Duca
  8. Avatar de Duca
    E que a Força esteja conosco!
  9. Avatar de netscaper
    magavilhindilhoso !!
  10. Avatar de jacksonezidio
    Cara vc ta de parabens pela excelente iniciativa, a comunidade agradece...
  11. Avatar de kakinho
    Putss.... obrigado por compartilhar conosco seus conhecimentos.... vlw msmo... otimo material... quando tiver oportunidade irei indicar a alguem... parabens msmo
  12. Avatar de Dedao
    Ola Pedro.
    Antes de tudo, queria te parabenizar pelo excelente material sobre iptables.....Bom, li as 4 partes da apostila de iptables que você criou, mas fiquei ainda com algumas dúvidas. Se você puder me responder, me ajudaria bastante. Segue elas abaixo:

    1 - Você poderia me explicar melhor para que server a tabela raw do iptables ? Poderia dar algum exemplo prático ?

    2 - A opção -Z zera os contadores de bytes. Mas qual a utilidade de eu fazer isso ? Em que isso vai afetar meu firewall ?

    3 - Fiquei com dúvida em relação a criar regras sem um target. Ok, se eu fizer uma regra sem target, essa regra ira trabalhar como um contador. Mas quando vou precisar fazer isso ? Pode dar algum exemplo prático ?

    4 - Poderia me explicar por que não devo utilizar a regra iptables -A INPUT -p tcp --syn -m limit --limit 5/s --limit-burst 3 -j DROP para evitar flooding ?
    Qual regra você acha mais adequada para evitar ataques floods ?

    5 - Vamos supor que eu tenha um sistema que utilize muito protocolo udp (ex: voip). Eu poderia ter as regras abaixo no firewall funcionando em perfeita harmonia ?
    iptables -A INPUT -m state --state RELATED,ESTABLISHED -p tcp -j ACCEPT
    iptables -A INPUT -m state --state RELATED,ESTABLISHED -p udp -j ACCEPT

    6 - Eu tendo um sistema voip, eu utilizando a regra iptables -A INPUT -m state --state RELATED,ESTABLISHED -p udp -j ACCEPT ajudaria a ter menos perda de pacote ?


    7 - Quando é vantagem utilizar o SNAT ao invés do DNAT, pois ao meu ver, sempre é mais pratico utilizar uma regra parecida com essa:
    iptables -t nat -s 200.200.200.200 -p tcp -m tcp --dport 21 -j DNAT --to-destination 192.168.20.1

    8 - Você acha importante deixar a chain output da tabela filter como DROP ? Eu normalmente deixo apenas o INPUT e o FORWARD como ACCEPT e não tenho muitos problemas.

    9 - Faz diferença em utilizar a regra iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT no final ou no início do firewall ? Onde seria melhor deixá-la ?

    10 - Sempre que eu faço um firewall, eu utilizo as sempre as seguintes regras:
    iptables -P INPUT -j DROP
    iptables -P FORWARD -j DROP
    iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
    iptables -A INPUT -s ! 127.0.0.0 -p tcp -j LOG --log-prefix "firewall.log"

    Depois dessas regras, eu crio o firewall, de acordo com o ambiente. Você acha que há necessidade de ter mais alguma regra ?

    []'s,
    Renato
  13. Avatar de PEdroArthurJEdi
    Citação Postado originalmente por Dedao
    Ola Pedro.
    Antes de tudo, queria te parabenizar pelo excelente material sobre iptables.....Bom, li as 4 partes da apostila de iptables que você criou, mas fiquei ainda com algumas dúvidas. Se você puder me responder, me ajudaria bastante. Segue elas abaixo:
    Obrigado...

    Citação Postado originalmente por Dedao
    1 - Você poderia me explicar melhor para que server a tabela raw do iptables ? Poderia dar algum exemplo prático ?
    A tabela raw tem a capacidade de manipular o filtro de estados do iptables. Um exemplo prático. Digamos que você tenha uma faixa de endereços IPs aos quais você não deseja prover serviço, nem muito menos alocar recursos para manter o estado dessas conexões. Assuma também uma política restritiva. Você poderia fazer:
    iptables -t raw -A PREROUTING -s 192.168.0.10-20 -j NOTRACK
    iptables -A INPUT -p tcp --dport 80 --syn -m state --state NEW -j ACCEPT
    Citação Postado originalmente por Dedao
    2 - A opção -Z zera os contadores de bytes. Mas qual a utilidade de eu fazer isso ? Em que isso vai afetar meu firewall ?
    Uma utilidade seria no momento de depuração das regras. Digamos que você esteja com um problema em suas regras e necessita avaliá-lo. Você pode zerar os contadores e a partir daí gerar tráfego e ver o comportamento das regras.

    Além, caso você esteja com um conjunto de regras em fase de testes e esteja avaliando-as em um servidor em produção. Quando estiver satisfeito com seu conjunto de regras, você pode zerar os contadores e ter as estatísticas a partir do momento da produção em si (quando o conjunto de regras sair da fase de testes e passar para uma fase estável).

    Até onde eu sei, não afeta em nada. Somente zera os contadores.

    Citação Postado originalmente por Dedao
    3 - Fiquei com dúvida em relação a criar regras sem um target. Ok, se eu fizer uma regra sem target, essa regra ira trabalhar como um contador. Mas quando vou precisar fazer isso ? Pode dar algum exemplo prático ?
    Isso é um caso bem específico. Por exemplo, caso se queira avaliar quantas conexões TCP para a porta 80 estão vindo pela rede interna e quantos da Internet para a criação de uma política de QoS. Estátistica!

    Citação Postado originalmente por Dedao
    4 - Poderia me explicar por que não devo utilizar a regra iptables -A INPUT -p tcp --syn -m limit --limit 5/s --limit-burst 3 -j DROP para evitar flooding ?
    Qual regra você acha mais adequada para evitar ataques floods ?
    Antes, obrigado! Encontrei um erro... teria que haver um ! antes --limit. Já corrigi lá no texto, obrigado novamente! Segue a explicação para a seguinte regra:
    iptables -A INPUT -p tcp --syn -m limit ! --limit 5/s --limit-burst 3 -j DROP
    Isso é um suicídio... Ou um pedido de demissão

    Entendamos a regra. Ela diz que: ``Assista todo o tráfego TCP com a flag syn presente. Após o terceiro pacote, se a taixa não estiver limitada a 5 pacotes por segundo, derrube o pacote''. Digamos que alguém realmente esteja tentando realizar uma inundação de pacotes syn na sua máquina. Caso existam tentativas de conexões paralelas e legítimas, os host requisitantes também serão derrubados. Se o indivíduo malicioso manter o ritmo de pacotes, está instalado um DoS na sua rede.

    Não conheço nenhuma... Recomento utilizar os syn cookies.

    Citação Postado originalmente por Dedao
    5 - Vamos supor que eu tenha um sistema que utilize muito protocolo udp (ex: voip). Eu poderia ter as regras abaixo no firewall funcionando em perfeita harmonia ?
    iptables -A INPUT -m state --state RELATED,ESTABLISHED -p tcp -j ACCEPT
    iptables -A INPUT -m state --state RELATED,ESTABLISHED -p udp -j ACCEPT
    Com certeza...

    Citação Postado originalmente por Dedao
    6 - Eu tendo um sistema voip, eu utilizando a regra iptables -A INPUT -m state --state RELATED,ESTABLISHED -p udp -j ACCEPT ajudaria a ter menos perda de pacote ?
    Vai depender muito da quantidade de regras de seu conjunto e da natureza da perda dos pacotes. Caso o conjunto de regas seja muito extenso, ter essa regra vai poupar tempo computacional pois irá evitar que outras regras sejam avaliadas (veja a resposta 9).

    Citação Postado originalmente por Dedao
    7 - Quando é vantagem utilizar o SNAT ao invés do DNAT, pois ao meu ver, sempre é mais pratico utilizar uma regra parecida com essa:
    iptables -t nat -s 200.200.200.200 -p tcp -m tcp --dport 21 -j DNAT --to-destination 192.168.20.1
    Não entendi a pergunta.

    Não lembro de ter comparado os dois. Mas se o tiver feito, me diga onde está pois deve ser outro erro.

    Sua regra está sem chain, mas pelo contexto, tem que ser a PREROUTING. E por que o "-m tcp"?

    Citação Postado originalmente por Dedao
    8 - Você acha importante deixar a chain output da tabela filter como DROP ? Eu normalmente deixo apenas o INPUT e o FORWARD como ACCEPT e não tenho muitos problemas.
    Como assim? Se deve-se usar uma política restritiva nas chains da tabela filter?

    Citação Postado originalmente por Dedao
    9 - Faz diferença em utilizar a regra iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT no final ou no início do firewall ? Onde seria melhor deixá-la ?
    Faz muita. Na minha opnião, a principal vantagem do módulo state é poupar processamente.

    Assuma que as regras que liberam o tráfego são do seguinte estilo:
    iptables -A INPUT -p tcp --dport $PORTA -m state --state NEW -j ACCEPT
    Assuma também que a ultima regra seja
    iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
    Ao chegar um pacotes SYN, ele será avaliado, até que seja aceito. Ou seja, atravessará as regras até que chegue em uma que aceite o pacote. Os próximos pacotes, irão atravessar o mesmo conjunto de regras, não casarão com nenhuma (pois seus estados já não são NEW) e irão casar ao chegar na ultima regra. Portanto, serão avaliadas N-1 regras até que o pacote seja aceito.

    Caso a situação se inverta, tenhamos
    iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
    iptables -A INPUT -p tcp --dport $PORTA -m state --state NEW -j ACCEPT
    Somente o primeiro pacote terá que passar por todas as regras, todo os outros casarão de imediato com a primeira, poupando N-1 avaliação. Ou seja, realizando somente 1.

    Espero que meu ponto de vista tenha ficado claro.

    Citação Postado originalmente por Dedao
    10 - Sempre que eu faço um firewall, eu utilizo as sempre as seguintes regras:
    iptables -P INPUT -j DROP
    iptables -P FORWARD -j DROP
    iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
    iptables -A INPUT -s ! 127.0.0.0 -p tcp -j LOG --log-prefix "firewall.log"

    Depois dessas regras, eu crio o firewall, de acordo com o ambiente. Você acha que há necessidade de ter mais alguma regra ?
    Só a ultima regra que pode levá-lo a um DoS.

    Em se tratando de um filto restritivo, eu faço da seguinte forma:
    iptables -P INPUT DROP
    iptables- P OUTPUT DROP
    iptables -P FORWARD DROP

    iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
    iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
    iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

    iptables -A INPUT -i lo -j ACCEPT
    iptables -A OUTPUT -o lo -j ACCEPT
    A partir desse ponto, vou apenas anexando regras ao final (sempre usando -A).
  14. Avatar de Dedao
    Ola Pedro.
    Obrigado pelas respostas
    Bom, me desculpe, acho que eu mesmo me confundi na questão 7...eheh...desconsidere.

    Na pergunta 8, também me passei. Segue a minha duvida de forma mais clara:

    8 - Você acha importante deixar a chain output da tabela filter como DROP ? Eu normalmente deixo apenas o INPUT e o FORWARD como DROP, e o OUTPUT deixo ACCEPT e não tenho muitos problemas.

    Em relação a questão 9, ficou claro sim. Mas me surgiu uma outra dúvida.
    Eu seria obrigado a ter a regra

    iptables -A INPUT -p tcp --dport $PORTA -m state --state NEW -j ACCEPT no final do firewall,
    ou apenas tendo a regra

    iptables -A INPUT -p tcp --dport $PORTA -m state --state RELATED,ESTABLISHED -j ACCEPT bastaria ?
    Em relação a esse mesmo assunto, teria problema se eu utilizar apenas a regra iptables -A INPUT -p tcp --dport $PORTA -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT, ou isso poderia comprometer a segurança ?
    Atualizado 10-03-2009 em 07:48 por Dedao
  15. Avatar de PEdroArthurJEdi
    Citação Postado originalmente por Dedao
    Ola Pedro.
    Obrigado pelas respostas
    De nada cara, pra isso que serve o Under-Linux.org! E é bem mais divertido quando dicutimos nossas opniões!

    Citação Postado originalmente por Dedao
    8 - Você acha importante deixar a chain output da tabela filter como DROP ? Eu normalmente deixo apenas o INPUT e o FORWARD como DROP, e o OUTPUT deixo ACCEPT e não tenho muitos problemas.
    Isso é um ponto bem pessoal, ligado ao seu nível de paranoia. Mas vamos a um cenário pra ficar mais claro minha opnião.

    Seja um servidor de rede rodando FTP e HTTP. Assuma as seguintes regras:
    iptables -P INPUT DROP
    iptables -P FORWARD DROP
    iptables -A INPUT -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
    iptables -A INPUT -p tcp --dport 21 -m state --state NEW -j ACCEPT
    iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
    Veja que a política da chain OUTPUT está como DROP.

    Agora imagine que num dia X aparece uma falha no serviço de FTP. Agora imagine que antes da falha ser relatada e corrigida surge um exploit para a falha (0-day). Um atacante utiliza o exploit contra o serviço de FTP e consegue acesso ao terminal com os previlégios do usuário ao qual o serviço estava associado.

    Agora, imagine que o kernel também está com uma falha e existe um exploir disponível. O usuário poderá fazer:
    e executar o exploit contra sua máquina.

    Porém, se seu conjunto de regras fosse:
    iptables -P INPUT DROP
    iptables -P OUTPUT DROP
    iptables -P FORWARD DROP

    iptables -A INPUT -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
    iptables -A INPUT -p tcp --dport 21 -m state --state NEW -j ACCEPT
    iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT

    iptables -A OUTPUT -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
    Veja que não há regras que aceitem novas conexões saindo do servidor, portanto a conexão maliciosa nunca seria realizada. E também não adianta somente se valer dessa técnica. Atualize seus servidores.

    Como eu disse, vai depender do seu nível de paranóia.

    Citação Postado originalmente por Dedao
    Em relação a questão 9, ficou claro sim. Mas me surgiu uma outra dúvida.
    Eu seria obrigado a ter a regra

    iptables -A INPUT -p tcp --dport $PORTA -m state --state NEW -j ACCEPT no final do firewall, ou apenas tendo a regra

    iptables -A INPUT -p tcp --dport $PORTA -m state --state RELATED,ESTABLISHED -j ACCEPT bastaria ?
    Você tem que ter regras para aceitar novas conexões. Quanto falei regras no estilo "X", quis dizer que $PORTA deve ser substituido pela porta do serviço que se deseja liberar. Como no exemplo que dei acima, temos duas portas, a 21 e a 80, logo, temos duas regras com o template citado:
    iptables -A INPUT -p tcp --dport $PORTA -m state --state NEW -j ACCEPT

    iptables -A INPUT -p tcp --dport 21 -m state --state NEW -j ACCEPT
    iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
    Citação Postado originalmente por Dedao
    Em relação a esse mesmo assunto, teria problema se eu utilizar apenas a regra iptables -A INPUT -p tcp --dport $PORTA -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT, ou isso poderia comprometer a segurança ?
    Sim teria, porém necessitaria de uma regra por serviço. Digamos que se faça:
    iptables -A INPUT -p tcp --dport 21 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
    iptables -A INPUT -p tcp --dport 80 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
    VEja que não haveria proveito do sistema de conntrack pois teriamos uma regra para cada serviço, e no caso de N regras, todos os pacote de uma conexão teria que passar por P regras até ser aceito, onde P é a posição da regra que o aceita, estando alguma conexão sempre necessitando a passar por um número de regras que se aproxime de N. Ao passao que, da forma como citado na outra resposta, após o primeiro pacote ser aceito, somente uma regra seria avaliada. Entendeu meu ponto de vista?
  16. Avatar de hantersoul
    tenho a solução para clonagem de mac definitiva
  17. Avatar de hantersoul
    me add no msn (mhr_renan@hotmail.com)

+ Enviar Comentário



Visite: BR-Linux ·  VivaOLinux ·  Dicas-L