Let’s encrypt!

Ich habe meine Seiten auf meinem Debian/Apache Webserver mit SSL verschlüsselt und dabei auf die kostenlose CA Let’s Encrypt! zurückgegriffen.

Es gibt viele Wege, wie man diese CA benutzen kann, aber der certbot ist echt der Hammer. So einfach geht es:

cd /usr/local/sbin
wget https://dl.eff.org/certbot-auto
chmod 750 certbot-auto
certbot-auto --apache

Danach wird man durch alle Schritte geführt und kann inerhalb kürzester Zeit funktionierende SSL Zertifikate nutzen, die sich vollautomatisch installieren.

Die Zertifikate sind zwar nur drei Monate gültig, aber mit certbot installierte Zertifikate lassen sich über diesen automatisch aktualisieren, so dass man sich nie wieder drum kümmern muss. Ein Eintrag wie dieser im Crontab von root reicht:

1 6,18 * * * /usr/local/sbin/certbot-auto renew --post-hook "apache2ctl restart" &>/dev/null

Lasst uns gemeinsam das Internet sicherer machen und „Let’s encrypt!

letsencrypt
https://eliyah.co.il/ ist SSL gesichert!
Advertisements
Let’s encrypt!

Welche Prefixe liefert welches AS – Teil 2

Mit der -i origin Abfrage vom letzten Post gibt es zu viele Einschränkungen. Das funktioniert nur mit der RIPE und andere IRR haben eine andere whois-Syntax und um ein ganzes AS-set rekursiv aufzulösen, muss ich unter Umständen viele, viele Male den Befehl anwenden. Das zu automatisieren, hat natürlich schon mal jemand gemacht. Das ISC hat mit dem IRRToolset ein eben solches herausgebracht. Ich habe es mir heruntergeladen und unter Debian 7 kompiliert. Dafür müssen ein paar Pakete installiert werden:

apt-get install make g++ bison flex

Danach kann man es wie üblich mit ./configure; make; make install kompilieren und installieren. Drei Programme werden installiert: peval, rpslcheck, rtconfig

Mit peval kann man rekursiv AS-Sets durchsuchen. Hier wieder ein Beispiel mit dem AS meines Arbeitgebers:

% peval 'afi ipv4, ipv6 AS-LWL'

({195.191.196.0/23, 193.47.147.0/24, 185.76.188.0/22, 185.76.188.0/23, 185.55.116.0/22, 185.55.118.0/24, 185.55.116.0/23, 185.55.116.0/24, 185.55.117.0/24, 185.52.160.0/22, 152.143.0.0/16, 109.69.64.0/21, 95.47.96.0/24, 91.202.40.0/22, 87.253.189.0/24, 46.19.88.0/21, 46.19.88.0/22, 46.19.92.0/22, 46.19.88.0/24, 46.19.89.0/24, 46.19.90.0/24, 46.19.91.0/24, 46.19.92.0/24, 46.19.93.0/24, 46.19.94.0/24, 46.19.95.0/24, 37.72.144.0/21, 37.72.144.0/22, 37.72.148.0/22, 37.72.144.0/24, 37.72.145.0/24, 37.72.146.0/24, 37.72.147.0/24, 37.72.148.0/24, 37.72.149.0/24, 37.72.150.0/24, 37.72.151.0/24, 31.209.80.0/20, 31.24.144.0/21}) OR ({2a04:ec40:ff28::/48, 2a04:ec40:ff29::/48, 2a04:ec40:ff20::/48, 2a04:ec40:ff21::/48, 2a04:ec40:ff22::/48, 2a04:ec40:ff23::/48, 2a04:ec40:ff24::/48, 2a04:ec40:ff25::/48, 2a04:ec40:ff26::/48, 2a04:ec40:ff27::/48, 2a04:ec40:ff18::/48, 2a04:ec40:ff19::/48, 2a04:ec40:ff14::/48, 2a04:ec40:ff15::/48, 2a04:ec40:ff16::/48, 2a04:ec40:ff17::/48, 2a04:ec40:ff12::/48, 2a04:ec40:ff13::/48, 2a04:ec40:ff10::/48, 2a04:ec40:ff09::/48, 2a04:ec40:ff04::/48, 2a04:ec40:ff05::/48, 2a04:ec40:ff06::/48, 2a04:ec40:ff07::/48, 2a04:ec40:ff02::/48, 2a04:ec40:ff03::/48, 2a04:ec40:ff01::/48, 2a02:2918::/32, 2a02:2918:adad::/48, 2a02:16d0::/32, 2a00:c380::/32, 2001:67c:1b43::/48})

