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 <paulo.rd...@bsd.com.br> Responder: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) <freebsd@fug.com.br> Data: 2 de maio de 2016 at 14:28:59 Para: freebsd@fug.com.br <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. Att.———Renato Frederick Consultor em TI http://about.me/renatofrederick Skype: renatofrederick +55 31 99123 - 3006 +55 31 2523 - 0686De: Ricardo Ferreira <ricardo.ferre...@sotech.com.br>Responder: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) <freebsd@fug.com.br> Data: 2 de maio de 2016 at 12:52:37 Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) <freebsd@fug.com.br> Assunto: Re: [FUG-BR] Segurança do PPTP para poucos acessosO colega tem razão quando fala do POWa um passo a frente dos gestores da empresa, ERBOX e é por isso que adotamos aseguinte solução. Meu cenário consiste de um MPLS de 256Kbps conectado entre minha casa e a empresa pois é somente a partir de determinado IP que se pode efetuar o acesso remoto por um requisito de segurança e da empresa tem um MPLS ligado a dois datacenters. Ainda assim o acesso é criptografado usando STUNNEL e autenticação via SO. Se preciso acessar de fora via Internet tenho que acessar minha casa e de lá para a empresa. Se estiver fora do ar, aí não tem jeito o acesso é efetuado via VPN com autenticação via smartcard para prosseguir. Tem que haver um compromisso entre segurança e custos de operação e a tecnologia está aí para isso. Na verdade a solução arquitetada por cada empresa para permitir o acesso remoto a seus recursos por funcionários qualificados deve seguir uma política rígida e séria para ter sucesso e evitar a ocorrência de incidentes. Mas tenho que confessar sem acesso remoto minha empresa não existiria. ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd-- :UNI><BSD: Paulo Henrique. UnixBSD Tecnologia Segurança em Tecnologia da Informação. Fone: (21) 96713-5042 / (21) 3708-9388 Site: https://www.unixbsd.com.br ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
-- :UNI><BSD: Paulo Henrique. UnixBSD Tecnologia Segurança em Tecnologia da Informação. Fone: (21) 998253-9727 / (21) 3708-9388 Site: https://www.unixbsd.com.br
<<attachment: paulo_rddck.vcf>>
------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
