[MASOCH-L] Sipvicious

[Durval Menezes]

Prezado Douglas,

On Fri, Apr 25, 2014 at 02:15:18PM -0300, Douglas Fischer wrote:
> Mas em diversas ocasi??es eu j?? recomendei e implementei solu????es OpenSource.
> 
> E nesse mundo OpenSource, eu tenho uma postura que pode parecer controversa
> para alguns, mas ?? a de manter o independ??ncia da ferramenta e da pessoa
> que configura a ferramenta.

Bom, entendo o que voce quer dizer, mas nao concordo. Nao acho que exista
esta dependencia ("da ferramenta e da pessoa que configura a ferramenta")
quando se trata de solucoes abertas, pois exatamente por serem abertas,
estao disponiveis para qualquer um com um minimo de especializacao possa
aprender/configurar/usar/manter.

O que existe (e talvez a isso voce esteja se referindo, ainda que de uma
forma bastante indireta) e' falta de pessoal com exatamente este minimo
de especializacao na maioria das empresas, bem como falta de disposicao
destas mesmas empresas em investir na formacao do seu pessoal para
capacita-lo a utilizar qualquer coisa menos "amigavel" do que uma
interface web.

> Exemplo? OK! Falemos de Firewall:
> 
> Analisando os recurso financeiros, humanos e t??cnicos da empresa ACME,
> cheguei a conclus??o que o melhor seria utilizarmos um Firewall Baseado em
> OpenSource.
> Qual vamos escolher?
>  -De cara eu descarto a possibilidade de construir um firewall na unha!
>  -Escolho uma ferramenta no estilo Endian ou PF-Sense(S??o s?? exemplos, no
> flames please).

Veja que e' desta forma que voce esta' exatamente criando a tal
"dependencia da ferramenta" que voce anunciou querer evitar: tanto
o PFSense como o Endian sao (a grosso modo) "pacotes de front-end"
em cima de ferramentas mais basicas (as tais "na unha" que voce
relatou: respectivamente o pf e o iptables e seus acompanhantes).

Desta forma, se amanha o PFSense e/ou o Endian pararem de ser
desenvolvidos (como diversas "ferramentas" do tipo ja' o foram, no
passado), a empresa que usar vai ficar inteiramente "na mao" (falta de
atualizacoes no caso de bugs, suporte a equipamentos correntes, novas
facilidades, etc) e vai ser eventualmente obrigada a jogar o seu
"investimento" fora e comecar tudo de novo com outra "ferramenta"
do mesmo tipo.

Se esta mesma empresa tivesse investido em treinar ou contratar (e manter)
os profissionais de nivel necessario para fazer o que precisa usando as ferramentas
basicas (como o iptables e o pf), isso nao aconteceria. O pf existe nos *BSD
ha' mais de 12 anos (e foi derivado de outra solucao, o IPFilter, de modo 
bastante "upward compatible" -- ou seja, preservando quase todo o investimento
de quem aprendeu e implementou a solucao anterior) e o iptables existe ha' mais
de 15 anos... sera' que daqui a 15 anos teremos pfsense e Endian? Acho que nao, 
mas acho tambem que teremos tanto o iptables como o pf, ou um "sucessor" deles
que preserve todo ou quase todo o investimento que tivermos nos mesmos.

Minha tese acima e' otima, nao e'? Entao, porque na maior parte das vezes
nao acontece assim?

O problema e' que a maior parte das empresas, especialmente aqui no BR,
ve mao-de-obra (incluindo, e muitas vezes ate' principalmente, a de TI por
nao ser "area fim") como um *custo* e nao como um *investimento*. Entao, a
estrategia que "faz sentido" (dentro dessa otica) e' contratar as pessoas
mais fracas possiveis (porque recebem um salario menor por mes, e portanto
"custam" menos) e entao sobrecarrega-las e nao abrir nunca tempo (e muito
menos custear treinamento) para que elas possam se aperfeicoar e utilizar
ferramentas melhores (ainda que mais dificeis de aprender a usar).

Resumindo, e' mais "barato" (dentro desta otica de que mao-de-obra e'
custo) jogar tudo fora periodicamente (incluindo as pessoas) e comecar
de novo...

>  -E implemento a solu????o de uma maneira tal que se de hoje para amanh?? eu
> necessite tirar o A e colocar o B

Vide acima. Acho que isso so' se justifica dentro da logica de que pessoas
sao custo e nao solucao, e entao e' melhor usar as de menor custo possivel
e mais faceis de se substituir quando aparecer uma ainda mais barata.

> eu n??o esbarre em legados...

