Springe zum Inhalt

Speziell auf NanoBSD, der auf ALIX-Boards eingesetzten pfSense-Variante schlägt das Update auf die Version 2.3.1_5 über die Verwaltungswebseite und auch über die Shell fehlt. Nach dem Duplizieren des Slice scheint der Updateprozess zu hängen, es dauert sehr lange, bis einfach nur ein "Failed" ausgegeben wird.

Der Updateprozess startet das Update im Slice als chroot-Umgebung. Durch einen Bug ist dort manchmal unter NanoBSD keine resolv.conf vorhanden, welche zum Auflösen von Hostnamen erforderlich ist. Downloads können dann nicht ausgeführt werden. Der Fehler ist mittlerweile bekannt.

Abhilfe schafft ein Update im laufenden System. Dabei wird nicht in die chroot-Umgebung gewechselt, sondern das laufende System upgedatet:

pkg update -f
pkg upgrade -f

Danach sollte die Box neu gestartet werden. Nachteil dabei ist, dass man kein Slice mit der vorhergehenden Version mehr hat. Eventuell sollte man also vorher über "Diagnostics -> NanoBSD -> Duplicate boot slice" das aktuelle (ältere) Slice sichern, um eine Fallbackvariante zur Verfügung zu haben.

4

Vielleicht kennen einige die sogenannte Löffelsprache, bei der es sich um eine spielerische Modifikation der Sprache handelt. Die Regeln sind einfach: hinter jeden Vokal wird "lef" gesetzt und der Vokal wiederholt (andere Variationen benutzen "lew" oder auch "low"). Diphthonge werden insgesamt behandelt. Hinter sie wird ebenfalls ein "lef" gesetzt und der Diphthong wiederholt. Ein Beispiel: Aus "Jens Tautenhahn" wird "Jelefens Taulefautelefenhalefahn". Die Vokale und Diphthonge hinter denen "lef" eingefügt wird sind fett markiert.

Im Netz kursieren ein paar Beispielimplementierungen in verschiedenen Sprachen, diese sind jedoch leider nicht vollständig. Ich habe keine Implementierung gefunden, die die Diphthonge beachtet. Ein Anreiz, mal wieder sed in die Hand zu nehmen und es richtig zu machen:

alias loeffel="sed 's/\([äae]u\|[ae]i\|ie\|[aeiouäöü]\)/\1lef\1/g;'"

"[äae]u" bildet die Diphthonge äu, au und eu ab, "[ae]i" ai und ei, dazwischen ie und zum Schluss alle Vokale inklusive der entprechenden Umlaute. Durch die Klammerung kann man anschließend den Match als Parameter in der Ersetzung verwenden (\1).

Jetzt kann man "loeffel" prima als Pipe verwenden und allen möglichen Text "löffeln" ;)

Lange Zeit war es still um ".DE Deutsche Domain" bzw. den Absender deutschedomain.com. Die letzten dokumentierten Fälle stammen aus Oktober und November 2015. Heute jedoch flatterte wieder einer dieser Abzockversuche ins digitale Postfach:

Sehr geehrte Frau / Herr,

Nachfolgend die Einzelheiten zu der Domainregistrierung für 2016 / 2017.

Wir hoffen, Sie ausreichend informiert zu haben.

Mit freundlichen Grüssen

Anna Müller

Kundendienst
DE Deutsche Domain
info@deutschedomain.com

Schon dass hier keine korrekte Anrede verwendet wurde sollte aufhorchen lassen. Im Anhang befindet sich dann ein bemerkenswertes PDF mit Namen "Rechnung 232366.pdf":

Rechnung 232366

Was als erstes an dieser "Rechnung" auffällt: sie ist schlicht an niemanden gerichtet. Ebenfalls unklar ist der Rechnungsgegenstand. Um welche Domain handelt es sich hier? Die bei Rechnungen erforderliche USt-ID oder Steuernummer fehlt ebenfalls.

Der Betrugsversuch wird erst im Kleingedruckten offenbar. Dort ist unter anderem zu lesen:

Dies ist ein angebot und keine rechnung, die zahlung auf dieses angebot hin wird als annahme des angebotes oder auftragsbestätigung verstanden.

Das Ganze ist also mitnichten eine Rechnung, sondern ein (selten dämliches) Angebot, bei dem noch nicht einmal die angebotene Leistung, auch nicht aus dem Kleingedruckten, ersichtlich ist.

Welche Fakten kann man dem PDF noch entnehmen?

  • Die Echtheit der angegebenen Telefonnummer wage ich zu bezweifeln. Nur fünfstellige Telefonnummern in Berlin?
  • Als Kontaktadresse ist nur ein Postfach (also keine ladungsfähige Adresse) in Berlin angegeben.
  • Überwiesen werden soll an eine spanische Bank (zu erkennen an dem Kürzel "ES" am Anfang der IBAN). Die Prüfung der IBAN ergibt, dass das Konto bei der Zweigstelle 0104 der UNICAJA BANCO, S.A., Malaga geführt wird.
  • Dass der PDF-Seitentitel "Página 1" (spanisch für "Seite 1") und der Benutzername "Usuario" (spanisch für "Benutzer") lautet, deutet darauf hin, dass Spanien auch der Ursprungsort des PDFs ist.
  • Zum Erstellen des PDFs wurde anscheinend CorelDRAW X5 verwendet. Dieser Hinweis und die eingebetteten Schriftarten ArialMT und Arial-BoldMT deuten auf einen Windows-Rechner hin.

Was gibt der E-Mail-Header her?

Hier die relevanten Header-Zeilen:

Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0087.outbound.protection.outlook.com [157.55.234.87])
	by mx1.xxxxxxxxxxxxxxxx (Postfix) with ESMTPS id 1CC7A1607DB
	for <xxxxxxxxxxxxxxx>; Wed, 22 Jun 2016 17:08:33 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=netorgft810459.onmicrosoft.com; s=selector1-deutschedomain-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;
 bh=UnZdiQs+DjMOkpBEYzTHPetqguKBJJhWGiDHDKuXLdk=;
 b=QMUkUfPEOzaQ4YlCFJWSvogzaGNjWMEvIWpkyuUO2KZkGyfXFsE59KJQjKsOpY4TxONWY2ZVLAWOOW23e6Sk8oPLk3mf+LYtsNnJh9iuJEoRoYiJ3P5lkc2BJApAxFV6nA1FbVsyqlFNY6LJG8ASPbu8WRLaZrXwrPpy0cybPr4=
Received: from DB4PR07MB0752.eurprd07.prod.outlook.com (10.242.223.17) by
 DB4PR07MB0750.eurprd07.prod.outlook.com (10.242.223.156) with Microsoft SMTP
 Server (TLS) id 15.1.523.12; Wed, 22 Jun 2016 15:08:28 +0000
Received: from DB4PR07MB0752.eurprd07.prod.outlook.com ([10.242.223.17]) by
 DB4PR07MB0752.eurprd07.prod.outlook.com ([10.242.223.17]) with mapi id
 15.01.0517.014; Wed, 22 Jun 2016 15:08:28 +0000
From: ".DE Deutsche Domain" <info11@deutschedomain.com>
To: ".DE Deutsche Domain" <info11@deutschedomain.com>
Subject: Domainregistrierung 2016 / 2017
Thread-Topic: Domainregistrierung 2016 / 2017
Thread-Index: AQHRzJd7BFty2iqWAE2esWDAagHjbQ==
Importance: high
X-Priority: 1
Date: Wed, 22 Jun 2016 15:08:27 +0000
Message-ID: <DB4PR07MB0752EA922CC0101E71AEFD8DA62C0@DB4PR07MB0752.eurprd07.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is )
 smtp.mailfrom=info11@deutschedomain.com; 
