Wenn ich die Diskussion hier so lese, dann bleibt eigentlich nur der Hinweis auf diesen Beitrag:
Hier ist die gleiche Situation. Das kann nicht gut ausgehen, das wird in wenigen Tagen zur Katastrophe.
nur zur Info: RDP enthält 300 ungepatchte Sicherheitslücken. Das darf man nicht direkt ins Internet hängen, ist zu gefährlich.
Die anderen Dienste hast du in der Firewall abgesichert?
Beim Error-Log ist vermutlich auch ein Fehler im Aufruf. Jedenfalls so, wie du es hier geschrieben hast.
Werte doch mal den Rückgabewert aus.
Dass Screen die Ursache ist, halte ich für unwahrscheinlich.
Du erzeugst bei der Ausführung ja mehr Logs, als eine Linux Server Farm. Was steht denn drin zur Fehlerursache?
mit der anpassung von Casstg läuft es jetzt mit UFW
Schon mal als Warnung: Das kann sich jederzeit (!) ändern.
aber Plesk verwaltet IPtables :\
Solange du mehrere Tools hast, die in deinen Firewallregeln herumpfuschen, musst damit rechnen, dass Dinge passieren, die du nicht willst. Vor allem, da es nicht so bleibt, wenn du es einmal eingestellt hast, da jedes Update und jeder Neustart Dinge ändern kann.
Dafür wurde aber doch ufw- docker installiert um das zu verhindern. Hat ja auf dem alter Server auch so geklappt.
Ohne dir zu nahe treten zu wollen, aber das wage ich zu bezweifeln. Das klappt vielleicht einmal kurzfristig, aber spätestens nach dem nächsten Docker Update, vielleicht sogar schon bei jedem Restart, trägt Docker wieder in die Firewall ein, was es für richtig hält. Ich habs nicht geschafft, es davon abzuhalten, und mit Firewalls unter Linux hab ich mich viel beschäftigt.
Wenn man wirklich sicher sein will, dass die Firewall nur das tut, was man selber will, aber nicht das, was Docker will, muss man eine Firewall Instanz vor Docker bringen. Das kann z.B. ein kleiner dedizierter Server sein, der nur Firewall und Router spielt, oder man richtet Docker in einer VM oder einem Container ein. Da kann es sich dann austoben, und in der Instanz davor stellt man alles so ein, wie man es möchte.
Die Frage war ja, warum der Container ohne Regel erreichbar ist. Und die Antwort ist Zeile 23. Du kannst die Zeile auch rausnehmen und die Portweiterleitung selber machen. Aber geh davon aus, dass jedes Update die Zeile zurückbringt und deine Firewall wieder aufreißt.
In Zeile 23 sieht man den Grund für Beitrag #23. Es ist nach wie vor dein Problem, dass Docker seine eigenen Regeln an der Firewall vorbei einträgt. Das ist der Grund, warum Docker bei mir nur in einem lxd Container läuft. Man verliert die Kontrolle über seine Firewall, weil Docker zu allen möglichen und unmöglichen Gelegenheiten irgendwas einträgt.
Und wenn ich das richtig erkenne, dann wird auf den SSH port nur per IPV6 gehört, oder?
Nein, der lauscht auch auf IPv4. tcp6 mit ::: deckt alle Protokolle und Interfaces ab.
Die obigen Regeln sind noch aktiv? Dann siehe #23.
Ich kann die Scripte wohl veröffentlichen, muss aber noch mal kurz drüber schauen, ob sie von der Code Qualität her vertretbar sind. 
Kleine Warnung: Das ist veraltete Information. Die aktuelle Firewall Technik in Linux heißt nftables und ipset ist damit Geschichte.
Stimmt nicht so ganz.
nftables hat (auch) ein iptables Frontend, und gerade bei den IP Filterlisten gibt es in nftables in einigen großen LTS Distributionen noch Fehler (u.a. in Ubuntu 22.04), die die Benutzung praktisch unmöglich machen. Bei den Distris bleibt man besser auf ipset. Irgendwo hier im Forum hab ich das schon mal ausfüherlicher aufgedröselt, auch wie man Scripte für das Pflegen der Listen von ipset auf nftables umstellt.
Mein Problem ist jetzt das UFW nun auch meine IP Adresse blockt.
Gut, das kriegt man in den Griff. War es Fail2Ban? Oder hast du die Regeln generell zu stark ausgelegt?
Ich empfehle für Blacklisten bei iptables das Tool ipset bzw. bei nftables die integrierten Filter. Die sind erheblich effizienter, als einzelne Regeln, und weniger anfällig für Bedienungsfehler.
Wie gesagt, gehe systematisch vor. Analysiere die Logfiles, schau dir an, was passiert ist. Vielleicht gibt es eine harmlose Erklärung, warum der Apache nicht mehr erreichbar ist.
Und lass dir den Schreck als Warnung dienen, und nutze die Gelegenheit, dein System ordentlich abzusichern. Wie gesagt, eigentlich müsste da in etwa eine UFW Meldung pro Sekunde aufploppen, wenn alle Meldungen gefiltert werden.
Ich hab mir eine Auswertung gebastelt, die meine Firewall-Regeln überwacht. Zur Info: Die angegeben Zahlenwerte repräsentieren die Anzahl der Attacken in einem 5-Minuten Fenster (Update-Intervall von Munin). 5 Minuten sind 300 Sekunden, und wenn ich die Anzahl der geblockten Pakete in der AVG Spalte zusammenzähle, komme ich auf mehr als 300. Also eine geblockte Attacke pro Sekunde, die meisten auf IPv4.
"INPUT REJECTED" bzw. "FORWARD REJECTED" sind Pakete von erlaubten Adressen, die aber von der Firewall geblockt wurden, entweder direkt auf den Host (bei "INPUT") oder auf ein Netz dahinter (bei FORWARD).
"DROPPED" sind Pakete, die von IPs auf der Blacklist kommen und direkt weggeblockt werden. Die Blacklist generiere ich mit aus den Listen einiger freier Dienste, auf denen "böse" IPs gesammelt werden.
Das Ganze ist dann noch für IPv4 und IPv6 getrennt.
Man erkennt, dass die Blacklisten das meiste rausfiltern. Aber ab und zu sieht man grüne Peaks, dann kommen Attacken von IPs, die nicht geblacklistet sind, aber trotzdem wild auf meine Firewall einprügeln.
Interessant, das ganze auch mal über einen längeren Zeitraum zu betrachten:
Im März war ich offensichtlich mal das Ziel einer IPv6 Attacke.
Von außen kann ich mich auch nicht mehr als normaler User ins SSH einloggen.
Wie bist du denn dann mit Putty aufs System gekommen?
Mein Apache2 ist auch nicht mehr erreichbar.
Und du hast ihn nicht deaktiviert? Dafür kann es auch ungefährliche Gründe geben.
Werde ich hier gerade angegriffen?
Man wird permanent angegriffen. Auf einer öffentlichen IPv4 in den Netcup Subnetzen ungefähr 1x pro Sekunde. Ich predige es andauernd, schön, dass mal jemand selber drauf aufmerksam wird.
Bei den Logmeldungen hast du Glück, das sind all diejenigen Angriffe, die UFW blocken konnte. Die sind keine Gefahr. Die Frage ist: Hast du Ports in UFW vergessen? Das wäre denn gefährlich, und die werden nicht geloggt.
Und über die eigentlichen Portscans hinaus gibt es natürlich auch Attacken auf die Applikationen, üblicherweise die Webseiten, PHP, etc. Schau mal in deine Apache Logs. Aber Vorsicht, die sehen noch deutlich dramatischer aus, als dein UFW Log, selbst wenn nichts passiert ist. Aber du musst unbedingt dafür sorgen, deine Systeme auch mit einer WAF abzusichern.
Also gehe ich davon aus, dass es an den VM-Einstellungen selbst liegt.
Was ja nicht heißt, dass es nicht eine einfache Lösung gibt.
Daher die Frage, ob sie die Einstellungen für meinen Server anpassen können
Eine einzelne VM in einem großen Rechenzentrum, die sich anders verhält, als alle anderen. Ich hätte mich gar nicht getraut, das zu fragen.
Für die Software, die installiert wird, ist Netcup nicht verantwortlich, und sie können unmöglich für alle Betriebssystemvarianten umfassenden Support liefern.
Kann man Kernel-Optionen nicht einfach im Bootloader anpassen? Dann braucht man kein Rettungssystem.
Und über das Rettungssystem die Kernelparameter so zu verändern, dass sie serielle Konsole nicht genutzt wird, geht nicht? Oder direkt im Bootloader?
Black Coffee Week. 
Jetzt glaube ich auch, dass es Kaffee ist.
