Samstag, 4. August 2018

Tweet-Hygiene — oder wieso einem alte Tweets noch Jahre später jagen können

They take tweets and other statements out of context because they want to disrupt us and harm [us] individual reporters.

Quelle: A note from the editorial leadership of The Verge

Als ich diesen Satz gelesen habe, musste ich kurz stoppen, schmunzeln und zu mir sagen: „Dasselbe Zitat hätte jetzt aber auch von der Gegenseite stammen können …“. Topaktuell: Guardians of the Galaxy cast come out in support of fired director James Gunn

Mein Lieblings Gadget-Blogger Volker Weber (vowe) hat eine simple, aber effektive Lösung: Deleting my tweets after 10 days

Tags: , , ,
Labels: Medien, USA

Keine Kommentare | neuen Kommentar verfassen

Samstag, 4. August 2018

Das Müll-Web („The Bullshit Web“)

An honest web is one in which the overwhelming majority of the code and assets downloaded to a user’s computer are used in a page’s visual presentation, with nearly all the remainder used to define the semantic structure and associated metadata on the page. Bullshit — in the form of CPU-sucking surveillance, unnecessarily-interruptive elements, and behaviours that nobody responsible for a website would themselves find appealing as a visitor — is unwelcome and intolerable.

Quelle: The Bullshit Web

Labels: Web

Keine Kommentare | neuen Kommentar verfassen

Samstag, 4. August 2018

logrotate meldet „mysqladmin: connect to server at ‚localhost‘ failed“

/etc/cron.daily/logrotate:
mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'root'@'localhost' (using password: NO)'
error: error running shared postrotate script for '/var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log /var/log/mysql/mariadb-slow.log /var/log/mysql/error.log '
run-parts: /etc/cron.daily/logrotate exited with return code 1

Hat man das root-Passwort angepasst (sprich: es ist nicht mehr leer, wie standardmässig vorgegeben), muss man das Passwort in der Datei /etc/mysql/debian.cnf ergänzen.

Die dort erfassten Parameter werden vom logrotate-Script unter /etc/logrotate.d/mysql-server eingelesen und zum Zugriff verwendet.

Quelle: MySQL logrotate error

Tags: ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Samstag, 4. August 2018

General Magic und Jodorowskys Dune: Wie „Erben“ gescheiterter Vorhaben die Gesellschaft bis heute prägen

General Magic, ein (gescheitertes) Silicon Valley-Startup der 90er, von welchem ich bis vor kurzem noch nie in meinem Leben gehört hatte. Aber seine „Erben“ sind auch 2018 allgegenwärtig:

Tony [Fadell] went on to build the iPhone, Andy Rubin built Android, Pierre Omidyar built eBay, Megan Smith became VP of Google and then America’s CTO, Kevin Lynch built apple Watch…I could keep going.

Quelle: That time in 1994 when Steve Jobs got to use a device like an iPhone

Im September 2018 erscheint ein Dokumentarfilm über das Unternehmen und sein Erbe.

Die ganze Geschichte erinnert mich an einen anderen Dokumentarfilm über das Filmprojekt Dune in den 1970ern, dessen Erbe in den Blockbustern Star Wars, Blade Runner, Alien und Terminator aufging. Der Film Dune kam 1984 zwar doch noch in die Kinos, hatte aber kaum noch etwas mit Jodorowskys Vision gemein.

PS: Die Songs der Band, welche den Soundtrack für den 1970er Dune-Film hätte liefern sollen, gehören zu den abgefahrensten Stücken auf meinem iPhone. Ich weiss immer noch nicht, ob ich die Songs mag.

Tags: , , , , , , , , , , , ,
Labels: Apple, Medien

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 19. Juli 2018

SRF Einstein: Das Grossbauprojekt Bahnhof Bern 2025

Eindrücklich! Nun weiss ich auch, was der Lärm auf sich hat, den wir an der Schlösslistrasse jeweils nachts bei voll geöffnetem Fenster hören …

Tags: , , , , , ,
Labels: Schweiz

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 19. Juli 2018

SPF für ein Cyon-Hosting aktivieren

Da ich mich auf der Arbeit gerade mit dem Thema E-Mail-Sicherheit und -Authentizität befasse, war es nun an der höchsten Zeit, auch meinen privaten Mailverkehr sicherer zu machen.

Begonnen habe ich mit der Konfiguration des sogenannten Sender Policy Frameworks SPF. Der Besitzer einer Domain gibt mit einem TXT-Eintrag in einem bestimmten Format auf dem Nameserver der Domain bekannt, von welchen IPs aus überall legitime E-Mails versendet werden können.

