Mostrando postagens com marcador Cisco. Mostrar todas as postagens
Mostrando postagens com marcador Cisco. Mostrar todas as postagens

terça-feira, 2 de março de 2010

Cisco Port Security

Buenas!

Mais uma breve postagem sobre segurança de portas em Switches.
Para fazermos um switch funcionar, basicamente precisamos comprá-lo, ligá-lo na energia e plugarmos os hosts em suas portas. Simples e fácil. Isso é uma opção dos fabricantes em tornar o dispositivo o mais fácil possível, porém todos os fabricantes recomendam fortemente configurações avançadas de segurança. 

Uma delas é o Port Security que trata-se de uma tecnologia para limitar e controlar a quantidade de dispositivos ligados em uma porta. Imagine a situação na qual você tem uma sala isolada em sua empresa com apenas uma porta LAN liberada para a única estação de trabalho que se encontra nessa salinha. Essa estação controla algumas câmeras IP e precisa estar sempre conectada mesmo que quase ninguém vá até a sala. Hehehe, que exemplo... : ).

Bom, mas onde eu quero chegar é que qualquer pessoa pode entrar nessa sala, plugar um HUB nesse ponto de rede, ligar a estação no HUB e mais um notebook. Pronto! Teremos uma máquina estranha conectada em nossa rede sem o nosso conhecimento e que pode estar transmitindo vírus, fazendo varreduras ou mesmo DoS na nossa LAN. Esse é um exemplo de risco com switches mal configurados.

Com Port Security podemos especificar que essa porta aceitará tráfego de apenas um  (ou mais) MAC Address e caso um segundo MAC tente trafegar por essa porta, caracterizando a situação acima, o Swicth tome algumas ações automaticamente:

protect: Simplesmente descartará qualquer pacote vindo desse MAC não autorizado.
restrict: Fará a mesma coisa que o protect além de também enviar TRAPs SNMP informando o que está ocorrendo.
shutdown: Essa é a mais drástica. Dará um shutdown administrativo na porta, o que significa que ela só voltará a funcionar se o administrador conectar no switch e mandar a porta funcionar novamente.

Particularmente acho a opção restrict mais vantajosa, pois sempre que houver uma violação o "atacante" não conseguira acesso à LAN e ainda poderei ver as informações do que está ocorrendo através do SNMP. Uma dica é utilizar uma ferramenta de monitoramento como o Zenoss para ajudar nessa tarefa.

Caso eu escolha shutdown, por exemplo, posso estar dando chance para o DoS e se um larápio souber disso ele vai se divertir nas suas custas.

Mas como ele fará o controle do MAC?
Podemos optar entre duas formas sendo a primeira manual e a segunda automática.

Mas como, câmbio?
Quando habilitamos Port Security em uma porta, temos que definir a quantidade de MACs que a porta aceitará. Por padrão ela aceitará apenas 1 MAC. Independente do número x de MACs que for configurado, poderemos especificar manualmente esses endereços ou ligar a opção sticky que irá liberar os primeiros x MAC a chegarem na interface. Fique calmo que colocarei os comandos depois. : )

Eu particularmente acho a opção do Sticky muito mais vantajosa pela menor esforço no gerenciamento, mas para estruturas realmente pequenas isso pode ser interessante olhando pelo lado da segurança.

Como configurar?
Exemplo bem breve e prático de como configurar:

! Acessa um range de portas para configurar tudo de uma só vez.
# interface range FastEthernet 0/1 - 24
! Tem que ser interface de acesso. Não pode ser trunk, por exemplo.
(config-if) # switchport mode access
! Habilita Port security.
(config-if) # switchport port-security 
! Define que a porta aceitará apenas 2 MACs.
(config-if) # switchport port-security maximum 2
! Se um terceiro MAC tantar acesso será descartado e traps SNMP serão enviadas.
(config-if) # switchport port-security violation restrict
! Os dois primeiros MAC que passarem pela porta serão cadastrados automaticamente.
! No lugar do sticky também pode ser digitado o MAC caso queira especificá-lo xxxx.xxxx.xxxx
(config-if) # switchport port-security mac-address sticky

