nicht angemeldet
Der Martin
Matthias Apsel
Felix Riesterer
Der Martin
Hello,
heute Nacht ist eine der von mir betreuten Webseiten angegriffen worden. Als vermeintlicher Verursacher konnte
NetRange: 74.119.232.0 - 74.119.235.255
CIDR: 74.119.232.0/22
OriginAS: AS46506, AS16626
NetName: SIMPLEHELIX
NetHandle: NET-74-119-232-0-1
Parent: NET-74-0-0-0-0
NetType: Direct Allocation
Comment: http://www.simplehelix.com
Comment: Standard NOC hours are 24/7 CST
RegDate: 2009-11-19
Updated: 2012-03-02
Ref: http://whois.arin.net/rest/net/NET-74-119-232-0-1
OrgName: SimpleHelix.com
OrgId: SIMPL-62
Address: 4092 Memorial Pkwy SW
Address: Suite 202
City: Huntsville
StateProv: AL
PostalCode: 35802
Country: US
RegDate: 2009-10-12
Updated: 2011-12-27
Comment: http://www.simplehelix.com
Ref: http://whois.arin.net/rest/org/SIMPL-62
festgestellt werden. Habe ich da irgend eine Chance, etwas zu tun?
Der Ausschnitt aus dem Access-Log ist unter
http://selfhtml.bitworks.de/angriffsmuster/20140219_0929_access_log.txt
zu sehen. Der Server-Status 200 rührt daher, dass alle Anfragen, die nicht befriedigt werden können, auf die Haupt-index.php umgelenkt werden. Die unterschiedlichen Content-Lenght rühren von einer Kontrollausgabe (im HTML-Kommentar verpackt) in der die aktuelle Request-URL angezeigt wird.
Das werde ich nun mal rausnehmen aus dem Produktivbetrieb. Die Seite ist allerdings noch nicht fertig und ich benötige auch auf dem P-Server gelegentlich noch Kontrollausgaben. Der weicht in weinem Verhalten geringfügig vom Entwicklungsserver ab...
Na jedenfalls lasse ich dieses Beispiel mal so stehen, damit man den Leuten die immer mit
Auge
file_get_contents($_GET['filename'])
mal plastisch vorführen kann, warum das so schädlich ist.
BTW: kann man hier in [Code]-Blöcken eigentlich auch die Farbe steuern?
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hello,
heute Nacht ist eine der von mir betreuten Webseiten angegriffen worden...
festgestellt werden. Habe ich da irgend eine Chance, etwas zu tun?Der Ausschnitt aus dem Access-Log ist unter
http://selfhtml.bitworks.de/angriffsmuster/20140219_0929_access_log.txt
zu sehen.
Sieht wie ein 08/15 automatisierter "Angriff" eines Bots aus, wie er auf mittelmäßig bekannten Domains mehrfach täglich vorkommt. Wozu die Aufregung?
Der Server-Status 200 rührt daher, dass alle Anfragen, die nicht befriedigt werden können, auf die Haupt-index.php umgelenkt werden.
Das ist allerdings ein großer Fail. Wenn Du einer Ressourcenanforderung keinen Inhalt zuordnen kannst, antworte mit 404 - dafür isses da.
Hello,
Der Server-Status 200 rührt daher, dass alle Anfragen, die nicht befriedigt werden können, auf die Haupt-index.php umgelenkt werden.
Das ist allerdings ein großer Fail. Wenn Du einer Ressourcenanforderung keinen Inhalt zuordnen kannst, antworte mit 404 - dafür isses da.
Nee, da hast Du die Kommunikation (eine Säule des Marketing) im Netz falsch verstanden. Es ist doch ein Inhalt da. Der besteht eben, wenn das angeforderte Dokument nicht auffindbar ist, aus der Startseite der Site. Von dort aus kommt der User dann weiter.
Und außerdem: warum sollte ich dem Bot und seinem Betreiber das Leben leicht machen? Immer wenn der "200" bekommt, fangen bei ihm die Augen an zu leuchten und er schaut (persönlich) nach, ob er mit dem Ergebnis etwas anfangen kann.
Die Muster sollte man sich aber mal merken. Wenn man ein CMS einsetzt, in dem eines der Muster passt, dann sollte man überprüfen, ob die Lücke noch besteht *ohohoh*
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hi,
Der Server-Status 200 rührt daher, dass alle Anfragen, die nicht befriedigt werden können, auf die Haupt-index.php umgelenkt werden.
Das ist allerdings ein großer Fail. Wenn Du einer Ressourcenanforderung keinen Inhalt zuordnen kannst, antworte mit 404 - dafür isses da.
Nee, da hast Du die Kommunikation (eine Säule des Marketing) im Netz falsch verstanden. Es ist doch ein Inhalt da. Der besteht eben, wenn das angeforderte Dokument nicht auffindbar ist, aus der Startseite der Site. Von dort aus kommt der User dann weiter.
Das ist Unfug – insb. auch in Hinsicht auf Suchmaschinen, die so gar nicht feststellen können, dass es einen URL den sie irgendwo aufgeschnappt haben gar nicht gibt.
Eine *vernünftige* Umsetzung wäre eine 404-Seite, die dem menschlichen Besucher das Problem erklärt – und ihm Alternativen anbietet. Das könnten bspw. eine Verlinkung zurück zur Startseite, ein Suchformular, eine Liste ähnlicher Inhalte etc. sein.
MfG ChrisB
Das ist allerdings ein großer Fail. Wenn Du einer Ressourcenanforderung keinen Inhalt zuordnen kannst, antworte mit 404 - dafür isses da.
Nee, da hast Du die Kommunikation (eine Säule des Marketing) im Netz falsch verstanden...
LOL. Lasst uns alle niederknien, Du großer Guru der Säulen des Netzmarketings. Ich schmeiß mich weg!
Hello,
Das ist allerdings ein großer Fail. Wenn Du einer Ressourcenanforderung keinen Inhalt zuordnen kannst, antworte mit 404 - dafür isses da.
Nee, da hast Du die Kommunikation (eine Säule des Marketing) im Netz falsch verstanden...
LOL. Lasst uns alle niederknien, Du großer Guru der Säulen des Netzmarketings.
Ich schmeiß mich weg!
Ja, tu das mal. Aber bitte irgendwohin, wo Du nicht weiter störst. :-)
Wenn der Inhaltsanbieter entscheidet, auf eine nicht direkt auflösbare Anfrage die Startseite seiner Internetpräsentation (oder auch eine Suchhilfe) anzuzeigen, dann ist das mMn vollkommen legitim. Und wenn er etwas anzeigt, ist auch ein Status 200 für das ausgelieferte Dokument gerechtfertigt.
Wie Ihr beiden ja schon richtig bemerkt habt, geht es nicht um "Dateien" sondern um "Ressourcen". Und wie die berechnet werden, ist dem Betreiber der Webseite vollkommen frei überlassen.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hi,
Wenn der Inhaltsanbieter entscheidet, auf eine nicht direkt auflösbare Anfrage die Startseite seiner Internetpräsentation (oder auch eine Suchhilfe) anzuzeigen, dann ist das mMn vollkommen legitim.
full ACK, bis hierher.
Und wenn er etwas anzeigt, ist auch ein Status 200 für das ausgelieferte Dokument gerechtfertigt.
Nein, nicht unbedingt.
Man sollte zwischen dem tatsächlich ausgelieferten Inhalt und dem HTTP-Status unterscheiden. Der Inhalt ist für Menschen gedacht, der Status eher für Maschinen. Wenn du also eine Anfrage nicht unmittelbar bedienen kannst und stattdessen einen Ersatz lieferst, etwa die Startseite der Webpräsenz, ist das IMO akzeptabel (obwohl ein Hinweis angebracht wäre, und ein paar Links auf möglicherweise passende alternative Inhalte). Aber der Status sollte trotzdem 404 sein, denn dem Wunsch nach dem ursprünglich gesuchten Dokument konntest du offensichtlich nicht entsprechen.
Ciao,
Martin
Hello Martin,
Und wenn er etwas anzeigt, ist auch ein Status 200 für das ausgelieferte Dokument gerechtfertigt.
Nein, nicht unbedingt.
Man sollte zwischen dem tatsächlich ausgelieferten Inhalt und dem HTTP-Status unterscheiden. Der Inhalt ist für Menschen gedacht, der Status eher für Maschinen. Wenn du also eine Anfrage nicht unmittelbar bedienen kannst und stattdessen einen Ersatz lieferst, etwa die Startseite der Webpräsenz, ist das IMO akzeptabel (obwohl ein Hinweis angebracht wäre, und ein paar Links auf möglicherweise passende alternative Inhalte). Aber der Status sollte trotzdem 404 sein, denn dem Wunsch nach dem ursprünglich gesuchten Dokument konntest du offensichtlich nicht entsprechen.
Da dürfen wir aber jetzt mindestens zwei Fälle nicht durcheinanderbringen:
Die Ressource hat unter der URi tatsächlich schon existiert
-> Dann sollte man keinen Soft 404 verwenden, sondern besser eine Weiterleitung
auf eine vergleichbar hilfreiche Seite, wie auch immer man das anstellt
Die Ressource hat unter der URi noch nie existiert.
-> Dann ist ein Soft 404 angemessen; die ausgelieferte Ressource kann indiziert
werden und führt bei einer Suche ggf. auch zur Listung
Grundsätzlich sollte man überlegen, ob oder wann man eine veröffentlichte Ressource überhaupt irgendwann wieder aus dem Zugriff entfernt.
Das ist z.B, auch ein Problemchen bei "Gästebüchern" (oder vergleichbaren Listungen), die eine umgekehrte Anzeige, also neusete Einträge oben, über einen paginierten Mechanismus bereitstellen. Bei den meisten Systemen zeigt so die "Seite 1" dauernd andere Inhalte an, kann also von den Suchmaschinen auch nicht vernünftig indiziert werden.
Aber das ist der Unterschied, zwischen "dynamischen Datenmengen" und "dynamisch wachsenden Datenmengen".
Man muss also mMn etwas genauer darüber nachdenken, bevor man "Blanker Unsinn" blökt.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hi,
Da dürfen wir aber jetzt mindestens zwei Fälle nicht durcheinanderbringen:
- Die Ressource hat unter der URi tatsächlich schon existiert
-> Dann sollte man keinen Soft 404 verwenden, sondern besser eine Weiterleitung
auf eine vergleichbar hilfreiche Seite, wie auch immer man das anstellt
Wenn es den oder einen vergleichbaren Inhalt unter einem neuen URL gibt – 301.
Wenn nicht – 410 Gone, hilfreiche Informationen (welcher Art auch immer) für den menschlichen Nutzer.
- Die Ressource hat unter der URi noch nie existiert.
-> Dann ist ein Soft 404 angemessen; die ausgelieferte Ressource kann indiziert
werden und führt bei einer Suche ggf. auch zur Listung
Mit einem Status 404 wird keine Suchmaschine den Inhalt indizieren – und es wäre auch blödsinng. (Durch das Setzen fehlerhafter Links könnte ich dann Ressourcen auf deiner Seite quasi „erzeugen”, indem ich sie den SuMas vorlege, die sie dann indizieren und anschließend darauf verweisen würden – so das künftig sogar mehr Traffic für diese nicht existierenden Ressourcen entsteht … totaler Humbug.)
Das ist z.B, auch ein Problemchen bei "Gästebüchern" (oder vergleichbaren Listungen), die eine umgekehrte Anzeige, also neusete Einträge oben, über einen paginierten Mechanismus bereitstellen. Bei den meisten Systemen zeigt so die "Seite 1" dauernd andere Inhalte an, kann also von den Suchmaschinen auch nicht vernünftig indiziert werden.
Auch leicht zu lösen: noindex, follow für solche „Übersichtsseiten”, und die eigentlichen Beiträge unter permanenten URLs verfügbar machen.
Man muss also mMn etwas genauer darüber nachdenken, bevor man "Blanker Unsinn" blökt.
Gut, dass du nach deinem geblökten inzwischen wieder etwas zurück ruderst. (Aber noch bist du nicht ganz da, s.o.)
MfG ChrisB
Man muss also mMn etwas genauer darüber nachdenken, bevor man "Blanker Unsinn" blökt.
Gut, dass du nach deinem geblökten inzwischen wieder etwas zurück ruderst. (Aber noch bist du nicht ganz da, s.o.)
Jetzt hast Du ihn erwischt. Da wird nichts mehr kommen.
Hello,
Jetzt hast Du ihn erwischt. Da wird nichts mehr kommen.
*g* netter Versuch. Nimmmal einen Kursus in "wie mobbe ich richtig?"
Ja, ja, die Welt ist böse. Da senden die Leute Status-Codes, die nicht dahin gehören, nur um sich Vorteile zu verschaffen. War aber nett, dass wir mal darüber gesprochen haben :-)
Die Diskussion ist für mich keinesfalls zuende, denn hier beginnt sie doch gerade!
Welche Statuscodes gehören wohin (was ich im Ursprung doch auch nicht anfechte) und was bewirken sie wirklich? Was passiert, wenn man stattdessen andere sendet (DAS ist meine Frage)?
Der Begriff "Soft 404" wurde von mir übrigens mMn noch falsch benutzt, so wie von ca. 55% der Seiten dazu im Web. "Soft-404" ist nach Auskunft der Google-Spezialisten so zu verstehen, dass ein Statuscode ungleich 404 gesendet wird, aber in dem ausgelieferten Dokument dann steht: "tut mir leid ... angeforderte Seite nicht gefunden". Der verbale Inhalt der Seite stellt also den "404" dar.
An den "Spezialisten", der hier die Diskussion auf "500" ausdehnen wollte, sicherlich nicht, weil er Ahnung davon hatte, sondern weil er mitmobben wollte: Ein 500er Fehler ist ein Systemfehler des Servers und sollte daher gar nicht "soft" beantwortet werden können. Das CGI (der API-Handler) sollten davon i. d. R. überhaupt keine Kenntnis erlangen.
Und die 300er kann und sollte man in seiner Applikation oft und bewusst einsetzen, und kann sie nicht einfach durch "200" ersetzen. Die Beiträge der "Spezialisten" hier im Thread zeigen mir eigentlich nur, dass sie sich bisher überhaupt nicht für die Praxis mit der Materie auseinandergetzt haben. Zum Glück ist wenigstens Martin dazu bereit (wie gewohnt *freu*), zu diskutieren und nicht zu mobben :-O
Nun wollen wir doch nochmal die Fallunterscheidungen vorantreiben:
Dass ein User unter einem Link eine spezielle Information erwartet, kann doch an verschiedenen Randbedingungen liegen:
Unter der URi gab es schon einmal eine veröffentlichte Information und die ist
leider verschwunden. In einer Suchmaschine oder sonstigen URi-Sammlungen gibt
es aber noch eine Meta-Information (Link + Description)
Die URi ist "sprechend" und verspricht mehr, als sie halten kann. Woher der User die URi
hat, ist suspekt
Die Webpräsentation selber verweist auf die URi, die ist aber fehlerhaft
???
Welche Gründe könnte es sonst noch geben, dass ein User eine bestimmte URi auswählt, die auf dem Zielsystem nicht direkt beantwortet werden kann, die das Zielsystem aber gerne beantworten würde?
Das zeigt uns aber schon einmal, dass wir im Marketing (hiervon mindestens die Säulen: Kommunikation, Produkt, Expansion) die "Lost-Request"-Behandlung näher betrachten sollten.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Ja, ja, die Welt ist böse. Da senden die Leute Status-Codes, die nicht dahin gehören, nur um sich Vorteile zu verschaffen. War aber nett, dass wir mal darüber gesprochen haben :-)
Mit den falschen Status-Codes handelst Du Dir Nachteile ein. Malcom Becks hat sich die Mühe gemacht, Dir die Zusammenhänge zu erläutern.
Die Diskussion ist für mich keinesfalls zuende, denn hier beginnt sie doch gerade!
Du stehst bei dem Thema auf dem Wissensstand Grundschule - sorry, da diskutiere ich nicht. Lies dich ordentlich ein und stelle _konkrete_ Fragen, dann schauen wir weiter.
Welche Statuscodes gehören wohin (was ich im Ursprung doch auch nicht anfechte) und was bewirken sie wirklich? Was passiert, wenn man stattdessen andere sendet (DAS ist meine Frage)?
Das ist keine konkrete Frage. Lies dich ein und frag konkret nach:
http://de.selfhtml.org/servercgi/server/httpstatuscodes.htm
Der Begriff "Soft 404" wurde von mir übrigens mMn noch falsch benutzt, so wie von ca. 55% der Seiten dazu im Web. "Soft-404" ist nach Auskunft der Google-Spezialisten so zu verstehen, dass ein Statuscode ungleich 404 gesendet wird, aber in dem ausgelieferten Dokument dann steht: "tut mir leid ... angeforderte Seite nicht gefunden". Der verbale Inhalt der Seite stellt also den "404" dar.
Ja, der Begriff ist auch Mist. Sollte besser "Fail 404" lauten. Dann wäre klarer, dass man das tunlichst vermeiden sollte:
https://support.google.com/webmasters/answer/2409443?hl=de
An den "Spezialisten", der hier die Diskussion auf "500" ausdehnen wollte, sicherlich nicht, weil er Ahnung davon hatte, sondern weil er mitmobben wollte...
Nein. Weil er Dir mit dem absurden Beispiel den Unsinn deines Vorgehens aufzeigen wollte.
Und die 300er kann und sollte man in seiner Applikation oft und bewusst einsetzen, und kann sie nicht einfach durch "200" ersetzen. Die Beiträge der "Spezialisten" hier im Thread zeigen mir eigentlich nur, dass sie sich bisher überhaupt nicht für die Praxis mit der Materie auseinandergetzt haben.
Oh, doch - ausgiebig sogar. Warum ich Dir mein Wissen bislang vorenthalten habe? Deine dümmliche Antwort auf meinen gut gemeinten Hinweis! Du und Hotti seid da beide Vorreiter: Keine Ahnung, aber gaaanz dicke Hose.
- Unter der URi gab es schon einmal eine veröffentlichte Information und die ist
leider verschwunden. In einer Suchmaschine oder sonstigen URi-Sammlungen gibt
es aber noch eine Meta-Information (Link + Description)
Wenn Du zu der Ressourcenanforderung den passenden Ersatz "weißt": 302, andernfalls: 404.
- Die URi ist "sprechend" und verspricht mehr, als sie halten kann. Woher der User die URi
hat, ist suspekt
Häh? Völlig egal wie sprechend und/oder suspekt, Du musst die Ressourcenanforderung auf Deiner Datenbasis beurteilen und beantworten.
- Die Webpräsentation selber verweist auf die URi, die ist aber fehlerhaft
404
Welche Gründe könnte es sonst noch geben, dass ein User eine bestimmte URi auswählt, die auf dem Zielsystem nicht direkt beantwortet werden kann, die das Zielsystem aber gerne beantworten würde?
Vertipper... unzählig viele... am Ende meines Postings nenne ich dir noch einen spannenden, der dich womöglich erhellen wird.
Das zeigt uns aber schon einmal, dass wir im Marketing (hiervon mindestens die Säulen: Kommunikation, Produkt, Expansion) die "Lost-Request"-Behandlung näher betrachten sollten.
OMG, bla bla! Nur soviel: Zum Marketing im Web gehört SEO. Aus SEO-Sicht ist Dein "200er mit Startseiteninhalt" statt dem eigentlich angebrachten 404 eine Katastrophe. So, jetzt zur angekündigten Erhellung:
Stell Dir mal vor, wir beide betreuen einen Shop für z.B. Damenschuhe und streiten uns um das bessere Google-Ranking. Nachdem ich nun Kenntnis von Deiner supercoolen "200er mit Startseiteninhalt"-Strategie erhalten habe, kann ich Dir nun sehr einfach sehr weh tun: Ich spamme das Netz (und damit die Sumas) mit (eigentlich bei dir nicht existenten) Links voll. Ergebnis: Unendlich viel Duplicate-Content bei Dir.
Wenn Du zu der Ressourcenanforderung den passenden Ersatz "weißt": 302, andernfalls: 404.
301 natürlich. My fail.
Hello,
Wenn Du zu der Ressourcenanforderung den passenden Ersatz "weißt": 302, andernfalls: 404.
301 natürlich. My fail.
Woher will denn ein User wissen, welchen Inhalt eine Ressource haben soll, wenn er sich die URi gerade ausgedacht hat?
Ein Fallback auf die Startseite der zugehörigen Domain ist dann durchaus legitim und liegt im Interesse des Webseitenanbieters.
404 ist nur dann angebracht, wenn man zu einem dediziert angeforderten Inhalt (der quasi versprochen wurde, z. B. in einem Teaser) keine Antwort (mehr) geben möchte.
Die mMn idealste Antwort wäre die Auslieferung einer Suchseite zur Domain, in der der User dann sein Anliegen strukturiert formulieren kann und ggf. auch eine Antwort findet.
Aber stumpf zu behaupten, dass man auf die Frage des Users keine Antwort geben kann, ist mMn nicht die Universallösung.
Auf 303 und als Ziel eine Suchseite würde ich mich ggf. auch noch einlassen... Das würde auch andere Problemchen lösen helfen (Repost), wenn der Browser des Users mitspielt.
301 würde bedeuten, dass es eine dirkete Antwort gibt, die aber umgezogen ist.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hello,
Woher will denn ein User wissen, welchen Inhalt eine Ressource haben soll, wenn er sich die URi gerade ausgedacht hat?
Ich habe das Spiel gerade mal bei ein paar namhaften Seiten durchgeführt. Da nutzt kaum einer die Möglichkeiten, die darin stecken. Aber an anderer Stelle werden von den Unternehmen Millionen für die Marktforschung ausgegeben, hier könnten sie viele Anregungen nahzu kostenlos ernten.
Beispiel:
ist mMn eine aussagefähige Frage an den Konzern BMW. Leider lässt er mich auf einer 404 verhungern. Technisch in Ordnung (das habe ich ja nie angezhweifelt), aber von der Marketing-Seite betrachtet, absolut daneben.
Der nicht auflösbare Teil des Requests gehört durch die (interne) Suchmaschine gejagt und sollte dann zu Vorschlägen führen. Außerdem sollte dieser Requestanteil auf einem "Human Desk" landen, also ausgewertet werden. Solche Anfragen sind für Unternehmen bares Geld wert!
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
હેલો
Ich habe das Spiel gerade mal bei ein paar namhaften Seiten durchgeführt.
Hattest du nicht mal schwierigkeiten mit Dubiosen Geschäftsleuten, die Dubiose Geschäfte betrieben haben, auf kosten anderer? Warum glaubst du, ist das hier anders? Leiter[A] hat Budget[XY] zur Verfügung und soll sich um die Seite kümmern. Der sucht sich einen netten Bekannten, der das alles regelt und sogar ein „Danke schön“ springen lässt. Sobald die Ocken erstmal geflossen sind, ist, was hinten raus kommt, scheiss egal ... das spielchen geht von ganz weit unten bis ganz weit oben und in praktisch jeder Branche.
બાય
Om nah hoo pez nyeetz, Tom!
Das ist ein schlechtes Beispiel für eine 404. Auf einem Smartphone bekommt man eine andere 404. „Diese Seite steht nicht für Mobiltelefone zur Verfügung.“ oder so ähnlich mit einer Auswahl, was man so tun sollte.
Ich stimme zu, dass man seine Gäste nicht mit einer solchen 404 abspeisen sollte. Auch eine 404 sollte keine Sackgasse sein. Man darf dabei ruhig auch den Weg gehen, den du gehst. Aber eben mMn. nicht eine auf die fehlerhafte url zugeschnittene Startseite sondern eine auf die fehlerhafte url zugeschnittene 404-Fehlerseite. Die darf ruhig auch wie eine ordentliche Seite aussehen.
Matthias
Hi,
Der nicht auflösbare Teil des Requests gehört durch die (interne) Suchmaschine gejagt und sollte dann zu Vorschlägen führen.
Das habe ich doch von Anfang an vorgeschlagen.
MfG ChrisB
Hello,
Der nicht auflösbare Teil des Requests gehört durch die (interne) Suchmaschine gejagt und sollte dann zu Vorschlägen führen.
Das habe ich doch von Anfang an vorgeschlagen.
Daran erkennt man (tm) jetzt wieder, wie wichtig die Diskussion hier im Forum ist :-)
Dann sind wir uns jetzt zumindest (teilweise) einig und ich kann meinen Handlungsbedarf daraus ableiten.
Wie ich die bösen Bots nun aber verarschen kann, weiß ich immer noch nicht, mit Ausnahme der Idee von Fastix. Und da gab es eine Bemerkung, die mich in Zusammenhang damit darauf gebracht hat: wenn eine passwd gesucht wird, sollte man eine liefern *gg*
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
હેલો
Wie ich die bösen Bots nun aber verarschen kann, weiß ich immer noch nicht
Brauchst du ja nicht. Ich habe derzeit zugriff auf die Statisktiken von 5 kleinen Webseiten, auf allen habe ich den ganzen tag völlig absurde 404er, sogar wiederholt von den selben Bots.
/seite/sonstwas"
Ich weiss nicht, warum diese dummen bots die anführungszeichen hinten dranhängen, dass habe ich aber auf allen Seiten, täglich duzend bis hundertfach. Immer das gleiche Schema. Angriffsversuche gibt es auch, oft mit Paramtern, aber wen juckt's? Die kommen nicht durch, Punkt.
Abgesehen davon, täglich hecken hacker neue Pläne aus, uns in irgendeiner weise an die Wäsche zu gehen. Glaubst du ernsthaft, dass du auch nur auf einen bruchteil davon reagieren kannst? Es sind schon jetzt unzählige, und werden täglich mehr. Das wird „Die unendliche verarsche“ ;)
બાય
404 ist nur dann angebracht, wenn man zu einem dediziert angeforderten Inhalt (der quasi versprochen wurde, z. B. in einem Teaser) keine Antwort (mehr) geben möchte.
404 ist angebracht wenn die angefragte Resource nie existiert hat (oder schon einen sehr langen Zeitraum nicht mehr existiert*).
410 ist angebracht, wenn die Resource existiert hatte, nun aber nicht mehr.
301, wenn die Resource nur noch über eine neue URI zu finden ist.
302/307, wenn sie vorübergehend woanders zufinden ist.
303, alles ist gut, nun geh "da" hin.
Die mMn idealste Antwort wäre die Auslieferung einer Suchseite zur Domain, in der der User dann sein Anliegen strukturiert formulieren kann und ggf. auch eine Antwort findet.
Aber stumpf zu behaupten, dass man auf die Frage des Users keine Antwort geben kann, ist mMn nicht die Universallösung.
Bei 4XX-Statuscodes kannst du natürlich auch die Startseite anzeigen lassen (rein vom HTML her) oder eine Suchseite (eventuell mit potentiellen Ergebnissen), die URI wird aber nicht von irgendwelchen Crawlern indiziert und der Benutzer hat trotzdem noch ein relativ brauchbares Ergebnis.
Wann ist ein Soft 404 legitim, wann kontraproduktiv? [Frage aus dem einen Betreff]
MMn. ist ein "Soft 404" niemals legitim. Begründung s.o.
MfG
bubble
Hi,
Bei 4XX-Statuscodes kannst du natürlich auch die Startseite anzeigen lassen (rein vom HTML her) oder eine Suchseite (eventuell mit potentiellen Ergebnissen), die URI wird aber nicht von irgendwelchen Crawlern indiziert und der Benutzer hat trotzdem noch ein relativ brauchbares Ergebnis.
Wenn es einfach nur *kommentarlos* die Startseite(ninhalte) sind, dann hat der Nutzer kein wirklich brauchbares Ergebnis – er ist in erster Linie frustriert, weil seine *Erwartung* nicht erfüllt wurde; die Erwartung geschürt durch was/wen auch immer (externer Link mit bestimmtem Titel/in bestimmtem Kontext, Suchergebnis, …)
Der Hinweis, dass der angeforderte Inhalt nicht (mehr) verfügbar ist/nicht gefunden werden konnte, ist m.E. unabdinglich.
MfG ChrisB
Hello,
Der Hinweis, dass der angeforderte Inhalt nicht (mehr) verfügbar ist/nicht gefunden werden konnte, ist m.E. unabdinglich.
Das wäre aber ein sogenannter "Soft 404" laut Spezialisten von Google, den sie gar nicht gerne sehen. Sie sehen lieber einen Fallback auf die Startseite. Der User denkt dann angeblich, dass die Inhalte eben noch nicht funktionieren, was ja auch stimmt. Google schmeißt den Link (wenn er auf der Webseite selber steht) nict aus dem Index raus, gibt ihm aber auch keine Punkte.
Andere Suchmaschinen mögen ähnlich reagieren, das weiß ich nicht.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Der Hinweis, dass der angeforderte Inhalt nicht (mehr) verfügbar ist/nicht gefunden werden konnte, ist m.E. unabdinglich.
Das wäre aber ein sogenannter "Soft 404" laut Spezialisten von Google, […]
Nur mit 200 als Status-Code.
Bei 4XX-Statuscodes kannst du natürlich auch […]
Und damit ist es keiner mehr.
MfG
bubble
Hello,
Der Hinweis, dass der angeforderte Inhalt nicht (mehr) verfügbar ist/nicht gefunden werden konnte, ist m.E. unabdinglich.
Das wäre aber ein sogenannter "Soft 404" laut Spezialisten von Google, […]
Nur mit 200 als Status-Code.
Ja, hab ich inzwischen nachvollziehen können.
Allerdings sehen die lieber einen 200 auf eine aussagefähige Seite, zur Not die Startseite, als einen 200 auf eine "404-Seite" (vom Inhalt her). Am liebsten sehen sie eine Altenativseite- Welcher Status dafür aber nun (nach den offentichtlich gewordenen Eingriffen von "Diensten" ind das Netz) zutrifft, ist mir noch nicht klar. Der müsste zum Ausdruck bringen:
Jedenfalls scheint das WWW noch Entwicklungsbedarf zu haben. Es funktioniert nichts mehr wirklich so, wie ursprünglich geplant.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
MMn. bringst du Mensch und Maschine durcheinander.
- angeforderte Ressource ist nicht vorbereitet und wurde daher bisher auch nicht veröffentlicht
Sprich bis dato existierte die Resource nicht -> 404
- eine Ressource, die Ihnen weiterhelfen könnte ist eventuell: ...
Ist was für den Menschen -> Response-Body
- eine Ressource, die Ihre Anforderungen mit useren Möglichkeiten abgegleichen hat
lieferte folgende Altenativen...
Ist was für den Menschen -> Response-Body
Eine Ressource kann ja für einen Außenstehenden nur ein paar Zustände haben:
Das ist natürlich pauschalisiert, aber auf Ausnahmen kann man in einer allgemeinen Diskussion nicht eingehen, es seiden wir wollen in 40 Jahren noch an dem Thema hängen, wobei sich dann die Standards auch wieder zig mal geändert haben ;)
- angeforderte Ressource ist nicht vorbereitet und wurde daher bisher auch nicht veröffentlicht
Hier drauf möchte ich aber doch noch mal näher nachfragen. Wenn die Resource noch nicht veröffentlicht wurde, gibt es nicht viele Möglichkeiten, was sein kann:
a) Sie wurde unter einer URI angekündigt, ist aber noch nicht da -> falsche herangehensweise meiner Meinung nach
b) Sie wurde erraten -> Zufälle deren wahrscheinliches Auftreten so gering sind sollte man nicht berücksichtigen.
c) Links sind vorhanden und die Resource wird gerade hinzugefügt, ist aber in exakt diesem Moment noch nicht vorhanden -> siehe a)
Jedenfalls scheint das WWW noch Entwicklungsbedarf zu haben. Es funktioniert nichts mehr wirklich so, wie ursprünglich geplant.
Stimme ich dir zu; Standards haben immer Entwicklungsbedarf weil sich mit der Zeit auch die Technik und somit die Möglichkeiten ändern.
Man darf es mit dem SEO halt nicht übertreiben ;)
MfG
bubble
Hello,
Eine Ressource kann ja für einen Außenstehenden nur ein paar Zustände haben:
- nicht existent -> 404
- existent -> 200/303 (und andere)
- momentan woanders -> 302/307
- für immer woanders -> 301/308 (ist 308 eigentlich noch experimentell?)
- nicht mehr existent -> 410
Ich halte es da mit Heinz Rudolph Kunze:
Eigene Wege kann man nicht beschreiben, sie entstehn ja erst beim Gehn.
Und genauso verhält sich das mit "Ressourcen". Die entstehen erst im Moment der Response. Und wie ein Webseitenbetreiber die zusammenstellt, ist einzig und alleine seine Sache :-)
Man spricht ja im Internet nicht umsonst von Ressourcen und nicht von Dateien. Ein Request kann also, wenn der Betreiber das will, immer beantwortet werden, wenn er ihn erreicht. Und da Antworten durchaus dynamisch sein dürfen, können die auch jedes Mal anders aussehen.
Das hat auch nichts mit der urprünglichen technischen Festlegung für HTTP-Status-Codes zu tun. Man müsste mal ermitteln, wie lange es die überhaupt schon gibt.
Und was hier im Thread sonst noch geschrieben wurde, ist durchaus zu berücksichtigen; es gibt da aber wohl nicht nur eine Wahrheit...
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Bei 4XX-Statuscodes kannst du natürlich auch die Startseite anzeigen lassen (rein vom HTML her) oder eine Suchseite (eventuell mit potentiellen Ergebnissen), die URI wird aber nicht von irgendwelchen Crawlern indiziert und der Benutzer hat trotzdem noch ein relativ brauchbares Ergebnis.
Wenn es einfach nur *kommentarlos* die Startseite(ninhalte) sind, dann hat der Nutzer kein wirklich brauchbares Ergebnis – er ist in erster Linie frustriert, weil seine *Erwartung* nicht erfüllt wurde; die Erwartung geschürt durch was/wen auch immer (externer Link mit bestimmtem Titel/in bestimmtem Kontext, Suchergebnis, …)
Das mit der Startseite war eher eine Aussage, dass man das trotz 404 machen kann, technisch betrachtet.
Der Hinweis, dass der angeforderte Inhalt nicht (mehr) verfügbar ist/nicht gefunden werden konnte, ist m.E. unabdinglich.
Da stimm ich dir voll und ganz zu.
MfG
bubble
Hello,
Wenn Du zu der Ressourcenanforderung den passenden Ersatz "weißt": 302, andernfalls: 404.
301 natürlich. My fail.
Woher will denn ein User wissen, welchen Inhalt eine Ressource haben soll, wenn er sich die URi gerade ausgedacht hat?
Da steht "Wenn Du zu der Ressourcenanforderung den passenden Ersatz weißt". Da steht "Du". Oh mann....
Lieber Tom,
Da dürfen wir aber jetzt mindestens zwei Fälle nicht durcheinanderbringen:
- Die Ressource hat unter der URi tatsächlich schon existiert
-> Dann sollte man keinen Soft 404 verwenden, sondern besser eine Weiterleitung
auf eine vergleichbar hilfreiche Seite, wie auch immer man das anstellt
mit entsprechendem HTTP-Statuscode, ja, also entweder 301 oder 308.
- Die Ressource hat unter der URi noch nie existiert.
-> Dann ist ein Soft 404 angemessen; die ausgelieferte Ressource kann indiziert
werden und führt bei einer Suche ggf. auch zur Listung
Wiebitte? Wenn 404 als Antwortheader kommt, wieso sollte dann bei einer Suche zu dieser URL eine Ressource gefunden werden können? Die war doch gerade eben noch nicht auffindbar (daher 404)! Oder habe ich das eben falsch verstanden?
Grundsätzlich sollte man überlegen, ob oder wann man eine veröffentlichte Ressource überhaupt irgendwann wieder aus dem Zugriff entfernt.
Es ist völlig egal, was man bezüglich Zugriffen plant. Aus technischer Sicht sollten Requests mit einem wirklich passenden HTTP-Statuscode ausgeliefert werden.
Das ist z.B, auch ein Problemchen bei "Gästebüchern" (oder vergleichbaren Listungen), die eine umgekehrte Anzeige, also neusete Einträge oben, über einen paginierten Mechanismus bereitstellen. Bei den meisten Systemen zeigt so die "Seite 1" dauernd andere Inhalte an,
Aus meiner Sicht sind solche Gästebücher "broken by design", also sprichwörtlich kaputt.
kann also von den Suchmaschinen auch nicht vernünftig indiziert werden.
Das ist eine logische Folge bei kaputten Seiten.
Aber das ist der Unterschied, zwischen "dynamischen Datenmengen" und "dynamisch wachsenden Datenmengen".
Wieso muss das so sein? Kann man sich keine Parameter überlegen, die eine wirklich eindeutige Indizierung möglich machen? Dass die Einstiegsseite bei Blog oder GB jeweils neue Inhalte liefert, ist offensichtlich, da sie einen Portal-Charakter hat. Aber die dort
angebrachten Links auf "Folgeseiten" sollten einem Schema folgen, welches auch später noch "nach der Archivierung" greift!
Liebe Grüße,
Felix Riesterer.
Man muss also mMn etwas genauer darüber nachdenken, bevor man "Blanker Unsinn" blökt.
Das war in dem Fall überflüsssig. Deine Ausführungen waren hanebüchen genug für das gewählte Etikett.
Mahlzeit,
Und wenn er etwas anzeigt, ist auch ein Status 200 für das ausgelieferte Dokument gerechtfertigt.
Also lieferst du statt nem 500er auch nen 200er aus, weil ja was angezeigt wird? ja, das ist Bullshit, nichts anderes.
Also lieferst du statt nem 500er auch nen 200er aus, weil ja was angezeigt wird? ja, das ist Bullshit, nichts anderes.
Es ist doch der Client schuld daran, also sollte es doch auch ein Status-Code aus der 400er Reihe sein, kein 500er, oder?
MfG
bubble
હેલો
Wenn der Inhaltsanbieter entscheidet, auf eine nicht direkt auflösbare Anfrage die Startseite seiner Internetpräsentation (oder auch eine Suchhilfe) anzuzeigen, dann ist das mMn vollkommen legitim. Und wenn er etwas anzeigt, ist auch ein Status 200 für das ausgelieferte Dokument gerechtfertigt.
Wenn aber bspw. Suchbot[XY] eine URL im Index hat, die falsch ist, warum soll diese weiterhin im Index bleiben? Die URL ist ja für niemanden Zielführend, weder für Suchbot, noch dem Nutzer der Suchmaschine, nicht mal für dich. Ich find das immer zum kotzen,. wenn ich irgendwo einen Link klicke, einen bestimmten Inhalt erwarte und dann auf die Startseite geleitet werde. So eine Seite verlasse ich min. so schnell, wie mich das ding zur Startseite leitet * ;)
બાય
* z.Z.
Hi,
Wenn aber bspw. Suchbot[XY] eine URL im Index hat, die falsch ist, warum soll diese weiterhin im Index bleiben? Die URL ist ja für niemanden Zielführend, weder für Suchbot, noch dem Nutzer der Suchmaschine, nicht mal für dich. Ich find das immer zum kotzen,. wenn ich irgendwo einen Link klicke, einen bestimmten Inhalt erwarte und dann auf die Startseite geleitet werde. So eine Seite verlasse ich min. so schnell, wie mich das ding zur Startseite leitet
Natürlich.
Aber es gibt umnachtete Zeitgenossen, die Besucher für „verloren” halten, wenn sie sie in solch einem Fall nicht auf ihre kostbare Startseite umleiten …
Der Besucher geht i.a.R. nicht „verloren”, wenn man ihn auf den Fehler (der nicht seiner sein muss) freundlich hinweist, und ihm thematisch passende Alternativen vorschlägt, oder eine (automatische) Suche nach dem gewünschten Inhalt durchführt und mögliche Treffer schön übersichtlich präsentiert.
MfG ChrisB
હેલો
Der Besucher geht i.a.R. nicht „verloren”, wenn man ihn auf den Fehler (der nicht seiner sein muss) freundlich hinweist,
Ganz im gegenteil, User freut sich, wenn er auf verständliche Weise darauf hingewiesen wird, dass die gewünschte URL bspw. nicht existiert, oder dass die Seite ersatzlos gelöscht wurde, statt stumpf irgendwohin umzuleiten.
Das ist manchmal so ätzend ... ich suche was, klicke Link in Suchmaschine, lande irgendwo, werde, warum auch immer, 2 mal redirected, bekomme hinweis, gleich weitergeleitet zu werden, lande dann im nirgendwo und hab in der zwischenzeit völlig vergessen, wonach ich überhaupt gesucht hab?
und ihm thematisch passende Alternativen vorschlägt, oder eine (automatische) Suche nach dem gewünschten Inhalt durchführt und mögliche Treffer schön übersichtlich präsentiert.
Das wär dann das Sahnetüpfelchen ;)
બાય
Das ist manchmal so ätzend ... ich suche was, klicke Link in Suchmaschine, lande irgendwo, werde, warum auch immer, 2 mal redirected, bekomme hinweis, gleich weitergeleitet zu werden, lande dann im nirgendwo und hab in der zwischenzeit völlig vergessen, wonach ich überhaupt gesucht hab?
Du hast vergessen, dass man dann auch noch auf solchen Vergleichsseiten landet, wie idealo.de oder preisvergleich.de, die die Links zur Verfügung stellen die du gerade eben in den Ergebnissen deiner Suchmaschine gekonnt ignoriert hast.
MfG
bubble
હેલો
Du hast vergessen, dass man dann auch noch auf solchen Vergleichsseiten landet, wie idealo.de oder preisvergleich.de, die die Links zur Verfügung stellen die du gerade eben in den Ergebnissen deiner Suchmaschine gekonnt ignoriert hast.
Das kommt erschwerend hinzu ...
બાય
Hello Chris,
Aber es gibt umnachtete Zeitgenossen, die Besucher für „verloren” halten, wenn sie sie in solch einem Fall nicht auf ihre kostbare Startseite umleiten …
Der echte Besucher fühlt sich ggf. wirklich genervt, wenn er in einer Suchmaschine hunderte von Links mit aussagefähiger Description findet, die immer nur auf die Startseite einer Webpräsenz führen. Das finde ich pesönlich aber immer noch besser, als eine Seite, aud er nur steht "tut uns leid, gesuchter Inhalt wurde nicht gefunden (200)".
Auch wenn diese Seite mit "404" gekennzeichnet wurde, verschwindet sie nicht (automatisch) aus Katalogen, Gästebüchern und sonstigen Verweisen. Das Web besteht ja zum Glück noch aus mehr, als nur Suchmaschinen und der NSA.
-----
Dieser Thread zeigt mir, dass ich als Fragesteller von den meisten der (selbsternannten) Profis keine durchdachte Antwort erhalte. Schade eigentlich.
forum.de.selfhtml.org sollte doch nach meinem Wissensstand ein Diskussionsforum für Gedanken aus dem Webumfeld sein, und keine Plattform für psychopathische Menschenhasser.
In einer Diskussion kann/sollte jeder Teilnehmer selbstverständlich auch seine Eintrittsmeinung ändern können. Dazu gehören aber Diskussionspartner, die man achten kann und die diese Achtung den Anderen gegenüber auch selber rüberbringen können.
Ich werde aber wegen euch paar Idioten hier nicht das Handtuch werfen :-O
Es gibt hier zum Glück noch etliche Diskussionspartner, die mich zum Wiederkommen motivieren. Und ja: ich erwarte jetzt eure komplette Mobbingwelle. Mehr habt Ihr doch sowieso nicht drauf.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hi,
Dieser Thread zeigt mir, dass ich als Fragesteller von den meisten der (selbsternannten) Profis keine durchdachte Antwort erhalte. Schade eigentlich.
Du hast bereits durchdachte Antworten erhalten, bist aber nicht bereit, sie zu akzeptieren.
MfG ChrisB
Hello,
Dieser Thread zeigt mir, dass ich als Fragesteller von den meisten der (selbsternannten) Profis keine durchdachte Antwort erhalte. Schade eigentlich.
Du hast bereits durchdachte Antworten erhalten, bist aber nicht bereit, sie zu akzeptieren.
Das ist nicht richtig interpretiert. Ich lese die Antworten und denke darüber nach. Und ich erlaube mir, trotzdem eine eigene Meinung zu behalten, auch wenn die sich durch die Antworten ggf. wandelt. Das sollte doch der Sinn einer Diskussion sein, oder?
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hello Engin,
Wenn der Inhaltsanbieter entscheidet, auf eine nicht direkt auflösbare Anfrage die Startseite seiner Internetpräsentation (oder auch eine Suchhilfe) anzuzeigen, dann ist das mMn vollkommen legitim. Und wenn er etwas anzeigt, ist auch ein Status 200 für das ausgelieferte Dokument gerechtfertigt.
Wenn aber bspw. Suchbot[XY] eine URL im Index hat, die falsch ist, warum soll diese weiterhin im Index bleiben? Die URL ist ja für niemanden zielführend, weder für Suchbot, noch dem Nutzer der Suchmaschine, nicht mal für dich.
Das ist nicht ganz richtig.
Ich find das immer zum kotzen,. wenn ich irgendwo einen Link klicke, einen bestimmten Inhalt erwarte und dann auf die Startseite geleitet werde.
Da fragt man sich, woher der Link den kommt.
Ich habe mir dazu durchaus weiterreichende Gedanken gemacht, die diesen Thread hier allerdings sprengen würden.
Ich werden gerade durch die Lektüre der Ignoranten- und Mobber-Postings in meinem Standpunkt bestärkt, dass ein gehaltvoller (mit einem Content belegter) 200er die passende (wenn auch nicht technisch richtige) Antwort auf die gezeigten Requests sein muss!
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
હેલો
Hello Engin,
Hi Tom,
Das ist nicht ganz richtig.
- Woher hat der User die URi?
- Woher hat die SM die URi?
- Warum steht die URi in einem Kontext, der hier augenscheinlich nicht passt?
- Welche Erkenntnisse kann ich als Webseitenbetreiber aus dem "Lost Request" ziehen?
Ich hatte den Gedankengang nicht ganz zu ende gebracht. Es ist egal, woher die URI kommt, wenn du der SuMa mit 200 Antwortest, geht Bot davon aus, dass die URI korrekt ist. Ist sie ja nicht, daher muss die Antwort an den Bot 404 sein, damit Bot weiss, dass diese URI falsch ist. Das du dem User was anzeigen musst ist klar, die Header sind aber nicht für den User gedacht.
Da fragt man sich, woher der Link den kommt.
Aus einem Forum, wo der Poster versehentlich ein Zeichen zuviel eingefügt hat z. B.. Dieser wird von einem Bot aufgeschnappt und im Index aufgenommen. Wenn Bot disem Link nun folgt und 200 als Antwort bekommt, ist für den Bot die sache geritzt. Unter der URI bekommt man den zum „Kontext“ passenden Inhalt, was aber nicht stimmt.
Ich habe mir dazu durchaus weiterreichende Gedanken gemacht, die diesen Thread hier allerdings sprengen würden.
Du gehst anscheinend nur aus Usersicht an die sache ran, du musst das mal aus der Botsicht betrachten. Bots sind Primitive Subjekte, die gerade mal lesen können. Wenn die auf deiner Startseite landen, und in dieser steht, „fehler aufgetreten“, denken die, dass ist der Content der Seite, weil der header 200, ist „korrekter content“, behauptet.
Ich werden gerade durch die Lektüre der Ignoranten- und Mobber-Postings in meinem Standpunkt bestärkt, dass ein gehaltvoller (mit einem Content belegter) 200er die passende (wenn auch nicht technisch richtige) Antwort auf die gezeigten Requests sein muss!
Technisch gesehen nein (es ist finde ich eine reine frage der Technik), weil bots es nicht verstehen. Aber für die sind die header gedacht. Kaum ein User kann was mit headern anfangen, aber Bots, Browser, Server und co..
બાય
Hello Engin,
Ich hatte den Gedankengang nicht ganz zu ende gebracht. Es ist egal, woher die URI kommt, wenn du der SuMa mit 200 Antwortest, geht Bot davon aus, dass die URI korrekt ist. Ist sie ja nicht, daher muss die Antwort an den Bot 404 sein, damit Bot weiss, dass diese URI falsch ist. Das du dem User was anzeigen musst ist klar, die Header sind aber nicht für den User gedacht.
Dass Ihr mich einfach nicht verstehen wollt *grummel*.
Wenn ich dem (bösen) Bot eine 404 sende, weiß er, dass sein Versuch nicht erfolgreich war und wird diese Möglichkeit aus der Liste der Versuche für meine Domain streichen. Sein Programmierer darf ruhig weiterschlafen und wird von ihm nicht gestört.
Wenn ich dem (bösen) Bot nun aber eine 200 (oder auch 303, 301) sende, dann weckt er seinen Programmierer und teilt ihm mit, dass der sich einen Erfolg anschauen soll, ob man da nicht eindringen kann... Wie weiter vorzugehen ist, kann der Bot i. d. R. noch nicht alleine entscheiden.
Schade, der arme Programmierer kommt jertzt nicht mehr zum Schlafen.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
હેલો
Wenn ich dem (bösen) Bot eine 404 sende, weiß er, dass sein Versuch nicht erfolgreich war und wird diese Möglichkeit aus der Liste der Versuche für meine Domain streichen. Sein Programmierer darf ruhig weiterschlafen und wird von ihm nicht gestört.
Wenn ich dem (bösen) Bot nun aber eine 200 (oder auch 303, 301) sende, dann weckt er seinen Programmierer und teilt ihm mit, dass der sich einen Erfolg anschauen soll, ob man da nicht eindringen kann... Wie weiter vorzugehen ist, kann der Bot i. d. R. noch nicht alleine entscheiden.
Wird wohl so sein.
Schade, der arme Programmierer kommt jertzt nicht mehr zum Schlafen.
Oh, der arme, arme programmierer ;)
Um's mal so auszudrücken: Du machst wegen „dummen“ bots deine Seite für normale Nutzer schwerer zugänglich. In Zeiten, wo wir uns um Barriererefreiheiten in alle richtungen bemühen, ein schuss nach hinten. Und sicherer wird deine Anwendung durch diese maßnahme auch nicht. Lass dich lieber angreifen, schau wie sie es schaffen, und stopf die Lücken wie ein Admin. Bist doch ein Alter Hase, dass müsstest eig. du mir schreiben ;)
બાય*SCNR*
[…] Wie weiter vorzugehen ist, kann der Bot i. d. R. noch nicht alleine entscheiden.
Die /etc/passwd hat ja auch eine Syntax, die man grob identifizieren kann, selbst mit relativ vielen false-positive-Ergebnissen bezweifle ich, dass eine normale Startseite da so oft matcht. [*]
Sprich, den "bösen" Bot zu verarschen bringt dir nicht viel außer mehr Spam in den logs, falsche Indizierung und duplicate content bei den Suchmaschinen.
[*] und selbst, wenn deine "falschen Resourcen" nach dem mismatch immer noch auf der Liste stehen, dann wohl eher ziemlich weit unten.
MfG
bubble
Hi,
Wenn ich dem (bösen) Bot eine 404 sende,
Ja, du hattest den Thread mit dem „Angriffsversuch” eröffnet – aber inzwischen sind wir doch weiter bzw. woanders gelandet.
Wenn ich dem (bösen) Bot nun aber eine 200 (oder auch 303, 301) sende, dann weckt er seinen Programmierer und teilt ihm mit, dass der sich einen Erfolg anschauen soll, ob man da nicht eindringen kann... Wie weiter vorzugehen ist, kann der Bot i. d. R. noch nicht alleine entscheiden.
Schade, der arme Programmierer kommt jertzt nicht mehr zum Schlafen.
Den „bösen” Bot kratzt von allen Beteiligten vermutlich am wenigsten, was und wie du antwortest.
Aber alle anderen (SuMa-Bot, menschlicher Nutzer – und damit abhängig von den Reaktionen ersterer nicht zuletzt deine Seite) können nur verlieren, wenn du es *falsch* machst; und deshalb:
404/410 für nicht (mehr) existente Ressourcen, und alle sind glücklich – der Suchmaschinen-Bot, und der menschliche Nutzer, dem wir ein Dokument mit sinnvollen Informationen und Alternativen liefern.
Und den bösen Bot vergessen wir am besten einfach – den abgesehen von einem Hit in den Logfiles hat der sowieso nichts erreicht. Ihn „bekämpfen” zu wollen ist einfach vergebene Liebesmüh, mit ggf. destruktiven Seiteneffekten.
Böse Bots und Botnetze sind einfach “out there”, und feuern weitestgehend ziellos in alle Richtungen, in der Hoffnung ein angereifbares Opfer zu finden – da kannst und wirst du nichts dran ändern. Einfach nach bestem Wissen und Gewissen keine Angriffsfläche bieten, und ansonsten ignorieren ist m.E. das Beste, was man machen kann.
MfG ChrisB
Hello,
Wenn ich dem (bösen) Bot eine 404 sende,
Ja, du hattest den Thread mit dem „Angriffsversuch” eröffnet – aber inzwischen sind wir doch weiter bzw. woanders gelandet.
Wenn ich dem (bösen) Bot nun aber eine 200 (oder auch 303, 301) sende, dann weckt er seinen Programmierer und teilt ihm mit, dass der sich einen Erfolg anschauen soll, ob man da nicht eindringen kann... Wie weiter vorzugehen ist, kann der Bot i. d. R. noch nicht alleine entscheiden.
Schade, der arme Programmierer kommt jertzt nicht mehr zum Schlafen.
Den „bösen” Bot kratzt von allen Beteiligten vermutlich am wenigsten, was und wie du antwortest.
Aber alle anderen (SuMa-Bot, menschlicher Nutzer – und damit abhängig von den Reaktionen ersterer nicht zuletzt deine Seite) können nur verlieren, wenn du es *falsch* machst; und deshalb:
404/410 für nicht (mehr) existente Ressourcen, und alle sind glücklich – der Suchmaschinen-Bot, und der menschliche Nutzer, dem wir ein Dokument mit sinnvollen Informationen und Alternativen liefern.
Und den bösen Bot vergessen wir am besten einfach – den abgesehen von einem Hit in den Logfiles hat der sowieso nichts erreicht. Ihn „bekämpfen” zu wollen ist einfach vergebene Liebesmüh, mit ggf. destruktiven Seiteneffekten.
Böse Bots und Botnetze sind einfach “out there”, und feuern weitestgehend ziellos in alle Richtungen, in der Hoffnung ein angereifbares Opfer zu finden – da kannst und wirst du nichts dran ändern. Einfach nach bestem Wissen und Gewissen keine Angriffsfläche bieten, und ansonsten ignorieren ist m.E. das Beste, was man machen kann.
Scheint alles in Allem eine fruchtbare Diskussionslösung zu geben.
Wenn so eine Anfrage kommt, in Zukunft
Der böse Bot bekommt so also entweder einer nüchternen 404 oder einen Honeypot, am besten mit Rückkopplung(?) = Umleitung auf seine Requestor-Adresse?
Ach nee, das würde nur die Netze verstopfen :-O
Ok, der Thread war dann doch noch ganz ergiebig. Mam darf eben nur nicht sofort aufgeben ;-)
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hi,
Ich werden gerade durch die Lektüre der Ignoranten- und Mobber-Postings in meinem Standpunkt bestärkt, dass ein gehaltvoller (mit einem Content belegter) 200er die passende (wenn auch nicht technisch richtige) Antwort auf die gezeigten Requests sein muss!
Das zeigt nur mal wieder, wie verbohrt du reagierst, wenn deine fachliche falsche Meinung nicht geteilt wird.
MfG ChrisB
Hi,
heute Nacht ist eine der von mir betreuten Webseiten angegriffen worden. Als vermeintlicher Verursacher konnte
[...]
festgestellt werden. Habe ich da irgend eine Chance, etwas zu tun?
ich fürchte, nein. Was willst du denn tun?
Der Ausschnitt aus dem Access-Log ist unter
http://selfhtml.bitworks.de/angriffsmuster/20140219_0929_access_log.txt
zu sehen.
Da scheint jemand systematisch nacheinander -zig mutmaßlich bekannte Sicherheitslücken abzuklopfen. Wenn die bei dir nicht vorhanden sind, ist das eigentlich nur lästig (im wahrsten Sinn des Wortes), weil jeder Request unnötige Server-Last erzeugt, aber sonst nicht weiter schlimm.
Übrigens lässt mich vor allem der Teil
OrgName: SimpleHelix.com
OrgId: SIMPL-62
Address: 4092 Memorial Pkwy SW
Address: Suite 202
City: Huntsville
StateProv: AL
PostalCode: 35802
Country: US
vermuten, dass es sich um eine Briefkastenfirma handelt, die nur vorgibt, ihren Sitz in den USA zu haben. Denn ein kleines, einstöckiges Gebäude in einer für amerikanische Verhältnisse idyllisch anmutenden Gegend als Firmensitz? Und darin nur eine Suite? Als großes Hosting-Unternehmen, das sie angeblich sind, müssen sie irgendwo ein respektables Rechenzentrum betreiben, und warum sind dann nicht dort auch die Büros? Sehr merkwürdig ...
BTW: kann man hier in [Code]-Blöcken eigentlich auch die Farbe steuern?
Für dich selbst über dein User-Stylesheet. Global, so dass es auch andere so sehen - nein.
Ciao,
Martin
Hallo
Übrigens lässt mich vor allem der Teil
OrgName: SimpleHelix.com
OrgId: SIMPL-62
Address: 4092 Memorial Pkwy SW
Address: Suite 202
City: Huntsville
StateProv: AL
PostalCode: 35802
Country: USvermuten, dass es sich um eine Briefkastenfirma handelt, …
Frag doch mal Wernher *not my departement* von Braun!
Tschö, Auge
Hello,
Hallo
Übrigens lässt mich vor allem der Teil
OrgName: SimpleHelix.com
OrgId: SIMPL-62
Address: 4092 Memorial Pkwy SW
Address: Suite 202
City: Huntsville
StateProv: AL
PostalCode: 35802
Country: USvermuten, dass es sich um eine Briefkastenfirma handelt, …
Frag doch mal Wernher *not my departement* von Braun!
Tja, nmach ich doch glatt.
Wenn ich HIER die Frage an ihn stelle, müsste sie ihn (seine Nachfolger) doch erreichen, oder? Die lesen hier doch sowieso mit *höhöhö*
Ich habe das erstmal zu Strato (Der hoster für die Seite) geschickt mit der Frage, ob sie solchen Sachen nachgehen. Die haben schließlich bessere Möglichkeiten und im Schadensfalle auch immer den Ärger mit ihren Kunden. Da könnten sie ja ggf. interessiert sein daran.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hi,
City: Huntsville
StateProv: AL
Frag doch mal Wernher *not my departement* von Braun!
hat der da mal gelebt? - Tatsächlich.
Naja, der wird mir aber nicht mehr viel erzählen ... ;-)
Ciao,
Martin
Der Ausschnitt aus dem Access-Log ist unter
http://selfhtml.bitworks.de/angriffsmuster/20140219_0929_access_log.txt
Oh! Futter für meinen Honeypot.
Jörg Reinholz
Du solltest dir eventuell mal Syntax-Highlighting zulegen. Für mich war das jetzt zu anstrengend zu lesen (was auch Teilweise an meinen Alkohol-Spiegel momentan liegen mag).
MfG
bubble
Hello Fastix,
Da ist 'was dran!
Ich werde mir Deine Überlegungen mal näher zu Gemüte führen. Honeypot ist mMn auch besser, als "404" ;-))
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hello,
heute Nacht ist eine der von mir betreuten Webseiten angegriffen worden. Als vermeintlicher Verursacher konnte
NetRange: 74.119.232.0 - 74.119.235.255
CIDR: 74.119.232.0/22
OriginAS: AS46506, AS16626
NetName: SIMPLEHELIX
NetHandle: NET-74-119-232-0-1
Parent: NET-74-0-0-0-0
NetType: Direct Allocation
Comment: http://www.simplehelix.comfestgestellt werden. Habe ich da irgend eine Chance, etwas zu tun?
Und das ist dir jetzt tatsächlich das erste Mal passiert!?
So etwas kommt bei meinen Servern 20 - 30 Mal am Tag vor. Überwiegend von IP Adressen in China und Russland. Aber auch von allen möglichen "gekaperten Rechnern" around the world.
Für solche "Versuche" gibt es bspw. fail2ban.
Gruß Gunther
Hello,
heute Nacht ist eine der von mir betreuten Webseiten angegriffen worden. Als vermeintlicher Verursacher konnte
NetRange: 74.119.232.0 - 74.119.235.255
CIDR: 74.119.232.0/22
OriginAS: AS46506, AS16626
NetName: SIMPLEHELIX
NetHandle: NET-74-119-232-0-1
Parent: NET-74-0-0-0-0
NetType: Direct Allocation
Comment: http://www.simplehelix.comfestgestellt werden. Habe ich da irgend eine Chance, etwas zu tun?
Und das ist dir jetzt tatsächlich das erste Mal passiert!?
So etwas kommt bei meinen Servern 20 - 30 Mal am Tag vor. Überwiegend von IP Adressen in China und Russland. Aber auch von allen möglichen "gekaperten Rechnern" around the world.Für solche "Versuche" gibt es bspw. fail2ban.
Ist fail2ban wirklich gegen die gezeigten Versuche wirksam, oder doch eher gegen die (nachfolgend|parallel) erwarteten Anmeldeversuche beim Host?
Ich halte es für nicht sinnvoll, auf das Problem nur "Medizin" zu schütten, ohne dem eigentlichen Szenario weitere Bedeutung beizumessen.
Mir geht es darum:
Unserem Sytem ist hier nichts weiter geschehen, aber ich habe dennoch geschaut, ob nicht einer der Versuche (ggf. in anderem Kontext, den ich hier gewiss nicht veröffentlichen möchte) hätte Erfolg haben können.
Die erfolgreichen Angriffe laufen aber ganz anders. Meine Sammlung hierzu wächst nur noch langsam...
Einige davon habe ich hier in meiner jahrelangen Dummheit ja schon geschildert :-O
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hello,
Für solche "Versuche" gibt es bspw. fail2ban.
Ist fail2ban wirklich gegen die gezeigten Versuche wirksam, oder doch eher gegen die (nachfolgend|parallel) erwarteten Anmeldeversuche beim Host?
Ich halte es für nicht sinnvoll, auf das Problem nur "Medizin" zu schütten, ohne dem eigentlichen Szenario weitere Bedeutung beizumessen.
Mir geht es darum:
- Was kann man gegen solche Angriffe tun? (Auswertung der Angiffe, Prävention)
- Wie kann man solche Angriffe verfolgen? (Verursacher feststellen)
Was willst du denn "gegen solche Angriffe tun"?
Sobald ein Server (egal ob Web, FTP, Mail etc.) übers Netz erreichbar ist, ist er solchen "Angriffen" ausgesetzt.
Als erste und vorrangigste Maßnahme sollte ein Server natürlich "korrekt" konfiguriert sein und auf keinen Fall irgendwelche "Sicherheitslücken" aufweisen.
Das verhindert aber natürlich nicht, dass "die bösen Bots" trotzdem vorbeischauen, um nach solchen zu suchen.
Und ja, mit fail2ban kann man ihnen durchaus "in die Suppe" spucken. Denn anstatt wie in deinem Fall, den Bot in aller Seelenruhe sein komplettes Programm durchprobieren zu lassen, wird er eben nach X Fehlversuchen ausgesperrt.
Die Liste der möglichen "Angriffsversuche" ist dabei relativ umfangreich.
Auf dieser Seite kannst du dir mal einen kleinen Überblick verschaffen: http://www.pontikis.net/blog/fail2ban-install-config-debian-wheezy
Gruß Gunther
Hello,
Was willst du denn "gegen solche Angriffe tun"?
Sind wir uns einig, dass solche Anfragen "Angriffe" sins, also unrechtmäßig?
Dann will ich sie verfolgen (lassen).
Sobald ein Server (egal ob Web, FTP, Mail etc.) übers Netz erreichbar ist, ist er solchen "Angriffen" ausgesetzt.
Das ist mir doch vollkommen klar. Aber in einer so drastischen Form müssten die doch rechtlich verfolgbar sein!
Als erste und vorrangigste Maßnahme sollte ein Server natürlich "korrekt" konfiguriert sein und auf keinen Fall irgendwelche "Sicherheitslücken" aufweisen.
Ist er ja zum Glück (noch).
Und ja, mit fail2ban kann man ihnen durchaus "in die Suppe" spucken. Denn anstatt wie in deinem Fall, den Bot in aller Seelenruhe sein komplettes Programm durchprobieren zu lassen, wird er eben nach X Fehlversuchen ausgesperrt.
Da hast Du mich überzeugt. Ich werde mir fail2ban nochmal genauer ansehen.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
