Caso 1: Servidor com SSH | Firewall Desligada |
|
| 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 |
|
| 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 |
|
| 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 |
|
| 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 |
|
| 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
ÚLTIMO MÊS: Junho 2010
Dia.8: Moto 4 e jantar de despedida (22/06/10)Dia.7: O Misterioso Caso do Casal Português (22/06/10)
Dia.6: Red Sea e Snorkeling (22/06/10)
Dia.5: Aproximação teórica aos nómadas do deserto (22/06/10)
Dia.4: L como Lundi e como Luxor (21/06/10)
Dia.3: Hoje não faço nada, hoje é domingo (09/06/10)
Dia.2: Egipto: Estou oficialmente de férias.pt (08/06/10)
Dia.1: O.início.do.principio.pt (06/06/10)
Happy.now.pt (06/06/10)
O.melhor.apaga.fogos.pt (06/06/10)
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.
~~~
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.****
