Seite wählen

NETWAYS Blog

P-States selbst schalten? CPU-Performancemanagement unter Linux

Was sind nochmal P-States?

TLDR: P-States sind Performance-States. Wer sich mit der offiziellen Linux-Kernel Dokumentation auseinandersetzt, findet zusammengefasst das moderne Prozessoren in verschiedenen Abständen Frequenz- und Spannungskonfigurationen vornehmen, die auch ‚Operating Performance Points‘ oder auch P-States genannt werden (obwohl man hier korrekterweise eigentlich nach CPU-Architektur & Generation unterscheiden müsste), um Leistung und Stromverbrauch zu bestimmen. Im Linux Kernel findet man hierzu das CPUFreq-Subsystem das aus drei Layern besteht: Dem Kern, Scaling-Governorn und Scaling-Treibern. Während Scaling-Governer Algorithmen zur Abschätzung künftiger Leistung da sind, kommunizieren Scaling-Treiber mit der Hardware.

Vorab: Überprüfe bitte, dass Tuned & TLP nicht stören (sollten diese extra installiert worden sein). Unter Linux befindet sich das CPUFreq Verzeichnis unter /sys/devices/system/cpu und für cpu0 unter /sys/devices/system/cpu/cpu0/cpufreq/

Einfach mal ein cat auf die oben gelisteten Dateien werfen und schauen was das eigene Gerät so bietet. Zum Beispiel könnte man sich die scaling_available_governors (das braucht man für später) anschauen. Noch cooler, durch die „Everything is a file“-Philosophie bei Unix ist es jetzt direkt möglich die scaling_min_freq zu überschreiben und sofort hochzutakten! Wichtig ist nur zu wissen, dass die Werte in KHz angegeben werden.

  • Beispiel: Bei mir sind in jenem scaling_min_freq 800000 KHz eingetragen was also 0.8 GHz entspräche.
  • Ich ändere mal den Wert in 2.7 GHz um nicht unter 2.7 GHz zu takten, danach lasse mir im Anschluss das Ergebnis zur Prüfung anzeigen (nur zu Demozwecken):

Als Root:

 echo 2700000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq && cat /proc/cpuinfo | grep MHz

Warum manuell schalten oft besser sein kann:

Die meisten Geräte laufen meiner Erfahrung nach unter einem powersave statt einem performance-Profil was manche Desktop-Erweiterungen anzeigen.

  • Das kann natürlich beim sofortigen Browseröffnen mit mehreren Tabs (plus mehreren Extensions), oder Snaps oft zum Ruckeln führen da es auch für gute Governor Profile sehr schwer ist alles mit einzubeziehen.
  • Selbiges betrifft oft auch Wifi & Bluetooth-Chipsätze, die mit individuelleren Performance-Tweaks sowie dem Abschalten des Anderen (fast immer teilen sich beide den Chip) auf einmal wesentlich besser oder stromsparender laufen.
  • Wenn Du auf längeren Reisen unterwegs bist drehst Du einfach die Frequenz auf ein Minimum runter (ohne irgendeine Chance auf höhere Frequenzen) um auf höhere Batterielaufzeiten zu kommen.
  • Nicht jedes Gerät unterstützt CPU Governor wie ondemand oder conservative wobei ersteres aggressiver, schneller und genauer arbeitet und letzterer entspannter, langsamer und ungenauer. Willst du wirklich nur powersave ausgesetzt bleiben?

Du scheinst zu wissen worauf ich nun hinaus will, es ist gut zu wissen wie man selbst schaltet, und das am besten sicher, ohne dauernd das Root-Passwort einzugeben müssen und mit Hotkey? Hier mein Ansatz:

Der Plan:

  • Teil 1: Du installierst Dir die entsprechenden Distributions-Kernel-Module.
  • Teil 2: Du legst Dir als Root-Benutzer unter /usr/local/bin 6 Dateien an. Somit teilst Du deine CPU Leistung in sinnvolle Profile ein (ein Beispiel folgt), während der eigentliche Nutzer in diese Skripte nicht schreiben darf.
  • Teil 3: Du gibst jenem Benutzer die Möglichkeit diese Skripte ohne Passwortabfrage auszuführen.
  • Teil 4: Du legst dir 6 Hotkeys an: 4 für die Skripte sowie 2 für powersave und performance.

Teil 1

  • Packte installieren:

Fedora:

sudo dnf install kernel-tools

Ubuntu:

sudo apt install linux-tools-5.8.0-63-generic #(Ubuntu will an dieser Stelle die genaue Kernelversion zum Packet wissen, und macht dir einen Vorschlag)

