Kleine und große Linux AHAs
Beiträge getaggt mit netzwerk
Asterisk Projekt: Season 3 – malen nach Zahlen
28. Sep
Bisher habe ich beschrieben was gebraucht, bzw. eingesetzt wird. Wie sieht das ganze nun aus?? Lasset uns malen …
Was ich bisher noch nicht erwähnt hatte waren die VLANs. Das “normale” Netzwerk wird von dem VoIP Netz separiert. Das macht man um das VoIP Netz möglichst sauber zu halten von unnötigem Traffic.
Gateways in einer eigenen Welt
In diesem Szenario haben die Patton Geräte quasi eine eigene Welt für sich. Sie befinden sich natürlich in einem Netz mit den Telefonen und dem SIP Server, allerdings machen die Boxen beispielsweise das Analogrouting komplett alleine. Um einen analogen Anruf (Anruf, Fax, Modem) zu handeln wird der SIP Server nicht genutzt. Der Anruf geht von der Patton 4960 (an dem E1 Anschluss) direkt auf die 4118 und zum Endgerät. Dazu sind Routen auf den Geräten definiert. Der Vorteil ist dass nur wenige Geräte beteiligt sind und diese Geräte über die gleichen Fähigkeiten verfügen. Es gibt zwischen den Patton Geräten keine Probleme wenn es um das aushandeln von Parametern geht – was gerade bei Faxgeräten extrem wichtig ist.
Lediglich ein normaler Sprachanruf wird von der 4960 zum SIP Server durchgestellt und von diesem verarbeitet, bzw. an das Endgerät geroutet.
Telefon vermittelt zwischen VLANs
Ein Vorteil der VoIP Technik ist die Verkabelung. Man benötigt lediglich Netzwerk. Um das ganze auch wirklich sinnvoll zu machen haben die Telefone zwei Netzwerkports. Einen für die Versorgung mit dem Netzwerk an sich und einen für den Anschluß eines PCs. Man benötigt also für PC und Telefon nur einen Netzwerkanschluss. Da wir mit den Telefonen ein eigenes VLAN betreiben separiert das Telefon den PC in ein anderes VLAN. In unserem Beispiel arbeitet das Telefon in VLAN 3 und der PC in VLAN 20. Das Telefon wird also über einen Trunk Port an den Switch angeschlossen.
Neue Serie: Asterisk Projekt – erst einmal Vortasten
22. Sep
Zur Zeit ist es “Inn” auch innerhalb von Firmen auf VoIP umzustellen. Das ganze macht auch durchaus Sinn. Die Installationskosten lassen sich damit drücken – schon alleine von der Verkabelung her da lediglich Netzwerk benötigt wird. Ansonsten verlangen die klassichen Telefonanlagenanbieter auch recht hohe Wartungskosten. Oft für Anlagen, an die moderne Funktionen immer nur “angebaut” werden. Des Weiteren gibt trotz der Abhängigkeiten vom Hersteller (bspw. Systemtelefone) auch noch weitere Lizenzmodelle. Beispielsweise kostet jeder Post oder auch jeder SIP Account.
Das ganze kann man sich mit Hilfe der freien Anlagen sparen und ist noch dazu – ein wenig Erfahrung vorausgesetzt – um einiges flexibler. Als ich mit dem Projekt begonnen habe hatte ich quasi keine Ahnung von Asterisk und dem Aufbau einer solchen produktiven Anlage. Mittlerweile hab ich dann doch einiges an Know-How aufgebaut. Der Grund warum ich daraus auch wieder eine Reihe auf linux-aha machen möchte: Es gibt nur recht wenig Dokumentation für Business Anforderungen. Ich musste mir viel an Informationen zusammen suchen und genau das ist das, was hier nun hin soll.
Was sind die Anforderungen?
Welche Anforderungen gibt es an eine Telefonanlage innerhalb eines Unternehmens? Wir haben das “einfach” so gemacht, dass wir den Ist Stand als Minimum definiert haben und das Ziel mehr zu bieten. Die “normalen” Anforderungen sind von uns also quasi so definiert:
- Rufumleitung
- Rufweiterleitung
- Anrufergruppen
- Warteschleifen / Queues
- Mailboxen
- Auswertungsmöglichkeiten
- Anbindung an externe Systeme
- Mobilteile (DECT)
- Skalierbarkeit
- Verfügbarkeit
- Offenheit (keine Bindung an Hersteller, Schnittstellen)
- interaktive Menüs
- Ansagen, auch Zeitgesteuert
Nur Asterisk?
Am bekanntesten ist natürlich Asterisk – die OpenSource Anlage. Es gibt auch viele andere. Wir haben uns für Asterisk entschieden, da es dort die größte Community gibt und die Software einfach auch am längsten verfügbar ist. Wobei der Part mit der Community mich dann doch an der ein oder anderen Stelle ein wenig enttäuscht hat.
Eine potenziell mögliche Alternative ist freeswitch. Freeswitch ist wohl – und das hab ich nun nicht weiter geprüft – aus Asterisk entstanden aber hat mit einigen Altlasten aufgeräumt. Ich habe es nie getestet, da uns das ganze als noch zu früh beschrieben wurde.
Großer Kasten oder wie?
Telefonanlagen sind oft recht große Kästen. Ein Haufen Steckkarten, Netzteile und ….
Kann den eine VoIP Anlage das gleiche leisten? Naja, schon. Die eigentliche VoIP Anlage ist ja zuerst einmal ein Server. Der Server muss eine gewisse Leistung haben um x gleichzeitige Anrufe verwalten zu können. Der Server ist also zuerst einmal vergleichbar mit dieser großen Kiste. Nun hat der Server jedoch keine Anschlußmöglichkeiten für analoge Telefone, für Faxgeräte oder auch für den Zugang zum PSTN (zum öffentlichen Telefonnetz). Um diese Anschlußmöglichkeiten zur Verfügung zu stellen gibt es nun mehrere Möglichkeiten. Man kann auf der einen Seite den Server genau so nutzen wie die große Kiste vom klassischen Anbieter. Man nimmt einen Server der einige Steckplätze hat und baut dort dann Karten ein, welche die gewünschten Ports zur Verfügung stellen. Bis zu einem gewissen Maß mag das funktionieren. Allerdings birgt das ganze einen recht großen Nachteil. Die Karten müssen vom Betriebssystem und auch von der VoIP Software unterstützt werden. Das mag am Anfang nicht das Problem sein. Was ist aber bei einem Update? Update des OS, bzw. der VoIP Software? Mit jedem Update stellt sich damit immer wieder nicht nur die Frage ob die Software noch läuft, sondern auch ob die Hardware noch läuft. Das ist nicht wirklich wünschenswert – wenn vermeidbar
Vermeiden lässt das ganze sich durch sogenannte Gateways. Gateways sind in dem Fall schwarze Boxen die beispielsweise einen Ethernet und 8 analoge Ports zur Verfügung stellen oder auch einfach die Schnittstelle zum PSTN darstellen. Sie wandeln beispielsweise das SIP Protokoll (bzw. RTP, T.38) in analoge Signale um das ganze kompatibel zu einem Faxgerät zu machen. Wir setzen dabei die Geräte der Firma Patton (www.patton.com) ein. Die Geräte sind ein wenig teurer, wurden uns jedoch als Qualitativ hochwertig und zuverlässig empfohlen. Damit hat man kein Problem mehr mit Updates und ist dazu noch nach oben hin skalierbar. Braucht man weitere Ports, so kommt eine weitere Box dazu und gut. Die Konfiguration ist recht einfach – darauf wird später nocheinmal eingegangen.
— Soweit Teil 1 —
Unleserliches debuggen, oder: Fehlersuche in verschlüsselten Protokollen
03. Mai
Immer mehr Datenverkehr wird verschlüsselt. Einerseits natürlich richtig und gut. Andererseits ein Problem. Früher konnte man mit Hilfe von Tools wie Wireshark (Ethereal) oder tcpdump relativ schnell Probleme (z.B.) in der Kommunikation zwischen Programm und Server herausfinden. Einfach den Netzwerkverkehr mitschneiden, ansehen / auswerten und es zeigten sich Fehler die man im Programm möglicherweise nicht zu Gesicht bekommen hat.
Mittlerweile sind die Pakete weitestgehend verschlüsselt und man kann nicht mehr einfach so “mit schreiben” – naja, man kann natürlich; aber lesen kann man es nicht. Also fällt ein mitschreiben – einfach mal so – flach.
Eine andere Möglichkeit die Kommunikation zwischen Programmen zu debuggen ist, sich einfach manuell zu verbinden und die Kommandos direkt einzugeben um zu prüfen ob der Server richtig reagiert. Dazu nahm man früher telnet … Auch telnet ist kein Kandidat mehr für verschlüsselte Protokolle.
Verbindung zu einem SSL geschützten Dienst
Eine Möglichkeit sich auf einen solchen Dienst zu verbinden bietet der Befehl
openssl s_client -connect <Zielrechner>:<Port>
Mit diesem Befehl kann man sich beispielsweise direkt auf einen per SSL geschützten IMAP Server (Port 993) verbinden und manuell Kommandos absetzen. Das ganze über eine SSL geschützte Verbindung – die nicht mitgeschnitten werden kann
Ganz wie früher mit telnet *freu*
Daten auf NAS – aber bitte sicherererer
12. Apr
Vor genau einem Jahr habe ich einen Artikel geschrieben der sich mit einem NAS für zu Hause mit iSCSI beschäftigte (s. Teil I, Teil II, Teil III). Mittlerweile habe ich mir ein neues NAS gekauft – ein Synology DS411slim (Link). Was hat mich nun zu diesem NAS System gebracht? Kurz gesagt: Denny
Nee, im Ernst. Die Unterschiede zwischen den Systemen (und ich spreche nur von den Home NAS Systemen) ist sehr identisch. Man bekommt sehr billige die – laut Beschreibung – sämtliche Protokolle unterstützen und auch schnell sein sollen. Man bekommt teure die das gleiche versprechen.
Natürlich gibt es Unterschiede. Ein wichtiger Faktor ist beispielsweise die Lautstärke. Hat das System Lüfter? Welche größe haben sie? Laufen sie immer? Auch die Plattendimension macht einen Unterschied bei der Lautstärke – 3,5″ oder 2,5″? Für uns hier interessant: Mit welchem OS wird das System betrieben? Linux? Bei komplett fertigen Systemen ist auch die Frage welche Festplatten eingebaut sind oder ob 2x die gleiche oder verschiedene eingebaut sind. Das kenne ich aus dem Enterprise Umfeld, wo man zusieht dass in einem Plattensystem nicht eine komplette Serie verbaut ist – hat die einen Fehler, so hat mein ganzes System ein Problem. Das zu Hause zu bedenken mag dem ein oder anderen übertrieben erscheinen, allerdings ist das recht kostenneutral 2 oder mehrere Platten von verschiedenen Serien oder Herstellern zu nehmen – also warum nicht?
Das aber nur als kleines Vorwort
Darum Synology für mich
Ich habe mich für Synology entschieden, weil
- OS ist Linux
- Shellzugriff (bisher nicht benötigt aber möglich)
- erweiterbar über Pakete
- intuitive Benutzeroberfläche
- sehr nützliche Softwarefeatures
- das Gerät wurde als extrem leise getestet (stimmt auch)
- extrem klein, da nur 2,5″ Festplatten eingebaut werden können
- Raid im nachhinein erweiterbar
- geringer Stromverbrauch, gerade auch wegen den 2,5″ Platten
Nun kann man sagen das ganze sind keine Alleinstellungsmerkmale und diese Features haben viele NAS Systeme verschiedener Hersteller. Richtig. Aber:
- Von Synology gibt es gibt Apps für Android und iPhone, mit denen man bequem auf die Bilder, Musik und auch die Dateien auf der Box von überall zugreifen kann
Das war für mich das ausschlaggebende Argument.
Sicherheit der Daten
Das eigentliche Thema dieses Beitrags ist die Datensicherheit auf einer solchen Box. Ich habe einiges an Dokumenten die eine gewisse Sicherheit benötigen. Kann ich diese dann einfach per NFS oder Samba auf eine NAS Box legen? Meiner Meinung nach nicht.
Was passiert wenn die Box gehackt wird? Was wenn sie gestohlen wird? Der Hersteller muss nur einen Softwarefehler in der Firmware haben und die Daten stehen jedem offen. Alles natürlich nur dann, wenn die Box per DynDNS von Außen erreichbar ist (Apps!).
Nun bietet Synology an, die Daten eines “Gemeinsamen Ordners” per integriertem AES Chip zu verschlüsseln. Gut. Aber wie funktioniert das? Naja, so wie es eben nur möglich ist. Das Volume ist verschlüsselt. Um darauf zuzugreifen muss man entweder vorher per Benutzeroberfläche das Volume entsperren oder man lässt es beim booten entsperren. Hmmm… Also der Sinn das ganze beim Booten automatisch machen zu lassen erschließt sich mir auf Anhieb nicht und vor jedem Zugriff das Volume über die Benutzeroberfläche zu entsperren, bzw. danach wieder zu sperren, ist nicht wirklich benutzerfreundlich. Eine andere Möglichkeit gibt es jedoch so direkt nicht.
Container?
Am Anfang dachte ich, man könnte das ganze mit einem Container machen. Beispielsweise mit TrueCrypt. In Nautilus auf den Container klicken, Passwort eingeben und glücklich sein. Nada. TrueCrypt kann nicht mit Samba Laufwerken umgehen
(wenigstens nicht so über Nautilus).
Also das Verzeichnis direkt beim Booten mounten? Auch unschön. Der NetworkManager ist bei mir für die Netze verantwortlich. Also ist ein mounten von Laufwerken über die fstab nicht so einfach möglich.
iSCSI!!
Tja, nach einigem überlegen bin ich dann auf meinen eigenen Artikel gekommen
. Warum nicht iSCSI? Die Box macht das und ich könnte – mit Linux Standardmitteln – die Daten verschlüsseln. Gedacht, getan. Ein iSCSI Target auf der Box angelegt. Und wie schon in meinem anderen Artikel das LUKS Device angelegt, formatiert und gut.
Sobald der NetworkManager ein Device konfiguriert hat, erscheint in Nautlilus ein neues Gerät. Anklicken, Passwort eingeben (oder beim ersten Mal speichern) und schon bin ich auf der Box in einem verschlüsselten Volume.
Problem
Es gibt an sich nur ein Problem mit der Lösung. Es kann immer nur einer darauf zugreifen (zur selben Zeit). Das ist für mich kein Problem, da es sich nur um die Sicherheitsbedürtigen Daten handelt. Alle anderen Dateien sind von mehreren Rechnern gleichzeitig zugreifbar.
Schizophrene Router überwachen
25. Mrz
Es geht um redundante Internetanbindungen. Bekommt man diese von seinem Provider installiert, so hat man zwei Router in seinem Rechenzentrum stehen. Beide Router haben eine IP Addresse und halten eine weitere, virtuelle Addresse dei das Gateway darstellt.
Unterschiedliche Bandbreiten
Nun ist es so, dass man nur selten zweimal mit der identischen Bandbreite angebunden wird. Beispielsweise – auch je nach Standort – kann es sein, dass man nur 10% der normalen Leistung auf dem Backupmedium hat. So ist es natürlich wichtig zu wissen wenn die Hauptleitung ausfällt um einerseits das Problem zu melden und auch andererseits vielleicht diverse Dienste abzuschalten. Nur wie kann man erkennen welcher Router gerade aktiv ist? SNMP Zugriff ist meist auf Providerrouter nicht möglich – warum auch immer.
Welcher ist aktiv?
Wir hatten dann zuerst geplant die MAC Addresse über ARP zu prüfen – wenn sie sich ändert wäre der Router umgeschaltet worden. Leider nimmt HSRP (Hot-Standby-Routing-Protocoll) die MAC Addresse mit. Also ging das auch nicht. Was dann ging ist das ganze per traceroute zu machen. Traceroute zeigt als einen Hop eine der festen IPs der Router. Auf diese Weise kann man also bestimmen welcher Router gerade aktiv ist.
Das Script dazu
#!/bin/bash
# Dieses Script prueft per traceroute welcher
# Router gerade aktiv ist.
#
# Da wir keinen Zugriff auf die Router haben
# (snmp oder anders) musste das so gemacht werden.
#
# Ronny Becker, 03.2011
# Gateway IPs
PRI_GW=""
SEC_GW=""
# HOPs to GW
GW_HOPCOUNT="2"
# Check Target(s)
TEST_TARGET="www.heise.de www.google.de"
# Do your job
for TARGET in $TEST_TARGET
do
# run trace
TRACE=$(traceroute -m $GW_HOPCOUNT $TARGET 2>&1)
if [ $? != 0 ]
then
continue
fi
# check if primary matches
if [[ $TRACE =~ $PRI_GW ]]
then
echo "Primary Gateway active"
exit 0
fi
# check if secondary matches
if [[ $TRACE =~ $SEC_GW ]]
then
echo "Seconday Gateway active"
exit 1
fi
done
echo "Unknown Gateway status"
exit 2
Das Script ist so gemacht, dass es von Nagios genutzt werden muss. Wer das ganze auf Mail umstellen möchte muss halt ein paar Änderungen vornehmen.
Piwik Selbstversuch: Sehr schön – und diese Farben …
22. Feb
Durch einen Planetenartikel bin ich auf Piwik aufmerksam geworden (ja ok, Denny hatte mir schon vorher mal davon erzählt).
Da ich selbst einen Blog schreibe (Ohhh, echt?) interessiere ich mich natürlich schon dafür, wer sich so auf meiner Seite tummelt. Das ist rein fürs Ego, da sich auf meiner Seite ja keine Werbung befindet
Bisher hatte ich ein Plugin für WordPress genutzt – StatPress – welches mir einige Informationen lieferte, jedoch lange nicht so hübsch wie Piwik. Des Weiteren liefert Piwik auch einige Details mehr über den Browser bzw. das Surfverhalten.
Also gesagt getan Piwik auf meinem Webspace installiert. Dann ein WordPress Plugin (WP Piwik) dazu, welches mir das Editieren von Header / Footer Seiten abnimmt und mich lediglich nach der URL und einem authkey für die Piwik Installation fragt. Alles prima – es funktioniert und ständig trudeln neue Datensätze ein.
Warum nochmal?
Warum ich das ganze nochmal hier schreibe? Ich sehe das ganze ein wenig mehr aus Firmensicht. Es gibt kommerzielle Anbieter für diese Dienste, die teilweise mehr oder weniger genau das können, was man mit Piwik bewerkstelligen kann. Diese verlangen jedoch Geld dafür – naja sagen wir mal häufig.
Einer der bekannten Anbieter ist Google mit Analytics. Dieses Produkt ist sehr umfangreich und gut – man liefert jedoch Google auch einen Haufen an Daten die man vielleicht nicht unbedingt weitergeben möchte, bzw. müsste man an sich den Benutzer fragen ob diese Daten bei Google landen dürfen. Es ist klar, dass auch ich “meine Benutzer” nicht gefragt habe ob Ihre Daten in Piwik landen dürfen, jedoch werden die Daten bei mir anonymisiert und nicht weitergegeben. Wie das bei Google oder anderen aussieht …
Eine der Funktionen die für eine Firma interessant sein kann sind die “Ziele” in Piwik. In anderen Systemen kann das ganze auch “Kampagne” genannt werden. Mit dieser Funktion ist es möglich beispielsweise eine URL zu definieren, die genau “getrackt” werden soll. Ein Beispiel: Man erstellt einen Newsletter und möchte wissen, wie viele Leute diesen öffnen, bzw. einen speziellen Link anklicken. Das kann man erreichen in dem man ein Bild innerhalb des Newsletters hinterlegt und dieses Bild als Ziel in Piwik einrichtet. Damit kann genau verfolgt werden wie oft dieses Bild aufgerufen wurde. Das ganze funktioniert auch mit Downloads (Dateien) und mit quasi jeder URL einer Seite.
Das ganze natürlich nur neben den bereits bekannten Funktionen wie Anzahl Zugriffe (heruntergebrochen in diversen Levels), Browsertyp, Betriebssysteme, installierte Plugins, Bildschirmauflösung, Besucher nach Land, Besucher nach Datum / Zeit …….
Erweiterbar
Da Piwik mit Plugins arbeitet kann man mit Sicherheit auch eigene Erweiterungen entwickeln. Das hab ich jedoch nicht ausprobiert.
Was mir da eher in den Sinn kommt ist, dass man durch die MySQL Datenbank natürlich auf alle Daten zugreifen kann. Damit kann man – gerade wenn es um Unternehmen geht – eigene Reports nach ganz eigenen Vorstellungen erstellen.
Openvpn: Tür auf, Tür zu, Tür auf, Tür zu …
20. Aug
Betreibt man einen Openvpn Server – beispielsweise zur Einwahl von Dienstleistern oder auch einfach nur für “normale” Benutzer – so sollte man das ganze mit einem Zertifikat abgesichert haben. Das ganze geht unter Debian/Ubuntu (und auch anderen) recht einfach mit easy-rsa. Jeder Client bekommt seinen eigenen Key und kann damit den Tunnel aufbauen.
Tür zu?
Was nun, wenn man einen Client aussperren möchte? Der Dienstleister ist ab sofort “böse”. Die Zusammenarbeit beendet. Er hat noch seinen Key und kann sich damit per Openvpn verbinden und ins interne Netz (soweit die Firewall den Zugriff zulässt). Eigentlich ganz einfach. Der Key des Benutzers wird “revoked” – das geht auch per easy-rsa recht einfach. Ist der Key revoked, so ist der Key für Openvpn ungültig und die Verbindung kann nicht mehr aufgebaut werden. Fertig.
Tür wieder auf?
Ganz anders sieht das aus, wenn man einen Benutzer hat der sich einwählen können soll, jedoch nur dann wenn man es möchte. Man vereinbart quasi einen Termin an dem irgendetwas gemacht werden soll und zu diesem Termin hat der Client Zugriff. Ist der Key eines Benutzers einmal “revoked”, dann ist das erstmal so. Einen Key wieder freizuschalten ist nicht so einfach zu machen.
Tür zu, Tür auf: Openvpn Switching
Ganz einfach ist das ganze zu machen, indem man den Parameter ccd-exclusive dazu benutzt. Dieser Parameter lässt nur Clients zu, die eine Konfigurationsdatei im sogenannten client-config-dir (Parameter in der openvpn Konfig) besitzen. Man kann diese Dateien nutzen, um Clientkonfigurationen zu setzen. Dazu wird in dem Verzeichnis eine Datei mit dem CN (der eindeutige Name/Zeritifikat) des Benutzers angelegt.
Der Parameter ccd-exclusive bewirkt nun, dass nur Clients sich verbinden dürfen, für die eine Datei im ccd vorhanden ist – mit dem genauen Namen (CN). Ob diese Datei nun gefüllt ist mir einer Clientspezifischen Konfiguration oder leer ist, das macht dabei keinen Unterschied. Um einen Client zu sperren muss man also lediglich die Datei im ccd beispielsweise in “disabled-<CN>” umbenennen. Das ganze funktioniert ohne Neustart des Daemons
Firefox Single-Sign-On (für Arme)
03. Mai
Gerade in Unternehmen wird mittlerweile von diversen Webapplikationen (beispielsweise Nagios, Proxy, eigene Applikationen) eine Authentifizierung verlangt. Das eine dabei sind die Passwörter die man sich merken, bzw. sich erst einmal ausdenken muss. Das andere sind die ständigen Authentifizierungsanfragen – beispielsweise in Firefox.
Out-of-the-box kann Firefox sich Benutzer und Passwörter in Formularen ja seit geraumer Zeit merken. Anders sieht es mit HTTP-Authentifizierungen aus (Popups). Firefox merkt sich zwar die Daten, allerdings schickt er diese nicht automatisch ab, so dass man immer wieder bestätigen muss. Abhilfe schafft da “AutoAuth” (Homepage). Ich benutze dieses Addon schon länger und bin bestens zufrieden damit.
Leider muss man mit jedem Passwortwechsel die Daten in Firefox manuell und einzeln Updaten. Sollte jemand von Euch eine besser Lösung kennen, dann bitte nicht schüchtern sein!
Vom Authentifizierungssystem her wäre eine Umstellung auf Kerberos die bessere Alternative. Damit könnte man wirkliches SSO machen. Die Umsetzung ist allerdings – vor allem wenn proprietäre Software eine Rolle spielt – ein Problem. Wir haben beispielsweise den Proxy (Squid) auf Kerberos Authentifizierung umstellen wollen und mussten feststellen, dass der IE6 Kerberos für Proxy Authentifizierung nicht unterstützt. Mit Firefox war das kein Problem.
Home NAS mit iSCSI – Format, Crypt und gut (Teil 3/3)
12. Apr
Teil I (hier) zeigte die Einrichtung des Servers inkl. iSCSI-Target.
Teil II (hier) zeigte die Einrichtung des Initiators – des Clients.
Teil III zeigt nun die restlichen Arbeiten – verschlüsseln der Platte, formatieren und den “luxuriösen” Zugriff darauf.
Verschlüsseln
Alleine um sich davor zu schützen, irgendwelche Daten aus versehen – z.B. wenn man eine alte Festplatte verkauft – an “unbefugte” weiter zu geben, sollte man seine Daten verschlüsseln. Daher habe ich die Daten auf meinem Laptop verschlüsselt und mache gleiches natürlich auch mit meinem Backup.
Unter Linux gibt es mehrere Möglichkeiten Festplatten, Partitionen oder auch nur Dateien zu verschlüsseln. Ich halte LUKS / Cryptsetup (Homepage) für eine der einfachsten Möglichkeiten.
Unter Ubuntu ist cryptsetup nicht in der Standardinstallation enthalten. Von daher muss das Paket installiert werden ->
apt-get install cryptsetup
Aus dem vorhergehenden Artikel sollten wir eine weitere Festplatte im System sehen. Beispielsweise /dev/sdb. Auf dieser Platte legen wir nun eine Partition an (/dev/sdb1) und verschlüsseln diese:
cryptsetup luksFormat /dev/sdb1
Nach Aufruf dieses Befehls wird nach einer Passphrase gefragt. Diese sollte – wie jedes Passwort – möglichst sicher gewählt werden. Mit Hilfe von LUKS / Cryptsetup werden die Daten während des Schreibens auf die Festplatte verschlüsselt, bzw. während des Lesens entschlüsselt. Dadurch dauert die Initiale Verschlüsselung nicht lange. Wirklich verschlüsselte Daten gelangen erst mit der Formatierung auf den Datenträger.
Formatieren
Die Passphrase für die Platte ist eingegeben. Nun muss die Platte ein Dateisystem bekommen damit wir damit arbeiten können. Dazu muss die Platte zuerst einmal per Luks “geöffnet” werden (wir haben bisher nur den Schlüssel angelegt).
cryptsetup luksOpen /dev/sdb1 SecureISCSI
Dieser Befehl fragt nun nach der Passphrase und legt – bei korrekter Eingabe – ein Device unter /dev/mapper mit Namen “SecureISCSI” an. Dieses ist dann das wirkliche Device, mit dem wir ganz normal arbeiten können.
mkfs.ext3 -L SecureISCSI /dev/mapper/SecureISCSI
Damit ist die Platte formatiert und kann gemountet / beschrieben werden.
Um das ganze zu vervollständigen: nach dem umounten kann das “entsicherte” Device (/dev/mapper/SecureISCSI) mit dem Befehl
cryptsetup luksClose /dev/mapper/SecureISCSI
wieder “verriegelt” werden.
Luxuriöser Zugriff
Was ich mittlerweile wirklich geil finde und vorher so gar nicht gewusst habe ist, wie man diese Festplatte nun unter Ubuntu nutzen kann.
Wenn ich meinen Laptop starte und mein Server ist verfügbar, werden mir die iSCSI Platten in Nautilus (Dateimanager) angezeigt (ich habe mehrere erzeugt). Die verschlüsselten Platten werden dabei als “290 GB verschlüsselt” angezeigt, die anderen mit ihrem Label (s. mkfs.ext3 -L …). Klickt man nun auf die “290 GB verschlüsselt”, so öffnet sich ein Dialog der mich nach der Passphrase fragt. Ich gebe die Passphrase ein und bekomme die Platte gemountet – mit ihrem Label, welches das System nun nach der Entschlüsselung erkannt hat. Ich kann direkt darauf zugreifen und beispielsweise per rsync meine Daten vom Laptop sichern.
fstab
Damit das ganze so einfach funktioniert, ist eine kleine Erweiterung der /etc/fstab notwendig. Macht man das ganze ohne diese Erweiterung, so wird man nach der Passphrase gefragt, zum mounten wird der Admin Zugriff abgefragt und als normaler User hat man dann keinen Zugriff sondern nur als root.
Um das zu umgehen trägt man in der fstab folgendes ein:
LABEL=SecureISCSI /media/SecureISCSI ext3 defaults,user,noauto 0 1
Damit ist der mountpoint bekannt und das wichtigste – es sind Optionen gesetzt. Die interessanteste dabei ist “user”, was so viel bedeutet wie “jeder Benutzer darf dieses Device auf diesem Mountpoint mounten und es auch wieder umounten”.
Wichtig ist hier auch, dass man dem Filesystem ein Label vergibt. Die iSCSI Platten müssen nicht immer den gleichen Gerätenamen (z.B. /dev/sdb) bekommen. Je nach dem ob beispielsweise ein USB Stick eingesteckt ist, kann es auch mal /dev/sd{c,d,e,f…} sein. Hat man jedoch ein Label vergeben, so spielt das eigentliche Device keine Rolle mehr. Alternativ könnte man auch mit der UUID arbeiten.
Ich hoffe dieser Artikel war recht interessant – über Feedback würde ich mich durchaus freuen
.
Home NAS mit iSCSI – Initiator (Teil 2/3)
06. Apr
In Teil I (hier) hatten wir die Einrichtung des Servers inkl. iSCSI-Target gezeigt. Teil II zeigt die Einrichtung des Initiators – des Clients.
Pakete
Wir gehen von einem Ubuntu Karmic (9.10) aus. Um iSCSI nutzen zu können wird das Paket open-iscsi benötigt.
apt-get install open-iscsi
Konfiguration
Nach der Installation findet sich ein neues Verzeichnis unter /etc/ -> iscsi – dort befinden sich die Konfigurationsdateien …
initiatorname.iscsi
Dort steht quasi der Name des Initiators. Unter Debian wird bei der Installation eine ID generiert, die eindeutig ist. Möchte man den Client jedoch eindeutig zuordnen können, so sollte man den Namen in etwas “sprechendes” anpassen.
iscsid.conf
In dieser Datei werden die Defaults definiert, die von dem Daemon am Ende genutzt werden. Um mit unserer Serverseitigen Konfiguration zu arbeiten funktioniert die folgende:
node.startup = automatic node.conn[0].startup = automatic node.session.auth.authmethod = CHAP node.session.auth.username = linux-aha node.session.auth.password = secret node.session.auth.username_in = linux-aha node.session.auth.password_in = password discovery.sendtargets.auth.authmethod = CHAP discovery.sendtargets.auth.username = linux-aha discovery.sendtargets.auth.password = secret node.session.timeo.replacement_timeout = 120 node.conn[0].timeo.login_timeout = 15 node.conn[0].timeo.logout_timeout = 15 node.conn[0].timeo.noop_out_interval = 5 node.conn[0].timeo.noop_out_timeout = 5 node.session.err_timeo.abort_timeout = 15 node.session.err_timeo.lu_reset_timeout = 20 node.session.initial_login_retry_max = 8 node.session.cmds_max = 128 node.session.queue_depth = 32 node.session.iscsi.InitialR2T = Yes node.session.iscsi.ImmediateData = No node.session.iscsi.FirstBurstLength = 262144 node.session.iscsi.MaxBurstLength = 16776192 node.conn[0].iscsi.MaxRecvDataSegmentLength = 131072 discovery.sendtargets.iscsi.MaxRecvDataSegmentLength = 32768 node.session.iscsi.FastAbort = Yes
Damit ist die Konfiguration bereits erledigt.
Discover
Um das ganze ans Rennen zu bringen muss man einen sog. Discover ausführen. Das ist vergleichbar mit einem SCSI Busscan. Da wir die Default Konfiguration für open-iscsi bereits angepasst haben, kann man den Discover Befehl auf das nötigste reduzieren:
root@machine$: iscsiadm -m discovery -t sendtargets -p <iSCSI Targethost> iqn.2008-04.local.home:SecureISCSI
So oder so ähnlich sollte der Output aussehen. Es sollte also – vergleichbar mit einem SCSI Busscan ein Device gefunden werden.
Mit dem Discover wurde nun unterhalb von /etc/iscsi/nodes die Konfiguration für dieses Device angelegt. Dadurch ist das Device dem Daemon bekannt und kann beim Systemstart gesucht und ggf. verbunden werden. Nach dem Discover genügt ein restart des Daemons um das Device im System verfügbar zu machen.
/etc/init.d/open-iscsi restart
Platte da ?
Nach dem restart sollte die neue Platte vorhanden sein. Am einfachsten hilft ein “fdisk -l” dabei, die neue Platte zu finden.






