Bullshit made in germany …

On 13. 04 2014, in Allgemein, by Raptor 2101

oder “Ich hab jetzt endlich auch ein Konto in der Schweiz”

Zu einer Zeit als mobile Endgeräte noch PDA genannt wurden, entschied ich, wegen eben solch eines Endgerätes, dass ich unbedingt einen IMAP fähigen Mail-Server benötige. Leider hatte man zu dieser Zeit nur zwei Möglichkeiten: selber einen Mail Server betreiben oder Geld für mehr Service bezahlen. (Google Mail war gerade erst im kommen).

Seit diesen Tagen bin ich GMX Pro Kunde. Rückblickend eine verdammt lange Zeit. Ich könnte jetzt einen langen Beitrag darüber schreiben, was GMX und United Internet in Zeiten der Mobilen Endgeräte alles verpennt hat, oder was man als “versierter” Endnutzer eigentlich erwartet aber belassen wir es bei den Basics. Unzufrieden war ich schon lange mit diesem Verein. Ausschlaggebend für meinen Wechsel weg von GMX war jedoch nur ein Grund: Sicherheit

Ich hab mit entsetzten registriert, wie dilettantisch GMX die letzten Monate agiert hat. Da wird mit großen getöße Angekündigt, dass eine Jahrzehnte alter Standard jetzt umgesetzt wird (Verschlüsselung erzwingen) und dann Versagen sie auf ganzer Linie. Für einen Lacher auf dem 30C3 hat es gereicht. Anstatt sich dann um die Sicherheit ihrer Kunden zu kümmern und endlich ihr WebFronted zu überarbeiten, wird lieber eine Kampagne gegen unliebsame Adblocker gefahren. Das Niveau war erschreckend. Weder vor Scaring noch vor FUD wurde zurückgeschreckt.

Gleichzeitig war das WebFronted von GMX ohne Adblocker, Ghostery und co selbst als zahlender Kunde nicht anzusteuern. Von der Aufmachung nach Bildniveau ganz zu schweigen. Dazu kamen so witzige Sachen wie “nicht abschaltbares Bilderladen beim betrachten von Mails”.

Lange rede kurzer Sinn: ich brauchte einen anderen E-Mail Provider. Eigendeich wollte ich mir selbst einen Server hosten. Kurze die Rahmenbedingen überschlagen:

  • Kosten für eine statische IP (über VPN) – Mein Provider will mir keine statische IP schalten.
  • Mir stehen “nur” 16/1 Mbit zur Verfügung. Sollte für Mailversand reichen, aber schön ist anders…
  •  Ein Mailserver der öffentlich zugänglich ist, ist eine ganz andere Hausnummer. Vom Pflegen der Spamfilter mal ganz zu schweigen.

Danach hab ich das “Eigenhosting” für weitere 5 Jahre auf Eis gelegt und mich auf die Suche nach passenden Providern gemacht und bin bei einem kleinen Anbieter in der Schweiz fündig geworden: Kolab Systems.

Zum einen bieten sie ihre Groupware als OpenSource an (was Standard in der Branche zu sein scheint, wenn man gegen Outlook bestehen will), zum anderen betreiben sie einen Mail-Service mit eben dieser Groupware, der all das bietet, was man sich von einem modernen Mail-Provider wünscht:

  • Sicherheit:  Nach bekanntwerden des Hearthbleed – GAUs wurden binnen weniger Stunden die Zertifikate getauscht und die User Informiert. Bei GMX warte ich immer noch auf eine Benachrichtigung.
  • Sicherheit: unverschlüsselt wird nichts angeboten und deren Transportverschlüsselung ist “State of the Art”
  • Datenschutz: Es wird stark auf Anonymität und Sicherheit geachtet. Das FAQ und die Service Beschreibung lesen sich als ob Aluhut-Träger die Zielgruppe sind.
  • Terms of Service die man verstehen kann.
  • Ach und nebenbei voller Support von Mobilen Endgeräten OHNE proprietäre APP (via ActiveSync und Card/Cal-DAV)
  • Synchronisation zwischen verschiedenen Usern
  • Achja und keine Werbung

Müsste ich jetzt nicht alle Dienste auf die neue Mail umstellen, wäre ich im siebten Himmel.

ExpireDate von Zertifikat überwachen.

On 12. 02 2014, in Munin, Netzwerk, by Raptor 2101

Wer, wie ich, eine eigene (private) CA betreibt, wird irgendwann mal überrascht feststellen, dass auch das Root-Zertifikat ausläuft. Standardmäßig nach 4 Jahren. Wenn plötzlich der Radius keine Clients mehr ins Netz lässt, wenn jede interne HTTPS-Verbindung auf Warnung läuft und man sich plötzlich wieder mit Notfall-Passwörtern anmelden muss, weiß man, dass man vergessen hat, sein Root-Zertifikat rechtzeitig zu erneuern.

Was bei einzelnen Clients noch mit vertretbaren Aufwand zu beheben ist, nervt beim Zwangs erneuern der CA doch ziemlich, besonders wenn man gerade etwas anderes vor hatte.

