12112010 http://imasters.com.br/artigo/13899/re...

isando_o_threeway_handshake/imprimir/ #1

Júlio Henrique Conceição Sextafeira, 14 de agos to de 2009

Analisando o ThreeWay Handshake

Nes te artigo, irem os verificar na prática o tão fam os o proces s o threeway handshake , utilizado para o es tabelecim ento de conexões tcp.

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.

Analisando o ThreeWay Handshake

Prim eiram ente, é precis o ter o Wires hark ins talado; em s eguida, irem os fazer o download do arquivo tcps hake.zip, que contém um a s eqüência inicial de

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,

vem os a inform ação Flags: 0x02 (SYN) .

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

inform ações cons tam no cabeçalho anterior, Internet Protocol (IP).

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.

Mas com o podem os m elhorar a s egurança em regras de Firewall Linux?

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

Servidor de Correio s eja 200.200.200.20, criam os as s eguintes regras no Firewall:

12112010 http://imasters.com.br/artigo/13899/re...isando_o_threeway_handshake/imprimir/ #2
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
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

(determ inada pelo Sis tem a Operacional), terem os o s eguinte:

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

Então, o que podem os m elhorar nes tas regras ?

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

não s erão es tabelecidas .

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

adquirim os para elevar o nível de s egurança de regras de um firewall linux.

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!