Auch Entwickler brauchen Platz zum Spielen

24. Juli 2014 /

Snitch: Netzwerkmonitor für WordPress

Das Snitch-Plugin überwacht den ausgehenden Datenverkehr in WordPress-Blogs und blockiert ausgewählte Verbindungen nach definierten Regeln.
Snitch

Nach der Installation von WordPress und Drittanwendungen fehlt Blog-Administratoren die Möglichkeit einzusehen, ob und wohin Themes und Plugins im Hintergrund kommunizieren. Aus Datenschutz- (Stichwort Tracking) und Sicherheitsgründen (Stichwort Malware) würde ein Logbuch über ausgehende Blog-Verbindngen Sinn machen. Snitch als Datenwächter für WordPress eilt zu Hilfe.

Sprungmarken


Funktionsweise

Snitch ist Netzwerkmonitor für ausgehende Verbindungen in WordPress. Der Verbindungsaufbau dieser Art findet meist im Hintergrund statt und wird vom Blogger nicht wahrgenommen. Die periodische Prüfung auf existente WordPress- und Plugin-Updates dient hier als Beispiel. Jeder Verbindungsversuch wird von Snitch erfasst und protokolliert – automatisch. Unerwünschte Verbindungen können abhängig von der Domain bzw. Datei abgefangen und unterbunden werden. Analog einer Firewall.

Nach diesem Prinzip gewährt Snitch dem Administrator einen prompten Einblick in die ausgehende Kommunikation und erlaubt eine gezielte Sperre einzelner Anfragen. Und das Blog-weit. Mit Snitch ausgerüstet kann jeder Blogger unkompliziert und jederzeit erkennen, wohin und wie oft installierte WordPress-Plugins und Themes „telefonieren“.

Snitch WordPress-Plugin
Snitch: WordPress-Plugin für Netzwerküberwachung


Features

Warum ausgerechnet Snitch? Einige Gründe sprechen dafür:

  • Kostenlos und werbefrei
  • Kompakt und übersichtlich
  • Erkennung der Ziel-URL und Dateizeile
  • Sperre und Freigabe einzelner Verbindungen
  • Gruppierung und Sortierung der Werte
  • Optionale Abschaltung der Überwachung interner Verbindungen

Dokumentation

Mithilfe der WordPress-Konstante WP_HTTP_BLOCK_EXTERNAL unterbindet das Blog-System gänzlich die externe Kommunikation. Auf Wunsch pflegt der Blog-Administrator in WP_ACCESSIBLE_HOSTS eine Whitelist an zugelassenen Domains. Was definitiv fehlt, ist die bequeme Möglichkeit den Zugang zu bestimmten Hosts (= Domains) zu unterbrechen. Genau für diesen Zweck wurde Snitch erfunden.

Snitch Verbindungsübersicht
Snitch Verbindungsübersicht zugänglich über die Sidebar

Jede WordPress-Verbindung nach „Außen“ sammelt Snitch im tabellarischen Protokoll, welches für Administratoren über die Admin-Sidebar zugänglich ist. Eigenschaften protokollierter Verbindungen teilt das Plugin in sortierbare Spalten auf. Vorhandene Spalten im Detail:

Ziel-URL
Adresse, die WordPress oder eine der Ressourcen versucht zu kontaktieren.

Herkunftsdatei
Skript-Datei, die den eigentlichen Verbindungsaufbau initiiert hat. Nach dem Doppelpunkt platziert Snitch die betroffene Zeilennummer, um mit der Recherche der Fundstelle starten zu können. Bonus: Snitch versucht die Datei einem Theme oder Plugin zuzuordnen.

Zustand
Aktueller Zustand der Verbindung. Entweder wurde diese autorisiert oder blockiert. In der Auswahlbox oberhalb der Liste lassen sich Einträge nach Zustand gruppieren.

Code
Der Status-Code, der bei autorisierten Verbindungen empfangen wurde.

Zeit
Zeitpunkt der Protokollierung.

POST-Daten
Wurde eine ausgehende Verbindung mit POST-Variablen versehen, speichert Snitch diese Werte zwischen und stellt sie per Klick auf die Schaltfläche dar.

Snitch Verbindungseigenschaften
Verbindungseigenschaften in Snitch


Blockieren der Verbindungen
Spalten Ziel-URL und Herkunftsdatei verfügen jeweils über einen Link zum Blockieren der zukünftigen Verbindungen nach Muster:

  • Zugriffe auf diese Domain blockieren
    Blockiert alle Verbindungen zu ausgewählter Domain
  • Zugriffe aus dieser Datei blockieren
    Blockiert alle Verbindungen aus der Datei

Nach dem Klick auf einen der Links befördert Snitch die Domain bzw. Datei in die interne Blacklist und wendet die aktualisierte Regel bei der nächsten Kommunikation an. Übrigens markiert Snitch alle Verbindungen innerhalb der Liste in Orange, wenn sie den Regeln der Blacklist entsprechen. Blockierte Verbindungen bekommen einen leicht roten Hintergrund zugewiesen.