Für diesen Zweck hab ich mir ein kleines Script gebastelt, das via Munin alle Cert-Restlaufzeiten ermittelt und rechtzeitig Alarm schlägt.

wie immer unter GPL hier zu beziehen: Check Expire Date

Tagged with:
 

Wer das Problem hat, dass bei iptables-Rules wie der folgenden keine (oder nur vereinzelt) Verbindungen nach draußen zustande kommen hat das gleiche Problem wie ich es hatte:

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth1 -o pppoe0               -j ACCEPT

Die Regel besagt, alles von “Drinnen” (eth1) nach “Draußen” (pppoe0) zuzulassen und alle Pakete der Verbindungstatus als ESTABLISHED oder RELATED erkannt wird zuzulassen. Kurz: eine StateFull-Firewall die alles von drinnen nach draußen routet aber von draußen nur angefragtes rein lässt.

Wer auf etwas “stabilere” (oder ältere) Software setzt (in Worten: debian squeeze) ist noch mit einem 2.6er Kernel unterwegs. Bei diesem sind die Module fürs ConnectionTracking wohl noch etwas schärfer/unbrauchbarer.

Erst mit folgendem Befehl verhält sich das ConnectionTracking wie man es erwarten würde:

echo 1 > /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal

Ab Kernel 2.6.22 ist dies nicht mehr notwendig.

Quelle: http://conntrack-tools.netfilter.org/manual.html

Tagged with:
 

OpenVPN – TLS-Server-Check bestehen

On 18. 08 2013, in Administration, Server, by Raptor 2101

OpenVPN liefert gleich eine ganze BuildChain mit um sich Zertifikate zu generieren und zu signieren. Leider hat man meist schon eine Infrastruktur (CA) im Feld mit der man seine Zertifikate signiert und verteilt. Bei mir habe ich das immer über das in Ubuntu mitgelieferte CA.pl Skript gemacht und die so erzeugten Zertifikate funktionieren gerade nicht in OpenVPN. Es kann zwar eine Verbindung aufgebaut werden aber ein TLS-Server-Check schlägt fehl. Um gültige Zertifikate zu erzeugen muss man folgendes machen.

in der /etc/ssl(openssl.cnf muss man eine neue Sektion anlegen. Am besten mit dem Namen “Server” oder “OpenVPNHost”

[ server ]
basicConstraints=CA:FALSE
nsCertType          = server
nsComment           = "Some comment"
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always
extendedKeyUsage=serverAuth
keyUsage = digitalSignature, keyEncipherment

anschließend muss man das certifiacte wie folgt erzeugen:

openssl req -days 365 -nodes -new -keyout newkey.pem -out newreq.pem -extensions server -config /etc/ssl/openssl.cnf
openssl ca -days 1095 -extensions server -in newreq.pem -policy policy_anything -out newcert.pem

Das so erzeugte Zertifikat besteht auch einen TLS-Server-Check

Tagged with:
 

Wer einen EdgeMax Router im Einsatz hat, kann über die Configschnittstelle seinen DHCP Server aufsetzten. Wer aber einen bestehenden DHCP Server migrieren will, wird blöde, alles über dieses Interface einzuhacken. Es geht auch einfacher. Die bestehende dhcpd.conf unter /config ablegen. Man kass es prinzipjell überall hinlegen, aber dort überlebt die Datei ein Firmware-Upgrade.

 

Anschließend die Datei /etc/init.d/dhcpd anpassen und von der automatisch generierten auf die /config/dhcpd.conf umbiegen. Wenn man im Configmenu den DHCP-Server abgeschaltet hat (kein Eintrag unter services) muss man nun noch den DHCP-Server beim Start mit starten lassen:

update-rc.d dhcpd default

Schon hat man seinen selbst-konfigurierten DHCP Server am Start.

Tagged with:
 

EdgeMax Lite – eine kurze Review

On 22. 07 2013, in Netzwerk, by Raptor 2101

Seit 14 Tagen verrichtet ein Router der Marke “EdgeMax Lite” von Ubiquiti seinen Dienst in meinem Netzwerk. Hier eine kleine Zusammenfassung meiner Erfahrungen.

Kurzfazit: Dieser Router wurde darauf ausgelegt 1Gbit über alle drei Ethernet Interfaces zu routen. Dafür wurde auf die üblichen Dinge wie WLAN, integrierter Switch, TK-Anlage und weitere Features verzichtet. Wer hingegen einen leistungsstarken Router und nur “einen Router” braucht, der liegt mit diesem Gerät goldrichtig.

Der EdgeMax Lite wird es als Produkt nicht leicht haben, dass wird schon bei einem einfachen Blick auf die Featureliste und Technischen Daten klar. Andere Produkte im 100€ Segment bieten für die “normale Nutzung” wesentlich mehr zusätzliche Features. Spätestens 30 Minuten nach Inbetriebnahme dürfte der Normalnutzer entgeistert aufgeben und bereuen sich keine “Eierlegende Wollmichsau” zum gleichen Preis gekauft zu haben. Wie ein solcher “Vergleich” sich dann in einem Test niederschlägt, kann man bei SmallnetBuilder nachlesen. Den EdgeMax mit einer FritzBox zu vergleichen ist ungefähr so als wolle man einen Combi mit einem Sportwagen vergleichen. Das kann man machen, viel Sinn macht es aber nicht.

Ich hab mich für einen Einsatz des EdgeMax entschieden, da mein “alter” Buffalo AG300H einige Features einfach nicht abdecken konnte. Das Killer-Feature war dabei der Routing-Durchsatzt. Ich wollte meinen Server von meinem lokalen LAN isolieren. Etwas was jeder IT-Azubi im ersten Lehrjahr lernen sollte. Mit dem Buffalo war das nicht möglich. Ein frisches OpenWRT mit geflushten Iptables brachte gerade mal 400mbits über den Router. Sobald ein paar Iptables Rules zum Einsatz kamen, sank der Durchsatz auf unter 300mbits. HD Filme die von einem NAS gestreamt werden, fangen jetzt an zu ruckeln. Das war keine Option.

Der EdgeMax gibt sich hier keine Blöße. Wie von Ubiquiti beworben legt er das Gigabit auf die Leitung. Der Einsatz von Firewall-Regeln oder QoS  hat dabei keinen Einfluss auf den Durchsatz, wenn man sich an kleinere Einschränkungen hält (erleuterung folgt gleich). Mittels IPerf konnte ich 850mbits ermitteln. Wobei mein Switch 900mbits auf die Leitung legt. Dieser Durchsatz wird erreicht, ohne dass der CPU auch nur Notiz davon nimmt (Load von 0).

Ein Blick auf die technischen Daten macht aber klar, dass dieses Ergebnis zu erwarten ist. Zum Einsatz kommt ein Cavium Octeon 500MHz Dual Core (Hardware Einheit zur Paketverarbeitung inklusive), 512MB RAM und 2GB Flashspeicher. Das ist einfach eine andere Hausnummer als meine bisherige Routerhardware. Auch so hinterlässt der EdgeMax einen anderen Eindruck als jeder SoHo Router den ich bis jetzt in die Finger bekommen habe. Er blinkt nicht wie ein Weihnachtsbaum und buhlt auch nicht um Aufmerksamkeit wie die letzten Asus und Netgear Geräte.

EdgeMaxLite

EdgeMax-Lite während der Konfiguration

Das auffälligste ist im ersten Moment der vierte RJ45 Port – die gute alte Serielle Schnittstelle ist zu Wartungszwecken raus geführt worden. Gut selbst Cisco nutzt dafür jetzt USB Ports aber egal, ob Hauptsache sie ist raus geführt. Danach bekommt man (normalerweise) als erstes die (Web) GUI zu Gesicht. Diese kann man wohlwollend mit “managementtauglich” Beschreiben. Man kann quasi jedem Azubi Zugriff geben, viel kaputt machen kann er nicht… Selbst für das Konfigurieren der Interfaces braucht man Zugriff via Konsole. Eine Konsole kann man zwar auch über die GUI bekommen, aber dass ist dann nicht mehr Klicki-Bunti. Überhaupt die GUI noch die sichtbarste Baustelle. Das einrichten einer Firewall Rule geht noch alles andere als intuitive von der Hand.

Wenn man sich via SSH (muss aktiviert werden) oder gar Seriellen Konsole auf den Router verbindet bekommt man direkten Zugriff auf das Router OS. Zum Einsatz kommt ein von Ubiquiti geforktes Vyatta. Dies ist eine Debian basierte Router Distribution. Anders als z.B Chanonical setzt Ubiquiti aber auf die standart Debian (squeeze) Quellen.

Die zur Verfügung gestellte vbash lehnt sich in Aufbau und Bedienung an die IOS (Cisco) Devices an. Das kann man mögen, muss aber man nicht. Standardmäßig wird zudem eine eingeschränkte Quagga Routing Suite eingesetzt. Wobei ich das Gefühl nicht loswerden, dass diese nur eingeschränkt wurde, weil man noch nicht das ganze Spektrum in der Konfigurations-Schnittstelle abdecken kann.

Das Konfigurieren geht dabei gut von der Hand. Schnittstellen und Routing sind schnell und übersichtlich Konfiguriert und der Router einsatzbereit. Besonders angenehm fällt dabei die “Commit/Rollback”-Fähigkeit der Konfigurationsoberfläche auf. Änderungen müssen erst via “Commited” freigegeben werden bevor man sie final in den VRAM raus schreiben kann. So kann man zu jedem Zeitpunkt seine Änderungen “einsehen”. Beim Commit werden die neuen Einstellungen auf “Konsistenz” geprüft. Firewall Rules ohne Interface werden gar nicht erst gespeichert. Anschließend werden alle Änderungen wirksam gemacht: Befehle angewendet, Dienste neu gestartet usw. Erst jetzt kann der finale “Save” ausgeführt werden. Fehlkonfigurationen bei denen man sich selber Aussperrt, werden so erschwert. Zusätzlich können mehrere Einstellungssets vorgehalten werden. Das wirkt alles ausgereift und durchdacht. Nur leider bleibt das was man konfigurieren kann, weit hinter dem zurück, was dieser Router bietet.

Für mich war bei der Einrichtung der Firewall Schluss mit der vbash. Ich weiß nicht wie viele Versuche ich gesehen habe das Iptables-Kommando vor dem Benutzer zu verstecken. Dies ist ein weiterer auf der Liste. Kurz: ich führe nur noch das Nötigste (interfaces, web-gui abschalten, logins) in der Konfiguration, danach geht es über einen zweiten Benutzer (alternativ sudo su) an das “eigentliche” Debian.

Ab jetzt spielt der “Router” seine Stärke aus: brachiale Performance, Platz und Debian halt. 2GB sind für den Anfang mehr als genug um ein paar zusätzliche Dienste zu installieren. Da man die kompletten Debian-Quellen im Zugriff hat, findet man eigentlich jeden Dienst, den man irgendwie im Netzwerk gebrauchen könnte. Man hat aber auch nur 2GB Speicher. Eine Erweiterung via USB oder anderen BusSystem ist nicht vorgesehen. Zum Hosten kleiner WebSites würde es reichen, ist aber nicht zu empfehlen. Begründung folgt gleich…

Bei muss der Router FreeRadius , Kerberos  zur Verfügung stellen und mehrere Clients mit einer 2 DMZ-Lans verbinden. Zu Testzwecken hab ich vier simultane (unterschiedliche Rechner) bonnie++ auf eine NFS Freigabe losgegangen. Der Durchsatz über den Router lag immer  im Bereich 750 bis 850 mbits und die CPUs langweilten sich bei einem Load von 0. Auch versuche die CPU mit normalen Radius/Kerberos anfragen zu quälen, waren nicht von Erfolg gekrönt. Das sollte für den “Heimgebrauch” reichen. Der Durchsatz ist aber stark vom Einsatz-Szenario abhängig. Die Hardwarebeschleunigung greift nicht überall. Sobald Bridging oder VLANs in Spiel kommen, muss die CPU rann. IPv6 wird erst mit der neusten Firmware auch “beschleunigt” (disabled by default.). Wenn die Hardwarebeschleunigung fehlt bricht der Durchsatz rapide ein. Jeh nach Szenario landet man bei 500mbits oder gar 400 mbits (Firewall, NAT, QOS, IPv6 ohne HW) und der CPU ist am Limit. Der Router war allerding noch  ansprechbar, und gut bedienbar. Ich hab es mit fünf Simultanen Floodings nicht geschafft, den Router so weg zu schießen, dass er nicht mehr bedienbar war. Ob er einem richtigen DDOS angriff stand hält würde ich mal bezweifeln.

Ein Wort zu den VLANs/Bridging Einschränkungen. Es ist möglich auf einem Interface “ungebridged”/”ungetagged” und gleichzeitig “bridged”/”tagged” zu arbeiten. Dabei wird der “ungebridged”/”ungetagged” Traffic durch die Hardware beschleunigt und der Rest muss über die CPU. Man hat also, wenn man es clever anstellt, genügend Spielraum diesen “Makel” zu umgehen. Zumal der Hersteller in Aussicht gestellt hat, dass sich dieser Umstand in Zukunft noch verbessert, sprich VLANs auch Hardware beschleunigt werden. Überhaupt sind noch viele der Eckpunkte des EdgeMax “im Fluss”. Ubiquiti erweitert mit jedem Update die Funktionalitäten, den Umfang der Hardwarebeschleunigung und behebt (natürlich) Bugs. Dabei hatte ich nie das Gefühl eine Beta im Einsatz zu haben. (Wobei man sich für selbige anmelden kann.) Die FirmwareUpdates machen immer einen sehr runden Eindruck.

Wo wir bei den Firmware Updates waren. Die kommen momentan recht zügig (zwischen 1.1.0 und 1.2.0 lagen 4 Monate). Das Firmwareupdate läuft dabei ähnlich wie bei OpenWRT. Einmal geflasht gehen alle Informationen verloren. Einzig die ConfigDatei und alles was in bestimmten Ordnern liegt wird erhalten. Größere Datenmengen oder gar Datenbanken verbieten sich da. Da nach einem Update sowieso die zusätzlichen Dienste neu installiert werden müssen, sollte man sich nur Keys, Certs und ähnliches auf dem Router vorhalten. Ein richtiger Webserver schließt sich somit fast aus. Komfortabel ist das noch nicht. Ein Mitarbeiter von Ubiquiti hat jedoch erläutert, dass in späteren Versionen auf einen RollingRelease angeboten werden könnte…

Wo wir beim letzten wichtigen Thema sind: dem Support von Ubiquiti. Der wird recht häufig gescholten. Ich hatte bis jetzt nur das “Vergnügen” ihn in den Foren zu erleben und muss sagen, dass es wirklich ein Vergnügen ist. Es scheinen ein paar Mitarbeiter der EdgeMax Produktlinie abgestellt worden zu sein, durch die Foren zu streifen. Zu jeder wichtigeren Frage findet man immer eine, meist sogar mehrere Antworten von Ubiquiti-Mitarbeitern. Sie begründen Entscheidung, gehen auf Testergebnisse ein oder geben Hilfestellungen. Alles in allem macht es einen ungewohnt offenen Eindruck. Dies ist aber angesichts der Funktionalität und der (fehlenden) Dokumentation auch nötig. Während die meisten etablierten Router-Hersteller eine selbsterklärende GUI oder dicke (sinnfreie) Manuals anbieten, baut Ubiquiti gerade erste ihre KnowledgeBase auf. Bei vielen Fragen muss man aufs Forum zurückgreifen. In diesem Fall sehe ich das aber nicht als Nachteil. Die Suche funktioniert gut die passenden Antworten sind markiert.

Ein letztes Wort zum Thema OpenSource: Hier blick ich nicht mehr ganz durch. Laut Ubiquiti ist es möglich sich einen eigenen Kernel oder gar Image selber zu erzeugen. Bei Freebsd und OpenWRT gibt es auch Builds die wohl den Chip unterstützen. In wie weit dort die Hardware-Beschleunigung inbegriffen ist konnte ich in Ermangelung an Zeit nicht Testen. Interessant ist in jedem Fall, das für einen SDK von Cavium erst mal ein NDA unterzeichnet werden muss. Man bekommt also einen Kernel mit ClosedSource Binaries. Für Leute die nur 100% frei Software im Einsatz haben wollen, ist die Büchse aktuell erst mal nichts.

Für alle anderen, die einen “echten” Router suchen, ist der EdgeMax genau das richtige. Klein, Unscheinbar, Leistungsstark und wenn man Linux beherrscht simpel in der Bedienung. Hatte ich den serielle Konsole schon erwähnt? Ende des Jahres sollte die 5Port POE Version des Routers im Handel verfügbar sein, dann werden meine Buffalos endgültig ausgemistet…

Tagged with:
 

Ich hab seit einiger Zeit einen FreeRadius-Server um mein WLAN abzusichern und mein VPN Zugang zu regeln. Das System war so konfiguriert, dass der Client ein Zertifikat vorzeigt, einen Tunnel aufbaut und dann via EAP/PAP autorisiert wird. Das Gruppenmanagement übernahm dabei LDAP und die das Passwort wurde via Kerberos geprüft. Alles in allem sehr flexibel aber auch sehr komplex. Vor allem der LDAP Server störte mich doch extrem. Zum einen ist der so ganz anders zu konfigurieren und zu verwalten, als alle anderen Dienst ein meiner Landschaft, zum anderen hab ich ihn nie so richtig verstanden. Kurz der musste weg. Ich wollte aber weiterhin die Option haben, eine Nutzer via VPN auf Subnets “Zugang” zu lassen aber vom Heimnetz “Sicher” fern zu halten. Insofern man den aktuellen FreeRadius einsetzt bietet dieser eine sehr elegante Möglichkeit an, dass auf Zertifikatsbasis zu lösen.

Der Grundgedanke: Insofern man der CA wirklich vertraut bzw. die CA selber stellt, kann man davon ausgehen, dass ein Client nur das Zertifikat hat, dass er haben darf. Verlust und Diebstahl wird über eine aktuelle “Revocation Liste” gelöst. Vertraut man der CA, kann man somit die Zugangsinformationen ins Zertifikat hinterlegen. Zum Beispiel kann man das OU (OrganisationUnit) oder gar das CN Feld nutzen. In meinem Fall, hab ich mich auf das CN Feld bzw den ganzen Zertifikats-Pfad verlassen. Meine Netz ist in verschiedene Bereiche getrennt: Sicher, Gesichert, Offen (Radius entfällt). Alle Clients haben schon jetzt Zertifikate die wie folgt aussehen: hostname.sicher.ca oder bekannter.gesichert.ca. Ich musste den Radius nur noch dazu bekommen, dass ein Client der in das “Sichere” Netz will auch ein “sicher.ca”-Zertifakt vorweißt.

Umsetzung: Was man vorher braucht, ist ein Radius der TLS beherrscht. Das wird hier beschrieben: Ubuntusers:Wiki – FreeRadius. Läuft der TLS Modus stehen nun eine Reihe von Variablen innerhalb der FreeRadius-Configuraiton zur Verfügung. Eine komplette Liste konnte ich nicht auftreiben aber laut einigen Mailinglisten sind die folgenden Variablen wohl verfügbar:

  • TLS-Cert-Serial
  • TLS-Cert-Expiration
  • TLS-Cert-Issuer
  • TLS-Cert-Subject
  • TLS-Client-Cert-Serial
  • TLS-Client-Cert-Expiration
  • TLS-Client-Cert-Issuer
  • TLS-Client-Cert-Subject

Interessant ist die TLS-Client-Cert-Subject – Variable. Diese stellt das Subject via String zur verfügung. Jetzt muss man nur noch mittels RegExp seine gewünschte Prüfung durchführen. Dass kann dann so aussehen.

authenticate {
  Auth-Type eap {
    eap 
    if ( Huntgroup-Name == 'sicher' && "%{TLS-Client-Cert-Subject}" =~ /\/CN=.*\.sicher\.ca\// ) { 
      ok 
    }
    else {
      reject
    }
  }
}

Die “Huntgroup” ist eine Eigenschaft die durch beliebige Regeln vorher gesetzt wird. In meinem Fall sieht die Regel so aus:

atlantic   NAS-IP-Address == 10.11.1.2, NAS-Identifier == "sicheres-lan"

Was folgt ist folgende Prüfung. Wenn eine TLS-Verbindung über einen Zugangspunkt mit der IP 10.11.1.2 und NAS-ID (vorher vereinbart) “sicheres-lan” ankommt muss das CLientZertifikat auf “*.sicher.ca” ausgestellt sein. Alles andere wird abgeleht. Mann kann da noch weitere else-Zweige einbauen. Aber das Prinzip bleibt das gleiche.

Tagged with:
 

Da CSync leider nicht meine Erwartungen erfüllt hat bzw. nicht im Ubuntu-Repository versorgt wird musste ich mich vor ein Weile nach Alternativen umschauen.

Dabei bin ich auf Unison gestoßen. Installiert man es auf Client und Server kann man via ssh sehr schnell große Datenmengen in beide Richtungen abgleichen. Man kann sogar eine Konfliktlösungsstrategie angeben, falls es sowohl auf Server als auch Clients zu Änderungen kam.
Mittels Exclude-List kann man gezielt steuern was übertragen werden soll. Sogar via Regex.

Beispielconfig:

root = /home/myuser
root = ssh://myuser@myserver.local//path/to/storage
batch = true
 
ignore = Path .unison
ignore = Path .kdevduchain
ignore = Path .kde*/cache-*
ignore = Path .kde*/socket-*
ignore = Path .kde*/tmp-*
ignore = Path .kde/share/apps/amarok/albumcovers
ignore = Path .kde/share/apps/nepomuk
ignore = Path .kde/share/apps/akregator/Archive
 
 
ignore = Regex [^\.].* # alle Dateien die nicht mir . beginnen werden ignoriert.

Das ganze kann man ohne Probleme über ein Skript beim Start oder Login automatisieren:

/usr/bin/unison sync_homedir -silent -prefer newer -times

Bleibt nur noch das Problem wie man den ssh-Daemon auf der Server-Seite dazu bekommt ohne weitere Passwortabfrage eine Verbindung zuzulassen. Da gibt es verschiedene Varianten wie z.b. das Public-Key-Verfahren (wobei der keyring automatisch aufgemacht werden muss) oder GSSAPI. Letztere ist relativ bequem einzusetzen, wenn man mal einen Kerberos eingerichtet hat. Dann muss man einfach folgende Konfiguration im SSH Daemon vornehmen.

# Kerberos options
KerberosAuthentication yes
KerberosGetAFSToken yes
KerberosOrLocalPasswd yes
KerberosTicketCleanup yes
 
# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

Anschließend akzeptiert der SSH Daemon nach einem Neustart auch Kerberos Tickets anstatt ein Password abzufragen.

Tagged with:
 

Aquaero – einmal Lüftersteuerung bitte

On 6. 03 2013, in Allgemein, by Raptor 2101

Diesmal ein (noch) nicht Linux bezogenes Thema.

Alle Rechner die ich mir in letzter Zeit aufgebaut habe, habe ich immer auch dahin gehend optimiert, möglichst geräuscharm zu sein. Das Spektrum reicht von “kaum Wahrnehmbar” (HTPC – *grml* Asus…) bis “nicht vermeidbar” (14 HDDs erzeugen Vibrationen und Wärme…). Immer eine große Hilfe war mir dabei Produkte von Aquacomputer. Da ich mittlerweile ein kleines Vermögen bei der Firma gelassen habe, will ich mal meine Erfahrung für all die Kundtun, die mit dem Gedanken spielen, Produkte von dieser Firma zu erwerben.

Aquacomputer ist eine der wenigen deutschen Firmen die Computerbauteile (im entferntesten Sinne) in Kleinserie für den Endnutzer fertigen. Die Produktpalette von AC dreht sich dabei komplett um das Thema “Wasserkühlung und Steuerung”. Von Pumpen über Radiatoren bis hin zu Steuerungen/Reglern wird alles angeboten was man so braucht. Die Produkte sind alle hochwertig und passgenau verarbeitet, und machen Optisch einiges her. Zu beanstanden hatte ich nie etwas (von fehlenden Schrauben mal abgesehen).

IMG_20130223_13_57_39Besonders zu erwähnen ist die Aquaero 5. Diese “Lüftersteuerung” setzt sich von ihrer Konkurrenz vor allem durch ihre Konfigurierbarkeit aus. Preislich liegt sie mit anderen Produkten auf einer Linie, ich hab aber keine andere Steuerung gefunden die so viele Regelungsmöglichkeiten bietet. 8 Temperatursensoren (die einzige Eingangsgröße die Einfluss auf Ausgangswerte nehmen kann) können direkt angeschlossen werden, wer mehr braucht, kann sich Erweiterungsmodule dazu stecken. Vier Lüfter kann die Steuereinheit direkt Versorgen (auch das kann man erweitern). Leider nur einen davon im PWM – Modus. Alle Ausgänge sollen 1,65 A bieten. Man kann also mehre als nur einen Lüfter pro Kanal antreiben. Kaufgrund und vor allem Empfehlenswert ist für mich aber die Steuereinheit selber. Es werden fünf Reglertypen angeboten, wobei jeder der angebotenen Hardwareausgänge angesteuert werden kann (LED, Lüfter, PWM-Leistungsausgänge):

  • Vorgabewert: Ausgang mit x% Leistung
  • Zweipunkt Regler: bei Temp x1 einschalten und bei Temp x2 auschalten.
  • Kurveregelung: bei Temp X -> Leistung y
  • Sollwert/PID-Regler: Versucht die eingestellte Temperatur zu “halten”.
  • LED-Regler: Kennt drei Bereiche (zu kalt, optimal, zu heiß) und kann entsprechend drei Ausgänge ansteuern.

IMG_20130223_13_54_43Der PID-Regler hat es mir angetan. Kurz und knapp: wenn man den PID Regler richtig einstellt, das braucht eine Weile, werden die Lüfter nur dann hochgedreht wenn sie gebraucht werden, anschließend wird die Lüfterleistung und Temperatur auf den Sollwert “eingeschwungen” (im wahrsten sinne des Wortes). Dies hat z.B gerade bei “AlwaysOn” Festplatten den Vorteil, dass man die optimale Betriebstemperatur einstellt und halten kann. Das ist materialschonend und erhöht die Lebenserwartung. Meine Serverplatten werden seit zwei Jahren konstant im Bereich 35 bis 40°C gehalten, unabhängig ob sie gerade belastet werden oder in Ruhe sind. Auch Schwankungen der Außentemperatur können bis zu einem gewissen Grad gut kompensiert werden.
Die AE5 wird in mehreren Versionen angeboten. Meine präferierte Version war eigentlich die LT Version. Bei dieser Version bekommt man nur eine Platine ausgeliefert. Parametriert und überwacht wird die AE5 via USB. Eigendlich ideal für Server die remote Verwaltet werden und HTPCs die keine 5 1/2 Zoll Slot zu verschenken habe. Leider wird von Aquacomputer kein Linux Support geliefert, so dass man zwingend Windows braucht um die AE5 initial zu konfigurieren. Die anderen beiden Versionen werden mit Display und Bedienknöpfen samt Edelstahl-Einbaurahmen geliefert. Die teuerste Version bringt gleich noch eine IR-Tasturvernbedienung mit.

Verbaut habe ich die AE5 drei mal. Einmal eine LT in meinem HTPC, wo zwei kleine Lüfter so geregelt werden, so dass das eigentlich “lüfterlose” Board AT5IONT sich nicht über 60 Grad aufheizt. Die AE5 dafür zwar auf den ersten Blick oversized , im nach hinein ist es meiner Meinung nach das schwierigste Setup. Der HTPC steht im Wohnraum und darf kein Geräusch von sich geben. Die AE5 war die einzige Steuerung, für die ich kein Laufwerkslot brauchte und die Lüfter quasi Stufenlos Aussteuern kann. Dies gelingt ohne Probleme. Einmal korrekt eingerichtet, verrichtet die AE5 ihren dienst seit gut einem Jahr ohne ein Aufhäulen eines Lüfters oder abrauchen des Boards.

Daneben kommen noch zwei weitere AE5 mit Display in meinem Server als auch meinem Desktop PC zum Einsatz. Beide Setups sind nicht weiter erwähnenswert. Beim Server werden insgesamt 6 Lüfter Zonenweise so aus gesteuert, dass die oben erwähnte Betriebstemperatur der Platten gehalten wird. Im Desktop kann die AE5 ihr vorgesehenes Potential auspielen und neben 4 Lüftern auch noch eine ganze Wasserkühlung mit überwachen. Auch dieses System wird wie Vorgesehen ohne Lärm auf den vorgesheen Temperaturen gehalten.

Aquastream quer verbautAquastream und Aqualis aufrecht verbautNeben der AE5 ist noch die Aquastream XT-Pumpe als “intelligentes Bauteil” erwähnenswert. Diese gibt es in drei Varianten. Bautechnisch handelt es sich immer um die gleiche Pumpe, es werden per Software nur neue Steuerfeatures freigeschaltet. Die kleinste Variante agiert “nur” als Regelbare Pumpe. Die Pumpfrequenz kann von 50Hz (leiser als das Festplattenbrummen) bis 75Hz (höhrbar/vergleichbar mit guten CPU Lüfter). Die Pumpe kann dabei via Aquabus an die AE5 angeschlossen und über diese Konfiguriert und Überwacht werden. Die beiden teureren Versionen bietet dann noch manuelle bzw. temperaturgesteuerte Lüftersteuerung.

Tagged with:
 

OpenWrt im Langzeittest

On 22. 02 2013, in Administration, Wissenswertes, by Raptor 2101

Ich hab seit einer geraumen Zeit OpenWRT im Einsatz und will hier mal meine Meinung zu dieser “Linux-Distribution” kundtun.

Bei OpenWRT handelt es sich wie DD-WRT um eine aus dem WRT54G-Basissystem entstandene, auf Router ausgerichtete Firmware. Viele weitere Projekte wie z.b Freifunk bauen auf OpenWRT auf.

Was zeichnet OpenWRT nun gegenüber anderen Router-Firmwares aus, was macht es empfehlenswert? Kurz und knapp: es ist ein “echtes” Linux. Soll heißen, man hat ein schreibbares  Root-Dateisystem, vollen Zugriff auf /dev, /etc und alle Änderungen überleben einen Reboot. Man kann sämtliche Hilfs- und Automatisierungsfunktionen abschalten bzw. deinstallieren und ggf. auf einem “nackten” System aufsetzen. Mittels des Paketmanagers opkg kann man bequem fast alles nachinstallieren was man so braucht, wenn mal etwas fehlt kann man es sich auch selber ein Paket bauen. Alles in allem ein Eldorado. Kniffelige Setups lassen sich relativ unkompliziert Umsetzen, Dinge die mit anderen Firmwares nicht funktionieren (VLAN  Konfiguration pro Port) sind mit OpenWRT ohne größeren Aufwand umgesetzt. All das hat dafür gesorgt, dass OpenWRT momentan auf allen meinen Routern im Einsatz ist.

Es gibt aber auch Schattenseiten. Die große Funktionsvielfalt geht meist mit einem Konfigurationswust einher. Bei OpenWRT versucht man das über eine einheitliche Konfigurationsschnittstelle  abzufangen (UCI). Dabei gibt es unter /etc/config eine reihe von Konfigfiles die immer “gleich” gestaltet sind. Diese werden mittels Paketabhängiger Scriptes dann in die eigentlichen Konfigurationsfiles umgesetzt. Aus der WLAN-Config Datei /etc/config/wireless wird zb das /tmp/hostapd.conf erzeugt und anschließend der hostapd Dienst hochgefahren. Dieses Verfahren hat drei Schwächen. Wenn der Paketverwalter keine UCI Unterstützung vorsieht, ist man wieder mit der Hand am arm unterwegs. Manchmal wird sowohl UCI als auch die eine eigene Konfiguration benötigt, dann wird es schnell unübersichtlich. In seltenen Fällen empfinde ich das UCI Interface komplizierter als die ursprüngliche Konfigurationsmethoden. Die UCI-Firewall Konfig schmeiße ich immer als erstes runter und setzte mir alles selber mit iptables-befehlen auf.

Was noch Problematisch ist, ist der  Upgrade/Deploy-Prozess. Es gibt verschiedene Varianten OpenWRT auf seinen Router zu bekommen. Einmal die “stable” Images, dann den Entwickler-Images und zu guter letzt kann man sich aus dem Entwickler-Repo auch das latest-Image zusammenbauen. Die komfortabelste Variante ist ein stable-Image. Diese wird über die gesamte zeit mit Packages versorgt. Das Entwickler-Image (trunk) benötigt man, wenn die eigene Hardware noch nicht von dem stable-Image unterstützt wird. Hier hat man mit zwei Problemen zu rechnen. Zum einen fliegen Pakete aus dem Repo einfach raus. Das würde einen normalerweise erst bei der nächsten stable-Version (mit Vorwarnung) ereilen. Das zweite Problem ist, sobald die Entwicklerversion auf einen neuen Kernel setzt, werden die module entsprechend hochgezogen. Will man ein Paket aktualisieren steht nun ein komplettes Router flashen an. Nach dem flashen hat man quasi wieder einer jungfräulichen Router. Einzig ein paar vor definierte Ordner und Dateien (inkl /etc)  werden erhalten. Pakete und Anpassungen muss man manuell nachziehen. Das macht die Fernwartung ein wenig kniffelig.

Das sind aber auch die einzigen Probleme, die ich mit dieser Distri hatte. Ansonsten sind in ca einem Jahr betrieb keine einziger störender Effekt aufgetreten. Die ganze Zeit liefen die Router stabil und ohne nennenswerten Konfiguration/Administrationsaufwand.

Tagged with: