Beiträge von Copro

Kannst Du in den Logs (1) im Wordpress Toolkit nachsehen, was genau der Webserver für Schmerzen hat bzw. ebenfalls im Wordpress Toolkit Debugging (2) aktivieren? (der aktiviert meines Wissens auch ein höheres PHP Debug Level)

netcup_WCP_Wordpress_Toolkit_1_Logs_und_2_Debugging.png

Die von Olivetti angesprochene .htaccess Datei ist in Deinem Hosting Verzeichnis ... also evtl. httpdocs ... oder möglicherweise auch der Ordner Wordpress.
Den genauen Ort wo Deine Wordpress Installation sitzt, zeigt das Wordpress Toolkit nicht direkt an, aber müsste im CCP über den Dokumentenstamm der Domain einsehbar sein.

netcup_CCP_Domain_Dokumentenstamm.png

Die Profis hier können Dir sicher auch weiterhelfen, wenn noch etwas mehr Informationen kommen ... ich wollte eigentlich auch nur kurz eine Wordpress Installation umziehen und habe deswegen den Beitrag gesehen, muss aber jetzt dann zum Wellnessen weglaufen

Deine Webhosting Seite zeigt auch nur einen 503 Fehler: (wenn ich die URL anhand der Screenshots richtig zusammengebaut habe. Diese solltest Du nach der Lösung des Problems auch wieder entfernen, weil die wichtige Details zu Deiner Hostingumgebung bekannt machen.)

https://hosting1048XX.af9YY.netcup.net/ -> 503 Service Temporarily Unavailable

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

Wenn Du beiden Dokumentenstämme auf den gleichen Ordner im Verzeichnis, also den von der 1. Domain gesetzt hast und dort Wordpress installiert hast, sollte das passen. Was das Wordpress Toolkit und die Wordpress Installation macht, wenn Du da mit Links von der 2. Domain z.B. im Admin Bereich arbeitest, ist mir aber auch nicht zu 100 % klar, bzw. man hat dort eventuell komische Seiteneffekte.

Wenn es Dich nicht stört, dass die Besucher mitbekommen, dass auf die 1. Domain weitergeleitet wird, könntest Du auch wie von Homwer hier mal beschrieben einfach die 2. Domain als normales Webhosting lassen und dort einfach die Weiterleitung per .htaccess einrichten. Das wäre dann eine richtige "Weiterleitung"

Wichtig ist aber vor allem im Zusammenhang mit SSL, dass Du am besten vorher alle Domains mit einem SSL Zertifikat ausgestattet hast, wie Julian137 schon geschrieben hat und auch alle Optionen gelistet hat.

Also viele Möglichkeiten:

1. Gleicher Dokumentenstamm
netcup serviert praktisch dieselbe Wordpress Installation unter ab.de und ba.de, ohne dass man das merkt. Aufpassen müsse man hier beim Entfernen einer Domain oder beim Anpassen des Hosting-Typs, weil dort durch Änderungen am Dokumentenstamm auch die jeweils andere Domain betroffen ist.

2. netcup Weiterleitung 301/ 302 oder Frame-Weiterleitung per Hosting-Typ
Wie oben schon beschrieben, kann man im CCP unter Hosting-Typ die Weiterleitung konfigurieren. Dabei die Warnung beachten, dass beim Einrichten einer Umleitung die eventuell schon angelegten Dateien verloren gehen. Aus dem verlinkten netcup Hilfecenter würde sich für eine dauerhafte Weiterleitung die 301 anbieten. (301 Dauerhaft verschoben: Anlegen einer Weiterleitung auf eine andere Webseite mit HTTP Code 301 (dauerhaft verschoben). Browser können diese Weiterleitung cachen.)

netcup_CCP_Domain_Umleitung_301_Warnung.png

3. Weiterleitung per eigener .htaccess Datei im Hosting-Typ Webseite
Mit dem normalen Hosting-Typ Webseite kann man, wie von Homwer hier beschrieben, die Weiterleitungsregeln 301 oder 302 per htaccess Anweisungen selber konfigurieren und weitere Experteneinstellungen mit dem ReWrite Modul dazu packen.

4. Weiterleitung rein per DNS per redirect.center
Die Weiterleitung direkt per DNS konfigurieren durch Nutzung des Dienstes von redirect.center mit der Angabe von einfachen DNS Einträgen für ba.de entweder für http:// oder https:// aber mit dieser Option von einem externen Dienst abhängig sein.

