class main AboutMe { exec(); }

Caso 1: Servidor com SSH | Firewall Desligada
iptables –F && iptables -X

Pacote 1
Pacote 2
Pacote 3
192.168.171.1->192.168.171.6 | TCP | [SYN] Seq=0 Win=1024 Len=0 MSS=1460
192.168.171.6->192.168.171.1 | TCP | [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
192.168.171.1->192.168.171.6 | TCP | [RST] Seq=1 Win=0 Len=0
Nmap: 22/tcp open  ssh
SSH: rubenalves@192.168.171.6's password:
Explicação: Temos um serviço em funcionamento, sem nenhuma firewall. É enviado um SYN, seguido de um SYN,ACK vindo do remetente, desta forma é sincronizada uma comunicação. Por fim, o emissor envia um pacote RST (reset) para terminar a comunicação entre as duas máquinas (pois, o portscan terminou). Tudo correu como previsto, o nmap mostra o porto 22 aberto, e ao tentar establecer uma ligação por SSH, o servidor distante pede-me por uma password.

Caso 2: Servidor com SSH | Firewall DROP
iptables -A INPUT -p tcp -i eth2 --dport 22 -j DROP

Pacote 1
Pacote 2

192.168.171.1->192.168.171.6 | TCP | [SYN] Seq=0 Win=4096 Len=0 MSS=1460

192.168.171.1->192.168.171.6 | TCP | [SYN] Seq=0 Win=4096 Len=0 MSS=1460
Nmap: 22/tcp filtered ssh
SSH: ssh: connect to host 192.168.171.6 port 22: Connection timed out
Explicação: Temos um serviço em funcionamento, mas com uma regra na firewall que faz DROP a todos os pacotes que entram do porto 22. Ao fazer um port scan no porto 22, acabam por serem enviados 2 pacotes iguais: dois SYN. De facto, são enviados 2 porque como o destinatário não respondeu, tenta enviar outro pacote. Como o destinatário não enviou, o nmap automaticamente detecta que algo foi “DROPADO”. Poe o estado do serviço em modo “filtered”, e quando tentamos estabelecer uma ligação por SSH depois de vários minutos acaba por aparecer uma mensagem de erro com Connection timed out.
O caso 5 mostra como os pacotes transitam na rede quando um serviço está simplesmente desligado.

Caso 3: Servidor com SSH | Firewall REJECT
iptalbes -A INPUT -p tcp -i eth2 --dport 22 -j REJECT

Pacote 1
Pacote 2
192.168.171.1->192.168.171.6 | TCP | [SYN] Seq=0 Win=4096 Len=0 MSS=1460
192.168.171.6->192.168.171.1 | ICMP |Destination unreachable (Port unreachable)
Nmap: 22/tcp filtered ssh
SSH: ssh: connect to host 192.168.171.6 port 22: Connection refused
Explicação: Temos um serviço em funcionamento no porto 22, mas há uma regra na firewall que faz REJECT a todos os pacotes que entram pelo porto 22. Ao contrário do caso anterior, quando o emissor envia um pacote TCP com a flag SYN, o receptor responde com um pacote ICMP a indicar um erro. Neste caso “Port Unreachable”.
O nmap entende este erro como sendo um porto filtrado. Ao tentar fazer SSH, a resposta “Connection refused” é imediata devido ao pacote ICMP que recebemos.

Caso 4: Servidor com SSH | Firewall REJECT com Net Unreachable
iptalbes -A INPUT -p tcp -i eth2 --dport 22 -j REJECT –reject-with icmp-net-unreachable

Pacote 1
Pacote 2
192.168.171.1->192.168.171.6 | TCP | [SYN] Seq=0 Win=4096 Len=0 MSS=1460
192.168.171.6->192.168.171.1 | ICMP | Destination unreachable (Network unreachable)
Nmap: 22/tcp filtered ssh
SSH: ssh: connect to host 192.168.171.6 port 22: Connection refused
Explicação: Este caso é idêntico ao caso 3. No entanto, só mudamos uma regra na firewall: icmp-net-unreachable. Com isto, mostra-se como podemos alterar o erro enviado no pacote ICMP. No entanto, na prática nada é alterado. Emissor continua a ver o porto 22 como filtrado e não consegue ligar-se por SSH.

Caso 5: Servidor sem SSH | Firewall Desligada
iptables –F && iptables -X

Pacote 1
Pacote 2
192.168.171.1->192.168.171.6 | TCP | [SYN] Seq=0 Win=4096 Len=0 MSS=1460
192.168.171.6->192.168.171.1 | TCP | [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
Nmap: 22/tcp closed ssh
SSH: ssh: connect to host 192.168.171.6 port 22: Connection refused
Explicação: Este caso pode ser visto como o de controlo. Pois, quando o serviço está desligado, mesmo sem firewall, são enviados dois pacotes. O SYN do emissor e o erro RST, ACK do receptor. Neste caso o nmap mostra o porto 22 como “closed”, e obviamente qualquer ligação por SSH é recusada.

Conclusão: DROP ou REJECT em IPTABLES? Basicamente o importante é entender que ambos dão informação sobre o serviço. Seja pelo silencio ou pelo erro via ICMP. A questão é simples: saber o que pretendemos devolver como informação na rede. Não podemos aplicar DROP a tudo, caso contrário no caso de querer fazer um debugging à rede a falta de informação pode fazer perder imenso tempo ao analista ou então no caso de um utilizador querer ligar-se a serviço que está DROPADO, terá que esperar imenso tempo até a ligação morrer num timeout. O melhor do dois mundos encontra-se ao fazer DROP nas ligações externas ou críticas, nas quais não é do nosso interesse facultar informação explicita (ICMP). No entanto, em serviços internos ou menos críticos, é do nosso interesse deixar as mensagens de erro circularem pela rede.
Sem comentário, seja o primeiro! | Publicado por Ruben Alves @ 28/11/09 17:27
Escrever um comentário ao texto: "Iptables:DROP.vs.REJECT"
Nome*:
E-mail*:
Página web
(não obrigatório):
"Quanto dá dez mais Catorze"
(Resposta: 20,22 ou 24?)*:
Mensagem*:


  ÚLTIMO MÊS: Agosto 2011

  Sobre.Pessoas.pt (21/08/11)
  Pensamento.dia.em.pleno.Agosto.pt (18/08/11)
  E foi assim que... (18/08/11)
  Julho.em.Imagens.2011 (18/08/11)

  TEXTOS EM ALTA!

  iPhone5 - my predictions.com (07/03/11)
  parvo.que.sou.pt (22/02/11)
  2G,3G,4G e agora 5G! (08/02/11)
  Novo.Projecto:Pedra-alta.com (01/02/11)
  website.updates-status-v1.pt (30/01/11)



FOTOGRAFIA ALEATÓRIA: Paranoia em Panóias.

Paranoia em Panóias.

Ruben... Quem sou? Nascido em Novembro de 1980, Sagitáriano puro e duro com ascendente Aquário. Sou canhoto, adoro arte, computadores, fotografia, redes, programação, design, música. Odeio futebol, bacalhau e injustiça.

Neste momento sou um Jovem de 30 anos, curioso pela vida, curioso por tudo o que mexe, tudo que respira, que faça ruídos. Encanto-me facilmente com uma gota de água a bater no vidro mas não fico impressionado com um Ferrari. Gosto das coisas simples da vida, um olhar, um sorriso, um simples gesto. Adoro amar, como gosto de ser amado. Não troco o meu leitor DVD por uma PlayStation, no entanto trocaria um filme por uma bela fotografia.

Não sou complexo, apenas perplexo... tudo depende do ponto de vista.

[...] Farto de escrever... | pausa II

~~~


No meio de tudo isto, tenho este lugar cibernético. Um recanto pontualmente actualizado, apontado como um blog, mantenho a minha ideia que antes de ter esta pretensão, considero que é antes de mais nada um simples sítio web onde escrevo, descrevo, apresento, coloco perguntas, dúvidas e afirmações. Com os textos, coabitem vários espaços representativos do meu Espaço.

Talvez seja o lugar mais sensato para me conhecer... Ou pelo menos, iniciar-se nesta longa viagem que é o meu Ser...
[...] Farto de escrever..| stop .

Correio.electrónico:
mail AT ruben-alves PONTO com

Telefone:
919.181.***

A minha Página no Twitter.


creative commons