sudo apt-get install chromium-browser

Noch sind nicht alle Freatures die im Chrome bereits zum Standard zählen implementiert. Auch das Plugin System muss zunächst aktiviert werden. Das aktivieren erfolgt über das Eintragen von

CHROMIUM_FLAGS="--enable-plugins"

in die Datei /etc/chromium-browser/default. Ein Symlink muss nun in /usr/lib/chromium-browser/plugins/libflashplayer.so erstellt werden der auf die Datei /usr/lib/flashplugin-nonfree/libflashplayer.so zeigt. Der Symlink wird mit dem Befehl

sudo ln -s /usr/lib/chromium-browser/plugins/libflashplayer.so /usr/lib/flashplugin-nonfree/libflashplayer.so

erstellt. Hierbei ist zu beachten das der Pfad zur .so Datei des Flash Players von Distribution zu Distribution in verschiedenen Verzeichnissen liegt (dieser Artikel ist für Ubuntu). Die Pfade im Befehl zum erstellen eines Symlinks müssen eventuell angepasst werden. Sollte die Datei nicht vorhanden sein kann sie mit dem Installieren des Flash Players installiert werden. Mit

sudo apt-get install flashplugin-nonfree

sollte Flash unter einem Ubuntu System installiert sein. Adobe Flash sollte nach dem Ausführen der oben genannten Schritte in deinem Chromium funktionieren. Falls dem nicht so sein sollte hinterlasse mir ein Kommentar woran es gelegen hat.

<IfModule mod_security.c>
SecFilterEngine Off
</IfModule>

Mit diesen 3 Zeilen Code wird geprüft ob mod_security vorhanden ist und mod_security deaktiviert. Dadurch funktioniert der Flash Uploader wieder.

Zum Artikel gehts mit diesem Link: Verschlüsseltes Debian Backup

unset HISTFILE

abhilfe schaffen. Der Befehl deaktiviert die Shell History (den Verlauf) für die aktuelle Sitzung. Beim neu Einloggen ist der Standard wiederhergestellt und die Shell History wieder aktiviert.

Die Installation beider Komponenten gestaltet sich unter Debian oder Ubuntu sehr einfach. Ein kurzes

apt-get install bittornado screen

reicht aus um die Installation auszuführen. Für andere Distributionen empfehle ich die Programme über den jeweiligen Paketmanager zu installieren. Ein compilieren der Quellcodes ist meiner Meinung nach zu aufwändig.

Zum starten des Bittornado Daemons aus der Shell verwende ich ein kleines von mir geschriebenes Script. Dieses macht es möglich den UNIX Benutzer, das Download Verzeichnis sowie die maximale Anzahl von Uploads und die Uploadbandbreite festzulegen. Ich limitere den Upload um nicht zu viel Traffic zu erzeugen. Der Benutzer wird festgelegt um bei einer Exploitmöglichkeit für Bittornado keine umfassenden Angriffspunkte am System zu bieten. Sehr interessant ist hierbei auch das Bittornado in der Programmiersprache Python geschrieben ist. Dadurch wird etwas mehr Speicher und Rechenzeit benötigt. Was für mich keine Relevanz hat. Im Gegenzug können keine Buffer Overflows auftreten.

#! /bin/sh
 
## Author: Tobias Jäck
## License: GPL version 3
 
##
## <Configuration>
##
 
USER="webservices"
 
DIR="/home/webservices/incoming/"
 
MAX_UPLOADS="6"
 
MAX_UPLOAD_BANDWIDTH="14"
 
##
## </Configuration>
##
 
screen -AmdS bittornado su ${USER}  -c "btlaunchmanycurses ${DIR}  --minport 50000 --maxport 55000 --max_uploads ${MAX_UPLOADS} --max_upload_rate ${MAX_UPLOAD_BANDWIDTH}"

Das Script wird mit

chmod +x <SCRIPTNAME>

lauffähig gemacht und mit

./<SCRIPTNAME>

aufgerufen. Das Vorgehen ist bei allen Scripten unter UNIX Systemen gleich. Auch mein Script stellt da keine Ausnahme da. Der im Script hinterlegte Benutzer und das Verzeichnis musst du vorher natürlich noch für dein System anpassen. Nach dem Aufruf des Scriptes passiert scheinbar nichts. Im Hintergrund wurde jedoch eine Screen Sitzungen mit Bittornado gestartet.

Um einen Download zu starten muss eine gültige .torrent Datei in das im soeben gestartete Script angegebene Verzeichnis verschoben werden. Kurze Zeit später beginnt der Download des Torrents in Bittornado. Der aktuelle Stand der Downloadvorgänge kann mit

screen -r

oder, falls mehere Screen Sitzungen zur selben Zeit aktiv sind mit

screen -r bittornado

abgefragt werden. Wichtig ist es hierbei die Download Übersicht über screen mit strg + a und dem anschließendem Drücken der d Taste zu schließen. Ein eingeben der Tastenkombination strg + c würde Bittornado umgehend beenden und den Download abbrechen.

Den fertigen Dowload findest du im Download Verzeichnis neben den .torrent Dateien.

Natürlich könnte Bittornado auch mit dem manuellen eintippen der Befehle ohne das Startscript auf die selbe Art und Weise gestartet werden. Diese Arbeit möchte niemand antun. Insbesondere nicht ich. Ich denke mein Startscript für Bittornado ist mehr als hilfreich.

Apr 28 15:33:56 mail postfix/smtpd[8110]: warning: unknown[218.248.1.181]: SASL CRAM-MD5 authentication failed: PDM2NjYyMjQ0OTU5OTE5MTMuMTI3MjQ2MTYzNUBFTVAtUz4=

Mich wunderte das die IP Adresse nicht nach 3 Versuchen von Fail2ban (Version 0.8.3-2sid1) gebannt wurde. Es hat sich herausgestellt das der Reguläre Ausdruck den Fail2ban für das erkennen Fehlgeschlagener authentifizierungs Versuche nicht mit der Log-Nachricht übereinstimmt. Ein Entfernen des $ am Ende des Regulären Ausdrucks (failregex) in der Datei /etc/fail2ban/filter.d/sasl.conf reichte aus um die Logs passend zu filtern.

Warum das $ entfernen?
Das $ steht in einem Regulären Ausdruck für das Ende der zu suchenden Zeichenkette. Da aber nach “authentication failed” in dem Log Eintrag weitere Zeichen folgen passt der Reguläre Ausdruck nicht zum Logeintrag.

failregex = : warning: [-._\w]+\[<HOST>\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed

Ist meine aktueller Eintrag um fehlgeschlagene authentifizierungs Versuche am Postfix SMTP Daemon zu erkennen.

Spamassassin füllte meine Logs zum selben Zeitpunkt mit:

Apr 28 00:31:27 mail spamd[21987]: spamd: creating default_prefs: /nonexistent/.spamassassin/user_prefs
Apr 28 00:31:27 mail spamd[21987]: config: cannot write to /nonexistent/.spamassassin/user_prefs: No such file or directory
Apr 28 00:31:27 mail spamd[21987]: spamd: failed to create readable default_prefs: /nonexistent/.spamassassin/user_prefs

Eine weitere Lösung musste her… Da Spamassassin bei mir unter dem Benutzer nobody läuft und dieser zu diesem Zeitpunkt kein gültiges Heimatverzeichnis in der /etc/passwd Datei hinterlegt hatte blieben mir sinnvolle 2 Möglichkeiten. Zum einen das Eintragen eines gültigen Heimatverzeichnisses in die Datei /etc/passwd. (Platzhalter: <VERZEICHNIS>)

nobody:x:65534:65534:nobody:<VERZEICHNIS>:/bin/false

Zum Anderen gab es die Möglichkeit Spamassassin durch eine Änderung in /etc/defaults/spamassassin mit einem virtuellen Verzeichnis zu starten. Hier mein Aktueller Eintrag für standard Startoptionen von Spamassassin: (Platzhalter: <VERZEICHNIS>)

OPTIONS="--create-prefs --max-children 5 --helper-home-dir -u nobody -x --virtual-config-dir=<VERZEICHNIS>"

Ich entschied mich für die zweite Möglichkeit (Verzeichnis: /var/spool/spamassassin).