Re: [FUG-BR] Infra Web Services

[Fábio Rodrigues Ribeiro]

Em 20/05/2016 10:56, Ricardo Ferreira escreveu:

Senhores,


Tenho que implementar uma infra para suporte a Web Services e claro que
quero fazer em FreeBSD. Tenho algumas idéias como Apache mais Tomcat por
exemplo, dentre outras... mas gostaria de ouvir dos companheiros
sugestões, experiências, soluções de segurança, críticas dentre outros
detalhes a fim de alimentar o processo decisórioUm detalhe
importante é que segurança se impõe sobre todos os outros aspectos.

[]s


Ricardo Ferreira


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


Eu como aspirante a devOps, tendo a preocupação voltada ao developers
preocuparia em performance e HA (estilo heartbeat – no IPv6 é
desnecessário – & DRDB ou HADOOP). Além de dividir o sistema em três
S.O. neles o DB, APLICAÇÃO (com integração contínua) e ACELERADOR
(somente esse com acesso a externo, aka DMZ)

--
Fábio Rodrigues Ribeiro
http://www.linkedin.com/in/farribeiro
http://www.farribeiro.com.br
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Infra Web Services

[Patrick Tracanelli]

> Discussão bacana mas tenho uma dúvida.
> Este Firewall de outro sabor(Linux, OpenBSD, NetBSD) tem que possuir
> as mesmas regras que o FreeBSD/IPFW ?

Não, exatamente ao contrário. A essência chave aqui é o conceito de Defense in 
Depth e Layered Security onde um ativo de controle preenche o GAP do outro. 
Você precisa, no caso dos firewall, distribuir stateless pra proteger contra 
ataques volumétricos e não elaborados, negação de serviço, anomalias de 
protocolos, pacotes artificialmente mal formados etc, sem nem pensar em gastar 
memória, lembrar de states, ou gastar CPU fazendo deep inspection, etc. Depois, 
em outro Layer, fazer firewall misto, stateless pra tudo que por definição é 
stateless (ICMP, UDP), stateless pras anomalias TCP (combinação invalida de 
flags, ataques stealth, etc) e stateful seletivo pros serviços TCP/SCTP mais 
críticos. Entre um Layer e outro você pode claro ter regras repetidas, 
especialmente as anti-spoof, controle ingress, policy pra serviços normalmente 
usados pra amplificação (NTP, DNS, CHARGEN, SNMP, TFTP, …) ja que em outro 
Layer voce tem outra perspectiva dos perímetros.

Depois, e só depois que os grandes comedores de recurso tiverem sido limpos, 
você segue com Firewall Statefull e Firewall-NG (DPI, Palo Alto, NTOPNG, etc) 
pois será um momento onde ataques mais aprimorados terão passado dos controles 
anteriores, mas em volume menor então pode ser inspecionado com controles mais 
refinados (e consequentemente mais caros sob o ponto de vista de consumo de 
recursos computacionais). Você ja estará em uma profundidade distante da borda, 
então começa caber stateful e afins.

A mesma teoria é pra IDS/IPS, primeiro tratar a detecção (IDS) com Respostas 
Ativas (bloqueios, triggers disparadas de eventos detectados), mas jamais meter 
1 IPS sem que o próprio IPS tenha sido protegido antes, nem colocar um IPS 
depois do outro em linha fazendo as mesmas coisas. A ideia é sempre o conceito 
militar onde você não tem como garantir defesa com uma única solução milagrosa, 
e deve portanto distribuir sua defensa em camadas onde uma preencherá o gap da 
anterior. Da mesma forma se você nunca consegue ter garantia total de defesa, 
tenha sempre em mente que de um ponto de controle pro outro, sempre passará 
alguma coisa nociva, algum ataque. A idéia que algo sempre vai passar portanto 
se ela é uma certeza, a gente tem sempre que considerar como tratar.

Por isso a terminação deve ser um WAF, ou seja o vetor principal de risco (o 
usuário autentico ou o agente que esta atacando) não deve nunca chegar na 
aplicação, na regra do negócio, no “ouro”. O fim-a-fim dele encerra no WAF, a 
terminação, ou em algo que o valha (proxy de entrada com ha-proxy, varnish, ou 
algum legado comercial caso exista, F5 BigIP da vida, etc).

--
Patrick Tracanelli

FreeBSD Brasil LTDA.
Tel.: (31) 3516-0800
316...@sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"

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

Re: [FUG-BR] Infra Web Services

[Paulo Henrique]

Em 24 de maio de 2016 13:21, Patrick Tracanelli  escreveu:

> >>
> https://docs.google.com/document/d/1SISJWwrmPoD_bvOnMRwxbVm8o_x_PTJivVvQQTiiLhg/edit?usp=sharing
> >
> > A palestra é especifica para empresas/corporação ou no treinamento da
> SSE a
> > mesma é abordada.
> >
> > A gama de informação é significativa, para quem está atoa valeu pelas
> > referencias, pesquisando na net :D, assim que possivel quero estar
> podendo
> > realizar um treinamento na FreeBSD Brasil.
> >
> > Abrs.
>
> Fala Paulo,
>
> Não é abordado no SEE não, nessa linha. Essa palestra é na verdade da IDS (
> ids.com.br), empresa que pertence a FreeBSD Brasil, é uma palestra focada
> em desenvolvedores de aplicações Mobile e desenvolvimento de aplicações
> seguras em linhas com foco em segmento financeiro. Ou seja é pro
> desenvolvedor, aborda muito de webservice mas aborda muita coisa que não é
> nem de Webservice nem de infra de segurança, como técnicas contra ataques
> offband que é o Vetor1 de abordado.
>
> Deve sim gerar um treinamento, inclusive a palestra esta dividida em 2
> formatos, formato 1: tradicional, 50 minutos +1 hora, apresentação dos
> ataques principais e discussão de como os previnir/corrigir
> (desenvolvimento) e como os mitigar (nossa área, infra, defense in depth,
> firewall/ids/waf/hardening/pinning/camadas de seguranca/etc). E o formato 2
> é pra uma palestra de 2h no mínimo dividida normalmente em 2 dias,
> abordando ai sim o conteúdo inteiro.
>
> Essa palestra não é minha. Ela é do Renan Fagundes e Rafael Honorato,
> respectivamente desenvolvedores e analista de segurança na FreeBSD/IDS. Eu
> estou de co-autor, essas atividades são parte do que nós fazemos no nosso
> dia-a-dia atendendo bancos, financeiras, empresas onde segurança da
> informação não é negócio fim mas é parte crítica do negócio.
>
> Eu jamais conseguiria dar essa palestra. Quem me conhece sabe que é
> impossível eu falar de 26 camadas de segurança em 2 horas hehehe é
> necessário uma capacidade de sumarização que eu não tenho. Eu gasto 2h só
> na introdução do tema. Minha parte foi definir a estrutura, fundamentação e
> os ataques contra as aplicações. Os palestrantes definiram os formatos
> finais e cronograma. Eu só apoio e assisto :D
>
>
Agradeço a explicação.

Tem alguns assuntos que está apresentado nela que conhecia bem
superficialmente, contudo, como no próprio sumario já descreveu a
relevância estou a aprofundar-me no assunto.

Att.

