Beiträge von NaN

Zitat von frank_m

Aber warum? Was will man darüber machen, um diesen Rückschluss zu unterbinden.

Zum einen wird der Dienst, der auf IPv4 läuft, höchstwahrscheinlich auch auf IPv6 laufen, zumindest wenn sowas wie HTTPS Dienste involviert sind. Dann ist es unwahrscheinlich, dass der Wireguard Dienst, von dem niemand zurückschließen soll, nur über die IP erreicht wird, d.h., ich brauche auch da sowas wie eine Domain. Nicht zuletzt: Mit dem Wireguard Tunnel bin ich auf dem Server. Und zwar unmittelbar drauf. Wenn die anderen Dienste so sensibel sind, sollte man niemanden über VPN einladen.

Spart euch doch mal diese ständigen Einwände der Art "Du machst das falsche, weil ich es anders machen würde".

HTTPS läuft auch nur mit IPv4. Wireguard braucht auf einem Host mit statischer IP keinen DNS-Namen. Wenig bekannte Tatsache: Der Kernel-Teil von Wireguard hat gar keine Möglichkeit, Namen aufzulösen. Das ist alles numerisch. Netfilter funktioniert auch auf dem Wireguard Interface. Es geht wahrscheinlich nicht darum, dass irgendwas sensibel ist. Warum der Bezug zwischen diesen Diensten nicht hergestellt werden soll, ist nicht wesentlich für die Frage.

Zitat von H6G

Ein Hostname ist nunmal öffentlich - ihn zu verstecken bringt keinen Sicherheitszugewinn (Security through Obscurity).

Am Ende kann ich auch den gesamten IPv4 Raum scannen und finde deinen Server genau so - dafür brauche ich keinen FQDN.

Nur aus Interesse: Wie stellst du die Verknüpfung zwischen einer IPv6 Adresse und einer IPv4 Adresse her? Was verrät dir, dass das nicht verschiedene Server sind? Es geht offenbar darum, dass die Nutzer des Wireguard-Tunnels nicht erfahren sollen, was auf dem selben Server über IPv4 läuft bzw. wessen Server das ist.

Ich würde den Server als Remote Desktop einsetzen, und zwar nur, damit eripek ihn nicht für die Elektrosensibelchen bekommt. Schaltet lieber euer Internet ab, ist gesünder für euch.

Ex-Twitter. Von mir aus auch Twitter-Exitus.

Generationenwechsel beim Heise-Verlag. Die anderen gehen mit dem Lockmittel "ernstzunehmender Journalismus" noch sparsamer um und waren eigentlich schon immer mehr Marktschreier als sonstwas.

Wenn man mehrere Accounts ("Email-Postfächer") einrichten kann, ist es häufig möglich, diese mit der selben Absenderadresse zu verwenden. SMTP-Benutzername und Absenderadresse können verschieden sein. Das geht z.B. bei Netcup, aber auch bei anderen Providern funktioniert das. Es war schon Thema im Forum, weil man damit Schabernack treiben kann. Mit einem eigenen Mailserver hast du natürlich mehr Kontrolle.

Zitat von mlohr

Wenn man aber die Mails nun, sagen wir, in begrenzem Umfeld, verschicken möchte (kleinerer Newsletter mit 100 Leuten, eben solche wie o.g. Notification-Mails)

Mit "Transaktions-Mails" (engl. transactional emails) sind gerade nicht Newsletter gemeint, sondern höchstens Bestätigungen von Newletter-Anmeldungen. Es sind Emails an einzelne Empfänger als direkte Reaktion auf bestimmte Transaktionen, keine Massenmails, auch wenn die Masse nur aus 100 Empfängern besteht.

Du kannst weder mit dem CNAME noch mit einem A-Record Ports angeben. HTTP(S) unterstützt dummerweise keine SRV-Records, sonst ginge das damit. Entweder wirst du den Port in die URL schreiben müssen oder du verwendest den Standardport 443. Eine Alternative könnte sein, einen Reverse Proxy aufzusetzen, aber dafür wäre ein VPS besser geeignet als ein Webhostingpaket.

Leite Port 443 in der Fritzbox auf den Webserver des Raspberry Pi weiter und schau, ob du per IP eine Verbindung von außen, z.B. vom Handy ohne WLAN, zum Webserver bekommst. Den Zertifikatsfehler ignorierst du erstmal. Bis das klappt, ist alles andere egal. Wenn du soweit gekommen bist, kannst du dir aussuchen, wie du deinen Domainnamen mit der IP-Adresse verknüpfst: Einfach über den CNAME mit dem funktionierenden MyFritz DynDNS oder mit dem eigenen DynDNS Skript. Wenn du dann von außen über deinen Domainnamen eine Verbindung mit deinem Pi Webserver bekommst, gibt es immer noch einen Zertifikatsfehler, und darum kümmerst du dich dann. Und wenn alles funktioniert und automatisiert ist, dann kannst du HSTS einschalten, keine Sekunde vorher.

