Beiträge von MichaelOF

  • DNS für Domains in Virtual Server (VPS)

    Ich hatte mal ein evtl ., bin nicht ganz sicher, ähnliches Problem:

    Meine Situation:

    • Domain original über Netcup gekauft.
    • "Eigene Nameserver" auf Nicht-Netcup

    Alles OK


    Dann irgendwann Rückweg:

    • "Externe" Domain extern gelöscht
    • Domain wieder bei Netcup auf NC Nameserver gesetzt

    Musste AFAIR in dieser Reihenfolge geschehen, da das CCP eine Fehler warf, solange die Domain "drüben" noch aktiv war

    Im Ergebnis hatte ich dann die Situation, dass die Domain im CCP wieder als "ist hier, alles grün" aufschien, drüben als nicht mehr bekannt gezeigt wurde.

    Aber, und da ist meine vermutete Ähnlichkeit zu deinem Problem, die Domain unverändert bei der Registry als "drüben" eingetragen war.

    Und alle DNS Abfragen, dig etc., in die von dir auch beobachteten Timeouts liefen.

    Da das CCP ja sagte, "kann bis zu 48h dauern" hab ich da brav gewartet. Tat sich aber definitiv nichts, auch nach >48h


    In meinem Fall war es eine DE Domäne , also DENIC als Registry, kannst du so abfragen:

    Code
    dig @a.nic.de domain.de NS

    Verwies mit voller TTL etc. konstant auf "drüben"

    Ich vermutete, dass seitens NC ein Job, der die "Registrar ist wieder authorative" zur Registry publiziert, in meinem Fall hing/fehlschlug/....

    Und habe dann ein Support Ticket aufgemacht und innerhalb 24h das Problem gelöst bekommen.

    (Sarkasmus aus :))


    Ich habe dann folgendes versucht, erfolgreich:

    • Nochmals die Prozedur "externe Nameserver" diesmal aber Ziel Cloudflare, free tier/account
    • Warten bis dort, ging sehr schnell
    • (SOA Werte bei Cloudflare alle auf so kurz wie möglich gesetzt)
    • Rückübertragung zu NC

    War dann auch in Sekunden bei der DENIC propagiert, bestätigt für mich die vorige Vermutung "Job hing"


    Vielleicht hilfts dir...

  • Wie funktioniert der `login` API Aufruf mit den neuen tokens?

    Wenn du hier (wie ich für meine Domains, aber ohne Webhosting) "nur" den Link zur Legacy API siehst, dann musst du so wie ich es verstehe einfach warten, bis du auf CloudDNS umgestellt wirst. Geschieht für alle Kunden automatisch, sequentiell.

    Bis dahin ist aber die alte API vollständig verfügbar. Und Totes Pferd wäre es für mich nicht, ist ja nicht sooo kompliziert, es zu nutzen und irgendwann auf die neue API umzustellen.

  • Wie funktioniert der `login` API Aufruf mit den neuen tokens?

    Ich hab gerne versucht dir zu helfen ;)

    Kannst du evtl kurz definieren, welche API du genau nutzen möchtest? "... API für die Domains .." gibt es AFAIK mehrere, eine für Domain Reseller, eine für DNS Settings von Domains LEGACY, wenn die Domain neuer ist (CloudDNS) eine neue ...

    Welche Keys du wo benutzen musst, steht auf deinem Link.

    Und wenn du die CloudDNS API meinst - die ich weder kenne, nicht mal ihre BaseURL oder Endpoints, noch bisher selbst brauche - dann wäre ein Startpunkt sicher hier: Informationen zu Cloud DNS & API-Schnittstelle

  • Wie funktioniert der `login` API Aufruf mit den neuen tokens?

    Hallo,


    wenn du das neue REST API verwenden willst ist der Einstieg in die Doku hier: https://www.netcup.com/de/helpcenter/…server/rest-api

    Dort wird direkt erwähnt, dass der Authentifizierungsmechanismus im SCP zu finden ist
    Der relevante Link ist dieser https://www.servercontrolpanel.de/scp-ui/api/rest-docs#/

    Erst verfügbar nach Anmeldung, daher werde ich hier keine Details einfügen. Ist aber IMHO präzise beschrieben.


    Kleiner Hinweis, vielleicht war aber auch nur ich zu blöd es direkt zu finden:


    Wenn du über ein Smartphone auf die responsiven Seiten des SCP zugreifst, dann findet sich unter dem Hamburger Menü auch der Link API:

    1000004963.png


    Nachdem du den anwählst, landest du hier:

    1000004961.png


    Und das gesuchte Ziel "REST API Dokumentation" ist dann nochmals hinter dem Hamburger Menü "versteckt":

    1000004964.png

  • Ist es möglich seine Webseite "down" zu nehmen und nur für Mail zu nutzen?

    Zitat von ASS

    Das ist so nicht ganz richtig.

    Es kommt da nicht auf den Status des Betreibers an, sondern auf den Inhalt der Seite.

    Für eine Seite nur mit einem login Prompt braucht man definitiv kein Impressum. Auch wenn man ne Firma ist nicht...

    ASS Du widersprichst mir anscheinend gerne :D

    Doch, mein Satz "Impressumspflicht für Privatpersonen besteht nicht" ist nach allem was ich weiß (Digital Services Act EU, Umsetzung im DDD für D) genauso korrekt. Daher habe ich habe ich ja den Themenhersteller gefragt, ob er hier als Privatperson auftritt, nicht kommerziell.

    Dein Aspekt, dass ein kommerzieller Diensteanbieter evtl. AUCH Dienste in der Ausprägung "Website" anbieten kann, welche (auch) kein Impressum brauchen, mag so sein.

    Hat aber mit meinem Satz gar nichts zu tun, oder?

  • Das längste Thema

    Zitat von KB19

    Du gehst davon aus, dass nur netcup das Ziel ist. Wenn man aber die Daten aber sowieso schon abfragt, kann man sie gleich in mehrere ISP-Listen aufteilen und die anderen für spätere Aktionen aufheben. Dann relativiert sich der Aufwand, denn diese Listen kann man auch Jahre später noch verwenden. Auf ein paar False-Positives kommt es da auch nicht mehr an…

    Ich habe die Tage einen Satz Phishing Mails, etwas andere Machart aber gleicher Inhalt (Domain läuft ab, unbedingt schnell zahlen um zu verlängern) "gebrandet" auf einen früheren Hoster (von welchem ich zu Netcup wechselte) bekommen.

    Somit dürfte eure Vermutung LetsEncrypt-Logs als Quelle immer wahrscheinlicher sein.

  • Das längste Thema

    Zitat von KB19

    Du gehst davon aus, dass nur netcup das Ziel ist. Wenn man aber die Daten aber sowieso schon abfragt, kann man sie gleich in mehrere ISP-Listen aufteilen und die anderen für spätere Aktionen aufheben. Dann relativiert sich der Aufwand, denn diese Listen kann man auch Jahre später noch verwenden. Auf ein paar False-Positives kommt es da auch nicht mehr an…

    Na Servus, du hast aber viel mehr kriminelle Energie als ich ;) Auf jeden Fall hast du völlig recht, hab ich gar nicht dran gedacht. Jetzt drüber nachgedacht wird dann auch plausibel, dass die Landing Pages eher primitiv waren - ein paar Bilder ausgetauscht und schon "klappt" das genauso für andere Provider.

  • Das längste Thema

    Spannend.... CT, was neues gelernt... Danke!

    Aber IPs stehen das AFAI gesehen habe nicht drin - Somit erst einmal kein direkter Bezug zu netcup aus den CT Logs.

    Deiner/eurer CT Logs als initiale Quelle Vermutung folgend hieße dass, dass zuvor diese Logs durchgearbeitet worden sein müssten:

    1. Domain extrahieren - einfach

    2. zu dieser DNS Records abfragen:

    - wenn SOA auf netcup -> "Treffer"

    - wenn A/AAAA auf netcup -> "Treffer"

    Für alle möglichen Treffer aus 1 die DNS Records abfragen würde ich vermuten dauert wegen der schieren Menge sicher eine Weile.... Selbst wenn sie weil Ziel netcup evtl. "nur" eine TLD Teilmenge wie DE/AT/CH/EU/COM/ORG/NET etc. nehmen würden - andere Vorabeinschränkungen fallen wir erst einmal nicht ein.

    Also anscheinend doch eine Menge "Mühe" für diese Aktion, interessant.

  • Das längste Thema

    Ich habe mir gestern Abend mal den Spaß gemacht, im privaten Firefox Fenster (unter Linux) mit den WebDevTools die Ziele des Phishings etwas genauer anzusehen.

    Sieht nach den üblichen - angeblich via Darknet erwerbaren - "Wir basteln uns eine Phishing Site" Baukasten aus - sehr viel sehr ähnliches - unabhängig von netcup - im Umlauf aktuell.

    Die Links aller "netcup" Phishing Emails selbst gingen über diverse rein client-seitige Redirects (keine HTTP 301 o.ä. extern trackbar) zu einer Subdomain von artida.com (wo eine Wordpress Under Consctruction Site grüßt)

    Ziel also sowas wie http://01234567.artida.com/?id=example.com

    Ja, funktionierte tatsächlich mit example.com - der Query Parameter wird ohne Prüfung in die Maske "eingebaut".

    Diese ist eine mit mäßiger Mühe auf netcup "gebrandete" Seite, welche für die "Domainverlängerung" - Überraschung - Kreditkartendetails abfragt. Minimale Validierung, die ersten x Ziffern der Kartennummer scheinen gültig sein zu müssen - AFAIK definieren diese, ob VISA|MASTER|AMEX|... "1234..." werden also nicht akzeptiert. Gültig bis 07/99 auch nicht :)

    Ein Versuch mit Phantasiedaten und "Donald Duck" als Karteninhaber tat dann minutenlang nichts, außer in einer Schleife eine "Eieruhr" am laufen zu halten. Und teilte mir dann irgendwann mit, ich hätte jetzt eine 3D-Secure oder sowas Meldung auf meiner App bekommen. Welche ich doch bitte bestätigen soll. Danach geht die Maske irgendwann wieder in den Ausgangszustand zurück. Alles ohne weitere Interaktion.

    Also langweilig. So dass ich vermute, plattes Phishen von evtl. gültigen Kreditkartendaten. Sofern die Maske nicht doch bei "echter" Domain und "echten" Kartendaten was anderes tut ;)

    Ich hatte vermutet, dass es um was anderes gehen könnte. Da die Aktion ja doch - bei allen Ungenauigkeiten - recht präzise auf netcup Kunden zugeschnitten ist, habe ich vermutet, dass sie CCP Credentials abfangen wollen.... um Server etc. zu kapern.

    (Sarkasmus an) Davon hätten sie beim aktuellen Spammer's Heaven Netcup langfristig sicher mehr "Umsatz" gemacht. (Sarkasmus aus)

  • Das längste Thema

    Zitat von sla

    Andere Theorie für die aktuelle Spamwelle:

    ich nutze netcup nicht als Registrar, für absolut nichts (brauche funktionierendes DNSSEC). Meine Domains sind Registriert bei INYX und Nameserver bei INYX sowie der Wolkenfackel. Ich erhalte den Spam auch, die einzige Gemeinsamkeit aller Domains:

    A/AAAA Record zeigen auf einen netcup Server

    PTR einzeler Server enthalten die Domainnamen bzw. Subdomains.

    Riecht nach einem automatisierten PTR Lookup mit etwas Regex-Magic was den Subdomainteil wegschneidet und voilà: Spam-Liste erstellt. Dann noch RFC Adressen und übliche Verdächtige wie info@, postmaster@ etc. anhängen und ab geht die Lutzi

    Du warst acht Minuten schneller ;)

  • Das längste Thema

    My 5 cents...


    was ich bisher mitgelesen habe:

    Vom aktuellen Phishing betroffen sind:
    a) Webhosting Kunden, mit deren Domains
    b) VPS/RS Kunden, mit deren Domains
    c) "Domain-only" Kunden

    (c) sogar, wenn gar keine eigenen DNS Einträge existieren, korrekt? Somit nur der SOA Record


    Zur Gruppe (b) gehöre ich auch. Hier würde ich aus den "üblichen Erfahrungen" mit Port Scans, brute forcing etc. vermuten, dass hier spezifisch netcup Netzsegmente einfach gescriptet per z.B. nslookup <IPv4> "vorbereitend" durchgearbeitet wurden. Jeder VPS/RS Kunde mit PTR offenbart darüber zumindest eine seiner Domains. Und diese Segmente lassen sich über die netcup ASN einfach finden, kein Geheimnis.

    Würde mich, auf die Schnelle finde ich dazu nichts im Wiki oder hier im Forum (nicht sehr sortfältig gesucht evtl. ;)) interessieren, ob dieser Weg auch für Webhosting möglich wäre - funktioniert da FcrDNS genauso?

    Und was mich zusätzlich interessieren würde:

    Ich habe drei Domains, <domain>.DE|AT|EU. Da nur eine statische IPv4, zeigt der PTR auf <domain>.DE. Damit nun aber <postfach>@<domain>.AT|EU senden können, existiert (u.a.) für beide Domains ein "Host" <domain>.AT|EU._report._dmarc TXT record in den DNS Records für <domain>.DE

    Aus Sicht der Domain <domain>.DE, also der einzigen der drei mit auf sie zeigendem PTR, ist das der einzige "Link" zu den beiden anderen Domains, welche via reverse DNS zu ihnen führen würde....

    Hat diese Konstellation noch jemand?

    Hat jemand eine aktuelle Phishing Mail zu einer Domain bekommen, auf die KEIN PTR zeigt?

    (c) würde über diesen Weg nicht funktionieren. Gibt es hier tatsächlich Einschläge?? Ich selbst habe zwar aus der letzten Aktion eine Domain geparkt, für diese kann aber nichts ankommen, da weder echte noch catch-all Postfächer bis jetzt :)

  • Domain bekommt immer ein zusätzliches /

    .. auch wenn sie unsauber aufgebaut wird :)

    An HTTP Redirects liegt es nicht, https://www.redirect-checker.org/index.php z.B. bekommt jeweils HTTP 200 für Pfade OHNE anschließenden "/".

    Was mir auffällt:

    Deine Seite hat diesen Footer:

    Code
    <div class="footer"><p class="footer"><a href='http://derschmaletaler.de/' class='footer'>Home</a> &nbsp; <a href='http://derschmaletaler.de//ueber_uns' class='footer'>Über Uns</a> &nbsp; <a href='http://derschmaletaler.de//faq' class='footer'>FAQ</a> &nbsp; <a href='http://derschmaletaler.de//agb' class='footer'>AGB</a>

    Es gibt da einen Verweis auf https://ads-media.de Deren Seite sieht strukturell genau aus wie Deine, ich vermute also sie der CMS-Anbieter. Deren Seite hat die Dopplung nicht drin. Aber auch keinen "Home" Eintrag. Da die Dopplung schon im gerenderten HTML - wo wird der Werte für HOME hinterlegt? Welcher Wert genau?