Vodafone GigaCube SIM im E3372 Surfstick am LEDE/OpenWRT Router

Ich habe mir Vodafone GigaCube mit einem Volumen von 200 GB / Monat als DSL-Ersatz zugelegt. Der Cube selbst war schnell eingerichtet und im LEDE-Router als Gateway eingetragen. Allerdings muss ich damit ein weiteres Gerät und bekomme auch noch Doppel-NAT. Daher habe ich das ganze auf einen Huawai E3372 Surfstick umgebaut.
Die Prozedur war holpriger als erwartet, was nicht an der Komplexität sondern an den lückenhaften Infos im Netz liegt. Daher trage ich hier mal alle notwendigen Schritte zusammen.
Weiterlesen

Öffentliche IP-Adresse mit Tinc-VPN von einem Server auf einen anderen Tunneln

Für einen Server-Umzug sollte das neue System übergangsweise mit IP-Adressen des alten Systems betrieben werden. Da das neue System bei einem anderen Anbieter gehostet wird als das alte, war eine Übernahme der IP-Adressen via Routing nicht möglich. Daher habe ich ein Routing über einen verschlüsselten Tunnel via Tinc-VPN eingerichtet.

Der Prozess war nicht ganz so einfach wie ich dachte. Wie ich es zum Laufen bekommen habe, dokumentiere ich in diesem Artikel.

Weiterlesen

Xubuntu 15.04 auf dem Laptop mit Hybrid-Suspend (Hibernate after Suspend)

Auf meinem Laptop (Acer Travelmate 8371) habe ich seit etwa einem Jahr Windows endgültig verbannt und hatte bisher ArchLinux am Laufen. Dieses Linux ist extem flexibel und lief bisher am saubersten, bis auf den Fingerprint-Reader wird alles unterstützt. Leider bringt die Flexibilität von ArchLinux auch ein (für mich nebenher kaum noch zu schaffenden) Pflegeaufwand mit, so dass ich mich immer mal in Richtung Ubuntu, konkret Xubuntu umgeschaut habe.

Meine Anforderungen sind:

  • möglichst volle Hardware-Unterstützung (auf Kleinigkeiten kann ich ggf. verzichten)
  • saubere Unterstützung von Standby (Suspend to RAM) und Hibernate (Suspend to Disk)
  • saubere Unterstützung von Hibernate after Suspend (das System geht in den Bereitschaftsmodus, nach einer Weile fährt es in den Ruhezustand – wie man es von Windows her kennt)
  • ordentliche Akkulaufzeit
  • keine nervigen Bugs, die das tägliche Arbeiten behindern

Weiterlesen

Secure your vagrant boxes – replace ssh host keys

Vagrant is a cool piece of software that allows automatic deployment of development machines. It is even usefull to bring the result of development to production. In all cases, security should be a concern. Ready to use box templates often come with a default user (vagrant, password vagrant) and a well-known, insecure private ssh key for that user. This raises a security issue – everyone with network access to the machine can login using the credentials or the ssh key. While this issue is well known and addressed in many discussions (and solved with Vagrant 1.7 which by defautl replaces the keys), another similare issue still exists.

Most box images comes with a ssh host key that was created during the creation of the image. So most running machines will use that hostkey. Since it is well-known, an attacker could easily do a man-in-the-middle-attack to any remote ssh connection going to such a box. In development environments this may no problem (because most connections go from localhost to localhost). But starting with test/integration deployments, ssh connections are more likely to be remote.

My solution for this problem is pretty simple. Since I provision all my boxes with ansible, I use the following snipped to create fresh ssh host keys for each box I run:

# Secure ssh Server-Keys
- local_action: file name=data state=directory
  sudo: false
- local_action: file name=data/ssh-host-keys state=directory
  sudo: false
- name: Creating individual SSH keys for this box
  local_action: command ssh-keygen -t {{ item }} -N "" -f data/ssh-host-keys/ssh_host_{{ item }}_key
                creates=data/ssh-host-keys/ssh_host_{{ item }}_key
  with_items: [ 'dsa', 'ecdsa', 'rsa' ]
  sudo: false
- name: Copying individual SSH private keys for this box to /etc/sshd/
  copy: src=data/ssh-host-keys/ssh_host_{{ item }}_key
        dest=/etc/ssh_host_{{ item }}_key mode=0600
  with_items: [ 'dsa', 'ecdsa', 'rsa' ]
  notify: Restart sshd
- name: Copying individual SSH public keys for this box to /etc/sshd/
  copy: src=data/ssh-host-keys/ssh_host_{{ item }}_key.pub
        dest=/etc/ssh_host_{{ item }}_key.pub mode=0644
  with_items: [ 'dsa', 'ecdsa', 'rsa' ]
  notify: Restart sshd

This should be easy to adapt to other provisioners, including shell provisioner. What it does:

First the script ensires that a local directory data/ssh-host-keys exists. There the new keys will be stored. Placing the keys outside the box allows to keep them even if the box is destroyed/recreated.

If the individual box keys are not present, they are created using ssh-keygen. There are 3 different key algorithms (dsa, ecdsa, and rsa), for each a key pair is created. After this, the keys are copied to /etc/sshd/in the box. Ansible checks if the keys are actually changes and notifies the handler named „Restart sshd“ in this case. The handler restarts the SSH Server so that the new keys are used.

This should work with all base boxes for both, local and remote providers. To provide new keys, simply delete data/ssh-host-keys and run the provisioner again.

Heartbleed-BUG und StartSSL – einfach ein neues Zertifikat erstellen?

Der Heartbleed-SSL-BUG hat viele Nutzer von SSL-Zertifikaten verunsichert. Während einige der CAs anscheinend die Sicherheit des Systems als Ganzes im Blick haben und das kostenlose Widerrufen von Zertifikaten ermöglichen, beharrt StartSSL darauf dass die Sicherung des Schlüssels dem Nutzer obliegt und verlangt ~25 $ für das Widerrufen seiner Zertifikate.

Weiterlesen