Die DNS-Konstruktion mit dem CNAME war in Ordnung. Mach dir keine unnötigen Probleme, besonders nicht wenn andere sie lösen sollen.

Edit: Was verwirrt dich an der Antwort? Ich habe zweimal erklärt, dass der CNAME auf den MyFritz-DynDNS nicht dein Problem ist, aber du baust dir dein DynDNS trotzdem selbst und das liefert dir eine falsche Adresse. Deinem eigentlichen Ziel bringt dich das nicht näher, und das hätte es selbst dann nicht, wenn es funktioniert hätte.

Der DNS-Teil ist nicht das Problem und der Wechsel von CNAME+MyFritz einerseits zur "API-Lösung" andererseits ändert nichts an der Zertifikatssituation. Der Raspberry Pi braucht ein Zertifikat für die Domain, mit der er angesprochen werden soll. Zertifikate werden auf Domainnamen ausgestellt. Die IP-Adresse, und ob der Browser die über einen CNAME und einen A-Record oder direkt über einen A-Record erfährt, spielt für das Zertifikat keine Rolle. Du brauchst einen ACME-Client für den Raspberry Pi und beantragst darüber ein Zertifikat für deine Subdomain und installierst das in dem Server auf dem Raspberry Pi. Weil das Zertifikat spätestens nach drei Monaten erneuert werden muss, sollte der ganze Vorgang automatisch laufen, sonst wirst du die Erneuerung früher oder später vergessen.

Ich verstehe das so, dass nicht die Fritzbox das freigegebene Gerät ist. Wenn das Gerät einen ACME Client hat oder man einen installieren kann, dann wäre das die naheliegendste Möglichkeit. Der Name, auf den das Zertifikat ausgestellt werden muss, ist die Subdomain mit dem CNAME, nicht die MyFritz-Adresse. Der Browser erfährt gar nichts von der MyFritz-Adresse. Er löst die Subdomain auf und bekommt eine IP-Adresse. Deswegen ist es auch praktisch kein Unterschied, ob man das mit CNAME oder direkt per API mit A- oder AAAA-Record macht.

Wenn man es sich einfach machen möchte, kann man die Subdomain mit Zertifikat im Webspace einrichten, um von dort per HTTP-Redirect auf die MyFritz-Adresse weiterzuleiten, oder die MyFritz-Adresse als alleinigen Inhalt eines Frames im Webspace ablegen. Beides setzt aber voraus, dass der Aufruf der MyFritz-Adresse keinen Zertifikatsfehler produziert. Dazu muss das freigegebene Gerät ein Zertifikat z.B. von Letsencrypt für die MyFritz Adresse haben, kein selbstsigniertes. Die Fehlermeldung oben sieht so aus, als wäre das nicht der Fall. Wenn man sich darum noch kümmern muss, kann man es auch gleich mit der richtigen Domain machen.

Zitat von Valkyrie

die Google Captchas sind mir plötzlich neu

Das heißt, dass Google dich unter den anderen Clients in dem Adressbereich nicht wiedererkennen konnte. Wahrscheinlich bist du so ein Cookielöscher.

Der Apple iOS Mail Client verwendet nicht IMAP-IDLE sondern eine Apple-spezifische Extension, mit der der IMAP-Server den zentralen Apple Push Notification Service nutzen kann, um den Client zu benachrichtigen. Apple macht das, weil IMAP-IDLE ein schlimmes Protokoll ist und die iPhones nicht mit den vielen langlebigen TCP-Connections belastet werden sollen. Stattdessen soll eben nur die eine Push-Verbindung mit der iCloud bestehen und alles andere nur bei Bedarf passieren. Die Apple-spezifische Push Technik muss der Server untersützen, damit das funktioniert. Alternative Clients umgehen diese Voraussetzung teilweise, indem sie Server einsetzen, die im Auftrag des Clients IMAP-IDLE mit dem IMAP-Server machen und dann die Push-Notification in Richtung Client absetzen.

Zitat von RAD750

Hab Integrale komplett vergessen...

