Beiträge von Synonym

Ehrlich gesagt, keine Ahnung. Ist schon länger. Ob das aber nun 2 Wochen oder 2 Monate sind, keine Ahnung.

Hm, Guppy, ich glaube da reden wir aber aneinander vorbei.

Ich meinte das hier:

"Wenn jemand 100x pro Minute z.B. auf eine Loginseite im Shop per http zugreifen will und dabei PWs austestet"

Das macht der Default-Filter nicht. Der reagiert vielleicht auf Fehler, aber dann auf alle, egal wo und wie die entstehen. Um explizit den Login zu schützen bedarf es einer extra Regel, einem Filter ähnlich dem hier, der auf WP-Fehllogins reagiert.

*** Link veraltet ***

Wobei der aber auch nicht unterscheidet zwischen erfolgreicher Login oder fehlerhaft. Der geht einfach über die Anzahl im Zeitraum.

Ein Fehlerhafter Login in einem PHP-Script schreibt ja selbst keine Meldung ins Error-Log. Das ist für den Apache auch kein Fehler, sondern ein normaler Seitenaufruf bei dem Daten per POST übertragen werden. Die Antwort, also erfolgreich oder nicht, das ist dann ganz normal GET. Das Apache-Modul auth ist da gar nicht beteiligt. Beim Passwortschutz der htaccess allerdings schon, denn hier übernimmt die Authentifizierung der Apache und nicht PHP.

ja. Es lässt sich alles blocken, was in einem Log steht und per Fail2Ban-Filter erkannt wird / werden kann. Wenn Confixx also eine entsprechende Meldung in ein Log schreibt, dann ja. Die Filter sind schon umfangreich vorhanden, können aber auch selbst erstellt werden.

Genau genommen würde sogar ein Dateizugriff zu sperren sein, z.B. Download zu schnell und zu oft. Der Download muss dann halt nur eindeutig im Logfile erkennbar sein und vor allem so sein, dass den ein Filter filtern kann. Also einfach das Access.Log auswerten geht nicht, denn das wären ja alle Dateizugriffe. Aber ein Filter, der genau auf eine Datei achtet, das geht.

guppy
Kommt drauf an, ob der Filter für Apache auch geladen ist. Default ist glaube ich nur SSH. Und wenn der Apache-Filter geladen ist, dann reagiert der auf Fehllogins, aber nur als apache-auth, also Fehllogins über htaccess. Ist das aber ein Loginsystem von PHP, dann steht das nicht im Log.

Fail2Bad kann alles mögliche blockieren, allerdings keine Dateien an sich. Fail2Bad arbeitet mit Logfiles bzw. wertet diese aus. Wenn Du also ein Login-Script hast, dann kannste rein theoretisch bei einem Fehllogin eine Zeile in eine Log schreiben und dieses Log von Fail2Ban überwachen lassen.

Über die Logs und die entsprechende Conf für Fail2Ban (Filter) kannste eigentlich alles abwickeln, auch eine Sperre bei zu vielen 404ern in zu kurzer Zeit.

Die Versionen sind abwärtskompatibel, daher gibt es ja das Deprecated und die schalten so eine Funktion nicht einfach so ab. Ansonsten ist das aber auch verständlich. Würde die alles drinnen lassen, was es jemals gab, dann wäre der Core wohl 3mal so groß und alles gäbe es doppelt und dreifach. Wobei die neuen Funktionen in aller Regel das gleiche können, oft mehr und teils auch deutlich schneller sind.

Zitat

Und warum steht das nicht in der Dokumentation?

Steht doch da, unten in den Beispielen
*** Link veraltet ***

Ansonsten brauchen das alle preg_xxx-Funktionen. Der Pattern wird immer in einen Delimer gesetzt. Das muss kein Slash sein, aber der ist halt üblich.
*** Link veraltet ***

Also mit Explode wird es umfangreicher, da es nur anhand eines Zeichens splittet, Du aber : und , zur Auswahl hast.

Mit preg_split sollte es aber so gehen:

$dp_table = preg_split("/[:,]/", $dp_cost);

Ah, ok, danke. Und an was kann das dann liegen bei mir?

[ATTACH=CONFIG]931[/ATTACH]

Sagt mal, ist das nur bei mir so oder allgemein? Bei mir fehlen bei den "Neuen Beiträgen" die Uhrzeiten hinter dem Datum. Gut, die Zeiten sind da, aber nicht sichtbar, da irgendwie rechts über die Zelle hinaus geschoben.

Die kommen nach oben in die neun grauen Quadrate und dort unter den Punkt "mehr".

Mach das mal grundsätzlich so, denn ein Slash hat in einem Dateinamen auch nichts zu suchen. Woher soll den ein System auch wissen, dass bei "lieferscheine/1/12345" die 1/ kein Verzeichnis sein soll, das lieferscheine/ aber schon

P.S. FPDF ist ne nette Klasse, verwende ich schon immer.

Jo, hier auch. Gestern waren es bei mir im Durchschnitt 78%.

Ja Chris, so kommt mir das vor. Wenn ich jetzt mal bedenke, was ihr da an Zeit investiert habt, vor allem Alex, ich hatte auch drei komplette Tage für den Mist und vorher war es ja schon mal hin und wieder ein anderes Problem mit AOL. Das ist es echt nicht wert.

Das doofe ist halt nur, dass ich das den Kunden und / oder Besuchern bei mir nicht erklären kann.

Aber irgendwas muss AOL da jetzt geändert haben, denn die letzten 10-12 Monate ging es ja, nur seit ca. Montag nicht mehr. Allerdings weiß ich auch, dass es vorher ging und dann 2012 von jetzt auf gleich alle Mails im Spam-Ordner gelandet sind. Da gab es aber eine Lösung für. Allerdings ist diese dubiose, nicht hilfreiche und teils falsche Webmasterhilfe schon seit Jahren so. Da bin ich richtig erstaunt über MS. Da bin ich zwar auf einer Blackliste, aber die sagen wenigstens klar warum.

Also dann mal Danke an euch, dass Ihr es versucht habt. Waren ja durchaus alles brauchbare bzw. denkbare Möglichkeiten

Nun ist das halt ein Thread mehr im Netz, einer mehr von den zig tausenden, die sich mit AOL beschäftigen und letztendlich ohne Lösung enden ... Naja... Muss wohl so sein.

Sagte ich ja, ich hasse AOL. Das ist ein Saftladen hoch 10. Alle anderen Provider können das doch auch, einen vernünftigen Fehlercode zu senden und den dann auch in der Liste zu haben und zu erklären.

Also irgendwie glaube ich nun fast, dass das gar kein Fehler ist, sondern so gewollt. Auf der Web-Oberfläche von AOL gibt es gar keine Option, eine abweichende Antwortadresse auszuwählen.

Nö, bleibt dabei. Abgesehen von gut 150 extra Zeilen an Kommunikation steht exakt die gleiche Fehlermeldung im Log (mit Debug).

Quatsch... Debug hatte nicht funktioniert... Moment.

So, Deinen Vorschlag von oben habe ich nun durch. Hier der Log-Auszug vom Server:

Jan 17 16:16:27 h1666945 postfix/smtpd[584]: connect from localhost.localdomain[127.0.0.1]
Jan 17 16:16:27 h1666945 postfix/smtpd[584]: 475394E40397: client=localhost.localdomain[127.0.0.1]
Jan 17 16:16:27 h1666945 postfix/cleanup[581]: 475394E40397: message-id=<cd5cbb66a68c7c90f3d02036d98e4b84@diego.domain.de>
Jan 17 16:16:27 h1666945 postfix/qmgr[531]: 475394E40397: from=<mail@domain.de>, size=2646, nrcpt=1 (queue active)
Jan 17 16:16:27 h1666945 postfix/smtpd[584]: disconnect from localhost.localdomain[127.0.0.1]
Jan 17 16:16:27 h1666945 amavis[32447]: (32447-05) Passed CLEAN, [85.xxx.xxx.xxx] [85.xxx.xxx.xxx] <mail@domain.de> -> <mail@aol.de>, Message-ID: <cd5cbb66a68c7c90f3d02036d98e4b84@diego.domain.de>, mail_id: p80y7aDgd-ux, Hits: -2.9, size: 2165, queued_as: 475394E40397, 386 ms
Jan 17 16:16:31 h1666945 postfix/smtp[585]: 475394E40397: to=<mail@aol.de>, relay=mailin-03.mx.aol.com[64.12.91.196]:25, delay=2.3, delays=0.22/0.04/0.35/1.7, [COLOR="#B22222"]dsn=5.2.1, status=bounced (host mailin-03.mx.aol.com[64.12.91.196] said: 521 5.2.1 :  AOL will not accept delivery of this message. (in reply to end of DATA command))[/COLOR]
Jan 17 16:16:31 h1666945 postfix/cleanup[581]: 59E9F4E4039A: message-id=<20140117151631.59E9F4E4039A@diego.domain.de>
Jan 17 16:16:32 h1666945 postfix/qmgr[531]: 59E9F4E4039A: from=<>, size=4782, nrcpt=1 (queue active)
Jan 17 16:16:32 h1666945 postfix/bounce[588]: 475394E40397: sender non-delivery notification: 59E9F4E4039A
Jan 17 16:16:32 h1666945 postfix/qmgr[531]: 475394E40397: removed
Jan 17 16:16:32 h1666945 postfix/pipe[590]: 59E9F4E4039A: to=<mail@domain.de>, relay=dovecot, delay=1.1, delays=0.69/0.01/0/0.41, dsn=2.0.0, status=sent (delivered via dovecot service)
Jan 17 16:16:32 h1666945 postfix/qmgr[531]: 59E9F4E4039A: removed

Ist komplett identisch wie vorher.

Nee, ist hier nicht immer so, nur bei AOL.

Ach ja... Die SMTP-Fehler-Hilfe habe ich schon mehrfach durch. Die habe ich sogar als Bookmark, weil da öfters mal was ist. Und genau das ist eben das Problem, dass es dort weder die Meldung "AOL will not accept delivery of this message.", noch "521" oder "5.2.1" gibt.

Und unten auf der Seite, die drei URLs zu "Verifying DNS conformance" habe ich natürlich auch durch und alle drei geben mir grünes Licht.