x-originating-ip: [132.245.225.101]
x-ms-office365-filtering-correlation-id: 901118ad-2e91-4199-1271-08d39aaf10e2
x-microsoft-exchange-diagnostics: 1;DB4PR07MB0750;6:lzSdY+JQkpRaZDdcOMB05Lmlpqpyk1D1JkrsiiRjN4DqwK8Yn2X+6PM9lroNCF8vXTnurcnI6DL1E0MoeL1PNf3hE6bzpWmXx9H/iWuNu5dJgawWJPvlyGgNhRg9qTdw4TKf+3mJ6jWurzb3Ka3wVQMccyrA07OUwwodkHlkoYhAo2EWXV121l+IBI14BQTk3m+75fmT+hGL6DWMghv9dy1XD45iDe4+BKS854v1r3siPJkB/znvTGpVdAsRSRDaoi7FFcCje/r5iv6HA+DUBeEEdR5z4NNx2eNWWBaiiTGTPgkKwRs0T7JcVa8tjTHj;5:qCNYOOyHwdFfT6+BC3LsFF3FiM/FP/EzAV/lCOT+hC+4BhXiXCso9Fpu9koGouYoF28ObNIQlIr39BbncTkUPs+u3XK/DrEKi0aA9eymGjRo/K79vFAB6k6byb+Yzh4uwxpHNP6pcnyLRgpl69y78w==;24:sftGZ8jmC8gZ2FlheIYLPKq669lGhisU/6dfwI2zmdq3WU3PkOM0IZM8H7IQU2+4Tc+v/kfpjYlvofYt6daSoJbCPvlgOGpdWpBcFLiRffc=;7:CV4V4bVkM00okIx2HupB1wf+wiB5nWpQt9R1vq6aOFghsbO1H2Ys015m/xFyPQa4+686+40BhiGfzff6Upr1WHJG2/+CH7Cs4WRy2rnrTjN0bRGx/ODbj6dg1EF+xIZy7D18N9pV/2FOv0ags4YdCrOM7R26C9zFuZEG5DJyCCG16oE2eMjZO4WVr0lCqLeu8Cv5xvJRxdl4NxGDhGLaBGCxi6Gn7xGWfqvynfH/XGAE5Cy+BQdPcepIZnItQXCW
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR07MB0750;
x-microsoft-antispam-prvs: <DB4PR07MB07503B8F11E38473B6726D44A62C0@DB4PR07MB0750.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(102415321)(6040130)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041072)(6043046);SRVR:DB4PR07MB0750;BCL:0;PCL:0;RULEID:;SRVR:DB4PR07MB0750;
x-forefront-prvs: 0981815F2F
x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(7916002)(199003)(189002)(106356001)(106116001)(105586002)(87936001)(189998001)(76576001)(33656002)(101416001)(3280700002)(19627405001)(229853001)(66066001)(3660700001)(8666005)(97736004)(4001450100002)(110136002)(107886002)(74316001)(99936001)(10400500002)(50986999)(122556002)(54356999)(81686999)(9686002)(6200100001)(86362001)(11100500001)(8676002)(19625215002)(81166006)(81156014)(586003)(558084003)(19580405001)(2906002)(19580395003)(16236675004)(68736007)(5002640100001)(7696003)(92566002)(7736002)(5003600100003)(7846002)(77096005)(8936002)(3846002)(2900100001)(102836003)(6116002)(7059030);DIR:OUT;SFP:1101;SCL:1;SRVR:DB4PR07MB0750;H:DB4PR07MB0752.eurprd07.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:de;
received-spf: None (protection.outlook.com: deutschedomain.com does not
 designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/mixed;
	boundary="_004_DB4PR07MB0752EA922CC0101E71AEFD8DA62C0DB4PR07MB0752eurp_"
MIME-Version: 1.0
X-OriginatorOrg: deutschedomain.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2016 15:08:27.7593
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: a87ceb82-ac57-4031-b8db-3e4f2cb4dd53
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB0750

Anscheinend wurde die E-Mail direkt über das Webinterface von Microsoft bzw. Live gesendet. Die angegebene x-originating-ip ist einem Netblock von Microsoft zugeordnet. Der Umstand, dass Microsoft eine DKIM-Signatur einfügt und das Setzen der Absenderdomain erlaubt deutet darauf hin, dass ein Benutzerkonto verwendet wurde, welches durch Microsoft auch der Absenderdomain deutschedomain.com zugeordnet werden kann.

Mehr kann den ganzen Microsoft spezifischen Headern wohl nur Microsoft selbst entnehmen.

Die Domain deutschedomain.com

Die Domain wurde über GODADDY registriert. Als Inhaber wurde eine Firma "NL Domein Hosting" in Amsterdam angegeben. Lt. Google Maps gibt es die angegebene Adresse des Domaininhabers nicht. Die angegebene Telefonnumer aus den Niederlanden hat schon eine Ortsvorwahl welche nicht existiert.

Der für diese Domain zuständige Mailserver wird ebenfalls von GODADDY betrieben. Das hilft also auch nicht weiter.

Fazit

Es bleibt nur eins: auf gar keinen Fall zahlen! Evtl. sogar Anzeige gegen Unbekannt bei der Polizei erstatten.

Munin kann so eingestellt werden, dass die Grafiken und HTML-Dateien nicht alle fünf Minuten sondern nur auf Anforderung bzw. beim Abrufen der jeweiligen Webseite erzeugt werden. Zuständig dafür sind die Einstellungen cgi_strategy und html_strategy in /etc/munin/munin.conf. Munin benötigt dazu zwei FastCGI-Schnittstellen, welche idealerweise über einen Socket angesprochen werden. Früher konnte man das Problem lösen, indem man an passender Stelle mit spawn-fcgi die entprechenden FastCGI-Schnittstellen über Sockets bereitstellte. Eine Lösungsmöglichkeit war z.B. folgende:

/usr/bin/spawn-fcgi -s /var/run/munin/fcgi-graph.sock -U www-data -u www-data -g www-data /usr/lib/munin/cgi/munin-cgi-graph
/usr/bin/spawn-fcgi -s /var/run/munin/fcgi-html.sock -U www-data -u www-data -g munin  /usr/lib/munin/cgi/munin-cgi-html

In Zeiten von systemd läßt sich das nun eleganter bewerkstelligen. ...weiterlesen "FastCGI für Munin mit systemd"