Re: libssh-Bruteforcer in IPTABLES Chain bannen
Thomas Antepoth <debian@antepoth.de> writes:
> Hallo Bruno, :-)
>
>
> On Wed, 30 Mar 2005, Bruno Hertz wrote:
>
>> Thomas Antepoth <t_antepoth@antepoth.de> writes:
>> > [ Logfiles in near-realtime parsen ]
>> OK, unter Perl wäre die Vorgehensweise vielleicht wie folgt:
>> * anstatt einer read loop eine select loop mit timeout
>> * in jeder Iteration mit stat prüfen ob sich der inode meiner Datei
>> geändert hat
>> * wenn ja, file neu öffnen.
>> Oder?
>
> Ganz genau so muß es funktionieren.
>
> Gerade habe ich ein wenig ge"apt-cache"d. Hierbei fand sich dann
> "libfile-tail-perl", welches genau dies macht. Ich konnte mir auch ehrlich
> gesagt nicht vorstellen, dass dieses Basisproblem nicht schon von
> irgendeinem Menschen auf dem Planeten gelöst wurde.
>
> Das gefällt mir dann doch viel besser als alle "tail --retry -n ..."
> Backtick-Wurschdeleien.
>
> Das auf "File::Tail" angepasste Script findet sich a.a.O. - der
> diff dazu findet sich bei http://212.227.20.60/debian/denyssh.diff
>
> Herzlichen Dank noch für den Denkanstoß und ein schönes Wochenende! :-)
> t++
Gleichfalls, vielen Dank :) Das Problem ist übrigens klassisch, insbesondere
auch für C Programmierer. I.e. wenn du ein 'open' auf eine Datei machst,
kriegst du einen descriptor der valid ist auch wenn die Datei von einem
anderen Prozess entfernt wird. D.h. die Datei ist in Wirklichkeit noch da,
du kannst sie noch immer lesen und in sie schreiben, sie ist halt nur nicht
mehr im Dateisystem sichtbar und wird eben in Wirklichkeit erst entfernt wenn
kein Prozess mehr einen offenen file descriptor auf sie hält. All das ist sehr
schön, aber es nützt dir natürlich nichts wenn du selbst aus der Datei lesen
willst was andere Prozesse in sie schreiben, diese aber bereits eine neue Datei
verwenden.
Das andere Thema, i.e. 'read' und 'select' ist fast noch klassischer. I.e. in der
Regel blockiert ein read auf einem descriptor solange bis Daten zum Lesen
eintreffen, was recht lange dauern kann insbesondere wenn keiner mehr in
die zugehörige Datei schreibt :) Man kann zwar nun, wenn man regelmäßig andere
Bedingungen abprüfen will wie den Zustand der Datei, den read nonblocking
setzen, aber das würde auf eine busy loop hinauslaufen solange keine Daten
eintreffen, was natürlich unerwünscht ist. Die Standardlösung ist eben 'select',
das den Prozess ebenso hübsch schlafen legt wie read wenn keine Daten da sind,
aber wo man zusätzlich ein timeout setzen kann, was bei read alleine eben nicht
möglich ist. In summa ist also die ganze Thematik, vom programmiertechnischen
Standpunkt aus, wirklich ein sehr typischer Standardfall :)
Gruss, Bruno.
Reply to: