[Eisfair] [eisfair-1/eisfair-2/eisxen] brute_force_blocking (BFB) 0.3.8 released

[Raphael Gradenwitz]

Hi Olaf,

Am 28.09.2011 01:05, schrieb Olaf Jaehrling:
> Hi @ll,
> 
> ich habe eine neue Version von BFB veröffentlicht. In dieser Version
> wurde ein schwere Fehler behoben, der Auftrag, wenn beim Apache VHOSTS
> verwendet wurde. BFB ist in dieser Konstellation zietweise einfach
> hängen geblieben. Ich empfehle die neue Version zu installieren.
> 

Ich habe die neue Version installiert und die Installation blieb beim
Neustart des Dienstes hängen. Ich kann, nein ich muss leider erst mal
jedem davon abraten diese Version zu installieren!

Das Init-Script ist so nicht in der Lage die IP-Tables-Regeln auf zu
räumen bzw. alle mögliche eventualitäten ab zu decken wie es für einen
Neustart des Dienstes nach dem Update nötig ist und geriet deshalb bei
mir in einer Endlos-Schleife!

Wer nicht mit iptables auf der Console umgehen kann, bleibt dann nur ein
Neustart der Maschine nach der Installation und das kann es aber nicht sein!

Lieber Olaf, räume bitte (endlich) dein Code auf, es ist ein absolutes
Chaos und durcheinander. Baue es bitte moduliert(er) und lesbar.
Das Paket wird so immer mehr selber zum Sicherheitsrisiko welches ich
für mein Part immer noch nicht ohne ständige Änderungen ein zu setzen wage!
Aber nur zur Klarheit: Direkt VOR dem Update, war eine unveränderte
version von dir drinnen, nicht das du meinst, es sei wegen etwaige
Änderungen meinerseits zum hängenbleiben gekommen.

Ich möchte auch nicht unbedingt das iptables auf dem Host, sondern das
auf dem vorgelagerten fli4l blocken lassen aber so etwas ist schon gar
nicht, nicht mal ansatzweise vorgesehen und so wie das jetzt
strukturiert ist, muss ich da jedes Mal fast alles neu schreiben.

Temporäre Dateien werden nie aufgeräumt, ob es nun die letzte Mail ist
oder z.B. /tmp/atmaupdate (wozu ist die Datei überhaupt gedacht? Wird
die auch noch irgendwo abgefragt? Ich habe auf die Schnelle nur Stellen
gefunden wo sie mit IP-Nummern gefüttert wird) die ständig anwächst auf
bei mir mittlerweile über 50.000 Einträge.

Das Proaktive Blocking ist auch noch recht suboptimal gelöst. Solche
Blacklisten können viel effizienter mit pgl geblockt werden. Schaue dir
das (pgl) bitte mal an. Dann werden nicht einzelne IP's geblockt so wie
hier zufällig herausgeschnitten:

220.181.108.165
220.181.108.166
220.181.108.167
220.181.108.168
220.181.108.169
220.181.108.170
220.181.108.171
220.181.108.172
220.181.108.173
220.181.108.174
220.181.108.175
220.181.108.176
220.181.108.177
220.181.108.178
220.181.108.179
220.181.108.180
220.181.108.181
220.181.108.182
220.181.108.183
220.181.108.184
220.181.108.185
220.181.108.186
220.181.108.187

sondern in disem Fall einfach die Range
220.181.108.165-220.181.108.187

So wie du das jetzt zusammengebastelt hast, habe ich gleich am Anfang
beim Start über 1880 einzelne Regeln in der BFBBLOCK-Chain die jedes
einzelne Paket unabhängig vom Protokoll via der INPUT-Chain durchlaufen
muss.

Nun ja, das geht natürtlich, ist aber nicht gerade elegant gelöst. Wie
gesagt, pgl, dann können gleich die ganzen bluetack Blocklisten benutzt
werden oder eben, so wie jetzt, eigene Blocklisten unterhalten werden
mit einen viel geringeren .

dies nur auf die Schnelle.

Liebe Grüße,

Raphael