Re: [FUG-BR] MIPS64 500MHZ no FreeBSD e Pfsense 2.2
E ai galera.. com o lançamento da versão 2.2 será que roda o pfsense numa Edge Router ? Em 11 de dezembro de 2014 08:07, Fabricio Lima escreveu: > Gustavo, > > CDN quer dizer Content Distribution Network > > seria empresas tipo Akamai e Amazon S3 q permitem q as empresas tenham > conteudo globalmente espalhados. > > Vc faz um download do service pack do windows 8 a partir de sp, sem > precisar q o trafego va ate a microsoft nos eua por exemplo. > o mesmo acontece pro povo la na india, etc.. > > Ou seja, o cara faz uma vpn e o trafego dele sai pelo EUA direto, burlando > restriçoes de netflix q bloqueiam brasil. > > [ ]'s > Fabricio Lima > When your hammer is C++, everything begins to look like a thumb. > > Em 11 de dezembro de 2014 08:46, Gustavo Freitas > escreveu: > >> Renato, >> >> "tenho uma caixa aqui em casa fazendo uns IPSEC prá burlar os CDN >> congestionados" >> >> que caixa vc diz ? e o que seria CDN.. >> - >> 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 -- Gustavo Freitas - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] Zine sobre BSD em geral
Boa noite pessoal ! Eu to começando um novo projeto para a comunidade hoje e quero divulgar para os amigos, trata-se de um portal, no formato de blog (ou magazine) com noticias e artigos. A ideia é voltar a publicar minhas publicações e experiencias no mundo Unix em Geral, como eu já vinha fazendo algum tempo com meu blog pessoal ( www.luizgustavo.pro.br). Eu dessa vez estou querendo tirar o termo "pessoal" e deixar a coisa mais atrelada a Mundounix. Então, espero a apreciação de vocês. Segue endereço e primeiro post :) http://zine.mundounix.com.br/ http://zine.mundounix.com.br/2015/01/25/pfsense-2-2-lancado/ Abraços -- Luiz Gustavo Costa (Powered by BSD) *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ ICQ: 2890831 / Gtalk: gustavo@gmail.com Blog: http://www.luizgustavo.pro.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] Opinião sobre proxy transparente
On 25/01/2015 17:53, Renato Frederick wrote: Patrick Tracanelli escreveu: Sobre a estrategia de "seguranca" defendida, convenhamos, é enrolar o rabo e sentar em cima pra tentar esconder. Colocar um gateway falso pra evitar proliferacao de vírus ehahuauha em primeiro lugar não deveria haver vírus, em segundo lugar se tem, não deveria assumir uma posicão que o virus vai ficar la tentando se propagar, ele sera eliminado ASAP. Faz favor. Outro ponto nada a ve, e que nada impede a adocao de um DNS a parte. Mas de novo, ter um "dns pros virus" e deixar o proxy ser o unico a usar o DNS autentico me parece de novo o caminho totalmente oposto da seguranca. Olá Patrick! Muito boa, como sempre, sua explicação sobre os outros pontos. Interessante saber que as ameaças sabem mais como usar a pilha tcp/ip do Windows do que programas lícitos. Eu mesmo já tive problema com alguns programas Windows que usavam JAVA, porque não pegavam a conf. do navegador, tinha que sair máquina e máquina e colocar na mão :( Sobre o ponto acima, foi exatamente o ponto que mais discordei :-) Acho que é, como alguém falou nos comentários deste site que li, "inventar uma solução complicada para algo simples"! Eu costumo trabalhar do jeito que você comentou, se há como interferir no equipamento final(Um AD, com GPO, empresa), faço uma GPO com ativação de proxy para tudo e um belo "deny from $rede_interna to any", liberando eventualmente alguma porta específica. Costumo fazer a regra de nat permitindo any to any, mas tem gente que faz 1 regra de nat para cada porta. Não gosto disto porque no firewall de borda(considerando que atrás dele tenha um proxy/nat) vai ficar no log ips internos que tentaram fazer o roteamento sem passar pelo NAT. Porém, tem empresa que é mais permissiva, ou tem colaboradores que usam a internet eficientemente, estas normalmente fecho portas bem conhecidas como 135-139, etc, etc e o gestor fica monitorando, quem eventualmente comete abuso leva puxão de orelha. Agora, quando é um hotspot, ou um ISP, é proxy transparente com squid ou interceptação de todo tráfego e jogando para um equipamento de cache. A ideia de sempre usar proxy transparente sempre aparece em meus diagramas, já tenho até o esboço salvo como padrão, 2 links internet -> cluster pfsense com carp -> servidor proxy transparente -> rede interna ;) Obrigado pela sua atenção, mais conteúdo prá enriquecer a lista! Saudações a todos, Como sempre excelentes abordagens. Os argumentos apresentados pelo material com relação a segurança está mais para administrador de rede preguiçoso, sou adepto a proxy transparente, não pela facilidade de administrar a rede mais pela ineficiência de um usuário conseguir burlar os controles implantados na infraestrutura. Em resumo mantenho todas as portas bloqueadas e libero acesso a porta/servidor especifico caso seja necessário com exceção de interceptar o stream daquela conexão ( tipo Conexão Segura da Caixa econômica ) e encaminha-lo para a proxy. Dá um trabalho maior e não é difícil chegar a 600 ou 800 regras no firewall com exceções, contudo o trafego que entra ou sai da rede é totalmente confiável. E estação de trabalho com virus/worms é irresponsabilidade do administrador por deixar que uma estação seja infectada, restringe os privilégios dos usuários, coloca recursos de gerenciamento centralizados onde o controle do antivírus não seja manipulado pelo usuário, proíbe a utilização de discos removíveis e acesso a sites apenas no que diz questão ao trabalho do colaborador, só com essas medidas cairá em 99% a possibilidade de se ter uma estação infectada. E outra coisa que coloco na rede é segmentar a rede por departamentos e o trafego entre eles serem inspecionado pelo IDS, tive só alguns problemas com protocolos de impressão que parecem não funcionar muito bem quando se tem um IDS no meio. Att. -- Paulo Henrique. Grupo de Usuários de Sistemas BSDs no Brasil. Fone: +55 21 96713-5042 Não importa o que faça, sempre haverá alguém em algum lugar do mundo que será sempre melhor do que você. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] OpenBGP allowas-in
eks...@freebsdbrasil.com.br escreveu: Botei a feature no OpenBGP. O patch[1] funciona OK no OpenBSD tambem, alem do FreeBSD claro (e ate aplicou na versão do Linux mas como n uso, só vi que aplicou clean...). Se alguem preferir usar direto no ports ao invés de aplicar o patch na mão o diff está pronto[2] pra enviar um PR pro ports também, mas vou enviar depois de 1 semana de testes. Todo teste é bem-vindo. Testado e funcionando. BSD 8. Sessão com o PTT. Fui em outro provedor que também tem sessão lá e brinquei de zonear os preprends e o allowas-in foi respeitado. Vamo ver agora se algumas pessoas da GTER evolui na vida e com este patch + o TCP, para de usar quagga em UBUNTU. []s - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Opinião sobre proxy transparente
Patrick Tracanelli escreveu: Sobre a estrategia de "seguranca" defendida, convenhamos, é enrolar o rabo e sentar em cima pra tentar esconder. Colocar um gateway falso pra evitar proliferacao de vírus ehahuauha em primeiro lugar não deveria haver vírus, em segundo lugar se tem, não deveria assumir uma posicão que o virus vai ficar la tentando se propagar, ele sera eliminado ASAP. Faz favor. Outro ponto nada a ve, e que nada impede a adocao de um DNS a parte. Mas de novo, ter um "dns pros virus" e deixar o proxy ser o unico a usar o DNS autentico me parece de novo o caminho totalmente oposto da seguranca. Olá Patrick! Muito boa, como sempre, sua explicação sobre os outros pontos. Interessante saber que as ameaças sabem mais como usar a pilha tcp/ip do Windows do que programas lícitos. Eu mesmo já tive problema com alguns programas Windows que usavam JAVA, porque não pegavam a conf. do navegador, tinha que sair máquina e máquina e colocar na mão :( Sobre o ponto acima, foi exatamente o ponto que mais discordei :-) Acho que é, como alguém falou nos comentários deste site que li, "inventar uma solução complicada para algo simples"! Eu costumo trabalhar do jeito que você comentou, se há como interferir no equipamento final(Um AD, com GPO, empresa), faço uma GPO com ativação de proxy para tudo e um belo "deny from $rede_interna to any", liberando eventualmente alguma porta específica. Costumo fazer a regra de nat permitindo any to any, mas tem gente que faz 1 regra de nat para cada porta. Não gosto disto porque no firewall de borda(considerando que atrás dele tenha um proxy/nat) vai ficar no log ips internos que tentaram fazer o roteamento sem passar pelo NAT. Porém, tem empresa que é mais permissiva, ou tem colaboradores que usam a internet eficientemente, estas normalmente fecho portas bem conhecidas como 135-139, etc, etc e o gestor fica monitorando, quem eventualmente comete abuso leva puxão de orelha. Agora, quando é um hotspot, ou um ISP, é proxy transparente com squid ou interceptação de todo tráfego e jogando para um equipamento de cache. A ideia de sempre usar proxy transparente sempre aparece em meus diagramas, já tenho até o esboço salvo como padrão, 2 links internet -> cluster pfsense com carp -> servidor proxy transparente -> rede interna ;) Obrigado pela sua atenção, mais conteúdo prá enriquecer a lista! - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] OpenBGP allowas-in
On 01/24/15 19:24, ae moura wrote:
Uau! patrick!Funcionou direitinho.
Opa, que bom que funcionou ai tambem.
Quase perfeito exceto que tive que reiniciar o servico, veja abaixo.
Bora ver isso...
Segundo patch seu que funciona muito bem no OpenBGP tomara que coloque logo no
ports.
Daqui uma semana a mais em producao eu mando o PR. Se vai entrar ja n
sei ;-)
Não entendi porém seu comentário no patch:
" Cisco, Juniper and other BGP routing daemons do offer the samefeature, sometimes
with explicit control of how many times the ASnumber is accepted in the as-path. It does
not help, the wrong setupwill loop anyway, therefore we just allow it any number of
times."
Qual é a diferenca na implementacao?
Cisco, Juniper, Mikrotik, e varios outros engines BGP permitem algo do tipo
allowas-in 3
Isso quer dizer que é permitido até 3 vezes o seu AS no AS-Path da rota
recebida, mas não será permitido 4 vezes seu AS-path la.
Ou seja na pratica não importa se é 1 ou 10 vezes, a possibilidade de
loop é exatamente a mesma, então liberar e impor um limite é meio aquele
negocio... voce permite que seu filho vai pra balada mas impoe um
limite: nao chegar depois das 3 da manha. Convenhamos o que quer q vc
tenha medo que ele faca de errado... ele podera fazer até as 3 da manha
hehehe ou vc confia ou não confia.
Na pratica ainda piora pq vc tem que pensar "quantos prepend do meu
proprio AS eu ja fiz? quantos desses anuncios prependados podem chegar
por esse peer?" e ai vc vai concluir que precisaria liberar:
allowas-in = (seu_numero_de_prepend_anunciado+1)
Ou seja... filhao vai pra balada mas nao volte depois de
(horas_do_fervo_da_balada+1).
Por isso eu preferi uma abordagem do tipo ou voce confia e libera, ou
nao libera. O risco de loop é o mesmo, independente se voce da 1 metro
ou 1 km de corda pro cidadao se enforcar.
Alem disso voce viu a simplicidade do patch? Mudancas de 1 ou 2 linhas
em locais chaves da estrutura. Eu nao quero ter que ir no rde.c e ficar
contando e comparando com o limite configurado. Quanto maior o patch
mais dificil de manter e de ser aceito no ports alem de maior
probabilidade de conflitar com outros.
Outra coisa coloquei allowas-in no peer e dei reload, nao funcionou. Mas quando
reiniciei o openbgpd funcionou, era isso mesmo esperado?
Não, você não tinha que reiniciar o servico ;-)
O "allowas-in" é definido no fechamento da sessão. Não está implementado
em softreconfig pq não faz muito sentido essa mudanca ser dinamica,
entao na pior das hipoteses... voce poderia ter dado um clear no peer,
pra forcar imediatamente a renegociacao. Algo menos radical seria
aguardar renegociacao de capabilities, que acontece no inicio da sessao
ou periodicamente, ou ainda se solicitado entre as pontas. Isso pq o
controle de loop do OpenBGP ja é reprocessado no capabilities change...
ou seja voce poderia esperar, forcar renegociacao mudando alguma
capability anunciada... ou na pior das hipoteses dar clear na sessao mas
reiniciar o processo nao precisava nao ;-)
Abracos e sigamos.
From: eks...@freebsdbrasil.com.br
To: freebsd@fug.com.br
Date: Sat, 24 Jan 2015 02:47:00 -0200
Subject: [FUG-BR] OpenBGP allowas-in
Botei a feature no OpenBGP. O patch[1] funciona OK no OpenBSD tambem,
alem do FreeBSD claro (e ate aplicou na versão do Linux mas como n
uso, só vi que aplicou clean...). Se alguem preferir usar direto no
ports ao invés de aplicar o patch na mão o diff está pronto[2] pra
enviar um PR pro ports também, mas vou enviar depois de 1 semana de
testes.
Todo teste é bem-vindo.
[1]http://main.bh.freebsdbrasil.com.br/~eksffa/l/local-patch-openbgpd-allowas-in.c>
[2]http://main.bh.freebsdbrasil.com.br/~eksffa/l/ports_net_openbgpd-allowas-in.diff
Allow the AS path of a received route to contain the recipient BGP
speaker's AS number any number of times, avoiding Route Decision
Engine loop prevention for this peer. This is a feature that should
rarely be needed. Usually the need for this feature suggests something
wrong on the current BGP setup. However in some particular setups it's
just needed, and can be used without breaking BGP or adding loops.
Cisco, Juniper and other BGP routing daemons do offer the same
feature, sometimes with explicit control of how many times the AS
number is accepted in the as-path. It does not help, the wrong setup
will loop anyway, therefore we just allow it any number of times. On
bgpd.conf(5), use it on a per neighbor/group basis: group "my_peers" {
allowas-in (...) neighbor $a_peer { (...) allowas-in } } Shamely, I
didn't patch bgpd.conf(5), therefore it's more than welcome. --
Patrick Tracanelli
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
--
Patrick Tracanelli
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fu
Re: [FUG-BR] Opinião sobre proxy transparente
On 01/25/15 04:23, Renato Frederick wrote: Pessoal Olha aí, http://lucianopinheiro.net/portal/node/129 O que vocês acham? Eu nunca parei para pensar se o proxy transparente é ou não a melhor opção, sempre faço meus projetos tendo em mente um proxy transparente. Também achei bem estranho a afirmação abaixo: [] "Quanto à segurança, parece-me que o melhor mesmo é usar proxy não transparente, principalmente por causa dos vírus, trojans e toda a fauna de processos mal intencionados no sistema operacional. No Windows, isso é vital. Coloca-se um gateway e servidores DNS falsos e processa-se apenas o que vier através do navegador. Sugiro utilizar uma máquina válida preparada para receber os pacotes não autorizados, de modo que identifique-se, via tcpdump, a origem e intenção destes pacotes." [] Eu não concordo plenamente nem discordo. Proxy foi criado pra não ser transparente. Diversos recursos, incluindo autenticacão não funcionam de forma transparente plenamente ou sem grandes ajustes (aka, gambiarra ou novas tecnicas) que vieram depois. O proprio proxy transparente veio depois. A auto-configuracao de proxy seja manual seja por auto-discovery ajuda na adocao de proxy não transparente, que já diminuiria uma das primeiras vantagens do proxy transparente, que é a ausencia ou não necessidade de configurar nada. Outra vantagem do proxy não transparente é que uma vez configurado proxy no sistema, outras aplicacões que simplesmente não funcionariam em um proxy transparente, ou não usam portas default ainda que usem protocolos default, vão usar o servidor proxy sem ter sido interceptados por um firewall em algum momento. Por exemplo, Dropbox desktop ou a solucao de conferencia da Cisco nao funcionarão em modo transparente, mas vão funcionar com proxy automatico na maquina ou proxy manual. As vantagens pra mim, param por ai. Isso no entanto so e possivel em ambientes corporativos, uma empresa, orgao de governo, etc. Em um provedor ou uma rede publica de outro tipo onde nao existe a possibilidade de intervencao no navegador do usuario ou nao existe garantia que a auto-configuracao possa ser viavel (o cara pode ter firewall, etc), nao tem escolha e a interceptacao transparente se faz necessaria. A respeito de filtros, nao ha diferenca, nao ha desvantagem no transparente, tudo se filtra da mesma forma. A respeito da autenticacao nao funciona por padrão mas ja existem alternativas funcionais para navegadores modernos - nao vai funcionar no seu firefox2 no IE6 ou no Lynx/netscape hehehe como funciona autenticacao em um proxy manual, mas se vc usa qualquer coisa de 2 anos pra ca, as alternativas pra auth transparente ja funcionarao... Sobre a estrategia de "seguranca" defendida, convenhamos, é enrolar o rabo e sentar em cima pra tentar esconder. Colocar um gateway falso pra evitar proliferacao de vírus ehahuauha em primeiro lugar não deveria haver vírus, em segundo lugar se tem, não deveria assumir uma posicão que o virus vai ficar la tentando se propagar, ele sera eliminado ASAP. Faz favor. Outro ponto nada a ve, e que nada impede a adocao de um DNS a parte. Mas de novo, ter um "dns pros virus" e deixar o proxy ser o unico a usar o DNS autentico me parece de novo o caminho totalmente oposto da seguranca. Se o gateway ou o switch ja no perimetro descartam os pacotes que não destinados a interceptacao web pra desvio pro proxy, ja é mais eficiente, especialmente porque o drop de um filtro será silencioso enquanto um "gateway falso" vai ficar retornando TCP RST, ou icmp unreach host loucamente, prejudicando a rede ao inves de trazer qualquer tipo de vantagem psicologica. Entao filtro proximo a estacao, ou filtro silencioso (default) no firewall, além de mais eficiente dão mais controle ja que tem logs, monitoracao... ninguem quer simplesmente uma maquina tomando pancada de virus e sem controle sobre o que esta acontecendo. Isso sem mencionar que a maior parte dos virus/worms hoje ja consultam se ha um proxy configurado para usa-lo. Primeiro pq isso é facil de ser implementado especialmente em Windows, API uniforme e de facil acesso. Segundo que esta nas melhores praticas. Sim quem faz virus compartilha de suas melhores praticas e buscar proxy, conf dinamica de proxy, DNS estatico está entre elas. Incrivelmente tem virus/worms que implementam melhores praticas ainda mais eficientes que aplicativos profissionais, de home banking por exemplo. Sem exageros, essa semana me deparei com um backdoor escrito em PERL na maquina comprometida por injection de um cliente cujo codigo em execucão fazia Public Cert Pinning Convenhamos 90% dos apps de home banking no Brasil NAO FAZEM Public Cert Pinning... nem pub key. Esse backdoor se preocupa mais com a seguranca pra falar com seu Control Node do que o Banco do Brasil se preocupa pro Mobile Banking falar com webservice do BB. Ou seja achar que um virus hoje nao va acessar uma API de uma unica cham
