Sunday, July 29, 2012

CSMA/CA X CSMA/CD

Em posts anteriores já falamos de ambos os métodos de contenção de camada dois: CSMA/CD,para redes Ethernet cabeadas,CSMA/CA,para rede Wireless.
  Hoje quero falar um pouco mais dessas técnicas de transmissão,visando o estudo para o CCNA Wireless.
  Se nas redes cabeadas o Switch veio para resolver os problemas de colisão, fazendo com que o CSMA/CD deixe de ter um papel tão importante quanto tinha na Era dos Hubs,criando canais de comunicação Full-Duplex, nas  redes Wireless isso ainda não aconteceu e,talvez, nunca aconteça. Seria como dizer que, em se tratando de redes Wireless, ainda estamos usando Hubs.
  A razão disso é bastante óbvia. A transmissão via ondas de rádio irradiadas pelo ar, não permite criar um canal de comunicação exclusivo entre dois pontos de transmissão da mesma forma que  ocorre nas redes cabeadas, onde isso fisicamente é inerente.
   Na verdade, isso até é possível, usando frequências diferentes. Por essa razão é que quando vamos adicionar um novo AP, temos que verificar se já existe um AP próximo e, se existe, verificar em qual Canal ele está transmitindo. Como já explicado, 802.11b/g possuem 11 Canais e 802.11a/n 23 Canais, dessa forma, se  você observar que já existe um outro AP usando o Canal 1, instale o novo AP no Canal 6. Isso porque os Canais 1,6 e 11 não se sobrepoem. Entretando, é óbvio que haverá APs operando nos mesmos Canais. Apesar de ser possível, como podemos ver abaixo, dificilmente você irá conseguir tal proeza em uma grande cidade por exemplo.



 
  Fonte: http://technet.microsoft.com/en-us/library/cc783011%28v=ws.10%29.aspx

 Porém, isso ainda não é tudo. Mesmo que os APs operem em frequências diferentes, o Clients irão usar as mesmas frequências. E além de tudo isso, ainda tem outras formas de interferência como  Fornos Micro-ondas, aparelhos telefonicos sem fio,etc.

Dessa forma, é preciso que a tecnologia esteja preparada para enfrentar esse tipo de problema. Por isso a importância do CSMA/CA.

 Vamos um pouco mais a fundo e vamos ver como a comunicação acontece quando estamos usando Wireless. Nesse tipo de tecnologia, usamos três tipos de quadros:
-Quadros de gerenciamado
-Quadros de controle
-Quadros de Dados.

  Sendo uma tecnologia Half-duplex, para o envio desses quadros, é preciso se certificar de que o meio está livre.Tal como acontecia em redes Cabeadas quando eram usados Hubs.
  A porção CS (Carrier Sense) é responsável por isso. Ela faz isso através da técnica chamada de Clear Channel Assesstmente (CCA), em resumo isso significa: Ouça o meio antes de transmitir.
  As redes Wireless ainda enfretam um outro problema conhecido como "Hiden note problem",ou, problema do nó escondido, em que um client pode não  'ouvir' o outro,causando colisão na transmissão. Para solucionar esse problema, as redes Wireless usam a técnica chamada de Virtual Carrier Sense (VCS).
  Outra técnica peculiar as redes Wireless é o IFS. IFS é o período  de espera para a transmissão. A função do IFS vai além de garantir o envio de quadros sem colisão. Em redes Wireless é preciso que seja definida ainda a prioridade dos tipos de quadros. Isso é conseguido, definindo periodos de transmissão inter-quadros, como segue:

-SIFS: Short Interframe space.
Se um client ou AP precisa enviar um quadro de alta prioridade, por exemplo, um ACK, ele ira´enviar nesse intervalo. Isso garante que esse quadro não seja  interpretado erroneamente.

-PIFS: Point Coordinations Interframe space.
Usado quando o AP é quem controla a transmissão dos quadros.

-DIFS:Distribution-coordinations Interframe space.

Usado em transmissões de quadro de dados.

Agora vamos compreender como funciona o IFS. O periodo de espera para a transmissão de um quadro e qual a tratativa dada caso esse tempo tenha que ser re-dimensionado.

O algoritmo funciona da seguinte forma:

1- Client A escolhe um valor entre 0 e 31.
2-Consideremos que o Client A escolheu 29. Ele irá descrementar esse número: 29,28,27...Enquanto isso ele continuará escutando o meio afim de observar se não há ninguem transmitindo. Escutando o meio significa,acima de tudo, envio de SIFS. A cada SIFS enviado,slot time,é decrementado 1 no backoff.
3-Supondo que quando estivesse em 18, um outro client, client B começa a transmitir. No quadro desse client B, existe uma informação chamada de Duration Value, Valor de Duração. Esse valor será usado pelo Client A, para reprogramar sua contagem. Esse valor presente no Quadro de B é chamado de NAV, Network Allocation Vector. Na verdade, é o tempo gasto para um quadro do tipo SIFS, como visto acima, para ida e volta.  Em redes Cabeadas isso é chamado de Slot Time. Tempo de ida e volta de uma quadro.
 Esse tempo em ambas as redes é influenciado pelo meio, no caso de redes Wireless,depende do padrão,como deveremos abaixo.
4-O valor 18, ponto onde estava o client A até perceber que B enviou um quadro, é somado ao Valor 45, Duration Value, e passa ser o novo tempo que A deverá decrementar até poder transmitir. Ou seja, ele comecará e 63,62,61....

5- O client A decrementou até 0 e não foi observado outra transmissão de quadro, então o meio está livre e ele pode enviar seu quadro.

Caso ocorra colisão após esse processo, o algoritmo inicia novamente,porém, agora de 0 até 127.

O processo não é tão diferente do usado pelo CSMA/CD.

Todo o processo de envio de quadro é conhecido como Distributed Coordination Function (DCF) e caracteriza-se pelo Client coordenando de forma autonoma o envio de quadro como forma padrão.
 Uma alternativa para esse processo é o Point Coordination Function (PCF) onde o AP fica responsável por coordenar o envio de quadros.

    Abaixo segue  uma interessante figura:








Podemos ver claramente aqui a questão da Interoperabilidade entre diferentes tipos de padrão IEEE. Vejam que 802.11g e 802.11n operam em intervalos de IFS e Slot Times diferentes afim de coexistir com padrões anterirores.

  Dessa forma discutimos um pouco mais sobre técnicas de transmissão. Se nas redes cabeadas esse assunto perdeu importância com o desenvolvimento dos Switches e a consequênte comunicação Full-Duplex, nas redes Wireless isso ainda é um desafio. Como dito acima, talvez isso nunca mude para essa tecnologia considerando a natureza de seu meio físico.
  O fato é que os fabricantes tem conseguido encontrar meios de resolver as complicadas equações que envolvem essas limitações e conduzir as redes Wireless ao patamar de mais importante forma de comunicação. Como também já dito anteriormente, as redes Wireless tem ganhado cada vez mais importância no dia-a-dia por razões óbvias: A comunicação requer antes de tudo mobilidade!

 Até o próximo post rumo ao nosso CCNA Wireless!



Sunday, July 15, 2012

ASDM 6 no ASA 8





Se alguma vez ao tentar abrir o ASDM usando GNS3 você se deparou com esse erro, hoje vamos dar a dica de como tratá-lo.

  Todos os créditos ao Blog :
http://7200emu.hacki.at/viewtopic.php?t=2187&postdays=0&postorder=asc&start=240

A causa:

hofw004# sh ver

Cisco Adaptive Security Appliance Software Version 8.0(2)
Device Manager Version 6.0(2)

Compiled on Fri 15-Jun-07 19:29 by builders
System image file is "Unknown, monitor mode tftp booted image"
Config file at boot was "startup-config"

hofw004 up 26 mins 58 secs

Hardware:   , 128 MB RAM, CPU Pentium II 2097 MHz
Internal ATA Compact Flash, 256MB
BIOS Flash Firmware Hub @ 0xffe00000, 1024KB


 A linha Hardware em destaque, nos trás a dica do problema. Veja que antes da vírgula deveria vir uma informação e não temos. Essa informação é o Hardware ID. Essa informação é trocada no momento da conexão do ASDM com o servidor HTTP do ASA.

A solução:

A solução encontrada é enganar o ASDM usando um proxy. Essa solução é genial e nos dá uma amostra de como as coisas podem ocorrer em ambientes de rede. O poder de proxies no gerenciamento de conexões e o risco ao qual todos estão expostos.

  A programinha que fará a mágica chama-se Fiddler2.

Baixe o programa de :

http://www.fiddlertool.com/fiddler/

 Abaixo mostro a interface do nosso Proxy:




 Vamos configurá-lo:

Você irá precisar da classe em Java presente no seguinte link:

http://www.networksa.org/wp-content/uploads/2010/06/fiddler.CustomRules.js.txt

Copie essa classe em um bloco de notas porque a usaremos logo em seguida.

Após abrir o programinha, vá na aba "Rules"> "Customize Rules",como abaixo:




 


A janela aberta será uma um arquivo txt chamado CustomRules. Tudo que você têm a fazer é substituir essas linhas por aquelas copiadas no link  acima.


Agora vamos configurar nosso Java.



No painel de Controle, click em Java, click em Network Settings... e deixe como a janela acima.

 Estando tudo configurado, vamos fazer o seguinte teste. Vamos tentar acessar o Firewall com o ASDM sem  o Proxy:



Veja na capitura do WireShark  toda a "Conversa".


 Primeiro, no quadro 49, ocorreu o envio do SYN pelo Client ASDM :



Depois, no Quadro 50, houve a resposta SYN/ACK do Firewall:



Como não poderia deixar de ser, o Client ASDM responde ao SYN do Firewall com um ACK. Está fechado o Three-Way-Handshack.

  " Isso é uma poesia para min"..rsrsrs




 Fechado a conexão TCP, o client ASDM inicia uma conversa segura com o Firewall enviando um Hello SSL. SSL é Secure  Sockets Layer também conhecido como HTTPS.
 
O Hello do Protocolo SSL:



O Firewall responde com um ACK:





O Firewall envia no próximo Quadro um "Server Hello":



 O Client responde com um ACK ao Server Hello:



O client envia sua Chave:



ACK do Firewall  a chave enviada






O Firewall  envia as informações (PUSH). Nesse momento a informação de Hardware ID irá como "Null".

 

Client envia ACK:



E na sequência podemos presenciar no exato momento em que o client envia o Reset na conexão:



 Acima foi a conversa TCP sem o Proxy, culminando com o Reset da conexao:



Agora vamos fazer um outro teste. Vamos deixar o Fiddler2 aberto,porém, não vamos fazer o Spoof nos pacotes HTTPS.




O resultado é o pacote passando de forma ´natural´ pelo Proxy. Sem a informação do Hardware ID. Consequentemente, iremos ter o erro.


 





Abaixo, como o problema é contornado com o uso do Proxy.

Aqui a parte do Codigo que engana o ASDM:

    // Note that you really should also fix your .NET code to gracefully handle unexpected connection closure.
        //
        // if (!(((oSession.responseCode == 401) && oSession.oResponse["WWW-Authenticate"].Length > 9) ||
        //  ((oSession.responseCode == 407) && oSession.oResponse["Proxy-Authenticate"].Length > 9))) {
        //   oSession.oResponse["Connection"] = "close";
        // }
        if (oSession.url.Contains("/show+version")) {
            oSession.utilDecodeResponse();
            oSession.utilReplaceInResponse('Hardware:   ,','Hardware:   ASA5520,');
        }
    }
       

    static function Main()


O exato momento em que nosso proxy Fiddler engana o ASDM. Nós vimos acima que essa informação não aparece no comando "Show Version", mas aparece aqui como "ASA5520". Ou seja, o Proxy faz um Spoof no pacote que vem do Firewall e acrescenta a informação de Hardware.






Abaixo o ASDM aberto.

 


ASDM é uma excelente ferramenta. Se as atividades a serem realizadas no Firewall envolve visualização de informações, ASDM é o que há. Eu prefiro linha de comando sempre por uma série de razões, mas não há a menor dúvida que ter ASDM à disposição é muito útil.

  Dessa forma concluo mais esse Post. Não há muita dificuldade em seguir os passos acima.
  Parabéns ao carinha que postou a solução. Descobrir uma forma de enganar o ASDM foi genial.

Até o próximo!