Freigabe der Verbindungen
Bereits abgewiesene oder erst zum Blockieren markierte Verbindungen in Orange-gefärbten Spalten lassen ihre Aktion invertieren, sprich die Regel aus der Blacklist entfernen. Die Ausführung dieser Aktion findet ebenfalls über einblendbare Links statt. Nach dem Klick wechselt sich die Spaltenmarkierung auf Grün und bedeutet: Verbindungsmuster vom Regelwerk nicht länger erfasst.

Unterdrückung interner Verbindungen
Snitch 1.0.9 beherrscht die Möglichkeit, WordPress-interne Verbindungen wie es beispielsweise Cronjobs sind, zu ignorieren. Für diesen Zweck wurde die PHP-Konstante SNITCH_IGNORE_INTERNAL_REQUESTS eingeführt.

Ist in der Konfigurationsdatei wp-config.php folgende Definition notiert, listet Snitch keine Cronjobs und interne Connections mehr auf:

define('SNITCH_IGNORE_INTERNAL_REQUESTS', true);

Löschen der Verbindungen
Snitch-Einträge können per Schaltfläche Protokoll leeren gefahrlos gelöscht werden. Dieser Vorgang hat keinerlei Beeinträchtigungen auf die Funktionsweise des Plugins. Angelegte Snitch-Regel zu blockierten Inhalten (Domains bzw. Dateien) bleiben weiterhin bestehen und sind aktiv.

Seit Version 1.0.5 bewahrt das Plugin maximal 200 Snitch-Einträge auf. Ältere Aufzeichnungen werden täglich bereinigt. Mithilfe des Filters snitch_cleanup_items kann die Länge des Protokolls benutzerdefiniert angepasst werden.

Zusammenfassung
Leichtgewichtiges Plugin für die Überwachung der Verbindungen im Blog. Das manuelle Blockieren ausgewählter Kommunikationsversuche sorgt für mehr Privatsphäre und Sicherheit.



Hilfeleistung via PayPal, Flattr, Amazon ist jederzeit willkommen. Danke.


Download

› Snitch – Netzwerkmonitor für WordPress ↓


Häufige Fragen

Hat das obige Online-Handbuch nicht alle Fragen beantwortet? Vielleicht helfen nachfolgende Antworten auf die oft gestellten Fragen.

Snitch erzeugt sehr viele Einträge in der Datenbank
Snitch wurde konzipiert, um jede ausgehende Verbindung in WordPress zu protokollieren. Läuft die Datenbank schnell voll, da sollte man sich als Blog-Betreiber fragen: Warum eigentlich? Warum kommuniziert mein WordPress samt Plugins so oft nach Außen? Geht denn wirklich alles mit rechten Dingen zu und muss diese Kommunikation wirklich sein?

Zur Erinnerung: Snitch soll helfen, die WordPress-Performance zu erhöhen, indem Verbindungen als Flaschenhälse erkannt und aufgezeigt werden. Die Aufgabe des Blog-Administrators ist es, die Quelle der Ursache (Plugin, Theme, Code-Snippets in functions.php) zu eliminieren.

Snitch sorgt automatisch dafür, dass in der Datenbank nicht mehr als 200 Einträge aufbewahrt werden.

Warum listet Snitch WordPress-Cronjobs auf?
WordPress ruft eigene Cronjob-Aufträge via WordPress HTTP API auf – genau diese Schnittstelle überwacht Snitch. Da solche Aufrufe intern abgewickelt werden und den Blog nicht verlassen, erhalten sie in Snitch keinen Status-Code zugewiesen (die entsprechende Snitch-Spalte ist nicht belegt).

Werden Cronjobs zu oft gelistet, stimmt möglicherweise etwas nicht. Es empfiehlt sich, die Liste an geplanten Aufträgen zu überprüfen, siehe WordPress-Cronjobs begutachten und bereinigen.

Seit Version 1.0.9 berücksichtigt Snitch die PHP-Konstante SNITCH_IGNORE_INTERNAL_REQUESTS (Details siehe oben) – diese kann dazu genutzt werden, um WordPress-Cronjobs in der Snitch Verbindungstabelle nicht aufzulisten.

Überwacht Snitch auch Verbindungen im Frontend?
Snitch schreibt jede Verbindung mit, die einen Blog über das WordPress HTTP API (interne WordPress-Schnittstelle für Datenkommunikation) verlässt. Das betrifft sowohl das Backend wie auch Frontend einer WordPress-Installation.

