-=Kernel-Error=-

IT-Blog von Sebastian van de Meer

Kategorie: Kernel-Error-Blog (Seite 43 von 46)

Persönlicher Tech-Blog von Sebastian van de Meer — Beiträge zu IT-Security, Netzwerken, FreeBSD, Linux, Elektronik und Maker-Projekten.

Datenrettung mit Linux: ntfsundelete, ddrescue und PhotoRec im Praxistest

22. November 2010 / / Keine Kommentare

Ich wollte wissen, wie gut sich Daten mit Linux-Bordmitteln wiederherstellen lassen. Also habe ich eine alte Festplatte genommen und es systematisch ausprobiert. Erst normal gelöschte Dateien, dann ein RAW-Image, und am Ende habe ich die Platte physisch zerstört, um zu sehen was ddrescue und PhotoRec aus den Trümmern holen.

Vorbereitung: Testplatte befüllen

Die älteste funktionierende Platte aus meinem Fundus: eine WD Expert 136BA. Erst komplett mit Nullen überschrieben, dann partitioniert und als NTFS formatiert:

dd if=/dev/zero of=/dev/sdb1
mkfs.ntfs -L TestDatenloeschung -T /dev/sdb1

Einen ca. 1,53 GB großen Ordner mit verschiedensten Dateien habe ich dann so lange auf die Platte kopiert, bis sie voll war.

Dolphin zeigt die Ordner auf der Festplatte
kdf zeigt: Festplatte ist voll

ntfsundelete: Gelöschte Dateien wiederherstellen

Erster Scan, noch ohne etwas gelöscht zu haben:

ntfsundelete -s /dev/sdb1
# Files with potentially recoverable content: 0

Logisch, es wurde ja noch nichts gelöscht. Also ein paar Dateien weg und erneut scannen:

ntfsundelete -s /dev/sdb1
# Files with potentially recoverable content: 154

154 Dateien. Jetzt die Wiederherstellung:

ntfsundelete /dev/sdb1 -u -m '*.*' -p 100 -d /test

Die Optionen: -u für Undelete-Modus, -m '*.*' für alle Dateien (mit -m '*.doc' könnte man nur Word-Dateien holen), -p 100 für nur zu 100 % wiederherstellbare Dateien, -d /test als Zielverzeichnis. Bei Bildern könnte man den Prozentsatz auch niedriger setzen, Teile eines JPEG sind besser als nichts.

Alle 154 Dateien kamen vollständig zurück. Einzige Einschränkung: Dateien mit gleichem Namen werden nicht überschrieben. Sollte man beachten oder per Script lösen.

Arbeiten mit RAW-Images

Im Ernstfall arbeitet man nie mit der Originalplatte. Sobald man den Datenverlust bemerkt, am besten sofort den Stecker ziehen. Jeder weitere Betrieb, selbst ein Herunterfahren, kann die gelöschten Daten überschreiben. Also erst ein RAW-Image ziehen:

dd if=/dev/sdb1 of=/001/TestRettung.img
# 26709984+0 Datensätze ein
# 13675511808 Bytes (14 GB) kopiert, 701,766 s, 19,5 MB/s

ntfsundelete funktioniert genauso mit dem Image-File. Gleiche Ergebnisse, gleiche Wiederherstellung. Genau so soll es sein.

Die Festplatte zerstören

Jetzt wird es interessant. Mich hat natürlich interessiert, was bei einer physisch beschädigten Platte passiert. Also Platte wieder voll gemacht und dann aufgeschraubt.

Festplatte mit freigelegten Gehäuseschrauben
Geöffnete Festplatte, bereit zur Zerstörung

Vorsichtig ein paar Kratzer mit dem Schraubendreher auf die Magnetscheiben gesetzt. Nicht zu viel, aber genug, dass einige Gigabyte unlesbar sein sollten.

Festplatte wird mit einem Schraubendreher zerkratzt
Geöffnete Festplatte wird mit einem Schraubendreher zerkratzt
Geöffnete Festplatte mit zerkratzten Magnetscheiben

ddrescue: 52 Stunden an einer zerkratzten Platte

Platte wieder zugeschraubt und ddrescue drauf losgelassen:

ddrescue -n /dev/sdb1 /001/datenrettung.img /001/datenrettung.log
ddrescue -d -n -r3 /dev/sdb1 /001/datenrettung.img /001/datenrettung.log
ddrescue bei der Arbeit

Nach meiner kleinen Kratzorgie hat ddrescue 52 Stunden an der Platte gefummelt, bevor es durch war.

Wann zum Profi?

Wenn einem die Daten mehr als 3.000 Euro wert sind, sollte man einen professionellen Datenretter aufsuchen. Die nehmen zur Diagnose oft um die 90 Euro und sagen dann, was es wirklich kostet. Bei einem Fall aus 2010 hat ein Kunde mit einer 160 GB HDD und Headcrash einen Kostenrahmen von 15.000 bis 18.000 Euro genannt bekommen. Jede Bewegung an der Platte kann weitere Daten zerstören.

Ich habe selbst mal bei einer Seagate SCSI-Platte die komplette Elektronik von einer baugleichen getauscht, weil sie keinen Spin-Up mehr machte. Lief danach wieder, als wäre nie etwas gewesen. Auch ein Tausch der Schreib-/Leseköpfe hat einmal funktioniert, nachdem einer halb abgerissen war. Die Platte sprang genau ein Mal an, ich konnte sichern, beim nächsten Versuch ging nichts mehr. Solche Experimente klappen nicht immer. Hat man an der Platte herumgefummelt, hat oft auch der Profi keine Chance mehr.

PhotoRec: Dateien anhand des Headers retten

Das ddrescue-Image ließ sich in meinem Fall nicht mehr mounten. Durch die Kratzer war auch das NTFS-Dateisystem total im Eimer, selbst fsck half nicht. Also brauchte ich ein Programm, das Dateien anhand ihres Headers wiederherstellen kann: PhotoRec.

photorec datenrettung_parti_sicher.img
PhotoRec: Auswahl der Festplatte
PhotoRec: Auswahl der Partition
PhotoRec: Auswahl des Dateisystems
PhotoRec bei der Arbeit

PhotoRec hat erstaunlich viele Dateien aus der zerkratzten Platte zurückgeholt. Wer sich das Programm anschaut, sollte sich auch TestDisk vom gleichen Entwickler ansehen. Damit lassen sich gelöschte Partitionen rekonstruieren und noch vieles mehr.

TestDisk mit RAW-Image

Fazit

Für normal gelöschte Dateien auf NTFS reicht ntfsundelete. Bei physischen Schäden ist ddrescue das Mittel der Wahl, um erst ein Image zu sichern. Und wenn das Dateisystem komplett zerstört ist, kann PhotoRec anhand der Datei-Header noch erstaunlich viel retten. Wichtigste Regel: Nie an der Originalplatte arbeiten, immer zuerst ein Image ziehen.

Fragen? Einfach melden.

DNSSEC einrichten: Zonen signieren mit BIND

17. November 2010 / / Keine Kommentare

DNSSEC (Domain Name System Security Extensions) schützt DNS-Antworten vor Fälschung. Ein anfragender Resolver kann damit prüfen, ob die gelieferten Zonendaten tatsächlich vom autorisierten Nameserver stammen und unterwegs nicht verändert wurden. DNSSEC wurde als Mittel gegen Cache Poisoning entwickelt — Serverauthentifizierung findet nicht statt.

Die Vertrauenskette

Was mich beim ersten Lesen zu DNSSEC durcheinandergebracht hat, war das Umherwerfen mit Begriffen: KSK, ZSK, DNSKEY, RRSIG, DS. Im Grunde ist es einfach:

Der KSK (Key Signing Key) hat eine Aufgabe: den ZSK unterschreiben. Der KSK wird als DS-Record in der übergeordneten Zone hinterlegt. Der ZSK (Zone Signing Key) hat auch nur eine Aufgabe: die eigentlichen Zonendaten unterschreiben.

Es beginnt bei der Root-Zone. Die Root-Server wissen, welche Nameserver für die TLDs zuständig sind. Die TLD-Server wissen, welche Nameserver für die einzelnen Domains zuständig sind. Jede Ebene signiert ihre Zone und veröffentlicht den DS-Record der Ebene darunter. So entsteht eine durchgehende Kette vom Root-KSK bis zu meiner Zone.

Will ein Angreifer dafür sorgen, dass www.kernel-error.org auf seinen Server zeigt, hat er zwei Möglichkeiten:

  1. Er antwortet auf die Delegation-Anfrage mit seinem eigenen Nameserver.
  2. Er antwortet mit gefälschter Absenderadresse schneller als der echte Server.

Mit DNSSEC kann der Resolver beide Angriffe erkennen — die gefälschte Antwort hat keine gültige Signatur.

Schematische Darstellung der DNSSEC-Vertrauenskette: Root-KSK signiert TLD, TLD signiert Domain.

DNSSEC in BIND aktivieren

Auf dem autoritativen Nameserver muss DNSSEC-Validierung aktiv sein. In modernen BIND-Versionen (ab 9.16) reicht im options-Block:

options {
    dnssec-validation auto;
};

auto bedeutet, dass BIND den eingebauten Root-Trust-Anchor nutzt und diesen bei KSK-Rollovers automatisch aktualisiert (RFC 5011). Der alte dnssec-enable yes wurde in BIND 9.18 entfernt — DNSSEC ist seitdem immer aktiv.

Zone signieren — der moderne Weg

Seit BIND 9.16 gibt es dnssec-policy. Damit übernimmt BIND die Schlüsselerzeugung, das Signieren und den Key-Rollover vollautomatisch:

zone "kernel-error.org" {
    type primary;
    file "kernel-error.org";
    dnssec-policy default;
    inline-signing yes;
};

Die default-Policy verwendet ECDSAP256SHA256 (Algorithmus 13) — schneller und sicherer als das früher übliche NSEC3RSASHA1 mit 4096-Bit-Schlüsseln. inline-signing yes bedeutet: BIND signiert die Zone im Speicher, die Zonendatei auf der Platte bleibt unsigniert und lässt sich wie gewohnt bearbeiten.

Zone manuell signieren

Wer mehr Kontrolle will oder eine ältere BIND-Version hat, kann die Schlüssel von Hand erzeugen. KSK erstellen:

$ dnssec-keygen -a ECDSAP256SHA256 -f KSK -n ZONE kernel-error.org
Kkernel-error.org.+013+12345

ZSK erstellen:

$ dnssec-keygen -a ECDSAP256SHA256 -n ZONE kernel-error.org
Kkernel-error.org.+013+67890

Die öffentlichen Teile (*.key) in die Zonendatei einbinden und signieren:

$ cat Kkernel-error.org.+013+*.key >> kernel-error.org

$ dnssec-signzone -S -K /pfad/zu/keys -o kernel-error.org kernel-error.org
Verifying the zone using the following algorithms: ECDSAP256SHA256.
Zone signing complete:
Algorithm: ECDSAP256SHA256: ZSKs: 1, KSKs: 1 active, 0 stand-by
kernel-error.org.signed

Dann BIND anweisen, die signierte Zonendatei zu laden. Nach jeder Änderung an der Zone muss neu signiert werden — oder man nutzt inline-signing, dann entfällt das.

DS-Record beim Registrar einreichen

Der öffentliche KSK muss als DS-Record in der übergeordneten Zone landen. Bei der DENIC (.de) und den meisten TLD-Registries gibt es dafür ein Webinterface beim Registrar. Man schickt den öffentlichen KSK hin, der Registrar erstellt daraus einen DS-Record und veröffentlicht ihn neben den NS-Records.

Ob der DS-Record gesetzt ist, lässt sich prüfen, indem man die TLD-Nameserver direkt fragt:

$ dig +short kernel-error.org DS @a0.org.afilias-nst.info
12345 13 2 A1B2C3D4...

Prüfen ob alles funktioniert

Mit dig +dnssec eine signierte Domain abfragen. Das ad-Flag (Authenticated Data) in der Antwort zeigt, dass die DNSSEC-Validierung erfolgreich war:

$ dig +dnssec kernel-error.org @8.8.8.8
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

Grafisch lässt sich die gesamte Vertrauenskette mit DNSviz darstellen — einfach die eigene Domain einsetzen:

Stolpersteine

DNSSEC-Signaturen machen DNS-Antworten deutlich größer als die 512 Bytes, die klassisches DNS über UDP erlaubt. EDNS (RFC 6891) hebt dieses Limit auf. Das ist seit 1999 spezifiziert, aber manche Firewalls und Billig-Router haben damit immer noch Probleme — sie filtern große UDP-Pakete oder EDNS-Optionen.

Wichtig: Gehen die Schlüssel verloren oder die signierte Zonendatei brennt ab, hat man ein Problem. Vor jeder großen Änderung (Key-Rollover, Algorithmus-Wechsel) immer die längste TTL der Zone abwarten. Sonst sind gecachte Antworten mit der alten Signatur noch gültig, während die neue Signatur schon aktiv ist — die Zone wird temporär nicht validierbar.

Meinen „analogen“ DNSSEC-Masterplan dazu habe ich mir damals aufgezeichnet:

Handgezeichneter DNSSEC-Masterplan: Reihenfolge fuer Key-Rollover und Zonenuebergaenge mit TTL-Wartezeiten.

Was man auf DNSSEC aufbauen kann

Wenn die Zone signiert ist, lassen sich darüber weitere Sicherheitsmechanismen verteilen:

Wer einen DNSSEC-validierenden Resolver sucht — dns.kernel-error.de bietet DNS over TLS und DNS over HTTPS mit DNSSEC-Validierung.

Chronik

Dieser Beitrag wurde 2010 veröffentlicht und dokumentiert meine DNSSEC-Einführung über mehrere Jahre:

  • November 2010 — Erste Signierung von kernel-error.org (NSEC3RSASHA1, 4096 Bit).
  • Februar 2011 — DS-Record für kernel-error.org endlich in der .org-Zone veröffentlicht. DENIC kündigt Signierung der .de-TLD an.
  • Februar 2011 — kernel-error.de signiert, über DENIC-Testbed validierbar.
  • Juni 2011 — DENIC signiert .de offiziell, DS-Records in der Root-Zone.
  • Februar 2012 — kernel-error.com ebenfalls signiert. Alle drei Domains komplett.
  • Mai 2012 — GPG-Keys und SSHFP-Records im DNS hinterlegt.
  • August 2013 — DANE/TLSA-Records für alle TLS-Dienste eingerichtet.
  • 2024 — Algorithmus-Wechsel auf ECDSAP256SHA256 (Algorithmus 13). Anleitung oben entsprechend aktualisiert.

Siehe auch: DNSSEC und DANE

Fragen? Einfach melden.

Eigenen Jabber-Server betreiben: Warum und wie mit Openfire

3. November 2010 / / Keine Kommentare

Jabber, offiziell XMPP, ist ein offenes Messaging-Protokoll. Kein zentraler Betreiber, kein Vendor Lock-in, kein Unternehmen das die Nutzungsbedingungen diktiert. Jeder kann einen eigenen Server betreiben, und die Server sprechen untereinander. Wie E-Mail, nur für Messaging.

Warum ein eigener Server

Bei kommerziellen Messengern gibt man mit der Nutzung Rechte an seinen Inhalten ab. Die AGBs von AIM, ICQ, MSN und Co. erlaubten dem Betreiber die Verwertung aller Inhalte die über den Dienst liefen. Die Dienste gibt es größtenteils nicht mehr, aber das Muster ist geblieben. Ein eigener Server bedeutet: Eigene Regeln, eigene Daten, eigene Entscheidung welche Module aktiv sind.

Die Vorteile von XMPP: Open Source, Verschlüsselung per TLS, kein Single Point of Failure, und eine riesige Auswahl an Clients für jede Plattform.

Openfire

Nach Tests mit jabberd, ejabberd und Openfire bin ich bei Openfire hängengeblieben. Für einen kleinen Server mit Familie und Freunden bringt Openfire alles mit: Weboberfläche zur Administration, Plugin-System, IPv6-Support und einfache Installation unter Debian. Für einen großen öffentlichen Server würde ich anders entscheiden, aber für meinen Zweck passt es.

Die Installation unter Debian ist schnell erledigt. Die TLS-Konfiguration braucht etwas Handarbeit, dazu gibt es eigene Beiträge: Unsichere Cipher deaktivieren und S2S-Verbindungen mit fehlenden Intermediate-Zertifikaten.

Jabber auf dem DECT-Telefon

Um zu zeigen wie flexibel XMPP ist: Mein Siemens Gigaset C470IP hat ein Mobilteil C47H mit eingebautem Messenger. Das Telefon verbindet sich mit dem Jabber-Server und kann Nachrichten empfangen und verschicken. Ohne App, ohne Smartphone, direkt auf dem DECT-Telefon.

Gigaset C470IP mit Mobilteil C47H online am Jabber Server mit seinem MessangerGigaset C470IP mit Mobilteil C47H online am Jabber Server mit seinem Messanger neue NachrichtGigaset C470IP mit Mobilteil C47H online am Jabber Server mit seinem Messanger neue Nachricht
Der Jabber Messenger des Gigaset C47H ist online und mit dem Server verbunden.Am Gigaset C47H ist eine neue Jabber-Nachricht angekommen.Die Nachricht wird am Mobilteil gelesen. Antworten funktioniert genauso.

