Gelöst: Brute Force Angriff

Hallo User,

lt. Protokoll fand mal wieder ein Brute-Force-Angriff auf meine NC statt. Das Protokoll meldet ca. 50 mal:

[geoblocker] Warnung: The user "xxxxxxxx" attempt to login with IP address "100.74.113.192" from blocked country "AA". No reaction is activated.

Mein Geoblocker hat dies erkannt und reagiert. Zeitlich war der Angriff vor 7 Stunden. Mich bewegen zwei Fragen:

  1. Warum hat fail2ban nicht reagiert? In den Logdateien zu fail2ban ist nichts zu finden.
  2. Das “xxxxxx” ist mein Username, welcher erst seit 14 Tagen existiert. Wie ist man an diesen neuen Benutzernamen gekommen?

Vor einem Monat hatte ich schon mal einen Angriff mit meinem damaligen Benutzernamen. Darauf hin habe ich den Anmeldenamen umstÀndlich geÀndert und den alten gelöscht. Gleichzeitig habe ich 2FA aktiviert, was mich jetzt nach der erneuten Aktion relativ entspannt lÀsst. Die IP werde ich in ufw noch blocken. Ich denke, mehr kann ich nicht machen. Oder?

Thomas

Hast du ein Fail2ban Jail fĂŒr Nextcloud eingerichtet? StandardmĂ€ssig reagiert es nur auf SSH.

100.74.113.192 ist eine private IP Adresse im 100.64.0.0/10 Adressraum. Das ist ein “Shared Address Space”, aus dem dein Provider deinem Inetrnetanschluss eine IP zuwesen kann, wenn er CGNAT (Carrier Grade NAT) nutzt.

https://de.wikipedia.org/wiki/Carrier-grade_NAT

https://www.rfc-editor.org/rfc/rfc6598

Ich tippe jetzt einfach mal so ins Blaue, dass das ein GerÀt in deinem Netzwerk war, welches via NAT Loopback auf deine Nextcloud zugreift, und noch ein altes Passwort gespeichert hat.

1 Like

Hallo @bb77,
Du wirfst da ein interessantes Thema auf, das kannte ich noch nicht. Meine NC steht in einem lokalen LAN hinter einer FB mit fester WAN IP und Domainname. Kann es sich trotzdem um eine Shared-Address von unserem Provider handeln?
Zu der angegebenen Zeit war ich an dem Standort im lokalen LAN mit meinem Handy (Android). Da laufen Apps wie NC, DAV5x, Talk usw., zu dieser Zeit aber ohne AuffÀlligkeiten.

Ich kontaktiere im Anschluss mal den Provider zu diesem Effekt und melde mich dann wieder.

Eine Frage aber noch zu fail2ban. Im NCP Dashboard ist fail2ban aktiviert, sollte also funktionieren. Mich macht der Hinweis nur etwas stutzig, da ich mich ĂŒber SSH schon hĂ€ufig mal 10 min ausgeschlossen habe und frĂŒher auch Mails erhalten habe, wenn NC eine IP gebannt hat. Mails habe ich lange nicht mehr erhalten.

Bis gleich.

Hmm. Wenn du eine fixe öffentlich IP Adresse hast, dĂŒrftest du eigentlich keine Zugriffe von IPs in diesem Range haben bzw. mĂŒsste der Zugriff aus diesem Bereich kommen
 Denn soviel ich weiss, sind IPs aus diesem Range nicht öffentlich routbar. Ähnlich wie die privaten IP Adressbereiche in Heim- und Firmennetzen, wie z.B. der Range 192.168.0.0/16.

Leider habe ich aber auch keine schlĂŒssige Antwort darauf
 Bin kein Experte wenn es um CGNAT geht, und ĂŒbersehe vielleicht etwas, oder der RFC6598 Bereich wird auch noch fĂŒr andere Dinge als CGNAT genutzt!?

Den ISP zu kontaktieren, ist aber sicher mal eine gute Idee
 :slight_smile:

Hallo @bb77,
ich hatte ein sehr nettes und informatives GesprÀch mit meinem Provider. Die IP gehört dem Provider und war zum angegebenen Zeitpunkt einem anderen Endpunkt hier im Ort zugeordnet. Wie es der Zufall so will, war ich auch dort im Gast-WLAN aktiv und wollte via VPN auf mein LAN zugreifen, ging aber nicht. Jetzt wird es spannend: Die IP (AA Country-Kennung) gehört zur Insel Aruba vor Venezuela. Aruba ist eines der vier konstituierenden LÀnder, die das Königreich der Niederlande bilden.
Mein Geo-Blocker hat neben DE nur noch PT freigegeben. Jetzt fragt man sich, warum die IP aus Aruba in der RIR-DB der NC nicht zu DE gehört, wenn diese doch hier vom Provider vergeben wird. Mein Provider ist frĂŒher sehr schnell gewachsen und hatte plötzlich keine öffentlichen IPs mehr. Man kaufte ua aus RumĂ€nien IPs anderer Provider, darunter auch die 100.74


Am Montag bin ich wieder in dem Gast-WLAN und stelle dies nach.

Lösung: Ich muss dann wahrscheinlich die Niederlande noch freigeben.

Was es nicht alles gibt.

Thomas

1 Like

Nunmehr habe ich fail2ban auch mal mittels falscher Kennworteingabe getestet und wurde dann korrekt nach 3 falschen Eingaben ausgeschlossen. fail2ban funktioniert also aus der NC heraus. FrĂŒher habe ich diesbezĂŒglich aber eine Mail erhalten, nun nicht mehr. Dies wird daran liegen, dass ich frĂŒher sendmail und jetzt postfix verwende. Den Grund zu postfix zu wechseln, kann ich Dir gar nicht mehr sagen. Aber damit sind mir die Mails vom Linux-System verloren gegangen. Aus der NC heraus kommt alles korrekt an. Da muss ich mal recherchieren. @bb77 hast Du mich einen Ansatzpunkt?

Spontan fÀllt mir folgendes ein:

Fail2ban hat standardmÀssig sendmail als Mail Transfer Agent konfiguriert. Wenn du Postfix nutzt musst du das umkonfigurieren.

Entweder direkt in der /etc/fail2ban/jail.conf die Zeile


mta = sendmail

abÀndern auf:

mta = mail

oder falls du eine eigene Config unter /etc/fail2ban/jail.d nutzt, die Zeile am besten dort eintragen / hinzufĂŒgen.

1 Like

Danke @bb77, der Eintrag mta steht bei mir in der jail.conf.dpkg-dist. Nach der Änderung habe ich einen restart von fail2ban durchgefĂŒhrt und mich 3 x falsch eingeloggt. Bin gesperrt, jedoch ein Mail kommt immer noch nicht. In der Zeit könnte auch eine Änderung im SMTP mit hereingefallen sein. Jedenfalls musste ich den SMTP in der NC direkt Ă€ndern. Welche .conf ist dafĂŒr zustĂ€ndig. In der /etc/mail.rc steht auch noch set sendmail="/usr/bin/msmtp -t".

Heute ist hier noch Familientreffen, da komme ich zu nichts, frĂŒhestens am Sonntagnachmittag.

Thomas

DieseDatei wurde bei einem Update erzeugt, da die Originaldatei jail.conf durch Dich verÀndert worden war.

Sichere die jail.conf, trage Deine Änderungen in jail.conf.dpkg-dist ein und benenne sie in jail.conf um. Nach einem fail2ban-Neustart sollte die Mailfuntion wieder laufen. - PrĂŒfe dabei auch die /var/log/mail.log und /var/log/fail2ban.log

Nach Umstellung auf die “neue” jail.conf erhalte ich auch noch keine Mails. Die fail2ban.conf ist unauffĂ€llig. Allerdings meldet der postfix/smtp einem Fehler mit dem NEMESIS ESMTP Service. Es handelt sich wohl um die Ablehnung der Mail. GMX/Web.de vermuten SPAM.

Komisch nur, aus der NC heraus ist das kein Problem. Kann man einen anderen SMTP Server fĂŒr das System verwenden und wo?

Verwendest du den ĂŒberhaupt, respektive authentifiziert sich dein lokaler Postfix am SMTP von GMX, oder schickt er die Mails einfach direkt an deine GMX Adresse. Wenn letzteres der Fall ist, wĂŒrde ich erwarten, dass GMX die Mails ablehnt.

Anbei habe ich mal meine Doku reinkopiert. Evtl hilft dir die ja weiter. Mit dieser Konfig werden alle Mails, die an root, deinen Benutzer und an www-data gesendet werden, ĂŒber einen externen SMTP Server versendet / weitergeleitet. (Der interessante Teil startet ab Kapitel 3)

Update Benachrichtigungen Ubuntu Server (Postfix)

1. Apticron und Postfix installieren

apt install apticron
apt install postfix
apt install libsasl2-modules

2. Apticron konfigurieren

Die Standard Konfigurationsdatei erstellen:

cp /usr/lib/apticron/apticron.conf /etc/apticron

Die Datei öffnen


nano /etc/apticron/apticron.conf


und anpassen:

EMAIL="root"
SYSTEM=$(/bin/hostname -f)
NOTIFY_NO_UPDATES="1"

Den Cronjob anpassen:

nano /etc/cron.d/apticron

3. Postfix konfigurieren

Die originale Konfigurationsdatei umbenennen:

mv /etc/postfix/main.cf /etc/postfix/main.cf.bak

Eine neue Konfigurationsdatei anlegen


nano /etc/postfix/main.cf


und folgendes einfĂŒgen:

# See /usr/share/postfix/main.cf.dist for a commented, more complete version

# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no

# appending .domain is the MUA's job.  
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

myhostname = hostname.domain.tld
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydestination = hostname.domain.tld
mynetworks = 127.0.0.0/8
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = loopback-only
inet_protocols = ipv4

##########################################
##### non debconf entries start here #####

##### client TLS parameters #####
smtp_tls_loglevel=1
smtp_tls_security_level=encrypt
smtp_sasl_auth_enable=yes
smtp_sasl_password_maps=hash:/etc/postfix/sasl/passwd
smtp_sasl_security_options = noanonymous

##### map jane@localhost to jane.doe@gmail.com #####
smtp_generic_maps=hash:/etc/postfix/generic

relayhost=[smtp.example.tld]:587

SASL Credentials File anlegen


nano /etc/postfix/sasl/passwd


und folgendes eintragen:

[smtp.example.tld]:587 username:password

Postfix lookup table generieren:

postmap /etc/postfix/sasl/passwd

SASL Datei Berechtigungen einschrÀnken:

chown -R root:postfix /etc/postfix/sasl
chmod 750 /etc/postfix/sasl
chmod 640 /etc/postfix/sasl/passwd*

Damit der SMTP Relay Server die Mails nicht ablehnt, muss die Absenderadresse der Mails auf die Absenderadresse des Mail Kontos auf dem Relay Server umgeschrieben werden.

Dazu mĂŒssen in der Datei


nano /etc/postfix/generic


folgende EintrÀge vorgenomen werden:

root@hostname.domain.tld absenderadresse@example.tld
user@hostname.domain.tld absenderadresse@example.tld
www-data@hostname.domain.tld absenderadresse@example.tld

Mapping aktualisieren und Postfix neu starten:

postmap /etc/postfix/generic
systemctl restart postfix

4. (System-)Mails an root oder andere lokale Systembenutzer umleiten an externe Mailadresse.

Die Datei /etc/aliases öffnen


nano /etc/aliases


und folgendes hinzufĂŒgen:

root: empfÀngeradresse@example.tld
user: empfÀngeradresse@example.tld
www-data: empfÀngeradresse@example.tld

Die neuen EintrÀge aktivieren:

newaliases

Den Postfix Service neu starten:

systemctl restart postfix

5. Test und Problembehandlung

Testmail senden:

echo "Test to root." | mail -s "Test message to root" root
echo "This is a test." | mail -s "test message" email@example.tld

Mail Log ĂŒberprĂŒfen:

tail -f /var/log/mail.log

Links:

https://devops.ionos.com/tutorials/configure-a-postfix-relay-through-gmail-on-ubuntu/

https://www.lunanode.com/guides/postfix_smtp_secure

Vielen Dank @bb77, das wird mir weiter helfen. :grin:Morgen arbeite ich Deine Zeilen ein und melde mich.

Ich schicke alles zu einem SMTP, es Ă€ndert sich nur mal ĂŒber Jahre der Provider. Heute habe ich bei Host Europe eine neue Mailadresse angelegt und werde morgen alles umstellen. Mit Host Europe hatte ich bisher nie Probleme diesbezĂŒglich.

Bis morgen. :wave:

Thomas

Hallo @bb77,

ich habe so weit alle Deine Punkte ab 3. abgearbeitet bzw. die Änderungen/Anpassungen vorgenommen. Du hast alles sehr gut dokumentiert! Danke. :smiley:
Nach dem systemctl restart postfix trafen auch gleich mehrere alte Mails ein, darunter auch von fail2ban.

Den Test nach 5. wollte ich auch abschließend durchfĂŒhren, erhalte aber hier einen Fehler:

echo "Test to root." | mail -s "Test message to root" root
mail: Senden der Daten an /usr/bin/msmtp -t fehlgeschlagen: Kann nicht ausgefĂŒhrt werden
mail: Nachricht kann nicht gesendet werden: Kann nicht ausgefĂŒhrt werden

In der mail.log ist kein Eintrag dazu zu finden. :cry:

msmtp ist ein SMTP Client, den du ebenfalls nutzen könntest um Mails zu versenden. Hast du den allenfalls irgendwann mal installiert? Falls ja kannst du den deinstallieren.

sudo apt purge msmtp

Danach wĂŒrde ich noch die /etc/mail.rc ĂŒberprĂŒfen und falls noch vorhanden, die Zeile set sendmail="/usr/bin/msmtp -t" löschen.

Den SMTP Client msmtp hatte ich auch mal in Nutzung, ist schon lÀnger her. Ich habe die Pakete entfernt und die Zeile sendmail.... aus der mail.rc gelöscht. Die mail.rc ist nun total leer.

Der Testversand lÀuft jetzt ohne Ausgabe von Fehlern, kommt aber nicht an. In der mail.log kommen nun Meldungen:

> Feb  6 20:02:00 nextcloudpi postfix/pickup[707315]: 8267C200C8: uid=0 from=<root@nextcloudpi>
> Feb  6 20:02:00 nextcloudpi postfix/cleanup[707381]: 8267C200C8: message-id=<20230206190200.8267C200C8@raspberrypi>
> Feb  6 20:02:00 nextcloudpi postfix/qmgr[707316]: 8267C200C8: from=<root@nextcloudpi>, size=344, nrcpt=1 (queue active)
> Feb  6 20:02:01 nextcloudpi postfix/smtp[707383]: Untrusted TLS connection established to [mein SMTP]:587: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
> Feb  6 20:02:01 nextcloudpi postfix/smtp[707383]: 8267C200C8: to=<root@nextcloudpi>, relay=[mein SMTP]:587, delay=1, delays=0.02/0/0.93/0.1, dsn=2.0.0, status=sent (250 OK id=1pP6kb-0005gS-G7)
> Feb  6 20:02:01 nextcloudpi postfix/qmgr[707316]: 8267C200C8: removed

Aus der NC heraus ist der Mailversand ok, auch fail2ban. Steht noch die Frage nach der Antwort zu: Warum kommt root nicht an?

Der Moderator hat den Thread gelöscht. Wollen wir einen neuen eröffnen?

@dtb
Ich habe deinen Beitrag nur grob ĂŒberlesen und möchte an dieser Stelle noch mal eine kurze grundlegende Diskussion bzgl. der Sicherheit deiner Nextcloud anfĂŒhren. Hierbei möchte ich zwei Möglichkeiten gegenĂŒberstellen:

Sperrung von Nextcloud-Accounts z. B. nach drei falschen Passwörtern
Der Account wird gesperrt, wenn der Benutzer (oder der Angreifer) sich mit drei falschen Passwörtern versucht anzumelden. Da ist deine Konfiguration.

Verwendung von 2FA
Neben dem normalen Passwort wird ein zweiter Faktor z. B. eine 6-stelligen PIN per Google Authenticator benötigt.

Vergleich
Leider unterliegst du einem Irrglauben, wenn du glaubst, dass die Sperre der Benutzerkennungen nach drei (oder auch mehr) Fehlversuchen einen signifikaten Sicherheitsgewinn bringt. Es ist einfach falsch anzunehmen, dass ein Angreifer irgendwelche Passwörter ausprobiert. Bei einer geringen PasswortqualitĂ€t (z. B.nur 8 Buchstaben oder Zahlen = 36^8 = 2.821.109.907.456‬) ist es vollkommen absurd anzunehmen, dass man mit einer geringen Anzahl (3, 300, 3000) von Versuchen ein Passwort errĂ€t. Das passiert einfach nie. Ich kann die Hacker der Welt bis hier ĂŒber diese NaivitĂ€t der Pseudo-Administratoren nur lachen hören.

Angriffe funktionieren ganz anders. Passwörter werden z. B. per Malware bzw. Keylogger mitgelesen und werden bereits beim ersten Versuch korrekt verwendet. Auch werden SicherheitslĂŒcken auf Servern genutzt. Nur wenn du 2FA verwendest, kannst du effektiv (bestimmt auch nicht immer) deine Accounts schĂŒtzen, da neben dem mitgelesenen Passwort ein zweiter Faktor wie z. B. Google Authenticator auf dem Smartphone benötigt wird. Auch kannst du deine Nextcloud selbst hĂ€rten, wozu natĂŒrlich auch immer das Einspielen der neusten Sicherheitspatches gehört.

https://docs.nextcloud.com/server/latest/admin_manual/installation/harden_server.html

Benutzersperren nach einer gewissen Anzahl Fehlversuche gehören meiner Meinung nach nicht dazu. Sinnvoll ist es maximal IP-Subnetze zu sperren, welches aber dann gegen DoS-Angriffe und nicht gegen irgendwelches sinnloses Ausprobieren von Passwörtern schĂŒtzt.

@dtb Ich bin nicht sicher ob die die “Untrusted TLS Verbindung” wirklich das Problem ist, denn die Verbindung scheint gemĂ€ss Log ja zustande zu kommen
 Um den “Fehler” wegzukriegen, könntest du aber in der /etc/postfix/main.cf mal die folgenden beiden Zeilen auskommentieren


#smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
#smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key


und dafĂŒr die folgenden beiden Zeilen hinzufĂŒgen:

smtp_tls_CApath = /etc/ssl/certs
smtpd_tls_CApath = /etc/ssl/certs

Danch den postfix service neustarten.

@devnull
Ich finde nicht dass man 2FA und “Brutforce Protection” wie die Sperrung von Nextcloud-Accounts z. B. nach drei falschen Passwörtern, einander gegenĂŒberstellen muss. Man kann problemlos beides nutzen. Ob es dafĂŒr Fail2ban wirklich braucht, oder ob es nicht genĂŒgt einfach die eingebaute “Bruteforce Protection” der Nextcloud zu verwenden, wĂ€re dann nochmal eine separate Diskussion.

1 Like

ErgÀnzung:

Meiner Meinung nach scheint eher dieser Log Eintrag das Problem zu sein:

Dort mĂŒsste meiner Meinung nach die EmpfĂ€ngeradresse anstatt root@nextcloudpi stehen.

Hast du Punkt 4 meiner Anleitung durchgefĂŒhrt und via dem Befehl newaliases eingelesen? Poste sonst mal den Inhalt der Datei /etc/aliases, wenn du unsicher bist, ob alles korrekt ist


Hallo @devnull,
ich denke, wir sind beide nahezu der gleichen Meinung. Fail2ban gibt mir zwar ein besseres GefĂŒhl an Sicherheit, wird aber in der Nutzung bei mir mehr zur Kontrolle der realen User-Zugriffe mit falschem Account verwendet. Seit 2 Wochen ist auch 2FA aktiv und lĂ€uft nach den vielen Umstellungen auf den NBs und Smartphons unauffĂ€liig, also sehr gut. MIt goaccess protokolliere ich nach hĂ€ufigen Anfragen, aktuell aus Asien und der Russischen Föderation. Kommen IPs verhĂ€uft, trage ich diese bei ufw ein. Parallel habe ich mir noch ein System fĂŒr die Admin SSH-Zugriffe mit unterschiedlichen SchlĂŒsselpaaren auf verschiedenen Systemen im LAN und WAN erarbeitet und umgesetzt.

Mit allen diesen Prozessen denke ich in puncto Sicherheit gut aufgestellt zu sein.

Ein letzter Punkt ist noch postfix einzurichten. @bb77 ich sende Dir gleich meine Daten dazu.

1 Like

Guten Morgen @bb77, aus Deinen letzten Posts habe ich die mail.cf entsprechend geĂ€ndert und eine Testmal “versucht” zu senden. Hier der Auszug aus dem Log:

> root@nextcloudpi:/home/pi# echo "Test to root." | mail -s "Test message to root" root
> root@nextcloudpi:/home/pi# tail -f /var/log/mail.log
> Feb  7 09:23:44 nextcloudpi postfix/pickup[785611]: EE129200C8: uid=0 from=<root@nextcloudpi>
> Feb  7 09:23:44 nextcloudpi postfix/cleanup[785620]: EE129200C8: message-id=<20230207082344.EE129200C8@raspberrypi>
> Feb  7 09:23:45 nextcloudpi postfix/qmgr[785612]: EE129200C8: from=<root@nextcloudpi>, size=344, nrcpt=1 (queue active)
> Feb  7 09:23:45 nextcloudpi postfix/tlsmgr[785623]: warning: request to update table btree:/var/spool/postfix/smtpd_scache in non-postfix directory /var/spool/postfix
> Feb  7 09:23:45 nextcloudpi postfix/tlsmgr[785623]: warning: redirecting the request to postfix-owned data_directory /var/lib/postfix
> Feb  7 09:23:45 nextcloudpi postfix/tlsmgr[785623]: warning: request to update table btree:/var/spool/postfix/smtp_scache in non-postfix directory /var/spool/postfix
> Feb  7 09:23:45 nextcloudpi postfix/tlsmgr[785623]: warning: redirecting the request to postfix-owned data_directory /var/lib/postfix
> Feb  7 09:23:45 nextcloudpi postfix/smtp[785622]: Trusted TLS connection established to [mein SMTP]:587: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
> Feb  7 09:23:45 nextcloudpi postfix/smtp[785622]: EE129200C8: to=<root@nextcloudpi>, relay=[mein SMTP]:587, delay=0.67, delays=0.06/0.06/0.46/0.09, dsn=2.0.0, status=sent (250 OK id=1pPJGT-00023a-Hw)
> Feb  7 09:23:45 nextcloudpi postfix/qmgr[785612]: EE129200C8: removed

Aus der NC heraus nutze ich den gleichen SMTP mit STARTTLS, ohne AuffĂ€lligkeiten. Prinzipiell habe ich 2 Mailadressen fĂŒr den Empfang. Ich kann eine Mailadresse vom Provider mit dem SMTP (HostEurope) verwenden oder eine von einem anderen Provider. Das denke ich macht aber keinen Unterschied.

Hier die /etc/aliases:

postmaster: root
root: [meine Mailadresse beim SMTP Provider]
default: [meine Mailadresse beim SMTP Provider]

Die Adresse root@nextcloudpi stammt sicherlich aus der main.cf oder generic, denn nextcloudpi ist der Hostname vom System.

# See /usr/share/postfix/main.cf.dist for a commented, more complete version

# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

# TLS parameters
#smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
#smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtp_tls_CApath = /etc/ssl/certs
smtpd_tls_CApath = /etc/ssl/certs
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

myhostname = raspberrypi
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydestination = [meine Domain].de
mynetworks = 127.0.0.0/8
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = loopback-only
inet_protocols = ipv4

##########################################
##### non debconf entries start here #####

##### client TLS parameters #####
smtp_tls_loglevel=1
smtp_tls_security_level=encrypt
smtp_sasl_auth_enable=yes
smtp_sasl_password_maps=hash:/etc/postfix/sasl/passwd
smtp_sasl_security_options = noanonymous

##### map jane@localhost to jane.doe@gmail.com #####
smtp_generic_maps=hash:/etc/postfix/generic

Hier die generic:

root@[meine Domain].de [meine externe Mailadresse, nicht vom SMTP Provider]
pi@[meine Domain].de [meine externe Mailadresse, nicht vom SMTP Provider]

Die EmpfĂ€ngeradresse aus dem Log root@nextcloudpi scheint definitiv nicht zu stimmen. Bevor ich selbstĂ€ndig Änderungen vornehmen, warte ich lieber auf Deine Hinweise.

Danke.