Vielen unter euch ist sicher der Mulit Datei Upload mit Flash ein Begriff. Diese Methode ermöglicht es mehrere Dateien auf einmal auszuwählen und diese automatisch nacheinander hochladen zu lassen. Unter anderem wird diese Methode für den Dateiupload bei xt:commerce Veyton eingesetzt. Bei der Arbeit mit diesem Shopsystem ist ein Problem mit dem Flash Uploader aufgetreten. Der Apache2 Webserver meldete den Fehler 403 (Error 403). Der Fehler wurde durch den aktivierten POST Filter der Apache2 Erweiterung mod_security ausgelöst. Die einfachste Lösungsmöglichkeit war das Deaktivieren von mod_security. Hierzu wurde in die .htaccess Datei folgendes eingetragen:

<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.

Keine Kommentare »
 

Mein Artikel „Debian Backup mittels Paketlisten & MySQL Dumps & FTP Upload“ wurde soeben aktuallisiert. Das Script passt nun die Prozess und I/O Priorität für den eigenen Prozess an um den Server nicht bei seinen regulären Arbeiten zu behindern und verschlüsselt das Backup auf Wunsch mit GnuPG.

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

Keine Kommentare »
 

Wenn man sich in der Shell nicht auf die Finger schauen lassen will kann mit dem Kommando

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.

Keine Kommentare »
 

Torrents mit dem eigenen Server herunterzuladen ist nicht nur schonend für die eigene Leitung Zuhause sondern schont ebenso die Internet Leitungen der Open Source Projekte von dessen HTTP Servern der Download ansonsten stattfinden würde. Aus diesem Grund lade ich seit längerem größere Dateien gerne über die, sofern vorhanden, verfügbaren Torrent Quellen herunter. Dazu verwende ich den Konsolen basierenden Bittorrent Client Bittornado im Zusammenspiel mit dem allseits bekannten Screen.

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
 
##
## <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.

Keine Kommentare »
 

Beim studieren der Server Logs meines Debian Lenny Servers fiehl mir auf das sehr viele fehlgeschlagene authentifizierungs Versuche am SMTP Daemon von Postfix statt gefunden hatten. Folgende Meldung wiederholte sich mehrfach:

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).

ein Kommentar »
 

Shellzugriff aus dem Browser heraus ist nicht nur geschickt sondern in streng konfigurierten Netzwerken auch die einzige Möglichkeit Shellzugriff auf den Server zu bekommen. Hierfür kann ich dir PHP Shell empfehlen. Shellkommandos lassen sich damit ausführen und die Ergebnisse der Kommandos ansehen.

Leider lassen sich Programme wie Nano mit der PHP Shell nicht ausführen. Autovervollständigung mittels TAB unterstützt das Shell Werkzeug ebenfalls nicht.

Neben dem starten des PHP Shell Scriptes als root ist es eine weitere Vorraussetzung „Safe Mode“ zu deaktivieren und das Ausführen der Funktion proc_open() zu erlauben.

Ich kann euch diese kleine Webapplikation nur ans Herz legen.

Links:

Keine Kommentare »