Fragen? Einfach melden.

Theraphosinae

18. Oktober 2010 / / Keine Kommentare

Theraphosinae

Lasiodora Klugi

Die Theraphosinae ist die artenreichste Unterfamilie innerhalb der Vogelspinnen und beinhaltete annähernd 425 Arten und 52 Gattungen (Stand 2003). Viele kleine Arten wurden früher zu den Ischnocolinae gezählt. Weil diese Arten aber Reizhaare und einen gekielten Embolus enthalten, werden sie heute in die Unterfamilie Theraphosinae gestellt.

Verbreitung

Diese Unterfamilie beinhaltet ausschließlich amerikanische Arten.[1] Das Verbreitungsgebiet der Theraphosinae erstreckt sich auf dem amerikanischen Doppelkontinent von den USA südwärts bis nach Südamerika.

Merkmale

Die Körperlängen der Spezies variieren von 12 mm (z. B. Apachepelma paloma) bis 11 cm (Theraphosa blondi).[1]. Vertreter der Unterfamilie Theraphosinae werden auch als „Bombardierspinnen“ bezeichnet, und auch nur die Vertreter dieser Unterfamilie. In der Unterfamilie kommen keine baumbewohnenden Arten vor; baumbewohnende Vogelspinnen aus dem gleichen Verbreitungsgebiet gehören zu den Aviculariinae und Selenocosmiinae Simon, 1889.

Verhalten

Das Verhalten der Arten in dieser Unterfamilie ist sehr vielfältig. Einige Arten bauen tiefe Röhren in das Erdreich, andere leben unter Baumwurzeln, Rindenstücken oder Steinen. [1]

Es gibt sehr defensive Arten, insbesondere die Gattungen Theraphosa, Acanthoscurria und Phormictopus.[1] Bei Störungen ziehen sie sich sehr schnell in ihre Wohnröhre bzw. -höhle zurück. Häufig bewerfen die Bombardierspinnen unter den Theraphosinae den Angreifer mit ihren Brennhaaren. Haben sie nicht die Möglichkeit zum Rückzug, gehen sie in Verteidigungs-/Drohstellung. Werden sie weiter provoziert, schlagen sie in der Regel erst drei- bis viermal mit den Vorderbeinen und den Tastern nach dem Angreifer, bevor sie zubeißen.

Unter den Theraphosinae-Arten gibt es aber auch sehr friedfertige Gattungen, wie z. B. Eupalaestrus, Grammostola oder Brachypelma.[1]

Das Nahrungsspektrum der Theraphosinae ist abhängig der Körpergröße und des Verbreitungsgebietes der einzelnen Art und beinhaltet so eine große Auswahl von Beutetieren von Insekten bis Schlangen.

Quelle:

http://de.wikipedia.org/wiki/Theraphosinae

>>Einige Bilder zu dieser Spinne gibt es hier!<<

Siehe auch: Avicularia versicolor

Fragen? Einfach melden.

Theraphosa blondi

18. Oktober 2010 / / Keine Kommentare

Goliath-Vogelspinne

Die Riesenvogelspinne (Theraphosa blondi), oder auch Goliath-Vogelspinne, gilt mit bis zu 12 Zentimeter Körperlänge und einer Beinspannlänge von bis zu 30 Zentimeter lt. Guinness-Buch der Rekorde als die größte Vogelspinne der Welt. Sie ist stark behaart, und ihre Färbung ist rost- bis kastanienbraun. Weibchen können ein Gewicht von bis zu 170 Gramm erreichen. Adulte Männchen sind weniger kräftig gebaut als weibliche Exemplare und sind oft dunkler gefärbt. Im Gegensatz zu vielen anderen Vogelspinnenarten tragen die Männchen der Riesenvogelspinne am ersten Beinpaar keine Schienbeinhaken (Tibiaapophysen). Die Cheliceren der Riesenvogelspinne erreichen eine Länge von ca. 2,5 Zentimeter und das Abdomen kann in Gefangenschaft bei übermäßiger Fütterung die Größe eines Tennisballs erreichen. Oft ist die Behaarung des Abdomens unvollständig, da sie ihre Wohnröhre regelmäßig mit Brennhaaren tapeziert. Diese Tiere stammen aus dem tropischen Regenwald Südamerikas, wo sie besonders im nördlichen Teil Brasiliens, in Venezuela und Guyana vorzufinden sind. Die Luftfeuchtigkeit beträgt in ihrem natürlichen Lebensraum ca. 80 bis 95 % bei einer Temperatur von 25 bis 32 °C. Wobei das Mikroklima in den Bauten sich vom Makroklima etwas unterscheidet. Die Riesenvogelspinne bevorzugt feuchte Gebiete. Dort gräbt sie tiefe Wohnhöhlen in die Erde, damit sie in Trockenzeiten eine ausreichend feuchte Rückzugmöglichkeit hat. Sie ist eine Bombardierspinne, die vor dem Abstreifen der Brennhaare Warnlaute erzeugt, sog. Stridulieren. Bei der Paarung sind die Weibchen weniger aggressiv als ihr allgemeines Verhalten erwarten lässt. Ein Kokon enthält ca. 100 bis 150 Eier. Die Jungtiere sind beim Schlüpfen bereits 1,5 bis 2 cm groß. Bei einigen südamerikanischen Ureinwohnern wird Theraphosa blondi als Proteinquelle genutzt. (Der Geschmack soll dem von Langusten oder Krabben ähneln; näheres siehe Entomophagie beim Menschen) Quelle: http://de.wikipedia.org/wiki/Goliath-Vogelspinne >>Einige Bilder zu dieser Spinne gibt es hier.<<

Fragen? Einfach melden.

Avicularia versicolor: Pflege und Haltung der Vogelspinne

18. Oktober 2010 / / Keine Kommentare

Bei der Vogelspinne Avicularia versicolor (dt.: „Martinique-Baumvogelspinne“) (Walckenaer, 1837) handelt es sich um eine sehr oft im Terrarium gehaltene Art der GattungAvicularia. Diese Art wurde im Jahr 1837 durch Baron Charles Athanasie Walckenaer beschrieben. Ihre Heimat ist Martinique. Die weiblichen Tiere werden 4–6 cm groß, wobei es teilweise Exemplare gibt, welche 7–8 cm groß geworden sind. Die Männchen bleiben oft mit ca. 2–4 cm deutlich kleiner. Als Jungtiere (Spiderlinge) haben sie die typische Avicularia-Jugendfärbung. Das ganze Tier schimmert metallisch-blau. Ab dem 4. bis 5. Nymphenstadium färben sich die Jungtiere langsam um. Mit jeder weiteren Häutung ähneln sie den erwachsenen Tiere mehr. Diese haben einen dunklen Hinterleib mit roter Behaarung. Die Beinbehaarung ist ebenfalls rötlich. Das Kopf-Bruststück (Carapax) schimmert grün-bläulich.

Verhalten

Diese Spinnenart ist sehr friedlich, gutmütig und dämmerungs- bzw. nachtaktiv. Je älter sie wird, desto ruhiger wird sie. Im Laufe der verschiedenen Entwicklungsstufen (Häutungen) sind jedoch starke Verhaltensänderungen zu erleben. Während sie in dem einen Stadium noch sehr scheu sein mag, kann sie bereits nach der nächsten Häutung schon sehr „neugierig“ und „interessiert“ sein.

Sie lebt in einem seidigen Wohngespinst, welches sie – wenn möglich – mit Hilfe von Pflanzen oder Ästen tarnt. Sie hält ihr Haus immer von Unrat rein, in dem sie sich sowohl zum Entsorgen von Essensresten als auch zum Koten außerhalb ihrer Wohnhöhle aufhält. Sie ist sehr reinlich, was sich besonders nach dem Fressen beobachten lässt: Dann nämlich werden ihre Cheliceren und ihre Pedipalpen ausgiebig gereinigt.

Sie ist eine ausgezeichnete Jägerin, die besonders auf Fluginsekten (z. B. „dicke Brummer“) interessiert reagiert. Da lässt es sich schon mal beobachten, wie sie am helllichten Tag langsam aus ihrem Gespinst gekrabbelt kommt und sich ans Opfer anpirscht. Sollten anfängliche Versuche des Fangens fehlschlagen, wird man ihre sehr schnellen Reaktionen zu sehen bekommen: Dann läuft sie hinter ihrer Beute her und springt sogar manchmal von den Wänden auf Äste oder fällt schon mal auf den Boden. Avicularia versicolor ist eine baumbewohnende Vogelspinne, die im Jungtieralter auch häufig und gerne weite Sprünge ausübt. Diese Verhaltensweise verliert sich mit zunehmendem Alter.

Bedrängt man diese Spinne, wird sie als erstes versuchen, sich zurückzuziehen und die Flucht ergreifen, bzw. sich flach auf den Boden drücken, die Beine an den Körper ziehen und reglos verharren. Falls ihr all dies nicht möglich sein sollte, hat sie zwei verschiedene Abwehrmechanismen:

  1. Sie beschießt ihren Feind mit Kot (wobei sie ca. 30 cm weit noch treffen kann)
  2. Sie hat Brennhaare auf dem Hinterleib (sieht man auf Fotos immer als Fleck in der Mitte des hinteren Teils des Abdomen). Sie streckt ihr Hinterleib einem Angreifer entgegen.
  3. Sollten die anderen Verteidigungsmethoden nicht wirken, beißt sie auch zu.

Fortpflanzung

Zu Paarungszwecken im Terrarium sollte das Männchen zum Weibchen gegeben werden. Dieses wird, sobald es das Gespinst des Weibchens berührt, anfangen mit den Tastern (Padipalpen) zu Trommeln. Ist das Weibchen paarungswillig wird es ebenfalls Trommeln und dem Männchen entgegengehen. Ist das Weibchen nicht willig und der Bock geht dennoch näher an das Weibchen heran, landet er meistens als Zwischenmahlzeit, auch bei sehr gut gefütterten Weibchen, im Magen. Ist das Weibchen paarungswillig, besteht die nächste Hürde für den Bock darin, an die Geschlechtsöffnung zu gelangen. Diese liegt zwischen den ersten Lungenpaar auf der unteren Seite des Hinterleibs. Gelingt es dem Bock nicht das Weibchen hochzustemmen, wurde bereits beobachtet, wie sich das Weibchen auf die Seite legt oder selbstständig aufrichtet, um dem Bock den Paarungsakt zu erleichtern. Nach der Paarung sollte das Männchen wieder in sein eigenes Terrarium gesetzt werden. Ein längeres Zusammenleben endet für den Bock nach etwa ein bis zwei Wochen tödlich. Hat das Weibchen dann einen Kokon gebaut, kann man sich auf 50 bis 300 Jungtiere freuen. Die Aufzucht bereitet in der Regel keine Probleme. Es kommt meistens nur bei zu viel oder zu wenig Feuchtigkeit zu Komplikationen, zum Beispiel bei der Häutung.

 

Quelle:

http://de.wikipedia.org/wiki/Avicularia_versicolor

>>Hier nun einige Bilder zu der Spinne<<

Siehe auch: Theraphosinae — Vogelspinnen-Übersicht

Fragen? Einfach melden.

Dovecot Quota einrichten: Postfachgröße begrenzen mit Warnungen und SQL

9. August 2010 / / Keine Kommentare

