Zufällig habe ich gesehen, dass die Suchmaschine Shodan bereits die security.txt auswertet und als Security Contact auflistet. Genau so habe ich mir das vorgestellt 🙂 https://www.shodan.io/host/148.251.40.23
Die Zeit ging weiter, die Entwicklung bei BIND und DNS ebenfalls. Daher gibt es nun einen neuen Beitrag, der das aktuelle Setup mit BIND 9.20 auf FreeBSD 15 beschreibt – inklusive sauberer Trennung von authoritative DNS (Port 53) und öffentlichem Resolver (DoT/DoH) sowie reproduzierbaren CLI-Tests für IPv4 und IPv6. Bitte dort weiterlesen.
Meine Tests mit DoT (DNS over TLS) habe ich bereits vor einiger Zeit gestartet. DoT DNS over TLS mit Bind, stunnel und Android 9 Dieses arbeitet noch immer ganz fein auf meinem Smartphone. DoT gefällt mir noch immer um einiges besser als DoH aber auch hier wollte ich nun einmal einen Versuch starten. Zusammen mit nginx und einem etwas angepassten doh-proxy läuft dieses nun auf dem gleichen System.
Im Firefox ist es schnell aktiviert https://ns1.kernel-error.de/dns-query…
Es funktioniert auch, so richtig glücklich macht es mich aber nicht! Natürlich ist die Umsetzung nur etwas für einen kleinen privaten Test. „Schnell“ genug ist es ebenfalls! Zumindest zum Surfen im Internet, dennoch wäre mir eine saubere Implementierung von DoT im resolver vom OS viel lieber. So wie bereits ab Android 9 zu sehen. Vielleicht ändert sich mein Gefühl ja etwas zusammen mit QUIC (HTTP/3)?!?
Es gibt seit einiger Zeit einen Draft zu Security Policies. Schaut mal hier: https://tools.ietf.org/html/draft-foudil-securitytxt-07 über diesen Weg kann man für seine Domain eine Security Policie veröffentlichen. Dieses inkl. Kontaktdaten einer „Dankeschön“ Seite usw…
Die Idee ist es eine einheitliche Möglichkeit zu schaffen um freundlichen Findern von Sicherheitslücken/Problemen eine einfache und „sichere“ Anlaufstelle zu geben. Wer schon mal ein Löchlein gefunden hat, kennt das Problem. Man sucht eine Kontaktmöglichkeit, scheitert an der Human Firewall oder am technischen Verständnis von seinem Gegenüber. Gibt es es bug bounty oder wird der Informierte ~nervös~?!? Ist die Webseite vielleicht schon kompromitiert und der Hinweis wandert direkt an den Bösewicht? usw. usw. usw…
Diese Probleme soll dieser RFC möglichst einfach erschlagen. Es gibt ein textfile mit dem Namen security.txt unter der jeweiligen Domain im Pfad .well-known, diese ist nach Möglichkeit noch gpg cleartext signiert und beinhaltet alle nötigen Informationen.
Wie man gut sehen kann wird einfach jede Anfrage nach /autodiscover/autodiscover.xml (egal ob am Anfang groß oder klein geschrieben), im Hintergrund weitergeleitet an das php file autodisvocer.php:
<?php
/********************************
* Autodiscover responder
********************************
* This PHP script is intended to respond to any request to http(s)://mydomain.com/autodiscover/autodiscover.xml.
* If configured properly, it will send a spec-complient autodiscover XML response, pointing mail clients to the
* appropriate mail services.
* If you use MAPI or ActiveSync, stick with the Autodiscover service your mail server provides for you. But if
* you use POP/IMAP servers, this will provide autoconfiguration to Outlook, Apple Mail and mobile devices.
*
* To work properly, you'll need to set the service (sub)domains below in the settings section to the correct
* domain names, adjust ports and SSL.
*/
//get raw POST data so we can extract the email address
$request = file_get_contents("php://input");
// optional debug log
# file_put_contents( 'request.log', $request, FILE_APPEND );
// retrieve email address from client request
preg_match( "/\<EMailAddress\>(.*?)\<\/EMailAddress\>/", $request, $email );
// check for invalid mail, to prevent XSS
if (filter_var($email[1], FILTER_VALIDATE_EMAIL) === false) {
throw new Exception('Invalid E-Mail provided');
}
/**************************************
* Port and server settings below *
**************************************/
// IMAP settings
$imapServer = 'imap.kernel-error.de'; // imap.example.com
$imapPort = 993;
$imapSSL = true;
// SMTP settings
$smtpServer = 'smtp.kernel-error.de'; // smtp.example.com
$smtpPort = 465;
$smtpSSL = true;
//set Content-Type
header( 'Content-Type: application/xml' );
?>
<?php echo '<?xml version="1.0" encoding="utf-8" ?>'; ?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
<Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
<Account>
<AccountType>email</AccountType>
<Action>settings</Action>
<Protocol>
<Type>IMAP</Type>
<Server><?php echo $imapServer; ?></Server>
<Port><?php echo $imapPort; ?></Port>
<DomainRequired>off</DomainRequired>
<LoginName><?php echo $email[1]; ?></LoginName>
<SPA>off</SPA>
<SSL><?php echo $imapSSL ? 'on' : 'off'; ?></SSL>
<AuthRequired>on</AuthRequired>
</Protocol>
<Protocol>
<Type>SMTP</Type>
<Server><?php echo $smtpServer; ?></Server>
<Port><?php echo $smtpPort; ?></Port>
<DomainRequired>off</DomainRequired>
<AuthRequired>on</AuthRequired>
<LoginName><?php echo $email[1]; ?></LoginName>
<SPA>off</SPA>
<SSL><?php echo $imapSSL ? 'on' : 'off'; ?></SSL>
<AuthRequired>on</AuthRequired>
<SMTPLast>off</SMTPLast>
<UsePOPAuth>off</UsePOPAuth>
</Protocol>
</Account>
</Response>
</Autodiscover>
Das kleine php script macht auch nicht viel mehr als die im Post übermittelte E-Mail Adresse in eine Variable zu schieben, zu prüfen ob es wirklich eine E-Mail Adresse ist und dann am Ende einfach das fertige xml zurück zu liefern.
Sonst darf man für den Postausgangsserver nämlich immer manuell den Haken setzen bei: „Gleiche Einstellungen wie für den Posteingangsserver verwenden“ Welches sicher einige Anwender vor einer nur schwer zu überwindenden Hürde stell.
Damit dieses nicht nur für E-Mail Adresse der Domain kernel-error.de funktioniert gibt es in den anderen DNS Zonen SRV RRs welche auf diese Autodiscoverdomain verweisen:
Nun sorgt dieses bei Outlook für eine kleine Warnmeldung bei der Konfiguration, ob man diesem Verweis wirklich folgen möchte.
Dieses kommt nur einmalig und man könnte es zudem mit deinem Registierungsschlüssel unterbinden aber naja das sollte für jeden klickbar sein, oder?!?! Im Anschluss ist die Konfiguration vom E-Mail Client schon abgeschlossen.
Wie man sieht ist es sehr simpel und sollte von nahezu jedem erledigt werden können, der es schafft seine E-Mail Adresse und sein Kennwort nach dem Outlookstart einzugeben.
Wie man bei allen ausgehenden E-Mails dafür sorgt, dass die Client IP Adresse sowie der eingesetzte Mailclient vom Postfix verschleiert wird… Ja dieses habe ich bereits geschrieben. Postfix soll verschleiern…
Nun kann es dennoch Sinn ergeben dieses nicht für jede E-Mail zu tun, welche den Mailserver verlässt. Wenn man dieses nur auf E-Mails anwenden möchte, welche von angemeldeten Benutzern versendet werden, funktioniert es wie folgt.
Man erstellt in der master.cf vom Postfix einen neuen Service:
anonym unix n - - - 0 cleanup
-o header_checks=pcre:/usr/local/etc/postfix/header_cleanup
Nun sorgt man in der gleichen Konfigurationsdatei noch dafür, dass am Ende vom Submission und smtps Service in diesen neuen Service gesprungen wird:
submission inet n - n - - smtpd
[...]
-o cleanup_service_name=anonym
[...]
smtps inet n - n - - smtpd
[...]
-o cleanup_service_name=anonym
Der Inhalt unserer /usr/local/etc/postfix/header_cleanup ist dabei weiterhin gleich:
Ich nutze auf meinen Desktops GhostBSD und FreeBSD Systeme zusammen mit Mate und LightDM. Ebenfalls verwende ich für ein paar Kleinigkeiten den gnome-keyring. Dabei „stört“ es mich diesen nach der Anmeldung am Desktop gesondert entsperren zu müssen. Es gibt aber eine Möglichkeit dieses von pam nach der Anmeldung automatisch entsperren zu lassen. Dafür müssen nur folgende Zeilen in der /usr/local/etc/pam.d/lightdm ergänzt werden: auth optional pam_gnome_keyring.so session optional pam_gnome_keyring.so auto_start
Meine sieht nun also wie folgt aus:
#
# PAM configuration for the "lightdm" service
#
# auth
auth sufficient pam_self.so no_warn
auth include system
auth optional pam_gnome_keyring.so
# account
account requisite pam_securetty.so
account required pam_nologin.so
account include system
# session
session include system
session optional pam_gnome_keyring.so auto_start
# password
password include system
Nach dem nächsten Login habe ich nun die Möglichkeit, beim Entsperren des Keyrings, einen Haken zu setzten und schon wird bei jedem Login mein Keyring automatisch geöffnet.
Schau mal einer an; was sehen meine Augen denn da? Eine E-Mail von Microsoft in welcher sie darauf hinweisen, dass ab dem 01.06.2020 mit ihrem Office 365 kein TLS 1.0 und TLS 1.1 mehr möglich ist 😀 Über so etwas freue ich mich natürlich! Ob sich dann nun so langsam auch andere bewegen?
As previously communicated (MC124104 in Oct 2017, MC126199 in Dec 2017 and MC128929 in Feb 2018), we are moving all of our online services to Transport Layer Security (TLS) 1.2+ to provide best-in-class encryption, and to ensure our service is more secure by default.
Keeping on track with this promise – Office 365 will be retiring TLS 1.0 and 1.1 starting June 1, 2020.
[How does this impact me?]
Starting June 1, 2020, Office 365 will begin retiring TLS 1.0 and 1.1. This means that all connections to Office 365 using the protocols TLS 1.0 and TLS 1.1 will not work.
[What should I do to prepare for this change?]
Update or replace clients and devices that rely on TLS 1.0 and 1.1 to connect to Office 365, prior to June 1, 2020.
Please click Additional Information to learn more.
Ob sie dieses auch bis zum MX durchziehen? Ich glaube fast nicht…
Die Zeit ging weiter, die Entwicklung bei BIND und DNS ebenfalls. Daher gibt es nun einen neuen Beitrag, der das aktuelle Setup mit BIND 9.20 auf FreeBSD 15 beschreibt – inklusive sauberer Trennung von authoritative DNS (Port 53) und öffentlichem Resolver (DoT/DoH) sowie reproduzierbaren CLI-Tests für IPv4 und IPv6. Bitte dort weiterlesen.
Die eigenen DNS Anfragen über eine Verschlüsselte Verbindung an einen DNS Server zu schicken welchem man vertraut, dieses liest sich schon gut oder? Keiner verfolgt mein Surfverhalten und zusammen mit DNSSEC schiebt mir so schnell keiner falsche Records unter 🙂
Am ehesten vertraue ich meinem eigenen DNS Server (ns1.kernel-error.de). Auf diesem arbeitet ein Bind und vor diesen habe ich für DoT stunnel gestellt. Die Konfiguration vom stunnel sieht dabei grob wie folgt aus:
Auf einem Android 9 Gerät kann ich also nun unter den Einstellungen ==> Netzwerk & Internet ==> Erweitert ==> Privates DNS meinen Nameserver eintragen.
Jetzt sieht mir keiner mehr beim meinen DNS Abfragen zu 😀
Die Europäische Kommission hat ein online Tool veröffentlicht, welches jedem Benutzer eines E-Mail Dienstes ermöglichen soll den eingesetzten E-Mail Dienst zu „prüfen“.
Natürlich kann man sich nicht blind auf so einen Test verlassen aber dieses Tool gibt einem eine ganz gute Übersicht. Diese wird dabei in drei Bereiche unterteilt:
1. Confidential Delivery 2. Phishing and Identity Theft 3. Integrity of Messages
Dort kann man nun seine E-Mail Adresse eintragen, zu dieser sendet das Tool nun eine E-Mail und bittet darum auf die Mail zu antworten. Hat man dies erledigt bekommt man seinen Code zur Auswertung. Diesen kann man nun auf der gleichen Seite eintragen und sich seine Auswertung anschauen.
Mein Identifier vom Report heute ist zum Beispiel: 19a837a05e4b7e04a3dea8cea29bd355
Prüft also ruhig einmal euer eingesetztes Mailsystem und fragt ggf. bei eurem Anbieter/Admin nach, wenn ich beim Ergebnis unsicher seit.