Weiterleitung an http://www.ba.de

Host Record:<leer_lassen> Type: A To: 54.84.55.102

Host Record: redirect Type: CNAME To: http://www.ba.de.redirect.center

oder für eine Weiterleitung an https://www.ba.de

Host Record:<leer_lassen> Type: A To: 54.84.55.102
Host Record: redirect Type: CNAME To: http://www.ba.de.opts-https.redirect.center

netcup_DNS_Einstellung_Weiterleitung_CNAME_redirect.center.png

Wie erwartet war die schnellste Lösung den bisherigen Provider zu bitten die Domain wieder zu aktivieren, ein kleines günstiges Paket mit kurzer Laufzeit bzw. 30 Tage-Geld-zurück-Garantie und dann innerhalb dieser Zeit den sauberen Transfer vorzubereiten. Thema habe ich geschlossen, weil es so vermutlich niemand interessiert. Alles gut gegangen

Ein aktueller Fall von fehlgeschlagenem DE Domain Übertrag zu netcup aufgrund von vermutlich abgelaufenem AuthInfo Code VOR Domain Löschung und der Redemption Grace Period (RGP)
Gestern wurde noch versucht beim alten Provider telefonisch der AuthInfo Code zu verifizieren, obwohl dieser weil seit dem 16.01.2024 bekannt mittlerweile abgelaufen sein müsste weil nur 30 Tage gültig. Das alleine ist schon kein gutes griechisches Omen - aber wie lautet hier die Empfehlung der Experten?

Aktueller Stand:

- netcup kann keinen Domaintransfer durchführen, weil DENIC meldet "AuthInfo does not match"
- Webseite und Zugangsdaten beim alten Provider schon gelöscht und Kontakt E-Mail-Adresse leider die info@-Adresse der verwendeten Domain
- Domain bei DENIC aktuell noch als registriert gelistet

- beim ersten telefonischen Kontakt schon einen Mitarbeiter des alten Providers fast soweit gehabt, dass der ein Formular zum Ändern der Kontaktdaten übermittelt hat
- einen neuen bzw. anderen AuthInfo Code wollte man beim alten Provider nicht ausstellen, weil eine Übermittlung am Telefon ausgeschlossen war und nur an die aktuell gültige bzw. nicht mehr abrufbare Kontakt E-Mail in Frage kam
- der Weg mit der AuthInfo2 ist grundsätzlich bekannt und wurde in der Vergangenheit schon einmal angewendet und Extrakosten sind bekannt

Das Problem beim erneuten Ausstellen war, dass der alte Provider - vermutlich völlig korrekt - den AuthInfo Code nicht telefonisch mitteilen wurde und nicht darauf hingewiesen hat, dass dieser nach 30 Tagen abläuft. (Zum Schutz der Domain ist eine AuthInfo nur begrenzt gültig. Sie verfällt nach 30 Tagen. Danach muss für den Providerwechsel dieser Domain eine neue AuthInfo hinterlegt werden.)

Der aktuelle Plan ist es also den alten Provider dazu zu bringen schnell per Formular die Kontakt E-Mail zu ändern und einen neuen gültigen AuthInfo Code dorthin zu übermitteln und netcup erneut transferieren zu lassen. Noch ist heute ja ein letzter Arbeitstag im Februar und es besteht noch die Chance die Domain vor dem Abrutschen in die RGP Phase zu verhindern.

Oder wäre eure Empfehlung darauf nicht zu warten und per AuthInfo2 direkt die Briefzustellung abzuwarten und dann zu transferieren?

Zitat von TobiasH

Man kann alternativ/zusätzlich noch über GeoBlock von IP-Adressen nachdenken und so z.B. nur Land des Wohnorts und (aktuelles/zukünftige) Urlaubsland den Zugriff erlauben, man braucht ja nicht die ganze Welt.

Neben Geoblocking ist auch besonders Port knocking geeignet, um einen Serverdienst abzusichern. Übersetzt heißt das man "klopft" auf einem anderen Port am Server an, um dann den eigentlichen Dienst also z.B. SSH freizuschalten. Der eigentliche Dienst SSH sieht für den Rest der Welt geschlossen aus und nur der eigentliche Besitzer kennt den Port an dem vorher angeklopft werden muss.

Erfahrungen mit kockd einem Daemon für Port knocking sind z.B. hier in dem Beitrag erfasst.

