it-swarm.com.de

htaccess leerer Referer verweigert "google bot"

  1. Ich habe diese Regel in die htaccess-Datei eingefügt, um leere Verweise abzulehnen, die 403 zurückgeben

    SetEnvIfNoCase Referer "^$" bad_user  
    Deny from env=bad_user
    

    Ich kann das Protokoll sehen, es lehnt auch Googlebot ab, der auch als leerer Referrer fungiert. Gibt es eine Möglichkeit, die Regel zu ändern, um den Zugriff für Googlebot zuzulassen und alle anderen leeren Verweise zu verweigern?

  2. Ich habe einen Referrer www.example.com mit blockiert

    RewriteCond %{HTTP_REFERER} example\.com [NC]  
    RewriteRule .* - [F]
    

    Es funktioniert gut, wenn er 403 zurückgibt, aber was ist, wenn er sich auf example.com/another_page bezieht?

    Also habe ich das gemacht:

    RewriteCond %{HTTP_REFERER} example\.com [NC,OR]  
    RewriteCond %{HTTP_REFERER} example/another_page\.com/ 
    RewriteRule .* - [F]
    

    Ist es richtig?

  3. Wie kann ich diesen Benutzeragenten blockieren: Mozilla/5.0/Firefox/42.0 - nbertaupete95(at)gmail.com? Wie soll die Regel aussehen? Wird das funktionieren?

    RewriteCond %{HTTP_USER_AGENT} ^nbertaupete95(at)gmail.com [NC]  
    RewriteRule .* - [F,L]
    
2

Wie Sie in Kommentaren festgestellt (und davor gewarnt) haben, sollten Sie nicht versuchen, Anforderungen zu blockieren, die einen leeren Referer -Header enthalten. Google (und die meisten Bots) und viele legitime Benutzer senden den HTTP Referer -Header (zumindest zu einem bestimmten Zeitpunkt) nicht, sodass dies nur zu Problemen führt.

Um die beiden verbleibenden Fragen in Ihrer Frage zu beantworten ...

  1. Ich habe einen Referrer www.example.com mit blockiert

    RewriteCond %{HTTP_REFERER} example\.com [NC]  
    RewriteRule .* - [F]
    

    Es funktioniert gut, wenn er 403 zurückgibt, aber was ist, wenn er sich auf example.com/another_page bezieht?

Sie müssen an Ihren vorhandenen Anweisungen nichts ändern. Die erste Anweisung RewriteCond blockiert bereits alle Verweise, die einfach enthältexample.com. Beachten Sie, dass example\.com eine Regex (regulärer Ausdruck) ist (weshalb der Punkt mit einem Backslash versehen ist). Ohne Anker passt das Muster natürlich überall in HTTP_REFERER.

(Allerdings ist das Muster in Ihrer zusätzlichen Direktive example/another_page\.com/ ohnehin ein bisschen püriert, würde also nie wie beabsichtigt passen. Das hätte nichts ausgemacht, da es wird die erste gefunden haben Bedingung sowieso.)

  1. Wie kann ich diesen Benutzeragenten blockieren: Mozilla/5.0/Firefox/42.0 - nbertaupete95(at)gmail.com? Wie soll die Regel aussehen? Wird das funktionieren?

    RewriteCond %{HTTP_USER_AGENT} ^nbertaupete95(at)gmail.com [NC]
    RewriteRule .* - [F,L]
    

Nein, das würde nicht funktionieren, der reguläre Ausdruck ist nicht korrekt. Sie haben einen Zeichenfolgenanfang anchor (^) in die Regex eingefügt, sodass nur Benutzeragenten berücksichtigt werden, die start "nbertaupete95 ...". In der angegebenen User-Agent-Zeichenfolge ist diese Teilzeichenfolge enthalten in it.

Klammern (( und )) sind spezielle Metazeichen in Regex - sie werden für Wechsel und zum Erfassen von Untermustern verwendet. Um einer wörtlichen Klammer zu entsprechen, müssen diese mit einem Backslash versehen werden, z. \(.

Ihr Beispiel sollte also stattdessen etwa wie folgt lauten:

RewriteCond %{HTTP_USER_AGENT} nbertaupete95\(at\)gmail\.com
RewriteRule .* - [F]

Das L -Flag ist nicht erforderlich, wenn F verwendet wird (dies ist impliziert). Das NC -Flag auf dem _CondPattern_ ist ebenfalls nicht erforderlich, es sei denn, dieser Benutzeragent hat tatsächlich eine Variation der Groß-/Kleinschreibung? Außerdem müssen Punkte maskiert werden, um mit einem wörtlichen Punkt übereinzustimmen, wie Sie es in Ihren früheren Anweisungen getan haben.

Im angegebenen User-Agent steht die "E-Mail-Adresse" am Ende des User-Agents. Wenn dies der Fall ist, können Sie dem regulären Ausdruck ein Ende der Zeichenfolge Anker ($) hinzufügen, zum Beispiel: nbertaupete95\(at\)gmail\.com$.

1
MrWhite