In der Dokumentation der Extension wird die Einrichtung eines RSS-Feeds unter “XML feeds from tt_news” beschrieben.

Das Ergebnis ist ein RSS 2.0 Feed, ohne Grafik und ohne Absätze. Dieser Artikel beschreibt, wie dies zugefügt werden können.

Der in der Dokumentation aufgelistete TypoScript Code dient als Basis für die weiteren Ausführungen:

Konstanten:

plugin.tt_news {
  displayXML {
    rss2_tmplFile = EXT:tt_news/res/rss_2.tmpl
    xmlFormat = rss2
    xmlTitle = example.com: Latest News
    xmlLink = http://example.com/
    xmlDesc = Latest News
    xmlLang = en
    xmlIcon = fileadmin/tt_news_article.gif
    title_stdWrap.htmlSpecialChars = 1
    title_stdWrap.htmlSpecialChars.preserveEntities = 1
    subheader_stdWrap.stripHtml = 1
    subheader_stdWrap.htmlSpecialChars = 1
    subheader_stdWrap.htmlSpecialChars.preserveEntities = 1
    subheader_stdWrap.crop = 100 | ... | 1
    subheader_stdWrap.ifEmpty.field = bodytext
    xmlLastBuildDate = 1
  }
}

Darauf das die Werte für “xmlTitle”, “xmlLink” “xmlDesc”, “xmlLang” und “xmlIcon” den lokalen Gegebenheiten angepasst werden müssen, wird hier nicht weiter eingegangen. Die Einträge für “title_stdWrap” und “subheader_stdWrap” können auch, wenn dort nichts geändert werden soll, ganz gelöscht werden, da sie die Defaults der Extension darstellen.

Setup:

xmlnews = PAGE
xmlnews {
  typeNum = 100
  10 >
  10 < plugin.tt_news
  10.pid_list >
  10.pid_list = {$plugin.tt_news.pid_list}
  10.singlePid = {$plugin.tt_news.singlePid}
  10.defaultCode = XML
  config {
    disableAllHeaderCode = 1
    additionalHeaders = Content-type:text/xml
    no_cache = 1
    xhtml_cleaning = 0
  }
}

Wichtig ist, das die Konstanten “pid_list” und “singlePid” in TypoScript definiert werden.

Anpassung XML-Template

Damit das XML-Template nicht bei einem Upgrade der Extension überschrieben wird, wird es in einem ersten Schritt eine Kopie erstellt:

cp -a typo3conf/ext/tt_news/res/rss_2.tmpl fileadmin/tpl/ext/ttnews_rss_2.tmpl

In das kopierte Template wird der Marker “###NEWS_IMAGE###” in den “content:encoded” Tag eingefügt, so dass dieser wie folgt aussieht:

<content:encoded><![CDATA[###NEWS_IMAGE### ###NEWS_CONTENT###]]></content:encoded>

Das komplette Template lässt sich hier herunterladen.

Eingebunden wird das kopierte HTML-Template mittels:

plugin.tt_news.displayXM.rss2_tmplFile = fileadmin/tpl/ext/ttnews_rss_2.tmpl

Grafik anpassen

Anstelle des Marker wird im RSS-Feed nun die Grafik des jeweiligen News-Artikels ausgegeben, wobei die Grafik nicht in ihrer Größe angepasst wird. Dies muss nun in TypoScript erfolgen.

Hierfür wird im Setup bei “plugin.tt_news.displayXML.image” eine maximale Weite oder Höhe definiert:

plugin.tt_news.displayXML {
	image {
		file.maxW = 120
		#file.maxH = 90
	}
	xmlWebMaster = webmaster@example.com
}

Wichtig ist, dass entweder die maximale Weite oder die maximale Höhe angeben werden. Wenn beide Werte angegeben werden, werden die Grafiken fest auf diesen Wert skaliert. In den meisten Fällen ist sicherlich die maximale Weite angeben, wenn der RSS-Feed aber automatisch (z.B. mittels RSS.Graffiti) auf Facebook eingebunden werden soll, ist für maximale Höhe ein Wert von 80 oder mehr sinnvoll, da ansonsten die Grafiken von Facebook oft nicht eingebunden werden.

Die Angabe des Webmasters bei “xmlWebMaster” kann bei technischen Problemen für die Kontaktaufnahme sinnvoll sein.

Nun benötigen die Grafiken noch eine absolute URL. Hierfür wird im Setup den relativen Links ein Präfix geben:

xmlnews.config.absRefPrefix = http://example.com/

Absatz-Formatirung erhalten

Ohne weitere Bearbeitung würde der gesamte News-Text als Fließtext, ohne jegliche Absätze, in den RSS-Readern erscheinen. Gerade bei längeren Texten kann dies dazu führen, dass der Text nicht mehr lesbar ist.

Abhilfe schafft hier der folgende Eintrag:

plugin.tt_news.displayXML.content_stdWrap.parseFunc < tt_content.text.20.parseFunc

Fertiges TypoScript

Somit ergibt sich folgende TypoScipt:
Konstanten:

plugin.tt_news {
  displayXML {
    pid_list = 47,11                          # Wert den lokalen Gegebenheiten anpassen
    singlePid = 42                            # Wert den lokalen Gegebenheiten anpassen
    rss2_tmplFile = fileadmin/tpl/ext/ttnews_rss_2.tmpl
    xmlFormat = rss2
    xmlTitle = example.com: Latest News       # Wert den lokalen Gegebenheiten anpassen
    xmlLink = http://example.com/             # Wert den lokalen Gegebenheiten anpassen
    xmlDesc = Latest News                     # Wert den lokalen Gegebenheiten anpassen
    xmlLang = de
    xmlIcon = fileadmin/tt_news_article.gif   # Wert den lokalen Gegebenheiten anpassen
    xmlLastBuildDate = 1
  }
}

Setup:

plugin.tt_news.displayXML {
	image {
		#file.maxW = 120
		file.maxH = 90
	}
	xmlWebMaster = webmaster@example.com  # Wert den lokalen Gegebenheiten anpassen
	content_stdWrap.parseFunc < tt_content.text.20.parseFunc
}
 
xmlnews = PAGE
xmlnews {
  typeNum = 100
  10 >
  10 < plugin.tt_news
  10.pid_list >
  10.pid_list = {$plugin.tt_news.pid_list}
  10.singlePid = {$plugin.tt_news.singlePid}
  10.defaultCode = XML
  config {
    disableAllHeaderCode = 1
    additionalHeaders = Content-type:text/xml
    no_cache = 1
    xhtml_cleaning = 0
  }
}
 
page.headerData.500 = TEXT
page.headerData.500.value = <link rel="alternate" type="application/rss+xml" title="example.com: Latest News" href="http://example.com/index.php?id={$xmlnewsfeed_id}type=100" />

©2012 Dirks Blog. All Rights Reserved.

©2012 Dirks Blog. All Rights Reserved.

Es gibt sowohl Aufrufe, Free und Open Source Software mit Flattr zu unterstützen, als auch die gegensätzliche Postion. Hautkritik an Flattr ist hier die Gebühr von 10%, die Flattr bei jeder Zahlung abzieht. Martin schreibt in seinem Blog: “Von Flattr profitieren weder die Spender, noch die die Spenden erhalten, sondern einzig und alleine Flattr”.

Da auf dem Planet ubuntuusers.de zzt. Blog Beiträge mit einem Flattr-Button nicht durchgelassen werden, gibt es schon die ersten Rückzüge aus dieser Community.

Es bleibt abzuwarten, in welche Richtung diese Diskussion weiter geht und ob sich Flattr wirklich zu einem Beitrag der Finanzierung von Free und Open Source Software entwickelt.

©2012 Dirks Blog. All Rights Reserved.

Software

Um WordPress dazu zu bringen, SSH für die Aktualisierungen zu verwenden, wird libssh2 und die PHP Bindings für SSH benötigt. Wenn diese Bestandteil der Distribution sind, gut, ansonsten müssen sie selber compiliert werden oder Pakete bei den einschlägigen Quellen gesucht werden. Für Debian habe ich Backports der aktuellen Versionen der Pakete libssh2 und php-ssh2 erstellt, die in der aktuellen Debian Version “Lenny” verwendete libssh2-Version muss auch ersetzt werden.

SSH-Schlüsselpaar

Benötigt wird ein SSH-Schlüsselpaar. Da der Apache-Daemon lesend auf den privaten Schlüssel zugreifen muss, sollte ein extra Schlüsselpaar für die WordPress Updates verwendet werden. Hierfür im Home-Verzeichnis (oder einem anderen, nicht auf dem Webserver publizierten Verzeichnis) “ssh-keygen” ausführen:

ssh-keygen -C WordPress -f id_wp

Hierdurch wird der private Schlüssel “id_wp” und der öffentlich Schlüssel “id_wp.pub” erzeugt. Letzterer erhält zusätzlich  den Kommentar “WordPress”. Da, wie erwähnt, der Webserver auch auf den privaten Schlüssel lesend zugreifen muss, müssen die Rechte dieses Schlüssels entsprechend angepasst werden:

chgrp www-data id_wp.pub
chmod g+r id_wp.pub

In einem weiteren Schritt muss der private Schlüssel noch die Datei “authorized_keys” eingetragen werden:

cat id_wp.pub >> ~/.ssh/authorized_keys

WordPress konfiguieren

Zum Schluss müssen noch die folgenden Zeilen der WordPress Konfiguration “wp-config.php” zugefügt werden:

/* Updates über SSH: */
define('FTP_PUBKEY','/home/user/id_wp.pub');
define('FTP_PRIKEY','/home/user/id_wp');
define('FTP_USER','user');
define('FTP_HOST','localhost:22');

Selbstverständlich müssen Pfade und User an die lokalen Gegebenheiten angepasst werden.

©2012 Dirks Blog. All Rights Reserved.

Nicht so richtig mitspielen will da Microsofts mit seinem “Outlook Social Connector für Facebook und Windows Live“, dieser Connector sendet die Mail-Adressen nur als Hash-Wert an Facebook und Co, es sei denn, man drück den Add-Button, womit man Facebook auffordert, die Person einzuladen.

Was der Connector ansonsten bringt? Bei jeder Mail werden nun die Aktivitäten des Absenders bei Facebook und Co. angezeigt. Der “aufwendige” Schritt der manuellen Recherche entfällt, was manchen Personaler bei Einstellungen erfreuen dürfte. Für Mircosoft in es ein Versuch, an die verschlafene Entwicklung der Sozialen Netze anzuknüpfen.

©2012 Dirks Blog. All Rights Reserved.

Was alles an Ports auf einem System offen ist, kann auf diesem System mittels netstat -lnptu festgestellt werden. Hierbei werden alle offenen TCP und UDP Ports mit den jeweiligen IP-Adressen, PIDs und Programmnamen angezeigt. Weitere Informationen sind der Manpage von “netstat” zu entnehmen.

Mittels Portscannern können auch andere Rechner nach offenen Ports untersucht werden oder der eigene Rechner von außen. Ein einfach Scan wäre z.B. mittels telnet möglich, indem versucht wird, sich mit jedem einzelnen interessanten Port zu verbinden. Moderne Scanner (wie z.B. nmap) sind darüber hinaus in der Lage einen so genannten Stealth-Scan durch zuführen, wobei der Verbindungsaufbau nicht komplett durch geführt wird und somit evtl. nicht in den Logfiles gespeichert wird. Oft ist es mit diesen Tools möglich, weitere Informationen über das gescannte System zu erhalten, wie z.B. das jeweils verwendete Betriebssysteme oder die Uptime.

• Webserver Apache: In der Datei “httpd.conf” der Eintrag Listen 10.0.0.1:80 für jeden (Name)VirtualHost.
• DNS-Server Bind: In der Datei “named.conf” der Eintrag listen-on { 10.0.0.1; 127.0.0.1; }.
• Common UNIX Printing System (CUPS): In der Datei “cupsd.conf” muss für jede IP-Adresse ein Eintrag in der Form Port 10.0.0.1:631 erstellt werden.Zusätzlich gibt es neben der Interface-Bindung bei CUPS ein eigenes System von Zugriffsberechtigungen, die für jedes einzelne Verzeichnis (z.B. admin, printers oder printer/name) gesetzt werden können. Diese sollten für ein internes Berechtigungskonzept verwendet werden.
• Cyrus IMAP: Ab Version 2.0 wird der Cyrus IMAP Server über einen eigenständigen Dienst “cyrmaster” gestartet, der über die Datei “cyrus.conf” für jeden Cyrus Dienst (IMAP, POP3, Sieve, etc.) eine eigenständige Bindung an bestimmte IP-Adressen oder einen UNIX-Sockets ermöglicht (zuvor wurde dieser Server über den inetd gestartet).Für die verwendeten Dienste muss dort unter “SERVICES” der “listen”-Eintrag um den Hostnamen (z.B. localhost) oder die IP-Adresse ergänzt werden. Für den IMAP sähen die Einträge z.B. wie folgt aus:
  imap cmd=”imapd -U 30″ listen=”localhost:imap” prefork=0 maxchild=100
  imaps cmd=”imapd -s -U 30″ listen=”10.0.0.1:imaps” prefork=0 maxchild=100.
  Hierbei wird der IMAP-Dienst an das Loopback-Interface gebunden und der IMAP over SSL an die gewünschte Netzwerkkarte.
• DHCP Server: Auch hier kann im Runlevel-Startscript bei den Start-Optionen die Bindung an eine oder mehrer Netzwerkkarten festgelegt werden. Hierfür muss dem DHCP-Daemon einfach das entsprechende Interface übergeben werden, also z.B. dhcpd eth0 lo.Da DHCP teilweise über Broadcast-Anfragen abläuft, ist dieser Dienst zwar weiter an die IP-Adresse 0.0.0.0 gebunden, es werden aber Anfragen, die nicht über die angebenen Interfaces ankommen verworfen.
• Newsserver INN: In der Datei “inn.conf” der Eintrag bindaddress: 10.0.0.1.
• Datenbank MySQL: Im Runlevel-Startscript kann bei den Start-Optionen die Bindung festgelegt werden. Es gibt dort zwei Möglichkeiten:Wenn nur lokal auf die Datenbank zugegriffen werden soll, kann der Zugriff auf UNIX-Sockets reduziert werden: –skip-networking.Ansonsten kann MySQL an die interne Netzwerk-Adresse gebunden werden: –bind-address=10.0.0.1.
• Verzeichnisdienst OpenLDAP: Im Runlevel-Startscript kann als Start-Option mittels des Parameters -h URL-Liste eine Liste von URLs übergeben werden, an die der “Standalone LDAP Daemon – slapd” gebuden werden soll.Die URL-Liste besteht aus mittels Leerzeichen getrennten einzelnen URLs in der Form ldap://127.0.0.1/ oder ldap://127.0.0.1:9009/, womit “slapd” entweder an seinen Standardport 389 auf Locelhost oder aber an einen beliebigen anderen Port (in dem Beispiel 9009) auf Locelhost gebunden wird. Ebenso ist es möglich, mittels ldapi:/// den LDAP-Server an Unix-Sockets (IPC) zu binden.
• Mailserver Postfix: In der Konfigurationsdatei “main.cf” den Parameter inet_interfaces = loopback-only eintragen.
• PostgreSQL Datenbank: In der Konfigurationsdatei “postgresql.conf” kann mittels des Eintrags virtual_host = ’127.0.0.1′ die Bindung an eine IP-Adresse erfolgen oder mittels des Eintrags virtual_host = localhost die Bindung an den Hostname erfolgen.Ebenso ist es möglich, den PostgreSQL Server direkt mittels der Startoptionen postmaster -h 127.0.0.1 oder postmaster -h localhost zu starten.
• SaMBa-Server: In der Datei “smb.conf” die Einträge interfaces = 10.0.0.1/24 und bind interfaces only = yes.Hierbei werden der Fileservice “smbd” und der Nameservice “nmbd” unterschiedlich behandelt. “smbd” wird auf der angegebene IP-Adresse an Port 139 gebunden während “nmbd” zum einen an diese IP-Adresse auf den Ports 137 und 138 gebunden wird und zusätzlich noch einmal an diese Ports auf der IP-Adresse 0.0.0.0, um Broadcast-Anfragen entgegen nehmen zu können. Damit kann dieser Dienst zwar von überall Broadcast-Anfragen entgegen nehmen, er verwirft sie aber, wenn sie nicht aus dem mit interfaces angegebenen Absendebereich kommen (siehe aber auch IP-Spoofing). Wenn eine Einbindung des Rechners nicht in den Windows-Nameservice benötigt wird, kann aber im Startscript der Start des “nmbd” komplett deaktiviert werden.
• Mailserver Sendmail: Bei Sendmail hat sich zwischen den Versionen 8.10.0 und 8.12.0 die Funktionsweise für die Verarbeitung lokal erstellter Mails geändert. Ab 8.10.0 bietet Sendmail hierfür die Funktion Message Submission Agent (MSA), nach RFC2476, an. Diese ist ab Version 8.12.0 zwingend, da der nicht standardgemäße SMTP-Befehl XUSR nicht mehr unterstützt wird.Für die Konfiguration von Sendmail gibt es unterschiedlich Möglichkeiten. Einmal über Konfigurationsmakros und einmal über die mittels dieser erstellten Konfigurationsdatei.
  • In der m4 Konfigurationsdatei “sendmail.mc” kann mittels der Einträge DAEMON_OPTIONS(‘Addr=10.0.0.1, Name=MTA’)dnl und DAEMON_OPTIONS(‘Addr=127.0.0.1, Port=587, Name=MSA, M=E’)dnl eine Bindung an eine IP-Adresse erfolgen. Hierbei wird Sendmail als MSA für die Mails vom lokalem Rechner an die Loopback-Adresse gebunden und als MTA für das interne Netz an die interne IP-Adresse.Bei älteren Sendmail Versionen (vor 8.10.0) erfolgt dies mittels des Eintrags define(‘confDAEMON_OPTIONS’,‘Addr=10.0.0.1’). Einen MSA gibt es hier, wie oben erwähnt, noch nicht.Zu Beachten ist hierbei, dass oft schon mittels der zentralen Makros der Eintrag für den MSA gesetzt wird. Hier ist es dann notwendig, diesen mittels des Eintrags FEATURE(`no_default_msa’)dnl erst einmal zu deaktivieren und dann, wie zuvor beschrieben, zu setzen. Da Sendmail nur den ersten Wert ausführt, würde ansonsten evtl. die Einstellung wirkungslos. Deshalb muss ein vorhandener Eintrag auch immer geändert werden und nicht mittels eines zweiten Eintrags ergänzt werden.
  • In der Konfigurationsdatei “sendmail.cf” können die Werte O DaemonPortOptions=Addr=10.0.0.1, Name=MTA und O DaemonPortOptions=Addr=127.0.0.1, Port=587, Name=MSA, M=E gesetzt werden. Falls es schon Einträge für MTA und MSA gibt, müssen diese entsprechend ergänzt werden, da ansonsten immer der erste Eintrag verwendet wird. Bei älteren Sendmail Versionen gilt dies entsprechend nur für den MTA-Eintrag.
• Squid Web Proxy Cache: In der Datei “squid.conf” der Eintrag http_port 10.0.0.1:3128 (oder ein anderer gewünschter Port wie z.b. 8080). Es sind hier mehrere Einträge möglich, um Squid an unterschiedliche IP-Adressen/Ports zu binden.Um die Verständigung des Squid mit anderen Nachbar-Caches über ICP (Interprocess Comunication Protocoll) auf eine IP-Adresse zu binden, kann der Eintrag udp_incoming_address 10.0.0.1 verwendet werden. Diese kann im Standalone-Betrieb aber auch mittels icp_port 0 gleich ganz deaktiviert werden.Ältere Versionen des Squid (<2.3) kennen die Bindung mittels des Eintrags http_port nicht. Hier kann mittels des Eintrags tcp_incoming_address 10.0.0.1 dies erreicht werden (wobei auch über ein Update mal nachgedacht werden sollte).
• SSH Daemon: In der Datei “sshd_config” der Eintrag ListenAddress 10.0.0.1.
• X-Server: Beim Aufruf des X-Servers kann mittels des Aufrufparameters -nolisten tcp die Bindung an IP-Sockets deaktiviert werden. Es erfolgt nur noch eine Bindung an die die UNIX-Sockets, was nicht nur für den lokalen Betrieb ausreicht, sondern auch die schnellere Verbindung ist. Im Allgemeinen wird der X-Server über den X Display Manager (xdm) gestartet. Dort sind die Aufrufparameter für den X-Server in der Datei “Xservers” oder “xserverrc” (je nach Distribution) zu finden.Wenn aber ein Remote-Zugriff für den X-Server benötigt wird, kann diese Einstellung nicht verwendet werden. Hier kann als Alternative in der Datei Xaccess eine detaillierte Zugriffsgewährung für einzelne Clients erfolgen oder, als sinnvollere da sichere Alternative, die Anbindung über SSH.

©2012 Dirks Blog. All Rights Reserved.

Aber Facebook ist da nicht alleine, Google hat diese Möglichkeit seinen Werbebannern schon länger, Stichwort ist hier “Google Analytics” und seit diesem Frühjahr gibt es den Mircopayment-Dienst Flattr. Die auf Recht der Neuen Medien spezialisierte Kanzlei Dr. Bahr geht davon aus, dass nach deutschem Datenschutzrecht praktisch ein Großteil des Web 2.0 rechtswidrig ist.

Wer diese mögliche Nutzerprofile nicht möchte, hat eigentlich nur noch die Möglichkeit mittels Werbeblockern in seinem Browser dies zu verhindern. Für Firefox bittet sich die Erweiterung “Adblock Plus” an. Diese muss dann noch manuell um Flattr, Facebook und ähnliche Dienste erweitert werden:
api.flattr.com^$third-party
facebook.com^$third-party
tweetmeme.com^$third-party

Es sollte aber zumindest erwähnt werden, dass mit Flattr ein Micropayment-Dienst entsteht, der sich lohnt in nächster Zeit weiter zu beobachten. Die Kommentare im Netz sind da durchaus mal positiv und mal negativ.

Last but not least, ich habe ein Facebook Account, aber da weiß ich selber, was ich Facebook mitteile.

©2012 Dirks Blog. All Rights Reserved.

Grade eben erst hatten wir Ihnen, dem vatikanischen Kardinalstaatssekretär, der rechten Hand von Benedikt Ratzepapst, Gottes Stellvertreterstellvertreter also, geraten, sich fürderhin in Schweigen zu hüllen und die Öffentlichkeit zu meiden wie der Pfarrer das Planschbecken, da erregten Sie sich laut Spiegel über eine Razzia bei der belgischen Bischofskonferenz, wo es galt, alte Akten über pädophile Priester aufzutreiben. Die von der Polizei durchsuchten Bischöfe wurden nämlich neun Stunden lang ohne Essen und Trinken festgehalten; eine grausame und demütigende Behandlung, die man nicht einmal Tieren oder Zimmerpflanzen angedeihen lassen sollte – oder, wie Sie, Bertone, es ausdrückten: »Als wären sie Kinder«. Eminenz! Das haben Sie nicht wirklich gesagt, oder? Das hat sich der Spiegel ausgedacht, oder? Denn wenn Sie Ihren kircheninternen Kinderdrill samt Einsperren und Hungernlassen nun schon öffentlich und anlaßlos eingestehen, dann läßt das nur zwei Schlüsse zu: daß Ihnen a) schon alles wurscht ist, weil inzwischen ruhig jeder wissen kann, was in Ihrer Institution so los ist, oder daß Sie b) die relativ neue christliche Tugend der Selbstironie entdeckt haben.

Wir tippen auf a).

Aus TITANIC   Briefe an die Leser August 2010 und der erwähnte Artikel des Spiegels.

Die Titianic hat es hier kurz und knapp auf den Punkt gebracht. Der eigentliche Skandal ist der Missbrauch durch diverse Kirchenvertreter, aber ursächlich hierfür ist das Menschenbild das sich in der Formulierung “Als wären sie Kinder” offenbart. Und ja, in diesem Kontext ist kein Wort unschuldig!

©2012 Dirks Blog. All Rights Reserved.

Auf den ersten Blick hatte aber auch “timtab_sociable” einen entscheidenden Nachteil, aktuelle Social Networks, wie Facebook, Twitter und StudiVZ werden nicht unterstützt. Vorteil ist aber, die Extension kann flexibel konfiguriert werden und es können ihr damit neue Social Links beigebracht werden..

Hierfür ist in dem Template der Seite die folgendes Setup sinnvoll:

### Sociable Bookmarks:
plugin.tx_timtabsociable_pi1 {
	services {
		facebook {
			icon {
				file = fileadmin/technik/facebook.png
				altText = Facebook Teilen
				titleText = Facebook Teilen
			}
			url = http://www.facebook.com/sharer.php?u=%URL%&t=%TITLE%
			title = Facebook Teilen
			target < plugin.tx_timtabsociable_pi1.iconTarget
			wrap < plugin.tx_timtabsociable_pi1.iconWrap
		}
		twitter {
			icon {
				file = fileadmin/technik/twitter.png
				altText = Twitter
				titleText = Twitter
			}
			url = http://twitter.com/home?status=%URL%
			title = Twitter
			target < plugin.tx_timtabsociable_pi1.iconTarget
			wrap < plugin.tx_timtabsociable_pi1.iconWrap
		}
		myvz {
			icon {
				file = fileadmin/technik/myvz.png
				altText = studiVZ meinVZ schülerVZ
				titleText = studiVZ meinVZ schülerVZ
			}
			url = http://www.studivz.net/Suggest/Selection/?u=%URL%&desc=%TITLE%
			title = studiVZ meinVZ schülerVZ
			target < plugin.tx_timtabsociable_pi1.iconTarget
			wrap < plugin.tx_timtabsociable_pi1.iconWrap
		}
		live {
			icon.altText = Windows Live
			icon.titleText = Windows Live
			title = Windows Live
		}
	}
	# Lokalisierung in einer deutschsprachigen Umgebung:
	# _LOCAL_LANG.de.tagline = Social Bookmarks

	# Oder lieber die Tagline ausschalten:
	# tagline <

	# Nur die gewünschten Social Links anzeigen:
	activeServices = twitter,facebook,myvz,google,live,misterwong,delicious,yahoomyweb
}

Ach ja, die verwendeten Grafiken:
Facebook:
Twitter:
StudiVZ:

©2012 Dirks Blog. All Rights Reserved.

• “Squid” installieren
• Basis Konfiguration des “Squid”
  • Netzwerk Optionen
  • Cache Optionen
  • Logfile- und Cache-Verzeichnisse
  • Optionen für externe Programme
  • Administrative Parameter
  • Verschiedenes
• Access Control Lists (ACL)
• User-Authentifizierung
  • Authentifizierung mittels Passwortdatei
  • Authentifizierung mittels Pluggable Authentication Modules (PAM)
  • Authentifizierung mittels Lightweight Directory Access Protokoll (LDAP)
  • Authentifizierung gegen eine Windows NT Domäne
• “Squid” als Transparenter Proxy
• “Squid” starten

Die Webseiten des Squid Web Proxy Cache.
Eine deutsche Übersetzung des Squid Proxyserver Administrationshandbuch.

“Squid” installieren

Falls keine aktuelle Version des Squid Proxy der verwendeten Linux Distribution beiliegt, kann die aktuelle Version von der Squid Seite aus bezogen werden. Diese wird mit den folgenden Befehlen kompiliert und installiert:

$ ./configure --prefix=/usr/local/squid
$ make all
# make install

Hierbei wird Squid in das Verzeichnis /usr/local/squid installiert.

Wer die Konfigurationsdateien lieber im Verzeichnis /etc/squid liegen haben möchte statt in /usr/local/squid/etc, der kann bei ./configure auch noch die Option --sysconfdir=/etc/squid angeben.

Wer lieber deutschsprachige Fehlerseiten verwenden möchte, kann ./configure noch zusätzlich die Option --enable-err-language=German übergeben. Somit sähe der ./configure-Aufruf wie folgt aus:

$ ./configure --prefix=/usr/local/squid --sysconfdir=/etc/squid --enable-err-language=German

Basis Konfiguration des “Squid”

Konfiguriert wird der Squid Proxy über die Konfigurationsdatei squid.conf. Eine Vorlage hierfür liegt, ausgehend von der obigen Installation, nun entweder im Verzeichnis /usr/local/squid/etc oder /etc/squid. In älteren GNU/Debian Paketen liegt sie unter /etc. Wenn schon, vielleicht von einer älteren Squid Version, dort eine Konfigurationsdatei liegt, wird diese nicht überschrieben. Zusätzlich wird noch in jedem Fall eine zweite Vorlage squid.conf.default dort angelegt. Diese ist recht praktisch, wenn man von einer älteren Squid Version updatet.

Nachfolgend werden nun relevante Teile der Einstellungen in der Konfigurationsdatei squid.conf beschrieben. Diese Aufstellung erhebt keinen Anspruch auf Vollständigkeit. Besonders auf den Bereich “Proxy-Farmen (neighbor caches)” wird nicht eingegangen. Ebenso wird auf Einstellungen, deren Default-Werte übernommen werden können, nur selten eingegangen.

Eine ausführlichere Beschreibung ist in der Konfigurationsdatei selbst enthalten oder als FAQs auf den Webseiten des Squid Proxy.

Netzwerk Optionen

Hier sind einige Einstellungen zu den Netzwerkbindungen und den verwendeten Protokollen zu treffen.

Netzwerkbindung:

#  TAG: http_port
#   Usage:  port
#       hostname:port
#       1.2.3.4:port
…
#Default:
# http_port 3128
http_port 10.0.0.1:3128
http_port 10.0.0.1:8080

Hier wird festgelegt, auf welchem Port oder IP-Adresse/Port bzw. Hostname/Port Squid Verbindungen annimmt. Hierbei können mehrere Adressen in unterschiedlichen Zeilen angegeben werden.

Die Standardeinstellung ist, dass Squid Verbindungen auf allen IP-Adressen des Rechners auf Port 3128 entgegen nimmt. Eine sinnvolle Änderung wäre das binden an die interne IP-Adresse (z.B. 10.0.0.1), damit der Proxy nur von intern zu erreichen ist. Außerdem erwachten viele Anwender einen Proxy auf dem Port 8080, deshalb kann es recht sinnvoll sein, Squid auf beiden Ports lauschen zu lassen..

ICP Protokoll:

#  TAG: icp_port
…
#Default:
# icp_port 3130
icp_port 0

Das Internet Cache Protocoll (ICP) dient der Kommunikation des Squids mit anderen Proxies und ist definiert im RFC2186 und RFC2187. Eine Kommunikation mit anderen Proxies wird eher in größeren Netzwerken benötigt und dementsprechend sollte dieses Protokoll im Einzelbetrieb mittels der Portangabe 0 deaktiviert werden.

Cache Optionen

Bestimmte Objekte nicht speichern:

#  TAG: no_cache
…
#We recommend you to use the following two lines.
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY

Hier kann dem Proxy mittels Access Control Lists (ACL) mitgeteilt werden, welche Seiten nicht gespeichert werden sollen. Die Voreinstellung erfasst einen großen Teil der dynamischen Websites, indem alle Adressen, die ein “cgi-bin” oder ein Fragezeichen (dieses trennt die Aufrufparameter einer Seite von der Seitenadresse und muss in Regulären Ausdrücken mit einen Backslash “\” maskiert werden) beinhalten, vom Speichern ausgeschlossen werden.

Hier können weitere Adressen, wie zum Beispiel der eigene Server oder das lokale Netzwerk eingetragen werden.

Weitergehende Hinweise zur Verwendung von ACLs folgen später.

Speichergröße:

#  TAG: cache_mem   (bytes)
…
#Default:
# cache_mem 8 MB
cache_mem 32 MB

Hier wird festgelegt, wieviel Arbeitsspeicher Squid maximal dafür verwendet einkommende Daten, sehr oft angefragte Objekte und sog. Negative-Cached Objekte (diverse Statusmeldungen des HTTP-Protokolls) im Arbeitsspeicher zwischen zu speichern. Hierbei haben einkommende Daten absoluten Vorrang.

Diese Angabe bezieht sich nicht auf den von Squid insgesamt benötigten Arbeitsspeicher, sondern ist nur ein bestimmter Teil davon.

Bei der heutigen Ausstattung von PCs mit Arbeitsspeicher kann diese Angabe ruhigverdoppelt oder vervierfacht werden. Auf Proxies, die für die Versorgung ganzer Netzwerke zuständig sind, sollte dies sogar geschehen.

Logfile- und Cache-Verzeichnisse

Cache-Verzeichnis:

#  TAG: cache_dir
…
#Default:
# cache_dir ufs /usr/local/squid/var/cache 100 16 256
cache_dir ufs /var/cache/squid 100 16 256

Hier wird festgelegt, welche Speichermethode verwendet wird, in welchem Verzeichnis der Cache liegen soll, wie groß der Cache sein soll und welche Unterverzeichnisstruktur verwendet werden soll.

Als Speichermethode ist standardmäßig nur “ufs” (Unix Filesystem) verfügbar. Andere Speichermethoden sind nur dann verfügbar, wenn sie extra mit ein kompiliert wurden.

Das Verzeichnis sollte entsprechend den eigenen Gegebenheiten (Festplattenplatz) und grundsätzlichen Überlegungen (was wird beeinträchtigt, wenn die Festplatte voll ist) angepasst werden. Die obige Vorgabe beruht auf den bei der Installation angegebenen Parameter –prefix=/usr/local/squid. Da es sich aber bei den Inhalten des Squid-Caches um variable Daten handelt, sollten diese besser auch im entsprechenden Bereich /var des Filesystems liegen, der auch oft auf einer eigenen Festplatten-Partition liegt. Deshalb die Angabe /var/cache/squid als Cache-Verzeichnis. Hierbei ist zu beachten, dass dieses Verzeichnis existieren und für Squid beschreibbar sein muss, damit der Squid Proxy starten kann. Mit dem Befehl squid -z kann das Cache-Verzeichnis mit allen benötigten Unterverzeichnissen angelegt werden.

Die anderen Angaben (Größe in MB und Struktur – 16 Unterverzeichnisse mit jeweils 256 weiteren Unterverzeichnissen – des Caches) können so belassen werden.

Logfile-Path:

#  TAG: cache_access_log
…
#Default:
# cache_access_log /usr/local/squid/var/logs/access.log
cache_access_log /var/log/squid/access.log

#  TAG: cache_log
…
#Default:
# cache_log /usr/local/squid/var/logs/cache.log
cache_log /var/log/squid/cache.log

#  TAG: cache_store_log
…
#Default:
# cache_store_log /usr/local/squid/var/logs/store.log
cache_store_log /var/log/squid/store.log

Entsprechend sollten die Logfiles als variable Daten auch unter /var abgelegt werden. Hinzu kommt, dass dort auch die Logfiles der anderen Programme liegen. Hierbei ist zu beachten, dass Squid das Recht haben muss, in diesem Verzeichnis Dateien an zu legen. Deshalb ist ein eigenes Verzeichnis für die Squid-Logfiles sinnvoll.

Access-Log Type:

#  TAG: emulate_httpd_log       on|off
…
#Default:
# emulate_httpd_log off
emulate_httpd_log on

Standardmäßig wird das “access.log” Logfile, das Auskunft über die Zugriffe gibt, in einem Squid eigenen Format abgespeichert. Es ist aber auch möglich, das sog. “common” Format zu verwenden, das diverse HTTP-Server, wie z.B. “Apache”, verwenden, wenn man dieses Format besser auswerten kann.

Prozess-ID-Datei:

#  TAG: pid_filename
…
#Default:
# pid_filename /usr/local/squid/var/logs/squid.pid
pid_filename /var/run/squid.pid

Auch die Datei, die die Prozess-ID des Squids beinhaltet, sollte in dem entsprechenden Verzeichnis unter /var abgelegt werden. Auch hier ist unbedingt darauf zu achten, dass Squid das Recht haben muss, diese Datei anzulegen.

Debuging Informationen in den Logfiles:

#  TAG: debug_options
…
#Default:
# debug_options ALL,1

Die Logging-Optionen sind eine Kombination aus Logging-Bereich und Logging-Level, getrennt mittels Komma. Ein geringes Logging-Level führt zu kleinen Logfiles und ein Logging-Level “9″ (als höchster Wert) kann zu sehr großen Logfiles führen. Der Logging-Bereich “ALL” umfasst alle Bereiche. Die Standardeinstellung “ALL,1″ ist für den Normalbetrieb völlig ausreichend. Nur wenn es Probleme gibt, sollte man sich langsam in den Logging-Levels bis “9″ nach oben arbeiten.

Logging der IP-Adresse oder Rechner-Namens

#  TAG: log_fqdn        on|off
…
#Default:
# log_fqdn off

Standardmäßig wird in den Logfiles nur die IP-Adresse den abfragenden Clients gespeichert. Wenn stattdessen der vollständige Rechnername (mit Domainteil auch Fully Qualified Domain Name = FQDN) gewünscht wird, so ist diese Option zu aktivieren.

Privacy-Einstellung:

#  TAG: client_netmask
…
#Default:
# client_netmask 255.255.255.255

Wenn die Privatsphäre der Clients bewahrt werden soll oder muss (z.B. Datenschutz in Unternehmen), kann hier eine Netzwerk-Maske definiert werden, die dazu führt, dass die einzelnen Logfile-Einträge nicht mehr einem Rechner zuordbar sind.

Eine Netzwerk-Maske von 255.255.255.0 würde dazu führen, dass bei allen IP-Adressen in den Logfiles und der cachemgr Ausgabe die letzte Stelle als “0″ dargestellt wird. Beim Standardwert 255.255.255.255 wird die komplette Adresse angezeigt.

Optionen für externe Programme

Anonymous FTP-User:

#  TAG: ftp_user
…
#Default:
# ftp_user Squid@

Beim Anonymous FTP-Zugriff gilt es als höflich, dass Nutzer als eine E-Mail-Adresse als Passwort eingibt. Da einige FTP-Server ohne Angabe einer gültigen E-Mail-Adresse keinen Zugriff gewähren, sollte hier eine gültige Adresse eingetragen werden.

Passives FTP:

#  TAG: ftp_passive
…
#Default:
# ftp_passive on
ftp_passive off

Wenn passives FTP Probleme bereitet, kann dies hier ausgeschaltet werden.

Aktives FTP ist aber aus Sicherheitsgründen sehr bedenklich, da die Gegenseite dann selber eine Verbindung herstellen muss, und sollte vermieden werden.

Schemas zur User-Authentifizierung:

#  TAG: auth_param
…

Hier können verschiedene Schemata zur User-Authentifizierung eingestellt werden.

Dieses Thema wird später ausführlich in einem separaten Kapitel zur User-Authentifizierung behandelt.

#  TAG: external_acl_type
…

Mittels Hilfsprogramme können hier externe ACLs definiert werden.

Auch dieses Thema wird später ausführlich anhand eines LDAP-Filters erklärt.

Administrative Parameter

E-Mail-Adresse des Admins

#  TAG: cache_mgr
…
#Default:
# cache_mgr webmaster

E-Mail-Adresse des Squid-Admins, an den Meldungen über einen evtl. Absturz des Proxies gesendet werden sollen. Die Standardeinstellung ist “webmaster”.

Standarduser und -gruppe:

#  TAG: cache_effective_user
#  TAG: cache_effective_group
…
#Default:
# cache_effective_user nobody
cache_effective_user squid
cache_effective_group squid

Diese Einstellung bewirkt, dass wenn der Squid Proxy als Root gestartet wird er die angegebene User- und Gruppen-ID annimmt. Ist kein User angegeben, wird UID des Users “nobody” und als GID dessen Standardgruppe angenommen.

Wenn Squid nicht als Root gestartet wird, behält er die aktuelle UID/GID und es kann nur die GID zu einer der Gruppen gewechselt, wo der aktuelle User auch Mitglied ist.

Dies ist ein Schutz davor, dass der Squid-Prozess als Root volle Kontrolle über das System hätte. Die Voreinstellung “nobody” sollte aber auch nicht verwendet werden, da evtl. diverse Prozesse unter dieser User-ID laufen und bei einem erfolgreichen Angriff der Angreifer auf zu viele Programme Zugriff hätte. Es ist deshalb sinnvoll, dem Squid Proxy eine eigene UID und GID zu geben, die selbstverständlich auf dem System existieren müssen.

Vollständiger Rechnername

#  TAG: visible_hostname
…
#Default:
# none

Squid benötigt zum Starten einen “Fully Qualified Domain Name (FQDN)” um diesen z.B. in Fehlermeldungen zu verwenden. Dieser FQDN wird in der Konfiguration des Betriebsystems angegeben. Mittels hostname -f läßt sich der aktuelle FQDN des Rechners ermitteln. Wenn ein ander anderer Rechnername von Squid verwendet werden soll (oder kein FQDN definiert wurde), kann dies durch den Eintrag visible_hostname erfolgen.

Verschiedenes

Anonymisieren der IP-Adresse:

#  TAG: forwarded_for   on|off
…
#Default:
# forwarded_for on

Standardmäßig wird in jede HTTP-Anfrage die IP-Adresse oder der Name des Clients über die “X-Forwarded-For”-Umgebungsvariable an den externen Server mitgeteilt:

X-Forwarded-For: 192.1.2.3

Wenn dies aus irgend welchen Gründen nicht gewünscht wird, muss die Option mittels forwarded_for off ausgeschaltet werden. Dies führt zu der folgenden Mitteilung an den externen Server:

X-Forwarded-For: unknown

Access Control Lists (ACL)

Die Zugriffskontrollen teilen sich in zwei unterschiedliche Bereiche auf. Zuerst werden mit dem Tag acl bestimmte Zugriffslisten definiert und danach werden mittels des Tags http_access die Listen angewendet.

Hierbei können ACLs auf Basis von Quell- und Ziel-Adressen, URLs, Zeitangaben, Protokolle, Ports und User definiert werden.

Die Default-Einstellung unterbindet jegliche Verbindung nach außen und es wird zuerst einmal dies geändert. Eine weitergehende Beschreibung erfolgt evtl. zu einem später Zeitpunkt oder sollte in der Konfigurationsdatei squid.conf nachgelesen werden.

#  TAG: acl
…
#Recommended minimum configuration:
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl SSL_ports port 443 563
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443 563     # https, snews
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

Hier sind nun diverse ACLs definiert worden. Bis auf die ersten drei ACLs können diese m.e. gleich ganz gelöscht werden (besonders die ACLs, die vermeidlich sichere Ports definieren), da sie von einer doppelt falschen Ausgangsvoraussetzung ausgehen. Das auf Port 80 ein HTTP-Server laufen soll, ist nur eine Empfehlung. Es kann dort genau so gut eine unerwünschte Anwendung laufen. Ebenso ist es möglich, dass ein HTTP-Server (zusätzlich) auf einem anderen Port läuft. Dies kommt besonders bei “Geschlossenen Benutzer Gruppen” vor. Somit handelt man sich mit einer solchen Einstellung nur eine vermeidliche Sicherheit ein (“Security by Obscurity” ist keine Sicherheit) und evtl. noch zusätzliche Probleme, weil ein Server nicht erreichbar ist.

Auch das Tunneln von Verbindungen von Clients durch den Proxy lässt sich so nicht verhindern, da die Gegenseite durchaus auf einem der “Safe_ports” lauschen kann. Die ISO/OSI-Leyer 3-5 sind nicht geeignet, dies zu unterbinden und bei darüber liegenden Leyern muss man dann jedes Paket einzeln bewerten, womit man sich die SSL-Einstellungen auch schenken kann, denn dies schließt sich gegenseitig aus.

Die Argumentation der Squid-FAQ hierzu, dass jemand den Proxy als SMTP-Relay benutzen könnte, ist insoweit nicht überzeugend, als dies bedeuten würde, dass der Proxy von außen für jede interessierte Person erreichbar ist. Wer eine solche Umgebung betreibt, der hat aber eher noch ganz andere Probleme.

#  TAG: http_access
#   Allowing or Denying access based on defined access lists
…
#Recommended minimum configuration:
#
# Only allow cachemgr access from localhost
http_access allow manager localhost
http_access deny manager
# Deny requests to unknown ports
http_access deny !Safe_ports
# Deny CONNECT to other than SSL ports
http_access deny CONNECT !SSL_ports
#
# We strongly recommend to uncomment the following to protect innocent
# web applications running on the proxy server who think that the only
# one who can access services on "localhost" is a local user
#http_access deny to_localhost
#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
# Exampe rule allowing access from your local networks. Adapt
# to list your (internal) IP networks from where browsing should
# be allowed
#acl our_networks src 192.168.1.0/24 192.168.2.0/24
#http_access allow our_networks
# And finally deny all other access to this proxy
http_access deny all

Mittels “allow” oder “deny” wird der Zugriff, basierend auf ACLs erlaubt oder unterbunden.

Wenn keine Access-Einstellung vorhanden ist, wird jeder Zugriff zurück gewiesen. Anders aber, wenn keine Access-Einstellung zutrifft, dann wird das Gegenteil der letzten Einstellung verwendet, d.h. wenn die Letzte Einstellung eine Ablehnung “deny” ist, wird der Zugriff erlaubt. Deshalb ist es sindvoll, als letzte Einstellung je nach Bedarf, ein “deny all” oder “allow all” zu verwenden. Ansonsten gilt, dass die erste passende Einstellung verwendet wird.

Die obigen ersten beiden Access-Einstellungen erlauben den Zugriff auf die ACL “manager” mittels der ACL “localhost”, die die Client-IP-Adressen auf 127.0.0.1 (Localhost) reduziert, und verbietet ihn ansonsten für alle anderen. Zuvor war in der ACL “manager” definiert worden, dass es sich hierbei um das Protokoll “cache_object” handelt. Somit wird hier festgelegt, dass dieses Protokoll nur vom lokalem Rechner aus aufgerufen werden kann.

Die beiden nächsten Access-Einstellungen können dann auch gelöscht werden, wenn die entsprechenden ACLs gelöscht wurden. Ansonsten definieren sie, dass der Zugriff auf alles, was nicht als “Safe_port” angesehen wird, unterbunden wird, ebenso wie SSL-Verbindungen auf nicht SSL-Ports.

Die letzte Access-Einstellung unterbindet jeglichen sonstigen Zugriff und sollte entweder in “http_access allow all” geändert werden, wenn man weiterhin surfen möchte oder es sollte zuvor eine ACL für die Clients definiert die dies dürfen und ein entsprechender Access-Tag gesetzt werden.

Eine ACL und ein Access-Eintrag in einem Netz (10.0.0.0/255.255.255.255), wo die erste Hälfte der Clients das Internet benutzen darf und die zweite nicht, sähe wie folgt aus:

acl our_networks src 10.0.0.0/25
http_access allow our_networks

Hierbei wird in die ACL “our_networks” der Bereich der IP-Adressen definiert, diesen dann Zugriff gewährt und allen anderen nicht. Dieses müsste nun vor der ACL http_access deny all in die Konfigurationsdatei eingefügt werden.

Ebenso ist es möglich bestimmte URLs aus zu schießen:

acl banner url_regex ^http://banner[0-9]*\.
http_access deny banner

Hier wird zuerst mittels eines Regulären Ausdruckes (Regex) eine ACL auf URLs gebildet, die mit http://banner beginnen und dann keine bis unendlich viele Zahlen im Hostnamen haben. Danach wird mittels “deny” diese ACL angewendet.

Wenn anstelle des Wertes einer ACL (als in den beiden obigen Beispielen 10.0.0.0/25 oder ^http://banner[0-9]*\.) eine in Anführungsstrichen stehender Dateiname angegeben wird, wird der Inhalt dieser Datei zeilenweise ausgewertet. Hiermit erspart man sich die Definition mehrerer ACLs für eine Aufgabe. Es ist so z.B. möglich, sich ganze Listen von Begriffen an zu legen, wo kein Zugriff auf eine URL möglich ist, wenn dieser Begriff bestandteil der URL ist.

Dies ist aber nicht ganz unproblematisch, da der Begriff, nach dem gefiltert wird, immer auch Bestandteil von URLs sein, die nicht gefiltert werden sollen. Wenn man z.B. nach dem Begriff Sex filtert, wird man auch immer den Zugriff auf Webseiten wie z.B. www.staatsexamen.de oder www.rechtsexperte.de mit verhindern. Anderseits wird man mit solchen Filterbegriffen niemals alle evtl. unerwünschten Seiten ausschließen können.

ACLs auf Basis einer User-Authentifizierung sind auch möglich, da hier unterschiedliche Methoden möglich, die auf verschiedenen zusätzlichen Modulen aufbauen, wird dies in einem separaten Kapitel behandelt.

User-Authentifizierung

Die User-Authentifizierung ist beim Squid in zwei unterschiedliche Komponenten aufgeteilt: Authentifikations-Schemas und Authentifikations-Module.

Das Authentifikations-Schema beschreibt, wie der Squid-Proxy die Anmeldeinformationen (Username und Passwort) vom User erhält. Hierbei werden die Schemas entsprechend der im Konfigurationsfile vorgegebenen Reihenfolge angewendet. Der Hauptunterschied bei den drei vorhandenen Schemata ist ein Sicherheitsaspekt. Beim Basis-Schema wird auch das Passwort im Klartext im Netz übertragen.

Das Authentifikations-Modul übernimmt dann die eigentliche Überprüfung der übermittelten Anmeldeinformationen, wobei es aus externen Komponenten besteht. Die auf das Basis- oder NTLM-Schema aufsetzenden Module lesen in einer Endlosschleife von “STDIN”, erwachten “username password” (entweder bei Basis unverschlüsselt oder bei NTLM verschlüsselt) und geben entsprechend dem Ergebnis der Authentifizierungsprüfung “OK” oder “ERR” auf “STDOUT” zurück. Auf diese Basis lässt sich auch eine eigene Lösung aufsetzen.

Der Squid Proxy bietet somit diverse Authentifizierungsmöglichkeiten an, mit denen es sowohl möglich ist, für den Squid eine eigenständige Passwort-Datei zu nutzen, die “Pluggable Authentication Modules (PAM)” zu verwenden, gegen eine Windows NT Domäne, ein Windows “Active Directory Service (ADS)” oder einen “LDAP”-Server zu authentifizieren oder selber ein Programm/Skript hierfür zu schreiben.

Authentifizierung mittels Passwortdatei

Bei einem selbst kompilierten “Squid” muss zuerst das entsprechende Modul erzeugt werden. Hierfür muss in dem Verzeichnis, in dem der Source-Code des Squids liegt in das entsprechende Verzeichnis gewechselt werden.

$ cd helpers/basic_auth/NCSA/
$ make
# make install

Nun liegt das entsprechende Modul “ncsa_auth” in dem Verzeichnis /usr/local/squid/bin und kann in der “squid.conf” eingebunden werden. Bei einem GNU/Debian-Paket liegen alle Module im Verzeichnis /usr/lib/squid.

#  TAG: auth_param
…
#Default:
# none
auth_param basic program /usr/local/squid/bin/ncsa_auth /usr/local/squid/etc/passwd
# auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/passwd # bei GNU/Debian
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours

Die Angabe children 5 bezieht sich auf die Anzahl an Prozessen die für die User-Authentifizierung gleichzeitig gestartet wird. Der bei realm stehende Text wird bei der Passwort-Abfrage den Usern angezeigt. Bei credentialsttl wird die Dauer der Gültigkeit einer User-Authentifizierung angegeben. Alle diese Werten können so übernommen werden.

Mittels einer entsprechenden ACL wird nun der Zugriff geregelt:

#  TAG: acl
…
acl manager proto cache_object
acl users proxy_auth "/etc/squid/admins"
acl users proxy_auth REQUIRED
#  TAG: http_access
…
http_access allow manager admins
http_access deny manager
http_access allow users

Mittels dieser ACL wird fest gelegt, welche Benutzer Zugriff erhalten sollen. Hierbei können auch mehrere, durch Leerzeichen getrennte, Benutzernamen oder eine, in Anführungszeichen eingeschlossene, Datei angegeben werden. Da aber schon das Authentifizierung-Modul gegen eine Datei prüft, würde dies bei diesem Modul eine Doppelpflege bedeutet. Dies lässt sich mittels der Verwendung von “REQUIRED”, anstelle der Usernamen, vermeiden. Damit wird jede gültige Anmeldung akzeptiert.

Man kann aber zusätzlich eine Benutzerliste dazu verwenden, den Zugriff auf geschlossene Bereiche, wie dem Squid-Management, nur bestimmten Usern zu ermöglichen.

Nun muss nur noch die entsprechende Passwort-Datei angelegt werden. Diese Datei ist im sog. NCSA-Format, wie es auch vom Web-Server “Apache” verwendet wird. Deshalb kann auch dessen Programm htpasswd hierzu verwendet werden, es erfüllt die gleiche Aufgabe. Ansonsten gibt es noch unter htpasswd ein Source-File.

Ansonsten ist noch darauf zu achten, dass die Passwort-Datei von Squid gelesen werden kann, aber von keinem anderen user.

chown squid.squid passwd
chmod 600 passwd

Squid 2.4:

#  TAG: authenticate_program
…
#       authenticate_program /usr/local/squid/bin/ncsa_auth /usr/local/squid/etc/passwd
#
#Default:
# none

Diese Option ist mit der Squid Version 2.5. durch die Option auth_param ersetzt worden und ist dort mit dem “Basis-Schema” zu vergleichen. Dieses Beispiel bewirkt die gleiche Authentifizierung gegen eine Passwort-Datei wie das vorherige Beispiel.

Authentifizierung mittels Pluggable Authentication Modules (PAM)

Bei PAM handelt es sich um ein System von Software-Bibliotheken die die Authentifizierungs-Anfragen einzelner Programme gegenüber dem System verarbeiten.

Das Squid-Modul, das die Verbindung zu diesen Bibliotheken herstellt, wird wie folgt kompiliert:

$ cd helpers/basic_auth/PAM/
$ make
# make install

Bestimmte PAM Module (z.B. “shadow password authentication”) benötigen dieses Programm installiert als Root mit gesetztem setuid-Bit um Zugriff auf die Passwort-Datei zu erhalten:

# chown root /usr/local/squid/libexec/pam_auth
# chmod u+s /usr/local/squid/libexec/pam_auth

Nun muss dieses Modul noch in die Squid Konfiguration eingebunden werden:

#  TAG: auth_param
…
#Default:
# none
auth_param basic program /usr/local/squid/libexec/pam_auth
# auth_param basic program /usr/lib/squid/pam_auth # bei GNU/Debian
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
#  TAG: acl
…
acl users proxy_auth "/etc/squid/allow_users"
#  TAG: http_access
…
http_access allow users

Im Idealfall war es dies schon und die Zugriffskontrolle funktioniert über die zentrale Passwort-Datei des Systems. Da nun alle authentifizierten User über den Squid Zugriff auf das Web haben, kann es in diesem Fall sinnvoll sein, einen eigenständige Berechtigungsdatei zu führen und mittels einer ACL einzubinden.

Falls die PAM-Voreinstellungen nicht greifen, muss für den Squid Proxy noch ein entsprechende Eintrag in der PAM-Konfiguration erstellt werden. Konfiguriert wird PAM mittels einer Datei /etc/pam.conf oder eines Verzeichnis /etc/pam.d. Wenn dieses Verzeichnis vorhanden ist, wird die Datei ignoriert.

Entsprechend der lokalen Gegebenheit (Datei oder Verzeichnis) müssen für den Squid noch mindestens zwei Einträge erstellt werden.

In der Datei /etc/pam.conf:

squid auth    required pam_unix.so
squid account required pam_unix.so

Oder in der neu anzulegenden Datei /etc/pam.d/squid:

auth    required pam_unix.so
account required pam_unix.so

Ebenso müssen eigene Einträge erstellt werden, wenn ein anderes PAM-Modul verwendet werden soll, um zum Beispiel eine Authentifizierung mittels PAM gegen einen LDAP-Server zu betreiben.

Mehr Infos zu PAM bietet man 8 pam.

Authentifizierung mittels Lightweight Directory Access Protokoll (LDAP)

Für eine Authentifizierung mittels “LDAP” gibt es unterschiedliche Ansätze.

Der einfachste Ansatz ist hierbei auf die Authentifizierung per PAM zurück zu greifen und dieses Verfahren um LDAP-Support zu erweitern.

Hierfür müssen in der Datei /etc/pam.d/squid die folgenden Einträge stehen:

auth    sufficient pam_ldap.so
auth    required   pam_unix.so try_first_pass
account sufficient pam_ldap.so
account required   pam_unix.so

Hier wird nun zuerst gegen einen LDAP-Server geprüft und wenn dies erfolglos war, ohne erneute Passwort-Eingabe, gegen die zentrale Passwort-Datei.

Eine andere Möglichkeit besteht in der Verwendung des Moduls “squid_ldap_auth” (bei GNU/Debian hat man es in “ldap_auth” umbenannt). Der Aufruf des Moduls erfolgt über squid_ldap_auth -b basedn [options] [ldap_server_name[:port]]…. Welche Optionen im Detail zur Verfügung stehen lässt sich durch einen einfachen Aufruf des Moduls auf einer Konsole feststellen.

Die Option -b basedn ist auf jeden Fall zwingend und Erfahrungsgemäß ist auch die Übergabe der Protokollversion mittels -v 2|3 oft sinnvoll, da das Module nicht immer die richtige Version erkennt und somit unnötig Fehler produziert werde. Es sollte auf jeden Fall auf einer Konsole eine Abfrage getestet werden, bevor das Module in der “squid.conf” aktiviert wird:

echo "
" | /usr/local/squid/libexec/squid_ldap_auth -v 3 -b dc=example,dc=org -f "uid=%s" localhost, wobei “dc=example,dc=org” nur ein Beispiel für einen Base DN ist.

Wenn als Ausgabe ein “OK” erscheint, hat alles funktioniert und der Integration der LDAP-Authentifizierung in Squid steht nichts mehr im Wege. Bei einem Fehler sollte auf jeden Fall in den Logfiles des LDAP-Servers nachgesehen werden (bzw. das Log-Level dort erhöht werden und die Abfrage wiederholt).

Die Einbindung in die Squid-Konfiguration erfolgt dann wie gewohnt:

#  TAG: auth_param
…
#Default:
# none
auth_param basic program /usr/local/squid/libexec/squid_ldap_auth -v 3 -b dc=example,dc=org -f "uid=%s" localhost
# auth_param basic program /usr/lib/squid/ldap_auth -v 3 -b dc=example,dc=org -f "uid=%s" localhost # bei GNU/Debian
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours

Für eine dettailierter Zugriffsnegelung muss auch hier wieder eine ACL definiert werden. Neben der schon bekannten Form der externen Liste bietet sich gerade hier eine LDAP-Abfrage an. Hierfür steht das zum Squid gehörende Programm “squid_ldap_group” zur Verfügung.

Wenn “squid_ldap_group” nicht über die verwendete Linux-Distribution installiert wurde, muss es als erstes kompiliert werden. Wichtig ist hierbei, dass beim Kompilieren die Header-Dateien von OpenLDAP installiert sind.

$ cd helpers/external_acl/ldap_group/
$ make
# make install

Dann sollte ein Test dieses Programms und des Filters auf einer Konsole erfolgen:

echo " " | /usr/lib/squid/squid_ldap_group -b dc=example,dc=org -v 3 -f "(&(objectClass=posixGroup)(cn=%a)(memberUid=%v))" localhost

Hier wird mittels eines LDAP-Filter getestet, ob es einen LDAP-Eintrag gibt, der als Inhalt die Klasse “posixGroup” hat – also eine Benutzergruppe ist – und den Übergebenen Gruppennamen z.B. “squid_user” hat und den Eintrag “memberUid” mit dem übergebenen User-Name. Oder anders gesagt, ist der übergebene Benutzer Mitglied der Benutzergruppe “squid_user”.

Bei einem “OK” als Rückgabewert sollte man aber auch einmal mit falschen Werten testen um zu sehen, ob der Filter dann einer “ERR” zurück gibt oder nicht einfach alles bestätigt.

Die Einbindung des Filters erfolgt nun an mehreren Stellen.

#  TAG: external_acl_type
#         external_acl_type name [options] FORMAT.. /path/to/helper [helper arguments..]
…
external_acl_type ldap_filter %LOGIN /usr/local/squid/libexec/squid_ldap_group -b ou=group,dc=example,dc=org -v 3 \
	-f "(&(objectClass=posixGroup)(cn=%a)(memberUid=%v))" localhost
…
#  TAG: acl
#       acl acl_name external class_name [arguments...]
…
acl users external ldap_filter squid_user

Zuerst wird die externe ACL-Klasse “ldap_filter” definiert. Das übergebene Format “%LOGIN” beinhaltet den schon durch die Authentifizierung festgestellten Usernamen. Aufgerufen wird diese externe ACL-Klasse dann mit dem zweiten Eintrag, dem als Parameter “squid_user” übergeben wird. Durch diese Übergabe des abzufragenden Gruppennamens ist es möglich, mehrere Gruppen abzufragen und somit strukturiertere Zugriffsberechtigungen zu setzen. Nun muss nur noch der Zugriff für diese ACL definiert werden:

#  TAG: http_access
…
http_access allow users

Authentifizierung gegen eine Windows NT Domäne

Für die Authentifizierung gegen die Konten einer Windows NT Domäne gibt es z.Zt. zwei unterschiedliche Module (“SMB” und “MSNT”). Nachfolgend wird sich nur auf das Modul “SMB” bezogen.

Dieses Module prüft die Zugangsberechtigung wahlweise gegen einen SaMBa-Server als auch gegen eine NT-Domäne. Es setzt hierbei aber eine SaMBa-Installation zwingend voraus, ermöglicht aber eine Konfiguration über Rechtevergabe auf der NT-Domäne.

Auch hier muss das entsprechende Modul zuerst kompiliert werden:

$ cd helpers/basic_auth/SMB/
$ make
# make install

Die weitere Konfiguration erfolgt über den NT-Domän-Kontroller (bzw. dem entsprechenden SaMBa-Server), indem die Datei \netlogon\proxyauth ausgewertet wird. Die Datei hat als einzigen Inhalt das Wort “allow”. Nun muss noch auf Seiten der NT-Rechteverwaltung einem User oder einer Lokalen bzw. Globalen Gruppe (z.B. “Internet-Nutzer”) Leserecht für diese Datei gewährt. Danach können sich die User mit ihrem NT-Passwort am Squid-Proxy anmelden.

In der Squid Konfiguration wird dieses Modul wie folgt eingebunden:

#  TAG: auth_param
…
auth_param basic program /usr/local/bin/smb_auth -W
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
#  TAG: acl
…
acl domainusers proxy_auth REQUIRED
#  TAG: http_access
…
http_access allow domainusers

Dem Module smb_auth wird mittels der Option der Domänname der NT-Domäne (bitte nicht mit der DNS-Domain verwechseln) übergeben. Dies ist zwar nicht absolut notwendig, da das Modul ansonsten per Broadcast-Umfrage diesen finden würde, aber es beschleunigt die Anmeldung doch ungemein.

Ansonsten wird mittels “REQUIRED” allen gültig Angemeldeten, sprich die, die die entsprechenden Rechte auf NT-Seite erhalten haben, Zugriff auf den Proxy gewährt.

“Squid” als Transparenter HTTP-Proxy

Ein beliebtest Einsatzgebiet des Squids ist der Einsatz als Transparenter Proxy. Der Vorteil hierbei ist, dass auf den Clients kein Proxy im Browser eingetragen werden muss (wobei hierfür in Netzwerken durchaus zentrale Möglichkeiten bestehen, die Konfiguration der Clients zu verändern). Der evtl. Nachteil ist aber, dass auf einem transparenten Proxy keine User-Authentifizierung möglich ist und dass das Ganze nur bei HTTP (und nicht bei HTTPS oder FTP) funktioniert.

Umgesetzt wird dies durch eine Umleitung aller TCP-Pakete am Router, die von den Clients zu einem externen Port 80 gesendet werden. Diese Pakete werden nun direkt an den Squid-Proxy umgeleitet. Da die Clients nun aber nichts über einen Proxy in ihrer Verbindung zu externen Servern wissen, können sie auch keine speziellen Anfragen an diesen Proxy stellen. Hierdurch versagen nun die HTTPS- und FTP-Requests, da erstere, auf Sicherheit beruhend, nun den Proxy als “man-in-the-middle attack” ansehen und letztere neben der Download-Verbindung eine weitere Verbindung für das Senden von Daten benötigen (beim normalen Proxy wird zwischen Client und Proxy eine HTTP-Verbindung aufgebaut und erst vom Proxy zum FTP-Server eine FTP-Verbindung).

Damit der Squid als transparenter Proxy arbeitet müssen die folgenden Einstellungen geändert werden:

#  TAG: httpd_accel_host
#  TAG: httpd_accel_port
…
#Default:
# httpd_accel_port 80
httpd_accel_host virtual
httpd_accel_port 80
#  TAG: httpd_accel_with_proxy  on|off
…
httpd_accel_with_proxy on
#  TAG: httpd_accel_uses_host_header    on|off
…
httpd_accel_uses_host_header on

Weiterhin ist es notwendig mittels “iptables”-Regeln alle TCP-Pakete an den Proxy umzuleiten:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128

Diese Regel sollte dann in einem Skript stehen, dass automatisch nach dem Booten ausgeführt wird.

“Squid” starten

Nun kann der Squid Proxy mittels /usr/local/squid/bin/squid gestartet werden. Wenn dies nicht zu dem gewünschten Erfolg führt und der Squid auch keine Fehlermeldung ausgibt, sollte man folgendes prüfen:

• Sind die für den Start des Proxies angegebene User und Gruppe vorhanden?
• Ist ein “Fully Qualified Domain Name” für den Proxy-Server definiert?
• Hat der Squid Schreibrechte auf sein PID-File, seinen Cache und seine Logfiles?
• Das Logfile-Debuging hoch setzen um evtl. mehr Fehlermeldungen zu erhalten.

Wenn der Squid läuft, sollte man für ihn ein Runlevel-Skript anlegen und die entsprechenden Links in den Runlevel-Verzeichnissen anlegen. Eine Vorlage für dieses Skript ist bei den meisten Distributionen unter /etc/rc.d/init.d/skeleton zu finden.

©2012 Dirks Blog. All Rights Reserved.