Re: [squid-br] (very longo) Re: SquidGuard não entende rede 10.0.0.0/8

Sat, 20 May 2006 16:50:55 -0700

Companheiro,

Acho que chegamos a um sincronismo no nosso raciocínio. Apesar de eu não ter procurado e esmiuçado tão bem o assunto quanto você eu entendi o fato da ordem das SRC, já que neste exemplo de dois níveis eu conesgui fazer as coisas funcionarem.

Já que você já entrou no barco, veja mais este caso com 3 níveis de rede (este sim é o que me interessa) e que não funcionou:

src administrador {
  ip 10.20.168.56
}
src dirad {
  ip 10.20.168.0/24
}
src dipeq {
  ip 10.20.169.0/24
}
src todarede {
  ip 10.0.0.0/8
}

Observe que Eu tenho um IP isolado ("administrador") dentro de uma faixa de subrede ("dirad") e duas faixas de subrede na rede geral. Considerando aquelas "SRC" exatamente na ordem apresentada (que pelo que testamos estaria na ordem correta) veja o que acontece em um conjunto de testes onde eu tenho uma ACL para tratar cada respectiva SRC:

- ACL para o IP "administrador" (10.20.168.56) - Funciona bem
- ACL para a subrede "dirad" (10.20.168.0/24) - Funciona bem
- ACL para a subrede "dipeq" (10.20.169.0/24) - Funciona bem
- ACL para a a rede toda (10.0.0.0/8) - Não funciona

Observe que quando eu digo funciona/não funciona me refiro ao teste com IPs que estão dentro de cada faixa e o SquidGuard disparou as respectivas ACLs. Eu fiz os testes com os seguintes IPs:
10.20.168.56  (Casa com "administrador")
10.20.168.14 (Casa com "dirad")
10.20.168.200 (Casa com "dirad")
10.20.169.80 (Casa com "dipeq")
10.20.169.100 (Casa com "dipeq")
10.30.150.10 (DEVERIA CASAR com "todarede" - Mas não casa - Cai na ACL default)
10.15.20.30 (DEVERIA CASAR com "todarede" - Mas não casa - Cai na ACL default)


Em 19/05/06, jmhenrique <[EMAIL PROTECTED]> escreveu:
Welington, td bem ? Eu de novo!
Acho que decifrei, em parte, a charada.

Está documentado sim, mas de forma sutil, e sem maiores explicações
,na documentação oficial.
http://www.squidguard.org/config/#example05

src grownups {
ip 10.0.0.0/24 # range 10.0.0.0  - 10.0.0.255
}
src kids {
ip 10.0.0.0/22 # range 10.0.0.0 - 10.0.3.255
}
....

perceba que o range aumenta de cima pra baixo na ordem das acls.
Parece até o seu caso.

no src grownups  temos um range que vai de 10.0.0.0 ate 10.0.0.255 e
na src abaixo, o range engloba todo o range da src de cima e mais um
pouco, de 10.0.0.0 até 10.0.3.255.

Isso realmente não está explicado explicitamente na documentação,
mas no fórum deles tem bastante coisa correlata. E imaginando o
mesmo esquema do squid, em que a primeira acl que for casada
automaticamente faz com que o squid ignore as próximas acls, o
squidguard deve seguir o mesmo modelo em relação as origens: a
primeira que casar automaticamente ignora as próximas. No squid isso
não é feito com as acls, mas sim com os http_access e  similares, e
este é um cuidado que temos que ter ao definir a ordem de
quem-ou-o-que está liberado no squid.

você nunca veria este exemplo abaixo em nenhum site, referente a uma
configuração incorreta do squid:

acl subrede1 src 10.20.169.0/24
acl redetoda src 10.0.0.0/8

http_access allow redetoda
http_access deny subrede1

Justamente porque está errada no seu propósito, pois do modo como
está, irá liberar toda a sua rede, não importando a linha com
o "http_access deny subrede1", isso porque se o cliente estiver
usando o micro 10.20.169.12 ele estará na redetoda, e casará
primeiro uma regra que está liberando tudo.

Usando a mesma analogia, pelo visto o squidguard trata a ordem das
src's e não das acls, como é feito no squid.