>
> >
> >
> >>
> 
>  Dê uma olhada no Vetor 3, acredito que é a discussão que você está
> >> buscando iniciar. Lembrando que o vetor 3 deve subsidiar as camadas de
> >> segurança do Vetor 2.
> 
>  E o principal alguém deve colocar no papel as regras de negócio tanto
> >> do V3 quanto do V2 e onde possível as do V1 que forem obrigatórias
> >> (imperativas). Quando falarmos por exemplo do L3 do V2 estamos falando
> de
> >> regras bem definidas de como o desenvolvimento deve atuar pra subsidiar
> >> controles e auditoria tanto pra equipe de SI quanto pra equipe que vai
> >> gerenciar o backend/terminação no V3 e abaixo do V3.
> 
>  Em termos tecnológicos, minhas recomendações pro V3:
> 
>  0) FreeBSD / IPFW em Bridge
>  1) Linux Netfilter ou Sal a Gosto*
>  2) FreeBSD Suricata
>  3) FreeBSD Nginx
> 
>  *Como você sabe o compliance sugere que sempre que um dos domínios se
> >> repita que se busque Diversidade na Profundidade então como no Tier0 e
> no
> >> Tier1 temos firewall, entra um Linux ou legado existente se apropriado
> pra
> >> T1.
> 
>  Ja na Tier3, Nginx com:
> 
>  - NAXSI
>  - Mod Security
>  - Testcookie
>  - GeoIP
>  - CIDR limiters
>  - Anti Robot
>  - Hardened pra ataques de Slow e SSL
> 
>  Infelzimente o testcookie não é suficiente pra anti-robot, eu tive que
> >> rescrever e aqui passamos a usar um próprio baseado no testcookie mas
> com
> >> challenge response em VB Script (IE), Apple Script (osascript, Safari)
> e JS
> >> pra Firefox/Chrome.
> 
>  O CIDR Limiters eu também tive que fazer, tomei muito ataque
> >> distribuído que GeoIP não bastava, tive que setar políticas de banda ou
> de
> >> sessões por CIDR, hoje tenho locais com limite de 300 sessões pra cada
> /20
> >> e as vezes até 200 pra cada /21. Também coloco limite de banda por CIDR,
> >> então dependendo do tipo de ataque o que você tem open source pode não
> ser
> >> suficiente, por outro lado open source é sempre suficiente quando você
> pode
> >> desenvolver =) Aqui “em casa” temos no total 3 módulos do nginx feitos
> from
> >> scratch e o testcookie modificado. Alem das regras comerciais do Mod
> >> Security sempre imprescindíveis em alvos mais “cobiçados”.
> 
>  Por ultimo, o respaldo da diretoria e imposição da SI, em relação ao
> V2
> >> pois vai, cedo ou tarde, precisa definir um documento de Melhores
> Práticas
> >> de Desenvolvimento Seguro que imponham os controles e 

Re: [FUG-BR] Infra Web Services

[Patrick Tracanelli]

>> https://docs.google.com/document/d/1SISJWwrmPoD_bvOnMRwxbVm8o_x_PTJivVvQQTiiLhg/edit?usp=sharing
> 
> A palestra é especifica para empresas/corporação ou no treinamento da SSE a
> mesma é abordada.
> 
> A gama de informação é significativa, para quem está atoa valeu pelas
> referencias, pesquisando na net :D, assim que possivel quero estar podendo
> realizar um treinamento na FreeBSD Brasil.
> 
> Abrs.

Fala Paulo,

Não é abordado no SEE não, nessa linha. Essa palestra é na verdade da IDS 
(ids.com.br), empresa que pertence a FreeBSD Brasil, é uma palestra focada em 
desenvolvedores de aplicações Mobile e desenvolvimento de aplicações seguras em 
linhas com foco em segmento financeiro. Ou seja é pro desenvolvedor, aborda 
muito de webservice mas aborda muita coisa que não é nem de Webservice nem de 
infra de segurança, como técnicas contra ataques offband que é o Vetor1 de 
abordado.

Deve sim gerar um treinamento, inclusive a palestra esta dividida em 2 
formatos, formato 1: tradicional, 50 minutos +1 hora, apresentação dos ataques 
principais e discussão de como os previnir/corrigir (desenvolvimento) e como os 
mitigar (nossa área, infra, defense in depth, 
firewall/ids/waf/hardening/pinning/camadas de seguranca/etc). E o formato 2 é 
pra uma palestra de 2h no mínimo dividida normalmente em 2 dias, abordando ai 
sim o conteúdo inteiro.

Essa palestra não é minha. Ela é do Renan Fagundes e Rafael Honorato, 
respectivamente desenvolvedores e analista de segurança na FreeBSD/IDS. Eu 
estou de co-autor, essas atividades são parte do que nós fazemos no nosso 
dia-a-dia atendendo bancos, financeiras, empresas onde segurança da informação 
não é negócio fim mas é parte crítica do negócio.

Eu jamais conseguiria dar essa palestra. Quem me conhece sabe que é impossível 
eu falar de 26 camadas de segurança em 2 horas hehehe é necessário uma 
capacidade de sumarização que eu não tenho. Eu gasto 2h só na introdução do 
tema. Minha parte foi definir a estrutura, fundamentação e os ataques contra as 
aplicações. Os palestrantes definiram os formatos finais e cronograma. Eu só 
apoio e assisto :D


> 
> 
>> 
 
 Dê uma olhada no Vetor 3, acredito que é a discussão que você está
>> buscando iniciar. Lembrando que o vetor 3 deve subsidiar as camadas de
>> segurança do Vetor 2.
 
 E o principal alguém deve colocar no papel as regras de negócio tanto
>> do V3 quanto do V2 e onde possível as do V1 que forem obrigatórias
>> (imperativas). Quando falarmos por exemplo do L3 do V2 estamos falando de
>> regras bem definidas de como o desenvolvimento deve atuar pra subsidiar
>> controles e auditoria tanto pra equipe de SI quanto pra equipe que vai
>> gerenciar o backend/terminação no V3 e abaixo do V3.
 
 Em termos tecnológicos, minhas recomendações pro V3:
 
 0) FreeBSD / IPFW em Bridge
 1) Linux Netfilter ou Sal a Gosto*
 2) FreeBSD Suricata
 3) FreeBSD Nginx
 
 *Como você sabe o compliance sugere que sempre que um dos domínios se
>> repita que se busque Diversidade na Profundidade então como no Tier0 e no
>> Tier1 temos firewall, entra um Linux ou legado existente se apropriado pra
>> T1.
 
 Ja na Tier3, Nginx com:
 
 - NAXSI
 - Mod Security
 - Testcookie
 - GeoIP
 - CIDR limiters
 - Anti Robot
 - Hardened pra ataques de Slow e SSL
 
 Infelzimente o testcookie não é suficiente pra anti-robot, eu tive que
>> rescrever e aqui passamos a usar um próprio baseado no testcookie mas com
>> challenge response em VB Script (IE), Apple Script (osascript, Safari) e JS
>> pra Firefox/Chrome.
 
 O CIDR Limiters eu também tive que fazer, tomei muito ataque
>> distribuído que GeoIP não bastava, tive que setar políticas de banda ou de
>> sessões por CIDR, hoje tenho locais com limite de 300 sessões pra cada /20
>> e as vezes até 200 pra cada /21. Também coloco limite de banda por CIDR,
>> então dependendo do tipo de ataque o que você tem open source pode não ser
>> suficiente, por outro lado open source é sempre suficiente quando você pode
>> desenvolver =) Aqui “em casa” temos no total 3 módulos do nginx feitos from
>> scratch e o testcookie modificado. Alem das regras comerciais do Mod
>> Security sempre imprescindíveis em alvos mais “cobiçados”.
 
 Por ultimo, o respaldo da diretoria e imposição da SI, em relação ao V2
>> pois vai, cedo ou tarde, precisa definir um documento de Melhores Práticas
>> de Desenvolvimento Seguro que imponham os controles e os procedimentos do
>> Webservice. Pq senão ninguém faz OTP, ninguém segue RFC, ninguém faz X
>> alguma, e como webservices são essencialmente stateles, não tem o que você
>> faça na infra pra previnir um ataque de Replay ou Interception se o
>> desenvolvedor não cooperar ;-)
 
 
 
 
> On 20/05/2016, at 10:56, Ricardo Ferreira <
>> ricardo.ferre...@sotech.com.br> wrote:
> 
> Senhores,
> 
> 
> Tenho que implementar uma infra para suporte 

Re: [FUG-BR] Infra Web Services

[Otavio Augusto]

Em 23 de maio de 2016 14:33, Patrick Tracanelli
 escreveu:
>
>
>> On 23/05/2016, at 14:00, Ricardo Ferreira  
>> wrote:
>>
>>
>>
>>
>>
>>
>>
>> Em 23/05/2016 13:21, Patrick Tracanelli escreveu:
>>> Grande Ricardo,
>>>
>>> Aqui na empresa a equipe de desenvolvimento na IDS junto com a de segurança 
>>> da FreeBSD está dando uma palestra sobre esse tema, alias sobre o tema 
>>> de forma ampla envolvendo segurança Offband, no Transporte e na Terminação. 
>>> Vou compartilhar as notas da palestra aqui:
>>>
>>> https://docs.google.com/document/d/1SISJWwrmPoD_bvOnMRwxbVm8o_x_PTJivVvQQTiiLhg/edit?usp=sharing
>>>
>>> Dê uma olhada no Vetor 3, acredito que é a discussão que você está buscando 
>>> iniciar. Lembrando que o vetor 3 deve subsidiar as camadas de segurança 
>>> do Vetor 2.
>>>
>>> E o principal alguém deve colocar no papel as regras de negócio tanto do V3 
>>> quanto do V2 e onde possível as do V1 que forem obrigatórias 
>>> (imperativas). Quando falarmos por exemplo do L3 do V2 estamos falando de 
>>> regras bem definidas de como o desenvolvimento deve atuar pra subsidiar 
>>> controles e auditoria tanto pra equipe de SI quanto pra equipe que vai 
>>> gerenciar o  backend/terminação no V3 e abaixo do V3.
>>>
>>> Em termos tecnológicos, minhas recomendações pro V3:
>>>
>>> 0) FreeBSD / IPFW em Bridge
>>> 1) Linux Netfilter ou Sal a Gosto*

Discussão bacana mas tenho uma dúvida.
Este Firewall de outro sabor(Linux, OpenBSD, NetBSD) tem que possuir
as mesmas regras que o FreeBSD/IPFW ?
Ou deve se preocupar com  filtros diferentes ?


>>> 2) FreeBSD Suricata
>>> 3) FreeBSD Nginx
>>>
>>> *Como você sabe o compliance sugere que sempre que um dos domínios se 
>>> repita que se busque Diversidade na Profundidade então como no Tier0 e no 
>>> Tier1 temos firewall, entra um Linux ou legado existente se apropriado pra 
>>> T1.
>>>
>>> Ja na Tier3, Nginx com:
>>>
>>> - NAXSI
>>> - Mod Security
>>> - Testcookie
>>> - GeoIP
>>> - CIDR limiters
>>> - Anti Robot
>>> - Hardened pra ataques de Slow e SSL
>>>
>>> Infelzimente o testcookie não é suficiente pra anti-robot, eu tive que 
>>> rescrever e aqui passamos a usar um próprio baseado no testcookie mas com 
>>> challenge response em VB Script (IE), Apple Script (osascript, Safari) e JS 
>>> pra Firefox/Chrome.
>>>
>>> O CIDR Limiters eu também tive que fazer, tomei muito ataque distribuído 
>>> que GeoIP não bastava, tive que setar políticas de banda ou de sessões por 
>>> CIDR, hoje tenho locais com limite de 300 sessões pra cada /20 e as vezes 
>>> até 200 pra cada /21. Também coloco limite de banda por CIDR, então 
>>> dependendo do tipo de ataque o que você tem open source pode não ser 
>>> suficiente, por outro lado open source é sempre suficiente quando você pode 
>>> desenvolver =) Aqui “em casa” temos no total 3 módulos do nginx feitos from 
>>> scratch e o testcookie modificado. Alem das regras comerciais do Mod 
>>> Security sempre imprescindíveis em alvos mais “cobiçados”.
>>>
>>> Por ultimo, o respaldo da diretoria e imposição da SI, em relação ao V2 
>>> pois vai, cedo ou tarde, precisa definir um documento de Melhores Práticas 
>>> de Desenvolvimento Seguro que imponham os controles e os procedimentos do 
>>> Webservice. Pq senão ninguém faz OTP, ninguém segue RFC, ninguém faz X 
>>> alguma, e como webservices são essencialmente stateles, não tem o que você 
>>> faça na infra pra previnir um ataque de Replay ou Interception se o 
>>> desenvolvedor não cooperar ;-)
>>>
>>>
>>>
>>>
 On 20/05/2016, at 10:56, Ricardo Ferreira  
 wrote:

 Senhores,


 Tenho que implementar uma infra para suporte a Web Services e claro que 
 quero fazer em FreeBSD. Tenho algumas idéias como Apache mais Tomcat por 
 exemplo, dentre outras... mas gostaria de ouvir dos companheiros 
 sugestões, experiências, soluções de segurança, críticas dentre outros 
 detalhes a fim de alimentar o processo decisórioUm detalhe importante 
 é que segurança se impõe sobre todos os outros aspectos.

 []s


 Ricardo Ferreira


 -
 Histórico: http://www.fug.com.br/historico/html/freebsd/
 Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>>> --
>>> Patrick Tracanelli
>>>
>>> FreeBSD Brasil LTDA.
>>> Tel.: (31) 3516-0800
>>> 316...@sip.freebsdbrasil.com.br
>>> http://www.freebsdbrasil.com.br
>>> "Long live Hanin Elias, Kim Deal!"
>>>
>>> -
>>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>>>
>> Prezado Patrick,
>>
>>
>> Grato pelas observações, sugestões e orientações. Acho que tá na hora de 
>> voltar na freebsdbrasil pra reciclar no SEE, hehe faz um tempo já….
>
> Hahaha sempre divertido =)
>
>>
>> Estou no início do início do projeto e claro que 

Re: [FUG-BR] Infra Web Services

[Paulo Henrique]

Em 23 de maio de 2016 14:33, Patrick Tracanelli  escreveu:

>
>
> > On 23/05/2016, at 14:00, Ricardo Ferreira <
> ricardo.ferre...@sotech.com.br> wrote:
> >
> >
> >
> >
> >
> >
> >
> > Em 23/05/2016 13:21, Patrick Tracanelli escreveu:
> >> Grande Ricardo,
> >>
> >> Aqui na empresa a equipe de desenvolvimento na IDS junto com a de
> segurança da FreeBSD está dando uma palestra sobre esse tema, alias sobre o
> tema de forma ampla envolvendo segurança Offband, no Transporte e na
> Terminação. Vou compartilhar as notas da palestra aqui:
> >>
> >>
> https://docs.google.com/document/d/1SISJWwrmPoD_bvOnMRwxbVm8o_x_PTJivVvQQTiiLhg/edit?usp=sharing
>

A palestra é especifica para empresas/corporação ou no treinamento da SSE a
mesma é abordada.

A gama de informação é significativa, para quem está atoa valeu pelas
referencias, pesquisando na net :D, assim que possivel quero estar podendo
realizar um treinamento na FreeBSD Brasil.

Abrs.


>
> >>
> >> Dê uma olhada no Vetor 3, acredito que é a discussão que você está
> buscando iniciar. Lembrando que o vetor 3 deve subsidiar as camadas de
> segurança do Vetor 2.
> >>
> >> E o principal alguém deve colocar no papel as regras de negócio tanto
> do V3 quanto do V2 e onde possível as do V1 que forem obrigatórias
> (imperativas). Quando falarmos por exemplo do L3 do V2 estamos falando de
> regras bem definidas de como o desenvolvimento deve atuar pra subsidiar
> controles e auditoria tanto pra equipe de SI quanto pra equipe que vai
> gerenciar o backend/terminação no V3 e abaixo do V3.
> >>
> >> Em termos tecnológicos, minhas recomendações pro V3:
> >>
> >> 0) FreeBSD / IPFW em Bridge
> >> 1) Linux Netfilter ou Sal a Gosto*
> >> 2) FreeBSD Suricata
> >> 3) FreeBSD Nginx
> >>
> >> *Como você sabe o compliance sugere que sempre que um dos domínios se
> repita que se busque Diversidade na Profundidade então como no Tier0 e no
> Tier1 temos firewall, entra um Linux ou legado existente se apropriado pra
> T1.
> >>
> >> Ja na Tier3, Nginx com:
> >>
> >> - NAXSI
> >> - Mod Security
> >> - Testcookie
> >> - GeoIP
> >> - CIDR limiters
> >> - Anti Robot
> >> - Hardened pra ataques de Slow e SSL
> >>
> >> Infelzimente o testcookie não é suficiente pra anti-robot, eu tive que
> rescrever e aqui passamos a usar um próprio baseado no testcookie mas com
> challenge response em VB Script (IE), Apple Script (osascript, Safari) e JS
> pra Firefox/Chrome.
> >>
> >> O CIDR Limiters eu também tive que fazer, tomei muito ataque
> distribuído que GeoIP não bastava, tive que setar políticas de banda ou de
> sessões por CIDR, hoje tenho locais com limite de 300 sessões pra cada /20
> e as vezes até 200 pra cada /21. Também coloco limite de banda por CIDR,
> então dependendo do tipo de ataque o que você tem open source pode não ser
> suficiente, por outro lado open source é sempre suficiente quando você pode
> desenvolver =) Aqui “em casa” temos no total 3 módulos do nginx feitos from
> scratch e o testcookie modificado. Alem das regras comerciais do Mod
> Security sempre imprescindíveis em alvos mais “cobiçados”.
> >>
> >> Por ultimo, o respaldo da diretoria e imposição da SI, em relação ao V2
> pois vai, cedo ou tarde, precisa definir um documento de Melhores Práticas
> de Desenvolvimento Seguro que imponham os controles e os procedimentos do
> Webservice. Pq senão ninguém faz OTP, ninguém segue RFC, ninguém faz X
> alguma, e como webservices são essencialmente stateles, não tem o que você
> faça na infra pra previnir um ataque de Replay ou Interception se o
> desenvolvedor não cooperar ;-)
> >>
> >>
> >>
> >>
> >>> On 20/05/2016, at 10:56, Ricardo Ferreira <
> ricardo.ferre...@sotech.com.br> wrote:
> >>>
> >>> Senhores,
> >>>
> >>>
> >>> Tenho que implementar uma infra para suporte a Web Services e claro
> que quero fazer em FreeBSD. Tenho algumas idéias como Apache mais Tomcat
> por exemplo, dentre outras... mas gostaria de ouvir dos companheiros
> sugestões, experiências, soluções de segurança, críticas dentre outros
> detalhes a fim de alimentar o processo decisórioUm detalhe importante é
> que segurança se impõe sobre todos os outros aspectos.
> >>>
> >>> []s
> >>>
> >>>
> >>> Ricardo Ferreira
> >>>
> >>>
> >>> -
> >>> Histórico: http://www.fug.com.br/historico/html/freebsd/
> >>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
> >> --
> >> Patrick Tracanelli
> >>
> >> FreeBSD Brasil LTDA.
> >> Tel.: (31) 3516-0800
> >> 316...@sip.freebsdbrasil.com.br
> >> http://www.freebsdbrasil.com.br
> >> "Long live Hanin Elias, Kim Deal!"
> >>
> >> -
> >> Histórico: http://www.fug.com.br/historico/html/freebsd/
> >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
> >>
> > Prezado Patrick,
> >
> >
> > Grato pelas observações, sugestões e orientações. Acho que tá na hora de
> voltar na freebsdbrasil pra reciclar no SEE, hehe faz um tempo já….
>
> Hahaha sempre divertido =)
>
> >
> > Estou 

Re: [FUG-BR] Infra Web Services

[Patrick Tracanelli]

> On 23/05/2016, at 14:00, Ricardo Ferreira  
> wrote:
> 
> 
> 
> 
>   
>   
> 
> Em 23/05/2016 13:21, Patrick Tracanelli escreveu:
>> Grande Ricardo,
>> 
>> Aqui na empresa a equipe de desenvolvimento na IDS junto com a de segurança 
>> da FreeBSD está dando uma palestra sobre esse tema, alias sobre o tema de 
>> forma ampla envolvendo segurança Offband, no Transporte e na Terminação. Vou 
>> compartilhar as notas da palestra aqui:
>> 
>> https://docs.google.com/document/d/1SISJWwrmPoD_bvOnMRwxbVm8o_x_PTJivVvQQTiiLhg/edit?usp=sharing
>> 
>> Dê uma olhada no Vetor 3, acredito que é a discussão que você está buscando 
>> iniciar. Lembrando que o vetor 3 deve subsidiar as camadas de segurança do 
>> Vetor 2.
>> 
>> E o principal alguém deve colocar no papel as regras de negócio tanto do V3 
>> quanto do V2 e onde possível as do V1 que forem obrigatórias (imperativas). 
>> Quando falarmos por exemplo do L3 do V2 estamos falando de regras bem 
>> definidas de como o desenvolvimento deve atuar pra subsidiar controles e 
>> auditoria tanto pra equipe de SI quanto pra equipe que vai gerenciar o 
>> backend/terminação no V3 e abaixo do V3.
>> 
>> Em termos tecnológicos, minhas recomendações pro V3:
>> 
>> 0) FreeBSD / IPFW em Bridge
>> 1) Linux Netfilter ou Sal a Gosto*
>> 2) FreeBSD Suricata
>> 3) FreeBSD Nginx
>> 
>> *Como você sabe o compliance sugere que sempre que um dos domínios se repita 
>> que se busque Diversidade na Profundidade então como no Tier0 e no Tier1 
>> temos firewall, entra um Linux ou legado existente se apropriado pra T1.
>> 
>> Ja na Tier3, Nginx com:
>> 
>> - NAXSI
>> - Mod Security
>> - Testcookie
>> - GeoIP
>> - CIDR limiters
>> - Anti Robot
>> - Hardened pra ataques de Slow e SSL
>> 
>> Infelzimente o testcookie não é suficiente pra anti-robot, eu tive que 
>> rescrever e aqui passamos a usar um próprio baseado no testcookie mas com 
>> challenge response em VB Script (IE), Apple Script (osascript, Safari) e JS 
>> pra Firefox/Chrome.
>> 
>> O CIDR Limiters eu também tive que fazer, tomei muito ataque distribuído que 
>> GeoIP não bastava, tive que setar políticas de banda ou de sessões por CIDR, 
>> hoje tenho locais com limite de 300 sessões pra cada /20 e as vezes até 200 
>> pra cada /21. Também coloco limite de banda por CIDR, então dependendo do 
>> tipo de ataque o que você tem open source pode não ser suficiente, por outro 
>> lado open source é sempre suficiente quando você pode desenvolver =) Aqui 
>> “em casa” temos no total 3 módulos do nginx feitos from scratch e o 
>> testcookie modificado. Alem das regras comerciais do Mod Security sempre 
>> imprescindíveis em alvos mais “cobiçados”.
>> 
>> Por ultimo, o respaldo da diretoria e imposição da SI, em relação ao V2 pois 
>> vai, cedo ou tarde, precisa definir um documento de Melhores Práticas de 
>> Desenvolvimento Seguro que imponham os controles e os procedimentos do 
>> Webservice. Pq senão ninguém faz OTP, ninguém segue RFC, ninguém faz X 
>> alguma, e como webservices são essencialmente stateles, não tem o que você 
>> faça na infra pra previnir um ataque de Replay ou Interception se o 
>> desenvolvedor não cooperar ;-)
>> 
>> 
>> 
>> 
>>> On 20/05/2016, at 10:56, Ricardo Ferreira  
>>> wrote:
>>> 
>>> Senhores,
>>> 
>>> 
>>> Tenho que implementar uma infra para suporte a Web Services e claro que 
>>> quero fazer em FreeBSD. Tenho algumas idéias como Apache mais Tomcat por 
>>> exemplo, dentre outras... mas gostaria de ouvir dos companheiros sugestões, 
>>> experiências, soluções de segurança, críticas dentre outros detalhes a fim 
>>> de alimentar o processo decisórioUm detalhe importante é que segurança 
>>> se impõe sobre todos os outros aspectos.
>>> 
>>> []s
>>> 
>>> 
>>> Ricardo Ferreira
>>> 
>>> 
>>> -
>>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>> --
>> Patrick Tracanelli
>> 
>> FreeBSD Brasil LTDA.
>> Tel.: (31) 3516-0800
>> 316...@sip.freebsdbrasil.com.br
>> http://www.freebsdbrasil.com.br
>> "Long live Hanin Elias, Kim Deal!"
>> 
>> -
>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>> 
> Prezado Patrick,
> 
> 
> Grato pelas observações, sugestões e orientações. Acho que tá na hora de 
> voltar na freebsdbrasil pra reciclar no SEE, hehe faz um tempo já….

Hahaha sempre divertido =)

> 
> Estou no início do início do projeto e claro que o FreeBSD é premissa. Todo o 
> resto tem que girar em torno deleQuanto ao *sal a gosto já tinha pensado 
> nisso e o CentOS deve ser a escolha mas to pensando em usar o NetBSD no 
> lugar. (no flames please nada contra)

De acordo, é outro kernel e tem 2 opções de firewall diferente de ipfw, 
incluindo NPF, +1 pra diversidade :)


> apenas para facilitar o suporte lá na frente 

Re: [FUG-BR] Infra Web Services

[Patrick Tracanelli]

> On 23/05/2016, at 14:05, alla...@ig.com.br wrote:
> 
> 
> 
> Grande Patrick, blz? Vai haver aberta ao publico? 

Sim, são todas aberta ao publico, uma delas será no Latinoware. Outras são em 
universidades e congressos de desenvolvimento =)

> 
> Valeu. 
> 
> Allan Patrick 
> 
> Guarapuava/PR 
> 
> Em 23/05/2016 13:21, Patrick Tracanelli escreveu: 
> 
>> Grande Ricardo,
>> 
>> Aqui na empresa a equipe de desenvolvimento na IDS junto com a de segurança 
>> da FreeBSD está dando uma palestra sobre esse tema, alias sobre o tema de 
>> forma ampla envolvendo segurança Offband, no Transporte e na Terminação. Vou 
>> compartilhar as notas da palestra aqui:
>> 
>> https://docs.google.com/document/d/1SISJWwrmPoD_bvOnMRwxbVm8o_x_PTJivVvQQTiiLhg/edit?usp=sharing
>>  [3]Dê uma olhada no Vetor 3, acredito que é a discussão que você está 
>> buscando iniciar. Lembrando que o vetor 3 deve subsidiar as camadas de 
>> segurança do Vetor 2.
>> 
>> E o principal alguém deve colocar no papel as regras de negócio tanto do V3 
>> quanto do V2 e onde possível as do V1 que forem obrigatórias (imperativas). 
>> Quando falarmos por exemplo do L3 do V2 estamos falando de regras bem 
>> definidas de como o desenvolvimento deve atuar pra subsidiar controles e 
>> auditoria tanto pra equipe de SI quanto pra equipe que vai gerenciar o 
>> backend/terminação no V3 e abaixo do V3.
>> 
>> Em termos tecnológicos, minhas recomendações pro V3:
>> 
>> 0) FreeBSD / IPFW em Bridge
>> 1) Linux Netfilter ou Sal a Gosto*
>> 2) FreeBSD Suricata
>> 3) FreeBSD Nginx
>> 
>> *Como você sabe o compliance sugere que sempre que um dos domínios se repita 
>> que se busque Diversidade na Profundidade então como no Tier0 e no Tier1 
>> temos firewall, entra um Linux ou legado existente se apropriado pra T1.
>> 
>> Ja na Tier3, Nginx com:
>> 
>> - NAXSI
>> - Mod Security
>> - Testcookie
>> - GeoIP
>> - CIDR limiters
>> - Anti Robot
>> - Hardened pra ataques de Slow e SSL
>> 
>> Infelzimente o testcookie não é suficiente pra anti-robot, eu tive que 
>> rescrever e aqui passamos a usar um próprio baseado no testcookie mas com 
>> challenge response em VB Script (IE), Apple Script (osascript, Safari) e JS 
>> pra Firefox/Chrome.
>> 
>> O CIDR Limiters eu também tive que fazer, tomei muito ataque distribuído que 
>> GeoIP não bastava, tive que setar políticas de banda ou de sessões por CIDR, 
>> hoje tenho locais com limite de 300 sessões pra cada /20 e as vezes até 200 
>> pra cada /21. Também coloco limite de banda por CIDR, então dependendo do 
>> tipo de ataque o que você tem open source pode não ser suficiente, por outro 
>> lado open source é sempre suficiente quando você pode desenvolver =) Aqui 
>> "em casa" temos no total 3 módulos do nginx feitos from scratch e o 
>> testcookie modificado. Alem das regras comerciais do Mod Security sempre 
>> imprescindíveis em alvos mais "cobiçados".
>> 
>> Por ultimo, o respaldo da diretoria e imposição da SI, em relação ao V2 pois 
>> vai, cedo ou tarde, precisa definir um documento de Melhores Práticas de 
>> Desenvolvimento Seguro que imponham os controles e os procedimentos do 
>> Webservice. Pq senão ninguém faz OTP, ninguém segue RFC, ninguém faz X 
>> alguma, e como webservices são essencialmente stateles, não tem o que você 
>> faça na infra pra previnir um ataque de Replay ou Interception se o 
>> desenvolvedor não cooperar ;-)
>> 
>>> On 20/05/2016, at 10:56, Ricardo Ferreira  
>>> wrote: Senhores, Tenho que implementar uma infra para suporte a Web 
>>> Services e claro que quero fazer em FreeBSD. Tenho algumas idéias como 
>>> Apache mais Tomcat por exemplo, dentre outras... mas gostaria de ouvir dos 
>>> companheiros sugestões, experiências, soluções de segurança, críticas 
>>> dentre outros detalhes a fim de alimentar o processo decisórioUm 
>>> detalhe importante é que segurança se impõe sobre todos os outros aspectos. 
>>> []s Ricardo Ferreira - Histórico: 
>>> http://www.fug.com.br/historico/html/freebsd/ [1] Sair da lista: 
>>> https://www.fug.com.br/mailman/listinfo/freebsd [2]
>> 
>> --
>> Patrick Tracanelli
>> 
>> FreeBSD Brasil LTDA.
>> Tel.: (31) 3516-0800
>> 316...@sip.freebsdbrasil.com.br
>> http://www.freebsdbrasil.com.br [4]
>> "Long live Hanin Elias, Kim Deal!"
>> 
>> -
>> Histórico: http://www.fug.com.br/historico/html/freebsd/ [1]
>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd [2]
> 
> 
> Links:
> --
> [1] http://www.fug.com.br/historico/html/freebsd/
> [2] https://www.fug.com.br/mailman/listinfo/freebsd
> [3]
> https://docs.google.com/document/d/1SISJWwrmPoD_bvOnMRwxbVm8o_x_PTJivVvQQTiiLhg/edit?usp=sharing
> [4] http://www.freebsdbrasil.com.br
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

--
Patrick Tracanelli

FreeBSD Brasil LTDA.
Tel.: (31) 3516-0800

Re: [FUG-BR] Infra Web Services

[allanpk]

 

Grande Patrick, blz? Vai haver aberta ao publico? 

Valeu. 

Allan Patrick 

Guarapuava/PR 

Em 23/05/2016 13:21, Patrick Tracanelli escreveu: 

> Grande Ricardo,
> 
> Aqui na empresa a equipe de desenvolvimento na IDS junto com a de segurança 
> da FreeBSD está dando uma palestra sobre esse tema, alias sobre o tema de 
> forma ampla envolvendo segurança Offband, no Transporte e na Terminação. Vou 
> compartilhar as notas da palestra aqui:
> 
> https://docs.google.com/document/d/1SISJWwrmPoD_bvOnMRwxbVm8o_x_PTJivVvQQTiiLhg/edit?usp=sharing
>  [3]Dê uma olhada no Vetor 3, acredito que é a discussão que você está 
> buscando iniciar. Lembrando que o vetor 3 deve subsidiar as camadas de 
> segurança do Vetor 2.
> 
> E o principal alguém deve colocar no papel as regras de negócio tanto do V3 
> quanto do V2 e onde possível as do V1 que forem obrigatórias (imperativas). 
> Quando falarmos por exemplo do L3 do V2 estamos falando de regras bem 
> definidas de como o desenvolvimento deve atuar pra subsidiar controles e 
> auditoria tanto pra equipe de SI quanto pra equipe que vai gerenciar o 
> backend/terminação no V3 e abaixo do V3.
> 
> Em termos tecnológicos, minhas recomendações pro V3:
> 
> 0) FreeBSD / IPFW em Bridge
> 1) Linux Netfilter ou Sal a Gosto*
> 2) FreeBSD Suricata
> 3) FreeBSD Nginx
> 
> *Como você sabe o compliance sugere que sempre que um dos domínios se repita 
> que se busque Diversidade na Profundidade então como no Tier0 e no Tier1 
> temos firewall, entra um Linux ou legado existente se apropriado pra T1.
> 
> Ja na Tier3, Nginx com:
> 
> - NAXSI
> - Mod Security
> - Testcookie
> - GeoIP
> - CIDR limiters
> - Anti Robot
> - Hardened pra ataques de Slow e SSL
> 
> Infelzimente o testcookie não é suficiente pra anti-robot, eu tive que 
> rescrever e aqui passamos a usar um próprio baseado no testcookie mas com 
> challenge response em VB Script (IE), Apple Script (osascript, Safari) e JS 
> pra Firefox/Chrome.
> 
> O CIDR Limiters eu também tive que fazer, tomei muito ataque distribuído que 
> GeoIP não bastava, tive que setar políticas de banda ou de sessões por CIDR, 
> hoje tenho locais com limite de 300 sessões pra cada /20 e as vezes até 200 
> pra cada /21. Também coloco limite de banda por CIDR, então dependendo do 
> tipo de ataque o que você tem open source pode não ser suficiente, por outro 
> lado open source é sempre suficiente quando você pode desenvolver =) Aqui "em 
> casa" temos no total 3 módulos do nginx feitos from scratch e o testcookie 
> modificado. Alem das regras comerciais do Mod Security sempre imprescindíveis 
> em alvos mais "cobiçados".
> 
> Por ultimo, o respaldo da diretoria e imposição da SI, em relação ao V2 pois 
> vai, cedo ou tarde, precisa definir um documento de Melhores Práticas de 
> Desenvolvimento Seguro que imponham os controles e os procedimentos do 
> Webservice. Pq senão ninguém faz OTP, ninguém segue RFC, ninguém faz X 
> alguma, e como webservices são essencialmente stateles, não tem o que você 
> faça na infra pra previnir um ataque de Replay ou Interception se o 
> desenvolvedor não cooperar ;-)
> 
>> On 20/05/2016, at 10:56, Ricardo Ferreira  
>> wrote: Senhores, Tenho que implementar uma infra para suporte a Web Services 
>> e claro que quero fazer em FreeBSD. Tenho algumas idéias como Apache mais 
>> Tomcat por exemplo, dentre outras... mas gostaria de ouvir dos companheiros 
>> sugestões, experiências, soluções de segurança, críticas dentre outros 
>> detalhes a fim de alimentar o processo decisórioUm detalhe importante é 
>> que segurança se impõe sobre todos os outros aspectos. []s Ricardo Ferreira 
>> - Histórico: 
>> http://www.fug.com.br/historico/html/freebsd/ [1] Sair da lista: 
>> https://www.fug.com.br/mailman/listinfo/freebsd [2]
> 
> --
> Patrick Tracanelli
> 
> FreeBSD Brasil LTDA.
> Tel.: (31) 3516-0800
> 316...@sip.freebsdbrasil.com.br
> http://www.freebsdbrasil.com.br [4]
> "Long live Hanin Elias, Kim Deal!"
> 
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/ [1]
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd [2]
 

Links:
--
[1] http://www.fug.com.br/historico/html/freebsd/
[2] https://www.fug.com.br/mailman/listinfo/freebsd
[3]
https://docs.google.com/document/d/1SISJWwrmPoD_bvOnMRwxbVm8o_x_PTJivVvQQTiiLhg/edit?usp=sharing
[4] http://www.freebsdbrasil.com.br
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Infra Web Services

[Ricardo Ferreira]

Em 23/05/2016 13:21, Patrick Tracanelli escreveu:

Grande Ricardo,

Aqui na empresa a equipe de desenvolvimento na IDS junto com a de segurança da 
FreeBSD está dando uma palestra sobre esse tema, alias sobre o tema de forma 
ampla envolvendo segurança Offband, no Transporte e na Terminação. Vou 
compartilhar as notas da palestra aqui:

https://docs.google.com/document/d/1SISJWwrmPoD_bvOnMRwxbVm8o_x_PTJivVvQQTiiLhg/edit?usp=sharing

Dê uma olhada no Vetor 3, acredito que é a discussão que você está buscando 
iniciar. Lembrando que o vetor 3 deve subsidiar as camadas de segurança do 
Vetor 2.

E o principal alguém deve colocar no papel as regras de negócio tanto do V3 
quanto do V2 e onde possível as do V1 que forem obrigatórias (imperativas). 
Quando falarmos por exemplo do L3 do V2 estamos falando de regras bem definidas 
de como o desenvolvimento deve atuar pra subsidiar controles e auditoria tanto 
pra equipe de SI quanto pra equipe que vai gerenciar o backend/terminação no V3 
e abaixo do V3.

Em termos tecnológicos, minhas recomendações pro V3:

0) FreeBSD / IPFW em Bridge
1) Linux Netfilter ou Sal a Gosto*
2) FreeBSD Suricata
3) FreeBSD Nginx

*Como você sabe o compliance sugere que sempre que um dos domínios se repita 
que se busque Diversidade na Profundidade então como no Tier0 e no Tier1 temos 
firewall, entra um Linux ou legado existente se apropriado pra T1.

Ja na Tier3, Nginx com:

- NAXSI
- Mod Security
- Testcookie
- GeoIP
- CIDR limiters
- Anti Robot
- Hardened pra ataques de Slow e SSL

Infelzimente o testcookie não é suficiente pra anti-robot, eu tive que 
rescrever e aqui passamos a usar um próprio baseado no testcookie mas com 
challenge response em VB Script (IE), Apple Script (osascript, Safari) e JS pra 
Firefox/Chrome.

O CIDR Limiters eu também tive que fazer, tomei muito ataque distribuído que 
GeoIP não bastava, tive que setar políticas de banda ou de sessões por CIDR, 
hoje tenho locais com limite de 300 sessões pra cada /20 e as vezes até 200 pra 
cada /21. Também coloco limite de banda por CIDR, então dependendo do tipo de 
ataque o que você tem open source pode não ser suficiente, por outro lado open 
source é sempre suficiente quando você pode desenvolver =) Aqui “em casa” temos 
no total 3 módulos do nginx feitos from scratch e o testcookie modificado. Alem 
das regras comerciais do Mod Security sempre imprescindíveis em alvos mais 
“cobiçados”.

Por ultimo, o respaldo da diretoria e imposição da SI, em relação ao V2 pois 
vai, cedo ou tarde, precisa definir um documento de Melhores Práticas de 
Desenvolvimento Seguro que imponham os controles e os procedimentos do 
Webservice. Pq senão ninguém faz OTP, ninguém segue RFC, ninguém faz X alguma, 
e como webservices são essencialmente stateles, não tem o que você faça na 
infra pra previnir um ataque de Replay ou Interception se o desenvolvedor não 
cooperar ;-)