Mailserver, welche von einer mit SPF ausgerüsteten Domain E-Mails erhalten, können — müssen aber nicht — diese Information abfragen und mit den Informationen im Header des E-Mails vergleichen. Basierend auf dem Resultat dieser Auswertung kann der Mail-Server oder der Mail-Client des Empfänger Aktionen ergreifen. Beispielsweise E-Mails markieren oder in einen Unterordner verschieben, welche von keiner der freigegebenen IP versendet wurden. Oder E-Mails von einer offiziellen Mail-Server-IP eine höhere Authentizitätspunktzahl geben und so von der Spam-Score abziehen.

Mein Hoster der Wahl, Cyon, hat im Support-Artikel Was ist ein SPF-Record? festgehalten, wie ein solcher SPF-Record aussehen könnte und wie man diesen über das Controlpanel my.cyon einrichtet. Obwohl der Autor des Support-Artikels festhält, dass alle Kundendomains bereits einen Eintrag besitzen …

Der Standardeintrag bei cyon sieht folgendermassen aus: […] Sie können diesen im my.cyon unter «Webhosting» > «DNS-Editor» mit dem DNS-Editor anpassen. Wichtig ist, dass man den bestehenden Eintrag ergänzt, da nur jeweils ein SPF-Eintrag gültig ist.

… hatten meine Domains keinen solchen Eintrag. Wahrscheinlich, weil ich bereits langjähriger Kunde bin und nur neue Hostingkunden diesen Eintrag automatisch erhalten.

Cyon schlägt folgenden Eintrag vor:

v=spf1 +a +mx +ip4:194.126.200.0/24 +ip4:149.126.0.0/21 -all

Ich empfand diese zwei Ranges viel zu weitläufig und habe mich entschieden, stattdessen folgende Konfiguration einzuspeisen:

v=spf1 +a +mx +ip4:194.126.200.18 +ip4:194.126.200.19 +ip4:194.126.200.20 +ip4:194.126.200.22 +ip4:149.126.4.65 -all

Die IPs fand ich folgendermassen heraus:

$ host mail.cyon.ch
mail.cyon.ch has address 194.126.200.18
mail.cyon.ch has address 194.126.200.22
mail.cyon.ch has address 194.126.200.20
mail.cyon.ch has address 194.126.200.19
$ host s056.cyon.net
s056.cyon.net has address 149.126.4.65

Dahinter verstecken sich einerseits alle vier Server, auf welche mail.cyon.ch auflöst, andererseits der physische Server, auf welchem meine Web-Site gehostet wird: s056.cyon.net.

Die TTL habe ich auf 15 Minuten gesetzt, damit ich in Notfällen Anpassungen vornehmen kann und diese sich dann rasch propagieren.

Existenz des Eintrags verifizieren

$ dig @ns1.cyon.ch emeidi.com txt
...
;; ANSWER SECTION:
emeidi.com.		900	IN	TXT	"v=spf1 +a +mx +ip4:194.126.200.18 +ip4:194.126.200.19 +ip4:194.126.200.20 +ip4:194.126.200.22 +ip4:149.126.4.65 -all"
...

Via: Using dig to search for SPF records
und Force dig to resolve without using cache

Warnung

Auf der Arbeit musste ich realisieren, dass man als Besitzer einer Domain den SPF-Record stets aktuell halten muss. Bisher sah ich folgende Probleme:

  • E-Mails werden im Namen des Dienstleister über den Services eines Dritten versendet (bspw. SaaS), der Dienstleister vergisst aber, die IP(s) resp. die Domain mit den SPF-Einträgen des Mail-Servers in die Konfiguration aufzunehmen.
  • Man macht einen Flüchtigkeitsfehler und schreibt bspw. Anstelle +ip4:1.2.3.4 folgende syntaktisch falsche Konfiguration: +ipv4:1.2.3.4

Validität prüfen

Es empfiehlt sich deshalb, zumindest die Validität eines SPF-Records zu testen. Hierfür hat sich bei mir das Tool MxToolbox Supertool bewährt:

image-7972

Wird der SPF-Record grün hinterlegt, ist alles bestens. Erscheint er rot, ist etwas an der Syntax nicht korrekt. Übrigens: Bei mit +include: verschachtelten Einträgen empfiehlt es sich, die Domains im Include-Statement auch noch gleich abzufragen, indem man in der Resultate-Tabelle darauf klickt. In einem Fall fand sich die Fehlkonfiguration dort.

Zusätzlich gibt es noch eine andere Variante — lasst uns doch einfach ein Mail senden! Und zwar an diese Mail-Adresse: check-auth@verifier.port25.com. Man erhält automatisch eine Antwort zurück, die sich etwa so liest:

==========================================================
Summary of Results
==========================================================
SPF check:          pass
"iprev" check:      pass
DKIM check:         permerror
SpamAssassin check: ham

==========================================================
Details:
==========================================================

HELO hostname:  s056.cyon.net
Source IP:      149.126.4.65
mail-from:      xyz@eMeidi.com

----------------------------------------------------------
SPF check details:
----------------------------------------------------------
Result:         pass
ID(s) verified: smtp.mailfrom=xyz@eMeidi.com

DNS record(s):
   eMeidi.com. 60 IN TXT "v=spf1 +a +mx +ip4:194.126.200.18 +ip4:194.126.200.19 +ip4:194.126.200.20 +ip4:194.126.200.22 +ip4:149.126.4.65 -all"
   eMeidi.com. 60 IN A 149.126.4.65


----------------------------------------------------------
"iprev" check details:
----------------------------------------------------------
Result:         pass (matches s056.cyon.net)
ID(s) verified: policy.iprev=149.126.4.65

DNS record(s):
   65.4.126.149.in-addr.arpa. 60 IN PTR s056.cyon.net.
   s056.cyon.net. 60 IN A 149.126.4.65

Produktiver Test

Um das funktionieren des SPF-Records vollends zu testen, sendete ich mir ein Mail an eine Gmail-Adresse und guckte mir dann den Mail-Header an, wie er bei Google ankommt:

...
Received-SPF: pass (google.com: domain of xyz@emeidi.com designates 149.126.4.65 as permitted sender) client-ip=149.126.4.65;
Authentication-Results: mx.google.com;
       dkim=temperror (no key for signature) header.i=@emeidi.com header.s=default header.b=LchLhMBS;
       spf=pass (google.com: domain of xyz@emeidi.com designates 149.126.4.65 as permitted sender) smtp.mailfrom=xyz@emeidi.com
...

Ist SPF gar nicht konfiguriert, sieht der E-Mail-Header stattdessen folgendermassen aus:

...
Received-SPF: neutral (google.com: 149.126.4.65 is neither permitted nor denied by best guess record for domain of xyz@emeidi.com) client-ip=149.126.4.65;
Authentication-Results: mx.google.com;
       dkim=temperror (no key for signature) header.i=@emeidi.com header.s=default header.b=cbFM4Bn7;
       spf=neutral (google.com: 149.126.4.65 is neither permitted nor denied by best guess record for domain of xyz@emeidi.com) smtp.mailfrom=xyz@emeidi.com
...

Tags: , , , ,
Labels: Web

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 18. Juli 2018

Wovor die Superreichen so richtig Schiss haben

Der Autor und Dozent Douglas Rushkoff wird von fünf Superreichen Hedge Funds-Besitzern eingeladen, um sie zu „beraten“, wie sie die unausweichbar nahende Apokalypse überleben.

Bunker haben sie schon gebaut, interessieren sich aber dennoch dafür, in welcher Weltregion man den Klimawandel überlebt. Und wie sie ihre Sicherheitskräfte loyal halten, sobald Geld wertlos geworden ist:

[…] they were preparing for a digital future that had a whole lot less to do with making the world a better place than […] insulating themselves from a very real and present danger of climate change, rising sea levels, mass migrations, global pandemics, nativist panic, and resource depletion. For them, the future of technology is really about just one thing: escape.

[…] For all their wealth and power, they don’t believe they can affect the future. They are simply accepting the darkest of all scenarios and then bringing whatever money and technology they can employ to insulate themselves

[…] The more committed we are to this view of the world, the more we come to see human beings as the problem and technology as the solution. The very essence of what it means to be human is treated less as a feature than bug.

Quelle: Survival of the Richest

Dabei läge — aus Sicht Rushkoffs — die Lösung auf der Hand:

When the hedge funders asked me the best way to maintain authority over their security forces after “the event,” I suggested that their best bet would be to treat those people really well, right now. They should be engaging with their security staffs as if they were members of their own family. And the more they can expand this ethos of inclusivity to the rest of their business practices, supply chain management, sustainability efforts, and wealth distribution, the less chance there will be of an “event” in the first place. All this technological wizardry could be applied toward less romantic but entirely more collective interests right now.

Tags: , , , , ,
Labels: Gesellschaft

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 18. Juli 2018

Auf chinesischen iPhones gibt es die Taiwan-Flagge nicht als Emoji

Patrick Wardle hat einer Bekannten geholfen, reproduzierbare Abstürze ihres iPhones zu debuggen.

Die Abstürze rührten von einem Bug in einer Routine her, welche nur Personen betraf, welche ihr iPhone in der chinesischen Lokalisation betrieben: Die Routine kümmert sich darum, dass iPhones mit dieser Landeseinstellung das Wort „Taiwan“ in Texten sowie die Taiwan-Flagge (Emoji) nicht anzeigen, sondern stattdessen mit einem rechteckigen, ein Kreuz enthaltendes Kästchen ersetzen (Bild):

A Remote iOS Bug. apple wrote code to appease the chinese government …it was buggy

Apple hat den Bug in der Routine in der Zwischenzeit behoben. Die Taiwan-Flagge kriegen solche Benutzer aber aus nachvollziehbaren Gründen immer noch nicht zu sehen: Apple möchte es sich mit seinem grössten Markt nicht verderben und zensiert seine Produkte freiwillig.

Wem die vertrackten geschichtlichen Hintergründe dieser Angelegenheit nicht klar sind, lese sich auf Wikipedia ein: Taiwan-Konflikt sowie als konkretes Symptom des Konflikts die Resolution 2758 der UN-Generalversammlung.

Nachtrag

Und jetzt flattert auch noch gerade diese Meldung bei mir rein:

China does not recognise any nation that has diplomatic relations with Taiwan – officially known as the Republic of China (ROC). Under the One China Policy, it does not consider the island nation be an independent country. The island has been self-ruled since its split from the mainland after the 1949 civil war.

Palau officially established diplomatic ties with Taiwan in December 1999.

Quelle: Airline says it shut down after China labelled Palau an ‘illegal destination’ over its Taiwan recognition

Tags: , , , , , , , , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 8. Juli 2018

Endlich ist es da: Die M2M- resp. OOB-SIM für Normalsterbliche

Seit Jahr und Tag bin ich auf der Suche nach einer Daten-SIM-Karte, welche ich als Out-of-Band-Lösung in meinen drei Netzwerk-Standorten installieren kann.

Die SIM möchte ich in ein UMTS-Modem einbauen, welches ich entweder extern per USB oder intern per Einbau an den ThinkPad-„Server“ der jeweiligen Location anhänge.

Fällt das Internet aus, oder verliere ich aus irgendeinem Grund den Remote-Zugriff ins LAN, aktiviert sich die SIM-Karte von alleine, meldet seine IP bei einem Dienst wie DynDNS, öffnet einen VPN-Tunnel und bietet mir so die Möglichkeit, Probleme aus der Ferne zu diagnostizieren.

Mit SimplyMobile von Swisscom scheint das nun Realität zu werden:

  • Prepaid-SIM, d.h. keine monatlich wiederkehrenden Kosten
  • Datenpaket von 750 MB für 9.90 CHF
  • Datenguthaben verfällt nicht

Quelle: SIMPLYMOBILE PREPAID

Fazit: Das Basteln kann beginnen!

Tags: , , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 8. Juli 2018

OpenVPN meldet „INSECURE cipher with block size less than 128 bit (64 bit).“

Zwar erscheint die folgende Fehlermeldung seit längerem in den Logs meiner Site-to-Site-VPNs, doch heute erst hatte ich die Zeit, mich dem Problem anzunehmen:

Sun Jul  8 09:24:37 2018 Outgoing Static Key Encryption: Cipher 'BF-CBC' initialized with 128 bit key
Sun Jul  8 09:24:37 2018 WARNING: INSECURE cipher with block size less than 128 bit (64 bit).  This allows attacks like SWEET32.  Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).

Zuerst dachte ich, dass ich die statischen Schlüssel der VPN-Verbindungen neu erstellen muss, weshalb ich zuerst einmal das Script optimierte. Falsch gedacht! Obwohl ich die Schlüssel ersetzt hatte, erschien beim erneuten Verbindungsaufbau erneut dieselbe Fehlermeldung.

Nach etwas Googlen dann die effektive Lösung: Ich muss die Konfigurationsdateien der jeweiligen Verbindungen anpassen! Folgende Zeile habe ich nun in die OpenVPN-Konfigurationsdateien auf beiden Seiten eingefügt:

...
cipher      AES-256-CBC
...

Et voilà! Auf der Seite des Servers sehe ich nun in der Log-Datei:

Sun Jul  8 10:47:17 2018 OpenVPN 2.4.0 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 18 2017
Sun Jul  8 10:47:17 2018 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.08
Sun Jul  8 10:47:17 2018 Outgoing Static Key Encryption: Cipher 'AES-256-CBC' initialized with 256 bit key
Sun Jul  8 10:47:17 2018 Outgoing Static Key Encryption: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Jul  8 10:47:17 2018 Incoming Static Key Encryption: Cipher 'AES-256-CBC' initialized with 256 bit key
Sun Jul  8 10:47:17 2018 Incoming Static Key Encryption: Using 160 bit message hash 'SHA1' for HMAC authentication
...

Tags: , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen