registrieren registriertes Mitglied


Anzeige

Anzeige

Email harvester und unerwünschte Bots mit .htaccess sperren

Alles zu Domain-Umzug, Weiterleitungen und Robots diskutiert Ihr hier.
nerd
PostRank 10
PostRank 10
Beiträge: 4329
Registriert: 15.02.2005, 04:02

Beitrag nerd » 12.02.2018, 04:56 Email harvester und unerwünschte Bots mit .htaccess sperren

Irgndwelche http-header in der htaccess auszuwerten ist aber ziehmlich micky-maus:

- alle http-header kann man nach belieben selbst setzen, soll heissen sie lassen keinen rueckschluss auf den tatsaechlichen user-agent, browser oder herkunftsland zu
- man muss am besten taeglich in der server-config rumwerkeln um die liste halbwegs aktuell zu halten
- wehe man vertippt sich dabei (sonderzeichen in der regex?), bei einem syntax-fehler gibts auf den meisten servern ausser "Error 500" und einer weissen seite nichts zu sehen, bis man die server-logs ausgraebt.
- es gibt kein error-logging und keine statistiken, wer wann und wieoft ausgesperrt wurde! Eine neue regel ueberschneidet sich versehentlich mit 50% deiner referer und besucher werden kommentarlos geblockt? Pech gehabt, in google analytics sieht man dann nur einen 50% traffic verlust, und in den server logs tauchen die geblockten user auch nicht auf!

Die bessere loesung waere natuerlich, bots am VERHALTEN zu erkennen: Laden sie irgendwelche bilder nach die nur in der .css verlinkt sind, fuehren sie javascript und ajax requests aus, gibt es mausbewegungen (ohne schnurgerade linien von A nach B!), entspricht die farbe von a:visited links auf dem bildschirm dem wert, der in der CSS angegeben ist, suchen sie nach robots.txt oder favicon auf dem server usw.

Ich verstehe das argument mit "Zugriff auf höhere Serverkonfiguration (wie z.B. ich auf nem shared Hosting)" nicht. Wer im jahre 2018 einen (shared-)hoster ohne PHP, MySQL oder andere serverstacks hat laeuft doch am leben vorbei.

Anzeige von:

Personal Branding mit ABAKUS:
  • Höhere Glaubwürdigkeit
  • Hervorhebung Ihrer Kompetenz
  • Stärkung Ihrer Alleinstellungsmerkmale
  • Abhebung von Namensvettern
Profitieren Sie von unserer Erfahrung!
0511 / 300325-0

ElCattivo
PostRank 4
PostRank 4
Beiträge: 112
Registriert: 12.02.2018, 02:24

Beitrag ElCattivo » 12.02.2018, 05:13 Email harvester und unerwünschte Bots mit .htaccess sperren

Du überschätzt die Intelligenz der Botbetreiber...viele bekommen es nichtmal gebacken nen UA zu spoofen, da steht im UA z.B. "User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31" - das ist so einfach zu blocken (siehe mein .htaccess Ausschnitt).

Dass man die Syntax drauf haben sollte, ist klar. Man muss aber nicht täglich in die Logs schauen, monatliches Abgrasen reicht. Beides habe ich übrigens erwähnt.

Dass es kein Logging gibt, ist Quatsch. Was denkst du, macht die 403.php? Genau, sie loggt alle 403er!

Was hat denn PHP und MySQL mit "Zugriff auf höhere Serverkonfiguration" zu tun? Natürlich kriegt man ersteres im shared Hosting hinterhergeworfen, Apache Konfiguration geht aber nicht über .htaccess hinaus, da neben einem ja noch andere auf dem Server sind, denen man nicht einfach mal die Server-Config verstellen soll. Die .htaccess ist allemal schneller (wenn man es richtig macht) als den Kram über PHP (am besten noch mit lahmer Datenbank hintendran) zu regeln. Klar wäre IPCop super zum Aussperren der ganzen Hoster-/Cloud-Ranges, geht aber nunmal nicht auf nem shared Hosting.

Viele Grüße
ElCattivo

nerd
PostRank 10
PostRank 10
Beiträge: 4329
Registriert: 15.02.2005, 04:02

Beitrag nerd » 12.02.2018, 07:21 Email harvester und unerwünschte Bots mit .htaccess sperren

ElCattivo hat geschrieben:Du überschätzt die Intelligenz der Botbetreiber...viele bekommen es nichtmal gebacken nen UA zu spoofen, da steht im UA z.B. "User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31" - das ist so einfach zu blocken (siehe mein .htaccess Ausschnitt).
Hm was ist daran jetzt genau falsch? Bis auf die Chrome versionsnummer identisch mit meinem unmodifizierten user agent; allerdings habe ich schon malware gesehen die verhindert das chrome updates installiert.
ElCattivo hat geschrieben: Dass es kein Logging gibt, ist Quatsch. Was denkst du, macht die 403.php? Genau, sie loggt alle 403er!
Die 403 kann aber erst ausgegeben werden wenn apache den request entgegengenommen hat, und bemerkt dass er den request nicht bediehnen kann. Wenn der webserver die htaccess wegen einem syntaxfehler nicht abarbeitet, quitiert apache mit einem generischen 500 den man nur in den serverlogs, aber nicht in den access-logs sieht.

