ruben-alves.com

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

Iptables:DROP.vs.REJECT @ 28/11/09 17:27 | Ruben Alves  

Fotografia Aleatória

luzSempreAparece.jpg

Ruben... Quem sou? Para muitos sou webmaster de vários sites, para outros um freelancer 5 stars, um aluno esforçado, um "stor" daqueles que vou ter saudades, um amigo do carago, um tipo bacano, para outras já fui namorado, também sou um irmão mais velho e finalmente para dois outros sou um Filho...

Neste momento sou um Jovem de 29 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, talvez um 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

~~~


O que faço da vida? Como tantos, ando por aí, vivo, estou vivo (e bem vivo, mais do que nunca talvez).

Estou neste momento a trabalhar numa empresa de IT em Lisboa, onde trabalho como Administrador de Redes. Também posso ser programador freelancer (PHP, html, MySQL), webdesigner, tal como explicador, professor, empregado de mesa...

O que já fui? Estudante em Mestrado em Redes da Fac. de Eng. da Universidade do Porto (FEUP). Também fui estudante em pós-graduação em Redes da fam.Lusiada, estudante em Multimédia no ISMAI. Também passei pelo estado de professor de vídeo e multimédia, dei workshops de Linux, programador em PHP no Tecmaia, webdesigner na Designarte ...

[...] Farto de escrever..| stop .

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

Telefone:
93.440.****

creative commons


» textos «
» projectos «
» fotografias «