Ohne Quota wachsen IMAP-Postfächer bis die Platte voll ist. Dovecot bringt ein Quota-Plugin mit, das die Postfachgröße begrenzt und den Benutzer warnt bevor es eng wird. Bei vollem Postfach kann Dovecot eingehende Mails mit einem temporären Fehler abweisen, statt sie sofort zu bouncen. So hat der Benutzer Zeit aufzuräumen.

Plugin aktivieren

In conf.d/20-imap.conf und conf.d/20-lmtp.conf (oder 15-lda.conf) das Quota-Plugin laden:

# 20-imap.conf
protocol imap {
  mail_plugins = $mail_plugins quota imap_quota
}

# 20-lmtp.conf
protocol lmtp {
  mail_plugins = $mail_plugins quota
}

imap_quota sorgt dafür dass Mailclients die Quota-Information per IMAP abfragen können (GETQUOTA/GETQUOTAROOT). Die meisten Clients zeigen dann einen Fortschrittsbalken.

Quota-Backend und Standardgröße

In conf.d/90-quota.conf:

plugin {
  quota = count:User quota
  quota_vsizes = yes
  quota_rule = *:storage=512M
}

count ist das empfohlene Backend ab Dovecot 2.2+. Es speichert die Quotadaten in der Index-Datei und muss nicht jedes Mal alle Mails auf der Platte zählen. Das alte dirsize-Backend funktioniert zwar noch, wird aber bei großen Postfächern langsam. quota_rule = *:storage=512M setzt die Standardgröße für alle Postfächer auf 512 MB.

Quota Warnings

Dovecot kann bei bestimmten Schwellenwerten ein Script aufrufen, das eine Warnung verschickt:

plugin {
  quota_warning = storage=80%% quota-warning 80 %u
  quota_warning2 = storage=95%% quota-warning 95 %u
}

service quota-warning {
  executable = script /usr/local/bin/quota-warning.sh
  user = vmail
  unix_listener quota-warning {
    user = vmail
  }
}

Die doppelten Prozentzeichen (%%) sind nötig weil Dovecot % als Variablen-Prefix interpretiert. Das Script /usr/local/bin/quota-warning.sh bekommt den Schwellenwert und die E-Mail-Adresse als Parameter:

#!/bin/sh
PERCENT=$1
USER=$2
echo "Ihr Postfach $USER ist zu $PERCENT% belegt.
Bitte loeschen oder archivieren Sie aeltere E-Mails." | \
  mail -s "Postfach $USER: $PERCENT% belegt" "$USER"

Individuelle Quotas per SQL

Wenn nicht jeder Benutzer die gleiche Postfachgröße bekommen soll, lässt sich die Quota per SQL-Abfrage pro Benutzer setzen. In der dovecot-sql.conf.ext:

user_query = SELECT \
  home, uid, gid, \
  CONCAT('*:storage=', quota_mb, 'M') AS quota_rule \
  FROM virtual_users \
  WHERE email = '%u'

Die Tabelle virtual_users braucht dafür ein Feld quota_mb. Dovecot übernimmt den Wert aus dem SQL-Ergebnis und überschreibt damit die Standardregel aus der Config. Benutzer ohne Eintrag bekommen weiterhin die 512 MB aus quota_rule.

Verhalten bei vollem Postfach

Standardmäßig gibt Dovecot bei vollem Postfach einen permanenten Fehler zurück und Postfix bounced die Mail. Mit der folgenden Einstellung wird stattdessen ein temporärer Fehler gesendet (4xx), damit Postfix die Mail in der Queue behält und es später nochmal versucht:

plugin {
  quota_exceeded_message = Quota exceeded, please try again later.
}

# In der LDA/LMTP Config:
quota_full_tempfail = yes

So hat der Empfänger Zeit sein Postfach aufzuräumen, ohne dass Mails verloren gehen. Fragen? Einfach melden.

Skoda Octavia LPG

11. Juni 2010 / / Keine Kommentare

Der alte Firmenwagen (Fabia II TDI Sport, 2,5 Jahre, 120.000 km, zweiter Motor) stand mehr in der Werkstatt als er mir zur Verfügung stand. Diesel wurde teurer, die Kfz-Steuer tat ihr Übriges und der Nachwuchs brauchte mehr Platz. Also musste ein neuer Firmenwagen her.

Die Entscheidung

Alle Firmenwagen waren und sind Skoda. Das Preis-Leistungs-Verhältnis passt, Diskussionen über die Marke gab es nicht. Also ein Octavia. Aber welcher genau?

In der Nähe unseres Firmenparkplatzes hatte eine Autogastankstelle (LPG) eröffnet. Kundenkarte, Monatsabrechnung, 2 Cent Rabatt pro Liter. Klingt gut, aber Autogas? Mehr Verbrauch, weniger Leistung, Tankstellensuche?

Glücklicherweise hatte das Autohaus einen Octavia LPG als Probefahrt da. Der hat überzeugt.

Im Alltag

Über 100 PS, auf Gas verliert man 3-4 PS. Spürt man nicht wirklich. Auf der Autobahn sind es bei der Endgeschwindigkeit vielleicht 5-10 km/h weniger, vergleichbar mit dem Einschalten der Klimaanlage.

Der Gastank sitzt dort, wo normalerweise der Ersatzreifen wäre (Bilder weiter unten). Der Tankstutzen ist formschön neben dem Benzintankstutzen verbaut. Kein Kriechen unters Auto, kein verdrehtes Nummernschild. Zwei Adapter für verschiedene Tankrüssel liegen bei.

Die Tankanzeige sitzt vor dem Schaltknüppel in der Mittelkonsole. Blaue LEDs zeigen den Füllstand, eine gelb blinkende LED signalisiert die Umschaltung auf Gas, dauerhaft gelb heißt Gasbetrieb. Rote LED kurz vor leer, dann piepst es und der Wagen schaltet automatisch auf Benzin um.

