Das längste Thema

  • florian2833z Eventuell hat die Person einfach das zugewiesene /64-Prefix heraus kopiert und/oder zu wenig markiert beim Copy & Paste.


    Ich würde einfach einmal davon ausgehen, dass die Quelladresse innerhalb von 20a1:9b3c:6bb4:7284::/64 liegt.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • florian2833z Eventuell hat die Person einfach das zugewiesene /64-Prefix heraus kopiert und/oder zu wenig markiert beim Copy & Paste.


    Ich würde einfach einmal davon ausgehen, dass die Quelladresse innerhalb von 20a1:9b3c:6bb4:7284::/64 liegt.

    Hab soeben nochmal gefragt, ob nicht ein Fehler unterlaufen ist. Ging um dieses Thema hier:

    https://github.com/chromium/hs…65#issuecomment-442971996


    Danke übrigens für deine Antworten!


    Edit: Jup, jetzt habe ich die korrekte Adresse. Da ist tatsächlich was abgeschnitten worden.

  • Da die Person wollte, dass die Adresse nicht öffentlich irgendwo dasteht, hat sie sie mir per E-Mail geschrieben und ich habe für die Frage im Forum die Zahlen ein wenig verändert. Der Aufbau war jedoch exakt der selbe und das war auch meine Frage.

    Ich darf zusammenfassen:

    1. Die genannte Hexdezimalzahlengruppe ist, so, wie sie dasteht, keinesfalls eine valide IPv6-Adresse.

    2. Die Zeichenkette erweckt aber den Eindruck, ein Network-Prefix mit der Länge 64 Bit zu sein - also jener minimale Adressbereich, der einem Endkunden von einem Provider für die Nutzung von IPv6 jedenfalls zuzuteilen ist.

    3. Ob die Vermutung zutrifft, kannst Du eventuell mittels Whois-Abfrage feststellen. In Whois werden Netzwerk- und Domaindaten (letztere mehr oder weniger) öffentlich abrufbar gemacht. Am Beispiel von Netcup lautet dieser zugeteilte Prefix für meinen eigenen VPS zwar nicht auf meinen Namen, sondern den von Netcup, weil die Zuweisung von netcup wohl nur als temporär erachtet wird und der Aufwand zu groß wäre, aber whois nennt mir das, was eingetragen ist - hier ein verkürzter Auszug dessen:

    Dieselbe Methode sollte auch im Fall Deiner Frage Antworten zur Gültigkeit der Zuweisung des nächstgrößeren Providerblocks geben. Existiert der schon nicht, ist jedes weitere Nachforschen überflüssig.


    Die weitere Überprüfung mittels dig kann, muss aber keine Antworten geben. Ist ein PTR für die IPv6-Reverse-DNS-Zone "ip6.arpa" für die von Dir genannte Adresse eingetragen, so wirst Du eine Antwort erhalten, was wiederum indiziert, dass dieser Adressbereich oder einzelne Hostadressen tatsächlich verwendet werden.


    Ich bitte um Pardon, wenn ich nun weiter ausgeholt habe, als es Deine eigentliche Frage betraf. Es ist mir wichtig, Fragen auch so zu beantworten, dass der Fragesteller sich stets danach selbst zu helfen weiss, denn das ist es, was ich auch von Antworten erhoffe, die auf meine eigenen Fragen gegeben werden.


    Sorry: hab zu lange getippt, da war KB19 schneller.

  • ich hab anscheinend die Erkenntnis, welche man eigentlich nicht erwartet ...

    http://www.dnslytics.com

    sagt wenn man diese IPv6-Adr. als Prefix interpretiert und z.B. ::1 hinzufügt

    folgendes:


    Summary IP Address 20a1:9b3c:6bb4:7284::1 is a public IP address but at this moment it is not configured in the global routing table.


    und da würd es mich nicht wundern, wenn er Deinen vServer od. was auch immer per IPv6 nicht erreicht;


    egal welchen Hostanteil er auch verwendet, der gesamte /64-Prefix muss geroutet sein, so kann man zum Test

    einfach ::1 anhängen und ein Traceroute od. ähnl. probieren


    und sowas ist dann schon sehr aussagekräftig ...

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • Ein Kunde (seine Domain: example.org) von mir hat mir heute eine Delivery-Notification (wohl Backscatter on dem Fall) weitergeleitet mit den Worten: "Spammen wir rum?".

    Ich hab mir das angeschaut und es sieht so aus als ob eine uns unbekannte IP (62.153.0.0) im Namen eines nicht existenten Accounts der Domain (EHLO auch example.org) Mails versendet.

    Message-ID ist z.B. auch 12309A57.ABC7F1A2@example.org (der echte SMTP-Server vergibt aber Message-IDs nach einem anderen Schema)


    Ich verstehe aber auch die Kombi dieser ganzen Received-Header zugegebenermaßen nicht ganz...


    Ich hab ihm jetzt gesagt, dass er / ich da nichts aktiv dran ändern können, wenn jemand im Namen seiner Domain E-Mails versendet. Nur passiv, durch Einsatz von SPF und DMARC-Records, um die Erkennung beim Empfänger zu erhöhen. Weiterhin, dass der t-online server in diesem Fall gar keine Mail an ihn (gefälschter Absender) hätte schicken sollen (Backscatter).


    Kann mir jemand bestätigen, dass das so richtig ist? :D

  • Ich denke pauschal nicht, dass T-Online ein Backscatter ist.


    Bist du sicher das die Email von T-Online zurückkam? Man kann ja in den Header was beliebiges reinschreiben. Welche IP hat die Email denn abgeliefert?


    Ansonsten ist das pauschal korrekt so. Das kannst du quasi nur aussitzen und per SPF / DKIM abwehren.

    "Security is like an onion - the more you dig in the more you want to cry"

  • Also, was mir die Header sagen: Das Mail wurde über das QMQP (Quick Mail Queuing Protocol (QMQP) is a network protocol designed to share e-mail queues between several hosts. It was designed and implemented by Daniel J. Bernstein in qmail.)¹ (Zeile 9: [34.65.0.0] by smtp-server1.cfdenselr.TLD) entgegengenommen, der keinen Reverse-Eintrag für diese IP hat, an mx03.listsystemsf.TLD with QMQP übergeben (Zeile 8 und 7). Es fakt jemand Eure Absenderadresse. DKIM und SPF werden helfen.

  • Relevant ist nur, was der Mailserver vom Kunden in den Header geschrieben hat, um zu wissen, woher die Mail eingeliefert wurde. Allen anderen Received-Zeilen kann man im Zweifel nicht trauen. Aber darauf hat vmk eh schon hingewiesen.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Hat jemand mal ein Brecheisen? Ich bekomm das Türchen nicht auf.


    EDIT: Kaum sag ich es, schon wird es aufgeschlossen. Und direkt auch gleich gesichert. ?

    [WH 4000 SE Ost. 19] – [3x 2x VPS 200 G8] – [VPS 10 G7] – [RS M Xmas 15][WH Exp. Spezial 16]

    [Adv15 RS SL A+] – [Failover IPv6-Subnet Ost. 18] – [Cloud vLAN]

  • Nachdem ich nun den 200er zwei Mal habe, überlege ich meinen großen VPS abzustellen und meine Dienste in Mail und Web auf die zwei aufzuteilen. ? Sind eh nur Seiten und Postfächer für die Familie, wenn auch teils kleingewerblich, sollte aber dennoch reichen. ?

    [WH 4000 SE Ost. 19] – [3x 2x VPS 200 G8] – [VPS 10 G7] – [RS M Xmas 15][WH Exp. Spezial 16]

    [Adv15 RS SL A+] – [Failover IPv6-Subnet Ost. 18] – [Cloud vLAN]

  • Nachdem ich nun den 200er zwei Mal habe, überlege ich meinen großen VPS abzustellen und meine Dienste in Mail und Web auf die zwei aufzuteilen. ? Sind eh nur Seiten und Postfächer für die Familie, wenn auch teils kleingewerblich, sollte aber dennoch reichen. ?

    Shared Single vCore - leider relativ uninteressant für mich, weil das schon bei Amavis/Clamav nicht ganz die erhoffte Performance bringt. Als Storage VPS hat er zu wenig Plattenplatz, dafür ist die Platte zu schnell. Mir fehlt die Phantasie, wofür außer für Asterisk, für VPN oder DNS ich ihn einsetzen sollte. Das VPS Osterei 2018 hatte zwei Cores und nur halb soviel Speicher Euch bleiben mehr ;)


    H6G was machen die Wikinger? Alles in Ordnung?