Testen ob es funktioniert, nun solltet du einen Frequenzwechsel der Kerne zurückbekommen:

sudo cpupower frequency-set -g powersave
sudo cpupower frequency-set -g performance

Teil 2

  • Ab jetzt bitte unter Root arbeiten: Hier erstellst und legst Du in einem Benutzerverzeichnis für Skripte 6 zusätzliche Performanz-Profile an (low, medium, high, max, powersave & performance) und machst diese im Anschluss ausführbar.
  • In folgendem Codeabschnitt ersetzt du min und max je pro Profil also 8x: Angenommen deine CPU hätte 4,2 GHZ Maximum, eine sinnvolle Einteilung in 1 GHz Abständen könnte so aussehen. (min=Minimum ist und max=Maximum):
cd /usr/local/bin && touch cpu{low,mid,high,max,performance,powersave}.sh;
echo $'#!/bin/bash\ncpupower frequency-set --min 800000 --max 1500000' > /usr/local/bin/cpulow.sh;
echo $'#!/bin/bash\ncpupower frequency-set --min 1500000 --max 2500000' > /usr/local/bin/cpumid.sh;
echo $'#!/bin/bash\ncpupower frequency-set --min 2600000 --max 3500000' > /usr/local/bin/cpuhigh.sh;
echo $'#!/bin/bash\ncpupower frequency-set --min 3600000 --max 4200000' > /usr/local/bin/cpumax.sh;
echo $'#!/bin/bash\ncpupower frequency-set -g performance' > /usr/local/bin/cpuperformance.sh;
echo $'#!/bin/bash\ncpupower frequency-set -g powersave' > /usr/local/bin/cpupowersave.sh;
cd /usr/local/bin && chmod +x cpu{low,mid,high,max,performance,powersave}.sh

Teil 3

  • Rechte setzen via: visudo
  • Hier ersetzt Du folgendes: Dein_Benutzername=Deinen Benutzernamen

#Eigene CPU-Frequenz Profile für Benutzer: Dein_Benutzername

 Dein_Benutzername ALL=(root) NOPASSWD: /usr/local/bin/cpulow.sh, /usr/local/bin/cpumid.sh, /usr/local/bin/cpuhigh.sh, /usr/local/bin/cpumax.sh, /usr/local/bin/cpuperformance.sh, /usr/local/bin/cpupowersave.sh

Teil 4

Hotkeys legen ist je nach Desktop-Umgebung anders, die Logik dahinter aber gleich: Immer gibt es irgendwo ein Feld oder eine Konfigurationsdatei in die man reinschreibt: Zum Beispiel unter XFCE4  via Keyboard->Application Shortcuts. Ich lege mir hier meine 6 Skripte auf die Windows/Super-Tasten {1-6}.

Super+1 = sudo -u root /usr/local/bin/cpulow.sh
Super+2 = sudo -u root /usr/local/bin/cpumid.sh
Super+3 = sudo -u root /usr/local/bin/cpuhigh.sh
Super+4 = sudo -u root /usr/local/bin/cpumax.sh
Super+5 = sudo -u root /usr/local/bin/cpuperformance.sh
Super+6 = sudo -u root /usr/local/bin/cpupowersave.sh

Lust auf mehr? Meine Ausbilder bei Professional Services bringen mir später in der Ausbildung noch mehr zu Thema Performance-Tuning bei und können Dir helfen das letzte bisschen Leistung aus Deiner Open Source Infrastruktur herauszuholen.

Lust auf mehr Privacy? DIY Wireguard mit DNSCrypt & Quad9

Privacy & Warum Wireguard?

Mein Ziel in diesem Artikel ist es, dir zu zeigen, wie man einen eigenen Wireguard Server aufsetzt. Warum nicht einfach eine fertige VPN-Lösung einkaufen? Weil du ansonsten nie wirklich weißt, was mit deinen Logs & Daten passiert und diese zu gerne zu Analysezwecken weiterverwendet und verkauft werden.

Grade im Hinblick auf Werbe-/User-Tracking, ist es relativ schwer, browserseitig Internet-Privacy in 2021 zu erreichen (wie man auf Seiten wie AmIUnique sehen kann). Ein VPN wird einen individuellen Browser-Fingerprint nicht wirklich entfernen. Schaltet man aber noch ein Squid zum VPN der Wahl hinzu, mit http_anonymizer standard oder http_anonymizer paranoid, könnte man kleinere Erfolge erzielen! Zum Thema Browser-Fingerprinting erzähle ich vielleicht in Zukunft mal mehr.

Auf andere Protokolle bezogen, macht ein VPN aus Privacysicht aber dennoch Sinn, um z.B. Vorteile durch spezielle Services, die ländergebunden sind, zu erreichen und / oder um ein besseres Routing zu gewinnen. Da z.B. eine Suchanfrage via Google schön zeigt (ganz unten im Browser), wie nahe man via IP ohne extra Geo-tracking den Standort bestimmen kann, macht ein VPN mit integriertem DNS aber doch Sinn. Auch, um all seine Geräte gegen fremde Router & IP & DNS basierte Netzwerkangriffe zu schützen.

Warum Wireguard als VPN?

  • Leistung: OpenVPN ist recheninvensiver und benötigt praktisch AES Beschleunigung auf CPU-Form. Das bedeutet, dass ein Router, der zumeist ein ARM-Board hat (ohne AES Chip), niemals die selbe Leistung erreichen wird (MBit Download/Upload – technisch) wie es mit Wireguard der Fall wäre. Dies sollte man auch skaliert mit mehreren Servern / Clients betrachten.
    Wireguard selbst läuft mittlerweile auch als Linux-Kernel-Modul. Dies bringt natürlich Performanz-Vorteile mit sich. Zugleich gibt es mittlerweile direkten Support für OpenWRT Router (ohne dedizierte AES Chips) auf Kernel-Level (!), sowie neuerdings auch in OPNSense im Userland, und ab FreeBSD 13 auch im Kernelland.
  • Batterie: Selbiges gilt für Smartphones & Laptops, die natürlich mitrechnen müssen. Via OpenVPN werden deine Geräte mehr Rechenleistung aufwenden müssen, und praktisch schneller an Batterie verlieren.
  • Sicherheit: Wireguard hat mehrere Krypto-Runden. Dazu kommt, dass man manuell, individuellen Clients Zugriff genehmigen muss / darf, via assymetrischer Kryptographie & IP sowie symmetrischer Kryptographie falls gewünscht.
  • Codebase: Der Code ist sehr viel kompakter (< 4000 Zeilen Code), was ihn fehlerfreier sein lassen könnte. Als Faustregel kann man sagen: ~ 1 Fehler pro 1000 Zeilen Code. (Stichwort OpenBSD)

Guide

Meinen Wireguard-Guide findest du hier im Github. Er ist die Schnittmenge aus mehreren anderen Guides und eigenen Experimenten.

Im Prinzip ist alles, was du dann noch machen musst, dir ein Redhat 8 (gibt es umsonst bis zu 16 Lizenzen für den Privatgebrauch) oder CentOs 8 – VPS zu holen, welche es teilweise schon ab 5 -10 € pro Monat gibt. Warum nicht Debian oder Ubuntu? Weil ich SELinux persönlich mächtiger finde, und dieser Guide komplett unter Enforcing-Policies läuft.

Weitere Tweaks

  • SSH nur per Wireguard zulassen / Fail2 Ban installieren
  • Automatische Updates via DNF-Automatic anschalten
  • Überlegen, ob du vielleicht den Wireguard Server nur als diesen laufen lassen solltest. Einerseits um sauberes Enforcing / Targeted SE-Linux beizubehalten -> ohne viele extra Services <- andererseits um gefährlichere Services (Mail / Web) auf einen anderen Server auszulagern
  • Je nach Situation Client-Isolation anschalten
  • In Clients Kill-Switches setzen

Hinweise

  • Mir fiel auf, dass unter DNSCrypt-Proxy anfänglich Cloudflare DNS-Leaks provoziert hat (falsche Routes?), während Quad9 das per Default nicht getan hat. -> Ob das reproduzierbar ist oder an meinem Setup liegt, kannst du mir gerne in den Kommentaren sagen.
  • Mir ist außerdem aufgefallen, dass Hibernate unter manchen Linux-Distros, nach dem Hibernate, DNS-Leaks hervorruft. Hier sind die DNS-Adresse des Netzwerk-Interfaces, /etc/systemd/resolved.conf & /etc/dhcp/dhclient.conf (prepend domain-name-servers) drei Anlaufstellen, welche man dann am besten mit der neuen DNS des Wireguard-Servers versieht.
  • Mein VPS unterstützt leider kein IPv6, ich habe aber die Settings mal für dich im Github angelassen. Testen kann ich es nicht, aber die Konfiguration läuft genau so auch unter IPv4, falls dein VPS änlich ist.
  • Scheinbar leiden selbst DoH & DoT unter dem Problem, dass die initialen Client-Hello-Messages vor dem TLS Handshake sichtbar sind (Stichwort ESNI, dies muss also Serverseitig nachgerüstet werden). Das bedeutet konkret, dass ein VPN Server wirklich immer Sinn macht, da man dann im Notfall auf ihn zurückfällt, ohne die eigene IP zu leaken. Adguard liefert mit DNS-over-QUIC einen anderen interessanten Ansatz und begräbt TLS, was man im DNSCRYPT einstellen könnte.

 