Benzin wird zum Starten und bis zur Betriebstemperatur gebraucht, danach schaltet er automatisch auf Gas. Man hört nur kurz ein Magnetventil im Kofferraum knacken. Per Knopfdruck lässt sich auch bewusst auf Benzin umschalten.

Verbrauch und Reichweite

Der Boardcomputer funktioniert einwandfrei mit beiden Kraftstoffen. Im Gasbetrieb ist der Verbrauch naturgemäß etwas höher. Bei rund 0,60 Euro pro Liter mehr als okay. Der 40-Liter-Gastank reicht für knapp 300 km. Zusätzlich bleibt der 50-Liter-Benzintank voll nutzbar.

Bei 0,2 km auf dem Tacho habe ich den Benzintank vollgetankt. Bei ca. 8.000 km musste zum ersten Mal Benzin nachgetankt werden. Autogastankstellen gibt es in Europa mehr als man denkt. Liegenbleiben mit leerem Gastank ist unrealistisch.

Motor und Fahrverhalten

Im Motorraum sieht alles sauber verbaut aus. Die normalerweise vorhandene Motorabdeckung passt durch die Gasanlage nicht mehr. Vermisse ich nicht.

Geräusche? Ich bin vorher Diesel gefahren. Die ersten Kilometer dachte ich an jeder Ampel, die Kiste sei aus. Kein Wackeln, kein Brummen, nichts. Die Motorleistung ist ausreichend, auf der Bahn sind 200 und etwas mehr drin. Das Auto fährt sich gut und ich bin zufrieden damit.

Hier die Bilder zum Octavia LPG.

Update Oktober 2012 (55.000 km)

Bei 55.000 km gab es ein Problem mit der Gasanlage. Der Wagen meldete sporadisch „zu fett“ oder „zu mager“. Mein Autohaus tippte auf die Lambdasonde, die mehrfach getauscht wurde, ohne Besserung. Ein Softwareupdate von einem befreundeten Autohaus half ebenfalls nicht. Erst ein längerer Aufenthalt im Skoda-Werk brachte die Lösung: der komplette Gasstrang vom Tank bis zum Motor wurde getauscht. Alles innerhalb der Garantie. Fazit: Sicherstellen, dass das Autohaus wirklich mit LPG-Autos umgehen kann.

Update März 2013

Der Octavia geht zurück, dafür kommt ein Skoda Yeti TDI 2.0. Gas war gut, jetzt doch wieder Diesel.

Fragen? Einfach melden.

Spam- und Virenabwehr durch HELO: So funktioniert’s

7. Juni 2010 / / Keine Kommentare

Postfix kann schon beim SMTP-Dialog prüfen, ob die Angaben des einliefernden Servers plausibel sind. Stimmt der HELO-Hostname nicht, existiert die Absenderdomain nicht im DNS, oder passt der Reverse-DNS nicht zur IP? Dann ist die E-Mail mit hoher Wahrscheinlichkeit Spam. Diese Prüfungen kosten fast nichts und filtern einen erheblichen Teil des Mülls, bevor die Nachricht überhaupt angenommen wird.

Warum das funktioniert

Ordentlich konfigurierte Mailserver melden sich mit ihrem FQDN, und der Reverse-DNS-Eintrag passt dazu. Gekaperte Rechner eines Botnetzes melden sich dagegen mit dem Hostnamen, den der Besitzer irgendwann eingegeben hat. Im besten Fall „Peters-PC“, im schlechtesten Fall gar nichts. Selbst wenn der FQDN stimmt, wird der Botnetzbetreiber kaum beim ISP einen passenden Reverse-DNS setzen lassen. Bei dynamischen IPs von DSL-Anschlüssen ist der Hostname meist nicht einmal in einem gültigen Format.

Das können wir uns zunutze machen. Wer sich nicht korrekt anmeldet, bekommt einen 5xx-Reject. Der Vorteil: Postfix beendet die Verbindung sofort und gibt Ressourcen frei. Fällt ein legitimer Absender durch diese Prüfung, hat dessen Admin nicht sauber gearbeitet. Die Fehlermeldung im Reject sagt ihm genau, was falsch ist.

Grundkonfiguration

In /etc/postfix/main.cf zwei Zeilen ergänzen:

smtpd_helo_required = yes
smtpd_delay_reject = yes

smtpd_helo_required erzwingt ein HELO/EHLO von jedem Client. smtpd_delay_reject verschiebt die Ablehnung bis nach dem RCPT TO, weil manche SMTP-Clients (vor allem von Microsoft) sonst Probleme bekommen.

Die Restrictions im Detail

Die eigentlichen Prüfungen kommen in smtpd_recipient_restrictions. Hier die einzelnen Regeln und was sie tun:

reject_non_fqdn_sender — Absenderadresse ist kein FQDN.
reject_non_fqdn_recipient — Empfängeradresse ist kein FQDN.
reject_non_fqdn_hostname — Clientname ist kein FQDN.
reject_non_fqdn_helo_hostname — HELO-Hostname ist kein FQDN.
reject_invalid_hostname — Clientname hat kein gültiges Format.
reject_invalid_helo_hostname — HELO-Hostname hat kein gültiges Format.
reject_unknown_recipient_domain — Empfängerdomain hat keinen A- oder MX-Record.
reject_unknown_sender_domain — Absenderdomain hat keinen A- oder MX-Record.
reject_unknown_client_hostname — IP und Hostname des Clients passen nicht zusammen.
reject_unknown_helo_hostname — HELO-Hostname hat keinen A- oder MX-Record.
reject_unlisted_recipient — Empfänger nicht in der Liste gültiger Adressen.
reject_unauth_destination — Domain ist weder lokal noch als Relay konfiguriert.

Vollständige Konfiguration

Zusammen mit DNS-Blocklisten (RBL/RHSBL) und SPF-Prüfung ergibt sich eine Konfiguration wie diese:

smtpd_recipient_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        check_recipient_access hash:/etc/postfix/recipient-access,
        reject_rbl_client zen.spamhaus.org,
        reject_rbl_client bl.spamcop.net,
        reject_rbl_client ix.dnsbl.manitu.net,
        reject_unlisted_recipient,
        reject_non_fqdn_recipient,
        reject_non_fqdn_helo_hostname,
        reject_non_fqdn_hostname,
        reject_non_fqdn_sender,
        reject_unknown_recipient_domain,
        reject_unknown_client_hostname,
        reject_unknown_helo_hostname,
        reject_invalid_helo_hostname,
        reject_invalid_hostname,
        reject_unknown_client,
        reject_unknown_sender_domain,
        reject_unauth_destination
smtpd_data_restrictions =
        reject_unauth_pipelining,
        permit

Die Reihenfolge ist wichtig. Postfix arbeitet die Regeln von oben nach unten ab, und die erste passende greift. permit_mynetworks und permit_sasl_authenticated stehen deshalb ganz oben, damit eigene Benutzer und vertrauenswürdige Netze nicht gefiltert werden. check_recipient_access erlaubt das Whitelisting bestimmter Empfänger (etwa postmaster@ und abuse@). Dann kommen die Blocklisten, danach die HELO- und DNS-Prüfungen.

Ein Reject im Log

So sieht ein typischer Reject aus, wenn ein Bot sich mit einem ungültigen HELO meldet:

Jun  7 17:50:35 smtp postfix/smtpd[22037]: NOQUEUE: reject: RCPT from
  unknown[94.52.112.110]: 504 5.5.2 <userpc>: Helo command rejected:
  need fully-qualified hostname;
  from=<MackenzieSaranzak@redvanilla.com>
  to=<empfaenger@domain.de>
  proto=ESMTP helo=<userpc>

Der Client „userpc“ hat keinen FQDN im HELO geliefert. Postfix lehnt mit 504 ab, die Verbindung ist sofort beendet. Kein Inhalt übertragen, keine Ressourcen verbraucht.

Wie effektiv ist das?

Allein die HELO- und DNS-Prüfungen filtern 30 bis 55 Prozent des Spams. Zusammen mit den RBLs kommt man auf über 90 Prozent, bevor rspamd überhaupt etwas zu tun bekommt. Das spart Rechenzeit und macht den Content-Filter deutlich entlastet.

Wer noch weiter gehen will: Mit eigenen DNS-Blocklisten lassen sich wiederkehrende Absender und Domains gezielt sperren.

Fragen? Einfach melden.

Greylisting mit Postfix und Postgrey einrichten

3. Juni 2010 / / Ein Kommentar

Greylisting ist ein einfacher Trick gegen Spam: Beim ersten Zustellversuch lehnt der Mailserver die Mail mit einem temporären Fehler ab (4xx). Ein regulärer Mailserver versucht es nach ein paar Minuten erneut und die Mail wird zugestellt. Spam-Botnets dagegen arbeiten nach dem „fire and forget“ Prinzip. Die probieren es kein zweites Mal, weil sie in der Zeit lieber den nächsten Empfänger anschreiben. Damit lassen sich 80 bis 90 Prozent der Botnet-Zustellungen abfangen, ohne eine einzige Mail filtern zu müssen.

Wie es funktioniert

Postgrey speichert bei jedem Zustellversuch ein Triplet aus Absender-Adresse, Empfänger-Adresse und Client-IP. Beim ersten Versuch wird die Mail abgelehnt. Kommt derselbe Server nach Ablauf der Wartezeit (Standard: 5 Minuten) nochmal, wird die Mail durchgelassen. Bekannte Triplets werden 35 Tage gespeichert, danach lernt Postgrey den sendenden Server automatisch und lässt ihn ohne Verzögerung durch (Auto-Whitelist).

Installation

# Debian/Ubuntu
apt-get install postgrey

# FreeBSD
pkg install postgrey

Nach der Installation lauscht Postgrey auf 127.0.0.1:10023 (Debian) bzw. 127.0.0.1:10030 (FreeBSD, je nach Config). Prüfen mit ss -tlnp | grep postgrey oder sockstat -4l | grep postgrey.

Postfix-Integration

In der main.cf den Postgrey-Check in die smtpd_recipient_restrictions einfügen, nach den Authentifizierungs-Checks und vor den RBL-Checks:

smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    check_policy_service inet:127.0.0.1:10023,
    reject_rbl_client zen.spamhaus.org,
    reject_rbl_client bl.spamcop.net

Nach einem postfix reload ist Greylisting aktiv.

Im Log

Beim ersten Versuch wird die Mail abgelehnt:

postgrey: action=greylist, reason=new, client_name=mail.example.de, sender=user@example.de
postfix/smtpd: NOQUEUE: reject: 450 4.2.0 Recipient address rejected: Greylisted

Beim zweiten Versuch (nach Ablauf der Wartezeit) wird durchgelassen:

postgrey: action=pass, reason=triplet found, delay=355, client_name=mail.example.de

Bekannte Server werden automatisch durchgelassen:

postgrey: action=pass, reason=client AWL, client_name=mail.example.de

Limitationen

Greylisting verzögert die erste Mail von jedem neuen Absender um einige Minuten. Für zeitkritische Mails (Passwort-Resets, Zwei-Faktor-Codes) kann das ein Problem sein. Postgrey führt deshalb eine Whitelist mit bekannten großen Providern (/etc/postgrey/whitelist_clients), die nie verzögert werden.

Inzwischen setzt auch rspamd Greylisting um, als Teil seines Score-basierten Ansatzes. Dort wird nur gegrey­listet wenn der Spam-Score in einem Graubereich liegt. Mails die eindeutig Spam oder eindeutig sauber sind, werden sofort abgelehnt oder zugestellt. Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