Estas linhas de iptables são suficientes em caso de uma máquina ser apenas cliente, isto é, não ser servidor e nem roteador. Publiquei esta configuração porque muitos usuários se perdem com scripts gigantes genéricos no estilo faz-de-tudo-e-mais-um-pouco (inclusive coisas desnecessárias).

A idéia é bem simples:

1. a máquina pode enviar QUALQUER PACOTE (OUTPUT em ACCEPT);
2. só entra na máquina o que for resposta de uma requisição feita pela máquina;
3. um cuidado para não DROPAR a interface lo usada para comunicação local.

A ausência de qualquer parâmetro, como interface, endereço, protocolo, etc o faz atuar sobre qualquer pacote. Resposta TCP e UDP casam com o STABLISHED enquanto que ICMP casa com o RELATED (entre outras coisas).


Observe mais uma vez: pode sair TUDO (OUTPUT em ACCEPT), mas só pode entrar o que for resposta (regra 4), sendo que tudo o mais que deveria entrar, se não for da lo é DROPADO (última regra).

Vos garanto que uma máquina cliente não precisa nada mais além disso!

[1] Comentário enviado por JosuéDF em 11/09/2007 - 09:20h:

Mais um da Série "A Simplicidade da Genialidade" :D

[2] Comentário enviado por randra em 11/09/2007 - 11:09h:

mando bem elgio, quero fala ctg no msn manda por pm ai pra mim!


abraço

[3] Comentário enviado por oletros em 11/09/2007 - 11:29h:

Prezado Elgio,

Boa dica, apenas recomendo as seguintes modificacoes:

iptables -P INPUT DROP #ao inves de accept
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

iptables -A INPUT -i lo -j ACCEPT #ao inves do not (!) e drop

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

Justificativa:

Em um desktop, eh comum usarmos KDE ou GNOME, cujos processos se comunicam via interface loopback (lo, 127.0.0.1), alem de outros daemons do linux que tambem a utilizam.

Como o modulo state (conntrack) tem um numero limitado de slots para conexao (8192 conexoes para cada 128mb de RAM - cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max) e precisa checar se cada pacote esta na tabela de conexoes (cat /proc/net/ip_conntrack), usa-lo para controlar o loopback tem alguma penalidade de performance.

Vem dai minha sugestao:

iptables -P INPUT DROP
#por politica padrao, nenhum pacote entra

iptables -A INPUT -i lo -j ACCEPT
#pacotes da loopback passam direto

Desta forma, se o host (nosso desktop) iniciar uma conexao, o retorno da mesma sera aceito. Caso contrario, dropado.

ATENCAO: em caso de torrent, lembrar de liberar as portas do mesmo:
iptables -A INPUT -p tcp --dport <porta_do_torrent> -j ACCEPT

E logico, seguir esta liberacao se desejar liberar para outros servicos (ssh - porta 22)
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

Mas parabens Elgio pela inciativa da divulgacao do script.

Abracos

Anderson

[4] Comentário enviado por angelomr em 11/09/2007 - 11:51h:

Como seria se eu quisesse Fechar todas as conexões, mas só quisesse deixar aberto (entrada) SSH (22) e HTTP (80)?

[5] Comentário enviado por elgio em 11/09/2007 - 11:54h:

Otimo Anderson!

Bem pensado tua otimização.

Fica assim então o script OTIMIZADO para maior performance:

ptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Muda uma pequena coisa e muda muito em desemepenho já que não irá montar contrack para lo!

Muito BOM!

[6] Comentário enviado por elgio em 11/09/2007 - 11:59h:

Para ir liberando serviços (e no caso tua máquina é SERVIDOR e não mais desktop) é só ir colocando outras regras de INPUT antes do DROP. Neste caso específico que você falou e já mudando um pouco seguindo a dica do nosso amigo Anderson (muito embora istoperca a beleza de "firewall em 5 linhas"):

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

iptables -A INPUT -i lo -j ACCEPT

iptables -A INPUT -p tcp --syn --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --syn --dport 22 -j ACCEPT

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

(veja que mudei a politica INPUT para DROP, para economizar uma linha do script... hehehe. Ah, e com o mudulo multiport as duas linhas do syn podem virar uma única)

[7] Comentário enviado por pardalz em 11/09/2007 - 20:15h:

sugiro para usuarios inesperientes (como eu) instalar o firestarter e adicionar as regras por ele, eu fiz isso aqui no meu kurumin, o firewall ta muito bom.. do jeito q eu keria.. depois q adicionar e as regras de uma estudada no firewall.conf, tb é util para aprender, as linhas ficam comentadas etc e tal..

[8] Comentário enviado por dnortiz em 12/09/2007 - 08:52h:

Achei muito bom... Um script simples mas muito funcional.

[9] Comentário enviado por elgio em 12/09/2007 - 10:11h:

Oi Anderson.

Você escreveu:
"
ATENCAO: em caso de torrent, lembrar de liberar as portas do mesmo:
iptables -A INPUT -p tcp --dport <porta_do_torrent> -j ACCEPT
"

Isto me passou desapercebido, mas tráfego de torrent deveria casar com o STABLISHED/RELATED certamente!! Se assim não o fosse, ninguém que está atrás de um NAT (como usuários domésticos em seu modem ADSL) teria o serviço de torrent, pois no NAT só entra mesmo conexões que já estejam relacionadas, para as quais já exista uma entrada na tabela de estado do modem (claro, exceto se o modem tenha sido configurado de outra forma).

Isto quer dizer que mesmo no torrent, é sempre o cliente quem inicia a conexão, deixando-a aberta.

Não conheço bem os protocolos torrent, mas pela minha análise de NAT, não poderia ser diferente, certo?

[10] Comentário enviado por yoshiki em 13/09/2007 - 10:57h:

Quando tentei executar a linha última linha, aconteceu isso:
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables: No chain/target/match by that name

Em uma mákina rodando o deb 4 etch. Ajuda é bem vinda =D

[11] Comentário enviado por oletros em 21/09/2007 - 18:43h:

Prezado Elgio,

Apesar do protocolo bittorrent funcionar sem precisar da liberacao das portas, isto eh interessante para aumentar a velocidade de download e ao mesmo tempo ser justo com os outros downloaders.
Justificativa:

[12] Comentário enviado por oletros em 21/09/2007 - 18:56h:

Prezado Elgio,

Apesar do protocolo bittorrent funcionar sem precisar da liberacao das portas, isto eh interessante para aumentar a velocidade de download e ao mesmo tempo ser justo com os outros downloaders.

Justificativa:

http://www.guiadohardware.net/dicas/bittorrent-tras-firewall-ou-nat.html

Quando o client torrent tem uma porta liberada para conexao, esta porta permite ao tracker remoto enviar uma solicitacao de download de arquivos ja disponibilizados, mesmo que voce nao esteja baixando nada no momento.

Esta eh a beleza do torrent; compartilhar banda e download atraves de diversos micros.

Voce baixou um arquivo e o deixa disponivel para que terceiros tambem possam baixa-lo.

Alguns clients, como o azureus (que eu uso) avisam quando voce nao esta liberando a conexao, e consequentemente, diminuindo a sua taxa de download por nao permitir o compartilhamento automatico.

So lembrando que o range padrao do torrent eh das portas 6881 a 6889, mas que pode ser alterado no client torrent.

Mas usar as portas padrao pode dar chance para o traffic shapping (limitacao de banda pelo provedor para protocolos P2P), assim recomendo ainda usar outra porta e criptografia (tudo isso ajustavel diretamente no cliente bittorrent).

Abracos

Anderson

[13] Comentário enviado por elgio em 21/09/2007 - 19:11h:

Beleza.
Entendo perfeitamente.

Só que 99% dos clientes não fazem isto: teriam que configurar OS SEUS MODEMs adsl.

:-D

[]'s

[14] Comentário enviado por removido em 01/10/2007 - 08:50h:

Olá, Primeiramente parabéns pelo seu artigo. Estou usando seu firewall há cerca de um mês e estou satisfeito. Tenho uma dúvida e gostaria de saber se
você pode me ajudar. Eu comprei um notebook e estou acessando via wireless
e consigo imprimir via rede (já configurei o cups). O problema é que o firewall está bloqueando a impressão. Gostaria de saber como eu libero neste script de firewall para eu conseguir imprimir via rede pelo notebook.
Obrigado.

[15] Comentário enviado por elgio em 01/10/2007 - 09:11h:

Pelo que pude observar a porta do cups é a 515 TCP.

Quem bloqueia? O firewall do notebook?
Vamos ver...

tenta por nele a regra:
iptables -I INPUT -p tcp --dport 515 -j ACCEPT
iptables -I INPUT -p tcp --sport 515 -j ACCEPT

Mas não estou certo, pois não sei se entendi direito o teu cenário...

Qualquer coisa, no firewall script, antes de bloquear os pacotes faz um
log para ver o que está sendo bloqueado:

iptables -P INPUT ACCEPT
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

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

iptables -A INPUT -i ! lo -j LOG --log-prefix "BLOQUEIO "
iptables -A INPUT -i ! lo -j DROP


Ai, depois de por no ar, fica fazendo um:
tail -f /var/log/messages |greo BLOQUEIO

Enquanto tu tenta imprimir. Ai vais ver o que foi bloqueado.

[16] Comentário enviado por removido em 01/10/2007 - 15:18h:

Quem tá bloqueando é o pc. Eu fiz isso aqui e funcionou, ve se tá certo.
Eu coloquei o IP do notebook e a porta 631 do cups. Para imprimir tá tudo bem, agora será que não tem alguma falha de segurança?

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

iptables -A INPUT -i lo -j ACCEPT

iptables -A INPUT -s 192.168* -p tcp --dport 631 -j ACCEPT

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

[17] Comentário enviado por renatoptr em 11/02/2008 - 20:35h:

?comentario= Muito bom, implementei aqui no meu desktop, nem imaginava que tinham tantos processos externos tentando acessar a minha máquina

[18] Comentário enviado por /bin/laden em 04/12/2010 - 02:34h:

oletros

"... Em um desktop, eh comum usarmos KDE ou GNOME, cujos processos se comunicam via interface loopback (lo, 127.0.0.1) ..."

Na verdade é o próprio servidor X (xorg) quem faz isso, independente do WM ou ambiente desktop utilizado.