ABAKUS

Verfasst: **12.02.2018, 04:56**

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.

Verfasst: **12.02.2018, 05:13**

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

Verfasst: **12.02.2018, 07:21**

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.

Verfasst: **12.02.2018, 07:53**

Ä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 &#40;Mozilla/4.0; MSIE 7.0; Windows NT 5.1; FDM; SV1; .NET CLR 3.0.04506.30&#41;"
"Mozilla/4.0 &#40;compatible; MSIE 6.0; Windows NT 5.1; SV1; Mozilla/4.0 &#40;compatible; MSIE 6.0; Windows NT 5.1; SV1&#41; &#41;"
"Mozilla/5.0 &#40;Windows NT 6.2; Win64; x64;&#41; Gecko/20100101 Firefox/20.0"
"Mozilla/4.0 &#40;compatible; MSIE 6.0; Windows NT 5.1; SV1;&#41;"
"Mozilla/4.0 &#40;compatible- MSIE 6.0- Windows NT 5.1- SV1- .NET CLR 1.1.4322"
"=Mozilla/5.0 &#40;Windows; U; Windows NT 6.1; en-US&#41; AppleWebKit/534.16 &#40;KHTML, like Gecko&#41; Chrome/10.0.648.204 Safari/534.16"
"\"Mozilla/4.0 &#40;compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0&#41;\""
"Mozilla/5.0 &#40;Macintosh; Intel Mac OS X 107&#41; AppleWebKit/534.48.3 &#40;KHTML like Gecko&#41; Version/5.1 Safari/534.48.3"
"Mozilla/5.0 &#40;X11; Linux AMD64&#41; Gecko Firefox/5.0"
"Mozilla/5.0 &#40;X11; Linux x86_64&#41; Gecko Firefox/5.0"
"Mozilla/5.0 &#40;X11; U; Linux i686; en-US; rv&#58;1.9.1.16&#41; Gecko/20120421 Gecko Firefox/11.0"
"Mozilla/5.0 &#40;Windows NT 5.1; rv&#58;11.0&#41; Gecko Firefox/11.0"
"Mozilla/5.0 &#40;Windows NT 6.1; WOW64; rv&#58;11.0&#41; Gecko Firefox/11.0"
"Mozilla/5.0 &#40;Windows NT 6.1; U;WOW64; de;rv&#58;11.0&#41; Gecko Firefox/11.0"
"Mozilla/5.0 &#40;Windows NT 6.1; WOW64; rv&#58;24.0&#41; Gecko/20140518 Firefox/24.0"
"Mozilla/5.0 &#40;Windows NT 6.1; it; rv&#58;1.9.2.20&#41; Gecko/20130612 Firefox/6.0.1"
"Mozilla/5.0 &#40;Windows NT 6.1; U;WOW64; de;rv&#58;11.0&#41; Gecko Firefox/11.0"
"Mozilla/5.0 &#40;Windows; U; Windows NT 5.1; en-US; rv&#58;x.x.x&#41; Gecko/20041107 Firefox/x.x"
"Opera/9.20 &#40;Windows; U; Windows NT 5.1; ru; rv&#58;1.8.1.19&#41;"
"Mozilla/4.0 &#40;compatible; MSIE 6.0; Windows XP&#41;"
"Mozilla/4.0 &#40;compatible;MSIE 7.0;Windows NT 6.0&#41;"
"Mozilla/6.0 &#40;compatible; MSIE 7.0a1; Windows NT 5.2; SV1&#41;"
"Mozilla/37.0.2 &#40;compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322&#41;"
"Mozilla/5.0 &#40;compatible; MSIE 11.0; Windows NT 5.1; Trident/5.1&#41;"
"Mozilla/4.0+&#40;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&#41;"

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.

Viele Grüße
ElCattivo

Verfasst: **12.02.2018, 09:46**

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

ja, kann mir gut vorstellen dass sich die ganzen fiesen hacker mit ihren gespooften referern die zaehne an deiner .htaccess ausbeissen ...

Verfasst: **12.02.2018, 09:56**

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

Was hat das mit Hackern zu tun? Für sowas ist eine .htaccess (oder höhere Instanzen) gar nicht da. Die kommen eher über dein sprödes WP/Joomla/Drupal rein, platzieren nen MITM zwischen deiner Seite und nem Adserver oder machen mal nen Meltdown in deiner Cloud.

Apropos sprödes WP/Joomla/Drupal...da gibt's auch schöne Exploits, MySQL-Injection Base64 codiert über nen POST abgesetzt - *zack* defacement, selbst gesehen in meiner "Szene" und auch ne News drüber geschrieben...mir egal mit meiner HTML/CSS only Seite.

Mal ehrlich...ich fand deine Posts in den letzten Jahren hier mehrheitlich sehr sinnvoll, aber damit greifst du ins Klo.

Edit:

Kleiner Treppenwitz...folgenden Zugriff kannst du ja mal decoden, er wurde übrigens durch meine .htaccess geblockt, obwohl er eh nichts bewirkt hätte.

MODEDIT: gelöscht -- Du hast hier die ganze Formatierung des Forums zerschossen

Viele Grüße
ElCattivo

Verfasst: **12.02.2018, 12:06**

ElCattivo hat geschrieben:Die kommen eher über dein sprödes WP/Joomla/Drupal rein, platzieren nen MITM zwischen deiner Seite und nem Adserver oder machen mal nen Meltdown in deiner Cloud.

Stimmt, darueber habe ich schon mal eine dokumentation gesehen....

ElCattivo hat geschrieben: Apropos sprödes WP/Joomla/Drupal...da gibt's auch schöne Exploits, MySQL-Injection Base64 codiert über nen POST abgesetzt - *zack* defacement, selbst gesehen in meiner "Szene" und auch ne News drüber geschrieben...mir egal mit meiner HTML/CSS only Seite.

Is richtig! PHP und datenbanken braucht man eigentlich auch gar nicht fuer ne webseite. Ausser vielleicht wenn man daten erfassen und speichern will. Oder einen webshop moechte. Oder mails verschicken will. Oder benutzereingaben auf dem server ueberpruefen muss. Oder das katzenblog aktualisieren moechte. Oder im backend API calls vornehmen muss. Oder bilder oder dateien irgendwie umwandeln muss. Oder PDFs erzeugt und verschickt.
Aber sonst eigentlich nicht.

Es gibt wirklich viele schoene seiten im internet die man auch ohne den ganzen PHP und MySQL quark umsetzen kann!

ElCattivo hat geschrieben:Kleiner Treppenwitz...folgenden Zugriff kannst du ja mal decoden, er wurde übrigens durch meine .htaccess geblockt, obwohl er eh nichts bewirkt hätte.

Code: Alles auswählen

... Hacked By aDriv4 ...

Hm also ich glaube ja echte "hacker" wuerden eher versuchen wertvolle nutzerdaten rauszutragen und dabei so unbemerkt wie moeglich vorzugehen (zum beispiel indem sie die logfiles ueberschreiben, und nicht die homepage!) und so oft wie moeglich wiederzukommen, statt die index mit ein einem albernen bildchen und grussbotschaft and die "1337 friends" abzusetzen.
Hier war einfach nur ein script-kiddie am rumcybern der wahrscheinlich nur planlos seinen POST mit payload an so viele domains wie moeglich schickt, in der hoffnung ein paar ungepatchte installationen von 2012 zu erwischen. Wuerde ich in meinen serverlogs sicher auch finden, wenn ich danach suchen wuerde.

Verfasst: **13.02.2018, 17:30**

ElCattivo hat geschrieben:MODEDIT: gelöscht -- Du hast hier die ganze Formatierung des Forums zerschossen

Jap, hatte kurz selber überlegt, ob ich es wieder rausnehme. Ist bißchen blöd hier ohne Zwangsumbrechen im Forum. :-/

@nerd:

Meinetwegen versuchst du das weiter ins Lächerliche zu ziehen. Ob ein Projekt interessant für einen Hacker ist, siehst du erst, wenn's zu spät ist.

Man kann auch moderne Seiten nur mit HMTL/CSS bauen. Deine "schönen" Beispiele finde ich trotzdem besser als den langweiligen bloated Einheitsbrei von heute. Gerade im Technik-Bereich sehen die besten Seiten eher nach Mitte 90er bis Anfang 2000er aus.

