Beiträge von Synonym

    Glücksrad :) Ich nehme ein N wie natürlich kenne ich das :) Läuft hier auch im TV, Sat1 Gold.

    La Valla find ich halt interessant, weil das so meine Richtung ist, eben wie "Sløborn" und Co. Aber im Vergleich zu anderen eben übertrieben. Gestern hatte ich auch einen anderen, auch spanisch. War genau der Moment, wo ich Deinen Post von gestern Abend las und was passierte, mitten in der Nacht rennt ein Kind auf die Straße und wird überfahren. Keine Ahnung was das genau war, zu viele Namen im Kopf. "Parallelwelten" oder so.

    Ich fand "La Valla" nicht schlecht, ist eine spanische Produktion. Erinnert mich etwas an das von Cura. Ist schon etwas übertrieben. Denen reicht nicht nur ein Virus und eine Pandemie, nein, die brauchen auch gleich noch einen 3. Weltkrieg und Wasserknappheit.

    P.S. Auf ZDF-Neo läuft seit gestern Staffel 2 von "Sløborn", also gestern Episoden 1-3 und heute 4-6.

    Also Google ist echt zum Kotzen. Sorry, ich rege mich nur noch auf. Ich weiß nicht mehr, wie es morgen weitergehen soll, sehe absolut kein Licht am Horizont, mache und investiere dennoch, aber nichts, absolut nichts wird honoriert. Ich brauche noch nicht mal mit meinen Reiseseiten weitermachen, wenn selbst eine kleine Seite mit 42 Seiten nicht funktioniert bzw. Google der Meinung ist, anderes wäre besser.

    Es ist mal wieder Januar. Die Zeit der Geranien-Saison beginnt. Und was ist? Meine wichtigste Seite, die da überhaupt Umsätze macht, ist nicht im Index. Naja, im Index schon, die Site-Abfrage liefert sie, auch mit nagelneuen Texten von den letzten Tagen, aber sie wird zu nicht, und ich meine nichts, gefunden. Und warum schreibe ich so explizit "mal wieder Januar"? Weil die Seite bis zum 23.12. noch auf P2 stand und seit dem 23.12. eben nicht mehr gefunden wird. Genau das gleiche Spiel wie schon 2021 und 2020. In den anderen Jahren kam sie irgendwann im September wieder. Im September, wenn die Saison vorbei ist.

    So, da ist meine Seite, angeblich neu gefunden vor 23 Stunden....

    Neu gefunden kann sie aber eigentlich nicht sein, denn sie war ja immer im Index. Search-Console meldet es auch. Aber egal, neu gefunden, Cache von heute Nacht. Soll mir recht sein, naja, würde die denn zu irgendwas ranken!

    Suche ich nach meinem Titel kommt das. Also 75 Treffer und meiner ist da natürlich nicht dabei:

    Suche ich exakt nach meinem Titel kommt das:

    Suche ich nach einem Textausschnitt, einem alten, der schon Jahre drauf ist, kommt so was da:

    Suche ich nach Text aus den Produkten (ist Affiliate), dann kommen andere Shops, die eben auch den Text haben, aber nur den und nicht alles was ich habe.

    Wenn ich noch mehr von dem Scheiß "abc.xyz.space" oder "abc.xyz.online" oder "xyz.blogspot.com" finde, dann drehe ich durch. Der scheiß rankt, ich bin nicht zu finden.

    Und ja, ich sage der Scheiß rankt. Habe auch ein WP gefunden, das gehackt wurde und Textwüsten drauf hat. Unter anderem auch mit meinen Texten. Sind ja aber auch noch andere Texte drauf, so an die 10.000.... Gestern gesehen, die rankt sogar zu so was wie "wetter 22179 hamburg" direkt hiinter dem Deutschen Wetterdienst!

    So was da rankt auch....

    Ach, ich höre auf, könnte noch ewig weitermachen. Bei einer anderen Unterseite, lang, mit Bildern, umfangreich Text, interne Navi und alles was irgendwie mir machbar ist, nicht im Index. Aber "ARD", die ein Bild auf der Seite haben und einen Satz, der von mir kopiert wurde. Das rankt in den Top10.

    Ach ja, und 50% meiner neuen Texte auf dem Reiseportal sind nun nach 5 Wochen noch immer nicht im Index.

    Kommt mir irgendwie bekannt vor. War gestern beim Steuerberater und nachdem mir das Knie weh tut, musste ich mit Straba und Bus da hin. Also einmal große Rundfahrt durch die Innenstadt und Randgebiete. War da schon ewig nicht mehr, aber was ich so gesehen habe, das war mir auch irgendwie suspekt. Alleinig Mediamarkt, Apollo, Telekom, Kaufhof und so eine exquisite Boutique hatten (sichtbar) Personal an den Türen und jeden geprüft. Bei allen anderen keine Ahnung, da lief einfach jeder so rein, am Eingang war keiner, nur Schilder und Wegweiser.

    ÖPNV ist hier ja 3G, aber auch da, es prüft keiner. Es werden seit der Pandemie noch nicht mal Fahrscheine kontrolliert. War in Bussen vorher ganz einfach. Man musste vorne einsteigen und dem Fahrer das Ticket zeigen. Keines gehabt oder nicht gültig, zack, wieder raus. Jetzt sind immer alle Türen offen und man steigt ein, wo man will. Vorne ist zu, damit der Fahrer geschützt wird.

    Auf dem Rückweg, wollte eigentlich Linie 6, aber die war mir zu weit weg. 250 Meter humpeln oder Linie 214 vor der Tür nehmen. Ok, ich nahm die 214. Dachte auch noch, ist kurz nach 12, die kommt von der Uni, da ist nix los. Also genommen. Nächste Haltestelle, zack, Bus voller Studenten. Keine Ahnung, wo die alle herkamen. Abstand und Co? Nö. Am Bahnhof angekommen war es nicht besser. Voll wie Sardinenbüchse. Da versucht man noch auf Abstand zu gehen, was in der Regel auch ging, dann kommt doch tatsächlich so eine Tussi mit lila Haaren, drängt sich mitten rein, zieht die Maske ab und fängt an eine zu rauchen. Hm, was soll man da noch sagen? Nebenan stänkern zwei Typen rum, jeweils mit ner Wodka-Flasche in der Hand, aber wenigstens Maske. Dann noch zwei andere Frauen, die dann die beiden Männer dumm anmachen. Dann war die Party der Alkoholiker am Bahnhof wieder mal perfekt.

    Das mit "der Grippe" hatte ich vorhin auch gelesen. So wie ich das verstanden habe soll nicht mehr getestet werden, also nicht mehr automatisch, auch nicht bei Personen mit Symptomen. Nur noch dann, wenn sie einen Arzt aufsuchen.

    Also anfangs war es wohl ein Kind

    https://www.rtve.es/noticias/20220…a/2248724.shtml

    und seit heute zwei

    https://www.spiegel.de/panorama/spani…ae-a70f4894a8b8

    Die Frage nach dem "wer schuld ist" ist so eine Sache. Ich denke mal an hier. Die Burg wurde laut Polizei richtig aufgebaut. War ja eine geliehene. Der hat sie an den Sportplatzbetreiber übergeben und der wiederum an den Veranstalter vom Sommercamp. Und einer hat dann, wer auch immer, Mist gebaut. War so ein hohes Ding mit einem "Podest" oben und einer Rutsche runter. Für das Foto standen die 25 Kinder alle oben und das Ding ist einfach umgekippt. Klar, zu viele Kinder und dann auch noch das Gewicht alles auf einer Seite und oben.

    Hat nix mit Spanier zu tun. Hatten wir hier vor 3 Jahren nebenan auf dem Sportplatz als "Sommercamp". Da war aber nix mit Wind, die ist einfach samt den Kindern umgefallen. 1 Toter, 12 verletzte. War so eine Hüpfburg mit Rutsche und so.

    Wobei ich mich bei dem Sportplatz eh langsam frage, was da los ist. Alleine heute flogen da binnen 4 Stunden 2 Hubschrauber vom ADAC an. Der letzte war über eine Stunde dort und ist erst seit ca. 30 Minuten weg. Ist nicht selten hier, aber was muss man da anstellen, damit kein Krankenwagen reicht? Und nein, da ist diesmal kein Fest oder so.

    Edit: Musste eben mal nachlesen, soweit das ohne Abo geht. War damals wohl ein Gruppenfoto, das gemacht werden sollte. 25 Kinder drauf, in bis zu 3,5 Meter Höhe. Zugelassen war die wohl nur für 15 Kinder.

    Ähm ja Gunnar, so weit war ich auch schon ;) Hatte so was aber noch nie, daher die Frage hier. Wie kann man das nachstellen? Also einen Request absetzen, damit mein Apache dann als Request nicht einen normalen Pfad, wie üblich, sondern eine Domain anzeigt. Würde gerne wissen, wie das geht und auch, warum mein Apache da einen Status 200 ausliefert.

    Interessant war auch, geht nun aber nicht mehr, dass ich bei der IP 124.88.55.2 auch bei Baidu gelandet bin. Habe da dann mal nach einer Domain von mir gesucht und auch etliches gefunden. Bestand aber alles nur aus irgendwelchen chinesischen Texten mit meiner URL als Link dazwischen oder irgendwelchen statistischen Daten, bei denen ich kein Wort verstanden habe.

    Habe da seit nun einer Stunde seltsame Zugriffe auf dem Server und frage mich, wie man überhaupt so einen Request hinbekommt und warum mein Server darauf antwortet.... Einer eine Idee?

    185.191.34.215 - - [08/Jan/2022:14:54:07 +0100] "POST /cache.php HTTP/1.1" 404 397 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.157 Safari/537.36" pizzateig.rocks

    185.191.34.215 - - [08/Jan/2022:14:54:07 +0100] "GET / HTTP/1.1" 200 365 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.157 Safari/537.36" pizzateig.rocks

    112.94.252.88 - - [08/Jan/2022:15:26:22 +0100] "GET http://www.wujieliulan.com/ HTTP/1.1" 200 0 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36" http://www.wujieliulan.com

    112.66.107.221 - - [08/Jan/2022:15:26:23 +0100] "GET http://www.soso.com/ HTTP/1.1" 200 365 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36" http://www.soso.com

    124.88.55.2 - - [08/Jan/2022:15:26:24 +0100] "CONNECT http://www.baidu.com:443 HTTP/1.1" 405 408 "-" "PycURL/7.43.0 libcurl/7.47.0 GnuTLS/3.4.10 zlib/1.2.8 libidn/1.32 librtmp/2.3" http://www.baidu.com:443

    117.22.144.197 - - [08/Jan/2022:15:26:25 +0100] "CONNECT cn.bing.com:443 HTTP/1.1" 405 408 "-" "PycURL/7.43.0 libcurl/7.47.0 GnuTLS/3.4.10 zlib/1.2.8 libidn/1.32 librtmp/2.3" cn.bing.com:443

    112.94.252.150 - - [08/Jan/2022:15:26:25 +0100] "GET http://www.minghui.org/ HTTP/1.1" 200 0 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36" http://www.minghui.org

    123.245.24.139 - - [08/Jan/2022:15:26:25 +0100] "GET http://www.epochtimes.com/ HTTP/1.1" 200 365 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36" http://www.epochtimes.com

    123.245.25.83 - - [08/Jan/2022:15:26:26 +0100] "GET http://www.rfa.org/english/ HTTP/1.1" 404 0 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36" http://www.rfa.org

    112.115.192.73 - - [08/Jan/2022:15:26:27 +0100] "CONNECT http://www.so.com:443 HTTP/1.1" 405 408 "-" "PycURL/7.43.0 libcurl/7.47.0 GnuTLS/3.4.10 zlib/1.2.8 libidn/1.32 librtmp/2.3" http://www.so.com:443

    175.184.166.158 - - [08/Jan/2022:15:26:27 +0100] "CONNECT http://www.voanews.com:443 HTTP/1.1" 405 0 "-" "PycURL/7.43.0 libcurl/7.47.0 GnuTLS/3.4.10 zlib/1.2.8 libidn/1.32 librtmp/2.3" http://www.voanews.com:443

    171.37.38.49 - - [08/Jan/2022:15:26:30 +0100] "GET http://dongtaiwang.com/ HTTP/1.1" 200 365 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36" dongtaiwang.com

    Die ersten beiden Zeilen sind einfach. Das ist ein normaler gültiger Fehler. In den Log-Zeilen ist immer hinten der angefragte Host protokolliert und der Port, wenn nicht 80. In Zeile eins und zwei war es also ein Zugriff auf pizzateig.rocks. Das ist meine Domain, aber die ist nicht projektiert und hat auf dem Server keinen eigenen vHost, also alles ok damit. Einmal ein Post an eine nicht existierende Datei und einmal ein Zugriff auf Root.

    Aber wie kommen die anderen Zugriffe zustande?

    Man beachte da mal so was wie "GET http://www.minghui.org/" mit Hostzugriff auf "http://www.minghui.org" in dem Fall Port 80. Hä?

    Ich frage mich nun wirklich, wie man diesen GET schafft, also so ohne Root oder Datei oder Ordner.... Wie kann das denn eine Domain sein?

    ohm je. Da denkt man, man hat seine Ruhe und dann ist da wieder so eine Demo, also Autokorso, in der Straße / Ortsteil. Was die da alles so an Mist von sich lassen und sich auch noch gegenseitig bestätigen und bejubeln.

    Millionen Menschen sind gestorben, wegen der Maßnahmen. Tausende Kinder, wegen der Impfung. Die Impfung hätte kein einziges Menschenleben gerettet, nur genommen.

    Aber schön finde ich, dass die teils mit ihren Firmenfahrzeugen mitfahren. Min zwei können sich nun wohl eine neue Hausveraltung als Auftraggeber suchen, denn die ist alles andere als erfreut, wenn sie das Video sieht. Nicht nur einfach so, was sie auch wäre, sondern weil sie ihren Bruder verloren hat.

    Hätten vor einer Stunde fahren sollen, da war ich einkaufen. Eier, ich habe Eier gekauft!

    Und die ganzen Kinder, die da aus den Schiebedächern schauten... Ist denen nicht kalt? Hier hat es zumindest -4 Grad.

    Hoffentlich ist die Holzknappheit bald vorbei, denen fehlen ein paar Latten.

    Frank-L Durch im Sinne von was genau?

    Meines hier, daher machte ich den Post gestern noch mal, ist nun noch nicht mal 4 Monate alt. Das andere im Flur ca. 1 Jahr. Drinnen sind ja schon die Panasonic Eneloop, also nicht die Hochleistrungsdinger, sondern die mit der hohen Ladeanzahl für schnurlose Telefone.

    Ich raffe es halt nicht. Die Telefone sind auch bei meiner Mutter im Einsatz, da gehen die schon seit 6 Jahren und die behandelt die alles andere als gut. Liegen mal in der Sonne, mal im Frost, mal im Regen, mal auf der Heizung. Und die telefoniert ca. das 20-fache wie ich.

    Komisch hier ist, dass ich letzte Woche noch 3 Stunden am Stück telefonieren konnte. Dachte eigentlich, das geht mitten im Gespräch aus, weil Akku leer, aber nein. Aber eben jetzt wieder, von vorgestern auf gestern. Zack, keine Telefonie möglich.

    Zu harter Schlag. Kann ich eigentlich ausschließen bzw. wüsste ich nicht, wann das passiert sein soll. Das im Flur ist ein Notfalltelefon, das steht eigentlich nur rum. Das Ding wird nicht bewegt, vielleicht 2-3 mal im Jahr telefoniert.

    Aber was kann das denn technisch sein? Auch wenn es ein Schlag ist, was ist da denn dann defekt? Es klingelt ja. Ich kann mit dem Teil machen, was ich will, alles gut. Aus geht es, sobald der Ruf aufgebaut wird. Also Rufannahme, nicht läuten lassen, dann schaltet sich das Gigaset ab.

    Ich kenne die halt auch von meinem alten Arbeitgeber. Da war ich für die Teile und die TK/IT-Technik verantwortlich. Im Einsatz waren ca. 1000 davon. Kaputt gingen die nur im Sinne von: In Kühlflüssigkeit ertrunken, im Öl ersoffen, Metallspäne auf dem Lautsprecher oder Mikrofon, "geschreddert" in der Reinigung-/Schleifanlage.

    Symptome:

    Gigaset klingelt in der Ladeschale ganz normal.

    Gigaset geht bei Rufannahme aus, entweder durch manuelle Annahme oder automatische Annahme.

    Alle anderen Funktionen inkl. Menü, Klingeltöne etc. funktionieren.

    Eingabe einer Rufnummer geht, beim Drücken der grünen Taste für den Rufaufbau geht es aus.

    Die Akkuanzeige springt gerne von "voll" auf "komplett leer". Teilweise lässt es sich danach auch nicht mehr einschalten.

    Sollte der Rufaufbau in seltenen Fällen doch mal funktionieren, so kann man auch längere Gespräche führen.

    In manchen Fällen sucht das Gigaset nach dem Abschalten und neu einschalten die Basis, findet sie aber nicht.

    Ebenfalls selten, dass es bereits beim ersten Klingelton bzw. dem Versuch zu klingeln ausgeht und danach direkt wieder neu startet.

    Super 4 Monate später.... Seit gestern geht gar kein Telefon mehr. Alle klingeln und gehen aus, wenn ich annehmen will. Akkus refreshen? Geht auch nicht, Ladegerät will nicht, sagt nur, die sind voll.

    Tel 1: Akkus raus, Batterien rein oder volle Akkus. Einschalten. Laut Anzeige Akku voll. Basissuche, eine Sekunde, aus.

    Tel 2: Gleiches Spiel. Basissuche. TockTock, Basis gefunden und verbunden. Alles gut. Anruf kommt, klingelt unendlich, wenn ich nix mache. Grüne Taste drücken, zack aus. Akkus noch mal gewechselt, Person zurückgerufen. Klingelt 5 mal an, geht. Person am anderen Ende geht ran, zack, mein Telefon aus.

    Was das an der Fritte sein sollte wüsste ich immer noch nicht bzw. finde ich nix oder Änderungen bringen kein anderes Ergebnis.

    Den Eindruck habe ich schon lange. Da das System aber millionenfach eingesetzt wird, scheint das Problem wohl eher hier bei mir zu suchen sein.

    Habe ja auch schon viel gefunden, aber das hilft alles nicht weiter. Entweder ist das exakt der gleiche Fehler, aber keine Lösung oder es gibt vermeintlich eine Lösung, aber die ist dann mit meiner Version nicht nutzbar.

    Der hier hat z.B. das gleiche Problem mit deutschen Umlauten:

    https://github.com/SpiderLabs/owa…crs/issues/1645

    Eigentlich ging es da erst um russische, da gab es schon vorher eine Bug-Meldung, aber dann kam er mit deutschen Zeichen. Genau das Gleiche habe ich hier, exakt das Gleiche. Auch so wie er beschreibt.

    z.B.

    Message: Warning. Pattern match "\\xbc[^\\xbe>]*[\\xbe>]|<[^\\xbe]*\\xbe" at ARGS:action_name. [file "/usr/share/modsecurity-crs/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf"] [line "546"] [id "941310"] [msg "US-ASCII Malformed Encoding XSS Filter - Attack Detected"] [data "Matched Data: \xbcneburger heide > found within ARGS:action_name: ferienh\xc3\xa4user mit hund l\xc3\xbcneburger heide > urlaub mit hunden"]

    Fehlerhaft und als XSS-Angriff wird hier das \xbc gewertet. Das ist in Kombination mit \xc3, also als \xc3\xbc schlicht ein deutsches "ü" als HEX utf8-kodiert. Mit dem "ä" als "\xc3\xa4" gibt es keine Probleme.

    Der oben im Link hat das selbe Problem mit dem Wort Sitzbezüge, also als "sitzbez\xc3\xbcge". Auch hier wird \xbc falsch erkannt und blockiert.

    Das andere oben mit dem Bild ist wieder was anderes. Hier erkennt eine Rule für "Oracle SQL" einen Angriff. Ich nutze aber gar kein Oracle, also ist das eigentlich schnuppe. Aber selbst wenn, die Zeichenfolge "ora" ist ja nicht selten. Cora, Kora, Nora etc. So noch kein Problem, aber wenn eine Ziffer danach kommt, zack, Erkennung. Also auch bei "Nora-2022", wenn das irgendwo im Text steht.

    Und das mit dem "Turm"! ist ähnlich. Hier ist es eine Erkennung für MSSQL. Habe ich auch nicht in Verwendung. Steht aber irgendwo im Text die Zeichenfolge "!, also kodiert als %22! in einem Link oder JSON-LD oder sonst was, kodiert halt, dann wird gesperrt.

    Dann gibt es da etliche gemeldete XSS-Angriffe. Vieles davon direkt von der Webseite, manches in Formularen, anderes durch Piwik. Ok, bei Piwik habe ich nun eine Mitteilung von 2014 gefunden, dass es mit mod_security nicht kompatibel ist. Ja, von 2014 und es zählt immer noch.

    https://matomo.org/faq/troubleshooting/faq_100/

    Habe ja, wie anfangs gesagt, schon die Rules v3.4.0 getestet. Nun gibt es neue DEV-Rules, die 3.4.2-DEV. In denen ist die Rule für die Umlaute geändert. Die könnte also gehen. Aber, dieses Ruleset 3.4.2 ist für meine Version von mod_secutity nicht kompatibel. Da müsste ich das Modul wechseln, das geht aber auch nicht, weil das neue nicht für Apache 2.4 gedacht ist, sondern für Apache 2.5 bzw. nginx.

    Also ich bin zu doof dazu, raffe es nicht oder das Modul ist wirklich scheiße, dabei soll es das Beste sein.....

    Nächste Sperren, wegen einem BILD!

    src="/bilder/kunden/1872/zusatzbilder/gross/essbereich-bora-1342218555.jpg"

    Hier löst "ora-1342" die Sperre aus, wegen:

    [msg "Oracle SQL Information Leakage"] [data "Matched Data: ora-1342 found within RESPONSE_BODY

    Und nachdem die Rule auf alles reagiert, was "ORA-[0-9][0-9][0-9][0-9]" ist, also ora- + Ziffern, wird das sehr häufig sein. Gibt genug Bezeichnungen und Namen, die mit "ora" enden und dann in der URL ein timestamp, Kundennummer, Objektnummer, Datum oder sonstige Ziffern folgen.

    Muss nun noch mal nachfragen, ob einer die Rule-Sets hat .... Scheint aber nun nicht nur deutsche Umlaute zu betreffen, sondern auch andere Daten.

    Das hier: Der "Turm"! Hundefreundlich und eingezäunt.

    Löst eine Sperre wegen einem angeblichen SQLi-Angriff aus :(

    Genauer gesagt das da:

    [msg "Detects MSSQL code execution and information gathering attempts"] [data "Matched Data: \x22! H found within ARGS

    Also das "! oben im Text. Naja, so sonderlich selten ist die Kombination an Satzzeichen ja nicht wirklich.

    Ausgelöst gleich mehrfach, in:

    /usr/share/modsecurity-crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf

    /usr/share/modsecurity-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf

    /usr/share/modsecurity-crs/rules/RESPONSE-980-CORRELATION.conf

    Dann nimm doch mal bei beiden Mobil-Anbietern den gleichen Zielserver zum Testen, also wie im letzten Bild den "Digimobil Madrid". Und P.S. Orange und Digi sind nicht nur zwei verschiedene Anbieter, das sind zwei verschiedene Netze.

    Hm, also an "Sevilla Orange" liegt es nicht, das kann ich Dir sagen. Ich bekomme da einen Upload von 10,42 Mbps. Nur einen fürchterlichen Ping von 52ms, der ist hier viel besser. Aber ok, "Sevilla" ist auch weit weg.

    So, nächster Versuch, vielleicht weiß ja hier einer was.

    Bing produziert bei mir immer wieder Fehler 403 und das beim Zugriff auf die robots.txt. Diese ist aber vorhanden und freigegeben. So wie es scheint, bin ich nicht alleine damit, aber mal wieder hat keiner eine Lösung dafür.

    Das ist exakt das, was ich auch habe. Nur, dass ich kein mod_security nutze...

    https://webmasters.stackexchange.com/questions/1358…-reject-the-1st

    Dann gibt es noch genug andere Posts aus den Jahren 2015 bis 2019..... Alle ohne Lösung.

    Ergebnis ist hier aber auch entsprechend.

    Code
    40.77.167.102 - - [05/Jan/2022:14:18:45 +0100] "GET /robots.txt HTTP/2.0" 403 386 "-" "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)"
    40.77.167.102 - - [05/Jan/2022:14:18:45 +0100] "GET /robots.txt HTTP/1.1" 200 2416 "-" "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)"
    40.77.167.102 - - [05/Jan/2022:14:18:45 +0100] "GET /robots.txt HTTP/2.0" 200 682 "-" "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)"

    Also drei Abrufe, zeitgleich. Und immer der erste Zugriff davon mit einem 403. Es handelt sich dabei um direkte Zugriffe, also keine Weiterleitungen oder so.

    Habe nun auch schon alles mehrfach durch, also mit SSL und ohne, mit www und ohne. Ich kann das nicht reproduzieren. Andere Logs sagen auch nichts, wie in dem Link oben. Da steht einfach nur immer wieder der 403 im Access-Log und das war alles.

    Das mit der Mutante kam gestern Mittag hier auch schon.

    Wegen den Zahlen. Das ist reine Denkarbeit, dabei muss man noch nicht mal rechnen, daher stehen da auch keine Werte dabei.

    Bild 3 ist, obwohl die Datenpunkte falsch sind, vom Wert her richtig. Warum? Weil der linke Tag ein Einzelwert ist und der rechte Wert ein Summierter. Summierte sind aber immer die Tage links davon, also in dem Fall die drei 0-Werte. Die Summe der ganzen Datenpunkte (rote Punkte) ist aber in Bild 3 gleich, egal wie man die Datenpunkte wichtet.

    Bei Bild 2 ist es anders. Da ist der linke Wert ein Summenwert. In dem Fall von 79.000. Von diesen 79.000 gehört aber ein Teil davon in die linken beiden 0-Werte. Und die rechten drei fehlen komplett, weil die erst am Tag darauf als Summenwert kommen. Bild 4 versucht das aufzutrennen. Die 79.000 werden aufgeteilt in jeweils 24.000 + 24.000 + 31.000, wobei eben die ersten beiden Werte rausfliegen, die gehören nicht in den 14-Tage-Block. An der Stelle werden es als Summe für den ganzen blauen Kasten also 48.000 weniger. Aber, nun kommt rechts. Da fehlt der Summenwert 373.000, dafür gibt es drei mit 0. Diese 373.000 werden daher aufgetreilt in 82.000 + 82.000 + 82.000 + 127.000. Die 127.000 fliegen raus, denn die sind erst der Folgetag bei dem Bild, die drei 82.000 kommen rein. Also Summe für den blauen Kasten +246.000. Ergibt am Ende.... +246.000 (rechts) - 48.000 (links) = +198.000. Heißt, in dem zweiten Bild fehlen (geschätzt) ca. 198.000 Fälle in der Berechnung.

    In Bild 3 sind diese dann sprunghaft enthalten, da die Summenwerte auch die 0-Tage abdecken und diese, in dem Fall, zum 14-Tage-Bereich gehören.

    Natürlich streichen die entsprechend die Tage am Anfang weg. Das hat mit den summierten Werten ja nix zu tun, das ist ein 14-Tage-Zeitfenster, wie die Boxen oben, das ist fest, nicht veränderbar. Wenn ein Wert am Dienstag kommt, dann startet die Berechnung am vorletzten Dienstag. Also 14 Tage. Für einen Freitag am vorletzten Freitag.

    Nimm z.B. den 18.1. Dann ist Startpunkt der 4.1. Das ist der Tag mit den 373.000. Der Wert geht also als erster Wert voll in die Berechnung ein, aber das ist falsch, denn von den 373.000 gehören auch Fälle zum 3.1., 2.1. und 1.1. (die oben fiktiv angenommenen je 82.000), die in den 14-Tage-Block dann nicht mehr gehören.

    Es kommt dann also drauf an, wie die Entwicklung an sich war. Entweder ergibt das dann eine viel zu hohe Inzidenz oder eine zu geringe. Und wirr wird es, weil es diese 0-Tage eben nicht konstant gibt. Sonst könnte man sagen, jeweils am Mittwoch sind die Sprünge bedingt durch die Summenwerte. Aber diese 0-Werte kann es ja als 2er, 3er oder gar 4er-Pack geben. Und da eben auch den Fall, dass links und rechts einer ist.

    Anders gesagt....

    links:

    Hier darf ein Null-Wert sein, aber es muss der erste 0-Wert der 0-Kette sein, denn der Aufbau ist "0-0-Summe"

    oder es muss ein Einzelwert sein

    rechts:

    Hier darf ein Summenwert sein

    Oder es muss ein Einzelwert sein

    Alle Bedingungen (links und rechts) müssen stimmen, nur dann ist das Ergebnis korrekt, weil die Summe aller Datenpunkte gleich ist, egal wie die Werte pro Tag vergeben werden. Trifft eine nicht zu, ergibt das ein falsches Ergebnis.

    Bildlich gesprochen. Ziehe gedanklich um die Null-Werte und den entsprechenden Summenwert eine grüne Box. So, nun müssen diese grünen Boxen entweder komplett in der blauen sein oder komplett außerhalb. Keinesfalls dürfen die sich überlagern.

    Vereinfachtes Beispiel.

    Werte

    10 10 10 10 10 10 10 10 10 10 10 10

    Ziehe gedanklich nun immer eine Box von 4 Tagen. Die Summe wird immer 40 sein.

    0 0 30 10 0 0 30 10 0 0 30 10

    Auch hier wird die Summe immer 40 sein, denn die 0-Werte sind konstant

    0 0 30 0 0 30 10 0 0 0 40 10

    Hier merkt man den Fehler. Es kann bei vier Tagen auch mal als Ergebnis 60 kommen oder 50 oder 40 oder 30 oder 10. Die Gesamtsumme ist in allen Fällen aber gleich, nämlich 120. Und Beispiel 2 funktioniert auch nur, weil die Zahlen konstant sind, also immer von 10 ausgegangen und entsprechend summiert wird. Ändern sich Zahlen aber, fallen oder steigen, dann wären die hier passenden 0-Werte auch falsch, es steigt oder fällt dann sprunghaft.