Seite wählen

NETWAYS Blog

Squid – Mit Proxy schneller zum Ziel

Bereits in zwei meiner Blogposts habe ich besonders interessante Ausbildungsprojekte vorgestellt. Im Beitrag Your own Mini-NAS zeige ich, wie einfach es ist, einen Massenspeicher im eigenen Netzwerk zu erstellen, in Pi-Hole – das Urgestein der DNS-basierten Werbeblocker geht es, wie der Name schon vermuten lässt, um die Installation und Einrichtung von Pi-Hole auf einem Raspberry Pi.

Auch im heutigen Post geht es um ein für mich interessantes Ausbildungsprojekt aus meinem ersten Ausbildungsjahr zum Fachinformatiker für Systemintegration bei NETWAYS Professional Services: die Installation und Konfiguration eines Proxy-Servers mit Squid.

Was genau macht ein Proxy-Server?

Der Begriff „Proxy“ ist in vielen Bereichen der IT anzutreffen und für die meisten IT-Profis bereits ein alter Hut. Nichtsdestotrotz stelle ich einmal kurz und knapp die wichtigsten Anwendungsbereiche eines Proxy-Servers vor.

Caching – Beschleunigung beim Datenaufruf

Der wohl bekannteste Einsatzbereich von Proxys ist die Funktion als Zwischenspeicher. Dafür wird die entsprechende Software als „Mittelsmann“ in die Kommunikation von Host und Datacenter/Server eingesetzt. Jede Anfrage eines Hosts im Netzwerk, zum Beispiel der Aufruf einer Homepage über den Browser sowie die Antwort vom Server wird über den Proxy geleitet. Die eingehenden Daten werden in seinem Speicher ablegt, das nennt man Caching.
Durch das Caching ist der Proxy in der Lage, regelmäßig auftretende Anfragen deutlich schneller zu beantworten, da er viele Daten bereits aus seinem Speicher laden kann. So wird nicht nur Zeit, sondern auch Bandbreite gespart.

Lastenverteilung

Neben dem Caching, kann ein Proxy auch für eine bessere Lastenverteilung zwischen mehreren angeschlossenen Systemen sorgen. Diese Funktion kommt häufig bei Anfragen auf (Web-)Servern zum Einsatz. Um das einmal zu veranschaulichen, stellen wir uns eine beliebte Homepage vor, die pro Sekunde Tausende Anfragen bekommt. Damit der Webserver unter der Last nicht zusammenbricht, kommt ein Proxy zum Einsatz, der checkt, wie groß die Last auf Webserver 1 ist und bei Bedarf neue Anfragen auf Webserver 2 umleitet. Auf beiden Servern liegen die exakt gleichen Inhalte. So kann ein Zusammenbruch der Homepage verhindert werden.

Filterung des Datenverkehrs

Blocklisten sind eine einfach umsetzbare Möglichkeit den Datenverkehr innerhalb des eigenen Netzwerks zu reglementieren. Mit dem Squid Proxy-Server lassen sich diese Regeln einfach umsetzen, dazu weiter unten im Text aber noch mehr.
Der Administrator des Netzwerks kann mithilfe eines Proxy-Servers festlegen, welche Seiten aus dem eigenen Netzwerk aufgerufen werden können und welche nicht. Sobald eine „verbotene“ Website aufgerufen werden soll, kann eine Weiterleitung auf eine Landingpage genutzt werden, auf welcher diese Regeln erklärt sind.

Authentifizierung

Ähnlich wie die Listen zur Filterung von Datenverkehr kann mit Access Control Lists (ACL) der Zugang zum Netzwerk oder zu bestimmten Teilen des Netzwerks beschränkt oder freigeschalten werden. Dadurch kann anhand von IP’s und/oder MAC-Adressen sowie durch Authentifizierung exakt eingestellt werden, welche Systeme oder Nutzer auf welche Bereiche eines Netzwerks Zugriff bekommen.

Installation von Squid

DISCLAIMER: Alle in diesem Blogbeitrag genannten Installations- und Konfigurationsschritte wurden nur auf CentOS 9 getestet. Für andere Distributionen, besonders Debian / Ubuntu, wird keine Gewähr für eine problemlose Funktionalität gegeben.

Um einen Proxy zu konfigurieren benötigt es zunächst einmal die passende Open Source Software, in diesen Fall der häufig verwendete Squid Proxy Server. Die Installation von Squid selbst ist mit drei CLI-Befehlen so einfach wie unkompliziert.

yum -y install squid
systemctl start squid
systemctl enable squid

Um zu überprüfen, ob Squid Proxy wie gewünscht läuft, kann der aktuelle Status mit dem Command

systemctl status squid

angezeigt werden. Haben die hier gelisteten Parameter den gewünschten Status (active und enabled), kann die Konfiguration starten.

Konfiguration von Squid Proxy

Um kleinere Stolpersteine beim Einsatz von Squid direkt bei der Erstkonfiguration aus dem Weg zu räumen wird in der Firewall der von Squid benötigte Port 3128 freigeschaltet. Nun können die Zugriffsregelungen, Benutzerauthentifizierung sowie Blocklisten konfiguriert werden. In diesem Post beschränke ich mich auf die Konfiguration der Zugriffsregelungen sowie der Blocklisten.

