subject:"\[FUG\-BR\] segurança"

Re: [FUG-BR] Segurança do PPTP para poucos acessos

2016-05-02 Por tôpico Renato Frederick



De: Ricardo Ferreira 
Responder: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) 

Data: 2 de maio de 2016 at 15:55:26
Para: freebsd@fug.com.br 
Assunto:  Re: [FUG-BR] Segurança do PPTP para poucos acessos  

Outro ponto que gostaria de complementar em relação às ideias discutidas 
até agora e é uma tecla que sou até chato aqui na empresa é com relação 
às diversas opções disponíveis, procurando evitar o "clubismo" na hora 
de se decidir o que usar seja ssh, openvpn, ipsec, l2tp, etc, etc 
Sou da opinião que são ferramentas únicas e que resolvem problemas 
específicos portanto é necessário que o analista faça seu trabalho e 
justifique formalmente porque da ferramenta A em vez da B, com testes 
que fundamente sua tese e isto vale para sistema operacional inclusive e 
assim por diante. Não acredito que um seja melhor ou pior que o outro, 
mas sim um que se adequa mais às suas premissas. Ah menos o PPTP neste 
escopo claro. Valeu pela discussão! Muito boa! 
- 
Histórico: http://www.fug.com.br/historico/html/freebsd/ 
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd 


Com certeza, as contribuições de você, Ricardo e do Paulo enriqueceram a lista. 
Eu gosto muito de tocar neste ponto, aproveitando que o Ricardo falou do 
“cubismo”:

Já tive situações em que eu era tão somente cliente de acesso remoto e tipo 
assim, é como se hoje eu precisasse acessar a empresa e me mandar um .exe de 32 
bits compatível SOMENTE com Windows XP. Você fala: “Oi, mas uso Windows 7(ou 
10) - algo suportado pela MS” e a empresa falava: Nosso acesso remoto só 
certificou para estações XP.

Ou então, receber um .dmg que só rodava em OSX 10.8 para baixo…

São situações em que eu pensava: Nossa, se seu acesso remoto certificado 
contempla Sistemas Operacionais Mortos e não atualizados mais pelo fabricante, 
o que deve estar passando nesta VPN hein…… :)

Mas a empresa se achava TOP, porque o .EXE//.DMG era de um grande fabricante de 
caixas de firewall/IDS/IPS… OK, o Fabricante é grande, mas a empresa precisava 
renovar os contratos de hardware, porque o produto não conhecia as novas 
versões de MAC/WIN :)







-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Segurança do PPTP para poucos acessos

2016-05-02 Por tôpico Ricardo Ferreira


Em 02/05/2016 15:38, Paulo Henrique - BSDs Brasil escreveu:



Em 02/05/2016 15:14, Renato Frederick escreveu:

Paulo, voce pegou meu ponto.

É que não adianta muito discutir o que usar, porque a ponta remota 
sempre vai ser a parte fraca.


Por ex, eu uso openvpn aqui no meu note(um OSX). Mas tive que 
resolver uma pendência particular a 30min. Eu o fechei.


Ao abrir, pede minha senha. Mas nestes 30min dava com certeza para um 
atacante fantasiado de funcionário dar um reboot, iniciar o OSX em 
recuperação e por um malware no meu startup.


OK, eu estou falho em não encriptar meu disco, etc….

Quanto ao acesso RDP, acredita que já fui “intimado” pelo dono da 
empresa, algo do tipo “não gostei, tenho que clicar agora em 2 
locais(van + RDP), volta do jeito que estava antes”… do tipo.. volta 
agora ou acho quem o faça(bilhete azul).




———
Renato Frederick
Consultor em TI
http://about.me/renatofrederick
Skype: renatofrederick
+55 31 99123 - 3006
+55 31 2523 - 0686


Pessoal, cuidado com o Top-posting, estraga o histórico da lista.

Renato, realmente é onde minha atenção sempre esteve voltada é para a 
parte que você frisou, a unica forma de diminuir esse risco foi 
abrangendo a responsabilidade do Departamento de TI para as estações 
remotas dos funcionários que efetuavam acesso remoto, não é 100% mas é 
melhor do que nada.
E isso complica ainda mais quando há a utilização dessas estações por 
outras pessoas que não os colaboradores, contudo como disse o Sr. 
Ricardo, é tudo questão de analise de risco real e o aceitável, no 
caso dele o risco real sobrepõem o risco aceitável devido a atividades 
exercidas pela empresa no qual ele gerencia, no meu caso o risco 
aceitável sobrepõem o risco real.


Quanto a esse problema de diretor criticando que a necessidade de mais 
uma autenticação para ter acesso, também tive esse problema e a unica 
alternativa que tive foi manter o redirecionamento, contudo usando 
junto o knork e no RDP usando um .bat em execução antes da conexão 
para liberar a porta, é ruim, leva mais de 20 segundos para iniciar a 
negociação de autenticação contudo manteve o minimo de dois niveis de 
autenticação ( um nivel de pseudo autenticação ) para que estes 
tivessem acesso a estação.


Eu passei a adotar tunnel ssh no firewall usando chaves e sobre esse 
tunel o acesso aos servidores, sempre com a dobradinha de 
chaves+password.
Quanto a esse negocio de criptografar o disco, lamento não no seu caso 
não resolveria, o atacante seria competente o suficiente para no 
worm/trojan que ele usar inserir um back-door, o disco já estaria 
descriptografado quando ele teve acesso, você só garantiria que ele 
não precisa-se de contra-medidas para lidar com firewall/IDS/IPS.
Criptografia de disco hoje só é segurança em caso de roubo do 
equipamento, é impraticável descriptografar qualquer coisa com chaves 
acima de 256bits de extensão, e nesse caso por eventualmente você 
armazenar chaves e senhas nesse mac seu sem criptografar o disco é um 
risco real e não aceitável.



Att. Paulo Henrique.


De: Paulo Henrique - BSDs Brasil 
Responder: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) 


Data: 2 de maio de 2016 at 14:28:59
Para: freebsd@fug.com.br 
Assunto:  Re: [FUG-BR] Segurança do PPTP para poucos acessos



Em 02/05/2016 13:57, Renato Frederick escreveu:

Sim.
  Mas daí o ponto fraco deixou de ser sua casa e virou a ponta 
remota onde você estiver... :)
  Claro que no mundo de pedaladas fiscais com IOF sobre o dólar 
aumentando, deslocar o funcionário a todo momento gasta 
gasolina(importada…) então acesso remoto é sobrevivência.
  Mas ficar neste #mimimimi de “ai eu não gosto de openvpn, é boba e 
feia” ou “ah, ipsec é a glória e unção do nosso senhor na terra nos 
diais atuais”, ou “ah, eu uso o hardware XPTO que custa milhares de 
dólares, estou protegido”…. não leva a nada.

  Para cada solução apresentada, teremos pontos fortes e fracos.
  Claro que concordamos todos com PPTP. Abre logo um TELNET, usa o 
login root, senha 1234, porque até isto é melhor que pptp…

Renato,

Pode ser por falta de conhecimento de minha parte, mas não conheço
qualquer metodo aceitável para comprometer o OpenSSH, que ele pode ter
falhas de segurança qualquer software está sujeito a isso e o OpenSSH
não será excessão.

Quanto a ponta remota ela sempre será o elo fraco da segurança pois não
terá os mesmos recursos de acesso como os implementados nos IDCs.
Sempre fui relutante em disponibilizar VPN para infraestrutura pois é
uma ramificação da infraestrutura que estará sem supervisão, contudo
antes você usar uma VPN do que ir para um redirecionamento de TS direto
para uma estação de um funcionário ( sim já usei isso no passado, não
nego, mas posteriormente foi adotado o acesso via TS sobre openvpn,
melhor ter mais uma autenticação e uns palavrões dos usuários finais do
que estar com um servidor TS exposto ).
Outro lado ruim de VPN é que worms irão passar pelo FW/IDS/IPS caso o
concentrador esteja após estes

Re: [FUG-BR] Segurança do PPTP para poucos acessos

2016-05-02 Por tôpico Paulo Henrique - BSDs Brasil

Em 02/05/2016 15:14, Renato Frederick escreveu:

Paulo, voce pegou meu ponto.

É que não adianta muito discutir o que usar, porque a ponta remota sempre vai
ser a parte fraca.

Por ex, eu uso openvpn aqui no meu note(um OSX). Mas tive que resolver uma
pendência particular a 30min. Eu o fechei.

Ao abrir, pede minha senha. Mas nestes 30min dava com certeza para um atacante
fantasiado de funcionário dar um reboot, iniciar o OSX em recuperação e por um
malware no meu startup.

OK, eu estou falho em não encriptar meu disco, etc….

Quanto ao acesso RDP, acredita que já fui “intimado” pelo dono da empresa, algo
do tipo “não gostei, tenho que clicar agora em 2 locais(van + RDP), volta do
jeito que estava antes”… do tipo.. volta agora ou acho quem o faça(bilhete
azul).

———
Renato Frederick
Consultor em TI
http://about.me/renatofrederick
Skype: renatofrederick
+55 31 99123 - 3006
+55 31 2523 - 0686

Pessoal, cuidado com o Top-posting, estraga o histórico da lista.

Renato, realmente é onde minha atenção sempre esteve voltada é para a
parte que você frisou, a unica forma de diminuir esse risco foi
abrangendo a responsabilidade do Departamento de TI para as estações
remotas dos funcionários que efetuavam acesso remoto, não é 100% mas é
melhor do que nada.
E isso complica ainda mais quando há a utilização dessas estações por
outras pessoas que não os colaboradores, contudo como disse o Sr.
Ricardo, é tudo questão de analise de risco real e o aceitável, no caso
dele o risco real sobrepõem o risco aceitável devido a atividades
exercidas pela empresa no qual ele gerencia, no meu caso o risco
aceitável sobrepõem o risco real.

Quanto a esse problema de diretor criticando que a necessidade de mais
uma autenticação para ter acesso, também tive esse problema e a unica
alternativa que tive foi manter o redirecionamento, contudo usando junto
o knork e no RDP usando um .bat em execução antes da conexão para
liberar a porta, é ruim, leva mais de 20 segundos para iniciar a
negociação de autenticação contudo manteve o minimo de dois niveis de
autenticação ( um nivel de pseudo autenticação ) para que estes tivessem
acesso a estação.

Eu passei a adotar tunnel ssh no firewall usando chaves e sobre esse
tunel o acesso aos servidores, sempre com a dobradinha de chaves+password.
Quanto a esse negocio de criptografar o disco, lamento não no seu caso
não resolveria, o atacante seria competente o suficiente para no
worm/trojan que ele usar inserir um back-door, o disco já estaria
descriptografado quando ele teve acesso, você só garantiria que ele não
precisa-se de contra-medidas para lidar com firewall/IDS/IPS.
Criptografia de disco hoje só é segurança em caso de roubo do
equipamento, é impraticável descriptografar qualquer coisa com chaves
acima de 256bits de extensão, e nesse caso por eventualmente você
armazenar chaves e senhas nesse mac seu sem criptografar o disco é um
risco real e não aceitável.

Att. Paulo Henrique.

De: Paulo Henrique - BSDs Brasil
Responder: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)

Data: 2 de maio de 2016 at 14:28:59
Para: freebsd@fug.com.br
Assunto: Re: [FUG-BR] Segurança do PPTP para poucos acessos

Em 02/05/2016 13:57, Renato Frederick escreveu:

Sim.

Mas daí o ponto fraco deixou de ser sua casa e virou a ponta remota onde você estiver... :)

Claro que no mundo de pedaladas fiscais com IOF sobre o dólar aumentando, deslocar o funcionário a todo momento gasta gasolina(importada…) então acesso remoto é sobrevivência.

Mas ficar neste #mimimimi de “ai eu não gosto de openvpn, é boba e feia” ou “ah, ipsec é a glória e unção do nosso senhor na terra nos diais atuais”, ou “ah, eu uso o hardware XPTO que custa milhares de dólares, estou protegido”…. não leva a nada.

Para cada solução apresentada, teremos pontos fortes e fracos.

Claro que concordamos todos com PPTP. Abre logo um TELNET, usa o login root, senha 1234, porque até isto é melhor que pptp…

Renato,

Pode ser por falta de conhecimento de minha parte, mas não conheço
qualquer metodo aceitável para comprometer o OpenSSH, que ele pode ter
falhas de segurança qualquer software está sujeito a isso e o OpenSSH
não será excessão.

Quanto a ponta remota ela sempre será o elo fraco da segurança pois não
terá os mesmos recursos de acesso como os implementados nos IDCs.
Sempre fui relutante em disponibilizar VPN para infraestrutura pois é
uma ramificação da infraestrutura que estará sem supervisão, contudo
antes você usar uma VPN do que ir para um redirecionamento de TS direto
para uma estação de um funcionário ( sim já usei isso no passado, não
nego, mas posteriormente foi adotado o acesso via TS sobre openvpn,
melhor ter mais uma autenticação e uns palavrões dos usuários finais do
que estar com um servidor TS exposto ).
Outro lado ruim de VPN é que worms irão passar pelo FW/IDS/IPS caso o
concentrador esteja após estes.

96 matches

Mail list logo