ElCattivo
PostRank 4
PostRank 4
Beiträge: 112
Registriert: 12.02.2018, 02:24

Beitrag ElCattivo » 12.02.2018, 07:53 Email harvester und unerwünschte Bots mit .htaccess sperren

Äh, ich hab das Falsche für dich schon extra ROT markiert...seit wann fängt ein valider Chrome UA mit "User-Agent: " an? Jeder, wirklich jeder (!), valide Chrome UA fängt mit "Mozilla/5.0 " an. Das ist einfach nur ein simpler String und der Spoofer hatte genauso wenig Ahnung von UAs wie du und hat einfach den String aus seinem "Tool" kopiert - nur blöd, dass das "Tool" noch User-Agent: davor geschrieben hat.

Und das ist nur einer der "billigsten" falsch gespooften UAs, man muss sich natürlich etwas mit UAs auskennen, um die passenden Regeln zu erstellen. Die gespooften Fake-UAs werden übrigens gern für Scraping benutzt...Ergebnis ist dann komplett geklonter Content, was hier auch schon öfters besprochen wurde.

Hier mal ein paar weitere Fake-UAs - ich hab dir die schönsten rausgesucht, alle sind Fakes, kannst dich ja mal dran probieren (Tip: rekursiv kannst du über die .htaccess-Regeln rangehen):

Code: Alles auswählen

"Mozilla/4.0 (Mozilla/4.0; MSIE 7.0; Windows NT 5.1; FDM; SV1; .NET CLR 3.0.04506.30)"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) )"
"Mozilla/5.0 (Windows NT 6.2; Win64; x64;) Gecko/20100101 Firefox/20.0"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;)"
"Mozilla/4.0 (compatible- MSIE 6.0- Windows NT 5.1- SV1- .NET CLR 1.1.4322"
"=Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.204 Safari/534.16"
"\"Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0)\""
"Mozilla/5.0 (Macintosh; Intel Mac OS X 107) AppleWebKit/534.48.3 (KHTML like Gecko) Version/5.1 Safari/534.48.3"
"Mozilla/5.0 (X11; Linux AMD64) Gecko Firefox/5.0"
"Mozilla/5.0 (X11; Linux x86_64) Gecko Firefox/5.0"
"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20120421 Gecko Firefox/11.0"
"Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko Firefox/11.0"
"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko Firefox/11.0"
"Mozilla/5.0 (Windows NT 6.1; U;WOW64; de;rv:11.0) Gecko Firefox/11.0"
"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20140518 Firefox/24.0"
"Mozilla/5.0 (Windows NT 6.1; it; rv:1.9.2.20) Gecko/20130612 Firefox/6.0.1"
"Mozilla/5.0 (Windows NT 6.1; U;WOW64; de;rv:11.0) Gecko Firefox/11.0"
"Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:x.x.x) Gecko/20041107 Firefox/x.x"
"Opera/9.20 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.19)"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows XP)"
"Mozilla/4.0 (compatible;MSIE 7.0;Windows NT 6.0)"
"Mozilla/6.0 (compatible; MSIE 7.0a1; Windows NT 5.2; SV1)"
"Mozilla/37.0.2 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
"Mozilla/5.0 (compatible; MSIE 11.0; Windows NT 5.1; Trident/5.1)"
"Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.2;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.4506.2152;+.NET+CLR+3.5.30729)"
Ob du nen 500 bekommst, kannst du doch gleich nach dem Hochladen der .htaccess testen (sollte man auch) - Browsercache löschen, entsprechende Domain und vll paar Unterseiten aufrufen, fertig. Wenn das nicht der Fall ist, hast du keinen Syntax-Fehler. Wenn es der Fall ist, Änderungen rückgängig machen und Code überprüfen. Anschließend erneut testen.

Da alles läuft, loggt das 403er Script friedlich vor sich hin, genau wie das 404er Script und das 503er Script...

Um nochmal auf deine "Verhaltens-Analyse" von oben zurückzukommen. Das bringt bei direkten Downloads gar nichts. Da greift PHP, CGI und sonstiges serverseitiges Scripting überhaupt nicht, weil die Aktion eine Etage tiefer auf HTTP Ebene stattfindet. Um das blocken zu können, brauchst du mindestens .htaccess (oder andere Server-Einstellungen, die dir auf shared Hosting nicht zur Verfügung stehen).

BTW: Google Analytics? Ich ziehe bestimmt kein externes JS usw., verstößt gegen meine strikte "privacy policy", haben die Nutzer meiner Seite garantiert nicht verdient.

Was du weiter oben "micky-maus" nennst, schützt meine Seite seit Jahren ganz gut. :naund:

Viele Grüße
ElCattivo

nerd
PostRank 10
PostRank 10
Beiträge: 4329
Registriert: 15.02.2005, 04:02

Beitrag nerd » 12.02.2018, 09:46 Email harvester und unerwünschte Bots mit .htaccess sperren

ElCattivo hat geschrieben: Was du weiter oben "micky-maus" nennst, schützt meine Seite seit Jahren ganz gut. :naund:
ja, kann mir gut vorstellen dass sich die ganzen fiesen hacker mit ihren gespooften referern die zaehne an deiner .htaccess ausbeissen ...

Anzeige von: