Beiträge von NaN

Snapshots are images of the virtual hard disk at that point in time. The OS doesn't really matter. You could use an exported snapshot to restore your server to an earlier state by uploading it later, instantiate a virtual machine on your own development servers with it, analyze it with forensic tools beyond what's available in the rescue system, work on the downloaded disk image while the server is running, etc.

You can create as many snapshots as are included in your virtual server plan. If you delete one, it's available to be created again. Only exports of snapshots are limited to a small number and gone if used. If you want to export more, you can purchase more exports.

Online snapshots (taken while the VM is running) can't be exported and exporting offline snapshots is not free (just once as an appetizer, I guess). You can boot into the rescue system and use it to export an image of your VM hard disk for free, if you're so inclined. The disadvantage of doing it that way is that it keeps the server offline for as long as that takes, while using the snapshot function is quick and you can download the snapshot while the server is up running again.

Streng genommen wurde gar nichts eingeräumt sondern lediglich eine künstliche Beschränkung, wann Snapshots angelegt werden können, verändert/aufgehoben. Der Speicherbedarf steigt durch den Snapshot ja zunächst nicht an, sondern erst, wenn in der VM geschrieben wird. Was passiert, wenn Snapshots und aktuelle Version zusammen zu viel Speicher belegen, ist noch offen. Das konnte bisher auch passieren, war aber natürlich unwahrscheinlicher, als wenn man einen Snapshot bei fast voll belegter Platte anlegt.

Gegen Snapshots spricht außerdem, dass sie eine auomatische Hostmigration verhindern. M.M.n. sind Snapshots vor allem geeignet, um halbwegs konsistente Full-Disk-Backups zu ziehen, ohne die VM herunterfahren zu müssen, oder um die Downtime zu verringern, wenn man ein solches Backup des ausgeschalteten Zustands ziehen möchte. Man kann auch vor riskanten Änderungen einen Snapshot machen und dann entweder Zurückrollen oder bei Erfolg den Snapshot löschen. In allen Fällen braucht man den Snapshot aber nur kurzzeitig, so dass die Überschreitung durch Aktivität in der VM unwahrscheinlich ist und der Snapshot auch keine Verschiebung auf einen anderen Host verhindert.

Der Server läuft, bis er ausgeschaltet ist. Das ist nicht die Uptime des Betriebssystems sondern sozusagen, wie lange das Netzteil deines virtuellen Computers schon an ist. Ein Reboot schaltet die virtuelle Maschine nicht aus. Deswegen muss der Server z.B. auch wirklich heruntergefahren werden, um Änderungen im Hypervisor zu übernehmen. Ein Reboot reicht dann nicht.

Wenn du in deiner VM deutlich weniger Speicher belegt hast, kannst du evtl. Speicher mit sudo fstrim -v / freigeben. Das signalisiert dem Speichermedium, dass bestimmte Blöcke keine Daten enthalten und deren Inhalt daher nicht gespeichert werden muss. Für SSDs bedeutet das, dass sie die Blöcke beim Wear-Leveling nicht umkopieren müssen. Mit virtuellen Laufwerken kann man so dem Host signalisieren, dass dieser Speicher freigegeben werden kann.

Snapshots sind COW (Copy On Write), belegen also erstmal keinen Platz. Jeder Schreibzugriff in der VM belegt dann aber zusätzlichen Platz, auch wenn er nur bereits im Snapshot belegten Platz überschreibt. Die Frage ist immer, was dann passiert, wenn die Snapshots und die aktuelle Version des Images zusammen mehr Platz belegen, als in dem Tarif zur Verfügung steht. Wenn dir auf deinem Computer die Platte volläuft, und der Hypervisor keinen Platz mehr für die Schreibzugriffe findet, pausiert er die VM. Vielleicht macht Netcup das auch so, aber vielleicht ist das Accounting für Snapshots auch anders. Ich würde auf einem Production-System keine dauerhaften Snapshots anlegen, wenn die Möglichkeit besteht, dass der belegte Speicher plus Snapshots den Tarifspeicherplatz überschreitet, erst recht nicht, wenn der Speicherplatz schon fast voll ist, auch wenn das mittlerweile "geht".

Die Gruppenzugehörigkeit von neu angelegten Dateien kannst du mit chmod g+s directory auf die Gruppe des Verzeichnisses festlegen. Der User, der die Datei anlegt, muss dabei nicht mal Mitglied der Gruppe sein. Für den Owner der Datei gibt es diese Möglichkeit in Linux nicht, aber FreeBSD kann das.

Eine Option, den Eigentümer und die Gruppe von Dateien fest vorzugeben, kennen die Ext-Dateisysteme und die meisten anderen nicht. Es gibt aber ein FUSE-Dateisystem, mit dem das geht: bindfs. Damit würdest du ein Verzeichnis so auf eine bestimmte Eigentümer/Gruppe-Kombination zwingen: sudo bindfs -u UID -g GID Quellverzeichnis Mount-Point. Es gibt auch die Möglichkeit, nur bestimmte Benutzer und Gruppen umzumappen.

TOTP ist ein Geheimnis wie ein Passwort, nur dass der Abgleich, ob du das Passwort kennst, nicht dadurch gemacht wird, dass du das Passwort überträgst, sondern indem du einen Teil eines Hashwert überträgst, der über die (gerundete) Uhrzeit und das Geheimnis berechnet wird. Wenn du die Parameter dieses Abgleichs, das Geheimnis und die Uhrzeit kennst, hast du alles, was du für den Login brauchst. Die meisten (auch Netcup) verwenden die Standardparameter, so dass du dir praktisch nur das Geheimnis aufschreiben musst. Die Standardparameter sind 6 Ziffern, 30 Sekunden, SHA1. Der Algorithmus ist in RFC 6238 und anderen dort referenzierten RFCs veröffentlicht.

Ich habe mir das jetzt mal mit ausführlichem Logging angeschaut. Die Ursache für die Schleife ist eine andere als ich dachte. Tatsächlich ist die Neuinterpretation des Query Strings das Erste, was Apache macht. Die wahre Ursache hat mit Subrequests und mod_dir zu tun, aber der Ablauf ist sehr unübersichtlich. Wenn man den Redirect extern abhandelt, gibt es keinen Subrequest und die Versuche mit den DirectoryIndex-Files durchlaufen nicht die RewriteRule. Aber bei einem internen Redirect wird die URL mit index.html bzw. index.php als Subrequest nochmal durch die Rewrite-Regel geschickt, und die matcht dann und das führt in eine Schleife. Man kann das wie oben beschrieben mit dem externen Redirect vermeiden.

Wenn man den Redirect intern haben möchte, damit die lesbarere URL beim User stehenbleibt, dann muss man verhindern, dass die Rewrite-Rule auf index.html oder index.php (oder was man sonst als DirectoryIndex definiert hat) anschlägt. Wenn die Usernamen z.B. keine Punkte enthalten, erweitert man die Regel einfach so: ^([^./]+)/?$. Wenn die Usernamen Punkte enthalten, kann man nur genau das Index-Script so ausschließen:

DirectoryIndex index.php
RewriteEngine ON
RewriteCond %{REQUEST_URI} !index\.php$
RewriteRule ^([^/]+)/?$ /profil/?user=$1 [L]

Das Fragezeichen ist nicht wörtlich gemeint und sollte deshalb nicht seiner Spezialbedeutung beraubt werden. Es macht den Schrägstrich hinter dem Usernamen optional. Die Regex soll USERNAME und USERNAME/ akzeptieren.

Ich würde es mit [R,L] versuchen. Die URL ...de/profil/?user=NUTZERNAME sollte nämlich nicht matchen: Der zu vergleichende Teil der URL ist leer, weil alles bis inklusive profil/ und alles ab inklusive ?user= abgeschnitten wird (Unterverzeichnis und Query String). Aber nach dem Umschreiben ist der neue Query String noch nicht uminterpretiert und damit matcht die Regel. Also die neue URL einmal zum Browser schicken. Wenn sie von dort zurückkommt, geht es nicht in eine Schleife.

Alles ungetestet, viel Glück.

Zitat von bastihase

iptables-mit-ipset

Kleine Warnung: Das ist veraltete Information. Die aktuelle Firewall Technik in Linux heißt nftables und ipset ist damit Geschichte. Es gibt in nftables einen ähnlichen und in gewisser Weise besseren Ersatz, aber der funktioniert etwas anders.

Am zweiten Logausschnitt sieht man, dass das Verlegen des SSH-Ports mittelfristig nichts bringt: Es dauert eine Weile, bis ein Slow Scan den Port entdeckt, aber sobald der gefunden und in den einschlägigen Datenbanken eingetragen ist, werden wieder wild Passwörter durchprobiert. Fail2Ban kann dann auch nicht viel mehr, als Buch darüber zu führen, welche IP-Adressen beteiligt waren. Wenn eine geblockt wird, kommt die nächste und macht weiter. Die Angreifer haben genug Zombies auf der ganzen Welt, um das Spiel ganz schön lange zu spielen.

Wenn du kannst, solltest du die Firewall so einstellen, dass der SSH-Port nur aus Netzen erreichbar ist, die du wahrscheinlich verwenden wirst. Zur Not, wenn du dich damit selbst ausgesperrt hast, kommst du ja trotzdem über die VNC-Console auf den Server. Etwas fortgeschrittener wäre Port Knocking oder ein VPN, damit der SSH-Port gar nicht durch Scannen zu entdecken ist. Andererseits sind diese Logeinträge harmlos, weil sie ja gerade keine erfolgreichen Versuche sind.

In dem Logauszug sieht man, dass anscheinend ein CRON job für den user www-data konfiguriert ist, der alle 5 Minuten ausgeführt wird. Das ist erstmal nicht ungewöhnlich. Ansonsten sieht man noch einen verteilten langsamen Portscan, den deine Firewall aber in dem Auszug komplett filtert. Auch das ist nicht ungewöhnlich für einen Computer, der mit dem Internet verbunden ist.

Hab's überflogen. Wenn du irgendwas daran hilfreich findest, solltest du es lassen. Das ist das übliche Gelaber von einer Maschine, die Text erzeugen soll. Alles Wichtige fehlt, Trivialitäten werden breit ausgerollt und wiederholt, wie hier z.B. DHCP, und mit subtilen Fehlern gespickt, z.B. dass der Proxmox-Host seine IP-Konfiguration per DHCP beziehen soll, oder dass ein in Proxmox vorhandener DHCP-Server deaktiviert werden soll (möglich, aber wer macht Proxmox zum DHCP-Server?). Dafür soll die WAN-Schnittstelle anscheinend fest konfiguriert werden, was auch ziemlich praxisfremd ist. Kein Wort dazu, wie die Netzwerkschnittstellen in die VM kommen.

Man kann Router virtualisieren. Das funktioniert und ist sehr praktisch. Aber man sollte verstehen, was man tut, nicht bei etwas abschreiben, das ohne zu verstehen selbst nur Texte zusammenklaut.

Zitat von Janko

Hmm, nun liegt die Spamkontrolle eigentlich bei mir und diese ist default bei 250Mails/Stunde

Meiner Meinung nach machst du mit diesem Kommentar sehr deutlich, warum solche Überprüfungen absolut notwendig sind. Spam ist in erster Linie ein inhaltliches Problem. Die quantitative Schranke ist nur ein "Not-Stop". Wenn du 250 Mails, die von den Empfängern als unverlangt und störend wahrgenommen werden, an diverse große Mailprovider verschickt hast, ist der angerichtete Schaden schon groß. Das Bewusstsein, wie leicht man bei Empfängern die Grenze zwischen sinnvoller Information und nervender Werbung überschreitet, ist bei vielen Gewerbetreibenden kaum ausgeprägt. Was für den einen ein Newsletter ist, ist für den anderen UCE, und die Trennung verläuft meist scharf zwischen Absender und Empfänger.

org domains... 🤞

Sitejet ist ja nicht ganz billig, vielleicht können die dafür auch ihren Kram etwas supporten.

Gute "SEO" ist hauptsächlich, dass man keinen Blödsinn macht. Grundsätzlich braucht Google wenig Hilfe. Wenn alle Domains einer Website auf eine einzige weiterleiten, reicht das eigentlich aus, um Google davon zu überzeugen, dass diese Domain die wichtige und richtige ist. Aber natürlich haben alle Sorge, dass sie was falsch machen, oder wollen höher gelistet werden, als der Bedeutung ihrer Site gerecht wird, also kassieren SEO-Spezialisten (SEO Coaches?) viel Geld für Handauflegen und Techspeak. Beweisbaren Erfolg müssen sie nicht vorweisen.

Es gibt Gründe für und gegen beides. Ich bevorzuge, die www Domain als kanonisch zu verwenden und die Domain ohne www darauf umzuleiten. Aus technischer Sicht erlaubt das eine klarere Trennung von anderen Subdomains und macht DNS-Einstellungen leichter, weil www keine "Apex-Domain" ist. Wichtig ist aber eigentlich nur, dass du dich für eine der Varianten entscheidest, dabei bleibst und die andere auf die kanonische Domain umleitest.

Wenn du keine anderen Subdomains als www verwendest, solltest du Du solltest im Netcup Webhosting kein Wildcard-Zertifikat einsetzen. Das erneuert sich bei Netcup nicht automatisch und ist für die Absicherung der Domain mit und ohne www nicht nötig.

Zitat von julian-w

Mit jeweils 128MB bzw. 256MB RAM läuft Debian leider nicht mehr auf den Kisten.

Für Alpine ist das mehr als genug Platz. Wie schon erwähnt fühlt sich auch OpenWRT auf den Kistchen wohl. Und wie KB19 nehme auch ich dir die Serverchen sehr gerne ab, wenn du sie nicht mehr brauchst.

Zitat von JuraS

wie lösche bzw. Benenne ich die Index.html?

Im Verwaltungspanel deines Webhostings kannst du im Menü auf der linken Seite unter "Dateien" einen Dateimanager öffnen. Damit kannst du einfache Aufgaben wie Umbenennen oder Löschen einzelner Dateien schnell erledigen. Zum Verwaltungspanel kommst du, indem du im Customercontrolpanel unter Produkte dein Webhostingpaket aufklappst (Lupensymbol anklicken) und dann in der Übersicht auf "Auto-Login WEB" klickst.

Da alle Kaffee getippt haben, sind auch alle im Lostopf.

Das Thema ist Dark Mode, genau richtig für späte Stunden, und "neu" auf der Netcup Webseite.