Datenhaufen zu IT und Elektronik.

Autor: kernel-error (Seite 7 von 47)

Outlook Autodiscover für IMAP und SMTP konfigurieren

Vor einigen Jahren habe ich bereits etwas zu Microsoft Outlook und dessen Autodiscover geschrieben. Microsoft Office Outlook Autodiscover

Ich setze es noch immer in recht ähnlicher Form ein und möchte den aktuellen Stand kurz beschreiben.

Primär habe ich eine Autodiscoverdomain https://autodiscover.kernel-error.de hinter dieser steht ein nginx und er liefert unter diesem Pfad https://autodiscover.kernel-error.de/Autodiscover/Autodiscover.xml die Konfigurationsinformationen für verschiedene Maildomains für smtps und imaps aus.

Die Konfiguration vom nginx ist recht überschaubar. Klar, https und der spannende Teil der Konfiguration ist folgender:

        location ~ /(?:a|A)utodiscover/(?:a|A)utodiscover.xml {
        root /usr/local/www/autodiscover.kernel-error.de;
        try_files /autodiscover/autodiscover.php =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass unix:/var/run/php-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $request_filename;
        include fastcgi_params;
        fastcgi_cache MYAPP;
        fastcgi_cache_valid 200 60m;
    }

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.

Besonders wichtig dabei ist:

<AuthRequired>on</AuthRequired>
<SMTPLast>off</SMTPLast>
<UsePOPAuth>off</UsePOPAuth>

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:

➜  ~ dig _autodiscover._tcp.kernel-error.com IN SRV +short
0 0 443 autodiscover.kernel-error.de.

Nun sorgt dieses bei Outlook für eine kleine Warnmeldung bei der Konfiguration, ob man diesem Verweis wirklich folgen möchte.

Outlook autodiscover

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.

Outlook autodiscover

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.

Postfix: Verschleierung nur für SASL-Benutzer einrichten

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:

/^(Received: from)[^\n]*(.*)/ REPLACE $1 ::88 (YOUR MOM [::88])$2
/^X-Originating-IP/ IGNORE
/^User-Agent*(.*)/ REPLACE User-Agent: YOUR MOMS MAILER
/^X-Mailer*(.*)/ REPLACE X-Mailer: YOUR MOMS MAILER

Nach einem Restart vom Postifx hat man nun den gewünschten Zustand. Natürlich dürfen nun die smtp_header_checks nicht mehr in der main.cf sein:

#smtp_header_checks = pcre:/usr/local/etc/postfix/header_cleanup

Viel Spaß

FreeBSD OpenSSH: OS-Banner sicher entfernen

Im Standard ist der OpenSSH Server auf einem FreeBSD so konfiguriert, dass er jeweils die aktuelle Betriebssystemversion mit ausliefert.

Dieses sieht dann im Beispiel so aus:

telnet bsd01.testsystem 22
Trying 1.2.3.4...
Connected to bsd01.testsystem.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.8 FreeBSD-20180909

Um hier zumindest die genaue OS Version zu verstecken reicht folgendes in der /etc/sshd_config:

#VersionAddendum FreeBSD-20180909
VersionAddendum DemMeisterSeinRennAuto

Testet man nun noch mal sieht man nur noch die Version:

telnet bsd01.testsystem 22
Trying 1.2.3.4...
Connected to bsd01.testsystem.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.8 DemMeisterSeinRennAuto

Auf einem Debian basierten System wäre es hingegen:

DebianBanner no

GhostBSD 19.09 Ports benutzen

GhostBSD basierte früher direkt auf FreeBSD. Inzwischen ist es aber auf TrueOS gewechselt. So sieht es ebenfalls mit den Ports aus. Man kann also nicht wie unter FreeBSD gewohnt mit portsnap arbeiten sondern muss einen gewissen „Umweg“ nehmen.

Die zu GhostBSD gehörenden Ports bekommt man nun so ins System:

sudo git clone https://github.com/ghostbsd/ghostbsd-ports.git /usr/ports

In GhostBSD Version 19.09 ist etwas Ordnung geschaffen worden und viele vermeintlich unnötige Pakete mussten weichen. Zum arbeiten mit den Ports benötigt man daher noch folgendes:

pkg install src os-generic-userland-devtools

Ab jetzt kann man wie gewohnt mit den Ports arbeiten!

GhostBSD und FreeBSD: GNOME-Keyring automatisch entsperren

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.

Ab 01.06.2020 auch kein TLS 1.0 und TLS 1.1 mehr bei Office 365

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…

DNS over TLS (DoT) mit BIND, Stunnel und Android 9 einrichten

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:

[dns4]
accept = 853
connect = 127.0.0.1:53
cert = /usr/local/etc/stunnel/ssl/dns.crt
key = /usr/local/etc/stunnel/ssl/dns.key
CAfile = /usr/local/etc/stunnel/ssl/ca.crt
ciphers = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
options = NO_SSLv2
options = NO_SSLv3
options = NO_TLSv1
options = NO_TLSv1.1
options = CIPHER_SERVER_PREFERENCE
options = DONT_INSERT_EMPTY_FRAGMENTS
renegotiation = no
TIMEOUTclose = 0

[dns6]

accept = 2a03:4000:38:20e::53:853 connect = ::1:53 cert = /usr/local/etc/stunnel/ssl/dns.crt key = /usr/local/etc/stunnel/ssl/dns.key CAfile = /usr/local/etc/stunnel/ssl/ca.crt ciphers = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 options = NO_SSLv2 options = NO_SSLv3 options = NO_TLSv1 options = NO_TLSv1.1 options = CIPHER_SERVER_PREFERENCE options = DONT_INSERT_EMPTY_FRAGMENTS renegotiation = no

Die TLS Konfiguration ergibt dabei nun folgendes Bild: https://tls.imirhil.fr/tls/ns1.kernel-error.de:853

Auf einem Android 9 Gerät kann ich also nun unter den Einstellungen ==> Netzwerk & Internet ==> Erweitert ==> Privates DNS meinen Nameserver eintragen.

DoT Android 9

Jetzt sieht mir keiner mehr beim meinen DNS Abfragen zu 😀

Der Matrix Server Synapse ist in der ersten Stable Version 1 erschienen

Es hat einige Zeit gedauert aber gestern ist Synapse in Version 1.0.0 erschienen.

https://matrix.org/blog/2019/06/11/introducing-matrix-1-0-and-the-matrix-org-foundation
https://matrix.org/blog/2019/06/11/synapse-1-0-0-released
https://github.com/matrix-org/synapse/releases/tag/v1.0.0

Eine ganz wichtige Änderung der Version ist, dass Zertifikate anderer Server ab jetzt gültig sein müssen.

Wer seinen Server mittels pip auf den letzten Stand bringen möchte:

$ pip install --upgrade matrix-synapse

„Meldet“ euch doch mal wenn es klappt 🙂

Tool der europäischen Kommission zur E-Mail Sicherheit MECSA

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

Dazu habe ich für euch sogar ein >>Youtube Video<<.

Zum Tool selbst geht es hier lang: https://mecsa.jrc.ec.europa.eu/en/

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.

Ersatz für www.dnsinspect.com

Lange Zeit war dnsinspect eine wunderbare Anlaufstelle um „mal eben“ eine DNS Zone sowie deren Nameserver auf die gröbsten Probleme hinsichtlich ihrer Konfiguration zu prüfen. Schon vor Monaten ging dann dnsinspect in threatintelligenceplatform auf… Hier kann man (mit Account) zwar noch immer prüfen, es ist für mich nur nicht mehr so flüssig, simpel und detailreich wie ich es gerne hätte. Daher musste ein Ersatz hier und dieser ist https://zonemaster.net/

Dieses erfüllt alle meine Wünsche und hat genau einen Zweck und Nutzen. Schaut einfach mal drauf!

« Ältere Beiträge Neuere Beiträge »

© 2024 -=Kernel-Error=-

Theme von Anders NorénHoch ↑