Realmente nunca tinha parado para pensar neste aspecto do
squidguard, especialmente pq não uso varias redes ou várias
definições para diferentes redes, e somente uso a acl default com N
dsts.

Como esse tema me interessa também, fucei mais um pouco com olhos
mais criticos e descobri estas linhas abaixo, do faq-plus, de 2004,
e que falam sobre o squid não fornecer todos os bits de
endereçamento e ser preciso adicionar um parametro no squid.conf
para que ele o faça.
http://www.maynidea.com/squidguard/faq-plus.html#nosrcip

achei meio estranho, tanto por conter 'nunca trabalharemos com a
Berkeley 4.0'  quanto por já terem se passado várias versões de
squid.

Com relação a colocar todas as maquinas em um grande txt, o site
desaconselha por  questões de performance. Assim como ele tbm
desaconselha usar regex complexas. Agora, vai lá saber o que eles
entendem como complexas... rs

e só pra confirmar, lendo os sources do squidguard(estou fazendo
isso agora) é isso mesmo! ele faz tudo a partir do src:

Current changes in the upcomming release 1.2.0:

2001-06-01      The source block takes a new argument: continue.
With this command an ipaddress or user can be configured in serval
sourceblocks. If a client is found but not blocked, squidGuard
will continue to search in the next source block, if the continue
command is defined. Thanks to Valentin Chopov for the patch

testei e não deu erro, pelo menos.  Lendo mais um pouco, achei algo
que outro dia alguém comentou comigo, de quotas de horario. Uma pena
que não funcionou aqui, o patch que a debian aplica automaticamente
retira essa característica, ou ela não funciona mesmo ou os patches
são incompativeis com isso... seria mto interessante pra mta gente,
ter N tempo de navegação por usuário ou por máquina ou por rede a
cada X horas/dias/semanas. Um único porém que eu li no forum é que
isso influenciava na performance do servidor. Mas tbm eles estavam
falando de 10.000 alunos... hehehe
até tentei compilar aplicando um mega-patche distribuido pela
http://linuxbox.com/tiki/tiki-index.php?page=squidGuard , mas cai no
mesmo dilema de quem compilou mas não fez bloqueio algum, deve ser a
tal do db4... ou o ldap. Ou ambos, ou eu mesmo.
Talvez se eu compilasse sem nenhum patch, usando a db3.x e me
sujeitando a alguns overflows e em um ambiente pequeno a médio (uma
lan house, ou um lab de 30 maquinas, por ex) eu conseguiria rodar
esse treco de quotauser tranquilamente.

[ ],s
Henry


--- Em [email protected], "Welington R. Braga"
<[EMAIL PROTECTED]> escreveu
>
> Fazendo mais alguns teste aqui, percebi uma coisa que não está
documentado
> (pelo menos não achei). A ordem dos "src" importa no casamento das
regras.
> Ex.:
> src administrador {
>   ip 10.20.168.56
> }
> src minharede {
>   ip 10.0.0.0/8
> }
>
> Se tiver uma acl para tratar cada caso desse e houver uma
requisição de
> 10.20.168.56 a ACL para "administrador" será acionada na boa. Mas
se a ordem
> dos "src" acima for invertida assim.
> Ex.:
> src minharede {
>   ip 10.0.0.0/8
> }
> src administrador {
>   ip 10.20.168.56
> }
>
> A ACL para "minharede" SEMPRE será acionada e nunca chegará a ACL
para
> adminsitrador. Independente da ordem das ACLs ao que parece o
importante é a
> ordem dos SRC.
>
> Alguém pode confirmar isso ?






Enviar mensagem: [email protected]
Assinar:  [EMAIL PROTECTED]
Cancelar assinatura:  [EMAIL PROTECTED]
Proprietário da lista:  [EMAIL PROTECTED]


Yahoo! Grupos, um serviço oferecido por:
PUBLICIDADE

Links do Yahoo! Grupos



--
Welington Rodrigues Braga
Instalar o Windows é humano, insistir em usar é burrice

Enviar mensagem: [email protected]
Assinar:  [EMAIL PROTECTED]
Cancelar assinatura:  [EMAIL PROTECTED]
Proprietário da lista:  [EMAIL PROTECTED]


Yahoo! Grupos, um serviço oferecido por:
PUBLICIDADE

Links do Yahoo! Grupos

Responder a