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.
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…
@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.
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.
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.
Ich sehe keinen Relayhost in deiner main.cf: (bei mir ganz am schluss der config)
Wichtig: Formatierung beachten (eckige Klammern).
relayhost=[smtp.example.tld]:587
In generic legst du die Absenderadresse fest bzw. schreibst sie von root@raspberrypi auf die Adresse des Emailkonts auf dem Relay Host / SMTP Server um, den du für den Versand verwendest. Ansonsten kann es sein, dass der SMTP Server die Mails ablehnt.
Beispiel:
root@nextcloudpi absenderadresse@example.tld
In der /etc/aliases definierst du wohin Emails weitergeleitet werden sollen, die von irgendwelchen lokalen Diensten an root oder andere User auf deinem System gesendet werden. Das ist optional. Konfigurierst du es nicht, musst du in den Config Files eines jeden Dienstes, der Benachrichtigungen verschicken soll, (z.B. der Fail2ban config oder apticron etc…) den Empfänger von z.B. “root” auf die Emailadresse umkonfigurieren, an die du die Benachrichtigungen senden willst. Vergisst du das irgendwo, werden die Mails an die lokale Inbox des entsprechenden Users zugestellt, und verlassen somit deinen Server nie.
Wenn die Absender- und Empfängeradresse identisch sind, weil du z.B. dein reguläres Emailkonto für den Versand und den Empfang benutzt, trägst du in der /etc/postfix/generic und in der /etc/aliases die selbe Emailadresse ein.
@bb77 , ich habe die Änderungen an der generic vorgenommen und die aliases modifiziert. In der generic steht jetzt root@nextcloudpi meine_SMTP_Versandmailadresse.
und in der aliases root: meine_externe_Zielmailadresse. Das sollte passen. Oder?
Die Log:
tail -f /var/log/mail.log
Feb 7 11:40:27 nextcloudpi postfix/tlsmgr[797040]: warning: redirecting the request to postfix-owned data_directory /var/lib/postfix
Feb 7 11:40:27 nextcloudpi postfix/smtp[797039]: Trusted TLS connection established to SMTP_Server: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 11:40:27 nextcloudpi postfix/smtp[797039]: EFA78200C9: to=<root@nextcloudpi>, relay=SMTP_Server:587, delay=0.58, delays=0.05/0.06/0.4/0.07, dsn=5.0.0, status=bounced (host SMTP_Server said: 550 relay not permitted (in reply to RCPT TO command))
Feb 7 11:40:27 nextcloudpi postfix/cleanup[797037]: 8C440200CA: message-id=<20230207104027.8C440200CA@nextcloudpi>
Feb 7 11:40:27 nextcloudpi postfix/bounce[797041]: EFA78200C9: sender non-delivery notification: 8C440200CA
Feb 7 11:40:27 nextcloudpi postfix/qmgr[797029]: 8C440200CA: from=<>, size=2189, nrcpt=1 (queue active)
Feb 7 11:40:27 nextcloudpi postfix/qmgr[797029]: EFA78200C9: removed
Feb 7 11:40:27 nextcloudpi postfix/smtp[797039]: Trusted TLS connection established to wp13564981.mailout.server-he.de[80.237.130.118]: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 11:40:27 nextcloudpi postfix/smtp[797039]: 8C440200CA: to=<root@nextcloudpi>, relay=SMTP_Server:587, delay=0.38, delays=0.01/0/0.33/0.04, dsn=5.0.0, status=bounced (host SMTP_Server said: 550 relay not permitted (in reply to RCPT TO command))
Feb 7 11:40:27 nextcloudpi postfix/qmgr[797029]: 8C440200CA: removed
Leider immer noch "to=root@nextcloudpi im Log. Als ob er die generic bzw. aliases nicht nutzt. Im Log steht auch TLS, mein Provider favorisiert STARTTLS und dies ist auch in der NC eingetragen.
@bb77 , ja newaliases und systemctl restart postfix habe ich mehrfach durchgeführt. Das wundert mich halt auch. Bin gerade unterwegs und habe nur Handy.
Einen Fortschritt kann ich verzeichnen. Im Log steht nun die korrekte to=mailadresse. Allerdings findet man dann auch vom SMTP said: 550 relay not permitted
tail -f /var/log/mail.log
Feb 7 16:49:31 nextcloudpi postfix/bounce[12833]: 854C720241: sender non-delivery notification: 0EC64202E6
Feb 7 16:49:31 nextcloudpi postfix/qmgr[12807]: 0EC64202E6: from=<>, size=2360, nrcpt=1 (queue active)
Feb 7 16:49:31 nextcloudpi postfix/qmgr[12807]: 854C720241: removed
Feb 7 16:49:31 nextcloudpi postfix/cleanup[12829]: 1199620241: message-id=<20230207154931.0EC64202E6@nextcloudpi>
Feb 7 16:49:31 nextcloudpi postfix/local[12831]: 0EC64202E6: to=<root@nextcloudpi>, relay=local, delay=0.02, delays=0.01/0/0/0.01, dsn=2.0.0, status=sent (forwarded as 1199620241)
Feb 7 16:49:31 nextcloudpi postfix/qmgr[12807]: 1199620241: from=<>, size=2483, nrcpt=1 (queue active)
Feb 7 16:49:31 nextcloudpi postfix/qmgr[12807]: 0EC64202E6: removed
Feb 7 16:49:31 nextcloudpi postfix/smtp[12832]: Trusted TLS connection established to SMTP[xx.xxx.xxx.xxx]: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 16:49:31 nextcloudpi postfix/smtp[12832]: 1199620241: to=<meine_korrrekte_Empfängeradresse>, orig_to=<root@nextcloudpi>, relay=SMTP[xx.xxx.xxx.xxx]:587, delay=0.46, delays=0.01/0/0.37/0.07, dsn=5.0.0, status=bounced (host SMTP[xx.xxx.xxx.xxx] said: 550 relay not permitted (in reply to RCPT TO command))
Feb 7 16:49:31 nextcloudpi postfix/qmgr[12807]: 1199620241: removed
Warum nimmt der Server die Mail nicht an? Aus der Nextcloud heraus nutze ich dieselben Einstellungen bis auf STARTLS.
Kann es noch am Zertifikat liegen. Unter dem Link findet man Hinweise dazu.
Denke ich eher nicht. Die Verbindung kann ja aufgebaut werden.
Für mich sieht es eher so aus, als würde sich Postfix nicht am sendenden Mailserver authentfizieren, bevor es die Mail abschickt. Hast du die folgenden Schritte ausgeführt, als du Postfix eingerichtet hast?
In diesem Zusammenhang habe mit einer kurzen Google Suche auch noch diesen Thread auf Serverfault gefunden, und darin scheint mir vorallem diese Antwort interessant zu sein, welche nicht als Lösung markiert ist.
Da fehlt meiner Meinung nach die Absender bei “from=…”.
@bb77:
Sollte die Domain des Absenders nicht auch in “myorigin=…” der main.cf gelistet sein?
Setze ich die Absenderdomain auf die des Postfix-Servers könnte die Mail wegen Spoofing-Verdachts abgelehnt werden.
Hmm stimmt, daran habe ich gar nicht gedacht. Bei mir war der myorigin Eintrag nie nötig, damit es funktioniert, allerdings nutze ich überall die gleiche Domain, sprich die Domain des Nextcloud Servers und die Email Domain, über die gesendet wird, sind bei mir identisch…