[GTER] Experiência sobre Criptografia em Redes Locais

Edgar Shine eshine at gmail.com
Thu Sep 8 11:40:05 -03 2005


Essa tem mais cara do GTS... ;)

Comentarios inline.

sd,
Edgar

Lao DanTong escreveu:

>On Wed, 7 Sep 2005, Hideki Nakamura wrote:
>  
>
>>com criptografia do tráfego de uma rede local. Estamos desenvolvendo nosso trabalho baseado no Windows 2003 Server e Windows XP Professional que oferecem suporte a IPSec, através de diretivas de grupo. Apesar de estar sendo aplicado aos produtos Microsoft na nossa monografia, o o foco é a criptografia do tráfego em redes locais. Sei de várias empresas utilizando IPSec para VPN, Wireless, etc. Porém, não tenho conhecimento de organizações que fazem o uso de criptografia em suas redes locais (em qualquer escala - 10, 1000 ou 10.000 hosts, exceto em casos isolados como SSH).
>>    
>>
>pode haver motivos para cifrar o tráfego local (medo de espionagem via 
>wire-tapping, por exemplo) mas há excelentes motivos para não fazê-lo 
>(impossibilidade prática de realizar certos diagnósticos), há que pesar com cuidado os prós e contras. Em princípio não acho sensato cifrar todo o tráfego da rede, deixando o assunto para um nível mais alto, aplicações que sejam sensíveis que usem TLS ou redes virtuais IPsec sobre a rede local.
>
>Note que voce não estará livre da interceptação pois os usuários dessa 
>rede cifrada tem que ter acesso aos certificados, de modo que também tem como fazer o chamado "man in the middle".
>existem switches que tem criptografia embutida, seria bom conhecer estes  equipamentos.
>  
>
Existem certos ptos abordados nesse paragrafo e solucoes diversas. Se 
falamos em wiretapping poderiamos utilizar 802.1x para auth e limitar o 
acesso fisico da rede local.
Do outro pto, alguem poderia tentar capturar dados sensiveis em modo 
promiscuo. Mas dominio de broadcast pode ser limitado de algumas 
maneiras. Hj existem switches q fazem vlan por protocolo, porta...
Enfim, criptografia pode ser interessante, mas ha problemas praticos na 
implementacao (q vc bem lembrou...).

>>Monografia à parte, gostaria de receber um retorno dos integrantes dessa lista, sobre suas experiências com esse tipo implementação, independente de plataforma, os motivos que os LEVARAM a fazer isso (por exemplo, "porque tivemos um caso de interceptação de dados na nossa rede local"), os motivos pelos quais NÃO FIZERAM ou NÃO VÃO FAZER isso (por exemplo, dúvidas quanto a performance ?), em que protocolos estão fazendo isso (por exemplo, correio eletrônico, servidor de arquivos, etc) e em que escala (TODA A REDE ? 10 % ?
>>20 % ?). Entendo que isso faça sentido em vários casos, afinal muitos de nós usamos SSH ao invés de Telnet, por motivos semelhantes.
>>    
>>
>a razão para usar ssh em vez de telnet é o fato de que telnet passa a 
>senha em texto claro. o engraçado é que ftp, http, pop, imap, etc. também passam senhas em texto claro e causam muito menos espécie que o famigerado telnet.
>  
>
O "famigerado"nao somente trafega dados em plain-text, como tbm nao tem 
controle de sessao, portanto suscetivel a session hijack. Caso a sessao 
raptada seja uma sessao com um alto nivel de privilegios da para fazer 
um estrago consideravel.

>se o objetivo é proteger senhas, todos os protocolos em que senhas 
>transitam em claro devem rodar em baixo de SSL. Note que é muito mais 
>seguro passar senha em texto claro em canal seguro do que passar senha 
>cifrada em canal aberto. Senha cifrada em canal aberto é equivalente a 
>texto claro. estas considerações independem de estarmos falando de LAN ou WAN.
>  
>
Como vc sabe, autenticacao eh apenas uma parte do processo. Qdo pensamos 
em seguranca na rede geralmente pensamos em privacidade e autenticidade. 
Penso q para processo temos q pensar no q eh razoavel para uma seguranca 
relativa e eficiente. Criptografia nao eh a unica solucao para todos os 
casos.




More information about the gter mailing list