Archiv Juli 2018

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:

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

1 Kommentar | 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

Sonntag, 8. Juli 2018

UniFi Produktenamen in syslog-Nachrichten

Auf meiner ELK-Installation finden sich unter anderem auch die Logs meiner UniFi-Controller und der damit kontrollierten Access Points. In den syslog-Nachrichten werden die Typen von UniFi-Netzwerkgeräten mit folgenden Kürzeln identifiziert:

  • U7PG2 — UniFi AP-AC-Pro Gen2
  • U7MSH — UniFi AP-AC-Mesh
  • U7LR — UniFi AP-AC-LR
  • U7P — UniFi AP-Pro

Die offizielle Liste von UniFi findet sich im JSON-Format hier: bundles.json.txt

Tags: , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Samstag, 7. Juli 2018

AhrefsBot und SEMrush Spider mit .htaccess blocken

Diese zwei Spider, deren Zweck (und Hintermänner) ich trotz folgender zwei erläuternden Seiten immer noch nicht verstehe, gehören geblockt:

Hauptgrund ist, dass sie (immer wieder) uralte URLs aufrufen, die nicht mehr existeren, obwohl dies von meinem CMS auch korrekt mit dem HTTP-Code 410 Gone zurückgemeldet wird:

The HyperText Transfer Protocol (HTTP) 410 Gone client error response code indicates that access to the target resource is no longer available at the origin server and that this condition is likely to be permanent.

If you don’t know whether this lack is temporary or permanent, a 404 status code should be used instead.

Quelle: 410 Gone

Nun gut, dann bleibt halt nur noch das drastischste Mitte mittels .htaccess:

...
RewriteCond %{HTTP_USER_AGENT} SemrushBot [OR]
RewriteCond %{HTTP_USER_AGENT} AhrefsBot
RewriteRule .* - [R=429]
...

Noch kurz getestet:

$ wget "https://www.domain.tld/" --user-agent "Mozilla/5.0 (compatible; AhrefsBot/5.2; +http://ahrefs.com/robot/)"
--2018-07-07 13:34:33--  https://www.domain.tld/
Auflösen des Hostnamens www.domain.tld (www.domain.tld)… 1.2.3.4
Verbindungsaufbau zu www.domain.tld (www.domain.tld)|1.2.3.4|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 429 Too Many Requests
2018-07-07 13:34:33 FEHLER 429: Too Many Requests.
$ wget "https://www.domain.tld/" --user-agent "Mozilla/5.0 (compatible; SemrushBot/2~bl; +http://www.semrush.com/bot.html)"
--2018-07-07 13:34:52--  https://www.domain.tld/
Auflösen des Hostnamens www.domain.tld (www.domain.tld)… 1.2.3.4
Verbindungsaufbau zu www.domain.tld (www.domain.tld)|1.2.3.4|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 429 Too Many Requests
2018-07-07 13:34:52 FEHLER 429: Too Many Requests.

Passt. Und jetzt herrscht hier Ruhe (und meine Log-Files bleiben leer).

Ah, und vielleicht sollte man sich noch vergewissern, dass alle anderen Browser durchkommen — Kollateralschäden wollen wir ja wennmöglich vermeiden:

$ wget "https://www.domain.tld/"
--2018-07-07 13:47:31--  https://www.domain.tld/
Auflösen des Hostnamens www.domain.tld (www.domain.tld)… 1.2.3.4
Verbindungsaufbau zu www.domain.tld (www.domain.tld)|1.2.3.4|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: nicht spezifiziert [text/html]
Wird in »index.html« gespeichert.

index.html.1                                                       [ <=>]  21,90K  --.-KB/s    in 0,005s  

2018-07-07 13:47:31 (4,07 MB/s) - »index.html« gespeichert [22421]

Tags: , , , , , , , , , , ,
Labels: Web

1 Kommentar | neuen Kommentar verfassen