JHK

Seit längerem betreibe ich auf meinem Macbook bereits ein Tor-Relay. Allerdings gehöre ich zu der Spezies welche den Rechner regelmäßig ausschaltet, erst recht wenn ich das Haus verlasse. Der Tor-Node lief daher immer nur abends und manchmal auch Nachts wenn ich zu Hause war. Ein solcher On-/Off-Node ist für das Tornetzwerk natürlich nicht optimal. Meine eigentlichen Arbeitsmaschinen wollte ich allerdings nicht für einen 24/7-Betrieb zweckentfremden. Also habe ich, nicht aktiv nur immer wieder mal, nach Alternativen umgesehen. Da bei uns auf der Arbeit das Thema Raspberry Pi hoch kam dachte ich mir ich könnte ja mal einen Blick drauf werfen. Gesagt getan.

Zur Einrichtung habe ich als System ein Macbook Air mit MacOSX 10.8.3 genutzt. Aufgrund des Unix-Unterbaus waren die Schritte zur Einrichtung unkompliziert und mit Hausmitteln zu erledigen.

Hardware

Natürlich ein relevanter Punkt gerade da der Raspberry ja immer als günstige Alternative für zum Beispiel MediaCenter genannt wird.

Raspberry Pi (ca. 45 €)
Stromadapter (ca. 7,5 €)
Netzwerkkabel (ca. 13 €)
SDHC Karte (8GB, ca 8€)
Gehäuse (ca. 9 €)

Macht also insgesamt knapp 80 €. Geht billiger, gerade beim Netzteil. Doch für das erste Gerät bin ich zufrieden. Und die Lieferzeit von einem Tag bei Amazon war es mir wert :)

Eine separate Maus und Tastatur ist nicht erforderlich, das Raspberry wird lediglich per SSH angesprochen.

Image besorgen

Da der Raspberry ohne Betriebssystem nicht läuft muss eines organisiert werden. Genutzt habe ich dafür die auf Debian basierende Distribution “Raspbian” Nach dem Download die Prüfsumme überprüfen und los geht es. Für meine Zwecke habe ich mich an das aktuelle Image vom 09.02.2013 gehalten.

Entpacken

unzip ~/2013-02-09-wheezy-raspbian.zip

Auf die SD-Karte schieben

sudo dd bs=4M if=~/2013-02-09-wheezy-raspbian.img of=/dev/sdd*

Bei diesem Schritt ist Vorsicht angesagt. Wer hier das falsche Gerät erwischt kann sich problemlos die Datei eines anderen Datenträgers vernichten. Die Zahl welche beim * eingetragen werden muss ist daher genau zu kontrollieren.

Dieser Schritt kann gerne einmal mehrere Minunten dauern. dd gibt darüber hinaus auch keine Zwischeninfos heraus sondern meldet sich erst wieder wenn der gesamte Vorgang abgeschlossen ist.

Im Grunde steht damit das Basissystem. Das Image wurde für DHCP vorbereitet was bedeutet das je nach eigener Netzwerkinfrastruktur keine weiteren Schritte mehr notwendig sind. Ich schiebe also die SD-Karte nun in den Raspberry, schließe das Netzwerkkabel an und gebe Saft auf die Buchse. Die Kontrolllampen blinken und nichts explodiert. Der erste Schritt ist damit erledigt.

In der Rückbetrachtung war dieser Schritt auch jener welche die meiste Zeit verbrauchte. Ich denke mit einer schnelleren SD-Karte, Class 10 anstatt meiner Class 4 zum Beispiel, lässt sich da noch ordentlich was rausholen.

Router konfigurieren

In meinem Router muss ich jedoch noch ein paar Einstellungen vornehmen. Zum einen sage ich dem Gerät das mein neuer Raspberry immer die selbe IP-Adresse bekommen soll. Zum anderen schalte ich die beiden von Tor verwendeten Ports frei. Dies sind in der Regel 9001 und 9030. Bei diesen Einstellungen habe ich es auch belassen. Als drittes erlaube ich dem Raspberry allgemein sich in meinem Netzwerk zu bewegen und mit dem Internet Kontakt aufzubauen. In der Regel wird dies bei mir unbekannten Geräten verweigert. Da die Konfiguration im Einzelnen von Router zu Router unterschiedlich ist spare ich mir hier eine Anleitung.

Erste Kontaktaufnahme

Raspberry-Image geladen, Router entsprechend eingestellt, nun kann der erste Kontakt hergestellt werden. Terminal gestartet und mittels SSH der Raspberry angesprochen

ssh pi@192.168.0.01

Die IP-Adresse ist hier nur als Beispiel anzusehen und spiegelt nicht mein Netzwerk wieder. "pi" ist der Standardbenutzer mit welchem das Raspbianimage ausgeliefert wird. Das Standardpasswort dieses Benutzers lautet "raspberry". Auf y und z beim Tastaturlayout achten ;)

Ab hier erfolgen alle weiteren Schritte lediglich per SSH-Terminal.

Passwort neu setzen

Als erstes wird das Passwort neu gesetzt. Das alte passwd hilft hier weiter. Nun kann ich die folgenden Schritte in "Ruhe" angehen.

Neuen Rootbenutzer anlegen

Jede Person welche die Information besitzt das ein Raspbian zur Einrichtung genutzt wurde kennt auch den Standardbenutzer und dessen Passwort. Also lege ich mit den üblichen Werkzeugen einen neuen Benutzer. Die konkrete Durchführung erspare ich mir daher an dieser Stelle.

Partitionierung anpassen

Das vorher auf die SD-Karte geschobene Image ist natürlich kleiner wie der maximal auf der Karte verfügbare Platz. Um diesen auch nutzen zu können muss die Partition der Karte erweitert werden. Dazu dient das übliche Tool parted.

System aktualisieren

Das Image war ja nun "ein paar" Tage alt. Also sorge ich erst einmal für eine Aktualisierung:

sudo apt-get updatesudo apt-get upgrade

Fertig, System aktualisiert. Da mein Raspbian selbstverständlich auch in Zukunft noch aktuell sein soll setze ich direkt mehrere Cronjobs hierzu auf.

# Das System aktuell und sauber halten

0 1 * * 1 apt-get update -y

0 3 * * 1 apt-get upgrade -y

0 5 * * 1 apt-get clean -y

0 7 * * 1 apt-get remove -y

0 2 1 * * apt-get dist-upgrade -y

Thema erledigt. System wird nun an jedem Montag aktualisiert.

Locate

Reine Bequemlichkeit und an sich kein Thema um den Server abzusichern. Der Befehl locate damit ich schnell Dateien im gesamten System auffinden kann.

sudo apt-get install locate

Fertig.

Tor installieren

Nun die eigentliche Anwendung, Tor.

sudo apt-get install tor

Da ich ab und an dann dochmal einen Blick auf den Server werfen möchte um mir den Status des Tor-Relays anzusehen wird auch gleich noch das Tool ARM installiert

sudo apt-get install tor-arm

Tor ist nun theoretisch einsatzbereit. Doch auch hier sind noch ein paar Anpassungen an der Konfiguration unter /etc/tor/torrc erforderlich. Also ein schnelles

sudo nano /etc/tor/torrc

und los geht es.

Tor konfigurieren

Interessant sind hier für mich nur eine handvoll von Einstellungen:

Nickname AliasName

RelayBandwidthRate 100 KB

RelayBandwidthBurst 200 KB

ContactInfo your@email.com

ExitPolicy reject *:*

Diese Einstellungen bedeuten im Einzelnen:

Der Nickname beschreibt den Namen des Nodes und dient lediglich zur einfacheren Identifikation. Tatsächlich nebensächlich da jeder Node einen eigenen Fingerprint besitzt. Mit RelayBandwidthRate und RelayBandwithBurst sage ich Tor im Grunde wieviel meiner Bandbreite zur Verfügung steht. Die vorgegebenen 100 KB sind mit 8 zu multiplizieren. Konkret bedeutet die Angabe also das ich 800 kb/s erlaube. Schaft meine Leitung locker und ich nutze sie sowieso nie aus. "Burst" ist für die temporären Spitzen gedacht wenn Tor gerade ein hohes Volumen schaufelt. So kann ggf. noch eine Verbindung bearbeitet werden bevor runter geregelt wird ohne direkt eine Verbindung abzulehnen. ContactInfo dient dazu damit mit mir bei Bedarf Kontakt aufgenommen werden kann. Ich empfehle hierfür eine eigene Adresse anzulegen. Denn diese Adresse ist durch diverse Übersichtsseiten auch von Google lesbar. Und zuletzt noch die wichtige ExitPolicy. Diese regelt wir mein Node genutzt werden kann. Das von mit vergebene "reject *:*" bedeutet im Klartext das mein Noden nur als Relay arbeitet und kein Ausgang für das Tor-Netzwerk ist.

Torserver neu starten und alles läuft wie geplant:

sudo /etc/init.d/tor restart

Meine vollständige Konfigurationsdatei ist unter Pastebin.com abgelegt:

Nun kann ich bereits einen ersten Blick auf meinen Node werfen. Dazu wird nun das vorhin installiert Tool Tor-Arm aufgerufen:

sudo -u debian-tor arm

Das wird nun mit ein paar bunten Bildern quittiert.

Nachdem nun der Tornode steht kann ich mich um den Rest des Servers kümmern.

Nodestatus per Email

Selbstverständlich kann ich nicht rund um die Uhr auf den Server blicken um den Status zu überprüfen. Hier springt eine externe Webseite namens Tor Weather ein. Sobald mein Node einmal nicht erreichbar ist werde ich fortan per Email informiert. Das sieht dann beispielhaft so aus:

Nodestatus per Webseite

Was per Email geht ist natürlich auch auf Webseiten möglich. Eine, welche mir aufgrund ihrer Einfachheit zusagt, ist http://torstatus.blutmagie.de/. Der Vorteil ist das ich anhand des Fingerprints meines Nodes diesen auch unter einer festen Adresse ansprechen kann.
Doch dazu eine Warnung. Es gibt Webfilter welche die Seite blockieren. Der häufigste Grund welchen ich sehen konnte ist "Proxy Avoidance". Also Sperrung wegen vermeintlicher Umgehung eines Proxys. Trifft zwar nicht zu doch ich vermute das hier generell Tor geflaggt ist.

Logdateien entsorgen

Warum mögen sicherlich nun einige Fragen sollte man denn Logs klein halten und löschen? Nun, aus zwei einfachen Gründen. Zum einen ist der Platz auf der von mir verwendeten SD-Karte begrenzt. Zum anderen kann ich, wenn das Tor-Log gar nicht erst da ist auch keine Infos dazu herausgeben.

Also wird ein neuer Cronjob angelegt:

# Tor Log klein halten 0/10 * * * * truncate -s 9 /var/log/tor/log

Dies sorgt dafür das alle 10 Minuten das Log auf die letzten 9 Einträge gekürzt wird. Zu überlegen ist hier noch ob ich das Log direkt nach /dev/null umleiten kann. Das wird jedoch zu einem späteren Zeitpunkt noch geprüft.

Daneben gibt es noch ein paar andere Logs welche ich nicht gerne entsorgt sehen möchte. Also werden auch diese alle 10 Minuten komplett geleert.

# Sonstige Logs des Systemes leeren
1/10 * * * * * truncate -s 0 /var/log/user.log

Prüfung auf Rootkits

Bei einem System welches quasi rund um die Uhr mit dem Internet verbunden ist sehe ich es als notwendig an die Sicherheit weiter aufzudrehen. Ein Schritt dazu ist überprüfen zu können ob ein Angreifer es ggf. geschafft hat ein Rootkit zu installieren. Also wird wieder apt bemüht:

