Wird wahrscheinlich eine Frage der Mischkalkulation sein. Wenn man Storagespace auch für Kunden ohne Server anbietet, wird höchstwahrscheinlich mehr externer Traffic anfallen. Die Kunden mit Server werden ihn hingegen wohl vorwiegend innerhalb des RZ nutzen.
Ob man als Kunde NFS außerhalb des RZ verwenden will, ist sowieso wieder eine andere Frage. Ich würde es (ohne einem sicheren Tunnel) nicht machen. Bei anderen Protokollen sieht die Sache wieder anders aus, aber die werden nicht angeboten.
was kostet es denn wenn man seine eigene TLD haben will?
Afaik beginnt das im niedrigen mittleren 5-stelligen Bereich pro Jahr.
Die wirklich interessante Frage wäre doch: Wann können wir endlich eine .netcup registrieren? 
(Ein großer Mitbewerber hat tatsächlich eine eigene TLD. Preislich im Rahmen von DE-Domains. Wer's braucht…)
Für eine komplette externe Firewall hätte ich persönlich keine Verwendung. Das würde ich eher über das vLAN und einen weiteren Server realisieren. Die primäre NIC deaktivieren zu können, wäre aber tatsächlich super! 
Soweit ich das verstanden habe setzt das netcup System diese NIC (bzw. die IPv4-Adresse) nur beim Rettungssystem oder Neuinstallieren voraus. Das könnte das SCP ja entsprechend abfangen und sie nur in diesen Fällen einbinden.
Das ist zwar nicht neu, aber zum ersten Mal in meinem Posteingang: Phishing über *.github.io 
Keine Sorge, ich habe mir damals beide Threads durchgelesen. 
Du hast um 19:19 und 19:33 Threads eröffnet. Nachdem Du hier eine Lösung erhalten hast, hast Du im anderen Forum um 19:53 geschrieben, dass es gelöst wurde. (Und so getan, als ob Du selbst drauf gekommen bist.)
D.h. Du hast für mindestens 20 Minuten zwei Foren damit beschäftigt. Wäre nicht schnell eine passende Antwort gekommen, wäre dieses Spielchen vielleicht einige Tage weiter gegangen. Nur weil noch nichts gepostet wurde, heißt das ja nicht, dass sich Helfende nicht schon damit beschäftigen.
Dass ich erst einige Stunden später darauf hingewiesen habe, hat damit gar nichts zu tun. Ich wollte Dich damit nur auf Dein Fehlverhalten hinweisen, damit Du es in Zukunft eventuell vermeiden kannst. Die kleine neckische Zusatzbemerkung bezüglich dem Smiley war - zugegebenermaßen - unnötig von mir, dennoch konnte ich sie mir nicht verkneifen. Ich bin nämlich kein aktiver User des anderen Forums und habe den Thread nur deshalb gefunden.
Ich würde vorschlagen: Lassen wir das Thema an dieser Stelle ruhen. Du kannst über das Thema Crossposting nochmals in Ruhe nachdenken und Dir überlegen, ob Du es in Zukunft weiterhin so machst. Ich persönlich weiß allerdings, dass ich keine Zeit zur Lösungsfindung in Crosspostings investieren werde.
LG & stay healthy
Darum geht es gar nicht.
Das Problem ist, dass Du mehrere Foren damit beschäftigst, ohne dass die Helfenden davon wissen. Während in Forum A vielleicht schon eine Lösung gepostet wurde, zerbrechen sich die User in Forum B noch immer den Kopf. Das ist einfach nicht in Ordnung, weil es die Zeit von Freiwilligen vergeudet.
Wenn Du es unbedingt in mehreren Foren gleichzeitig posten willst, wäre ein Hinweis mit Links zu den anderen Themen mehr als fair. Alles andere ist einfach fehlender Respekt ggü. potentiellen Unterstützern und wird im Internet nicht gerne gesehen.
Werden mittlerweile sicher schon mehr Domains sein. Und Glue-Records gibt es auch noch. DNSSEC verbraucht sicher ebenfalls ein paar KB.
btw: Was, nur 520 IDN-Domains bei .co.at? Ich halte also mehr als 2‰ der IDN-Domains bei .co.at? 
Das hat jetzt etwas gedauert. Ich hatte nur noch das im Kopf: Älterer Glatzkopf
Was soll das bringen, wenn ich die fünf (!) Buchstaben und Zahlen von xxxxx.webhosting.systems in wenigen Sekunden durchprobieren kann (um nicht zu sagen dann auch noch zu Brute-Forcen, falls es noch nicht gephisht ist.
Dann fehlt Dir aber immer noch eine gültige Kombination aus Benutzername und Passwort? Oder worauf willst Du raus? 
(Ich stimme Dir aber zu, dass es super wäre, wenn man den direkten Login ins Plesk Panel bei Bedarf deaktivieren könnte und nur noch übers CCP rein kommt.)
Hallo Dagobert Duck 
Scheint sich aber zu lohnen (für den Angreifer), sonst hättest Du solche Zeilen nicht im Log.
Gibt sicher noch genügend alte Software, die stattdessen readfile() verwenden wollte. Oder eben doch include(), aber mit Validierung der Parameter.
mainziman Dass der Angreifer somit ganz einfach prüfen kann, ob X0_sp3ctra in der Ausgabe vorkommt. Erst wenn das der Fall ist, wird der richtige Angriff gestartet. Lohnt sich vorher ja nicht und ruft nur die Security-Experten auf den Plan. Mit diesem nutzlosen Fragment kann man, ohne passenden Honeypot, noch nichts analysieren. Und das ist dem Angreifer nur recht
Die Lücke selbst ist wohl so was:
// allow_url_fopen = 1
// allow_url_include = 1
include($_GET['idb']);(Achtung Kinder: Nicht nachmachen!)
Crossposting: https://www.php.de/forum/webentwi…rrays-vermeiden
(Oder anders formuliert: Wenn man sich nicht einmal die Mühe macht einen fremden Smiley im kopierten Beitragstext zu ersetzen.)
Im schlimmsten Fall Snapshot erstellen, offline ablegen, neues Image einspielen, rDNS Eintrag notieren, Snapshot wieder einspielen.
Vor allem der hervorgehobene Teil ist wichtig. Andernfalls endet's unschön 
(Weil Snapshots bei einer Imageinstallation übers SCP bekanntlich weg sind.)
Beides Ubuntu Server 20.04.2 ohne VirtualBox Gasterweiterungen. Die Auflösung ist in der GUI vom Host nicht änderbar.
Einziger Unterschied: In VM B wurde zwischenzeitlich z.B. eine GParted-ISO gebootet.
Was ist passiert? Eine winzige – automatische – Anpassung der XML-Datei. Keine Ahnung warum VirtualBox das macht…
<VirtualBox>
<Machine>
<ExtraData>
<ExtraDataItem name="GUI/LastGuestSizeHint" value="1024,768"/>Ändert man das, sind beide Fenster wieder gleich groß. Eigentlich dachte ich, dass das ohne Gasterweiterungen keine Auswirkung haben darf. Komisch.
Na bei solchen Dingen macht die Fehlersuche, wenn man das nicht weiß, richtig Spaß.
Im Nachhinein betrachtet eh logisch, weil es nur einmal übersetzt und im Cache gehalten wird. Die anderen Hardlinks bekommen dementsprechend die Version aus dem Cache, die nicht übereinstimmen muss. Ist halt blöd, wenn man damit nicht rechnet und mit Hardlinks eine Sache unorthodox lösen möchte, dann ist die Fehlersuche wahrlich sehr lustig…
(Gilt selbstverständlich auch für die magische Konstante __FILE__!)
Das klingt nach dem üblichen Problem, dass die Ordnerpfade über HTTP anders als über SSH sind. Probier es mal so:
<?php require(__dir__ . '/adm/config.php');Ungetestet, aber damit sollte es klappen, egal worüber es aufgerufen wird. Ist z.B. bei Nextcloud inhaltlich identisch.
(Warum zum Teufel meinen Entwickler immer wieder, dass absolute Pfade eine tolle Idee sind? 
)
Achte unbedingt darauf, dass Du über SSH die richtige PHP-Version verwendest! Siehe Ausgabe von php -v
Welche Versionen zur Verfügung stehen und wie der genaue Pfad lautet, siehst Du so: ls -ld /usr/local/php*/bin/php
Das gewünschte Script führst Du mit PHP 7.3 z.B. so aus: /usr/local/php73/bin/php /pfad/zum/script.php
(Die Standard PHP-CLI-Version lässt sich auch dauerhaft einstellen. Siehe /conf/phpversion.readme!)