Re: [FUG-BR] RES: Filtro L7

[Tiago H.Pires]

Bom dia!

Cara testei esse snortlog2cmd, mas como o snort_inline é preciso que ele
saiba que trafego bloquear. O snortlog2cmd bloqueia as portas que
iniciaram um trafego referente a protocolos p2p. Mas ele pode bloquear
aplicaçoes que nao tem nada haver. 
No meu caso optei pelo snort_inline, mas me deparei com as rules para
identificaçao do p2p. Fiquei alguns dias(rsrsrssr varios) com o tcpdump
analizando o que ocorria na hora da conexao dos programas for p2p, e nao
consegui pegar tudo. Alguem que tenha esse ambiente em funcionamento
possa passar suas rules customizadas eu agradeço. ( Ja tinha comentando
isso aqui, de se criar um artigo com o passo a passo, mas me deparei com
as rules do snort que é preciso customizar)

att

Tiago



Em Sáb, 2008-04-12 às 15:36 -0400, Neerlan Amorim escreveu:
> Encontrei um material muito bom sobre filtro l7 em:
> http://www.karczmarski.com/snortlog2cmd.html
> 
> Estou implantando em um ambiente de testes, vamos ver como fica.
> Está ae a dica.
> 
> 2008/3/12 Klaus Schneider <[EMAIL PROTECTED]>:
> 
> > Snort inline é perfeito pra isso.
> >
> > Colocar em kernel space strings e expressões regulares é um tanto
> > arriscado,
> > já em user space, que se f*da, um overflow daria no máximo acesso a shell
> > do
> > usuário que está executando o snort.
> >
> > Snort pode ter um pouco de custo de CPU, mas em compensação, tem tudo, e é
> > simples fazer uma regra para ele.
> >
> > Não importa se o pacote é criptografado ou o protocolo mudou, o fato é que
> > ambos podem não detectar o P2P por causa da criptografia.
> >
> > O negócio é deixar passar apenas protocolos conhecidos e os desconhecidos
> > coloque-os em uma fila de QoS de baixa prioridade.
> >
> > Em 12/03/08, Neerlan Amorim <[EMAIL PROTECTED]> escreveu:
> > >
> > > Bloqueio de porta nenhum resolve resolve o problema do p2p pode ser via
> > > pf,
> > > ipfw.
> > > O controle de banda é uma idéia legal. Só lembrando que tem alguns p2p
> > que
> > > possuem o recurso de criptografia só pra complicar mais ainda.
> > >
> > > A solução pra p2p REALMENTE é filtro na camada 7, legal seria se
> > > desenvolvessem isso pro ipfw. tipo ipfw add deny all from any to any
> > > layer7
> > > p2p edonkey :)
> > >
> > > por enquanto a solução é usar o snort_inline+ipfw.
> > >
> > > 2008/3/12 Bruno Torres Viana <[EMAIL PROTECTED]>:
> > >
> > > > Não sei se vai ajudar muito, aqui eu criei uma regra legal no PF..
> > > >
> > > > pass log proto tcp from { $internal_net, $external_addr } to any port
> > {
> > > <
> > > > 1024, 1494, 1723, 1863, 3456, 50001 } modulate state flags S/SA
> > > >
> > > > Ninguém mais conseguiu usar e-mule nem p2p.
> > > >
> > > > []´s
> > > >
> > > > 2008/3/12 Tiago Isic Brasil <[EMAIL PROTECTED]>:
> > > >
> > > > > Boa tarde!
> > > > >
> > > > > Já tenho algumas soluçoes como descrito, mas precisa ter algo pois,
> > > vai
> > > > > que alguem solicite, quero todas as portas UDP abertas e TCP abertas
> > e
> > > > > bloqueio ou shapping do p2p.
> > > > >
> > > > > att
> > > > >
> > > > > Tiago ISIC Brasil
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Em Qua, 2008-03-12 às 14:43 -0300, Marcello escreveu:
> > > > > > Amigo
> > > > > > Já tem um bom tempinho que coloquei na lista que para bloquear p2p
> > > > basta
> > > > > > bloquear o trafego de UDP , liberando apenas o necessário de
> > > > preferencia
> > > > > > ponto a ponto , por exemplo DNS para servidores de dns , ponto a
> > > ponto
> > > > > > para VPN e assim por diante, isso não exatamente bloqueia o
> > download
> > > > mas
> > > > > > sim a pesquisa de fontes para downloads , tenho por habito colocar
> > o
> > > > > > trafego digamos sujo em uma tunnel de baixa prioridade e ainda com
> > > uma
> > > > > > pequena perda de pacotes , p2p ficam tão ruins que são convencidos
> > a
> > > > não
> > > > > > usa-los , bloquear mesmo 'quase impossivel , mas torna-los
> > > > ineficientes
> > > > > > essa é a minha receita.
> > > > > >
> > > > > > []'s
> > > > > >
> > > > > > Em Qua, 2008-03-12 às 09:56 -0300, Tiago Isic Brasil escreveu:
> > > > > > > Bom dia a todos.
> > > > > > >
> > > > > > > Seguinte estou na lutar por vários dias em criar as rules para o
> > > > > > > snort_inline identificar o trafego p2p.
> > > > > > > Fiquei mais de 1 dia vendo payloads e mais payloads via tcpdump,
> > > > > > > tentando descobrir padroes quando os aplicativos clientes tentam
> > a
> > > > > > > conexão. Bom estou no momento analizando o fonte do ipp2p para
> > > > > encontrar
> > > > > > > os benditos padroes, já consegui algumas coisas e criei em forma
> > > de
> > > > > > > rule, mas o problema " Ainda nao consegui criar as benditas
> > regras
> > > > do
> > > > > > > snort para bloquear pelo menos a tentativa de conexao ".  Nao
> > sou
> > > > > muito
> > > > > > > experiente em gerar as rules, mas estou tentato.
> > > > > > >
> > > > > > > Meu apelo, queria que o pessoal ajuda-se a criar essas regras em
> > > > modo
> > > > > > > geral, seria de utilidade d

Re: [FUG-BR] RES: Filtro L7

[Patrick Tracanelli]

Neerlan Amorim escreveu:
> Encontrei um material muito bom sobre filtro l7 em:
> http://www.karczmarski.com/snortlog2cmd.html
> 
> Estou implantando em um ambiente de testes, vamos ver como fica.
> Está ae a dica.

Só tome cuidado, por não ser orientado a sessão, evite usar regras "from 
any to table(1)" como sugerido na documentação.

Dê preferencia pra "from table(1) to table(2)" garantindo controle 
apenas entre origens e destinos envolvidos em tráfego identificado pelo 
snort.
-
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: Filtro L7

[Neerlan Amorim]

Encontrei um material muito bom sobre filtro l7 em:
http://www.karczmarski.com/snortlog2cmd.html

Estou implantando em um ambiente de testes, vamos ver como fica.
Está ae a dica.

2008/3/12 Klaus Schneider <[EMAIL PROTECTED]>:

> Snort inline é perfeito pra isso.
>
> Colocar em kernel space strings e expressões regulares é um tanto
> arriscado,
> já em user space, que se f*da, um overflow daria no máximo acesso a shell
> do
> usuário que está executando o snort.
>
> Snort pode ter um pouco de custo de CPU, mas em compensação, tem tudo, e é
> simples fazer uma regra para ele.
>
> Não importa se o pacote é criptografado ou o protocolo mudou, o fato é que
> ambos podem não detectar o P2P por causa da criptografia.
>
> O negócio é deixar passar apenas protocolos conhecidos e os desconhecidos
> coloque-os em uma fila de QoS de baixa prioridade.
>
> Em 12/03/08, Neerlan Amorim <[EMAIL PROTECTED]> escreveu:
> >
> > Bloqueio de porta nenhum resolve resolve o problema do p2p pode ser via
> > pf,
> > ipfw.
> > O controle de banda é uma idéia legal. Só lembrando que tem alguns p2p
> que
> > possuem o recurso de criptografia só pra complicar mais ainda.
> >
> > A solução pra p2p REALMENTE é filtro na camada 7, legal seria se
> > desenvolvessem isso pro ipfw. tipo ipfw add deny all from any to any
> > layer7
> > p2p edonkey :)
> >
> > por enquanto a solução é usar o snort_inline+ipfw.
> >
> > 2008/3/12 Bruno Torres Viana <[EMAIL PROTECTED]>:
> >
> > > Não sei se vai ajudar muito, aqui eu criei uma regra legal no PF..
> > >
> > > pass log proto tcp from { $internal_net, $external_addr } to any port
> {
> > <
> > > 1024, 1494, 1723, 1863, 3456, 50001 } modulate state flags S/SA
> > >
> > > Ninguém mais conseguiu usar e-mule nem p2p.
> > >
> > > []´s
> > >
> > > 2008/3/12 Tiago Isic Brasil <[EMAIL PROTECTED]>:
> > >
> > > > Boa tarde!
> > > >
> > > > Já tenho algumas soluçoes como descrito, mas precisa ter algo pois,
> > vai
> > > > que alguem solicite, quero todas as portas UDP abertas e TCP abertas
> e
> > > > bloqueio ou shapping do p2p.
> > > >
> > > > att
> > > >
> > > > Tiago ISIC Brasil
> > > >
> > > >
> > > >
> > > >
> > > > Em Qua, 2008-03-12 às 14:43 -0300, Marcello escreveu:
> > > > > Amigo
> > > > > Já tem um bom tempinho que coloquei na lista que para bloquear p2p
> > > basta
> > > > > bloquear o trafego de UDP , liberando apenas o necessário de
> > > preferencia
> > > > > ponto a ponto , por exemplo DNS para servidores de dns , ponto a
> > ponto
> > > > > para VPN e assim por diante, isso não exatamente bloqueia o
> download
> > > mas
> > > > > sim a pesquisa de fontes para downloads , tenho por habito colocar
> o
> > > > > trafego digamos sujo em uma tunnel de baixa prioridade e ainda com
> > uma
> > > > > pequena perda de pacotes , p2p ficam tão ruins que são convencidos
> a
> > > não
> > > > > usa-los , bloquear mesmo 'quase impossivel , mas torna-los
> > > ineficientes
> > > > > essa é a minha receita.
> > > > >
> > > > > []'s
> > > > >
> > > > > Em Qua, 2008-03-12 às 09:56 -0300, Tiago Isic Brasil escreveu:
> > > > > > Bom dia a todos.
> > > > > >
> > > > > > Seguinte estou na lutar por vários dias em criar as rules para o
> > > > > > snort_inline identificar o trafego p2p.
> > > > > > Fiquei mais de 1 dia vendo payloads e mais payloads via tcpdump,
> > > > > > tentando descobrir padroes quando os aplicativos clientes tentam
> a
> > > > > > conexão. Bom estou no momento analizando o fonte do ipp2p para
> > > > encontrar
> > > > > > os benditos padroes, já consegui algumas coisas e criei em forma
> > de
> > > > > > rule, mas o problema " Ainda nao consegui criar as benditas
> regras
> > > do
> > > > > > snort para bloquear pelo menos a tentativa de conexao ".  Nao
> sou
> > > > muito
> > > > > > experiente em gerar as rules, mas estou tentato.
> > > > > >
> > > > > > Meu apelo, queria que o pessoal ajuda-se a criar essas regras em
> > > modo
> > > > > > geral, seria de utilidade de todos. OU quem já possui em seu
> > > ambiente
> > > > e
> > > > > > funciona, por favor compartilhe, seja solidário com a
> comunidade.
> > > > > >
> > > > > > Pensem se conseguirmos bloquear o trafego p2p poderemos chamar
> > mais
> > > > > > adpetos para nosso Sistema Operacional.
> > > > > >
> > > > > > Segue abaixo as minhas rules geradas após analizar os fontes do
> > > ipp2p:
> > > > > >
> > > > > > #Analise de UDP
> > > > > >
> > > > > > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P
> eDonkey
> > > > eMule
> > > > > > Kad commands Client -> Server status request"; content:"|e3
> 96|";)
> > > > > > reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P
> eDonkey
> > > > eMule
> > > > > > Kad commands Server -> Client status request"; content:"|e3
> 97|";)
> > > > > >
> > > > > > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P
> eDonkey
> > > > eMule
> > > > > > Kad commands Server description request"; content:"|e3 a2|";
> > > dsize:6;)
> > > > > > reinject udp $HOME_NET any -> $EXTERNAL_NET

Re: [FUG-BR] RES: Filtro L7

[Klaus Schneider]

Snort inline é perfeito pra isso.

Colocar em kernel space strings e expressões regulares é um tanto arriscado,
já em user space, que se f*da, um overflow daria no máximo acesso a shell do
usuário que está executando o snort.

Snort pode ter um pouco de custo de CPU, mas em compensação, tem tudo, e é
simples fazer uma regra para ele.

Não importa se o pacote é criptografado ou o protocolo mudou, o fato é que
ambos podem não detectar o P2P por causa da criptografia.

O negócio é deixar passar apenas protocolos conhecidos e os desconhecidos
coloque-os em uma fila de QoS de baixa prioridade.

Em 12/03/08, Neerlan Amorim <[EMAIL PROTECTED]> escreveu:
>
> Bloqueio de porta nenhum resolve resolve o problema do p2p pode ser via
> pf,
> ipfw.
> O controle de banda é uma idéia legal. Só lembrando que tem alguns p2p que
> possuem o recurso de criptografia só pra complicar mais ainda.
>
> A solução pra p2p REALMENTE é filtro na camada 7, legal seria se
> desenvolvessem isso pro ipfw. tipo ipfw add deny all from any to any
> layer7
> p2p edonkey :)
>
> por enquanto a solução é usar o snort_inline+ipfw.
>
> 2008/3/12 Bruno Torres Viana <[EMAIL PROTECTED]>:
>
> > Não sei se vai ajudar muito, aqui eu criei uma regra legal no PF..
> >
> > pass log proto tcp from { $internal_net, $external_addr } to any port {
> <
> > 1024, 1494, 1723, 1863, 3456, 50001 } modulate state flags S/SA
> >
> > Ninguém mais conseguiu usar e-mule nem p2p.
> >
> > []´s
> >
> > 2008/3/12 Tiago Isic Brasil <[EMAIL PROTECTED]>:
> >
> > > Boa tarde!
> > >
> > > Já tenho algumas soluçoes como descrito, mas precisa ter algo pois,
> vai
> > > que alguem solicite, quero todas as portas UDP abertas e TCP abertas e
> > > bloqueio ou shapping do p2p.
> > >
> > > att
> > >
> > > Tiago ISIC Brasil
> > >
> > >
> > >
> > >
> > > Em Qua, 2008-03-12 às 14:43 -0300, Marcello escreveu:
> > > > Amigo
> > > > Já tem um bom tempinho que coloquei na lista que para bloquear p2p
> > basta
> > > > bloquear o trafego de UDP , liberando apenas o necessário de
> > preferencia
> > > > ponto a ponto , por exemplo DNS para servidores de dns , ponto a
> ponto
> > > > para VPN e assim por diante, isso não exatamente bloqueia o download
> > mas
> > > > sim a pesquisa de fontes para downloads , tenho por habito colocar o
> > > > trafego digamos sujo em uma tunnel de baixa prioridade e ainda com
> uma
> > > > pequena perda de pacotes , p2p ficam tão ruins que são convencidos a
> > não
> > > > usa-los , bloquear mesmo 'quase impossivel , mas torna-los
> > ineficientes
> > > > essa é a minha receita.
> > > >
> > > > []'s
> > > >
> > > > Em Qua, 2008-03-12 às 09:56 -0300, Tiago Isic Brasil escreveu:
> > > > > Bom dia a todos.
> > > > >
> > > > > Seguinte estou na lutar por vários dias em criar as rules para o
> > > > > snort_inline identificar o trafego p2p.
> > > > > Fiquei mais de 1 dia vendo payloads e mais payloads via tcpdump,
> > > > > tentando descobrir padroes quando os aplicativos clientes tentam a
> > > > > conexão. Bom estou no momento analizando o fonte do ipp2p para
> > > encontrar
> > > > > os benditos padroes, já consegui algumas coisas e criei em forma
> de
> > > > > rule, mas o problema " Ainda nao consegui criar as benditas regras
> > do
> > > > > snort para bloquear pelo menos a tentativa de conexao ".  Nao sou
> > > muito
> > > > > experiente em gerar as rules, mas estou tentato.
> > > > >
> > > > > Meu apelo, queria que o pessoal ajuda-se a criar essas regras em
> > modo
> > > > > geral, seria de utilidade de todos. OU quem já possui em seu
> > ambiente
> > > e
> > > > > funciona, por favor compartilhe, seja solidário com a comunidade.
> > > > >
> > > > > Pensem se conseguirmos bloquear o trafego p2p poderemos chamar
> mais
> > > > > adpetos para nosso Sistema Operacional.
> > > > >
> > > > > Segue abaixo as minhas rules geradas após analizar os fontes do
> > ipp2p:
> > > > >
> > > > > #Analise de UDP
> > > > >
> > > > > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey
> > > eMule
> > > > > Kad commands Client -> Server status request"; content:"|e3 96|";)
> > > > > reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P eDonkey
> > > eMule
> > > > > Kad commands Server -> Client status request"; content:"|e3 97|";)
> > > > >
> > > > > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey
> > > eMule
> > > > > Kad commands Server description request"; content:"|e3 a2|";
> > dsize:6;)
> > > > > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey
> > > eMule
> > > > > Kad commands Server description response"; content:"|e3 9a|";)
> > > > > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey
> > > eMule
> > > > > Kad commands Server description response"; content:"|e3 92|";)
> > > > > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey
> > > eMule
> > > > > Kad commands Server description response"; content:"|e4 20|";
> > > > > dsize:43;)
> > > > > reinject udp $HOME_NET any -> $EXTERNAL_NET a

Re: [FUG-BR] RES: Filtro L7

[Neerlan Amorim]

Bloqueio de porta nenhum resolve resolve o problema do p2p pode ser via pf,
ipfw.
O controle de banda é uma idéia legal. Só lembrando que tem alguns p2p que
possuem o recurso de criptografia só pra complicar mais ainda.

A solução pra p2p REALMENTE é filtro na camada 7, legal seria se
desenvolvessem isso pro ipfw. tipo ipfw add deny all from any to any layer7
p2p edonkey :)

por enquanto a solução é usar o snort_inline+ipfw.

2008/3/12 Bruno Torres Viana <[EMAIL PROTECTED]>:

> Não sei se vai ajudar muito, aqui eu criei uma regra legal no PF..
>
> pass log proto tcp from { $internal_net, $external_addr } to any port { <
> 1024, 1494, 1723, 1863, 3456, 50001 } modulate state flags S/SA
>
> Ninguém mais conseguiu usar e-mule nem p2p.
>
> []´s
>
> 2008/3/12 Tiago Isic Brasil <[EMAIL PROTECTED]>:
>
> > Boa tarde!
> >
> > Já tenho algumas soluçoes como descrito, mas precisa ter algo pois, vai
> > que alguem solicite, quero todas as portas UDP abertas e TCP abertas e
> > bloqueio ou shapping do p2p.
> >
> > att
> >
> > Tiago ISIC Brasil
> >
> >
> >
> >
> > Em Qua, 2008-03-12 às 14:43 -0300, Marcello escreveu:
> > > Amigo
> > > Já tem um bom tempinho que coloquei na lista que para bloquear p2p
> basta
> > > bloquear o trafego de UDP , liberando apenas o necessário de
> preferencia
> > > ponto a ponto , por exemplo DNS para servidores de dns , ponto a ponto
> > > para VPN e assim por diante, isso não exatamente bloqueia o download
> mas
> > > sim a pesquisa de fontes para downloads , tenho por habito colocar o
> > > trafego digamos sujo em uma tunnel de baixa prioridade e ainda com uma
> > > pequena perda de pacotes , p2p ficam tão ruins que são convencidos a
> não
> > > usa-los , bloquear mesmo 'quase impossivel , mas torna-los
> ineficientes
> > > essa é a minha receita.
> > >
> > > []'s
> > >
> > > Em Qua, 2008-03-12 às 09:56 -0300, Tiago Isic Brasil escreveu:
> > > > Bom dia a todos.
> > > >
> > > > Seguinte estou na lutar por vários dias em criar as rules para o
> > > > snort_inline identificar o trafego p2p.
> > > > Fiquei mais de 1 dia vendo payloads e mais payloads via tcpdump,
> > > > tentando descobrir padroes quando os aplicativos clientes tentam a
> > > > conexão. Bom estou no momento analizando o fonte do ipp2p para
> > encontrar
> > > > os benditos padroes, já consegui algumas coisas e criei em forma de
> > > > rule, mas o problema " Ainda nao consegui criar as benditas regras
> do
> > > > snort para bloquear pelo menos a tentativa de conexao ".  Nao sou
> > muito
> > > > experiente em gerar as rules, mas estou tentato.
> > > >
> > > > Meu apelo, queria que o pessoal ajuda-se a criar essas regras em
> modo
> > > > geral, seria de utilidade de todos. OU quem já possui em seu
> ambiente
> > e
> > > > funciona, por favor compartilhe, seja solidário com a comunidade.
> > > >
> > > > Pensem se conseguirmos bloquear o trafego p2p poderemos chamar mais
> > > > adpetos para nosso Sistema Operacional.
> > > >
> > > > Segue abaixo as minhas rules geradas após analizar os fontes do
> ipp2p:
> > > >
> > > > #Analise de UDP
> > > >
> > > > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey
> > eMule
> > > > Kad commands Client -> Server status request"; content:"|e3 96|";)
> > > > reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P eDonkey
> > eMule
> > > > Kad commands Server -> Client status request"; content:"|e3 97|";)
> > > >
> > > > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey
> > eMule
> > > > Kad commands Server description request"; content:"|e3 a2|";
> dsize:6;)
> > > > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey
> > eMule
> > > > Kad commands Server description response"; content:"|e3 9a|";)
> > > > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey
> > eMule
> > > > Kad commands Server description response"; content:"|e3 92|";)
> > > > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey
> > eMule
> > > > Kad commands Server description response"; content:"|e4 20|";
> > > > dsize:43;)
> > > > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey
> > eMule
> > > > Kad commands Server description response"; content:"|e4 00|"; )
> > > > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey
> > eMule
> > > > Kad commands Server description response"; content:"|e4 10|"; )
> > > > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey
> > eMule
> > > > Kad commands Server description response"; content:"|e4 18|"; )
> > > > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey
> > eMule
> > > > Kad commands Server description response"; content:"|e4 52|";
> > > > dsize:44;)
> > > > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey
> > eMule
> > > > Kad commands Server description response"; content:"|e4 58|";
> > dsize:6;)
> > > > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey
> > eMule
> > > > Kad commands Server description respons

Re: [FUG-BR] RES: Filtro L7

[Bruno Torres Viana]

Não sei se vai ajudar muito, aqui eu criei uma regra legal no PF..

pass log proto tcp from { $internal_net, $external_addr } to any port { <
1024, 1494, 1723, 1863, 3456, 50001 } modulate state flags S/SA

Ninguém mais conseguiu usar e-mule nem p2p.

[]´s

2008/3/12 Tiago Isic Brasil <[EMAIL PROTECTED]>:

> Boa tarde!
>
> Já tenho algumas soluçoes como descrito, mas precisa ter algo pois, vai
> que alguem solicite, quero todas as portas UDP abertas e TCP abertas e
> bloqueio ou shapping do p2p.
>
> att
>
> Tiago ISIC Brasil
>
>
>
>
> Em Qua, 2008-03-12 às 14:43 -0300, Marcello escreveu:
> > Amigo
> > Já tem um bom tempinho que coloquei na lista que para bloquear p2p basta
> > bloquear o trafego de UDP , liberando apenas o necessário de preferencia
> > ponto a ponto , por exemplo DNS para servidores de dns , ponto a ponto
> > para VPN e assim por diante, isso não exatamente bloqueia o download mas
> > sim a pesquisa de fontes para downloads , tenho por habito colocar o
> > trafego digamos sujo em uma tunnel de baixa prioridade e ainda com uma
> > pequena perda de pacotes , p2p ficam tão ruins que são convencidos a não
> > usa-los , bloquear mesmo 'quase impossivel , mas torna-los ineficientes
> > essa é a minha receita.
> >
> > []'s
> >
> > Em Qua, 2008-03-12 às 09:56 -0300, Tiago Isic Brasil escreveu:
> > > Bom dia a todos.
> > >
> > > Seguinte estou na lutar por vários dias em criar as rules para o
> > > snort_inline identificar o trafego p2p.
> > > Fiquei mais de 1 dia vendo payloads e mais payloads via tcpdump,
> > > tentando descobrir padroes quando os aplicativos clientes tentam a
> > > conexão. Bom estou no momento analizando o fonte do ipp2p para
> encontrar
> > > os benditos padroes, já consegui algumas coisas e criei em forma de
> > > rule, mas o problema " Ainda nao consegui criar as benditas regras do
> > > snort para bloquear pelo menos a tentativa de conexao ".  Nao sou
> muito
> > > experiente em gerar as rules, mas estou tentato.
> > >
> > > Meu apelo, queria que o pessoal ajuda-se a criar essas regras em modo
> > > geral, seria de utilidade de todos. OU quem já possui em seu ambiente
> e
> > > funciona, por favor compartilhe, seja solidário com a comunidade.
> > >
> > > Pensem se conseguirmos bloquear o trafego p2p poderemos chamar mais
> > > adpetos para nosso Sistema Operacional.
> > >
> > > Segue abaixo as minhas rules geradas após analizar os fontes do ipp2p:
> > >
> > > #Analise de UDP
> > >
> > > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey
> eMule
> > > Kad commands Client -> Server status request"; content:"|e3 96|";)
> > > reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P eDonkey
> eMule
> > > Kad commands Server -> Client status request"; content:"|e3 97|";)
> > >
> > > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey
> eMule
> > > Kad commands Server description request"; content:"|e3 a2|"; dsize:6;)
> > > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey
> eMule
> > > Kad commands Server description response"; content:"|e3 9a|";)
> > > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey
> eMule
> > > Kad commands Server description response"; content:"|e3 92|";)
> > > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey
> eMule
> > > Kad commands Server description response"; content:"|e4 20|";
> > > dsize:43;)
> > > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey
> eMule
> > > Kad commands Server description response"; content:"|e4 00|"; )
> > > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey
> eMule
> > > Kad commands Server description response"; content:"|e4 10|"; )
> > > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey
> eMule
> > > Kad commands Server description response"; content:"|e4 18|"; )
> > > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey
> eMule
> > > Kad commands Server description response"; content:"|e4 52|";
> > > dsize:44;)
> > > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey
> eMule
> > > Kad commands Server description response"; content:"|e4 58|";
> dsize:6;)
> > > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey
> eMule
> > > Kad commands Server description response"; content:"|e4 59|";
> dsize:2;)
> > > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey
> eMule
> > > Kad commands Server description response"; content:"|e4 28|"; )
> > > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey
> eMule
> > > Kad commands Server description response"; content:"|e4 50|";
> > > dsize:4; )
> > > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey
> eMule
> > > Kad commands Server description response"; content:"|e4 40|";
> > > dsize:48; )
> > >
> > >
> > > reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P eDonkey
> eMule
> > > Kad commands Server description request"; content:"|e3 a2|"; dsize:6;)
> > > reinject udp $EXTER

Re: [FUG-BR] RES: Filtro L7

[Tiago Isic Brasil]

Boa tarde!

Já tenho algumas soluçoes como descrito, mas precisa ter algo pois, vai
que alguem solicite, quero todas as portas UDP abertas e TCP abertas e
bloqueio ou shapping do p2p. 

att

Tiago ISIC Brasil




Em Qua, 2008-03-12 às 14:43 -0300, Marcello escreveu:
> Amigo
> Já tem um bom tempinho que coloquei na lista que para bloquear p2p basta
> bloquear o trafego de UDP , liberando apenas o necessário de preferencia
> ponto a ponto , por exemplo DNS para servidores de dns , ponto a ponto
> para VPN e assim por diante, isso não exatamente bloqueia o download mas
> sim a pesquisa de fontes para downloads , tenho por habito colocar o
> trafego digamos sujo em uma tunnel de baixa prioridade e ainda com uma
> pequena perda de pacotes , p2p ficam tão ruins que são convencidos a não
> usa-los , bloquear mesmo 'quase impossivel , mas torna-los ineficientes
> essa é a minha receita.
> 
> []'s
> 
> Em Qua, 2008-03-12 às 09:56 -0300, Tiago Isic Brasil escreveu:
> > Bom dia a todos.
> > 
> > Seguinte estou na lutar por vários dias em criar as rules para o
> > snort_inline identificar o trafego p2p.
> > Fiquei mais de 1 dia vendo payloads e mais payloads via tcpdump,
> > tentando descobrir padroes quando os aplicativos clientes tentam a
> > conexão. Bom estou no momento analizando o fonte do ipp2p para encontrar
> > os benditos padroes, já consegui algumas coisas e criei em forma de
> > rule, mas o problema " Ainda nao consegui criar as benditas regras do
> > snort para bloquear pelo menos a tentativa de conexao ".  Nao sou muito
> > experiente em gerar as rules, mas estou tentato.
> > 
> > Meu apelo, queria que o pessoal ajuda-se a criar essas regras em modo
> > geral, seria de utilidade de todos. OU quem já possui em seu ambiente e
> > funciona, por favor compartilhe, seja solidário com a comunidade.
> > 
> > Pensem se conseguirmos bloquear o trafego p2p poderemos chamar mais
> > adpetos para nosso Sistema Operacional.
> > 
> > Segue abaixo as minhas rules geradas após analizar os fontes do ipp2p:
> > 
> > #Analise de UDP
> > 
> > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
> > Kad commands Client -> Server status request"; content:"|e3 96|";) 
> > reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P eDonkey eMule
> > Kad commands Server -> Client status request"; content:"|e3 97|";) 
> > 
> > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
> > Kad commands Server description request"; content:"|e3 a2|"; dsize:6;) 
> > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
> > Kad commands Server description response"; content:"|e3 9a|";) 
> > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
> > Kad commands Server description response"; content:"|e3 92|";) 
> > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
> > Kad commands Server description response"; content:"|e4 20|";
> > dsize:43;) 
> > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
> > Kad commands Server description response"; content:"|e4 00|"; ) 
> > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
> > Kad commands Server description response"; content:"|e4 10|"; ) 
> > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
> > Kad commands Server description response"; content:"|e4 18|"; ) 
> > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
> > Kad commands Server description response"; content:"|e4 52|";
> > dsize:44;) 
> > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
> > Kad commands Server description response"; content:"|e4 58|"; dsize:6;) 
> > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
> > Kad commands Server description response"; content:"|e4 59|"; dsize:2;) 
> > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
> > Kad commands Server description response"; content:"|e4 28|"; ) 
> > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
> > Kad commands Server description response"; content:"|e4 50|";
> > dsize:4; ) 
> > reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
> > Kad commands Server description response"; content:"|e4 40|";
> > dsize:48; ) 
> > 
> > 
> > reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P eDonkey eMule
> > Kad commands Server description request"; content:"|e3 a2|"; dsize:6;) 
> > reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P eDonkey eMule
> > Kad commands Server description response"; content:"|e3 9a|";) 
> > reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P eDonkey eMule
> > Kad commands Server description response"; content:"|e3 92|";) 
> > reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P eDonkey eMule
> > Kad commands Server description response"; content:"|e4 20|";
> > dsize:43;) 
> > reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P eDonkey eMul

Re: [FUG-BR] RES: Filtro L7

[Marcello]

Amigo
Já tem um bom tempinho que coloquei na lista que para bloquear p2p basta
bloquear o trafego de UDP , liberando apenas o necessário de preferencia
ponto a ponto , por exemplo DNS para servidores de dns , ponto a ponto
para VPN e assim por diante, isso não exatamente bloqueia o download mas
sim a pesquisa de fontes para downloads , tenho por habito colocar o
trafego digamos sujo em uma tunnel de baixa prioridade e ainda com uma
pequena perda de pacotes , p2p ficam tão ruins que são convencidos a não
usa-los , bloquear mesmo 'quase impossivel , mas torna-los ineficientes
essa é a minha receita.

[]'s

Em Qua, 2008-03-12 às 09:56 -0300, Tiago Isic Brasil escreveu:
> Bom dia a todos.
> 
> Seguinte estou na lutar por vários dias em criar as rules para o
> snort_inline identificar o trafego p2p.
> Fiquei mais de 1 dia vendo payloads e mais payloads via tcpdump,
> tentando descobrir padroes quando os aplicativos clientes tentam a
> conexão. Bom estou no momento analizando o fonte do ipp2p para encontrar
> os benditos padroes, já consegui algumas coisas e criei em forma de
> rule, mas o problema " Ainda nao consegui criar as benditas regras do
> snort para bloquear pelo menos a tentativa de conexao ".  Nao sou muito
> experiente em gerar as rules, mas estou tentato.
> 
> Meu apelo, queria que o pessoal ajuda-se a criar essas regras em modo
> geral, seria de utilidade de todos. OU quem já possui em seu ambiente e
> funciona, por favor compartilhe, seja solidário com a comunidade.
> 
> Pensem se conseguirmos bloquear o trafego p2p poderemos chamar mais
> adpetos para nosso Sistema Operacional.
> 
> Segue abaixo as minhas rules geradas após analizar os fontes do ipp2p:
> 
> #Analise de UDP
> 
> reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
> Kad commands Client -> Server status request"; content:"|e3 96|";) 
> reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P eDonkey eMule
> Kad commands Server -> Client status request"; content:"|e3 97|";) 
> 
> reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
> Kad commands Server description request"; content:"|e3 a2|"; dsize:6;) 
> reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
> Kad commands Server description response"; content:"|e3 9a|";) 
> reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
> Kad commands Server description response"; content:"|e3 92|";) 
> reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
> Kad commands Server description response"; content:"|e4 20|";
> dsize:43;) 
> reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
> Kad commands Server description response"; content:"|e4 00|"; ) 
> reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
> Kad commands Server description response"; content:"|e4 10|"; ) 
> reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
> Kad commands Server description response"; content:"|e4 18|"; ) 
> reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
> Kad commands Server description response"; content:"|e4 52|";
> dsize:44;) 
> reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
> Kad commands Server description response"; content:"|e4 58|"; dsize:6;) 
> reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
> Kad commands Server description response"; content:"|e4 59|"; dsize:2;) 
> reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
> Kad commands Server description response"; content:"|e4 28|"; ) 
> reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
> Kad commands Server description response"; content:"|e4 50|";
> dsize:4; ) 
> reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
> Kad commands Server description response"; content:"|e4 40|";
> dsize:48; ) 
> 
> 
> reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P eDonkey eMule
> Kad commands Server description request"; content:"|e3 a2|"; dsize:6;) 
> reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P eDonkey eMule
> Kad commands Server description response"; content:"|e3 9a|";) 
> reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P eDonkey eMule
> Kad commands Server description response"; content:"|e3 92|";) 
> reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P eDonkey eMule
> Kad commands Server description response"; content:"|e4 20|";
> dsize:43;) 
> reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P eDonkey eMule
> Kad commands Server description response"; content:"|e4 00|"; ) 
> reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P eDonkey eMule
> Kad commands Server description response"; content:"|e4 10|"; ) 
> reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P eDonkey eMule
> Kad commands Server description response"; content:"|e4 18|"; ) 
> reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P eDonkey eMule
> Kad comm

Re: [FUG-BR] RES: Filtro L7

[Tiago Isic Brasil]

Bom dia a todos.

Seguinte estou na lutar por vários dias em criar as rules para o
snort_inline identificar o trafego p2p.
Fiquei mais de 1 dia vendo payloads e mais payloads via tcpdump,
tentando descobrir padroes quando os aplicativos clientes tentam a
conexão. Bom estou no momento analizando o fonte do ipp2p para encontrar
os benditos padroes, já consegui algumas coisas e criei em forma de
rule, mas o problema " Ainda nao consegui criar as benditas regras do
snort para bloquear pelo menos a tentativa de conexao ".  Nao sou muito
experiente em gerar as rules, mas estou tentato.

Meu apelo, queria que o pessoal ajuda-se a criar essas regras em modo
geral, seria de utilidade de todos. OU quem já possui em seu ambiente e
funciona, por favor compartilhe, seja solidário com a comunidade.

Pensem se conseguirmos bloquear o trafego p2p poderemos chamar mais
adpetos para nosso Sistema Operacional.

Segue abaixo as minhas rules geradas após analizar os fontes do ipp2p:

#Analise de UDP

reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
Kad commands Client -> Server status request"; content:"|e3 96|";) 
reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P eDonkey eMule
Kad commands Server -> Client status request"; content:"|e3 97|";) 

reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
Kad commands Server description request"; content:"|e3 a2|"; dsize:6;) 
reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
Kad commands Server description response"; content:"|e3 9a|";) 
reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
Kad commands Server description response"; content:"|e3 92|";) 
reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
Kad commands Server description response"; content:"|e4 20|";
dsize:43;) 
reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
Kad commands Server description response"; content:"|e4 00|"; ) 
reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
Kad commands Server description response"; content:"|e4 10|"; ) 
reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
Kad commands Server description response"; content:"|e4 18|"; ) 
reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
Kad commands Server description response"; content:"|e4 52|";
dsize:44;) 
reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
Kad commands Server description response"; content:"|e4 58|"; dsize:6;) 
reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
Kad commands Server description response"; content:"|e4 59|"; dsize:2;) 
reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
Kad commands Server description response"; content:"|e4 28|"; ) 
reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
Kad commands Server description response"; content:"|e4 50|";
dsize:4; ) 
reinject udp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P eDonkey eMule
Kad commands Server description response"; content:"|e4 40|";
dsize:48; ) 


reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P eDonkey eMule
Kad commands Server description request"; content:"|e3 a2|"; dsize:6;) 
reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P eDonkey eMule
Kad commands Server description response"; content:"|e3 9a|";) 
reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P eDonkey eMule
Kad commands Server description response"; content:"|e3 92|";) 
reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P eDonkey eMule
Kad commands Server description response"; content:"|e4 20|";
dsize:43;) 
reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P eDonkey eMule
Kad commands Server description response"; content:"|e4 00|"; ) 
reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P eDonkey eMule
Kad commands Server description response"; content:"|e4 10|"; ) 
reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P eDonkey eMule
Kad commands Server description response"; content:"|e4 18|"; ) 
reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P eDonkey eMule
Kad commands Server description response"; content:"|e4 52|";
dsize:44;) 
reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P eDonkey eMule
Kad commands Server description response"; content:"|e4 58|"; dsize:6;) 
reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P eDonkey eMule
Kad commands Server description response"; content:"|e4 59|"; dsize:2;) 
reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P eDonkey eMule
Kad commands Server description response"; content:"|e4 28|"; ) 
reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P eDonkey eMule
Kad commands Server description response"; content:"|e4 50|";
dsize:4; ) 
reinject udp $EXTERNAL_NET any -> $HOME_NET any (msg:"P2P eDonkey eMule
Kad commands Server description response"; content:"|e4 40|";
dsize:48; ) 


