[Squid3 + squidGuard et supernichons] iptables pour un nul

Support Debian
#1

Bonjour à tous,
voilà, j’ai installé squid3 en ne touchant pour le moment à rien au fichier de configuration, j’ai ensuite réglé firefox pour qu’il utilise squid (port 3128), et là je m’attendais être tout bloqué de partout, (comme mon dos en ce moment !), et bien pas du tout, j’ai même pu aller lire mon ip sur un site comme mon-ip.com ! (?)
Je joins une capture de la configuration de firefox, de mon ip et mon squid.conf :

acl manager proto cache_object acl localhost src 127.0.0.1/32 ::1 acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1 acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT http_access allow manager localhost http_access deny manager http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow localhost http_access deny all http_port 3128 hierarchy_stoplist cgi-bin ? coredump_dir /var/spool/squid3 refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern . 0 20% 4320
Si quelqu’un peut m’expliquer pourquoi je ne me retrouve pas dans la même situation que celle donnée ici : http://irp.nain-t.net/doku.php/start rubrique squid.
Je ne vois pas la différence entre sa configuration et la mienne.

Merci d’avance



#2

Salut,
C’est normal.

Squid est sur ta machine, il accepte les connexions de localhost (http_access allow localhost), donc tu peux l’utiliser.
Par contre une autre machine sur ton réseau, non.

#3

Mince, je n’avais strictement rien compris !
Merci donc, c’est ma propre machine que je veux filtrer (plus précisément deux comptes de cette machine).
Bon je vais donc continuer, il faudra que je passe à squidguard ensuite, ça risque d’être du bon encore une fois !

#4

Salut,

[quote=“cauchy”]
…il faudra que je passe à squidguard ensuite, ça risque d’être du bon encore une fois ![/quote]

Concernant SquidGuard.

Un fil à suivre sans aucun doute, de fran.b … Installation Squid et SquidGuard et configuration

yapuka … :wink:

#5

Bon, j’ai avancé : configuration de squid.conf, de squidguard.conf,
puis pour (re)construire la base de données des listes noires de l’UT1
j’ai fait un root@debian:/home/zeus# su proxy $ squidGuard -C all
et cela fait 4 h que c’est comme ça ! Cela fait un peu beaucoup je trouve :think: (?).

#6

Bon je viens de voir ça dans le squidguard.log :

2012-03-15 07:43:19 [2520] New setting: dbhome: /var/lib/squidguard/db 2012-03-15 07:43:19 [2520] New setting: logdir: /var/log/squid 2012-03-15 07:43:19 [2520] init domainlist /var/lib/squidguard/db/adult/domains 2012-03-15 07:43:19 [2520] Error db_open: No such file or directory 2012-03-15 07:43:19 [2520] Going into emergency mode
Heu c’est quoi l’erreur de db_open ?

#7

je crois que je commence à comprendre :confused: (c’est un forum maïeuticien ou quoi ?)

root@debian:/home/zeus# cd /var/lib/squidguard/db/ root@debian:/var/lib/squidguard/db# ls -l total 11932 drwxr-sr-x 48 proxy proxy 4096 14 mars 21:17 blacklists -rw-r--r-- 1 root proxy 12210635 14 mars 21:17 blacklists.tar.gz root@debian:/var/lib/squidguard/db# cd adult bash: cd: adult: Aucun fichier ou dossier de ce type root@debian:/var/lib/squidguard/db#
je vais donc déclarer dbhome: /var/lib/squidguard/db/blacklists
ou alors déplacer tout le contenu de /var/lib/squidguard/db/blacklists dans /var/lib/squidguard/db

#8

J’ai tout remis dans /db et m’a l’air de rouler !

[size=85]<< je l’aurai un jour, je l’aurai. >> Palace[/size]

#9

Ce qui est bien c’est qu’avec squid tu peux toujours te débrouiller avec les logs :slightly_smiling:
Penses à toujours faire un :

tail -f /var/log/squid3/squidguard.log quand tu reconstruis ta base.
Dans la plupart des cas, ce sera une erreur de syntaxe dans le fichier /etc/squid3/squidGuard.conf :slightly_smiling:

#10

Je poursuis, squid (port 3128) et squidGuard sont fonctionnels,
maintenant je voudrais obliger l’utilisateur hermes à passer par ce proxy pour naviguer (mais pas les autres), c’est à dire que je souhaite qu’il soit obligé de paramétrer ses navigateurs pour qu’ils passent tous par le proxy, sinon il n’y a rien qui passe !

