Squid verstehen/ überwacht nicht

[amiga1200]

Ich habe Suse 12.2 als Router konfiguriert, so dass die Win/Mac darüber ins Internet kommen.

Nun sollen für eine Clients einige Webseiten gesperrt werden, dazu habe ich mir Squid 3.1.23-2.4.1 installiert,
etwas konfiguriert und gestartet.
Doch alles ist wie vorher, die Clints kommen immer noch ins Netz!

Leider fehlt mir noch etwas Hintergrund Infos.
Jetzt ist es so, das jeder Client eine Feste IP hat, feste DSN und als Router die Router-IP.
Musst an die Client was geändert werden, wie Proxi einstellen?

Es ist doch so, dass die Client eine Anfrage an die interne Netzwerkkarte stellen t,der Router übersetzt das ins I-Netz
Squid müsste sich doch zwischen der interne Netzwerkkarte und das Internet einklinken, was bei mir nicht passiert!
oder ist es so, dass die Client Squid direkt ansprechen?

Wie bringe ich Squid dazu, den Verkehr zu überwachen?

Squid soll eigentlich nur einige Seite wie Fussball/Bild... sperren!

Code: Select all

# Recommended minimum configuration: 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

visible_hostname meinproxy

# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
 
acl localnet src 192.168.20.0/24 	# RFC1918 possible internal Network wir haben hier ein 192.168.20.x netz
 
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

#
# Recommended minimum Access Permission configuration:
#
# Only allow cachemgr access from localhost
http_access allow manager localhost
http_access deny manager

# Deny requests to certain unsafe ports
http_access deny !Safe_ports

# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports

# We strongly recommend the following be uncommented to protect innocent
# web applications running on the proxy server who think the only
# one who can access services on "localhost" is a local user
#http_access deny to_localhost

#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#

# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
http_access allow localnet

# Allow localhost always proxy functionality
http_access allow localhost

# And finally deny all other access to this proxy
http_access deny all

# Squid normally listens to port 3128
http_port 3128

# Uncomment and adjust the following to add a disk cache directory.
#cache_dir aufs /var/cache/squid 100 16 256

# Leave coredumps in the first cache dir
coredump_dir /var/cache/squid

# Add any of your own refresh_pattern entries above these.
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

#  TAG: auth_param
auth_param basic program /usr/lib/squid/pam_auth
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off

#  TAG: http_access
acl checkpw proxy_auth REQUIRED
http_access allow checkpw all

acl freigegeben1 src 192.168.20.0/255.255.255.0
http_access allow freigegeben1

[ddm3ve]

Ich würde dir folgendes Vorschlagen, tausche Deinen router gegen eine firewall, die auch einen Webproxy mit der gewünschten Funktionalität mit bringt.
Das Problem an Deinem setting ist, Deine Clients wissen und interesieren sich keinen deut um Deinen Proxy.
Daher ist das Gateway weiterhin Gateway und weil es den ausgehenden Verkerh nicht sperrt, kann man auch weiterhin ohne Proxy surfen.

Anstatt Suse 12.2 für eine solche ggf. auch sensible Aufgaben zu verwenden würde ich eher auf eine Firewalllösung wie z.B. Endian, IPCop und welöche Systeme es sonst noch gibt, setzen was genau dafür geeignet ist.
Und natürlich muss beim Client, eingestellt werden, wer der Proxy ist.

-> Aber nutze ein System, das dafür geeignet ist, ansonsten ist Dein vorhaben so, als würdest Du ein fort Knox an Deiner Haustüre auf bauen, mit Grossen Schildern auf die Sicherheitskontrolle an der Türe hinweisen, aber die Terrassentüre völlig ungeniert offen lassen.

Sprich die Fenster am Caprio hoch kurbeln und abschliessen bei offen Verdeckt als Diebstahlschutz des auf dem Sitz liegenden Notebooks, enstpricht ungefähr dem, was Du als Absicherung betreibst.

Viele Grüsse

[Joe User]

Wenn der Squid in den Clients nicht als Proxy konfiguriert ist, dann wird der Squid auch nicht genutzt.
Ausnahme: Du routest den gesamten vom internen Netz stammenden Traffik auf dem Router per Paketfilter auf den Squid um. Das gibt widerum Probleme mit diversen Protokollen wie SMTP, DNS und allen Anderen von Squid nicht unterstützten Protokollen, so dass Du für diese Protokolle Ausnahmen im Routing definieren musst, welche dann von den Clients per Tunnel ausgenutzt werden können und den Squid umgehen. Henne-Ei-Problem, welches sich nur mittels DPI effektiv lösen lässt und spezielle Hard-/Software erfordert.

Wie man solche Proxys umgeht, erfährt man in zwei Minuten googlen und fünf Minuten später ist es erledigt. Das gleiche Problem wie bei allen Jugendschutzfiltern, Netzfiltern (Stoppschilder), x-Strike-Verfahren (Frankreich, USA, etc) und sonstigen Placebos.

Strikte schriftliche Policies, welche konsequent sanktioniert werden, sind die effektivste Lösung. Wer sich nicht daran hält wird abgemahnt und bei Wiederholung gefeuert, konsequent, ohne Ausnahme.

[ddm3ve]

DPI effektiv lösen lässt und spezielle Hard-/Software erfordert.

Dots per inch?

[Joe User]

Deep Packet Inspection
http://en.wikipedia.org/wiki/Deep_packet_inspection