Tambem estou usando as rules padroes do s

Re: [FUG-BR] RES: Filtro L7

[mantunes]

valeu rapaz..

qualquer coisa vou buzinar ai na tua porta..

Em 21/02/08, Welkson Renny de Medeiros<[EMAIL PROTECTED]> escreveu:
> Márcio,
>
>  Os scripts já vem na instalação do OSSEC (para vários firewalls), veja:
>
>  [EMAIL PROTECTED]:/var/ossec/active-response/bin] # pwd
>  /var/ossec/active-response/bin
>
>  [EMAIL PROTECTED]:/var/ossec/active-response/bin] # ls
>  default-firewall-drop.sh*  firewall-drop.sh*  ipfw.sh*  pf.sh*
>  disable-account.sh*host-deny.sh*  ipfw_mac.sh*  route-null.sh*
>
>  É só copiar o pf.sh por cima do firewall-drop.sh... que é o script usado por
>  padrão no ossec... ou alterar o parâmetro firewall-drop no ossec.conf
>  (/var/ossec/etc)
>
>  Fora o firewall, o ossec também bloqueia via arquivo hosts.deny... eu não
>  gostei disso e comentei o script... prefiro usar o bloqueio só pelo firewall
>  mesmo.
>
>  Abraço,
>
>
>
>  --
>
> Welkson Renny de Medeiros
>  Focus Automação Comercial
>  Desenvolvimento / Gerência de Redes
>  [EMAIL PROTECTED]
>
>
>
>   Powered by 
>
>(__)
> \\\'',)
>   \/  \ ^
>   .\._/_)
>
>   www.FreeBSD.org
>
>  - Original Message -
>  From: "mantunes" <[EMAIL PROTECTED]>
>  To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
>  
>
> Sent: Thursday, February 21, 2008 2:50 PM
>  Subject: Re: [FUG-BR] RES: Filtro L7
>
>
>  Welkson
>
>  vc pode me passar esse script.. tenho interesse de implementar essa solução.
>
>  agradeço muito..
>
>  obrigado
>
>  Em 21/02/08, Welkson Renny de Medeiros<[EMAIL PROTECTED]>
>  escreveu:
>  > Bom tarde Márcio!
>  >
>  >
>  >  Do snort_inline não posso comentar, nunca usei... sobre o firewall, eu já
>  >  havia migrado todas as regras de bloqueio para o pf, deixei o ipfw
>  >  exclusivamente para controle de banda... com isso senti necessidade de
>  >  também migrar o ossec para pf... o Daniel Cid (ossec) já havia escrito o
>  >  shell script com regras para pf, testei e está funcionando muito bem...
>  > por
>  >  dia geralmente são bloqueados +- uns 300 ips...
>  >
>  >  Agora pouco reiniciei a máquina, olha só quantos ips já foram bloqueados:
>  >
>  >  [EMAIL PROTECTED]:~] # mostra-bloqueados
>  >  IPs bloqueados:   32
>  >
>  >  [EMAIL PROTECTED]:~] # cat /bin/mostra-bloqueados
>  >  printf "IPs bloqueados: $(pfctl -t ossec -T show | wc -l) \n\n"
>  >
>  >  Para acompanhar os bloqueios eu uso o BASE + PostgreSQL.
>  >
>  >  É isso, abraço!!!
>  >
>  >
>  >
>  >  --
>  >
>  > Welkson Renny de Medeiros
>  >  Focus Automação Comercial
>  >  Desenvolvimento / Gerência de Redes
>  >  [EMAIL PROTECTED]
>  >
>  >
>  >
>  >   Powered by 
>  >
>  >        (__)
>  >     \\\'',)
>  >   \/  \ ^
>  >   .\._/_)
>  >
>  >   www.FreeBSD.org
>  >
>  >  - Original Message -
>  >  From: "mantunes" <[EMAIL PROTECTED]>
>  >  To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
>  >  
>  >
>  > Sent: Thursday, February 21, 2008 11:26 AM
>  >  Subject: Re: [FUG-BR] RES: Filtro L7
>  >
>  >
>  >  Waelkson,
>  >
>  >  vc notou alguma diferença entre a mudaça do ossec de ipfw para pf ? o
>  >  snort_inline tambem pode ser usado um pf ??
>  >
>  >
>  >
>  >  Em 21/02/08, Welkson Renny de Medeiros<[EMAIL PROTECTED]>
>  >  escreveu:
>  >  > Bom dia Tiago!
>  >  >
>  >  >
>  >  >  Será o "artigo do ano" rsrsrs...
>  >  >
>  >  >  snort_inline nunca usei... uso o ossec... mas não trato p2p... só
>  > outros
>  >  >  tipos de ataque (web, sql, etc)... usava o ossec integrado ao ipfw,
>  > agora
>  >  >  estou usando com pf.
>  >  >
>  >  >
>  >  >
>  >  >  --
>  >  >  Welkson Renny de Medeiros
>  >  >  Focus Automação Comercial
>  >  >  Desenvolvimento / Gerência de Redes
>  >  >  [EMAIL PROTECTED]
>  >  >
>  >  >
>  >  >
>  >  > 

Re: [FUG-BR] RES: Filtro L7

[Welkson Renny de Medeiros]

Márcio,

Os scripts já vem na instalação do OSSEC (para vários firewalls), veja:

[EMAIL PROTECTED]:/var/ossec/active-response/bin] # pwd
/var/ossec/active-response/bin

[EMAIL PROTECTED]:/var/ossec/active-response/bin] # ls
default-firewall-drop.sh*  firewall-drop.sh*  ipfw.sh*  pf.sh*
disable-account.sh*host-deny.sh*  ipfw_mac.sh*  route-null.sh*

É só copiar o pf.sh por cima do firewall-drop.sh... que é o script usado por 
padrão no ossec... ou alterar o parâmetro firewall-drop no ossec.conf 
(/var/ossec/etc)

Fora o firewall, o ossec também bloqueia via arquivo hosts.deny... eu não 
gostei disso e comentei o script... prefiro usar o bloqueio só pelo firewall 
mesmo.

Abraço,


-- 
Welkson Renny de Medeiros
Focus Automação Comercial
Desenvolvimento / Gerência de Redes
[EMAIL PROTECTED]



  Powered by 

   (__)
\\\'',)
  \/  \ ^
  .\._/_)

  www.FreeBSD.org

- Original Message - 
From: "mantunes" <[EMAIL PROTECTED]>
To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)" 

Sent: Thursday, February 21, 2008 2:50 PM
Subject: Re: [FUG-BR] RES: Filtro L7


Welkson

vc pode me passar esse script.. tenho interesse de implementar essa solução.

agradeço muito..

obrigado

Em 21/02/08, Welkson Renny de Medeiros<[EMAIL PROTECTED]> 
escreveu:
> Bom tarde Márcio!
>
>
>  Do snort_inline não posso comentar, nunca usei... sobre o firewall, eu já
>  havia migrado todas as regras de bloqueio para o pf, deixei o ipfw
>  exclusivamente para controle de banda... com isso senti necessidade de
>  também migrar o ossec para pf... o Daniel Cid (ossec) já havia escrito o
>  shell script com regras para pf, testei e está funcionando muito bem... 
> por
>  dia geralmente são bloqueados +- uns 300 ips...
>
>  Agora pouco reiniciei a máquina, olha só quantos ips já foram bloqueados:
>
>  [EMAIL PROTECTED]:~] # mostra-bloqueados
>  IPs bloqueados:   32
>
>  [EMAIL PROTECTED]:~] # cat /bin/mostra-bloqueados
>  printf "IPs bloqueados: $(pfctl -t ossec -T show | wc -l) \n\n"
>
>  Para acompanhar os bloqueios eu uso o BASE + PostgreSQL.
>
>  É isso, abraço!!!
>
>
>
>  --
>
> Welkson Renny de Medeiros
>  Focus Automação Comercial
>  Desenvolvimento / Gerência de Redes
>  [EMAIL PROTECTED]
>
>
>
>   Powered by 
>
>(__)
> \\\'',)
>   \/  \ ^
>   .\._/_)
>
>   www.FreeBSD.org
>
>  ----- Original Message -----
>  From: "mantunes" <[EMAIL PROTECTED]>
>  To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
>  
>
> Sent: Thursday, February 21, 2008 11:26 AM
>  Subject: Re: [FUG-BR] RES: Filtro L7
>
>
>  Waelkson,
>
>  vc notou alguma diferença entre a mudaça do ossec de ipfw para pf ? o
>  snort_inline tambem pode ser usado um pf ??
>
>
>
>  Em 21/02/08, Welkson Renny de Medeiros<[EMAIL PROTECTED]>
>  escreveu:
>  > Bom dia Tiago!
>  >
>  >
>  >  Será o "artigo do ano" rsrsrs...
>  >
>  >  snort_inline nunca usei... uso o ossec... mas não trato p2p... só 
> outros
>  >  tipos de ataque (web, sql, etc)... usava o ossec integrado ao ipfw, 
> agora
>  >  estou usando com pf.
>  >
>  >
>  >
>  >  --
>  >  Welkson Renny de Medeiros
>  >  Focus Automação Comercial
>  >  Desenvolvimento / Gerência de Redes
>  >  [EMAIL PROTECTED]
>  >
>  >
>  >
>  >   Powered by 
>  >
>  >(__)
>  >                     \\\'',)
>  >   \/  \ ^
>  >   .\._/_)
>  >
>  >   www.FreeBSD.org
>  >
>  >
>  >  - Original Message -
>  >  From: "mantunes" <[EMAIL PROTECTED]>
>  >  To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
>  >  
>  >
>  > Sent: Thursday, February 21, 2008 10:25 AM
>  >  Subject: Re: [FUG-BR] RES: Filtro L7
>  >
>  >
>  >
>  > isso tiago, será de grande utilidade essa solução para lista.
>  >
>  >  Estamos esperando.
>  >
>  >  Em 21/02/08, Tiago Isic Brasil<[EMAIL PROTECTED]>

Re: [FUG-BR] RES: Filtro L7

[mantunes]

Welkson

vc pode me passar esse script.. tenho interesse de implementar essa solução.

agradeço muito..

obrigado

Em 21/02/08, Welkson Renny de Medeiros<[EMAIL PROTECTED]> escreveu:
> Bom tarde Márcio!
>
>
>  Do snort_inline não posso comentar, nunca usei... sobre o firewall, eu já
>  havia migrado todas as regras de bloqueio para o pf, deixei o ipfw
>  exclusivamente para controle de banda... com isso senti necessidade de
>  também migrar o ossec para pf... o Daniel Cid (ossec) já havia escrito o
>  shell script com regras para pf, testei e está funcionando muito bem... por
>  dia geralmente são bloqueados +- uns 300 ips...
>
>  Agora pouco reiniciei a máquina, olha só quantos ips já foram bloqueados:
>
>  [EMAIL PROTECTED]:~] # mostra-bloqueados
>  IPs bloqueados:   32
>
>  [EMAIL PROTECTED]:~] # cat /bin/mostra-bloqueados
>  printf "IPs bloqueados: $(pfctl -t ossec -T show | wc -l) \n\n"
>
>  Para acompanhar os bloqueios eu uso o BASE + PostgreSQL.
>
>  É isso, abraço!!!
>
>
>
>  --
>
> Welkson Renny de Medeiros
>  Focus Automação Comercial
>  Desenvolvimento / Gerência de Redes
>  [EMAIL PROTECTED]
>
>
>
>   Powered by 
>
>(__)
> \\\'',)
>   \/  \ ^
>   .\._/_)
>
>   www.FreeBSD.org
>
>  - Original Message -
>  From: "mantunes" <[EMAIL PROTECTED]>
>  To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
>  
>
> Sent: Thursday, February 21, 2008 11:26 AM
>  Subject: Re: [FUG-BR] RES: Filtro L7
>
>
>  Waelkson,
>
>  vc notou alguma diferença entre a mudaça do ossec de ipfw para pf ? o
>  snort_inline tambem pode ser usado um pf ??
>
>
>
>  Em 21/02/08, Welkson Renny de Medeiros<[EMAIL PROTECTED]>
>  escreveu:
>  > Bom dia Tiago!
>  >
>  >
>  >  Será o "artigo do ano" rsrsrs...
>  >
>  >  snort_inline nunca usei... uso o ossec... mas não trato p2p... só outros
>  >  tipos de ataque (web, sql, etc)... usava o ossec integrado ao ipfw, agora
>  >  estou usando com pf.
>  >
>  >
>  >
>  >  --
>  >  Welkson Renny de Medeiros
>  >  Focus Automação Comercial
>  >  Desenvolvimento / Gerência de Redes
>  >  [EMAIL PROTECTED]
>  >
>  >
>  >
>  >   Powered by 
>  >
>  >(__)
>  > \\\'',)
>  >                   \/  \ ^
>  >   .\._/_)
>  >
>  >   www.FreeBSD.org
>  >
>  >
>  >  - Original Message -
>  >  From: "mantunes" <[EMAIL PROTECTED]>
>  >  To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
>  >  
>  >
>  > Sent: Thursday, February 21, 2008 10:25 AM
>  >  Subject: Re: [FUG-BR] RES: Filtro L7
>  >
>  >
>  >
>  > isso tiago, será de grande utilidade essa solução para lista.
>  >
>  >  Estamos esperando.
>  >
>  >  Em 21/02/08, Tiago Isic Brasil<[EMAIL PROTECTED]> escreveu:
>  >  > Bom dia!
>  >  >
>  >  >  Lista, seguinte com a ajuda do sr. Patrick consegui jogar o trafego
>  >  >  identificado como p2p pelo snort_inline para as regras do ipfw. Valeu
>  >  >  Patrick, agora vou começar a customizar as rules do snort para ver se
>  >  >  pego mais do que o Emule no trafego.
>  >  >
>  >  >
>  >  >  Prometo montar um tutorial descrevendo o processo de bloqueio do p2p
>  > via
>  >  >  ipfw com snort_inline.
>  >  >
>  >  >
>  >  >  att
>  >  >  Tiago ISIC Brasil
>  >  >
>  >  >
>  >  >
>  >  >
>  >  >
>  >  >  Em Qua, 2008-02-20 às 17:49 -0300, Patrick Tracanelli escreveu:
>  >  >
>  >  > > Seguinte, numa olhada rapida esta tudo OK entao vamos direto a causa
>  >  >  > mais provavel, as regras
>  >  >  >
>  >  >  > include $RULE_PATH/p2p.rules
>  >  >  > include $RULE_PATH/bleeding-p2p.rules
>  >  >  >
>  >  >  > Estao modificadas pra ter a ação reinject?
>  >  >  >
>  >  >  > Por exemlo, minhas regras de filtro do eDonkey/eMule da vida:
>  >  >  >
>  >  >  > reinject tcp $EXTERNAL_NET 1024

Re: [FUG-BR] RES: Filtro L7

[Welkson Renny de Medeiros]

Bom tarde Márcio!


Do snort_inline não posso comentar, nunca usei... sobre o firewall, eu já 
havia migrado todas as regras de bloqueio para o pf, deixei o ipfw 
exclusivamente para controle de banda... com isso senti necessidade de 
também migrar o ossec para pf... o Daniel Cid (ossec) já havia escrito o 
shell script com regras para pf, testei e está funcionando muito bem... por 
dia geralmente são bloqueados +- uns 300 ips...

Agora pouco reiniciei a máquina, olha só quantos ips já foram bloqueados:

[EMAIL PROTECTED]:~] # mostra-bloqueados
IPs bloqueados:   32

[EMAIL PROTECTED]:~] # cat /bin/mostra-bloqueados
printf "IPs bloqueados: $(pfctl -t ossec -T show | wc -l) \n\n"

Para acompanhar os bloqueios eu uso o BASE + PostgreSQL.

É isso, abraço!!!


-- 
Welkson Renny de Medeiros
Focus Automação Comercial
Desenvolvimento / Gerência de Redes
[EMAIL PROTECTED]



  Powered by 

   (__)
\\\'',)
  \/  \ ^
  .\._/_)

  www.FreeBSD.org

- Original Message - 
From: "mantunes" <[EMAIL PROTECTED]>
To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)" 

Sent: Thursday, February 21, 2008 11:26 AM
Subject: Re: [FUG-BR] RES: Filtro L7


Waelkson,

vc notou alguma diferença entre a mudaça do ossec de ipfw para pf ? o
snort_inline tambem pode ser usado um pf ??



Em 21/02/08, Welkson Renny de Medeiros<[EMAIL PROTECTED]> 
escreveu:
> Bom dia Tiago!
>
>
>  Será o "artigo do ano" rsrsrs...
>
>  snort_inline nunca usei... uso o ossec... mas não trato p2p... só outros
>  tipos de ataque (web, sql, etc)... usava o ossec integrado ao ipfw, agora
>  estou usando com pf.
>
>
>
>  --
>  Welkson Renny de Medeiros
>  Focus Automação Comercial
>  Desenvolvimento / Gerência de Redes
>  [EMAIL PROTECTED]
>
>
>
>   Powered by 
>
>(__)
> \\\'',)
>   \/  \ ^
>   .\._/_)
>
>   www.FreeBSD.org
>
>
>  - Original Message -
>  From: "mantunes" <[EMAIL PROTECTED]>
>  To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
>  
>
> Sent: Thursday, February 21, 2008 10:25 AM
>  Subject: Re: [FUG-BR] RES: Filtro L7
>
>
>
> isso tiago, será de grande utilidade essa solução para lista.
>
>  Estamos esperando.
>
>  Em 21/02/08, Tiago Isic Brasil<[EMAIL PROTECTED]> escreveu:
>  > Bom dia!
>  >
>  >  Lista, seguinte com a ajuda do sr. Patrick consegui jogar o trafego
>  >  identificado como p2p pelo snort_inline para as regras do ipfw. Valeu
>  >  Patrick, agora vou começar a customizar as rules do snort para ver se
>  >  pego mais do que o Emule no trafego.
>  >
>  >
>  >  Prometo montar um tutorial descrevendo o processo de bloqueio do p2p 
> via
>  >  ipfw com snort_inline.
>  >
>  >
>  >  att
>  >  Tiago ISIC Brasil
>  >
>  >
>  >
>  >
>  >
>  >  Em Qua, 2008-02-20 às 17:49 -0300, Patrick Tracanelli escreveu:
>  >
>  > > Seguinte, numa olhada rapida esta tudo OK entao vamos direto a causa
>  >  > mais provavel, as regras
>  >  >
>  >  > include $RULE_PATH/p2p.rules
>  >  > include $RULE_PATH/bleeding-p2p.rules
>  >  >
>  >  > Estao modificadas pra ter a ação reinject?
>  >  >
>  >  > Por exemlo, minhas regras de filtro do eDonkey/eMule da vida:
>  >  >
>  >  > reinject tcp $EXTERNAL_NET 1024:65535 -> $HOME_NET 4660:4799
>  >  > (msg:"FBSDBR P2P Edonkey Server Status"; flow:established; dsize:14;
>  >  > content:"|e3 09 00 00 00 34|"; depth:6; classtype:policy-violation;
>  >  > reference:url,www.giac.org/certified_professionals/practicals/gcih
>  >  >
>  >  > /0446.php; sid:3003324; rev:1;)
>  >  >
>  >  > Note o reinject no inicio da regra.
>  >  >
>  >  > Faca um sed pra trocar de todas as suas regras.
>  >  >
>  >  >
>  >  >
>  >  > Tiago Isic Brasil escreveu:
>  >  > > Boa tarde!
>  >  > >
>  >  > > Sr. Patrick, estou testando o snort_inline + ipfw como descrito no
>  > seu
>  >  > > email de resposta a lista referente ao bloqueio do P2P , só que 
> não
>  >  > > estou tendo muito sucesso.