Pronto!

Dicas de Segurança:
- Deixe todas as portas configuradas como portas de acesso para evitar que alguém se conecte em uma porta trunk e acesse todas as VLANs.
- Coloque portas que não são usadas em VLANs que não existem.
- Dê um shutdown administrativos em todas as portas que não estão em uso.
- Mantenha um capacitor sempre carregado para dar choque em quem tente atazanar sua LAN.

Em breve falarei sobre o 802.1x.

Abraço!

quinta-feira, 11 de fevereiro de 2010

Como os Switches processam seus frames?

Olá!

Esse é um tópico bem curtinho mas não menos importante para entendermos os Swicthes. O básico do seu funcionamento já sabemos, mas o objetivo aqui é vermos cada vez mais profundamente suas características.

Entendendo essas formas de processamento podemos designar a melhor forma de operação para a nossa topologia e saber o que é mito ou não. hehe

Bom, preciso deixar claro que os termos usados se baseiam em Cisco, pois estou estudando para a CCNA, mas outros fabricantes possuem os mesmo conceitos podendo trocar alguns nomes...

Basicamente os Switches possuem três formas de processamento de frames:
- Store-and-Forward - A padrão em quase todos os switches.
- Cut-through - A que eu menos indico.
- Fragment-free - Bem inteligente.

Store-and-forward
Como já dito acima, esse é o padrão em quase todos os switches (pelo menos nos que conheço). Nesse formato de processamento o swicth irá trasmitir os frames para a porta de destino apenas quando todos os fragmentos desse frame chegarem no switch e forem analisados. É a forma mais segura e confiável para um switch trabalhar. Da para fazer uma analogia com um servidor proxy, o qual só retransmite o site para o destinatário depois que todos os frames chegam e o proxy consegue montar o pacote completo. A única desvantegem desse modo de processamento em relação aos outros é referente à latência. Como ele espera que todos os frames cheguem para depois transmitir isso pode causar uma pequena latência. Mas na prática isso não é problema hoje em dia, pois nossas LANs dificilmente atuam em toda sua capacidade e ainda assim temos velocidades bem altas.

Portanto, é a forma de processamento mais indicada para a maioria dos casos.

Cut-through
Essa é uma opção que na minha opinião não vale a pena. Em um frame ethernet o endereço MAC sempre vem bem no ínicio do frame (nos primeiros bytes). Em um swicth isso é mais do que necessário para ele tomar a decisão de que porta transmitir o frame. Assim que consegue ler o MAC de destino já começa a retransmitir os fragmentos desse frame. Isso causa uma latência realmente muito baixa na comunicação. Os frames serão restransmitidos assim que possível. O problema desse modo é que cada cabeçalho de frame possui um campo chamado FCS que fica mais ao final do cabeçalho. Esse campo tráz um hash de todo o frame no momento em que ele foi gerado. Na outra ponta o dispositivo calcula novamente esse hash e compara com o resultado que veio no campo FCS. Caso seja igual significa que o frame foi transmitido com sucesso e está íntegro. Caso contrário o frame foi corrompido no caminho.

Como nesse modo o Swicth nem chega a ler o campo FCS, o frame é retransmitido mesmo estando corrompido causando uma transmissão desnecessária e consequentemente perda de desempenho na comunicação. Na minha opinião não vale a pena esse ganho na análise do cabeçalho perdendo com transmissões corrompidas. NÃO recomendo.

Fragment-free
Esse é um kra legal. Considero um intermediário entre o Store-and-forward e o Cut-through.
Ele não espera todos os fragmentos e nem lê apenas o DST MAC. Na verdade ele espera os primeiros 64 Bytes de um frame, os quais contém todo o cabeçalho. Dessa forma ele consegue ler informações de MAC e ainda verificar a integridade do cabeçalho evitando a restransmissão de pacotes corrompidos. Talvez seria interessante em estruturas de Cluster sobre LAN.

