[FUG-BR] (OT) Os 10 piores Sistemas Operacionais de todos os tempos
colunista Steven J. Vaughan-Nichols, divulgou no site pcworld.com uma lista referenciando os 10 piores sistemas operacionais de todos os tempos. No minimo interessante, pois eu nem conhecia alguns dele, mas completamente aberta a discussões. 1. OS/360, 1964 2. ITS (Incompatible Timesharing System), late 1960s 3. GNU Hurd, launched in 1983 (still incomplete) 4. Windows 1.01, 1985 5. MS-DOS 4.0, 1988 6. SCO Open Desktop, 1989 7. JavaOS, 1996 8. Windows Me (Millennium Edition), 2000 9. Lindows/ Linux XP Desktop, 2001/2006 10. Windows Vista, 2006 Link: http://www.infoblogs.com.br/view.action?contentId=171989Os-10-piores-Sistemas-Operacionais-de-todos-os-tempos.html -- Alessandro de Souza Rocha Administrador de Redes e Sistemas FreeBSD-BR User #117 Long live FreeBSD Powered by (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] IPFW, protocolos obscuros, protocolos criptografados etc.
Prezados, Exponho um cenário anômalo, e serei grato pela opinião de vocês. Atendo um condomínio residencial que fornece internet gratuitamente aos moradores. Cada morador, ao assinar o contrato com o condomínio, opta por informar o endereço físico (MAC) do computador, caso queira internet. As concessões, negações e limitações dos recursos de rede são gerenciadas por um servidor FreeBSD 6.4 (Stable), atuando como proxy transparente (Squid), roteador e controle e banda (IPFW). Tudo funcionava perfeitamente, principalmente na questão de controle de banda. Porém, conforme descreve Okamoto e seus colegas[1], há bibliotecas de aplicações P2P mais eficazes em TCP do que UDP (inclusive 7x mais rápidas!). Os desenvolvedores de aplicações P2P perceberam isso e, aos poucos, estão abandonando o UDP, principalmente, devido ao fato de muitos administratores fecharem todas as portas UDP, exceto 53,67,68 e 123. Somado a isso, o eMule[2], há algum tempo, dispõe de um recurso chamado Obfuscation Protocol[3], que não era habilitado por padrão, ficando a critério do usuário habilitá-lo. Para completar o estrago, agora essa opção é padrão, e o BitTorrent[4] também entrou na onda da obfuscação[5]. Aqui começa a anomalia: Neste condomínio tem um morador com 256/128kbps de banda (download e upload, respectivamente). Para todas as aplicações que ele usa, o controle de banda é obedecido perfeitamente, exceto para eMule[2] e BitTorrent[4], aplicações que transferem dados em taxas quase 10 vezes maiores. O controle de banda está declarado/numerado no começo das regras, com one_pass desabilitado, tendo abaixo o desvio (fwd) do proxy transparente, desvio (skipto) do PrivateWire (Conectividade Social), divert de entrada, regras statefull e divert de saída. Sendo assim, agradeço novamente a opinião de vocês sobre quais as regras mais adequada para controlar essas aplicações e seus protocolos obscuros. [1] http://www2.lifl.fr/MAP/negst/secondWorkshop/slidesSecondWorkshopNegst/TakayukiOkamoto.ppt [2] http://www.emule-project.net [3] http://wiki.emule-web.de/index.php/Protocol_obfuscation [4] http://www.bittorrent.com [5] http://torrentfreak.com/how-to-encrypt-bittorrent-traffic/ Grande abraço a todos, Trober - - - - - - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] IPFW, protocolos obscuros, protocolos criptografados etc.
www.hostcert.com.br Esse sistema faz o controle de trafego diferente, não utiliza ipfw. Ele segura 100% esses casos. 2009/4/18 Trober tro...@trober.com Prezados, Exponho um cenário anômalo, e serei grato pela opinião de vocês. Atendo um condomínio residencial que fornece internet gratuitamente aos moradores. Cada morador, ao assinar o contrato com o condomínio, opta por informar o endereço físico (MAC) do computador, caso queira internet. As concessões, negações e limitações dos recursos de rede são gerenciadas por um servidor FreeBSD 6.4 (Stable), atuando como proxy transparente (Squid), roteador e controle e banda (IPFW). Tudo funcionava perfeitamente, principalmente na questão de controle de banda. Porém, conforme descreve Okamoto e seus colegas[1], há bibliotecas de aplicações P2P mais eficazes em TCP do que UDP (inclusive 7x mais rápidas!). Os desenvolvedores de aplicações P2P perceberam isso e, aos poucos, estão abandonando o UDP, principalmente, devido ao fato de muitos administratores fecharem todas as portas UDP, exceto 53,67,68 e 123. Somado a isso, o eMule[2], há algum tempo, dispõe de um recurso chamado Obfuscation Protocol[3], que não era habilitado por padrão, ficando a critério do usuário habilitá-lo. Para completar o estrago, agora essa opção é padrão, e o BitTorrent[4] também entrou na onda da obfuscação[5]. Aqui começa a anomalia: Neste condomínio tem um morador com 256/128kbps de banda (download e upload, respectivamente). Para todas as aplicações que ele usa, o controle de banda é obedecido perfeitamente, exceto para eMule[2] e BitTorrent[4], aplicações que transferem dados em taxas quase 10 vezes maiores. O controle de banda está declarado/numerado no começo das regras, com one_pass desabilitado, tendo abaixo o desvio (fwd) do proxy transparente, desvio (skipto) do PrivateWire (Conectividade Social), divert de entrada, regras statefull e divert de saída. Sendo assim, agradeço novamente a opinião de vocês sobre quais as regras mais adequada para controlar essas aplicações e seus protocolos obscuros. [1] http://www2.lifl.fr/MAP/negst/secondWorkshop/slidesSecondWorkshopNegst/TakayukiOkamoto.ppt [2] http://www.emule-project.net [3] http://wiki.emule-web.de/index.php/Protocol_obfuscation [4] http://www.bittorrent.com [5] http://torrentfreak.com/how-to-encrypt-bittorrent-traffic/ Grande abraço a todos, Trober - - - - - - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Lauro Cesar de Oliveira http://www.gurulinux.blog.br Hack to learn not learn to hack. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] Alias para a interface lo0
Senhores, Estou com uma situação estranha no meu FreeBSD (7.1-STABLE, amd64), eu coloquei um alias para a interface lo0 no rc.conf (ifconfig_lo0_alias=inet 189.xxx.xxx.xxx netmask 255.255.255.0), porem, ele só é aplicado quando eu executo o comando ifconfig ($ ifconfig lo0 alias inet 189.xxx.xxx.xxx netmask 255.255.255.0), quando a máquina inicia ele não é aplicado. Já verifiquei nos logs do boot, dmesg, messsages, etc, e não acho indícios do porque isso está acontecendo. Alguém pode me ajudar? um abraço, -- Otávio Fernandes otaviof at gmail.com http://otaviof.blogspot.com/ - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] IPFW, protocolos obscuros, protocolos criptografados etc.
Olá Lauro :) Grato pelo retorno. Muito boa sua sugestão, mas, por enquanto, o objetivo é manter o FreeBSD, adotando uma solução não-comercial. Caso o IPFW se mostre incapaz de cumprir o propósito de controlar banda de protocolos obscuros e criptografados, partirei para algo comercial. Novamente agradeço sua sugestão. Grande abraço, Trober - - - - www.hostcert.com.br Esse sistema faz o controle de trafego diferente, não utiliza ipfw. Ele segura 100% esses casos. 2009/4/18 Trober tro...@trober.com Prezados, Exponho um cenário anômalo, e serei grato pela opinião de vocês. Atendo um condomínio residencial que fornece internet gratuitamente aos moradores. Cada morador, ao assinar o contrato com o condomínio, opta por informar o endereço físico (MAC) do computador, caso queira internet. As concessões, negações e limitações dos recursos de rede são gerenciadas por um servidor FreeBSD 6.4 (Stable), atuando como proxy transparente (Squid), roteador e controle e banda (IPFW). Tudo funcionava perfeitamente, principalmente na questão de controle de banda. Porém, conforme descreve Okamoto e seus colegas[1], há bibliotecas de aplicações P2P mais eficazes em TCP do que UDP (inclusive 7x mais rápidas!). Os desenvolvedores de aplicações P2P perceberam isso e, aos poucos, estão abandonando o UDP, principalmente, devido ao fato de muitos administratores fecharem todas as portas UDP, exceto 53,67,68 e 123. Somado a isso, o eMule[2], há algum tempo, dispõe de um recurso chamado Obfuscation Protocol[3], que não era habilitado por padrão, ficando a critério do usuário habilitá-lo. Para completar o estrago, agora essa opção é padrão, e o BitTorrent[4] também entrou na onda da obfuscação[5]. Aqui começa a anomalia: Neste condomínio tem um morador com 256/128kbps de banda (download e upload, respectivamente). Para todas as aplicações que ele usa, o controle de banda é obedecido perfeitamente, exceto para eMule[2] e BitTorrent[4], aplicações que transferem dados em taxas quase 10 vezes maiores. O controle de banda está declarado/numerado no começo das regras, com one_pass desabilitado, tendo abaixo o desvio (fwd) do proxy transparente, desvio (skipto) do PrivateWire (Conectividade Social), divert de entrada, regras statefull e divert de saída. Sendo assim, agradeço novamente a opinião de vocês sobre quais as regras mais adequada para controlar essas aplicações e seus protocolos obscuros. [1] http://www2.lifl.fr/MAP/negst/secondWorkshop/slidesSecondWorkshopNegst/TakayukiOkamoto.ppt [2] http://www.emule-project.net [3] http://wiki.emule-web.de/index.php/Protocol_obfuscation [4] http://www.bittorrent.com [5] http://torrentfreak.com/how-to-encrypt-bittorrent-traffic/ Grande abraço a todos, Trober - - - - - - -- Lauro Cesar de Oliveira http://www.gurulinux.blog.br Hack to learn not learn to hack. - - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Problemas com regras PF+altq
use o queue nas em todas as interfaces pois o controle diferente do ipfw so
é feito no upload da interface isso ja foi muito divulgado aqui na lista
2009/4/17 joao jamaicabsd jamaica...@gmail.com
Bom dia Pessoal.
Estou com problema nas regras do PF+Altq. Não estou conseguinto fazer o
controle de banda funcionar.
| Empresa 1 (rl0)
Internet(1MB)---Freebsd 7.0 (Bridge)
| Empresa 2 (rl1)
Regras do PF:
MACROS
ext_if=sis0
lenke=rl0
wmw=rl1
CONTROLE DE TRAFEGO PARA A INTERFACE ext_if
altq on $ext_if cbq bandwidth 1Mb qlimit 150 \
queue {lenke,wmw,http}
queue lenke bandwidth 50% priority 3 qlimit 150 cbq(default red)
queue wmw bandwidth 50% priority 1 qlimit 150 cbq(red)
pass in quick on rl0 from yyy.yyy.yyy.130 to any tag EMPRESA1 queue
empresa1
pass out quick on sis0 tagged EMPRESA1 queue empresa1
pass in quick on sis0 from any to yyy.yyy..130 tag EMPRESA1 queue empresa1
pass out quick on rl0 tagged EMPRESA1 queue empresa1
pass in quick on rl1 from xxx.xxx.xxx.160 to any tag empresa2 queue
empresa2
pass out quick on sis0 tagged EMPRESA2 queue empresa2
pass in quick on sis0 from any to xxx.xxx.xxx.160 tag empresa2 queue
empresa2
pass out quick on rl1 tagged EMPRESA2 queue empresa2
Alguém pode me ajudar nessa questão de limitar o tráfego em 50% para cada
rede?
Obrigado a todos
--
E-mail: jamaica...@gmail.com
Aux Suporte de Sistemas (UNISUL)
E-mail: joao.may...@unisul.br
MSN: joaomayk...@hotmail.com
Cel: (48) 9144 2326
-
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
Re: [FUG-BR] Alias para a interface lo0
voce está querendo colocar esse alias no local para fazer bgp ? se for pode fazer direto na interface que se conecta no router nao precisa ser na lo isso é um costume que o pessoa tras do cisco 2009/4/18 Otávio Fernandes otavio_fernan...@yahoo.com.br Senhores, Estou com uma situação estranha no meu FreeBSD (7.1-STABLE, amd64), eu coloquei um alias para a interface lo0 no rc.conf (ifconfig_lo0_alias=inet 189.xxx.xxx.xxx netmask 255.255.255.0), porem, ele só é aplicado quando eu executo o comando ifconfig ($ ifconfig lo0 alias inet 189.xxx.xxx.xxx netmask 255.255.255.0), quando a máquina inicia ele não é aplicado. Já verifiquei nos logs do boot, dmesg, messsages, etc, e não acho indícios do porque isso está acontecendo. Alguém pode me ajudar? um abraço, -- Otávio Fernandes otaviof at gmail.com http://otaviof.blogspot.com/ - 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
[FUG-BR] RES: Alias para a interface lo0
Se for isto, para rodar bgp e estiver usando quagga, pode fazer direto nele: ! interface lo0 ip address 187.X.X.X/32 ! O daemon zebra do quagga vai transferir isto para a lo0 do freebsd: #ifconfig lo0 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 inet 187.X.X.X netmask 0x mas como o Renato falou, não precisa ser na lo0, pode ser em qualquer interface, isto é apenas para o bgp fazer um bind no IP. Abraços -Mensagem original- De: freebsd-boun...@fug.com.br [mailto:freebsd-boun...@fug.com.br] Em nome de renato martins Enviada em: sábado, 18 de abril de 2009 16:17 Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) Assunto: Re: [FUG-BR] Alias para a interface lo0 voce está querendo colocar esse alias no local para fazer bgp ? se for pode fazer direto na interface que se conecta no router nao precisa ser na lo isso é um costume que o pessoa tras do cisco 2009/4/18 Otávio Fernandes otavio_fernan...@yahoo.com.br Senhores, Estou com uma situação estranha no meu FreeBSD (7.1-STABLE, amd64), eu coloquei um alias para a interface lo0 no rc.conf (ifconfig_lo0_alias=inet 189.xxx.xxx.xxx netmask 255.255.255.0), porem, ele só é aplicado quando eu executo o comando ifconfig ($ ifconfig lo0 alias inet 189.xxx.xxx.xxx netmask 255.255.255.0), quando a máquina inicia ele não é aplicado. Já verifiquei nos logs do boot, dmesg, messsages, etc, e não acho indícios do porque isso está acontecendo. Alguém pode me ajudar? um abraço, -- Otávio Fernandes otaviof at gmail.com http://otaviof.blogspot.com/ - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] RES: IPFW, protocolos obscuros, protocolos criptografados etc.
Na regra IPFW você usa como? Eu uso assim: pipe 111 ip from 172.16.20.6 to any in pipe 112 ip from any to 172.16.20.7 out isto funciona indiferente de obfuscacao ou não, já que ele continua usar datagrama IP. :) a obfuscacao vai deixar de funcionar se você utilizar algo L7 para fazer shapping ou usar range de portas. Neste caso, tem que partir para solução comercial mesmo, snort e afins não estão a par do tipo de protocolo usado pela obfuscacao ainda. -Mensagem original- De: freebsd-boun...@fug.com.br [mailto:freebsd-boun...@fug.com.br] Em nome de Trober Enviada em: sábado, 18 de abril de 2009 14:55 Para: FUG-BR Assunto: Re: [FUG-BR] IPFW, protocolos obscuros, protocolos criptografados etc. Olá Lauro :) Grato pelo retorno. Muito boa sua sugestão, mas, por enquanto, o objetivo é manter o FreeBSD, adotando uma solução não-comercial. Caso o IPFW se mostre incapaz de cumprir o propósito de controlar banda de protocolos obscuros e criptografados, partirei para algo comercial. Novamente agradeço sua sugestão. Grande abraço, Trober - - - - www.hostcert.com.br Esse sistema faz o controle de trafego diferente, não utiliza ipfw. Ele segura 100% esses casos. 2009/4/18 Trober tro...@trober.com Prezados, Exponho um cenário anômalo, e serei grato pela opinião de vocês. Atendo um condomínio residencial que fornece internet gratuitamente aos moradores. Cada morador, ao assinar o contrato com o condomínio, opta por informar o endereço físico (MAC) do computador, caso queira internet. As concessões, negações e limitações dos recursos de rede são gerenciadas por um servidor FreeBSD 6.4 (Stable), atuando como proxy transparente (Squid), roteador e controle e banda (IPFW). Tudo funcionava perfeitamente, principalmente na questão de controle de banda. Porém, conforme descreve Okamoto e seus colegas[1], há bibliotecas de aplicações P2P mais eficazes em TCP do que UDP (inclusive 7x mais rápidas!). Os desenvolvedores de aplicações P2P perceberam isso e, aos poucos, estão abandonando o UDP, principalmente, devido ao fato de muitos administratores fecharem todas as portas UDP, exceto 53,67,68 e 123. Somado a isso, o eMule[2], há algum tempo, dispõe de um recurso chamado Obfuscation Protocol[3], que não era habilitado por padrão, ficando a critério do usuário habilitá-lo. Para completar o estrago, agora essa opção é padrão, e o BitTorrent[4] também entrou na onda da obfuscação[5]. Aqui começa a anomalia: Neste condomínio tem um morador com 256/128kbps de banda (download e upload, respectivamente). Para todas as aplicações que ele usa, o controle de banda é obedecido perfeitamente, exceto para eMule[2] e BitTorrent[4], aplicações que transferem dados em taxas quase 10 vezes maiores. O controle de banda está declarado/numerado no começo das regras, com one_pass desabilitado, tendo abaixo o desvio (fwd) do proxy transparente, desvio (skipto) do PrivateWire (Conectividade Social), divert de entrada, regras statefull e divert de saída. Sendo assim, agradeço novamente a opinião de vocês sobre quais as regras mais adequada para controlar essas aplicações e seus protocolos obscuros. [1] http://www2.lifl.fr/MAP/negst/secondWorkshop/slidesSecondWorkshopNegst/ TakayukiOkamoto.ppt [2] http://www.emule-project.net [3] http://wiki.emule-web.de/index.php/Protocol_obfuscation [4] http://www.bittorrent.com [5] http://torrentfreak.com/how-to-encrypt-bittorrent-traffic/ Grande abraço a todos, Trober - - - - - - -- Lauro Cesar de Oliveira http://www.gurulinux.blog.br Hack to learn not learn to hack. - - 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
Re: [FUG-BR] RES: IPFW, protocolos obscuros, protocolos criptografados etc.
Renato Frederick escreveu: Na regra IPFW você usa como? Eu uso assim: pipe 111 ip from 172.16.20.6 to any in pipe 112 ip from any to 172.16.20.7 out isto funciona indiferente de obfuscacao ou não, já que ele continua usar datagrama IP. :) a obfuscacao vai deixar de funcionar se você utilizar algo L7 para fazer shapping ou usar range de portas. Neste caso, tem que partir para solução comercial mesmo, snort e afins não estão a par do tipo de protocolo usado pela obfuscacao ainda. -Mensagem original- De: freebsd-boun...@fug.com.br [mailto:freebsd-boun...@fug.com.br] Em nome de Trober Enviada em: sábado, 18 de abril de 2009 14:55 Para: FUG-BR Assunto: Re: [FUG-BR] IPFW, protocolos obscuros, protocolos criptografados etc. Olá Lauro :) Grato pelo retorno. Muito boa sua sugestão, mas, por enquanto, o objetivo é manter o FreeBSD, adotando uma solução não-comercial. Caso o IPFW se mostre incapaz de cumprir o propósito de controlar banda de protocolos obscuros e criptografados, partirei para algo comercial. Novamente agradeço sua sugestão. Grande abraço, Trober - - - - www.hostcert.com.br Esse sistema faz o controle de trafego diferente, não utiliza ipfw. Ele segura 100% esses casos. 2009/4/18 Trober tro...@trober.com Prezados, Exponho um cenário anômalo, e serei grato pela opinião de vocês. Atendo um condomínio residencial que fornece internet gratuitamente aos moradores. Cada morador, ao assinar o contrato com o condomínio, opta por informar o endereço físico (MAC) do computador, caso queira internet. As concessões, negações e limitações dos recursos de rede são gerenciadas por um servidor FreeBSD 6.4 (Stable), atuando como proxy transparente (Squid), roteador e controle e banda (IPFW). Tudo funcionava perfeitamente, principalmente na questão de controle de banda. Porém, conforme descreve Okamoto e seus colegas[1], há bibliotecas de aplicações P2P mais eficazes em TCP do que UDP (inclusive 7x mais rápidas!). Os desenvolvedores de aplicações P2P perceberam isso e, aos poucos, estão abandonando o UDP, principalmente, devido ao fato de muitos administratores fecharem todas as portas UDP, exceto 53,67,68 e 123. Somado a isso, o eMule[2], há algum tempo, dispõe de um recurso chamado Obfuscation Protocol[3], que não era habilitado por padrão, ficando a critério do usuário habilitá-lo. Para completar o estrago, agora essa opção é padrão, e o BitTorrent[4] também entrou na onda da obfuscação[5]. Aqui começa a anomalia: Neste condomínio tem um morador com 256/128kbps de banda (download e upload, respectivamente). Para todas as aplicações que ele usa, o controle de banda é obedecido perfeitamente, exceto para eMule[2] e BitTorrent[4], aplicações que transferem dados em taxas quase 10 vezes maiores. O controle de banda está declarado/numerado no começo das regras, com one_pass desabilitado, tendo abaixo o desvio (fwd) do proxy transparente, desvio (skipto) do PrivateWire (Conectividade Social), divert de entrada, regras statefull e divert de saída. Sendo assim, agradeço novamente a opinião de vocês sobre quais as regras mais adequada para controlar essas aplicações e seus protocolos obscuros. [1] http://www2.lifl.fr/MAP/negst/secondWorkshop/slidesSecondWorkshopNegst/ TakayukiOkamoto.ppt [2] http://www.emule-project.net [3] http://wiki.emule-web.de/index.php/Protocol_obfuscation [4] http://www.bittorrent.com [5] http://torrentfreak.com/how-to-encrypt-bittorrent-traffic/ Grande abraço a todos, Trober - - - - - - -- Lauro Cesar de Oliveira http://www.gurulinux.blog.br Hack to learn not learn to hack. - - 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 Renato, Achei estranho quando ele fala que a aplicação consome 10x mais banda... como se ele tivesse liberado 256 para o cara e o p2p estivesse usando quase 2 MB... eh isso mesmo? Se for pode ser a regra do dummynet errada... dar uma olhada em um tópico que abri esses dias sobre dummynet... eu havia errado a netmask do pipe, os testes de velocidade mostravam a velocidade correta... mas um orbit da vida baixava a uma velocidade ENORME... após a correção ficou tudo ok. Não vai bloquear o p2p.. mas se tu limitar a 256 ele só vai baixar a 256... Uma outra coisa que ele pode testar é aquele projeto de L7 para ipfw que estava em testes outro dia...
[FUG-BR] RES: RES: IPFW, protocolos obscuros, protocolos criptografados etc.
Welkson, O L7 já está pegando os p2p obfuscado? Pelo menos quando eu usava virtua, obfuscação era o único jeito de fugir do shapping deles, mas não sei se já atualizaram as regras. Particularmente não tenho bloqueado nada, limito o cliente conforme contrato e dependendo do caso, faço burst para downloads 700MB :) Renato, Achei estranho quando ele fala que a aplicação consome 10x mais banda... como se ele tivesse liberado 256 para o cara e o p2p estivesse usando quase 2 MB... eh isso mesmo? Se for pode ser a regra do dummynet errada... dar uma olhada em um tópico que abri esses dias sobre dummynet... eu havia errado a netmask do pipe, os testes de velocidade mostravam a velocidade correta... mas um orbit da vida baixava a uma velocidade ENORME... após a correção ficou tudo ok. Não vai bloquear o p2p.. mas se tu limitar a 256 ele só vai baixar a 256... Uma outra coisa que ele pode testar é aquele projeto de L7 para ipfw que estava em testes outro dia... para um tráfego pequeno como o dele provavelmente resolve. (ou fica igual ao linux com patch L7) -- Welkson Renny de Medeiros Focus Automação Comercial Desenvolvimento / Gerência de Redes welk...@focusautomacao.com.br Powered by (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org - 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
Re: [FUG-BR] RES: RES: IPFW, protocolos obscuros, protocolos criptografados etc.
Renato Frederick escreveu: Welkson, O L7 já está pegando os p2p obfuscado? Pelo menos quando eu usava virtua, obfuscação era o único jeito de fugir do shapping deles, mas não sei se já atualizaram as regras. Particularmente não tenho bloqueado nada, limito o cliente conforme contrato e dependendo do caso, faço burst para downloads 700MB :) Renato, Achei estranho quando ele fala que a aplicação consome 10x mais banda... como se ele tivesse liberado 256 para o cara e o p2p estivesse usando quase 2 MB... eh isso mesmo? Se for pode ser a regra do dummynet errada... dar uma olhada em um tópico que abri esses dias sobre dummynet... eu havia errado a netmask do pipe, os testes de velocidade mostravam a velocidade correta... mas um orbit da vida baixava a uma velocidade ENORME... após a correção ficou tudo ok. Não vai bloquear o p2p.. mas se tu limitar a 256 ele só vai baixar a 256... Uma outra coisa que ele pode testar é aquele projeto de L7 para ipfw que estava em testes outro dia... para um tráfego pequeno como o dele provavelmente resolve. (ou fica igual ao linux com patch L7) -- Welkson Renny de Medeiros Focus Automação Comercial Desenvolvimento / Gerência de Redes welk...@focusautomacao.com.br Powered by (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org - 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 Renato, Acredito que não (não testei). O que quis dizer é que usando Linux vai ser a mesma coisa =) Acho que obfuscado não tem como detectar... só se quebrar o algorítimo de criptografia.. ou encontrar algum PADRÃO nos pacotes... não sei... viagem =) -- Welkson Renny de Medeiros Focus Automação Comercial Desenvolvimento / Gerência de Redes welk...@focusautomacao.com.br Powered by (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: RES: IPFW, protocolos obscuros, protocolos criptografados etc.
Em Sat, 18 Apr 2009 19:18:59 -0300 Welkson Renny de Medeiros welk...@focusautomacao.com.br, conhecido consumidor de drogas (BigMac's com Coke) escreveu: Acredito que não (não testei). O que quis dizer é que usando Linux vai ser a mesma coisa =) Acho que obfuscado não tem como detectar... só se quebrar o algorítimo de criptografia.. ou encontrar algum PADRÃO nos pacotes... não sei... viagem =) eu estava olhando o link indicado e entendi duas coisas e INFERI algumas outras; o que entendi: a) usam Linux b) usam tun o que INFERI: a)estão usando vpn's com ssl, ou seja, OpenVPN (pode ser vtun também); não acredito que sejam tuneis do catalyst, por ex. /mode rant on b) se fazem em Linux, não acredito que não possa ser melhor (bem melhor) em FreeBSD, por mais que os criadores do HostCERT sejam habilitados e criativos. mas fico realmente curioso: como é possível que um dummynet possa não estabelecer o limite de banda? Estou entendendo RAW BAND e não tráfego de pacotes - é (IMHO) como fechar/abrir torneiras, fo***se se a água é azul. Se não é nada disso então realmente ainda não entendi o conceito dos pipes. /mode rant off please READ CAREFULLY: flames /dev/null -- saudações, irado furioso com tudo Linux User 179402/FreeBSD BSD50853/FUG-BR 154 Não uso drogas - 100% Miko$hit-free O cachorro abana o rabo quando quer agradar, a mulher quando quer agrado. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: RES: IPFW, protocolos obscuros, protocolos criptografados etc.
b) se fazem em Linux, não acredito que não possa ser melhor (bem melhor) em FreeBSD, por mais que os criadores do HostCERT sejam habilitados e criativos. tambem nao acredito que o dummynet nao possa fazer essa limitação de banda.. deve ter algo de errado. Se fazem em linux.. no FreeBSD usando o IPFW eh possível também Cristina - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] Gambiarra ou router caseiro!!
Boa noite!! Tenho um ambiente de testes onde eu gostaria de implementar com o FreeBSD algo parecido com estes roteadores wireless que são vendidos por ae!! Exemplo: um d-link di-524.. possui uma porta wan e 4 portas para serem ligados pcs a cabo..e uma interface wireless. Se alguem se dispor a me ajudar está ai o que realmente quero fazer. Tenho um servidor com 3 placas de rede 10/100 e uma wireless, gostaria de utilizar uma placa para receber meu link de internet.. e com as outras 2 quero ligar 2 pcs para acessarem a net, com cabo cross é claro, e pela wireless quero acessar a net pelo meu notebook. É uma coisa simples.. mas não sei direito pois quero que o ip do servidor seja 192.168.1.254. somente um ip para todas as interfaces.exceto a interface da internet é claro.. como fazer isso?? via bridge?? como ficaria o pf.conf?? configurar o wireless hostap eu sei.. so não to conseguindo criar somente um ip para todas as interfaces.. imaginei que teria como colocar o ip na bridge, integrando todas as interfaces exceto a da internet.. como no windows atraves de conexão de ponte.. mas nao to conseguindo.. desde ja agradeço!!! - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: CPU hotplug
Madre de Dios Agora eu nao posso dormir se não vou sonhar com isso nice. da um boot com tudo habilitado pra 1 vm e passa o dmesg rs quero ver o que aparece no hardware desse monstrinho. 2009/4/17 Ricardo Augusto de Souza ricardo.so...@cmtsp.com.br: Gostei tb. Qt custa uma dessas? http://en.wikipedia.org/wiki/ES7000 -Mensagem original- De: freebsd-boun...@fug.com.br [mailto:freebsd-boun...@fug.com.br] Em nome de Eduardo Schoedler Enviada em: sexta-feira, 17 de abril de 2009 17:22 Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) Assunto: Re: [FUG-BR] CPU hotplug Ahhh, nem eh um blade ainda! kkk -- From: Marcelo Vilela marcelo.free...@gmail.com Sent: Friday, April 17, 2009 4:59 PM To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Subject: Re: [FUG-BR] CPU hotplug ES7000 =) 2009/4/17 Paulo Henrique paulo.rd...@bsd.com.br: Nossa, também fiquei curioso, um hardware desse é a 5 maravilha do mundo computacional. !! - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- - = - = - = - = - = - = - = - = - = - . Of course it runsWilliam David Armstrong |== Bio Systems Security Networking ' FreeBSD MSN / GT biosystems gmail . com http://biosystems.ath.cx:8080/ http://biosystems.broker.freenet6.net/ -- - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: CPU hotplug
só pra matar a curiosidade http://www.serverwatch.com/hreviews/article.php/3708896#chart Xeon configurations start at $29,900 and go up to $348,000; Itanium configurations start at $45,000 and go up to $600,000 http://www.unisys.com/products/enterprise__servers/high_d_end__servers/index.htm página da criança 2009/4/19 William David FUG-BR fu...@biosystems.ath.cx: Madre de Dios Agora eu nao posso dormir se não vou sonhar com isso nice. da um boot com tudo habilitado pra 1 vm e passa o dmesg rs quero ver o que aparece no hardware desse monstrinho. 2009/4/17 Ricardo Augusto de Souza ricardo.so...@cmtsp.com.br: Gostei tb. Qt custa uma dessas? http://en.wikipedia.org/wiki/ES7000 -Mensagem original- De: freebsd-boun...@fug.com.br [mailto:freebsd-boun...@fug.com.br] Em nome de Eduardo Schoedler Enviada em: sexta-feira, 17 de abril de 2009 17:22 Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) Assunto: Re: [FUG-BR] CPU hotplug Ahhh, nem eh um blade ainda! kkk -- From: Marcelo Vilela marcelo.free...@gmail.com Sent: Friday, April 17, 2009 4:59 PM To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Subject: Re: [FUG-BR] CPU hotplug ES7000 =) 2009/4/17 Paulo Henrique paulo.rd...@bsd.com.br: Nossa, também fiquei curioso, um hardware desse é a 5 maravilha do mundo computacional. !! - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- - = - = - = - = - = - = - = - = - = - . Of course it runs William David Armstrong |== Bio Systems Security Networking ' FreeBSD MSN / GT biosystems gmail . com http://biosystems.ath.cx:8080/ http://biosystems.broker.freenet6.net/ -- -- - = - = - = - = - = - = - = - = - = - . Of course it runsWilliam David Armstrong |== Bio Systems Security Networking ' FreeBSD MSN / GT biosystems gmail . com http://biosystems.ath.cx:8080/ http://biosystems.broker.freenet6.net/ -- - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] RES: RES: IPFW, protocolos obscuros, protocolos criptografados etc.
Trober, Você não pode colocar o emule dentro da limitação do cliente? Ex, limitá-lo a 100k, indiferente se ele usa WEB,FTP ou P2P? Se puder, um 'ipfw add pipe X all from IP_CLIENTE to any'(e a volta) funciona. Se não puder, creio que a única solução seria: Ipfw add pipe X all from IP_CLIENTE 1024-65535 to any 1024-65535... mas isto pegaria outros programas legítimos que usam porta alta, MSN, TSCLIENT, CITRIX, OPENVPN. -Mensagem original- De: freebsd-boun...@fug.com.br [mailto:freebsd-boun...@fug.com.br] Em nome de Trober Enviada em: domingo, 19 de abril de 2009 00:56 Para: FUG-BR Assunto: Re: [FUG-BR] RES: IPFW, protocolos obscuros, protocolos criptografados etc. Olá Welkson. Isso mesmo! Tudo perfeitamente controlado em 256kbps, mas BitTorrent, eMule, uTorrent estourando em quase 3mbps. Li seu tópico sobre o Orbit, e tem bastante similaridade com a anomalia que apresentei. Farei testes agora durante a madrugada, e reportarei o resultado assim que solucionado. A idéia também é de não bloquear P2P, mas colocar rédeas na mulinha do eMule e seus amigos vorazes :) Olá Renato. Em relação ao ipfw-classifyd, até onde sei (talvez por engano), ainda há limitações com tratamento de obfuscações e encriptações. Supondo que o RC4 ou qualquer outro algoritmo criptográfico usado em P2P seja quebrado, mesmo que somente em cada início de sessão ao invés de cada pacote trafegado, seria, computacionalmente falando, muito oneroso, principalmente se considerados fatores como limitações dos computadores contemporâneos e realidade financeira. Aos demais. Espero tão logo escrever no título da mensagem o tal do resolvido :P Grande abraço a todos. Saudações, Trober - - - - - Renato Frederick escreveu: Na regra IPFW você usa como? Eu uso assim: pipe 111 ip from 172.16.20.6 to any in pipe 112 ip from any to 172.16.20.7 out isto funciona indiferente de obfuscacao ou não, já que ele continua usar datagrama IP. :) a obfuscacao vai deixar de funcionar se você utilizar algo L7 para fazer shapping ou usar range de portas. Neste caso, tem que partir para solução comercial mesmo, snort e afins não estão a par do tipo de protocolo usado pela obfuscacao ainda. -Mensagem original- De: freebsd-boun...@fug.com.br [mailto:freebsd-boun...@fug.com.br] Em nome de Trober Enviada em: sábado, 18 de abril de 2009 14:55 Para: FUG-BR Assunto: Re: [FUG-BR] IPFW, protocolos obscuros, protocolos criptografados etc. Olá Lauro :) Grato pelo retorno. Muito boa sua sugestão, mas, por enquanto, o objetivo é manter o FreeBSD, adotando uma solução não-comercial. Caso o IPFW se mostre incapaz de cumprir o propósito de controlar banda de protocolos obscuros e criptografados, partirei para algo comercial. Novamente agradeço sua sugestão. Grande abraço, Trober - - - - www.hostcert.com.br Esse sistema faz o controle de trafego diferente, não utiliza ipfw. Ele segura 100% esses casos. 2009/4/18 Trober tro...@trober.com Prezados, Exponho um cenário anômalo, e serei grato pela opinião de vocês. Atendo um condomínio residencial que fornece internet gratuitamente aos moradores. Cada morador, ao assinar o contrato com o condomínio, opta por informar o endereço físico (MAC) do computador, caso queira internet. As concessões, negações e limitações dos recursos de rede são gerenciadas por um servidor FreeBSD 6.4 (Stable), atuando como proxy transparente (Squid), roteador e controle e banda (IPFW). Tudo funcionava perfeitamente, principalmente na questão de controle de banda. Porém, conforme descreve Okamoto e seus colegas[1], há bibliotecas de aplicações P2P mais eficazes em TCP do que UDP (inclusive 7x mais rápidas!). Os desenvolvedores de aplicações P2P perceberam isso e, aos poucos, estão abandonando o UDP, principalmente, devido ao fato de muitos administratores fecharem todas as portas UDP, exceto 53,67,68 e 123. Somado a isso, o eMule[2], há algum tempo, dispõe de um recurso chamado Obfuscation Protocol[3], que não era habilitado por padrão, ficando a critério do usuário habilitá-lo. Para completar o estrago, agora essa opção é padrão, e o BitTorrent[4] também entrou na onda da obfuscação[5]. Aqui começa a anomalia: Neste condomínio tem um morador com 256/128kbps de banda (download e upload, respectivamente). Para todas as aplicações que ele usa, o controle de banda é obedecido perfeitamente, exceto para eMule[2] e BitTorrent[4], aplicações que transferem dados em taxas quase 10 vezes maiores. O controle de banda está declarado/numerado no começo das regras, com one_pass desabilitado, tendo abaixo o desvio (fwd) do proxy transparente, desvio (skipto) do PrivateWire (Conectividade Social),
[FUG-BR] RES: RES: CPU hotplug
Realmente voltamos aos princípios do mainframe :-) Queria ver a cara de quem falou que este conceito ia morrer... -Mensagem original- De: freebsd-boun...@fug.com.br [mailto:freebsd-boun...@fug.com.br] Em nome de William David FUG-BR Enviada em: domingo, 19 de abril de 2009 00:39 Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) Assunto: Re: [FUG-BR] RES: CPU hotplug só pra matar a curiosidade http://www.serverwatch.com/hreviews/article.php/3708896#chart Xeon configurations start at $29,900 and go up to $348,000; Itanium configurations start at $45,000 and go up to $600,000 http://www.unisys.com/products/enterprise__servers/high_d_end__servers/ index.htm página da criança - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
