Category Archives: Debian

rtorrent monit- und Init-Skript

Wer rtorrent regelmäßig und dauerhaft einsetzt, wünscht sich eine elegantere Lösung, als das händische Starten und Stoppen einer screen-Sitzung. Ohne viele weitere Ausschweifungen folgt meine Lösung für diesen Wunsch: Ein Init-Skript und eine Konfigurationsdatei für monit. Monit ist eine Prozessüberwachungs-Software.

Im Gegensatz zu den anderen kursierenden Skripten kann mit dem hier vorgestellten sowohl die niceness (CPU-Priorität) als auch die I/O-Klasse eingestellt werden, sodass rtorrent nicht mehr alle Prozessoren und jede Eingabe-/Ausgabe-Operation für sich beanspruchen kann. Dazu absolut zu empfehlen ist die manpage von ionice und nice. Wer noch nicht reingesehen hat, verpasst was.

rtorrent Init-Skript

Das Init-Skript wird im Verzeichnis /etc/init.d/ unter dem Namen rtorrent-beispielUser abgelegt. Mit dem Befehl update-rc.d rtorrent-beispielUser defaults kann es in den Startprozess eingebunden werden.

#!/bin/bash
### BEGIN INIT INFO
# Provides:          rtorrent-beispielUser
# Required-Start:    $syslog $local_fs
# Required-Stop:     $syslog $local_fs
# Should-Start:      $remote_fs
# Should-Stop:       $remote_fs
# X-Start-Before:    xdm kdm gdm ldm sdm
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: rtorrent
# Description:       Load up rtorrent in a screen session
### END INIT INFO

###############
#
# TO INSTALL RUN
# sudo /usr/sbin/update-rc.d rtorrent defaults
#
##################


. /lib/lsb/init-functions

# EDIT THIS VARIABLE TO THE USER THAT YOU WANT RTORRENT TO RUN AS
USER=beispielUser
# Where to store the pidfile
PIDFILE="/var/run/rtorrent-${USER}.pid"
# Path to screen
SCREEN="/usr/bin/screen"
# Name of screen (visible via screen -ls)
SCREEN_NAME="rtorrent-${USER}"
RTORRENT="/usr/local/bin/rtorrent"
# Default (0), lowest=7, highest=0
IOPRIO="7"
# Default (0), lowest=19, highest=-19
NICE="5"

case "$1" in
  start)
    log_daemon_msg "Starting rtorrent"
    start-stop-daemon --start --background --oknodo \
    --pidfile "$PIDFILE" --make-pidfile \
    --chuid $USER --iosched best-effort:$IOPRIO --nicelevel $NICE \
    --exec $SCREEN -- -DmUS $SCREEN_NAME $RTORRENT
    if [ $? -gt 0 ]; then
        log_failure_msg "FAILED."
        log_end_msg 1
        exit 0
    else
        log_end_msg 0

    fi
    ;;
  stop)
    log_daemon_msg "Stopping rtorrent"
    start-stop-daemon --stop --oknodo --pidfile "$PIDFILE"
    if [ $? -gt 0 ]; then
      log_failure_msg "FAILED."
      log_end_msg 1
    else
      log_end_msg 0 
    fi
    ;;
  restart)
    $0 stop
    sleep 1
    $0 start
    ;;
  *)
    echo "usage: $0 {start|stop|restart}"
esac
exit 0

rtorrent Monit-Konfigurationsdatei

Die Monit-Konfigurationsdatei wird im Verzeichnis /etc/monit/conf.d/ unter dem Namen rtorrent-beispielUser abgelegt. Nach einem Neustart kann der Status von rtorrent abgerufen werden.

check process rtorrent-beispielUser with pidfile /var/run/rtorrent-beispielUser.pid
	start program = "/etc/init.d/rtorrent-beispielUser start"
	stop program = "/etc/init.d/rtorrent-beispielUser stop"
        # Nur bei aktiviertem scgi_port 127.0.0.1:5001 wirksam, sonst auskommentieren
        if failed host 127.0.0.1 port 5001 type tcp then restart
        if 5 restart within 5 cycles then timeout

Überarbeitung der Anleitungen zur Voll-Verschlüsselung

tauchfahrt_submarine

In den letzten drei Wochen war es etwas still im Blog. Das liegt zum einen daran, dass meine Diplomarbeit mich in Beschlag nimmt, aber auch daran, dass ich die gesammelten Tauchfahrt mit Linux Anleitungen zur Voll-Verschlüsselung für euch überarbeite und neu strukturiere.

