[GTER] Qual a real ameaça de usar VPN desconhecida?

Douglas Fischer fischerdouglas at gmail.com
Mon Dec 28 14:00:02 -02 2015


Percebo que está havendo um bocadinho de confusão aqui.

E talvez uma superestima do conceito de NGFW(tema que é dúbio por natureza).
   P.S.: Isso tem uma cara de semente plantada
         por vendedor da Palo-Alto que só.

   P.S. do P.S: Palo-Alto É SIM MUITO FODA,
                e não tenho nada contra ela.

   Sugestão: Esqueça a marca, apegue-se ao conceito.

Na minha visão, NGFW é a ferramenta que possibilita identificação e análise
de cada conexão/stream de dados sem necessariamente depender dos
sinalizadores básicos(Ex.: Protocolo e Porta), e faz
in-line(Ponto-Controverso) com performance comparável a side-walk.


Segue um exemplo MUITÍSSIMO superficial:
Uma conexão SSH que foi estabelecida na porta 110 continua sendo uma
conexão SSH.
Como saber disso? Olhe para a silhueta dos pacotes... As tais "assinaturas".

MAAAAAS, não existe mágica!
Esse papinho de que um NGFW pode quebrar criptografia é BALELA!
Ele precisa sim ter as chaves do certificado, seja original ou seja fake,
para ele poder fazer uma inspeção do tipo Man-In-The-Middle.

Então, naquele seu exemplo da conexão SSH que está sendo estabelecida
através de um Tunnel sobre HTTPS(Voltamos a ficar ON-TOPIC) o Firewall de
Nova Geração só vai conseguir identificar que ali por dentro passa um
SSH(independente de porta) se ele para enxergar a silhueta dos dados que
estão passando dentro do HTTPS, e como fazer isso? MITM!

Ou seja, não tem nada de muito especial nessa parada.
O que tem de diferencial(minha opinião) é como cada fabricante faz isso sem
adicionar latência na conexão. Aí entra o bom uso do multicore e do
processamento paralelo, além da virtualização que dá uma mãozinha nisso
tudo.



Um breve re-fork sobre Data Loss Prevention.
É recurso MUITO sério, e que caiu nas graças da verborragia comercial dos
fabricantes de Firewall.
Não é porque a sua caixa possui a capacidade de implementar um ou dois
recursos de inspeção de DLP que seu ambiente vai estar protegido contra DLP.



Em 27 de dezembro de 2015 08:52, casfre at gmail.com <casfre at gmail.com>
escreveu:

> 2015-12-25 23:30 GMT-02:00 Douglas Fischer <fischerdouglas at gmail.com>:
>
> > Em 25 de dezembro de 2015 21:23, casfre at gmail.com <casfre at gmail.com>
> > escreveu:
> >
> > >
> > > Permanece a dúvida: como esses "firewalls de aplicação" lidam, por
> > exemplo,
> > > com o risco de DLP por meio de conexões via tunel com SSH? Se alguém
> usar
> > > essas "VPNs de qualquer um" e, dentro do túnel, usar uma conexão via
> SSH,
> > > ainda se aplica á paranóia/
> > >
> > ​Num ambiente em ​
> >
> > ​que se pensa em DLP, permitir que o usuário(E estou falando de QUALQUER
> > usuário) faça qualquer tipo de conexão para fora que não sejam passante
> > pelos meios que inspecionam o DLP é quebra de protocolo!
> >
> > Em outras palavras:
> > Não tem cabimento falar em DLP num ambiente em que o usuário possa abrir
> > uma conexão SSH para fora. Se não puder ser aberto pelo NGFW, ou pelo
> > e-mail inspector, não passa.
> >
> > Não tive a oportunidade ainda de participar de um projeto de implantação
> de
> > DLP efetivo.
> > Apenas estudei para apresentarmos um... Mas cara, a coisa é
> SERÍÍÍSSSIIIMA!
> > Muito mais política do que técnica. MUITO MAIS!
> >
> > ​Todo o acesso é CASTRADO!
> > - Conteúdo WEB? Lista Branca com aprovação de superior e período de
> > validade(foi aí que tomamos pau).
> > - Protocolos para fora? Só HTTP e HTTPS!
> >   - E o HTTPS só o que aceitava a troca do certificado para o MITM.
> >     A maioria da APPs para celular não aceita.
> >     SPDY não tava dando liga naquela época.
> >     Mesmo HTTPS, o alguns sites em alguns Browsers não aceitam MITM(Ex.:
> > Gmail+Chrome)
> > - DNS recursivo dedicado e o resto do mundo bloqueado.
> > - E-mail? Subdomínio da empresa com ferramenta de e-mail dedicada.
> > - Acesso WEB? Lista Branca com aprovação de superior e período de
> > validade(foi aí que tomamos pau).
> >
> > ​​O projeto era muito mais de governança do que de infraestrutura.
> >
>
> A discussão está ótima, mas não sei quanto já está off-topic. :-)
>
> Eu não imaginei que esses ambientes fossem dessa forma. Achei que o papel
> dos "NGFW" fosse exatamente manter os níveis de segurança (ou algum nível
> de segurança) sem ter que restringir tanto os acessos. Pelo que explicou,
> até a avaliação da paranóia da VPN desconhecida versus MITM no túnel e
> afins ainda está aquém de um ambiente desse tipo.
>
> O que me intrigou sobre SSH versus NFGW foi saber como é que um NFGW separa
> uma conexão SSH de uma conexão HTTPS. Eu ainda não experimentei, por
> exemplo, usar um SSH via HTTPS (estou pensando no método CONNECT, com
> squid, por exemplo). Em um caso assim, será que esses NFGW iriam separar
> uma coisa da outra? Poderia ser um item da política, por exemplo, permitir
> HTTPS, mas não um tunnel SSH via método CONNECT (não sei se é possível, pq
> não testei).
>
> OU podemos pensar, por exemplo, permitir IMAPs, POP3s e SMTP com TLS ou
> SSL, mas não permitir HTTPS ou SSH no contexto que citei.
>
> Se tudo isso for possível, via NFGW, então, de alguma forma, mesmo conexões
> criptografadas, via VPN desconhecida, estariam comprometidas. Mas o detalhe
> do "erro no certificado", desconsiderando o detalhe do usuário nem
> perceber, acho que pareceria suspeito.
>
> Obrigado.
>
> Cássio
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



-- 
Douglas Fernando Fischer
Engº de Controle e Automação



More information about the gter mailing list