Problème de filtrage Internet
mardi 13 janvier 2004, par Benoît Thébaud
Fonctionnement du filtrage Internet sur Comedu
Etape 1
Lors de la demande par le navigateur (Internet Explorer, Firefox ou autre Opéra)
d’un site Internet, le proxy Squid demande une authentification. Cette
authentification est basée sur les logins et mots de passe stockés sur le
serveur Linux lors de la création des utilisateurs (fichiers /etc/passwd et
/etc/shadow). Dans 99,99 % des cas, le refus de l’identification à cette étape
est due à une mauvaise saisie (ou parfois à la persistance dans le navigateur
des coordonnées du dernier utilisateur qui a cru bon de cliquer dans la case "se
souvenir du mot de passe" dans IE).
Etape 2
Squid "passe" ensuite la main à SquidGuard qui vérifie d’abord l’autorisation pa
r classe (lien Autorisation Internet dans l’interface Comedu qui lit en fait
les fichiers classes dans /usr/share/squidGuard-1.1.4/db2/users/). Si l’élève ou
la classe ne sont pas autorisés, une page d’interdiction apparaît (Groupe du
client Default, catégorie None).
Etape 3
SquidGuard vérifie ensuite les types de sites autorisés par classe (liste noire
ou blanche, groupes Adult ....). Là encore une page d’interdiction apparaît si
le site est interdit mais avec l’indication de la classe et de la catégorie
interdite (adult ...).
Deux autres cas de figure :
 squid est "tombé" suite à un trop gros nombre de connexions (rare mais arrive
parfois dans les grands établissements) : pas de demande d’authentification et
page d’erreur.
squidGuard est "hors service" suite à des manipulations de création ou
suppression d’utilisateur "un peu rapides" : demande d’authentification mais pas
de filtrage, tout est autorisé, c’est la fête ;-)
pas d’Internet : demande d’authentication puis page d’erreur. Direction plan
B, sortez vos cahiers ...
N’hésitez pas à tenter en mode console sur le serveur un :
ping www.google.fr
pour vérifier que l’accès Internet est bien indisponible sur le serveur.
Paramétrage de SquidGuard
Si après la demande d’authentification dans le navigateur Internet, les élèves ne se voient pas refuser les sites interdits, il y a de fortes chances que SquidGuard, le logiciel de filtrage, soit "en panne".
En effet, le paramétrage de ce programme à travers Webmin est assez délicat et surtout ne comporte pas de contrôle d’erreurs. Ainsi si vous avez oublié une indication, le module de Webmin ne vous avertira pas mais SquidGuard ne fonctionnera plus.
Pour vérifier ceci, faites apparaître les dernières lignes des logs en tapant cette commande dans une console sur le serveur ou à distance via Putty :
tail /var/log/squidGuard/squidGuard.log
et /ou
tail /var/log/squid/squidGuard.log
Si c’est le cas, vous devriez lire ces lignes :
2004-01-13 22:09:38 [4046] parse error in
configfile /etc/squid/squidGuard.conf line 20
2004-01-13 22:09:38 [4046] going into emergency mode
Il faut alors modifier le fichier /etc/squid/squidGuard.conf pour "réparer" les erreurs.
le fichier squidGuard.conf original
#----------------------------------------------------------------
# DO NOT MODIFY THIS FILE AS IT IS MODIFIED BY THE TEMPLATE
#----------------------------------------------------------------
# SquidGuard CONFIGURATION FILE
#----------------------------------------------------------------
# CONFIGURATION DIRECTORIES
dbhome /usr/share/squidGuard-1.1.4/db2
logdir /var/log/squidGuard
# TIME RULES:
# abbrev for weekdays:
# s = sun, m = mon, t =tue, w = wed, h = thu, f = fri, a = sat
# SOURCE ADDRESSES:
src profs {
userlist user/profs
}
src eleves {
userlist user/eleves
}
# DESTINATION CLASSES:
dest adult {
domainlist adult/domains
urllist adult/urls
expressionlist adult/expressions
}
../..
dest violence {
domainlist violence/domains
urllist violence/urls
expressionlist violence/expressions
}
# ACLs
acl {
eleves {
pass none
redirect http://127.0.0.1/cgi-bin/squidGuard.cgi?clientaddr=%a&srcclass=%s&targetclass=%t&url=%u
}
profs {
pass !warez any
redirect http://127.0.0.1/cgi-bin/squidGuard.cgi?clientaddr=%a&srcclass=%s&targetclass=%t&url=%u
}
default {
pass none
redirect http://127.0.0.1/cgi-bin/squidGuard.cgi?clientaddr=%a&srcclass=%s&targetclass=%t&url=%u
}
}
le fichier squidGuard.conf après création des classes
Voici le fichier après la création d’un groupe Interdits (Destination Groups) et de deux classes (sixa puis sixb) puis affectation à ces classes des droits "Any" sauf !violence ...etc.
#----------------------------------------------------------------
# DO NOT MODIFY THIS FILE AS IT IS MODIFIED BY THE TEMPLATE
#----------------------------------------------------------------
# SquidGuard CONFIGURATION FILE
#----------------------------------------------------------------
# CONFIGURATION DIRECTORIES
dbhome /usr/share/squidGuard-1.1.4/db2
logdir /var/log/squidGuard
# TIME RULES:
# abbrev for weekdays:
# s = sun, m = mon, t =tue, w = wed, h = thu, f = fri, a = sat
# SOURCE ADDRESSES:
# COMEDU_FLAG
src sixb {
userlist user/sixb
}
src sixa {
userlist user/sixa
}
src profs {
userlist user/profs
}
src eleves {
userlist user/eleves
}
# DESTINATION CLASSES:
destination Interdits {
domainlist Interdits.destdomainlist
}
dest adult {
domainlist adult/domains
urllist adult/urls
expressionlist adult/expressions
}
../..
dest violence {
domainlist violence/domains
urllist violence/urls
expressionlist violence/expressions
}
# ACLs
acl {
eleves {
pass none
redirect http://127.0.0.1/cgi-bin/squidGuard.cgi?clientaddr=%a&srcclass=%s&targetclass=%t&url=%u
}
profs {
pass !warez any
redirect http://127.0.0.1/cgi-bin/squidGuard.cgi?clientaddr=%a&srcclass=%s&targetclass=%t&url=%u
}
default {
pass none
redirect http://127.0.0.1/cgi-bin/squidGuard.cgi?clientaddr=%a&srcclass=%s&targetclass=%t&url=%u
}
sixa {
pass !in-addr !Interdits !adult !audio-video !forums !hacking !mail !proxy !redirector !warez !ads !aggressive !drugs !gambling !publicite !violence any
redirect http://127.0.0.1/cgi-bin/squidGuard.cgi?clientaddr=%a&srcclass=%s&targetclass=%t&url=%u
}
sixb {
pass !in-addr !Interdits !adult !audio-video !forums !hacking !mail !proxy !redirector !warez !ads !aggressive !drugs !gambling !publicite !violence any
redirect http://127.0.0.1/cgi-bin/squidGuard.cgi?clientaddr=%a&srcclass=%s&targetclass=%t&url=%u
}
# COMEDU_FIN
}
Explication des modifications
Il faut toujours une correspondance entre les "SOURCE ADDRESSES" et les "ACLs".
Ainsi pour la classe sixb :
# SOURCE ADDRESSES:
../..
src sixb {
userlist user/sixb
}
../..
# ACLs
acl {
../..
sixb {
pass !in-addr !Interdits !adult !audio-video !forums !hacking !mail !proxy !redirector !warez !ads !aggressive !drugs !gambling !publicite !violence any
redirect http://127.0.0.1/cgi-bin/squidGuard.cgi?clientaddr=%a&srcclass=%s&targetclass=%t&url=%u
}
Après correction, il faut redémarrer squid en mode console :
service squid restart
puis vérifier le bon fonctionnement de squidguard :
tail /var/log/squidGuard/squidGuard.log
Le résultat devrait être :
2004-01-13 22:22:57 [4135] squidGuard 1.1.4 started (1074028977.059)
2004-01-13 22:22:57 [4135] squidGuard ready for requests (1074028977.069)
Les raisons de dysfonctionnement de SquidGuard peuvent être fort diverses mais sont généralement toujours liéés à une incohérence entre le fichier SquidGuard.conf et la réalité (classes créées puis supprimées un peu rapidement, manipulations "manuelles" des listes de sites ...etc).
Vous en trouverez quelques exemples dans le forum associé à cet article.
Par la suite, il est plus facile de surveiller le fonctionnement de SquidGuard dans Webmin en rajoutant dans Système-Analyse des Logs-Add a new system log la ligne /var/log/squidGuard/squidGuard.log avec l’indication Facilities positionnée à All. Il suffira ensuite de cliquer sur view pour lister les dernières lignes du fichier.
[ Imprimer cet article ] [ Haut ] []
|
Site développé avec 