Einrichten der Zugriffsregeln

Auf dem Proxy-Server

Bevor Authentifizierung und Listen genutzt werden können, muss der Zugriff auf den Squid-Proxy geregelt werden. Dafür werden die IP-Adressen der Hosts benötigt, die ihre Verbindungen über den Proxy-Server leiten sollen.
Die IP-Adressen können auf zwei verschiedene Arten bereitgestellt werden. Zum einen können sie mit dem entsprechenden Befehl direkt in die config-Datei von Squid geschrieben werden. Zum anderen kann eine eigene Textdatei mit allen relevanten Adressen angelegt und eingelesen werden. Letzteres Vorgehen ist besonders bei großen Netzwerken hilfreich und sinnvoll. Best Practice ist es, alle selbst erstellten Listen im Squid-Proxy-Ordner /etc/squid anzulegen.

Egal welche Methode genutzt wird, der entsprechende Befehl wird an den Anfang der Squid-Config-Datei geschrieben, damit die neue Direktive vor den bereits vordefinierten ACLs angewendet wird. Der entsprechende Befehl ist für die direkte Eingabe einer IP-Adresse

acl NAME_DER_ACL src IP_DES_SYSTEMS

und für die Verwendung einer Textdatei

acl NAME_DER_ACL dstdomain "PFAD_ZUR_TEXTDATEI"

Mit diesen Befehlen wurde eine neue ACL definiert, sie ist aber noch nicht aktiv. Dafür wird ein weiterer Befehl benötigt, der direkt unter den gerade geschriebenen Befehl eingefügt wird. Hier kann sowohl allow als auch deny genutzt werden, je nachdem, was das Ziel der neuen ACL ist, aber niemals beide zusammen in einem Befehl.

http_access allow NAME_DER_ACL
http_access deny NAME_DER_ACL

Auf den Clients im Netzwerk

Nachdem der Proxy-Server entsprechend konfiguriert ist, müssen auch auf den Clients, die den Proxy nutzen sollen, einige Anpassungen vorgenommen werden. In /etc/environment werden nun unabhängig vom bisherigen Inhalt der Datei die folgenden Zeilen eingefügt bzw. angepasst:

http_proxy=http://IP_DES_PROXY:3128/
https_proxy=http://IP_DES_PROXY:3128/
ftp_proxy=http://IP_DES_PROXY:3128/
no_proxy="localhost,127.0.0.1,localaddress,.localdomain"
HTTP_PROXY=http://IP_DES_PROXY:3128/
HTTPS_PROXY=http://IP_DES_PROXY:3128/
FTP_PROXY=http://IP_DES_PROXY:3128/
NO_PROXY="localhost,127.0.0.1,localaddress,.localdomain"

Damit sollten sowohl systemseitig als auch auf dem Proxy alle Konfigurationen für eine erfolgreiche Kommunikation der beiden durchgeführt sein.

Blocken von Websites und Keywords

Um eine Blockliste für Websites oder Keywords zu erstellen, müssen die zu sperrenden Seiten oder Begriffe in eigens dafür angelegten Textdateien gesammelt werden. Um welche zu sperrenden Inhalte es sich dabei handelt, ist von Anwendungsfall zu Anwendungsfall unterschiedlich. Häufig werden sie jedoch dafür genutzt, den Aufruf von Social Media-Kanälen zu beschränken, nicht-jugendfreie Inhalte aus dem Datenverkehr auszuschließen oder restriktiv alle Inhalte zu filtern, die für zu viel Ablenkung sorgen könnten.

Der Pfad zu den angelegten Listen, Best Bractice ist auch hier /etc/squid/…, wird nun in die squid.conf eingepflegt. Da die Konfigurationsdatei hierarchisch von oben nach unten abgearbeitet wird, MÜSSEN Blocklisten vor den Zugangsberechtigungen stehen.

acl blocked_sites dstdomain "PFAD_ZUR_EIGENEN_LINK-BLACKLIST"
acl blocked_keywords dstdomain "PFAD_ZUR_EIGENEN_KEY-BLACKLIST"
http_access deny blocked_sites
http_access deny blocked_keywords

Nachdem die Änderungen gespeichert wurden, ist noch ein Neustart von Squid-Proxy notwendig, um die Änderungen wirksam zu machen.

systemctl restart squid

Wenn alles korrekt eingerichtet wurde, ist der Squid-Proxy-Server nun einsatzbereit.

Die ersten Zeilen der veränderten squid.conf könnten nun in etwa so aussehen:

squid proxy configuration file with sample code

Wenn die eigene Konfigurationsdatei jedoch mehr oder weniger Inhalte beinhaltet oder diese in einer anderen Reihenfolge stehen, ist das kein Problem. Dieser Screenshot dient lediglich als Hilfestellung.

Ausbildung und #lifeatnetways

Wenn auch Du nun Lust bekommen hast, Dich mit diesem oder ähnlichen Projekten zu befassen oder bereits viel IT-Erfahrung mitbringst und direkt tiefer einsteigen willst, schick uns noch heute deine Bewerbung. Aktuell suchen wir besonders IT-Spezialist:innen in den verschiedensten Bereichen. Doch auch für das im September 2023 beginnende neue Lehrjahr kannst Du Dich bereits heute bewerben.
Wenn Du mehr über NETWAYS, freie Stellen oder unsere Firmenkultur erfahren willst, klick einfach auf den entsprechenden Link oder such auf Twitter, LinkedIn oder Instagram nach #lifeatnetways.

Squid 4 Proxy mit LDAP & MITM SSL-Bump

Im Zuge meiner Ausbildung bei NETWAYS durfte ich mich diese Woche mit Squid auseinandersetzen. Dabei merkte ich, dass man sich bezüglich LDAP & SSL-BUMP wirklich nur auf die offiziellen Squid Dokus und die Red Hat Dokus verlassen konnte.

Squid ist ein Caching Proxy für Web Seiten das HTTP, HTTPS, FTP und vieles mehr unterstützt. Es reduziert Bandbreite und verbessert Aufrufzeiten. Dabei kann es den effektiven Netzwerkdurchsatz verbessern.

  • Es ermöglicht Caching und Verteilung.
  • Es erlaubt Content Filtering.
  • Es unterstützt LDAP-Anbindung für die Authentifizierung.
  • Es kann als transparent / MITM Proxy genutzt werden.

 

 

Ubuntu 20.04.01 Server: Die für SSL Bump benötigten Kompilerflags lauten --enable-ssl-crtd & --with-openssl. Aktuell ist Squid in Version 4 mit diesen Flags in den Ubuntu-Server-Repos nicht vorkompiliert, sodass man man sich Squid praktisch selbst damit bauen muss. Ob die Flags aktiv sind kann man folgendermaßen checken:

$ squid -v | grep ssl

CentOS 8: Unter CentOS kommt Squid direkt mit SSL-Bump vorkompiliert.

  • Der folgende Artikel basiert auf Squid Version 4.4 unter CentOS 8.

 

Vorab-Konfiguration

  • Firewallregeln sollten Squid entsprechend angepasst werden.
$ sudo firewall-cmd --permanent --add-port=3128/tcp
$ sudo firewall-cmd --reload
  • Falls jemand sich wie ich noch nicht so sehr mit SELinux auskennt, empfiehlt es sich die SELinux Policies erstmal auf Permissive zu stellen. Dies geschieht in der /etc/selinux/config. Später nach erfolgreicher Installation sollte man sie wieder zurück auf Enforcing setzen.
SELINUX=permissive

LDAP

  • Das Root Zertifikat der Umgebung muss heruntergeladen, in den Zertifikatsordner des Squid Servers geschoben und aktualisiert werden damit LDAP signiert via TLS funktioniert.
$ sudo cp ROOT_ZERTIFIKAT.cer /etc/pki/ca-trust/
$ sudo update-ca-trust

Die auth_param Parameter sollten schon in der Konfigurationsdatei /etc/squid/squid.conf stehen und entsprechend aktiviert und vervollständigt werden.

  • Wichtig ist es exakt passend Base/Domain/Suchfilter und Server zu übergeben. Hilfreich hierzu sind die Man Page von basic_ldap_auth sowie ldapsearch.
  • Folgendes Beispiel basiert auf einer Microsoft Active-Directory Umgebung was an dem -f Suchparameter erkannt werden kann. Zwingend wichtig ist es hier das %s für den User mitzugeben.
Das –R Flag muss manchmal gesetzt werden um Referrals nicht zu folgen, da ansonsten mehrere Aufrufe stattfinden und Konflikte auslösen womit Squid LDAP verweigern wird.

 

auth_param basic program /usr/lib64/squid/basic_ldap_auth -b "dc=FIRST_DOMAIN,dc=SECOND_DOMAIN,dc=ROOT_DOMAIN"
-D "CN=LDAP/USERNAME,OU=SERVICEGROUP,OU=COMPANY,OU=NET,OU=COMPANY,DC=FIRST_DOMAIN,DC=SECOND_DOMAIN,DC=TOP_DOMAIN"
-w "password" -f "(&(objectCategory=Person)(samAccountName=%s))" -R -H ldaps://FIRST_DOMAIN.SECOND_DOMAIN.TOP_DOMAIN:636
auth_param basic children 5
auth_param basic realm Hi this is your Squid Proxy speaking
auth_param basic credentialsttl 5 minutes
#Falls die LDAP Authentifizierung nicht durching,HTTP Traffic sperren.
acl ldap-auth proxy_auth REQUIRED
http_access deny !ldap-auth

 

  • Jetzt braucht Squid noch einen Neustart
$ sudo systemctl restart squid
  • Innerhalb weniger Sekunden sollte die LDAP/AD Passwortabfrage kommen.

 

mehr lesen…

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:

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
Senior Systems 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 Team Operations als Senior Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre, 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.