Matrix Screensaver auf dem MAC

Mein Lieblingsbildschirmschoner auf dem MAC war schon immer RedPill 🙂

Bildschirmfoto 2016-02-28 um 14.39.24

Der frühere Entwickler (mathew) hatte anscheinend keine Lust mehr, wegen vieler Änderungen in der Politik von Apple.
Er hat freundlicherweise den Quellcode unter GPL gestellt und auch den Link auf Github zu den Sourcen publiziert.

Da ich den Bildschirmschoner mag, hab ich mir gedacht, ich portiere den einfach mal auf XCode 7.xx und >OSX 10.6.

Den Fork des Quellcodes findet Ihr auf Github

Ich gedenke den Code auch weiterhin zu pflegen und für neuere OS-Versionen verfügbar zu machen.

Ein Binary für den MAC findest Du hier. 🙂

Und nochmals vielen Dank an Mathew für einen mehr als genialen Bildschirmschoner in den Jahren 2002 bis 2012 🙂

 

Git mit zentralem Repository

Auch wenn Git eigentlich ein verteiltes Versionskontrollsystem ist, gehe ich immer gerne den Weg und richte zunächst ein zentrales Master Repository ein, an das sich alle Clients connecten.

Auf dem zentralen Master wird zunächst Git installiert (bei mir auf einem Debian System):

Unter Debian wird ein neues Verzeichnis unter /var/cache/git automatisch angelegt, in dem man das zentrale Repo ablegen sollte

Das frisch erstellte Master Repository ist nun für jeden, der Zugriff auf den Server hat, über ssh://<server>/var/cache/git/YourGitRepository.git verfügbar 🙂

 

Auf den Client, mit installiertem Git, wird nun das Master Repo gecloned.
Ich habe mir auf meinem Mac ein Verzeichnis GIT im home Directory angelegt und dann einfach das MasterRepo gecloned:

Und damit ist schon einmal der erste Teil fertig. 🙂

 

Praxistest

Was fängt man nun mit so einem zentralen Repo an ?

Ich habe ein paar Linux Server an verschiedenen Standorten stehen, dazu noch zwei Entwicklungs Macbooks und ein paar Windows-Büchsen.

  • Grundsätzlich möchte ich nicht, daß Git direkt auf meine im Betrieb laufenden Umgebungen schreiben darf (Also quasi „On the fly“ Umgebungen verändert)
  • Ich möchte von sämtlichen Servern und auch vom Notebook aus einen PUSH ausführen können
  • Ich möchte von sämtlichen Servern einen PULL ausführen können, um Änderungen einspielen zu können

Ich möchte die Verwendung des zentralen Repos hier am Beispiel eines Verzeichnisses auf dem Server aufzeigen.

Zunächst einmal , ein installiertes Git ist natürlich Vorraussetzung 🙂 , in das Verzeichnis wechseln, in dem die Dateien liegen, die man in das zentrale Repo hinzufügen möchte.
Dann dort einfach folgendes ausführen:

Jetzt wurde in dem Verzeichnis eine .git-Struktur erstellt, was man auch leicht mit

überprüfen kann.

Vor dem hinzufügen der Dateien zum Git muß man jetzt zunächst sein zentrales Repository hinzugen, was recht simpel geht.
Befindet sich das Verzeichnis/die Datei die man hinzufügen möchte auf dem Server mit dem zentralen Repository reicht ein:

Ist der Server mit dem zentralen Repository auf einer anderen Maschine nimmt man:

Als Nächstes werden mit

sämtliche Dateien aus dem Verzeichnis hinzugefügt.

Um die Dateien nun auch in das zentrale Repository einzufügen reicht ein simpler

 

Auf dem Client reicht nun ein einfacher

in dem entsprechenden Verzeichnis, das man vorher mittels

erstellt hatte.

 

Fazit

Eine recht simpel und einfach zu nutzende Möglichkeit, um ein zentrales Repository mit Git zu betreiben.
Empfehlenswert.

 