Warum wird die Tabelle mit Snitch-Einträgen kaputt dargestellt?
Das liegt an der Tatsache, dass andere WordPress-Erweiterungen ihre Stylesheets fälschlicherweise auf jeder Admin-Seite einbinden. Diese Einbindung auf “fremden” Seiten ruiniert die Darstellung benachbarter Plugins. In solchen Fällen lohnt sich die Suche nach dem zum Konflikt führenden Plugin durch Deaktivierung. Das WordPress-Plugin WP SlimStats wäre ein Kandidat.

Auto-Nachrichten an Twitter und Facebook spielen verrückt?
Dass mit jedem Snitch Eintrag auch eine automatische Nachricht an Facebook und/oder Twitter rausgeht, liegt eindeutig nicht an Snitch. Vielmehr liegt es am eingesetzten Auto-Tweet-Facebook-Plugin, welches fehlerhaft programmiert ist und bei jedem – auch nicht öffentlichen – CPT einen Event auslöst. Und das ist falsch. Der Einsatz solcher Plugins sollte überdacht werden.

Google indexiert Snitch-Einträge und liefert 404-Statuscodes
Wie eben angesprochen, legt Snitch seine Einträge standarisiert als WordPress Custom Post Types an. Wichtiger Schritt: Durch ein WordPress-Attribut markiert Snitch alle Protokolleinträge als Privat, also nicht öffentlich. Soweit würde die Ideologie mit privaten Einträgen auch klappen, wenn da nicht WordPress-Plugins wären, die alle – also auch interne bzw. private – Custom Post Types in die Welt kommunizieren würden – mit für den Blogger fatalen Folgen.

Und so passiert es schnell, dass Google plötzlich auf Snitch-Seiten stößt, die für den öffentlichen Zugang gar nicht vorgesehen sind. Zum Beispiel weil Snitch-Seiten in der Sitemap XML des Blogs auftauchen, da ein Sitemap XML Plugin der Meinung ist, auch private Seiten dahin stecken und für die Indexierung freigeben zu müssen. Da hilft auch keine Sperrung in robots.txt, da die Datei robots.txt die Indexierung der Seiten nicht verhindert.


Mindestanforderungen

  • WordPress 3.8

Hinweise

  • Snitch überwacht den Datenverkehr, der ausschliesslich über das integrierte WordPress HTTP API abgewickelt wird.
  • Durch die Blockierung einzelner Domains oder Dateien kann die Funktionsweise der betroffenen Anwendungen beeinträchtigt werden.
  • Nur Blog-Administratoren haben die Berechtigung, Snitch-Verbindungen als Liste angezeigt zu bekommen.

Geplant

  • Blockierung kompletter URLs
  • Konstanten mit definierten Werten (mit Wildcard-Support)
  • Ausgabe der POST-Variablen
  • Cronjobs überspringen

Versionsverlauf

Version 1.0.12 vom 24.07.2014

  • Berücksichtigung von Nutzerrollen bei Plugin-Aktionen
  • Anpassungen textlicher Natur

Version 1.0.11 vom 04.04.2014

  • Support zu WordPress 3.9
  • Aufräumarbeiten im Sourcecode

Version 1.0.10 vom 26.02.2014

  • Änderung des Rückgabewertes in der Funktion inspect_request

Version 1.0.9 vom 12.12.2013

  • Optionale Nicht-Protokollierung interner Verbindungen via PHP-Konstante
  • Optimierung für WordPress 3.8

Version 1.0.8 vom 29.07.2013

  • Schaltfläche für die Ausgabe der POST-Variablen
  • Kompatibilität zu WordPress 3.6

Version 1.0.7 vom 09.06.2013

  • Eliminierung des Links “Neu” in der Admin-Toolbar
  • Unterbindung direkter Aufrufe von Plugin-Dateien

Version 1.0.6 vom 23.03.2013

  • Funktion delete_items umbenannt und auf public gestellt

Version 1.0.5 vom 21.03.2013

  • Aufbewahrung von maximal 200 Snitch-Einträgen. Ältere werden gelöscht.

Version 1.0.4 vom 21.02.2013

  • Suche in Werten der Spalte Ziel-URL (Eingabefeld oben rechts)

Version 1.0.3 vom 18.02.2013

  • Button Protokoll leeren fürs Entfernen aller Einträge
  • Kein Verschieben der Einträge in den Papierkorb (Nutzerwunsch)

Version 1.0.2 vom 12.02.2013

  • Änderung der Custom Fields Namen für Vermeidung eventueller Konflikte

Version 1.0.1 vom 12.02.2013

  • Korrektur für möglichen Fehler Call to undefined function get_current_screen

Version 1.0.0 vom 12.02.2013

  • Snitch geht online
Sergej Müller

[Der Autor]Sergej Müller ist enthusiastischer Software Engineer mit Schwerpunkten Webentwicklung, Apps und WordPress. Seit 2007 programmiert und vertreibt er wpSEO, das zugkräftige SEO-Plugin für WordPress-Blogs.

Thematisch ähnliche Beiträge