Programm chkrootkit installieren

sudo apt-get install chkrootkit

Selbstverständlich soll das ganze täglich laufen. Dies kann zum einen in der Datei /etc/chkrootkit.conf eingestellt werden. Dazu muss der Parameter RUN_DAILY wie folgt gesetzt werden:

RUN_DAILY="true"

Das ganze kann natürlich auch mittels Cronjob gelöst werden. Und da ich nicht jeden Tag auf dem Raspberry einloggen will lasse ich mir die Protokolle hiervon direkt zusenden:

0 3 * * * root (cd /usr/sbin; ./chkrootkit 2>&1 | mail -s "chkrootkit output" your@email.com)

Da ich allerdings ungern nur einem Programm vertraue wird gleich noch ein zweites zur Suche nach Rootkits genutzt. Die Wahl viel dann auf RKHunter.

Programm RKHunter installieren und aktualisieren

sudo apt-get install rkhunter
sudo rkhunter --update

Ein erster Scan kann nie schaden, daher:

sudo rkkunter -c --sk

RKHunter gab mir bei der Datei /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so eine Warning. Schnell recherchier kam ich zu dem Schluss das diese Datei nicht für meine Zwecke benötigt wird. Also weg damit:

apt-get remove raspi-copies-and-fills

Da rkhunter aus den Paketquellen installiert wurde gibt es sofort einen Eintrag unter /etc/cron.daily/ Täglich wird nun also auch mittels RKHunter überprüft ob das System kompromittiert wurde.

Anschließend wird noch eingestellt das nette Mails versandt werden /etc/rkhunter.conf nach der Einstellung “MAIL_ON_WARNING”. Anpassung simpel, einfach die eigene Mailadresse eintragen.

MAIL-ON-WARNING="your@email.com"

RKHunter sollte nach der Installation noch antrainiert werden damit es nicht zu Falschmeldungen kommt. Dies ist jedoch ein eigenes Thema für sich. Ich verweise daher an dieser Stelle auf die Seite

Mitteilung wenn ein Root Login erfolgt

Ein einfacher Weg festzustellen wenn ein Login durch den Adminbenutzer erfolgt ist in diesem Moment eine Email zu verwenden.
Also schreibe ich in die Datei ~.bash_profile folgende Zeile:

echo 'ALERT - Root Shell Access on:' `date` `who` | mail -s "Alert: Root Access from `who | awk '{print $6}'`" your@email.com

Erledigt. Und schon erhalte ich bei einem Log-In eine Benachrichtigung. Da ich davon aus gehe das ich noch soweit fit im Kopf bin das ich zuordnen kann ob ein Login von mir erfolgt oder nicht sollte ich eine gute Info darüber erhalten ob sich jemand unbefugt Zugang zum Raspberry verschafft.

SSH-Logins absichern

Auch dieser Punkt ist schnell abgehakt durch eine Anpassung in der Datei /etc/ssh/sshd_config Hier passen wir die folgende Zeile wie folgt an:

#PermitRootLogin yes

auf

#PermitRootLogin no

Erledigt.

Brute Force Detection Installation

Manchmal kann natürlich auch die Situation auftreten das rohe Gewalt verwendet wird um Zugang zu erlangen. Auch hierfür gibt es Wege dieses zu entdecken. Brute Force Detection nennt sich das Tool. Dieses habe ich nicht im Repository gefunden daher erfolgt die Installation "manuell".

cd ~

wget http://www.rfxnetworks.com/downloads/bfd-current.tar.gz

tar -xvzf bfd-current.tar.gz

cd bfd-1.5

./install.sh

Auch hier ist die Konfiguration entscheidend welche unter /usr/local/bfd/conf.bfd abgelegt ist. Auch hier empfiehlt es sich eine Mailbenachrichtigung zu aktivieren.

Also wie gehabt die sudo nano-Kombination

sudo nano /usr/local/bfd/conf.bfd

und folgende Einstellungen anpassen:

# send email alerts for all events [0 = off; 1 = on]

EMAIL_ALERTS="1"

# local user or email address alerts are sent to (separate multiple with comma)

EMAIL_ADDRESS="your@email.com"

Während der Installation wird auch gleich ein Cronjob unter /etc/cron.d/bfd angelegt welcher alle drei Minuten aktiviert wird. Ein weiterer Eintrag in der Crontabelle ist daher nicht mehr notwendig.

Emailversand ermöglichen

Jetzt habe ich bei so vielen Schritten angegeben das ich eine Benachrichtigung per Email erhalten möchte und mein System ist noch gar nicht dafür vorbereitet. Also ran:

Notwendige Pakete installieren

sudo apt-get install exim4-daemon-light mailutils

Danach zur Konfiguration:

dpkg-reconfigure exim4-config

Und fertig.

Hierzu habe ich auf die Anleitung unter linode.com zurück gegriffen.

Nachwort zum Thema Sicherheit

Mir ist klar das ich hier sicherlich noch kein bombensicheres System geschaffen habe. Das kann es wie ich denke auch nie geben.

Ein weiterer großer Nachteil ist natürlich der Raspberry an sich. Sollte sich jemand Zugang zum Raspberrystandort verschaffen ist die SD-Karte und damit das System nicht mehr sicher. Vielleicht kann ich zu einem späteren Zeitpunkt einmal darüber nachdenken das Dateisystem auf der SD-Karte zu verschlüsseln. Das ist jedoch für meinen Anwendungsfall paranoide Zukunftsmusik. Zumal ich wohl auch ernstere Sorgen haben werde wenn sich jemand sogar Zugang zu meinen Räumlichkeiten verschaffen sollte. Da ist dann der Raspberry wohl auf einer niedrigeren Priorität.

Weiterhin habe ich bei sehr vielen Komponenten eine Emailbenachrichtigung aktiviert. Hier wird die Zeit zeigen ob das derzeitige Level in Ordnung ist oder das Mailaufkommen zu viel wird. Wenn dem so ist kann ich immer noch die Konfigurationen anpassen.

Offene Punkte

Software ausmisten

In der regulären Installation von Raspbian ist auch sehr viel enthalten was ich zum Betrieb des Tornodes nicht benötige. Hier werde ich in der nächsten Zeit noch die Liste filzen um nicht benötigte Komponenten zu entfernen. Insbesondere der Blick auf die derzeit noch vorhandenen Entwicklungssprachen und-werkzeuge wird wichtig sein. Wenn das System einmal eingerichtet ist werde ich hier kräfitig entsorgen können.

Tor-Logs weiter einschränken

Offen ist ebenfalls ob ich die Logdateien von Tor direkt nach /dev/null umleiten kann. So könnte der Node keine Infos verraten. Doch hier muss ich erst prüfen ob es möglich ist und was als "best practise" empfohlen wird. Doch eines nach dem anderen.

Nodestatus sichern

Regelmäßig die Infoseite des Nodes sichern und als PDF ablegen. Dient für mich rein zu Infozwecken.

Abgehende Emails signieren

Interessant, und auch eher eine Spielerei, ist die Frage ob ich die Emails automatisch mittels GPG signieren kann. Geht sicherlich. Wird dann eines der langfristigen Projekte.

Image sichern

Wenn ich irgendwann einmal der Meinung bin nun einen vernünftigen Stand erreicht zu haben werde ich die SD-Karte als neues Image sichern. Das wird mir die Einrichtungsarbeit bei zukünftigen Raspberrys, insbesondere bei jenen welche dauerhaft mit dem Internet verbunden sind, erleichtern. Und eine Sicherung kann nie schaden.

Ausblick

Wenn die bisherigen positiven Erfahren auch nach vier Wochen immer noch andauern werde ich mir noch mindestens einen weiteren Raspberry Pi zulegen. So ein eigenen yacy-Node reizt mich ja schon.

Dienstag, 2. April 2013

Raspberry Pi als Tor Node