Bei der Domain ist es zwar nicht so tragisch und der AuthInfo2 Weg wird nicht genutzt, weil es meiner Bekannten nur darum ging durch eine Umleitung eventuelle Irrläufer und möglicherweise den restlichen Google PageRank einzusammeln. Die neue Domain ist schon bei netcup erstellt und soll Mitte Ende März online gehen.

Danke an Bud
Ich kenne Mr. ED und habe den Service auch schon genutzt ... und das wird aber in dem Fall nicht genutzt. Meine Bekannte hat entschieden nach Ablauf der RGP Phase zu entscheiden, ob es sich lohnt die alte Domain zur Umleitung noch für ein Jahr zu sichern.

Für die Achtsamkeit auch Dir NaN herzlichen Dank - beim anderen akute Fall wird das auch berücksichtigt.

Ist eine DE Domain in der Redemption Grace Period (RGP) von 30 Tagen nach der Löschung nicht mehr über den AuthInfo Code transferiert werden?
Hatte den Fall eventuell jemand schon und kann Informationen anbieten?

Soweit ich das laut Wikipedia Artikel und die Informationen auf der DENIC Seite verstehe, ist ein Transfer nur über den AuthInfo2 Code, durch den ursprünglichen Inhaber oder wenn dieser bei der DENIC schriftlich vorher auf die RGP Phase verzichtet.

Ich meinem Fall hat eine Bekannte einen AuthCode erhalten, aber die Domain ist nach Löschung am 26.02.2024 jetzt in der RGP Phase und war mir nicht sicher, ob es noch sinnig ist einen normalen Transfer zu starten. Könnte mir vorstellen, dass der ursprüngliche bei der DENIC durch den Provider hinterlegte AuthCode bei Löschung der Domain ebenfalls entfernt wird.

Zitat von tegger

Ich überlege echt gerade, ob ich die nicht zu einem anderen Anbieter umziehe, kann ich die Email-Funktion mit einer externen Domäne nutzen ?

Auch bei einer externen Domain richtest Du die DNS Einstellungen so ein, dass die MX auf die netcup Server zeigen. Also ja - die E-Mail-Funktion kannst Du auch bei einer externen Domain nutzen.

Da gebe ich Dir recht, aber der Support kannte evtl. zu diesem Zeitpunkt das Problem nicht. Ein Supportmitarbeiter hat hier das Problem bestätigt und bittet noch um Geduld bis zur Lösung. In der Zwischenzeit wird das also auch die Runde bis in den First-Level-Support machen.
https://forum.netcup.de/informationen/…cup/#post218055

Zitat von MacLemon

Über IPv6 ist es, für den Mailaustausch mit Google gehosteten Domains, schon lange Pflicht SPF und DKIM zu unterstützten. Nut bei Legacy-IPv4 wurde das noch eine zeitlang gedulded. Jetzt isses auch bei Legacy-IPv4 Pflicht. Das ist auch nicht nur bei Google so, sondern generell bei sehr vielen Mailservern. Das ist also weder neu, noch kommt es überraschend, sondern gehört zum Betrieb eines modernen Mailsystems schlicht und ergreifend dazu. Grundsätzlich gehören eine vollständige DMARC Policy sowie geroutete RFC2142 Adressen ebenso zu den Minimalanforderungen.

An sich sollten, meiner Ansicht nach, Domains die kein sinnvolles^* SPF setzen und DKIM unterstützen, generell einen Null MX^† Record setzen und keine Emails mehr senden.

---

*) Ein sinnvoller SPF Record muß -all enthalten.

Der Standardvorschlag von netcup bei einer Externen Domain für den SPF ist [tt]~all{tt] also SoftFail, was ja heißt, lehne die E-Mail nicht ab, aber markiere sie. Ich wäre da vermutlich auch härter, habe es aber noch nicht ausprobiert, ob das der Kunde selber entscheiden darf.

Wenn ich den Beitragsfaden noch ein bisschen stören dürfte ... welche der common services, roles und functions würde man dann einem netcup Webhosting Kunden empfehlen? (oder soll ich dafür einen extra Beitrag irgendwo hinpacken?)

Ich erstelle meistens nur webmaster und postmaster ...