Re: [FUG-BR] RES: Filtro L7

[Patrick Tracanelli]

Tiago Isic Brasil escreveu:
> Bom dia!

Ola Tiago,

> 
> Lista, seguinte com a ajuda do sr. Patrick consegui jogar o trafego
> identificado como p2p pelo snort_inline para as regras do ipfw. Valeu
> Patrick, agora vou começar a customizar as rules do snort para ver se
> pego mais do que o Emule no trafego.

Voce vai conseguir pegar literalmente qualquer coisa :) Se as 
assinaturas do snort nao existir voce faz as suas hehe.

> Prometo montar um tutorial descrevendo o processo de bloqueio do p2p via
> ipfw com snort_inline.

Vai ser muito, muito proveitoso. Nem sei quantas pessoas ja solicitaram 
isso, mas o melhor q eu tive tempo de fazer foi aquele e-mail hehe.

-- 
Patrick Tracanelli

FreeBSD Brasil LTDA.
Tel.: (31) 3516-0800
[EMAIL PROTECTED]
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] RES: Filtro L7

[mantunes]

Waelkson,

vc notou alguma diferença entre a mudaça do ossec de ipfw para pf ? o
snort_inline tambem pode ser usado um pf ??



Em 21/02/08, Welkson Renny de Medeiros<[EMAIL PROTECTED]> escreveu:
> Bom dia Tiago!
>
>
>  Será o "artigo do ano" rsrsrs...
>
>  snort_inline nunca usei... uso o ossec... mas não trato p2p... só outros
>  tipos de ataque (web, sql, etc)... usava o ossec integrado ao ipfw, agora
>  estou usando com pf.
>
>
>
>  --
>  Welkson Renny de Medeiros
>  Focus Automação Comercial
>  Desenvolvimento / Gerência de Redes
>  [EMAIL PROTECTED]
>
>
>
>   Powered by 
>
>(__)
> \\\'',)
>   \/  \ ^
>   .\._/_)
>
>   www.FreeBSD.org
>
>
>  - Original Message -
>  From: "mantunes" <[EMAIL PROTECTED]>
>  To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
>  
>
> Sent: Thursday, February 21, 2008 10:25 AM
>  Subject: Re: [FUG-BR] RES: Filtro L7
>
>
>
> isso tiago, será de grande utilidade essa solução para lista.
>
>  Estamos esperando.
>
>  Em 21/02/08, Tiago Isic Brasil<[EMAIL PROTECTED]> escreveu:
>  > Bom dia!
>  >
>  >  Lista, seguinte com a ajuda do sr. Patrick consegui jogar o trafego
>  >  identificado como p2p pelo snort_inline para as regras do ipfw. Valeu
>  >  Patrick, agora vou começar a customizar as rules do snort para ver se
>  >  pego mais do que o Emule no trafego.
>  >
>  >
>  >  Prometo montar um tutorial descrevendo o processo de bloqueio do p2p via
>  >  ipfw com snort_inline.
>  >
>  >
>  >  att
>  >  Tiago ISIC Brasil
>  >
>  >
>  >
>  >
>  >
>  >  Em Qua, 2008-02-20 às 17:49 -0300, Patrick Tracanelli escreveu:
>  >
>  > > Seguinte, numa olhada rapida esta tudo OK entao vamos direto a causa
>  >  > mais provavel, as regras
>  >  >
>  >  > include $RULE_PATH/p2p.rules
>  >  > include $RULE_PATH/bleeding-p2p.rules
>  >  >
>  >  > Estao modificadas pra ter a ação reinject?
>  >  >
>  >  > Por exemlo, minhas regras de filtro do eDonkey/eMule da vida:
>  >  >
>  >  > reinject tcp $EXTERNAL_NET 1024:65535 -> $HOME_NET 4660:4799
>  >  > (msg:"FBSDBR P2P Edonkey Server Status"; flow:established; dsize:14;
>  >  > content:"|e3 09 00 00 00 34|"; depth:6; classtype:policy-violation;
>  >  > reference:url,www.giac.org/certified_professionals/practicals/gcih
>  >  >
>  >  > /0446.php; sid:3003324; rev:1;)
>  >  >
>  >  > Note o reinject no inicio da regra.
>  >  >
>  >  > Faca um sed pra trocar de todas as suas regras.
>  >  >
>  >  >
>  >  >
>  >  > Tiago Isic Brasil escreveu:
>  >  > > Boa tarde!
>  >  > >
>  >  > > Sr. Patrick, estou testando o snort_inline + ipfw como descrito no
>  > seu
>  >  > > email de resposta a lista referente ao bloqueio do P2P , só que não
>  >  > > estou tendo muito sucesso.
>  >  > >
>  >  > > Eu queria só que você checasse onde pode estar errado e me dar um
>  > toque
>  >  > > no que pode-se ser realizado.
>  >  > > Quando concluir os testes poderei descrever para a lista o processo
>  > da
>  >  > > instalação e configuração dos arquivos.
>  >  > >
>  >  > > Abaixo está minhas regras de firewall
>  >  > >
>  >  > >
>  >  > > Lembrando que está sendo realizado NAT com natd
>  >  > >
>  > ###
>  >  > > cmd="ipfw -q add"
>  >  > >
>  >  > > #Interfaces de rede
>  >  > > int1="xl0"
>  >  > > ext1="fxp0"
>  >  > > skip="skipto 900"
>  >  > > network1="192.168.90.0/24"
>  >  > >
>  >  > > #Libera trafego de qualquer lugar para lo0
>  >  > > $cmd 11 allow ip from any to any via lo0
>  >  > >
>  >  > > #Bloqueia trafego de qualquer lugar para 127.0.0.0/8
>  >  > > $cmd 12 deny ip from any to 127.0.0.0/8
>  >  > >
>  >  > > #Bloqueia trafego de 127.0.0.0/8 para qualqier lugar
>  >  > > $cmd 13 deny ip from 127.0.0.0/8 to any
>  >  > >
>  >  > > 

Re: [FUG-BR] RES: Filtro L7

[Welkson Renny de Medeiros]

Bom dia Tiago!


Será o "artigo do ano" rsrsrs...

snort_inline nunca usei... uso o ossec... mas não trato p2p... só outros 
tipos de ataque (web, sql, etc)... usava o ossec integrado ao ipfw, agora 
estou usando com pf.



-- 
Welkson Renny de Medeiros
Focus Automação Comercial
Desenvolvimento / Gerência de Redes
[EMAIL PROTECTED]



  Powered by 

   (__)
\\\'',)
  \/  \ ^
  .\._/_)

  www.FreeBSD.org

- Original Message - 
From: "mantunes" <[EMAIL PROTECTED]>
To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)" 

Sent: Thursday, February 21, 2008 10:25 AM
Subject: Re: [FUG-BR] RES: Filtro L7


isso tiago, será de grande utilidade essa solução para lista.

Estamos esperando.

Em 21/02/08, Tiago Isic Brasil<[EMAIL PROTECTED]> escreveu:
> Bom dia!
>
>  Lista, seguinte com a ajuda do sr. Patrick consegui jogar o trafego
>  identificado como p2p pelo snort_inline para as regras do ipfw. Valeu
>  Patrick, agora vou começar a customizar as rules do snort para ver se
>  pego mais do que o Emule no trafego.
>
>
>  Prometo montar um tutorial descrevendo o processo de bloqueio do p2p via
>  ipfw com snort_inline.
>
>
>  att
>  Tiago ISIC Brasil
>
>
>
>
>
>  Em Qua, 2008-02-20 às 17:49 -0300, Patrick Tracanelli escreveu:
>
> > Seguinte, numa olhada rapida esta tudo OK entao vamos direto a causa
>  > mais provavel, as regras
>  >
>  > include $RULE_PATH/p2p.rules
>  > include $RULE_PATH/bleeding-p2p.rules
>  >
>  > Estao modificadas pra ter a ação reinject?
>  >
>  > Por exemlo, minhas regras de filtro do eDonkey/eMule da vida:
>  >
>  > reinject tcp $EXTERNAL_NET 1024:65535 -> $HOME_NET 4660:4799
>  > (msg:"FBSDBR P2P Edonkey Server Status"; flow:established; dsize:14;
>  > content:"|e3 09 00 00 00 34|"; depth:6; classtype:policy-violation;
>  > reference:url,www.giac.org/certified_professionals/practicals/gcih
>  >
>  > /0446.php; sid:3003324; rev:1;)
>  >
>  > Note o reinject no inicio da regra.
>  >
>  > Faca um sed pra trocar de todas as suas regras.
>  >
>  >
>  >
>  > Tiago Isic Brasil escreveu:
>  > > Boa tarde!
>  > >
>  > > Sr. Patrick, estou testando o snort_inline + ipfw como descrito no 
> seu
>  > > email de resposta a lista referente ao bloqueio do P2P , só que não
>  > > estou tendo muito sucesso.
>  > >
>  > > Eu queria só que você checasse onde pode estar errado e me dar um 
> toque
>  > > no que pode-se ser realizado.
>  > > Quando concluir os testes poderei descrever para a lista o processo 
> da
>  > > instalação e configuração dos arquivos.
>  > >
>  > > Abaixo está minhas regras de firewall
>  > >
>  > >
>  > > Lembrando que está sendo realizado NAT com natd
>  > > 
> ###
>  > > cmd="ipfw -q add"
>  > >
>  > > #Interfaces de rede
>  > > int1="xl0"
>  > > ext1="fxp0"
>  > > skip="skipto 900"
>  > > network1="192.168.90.0/24"
>  > >
>  > > #Libera trafego de qualquer lugar para lo0
>  > > $cmd 11 allow ip from any to any via lo0
>  > >
>  > > #Bloqueia trafego de qualquer lugar para 127.0.0.0/8
>  > > $cmd 12 deny ip from any to 127.0.0.0/8
>  > >
>  > > #Bloqueia trafego de 127.0.0.0/8 para qualqier lugar
>  > > $cmd 13 deny ip from 127.0.0.0/8 to any
>  > >
>  > > #Aqui está a regra pelo que entendi no email do Patrick,  que é 
> enviar
>  > > tudo que esteja tagged 30 para a regra de nr. 65500
>  > > $cmd 14 skipto 65500 log all from any to any tagged 30
>  > >
>  > > #Libera o serviço SSH
>  > > $cmd 16 allow tcp from any to me 22 in via $ext1
>  > >
>  > > #Conexoes já estabilizadas vao para a regra de divert
>  > > $cmd 103 $skip tcp from any to any established
>  > >
>  > > #Aqui está a minha duvida. A regra 900 recebe o trafego, blz, mas se 
> eu
>  > > omitir ela e apenas usar a regra nr 901 não funciona nada.
>  > > #Quando inicio o snort ele abre o socket divert na porta 8000
>  > > $cmd 900  divert 8668 log ip4 from any to any
>  > > $cmd 901 divert 8000 log all from any to any
>  > >
>  > > #Permite 

Re: [FUG-BR] RES: Filtro L7

[mantunes]

isso tiago, será de grande utilidade essa solução para lista.

Estamos esperando.

Em 21/02/08, Tiago Isic Brasil<[EMAIL PROTECTED]> escreveu:
> Bom dia!
>
>  Lista, seguinte com a ajuda do sr. Patrick consegui jogar o trafego
>  identificado como p2p pelo snort_inline para as regras do ipfw. Valeu
>  Patrick, agora vou começar a customizar as rules do snort para ver se
>  pego mais do que o Emule no trafego.
>
>
>  Prometo montar um tutorial descrevendo o processo de bloqueio do p2p via
>  ipfw com snort_inline.
>
>
>  att
>  Tiago ISIC Brasil
>
>
>
>
>
>  Em Qua, 2008-02-20 às 17:49 -0300, Patrick Tracanelli escreveu:
>
> > Seguinte, numa olhada rapida esta tudo OK entao vamos direto a causa
>  > mais provavel, as regras
>  >
>  > include $RULE_PATH/p2p.rules
>  > include $RULE_PATH/bleeding-p2p.rules
>  >
>  > Estao modificadas pra ter a ação reinject?
>  >
>  > Por exemlo, minhas regras de filtro do eDonkey/eMule da vida:
>  >
>  > reinject tcp $EXTERNAL_NET 1024:65535 -> $HOME_NET 4660:4799
>  > (msg:"FBSDBR P2P Edonkey Server Status"; flow:established; dsize:14;
>  > content:"|e3 09 00 00 00 34|"; depth:6; classtype:policy-violation;
>  > reference:url,www.giac.org/certified_professionals/practicals/gcih
>  >
>  > /0446.php; sid:3003324; rev:1;)
>  >
>  > Note o reinject no inicio da regra.
>  >
>  > Faca um sed pra trocar de todas as suas regras.
>  >
>  >
>  >
>  > Tiago Isic Brasil escreveu:
>  > > Boa tarde!
>  > >
>  > > Sr. Patrick, estou testando o snort_inline + ipfw como descrito no seu
>  > > email de resposta a lista referente ao bloqueio do P2P , só que não
>  > > estou tendo muito sucesso.
>  > >
>  > > Eu queria só que você checasse onde pode estar errado e me dar um toque
>  > > no que pode-se ser realizado.
>  > > Quando concluir os testes poderei descrever para a lista o processo da
>  > > instalação e configuração dos arquivos.
>  > >
>  > > Abaixo está minhas regras de firewall
>  > >
>  > >
>  > > Lembrando que está sendo realizado NAT com natd
>  > > ###
>  > > cmd="ipfw -q add"
>  > >
>  > > #Interfaces de rede
>  > > int1="xl0"
>  > > ext1="fxp0"
>  > > skip="skipto 900"
>  > > network1="192.168.90.0/24"
>  > >
>  > > #Libera trafego de qualquer lugar para lo0
>  > > $cmd 11 allow ip from any to any via lo0
>  > >
>  > > #Bloqueia trafego de qualquer lugar para 127.0.0.0/8
>  > > $cmd 12 deny ip from any to 127.0.0.0/8
>  > >
>  > > #Bloqueia trafego de 127.0.0.0/8 para qualqier lugar
>  > > $cmd 13 deny ip from 127.0.0.0/8 to any
>  > >
>  > > #Aqui está a regra pelo que entendi no email do Patrick,  que é enviar
>  > > tudo que esteja tagged 30 para a regra de nr. 65500
>  > > $cmd 14 skipto 65500 log all from any to any tagged 30
>  > >
>  > > #Libera o serviço SSH
>  > > $cmd 16 allow tcp from any to me 22 in via $ext1
>  > >
>  > > #Conexoes já estabilizadas vao para a regra de divert
>  > > $cmd 103 $skip tcp from any to any established
>  > >
>  > > #Aqui está a minha duvida. A regra 900 recebe o trafego, blz, mas se eu
>  > > omitir ela e apenas usar a regra nr 901 não funciona nada.
>  > > #Quando inicio o snort ele abre o socket divert na porta 8000
>  > > $cmd 900  divert 8668 log ip4 from any to any
>  > > $cmd 901 divert 8000 log all from any to any
>  > >
>  > > #Permite trafego de qualquer lugar para qualquer lugar.
>  > > $cmd 1000 allow log ip from any to any
>  > >
>  > >
>  > > #Como descrito no email do Patrick, o que for identificado pelo
>  > > snort_inline, vai para a regra 65500
>  > > $cmd 65499 deny log all from any to any
>  > > $cmd 65500 count tag 30 log all from any to any keep-state
>  > >
>  > > #Bloqueia qualquer trafego de qualquer lugar
>  > > $cmd 65534 deny log ip from any to any
>  > > 
>  > >
>  > >
>  > > Meu snort_inline.conf
>  > > ###
>  > >
>  > > #Redes
>  > >
>  > > var HOME_NET [192.168.90.0/24]
>  > >
>  > > var HONEYNET any
>  > > var EXTERNAL_NET any
>  > > var SMTP_SERVERS any
>  > > var TELNET_SERVERS any
>  > > var HTTP_SERVERS any
>  > > var SQL_SERVERS any
>  > > var HTTP_PORTS 80
>  > > var SHELLCODE_PORTS !80
>  > > var DNS_SERVERS any
>  > >
>  > > #Manda para o ipfw
>  > >
>  > > config ipfw_reinject_rule: 65500
>  > >
>  > > var RULE_PATH /usr/local/share/snort_inline/rules
>  > >
>  > > preprocessor flow: stats_interval 0 hash 2
>  > > output alert_fast: inline_fast
>  > >
>  > > include /usr/local/share/snort_inline/classification.config
>  > > include /usr/local/share/snort_inline/reference.config
>  > >
>  > >
>  > > include $RULE_PATH/p2p.rules
>  > > include $RULE_PATH/bleeding-p2p.rules
>  > >
>  > > 
> ###
>  > >
>  > > O que está acontencendo é o seguinte, no log do snort apareceu a
>  > > identificaçao do trafego dos testes que re

Re: [FUG-BR] RES: Filtro L7

[Tiago Isic Brasil]

Bom dia!

Lista, seguinte com a ajuda do sr. Patrick consegui jogar o trafego
identificado como p2p pelo snort_inline para as regras do ipfw. Valeu
Patrick, agora vou começar a customizar as rules do snort para ver se
pego mais do que o Emule no trafego.


Prometo montar um tutorial descrevendo o processo de bloqueio do p2p via
ipfw com snort_inline.


att
Tiago ISIC Brasil