Je pensais à un truc du style

Est-ce que cela marchera et dans ce cas les autres utilisateurs naviguent normalement alors qu’hermes est obligé de passer par le proxy et donc est contrôlé par squid+squidGuard ?

#11

Juste histoire de mettre un peu de << couleurs >> dans le forum (!), avec Firefox qui utilise squid sur le port 3128 et Epiphany qui lui accède directement à internet, la différence avec le test supernichons sur l’image jointe.

Bon la question sur :

#iptables -t filter -A OUTPUT -p tcp --dport 80 -m owner --uid-owner hermes -j DROPm’intéresse toujours !

#12

A première vue, ça a l’air correct.

#13

Ah, bon c’est aussi simple que ça ; je colle donc : iptables -t filter -A OUTPUT -p tcp --dport 80 -m owner --uid-owner hermes -j DROPdans le /etc/rc.local, et hop, au prochain démarrage hermes est obligé de passer tous ses navigateurs par le port de squid, et est donc filtré.
Va diou, si c’est bon, il ne me reste plus que la mise à jour automatique de la blacklist via cron.
J’y suis presque.

#14

Mince, ça ne marche pas, j’ai écrit dans /etc/rc.local :

iptables -t filter -A OUTPUT -p tcp --dport 80 -m owner --uid-owner hermes -j DROP iptables -t filter -A OUTPUT -p tcp --dport 80 -m owner --uid-owner athena -j DROP
puis, sous le compte hermes, j’ai réglé Firefox pour qu’il accède directement à internet sans passer par squid, et… il y accède. Il y a donc un truc qui cloche. :think:
Je pensais que mes deux lignes ci-dessus bloquaient l’accès http ?

J’ai donc encore besoin d’aide.

Une copie complète de mon rc.local :

[code]#!/bin/sh -e

rc.local

This script is executed at the end of each multiuser runlevel.

Make sure that the script will “exit 0” on success or any other

value on error.

In order to enable or disable this script just change the execution

bits.

By default this script does nothing.

K le 16 mars 2012 pour forcer le passage par squid en bloquant le port 80 :

iptables -t filter -A OUTPUT -p tcp --dport 80 -m owner --uid-owner hermes -j DROP
iptables -t filter -A OUTPUT -p tcp --dport 80 -m owner --uid-owner athena -j DROP
exit 0[/code]

hermes@debian:~$ ls -l /etc/rc.local -rwxr-xr-x 1 root root 555 16 mars 00:01 /etc/rc.local
Des fois que …?

#15

Tu as vérifié que les règles sont bien en place avec iptables-save ? Il n’y a pas d’autres règles avant qui pourraient accepter les paquets ? Si tu as une connexion internet en IPv6, il faut aussi bloquer avec ip6tables.

#16

Pour IPv6 je pense que c’est non car avec network-manager je n’ai rien pour IPv6 (copie 1).
Pour iptables-save là je ne maîtrise plus grand chose :

root@debian:/home/zeus# iptables-save root@debian:/home/zeus#
ne renvoie rien, donc ça n’a pas l’air bon.

Comme je le disais au dessus, j’ai juste collé, en root, les deux lignes iptables dans /etc/rc.local et j’ai redémarré la bête, mais apparemment cela ne suffit pas.

#17

Tiens, un truc qui semble confirmer le fait que mes règles ne sont pas prises en compte c’est que iptables -L
me renvoie un truc comme :

[code]Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 0K packets, 0 bytes)
pkts bytes target prot opt in out source destination[/code]
(celui-ci est une copie d’arch-wiki) mais de tête c’était pareil.

#18

Donc les règles iptables n’ont pas été créées. Il faut chercher pourquoi.
Peut-être le path à ajouter (/sbin/). Ou bien le fichier rc.local n’a pas été exécuté. Fonctionne-t-il si tu le lances à la main ?

#19

pour le PATH ça m’a l’air bon (quoi que ce identifiant non valable ?) :

root@debian:/home/zeus# export $PATH bash: export: « /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin » : identifiant non valable
mais pour iptables :

root@debian:/home/zeus# /etc/rc.local iptables v1.4.8: unknown protocol `tcp ' specified Try `iptables -h' or 'iptables --help' for more information. root@debian:/home/zeus#
?

#20

Il n’y aurait pas un caractère blanc mais qui ne serait pas un “vrai” espace après ‘tcp’ ?