POSTMASTER     SMTP  --> relevant, weil ja auch die Absicherung der SMTP Konten im Kundeninteresse ist
HOSTMASTER     DNS   --> ist das relevant, wenn ein Webhosting Kunde nichts zum netcup Standard anpasst?
USENET         NNTP  --> nicht relevant
NEWS           NNTP  --> nicht relevant, da Dienst nicht angeboten
WEBMASTER      HTTP  --> relevant, weil ja vermutlich die Webseite zu 100 % im Kunden
FTP            FTP   --> nicht relevant

Weil ich den Beitragsfaden nicht weiter stören möchte, ergänze ich den Schmu hier noch:
Zur Sicherheit vor der gender police werde ich in Zukunft also auch webmistress und postmistress anlegen, um zumindest die erste Welle des Shitstorms mit etwas warmen Schmunzeln über mich hereinbrechen zu sehen. Dem Meister master möchte ich das nicht antun ...

Der Kunde ist Herr über den DNS bei einem externen Anbieter und netcup prüft aber bestimmte Werte vor der Aufschaltung der Externen Domain. (Kann aber sein, dass hier nicht auf dem Detail-Level geprüft wird und nur die wichtigsten A und MS Pointer.)

Danke für die Rückmeldung - kann bestätigen, dass es wieder klappt

netcup_WCP_Kontaktformular_Support_OK.png

Lasse aber auch hier noch den Verweis aufs Helpcenter da, den charmin.armin oben ja schon gegeben hat und der in der E-Mail zur Bestätigung des Empfangs jetzt enthalten ist.

Kennen Sie schon unser neues Kontaktformular? Gerne können Sie Ihre Anfrage zukünftig darüber versenden, damit wir Ihnen noch schneller und effizienter weiterhelfen können: https://deref-gmx.net/mail/client/PF…%2Fde%2Fsupport

Zitat von DerRené

Die Aussage des Supports, dass der Virenschutz permanent aktiviert sei, kann einfach nicht stimmen.

Doch die Aussage ist vermutlich schon richtig - aber versuche meiner Erklärung zu folgen.
Der Bug in plesk, auf dem ja das WCP basiert, verhindert aktuell, dass die Checkbox "[ ] Virenschutz für diese E-Mail-Adresse aktivieren" Wirkung zeigt. Diese Einstellung also das aktiv Flag dürfte vor der Änderung korrekt gesetzt worden sein und jetzt eben nicht mehr. Das erklärt auch das unterschiedliche Verhalten und schränkt auch die Auswirkung ein - sonst wären jetzt aktuell alle netcup Webhosting E-Mail-Konten ohne Virenschutz.

Und der Bug, dass dieser bisher als reiner Anzeigefehler behandelt sich auch auf die Sicherheit neu angelegter E-Mail-Konten auswirkt, wurde leider erst spät bzw. dummerweise kurz vor dem Wochenende auch nur auf einem Nebenkanal gemeldet. Also ohne netcup großartig verteidigen zu wollen ... warten wir mal das Wochenende ab und hoffen nächste Woche auf eine zügige Bereinigung ... also auch aller bis dato neu angelegter E-Mail-Konten, die davon betroffen sind.

Wildcard Let's Encrypt und WCP / plesk sind ein eigenes Thema, zu dem ich gerne noch einen Link einfügen würde, sobald ich ihn finde.

Diskussion um die Sinnhaftigkeit der Wildcard Zertifikate im WCP aus dem Jahr 2023
Empfehlung von @'[netcup] Lars S.' statt Wildcard Zertifikaten lieber einzelne zu beantragen aus anderem Beitrag 2022

---

Zurück zum Thema - die Subdmain webmail absichern ist also nicht so einfach möglich - aber dann nehmen wir doch einfach wm.netztassendomaene.de

Es hindert aber niemanden daran, seine eigene Subdomain (nicht webmail oder mail) aufzusetzen und mit korrektem LE SSL Zertifikat zu webmailern. Ich mache mal Werbung in eigener netcup Sache und verweise auf das Community Tutorial zum Aufsetzen eines Roundcube Webmail Frontends.

Setup of Roundcube as webmail frontend on webhosting (netcup.com)

Zitat von charmin.armin

https://helpcenter.netcup.com/de/support hat bei mir funktioniert

Copro hab den Chef in CC: gesetzt (rechne nicht vor nächster Woche mit einer Antwort)

Danke charmin.armin für die Info ... die viel wichtigere, dass neue Webhosting E-Mail-Konten ohne Virenschutz angelegt werden, habe ich per E-Mail übermittelt. Und danke Virinum für die Verlinkung auf den Eintrag zur eingeschränkten CCP Funktionalität auf der Statusseite.