On 20/05/2016, at 10:56, Ricardo Ferreira  
wrote:

Senhores,


Tenho que implementar uma infra para suporte a Web Services e claro que quero 
fazer em FreeBSD. Tenho algumas idéias como Apache mais Tomcat por exemplo, 
dentre outras... mas gostaria de ouvir dos companheiros sugestões, 
experiências, soluções de segurança, críticas dentre outros detalhes a fim de 
alimentar o processo decisórioUm detalhe importante é que segurança se 
impõe sobre todos os outros aspectos.

[]s


Ricardo Ferreira


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

--
Patrick Tracanelli

FreeBSD Brasil LTDA.
Tel.: (31) 3516-0800
316...@sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"

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


Prezado Patrick,


Grato pelas observações, sugestões e orientações. Acho que tá na hora de 
voltar na freebsdbrasil pra reciclar no SEE, hehe faz um tempo já


Estou no início do início do projeto e claro que o FreeBSD é premissa. 
Todo o resto tem que girar em torno deleQuanto ao *sal a gosto já 
tinha pensado nisso e o CentOS deve ser a escolha mas to pensando em 
usar o NetBSD no lugar. (no flames please nada contra) apenas 
para facilitar o suporte lá na frente pois não conseguimos engolir ainda 
o systemd e sua distância do POSIX


Vou analisar o conteúdo e assim que o projeto progredir vou postando 
aqui as soluções pois entendo ser um assunto interessante e divertido e 
que certamente deve ter mais interessados


Abraços,

Ricardo Ferreira

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

Re: [FUG-BR] Infra Web Services

[Patrick Tracanelli]

Grande Ricardo,

Aqui na empresa a equipe de desenvolvimento na IDS junto com a de segurança da 
FreeBSD está dando uma palestra sobre esse tema, alias sobre o tema de forma 
ampla envolvendo segurança Offband, no Transporte e na Terminação. Vou 
compartilhar as notas da palestra aqui:

https://docs.google.com/document/d/1SISJWwrmPoD_bvOnMRwxbVm8o_x_PTJivVvQQTiiLhg/edit?usp=sharing

Dê uma olhada no Vetor 3, acredito que é a discussão que você está buscando 
iniciar. Lembrando que o vetor 3 deve subsidiar as camadas de segurança do 
Vetor 2.

E o principal alguém deve colocar no papel as regras de negócio tanto do V3 
quanto do V2 e onde possível as do V1 que forem obrigatórias (imperativas). 
Quando falarmos por exemplo do L3 do V2 estamos falando de regras bem definidas 
de como o desenvolvimento deve atuar pra subsidiar controles e auditoria tanto 
pra equipe de SI quanto pra equipe que vai gerenciar o backend/terminação no V3 
e abaixo do V3.

Em termos tecnológicos, minhas recomendações pro V3:

0) FreeBSD / IPFW em Bridge
1) Linux Netfilter ou Sal a Gosto*
2) FreeBSD Suricata
3) FreeBSD Nginx

*Como você sabe o compliance sugere que sempre que um dos domínios se repita 
que se busque Diversidade na Profundidade então como no Tier0 e no Tier1 temos 
firewall, entra um Linux ou legado existente se apropriado pra T1.

Ja na Tier3, Nginx com:

- NAXSI
- Mod Security
- Testcookie
- GeoIP
- CIDR limiters
- Anti Robot
- Hardened pra ataques de Slow e SSL

Infelzimente o testcookie não é suficiente pra anti-robot, eu tive que 
rescrever e aqui passamos a usar um próprio baseado no testcookie mas com 
challenge response em VB Script (IE), Apple Script (osascript, Safari) e JS pra 
Firefox/Chrome.

O CIDR Limiters eu também tive que fazer, tomei muito ataque distribuído que 
GeoIP não bastava, tive que setar políticas de banda ou de sessões por CIDR, 
hoje tenho locais com limite de 300 sessões pra cada /20 e as vezes até 200 pra 
cada /21. Também coloco limite de banda por CIDR, então dependendo do tipo de 
ataque o que você tem open source pode não ser suficiente, por outro lado open 
source é sempre suficiente quando você pode desenvolver =) Aqui “em casa” temos 
no total 3 módulos do nginx feitos from scratch e o testcookie modificado. Alem 
das regras comerciais do Mod Security sempre imprescindíveis em alvos mais 
“cobiçados”.

Por ultimo, o respaldo da diretoria e imposição da SI, em relação ao V2 pois 
vai, cedo ou tarde, precisa definir um documento de Melhores Práticas de 
Desenvolvimento Seguro que imponham os controles e os procedimentos do 
Webservice. Pq senão ninguém faz OTP, ninguém segue RFC, ninguém faz X alguma, 
e como webservices são essencialmente stateles, não tem o que você faça na 
infra pra previnir um ataque de Replay ou Interception se o desenvolvedor não 
cooperar ;-)




> On 20/05/2016, at 10:56, Ricardo Ferreira  
> wrote:
> 
> Senhores,
> 
> 
> Tenho que implementar uma infra para suporte a Web Services e claro que quero 
> fazer em FreeBSD. Tenho algumas idéias como Apache mais Tomcat por exemplo, 
> dentre outras... mas gostaria de ouvir dos companheiros sugestões, 
> experiências, soluções de segurança, críticas dentre outros detalhes a fim de 
> alimentar o processo decisórioUm detalhe importante é que segurança se 
> impõe sobre todos os outros aspectos.
> 
> []s
> 
> 
> Ricardo Ferreira
> 
> 
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

--
Patrick Tracanelli

FreeBSD Brasil LTDA.
Tel.: (31) 3516-0800
316...@sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"

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

Re: [FUG-BR] Infra Web Services

[Rafael Henrique Faria]

2016-05-20 16:23 GMT-03:00 Paulo Henrique - BSD Brasil :
>
>
> On 20/05/16 15:40, Wilson Mendes wrote:
>> Prezado Ricardo,  a fug têm uma enciclopédia de informação sobre o
>> assunto, assim como un excelente índice. Pesquise e a sua possível
>> dúvida ainda existir, será de grande colaboração para essa
>> enciclopédia viva.
>>
>> Abs
>>
>> Sent with AquaMail for Android
>> http://www.aqua-mail.com
>>
>>
>> On May 20, 2016 10:56:42 AM Ricardo Ferreira
>>  wrote:
>>
>>> Senhores,
>>>
>>>
>>> Tenho que implementar uma infra para suporte a Web Services e claro que
>>> quero fazer em FreeBSD. Tenho algumas idéias como Apache mais Tomcat por
>>> exemplo, dentre outras... mas gostaria de ouvir dos companheiros
>>> sugestões, experiências, soluções de segurança, críticas dentre outros
>>> detalhes a fim de alimentar o processo decisórioUm detalhe
>>> importante é que segurança se impõe sobre todos os outros aspectos.
>>>
>>> []s
>>>
>>>
>>> Ricardo Ferreira
>>>
>>>
>>> -
>>> 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
> Cuidado com Top-posting, acaba estragando o histórico da lista.
>
> Bom vamos lá.
>
> Primeiro, que bom que considerando o FreeBSD como sistema operacional
> base para a sua solução, contudo tem que ser realista.
>
> Não acompanho o projeto tomcat para saber como está ele com relação as
> outras plataformas ( Linux/Windows ), contudo se o foco é segurança
> creio que usar uma tecnologia Java já é um tiro no pé que irá levar pelo
> menos uma perna, o java vem sendo constantemente colocado em check
> quanto a segurança, é a unica consideração que tenho negativa quanto ao
> proposto, porém é desenvolvido e mantido pela fundação Apache que são
> muito competentes no quesito segurança, posso estar falando m*
> devido a minha ignorância quanto a este software em especifico.
>
> Quanto ao FreeBSD mesmo, não há nenhuma critica negativa só positiva,
> porém só opte pelo mesmo caso possua expertice, o FreeBSD faz a parte
> dele que é disponibilizar um software seguro, estável e perfomatico com
> diversos recursos em cada um desses pilares, porém de nada adianta ter
> um bugati nas mãos e não passar dos 100Km/h em uma pista que permite
> chegar a 800Km/h.
> Ative os recursos do Framework MAC mantidos pelo TrustedBSD Project.
> Ative a auditoria do sistema e coloca um servidor de Logs aparte para
> manter um acompanhamento pro-ativo dos serviços
> Compile o kernel removendo coisas desnecessárias, sei que muitos
> administradores hoje já não compilam mais o kernel do FreeBSD em busca
> de perfomance  ou o fazem somente quando o recursos só estará disponivel
> on-kerrnel, contudo sou da premissa de que quanto menor a quantidade de
> codigo na memoria menor a possibilidade de algum exploit funcionar.
> Ajuste as sysctls relacionadas a desempenho de rede e do próprio sistema.
> Amplie os mbuffers de requisição da rede, ajuda muito na performance do
> sistema, principalmente quando este estiver com alto load.
> Ative o securelevel 3 caso a aplicação permita ou se possivel coloca o
> tomcat em uma Jail e mantenha um cluster Ativo/Ativo entre as jails e
> dois servidores fisicos e terá uma redundância que precisará de muito
> esforço da lei de murphe  para derrubar.
> Como o seu objetivo é segurança e caso possa expertice aceitável no que
> tange a segurança da informação demais softwares abaixo tem algumas
> dicas que valem a pena explorar.
>
> Instale e configure o IDS/IPS Suricata a parte da sua infraestrutura de
> serviços.
> Separe o banco de dados do servidor de aplicações e valide tudo o que
> acessar ele, revise o código da aplicação e tente forçar os
> desenvolvedores a terem práticas realmente seguras de codificação e
> comunicação entre a aplicação e o banco de dados.
> Ative o firewall em todos os seus servidores contudo com metodologias
> diferentes, no firewall de borda deixa passar com filtragem stateless
> apenas requisições para o servidor de aplicações contudo limitado a
> porta do socket de comunicação e no firewall do servidor de aplicações
> trabalhe com firewall statefull.
> Há muitas outras técnicas de harderning disponiveis para o FreeBSD e
> ambientes de Web Services, há muita literatura na Internet.
>
> Qualquer coisa estamos ai.
>
> Abraços e por favor seria muito bom depois disponibilizar um case da
> solução para que outros tenha um ponto de partida.
>
>
>
> --
> ##
> :UNI> Paulo Henrique
> Cel: (21) 98253-9727
> Fone: (21) 3708-9388
> ##
>
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: 

Re: [FUG-BR] Infra Web Services

[Paulo Henrique - BSD Brasil]

On 20/05/16 15:40, Wilson Mendes wrote:
> Prezado Ricardo,  a fug têm uma enciclopédia de informação sobre o
> assunto, assim como un excelente índice. Pesquise e a sua possível
> dúvida ainda existir, será de grande colaboração para essa
> enciclopédia viva.
>
> Abs
>
> Sent with AquaMail for Android
> http://www.aqua-mail.com
>
>
> On May 20, 2016 10:56:42 AM Ricardo Ferreira
>  wrote:
>
>> Senhores,
>>
>>
>> Tenho que implementar uma infra para suporte a Web Services e claro que
>> quero fazer em FreeBSD. Tenho algumas idéias como Apache mais Tomcat por
>> exemplo, dentre outras... mas gostaria de ouvir dos companheiros
>> sugestões, experiências, soluções de segurança, críticas dentre outros
>> detalhes a fim de alimentar o processo decisórioUm detalhe
>> importante é que segurança se impõe sobre todos os outros aspectos.
>>
>> []s
>>
>>
>> Ricardo Ferreira
>>
>>
>> -
>> 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
Cuidado com Top-posting, acaba estragando o histórico da lista.

Bom vamos lá.

Primeiro, que bom que considerando o FreeBSD como sistema operacional
base para a sua solução, contudo tem que ser realista.

Não acompanho o projeto tomcat para saber como está ele com relação as
outras plataformas ( Linux/Windows ), contudo se o foco é segurança
creio que usar uma tecnologia Java já é um tiro no pé que irá levar pelo
menos uma perna, o java vem sendo constantemente colocado em check
quanto a segurança, é a unica consideração que tenho negativa quanto ao
proposto, porém é desenvolvido e mantido pela fundação Apache que são
muito competentes no quesito segurança, posso estar falando m*
devido a minha ignorância quanto a este software em especifico.

Quanto ao FreeBSD mesmo, não há nenhuma critica negativa só positiva,
porém só opte pelo mesmo caso possua expertice, o FreeBSD faz a parte
dele que é disponibilizar um software seguro, estável e perfomatico com
diversos recursos em cada um desses pilares, porém de nada adianta ter
um bugati nas mãos e não passar dos 100Km/h em uma pista que permite
chegar a 800Km/h.
Ative os recursos do Framework MAC mantidos pelo TrustedBSD Project.
Ative a auditoria do sistema e coloca um servidor de Logs aparte para
manter um acompanhamento pro-ativo dos serviços
Compile o kernel removendo coisas desnecessárias, sei que muitos
administradores hoje já não compilam mais o kernel do FreeBSD em busca
de perfomance  ou o fazem somente quando o recursos só estará disponivel
on-kerrnel, contudo sou da premissa de que quanto menor a quantidade de
codigo na memoria menor a possibilidade de algum exploit funcionar.
Ajuste as sysctls relacionadas a desempenho de rede e do próprio sistema.
Amplie os mbuffers de requisição da rede, ajuda muito na performance do
sistema, principalmente quando este estiver com alto load.
Ative o securelevel 3 caso a aplicação permita ou se possivel coloca o
tomcat em uma Jail e mantenha um cluster Ativo/Ativo entre as jails e
dois servidores fisicos e terá uma redundância que precisará de muito
esforço da lei de murphe  para derrubar.
Como o seu objetivo é segurança e caso possa expertice aceitável no que
tange a segurança da informação demais softwares abaixo tem algumas
dicas que valem a pena explorar.

Instale e configure o IDS/IPS Suricata a parte da sua infraestrutura de
serviços.
Separe o banco de dados do servidor de aplicações e valide tudo o que
acessar ele, revise o código da aplicação e tente forçar os
desenvolvedores a terem práticas realmente seguras de codificação e
comunicação entre a aplicação e o banco de dados.
Ative o firewall em todos os seus servidores contudo com metodologias
diferentes, no firewall de borda deixa passar com filtragem stateless
apenas requisições para o servidor de aplicações contudo limitado a
porta do socket de comunicação e no firewall do servidor de aplicações
trabalhe com firewall statefull.
Há muitas outras técnicas de harderning disponiveis para o FreeBSD e
ambientes de Web Services, há muita literatura na Internet.

Qualquer coisa estamos ai.

Abraços e por favor seria muito bom depois disponibilizar um case da
solução para que outros tenha um ponto de partida.



-- 
##
:UNI>http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Infra Web Services

[Wilson Mendes]

Prezado Ricardo,  a fug têm uma enciclopédia de informação sobre o assunto, 
assim como un excelente índice. Pesquise e a sua possível dúvida ainda 
existir, será de grande colaboração para essa enciclopédia viva.


Abs

Sent with AquaMail for Android
http://www.aqua-mail.com


On May 20, 2016 10:56:42 AM Ricardo Ferreira 
 wrote:



Senhores,


Tenho que implementar uma infra para suporte a Web Services e claro que
quero fazer em FreeBSD. Tenho algumas idéias como Apache mais Tomcat por
exemplo, dentre outras... mas gostaria de ouvir dos companheiros
sugestões, experiências, soluções de segurança, críticas dentre outros
detalhes a fim de alimentar o processo decisórioUm detalhe
importante é que segurança se impõe sobre todos os outros aspectos.

[]s


Ricardo Ferreira


-
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