Wie man sieht, ist das Ergebnis deutlich länger als eine einfache whois-Abfrage nach dem AS. Das liegt daran, dass nun rekursiv alle Prefixe von allen im AS-set definierten AS mit ausgegeben werden.

Mit rpslcheck hat man einen erweiterten whois-client, einfach mal ausprobieren. Das Programm rtconfig wiederum ist sehr spannend. Es kann Konfigurationen für Cisco und Juniper-Geräte generieren. Ich muss mir das mal genauer anschauen. Aber ehrlich gesagt, bei so wichtigen Geräten im Netz will ich lieber selbst die Konfig schreiben und das nicht einem Script überlassen.

Welche Prefixe liefert welches AS – Teil 2

Nach Hause telefonieren!

Ich habe ein Gerät mit Debian aufgesetzt, von dem ich noch nicht weiss, wo es mal landen wird. Also wollte ich, dass es nach Hause telefoniert, sobald es online geht und mir eine Shell gibt.

Das Konzept:

  • Ethernet-Interface(s) auf DHCP
  • ssh Tunnel zu meinem Rechner zuhause mit remote Port forwarding und automatischem ssh-Login über key-authentication
  • Telnet server (doppelt ssh ginge auch, aber warum?)
  • Script, das alle 5 Minuten versucht, nach Hause (feste IP oder dyndns-Hostname) zu telefonieren und es bleiben lässt, wenn der Tunnel steht
  • telnet auf localhost und den getunnelten Port öffnet eine shell auf dem entfernten Gerät

So geht’s:

  • remote tunneling in der sshd_config erlauben (danach sshd neu starten):
# Allow remote port forwarding
GatewayPorts yes
  • Schlüsselpaar auf dem remote host anlegen und verteilen
ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/lalala/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/lalala/.ssh/id_rsa.
Your public key has been saved in /home/lalala/.ssh/id_rsa.pub.
The key fingerprint is:
4a:ad:04:26:3c:ae:df:0d:e7:3b:3c:77:54:45:b3:97
The key's randomart image is:
+--[ RSA 2048]----+
|          .oo.   |
|         .  o.E  |
|        + .  o   |
|     . = = .     |
|      = S = .    |
|     o + = +     |
|    . . o + o .  |
|           . o   |
|                 |
+-----------------+
scp ~/.ssh/id_rsa.pub lalala@callhomeip:.ssh/lalala.pub
    - und dort -
cat .ssh/lalala.pub >> .ssh/authorized_keys
  • telnet server installieren (apt)
  • service telnet2323 TCP auf Port 2323 in /etc/services anlegen
  • inetd oder xinetd anpassen:
telnet2323             stream  tcp     nowait  telnetd /usr/sbin/tcpd  /usr/sbin/in.telnetd
  • script auf dem remote host schreiben
#!/bin/bash
# callhome script

RUNS=$(netstat -p | fgrep 2323 | wc -l)

if [ $RUNS -ge 1 ]; then
   exit 0
fi

ssh -f -nNT -R 2323:localhost:2323 lalala@callhomeip

  • cronjob schreiben, der das script alle 5 Minuten aufruft
  • telnet auf localhost port 2323
  • Ethernet Interface in /etc/network/interfaces (oder wo auch immer das auf Deiner Distri ist) auf hotplug und DHCP stellen

Das gute ist: Das funktioniert auch hinter NAT und man muss wirklich nicht wissen, wo das Gerät aufgebaut wird. Das Script kann man sicher auch schöner bauen, aber es muss ja nur ein Mal funktionieren. Danach kann man eine „normale“ IP-Config und einen ssh-Zugang auf das Gerät konfigurieren.

Nach Hause telefonieren!