Bücher zu dem Thema

Bei Amazon gibt es zwei recht gute Bücher zu dem Thema. Wem also mein kurzer Blogeintrag nicht hilft und unbedingt mehr lesen möchte:


Antivirus auf dem MAC ?

Macht ein Antivirus-Programm auf einem MAC eigentlich irgendeinen Sinn ?

OK, in sämtlichen Windows- oder Linux-VMs die ich auf dem MAC so neben laufen lasse, sind immer irgendwelche Virenscanner aktiviert.

Bei den Linux-VMs hat sich seit mehr als 4 Jahren nichts ergeben. Die Windows VMs schlagen regelmässig an.

Aber was ist mit dem MAC selbst ?

Auf Wunsch habe ich vorhin einmal ein Antivirus-Programm über meinen kompletten MAC, der – nur so nebenbei bemerkt – seit 4 Jahren ohne so einen Unfug auskommt, rennen lassen.

Das Ergebnis hat mich nicht überrascht: 300GB und 1 Stunde später…

ES WURDE EIN VIRUS GEFUNDEN !

Bildschirmfoto 2016-02-25 um 18.23.30

Also sind MACs auch anfällig für Viren ?

Ich kann da beruhigen, das gefunde VIRUS ist eine Version von „0zapftis“.
Wem das Nichts sagt: das ist der sogenannte Bundestrojaner, den ich in einer Version zu Analysezwecken auf meinem MAC liegen habe.
Also weder aktiv noch sonst irgendwie schädlich – außer das man graue Haare ob der Unfähigkeit deutscher Behörden bei der Analyse bekommt 🙂

 

Fazit

Mein Macbook rennt nun schon 4 Jahre ohne Antvirusprogramm, es wurde weder ein Virus noch nicht einmal ansatzweise irgendwas Richtung AdWare gefunden.
Der Virenscanner wird nun sein Dasein irgendwo in der Versenkung fristen, weil benötigt wird er auf einem MAC nicht.

Macbook Pro 2012 SSD und Speicher aufrüsten

Mein Macbook Pro 15″ (2012) mit 8 GB RAM und einer 500GB HDD schwächelte etwas, wenn ich sehr viele Programme geöffnet hatte.
2 Entwicklungsumgebungen, 3 VMs, ca. 60 Browsertabs verteilt über 3 Browser, SQLDeveloper, eine laufende MysqlDB und diverse offene Terminalsessions brachten das gute Teil ein wenig ans Limit.

Es stand also zur Entscheidung: ein Neues kaufen oder Aufrüsten.

Nachdem ich mir die Preise für ein neues Macbook mit 16GB RAM und einer 1TB SSD angeschaut hatte, war klar: Aufrüsten ist deutlich günstiger.

 

Arbeitsspeicher

Die erste Frage die sich mir stellte, ob man in das 2012er Macbook Pro überhaupt 16GB RAM einbauen kann – laut Apple gehen maximal 8GB RAM in das Gerät -, wurde nach kurzer Recherche im Netz geklärt: ja es gehen wirkich 16 GB RAM, sofern man den richtigen Speicher verwendet.

Möglicher Speicher für das Macbook Pro 2012 Preis
Kingston KVR16S11K2/16 Arbeitsspeicher 16GB (DDR3 Non-ECC CL11 SODIMM Kit, 204-pin 1.5V) 71,- €
Samsung 16GB Dual Channel Kit 2 x 8 GB 204 pin DDR3-1600 SO-DIMM (1600Mhz, PC3-12800S, CL11) 100,- €
Corsair 16GB (2x8GB) DDR3 1600 MHz (PC3 12800) Laptop Arbeitsspeicher (CMSO16GX3M2A1600C11) 85,- €
Crucial ram memory 16GB kit (2 x 8GB) DDR3 PC3-12800,1600MHz for 2012 Apple Macbook Pro’s 89,- €
Hynix 16GB Dual Channel Kit 2 x 8 GB 204 pin DDR3-1600 SO-DIMM (1600Mhz, PC3-12800, CL11, 1.35V) 100,- €
Preise Stand Februar 2016

 

 Die passende SSD

