Du kannst den Kommentar wie in meiner Anleitungs-PDF beschrieben beliebig erweitern in dem du hinter dem DROP einen beliebigen Text angibst.
php -f fw.php add INPUT 42.42.42.42 DROP "ein beliebiger text"
Wichtig sind nur die " damit alles als ein Parameter erkannt wird. Ansonsten wird nur das erste Wort nach dem DROP als Kommentar verwendet. 
Und das Aktivieren von mod_rewrite in Confixx nicht vergessen!
F2B würde einfach stupide weiter machen. Wie ich weiter oben schon mal geschrieben habe, würde ich nur ungerne eine solche Logik in das Script einbauen. F2B bekommt von solchen Prüfungen nichts mit. Es würde dann wieder "already banned" Meldungen im Log hageln.
Ich könnte mir aber eine Email Benachrichtigung vorstellen, die ab X Regeln eine Alarm-Email versendet oder so. So könnte man als Admin eingreifen und händisch ganze Subnetze sperren, wenn es nötig wird. Das selbe ist ja auch für Fehlermeldung geplant, die von der API kommen.
Wo genau das Limit ist weiß ich aber nicht.
Da bei einem anderen Projekt was dazwischen gekommen ist, hatte ich ein Stündchen Zeit das Script neu aufzusetzen und die Kommentarfunktion einzubauen. Die Anleitung wurde entsprechend angepasst.
Der Sourcecode ist nun erheblich übersichtlicher und sauberer.
Freue mich über Feedback.
Im Log finde ich schonmal nen Syntax Fehler in einer der Konfigurationsdateien.
Den würde ich zum Beispiel schon mal beheben.
Hat Dein Server denn jetzt 6GB RAM?
Wenn DU da zu viel angibst schmiert er auch ab.
Der Screen Prozess stirbt ja immer sobald der java Prozess beendet wurde. Das hat nichts besonderes zu sagen. Ich würde den Bukkit einfach mal ohne Screen starten, dann sieht man auch die Fehlerausgaben. Ansonsten mal ins server.log von Bukkit gucken.
Zu Github:
Ich bin der Meinung das sich das nicht lohnt. Das Script ist so gut wie stabil und "fertig". Für ein paar kleine Korrekturen lohnt sich das nicht extra ein Github Projekt zu eröffnen.
SiGa
Wenn Du wirklich noch viele gute Ideen hast, dass sich das lohnt, würde ich Dir einen Zugang zu meinem GIT einrichten. Ansonsten kannst Du gerne das Script forken und selbst dran rum basteln. Bitte dabei die Lizenz beachten.
Zum Subnetze sperren:
Das ist eine Problemstellung für Fail2Ban, nicht für mein Script. Ich müsste im Script mitloggen welche IPs wann gesperrt wurden und auf diese Daten dann Analysen durchführen und die gemeinsamen Netze ermitteln. Davon bekäme F2B aber nichts mit. Der würde weiterhin einzelne IPs sperren und auch nur einzelne IPs wieder freigeben.
Deswegen halte ich persönlich von der Idee nichts.
Wenn Du magst kannst Du das ja selbst implementieren.
Kommendes Wochenende habe ich wieder ein bisschen Luft, dann werde ich das Script von der Qualität noch ein wenig überarbeiten und die Kommentarfunktion einbauen. Wer noch Ideen hat kann sich bis dahin ja noch melden.
Zu dem Passwort-Problem:
Da scheint irgendwas nicht richtig zu laufen. Schreib mal am besten den Support an.
IPv6 habe ich selbst noch nicht getestet mangels IPv6 Client. Vielleicht kann da ja jemand anderes was zu sagen. Bei den "already banned" Regeln wird wohl an der Verzögerung zum Webservice liegen. Bis die Regel hinzugefügt wurde kann es auch mal 2-5 Sekunden dauern. Der STATE Zusatz wurde hinzugefügt da es ja bis vor kurzem Probleme mit der Wirksamkeit der Regeln gab. Es wird trotzdem alles geblockt. Es gibt nur diese drei STATES.
Das Feature einen Zusatz in den Kommentar einzusetzen werde ich bei Gelegenheit noch einbauen. Du bist jetzt ja schon der zweite der das möchte.
Kein Problem.
Dann schau mal in den Logs ob die Jails überhaupt aktiviert werden.
Was schreibt denn Fail2Ban in sein Log?
Erkennt er überhaupt die "Hackversuche" und versucht einen Ban?
Hast Du mein Script denn in das action.d Script für iptables-multiport eingebaut?
Wird iptables-multiport denn auch als action verwendet?
Hat schon deinen Grund wieso Communities wie das Unixboard tot sind... 
Kleiner Tipp am Rande: Solche kritischen Tasks immer in einer Screen Session starten.
Wechsel einfach mit "cd" in den entsprechenden Order (Pfad steht im log) und checke mit "ls -lisa" den Besitzer und die Gruppe.
Die Dateien dürfen dabei nicht root gehören. Mit "chown" kannst du den Besitzer ändern.
Wie genau die Befehle funktionieren kannst du sehen wenn du ein "--help" anhängst.
Marcoo
Das hat nichts mit Regeln im Kopf haben zu tun. Das ist eigentlich logisch.
Die RIPE motzt seit Monaten rum das ihnen die IPs ausgehen und Netcup hat die Vergaberegelungen auch immer mehr angezogen. Und da ne eigene IP bei Webspace nur mit HTTPS Sinn macht, ist es eigentlich klar das man sonst halt keine IP bekommt.
IP Adressen gibt es nur nach RIPE Regelungen.
Also beim Webspace nur, wenn Du ein SSL Zertifikat dazu buchst.
Ansonsten gibt es da ja keinen Grund für.
Achso. Das hat sich eben so gelesen als ob Du noch ein Problem hast. 
Wo liegt genau Dein Problem?
Haste das ulimit auskommentiert?
Bei mir scheint auch alles zu klappen.
Auf die Lösung muss man auch erst mal kommen. 
Da wünsche ich mir definitiv ein bisschen mehr gesprächigkeit der API was genaue Fehlermeldungen usw angeht.
So die neue Version mit SORT=1 ist im GIT.