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 <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 - 0686
De: 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 acessos
O colega tem razão quando fala do POWa um passo a frente dos
gestores da empresa, ERBOX e é por isso que adotamos a
seguinte 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
-------------------------
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
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