Da für mich zwar von Anfang feststand, daß es eine 1TB SSD sein soll, möchte ich der Vollständigkeit halber hier die möglichen SSDs ab 500GB auflisten, die ich guten Gewissens empfehlen kann.

GB ca. Hersteller Preis
 500 Samsung 850 Pro interne SSD 512GB (6,3 cm (2,5 Zoll), SATA III)
227,- €
Samsung 850 EVO 6,4 cm (2,5 Zoll) 500GB interne SSD (SATA III)
170,- €
Samsung 840 Pro Series SSD-Festplatte 512GB (6,4 cm (2,5 Zoll), 512MB Cache, SATA III)
330,- €
Samsung 840 EVO Basic SSD-Festplatte (6,3 cm (2,5 Zoll) (500GB, 512MB Cache, SATA III)
320,- €
Crucial MX200 500GB interne SSD (6,4 cm (2,5 Zoll) 7 mm, SATA III) 165,- €
Crucial BX100 500GB interne SSD (6,4 cm (2,5 Zoll) 7mm, SATA III) 160,- €
1000 Samsung 850 Pro interne SSD Festplatte 1TB (6,3 cm (2,5 Zoll), SATA III) schwarz 419,- €
Samsung 850 EVO interne SSD 1TB (6,4 cm (2,5 Zoll), SATA III) schwarz 300,- €
Crucial MX200 1000GB interne SSD (6,4 cm (2,5 Zoll) 7mm, SATA III) 336,- €
Crucial BX100 1000 GB (6,4 cm (2,5 Zoll) 7mm, SATA III) 350,- €
2000 Samsung 850PRO SSD 2TB (6,4 cm (2,5 Zoll), SATA III) 869,- €
Samsung 850EVO SSD 2TB (6,4 cm (2,5 Zoll), SATA III)
637,- €
Preise Stand Februar 2016

 

Was braucht man noch, bevor man mit dem Einbau beginnen kann ?

Wie mittlerweile üblich, benötigt man für das Öffnen von Handys oder Computern leider immer ein Spezialwerkzeug 🙁
Um das Macbook auf der Unterseite zu öffnen, bedarf es eines PH00 Schraubenziehers (7 €).
Da ich mir nun nicht wirklich für jede Bastelei an diversen Geräten von Apple neue Einzelwerkzeuge kaufen mag, habe ich mich für das Mini Schraubendreher Set (12 €) von HAMA entschieden, weil es alles an Schraubendrehern anbietet, die man für die Bearbeitung von Apple Geräten benötigt.

RAM, Werkzeug, SSD sind also da, nur irgendetwas fehlt noch: die Daten von der alten HDD müßen ja irgendwie auf die neue SSD.
Es fehlt noch ein externes Gehäuse, in das man zunächst die SSD für das Überspielen der Daten von der HDD einbaut und später als Timemaschine Backup mit der alten HDD verwenden kann.
Hierfür gibt es ein günstiges externes USB 3.0 Gehäuse (15,- €), das sowohl die SSD als auch die HDD aufnehmen kann.

 

Der Umbau

Die HDD clonen

  1. Die neue SSD in das externe Gehäuse einbauen und an den Mac anschließen
  2. Die SSD nun als „Mac OS Extended Journaled„ mittels des Festplattendienstprogramms formatieren
  3. Mit SupeDuper! eine 1:1 bootfähige Kopie der eingebauten HDD auf der SSD erstellen (bei 300GB dauert das ca. 4 Stunden)

Einbau

Ich habe für mich den Weg genommen, die nun präparierte SSD schlicht gegen meine verbaute HDD auszutauschen.
Die HDD habe ich abschließend in das nun freie externe Gehäuse verbaut und nutze dies als TimeMaschine-Backup Volume, bis ich mit meiner SSD irgendwann die 500GB überschreite. Dann muß ich die externe HDD natürlich tauschen.

 

Fazit

Der Umbau hat mich 401,- € gekostet (Kingston Speicher, Samsung 850 EVO, Schraubendreherset und externes Gehäuse).

Schneller als mit 16GB RAM und einer 1TB SSD geht es eigentlich nicht mehr.
Selbst mit den Anfangs genannten offenen Programmen, braucht mein Macbook (2012) aus dem Standby 2 Sekunden und aus dem kompletten „Aus-Modus“ 14 Sekunden bis es nebst aller Programme oben ist.

Ich bin mehr als begeistert. 🙂

Oracle DB 12.x und das C##-User-Problem

Ich habe zu Testzwecken eine Oracle DB 12.1.0.2.0 auf meinem MACBook in einer VM installiert, weil ich für einen Kunden etwas testen wollte.

Neben der mehr als suboptimalen Grundinstallation via GUI, wollte ich dann über den EM (Oracle Enterprise Manager) Benutzer für meine Tests anlegen.

Tja, da staunt der Fachmann und wundert sich der Laie: die Benutzer, die man über den EM anlegen kann, müssen alle mit mit einem „C##“ im Usernamen anfangen, sonst kann man die nicht anlegen. 🙁

Beim Versuch den User Test, also ohne das C## im Usernamen vorangestellt, anzulegen, meldete Oracle zurück:

Selbst im Test mag ich nicht, daß ich die Namen meiner Benutzer, in auch welchem Format auch immer, nach der Meinung des Herstellers benennen muß.

Also kam der EM erst mal nicht weiter in Frage. Ich habe bis jetzt noch nicht rausgefunden, wie ich dem dieses Verhalten abgewöhnen kann.

Aber, es ist ja Oracle und nach einer kurzen Suche durch die Scripte auf der VM wurde ich fündig. 🙂

Soso, ihr prüft also beim Anlegen von Benutzern ab, ob die Variable „_ORACLE_SCRIPT“ in der Session gesetzt ist ?

Na dann fix eine sqlplus-Session als sysdba aufgemacht und folgendes probiert:

Und siehe da, ich konnte den Benutzer auch ohne das führende „C##“ anlegen.

Falls also mal wer auf ein ähnliches Problem stößt:
Einfach eine SQLPlus oder SQLDeveloper als Sysdba aufmachen, _ORACLE_SCRIPT auf true setzen und schon darf man auch als sysdba wieder alles wie gewohnt 🙂

SQLDeveloper auf dem MAC

Normalerweise läuft mein MAC ja ohne Probleme und durch den Einbau einer 1TB SSD ist er eigentlich von der Geschwindigkeit her durch Nichts mehr zu toppen.

Dachte ich 🙁

Letzte Woche hatte ich eine neue Version des Oracle SQLDevelopers installiert und das Ding natürlich auch versucht zu starten.
OK, es blinkte im Dock, zeigte also an das es startete, aber danach passierte erst mal nichts mehr.
Trotz dreimal klicken, zeigte es immer nur „ich starte gerade die Applikation“ an.
Da ich keinen Zeitdruck hatte dachte ich mir „OK, suchst Du mal die Tage den Fehler“.

Als ich meinen MAC dann nur mit Batterie beim Kunden angeschaltet hatte, wunderte es mich, daß der Akkuverbrauch enorm hoch war.

Dazu kam dann noch, daß meine Festplatte auf einmal 800GB belegten Speicherplatz einzeigte. WTF ?

Die suche nach dem Akkuverbrauch brachte recht schnell 3 laufende bash-Shells mit jeweils 99% CPU Usage zu Tage.
Nur woher kam das Zeug und warum war meine Platte fast voll ?

Meine erste Vermutung, daß irgendeines von meinen 30 Terminals (ssh sessions) frei drehte, war es leider nicht.
Nach dem Schließen sämtlicher Terminals (Shells) hatte ich immer noch  3 komplett frei drehende bash-shells mit 99% CPU usage 🙁

Die Vermutung lag nahe, dass es der frisch installierte und 3 mal angeklickte SQLDeveloper sein könnte.

Eine APP unter MAC OSX ist schlicht ein Verzeichnis, in dem die ganzen Binaries und Scripte drin liegen. Auf dem MAC wird dann ein Verzeichnis was mit „.app“ endet, als Application angezeigt, auch wenn es eigentlich nur ein Directory ist.

Also ging die Suche erst mal in dem SQLDeveloper.app Verzeichnis nach dem Startscript los.
Im Verzeichnis SQLDeveloper.app/Contents/MacOS wurde recht schnell der Übeltäter erwischt: sqldeveloper.sh

Was macht nun das Startscript ?

Sieht erst mal nicht sooo verdächtig aus, aber es ruft eine neue bash auf.

Und beim Aufruf in der Concolse sagte es auch brav, daß es nun nach /tmp loggen würde.

Also einmal in /tmp nachgeschaut und was finde ich da ?
380GB Logfiles vom SQLDeveloper 🙁
Kein Wunder das meine SSD fast voll war.

Ein Blick in die Logfiles brachte dann etwas wundersames zu Tage.
Da flogen mächtig viele Exceptions, daß die passende JAVA Version nicht gefunden werden konnte

Was war passiert ?
Die suboptimale Umsetzung von Startscript und Programm führte dazu, daß der SQLDeveloper in einer Endlosschleife ging.
Das Startscript startete den, die weiteren Scripte versuchten den SQLDeveloper zu laden, der auch brav loggte „mir fehlt die passende JAVA Version“ und sich beendete, was die Startscripte zum Anlass nahmen, erneut zu versuchen das Teil zu starten.

Klassischer Deadlock in einer Endlosschleife.

Die neueste Version des SQLDevelopers 4.1.3 hat diesen Effekt nicht mehr.

Falls jemand also mal auf CPU-belastende Prozesse in Verbindung mit dem Vollschreiben der Festplatte stößt: sucht unter /tmp und killed die bash-Prozesse.

Oracle DB GUI Installation

Da ich auf meinem MAC zu Test-/Entwicklungszwecken immer eine Menge VMs am laufen habe, kam ich die Tage in die Situation, daß ich in einer VM eine Oracle DB 12c installieren mußte.

Bis zur Version 10, die ich auch noch in irgendeiner VM installiert habe, ging das ganze Setup ja noch per Console.

Aber mit der 12c geht das nur noch über eine GUI oder Responsefile Installation 🙁

Ich weiß nicht, was sich die Jungs und Mädels da bei Oracle denken, aber gelinde ausgedrückt ist das mehr als Suboptimal.
Warum muß ich zur Installation einer Server-Version einer Datenbank jetzt eine „klickie-buntie“ GUI benutzen oder ein Responsefile ?

Aber egal. Also die GUI.

Das Problem: wie bekomme ich aus einer Linux VM, auf die ich mich nur per ssh connecte, diese komische GUI auf meinem MAC per X-Forwarding angezeigt ?

Nach etwas längerer Bastelei war die Lösung eigentlich recht einfach:

Die GUI wurde dann auch brav auf meinem MAC angezeigt.

Das X enabled das X-Forwarding und das C schaltet noch die Compression der Datenpakete ein 🙂

 

IPTables Alias für das .profile

Das Arbeiten unter Unix/Linux kann mitunter nervig sein, wenn man Befehle immer wiederholen muß.
Daher bieten sich alias an, die man einfach in sein .profle, oder unter bash halt ins .bash_profile, schreibt.

Bei der täglichen Spielerei mit meinen geliebten chinesischen Hackern, also der Entwicklung des Scripts aus Teil 2, waren drei alias Befehle mehr als hilfreich, die ich hier auch nicht vorenthalten möchte.

 

Anzeige welche IPs jetzt in der Blockliste stehen

Da mein Script alle 5 Minuten recht rigoros IPs auf die dynamische Blockliste setzt hab ich mich für den alias iptl entschieden, der mir sämtliche IPs anzeigt, die auf der Blockliste stehen:

Das ist nun kein Hexenwerk, erleichert die Arbeit aber ungemein 🙂

Für den Anfang recht cool, aber, daß muß ich zu meiner Schande gestehen, ab einer gewissen Anzahl von Einträgen in der dynamisch geblockten Liste, wird es schnell unübersichtlich.

Also hab ich mir gedacht, daß es doch noch recht schick wäre, wenn man nur die IPs angezeigt, die auch tatsächlich aktiv Pakete schicken.
Der Alias dafür ist iptld :

Und schon werden via iptld nur noch die „aktiven IPs“ angezeigt 🙂

 

Ein kleiner IPTables Echtzeitmonitor

IPTables in Echtzeit via alias zu monitoren ist auch eine nette Möglichkeit seinen Server im Auge zu behalten.
Daher nun ein kleiner IPTables-Monitor als alias:

IPTables SSH Brute Force blockieren – Teil 2

Im ersten Teil hatte ich ja eine recht simple Methode beschrieben, wie man BruteForce-SSH-Attacken recht simpel mit IPTables blockieren kann, ohne sich weiter um das Thema kümmern zu müßen.

In diesem Artikel wird es jetzt etwas kniffliger. Es ist zwar schön, wenn man BFAs (Brute Force Attacke) abwenden kann, die innerhalb kurzer Zeitspannen reinkommen, aber was passiert denn nun, wenn jemand gezielt dieses Zeitfenster umgeht und trotzdem zig tausende von Anfragen über einen bestimmten Zeitraum schickt ?
Meine IP-Tables config in /etc sieht zunächst einmal so aus:

Also nichts weltbewegendes. 🙂 Ich lasse SSH, HTTP, HTTPS und SMTP zu, der Rest wird gedropped.
Wie man unschwer erkennen kann, ist der BFA-Blocker aus dem ersten Teil ebenfalls Bestandteil der Basiskonfiguration von IP-Tables.

Bei einem meiner Server fiel mir nach recht kurzer Zeit auf, daß von einem chinesischen IP-Block aus versucht wurde einen verzögerten BFA über mehrere IPs und mit variablen Zeitabständen zu versuchen. Mal waren die Abstände zunächst innerhalb einer Minute, weswegen der Trick aus dem ersten Teil half. Dann hörten diese Versuche „innerhalb einer Minute“ für den gesamten IP-Block auf einmal auf. Die Chinesen schienen gemerkt zu haben, daß sie so nicht weiterkamen.

Danach kamen neue Versuche aus dem selben chinesischen IP-Block, mit variablen Zeitverzögerungen, die nun nicht mehr in den 60-Sekunden-Trick fielen.

Da mein root-Passwort größer 30 Zeichen ist und aus einer illustren Kombination aus Groß-/Kleinschreibung, Zahlen und Sonderzeichen besteht, zudem noch eine 2-Wege-Authentifizierung stattfindet, habe ich mir um das „Knacken“ meines PWs keine wirklichen Sorgen gemacht 🙂
Aber es nervt halt schon, wenn einem die Logs zugemüllt werden.

Es stand zunächst die Idee im Raum, eines von den vielen auf dem Markt verfügbaren Tools zu nutzen, aber ich vertraue auf Unix-Ebene zunächst grundsätzlich keinem Code den ich nicht selbst geschrieben habe oder innerhalb 15 Minuten verstehe. (Alte Admin-/Hacker-Krankheit).

Also was eigenes Schreiben.
Herausgekommen sind 98 Zeilen Shell-Script, die IP-Tables dynamisch, über cron gesteuert, konfigurieren 🙂
Ob diese 98 Zeilen jeder sofort innerhalb 15 Minuten versteht, kann ich nicht beurteilen, aber ich werde hier jetzt einfach zeigen wie ich vorgegangen bin und am Ende das fertige Script zum Download zur Verfügung stellen.

Mein betroffener Server läuft auf Debian GNU/Linux 7 (wheezy) und sollte daher, mal von einigen File-Locations abgesehen, als Referenz herhalten können.

Der erste Ansatz, um herauszufinden, wie man das Ganze nun dynamisch macht, ist ersteinmal herauszufinden, was man denn nicht blocken möchte ^^
Sämtliche Informationen die wir zum blocken oder nicht-blocken brauchen, finden wir unter Debian in dem File „/var/log/auth.log“.
Wenn man sich die Datei genauer anschaut, findet man darin auch Zeilen wie diese:

CRON mag ich nicht blocken 🙂

Für mich habe ich den Weg genommen, daß ich grundsätzlich nur alles blocken möchte, was einen „Failed password“ im auth.log hat und nicht zu meinen Ausnahmen gehört.

Ein „Invalid user“ ist zwar auch nicht nett, kann aber auch mal von einem Fehler vor der Tastatur kommen.

Wenn man jetzt mal ins „/var/log“ schaut, sieht man, daß die Logfiles rotiert und die wegrotierten, bis auf den auth.log.1, gezipped werden, also muß das Script auch diese Files entzippen, nach Mustern durchsuchen, dynamisch zur IPTables Blockliste hinzufügen und das ganze brav wieder zippen (manuelle Option, geeignet, um initial eine Blockliste aufzubauen).

Da ich ein unfreundlicher Admin bin, bleiben geblockte IPs für immer geblockt – also bis zum Sankt Nimmerleinstag. Ungeachtet Dessen, ob sie momentan noch im auth.log oder in den rotierten auth.logs drin sind. Daher muß das Script noch eine Historie führen, die man zur Not manuell bearbeiten kann. 🙂

Dann zur Umsetzung.

In THRESHOLD steht die maximale Anzahl an Versuchen, die zugelassen werden, bevor eine IP geblockt wird. Dies gilt über alle eingelesenen auth.log, also auch die gezippten. Taucht also die selbe IP in den gezippten Logs mehr als THRESHOLD-mal mit einem Fehler auf, geht diese IP in die IP-Tables-Blocklist.

Da das Script sowohl in einem FULL-SCAN (manuell) oder einem SHORT-SCAN (z.B. per CRON) läuft, sind die nächsten beiden Zeilen der maximale Linecount, der im entsprechenden ScriptModus verwendet wird. Bei einem FULL-SCAN können das durchaus mehr Zeilen werden, weswegen der Wert auf 50.000.000 Zeilen steht.

GREPVPATTERN ist das Argument, was an grep übergeben wird, um Sachen aus den Logs auszufiltern, die ich nicht blocken mag.

GREPVIPTABLES dient dazu, um im Log mitzuteilen, was wir jetzt tatsächlich in IPTables an geblockten IPs haben. (Es wird beim finalen Script deutlich)

GUNZIPARGBEFORE und GZIPARGAFTER stehen für die Files gezipped sind und bei einem FULL-SCAN mit einbezogen werden sollen und danach wieder gezipped werden müßen.

LOGLISTFULL und LOGLISTSHORT stehen für die Dateien, die bei einem Scan im FULL-SCAN oder im SHORT-SCAN durchsucht werden sollen.

PERMBLOCKLIST ist nun noch das File, wo sämtliche geblockten IPs abelegt werden sollen, die auch nach einem Restart des Rechners oder Reset der IPTables dynamischen Konfiguration wieder hinzugefügt werden sollen.

Hier nun das ganze Script (block_attack.sh):

Bei Fragen oder Anregungen -> Einfach einen Kommentar schreiben 🙂