Conclusão: Usar sempre que possível o primeiro modo - Store-and-forward - pois ele satisfaz praticamente todas as necessidades sem causar perdas consideráveis no desempenho da nossa rede. Na pior das hipóteses use o Fragment-free mas jamais o Cut-throug.

Abração!

segunda-feira, 18 de janeiro de 2010

LAN Switching

Buenas!!

Com esse post inicio uma série de posts relacionados à Networking. Estou estudando pela enésima vez para a CCNA e para ajudar na memoriazação e ainda no compartilhamento de informações publicarei informações quentinhas e sequenciais no decorrer dos estudos....


Conceitos de Switch
Bom, primeiramente vamos ao significado da palavra Switch. Acredito e sempre defendo que entender as origens dos nomes e conceitos é primordial para um entendimento claro. Fica muito mais fácil de memorizar e fazer analogias... Mas enfim... em todos os livros em português que já li sobre network o nome Switch é comumente traduzido para Comutador.

Mas o que é comutar? Pelo menos para mim era uma palavra bem incomum de ser usada no dia-a-dia. Para poupar o trabalho de quem está lendo, já fiz uma boa pesquisa tempos atrás e o melhor significado da palavra (relacionada a networking) está em unir, ou seja, um comutador/switch tem a função de unir equipamentos em um site. Mais especificamente criar uma LAN.

Hub x Switch
Aos conceitos... Normalmente vemos escreverem HUB e não Hub, como se fosse a sigla para algum conjunto de palavras como LAN, WAN, etc. Isso está errado. Hub não é uma sigla. É uma palavra inglêsa que significa cubo e diversas outras palavras. Esse equipamento foi chamado assim devido à uma analogia com as rodas raiadas de carros da época. Tais rodas possuiam um cubo/hub que interligava todos os raios formando uma estrela. Em network o que o hub faz é exatamente isso. Liga os raios/hosts.

Atualmente nem vemos muitos HUBs por aí (Isso me deixa muito feliz). Posso dizer que Hubs são equipamentos defasados e contra-indicados para as nossas nessecidades de networking. Ainda podem ser usados em casa para criar uma pequena rede domestica sob única justificativa de preço ou por administradores de rede para analises de tráfego (sniffing). Tirando essas situações o Hub não possui nenhuma vantagem em relação ao Switch.

Hub é um dispositivo que atua na camada 1 do modelo OSI, ou seja, a única coisa que ele faz e amplificar o sinal elétrico e repetí-lo para todas as suas portas com excessão da porta que recebeu o sinal original. Isso é um caos para a segurança e para o desempenho da rede. Como um mesmo sinal é repetido em todas as portas chegamos a conclusão que apenas um host pode transmitir simultaneamente, ou seja, quando ligarmos uma rede usando Hubs jamais teremos uma conexão Full-Duplex. Será sempre Half-Duplex. Isso causa uma disperdício completamente desnecessário na LAN somado com as colisões que ocorrem caso dois hosts tentem trasmitir ao mesmo tempo. Na prática: Quanto mais hubs na nossa rede, maior será nossa tristeza. : )

Na área da segurança o Hub é o melhor amigo do atacante. Como os sinais são sempre repetidos em todas as interfaces, basta eu estar naquele domínio de colisão que poderei ver QUALQUER informação transmitida pelos hosts desse mesmo domínio.

Extra: Uma vez vi um projetos de Cluster Beowulf de pequeno porte que estava usando Hubs no lugar de Switches sob justificativa que os hubs eram mais rápidos na transmissão de pacotes do que os Switches pois cusavam um delay ao analisar os pacotes na camada 2. Foi bem engraçada a justificativa.
Primeiramente o tempo gasto na análise de camada 2 compensa tranquilamente o tempo perdido com colisões, retrasmissões e half-duplex. Além disso os switches gerenciáveis e semi-gerenciáveis permitem que confuguremos o modo de análise dos pacotes (Store-and-forward, Cut-through e Fragment-free).