Em Qua, 2008-02-20 às 17:49 -0300, Patrick Tracanelli escreveu:
> Seguinte, numa olhada rapida esta tudo OK entao vamos direto a causa 
> mais provavel, as regras
> 
> include $RULE_PATH/p2p.rules
> include $RULE_PATH/bleeding-p2p.rules
> 
> Estao modificadas pra ter a ação reinject?
> 
> Por exemlo, minhas regras de filtro do eDonkey/eMule da vida:
> 
> reinject tcp $EXTERNAL_NET 1024:65535 -> $HOME_NET 4660:4799 
> (msg:"FBSDBR P2P Edonkey Server Status"; flow:established; dsize:14; 
> content:"|e3 09 00 00 00 34|"; depth:6; classtype:policy-violation; 
> reference:url,www.giac.org/certified_professionals/practicals/gcih 
> 
> /0446.php; sid:3003324; rev:1;)
> 
> Note o reinject no inicio da regra.
> 
> Faca um sed pra trocar de todas as suas regras.
> 
> 
> 
> Tiago Isic Brasil escreveu:
> > Boa tarde!
> > 
> > Sr. Patrick, estou testando o snort_inline + ipfw como descrito no seu
> > email de resposta a lista referente ao bloqueio do P2P , só que não
> > estou tendo muito sucesso.
> > 
> > Eu queria só que você checasse onde pode estar errado e me dar um toque
> > no que pode-se ser realizado.
> > Quando concluir os testes poderei descrever para a lista o processo da
> > instalação e configuração dos arquivos.
> > 
> > Abaixo está minhas regras de firewall
> > 
> > 
> > Lembrando que está sendo realizado NAT com natd
> > ###
> > cmd="ipfw -q add"
> > 
> > #Interfaces de rede
> > int1="xl0"
> > ext1="fxp0"
> > skip="skipto 900"
> > network1="192.168.90.0/24"
> > 
> > #Libera trafego de qualquer lugar para lo0
> > $cmd 11 allow ip from any to any via lo0
> > 
> > #Bloqueia trafego de qualquer lugar para 127.0.0.0/8
> > $cmd 12 deny ip from any to 127.0.0.0/8
> > 
> > #Bloqueia trafego de 127.0.0.0/8 para qualqier lugar
> > $cmd 13 deny ip from 127.0.0.0/8 to any
> > 
> > #Aqui está a regra pelo que entendi no email do Patrick,  que é enviar
> > tudo que esteja tagged 30 para a regra de nr. 65500
> > $cmd 14 skipto 65500 log all from any to any tagged 30
> > 
> > #Libera o serviço SSH
> > $cmd 16 allow tcp from any to me 22 in via $ext1
> > 
> > #Conexoes já estabilizadas vao para a regra de divert 
> > $cmd 103 $skip tcp from any to any established
> > 
> > #Aqui está a minha duvida. A regra 900 recebe o trafego, blz, mas se eu
> > omitir ela e apenas usar a regra nr 901 não funciona nada.
> > #Quando inicio o snort ele abre o socket divert na porta 8000
> > $cmd 900  divert 8668 log ip4 from any to any
> > $cmd 901 divert 8000 log all from any to any
> > 
> > #Permite trafego de qualquer lugar para qualquer lugar.
> > $cmd 1000 allow log ip from any to any
> > 
> > 
> > #Como descrito no email do Patrick, o que for identificado pelo
> > snort_inline, vai para a regra 65500
> > $cmd 65499 deny log all from any to any
> > $cmd 65500 count tag 30 log all from any to any keep-state
> > 
> > #Bloqueia qualquer trafego de qualquer lugar
> > $cmd 65534 deny log ip from any to any
> > 
> > 
> > 
> > Meu snort_inline.conf
> > ###
> > 
> > #Redes
> > 
> > var HOME_NET [192.168.90.0/24]
> > 
> > var HONEYNET any
> > var EXTERNAL_NET any
> > var SMTP_SERVERS any
> > var TELNET_SERVERS any
> > var HTTP_SERVERS any
> > var SQL_SERVERS any
> > var HTTP_PORTS 80
> > var SHELLCODE_PORTS !80
> > var DNS_SERVERS any
> > 
> > #Manda para o ipfw
> > 
> > config ipfw_reinject_rule: 65500
> > 
> > var RULE_PATH /usr/local/share/snort_inline/rules
> > 
> > preprocessor flow: stats_interval 0 hash 2
> > output alert_fast: inline_fast
> > 
> > include /usr/local/share/snort_inline/classification.config
> > include /usr/local/share/snort_inline/reference.config
> > 
> > 
> > include $RULE_PATH/p2p.rules
> > include $RULE_PATH/bleeding-p2p.rules
> > 
> > ###
> > 
> > O que está acontencendo é o seguinte, no log do snort apareceu a
> > identificaçao do trafego dos testes que realizei com os programas mais
> > conhecidos como Emule,DreMule.
> > Mas nada foi enviado para a regra:
> > 
> > #ipfw show
> > 
> > 000110   0 allow ip from any to any via lo0
> > 000120   0 deny ip from any to 127.0.0.0/8
> > 000130   0 deny ip from 127.0.0.0/8 to any
> > 000140   0 skipto 65500 log logamount 100 ip from any to any
> > tagged 30
> > 000202 156 allow icmp from any to any
> > 00103 4772 2137400 skipto 900 tcp from any to any established
> > 00900 5622

Re: [FUG-BR] RES: Filtro L7

[Patrick Tracanelli]

Seguinte, numa olhada rapida esta tudo OK entao vamos direto a causa 
mais provavel, as regras

include $RULE_PATH/p2p.rules
include $RULE_PATH/bleeding-p2p.rules

Estao modificadas pra ter a ação reinject?

Por exemlo, minhas regras de filtro do eDonkey/eMule da vida:

reinject tcp $EXTERNAL_NET 1024:65535 -> $HOME_NET 4660:4799 
(msg:"FBSDBR P2P Edonkey Server Status"; flow:established; dsize:14; 
content:"|e3 09 00 00 00 34|"; depth:6; classtype:policy-violation; 
reference:url,www.giac.org/certified_professionals/practicals/gcih 

/0446.php; sid:3003324; rev:1;)

Note o reinject no inicio da regra.

Faca um sed pra trocar de todas as suas regras.



Tiago Isic Brasil escreveu:
> Boa tarde!
> 
> Sr. Patrick, estou testando o snort_inline + ipfw como descrito no seu
> email de resposta a lista referente ao bloqueio do P2P , só que não
> estou tendo muito sucesso.
> 
> Eu queria só que você checasse onde pode estar errado e me dar um toque
> no que pode-se ser realizado.
> Quando concluir os testes poderei descrever para a lista o processo da
> instalação e configuração dos arquivos.
> 
> Abaixo está minhas regras de firewall
> 
> 
> Lembrando que está sendo realizado NAT com natd
> ###
> cmd="ipfw -q add"
> 
> #Interfaces de rede
> int1="xl0"
> ext1="fxp0"
> skip="skipto 900"
> network1="192.168.90.0/24"
> 
> #Libera trafego de qualquer lugar para lo0
> $cmd 11 allow ip from any to any via lo0
> 
> #Bloqueia trafego de qualquer lugar para 127.0.0.0/8
> $cmd 12 deny ip from any to 127.0.0.0/8
> 
> #Bloqueia trafego de 127.0.0.0/8 para qualqier lugar
> $cmd 13 deny ip from 127.0.0.0/8 to any
> 
> #Aqui está a regra pelo que entendi no email do Patrick,  que é enviar
> tudo que esteja tagged 30 para a regra de nr. 65500
> $cmd 14 skipto 65500 log all from any to any tagged 30
> 
> #Libera o serviço SSH
> $cmd 16 allow tcp from any to me 22 in via $ext1
> 
> #Conexoes já estabilizadas vao para a regra de divert 
> $cmd 103 $skip tcp from any to any established
> 
> #Aqui está a minha duvida. A regra 900 recebe o trafego, blz, mas se eu
> omitir ela e apenas usar a regra nr 901 não funciona nada.
> #Quando inicio o snort ele abre o socket divert na porta 8000
> $cmd 900  divert 8668 log ip4 from any to any
> $cmd 901 divert 8000 log all from any to any
> 
> #Permite trafego de qualquer lugar para qualquer lugar.
> $cmd 1000 allow log ip from any to any
> 
> 
> #Como descrito no email do Patrick, o que for identificado pelo
> snort_inline, vai para a regra 65500
> $cmd 65499 deny log all from any to any
> $cmd 65500 count tag 30 log all from any to any keep-state
> 
> #Bloqueia qualquer trafego de qualquer lugar
> $cmd 65534 deny log ip from any to any
> 
> 
> 
> Meu snort_inline.conf
> ###
> 
> #Redes
> 
> var HOME_NET [192.168.90.0/24]
> 
> var HONEYNET any
> var EXTERNAL_NET any
> var SMTP_SERVERS any
> var TELNET_SERVERS any
> var HTTP_SERVERS any
> var SQL_SERVERS any
> var HTTP_PORTS 80
> var SHELLCODE_PORTS !80
> var DNS_SERVERS any
> 
> #Manda para o ipfw
> 
> config ipfw_reinject_rule: 65500
> 
> var RULE_PATH /usr/local/share/snort_inline/rules
> 
> preprocessor flow: stats_interval 0 hash 2
> output alert_fast: inline_fast
> 
> include /usr/local/share/snort_inline/classification.config
> include /usr/local/share/snort_inline/reference.config
> 
> 
> include $RULE_PATH/p2p.rules
> include $RULE_PATH/bleeding-p2p.rules
> 
> ###
> 
> O que está acontencendo é o seguinte, no log do snort apareceu a
> identificaçao do trafego dos testes que realizei com os programas mais
> conhecidos como Emule,DreMule.
> Mas nada foi enviado para a regra:
> 
> #ipfw show
> 
> 000110   0 allow ip from any to any via lo0
> 000120   0 deny ip from any to 127.0.0.0/8
> 000130   0 deny ip from 127.0.0.0/8 to any
> 000140   0 skipto 65500 log logamount 100 ip from any to any
> tagged 30
> 000202 156 allow icmp from any to any
> 00103 4772 2137400 skipto 900 tcp from any to any established
> 00900 5622 2237029 divert 8668 log logamount 100 ip4 from any to any
> 00901 5622 2237029 divert 8000 log logamount 100 ip from any to any
> 01000 5622 2237029 allow log logamount 100 ip from any to any
> 654990   0 deny log logamount 100 ip from any to any
> 655000   0 count log logamount 100 tag 30 ip from any to any
> keep-state
> 655340   0 deny log logamount 100 ip from any to any
> 655350   0 deny ip from any to any
> 
> Bom queria uma orientação no que posso fazer.
> 
> Desde já agradeço
> 
> Tiago ISIC Brasil
> 
> 
> 
> 
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd


-- 
Patri

Re: [FUG-BR] RES: Filtro L7

[Tiago Isic Brasil]

Boa tarde!

Sr. Patrick, estou testando o snort_inline + ipfw como descrito no seu
email de resposta a lista referente ao bloqueio do P2P , só que não
estou tendo muito sucesso.

Eu queria só que você checasse onde pode estar errado e me dar um toque
no que pode-se ser realizado.
Quando concluir os testes poderei descrever para a lista o processo da
instalação e configuração dos arquivos.

Abaixo está minhas regras de firewall


Lembrando que está sendo realizado NAT com natd
###
cmd="ipfw -q add"

#Interfaces de rede
int1="xl0"
ext1="fxp0"
skip="skipto 900"
network1="192.168.90.0/24"

#Libera trafego de qualquer lugar para lo0
$cmd 11 allow ip from any to any via lo0

#Bloqueia trafego de qualquer lugar para 127.0.0.0/8
$cmd 12 deny ip from any to 127.0.0.0/8

#Bloqueia trafego de 127.0.0.0/8 para qualqier lugar
$cmd 13 deny ip from 127.0.0.0/8 to any

#Aqui está a regra pelo que entendi no email do Patrick,  que é enviar
tudo que esteja tagged 30 para a regra de nr. 65500
$cmd 14 skipto 65500 log all from any to any tagged 30

#Libera o serviço SSH
$cmd 16 allow tcp from any to me 22 in via $ext1

#Conexoes já estabilizadas vao para a regra de divert 
$cmd 103 $skip tcp from any to any established

#Aqui está a minha duvida. A regra 900 recebe o trafego, blz, mas se eu
omitir ela e apenas usar a regra nr 901 não funciona nada.
#Quando inicio o snort ele abre o socket divert na porta 8000
$cmd 900  divert 8668 log ip4 from any to any
$cmd 901 divert 8000 log all from any to any

#Permite trafego de qualquer lugar para qualquer lugar.
$cmd 1000 allow log ip from any to any


#Como descrito no email do Patrick, o que for identificado pelo
snort_inline, vai para a regra 65500
$cmd 65499 deny log all from any to any
$cmd 65500 count tag 30 log all from any to any keep-state

#Bloqueia qualquer trafego de qualquer lugar
$cmd 65534 deny log ip from any to any



Meu snort_inline.conf
###

#Redes

var HOME_NET [192.168.90.0/24]

var HONEYNET any
var EXTERNAL_NET any
var SMTP_SERVERS any
var TELNET_SERVERS any
var HTTP_SERVERS any
var SQL_SERVERS any
var HTTP_PORTS 80
var SHELLCODE_PORTS !80
var DNS_SERVERS any

#Manda para o ipfw

config ipfw_reinject_rule: 65500

var RULE_PATH /usr/local/share/snort_inline/rules

preprocessor flow: stats_interval 0 hash 2
output alert_fast: inline_fast

include /usr/local/share/snort_inline/classification.config
include /usr/local/share/snort_inline/reference.config


include $RULE_PATH/p2p.rules
include $RULE_PATH/bleeding-p2p.rules

###

O que está acontencendo é o seguinte, no log do snort apareceu a
identificaçao do trafego dos testes que realizei com os programas mais
conhecidos como Emule,DreMule.
Mas nada foi enviado para a regra:

#ipfw show

000110   0 allow ip from any to any via lo0
000120   0 deny ip from any to 127.0.0.0/8
000130   0 deny ip from 127.0.0.0/8 to any
000140   0 skipto 65500 log logamount 100 ip from any to any
tagged 30
000202 156 allow icmp from any to any
00103 4772 2137400 skipto 900 tcp from any to any established
00900 5622 2237029 divert 8668 log logamount 100 ip4 from any to any
00901 5622 2237029 divert 8000 log logamount 100 ip from any to any
01000 5622 2237029 allow log logamount 100 ip from any to any
654990   0 deny log logamount 100 ip from any to any
655000   0 count log logamount 100 tag 30 ip from any to any
keep-state
655340   0 deny log logamount 100 ip from any to any
655350   0 deny ip from any to any

Bom queria uma orientação no que posso fazer.

Desde já agradeço

Tiago ISIC Brasil




-
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: Filtro L7

[Patrick Tracanelli]

Lucas Mocellin escreveu:
> Obrigado pela atenção Patrick, com certeza sua contribuição será de
> muito bom proveito, vou tentar implementar algo como o que você falou
> e depois posto algum comentário sobre aqui, porém concordo com a idéia
> do Márcio.
> 
> Foi uma boa abordagem do assunto, porém soou um tanto complexa, tudo
> bem que sou iniciante no uso do FreeBSD, mas acredito que uma boa
> parte do pessoal da lista(se não for a maioria) também sentirá
> dificuldades assim como eu.
> 
> Obrigado mais uma vez, att,

Se quiser algo mais facil, considere:

http://doc.bleedingthreats.net/bin/view/Main/SnortSam

Qualquer dificuldade com as duas abordagens, sem exceção, se referirá 
aos conceitos de uso do snort muito mais do que algo especifico sobre of 
firewall ou FreeBSD, um pouco de atividade previa com snort ja te fara 
ficar bem mais a vontade.

E vai por mim: receita de bolo não ganha concurso de culinária ;)

> 
> Lucas Mocellin.
> 
> Em 26/11/07, Patrick Tracanelli<[EMAIL PROTECTED]> escreveu:
>> Marcio Antunes escreveu:
>>> Aproveitando patrick,
>>>
>>> pq vc não coloca em forma de artigo.. assim ficaria como um How-to.
>> Porque é simples demais, e se resumiria em essência ao conteúdo desse
>> e-mail. O resto é snort apenas, nada especifico com a abordagem.
>>
>> Outra abordagem bastante funcional é com snortsam colocando src e dst em
>> tables distintas, ai o controle seria "from table(1) to table(2)" e
>> vice-versa, diminuindo o problema dos p2p q mudam de protocolo no meio
>> da conversa.
>>
>>>
>>> Em 26/11/07, Patrick Tracanelli<[EMAIL PROTECTED]> escreveu:
 Vou tentar resumir o ambiente que eu uso pra filtrar L7, aja que a
 thread esta bem grande.

 Instale via ports o snort_inline, e entao configure o snort_inline.conf
 com algo proximo a isso (pode comecar com isso e depois customizar):

 ### Network variables
 var HOME_NET [192.168.0.0/16,10.0.0.0/8,200.X.Y.0/22]
 #var HOME_NET any
 var HONEYNET any
 var EXTERNAL_NET any
 var SMTP_SERVERS any
 var TELNET_SERVERS any
 var HTTP_SERVERS any
 var SQL_SERVERS any
 var HTTP_PORTS 80
 var SHELLCODE_PORTS !80
 var ORACLE_PORTS 1521
 var DNS_SERVERS any
 var SSH_PORTS 22  2022

 #config checksum_mode: all
 config ipfw_reinject_rule: 65500

 var RULE_PATH /usr/local/share/snort_inline/rules

 preprocessor flow: stats_interval 0 hash 2
 output alert_fast: inline_fast

 include /usr/local/share/snort_inline/classification.config
 include /usr/local/share/snort_inline/reference.config
 #include /usr/local/share/snort_inline/rules/classification.config

 include $RULE_PATH/FBSDBR/patrick.rules
 include $RULE_PATH/FBSDBR/patrick-p2p-drop.rules

 include $RULE_PATH/p2p.rules
 include $RULE_PATH/bleeding-p2p.rules

 Na regra 65500 u tenho um "add count tag 30 all from any to any keep-state"

 E logo abaixo faco queue (Wf2Q+) de tudo "tagged 30". Um pipe obviamente
 também serve.

 No comeco de tudo, faca um "skipto 65500 all from any to any tagged 30".

 As dicas são:

 - resuma seu firewall a regras antes da 65500, de forma que nada que nao
 for desviado/reinjetado para 65500 jamais chegue nela (ou seja: "add
 65499 deny all from any to any" pra ter a politica antes desse pool
 final de regras. Desvie para a 65500 apenas pelo snort_inline - o .conf
 acima ja esta configurado pra isso);

 - desvie para o snort_inline o trafego desejado, NO MOMENTO que voce
 jugar necessario: comece com "divert 8000 all from any to any" pra
 testes, depois seja seletivo: "divert 8000 all from $minharede to any
 out", "divert 8000 all from any to $minharede in"

 - lembre-se que apos o desvio 2 coisas acontecem: se o snort_inline nao
 classificar o pacote com as regras carregadas, o pacote volta pra
 proxima regra do firewall, se bater com as regras, o pacote sera
 reinjetado para a ipfw_reinject_rule configurada;

 - porque usar "tag" e "count" e "keep-state"? porque voce nao quer
 permitir, nem negar, nem ja jogar pro controle de banda, apenas aquele
 pacote; voce quer com base no pacote conhecer a sessao toda
 (keep-state), e taggear *todos* os pacotes da sessao, e depois manipula-los

 Por ultimo, eleve o net.inet.ip.fw.dyn_udp_lifetime, eu uso-o em 300 sem
   dó (sim, 5 minutos).

 Agora algumas considerações:

 - SANS Security recomenda que toda analise de payload nao seja feita
 pelo firewall, e preferencialmente seja feita por aplicacoes de
 userlevel pois se comprometidas nao desestabiliza o sistema (ao
 contrario de analise me kernel);

 - O custo de desviar pra uma aplicacao de userland com divert em relacao
 ao processamento que seria feito se fosse em kernel, é de 2 syscall para
 os pacotes nao classificados (praticamente todos) e 3 s

Re: [FUG-BR] RES: Filtro L7

[Lucas Mocellin]

Obrigado pela atenção Patrick, com certeza sua contribuição será de
muito bom proveito, vou tentar implementar algo como o que você falou
e depois posto algum comentário sobre aqui, porém concordo com a idéia
do Márcio.

Foi uma boa abordagem do assunto, porém soou um tanto complexa, tudo
bem que sou iniciante no uso do FreeBSD, mas acredito que uma boa
parte do pessoal da lista(se não for a maioria) também sentirá
dificuldades assim como eu.

Obrigado mais uma vez, att,

Lucas Mocellin.

Em 26/11/07, Patrick Tracanelli<[EMAIL PROTECTED]> escreveu:
> Marcio Antunes escreveu:
> > Aproveitando patrick,
> >
> > pq vc não coloca em forma de artigo.. assim ficaria como um How-to.
>
> Porque é simples demais, e se resumiria em essência ao conteúdo desse
> e-mail. O resto é snort apenas, nada especifico com a abordagem.
>
> Outra abordagem bastante funcional é com snortsam colocando src e dst em
> tables distintas, ai o controle seria "from table(1) to table(2)" e
> vice-versa, diminuindo o problema dos p2p q mudam de protocolo no meio
> da conversa.
>
> >
> >
> > Em 26/11/07, Patrick Tracanelli<[EMAIL PROTECTED]> escreveu:
> >> Vou tentar resumir o ambiente que eu uso pra filtrar L7, aja que a
> >> thread esta bem grande.
> >>
> >> Instale via ports o snort_inline, e entao configure o snort_inline.conf
> >> com algo proximo a isso (pode comecar com isso e depois customizar):
> >>
> >> ### Network variables
> >> var HOME_NET [192.168.0.0/16,10.0.0.0/8,200.X.Y.0/22]
> >> #var HOME_NET any
> >> var HONEYNET any
> >> var EXTERNAL_NET any
> >> var SMTP_SERVERS any
> >> var TELNET_SERVERS any
> >> var HTTP_SERVERS any
> >> var SQL_SERVERS any
> >> var HTTP_PORTS 80
> >> var SHELLCODE_PORTS !80
> >> var ORACLE_PORTS 1521
> >> var DNS_SERVERS any
> >> var SSH_PORTS 22  2022
> >>
> >> #config checksum_mode: all
> >> config ipfw_reinject_rule: 65500
> >>
> >> var RULE_PATH /usr/local/share/snort_inline/rules
> >>
> >> preprocessor flow: stats_interval 0 hash 2
> >> output alert_fast: inline_fast
> >>
> >> include /usr/local/share/snort_inline/classification.config
> >> include /usr/local/share/snort_inline/reference.config
> >> #include /usr/local/share/snort_inline/rules/classification.config
> >>
> >> include $RULE_PATH/FBSDBR/patrick.rules
> >> include $RULE_PATH/FBSDBR/patrick-p2p-drop.rules
> >>
> >> include $RULE_PATH/p2p.rules
> >> include $RULE_PATH/bleeding-p2p.rules
> >>
> >> Na regra 65500 u tenho um "add count tag 30 all from any to any keep-state"
> >>
> >> E logo abaixo faco queue (Wf2Q+) de tudo "tagged 30". Um pipe obviamente
> >> também serve.
> >>
> >> No comeco de tudo, faca um "skipto 65500 all from any to any tagged 30".
> >>
> >> As dicas são:
> >>
> >> - resuma seu firewall a regras antes da 65500, de forma que nada que nao
> >> for desviado/reinjetado para 65500 jamais chegue nela (ou seja: "add
> >> 65499 deny all from any to any" pra ter a politica antes desse pool
> >> final de regras. Desvie para a 65500 apenas pelo snort_inline - o .conf
> >> acima ja esta configurado pra isso);
> >>
> >> - desvie para o snort_inline o trafego desejado, NO MOMENTO que voce
> >> jugar necessario: comece com "divert 8000 all from any to any" pra
> >> testes, depois seja seletivo: "divert 8000 all from $minharede to any
> >> out", "divert 8000 all from any to $minharede in"
> >>
> >> - lembre-se que apos o desvio 2 coisas acontecem: se o snort_inline nao
> >> classificar o pacote com as regras carregadas, o pacote volta pra
> >> proxima regra do firewall, se bater com as regras, o pacote sera
> >> reinjetado para a ipfw_reinject_rule configurada;
> >>
> >> - porque usar "tag" e "count" e "keep-state"? porque voce nao quer
> >> permitir, nem negar, nem ja jogar pro controle de banda, apenas aquele
> >> pacote; voce quer com base no pacote conhecer a sessao toda
> >> (keep-state), e taggear *todos* os pacotes da sessao, e depois manipula-los
> >>
> >> Por ultimo, eleve o net.inet.ip.fw.dyn_udp_lifetime, eu uso-o em 300 sem
> >>   dó (sim, 5 minutos).
> >>
> >> Agora algumas considerações:
> >>
> >> - SANS Security recomenda que toda analise de payload nao seja feita
> >> pelo firewall, e preferencialmente seja feita por aplicacoes de
> >> userlevel pois se comprometidas nao desestabiliza o sistema (ao
> >> contrario de analise me kernel);
> >>
> >> - O custo de desviar pra uma aplicacao de userland com divert em relacao
> >> ao processamento que seria feito se fosse em kernel, é de 2 syscall para
> >> os pacotes nao classificados (praticamente todos) e 3 syscall para os
> >> classificados; isso realmente gera impacto no seu ambiente?
> >>
> >> - O custo de processamento do snort_inline, que atua de forma pró-ativa
> >> (veja bem: snort convencional: passivo, snort com flexresp: responsivo,
> >> snort com snortsam ou OSSEC evocando rotinas externas: resposta ativa,
> >> snort_inline = pró-ativo pois se o snort não reinjetar, não volta pro
> >> firewall e consequentemente não volta pra pilha IP) é no máximo 5%
> 

Re: [FUG-BR] RES: Filtro L7

[Patrick Tracanelli]

Marcio Antunes escreveu:
> Aproveitando patrick,
> 
> pq vc não coloca em forma de artigo.. assim ficaria como um How-to.

Porque é simples demais, e se resumiria em essência ao conteúdo desse 
e-mail. O resto é snort apenas, nada especifico com a abordagem.

Outra abordagem bastante funcional é com snortsam colocando src e dst em 
tables distintas, ai o controle seria "from table(1) to table(2)" e 
vice-versa, diminuindo o problema dos p2p q mudam de protocolo no meio 
da conversa.

> 
> 
> Em 26/11/07, Patrick Tracanelli<[EMAIL PROTECTED]> escreveu:
>> Vou tentar resumir o ambiente que eu uso pra filtrar L7, aja que a
>> thread esta bem grande.
>>
>> Instale via ports o snort_inline, e entao configure o snort_inline.conf
>> com algo proximo a isso (pode comecar com isso e depois customizar):
>>
>> ### Network variables
>> var HOME_NET [192.168.0.0/16,10.0.0.0/8,200.X.Y.0/22]
>> #var HOME_NET any
>> var HONEYNET any
>> var EXTERNAL_NET any
>> var SMTP_SERVERS any
>> var TELNET_SERVERS any
>> var HTTP_SERVERS any
>> var SQL_SERVERS any
>> var HTTP_PORTS 80
>> var SHELLCODE_PORTS !80
>> var ORACLE_PORTS 1521
>> var DNS_SERVERS any
>> var SSH_PORTS 22  2022
>>
>> #config checksum_mode: all
>> config ipfw_reinject_rule: 65500
>>
>> var RULE_PATH /usr/local/share/snort_inline/rules
>>
>> preprocessor flow: stats_interval 0 hash 2
>> output alert_fast: inline_fast
>>
>> include /usr/local/share/snort_inline/classification.config
>> include /usr/local/share/snort_inline/reference.config
>> #include /usr/local/share/snort_inline/rules/classification.config
>>
>> include $RULE_PATH/FBSDBR/patrick.rules
>> include $RULE_PATH/FBSDBR/patrick-p2p-drop.rules
>>
>> include $RULE_PATH/p2p.rules
>> include $RULE_PATH/bleeding-p2p.rules
>>
>> Na regra 65500 u tenho um "add count tag 30 all from any to any keep-state"
>>
>> E logo abaixo faco queue (Wf2Q+) de tudo "tagged 30". Um pipe obviamente
>> também serve.
>>
>> No comeco de tudo, faca um "skipto 65500 all from any to any tagged 30".
>>
>> As dicas são:
>>
>> - resuma seu firewall a regras antes da 65500, de forma que nada que nao
>> for desviado/reinjetado para 65500 jamais chegue nela (ou seja: "add
>> 65499 deny all from any to any" pra ter a politica antes desse pool
>> final de regras. Desvie para a 65500 apenas pelo snort_inline - o .conf
>> acima ja esta configurado pra isso);
>>
>> - desvie para o snort_inline o trafego desejado, NO MOMENTO que voce
>> jugar necessario: comece com "divert 8000 all from any to any" pra
>> testes, depois seja seletivo: "divert 8000 all from $minharede to any
>> out", "divert 8000 all from any to $minharede in"
>>
>> - lembre-se que apos o desvio 2 coisas acontecem: se o snort_inline nao
>> classificar o pacote com as regras carregadas, o pacote volta pra
>> proxima regra do firewall, se bater com as regras, o pacote sera
>> reinjetado para a ipfw_reinject_rule configurada;
>>
>> - porque usar "tag" e "count" e "keep-state"? porque voce nao quer
>> permitir, nem negar, nem ja jogar pro controle de banda, apenas aquele
>> pacote; voce quer com base no pacote conhecer a sessao toda
>> (keep-state), e taggear *todos* os pacotes da sessao, e depois manipula-los
>>
>> Por ultimo, eleve o net.inet.ip.fw.dyn_udp_lifetime, eu uso-o em 300 sem
>>   dó (sim, 5 minutos).
>>
>> Agora algumas considerações:
>>
>> - SANS Security recomenda que toda analise de payload nao seja feita
>> pelo firewall, e preferencialmente seja feita por aplicacoes de
>> userlevel pois se comprometidas nao desestabiliza o sistema (ao
>> contrario de analise me kernel);
>>
>> - O custo de desviar pra uma aplicacao de userland com divert em relacao
>> ao processamento que seria feito se fosse em kernel, é de 2 syscall para
>> os pacotes nao classificados (praticamente todos) e 3 syscall para os
>> classificados; isso realmente gera impacto no seu ambiente?
>>
>> - O custo de processamento do snort_inline, que atua de forma pró-ativa
>> (veja bem: snort convencional: passivo, snort com flexresp: responsivo,
>> snort com snortsam ou OSSEC evocando rotinas externas: resposta ativa,
>> snort_inline = pró-ativo pois se o snort não reinjetar, não volta pro
>> firewall e consequentemente não volta pra pilha IP) é no máximo 5%
>> superior ao snort atuando em modo passivo. Você não tem CPU suficiente
>> para o snort com meia duzia de rules seletivas?
>>
>> Por último, algumas considerações adicionais:
>>
>> - Impacto negativo: você está desviando um dado fluxo para o
>> snort_inline, isso quer dizer que se não tive nada ouvindo na porta 8000
>>   protocolo div4, aquele fluxo vai pra /dev/null (ou seja, tudo para);
>> mas o snort_inline nunca morre sozinho; se mesmo assim você tem medo:
>> daemontools pra que te quero.
>>
>> - Você pode anular o ponto negativo anterior trocando "divert" por "tee"
>> na regra de firewall. Nesse caso uma cópia vai para o snort_inline e
>> outra, do pacote, fica no firewall. Portanto voce vai querer repensar
>> seu firewall pra copia q fica 

Re: [FUG-BR] RES: Filtro L7

[Marcio Antunes]

Aproveitando patrick,

pq vc não coloca em forma de artigo.. assim ficaria como um How-to.


Em 26/11/07, Patrick Tracanelli<[EMAIL PROTECTED]> escreveu:
> Vou tentar resumir o ambiente que eu uso pra filtrar L7, aja que a
> thread esta bem grande.
>
> Instale via ports o snort_inline, e entao configure o snort_inline.conf
> com algo proximo a isso (pode comecar com isso e depois customizar):
>
> ### Network variables
> var HOME_NET [192.168.0.0/16,10.0.0.0/8,200.X.Y.0/22]
> #var HOME_NET any
> var HONEYNET any
> var EXTERNAL_NET any
> var SMTP_SERVERS any
> var TELNET_SERVERS any
> var HTTP_SERVERS any
> var SQL_SERVERS any
> var HTTP_PORTS 80
> var SHELLCODE_PORTS !80
> var ORACLE_PORTS 1521
> var DNS_SERVERS any
> var SSH_PORTS 22  2022
>
> #config checksum_mode: all
> config ipfw_reinject_rule: 65500
>
> var RULE_PATH /usr/local/share/snort_inline/rules
>
> preprocessor flow: stats_interval 0 hash 2
> output alert_fast: inline_fast
>
> include /usr/local/share/snort_inline/classification.config
> include /usr/local/share/snort_inline/reference.config
> #include /usr/local/share/snort_inline/rules/classification.config
>
> include $RULE_PATH/FBSDBR/patrick.rules
> include $RULE_PATH/FBSDBR/patrick-p2p-drop.rules
>
> include $RULE_PATH/p2p.rules
> include $RULE_PATH/bleeding-p2p.rules
>
> Na regra 65500 u tenho um "add count tag 30 all from any to any keep-state"
>
> E logo abaixo faco queue (Wf2Q+) de tudo "tagged 30". Um pipe obviamente
> também serve.
>
> No comeco de tudo, faca um "skipto 65500 all from any to any tagged 30".
>
> As dicas são:
>
> - resuma seu firewall a regras antes da 65500, de forma que nada que nao
> for desviado/reinjetado para 65500 jamais chegue nela (ou seja: "add
> 65499 deny all from any to any" pra ter a politica antes desse pool
> final de regras. Desvie para a 65500 apenas pelo snort_inline - o .conf
> acima ja esta configurado pra isso);
>
> - desvie para o snort_inline o trafego desejado, NO MOMENTO que voce
> jugar necessario: comece com "divert 8000 all from any to any" pra
> testes, depois seja seletivo: "divert 8000 all from $minharede to any
> out", "divert 8000 all from any to $minharede in"
>
> - lembre-se que apos o desvio 2 coisas acontecem: se o snort_inline nao
> classificar o pacote com as regras carregadas, o pacote volta pra
> proxima regra do firewall, se bater com as regras, o pacote sera
> reinjetado para a ipfw_reinject_rule configurada;
>
> - porque usar "tag" e "count" e "keep-state"? porque voce nao quer
> permitir, nem negar, nem ja jogar pro controle de banda, apenas aquele
> pacote; voce quer com base no pacote conhecer a sessao toda
> (keep-state), e taggear *todos* os pacotes da sessao, e depois manipula-los
>
> Por ultimo, eleve o net.inet.ip.fw.dyn_udp_lifetime, eu uso-o em 300 sem
>   dó (sim, 5 minutos).
>
> Agora algumas considerações:
>
> - SANS Security recomenda que toda analise de payload nao seja feita
> pelo firewall, e preferencialmente seja feita por aplicacoes de
> userlevel pois se comprometidas nao desestabiliza o sistema (ao
> contrario de analise me kernel);
>
> - O custo de desviar pra uma aplicacao de userland com divert em relacao
> ao processamento que seria feito se fosse em kernel, é de 2 syscall para
> os pacotes nao classificados (praticamente todos) e 3 syscall para os
> classificados; isso realmente gera impacto no seu ambiente?
>
> - O custo de processamento do snort_inline, que atua de forma pró-ativa
> (veja bem: snort convencional: passivo, snort com flexresp: responsivo,
> snort com snortsam ou OSSEC evocando rotinas externas: resposta ativa,
> snort_inline = pró-ativo pois se o snort não reinjetar, não volta pro
> firewall e consequentemente não volta pra pilha IP) é no máximo 5%
> superior ao snort atuando em modo passivo. Você não tem CPU suficiente
> para o snort com meia duzia de rules seletivas?
>
> Por último, algumas considerações adicionais:
>
> - Impacto negativo: você está desviando um dado fluxo para o
> snort_inline, isso quer dizer que se não tive nada ouvindo na porta 8000
>   protocolo div4, aquele fluxo vai pra /dev/null (ou seja, tudo para);
> mas o snort_inline nunca morre sozinho; se mesmo assim você tem medo:
> daemontools pra que te quero.
>
> - Você pode anular o ponto negativo anterior trocando "divert" por "tee"
> na regra de firewall. Nesse caso uma cópia vai para o snort_inline e
> outra, do pacote, fica no firewall. Portanto voce vai querer repensar
> seu firewall pra copia q fica nao cair num "allow" antes de cair no seu
> controle de banda. Dica: skipto vai resolver.
>
> - Funciona 100%? Não! Digamos, uns 70%. Porque? Porque tem alguns P2P
> que detectamos via TCP mas o tráfego vai por UDP. Nesse caso precisaria
> de um tipo de "keep-state" no firewall que mantesse a sessão apenas por
> IP, sem se ligar em porta ou protocolo. Ai sim funcionaria
> perfeitamente. Tai algo q mereceria ser investigado e feito no ipfw.
>
> - Eu amenizei todas as situações onde os "30%" q nao funcion

Re: [FUG-BR] RES: Filtro L7

[Patrick Tracanelli]

Vou tentar resumir o ambiente que eu uso pra filtrar L7, aja que a 
thread esta bem grande.

Instale via ports o snort_inline, e entao configure o snort_inline.conf 
com algo proximo a isso (pode comecar com isso e depois customizar):

### Network variables
var HOME_NET [192.168.0.0/16,10.0.0.0/8,200.X.Y.0/22]
#var HOME_NET any
var HONEYNET any
var EXTERNAL_NET any
var SMTP_SERVERS any
var TELNET_SERVERS any
var HTTP_SERVERS any
var SQL_SERVERS any
var HTTP_PORTS 80
var SHELLCODE_PORTS !80
var ORACLE_PORTS 1521
var DNS_SERVERS any
var SSH_PORTS 22  2022

#config checksum_mode: all
config ipfw_reinject_rule: 65500

var RULE_PATH /usr/local/share/snort_inline/rules

preprocessor flow: stats_interval 0 hash 2
output alert_fast: inline_fast

include /usr/local/share/snort_inline/classification.config
include /usr/local/share/snort_inline/reference.config
#include /usr/local/share/snort_inline/rules/classification.config

include $RULE_PATH/FBSDBR/patrick.rules
include $RULE_PATH/FBSDBR/patrick-p2p-drop.rules

include $RULE_PATH/p2p.rules
include $RULE_PATH/bleeding-p2p.rules

Na regra 65500 u tenho um "add count tag 30 all from any to any keep-state"

E logo abaixo faco queue (Wf2Q+) de tudo "tagged 30". Um pipe obviamente 
também serve.

No comeco de tudo, faca um "skipto 65500 all from any to any tagged 30".

As dicas são:

- resuma seu firewall a regras antes da 65500, de forma que nada que nao 
for desviado/reinjetado para 65500 jamais chegue nela (ou seja: "add 
65499 deny all from any to any" pra ter a politica antes desse pool 
final de regras. Desvie para a 65500 apenas pelo snort_inline - o .conf 
acima ja esta configurado pra isso);

- desvie para o snort_inline o trafego desejado, NO MOMENTO que voce 
jugar necessario: comece com "divert 8000 all from any to any" pra 
testes, depois seja seletivo: "divert 8000 all from $minharede to any 
out", "divert 8000 all from any to $minharede in"

- lembre-se que apos o desvio 2 coisas acontecem: se o snort_inline nao 
classificar o pacote com as regras carregadas, o pacote volta pra 
proxima regra do firewall, se bater com as regras, o pacote sera 
reinjetado para a ipfw_reinject_rule configurada;

- porque usar "tag" e "count" e "keep-state"? porque voce nao quer 
permitir, nem negar, nem ja jogar pro controle de banda, apenas aquele 
pacote; voce quer com base no pacote conhecer a sessao toda 
(keep-state), e taggear *todos* os pacotes da sessao, e depois manipula-los

Por ultimo, eleve o net.inet.ip.fw.dyn_udp_lifetime, eu uso-o em 300 sem 
  dó (sim, 5 minutos).

Agora algumas considerações:

- SANS Security recomenda que toda analise de payload nao seja feita 
pelo firewall, e preferencialmente seja feita por aplicacoes de 
userlevel pois se comprometidas nao desestabiliza o sistema (ao 
contrario de analise me kernel);

- O custo de desviar pra uma aplicacao de userland com divert em relacao 
ao processamento que seria feito se fosse em kernel, é de 2 syscall para 
os pacotes nao classificados (praticamente todos) e 3 syscall para os 
classificados; isso realmente gera impacto no seu ambiente?

- O custo de processamento do snort_inline, que atua de forma pró-ativa 
(veja bem: snort convencional: passivo, snort com flexresp: responsivo, 
snort com snortsam ou OSSEC evocando rotinas externas: resposta ativa, 
snort_inline = pró-ativo pois se o snort não reinjetar, não volta pro 
firewall e consequentemente não volta pra pilha IP) é no máximo 5% 
superior ao snort atuando em modo passivo. Você não tem CPU suficiente 
para o snort com meia duzia de rules seletivas?

Por último, algumas considerações adicionais:

- Impacto negativo: você está desviando um dado fluxo para o 
snort_inline, isso quer dizer que se não tive nada ouvindo na porta 8000 
  protocolo div4, aquele fluxo vai pra /dev/null (ou seja, tudo para); 
mas o snort_inline nunca morre sozinho; se mesmo assim você tem medo: 
daemontools pra que te quero.

- Você pode anular o ponto negativo anterior trocando "divert" por "tee" 
na regra de firewall. Nesse caso uma cópia vai para o snort_inline e 
outra, do pacote, fica no firewall. Portanto voce vai querer repensar 
seu firewall pra copia q fica nao cair num "allow" antes de cair no seu 
controle de banda. Dica: skipto vai resolver.

- Funciona 100%? Não! Digamos, uns 70%. Porque? Porque tem alguns P2P 
que detectamos via TCP mas o tráfego vai por UDP. Nesse caso precisaria 
de um tipo de "keep-state" no firewall que mantesse a sessão apenas por 
IP, sem se ligar em porta ou protocolo. Ai sim funcionaria 
perfeitamente. Tai algo q mereceria ser investigado e feito no ipfw.

- Eu amenizei todas as situações onde os "30%" q nao funcionava era um 
problema analisando com tcpdump os trafegos e criando minhas proprias 
regras. Ai que mora outra vantagem: regras snort, nada mais facil de fazer.

Finalmente, consideracoes de experiencia propria:

- Nessa mauqina:

# dmesg | grep "CPU:\|memory"
CPU: Intel(R) Core(TM)2 CPU T7200  @ 2.00GHz (

Re: [FUG-BR] RES: Filtro L7

[Jose Augusto]

Amigo, com L7 ainda é possível fazer alguma coisa quanto aos usuários :D,
mas se o cara quiser mesmo baixar, ai não tem jeito, burla mesmo! O Melhor
método que eu descobri até hoje é psicológico, hahahhhahah!! com o SQUIDSTAT
eu pego a conexão de muita coisa no ato :P, queria fazer um plugin/script
pro SQ que diria quando a conexão ultrapassa tanto e tals...mas so fraco com
esse negócio :)
Também tenho PFSense mas de nada adianta!

Abraços!

Em 25/11/07, keffer <[EMAIL PROTECTED]> escreveu:
>
> Admin de redes é o que não deve faltar por aqui, porem axo que como
> qualquer
> outra pessoa eles consequentemente devem ter suas vidas
> Em pleno sábado essas horas provavelmente estão aproveitando seu fds ou
> estão com suas familias
> Aguarde um tempo a mais que tera a ajuda que precisa
>
> Atenciosamente
>
>
>
>
> - Original Message -
> From: "Lucas Mocellin" <[EMAIL PROTECTED]>
> To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
> 
> Sent: Saturday, November 24, 2007 11:27 PM
> Subject: Re: [FUG-BR] RES: Filtro L7
>
>
> po, ta complicado assim.. =\ nao tem nenhum admin da NET ai?? eehehehe
>
> eu instalei o pfSense que faz traffic shapping, parece que eh por
> porta mesmo, mas eu acho estranho que os programas parece que comecam
> estabelecendo em uma porta e o envio do arquivo mesmo é em uma porta
> aleatória, aí é complicado..
>
> mas bem, vou pesquisar mais sobre e depois posto aqui o resultado da
> bagatela..
>
> abraço pessoal e muito gradecido mesmo das sugestões..
>
> =)
>
> Lucas.
>
> Em 24/11/07, Nilton Jose Rizzo<[EMAIL PROTECTED]> escreveu:
> > On Sat, 24 Nov 2007 13:02:05 -0200, Klaus Schneider wrote
> >
> >
> >  Certa vez, assisti em uma demonstração de um sistema de controle
> >  via socket.  Era tudo fechado proxy/conexão direta, so conseguia
> >  sair via sochet, e nessa conexão os caras faziam filtros de aplicação
> >  não entraram muito em detalhes técnicos por mais que eram questionados,
> >  mas pode ser um caminho ... sei lá   só uma ideia
> >
> >
> > > Já vi alguns sistemas que fazem controle de p2p, mas eu acredito que
> > > eles mesclem algumas tecnicas de Layer 7 com monitoramento de states,
> > >  tipo se o cara passa pelo layer 7 eles usam o state do firewall
> > > para monitorar o trafego, se ultrapassar um certo período ou
> > > quantidade de dados, eles alteram a classificacao do tráfego no
> > > QoS(seja baixando a prioridade ou colocando a conexão em uma fila
> > > mais lenta)... Não é tão complicado de fazer, e é o único meio que
> > > imagino ser possível... o problema é que isso pode prejudicar a
> > > conexão de quem esta simplismente baixando um arquivo para atualizar
> > > um AV ou o próprio sistema operacional, ai em vez de criar uma
> > > solução, tu cria um problema.
> > >
> > > Em 24/11/07, Welkson Renny de Medeiros
> > > <[EMAIL PROTECTED]> escreveu:
> > > >
> >
> > <<< CUT >>>
> >
> > --
> > Nilton José Rizzo
> > 805 Informatica
> > Disseminado tecnologias
> > 021 2413 9786
> >
> > -
> > 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
>
>
> __ Informação do NOD32 IMON 2683 (20071124) __
>
> Esta mensagem foi verificada pelo NOD32 sistema antivírus
> http://www.eset.com.br
>
>
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>



-- 
--
"Segurança da Informação se faz com tecnologia, processos e pessoas, e a
formação destas exige mais que uma seqüência de treinamentos. Porque você
treina macacos. Pessoas,você educa."

"Se a gente se lança sem vigor, sete de dez ações tomadas não dão certo. É
extremamente difícil tomar decisões num estado de agitação. Por outro lado,
se sem se preocupar com as conseqüências menores, abordamos os problemas com
o espíito afiado como uma lâmina, sempre encontramos a solução em menos
tempo do que é necessáio para respirar sete vezes."  Nabeshima Naoshige
(1538-1618)
-
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: Filtro L7

[keffer]

Admin de redes é o que não deve faltar por aqui, porem axo que como qualquer 
outra pessoa eles consequentemente devem ter suas vidas
Em pleno sábado essas horas provavelmente estão aproveitando seu fds ou 
estão com suas familias
Aguarde um tempo a mais que tera a ajuda que precisa

Atenciosamente




- Original Message - 
From: "Lucas Mocellin" <[EMAIL PROTECTED]>
To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)" 

Sent: Saturday, November 24, 2007 11:27 PM
Subject: Re: [FUG-BR] RES: Filtro L7


po, ta complicado assim.. =\ nao tem nenhum admin da NET ai?? eehehehe

eu instalei o pfSense que faz traffic shapping, parece que eh por
porta mesmo, mas eu acho estranho que os programas parece que comecam
estabelecendo em uma porta e o envio do arquivo mesmo é em uma porta
aleatória, aí é complicado..

mas bem, vou pesquisar mais sobre e depois posto aqui o resultado da 
bagatela..

abraço pessoal e muito gradecido mesmo das sugestões..

=)

Lucas.

Em 24/11/07, Nilton Jose Rizzo<[EMAIL PROTECTED]> escreveu:
> On Sat, 24 Nov 2007 13:02:05 -0200, Klaus Schneider wrote
>
>
>  Certa vez, assisti em uma demonstração de um sistema de controle
>  via socket.  Era tudo fechado proxy/conexão direta, so conseguia
>  sair via sochet, e nessa conexão os caras faziam filtros de aplicação
>  não entraram muito em detalhes técnicos por mais que eram questionados,
>  mas pode ser um caminho ... sei lá   só uma ideia
>
>
> > Já vi alguns sistemas que fazem controle de p2p, mas eu acredito que
> > eles mesclem algumas tecnicas de Layer 7 com monitoramento de states,
> >  tipo se o cara passa pelo layer 7 eles usam o state do firewall
> > para monitorar o trafego, se ultrapassar um certo período ou
> > quantidade de dados, eles alteram a classificacao do tráfego no
> > QoS(seja baixando a prioridade ou colocando a conexão em uma fila
> > mais lenta)... Não é tão complicado de fazer, e é o único meio que
> > imagino ser possível... o problema é que isso pode prejudicar a
> > conexão de quem esta simplismente baixando um arquivo para atualizar
> > um AV ou o próprio sistema operacional, ai em vez de criar uma
> > solução, tu cria um problema.
> >
> > Em 24/11/07, Welkson Renny de Medeiros
> > <[EMAIL PROTECTED]> escreveu:
> > >
>
> <<< CUT >>>
>
> --
> Nilton José Rizzo
> 805 Informatica
> Disseminado tecnologias
> 021 2413 9786
>
> -
> 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


__ Informação do NOD32 IMON 2683 (20071124) __

Esta mensagem foi verificada pelo NOD32 sistema antivírus
http://www.eset.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] RES: Filtro L7

[Lucas Mocellin]

po, ta complicado assim.. =\ nao tem nenhum admin da NET ai?? eehehehe

eu instalei o pfSense que faz traffic shapping, parece que eh por
porta mesmo, mas eu acho estranho que os programas parece que comecam
estabelecendo em uma porta e o envio do arquivo mesmo é em uma porta
aleatória, aí é complicado..

mas bem, vou pesquisar mais sobre e depois posto aqui o resultado da bagatela..

abraço pessoal e muito gradecido mesmo das sugestões..

=)

Lucas.

Em 24/11/07, Nilton Jose Rizzo<[EMAIL PROTECTED]> escreveu:
> On Sat, 24 Nov 2007 13:02:05 -0200, Klaus Schneider wrote
>
>
>  Certa vez, assisti em uma demonstração de um sistema de controle
>  via socket.  Era tudo fechado proxy/conexão direta, so conseguia
>  sair via sochet, e nessa conexão os caras faziam filtros de aplicação
>  não entraram muito em detalhes técnicos por mais que eram questionados,
>  mas pode ser um caminho ... sei lá   só uma ideia
>
>
> > Já vi alguns sistemas que fazem controle de p2p, mas eu acredito que
> > eles mesclem algumas tecnicas de Layer 7 com monitoramento de states,
> >  tipo se o cara passa pelo layer 7 eles usam o state do firewall
> > para monitorar o trafego, se ultrapassar um certo período ou
> > quantidade de dados, eles alteram a classificacao do tráfego no
> > QoS(seja baixando a prioridade ou colocando a conexão em uma fila
> > mais lenta)... Não é tão complicado de fazer, e é o único meio que
> > imagino ser possível... o problema é que isso pode prejudicar a
> > conexão de quem esta simplismente baixando um arquivo para atualizar
> > um AV ou o próprio sistema operacional, ai em vez de criar uma
> > solução, tu cria um problema.
> >
> > Em 24/11/07, Welkson Renny de Medeiros
> > <[EMAIL PROTECTED]> escreveu:
> > >
>
> <<< CUT >>>
>
> --
> Nilton José Rizzo
> 805 Informatica
> Disseminado tecnologias
> 021 2413 9786
>
> -
> 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: Filtro L7

[Nilton Jose Rizzo]

On Sat, 24 Nov 2007 13:02:05 -0200, Klaus Schneider wrote


 Certa vez, assisti em uma demonstração de um sistema de controle
 via socket.  Era tudo fechado proxy/conexão direta, so conseguia
 sair via sochet, e nessa conexão os caras faziam filtros de aplicação
 não entraram muito em detalhes técnicos por mais que eram questionados,
 mas pode ser um caminho ... sei lá   só uma ideia


> Já vi alguns sistemas que fazem controle de p2p, mas eu acredito que 
> eles mesclem algumas tecnicas de Layer 7 com monitoramento de states,
>  tipo se o cara passa pelo layer 7 eles usam o state do firewall 
> para monitorar o trafego, se ultrapassar um certo período ou 
> quantidade de dados, eles alteram a classificacao do tráfego no 
> QoS(seja baixando a prioridade ou colocando a conexão em uma fila 
> mais lenta)... Não é tão complicado de fazer, e é o único meio que 
> imagino ser possível... o problema é que isso pode prejudicar a 
> conexão de quem esta simplismente baixando um arquivo para atualizar 
> um AV ou o próprio sistema operacional, ai em vez de criar uma 
> solução, tu cria um problema.
> 
> Em 24/11/07, Welkson Renny de Medeiros 
> <[EMAIL PROTECTED]> escreveu:
> >

<<< CUT >>>

-- 
Nilton José Rizzo 
805 Informatica 
Disseminado tecnologias 
021 2413 9786

-
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: Filtro L7

[Klaus Schneider]

Já vi alguns sistemas que fazem controle de p2p, mas eu acredito que eles
mesclem algumas tecnicas de Layer 7 com monitoramento de states, tipo se o
cara passa pelo layer 7 eles usam o state do firewall para monitorar o
trafego, se ultrapassar um certo período ou quantidade de dados, eles
alteram a classificacao do tráfego no QoS(seja baixando a prioridade ou
colocando a conexão em uma fila mais lenta)... Não é tão complicado de
fazer, e é o único meio que imagino ser possível... o problema é que isso
pode prejudicar a conexão de quem esta simplismente baixando um arquivo para
atualizar um AV ou o próprio sistema operacional, ai em vez de criar uma
solução, tu cria um problema.

Em 24/11/07, Welkson Renny de Medeiros <[EMAIL PROTECTED]>
escreveu:
>
> Essa semana mesmo eu estava vendo uns vídeos no youtube... uns caras
> falando
> sobre o shapping do provedor Virtua... eles conseguem controlar o tráfego
> p2p, mas quando o pessoal liga a criptografia eles não conseguem (tipo,
> sem
> criptografia os caras baixavam a 20kbps, quando ativa baixa a 200kbps)...
> o
> vídeo era extamente pra isso, comprovar que eles aplicam shapping...
>
> Welkson
>
> - Original Message -
> From: "Lucas Mocellin" <[EMAIL PROTECTED]>
> To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
> 
> Sent: Saturday, November 24, 2007 11:18 AM
> Subject: Re: [FUG-BR] RES: Filtro L7
>
>
> mas entao como o traffic shapping funciona? ele age em cima "do que"?
>
> Em 24/11/07, Welkson Renny de Medeiros<[EMAIL PROTECTED]>
> escreveu:
> > Acho que para tráfego criptografado nem aqueles patchs do linux
> > resolvem...
> > alguém confirma?
> >
> > Welkson
> >
> > - Original Message -
> > From: "Thiago Damas" <[EMAIL PROTECTED]>
> > To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
> > 
> > Sent: Saturday, November 24, 2007 11:01 AM
> > Subject: Re: [FUG-BR] RES: Filtro L7
> >
> >
> >  Esses trafegos obfuscados e criptografados, nao...
> >
> > On Nov 24, 2007 11:40 AM, Lucas Mocellin <[EMAIL PROTECTED]>
> wrote:
> > > Olá,
> > >
> > > então Eduardo, na verdade eu queria primeiro saber quem está usando e
> > > quanto de banda está consumindo, para depois TALVEZ fazer um traffic
> > > shapping ou bloquear, mas o principal é descobrir quanto de banda ta
> > > consumindo.
> > >
> > > Tenho uma situação parecida, um link de 18MB no talo..
> > >
> > > o seu script já não serve a minha ocasião, acho que o interessante
> > > seria pela cmaada 7 mesmo, ouvi falar que torrent usa um protocolo
> > > diferente que não é tão difícil de reconhecer.
> > >
> > > Você já conseguiu filtrar a camada 7 thiago??
> > >
> > > Obrigado
> > >
> > > Lucas.
> > >
> > > Em 23/11/07, Augusto Jobim Badaraco<[EMAIL PROTECTED]> escreveu:
> > >
> > > > Olá, sobre o mesmo assunto, alguém já verificou alguma coisa sobre o
> > > > ng_pf ?
> > > >
> > > >
> > > > -Mensagem original-
> > > > De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Em
> > > > nome de Thiago Damas
> > > > Enviada em: sexta-feira, 23 de novembro de 2007 11:33
> > > > Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
> > > > Assunto: Re: [FUG-BR] Filtro L7
> > > >
> > > >  Ja fiz programa pra escutar com divert, e ele pega o pacote
> inteiro.
> > > > Da pra fazer camada 7 sim, mas como roda no modo usuario, usa mais
> > > > recursos do que se fosse no modo kernel (ipfw divert -> modo usuario
> > > > -> volta pro kernel)
> > > >  Na epoca minha rede estava em +- 18Mbps e nao dava conta.
> > > >
> > > > On Oct 3, 2007 5:06 PM, Daniel Loureiro <[EMAIL PROTECTED]>
> wrote:
> > > > > Marcelo Soares da Costa escreveu:
> > > > >  > Filtrar conteudo = squid
> > > > >  >
> > > > >  > snort me parece que vc procura , pode usar ainda ipfw com
> dumynet
> > > > para
> > > > >  > controle de banda
> > > > >  >
> > > > >
> > > > > obrigado pela resposta Marcelo, mas o squid eu já uso para o
> > > > > conteúdo
> > > > > web. Eu queria controlar o uso de aplicativos como emule, msn,
> etc,
> > > > > independente da porta/ip usados. Algo como isto:
> > > > >
> > > > > http://l

Re: [FUG-BR] RES: Filtro L7

[Welkson Renny de Medeiros]

Essa semana mesmo eu estava vendo uns vídeos no youtube... uns caras falando 
sobre o shapping do provedor Virtua... eles conseguem controlar o tráfego 
p2p, mas quando o pessoal liga a criptografia eles não conseguem (tipo, sem 
criptografia os caras baixavam a 20kbps, quando ativa baixa a 200kbps)... o 
vídeo era extamente pra isso, comprovar que eles aplicam shapping...

Welkson

- Original Message - 
From: "Lucas Mocellin" <[EMAIL PROTECTED]>
To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)" 

Sent: Saturday, November 24, 2007 11:18 AM
Subject: Re: [FUG-BR] RES: Filtro L7


mas entao como o traffic shapping funciona? ele age em cima "do que"?

Em 24/11/07, Welkson Renny de Medeiros<[EMAIL PROTECTED]> 
escreveu:
> Acho que para tráfego criptografado nem aqueles patchs do linux 
> resolvem...
> alguém confirma?
>
> Welkson
>
> - Original Message -
> From: "Thiago Damas" <[EMAIL PROTECTED]>
> To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
> 
> Sent: Saturday, November 24, 2007 11:01 AM
> Subject: Re: [FUG-BR] RES: Filtro L7
>
>
>  Esses trafegos obfuscados e criptografados, nao...
>
> On Nov 24, 2007 11:40 AM, Lucas Mocellin <[EMAIL PROTECTED]> wrote:
> > Olá,
> >
> > então Eduardo, na verdade eu queria primeiro saber quem está usando e
> > quanto de banda está consumindo, para depois TALVEZ fazer um traffic
> > shapping ou bloquear, mas o principal é descobrir quanto de banda ta
> > consumindo.
> >
> > Tenho uma situação parecida, um link de 18MB no talo..
> >
> > o seu script já não serve a minha ocasião, acho que o interessante
> > seria pela cmaada 7 mesmo, ouvi falar que torrent usa um protocolo
> > diferente que não é tão difícil de reconhecer.
> >
> > Você já conseguiu filtrar a camada 7 thiago??
> >
> > Obrigado
> >
> > Lucas.
> >
> > Em 23/11/07, Augusto Jobim Badaraco<[EMAIL PROTECTED]> escreveu:
> >
> > > Olá, sobre o mesmo assunto, alguém já verificou alguma coisa sobre o
> > > ng_pf ?
> > >
> > >
> > > -Mensagem original-
> > > De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em
> > > nome de Thiago Damas
> > > Enviada em: sexta-feira, 23 de novembro de 2007 11:33
> > > Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
> > > Assunto: Re: [FUG-BR] Filtro L7
> > >
> > >  Ja fiz programa pra escutar com divert, e ele pega o pacote inteiro.
> > > Da pra fazer camada 7 sim, mas como roda no modo usuario, usa mais
> > > recursos do que se fosse no modo kernel (ipfw divert -> modo usuario
> > > -> volta pro kernel)
> > >  Na epoca minha rede estava em +- 18Mbps e nao dava conta.
> > >
> > > On Oct 3, 2007 5:06 PM, Daniel Loureiro <[EMAIL PROTECTED]> wrote:
> > > > Marcelo Soares da Costa escreveu:
> > > >  > Filtrar conteudo = squid
> > > >  >
> > > >  > snort me parece que vc procura , pode usar ainda ipfw com dumynet
> > > para
> > > >  > controle de banda
> > > >  >
> > > >
> > > > obrigado pela resposta Marcelo, mas o squid eu já uso para o 
> > > > conteúdo
> > > > web. Eu queria controlar o uso de aplicativos como emule, msn, etc,
> > > > independente da porta/ip usados. Algo como isto:
> > > >
> > > > http://l7-filter.sourceforge.net/protocols
> > > >
> > > > Poderia ser algo como:
> > > >
> > > > -> liberar msn para o 192.168.0.1
> > > > # ipfw add 10 allow app msn from 192.168.0.1 to any layer7
> > > >
> > > > -> banda reduzida para p2p
> > > > # ipfw add 20 pipe 1 app p2p any to any layer7
> > > >
> > > > Tentei eu mesmo fazer um filtro da seguinte forma: criei um programa
> > > > ouvindo a porta 5000 (com "IPPROTO_DIVERT") e usei o ipfw para
> > > > "divertar" (alguém traduza isto ;P) todo o tráfego para ele.
> > > >
> > > > # ipfw add 1 divert 5000 from any to any
> > > >
> > > > Isto funcionou bem, mas o problema é que o ipfw só repassa o 
> > > > cabeçalho
> > > > do pacote, sem os dados. Só o cabeçalho, é útil para fazer um filtro
> > > > L2/L3 (portas/ip/mac), mas é inútil para fazer um filtro L7 (ex.,
> > > > procurar pela palavra "proto-x-donkey" nos dados).
> > > >
> > > >  > http://freebsd.rogness.net/snort_inline/
&g

Re: [FUG-BR] RES: Filtro L7

[Lucas Mocellin]

mas entao como o traffic shapping funciona? ele age em cima "do que"?

Em 24/11/07, Welkson Renny de Medeiros<[EMAIL PROTECTED]> escreveu:
> Acho que para tráfego criptografado nem aqueles patchs do linux resolvem...
> alguém confirma?
>
> Welkson
>
> - Original Message -
> From: "Thiago Damas" <[EMAIL PROTECTED]>
> To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
> 
> Sent: Saturday, November 24, 2007 11:01 AM
> Subject: Re: [FUG-BR] RES: Filtro L7
>
>
>  Esses trafegos obfuscados e criptografados, nao...
>
> On Nov 24, 2007 11:40 AM, Lucas Mocellin <[EMAIL PROTECTED]> wrote:
> > Olá,
> >
> > então Eduardo, na verdade eu queria primeiro saber quem está usando e
> > quanto de banda está consumindo, para depois TALVEZ fazer um traffic
> > shapping ou bloquear, mas o principal é descobrir quanto de banda ta
> > consumindo.
> >
> > Tenho uma situação parecida, um link de 18MB no talo..
> >
> > o seu script já não serve a minha ocasião, acho que o interessante
> > seria pela cmaada 7 mesmo, ouvi falar que torrent usa um protocolo
> > diferente que não é tão difícil de reconhecer.
> >
> > Você já conseguiu filtrar a camada 7 thiago??
> >
> > Obrigado
> >
> > Lucas.
> >
> > Em 23/11/07, Augusto Jobim Badaraco<[EMAIL PROTECTED]> escreveu:
> >
> > > Olá, sobre o mesmo assunto, alguém já verificou alguma coisa sobre o
> > > ng_pf ?
> > >
> > >
> > > -Mensagem original-
> > > De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em
> > > nome de Thiago Damas
> > > Enviada em: sexta-feira, 23 de novembro de 2007 11:33
> > > Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
> > > Assunto: Re: [FUG-BR] Filtro L7
> > >
> > >  Ja fiz programa pra escutar com divert, e ele pega o pacote inteiro.
> > > Da pra fazer camada 7 sim, mas como roda no modo usuario, usa mais
> > > recursos do que se fosse no modo kernel (ipfw divert -> modo usuario
> > > -> volta pro kernel)
> > >  Na epoca minha rede estava em +- 18Mbps e nao dava conta.
> > >
> > > On Oct 3, 2007 5:06 PM, Daniel Loureiro <[EMAIL PROTECTED]> wrote:
> > > > Marcelo Soares da Costa escreveu:
> > > >  > Filtrar conteudo = squid
> > > >  >
> > > >  > snort me parece que vc procura , pode usar ainda ipfw com dumynet
> > > para
> > > >  > controle de banda
> > > >  >
> > > >
> > > > obrigado pela resposta Marcelo, mas o squid eu já uso para o conteúdo
> > > > web. Eu queria controlar o uso de aplicativos como emule, msn, etc,
> > > > independente da porta/ip usados. Algo como isto:
> > > >
> > > > http://l7-filter.sourceforge.net/protocols
> > > >
> > > > Poderia ser algo como:
> > > >
> > > > -> liberar msn para o 192.168.0.1
> > > > # ipfw add 10 allow app msn from 192.168.0.1 to any layer7
> > > >
> > > > -> banda reduzida para p2p
> > > > # ipfw add 20 pipe 1 app p2p any to any layer7
> > > >
> > > > Tentei eu mesmo fazer um filtro da seguinte forma: criei um programa
> > > > ouvindo a porta 5000 (com "IPPROTO_DIVERT") e usei o ipfw para
> > > > "divertar" (alguém traduza isto ;P) todo o tráfego para ele.
> > > >
> > > > # ipfw add 1 divert 5000 from any to any
> > > >
> > > > Isto funcionou bem, mas o problema é que o ipfw só repassa o cabeçalho
> > > > do pacote, sem os dados. Só o cabeçalho, é útil para fazer um filtro
> > > > L2/L3 (portas/ip/mac), mas é inútil para fazer um filtro L7 (ex.,
> > > > procurar pela palavra "proto-x-donkey" nos dados).
> > > >
> > > >  > http://freebsd.rogness.net/snort_inline/
> > > >
> > > > O snort_inline usa o mesmo esquema que eu reproduzi. Como o ipfw só
> > > > repassa cabeçalhos, o máximo que ele vai fazer é filtrar por
> > > > ip/mac/porta, e não pelo conteúdo do pacote.
> > > >
> > > > Se alguém tiver mais alguma idéia...
> > > >
> > > > Sds,
> > > > Daniel Loureiro.
> > > >
> > > >
> > > > -
> > > > 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: Filtro L7

[Welkson Renny de Medeiros]

Acho que para tráfego criptografado nem aqueles patchs do linux resolvem... 
alguém confirma?

Welkson

- Original Message - 
From: "Thiago Damas" <[EMAIL PROTECTED]>
To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)" 

Sent: Saturday, November 24, 2007 11:01 AM
Subject: Re: [FUG-BR] RES: Filtro L7


  Esses trafegos obfuscados e criptografados, nao...

On Nov 24, 2007 11:40 AM, Lucas Mocellin <[EMAIL PROTECTED]> wrote:
> Olá,
>
> então Eduardo, na verdade eu queria primeiro saber quem está usando e
> quanto de banda está consumindo, para depois TALVEZ fazer um traffic
> shapping ou bloquear, mas o principal é descobrir quanto de banda ta
> consumindo.
>
> Tenho uma situação parecida, um link de 18MB no talo..
>
> o seu script já não serve a minha ocasião, acho que o interessante
> seria pela cmaada 7 mesmo, ouvi falar que torrent usa um protocolo
> diferente que não é tão difícil de reconhecer.
>
> Você já conseguiu filtrar a camada 7 thiago??
>
> Obrigado
>
> Lucas.
>
> Em 23/11/07, Augusto Jobim Badaraco<[EMAIL PROTECTED]> escreveu:
>
> > Olá, sobre o mesmo assunto, alguém já verificou alguma coisa sobre o
> > ng_pf ?
> >
> >
> > -Mensagem original-
> > De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em
> > nome de Thiago Damas
> > Enviada em: sexta-feira, 23 de novembro de 2007 11:33
> > Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
> > Assunto: Re: [FUG-BR] Filtro L7
> >
> >  Ja fiz programa pra escutar com divert, e ele pega o pacote inteiro.
> > Da pra fazer camada 7 sim, mas como roda no modo usuario, usa mais
> > recursos do que se fosse no modo kernel (ipfw divert -> modo usuario
> > -> volta pro kernel)
> >  Na epoca minha rede estava em +- 18Mbps e nao dava conta.
> >
> > On Oct 3, 2007 5:06 PM, Daniel Loureiro <[EMAIL PROTECTED]> wrote:
> > > Marcelo Soares da Costa escreveu:
> > >  > Filtrar conteudo = squid
> > >  >
> > >  > snort me parece que vc procura , pode usar ainda ipfw com dumynet
> > para
> > >  > controle de banda
> > >  >
> > >
> > > obrigado pela resposta Marcelo, mas o squid eu já uso para o conteúdo
> > > web. Eu queria controlar o uso de aplicativos como emule, msn, etc,
> > > independente da porta/ip usados. Algo como isto:
> > >
> > > http://l7-filter.sourceforge.net/protocols
> > >
> > > Poderia ser algo como:
> > >
> > > -> liberar msn para o 192.168.0.1
> > > # ipfw add 10 allow app msn from 192.168.0.1 to any layer7
> > >
> > > -> banda reduzida para p2p
> > > # ipfw add 20 pipe 1 app p2p any to any layer7
> > >
> > > Tentei eu mesmo fazer um filtro da seguinte forma: criei um programa
> > > ouvindo a porta 5000 (com "IPPROTO_DIVERT") e usei o ipfw para
> > > "divertar" (alguém traduza isto ;P) todo o tráfego para ele.
> > >
> > > # ipfw add 1 divert 5000 from any to any
> > >
> > > Isto funcionou bem, mas o problema é que o ipfw só repassa o cabeçalho
> > > do pacote, sem os dados. Só o cabeçalho, é útil para fazer um filtro
> > > L2/L3 (portas/ip/mac), mas é inútil para fazer um filtro L7 (ex.,
> > > procurar pela palavra "proto-x-donkey" nos dados).
> > >
> > >  > http://freebsd.rogness.net/snort_inline/
> > >
> > > O snort_inline usa o mesmo esquema que eu reproduzi. Como o ipfw só
> > > repassa cabeçalhos, o máximo que ele vai fazer é filtrar por
> > > ip/mac/porta, e não pelo conteúdo do pacote.
> > >
> > > Se alguém tiver mais alguma idéia...
> > >
> > > Sds,
> > > Daniel Loureiro.
> > >
> > >
> > > -
> > > 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
> >
> >
> > __ Informação do NOD32 IMON 2681 (20071123) __
> >
> > Esta mensagem foi verificada pelo NOD32 sistema antivírus
> > http://www.eset.com.br
> >
> >
> > -
> > 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

Re: [FUG-BR] RES: Filtro L7

[Thiago Damas]

  Esses trafegos obfuscados e criptografados, nao...

On Nov 24, 2007 11:40 AM, Lucas Mocellin <[EMAIL PROTECTED]> wrote:
> Olá,
>
> então Eduardo, na verdade eu queria primeiro saber quem está usando e
> quanto de banda está consumindo, para depois TALVEZ fazer um traffic
> shapping ou bloquear, mas o principal é descobrir quanto de banda ta
> consumindo.
>
> Tenho uma situação parecida, um link de 18MB no talo..
>
> o seu script já não serve a minha ocasião, acho que o interessante
> seria pela cmaada 7 mesmo, ouvi falar que torrent usa um protocolo
> diferente que não é tão difícil de reconhecer.
>
> Você já conseguiu filtrar a camada 7 thiago??
>
> Obrigado
>
> Lucas.
>
> Em 23/11/07, Augusto Jobim Badaraco<[EMAIL PROTECTED]> escreveu:
>
> > Olá, sobre o mesmo assunto, alguém já verificou alguma coisa sobre o
> > ng_pf ?
> >
> >
> > -Mensagem original-
> > De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em
> > nome de Thiago Damas
> > Enviada em: sexta-feira, 23 de novembro de 2007 11:33
> > Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
> > Assunto: Re: [FUG-BR] Filtro L7
> >
> >  Ja fiz programa pra escutar com divert, e ele pega o pacote inteiro.
> > Da pra fazer camada 7 sim, mas como roda no modo usuario, usa mais
> > recursos do que se fosse no modo kernel (ipfw divert -> modo usuario
> > -> volta pro kernel)
> >  Na epoca minha rede estava em +- 18Mbps e nao dava conta.
> >
> > On Oct 3, 2007 5:06 PM, Daniel Loureiro <[EMAIL PROTECTED]> wrote:
> > > Marcelo Soares da Costa escreveu:
> > >  > Filtrar conteudo = squid
> > >  >
> > >  > snort me parece que vc procura , pode usar ainda ipfw com dumynet
> > para
> > >  > controle de banda
> > >  >
> > >
> > > obrigado pela resposta Marcelo, mas o squid eu já uso para o conteúdo
> > > web. Eu queria controlar o uso de aplicativos como emule, msn, etc,
> > > independente da porta/ip usados. Algo como isto:
> > >
> > > http://l7-filter.sourceforge.net/protocols
> > >
> > > Poderia ser algo como:
> > >
> > > -> liberar msn para o 192.168.0.1
> > > # ipfw add 10 allow app msn from 192.168.0.1 to any layer7
> > >
> > > -> banda reduzida para p2p
> > > # ipfw add 20 pipe 1 app p2p any to any layer7
> > >
> > > Tentei eu mesmo fazer um filtro da seguinte forma: criei um programa
> > > ouvindo a porta 5000 (com "IPPROTO_DIVERT") e usei o ipfw para
> > > "divertar" (alguém traduza isto ;P) todo o tráfego para ele.
> > >
> > > # ipfw add 1 divert 5000 from any to any
> > >
> > > Isto funcionou bem, mas o problema é que o ipfw só repassa o cabeçalho
> > > do pacote, sem os dados. Só o cabeçalho, é útil para fazer um filtro
> > > L2/L3 (portas/ip/mac), mas é inútil para fazer um filtro L7 (ex.,
> > > procurar pela palavra "proto-x-donkey" nos dados).
> > >
> > >  > http://freebsd.rogness.net/snort_inline/
> > >
> > > O snort_inline usa o mesmo esquema que eu reproduzi. Como o ipfw só
> > > repassa cabeçalhos, o máximo que ele vai fazer é filtrar por
> > > ip/mac/porta, e não pelo conteúdo do pacote.
> > >
> > > Se alguém tiver mais alguma idéia...
> > >
> > > Sds,
> > > Daniel Loureiro.
> > >
> > >
> > > -
> > > 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
> >
> >
> > __ Informação do NOD32 IMON 2681 (20071123) __
> >
> > Esta mensagem foi verificada pelo NOD32 sistema antivírus
> > http://www.eset.com.br
> >
> >
> > -
> > 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

Re: [FUG-BR] RES: Filtro L7

[Lucas Mocellin]

Olá,

então Eduardo, na verdade eu queria primeiro saber quem está usando e
quanto de banda está consumindo, para depois TALVEZ fazer um traffic
shapping ou bloquear, mas o principal é descobrir quanto de banda ta
consumindo.

Tenho uma situação parecida, um link de 18MB no talo..

o seu script já não serve a minha ocasião, acho que o interessante
seria pela cmaada 7 mesmo, ouvi falar que torrent usa um protocolo
diferente que não é tão difícil de reconhecer.

Você já conseguiu filtrar a camada 7 thiago??

Obrigado

Lucas.

Em 23/11/07, Augusto Jobim Badaraco<[EMAIL PROTECTED]> escreveu:
> Olá, sobre o mesmo assunto, alguém já verificou alguma coisa sobre o
> ng_pf ?
>
>
> -Mensagem original-
> De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em
> nome de Thiago Damas
> Enviada em: sexta-feira, 23 de novembro de 2007 11:33
> Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
> Assunto: Re: [FUG-BR] Filtro L7
>
>  Ja fiz programa pra escutar com divert, e ele pega o pacote inteiro.
> Da pra fazer camada 7 sim, mas como roda no modo usuario, usa mais
> recursos do que se fosse no modo kernel (ipfw divert -> modo usuario
> -> volta pro kernel)
>  Na epoca minha rede estava em +- 18Mbps e nao dava conta.
>
> On Oct 3, 2007 5:06 PM, Daniel Loureiro <[EMAIL PROTECTED]> wrote:
> > Marcelo Soares da Costa escreveu:
> >  > Filtrar conteudo = squid
> >  >
> >  > snort me parece que vc procura , pode usar ainda ipfw com dumynet
> para
> >  > controle de banda
> >  >
> >
> > obrigado pela resposta Marcelo, mas o squid eu já uso para o conteúdo
> > web. Eu queria controlar o uso de aplicativos como emule, msn, etc,
> > independente da porta/ip usados. Algo como isto:
> >
> > http://l7-filter.sourceforge.net/protocols
> >
> > Poderia ser algo como:
> >
> > -> liberar msn para o 192.168.0.1
> > # ipfw add 10 allow app msn from 192.168.0.1 to any layer7
> >
> > -> banda reduzida para p2p
> > # ipfw add 20 pipe 1 app p2p any to any layer7
> >
> > Tentei eu mesmo fazer um filtro da seguinte forma: criei um programa
> > ouvindo a porta 5000 (com "IPPROTO_DIVERT") e usei o ipfw para
> > "divertar" (alguém traduza isto ;P) todo o tráfego para ele.
> >
> > # ipfw add 1 divert 5000 from any to any
> >
> > Isto funcionou bem, mas o problema é que o ipfw só repassa o cabeçalho
> > do pacote, sem os dados. Só o cabeçalho, é útil para fazer um filtro
> > L2/L3 (portas/ip/mac), mas é inútil para fazer um filtro L7 (ex.,
> > procurar pela palavra "proto-x-donkey" nos dados).
> >
> >  > http://freebsd.rogness.net/snort_inline/
> >
> > O snort_inline usa o mesmo esquema que eu reproduzi. Como o ipfw só
> > repassa cabeçalhos, o máximo que ele vai fazer é filtrar por
> > ip/mac/porta, e não pelo conteúdo do pacote.
> >
> > Se alguém tiver mais alguma idéia...
> >
> > Sds,
> > Daniel Loureiro.
> >
> >
> > -
> > 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
>
>
> __ Informação do NOD32 IMON 2681 (20071123) __
>
> Esta mensagem foi verificada pelo NOD32 sistema antivírus
> http://www.eset.com.br
>
>
> -
> 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