Schlagwort: SelfHosted (Seite 5 von 8)

FreeBSD: Verschlüsseltes ZFS-Backup auf USB-Platte mit geli

23. Mai 2015 / Sebastian van de Meer / Keine Kommentare

FreeBSD-Notebook erstellt per ZFS-Snapshot und zfs send ein verschlüsseltes Backup auf eine USB-Platte mit geli, Schlüsseldatei, Passphrase und sicherem Aushängen.

Ein Notebook mit Full-Disk-Encryption verdient auch ein verschlüsseltes Backup. Plan: ZFS-Snapshots per zfs send auf eine USB-Platte schieben, die komplett mit geli verschlüsselt ist. Schlüssel und Passphrase sicher aufbewahren, fertig.

Hinweis: Seit OpenZFS 2.0 (FreeBSD 13+) gibt es native ZFS-Verschlüsselung (zfs create -o encryption=aes-256-gcm). Damit entfällt geli als Zwischenschicht. Auf älteren Systemen oder wenn man die gesamte Platte unabhängig vom Dateisystem verschlüsseln will, bleibt geli die richtige Wahl.

USB-Platte verschlüsseln

Platte einstecken und per dmesg das Device identifizieren, in diesem Fall da0. Dann mit gpart eine neue GPT-Partitionstabelle anlegen und eine Partition erstellen.

geli braucht einen Schlüssel aus Zufallsdaten:

dd if=/dev/random of=./backup-key bs=256 count=1

Mit diesem Schlüssel die verschlüsselte Partition einrichten:

geli init -s 4096 -K ./backup-key -l 256 /dev/da0s1
Enter new passphrase:
Reenter new passphrase:

Metadata backup can be found in /var/backups/da0s1.eli and
can be restored with the following command:

    # geli restore /var/backups/da0s1.eli /dev/da0s1

Partition öffnen:

geli attach -k ./backup-key /dev/da0s1
Enter passphrase:

ZFS-Pool anlegen

Auf der geöffneten geli-Partition (da0s1.eli) den ZFS-Pool erstellen:

zpool create usb-backup /dev/da0s1.eli

zpool list
NAME         SIZE  ALLOC   FREE  CAP  HEALTH
zroot        460G   184G   276G  40%  ONLINE
usb-backup   928G   296K   928G   0%  ONLINE

Backup starten

Initiales Vollbackup per zfs send -R (rekursiv, alle Datasets und Snapshots):

zfs send -R zroot@auto-2015-05-23-21-00-00 | zfs recv -u usb-backup/notebook

Die Option -R sendet alles rekursiv. Die Option -u beim Empfänger verhindert, dass die Datasets auf der USB-Platte gemountet werden. Bei allen folgenden Backups muss nur noch die Differenz zwischen zwei Snapshots übertragen werden.

Platte sicher aushängen

Drei Schritte in der richtigen Reihenfolge:

Sync erzwingen, alle Daten sicher auf die Platte schreiben
ZFS-Pool exportieren
geli-Partition schließen

sync
zpool export usb-backup
geli detach /dev/da0s1

Wichtig: Den Schlüssel (backup-key) an einem dritten Ort aufbewahren, weder auf dem Notebook noch auf der Backup-Platte. Ohne Schlüssel und Passphrase sind die Daten nicht wiederherstellbar.

Mehr zu ZFS-Backups: Automatische ZFS-Snapshots und ZFS send/recv Fehler beheben. Fragen? Einfach melden.

OPENPGPKEY: GPG-Schlüssel direkt im DNS veröffentlichen

1. April 2015 / Sebastian van de Meer / Keine Kommentare

OPENPGPKEY-Record für einen GPG-Schlüssel im DNS mit Hash des E-Mail-Localparts, DNSSEC-Schutz, Base64-kodiertem Public Key und automatischem Abruf per GnuPG.

Schon länger kann man GPG-Schlüssel per CERT-Record im DNS hinterlegen, allerdings nur als Verweis auf einen Ort, an dem der Schlüssel liegt. Mit dem OPENPGPKEY Resource Record (RFC 7929) geht es einen Schritt weiter: Der komplette öffentliche Schlüssel steckt direkt im DNS-Record. Ist die Zone per DNSSEC gesichert, kann der Schlüssel nicht gefälscht werden, unabhängig von Keyservern und den dort möglicherweise kursierenden Fake-Keys.

