☰

Squid-Authentifizierung und -Streaming

tag-icon • tag-icon linux authentication kerberos squid
Squid-Authentifizierung und -Streaming

Ich habe Squid mit Kerberos-Authentifizierung eingerichtet. Außerdem verwende ich Squidguard als URL-Umleitung, um die üblichen Gemeinheiten des Internets auszublenden. Es gibt allerdings einige Websites, auf die wir bestimmten Benutzern den Zugriff erlauben, anderen jedoch nicht. Das funktioniert alles gut, vorausgesetzt, ich verwende kein Streaming.

Soweit ich es aus den Squid-Protokollen und den Wireshark-Traces, die ich erstellt habe, feststellen kann, ist beim Senden der ersten Stream-Anforderung alles in Ordnung. Der authentifizierte Benutzername wird mit der Anforderung an Squidguard gesendet. Das Problem besteht darin, dass der Benutzername bei nachfolgendem Datenverkehr nicht an Squidguard gesendet wird, was dazu führt, dass er gemäß der Standardrichtlinie blockiert wird.

Ich habe versucht, die in Squid integrierte Zulassen/Ablehnen-Funktion zu verwenden, aber sie ist relativ umständlich, und bislang war Squidguard ziemlich einfach und schnell.

Hier kommt/kommen die Frage(n):

  • Wie bringe ich Squid dazu, bei allen Anfragen den Benutzernamen weiterzugeben? (irgendwas sagt mir, dass das nicht der beste Weg ist)
  • Wie kann ich Squidguard dazu bringen, zu erkennen, dass der Datenverkehr einem bestimmten Benutzer zugeordnet ist, auch wenn kein Benutzername übergeben wurde?
  • Gibt es eine andere Möglichkeit, dies zu erreichen?

Einige Details, die von Bedeutung sein könnten:

  • Ich verwende eine in einer Textdatei gespeicherte Benutzerliste, mit der Squidguard einen Vergleich anstellt.
  • Ich verwende die vollständige Kerberos-Authentifizierung mit Squid.
  • CentOS 6.0
  • Tintenfisch 3.1.4
  • Tintenfischwächter 1.3

Bearbeiten

Zur Verdeutlichung habe ich den folgenden Calamaris-Ausschnitt hinzugefügt, um zu zeigen, was passiert:

wsXX.domain.local                       534   5.99      34M   3.04    1   69.93
  *.outsidedomain.com                   204  14.22       5M  20.66    0   92.14
 <error>                                137   0.00       0M   0.00    0  589.16

[email protected]@wsXX.domain.local    115   0.00       1M   0.00   70    0.16
 *.outsidedomain.com                     84   0.00       1M   0.00   73    0.17
 <error>                                 24   0.00       0M   0.00   21    0.00

* BEARBEITEN *

Je weiter ich mich in das Kaninchenloch vorwage, desto mehr scheint es, dass es insbesondere keine Authentifizierung gegen Antworten auf HTTP-Anfragen durchführt. Tatsächlich, wenn ich die Aussage eingebe

    http_reply_access deny !auth

Es lässt keinen https-Verkehr zu, aber den Großteil des http-Verkehrs. Ich bin völlig ratlos, es sieht tatsächlich so aus, als würde es nicht authentifizierten Verkehr durchlassen (das werde ich heute testen) [Getestet, und es lässt nicht authentifizierten http-Verkehr zu, aber Hot https], obwohl ich die folgenden Zeilen in meiner squid.conf habe:

    http_access deny !auth
    http_access allow auth
    http_access deny all

* BEARBEITEN * Ich habe nicht authentifiziertes http und httpsm behoben, alles scheint gut zu funktionieren, außer immer noch bei Streaming-Sites :(

ich musste folgende Zeile in der Konfiguration ändern

   http_access deny !Safe_ports

Zu

   http_access deny !Safe_ports !auth

Antwort1

Also, ich habe das herausgefunden. Es stellte sich heraus, dass es in meiner squid.conf einige andere ACLs gab, die nicht authentifizierten Datenverkehr durch den Proxy ließen. Da diese Regeln vor den Regeln zum Verweigern von nicht authentifiziertem Datenverkehr angewendet wurden, wurde der Datenverkehr nicht authentifiziert durchgeleitet.

Ich hoffe, dass dies eine gute Ressource für jeden ist, der versucht, etwas Ähnliches zu tun.

verwandte Informationen