Macht nichts. Das Integral ist fast nur zur Verwirrung. Man muss kaum rechnen. Erklärung: Du kannst das aufteilen in eine Summe aus x³cos(x/2) mal die Wurzel und 1/2 mal die Wurzel. Die Wurzel ist spiegelsymmetrisch um die y-Achse. x³cos(x/2) ist punktsymmetrisch um den Nullpunkt, das heißt, dass sich die erste Hälfte des Integrals im Bereich von -2 bis 0 und im Bereich von 0 bis 2 aufhebt, also gleich 0 ist. Bleibt nur das Integral von 1/2*Wurzel. Die Wurzel beschreibt einen Halbkreis mit dem Radius 2. Das Integral ist also die Hälfte der Hälfte der Fläche eines solchen Kreises. Die Kreisfläche ist Pi mal Radius zum Quadrat. Also ist das Ergebnis 1/2*1/2*Pi*4=Pi. Schönes Restwochenende.

Zitat von aRaphael

"the first digits". Ja, aber wie viele davon?

8-64

Ob ein Webhostingpaket reicht, hängt von der Ursache des Fehlers ab. Die Fehlermeldung kommt vom Reverse Proxy Nginx, der fehlerhafte/zu große Header vom Webserver bekommt. Es kann sein, dass man das mit größeren Puffern lösen kann. Dafür bräuchtest du in der Tat einen eigenen Server, weil diese Einstellung nicht individuell konfigurierbar ist. Die Fehlermeldung kann auch von einem Fehler im Bereich des Webservers ausgelöst werden, und der Fehler in dem Bereich kann bei einem größeren Webhostingpaket oder einem eigenen Server mit mehr Ressourcen verschwinden oder nicht. Was du brauchst kommt darauf an, was dort schiefgeht. Wenn du dir sicher bist, dass es kein Fehler an sich ist sondern nur zu große Cookies, dann hilft nur ein Server.

Zitat von vonHabsi

so long as the email boxes and storage allocation are not exceeded

That's the limit, but note that there is also a rather low limit how many emails you can send per hour, so using a web hosting account for too many email accounts may not be a good idea after all.

Sie kommen nicht wieder sondern sind einfach dageblieben. Es stört mich nicht so sehr, dass ich Handlungsbedarf sehe. War nur eine Antwort auf die Frage, ob palminator93 mit dem Problem alleine ist.

Das "Problem" mit Resten von ehemaligen Domains in diversen Teilen der Konfigurationsmenüs habe ich auch. Es handelt sich um zwischenzeitlich aufgeschaltete Zusatzdomains (bei Netcup bestellte zusätzlich bezahlte Domains, nicht inklusive, nicht extern), die es nicht mehr gibt.

Zitat von m_ueberall

Grundsätzlich können sie das – oder besser gesagt ein Nutzer, welcher dort eindringt oder das Gerät dazu bringt, Befehle für ihn auszuführen – aber, selbst ohne Root-Rechte. Wie einfach das ist, wenn nur Zugriff auf eine Shell besteht, zeigt etwa dieses Script: How to send e-mail from bash. Das geht auch problemlos am eigenen Mail-Gateway vorbei

Mir ist bewusst, dass SMTP keine Accounts voraussetzt. Das hatte ich auch schon in Kommentar #3 erwähnt. Aber erstens ist es schwer, von der Position der IoT Geräte im Netz unangemeldet irgendeine Email erfolgreich auszuliefern. Zweitens ist das dann kein Problem für die Reputation des Mailservers, was es zu keinem Problem für Netcup macht, und das macht es zu einem wesentlich kleineren Problem für mich. Drittens, nicht ganz unwichtig, können die Geräte im Normalfall Mail nicht ohne Smarthost verschicken. Das heißt, wenn ich von denen Mail bekommen möchte, dann muss ich ihnen einen SMTP-Account geben, und da würde ich gerne einen nehmen, mit dem man nicht unangenehm auffallen kann.

Alles, was es dafür bräuchte, wäre ein Häkchen im Bereich Ausgangskontrolle "Mails an die eigene Adresse für die Ausgangskontrolle nicht als ausgehende Mail zählen" und die entsprechende Funktionalität.

Du lässt ja auch nicht alle Programme als root laufen, obwohl die das, was über die Rechte eines normalen Users hinausgeht, einfach sein lassen könnten. Meine Fritzbox, Wetterstation, Webcam, Waschmaschine, Staubsauber, Kühlschrank, UPS, Kontaktformular, etc. müssen halt nicht Mail an irgendjemanden als an mich schicken können. Also warum soll ich ihnen mehr Rechte geben als nötig, die im Fall, dass die Geräte/Programme nicht so sicher wie gedacht sind, missbraucht werden können? Einen Mailaccount, der nur an sich selbst Mail verschicken kann, könnte ich z.B. bedenkenlos auch da eintragen, wo ich nicht der einzige mit Zugang zur Konfiguration bin.