Escolar Documentos
Profissional Documentos
Cultura Documentos
isando_o_threeway_handshake/imprimir/ #1
Por que digo que s erá na prática? Porque irem os utilizar o Wires hark para analis ar um conjunto de pacotes que foram trocados durante o es tabelecim ento de
um a conexão; para ver a teoria que envolve o threeway hands hare, s ugiro cons ultar a Wikipedia.
Ao final, tam bém verem os com o utilizar as inform ações adquiridas para elevar o nível de s egurança em regras de um Firewall em Linux.
es tabelecim ento de conexão TCP. Depois , irem os des com pactálo e abrir o arquivo tcpshake.cap através do Wires hark.
Selecionando o prim eiro pacote, verem os s eus detalhes na janela abaixo. Vam os expandir o últim o cabeçalho, Transmission Control Protocol (TCP); ali,
Is s o s ignifica que es te prim eiro pacote es tá tentando es tabelecer um a conexão; ou s eja, o endereço de origem (IP 130.57.20.10, que cham arem os de cliente )
através da porta TCP 1026 es tá tentando conectars e à porta TCP 524 no endereço de des tino (IP 130.57.20.1, que cham arem os de Servidor ); es tas
Em s eguida, vam os s elecionar o s egundo pacote na janela s uperior; abaixo, no Cabeçalho TCP, tem os a inform ação Flags: 0x12 (SYN, ACK) .
Is s o s ignifica que o Servidor aceitou a conexão naquela porta (ou s eja, há um s erviço res pondendo às requis ições ) e enviou um aceite (ACKnowledgem ent)
ao cliente.
Ao s elecionarm os o terceiro pacote na janela s uperior tem os , no Cabeçalho TCP, a inform ação Flags: 0x10 (ACK) .
Ou s eja, o cliente inform a ao Servidor que recebeu s eu aceite, e que pode es tabelecer a conexão.
São trocados três pacotes iniciais para o es tabelecim ento de um a conexão, então, tem os aí o ThreeWay Hands hake (ou, traduzindo, aperto de m ão de três
vias ).
Se qualquer um des tes pacotes for perdido, a conexão não poderá s er es tabelecida.
Ambiente proposto
Vam os s upor que precis am os liberar aos us uários da rede interna aces s o a um Servidor de Correio que es tá localizado na Internet (geralm ente, em um
provedor). As s im , para que os us uários pos s am enviar e receber s eus em ails , devem s er liberadas as portas 25 e 110. Então, s upondo que o endereço IP do
dport 25
j ACCEPT
iptables
A FORWARD
d 192.168.0.0/24
s 200.200.200.20
sport 25
j ACCEPT
iptables
A FORWARD
s 192.168.0.0/24
d 200.200.200.20
dport 110
j ACCEPT
iptables
A FORWARD
d 192.168.0.0/24
s 200.200.200.20
sport 110
j ACCEPT
Des te m odo, liberam os as m áquinas para aces s ar as portas neces s árias , e tam bém o retorno das conexões (lem bres e do threeway hands hake).
Observação: para alguns is s o pode parecer es tranho, m as já vi regras criadas exatam ente des ta m aneira.
Porém , nas regras de retorno, abrim os um a brecha de s egurança: s e alguém tom ar o controle do Servidor do Provedor, e iniciar um a conexão através dele,
utilizando um a das portas liberadas (25 ou 110) com o origem , es te Servidor poderá conectars e à QUALQUER porta de qualquer m áquina da rede Interna. E
is s o não é bom .
Tentando es tabelecer um a conexão com um a m áquina na rede Interna (um s ervidor de em ail local, por exem plo) utilizando um a porta randôm ica
# telnet 192.168.0.9 25
Trying 192.168.0.9...
telnet: Unable to connect to remote host: Connection timed out
A tentativa atingirá o tem po lim ite (tim eout) e s erá encerrada.
Porém , s e a porta de origem es pecificada for um a das portas liberadas (a porta 25, por exem plo), terem os :
# nc
p 25 192.168.0.9 25
220 localhost.localdomain ESMTP Sendmail 8.14.3/8.14.3; Thu, 13 Aug 2009 00:46:05
0400
Pronto! Conexão es tabelecida.
Nota : Obviam ente, há um pouco de exagero aqui; nes te cenário fictício, para que alguém pos s a entrar em um Servidor na rede interna através do Provedor, é
neces s ário que haja tam bém um a regra de DNAT no Firewall Linux, perm itindo que um endereço válido na Internet s eja traduzido para um endereço interno.
De qualquer form a, es tam os cam inhando para tornar as regras m ais s eguras .
Podem os configurar as regras de retorno para que não aceitem que as conexões s ejam iniciadas a partir do provedor. Elas , então, ficariam des ta m aneira:
iptables
A FORWARD
s 192.168.0.0/24
d 200.200.200.20
dport 25
j ACCEPT
iptables
A FORWARD
d 192.168.0.0/24
s 200.200.200.20
sport 25 !
syn
j ACCEPT
iptables
A FORWARD
s 192.168.0.0/24
d 200.200.200.20
dport 110
j ACCEPT
iptables
A FORWARD
d 192.168.0.0/24
s 200.200.200.20
sport 110 !
syn
j ACCEPT
Onde o ! syn s ignifica que s om ente pacotes com a flag SYN desabilitada s atis fazem a regra.
Com as novas regras configuradas , a m es m a tentativa de conexão executada anteriorm ente res ultará em :
# nc
p 25 192.168.0.9 25
(UNKNOWN) [192.168.0.9] 25 (smtp) : Connection timed out
As conexões originadas na rede local com des tino ao s ervidor do provedor terão s uces s o; porém , conexões originadas no provedor com des tino à rede interna
Conclusão
Através do Wires hark e de um a captura exem plo, analis am os o proces s o de es tabelecim ento de um a conexão tcp; além dis s o, utilizam os as inform ações que
Nes te artigo, tam bém foi utilizado o netcat para es tabelecer um a conexão com um a porta de origem prédeterm inada. Mais inform ações s obre ele podem s er
obtidas aqui.
Até a próxim a!