Aufbau des Records

Der Hostname des OPENPGPKEY-Records wird aus der E-Mail-Adresse abgeleitet. Aus dem Localpart (alles vor dem @) wird ein SHA-256-Hash gebildet und die ersten 56 Zeichen davon als Subdomain unter _openpgpkey.domain verwendet. Für user@example.de:

echo -n "user" | sha256sum
# Ergebnis: 04f8996da763b7a969b1028ee3007569eaf3a635486ddab211d512c85b9df8fb
# Die ersten 56 Zeichen des Hashes werden zum Hostnamen:

04f8996da763b7a969b1028ee3007569eaf3a635486ddab211d512c85b._openpgpkey.example.de. IN OPENPGPKEY <base64-encoded-key>

Der Wert des Records ist der GPG Public Key im Binärformat, Base64-kodiert.

Record erzeugen

Den Hash des Localparts berechnen:

echo -n "kernel-error" | sha256sum | cut -c1-56
# 4e1543e4c2a42754aa23025a940a30d0d3d106025c9e03be8e525ac4

Den Public Key exportieren und Base64-kodieren:

gpg --export --export-options export-minimal kernel-error@kernel-error.com \
  | base64 -w 0

Beides zusammen ergibt den Zoneneintrag:

4e1543e4c2a42754aa23025a940a30d0d3d106025c9e03be8e525ac4._openpgpkey.kernel-error.com. IN OPENPGPKEY mQINBF...==

Zugegeben, der Record sprengt etwas die Zonenlesbarkeit. Ein GPG-Schlüssel hat schnell mehrere Kilobyte, das wird im Zonefile eine lange Zeile. BIND kommt damit problemlos klar.

Schlüssel automatisch aus dem DNS holen

GnuPG ab Version 2.1 kann OPENPGPKEY-Records direkt abfragen. Will man eine E-Mail verschlüsseln und hat den Schlüssel des Empfängers noch nicht, reicht:

gpg --auto-key-locate dane --locate-keys kernel-error@kernel-error.com

GnuPG sucht den OPENPGPKEY-Record im DNS, prüft die DNSSEC-Signatur und importiert den Schlüssel automatisch. Kein Keyserver nötig, kein manueller Import.

Testen

Ob der Record korrekt im DNS steht, lässt sich online prüfen: openpgpkey.info, E-Mail-Adresse eingeben, der Dienst fragt den OPENPGPKEY-Record ab und zeigt den gefundenen Schlüssel an.

OPENPGPKEY vs. CERT-Record

Der ältere CERT-Record enthält nur eine URL zum Schlüssel, der Client muss den Schlüssel dann von dort herunterladen. OPENPGPKEY packt den kompletten Schlüssel ins DNS. Vorteil: Ein einziger DNS-Lookup genügt, kein zusätzlicher HTTP-Request nötig. Nachteil: Große DNS-Antworten, die bei UDP-Transport fragmentiert werden können, aber mit passender EDNS-Konfiguration kein Problem.

Siehe auch: GPG-Schlüssel per PKA im DNS, GPG: E-Mails signieren und verschlüsseln mit GnuPG, Der sichere GPG-Schlüssel

Fragen? Einfach melden.

DNSSEC, DANE und TLSA mit Postfix: Hintergründe und aktuelle Probleme

16. Januar 2015 / Sebastian van de Meer / Keine Kommentare

Seit ein paar Tagen scheint das Thema DNSSEC, DANE und TLSA im Zusammenhang mit Postfix im Internet besonders aktiv zu sein. Ich bekomme täglich Anfragen dazu und einige scheinen zu testen — E-Mails mit Random-Empfängern an meine Domains. Gegen Tests habe ich nichts, aber grob abgesprochen wäre schön, mein Monitoring wird sonst immer so wuschig.

Kurz zusammengefasst:

Basis von allem ist DNSSEC.
TLSA-Records sind DANE.
Postfix kann TLSA-Records auswerten, ohne selbst welche für sein System zu haben.

Weiterführend:

Fragen? Einfach melden.

Postfix: TLS-Protokoll und Cipher-Infos im E-Mail-Header anzeigen

17. Dezember 2014 / Sebastian van de Meer / Keine Kommentare

Als kleiner Postfix Tipp am Rande…. Wenn man gerade mit seinen TLS Einstellungen „herumspielt“, kann es helfen die groben Informationen für jede E-Mail nicht immer aus dem Logfile sammeln zu müssen.

Postfix bietet die schnelle Möglichkeit, genau diese Informationen einfach mit in den Mail Header zu packen.

Folgende Konfigurationserweiterung ist dafür nötig:

/etc/postfix/main.cf:
smtpd_tls_received_header = yes

Ab diesem Moment finden sich Informationen wie die unten stehende in eingehenden E-Mails.

So long….

Received: from mx01.domain.de (mx01.domain.de [1.2.3.4])
    (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits))
    (No client certificate requested)
    by smtp.kernel-error.de (Postfix) with ESMTPS id 245478112D9
    for <kernel-error@kernel-error.com>; Wed, 17 Dec 2014 05:15:10 +0100 (CET)

Siehe auch: Client-Initiated Renegotiation deaktivieren

Fragen? Einfach melden.

Postfix: EECDH mit 2048-Bit DH und spezifischen Kurven konfigurieren

17. Dezember 2014 / Sebastian van de Meer / Keine Kommentare

Kex exchange basierend auf EECDH (diese elliptischen Kurven nach DH Diffie-Hellmann), sollte ja inzwischen ein alter Hut sein. Ich gehe also mal von einer aktivieten und funktionsfähigen Konfiguration aus (irgendwo habe ich das wohl auch schon mal beschrieben).

Im Standard läuft dieses nun bei 1024bit also EECDH mit ca. 128bit (smtpd_tls_eecdh_grade=strong). Möchte man alles auf 2048bit EECDH mit ca. 192bit aufbohren… Was ca. die doppelte „Sicherheit“ zu EECDH mit 128bit bedeutet, dann ist folgendes zu erledigen.

Zuerst benötigen für eine große prime group:

$ cd /etc/postfix
$ openssl dhparam -out dh_2048.tmp 2048 && mv dh_2048.tmp dh_2048.pem
$ chmod 644 dh_2048.pem

Dann Postifix mitteilen, dass er sie bitte nutzten soll (ist kein Typo, gehört zur Option „smtpd_tls_dh1024_param_file„).

/etc/postfix/main.cf:
    smtpd_tls_dh1024_param_file = /etc/postfix/dh2048.pem
    smtpd_tls_dh512_param_file = /etc/postfix/dh512.pem

Nun wechselt smtpd_tls_eecdh_grade von strong zu ultra und ich setzte noch die zu verwendende „Kurve“ fest.

/etc/postfix/main.cf:
    smtpd_tls_eecdh_grade = ultra
    tls_eecdh_strong_curve = prime256v1
    tls_eecdh_ultra_curve = secp384r1

Diese Aktion könne nicht ganz Schmerzfrei sein. Für privat und mein Testsystem sicher zu verantworten. Manche MSA (Mail SUbmission Agent) könnten damit Probleme bekommen. Hat also jemand ein Problem mit E-Mail zu senden, bitte melden.

So long….

Siehe auch: Perfect Forward Secrecy

Fragen? Einfach melden.

TLS_FALLBACK_SCSV Debian 7 Wheezy OpenSSL 1.0.1e to 1.0.1j Upgrade

9. Dezember 2014 / Sebastian van de Meer / Keine Kommentare

Veraltet: Debian 7 (Wheezy) hat seit 2018 keinerlei Support mehr. TLS_FALLBACK_SCSV ist seit Jahren in allen aktuellen OpenSSL-Versionen enthalten und muss nicht mehr manuell kompiliert werden.

Wer bei seinem Debian TLS_FALLBACK_SCSV im Apache nutzen möchte, muss im Grunde nur auf eine OpenSSL Version >=1.0.1j wechseln.

Einen direkten Backport gibt es dafür leider nicht, also selbst übersetzten. Dazu nutzt man einfachsten direkt den „Debian-Weg“.

Vorbereiten fürs Kompilieren:

$ cd /usr/src
$ apt-get install build-essential fakeroot
$ apt-get build-dep openssl

Herunterladen der aktuellen Version:

$ wget http://ftp.de.debian.org/debian/pool/main/o/openssl/openssl_1.0.1j-1.dsc
$ wget http://ftp.de.debian.org/debian/pool/main/o/openssl/openssl_1.0.1j.orig.tar.gz
$ wget http://ftp.de.debian.org/debian/pool/main/o/openssl/openssl_1.0.1j-1.debian.tar.xz

Auspacken des Archives und mit den Patchen „verknüpfen“:

$ dpkg-source -x openssl_1.0.1j-1.dsc

Ins neue Verzeichnis wechseln:

$ cd openssl-1.0.1j

Kompilieren und deb Pakete erstellen:

$ dpkg-buildpackage -us -uc -rfakeroot

Die neuen Pakete installieren:

$ cd ..
$ dpkg -i libssl1.0.0_1.0.1j-1_amd64.deb libssl1.0.0-dbg_1.0.1j-1_amd64.deb libssl-dev_1.0.1j-1_amd64.deb libssl-doc_1.0.1j-1_all.deb openssl_1.0.1j-1_amd64.deb

Kontrolle der Version:

$ openssl version
OpenSSL 1.0.1j 15 Oct 2014

ACHTUNG… Ab diesem Moment ist man natürlich selbst dafür verantwortlich Pachte zu installieren.

So long…..

Selbstverständlich profitieren damit alle Anwendungen, die auf OpenSSL aufbauen, so auch Postfix, Dovecot usw:

$ openssl s_client -connect smtp.kernel-error.de:465 -fallback_scsv -no_tls1_2
CONNECTED(00000003)
140410198378152:error:1407743E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert inappropriate fallback:s23_clnt.c:770:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 215 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

U-P-D-A-T-E

Denkt an die Updates.

$ openssl version
OpenSSL 1.0.1k 8 Jan 2015

Openfire: 404 Remote Server Not Found bei S2S-Verbindungen mit TLS

19. November 2014 / Sebastian van de Meer / Keine Kommentare

Seit ich für die Server-zu-Server-Verbindungen (S2S) auf meinem Openfire TLS erzwinge, melden sich andere Openfire-Admins: Ihre User bekommen ein „404 remote server not found“. Nachrichten gehen nur in eine Richtung durch. Wenn die Unterhaltung einmal läuft, klappt es für eine Weile. Ein seltsamer Effekt der nicht direkt auf die Ursache schließen lässt.

Das Problem

Das Problem liegt nicht am eigenen Server und nicht am DNS. Es liegt am Java-Keystore auf der Gegenseite. Java 6 und einige Versionen von Java 7 können die Zertifikatskette nicht korrekt aufbauen, wenn das Intermediate-Zertifikat der CA fehlt. Mein Server sendet es zwar mit, aber Java ignoriert es und versucht die Kette allein aus dem lokalen Truststore zu bauen.

Im warn.log des betroffenen Openfire findet man dann:

org.jivesoftware.openfire.server.ServerDialback - Error verifying key of remote server: jabber.kernel-error.de
org.jivesoftware.openfire.server.ServerDialback - ServerDialback: OS - Ignoring unexpected answer in validation

Die Lösung: Intermediate-Zertifikat importieren

Der Admin des betroffenen Openfire muss das Intermediate-Zertifikat der CA in den Java-Truststore importieren. Auf einem Debian-System:

cd /etc/openfire/security/
/etc/init.d/openfire stop

# Intermediate-Zertifikat der CA herunterladen
wget "https://example-ca.com/intermediate.crt"

# In den Truststore importieren
keytool -import -keystore truststore -alias ca-intermediate -file intermediate.crt
# Passwort: changeit (Java-Default)

/etc/init.d/openfire start

Das Prinzip gilt für jede CA. Das Intermediate-Zertifikat von der Webseite der CA herunterladen und mit keytool in den Truststore importieren. Falls das Zertifikat bereits vorhanden ist, meldet keytool das und man kann den Import überspringen.

Prüfen ob die Kette stimmt

Mit openssl lässt sich prüfen ob der Server das Intermediate-Zertifikat korrekt ausliefert:

openssl s_client -showcerts -connect jabber.example.com:5222 -starttls xmpp

Entscheidend ist die letzte Zeile der Ausgabe:

Verify return code: 0 (ok)

Steht dort etwas anderes, fehlt ein Zertifikat in der Kette oder das Intermediate-Zertifikat wird nicht mitgesendet. In dem Fall muss der Serverbetreiber seine Zertifikatskonfiguration in Openfire prüfen.

Wer schon dabei ist die TLS-Konfiguration anzufassen: Im Beitrag zu unsicheren Ciphern und Protokollen in Openfire steht wie man die veralteten Algorithmen loswird.

Fragen? Einfach melden.

Kein Jabber/XMPP mehr ohne Transportverschlüsselung

20. Oktober 2014 / Sebastian van de Meer / Keine Kommentare

Hallo zusammen,

wie ja bereits vor einiger Zeit angekündigt, habe ich heute TLS als Transportverschlüsselung zwischen den Server to Server Verbindungen erzwungen. Für die Clients s2c besteht dieser Zwang bereits seit langem, nun also auch für die Verbindungen zwischen der Server.

Ich habe mir natürlich vorher die Mühe gemacht, andere Serverbetreiber anzuschreiben, wenn ich zu ihnen keine verschlüsselte s2s Verbindung aufbauen konnte. Ein paar sind aktiv geworden, ein paar nicht. Die Anzahl der nicht verschlüsselten s2s Verbindungen ist denn noch verschwindend gering! Ich habe diese Verbindungen also hiermit bewusst „abgehängt“.

Sollte ihr also aktuell Probleme mit der Verbindung zu oder von meinem System haben, bitte einfach melden!

So long…

Siehe auch: Openfire: Unsichere TLS-Cipher deaktivieren

Fragen? Einfach melden.

IP Reverse Map Delegation: Einrichtung und Fehlerbehebung

17. Oktober 2014 / Sebastian van de Meer / Keine Kommentare

IP-Reverse-Map-Delegation nach RFC 2317 mit Provider-Zone, Kunden-Subzone, CNAME-Verweisen, PTR-Antwort und Troubleshooting-Hinweisen.

Reverse Map Delegation nach RFC 2317 klingt komplizierter als es ist. Es löst ein konkretes Problem: Wer ein kleines IP-Netz hat (kleiner als /24), kann normalerweise keine eigene PTR-Zone betreiben. Mit Reverse Map Delegation geht es doch.

Warum man es braucht

In der guten alten Zeit bekam man ein /24 (256 Adressen). Da legt man einfach eine Zone 3.2.1.in-addr.arpa. an und fertig. Heute bekommt man, wenn überhaupt, ein /29 (8 Adressen). Und da liegt das Problem: DNS-Zonen werden am Punkt getrennt. Bei einem /24 passt das, bei einem /29 gibt es keinen Punkt an dem man die Zone aufteilen kann.

Der Provider behält also die /24-Zone und richtet für das kleine Subnetz CNAMEs ein, die auf eine „Sub-Zone“ des Kunden zeigen. Der Kunde kann dann seine PTR-Records selbst verwalten.

Die Provider-Seite

In der /24-Zone des Providers wird für das Subnetz 1.2.3.0/29 eine Delegation eingerichtet. Jede IP-Adresse bekommt einen CNAME in die Sub-Zone des Kunden:

$ORIGIN 3.2.1.in-addr.arpa.
$TTL 1D
@   1D IN SOA ns1.kernel-error.de. hostmaster.kernel-error.de. (
              2014101701 ; serial
              6H         ; refresh
              30M        ; retry
              2W         ; expiry
              1D )       ; minimum

         IN NS  ns1.kernel-error.de.
         IN NS  ns2.kernel-error.org.

; Delegation für 1.2.3.0/29 an den Kunden
0/29     IN NS    ns1.vandemeer.de.
0/29     IN NS    ns2.vandemeer.de.
0        IN CNAME 0.0/29.3.2.1.in-addr.arpa.
1        IN CNAME 1.0/29.3.2.1.in-addr.arpa.
2        IN CNAME 2.0/29.3.2.1.in-addr.arpa.
3        IN CNAME 3.0/29.3.2.1.in-addr.arpa.
4        IN CNAME 4.0/29.3.2.1.in-addr.arpa.
5        IN CNAME 5.0/29.3.2.1.in-addr.arpa.
6        IN CNAME 6.0/29.3.2.1.in-addr.arpa.
7        IN CNAME 7.0/29.3.2.1.in-addr.arpa.

Die Kunden-Seite

Der Kunde richtet auf seinem DNS-Server die Sub-Zone ein und kann dort seine PTR-Records setzen wie gewohnt:

$ORIGIN 0/29.3.2.1.in-addr.arpa.
$TTL 1D
@   1D IN SOA ns1.vandemeer.de. hostmaster.vandemeer.de. (
              2014101701 ; serial
              6H         ; refresh
              30M        ; retry
              2W         ; expiry
              1D )       ; minimum

         IN NS  ns1.vandemeer.de.
         IN NS  ns2.vandemeer.de.

0        IN PTR netzadresse.vandemeer.de.
1        IN PTR router.vandemeer.de.
2        IN PTR mailin.vandemeer.de.
3        IN PTR imap.vandemeer.de.
4        IN PTR webserver.vandemeer.de.
5        IN PTR frei.vandemeer.de.
6        IN PTR frei.vandemeer.de.
7        IN PTR broadcastadresse.vandemeer.de.

Ergebnis

Eine Reverse-Lookup-Abfrage für 1.2.3.4 läuft jetzt über den CNAME zum DNS des Kunden und liefert den gewünschten PTR-Record:

dig -x 1.2.3.4 +short
4.0/29.3.2.1.in-addr.arpa.
webserver.vandemeer.de.

Probleme

Wäre ja zu schön, wenn es keine gäbe.

Laut RFC darf ein PTR-Record eigentlich kein CNAME sein, außer in genau diesem Fall. Das RFC ist von 1998, aber es hat sich nicht überall herumgesprochen. Man muss seinem Gegenüber gelegentlich RFC 2317 erklären, bevor die Diskussion weitergeht.

Außerdem macht Postfix Ärger, wenn man reject_unknown_client in den smtpd_restrictions hat. Diese Prüfung erwartet, dass PTR und A/AAAA-Record zueinander passen. Bei Reverse Map Delegation tun sie das nicht, weil der CNAME dazwischen steht:

450 4.7.1 Client host rejected: cannot find your hostname, [4.5.6.7]

Wer einen größeren Mailserver betreibt, sollte auf der Mail-IP kein Reverse Map Delegation einsetzen, sondern den PTR direkt beim Provider setzen lassen. Spart Arbeit und Ärger.

Fragen? Einfach melden.

ownCloud Sync Client Sabayon

27. Juni 2014 / Sebastian van de Meer / Keine Kommentare

Veraltet: ownCloud wird nicht mehr aktiv weiterentwickelt und Sabayon Linux wurde 2020 eingestellt. Der ownCloud-Nachfolger ist Nextcloud.

Auf meinem Sabayon System findet mein Rigo leider keinen owncloud-client. Glücklicherweise baut sich dieser fast von alleine.

Ich lade mir also einfach die beiden Quellpakete qtkeychain-master.zip und mirall-1.6.1rc1.tar.bz2 herunter. Entpacke sie qtkeychain-master in qtkeychain-master und mirall-1.6.1rc1 in mirall. Dann beginne ich mit dem bauen, dabei lege ich den späteren Installationsprefix auf /usr fest damit es am Ende nicht alles unter /usr/local… liegt. Dieses aber, wie so oft, selbst denkend nachmachen, es wird schnell unordentlich.

$ mkdir qtkeychain-build
$ cd qtkeychain-build
$ cmake -DCMAKE_BUILD_TYPE="Debug" cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr ../qtkeychain-master
$ make
$ sudo make install

Jetzt noch der eigentliche owncloud-client.

$ mkdir mirall-build
$ cd mirall-build
$ cmake -DCMAKE_BUILD_TYPE="Debug" cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr ../mirall
$ make
$ sudo make install

Schon lässt sich alles aufrufen und wie gewünscht nutzen. Ach ja, sollten noch Abhängigkeiten fehlen, finden sich diese aktuell alle mit Rigo! Sauberer wäre es ebenfalls direkt Pakete zu erstellen, dann könnte man sie sauberer ersetzten, löschen usw.. Ist mir gerade für diese Nummer zu aufwendig.