Seite wählen

NETWAYS Blog

Squid – Mit Proxy schneller zum Ziel

von | Jan 12, 2023 | ,

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

von | Okt 15, 2020 |

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…

Was ist Consul und wozu dient es?

von | Dez 13, 2019 |

Eine Beschreibung in einem Wort ist hier Service Mesh. Was jemanden, der sich zuerst mit Consul beschäftigt, ebenfalls nicht wirklich weiterhilft. Dieser Blogpost zeigt die Features von Consul auf und gibt Hinweise zu deren Anwendung.

Consul verwaltet Services und Knoten in der Art eines „Verzeichnisdienstes“, also in der Form was läuft wo? Zugegriffen wird dabei über DNS oder alternativ mittels HTTP(s). Consul wird entweder im Modus Server oder Agent betrieben. Die Server speichern die Daten, kommen mehrere zum Einsatz werden die Daten automatisch synchronisiert.

Auf die Daten kann man direkt auf den Servern mittels DNS oder HTTP(s) zugreifen oder über den eh benötigten Agenten. Über den Agenten meldet sich jeder beliebige Knoten bzw. Host in Consul an und wird als Node registriert. Ebenfalls können dann auch Services registriert werden. Ein Webserver z.B. registriert sich so zum Beispiel als neues Cluster-Mitglied zu einem bereits bestehenden Services. Zusätzlich können auch Tags gesetzt werden, die sich via DNS-Abfrage dann als Aliases darstellen.

Nur was macht man nun mit diesen Informationen? Einfach wäre es nun seinen eigentlichen DNS auf diese Informationen weiterzuleiten. Dies geht wie oben schon angedeutet mit Anfragen entweder direkt an die Server oder über einen auf den DNS-Servern betriebenen Agenten. Damit ist leicht ein DNS-Round-Robin zu realisieren.

Möchte man hingegen einen Load-Balancer als Proxy für seinen Dienst betreiben, kommt Consul-Templates als eigenständiges Produkt ins Spiel. Es handelt sich hierbei um eine Template-Engine, die die Informationen aus Consul in Konfigurationsdateien überführt. Die Konfiguration kann dabei noch um zusätzliche Konfigurationsparamter, aus dem in Consul integrierten Key-Value-Store, angereichert werden.

Abschließend bietet Consul als weiteres Feature die Verwaltung einer Certificate Authority (CA). Die ausgestellten Zertifikate können sogleich mit Hilfe des Agents via Proxy (sidecar proxy) zur Absicherung der betriebenen Dienste mittels TLS eingesetzt werden. Das geschieht völlig transparent und Konfigurationsdateien müssen nicht angepasst werden.

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.
Lies mehr von Lennart und triff unser Team

HAProxy und SQL Grants

von | Okt 31, 2018 | , , , , , , ,

In diesem kurzen Beitrag will ich auf einen Fallstrick im Bezug von HAProxy und SQL Backends wie MySQL oder MariaDB eingehen. Speziell geht es um Grants und die damit verbunden Quell Hosts. Diese werden bei einem Standard Setup mit HAProxy durch die IP des Proxys ersetzt. Solange man sich in dem selben Netz wie die DB Server und dem Proxy befindet und die Host-Beschränkungen nicht all zu streng sind, kann es gut sein, das man dieses Szenario nicht erreicht. Sobald die Verbindungen aber Netz übergreifend erfolgen und die Grants damit umso wichtiger sind, kommt das Detail zum Tragen und stellt einen vor neue Herausforderungen. Dafür gibt es an sich schon etwas länger das Proxy Protokoll, welches aber erst nach und nach in mögliche Backend Software implementiert wurde/wird. Bei MariaDB war es mit der 10.3.1 z.B. erst Ende letzten Jahres soweit.
Die Arbeitsweise des Protokolls beschreibt sich einfach gesagt so, dass mit dem Aufbau der Verbindung zuerst ein zus. Header geschickt wird, in dem die IP des Quell Hosts bekannt gegeben wird. Dazu muss das Backend jedoch von der IP des HAProxys das Proxy Protokoll erlauben. Das Ganze drum rum kann mit Seiten über weitere Details und Sicherheit befüllt werden. Damit verschone ich Euch aber und weise nur auf eine schlichte Zusammenfassung im Blog von HAProxy hin.

File Caching mit Nginx

von | Mrz 26, 2010 |


Nginx ist ein leistungsfähiger Webserver und Reverse-Proxy, der ursprünglich für eine russische Website entwickelt wurde. In den letzten Monaten erfreut sich die unter BSD-Lizenz verfügbare Software einer immer größer werdenden Beliebtheit.
Besonders spannend finde ich die Möglichkeit diverse Remote-Services als Caching Instanz zusammenzufügen und den entsprechenden Filesysteminhalt auf dem Server abzulegen. So ist der Inhalt anschließend dann nicht in einem Cache-File oder einer Cache-Struktur, ähnlich Squid abgelegt, sondern in einer realen Schattenkopie.
Nachfolgender Code-Snip zeigt kurz den entsprechenden Abschnitt der Konfiguration:
[code lang=“bash“]
http {
server {
listen 8888;
server_name proxy.server.org;
# root url – don’t cache here
location / {
proxy_pass http://upstream.server.org;
}
# here is static caching
location ~* ^/Content.+\.(cab|exe|psf|CAB|EXE|PSF)$ {
root cache/wsus;
error_page 404 = @fetch;
}
location @fetch {
internal;
proxy_pass http://upstream.server.org;
proxy_store on;
root cache/wsus;
}
}
}
[/code]
Das Wiki von Nginx bietet darüber hinaus ausführliche Hilfestellung und zeigt viele Ideen auf, die durch den Einsatz möglich werden.

Bernd Erk
Bernd Erk
CEO
Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinen beiden Söhnen und seiner Tochter.
Lies mehr von Bernd und triff unser Team

Trainings

Web Services

Events