Parasitenabwehr von Bots – WordPress absichern Teil7

1. Bye bye Bot!Parasitenabwehr Bots

Bereits im vorhergehenden Beitrag der Artikelserie WordPress absichern bin ich auf die Bot-Thematik eingegangen und habe Techniken vorgestellt, die das Spam-Aufkommen verringern können. Doch die Maßnahmen reduzieren nicht nur den Kommentar-Spam, sondern wirken sich zugleich positiv auf die meist knappen Ressourcen des Webservers aus. Erreicht wird dies durch einfache Prüfmechanismen, die bereits auf Serverebene unerwünschte Gäste abweisen.

Neben den eher harmlosen Spam-Bots existieren noch weitere Varianten, die mit ihrem »parasitären Verhalten«, die Performance und Erreichbarkeit einer Webpräsenz negativ beeinflussen. Wie oft diese »Parasiten« eine Webseite besuchen, ist von unterschiedlichen, meist nicht öffentlich einsehbaren Faktoren abhängig. So kann der Bekanntheitsgrad eine Rolle Spiele oder welche Inhalte auf der Webseite zugänglich gemacht werden.

Die inhaltliche Vielfalt von Webseiten lockt somit nicht ausschließlich reale Personen an, sondern eine zunehmende Anzahl von Crawlern und Spidern. Diese generieren für den Webseitenbetreiber keinen erkennbaren Mehrwert, sondern »verschwenden« die kostbaren Ressourcen eines Webservers. Erst eine penible und individuelle Analyse der Server-Logs kann auch diese »unnützen« Bots identifizieren.


Dieser Beitrag ist Teil einer Artikelserie:

Update

März 2016: Die Artikelserie wurde das letzte Mal im März 2016 aktualisiert.

2. Bot-Varianten

Ein Bot ist ein Programm, das weitgehend automatisch wiederholende Aufgaben abarbeitet. Welche Aufgaben ein Bot verrichtet ist von der jeweiligen Programmierung abhängig. In der freien Wildbahn existieren somit ganz unterschiedliche Bots, die im Auftrag ihrer Entwickler mal mehr, mal weniger »wichtige« Aufgaben verfolgen. Dabei ist das Verhältnis von Webseiten-Betreibern zu den Bots ambivalent. Einerseits wird die Webseite nur so in einer Suchmaschine wie Google gelistet, andererseits nimmt die Masse an schlecht programmierten und rücksichtslosen Bots stetig zu.

Offiziell ist mir keine Einteilung in unterschiedliche Bot-Varianten (Crawler, Spider) bzw. Unterkategorien bekannt. Die folgende Übersicht ist daher vollkommen willkürlich und erhebt keinen Anspruch auf Vollständigkeit:

  • Webcrawler: Der Anspruch von Suchmaschinen wie Google oder Bing ist es, einem Suchenden die bestmöglichen Ergebnisse in Bezug auf seine Suchanfrage darzustellen. Auf Basis eines unbekannten Algorithmus besucht der Googlebot (User-Agent: Googlebot/2.1) eine Webseite, um neue Inhalt zu indexieren.
  • SEO: Für eigene Analysezwecke oder auch für die neugierige Konkurrenz kann eine Auswertung von Keywords, Backlinks oder des Schreibstils, im Rahmen einer Suchmaschinenoptimierung (SEO), durchaus zweckmäßig sein. Kostenlose, sowie bezahlte Dienste werden zur Genüge angeboten. Ab und zu wird die Webseite dann von einem BLEXBot/1.0, DotBot/1.1, linkdexbot/2.0 oder SISTRIX Crawler »heimgesucht«. Je nach Programmierung verhalten sich diese SEO-Bots oftmals aggressiv und rücksichtslos. Bemerkbar macht sich dies durch eine erhöhte Last auf den Webserver, da diese Bots häufig eine hohe Anzahl synchroner HTTP-Requests generieren. Unter Umständen sind Projekte bzw. Webseiten mit knappen Ressourcen, während den »Bot-Besuchszeiten«, schlecht für reale Personen erreichbar.
  • Backlinks: Einige Bots bzw. Dienste habe sich speziell auf die Auswertung von Backlinks fokussiert. Ihre Aufgabe besteht meist in der Indexierung und Verfolgung aller Links, mit dem Ziel, alle Backlinks einer Webseite zu erfassen und in einer detaillierten »Karte« aufzubereiten. Aus den gesammelten Informationen werden Statistiken und Diagramme generiert, die wiederum Rückschlüsse auf die Popularität einer Webseite zulassen. Bekannte Vertreter sind der AhrefsBot/5.0, BacklinkCrawler oder spbot/4.0.7.
  • Harvester: Diese Kategorie von Bots sucht gezielt nach Informationen. Oft erbeuten sie E-Mail Adressen aus dem gesetzlich vorgeschriebenen Impressum oder der Kontaktseite, um sie anschließend direkt in die Liste von Spammern zu überführen. Andere Vertreter dieser Kategorie suchen nach Marken- und Preisinformationen (magpie-crawler) oder verarbeiten Jobangebote, wie der CareerBot/1.1 oder iCjobs. Zu den Harvestern zählen also auch Dienstleistungen aus dem Marketing-Umfeld.
  • [ … ]

Du kannst den Blog aktiv unterstützen!

Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.

Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.

Mitmachen ➡

2.1 Fragwürdige Geschäftskonzepte

Die Grenzen zwischen »guten« und »bösen« Bots verschwimmen zunehmend in einer überdimensionalen Grauzone von Diensten, die dem Webseitenbetreiber selbst schaden und zugleich keinen Mehrwert bieten. Ganze Branchen sind heute auf die Zuarbeit ihrer »Bot-Kollegen« angewiesen, um ihre fragwürdigen SEO- oder Marketing-Konzepte als kommerzielle Dienstleistung anbieten zu können. Dem gegenüber stehen die »guten« Webcrawler, die dem legitimen Anwender als Recherchehilfe dienen und Inhalte über Suchmaschinen überhaupt erst auffindbar machen.

Komplettiert wird die »Parasiten-Gallerie« durch Bots, die E-Mail Adressen für Werbezwecke sammeln, massenhaft Webinhalte kopieren oder systematisch nach Sicherheitslücken suchen, um den Server später zu kompromittieren. Genug Gründe also, um dem chaotischen Treiben Einhalt zu gebieten.

3. Bot Erkennung

Viele Tools ermöglichen die Auswertung von Webserver-Logs. Zu den bekanntesten zählen The Webalizer und AWStats. Bei den meisten Webhosting-Angeboten ist eines der Tools bereits vorinstalliert. Allerdings dienen sie eher der Besucheranalyse, als der detaillierten Auswertung von relevanten Informationen. Grafisch ansprechender sind die Lösungen wie Matomo oder Google Analytics  – wobei Google aufgrund seiner Datensammelwut zu meiden ist.

Eines haben all diese Tools gemeinsam: Sie kratzen lediglich an der Oberfläche von Logfiles. Wer den »Parasiten« auf die Spur kommen möchte, benötigt Shell-Zugang auf den Server und muss sich mit Tools wie grepawk und sed anfreunden.

3.1 Combined Log Format

Webserver wie Apache oder nginx protokollieren Zugriffe auf Webseiten im Combined Log Format. Ein Auszug mit zwei Einträgen sieht folgendermaßen aus:

183.121.143.32 - - [29/Apr/2014:08:04:22 +0200] 
"GET /images/logo.jpg HTTP/1.1" 200 512 "http://www.wikipedia.org/" 
"Mozilla/5.0 (Windows NT 6.2; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0"

183.121.143.32 - - [08/Apr/2014:08:05:03 +0200] 
"GET /images/bild.png HTTP/1.1" 200 805 
"Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Aufsplitten lässt sich dies in folgende Parameter:

  • [1] 183.121.143.32: Die IP-Adresse des Besuchers
  • [2] “-”: Die Identität des Clients. Wird standardmäßig nicht ermittelt
  • [3] “-”: Wer die Anfrage ausgelöst hat
  • [4] [29/Apr/2013/:08:04:22 +0200]: Ein Zeitstempel wann der Zugriff stattgefunden hat
  • [5] GET /images/logo.jpg HTTP/1.1: Welche Ressource bzw. Ziel der Client angefordert hat
  • [6] 200: Statuscode den der Server zum Client zurückschickt
  • [7] 512: Die Größe der gesendeten Datenmenge in Byte
  • [8] https://www.wikipedia.org/: Von welcher Internetseite der Zugriff erfolgte
  • [9] Mozilla/5.0 (Windows NT 6.2; […]: Mit welchem Browser und Betriebssystem (User-Agent) der Zugriff erfolgt

Besonders interessant für unsere Zwecke ist der Parameter [9]. Webbrowser, als auch Bots verwenden zum Aufruf von Webseiten das HTTP-Protokoll und übertragen in der Anfrage den sogenannten User-Agent. Es handelt sich hierbei um ein optionales Feld, das eine eingeschränkte Identifizierung der anfragenden Quelle zulässt.

3.2 User-Agent Analyse

Wie bereits dargestellt übermitteln Webbrowser im »Normalfall« ihren User-Agent bei jeder Anfrage an den Webserver. Bei herkömmlichen nicht manipulierten Anfragen werden darin Informationen zur aktuellen Browser-Version und des verwendeten Betriebssystems übertragen. Da die Übertragung optional stattfindet und darüber hinaus beliebig manipuliert werden kann, ist die Aussagekraft leider eingeschränkt. Mit Hilfe des User Agent Switcher für Firefox oder User-Agent Switcher für Chrome lässt sich der User-Agent im Browser beliebig anpassen.

Bots unterliegen den selben Bestimmungen, wie ihre Browser-Kollegen. So sind auch sie in der Lage den User-Agent nach Belieben zu modifizieren und können damit einer eindeutigen und zuverlässigen Erkennung entgehen. Selbst nach der Umsetzung der folgenden Maßnahmen wird auch in Zukunft eine Dunkelziffer an parasitären Bots eure Webseite heimsuchen. Es lässt sich also niemals vollständig vermeiden, allerdings stark einschränken, was sich in weniger Datenbankabfragen, PHP-Interpreter Zugriffen und einer reduzierten Anzahl an Fehlermeldungen in den Log-Dateien bemerk machen wird.

3.3 Darstellung der Häufigkeit

Über die Konsole lässt sich durch die Kombination mehrerer Befehle die Häufigkeit der protokollierten User-Agents ermitteln. Im Beispiel wird die Log-Datei eines nginx-Servers unter dem Pfad »/var/log/nginx/access.log« ausgewertet:

awk -F\" '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -n

User-Agent

Die Mehrzahl der User-Agents lässt auf einen Besuch über den Firefox-Browser schließen. In der Darstellung sind auch einige RSS-Aggregatoren bzw. Feedreader (Tiny Tiny, Fever) erkennbar.

Bad Bots

In einem weiteren Auszug lassen sich drei Bots eindeutig identifizieren. Vagabondo/4.0/EU (Harvester), dlcbot/0.1 (Backlinks bzw. Links-Bot) und DotBot/1.1 (SEO). Eine kurze Recherche bei den jeweiligen Dienstleistern lässt die Erkenntnis zu: Keines der »Dienste« generieren für den WordPress-Betreiber einen Mehrwert bzw. werden von mir in Anspruch genommen. Als Webseitenbetreiber fasse ich daher den legitimen Entschluss, die für mich absolut unnötigen und nutzlosen Bots auszusperren.

Eine ausführliche Liste mit aktiven Bots findet ihr auf user-agent-string.info.

4. Umsetzung der Parasitenabwehr

Der korrekte Ansatz für die »Aussperrung« von unerwünschten Bots ist der Robots Exlusion Standard bzw. die robots.txt Datei im Wurzelverzeichnis eurer Webseite. Einige Crawler und Spider halten sich tatsächlich an die dort festgelegten Ausnahmen und Bestimmungen. Letztendlich ist es allerdings ein aussichtsloses Hase-und-Igel-Spiel, denn die Mehrzahl ignoriert die Definitionen schlichtweg und bereichert sich rücksichtslos im Dienste der Auftraggeber.

Daher werden wir »härtere« Maßnahmen ergreifen und parasitäre Bots direkt auf Serverebene, anhand ihres User-Agents, abweisen. Persönlich halte ich diese Variante für effektiver als IP-Sperren oder die »Bittstellung« in Form einer robots.txt Definition.

Im Internet findet ihr unterschiedliche Lösungen und Blockierlisten, die Bots über den User-Agent aussperren. Allerdings sind viele dieser Listen schlichtweg veraltet oder gnadenlos überdimensioniert. Als korrekten Ansatz schlage ich daher eine individuelle Analyse der Log-Dateien vor, die ihr mit dem bereits vorgestellten Konsolenbefehl umsetzen könnt. Als Ergebnis erhaltet ihr eine Liste mit User-Agents, die ihr halbjährlich einem Review unterziehen könnt. So könnt ihr ganz gezielt auf neue Bot-Varianten reagieren und müsst nicht auf Blockierlisten vertrauen, deren Qualität und Umfang die individuellen Anforderungen nicht erfüllen.

WordPress auf Schwachstellen und Konfigurationsfehler prüfen

Für Deine WordPress-Installation habe ich ein spezielles Leistungspaket im Angebot:
  • Scan Deiner WordPress-Installation auf Schwachstellen
  • Auswertung und Beurteilung der gefundenen Schwachstellen
  • Auf Basis der Ergebnisse erhälst Du von mir individuelle Maßnahmenempfehlungen zur Behebung und Absicherung

Wenn du Deine WordPress-Installation nachhaltig absichern möchtest, kannst Du mich gerne kontaktieren.

Gut zu wissen: Sicherheit erlangst Du nicht durch die Installation unzähliger Security-Plugins, sondern durch eine saubere Konfiguration, stetige Updates und proaktive Maßnahmen zur Absicherung. Kontakt aufnehmen

4.1 nginx Webserver

Bei meiner Artikel Recherche bin auf einen ausgezeichneten Beitrag von Sergej Müller gestoßen. Er beschreibt dort ausführlich die User-Agent Sperre gegen unerwünschte Bots. Außer einer abgewandelten bzw. an eure Bedürfnisse angepasste »bots.map«, kann ich die dort dargestellte Umsetzung empfehlen.

Eine Analyse meiner Log-Dateien ergab folgende bots.map:

# 02.05.2014: User-Agent Blocker
map $http_user_agent $is_bot {  
   default                0;

   # SEO
   ~AiHitBot              1;
   ~BLEXBot               1;
   ~Cliqzbot              1;
   ~DotBot                1;
   ~linkdexbot            1;
   ~MJ12bot               1;
   ~SEOkicks-Robot        1;
   ~SearchmetricsBot      1;
   ~SISTRIX               1;

   # Backlinks & Links
   ~AhrefsBot             1;
   ~BacklinkCrawler       1;
   ~dlcbot                1;
   ~spbot                 1;

   # Performance Testing
   ~200PleaseBot          1;
   ~ApacheBench           1;
   ~LoadTimeBot           1;

   # Harvester & Marketing
   ~CareerBot             1;
   ~GrapeshotCrawler      1;
   ~iCjobs                1;
   ~magpie-crawler        1;
   ~proximic              1;
   ~QuerySeekerSpider     1;
   ~Vagabondo             1;
   ~WBSearchBot           1;   

   # Useless, Bad & Unknown
   "~CMS Crawler"         1;
   ~Ezooms                1;
   ~^Java                 1;
   ~libwww-perl           1;
   ~niki-bot              1;
   ~updown_tester         1;

   # Empty User-Agent
   ""                     1;
}

Je nach Inhalt, Serverstandort und Bekanntheitsgrad werden eure Webseiten von unterschiedlichen Bots besucht. In eurer individuellen »Bestandsaufnahme« werdet ihr vermutlich einige der oben dargestellten Varianten wieder erkennen. Somit kann euch die Liste als Orientierungshilfe dienen, falls ihr zwecks Übersichtlichkeit ebenfalls eine Einteilung in unterschiedliche Kategorien vornehmen wollt.

Weitere Befehle können euch bei der erneuten Prüfung behilflich sein:
Auflistung aller von nginx (444 – No Response) geblockten bzw. abgewiesenen Bots:

cat /var/log/nginx/access.log | awk -F\" '{print $6,$3}' | sort | uniq -c | sort -n | grep 444

Auflistung aller User-Agents, die nicht von nginx abgewiesen wurden:

cat /var/log/nginx/access.log | awk -F\" '{print $6,$3}' | sort | uniq -c | sort -n | grep -v 444

Hinweis: Beide Befehle setzen die Umsetzung unter Ziffer 4.1 voraus.

4.2 Apache Webserver

Für den Apache Webserver sind ebenfalls entsprechende Anleitungen verfügbar. Jeff Starr hat zwei verschiedene Varianten in seinem Beitrag 2013 User Agent Blacklist zusammengefasst. Allerdings solltet ihr die unendlich lange Blockierliste nicht einfach übernehmen. Führt eine individuelle Analyse durch und erstellt eine Blockierliste, die euren Bedürfnissen gerecht wird.

Diese könnte folgendermaßen aussehen:

# 02.05.2014: User-Agent Blocker
<IfModule mod_setenvif.c>
   # SEO
   SetEnvIfNoCase User-Agent (AiHitBot|BLEXBot|Cliqzbot|DotBot|linkdexbot|MJ12bot|SEOkicks-Robot|SearchmetricsBot|SISTRIX) keep_out   
   # Backlinks & Links
   SetEnvIfNoCase User-Agent (AhrefsBot|BacklinkCrawler|dlcbot|spbot) keep_out   
   # Performance Testing
   SetEnvIfNoCase User-Agent (200PleaseBot|ApacheBench|LoadTimeBot) keep_out   
   # Harvester & Marketing
   SetEnvIfNoCase User-Agent (CareerBot|GrapeshotCrawler|iCjobs|magpie-crawler|proximic|QuerySeekerSpider|Vagabondo|WBSearchBot) keep_out   
   # Useless, Bad & Unknown
   SetEnvIfNoCase User-Agent (Ezooms|^Java|libwww-perl|niki-bot|updown_tester) keep_out
   # Empty User-Agent
   SetEnvIfNoCase User-Agent ^$ keep_out
   <limit GET POST PUT>
      Order Allow,Deny
      Allow from all
      Deny from env=keep_out   
   </limit>
</IfModule>

5. Fazit

Aus der Perspektive eines durchschnittlichen Webseitenbetreibers sind lediglich die »Dienste« der herkömmlichen Suchmaschinencrawler von Interesse. Bekannte Crawler wie der Googlebot/2.1 oder bingbot/2.0 sind gern gesehene Gäste, da sie den Inhalt einer Webseite indexieren und somit dem legitimen Anwender verfügbar machen.

Dem gegenüber steht eine Vielzahl von Diensten und Angeboten, die für den eigentlichen Webseitenbetreiber keinen Mehrwert generieren. Mit teils parasitären Verhalten beanspruchen die ausgeschickten Bots die knappen Ressourcen von Webservern und wirken sich insgesamt nachteilig auf die Performance der Webpräsenz aus. Derzeit ist nicht absehbar, wann dieser Trend ein Ende nehmen wird. Immer neuere, »intelligentere« Bots überschwemmen den Markt und generieren aberwitzige Statistiken – dessen Nutzen für die Allgemeinheit stark angezweifelt werden darf.

Es ist daher eine vollkommen legitime Entscheidung, unerwünschte Bots direkt auf Serverebene abzuweisen, noch bevor sie die Seite mit ihren Anfragen »überfluten« können.

Bildquellen:

Robot: „#53082452“, https://de.fotolia.com/id/53082452

Über den Autor | Kuketz

Mike Kuketz

In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.

Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.

Mehr Erfahren ➡

SpendeUnterstützen

Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.

Folge dem Blog

Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:

Bleib aktuell ➡


Diskussion

4 Ergänzungen zu “Parasitenabwehr von Bots – WordPress absichern Teil7”

  1. Comment Avatar Dentaku sagt:

    Gute Idee, aber meiner Meinung nach kommen hier zwei sinnvolle Sachen mit unter die Räder:

    Archive.org sollte nicht ausgesperrt werden, die sind das Langzeitgedächtnis des Web und keinesfalls „parasitär“.

    Die Default-UserAgent-Strings der gängigen Programmiersprachen auszusperren erzeugt öfter auch Probleme mit erwünschten Clients. Ich kenne z.B. Feedreader, deren Zugriff auf die Seite zur Suche nach der Feedadresse in solchen Konfigurationen fehlschlägt. Der Benutzer erhält dann die Meldung „Diese Seite hat leider keinen RSS-Feed“.

    • Comment Avatar Mike Kuketz sagt:

      Hallo Dentaku,

      mit den »Archive-Bots« hast du Recht. Die sind tatsächlich nicht »parasitär«. Ob der Besuch allerdings gewünscht ist, dass muss jeder selbst entscheiden.

      Mit den gängigen Programmiersprachen meinst du sicherlich Java. Es werden hier allerdings nur Bots geblockt, deren Name mit ^Java beginnt. Es rennen noch genügend Bots mit Kennungen wie »Java/1.4.1_04« oder »Java/1.6.0_17« durch das Internet, die eher schädlicher Natur sind.

  2. Comment Avatar Teamprove sagt:

    Einiges finde ich sehr interessant. Aber wie schon erwähnt wurde, sollte man gewisse Archive-Bots nicht aussperren.

  3. Comment Avatar Phadda sagt:

    Super Artikelreihe und auch klar verständlich. Weiter so, falls noch mehr positiver Optimierungsbedarf möglich ist ;-)
    Teilweise sind die Optimierung nach der Umsetzung zu spüren (speziell wenn es falsch ist *g*). Der Umkehrschluss ist dann, wie kann ich sicherstellen, das die individuellen Einstellungen auch so funktionieren wie gewollt? Evtl gibt das noch ein-zwei Artikel her?

HilfeWenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit. Kuketz-Forum

Abschließender Hinweis

Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.

Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.