Unser NETWAYS Github ist eine super Anlaufstelle, falls du Lust auf noch mehr Open Source hast.

Paralleluniversum 2025: Open Source verboten, Backdoors erlaubt

Nachfolgend eine Satire, fiktiv, aber eventuell basieren auf aktuellen Ereignissen.

Wir schreiben das Jahr 2025. Nach dem Upload-Filter Ende des Jahres 2021, entschied man 2022 sich Hintertüren in verschlüsselte Messenger einzubauen. Um das zu erzwingen gab es 2 Ansätze:

  • Direkt innerhalb der App
  • Im Betriebssystem

Problematisch sollte hierbei Open Source werden, denn wie will man Projekte backdooren, die sich Benutzer selbst aus Offenem Quellcode bauen sollten? Würden sie auf gebauten Packeten basieren, könnte man die Build-Chain kompromitieren, allerdings würde das relativ schnell auffliegen.

  • Bei GPL2 basierenden Projekten musste man gegen rechtliche & lizenbasierte Grundsätze ankämpfen und Ethische Grundsätze in Frage stellen.
  • Ausserdem könnte man doch einfach Projekte forken oder umpatchen?
  • Also hoffte man, dass Nutzer ganz einfach keine Open Source Lösungen benutzen würden, einerseits der Faulheit wegen, andererseits weil Sie es nicht kannten. Promoten dürfte man diese Open Source auf keinen Fall.

 

Nach langen Diskussionen und Ansätzen, war es nun 2023 soweit: Sämtliche Firmen die das backdoor_crypt.over nicht implementierten wollten,  sollten gezielt sanktioniert  und vom Markt entfernt werden.

Das Packet  backdoor_crypt.over war für sämtliche Dienste verfügbar.

  • Das Ziel war es zunächst an die oberste Stelle der Hierarchie der Vertrauenskette zu gelangen, ähnlich wie es in Browsern passiert, nur stat mehreren hierarchischen Top-Signieren, gab es auf einmal nur eine Instanz.
  • Man legte also den Root Trust in die App selbst via der backdoor_crypt.over, und Semi-Closed Source / Closed Source Betriebssysteme sollten gezwungen werden diese API zu priorisieren.

 

  • Man stellte sich also die Frage wie man das denn politisch lösen wollte, sollte jedes Land selbst signieren dürfen oder nur eines?
  • Damit wäre man in Krisensituation direkt chancenlos demjenigen der die Signaturkette kontrollieren durfte.
  • Also entschied man sich, dass jedes Land selbst signieren durfte. D
  • as hieß also es würde eine eingene DE_backdoor_crypt.over geben & eine für FR_backdoor_crypt.over, uvm. geben.

Anfangs gab es Streit, vor allem Signal wollte nicht mitziehen, doch Gesetz ist Gesetz, richtig? WhatApp, Telegram und Teams waren die ersten die mitzogen, und daher die einzigen die im AppStore sowie Googles Android Store verfügbar waren.

  • Also warf man alles was die  backdoor_crypt.over nicht beinhaltete aus den gängigen Plattformen

Das Resumee der Situation war also folgendes:

  • Nicht/Semi-Quelloffene Anwendungen waren leichtes Spiel
  • Quelloffene sowie dezentrale Lösungen wie TOR, Matrix oder die Kombination XMPP/Omemo waren nach wie vor nicht angreifbar.

Zudem ging es bald nicht mehr nur um Messenger, man musste auch Protokolle wie OpenSSL brechen, denn Nuzer könnten doch einfach auf eigene Server connecten, und sich dort Notizen hinterlassen.

Im Jahr 2024 merkte man, dass man eigentlich Garnichts erreicht hatte:

  • Closed Source / Semi-Open Source Firmen waren geschwächt
  • Open Source Projekte boomten noch mehr denn je

Anfang 2025 merkte mann, dass die einzige Lösung die es gab es war Open Source komplett zu verbieten, und nun?

  • Schwerer gedacht als geplant, denn Nutzer forkten einfach weiter, und dezentrale Plattformen waren nicht down zukriegen
  • Bald gab es auch streit innerhalb der Politk selbst, denn diejenigen die Open Source Lösungen verwendeten waren auf einmal nicht mehr überwachbar, das bedeutete, dass die höchste Überwachungsinstanz selbst Open Source Lösungen benutzen musste, um wirklich die höchste zu bleiben, denn würde Sie Closed Source benutzen, wäre sie niemals die Root-Instanz, sondernd nur an zweiter Stelle

Ende 2025 Stand merkte man, dass GNU/Open Source, GPL2 basiert, genau eine Sache signalisierte, Demokratie, und Freiheit. Meinungsfreiheit und Kontrollfreiheit. Zudem war es in der Lage interne Staats- und Firmengeheimnisse zu schützen, und man war nicht nur auf Länder, sondern auch auf Internationaler Ebene flexibel.

  • Man merkte auch, dass es nicht einfach reichte nur wenig Open Source zu benutzen, sondern, wollte man unabhängig sein, im besten fall die Komplette Infrastruktur und alle Front & Backends, sowie inklusive Authentifizierungssystemen nur via Open Source unter eigne Kontrolle bringen konnte.
  • Plötzlich war man auch in Krisensituationen gegen eventuelle bösartige Trigger-Mechanismen, also das Umlegen einer Komponente zum Gezielten Starten eines Botnetzes oder Ausfalls, gesichert.

Was macht man also wenn man selbst der einzige sein will der Kontrolle über seine Infrastruktur haben will? Man benutzt Open Source Lösungen, wie z.b. icinga, oder lässt sich von Open Source Firmen beraten.

 

NETWAYS stellt sich vor – Patrick Dolinic

This entry is part 7 of 63 in the series NETWAYS stellt sich vor

 

 

Name: Patrick Dolinic

Alter: 32

Position bei NETWAYS: Junior Consultant

Bei NETWAYS seit: September 2020

   

 

Wie bist du zu NETWAYS gekommen und was genau gehört zu Deinem Aufgabenbereich?

Gegen Ende meines Psychologiestudiums war der Wunsch sehr stark, keine geschlossene Software zum Arbeiten mehr zu benutzen und eine Firma zu finden, die moralisch und ethisch meinen Grundgedanken folgt. Das heißt, es mussten Growth-Mindset, Privacy und das Erlernen von Open Source Technologien & Computersicherheit möglich sein. Ich wollte unbedingt Linux Sysadmin werden, auch wenn das nach einem Psychologie Master erstmal verwunderlich klingt, ist es das, was mir am meisten Freude macht. Als ich dann auf der NETWAYS-Webseite die Vielzahl an möglichen Weiterbildungen sah, war die Bewerbung noch in der selben Nacht unterwegs.

 

Was macht Dir an Deiner Arbeit am meisten Spaß?

Die Möglichkeit mich komplett Linux hinzugeben, vom Kernel hin bis zu den Netzwerklayern, von aktuellen Trends und warum sie das sind. Dazu kommt, dass man hier von jahrelanger Erfahrung der Ausbilder profitiert und man Antworten auf Fragen findet, die normalerweise extrem schwer zu googlen sind. Auch erlauben es Projekte, die man bekommt, Dinge drumherum zu erforschen, diese sicherheitstechnisch abzusichern, abzuschießen und mit extra Konditionen zu testen. Mittlerweile denke ich, dass es eine Voraussetzung ist, Systeme sicher zu halten und habe gemerkt, dass meine Ausbilder das Wort „Computersicherheit“ teilweise gar nicht mehr benutzen, sondern nur noch auf gemachte / mögliche Fehlerquellen hinweisen.

 

Was machst Du, wenn Du mal nicht bei NETWAYS bist?

Prinzipiell sollte ich eigentlich weniger vor dem Rechner hängen und mehr Sport treiben, aber als Nerd ist das halt so ’nen Ding! Wenn ich also Freizeit habe und meine Zeit nicht mit zocken vergeude *zwinker*, schau ich meistens bei Reddit oder Twitter nach dem aktuellen Computersicherheitsgeschehen, oder schaue Youtubern dabei, zu wie sie CTFs lösen. Noch bin ich wohl ein relativ großer Newbie beim Lösen von CTFs, da ich zu viel schaue und zu wenig mache, aber ich hoffe, das wird sich im Laufe der nächsten Zeit ändern. Ansonsten versuche ich überall Linux draufzuknallen, wo es noch nicht drauf ist, manchmal auch öfters.

 

Wie geht es in Zukunft bei Dir weiter?

Tiefer in Web-Technologien & Betriebssystemkerne abtauchen, schauen, was man da so alles findet und monitoren & automatisieren kann, und bei so vielen Azubiprojekten wie möglich Sicherheits-/Konfigurationsfehler berücksichtigen. Wenn ich bisher eines gelernt habe, dann ist es das: Wenn etwas nicht klappt, schau in die Logs!

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…