Bridge
Bridges/Pontes são equipamentos usados para separar fisicamente pela camada 2 conjuntos de computadores. O que elas fazem é impedir que pacotes de camada 2 passem para o outro segmente desnecessáriamente. Para isso ela mantém uma lista de MAC Address de todos os dispositivos conectados em cada porta dela e quando chega algum pacote até ela, a mesma o retransmite apenas para a porta onde o MAC Address de destino se encontra.

Switch
Finalmente os Switches... Switches são como bridges multiportas, pois funcionam exatamente como as bridges, mas possuem bem mais que duas portas. O correto é ligarmos um host a cada porta do Switch.
Inicialmente e por pouquíssimo tempo, quanto os switches são ligados, atuam como Hubs, porém são dispositivos de camada 2 que trabalham com endereços MAC e toman decisões com eles.

Para tomada de decisões o switch pressisa de um banco de dados com informações de MAC Address conhecidos. Essa tabela chama-se tabela ARP. No momento que o Switch é ligado sua tabela ARP se encontra vazia e sua população ocorre na medida que pacotes vão chegando. Por exemplo, a máquina1 possui o MAC 11:11:11:11:11:11 e está ligada na porta 0/1. Assim que ela mandar um pacote para a rede esse pacote entrará no Swicth pela porta 0/1 e com o MAC de origem 11:11:11:11:11:11. O Switch fará uma associação na tabela ARP entre essa porta e esse MAC e quando o Swicth receber um pacote com destino ao MAC 11:11:11:11:11:11 já saberá que o pacote deve ser encaminhado para a porta 0/1. Isso ocorre sucessivamente até a tabela ficar completa.

Resumo: Para popular a tabela ARP o que importa é o endereço de origem e sempre que um pacote chega no switch a tabela ARP é consultada antes de encaminhar o pacote.

Caso chegue um pacote com destino à um endereço que não consta na tabela ARP daquele switch o mesmo enviará um broadcast (flooding) de camada 2 (FF:FF:FF:FF:FF:FF) pedindo quem possui determinado MAC. Na resposta ele já atualiza a tabela ARP.

Com essa tabela bem definida, o Switch consegue criar circuitos virtuais entre hosts que estão se comunicando, ou seja, uma comunicação ocorrerá somente entre os hosts interessados. Dessa forma o sniffing não poderá ser feito de forma normal e todas as máquinas poderão trafegar em Full-Duplex.

Forward x Filter Decision
A situação descrita acima consiste em Forward, ou seja, o Switch aprende o MAC conforme os pacotes vão chegando e armazena na tabela ARP associado com uma porta.
Quando algum pacote passa por ele, o Switch lê o MAC de destino e consulta sua porta na tabela ARP. Se não existir ele manda um broadcast de camada 2 pedindo quem o possui e armazena na tabela. Caso o MAC de destino esteja na tabela e associado à uma porta diferente da qual o pacote chegou, o switch repassa esse pacote, ou seja, forward.
Caso o MAC esteja na tabela, mas associado à mesma porta que o pacote chegou o switch fará um filter, ou seja, descartará o pacote. Isso caracteriza, por exemplo, uma comunicação entre duas máquinas ligadas à um Hub que está ligado à uma porta do Switch. Não faz sentido o switch repassar esse pacote.

Conclusão: Hub é um lixo comparado aos Switches. Use switches sempre que possivel e seja feliz.

EXTRA: Tabela ARP também é chamada de Content Addressable Memory (CAM) devido ao tipo de memória física usada para isso. Ela é especial para converter IP em MAC muito rapidamente.

Até a próxima.