Aktuell kann das Kontaktformular im CCP für den Support nicht genutzt werden und gibt immer nur folgende Fehlermeldung aus: Fehler: Session abgelaufen. Bitte melden Sie sich neu an.

Testfall: Kontaktformular für Support nutzen
1. "Kontakt" im CCP oder direkt https://www.customercontrolpanel.de/kontakt.php aufrufen

2. Bereich "Support", Betreff und Mitteilung ausfüllen

3 [Anfrage absenden]

--> Fehlermeldung: Fehler: Session abgelaufen. Bitte melden Sie sich neu an.
netcup_CCP_Support_Kontakt_Fehler_Session_abgelaufen.png

URL: customercontrolpanel.de/run/kontakt.php

Ich habe die eigentliche Meldung zum Problem mit dem Virenschutz bei neu angelegten E-Mail-Konten in Webhosting Paketen per E-Mail in einem anderen Ticket weiter gegeben, aber es sind noch andere Kunden betroffen.

Einen "Dienst" in dem Sinne kenne ich nicht - aber die Freundin eines Arbeitskollegen Java-Entwicklers und Linux Brotback-Bastlers ist professionelle Pentesterin.
Deine Angaben zur Absicherung hören sich aber schon sehr gut an und durch so Tool-Sammlungen wie Mozilla Observatory (Mozilla Observatory) oder Hardenize, etc. hier im Folgenden Link aufgelistet hast Du schon durch?
Online-Scanner: Tools für Sicherheit und Datenschutz ⋆ Kuketz IT-Security Blog (kuketz-blog.de)

Magst Du bitte probieren, ob Du das Problem ebenfalls weitergeben kannst - ich bekomme aktuell das Support-Formular nicht abgesendet wegen:
Fehler: Session abgelaufen. Bitte melden Sie sich neu an.

(und die springen sicher schon im Viereck, wenn der Copro-kun schon wieder dem "Anzeigeproblem" ankommt und keine Geduld hat)

Das Problem mit dem Support-Formular würde ich natürlich auch gerne irgendwo platzieren - aber jetzt ist ja Wochenende

Danke für den Test DerRené - ich habe es mit einer frischen E-Mail auf einer dieses Jahr eingerichtet Domain probiert und der Mailhost ist bei mir mx2e1e (Das Support-Formular foppt mich gerade mit "Fehler: Session abgelaufen. Bitte melden Sie sich neu an.").

Das ist ja schon einmal gut zu wissen, dass nicht alle Kunden betroffen sind - wird aber auch schwieriger das richten zu lassen.

Für den oben gemeldeten Sachverhalt habe ich jetzt eine neue Antwort und das Problem könnte ja damit zusammenhängen:

Zitat

Der Sachverhalt ist auf einen Bug in plesk zurückzuführen. Dieser befindet sich derzeit schon in Bearbeitung. Bitte haben Sie daher noch ein wenig Geduld.

Die Kopfzeilen sagen, dass hier gar kein Virenscan seitens netcup gelaufen ist und nur der SpamAssassin 3.4.2 drübergeschaut hat.
Soweit ich mich noch erinnern kann, bestünde auch die Möglichkeit, dem SpamAssassin die Virenprüfung z.B. via ClamAV zu geben, aber das scheint hier nicht der Fallzu sein.

Der einzige Eintrag in den Kopfzeilen dazu kommt anscheinend noch von extern: (ich habe die gesamten Kopfzeilen dem Support mitgegeben)
X-Virus-Scanned: Debian amavisd-new at !change-mydomain-variable!.example.com

Ich habe hier den Screenshot vom MS Edge Browser, dessen Smartscreen Technik auch gleich den Download der EICAR-Testdatei verhindert:
Webmail01_netcup_kein_Virenscan_EICAR-Testdatei.png

Zitat von Homepagehilfe

Ah ich Idiot... Jetzt muss ich ja https:// und nicht http.. Jetzt klappt es. Hab jetzt noch Umleitung eingestellt von http auf https, war das klug? Fehlt nur noch das Email Problem

Aktiviere noch die Option "Von HTTP auf HTTPS umleiten" und auch diese Eselsbrücke ist nicht mehr nötig.

Damit werden alle Besucher der Webseite http://deinewebseite.de automatisch auf https://deinewebseite.de umgeleitet.