Konfiguration des Proxyserver Squid mit SquidGuard und Authenifizierung


Ich werde heute beschreiben wie man den Proxy-Server Squid mit SquidGard einrichtet und Zugriff per Benutzer-Authentifizierung.
Anlass ist, das ich selbst bei mir zuhause diese Kombination einsetze, um meinen Kindern manche nicht kinderfreundlichen Inhalte im Web zu ersparen und zu blocken.
Es gibt verschiedene Einsatz-Scenarien von Squid z.B als Caching von Webseiten zum schnellen Anzeigen im Browser.
Zuerst muss man die Pakete dafür installieren, bei mir im Fall von openSUSE-Leap. Pakete können sich bei anderen Linux Distributionen unterscheiden.
zypper in squid squidGuard
Anschließend den Proxyserver Squid beim Systemstart aktivieren:
systemctl enable squid.service
Starten von Squid
systemctl start squid.service
Bei der fertigen Umgebung wird Squid die Anfragen über den SquidGuard leiten, zum die URL’s oder Domains zu überprüfen, ob derjenige Benutzer die Inhalte sehen darf oder nicht.
Als erstes konfiguriere ich den Squid, Konfigurationsdatei liegt unter:
cd /etc/squid/ && vim squid.confz.B meine squid.conf
auth_param basic program /usr/sbin/basic_pam_auth #----> Wichtig Authentifizierung von Usern, wird per Popup erscheinen
auth_param basic children 5 startup=0 idle=1
auth_param basic realm Squid proxy-caching web server
acl localnet src 192.168.100.0/24 # RFC1918 possible internal network #----> Wichtig Zugriff Regel für das Netz von Squid
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
acl password proxy_auth REQUIRED
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access allow localnet password
http_access allow localhost
http_access deny all
http_port 3145
coredump_dir /var/cache/squid
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
err_page_stylesheet /etc/squid/errorpage.css
redirect_program /usr/sbin/squidGuard -c /etc/squidguard.conf #-----> Wichig weiterleitung über SquidGuard und liest Konfig von squid ein
redirect_children 5 #----> Wieviele Kindprozesse darf Squidguard öffnen.

Es wird in dieser Konfig-Datei vieles per Kommentar erklärt, hier empfiehlt sich es mal gelesen zu haben.
Dann müssen noch Berechtigungen der Datei
/usr/sbin/basic_pam_auth
gesetzt werden, damit die Authentifizierung über die angelegten Benutzer funktioniert:
chgroup shadow /usr/sbin/basic_pam_auth
chmod g+s /usr/sbin/basic_pam_auth

Damit alles aktiv geschaltet wird müssen wird den Proxyserver neustarten:
systemctl restart squid.service
So jetzt damit kommen wir zum SquidGuard:
Die Konfigurationsdatei heisst:
vim /etc/squidguard.conf;
Ein Beispiel von mir:
logdir /var/log/squidGuard
dbhome /var/lib/squidGuard/db
src parents {
ip 192.168.100.0/24 # range 192.168.10.0 - 192.168.10.255
# AND
user papa mama # ident Papa und Mama
}
src kids {
ip 192.168.10.17 # Notebook Kind 1
user username # ident Kind1
# AND
ip 192.168.10.14 # Notebook Kind 2
user username (Kind # ident Kind2
}
dest blacklist {
domainlist blacklist/domains
urllist blacklist/urls
}
#####
#
# Zeitregeln
#####
# abbrev for weekdays:
s = sun, m = mon, t =tue, w = wed, h = thu, f = fri, a = sat
time tagsueber {
weekly mtwhfas 12:00-16:00 # Unter der Woche
}
acl {
parents {
pass all
}
kids {
pass !blacklist all
}
default {
pass none
redirect http://hostname/cgi-bin/squidGuard.cgi/blocked?clientaddr=%a&clientname=%n&clientuser=%i&clientgroup=%s&url=%u

Die Datei ist eigentlich sehr einfach strukturiert und auf der Webseite von SquidGuard gut erklärt, deswegen verlinke ich hier gern:
http://www.squidguard.org/Doc/configure.html
Für das Blocken von nicht kinderfreundlichen Seiten gibt es schon fertige Listen, die das meiste auch schon abdecken:
Block-Listen
Diese Listen müssen entpackt und in das Verzeichnis:
cd /var/lib/squidGuard/db/blacklist/
kopiert werden und anschließend initialisiert werden:
squidGuard -C all
So, jetzt sollte alles soweit funktionieren, testen kann man am besten, in dem man mit einem Benutzer, der für das Blocken eingerichtet ist, geblockte URL’s oder Domains aufzurufen, um zu sehen ob diese Seite aufgerufen werden kann.
In diesem Sinne Have Fun!

Johannes Carraro
Johannes Carraro
Support Engineer

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Managed Services Team als Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre in einer Metalband, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren.

Ein Buch über Icinga 2

Erscheint am 27. Juni 2016

 
41suqaLOyCL._SX336_BO1,204,203,200_April 2015, nach Monaten des Schwankens machten sich dann zwei verbliebene Möchtegernautoren doch auf ein Buch zum Thema Icinga 2 zu verfassen. Wir wollten ein sehr praxisnahes Werk mit vielen Beispielen wie und mit welchen Plugins etwas zu überwachen ist. Herausgekommen sind 344 Seiten von denen sich 100 mit Plugins und deren Verwendung in Icinga 2 befassen. Vorweg erfolgt eine generelle Einführung, die Vorstellung des neuen Webinterfaces Icingaweb 2 als auch eine ausführliche Erläuterung wie man lokale Werte wie Load bzw. CPU bei Windows oder Disk Usage mit NRPE/NSClient++, SSH und selbstverständlich mit dem neuen Icinga Agenten ermittelt.
Dem Kapitel über Plugins ist noch die Vorstellung einer fiktiven Firma vorangestellt. Diese betreibt ein zweigeteiltes Netzwerk mit einem internen Netz und eine durch Perimeter abgetrennte DMZ. Anhand dieses Beispiels wird eine verteilte Überwachung implementiert. Im internen Netz ist ein Icinga-Server (Master) für die Überwachung der dortig angesiedelten Server und Dienste zuständig. Für die DMZ wird ein weiterer Icinga-Server (Satellit) verwendet, der die ermittelten Ergebnisse an den Master meldet.
Diese Icinga-2-Infrastruktur wird dann im Folgenden benutzt, um eine Vielzahl von Diensten zu überwachen:

  • Host Erreichbarkeit
  • Zeitserver und lokale Zeit
  • Webservices incl. Apache und Ngnix
  • Domain Name Services
  • DHCP
  • Kerberos
  • Mailempfang und -versand
  • Proxy-Server
  • Generische Portüberwachung am Beispiel von Jabber
  • Javabasierte Application-Server
  • SAP
  • Kibana
  • Microsoft-Infrastrukturdienste: CIFS, Terminalservice, Domaincontroller, Exchange
  • Datenbanken: MySQL, PostgreSQL, MS SQL, Oracle
  • LDAP
  • Redis
  • Elasticsearch
  • VMware vSphere
  • Hardware: IPMI, HP, Oracle Solais, Thomas Krenn, Netzwerk, Festplatten
  • NetApp
  • Qnap

Das letzte Drittel ist Graphing mit PNP4Nagios und Graphite, Logmangement, Reporting und Businessprozessen gewidmet.
Teilbereiche werden von den beiden Autoren in einem Workshop vor der diesjährigen Open Source Monitoring Conference mit den Teilnehmern zusammen praktisch umgesetzt.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.