Considerando a questao do "legado"(se entendo claramente o que voce
quer dizer), concordo que pode de fato acontecer, quando se permite que um
profissional (que `as vezes nem e' tao bom assim) trabalhe "escondendo o
jogo", usando uma ferramenta como o pf/iptables e sem manter as coisas
minimamente organizadas e documentadas. Mas isso acontece com ferramentas
do tipo "front end" tambem, so' necessita de uma empresa de tamanho
maior e/ou mais complicada e/ou com menos controle para que o proximo
da fila herde uma solucao que seja impossivel de manter.

>     - Migro as configura????es e o que estava afetando a ferramenta A n??o
> afeta mais a ferramenta B.

Entendo a sua logica de utilizar ferramentas do tipo "qualquer um usa", e acho
que ela funciona bem, dentro de uma visao pragmatica, para a realidade que eu
descrevi acima.

Inclusive, congratulo voce por utilizar muitas vezes ferramentas
opensource como os citados "pacotes c/ front-end" para atender as empresas que
nao investem (e nem querem investir) na mao-de-obra necessaria para usar as 
ferramentas mais basicas e universais; por se basearem em solucoes abertas,
certamente sao melhores (em termos de seguranca para estas empresas) do que
utilizar produtos fechados, se bem que suspeito que estas solucoes abertas
"empacotadas" acabem mesmo sendo usadas na maior parte dos casos nao por
serem melhores neste ou em qualquer outro aspecto tecnico, e sim por serem
gratuitas (e desta forma reduzir ainda mais o investimento, quero dizer,
o custo).

Mas nao vamos nos enganar e perder de vista o que de fato faz as coisas
serem como sao...

Um Grande Abraco,
-- 
  Durval Menezes (durval AT tmp DOT com DOT br, http://www.tmp.com.br/)

> 
> Em 25 de abril de 2014 14:14, Douglas Fischer
> <fischerdouglas at gmail.com>escreveu:
> 
> > Entendo sua posi????o Durval!
> >
> > Atuo como engenheiro de rede j?? h?? algum tempo, e uso solu????es fechadas e
> > OpenSource em diversos ambientes.
> >
> > Quando eu analiso o ambiente do cliente, e chego a conclus??o que o que
> > cabe melhor ali ?? uma solu????o de caixa fechada, um dos fatores que levo em
> > considera????o ?? justamente o c??digo ser fechado.
> >
> > Vou exemplificar minha posi????o tomando como exemplo descoberta de novas
> > vulnerabilidades de seguran??a em solu????es.
> >
> > TODAS solu????es est??o sujeitas a vulnerabilidades de seguran??a.
> > Acho que disso ningu??m discorda, certo?
> >
> > Empresas como Checkpoint, Cisco, Palo-Alto, quando tem vulnerabilidades
> > identificadas em suas solu????es tem a pr??tica de INFORMAR INDIVIDUALMENTE
> > que est??o cadastrados como usu??rios daquela plataforma afetada ANTES DE
> > DIVULGAR PUBLICAMENTE A VULNERABILIDADE.
> >    P.S.: Da?? a import??ncia de manter um contrato
> >       de suporte com o fabricante, e l??gicamente
> >       manter seu cadastro devidamente atualizado
> >       por l??..
> >
> > Quando se usa ferramentas OpenSource, a informa????o sobre a vulnerabilidade
> > chega ao mesmo tempo na m??o do administrador do ambiente e do poss??vel
> > intrusor, o que dispara uma corrida entre corrigir e atacar(Haja vista o
> > HeartBleed).
> >
> >
> >
> >
> >
> > Em 25 de abril de 2014 13:25, Durval Menezes <durval at tmp.com.br> escreveu:
> >
> > Prezados,
> >>
> >> Desculpem-me, mas discordo de ambas as posicoes; a saber:
> >>
> >> Douglas: o que voce diz muito se parece com a velha posicao de que
> >>          "ninguem nunca foi mandado embora por comprar da IBM".
> >>          Com todo o respeito (e ressalvando que nao acredito que tenha
> >>          sido isso que que voce tenha *querido* dizer), esta e' uma
> >>          posicao mediocre de quem esta' tentando somente proteger o
> >>          proprio traseiro, nada digna de tecnicos como nos, que
> >>          frequentamos o MASOCH-L.
> >>
> >> Bruno: ninguem garante que *somente* a NSA saiba; se o furo esta' la',
> >>        e' questao de tempo ate' ser descoberto por alguem que ira' vender
> >>        a falha no mercado de "zero days" para o proximo ataque em massa
> >>        a la Zeus ou similar. Questoes de privacidade `a parte, na minha
> >>        opiniao o grande problema do "conchavo" entre os fabricantes de
> >>        produtos fechados e a NSA e' que ele praticamente garante que
> >>        os problemas vao permanecer no codigo eternamente enquanto nao
> >>        forem descobertos (e utilizados) por terceiros... o que IMNSHO
> >>        mais uma vez demonstra que nao e' possivel construir estruturas
> >>        de informacao realmente seguras utilizando produtos fechados.
> >>
> >> Um Grande Abraco,
> >> --
> >>   Durval Menezes (durval AT tmp DOT com DOT br, http://www.tmp.com.br/)
> >>
> >>
> >> On Fri, Apr 25, 2014 at 12:04:44PM -0300, Douglas Fischer wrote:
> >> > Assim...
> >> >
> >> > Eu n??o acho que a NSA precise usar meu SIP Session Manager p/ vender
> >> > liga????es VOIP Piratas.
> >> >
> >> > E se o Router que eu especifiquei e configurei for hackeado pela NSA,
> >> > atrav??s de supostas backdoors impostas ao fabricante, bom... Meu
> >> trabalho
> >> > foi bem feito!
> >> > N??o ser?? uma vergonha para mim.
> >> >
> >> > Mas se eu especificar uma distro X, deixar passar algum furo, e algum
> >> > noobie usando Cain e Abel conseguir entrar nela, meu filme vai ficar bem
> >> > tostado...
> >> >
> >> >
> >> >
> >> > Em 25 de abril de 2014 11:48, Bruno Cabral <bruno at openline.com.br>
> >> escreveu:
> >> >
> >> > > Aquelas que os furos apenas a NSA sabe...
> >> > >
> >> > > !3runo
> >> > >
> >> > >
> >> > > > Por isso eu amo appliances...
> >> > > >
> >> > > > Appliances MESMO, n??o distro customizadas.
> >> > > > Aquelas onde tudo ?? chrootado, onde a console ?? limitada, onde
> >> tudo ??
> >> > > > capado...
> >> > >
> >> > > __
> >> > > 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
> >>
> >
> >
> >
> > --
> > Douglas Fernando Fischer
> > Eng?? de Controle e Automa????o
> >
> 
> 
> 
> -- 
> Douglas Fernando Fischer
> Eng?? de Controle e Automa????o
> __
> masoch-l list