Wer Kommentare, Feedback oder Wünsche hat: Jetzt ist der Zeitpunkt dafür.

Talentwettbewerb – Bitte um Mithilfe!

UPDATE 12.05.2014: Ich habe dank Eurer Hilfe gewonnen.

Hallo,

mein Name ist Falk und heute wende ich mich das erstemal persönlich an meine Blogleser, also Euch. Seit einiger Zeit entwickle ich privat Konzepte, um Server durch Voll-Verschlüsselung zu schützen. Unter anderem für Debian GNU/Linux, Proxmox oder Kali Linux.

Zu diesem Thema durfte ich im letzten Semester eine Studienarbeit mit dem Titel Verteidigung externer Rechnerressourcen verfassen, einen Vortrag halten und habe über die Zeit viele sehr talentierte und engagierte Menschen kennenlernen dürfen. Neidlos gebe ich zu, dass es noch viel zu entdecken gibt.

Im Rahmen eines Talentwettbewerbs steht meine Studienarbeit jetzt zur Abstimmung und ich würde mich sehr freuen, wenn Ihr für mich abstimmt. Damit zeigt Ihr, dass meine privaten Bemühungen von euch geschätzt werden.

Ich veröffentliche regelmäßig Artikel zu Linux und IT-Sicherheit und lehne seit über vier Jahren jede kommerzielle Beeinflussung durch Werbung oder für euch nicht erkennbare Produktsponsorings ab. Bei meinen Artikel gebe ich mir größte Mühe, meine Meinung herauszuhalten und euch Fakten und Anleitungen zu präsentieren.

Falls das nicht als Motivation ausreicht:
Für die Dauer der Abstimmung gibt es unter dem Abstimmungslink ein Bild von mir. Das einzige im Internet.

Hier abstimmen

Grüße,
Falk

OS Command Injection am Beispiel Inter-Tech RPD-150

(Inter-Tech RPD-150 - Quelle: Inter-Tech Bilderpaket)

( RPD-150 )

Im Bereich eingebetteter Systeme ticken die Uhren langsamer, als im Desktop- und Server-Bereich. Hier lassen sich noch leicht klassische Schwachstellen wie Directory Traversal oder OS Command Injection finden. Letztere Variante findet sich auch im WLAN-Router RPD-150 der Firma PC-Professional, der durch Inter-Tech vertrieben wird. Das Gerät wird für circa 11 Euro angeboten und wird mit überragender Sicherheit beworben.

Bildschirmfoto - 17.04.2014 - 00:09:20

RPD-150: Mit überragender Sicherheit.

OS Command Injection Angriffe (nach OWASP) bezwecken es, Befehle die durch den Angreifer festgelegt werden, in eine anfällige Anwendung einzuschleusen. Dabei verhält sich die verwundbare Anwendung wie eine Pseudo-Shell, die es erlaubt, mit den Rechten und in der Umgebung in der sie ausgeführt wird, Befehle auf dem System auszuführen.

Erste Stelle, die oft für Command Injection Angriffe besonders interessant ist, ist die Ausführung von Diagnosebefehlen in der administrativen Oberfläche eines Routers. Hier werden teilweise Eingaben ungefiltert an die entsprechenden Systembefehle wie ping oder traceroute weitergegeben. So auch beim RPD-150. Das folgende Bildschirmfoto zeigt, wie mit Hilfe der PING Funktion und Einbettung von Shellbefehlen ein Telnet-Server gestartet werden kann.

command_injection

Ein kurzer Test bestätigt den Start des Telnet-Servers, wie auf folgendem Bildschirmfoto zu sehen.

Bildschirmfoto - 20.04.2014 - 14:06:47

Ein laufender Telnet-Server ist aber nicht gleichbedeutung mit vollem Superuser-Zugriff auf den Router. Dafür muss ein Kennwort gebrochen werden. Da das Webinterface mit Root-Rechten ausgeführt wird (eine Eingabe von 127.0.0.1; echo $USER bestätigt das), ist die Gewinnung der Datei /etc/passwd kein Problem.

Sie enthält bei eingebetteten Systemen nicht nur die bekannten Informationen zu Benutzernamen und User-IDs, sondern darüber hinaus auch das gehashte Kennwort. Auf Desktop-Systemen wird es sonst in der Datei /etc/shadow/ gespeichert. Durch Ausnutzung der Schwachstelle mit dem Befehl 127.0.0.1; cat /etc/passwd kann der Inhalt der Datei gewonnen werden: root:C75rzlQ3E2Dkc:0:0:root:/:/bin/sh.

