HomeKontaktImpressum
Sie sind hier: Home

.htaccess deny – Clients abwehren

Damit der Webserver über die Beantwortung von überflüssigen Anfragen von nutzlosen oder exzessiv agierenden Crawlern die realen Seitenbesucher nicht unnötig warten lässt, sollten unkooperative Bots, die sich nicht an die Angaben in der Robots.txt-Datei halten, ganz ausgeschlossen werden. Mit dem hier beschriebenen htaccess-Deny-Mechanismus sollte allerdings vorsichtig umgegangen werden.

Da massenhaft abgesetzte oder gar unnötige Anfragen an den Webserver die vorhandenen Resourcen unverhältnismäßig stark beanspruchen, sollten derartige Anfragen geblockt werden. Schließlich wird ein stark mit der Beantwortung von Bot-Anfragen beschäftigter Server bei der Bearbeitung anderer Browseranfragen durch echte Besucher ausgebremst. Die Wesite-Performance und letztlich die Usability der Internetseite leidet unter diesem Umstand und führt zu unzufriedenen Seitenbesuchern, die im Extremfall sogar den Ladevorgang vorzeitig abbrechen. Anders als bei den in der Robots.txt-Datei angegebenen Sperren kann mit dem Ausschluß von Clients per htaccess-Deny ein wirksamer Schutz vor ungewollten Zugriffen auf eine Website realisiert werden.

Mit der htaccess-Deny Restriktive lassen sich HTTP-Anfragen auf verschiedene Arten abwehren. Neben einen htaccess-Schutz auf Basis des User-Agents, können Webserver-Requests über die IP-Adresse des anfragenden Clients oder dessen Domainnamen abgewehrt werden. Im folgenden Code-Block wird letztere Variante gezeigt:

# Clients per htaccess deny abwehren
# Diesmal aber auf Basis des Domainnamen
order allow,deny
deny from .badbot.com
deny from .email-harvester.net
allow from all

Durch die mit order beginnende Zeile wird hier festgelegt, dass erst einmal die in der letzten Zeile mit allow angegebene Regel verarbeitet wird und erst dann die einzelnen hier angegebenen Verbote (Zeilen mit der deny Direktive) geprüft werden. Hierdurch wird also die Verarbeitungsreihenfolge geregelt. Im Beispiel werden alle Clients abgewiesen, die ihre Anfragen von den aufgeführten Domains bzw. darunter angesiedelten Subdomains stellen.

Hier ist, wie auch bei einer Crawler-Sperre via. htaccess und IP-Adressen, allerdings Vorsicht geboten. Bevor eine solche Barriere aufgebaut wird sollte, man sich eingehend über den betreffenden Bot und die Domains über welche die Website-Zugriffe erfolgen informieren. Schließlich ist die Gefahr groß mit einer allzu voreiligen Sperrung negative Nebeneffekte zu erzielen. Am Ende fällt man noch aus den Indexen von Suchmaschinen heraus, von denen dann keine echten Besucher mehr kommen. Darüber hinaus rufen die Crawler einiger Webverzeichnisse oder anderer Seiten, die ihre externen Links in bestimmten Intervallen überprüfen, die dort verlinkten Internetseiten regelmäßig ab um eventuell in ihrem System enthaltene Broken-Links zu erkennen und diese zu entfernen. Abgesehen davon, dass von solchen Bots ohnehin keine besonders große Anzahl von Abfragen zu erwarten ist, wäre eine Blockade dieser Bots also eher unvorteilhaft.

Ein weiterer Aspekt, der nicht ausser Acht gelassen werden sollte, ist der, dass htaccess-Deny-Einträge dieser Art grundsätzlich bei allen Anfragen an den Webserver verarbeitet werden wollen – auch bei Requests, die auf Bilddateien oder Stylesheets abzielen und normalerweise nicht durch Bots abgerufen werden. Mit wachsender Zahl an Verboten wächst zugleich der für die Verarbeitung der Sperren nötige Verarbeitungsaufwand. Bei der zuletzt angesprochenen Variante etwa müssen bei jeder Serveranfrage DNS-Lookups abgesetzt werden, mit deren Hilfe der zu einer IP-Adresse gehörende Domainname ermittelt wird. Aus diesem Grund sollte man den Einsatz entsprechender Einträge in der Robots-Datei vorziehen wo immer es möglich ist – also bei allen Crawlern, die sich an die dort angegebenen Vorgaben halten.

Durch Verschachtelung in einen FilesMatch-Block kann der Aufwand für den Webserver minimiert werden. Da die meisten Bots nur HTML-Dateien – bzw. URLs, unter denen HTML-Dateien ausgeliefert werden; also alles, was mit normalen A-Tags von irgendwo verlinkt ist und keine ausschließende Dateiendung (pdf, swf oder Ähnliches) besitzt – abrufen, lässt sich der nötige Aufwand zur Verarbeitung der Deny-Sperre auf diese URLs minimieren. Im folgenden Block wird eine solche Verschachtelung auf Dateien mit der Endung html realisiert.

<FilesMatch "\.html$">
# hier folgen die Direktiven zur Ablehnung von Bot-Zugriffen
...
</FilesMatch>

Ein derart realisierter Schutz vor Botzugriffen belastet den Webserver nicht unnötig, wenn er lediglich um die Auslieferung von Bildern oder Stylesheets gebeten wird. Im Prinzip lassen sich derartige Mechanismen auch für Bots, die Bilddateien abrufen, umsetzen. Dazu müssen lediglich die gewünschten Dateiendungen mit einem solchen Block bedacht werden.

Seite 1 von 3 | « [1] • [2][3] »
  
© 2009-2017 Möglichkeiten zur Steigerung von Geschwindigkeit und Usability Ihrer eigenen Website