[MASOCH-L] OpenVPN para acesso aos clientes
Vinícius Fontes
contato at viniciusfontes.com
Fri Aug 7 10:05:11 -03 2015
Apenas para dar o feedback: implementei o OpenVPN e está funcionando muito
bem! Obrigado a todos pelas dicas, foram muito úteis.
A única ressalva: tive que mudar o transporte de UDP para TCP. Apesar de
não gostar do overhead e da latência maior do TCP, ficou muito mais estável
dessa forma. Com isso meu Zabbix parou de reclamar que os agentes estão
unreachable a toda hora.
Em 14 de maio de 2015 11:28, Eduardo Rigler <erigler at gmail.com> escreveu:
> Não é paranóia e foi a primeira coisa que me ocorreu também, (in)segurança
> na rede do cliente aos olhos de alguém que manda.
>
> Já bati de frente com muito "especialista" em cargo gerencial que embarga
> uma coisa dessas em dois tempos "só de zuá".... só pra ter tudo
> buRRocraticamente centralizado nele não importa como for.
>
> Por outro lado, se for pra cuidar de redes pequenas "sem dono" as pessoas
> darão graças por ter isso, logo logo vão estar abrindo chamado para
> instalar impressoras remotamente via VPN :-)
>
>
> []'s
>
>
> Em 14 de maio de 2015 10:25, Douglas Fischer <fischerdouglas at gmail.com>
> escreveu:
>
> > A idéia é boa!
> > Usei o mesmo conceito SSH reverso nos meus idos tempos de Linux.
> >
> > Mas, pergunta...
> > E os clientes vão aceitar isso?
> > Eles vão estar sabendo desse acesso não supervisionado?
> >
> > Digo isso pois do ponto de vista da empresa cliente isso é uma brecha de
> > segurança bastante considerável.
> >
> > Alguns clientes não querem nem ativar os call-home de produtos com
> > garantia...
> > Preferem fazer liberação manual, transmissão, e bloqueio manual para
> evitar
> > backdoor.
> > Sei que é meio paranoia, mas eu não condeno a ideia completamente...
> >
> >
> >
> >
> > Em 14 de maio de 2015 10:00, Vinícius Fontes <contato at viniciusfontes.com
> >
> > escreveu:
> >
> > > Ótimas dicas, já tinha implementado a maioria no meu ambiente de teste.
> > >
> > > Outro problema que me ocorreu é caso o cliente utilize em sua rede
> > interna
> > > o mesmo bloco privado que eu atribuí à VPN. Por exemplo, 172.16.2.0/24
> .
> > > Para evitar isso, estou pensando em usar o bloco 100.64.0.0/10, que é
> > > definido pela RFC 6598 para utilização em CGNAT.
> > >
> > > Em 14 de maio de 2015 09:43, Leonardo Rodrigues <
> > leolistas at solutti.com.br>
> > > escreveu:
> > >
> > > > On 14/05/15 09:21, Vinícius Fontes wrote:
> > > >
> > > >> Tenho conhecimento técnico para implementar esta solução, mas
> gostaria
> > > da
> > > >> opinião dos colegas (que tem muito mais conhecimento e experiência
> do
> > > que
> > > >> eu). Isso é uma boa idéia? Existe algum problema nessa solução que
> não
> > > >> estou enxergando? Um problema que pensei seria o servidor do cliente
> > ser
> > > >> comprometido, e isso ser um vetor de ataques à minha rede, mas creio
> > que
> > > >> isso pode ser mitigado por regras de firewall.
> > > >>
> > > >> Ótima idéia e, com poucas observações, torna-se uma solução
> > > > imbatível e bastante segura. Tenho algo parecido rodando hoje em dia
> > sem
> > > > grandes problemas.
> > > >
> > > > 1) use o OpenVPN em modo TLS, gere 1 certificado pra cada servidor
> que
> > > > você precisa acesso, já que assim você pode revogar certificados
> > > > individualmente e não se preocupar com que suas chaves (no caso de
> uma
> > > VPN
> > > > de chave estática, por exemplo) vaze;
> > > > 2) não use a dobradinha "server" e "ifconfig-pool-persist" para
> > > distribuir
> > > > IPs pros seus clientes (seus servidores), já que essa solução não
> > garante
> > > > que cada cliente vai receber sempre o mesmo IP. Use "ccd-exclusive" e
> > um
> > > > arquivo de configuração por certificado (= por servidor) com um
> > > > "ifconfig-push". Assim você tem certeza que cada certificado, quando
> > > > conectado, vai receber sempre o mesmo IP
> > > > 3) regras de firewall conseguem evitar o tráfego originado do cliente
> > pra
> > > > sua rede, essa é fácil
> > > > 4) pra dificultar a vida de algum atacante, um "tls-auth" vai sempre
> > bem
> > > !
> > > > 5) não esqueça de ajustar o max-clients de acordo com a quantidade de
> > > > clientes (servidores) que irão usar a solução
> > > >
> > > >
> > > > o que me vem à cabeça é isso ...
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > >
> > > > Atenciosamente / Sincerily,
> > > > Leonardo Rodrigues
> > > > Solutti Tecnologia
> > > > http://www.solutti.com.br
> > > >
> > > > Minha armadilha de SPAM, NÃO mandem email
> > > > gertrudes at solutti.com.br
> > > > My SPAMTRAP, do not email it
> > > >
> > > >
> > > >
> > > > __
> > > > masoch-l list
> > > > https://eng.registro.br/mailman/listinfo/masoch-l
> > > >
> > > __
> > > masoch-l list
> > > https://eng.registro.br/mailman/listinfo/masoch-l
> > >
> >
> >
> >
> > --
> > Douglas Fernando Fischer
> > Engº de Controle e Automação
> > __
> > masoch-l list
> > https://eng.registro.br/mailman/listinfo/masoch-l
> >
> __
> masoch-l list
> https://eng.registro.br/mailman/listinfo/masoch-l
>
More information about the masoch-l
mailing list