Es ist logisch, dass es genügend Seiten gibt, die ohne PHP/JS/*SQL schlecht auskommen. Einfachste Seiten, die rein statisch sind, mit WP/Joomla/Drupal zu betreiben ist dagegen aus mehreren Gründen vollkommen übertrieben und unangebracht. Zu den Gründen gehört auch das automatische Abgrasen und Ausnutzen von Sicherheitslücken (das mittlerweile weggemoddete

Beispiel). Wenn es einen Zero Day gibt, hast evtl. einfach mal Pech gehabt und dein aktuelles Patchlevel nützt dir gar nichts.

Es ist auch vollkommen egal was du glaubst was "echte Hacker" so tun, den Schaden hast im Fall des Falles du. Die meisten automatisierten Angriffsversuche (und auch SPAM-Bots) laufen von Serverfarmen/Hostern, die man ganz wunderbar z.B. über die .htaccess aussperren kann (um mal wieder zum Thema zurückzukommen) - wenig Arbeit um sich schonmal viel Crap vom Hals zu halten.

Hanzo2012 hat geschrieben:Ein besonders wichtiger Ratschlag bezüglich .htaccess: Benutze sie nicht
Wie du wahrscheinlich weißt, werden .htaccess-Dateien bei jeder Abfrage neu interpretiert und in jedem Unterverzeichnis gesucht. Wenn möglich, sollte man solche Regeln global im VHost definieren und .htaccess komplett verbieten (nur dann gewinnt man):
https://haydenjames.io/disable-htaccess ... rformance/

nerd hat geschrieben: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.

Um nochmal auch für nerd darauf zurückzukommen...vll einfach mal das verlinkte auch lesen...

...You should only use .htaccess if you are on a shared hosting plan, don’t have root access to the web server or if you lack experience with modifying Apache’s config files...

Auf shared Hosting hat man logischerweise keinen Zugriff auf die Serverconfig, wie schonmal gesagt.

Viele Grüße
ElCattivo

Verfasst: **13.02.2018, 20:58**

ElCattivo hat geschrieben: Meinetwegen versuchst du das weiter ins Lächerliche zu ziehen. Ob ein Projekt interessant für einen Hacker ist, siehst du erst, wenn's zu spät ist.

Du verwechselst hier ganz klar hacker mit irgendwelchen script kiddies die ein paar uralt-exploits fuer gaengige CMS fahren. "Hacker" haben kein interresse daran die webseiten irgendwelcher wordpress/drupal/joomla webseiten lokalen baecker, blumenlaeden, autowerkstaetten oder nagelstudios zu "hacken", einfach weil es da nichts zu holen gibt was sich zu geld machen laesst!
Und bevor sie die seite nach sicherheitsluecken abgrassen, werden sie erstmal ein paar standard-passwoerter auf der admin-seite durchprobieren, was wahrscheinlich bei 90% der firmen die nichts mit IT am hut haben zielfuehrend ist.

Und dir nuetzt dir deine html-seite auch nichts, wenn die firmen-email, webhost-backend oder portal des zahlungsanbieters mit passwort "#firmenname#" zugaenlich ist. Wer schonmal mit solchen kunden zusammengearbeitet hat, weiss dass man gar nicht die tuer mit'm schweissbrenner bearbeiten muss um reinzukommen, wenn deren haus nichtmal waende hat.
Die htaccess schuetzt dich nicht vor "hackern", und dazu war sie auch nie gedacht

Verfasst: **13.02.2018, 21:32**

Ich weiß nicht ob das Projekt noch aktiv ist, ich denke schon:

https://www.bot-trap.de/home

https://www.spider-trap.de/

Gruss

Verfasst: **13.02.2018, 22:31**

@nerd:

Du verwechselst da was. Du hast mit „Hackern“ angefangen und ich hab geschrieben, dass die .htaccess nicht der Abwehr irgendwelcher Hacker-Angriffe dient bzw. nicht dafür gedacht ist.

Das gepostete kann meinetwegen ein Uralt-Exploit gewesen sein, ist ja auch schon ne ganze Weile her, dass der in den Logs war. Trotzdem kann dich ein Zero erwischen. Ist dann auch völlig egal, wer das losgelassen hat (Hacker, Script-Kiddie, Tante Erna, ...), die Arbeit, das zu entfernen, hast du, wenn‘s dich erwischt.

@swiat:

Hatte ich mir vor zwei, drei Jahren angeschaut und für nicht zielführend befunden. Da gibt’s noch paar andere Projekte in die Richtung. Habe mich dann lieber in die .htaccess Syntax eingearbeitet und fahre sehr gut damit.

Viele Grüße
ElCattivo

Verfasst: **14.02.2018, 01:45**

ElCattivo hat geschrieben:Habe mich dann lieber in die .htaccess Syntax eingearbeitet und fahre sehr gut damit.

Wenn man einen hammer in der hand hat dann sieht auch alles nach einem nagel aus...

Verfasst: **14.02.2018, 04:00**

nerd hat geschrieben:Wenn man einen hammer in der hand hat dann sieht auch alles nach einem nagel aus...

Nö...alles gut. Meiner Erfahrung nach ist das auch wesentlich performanter als das über PHP zu regeln, vor allem wenn noch ne DB mit hintendran hängt.

@swiat:

Hab grad nochmal reingeschaut, war vorhin auf Arbeit und konnte nur schnell über Tele schreiben. Was mir an diesen Projekten meist nicht gefällt am Beispiel von bot-trap.de:

Aktuell sind gesperrt [Stand: 1. Januar 2018 (1. Januar 2017)]:

591072 (556291) einzelne IP-Adressen,
34564 (33239) Adressbereiche und
327 (321) User-Agent-Kennungen.

...da sind je nach Projekt teils IP-Blöcke und UAs drin, mit denen ich keine Probleme habe, wo mir sogar legitime Nutzer ausgesperrt werden...da mache ich das doch lieber selbst inkl. Logfile-Analyse. Bei solchen Projekten werden oft auch legitime Suchmaschinen-Crawler wie Seznam, Côc Côc, Baidu, Naver, yooz usw. ausgesperrt...diese Suchmaschinen bringen mir aber wertvolle Nutzer. Genauso möchte ich nicht die ganze Ukraine und halb Russland aussperren.

Weiterhin bringen diese ganzen via PHP realisierten Sachen nichts bei direkten Zugriffen auf Bilder oder weitere Downloads. Wenn eine 30 MB große Datei hunderte Male vollkommen sinnlos automatisiert an einem Tag (teilweise dutzende Male innerhalb von Minuten) heruntergeladen wird, belastet das den Traffic nicht unerheblich. Auch, wenn da "Flatrate" o.ä. beim Hoster steht. Wäre ich bei Uberspace, wäre ich trotz des durch die .htaccess reduzierten Traffics schon fast in der Problemzone (>100GB/Monat).

Viele Grüße
ElCattivo

ABAKUS

Email harvester und unerwünschte Bots mit .htaccess sperren