Das Kennwort des Superusers kann darauf folgend mit John the Ripper in kurzer Zeit gebrochen werden. Es lautet admin.

Mit dem Kennwort kann jetzt eine Verbindung als Superuser zum vorher gestarteten Telnet-Server hergestellt werden, wie das folgende Bildschirmfoto zeigt.

Bildschirmfoto - 17.04.2014 - 00:10:06

Die Schwachstelle ist natürlich nur geringfügig, da eine Anmeldung im Webinterface erforderlich ist.

Besonderer Dank an Inter-Tech, die sehr schnell reagierten und der Veröffentlichung des Artikels zugestimmt haben. Quelle des Produktfotos: Inter-Tech RPD-150 Bilderpaket.

Studienarbeit “Verteidigung externer Rechnerresourcen” (mit Linux)

In den letzten Wochen ist es leider etwas still im Blog geworden, besonders zum Thema IT-Sicherheit. Das liegt zum einen daran, dass ich meine Diplomarbeit schreibe. Aber auch daran, dass ich im Wintersemester 2013/14 am Lehrstuhl 4 an der TU-Dortmund eine Studienarbeit im Themenbereich IT-Sicherheit schreiben durfte.

Der Titel lautet “Verteidigung externer Rechnerresourcen – Risiken durch die Aufgabe der physikalischen Kontrolle und Gegenmaßnahmen am Beispiel gemieteter Linux Server“.


Studienarbeit Verteidigung externer Rechnerressourcen (PDF)

Darin beschreibe ich ausführlich die auftretenden Probleme, sobald dem Provider nicht mehr vertraut wird. Im Anschluss wird eine Taktik basierend auf Anti-Forensik und einfacher Militärtaktik entwickelt, die einen voll-verschlüsselten gemieteten Server noch etwas besser schützt, indem der forensische Prozess behindert wird. Mit Implementierung für Debian Linux.

Die Arbeit löst ausdrücklich nicht das Problem, dass bei gemieteten Servern keine Vertrauenswurzel existiert, bietet aber einige Verbesserungen an. Zu diesem Vertrauensproblem gibt es einiges im Chaosradio 199 ab 1:37:00 bis 1:39:30 zu hören, falls Interesse besteht.

WPA2 Enterprise mit FreeRADIUS und DD-Wrt in 5 Minuten

freeradius
Wenn WPA2-PSK mit einem einzigen Kennwort nicht mehr für die WLAN-Sicherheit genügt, bietet sich der Einsatz von WPA2 Enterprise, also der Authentifikation mittels EAP und TLS an. Wie das auch im Heimnetzwerk mit einem DD-Wrt Router und einem RADIUS-Server geht, erklärt der folgende Artikel.

Installation

Zuerst wird FreeRADIUS-Server installiert. Dabei wird automatisch ein selbst-signiertes Zertifikat erzeugt, dass den Hostnamen des Servers enthält.

apt-get install freeradius 

Wird der RADIUS-Server auf der Firewall installiert, muss er an die interne Netzwerkschnittstelle gebunden werden. Aber auch wenn das nicht der Fall ist, lohnt sich diese Sicherungsmaßnahme. Dafür werden in der Datei /etc/freeradius/radiusd.conf die zwei mit listen { beginnenden Blöcke bearbeitet und die beiden folgenden Konfigurationsanweisungen einkommentiert und mit den entsprechenden Werten gefüllt.

ipaddr = IPv4Intern
interface = ethIntern

Die Angabe zur IP-Adresse befindet sich für den auth Block um Zeile 273, für den acct Block um Zeile 316. Die Angabe zur Netzwerkschnittstelle befindet sich um Zeile 293 und Zeile 320.

Benutzernamenfilter

Folgend wird in der Datei /etc/freeradius/sites-enabled/default ein Sicherheitsfilter für Benutzernamen aktiviert, der dazu führt, dass Benutzernamen die mit Leerzeichen beginnen oder nicht von FreeRADIUS unterstützte Zeichenketten enthalten, nicht an den Authentifikationsmechanismus weitergegeben werden.

Um Zeile 79 Policy-Statement filter_username einkommentieren.

Client einrichten

Im nächsten Schritt wird die Zugriffsberechtigung und Authentifikation für den DD-Wrt Router eingerichtet. Der DD-Wrt Router wird als Client eingerichtet. Ein Client besteht aus einer Quell-IP, einem Gerätetyp und einem gemeinsamen secret. Bevor dies geschieht, sollte in der Datei /etc/freeradius/clients.conf um Zeile 101 das Kennwort für den lokalen Testzugriff auf den RADIUS-Server von testing123 auf einen geheimen Wert abgeändert werden.

Ist dies geschehen, kann die Konfiguration für den DD-Wrt Router an das Ende der Datei angefügt werden. Die IP-Adresse des DD-Wrt Routers ist in der Weboberfläche im Menü Status - LAN ablesbar. Das Format lautet wie folgt:

client dd-wrt {
        ipaddr = 192.168.XXX.XXX
        netmask = 32
        secret = meinGeheimesKennwort
        require_message_authenticator = no
        nastype     = other
}

Benutzer hinzufügen

Jetzt können die Benutzer an das Ende der Datei /etc/freeradius/users hinzugefügt werden. Das Format lautet wie folgt.

# Lokale User
user1    Password = "meinGeheimesKennwort"

DD-Wrt konfigurieren

Nach Neustart des FreeRADIUS-Servers mit dem Befehl /etc/init.d/freeradius restart kann der DD-Wrt Router konfiguriert werden. Im Menü WLAN – WLAN-Sicherheit kann der Radius gemeinsam mit dem secret eingetragen werden.
Bildschirmfoto - 13.03.2014 - 17:06:04

Proxmox VE 3.2 Beta-Version – Was gibts neues?

Wie im Forum angekündigt, ist Proxmox VE 3.2 als Beta-Version verfügbar. Was gibt es neues?

logo_prox

Neuer Kernel

Die größte Änderung besteht im Angebot des RHEL7 basierenden Kernels in Version 3.10, allerdings bisher nur mit Unterstützung von KVM-Virtualisierung und ohne OpenVZ. OpenVZ ist die in Proxmox eingesetzte Paravirtualisierungslösung. Ein Parallels-Entwickler (der Hersteller von OpenVZ) kündigt in seinem Blog die Portierung von OpenVZ für den RHEL7-Kernel an. Der neue Kernel wird darüber hinaus langfristig unterstützt werden. Zuständig für die Unterstützung ist die LTSI, oder kurz Greg Kroah-Hartman.

Die Proxmox-Entwickler haben dem Kernel für die Beta-Version einige Treiber für RAID- und Netzwerkkarten hinzugefügt.

Und natürlich enthält der neue Kernel auch deutliche Verbesserungen der Verschlüsselungs-Infrastruktur; falls der eigene Proxmox-Server verschlüsselt ist.

Neues Dateisystem

Eine weitere interessante Entwicklung ist die Einbindung von Ceph, einem verteilten Dateisystem. Die Vorteile für den Einsatz mit Proxmox finden sich hier.

Weiteres

featured-image

(Quelle: openvswitch.org)

Darüber hinaus bringt die Beta-Version von Proxmox VE 3.2 einen Ersatz für die auf Java basierende Web-Konsole: Spiceterm. Spiceterm wird seit August 2013 von Dietmar Maurer entwickelt. Die README-Datei des Entwicklungs-Repositories enthält weitere Informationen.

Auch Open vSwitch ist in der Beta enthalten, soweit ersichtlich ohne Änderungen gegenüber der Version in Debian wheezy. vSwitch könnte in Zukunft aufgrund des Funktionsumfangs und dem scheinbar besseren Maximaldurchsatz gegenüber den Linux bridge-utils interessant werden.

Danke an Tim R. für den Hinweis zur neuen Beta.

OpenVPN mit TUN/TAP in OpenVZ Instanz

Um in einer OpenVZ Instanz das TUN/TAP Gerät /dev/net/tun verwenden zu können sind einige kurze Schritte notwendig. Da die Hersteller-Dokumentation leider nicht fehlerfrei zum gewünschten Ergebnis führt, hier die Zusammenfassung.

Zuerst wird die eindeutige Identifikatiosnummer der OpenVZ Instanz bestimmt. Dann kann wie folgt auf dem Host fortgefahren werden. Um die Befehle erfolgreich absetzen zu können, muss die VM teilweise gestartet und teilweise gestoppt werden.

# Identifikationsnummer, zum Beispiel 106
VZID=106
vzctl stop $VZID
vzctl set $VZID --devnodes net/tun:rw --save
vzctl set $VZID --devices c:10:200:rw --save
vzctl set $VZID --capability net_admin:on --save
vzctl start $VZID
vzctl exec $VZID mkdir -p /dev/net
vzctl exec $VZID mknod /dev/net/tun c 10 200
vzctl exec $VZID chmod 600 /dev/net/tun

Die Fähigkeit net_admin kann zu einer reduzierten Abschottung zwischen Host und Gast führen. Eine Schwachstelle gab es bereits (2).