Let’s Encrypt und Puppet

lets-encrypt-logoIch habe früher fast alle meine Zertifikate von CAcert bezogen. Ich habe sie regelmäßig aktualisiert und für das deployen habe ich ein Puppet Modul, dass die Zertifikate verteilt.

Nach und nach bin ich auf Let’s Encrypt Zertifikate umgestiegen. Da ein hoher Grad an Automatisierung bei Let’s Encrypt immer wieder propagiert wird dachte ich mir, dass sollte auch mit Puppet dann kein zu großes Problem sein. Hier die Lösung, die bei mir nun in Betrieb ist:

Als erstes habe ich das Puppet Modul bzed/letsencrypt installiert. Das Modul benötigt eine PuppetDB. Über exported resources  transportiert es die CSRs auf den puppetmaster, macht dort die gesamte Abwicklung und transferiert dann die Ergebnisse wieder zurück auf den Node. Das funktioniert auch sehr gut.

Auf dem Puppetmaster habe ich die Klasse eingebunden und einige wenige Einstellungen gesetzt (hiera). Bei dem Hook handelt sich m übrigen um einen letsencrypt.sh Hook:

---
classes:
  - letsencrypt

letsencrypt::challengetype: 'http-01'
letsencrypt::hook_source: 'puppet:///modules/helper/%{::fqdn}/le_hook.sh'

Auf den Nodes habe ich die Klasse eingebunden und die Domains definiert für die ein Zertifikat bezogen werden soll:

---
classes:
- letsencrypt

letsencrypt::domains:
- 'foo.example.net'
- 'bar.example.net'
- 'baz.example.net'

PL_logo_vertical_RGB_lgIn meinem recht simplen Szenario ist es so, dass ich einen Gate-Server habe, hinter dem sich alle anderen Maschinen „verstecken“. Dort läuft ein Apache Server als Proxy, der Anfragen über HTTP nach hinten weiterreicht. Die Konfiguration von Apache erfolgt ebenfalls über Puppet. Eine Authentifizierung über DNS für ACME klappt bei mir leider nicht, weswegen ich HTTP nehmen muss. Das habe ich so gelöst, dass ich für die Apache vhosts einfach über ProxyPassMatch den .well-known/acme-challenge/ auf einen Apache Vhost auf dem Puppetmaster weiterreiche. Auf dem Gate-Server sieht das für einen Vhost wie folgt aus:

apache::vhost:
  'proxy-foo.example.net':
    servername: 'foo.example.net'
    serveradmin: 'webmaster@example.net'
    port: '80'
    docroot: '/var/www/empty'
    proxy_dest: 'http://10.20.30.1'
    proxy_pass_match:
      -
        path: '^/.well-known/acme-challenge/(.*)$'
        url: 'http://10.20.30.2/$1'
        params:
          retry: '0'
    headers:
      - 'unset X-Powered-By'
    proxy_preserve_host: true

Auf dem Puppetmaster wiederum läuft ein Vhost, der einfach alle Domains als ServerAlias eingetragen hat.

Nun kommt noch der Hook für letsencrypt.sh ins Spiel den ich oben bereits erwähnt habe. Das Skript schreibt die ACME-Challenge in eine Textdatei in den DocRoot und löscht sie nach dem Erfolg wieder:

#!/bin/bash
 
#
# http-01 hook
#
 
CHALLENGEDIR="/var/www/example.net/letsencrypt"
 
done="no"
if [[ "$1" = "deploy_challenge" ]]; then
    echo "${4}" > "${CHALLENGEDIR}/${3}"
    chmod 644 "${CHALLENGEDIR}/${3}"
    done="yes"
fi
 
if [[ "$1" = "clean_challenge" ]]; then
    rm "${CHALLENGEDIR}/${3}"
    done="yes"
fi
 
if [[ "${1}" = "deploy_cert" ]]; then
    # do nothing for now
    done="yes"
fi
 
if [[ ! "${done}" = "yes" ]]; then
    echo Unkown hook "${1}"
    exit 1
fi
 
exit 0

Voila! Es braucht ein paar Durchläufe bis alles über die Puppetdb jeweils transportiert wurde, aber alles läuft vollautomatisch ab. Sehr cool!

Wartungsseite für alle Apache vhosts eines Webservers realisieren

Über eine Lösung um einen einzelnen Apache Vhost mit einer Wartungsseite auszustatten habe ich bereits vor einigen Jahren hier geschrieben.

Jetzt stand ich vor der Aufgabe wegen Wartungsarbeiten auf meinem Webserver eine Wartungsseite für alle dort gehosteten Apache Vhosts zu schalten. Davor sitzt ein Gate-Server mit Apache und mod_proxy. Eine Lösung das zu realisieren wäre auf dem Gate-Server mit mod_rewrite nach dem Vorhandensein einer Maintenance-Datei zu schauen und wenn die Bedingung zutrifft alle Anfragen auf die Wartungsseite weiterzuleiten. Eine solche Lösung ist in Ansätzen unter anderem hier skizziert. Unschön finde ich dabei die unnötig vielen Prüfungen nach der Maintenance-Datei.

Ich habe nun eine andere Lösung realisiert, die in meinen Augen deutlich einfacher und eleganter ist. Auf dem Gate-Server lasse ich einen Apache-Vhost auf einem gesonderten Port laufen auf dem die Wartungsseite angezeigt wird. Für den Fall, dass ich die Wartungsseite vorschalten möchte, leite ich einfach allen HTTP und HTTPS Traffic auf die IP des Gate-Servers und den gesonderten Port um. Mit nur einer iptables Regel ist somit für alle vhosts auf dem Webserver eine Wartungsseite vorgeschaltet:

iptables -t nat -A OUTPUT -p tcp -d INTERNALWEBSERVERIP --match multiport --dports 80,443 -j DNAT --to-destination EXTERNALGATESERVERIP:PORT

Bei dem Apache Vhost auf dem Gateserver ist noch zu beachten, dass man nach Möglichkeit den aufrufenden Browsern / Bots etc. mitteilt, dass es sich um etwas temporäres handelt. Aus diesem Grund habe ich in dem Vhost zwei Dinge beachtet:

  1. Es wird ein HTTP Status Code 503 (Temporarily Unavailable) gesendet
  2. Es wird der HTTP Header Retry-After gesetzt

Im vhost sieht das wie folgt aus. Spannend sind die letzten 3 Zeilen. Meine Wartungsseite heißt übrigens auch 503.html

<VirtualHost *:PORT>
  ServerName maintenance.example.net
  ServerAdmin webmaster@example.net
 
  DocumentRoot "/var/www/maintenance"
 
  <Directory "/var/www/maintenance">
    Options -Indexes
    AllowOverride None
    Require all granted
  </Directory>
 
 
  ErrorLog "/var/log/apache2/maintenance.example.net_error.log"
  CustomLog "/var/log/apache2/maintenance.example.net_access.log" combined 
 
  RedirectMatch 503  ^/(?!503.html)  
  ErrorDocument 503 /503.html
  Header always set Retry-After "18000"
</VirtualHost>

Hotels und (zu bezahlendes) WLAN

Inzwischen war ich in so einigen Hotels unterwegs und immer wieder trifft man auf WLANs, bei denen man fuer die Benutzung zahlen soll. Nach genauerem Blick haben sich die Hersteller oft mehr auf Corporate Design Fragen konzentriert als auf die Sicherheit. Deswegen hier einige Erfahrungen:

Grundsaetzlich ist es sinnvoll, wenn man einen Server hat auf dem man z.B. einen SSH-Server auf alternativen Ports laufen lassen kann. Ich empfehle explizit neben 22 auch 53, 80, 443, 3128 und 8080. Daneben gibt es einen sehr simplen und einfachen Perl-HTTP-Proxy, ich glaube ich hatte den mal aus irgendeinem Linux Magazin:

#!/usr/bin/perl
use HTTP::Proxy;
my $proxy = HTTP::Proxy->new( port => 3129);
$proxy->start;

der die folgende Abhaengigkeit benoetigt:

sudo aptitude install libhttp-proxy-perl

Zu guter letzt hilft natuerlich immer, wenn man weiss, wie man mit SSH externe Ports lokal bindet. Damit kann man z.B. auf dem externen Server den HTTP-Proxy starten, den Port lokal hertunneln, und dann diesen Proxy z.B. in seinem Firefox eintragen… Ein Eintrag in einer ~/.ssh/config koennte wie folgt aussehen:

Host			hotelhelper
HostName		1.2.3.4
User			user
Port			443
LocalForward		3129 localhost:3129

Dann kanns losgehen:

  • Testen welche Ports nach aussen offen sind. Oft wird nur Port 80 und 443 beschraenkt, der Rest ist offen. Man kann sich dann ohne Probleme ueber andere Ports verbinden.
  •  Gucken ob im Netz nicht irgendwo ein Proxy laeuft ueber den man raustunneln kann. Hier kann einem
     sudo aptitude install nmap corkskrew

    helfen

  • Gucken ob DNS-Anfragen richtig aufgeloest werden. Evtl. werden _nur_ http Pakete gefiltert werden auf den offenen Ports, evtl. geht ja SSH auf Port 53 oder 443 raus…
  • Gucken ob klicks auf Portalseiten nicht weitere Dinge oeffnen. In einem Beispiel konnte ich mit einem Klick auf „Hier klicken um mit VISA zu Zahlen“ und der Weiterleitung auf die Seite eines externen Zahlungsanbieters den Proxy dazu bewegen fuer ein Zeitfenster von 30min SSH auf den bekannten Ports zu oeffnen.

Command Line, SSH and webproxy

Ich hatte ja gerade erst darueber geschrieben wie man apt hinter einem proxy benutzen kann, hier noch 2-3 Kleinigkeiten hinzugefuegt.

Als erstes ist es gut, auch die env variable http_proxy=““ zu setzen, damit Programme wie w3m funktionieren:

export http_proxy="http://1.2.3.4:8080"

als zweites ist es natuerlich interessant auch per SSH rauszukommen. Zum Glueck gibt es dafuer in den Ubuntu repositories

aptitude install corkscrew

einem „tunnel TCP connections through HTTP proxies“ Programm. Dafuer die folgenden beiden Zeilen in die ~/.ssh/config hinzufuegen

Host *
ProxyCommand /usr/bin/corkscrew 1.2.3.4 8080 %h %p

wenn es eine Fehlermeldung geben sollte wie:

Proxy could not open connnection to example.net: Proxy Error ( The
  specified Secure Sockets Layer (SSL) port is not allowed. ISA Server
  is not configured to allow SSL requests from this port. Most Web
  browsers use port 443 for SSL requests.  )

einfach mal den SSH-Server auch auf Port 443 lauschen lassen (echo „Port 443 >> /etc/ssh/sshd_config; /etc/init.d/sshd restart) und dann auf dem Port verbinden.