Beiträge von Bachsau

    So sieht's aus. Man braucht das A+ Rating nicht. Auch die weniger sicheren Ciphers sind noch nie geknackt worden. Das ist alles theoretischer Natur. Für ein A+ Rating musst du so streng sein, dass mit vielen Clients keine Verbindung mehr zustande kommt. Zum Rumprobieren ganz nett, aber praktisch hast du nichts davon, außer dass du dir ein schönes Badge ansehen kannst. Ehrlich, pfeif' auf's Rating und schau dir die Details an: Gibt es Warnungen zu Lücken, die nicht geschlossen sind, und handeln auch alle Browser die für sie bestmögliche Suite aus?

    Der Fake-Server könnte den Key ignorieren und die Passwort-Authentifizierung verlangen.

    Vorausgesetzt man hat die aktiviert. Da ich die Passwörter der Accounts nicht im Kopf habe und der Client ebenfalls so konfiguriert ist, dass er bei meinen Servern keine PasswordAuthentication zulässt, würde ich sofort merken, dass was faul ist. Wenn die Passphrase zum Schlüssel einem Angreifer bekannt würde, hätte er davon auch herzlich wenig, weil er den Schlüssel nicht hat, und in der Zwischenzeit hätte ich dafür gesorgt, dass der, der das versucht hat, sich nie wieder auf irgendeinem Weg auf dem Server einloggt. :D Und dann ist da noch der Host-Key, auf den ein unprivilegierter Nutzer keinen Zugriff hat.

    Insofern wohl zu vernachlässigen.

    So sieht's aus. ;)

    Ich hab' schon mit MaxStartups 3:30:10 ohne Probleme gearbeitet. Zur Zeit verwende ich 10:30:30. Wenn man das nur selbst nutzt, reicht es locker. LoginGraceTime kann man auch auf drei Sekunden runter setzen, wenn man nur mit Schlüsseln einloggt.


    Wenn der Port belegt ist, kann ein nicht privilegierter Benutzer darauf nichts starten. Sollte der Daemon doch aus irgendeinem Grund mal nicht laufen, und es jemandem gelingen, bringt ihm das bei der Authentifizierung mittels öffentlichem Schlüssel ebenfalls nichts.


    Prinzipiell ist SSH schon von Haus aus sehr sicher. Da muss man nichts mehr davor murksen, um irgendwas sicherer zu machen.

    Sicherer wird's dadurch nicht, aber man verhindert auf jeden Fall, dass Bots den Server die ganze Zeit mit Loginversuchen traktieren, was Ressourcen frisst und Logs füllt. Da ich den abweichenden Port in meine ssh.conf eingetragen habe, merke ich davon kaum noch was.

    wp-content umschreiben brachte leider auch nichts. Wollte jetzt via phpMyAdmin den Pfad zu "httpdocs/fokks/wp-content/nfwlog/ninjafirewall.php" anpassen, wusste jetzt aber nicht genau wo ich den Eintrag in der Datenbank finde.

    Sollte in der "options" Tabelle sein. Den SQL-Query hatte ich hier schon gepostet.

    Auch wenn alles gut aussieht, kann es sein das die ganzen Verlinkungen noch zur alten Seite zeigen, weil die in der DB verdrahtet sind.

    Um die zu ändern gibt es Plugins die das erledigen oder man macht es über die Kommandozeile mit wp-cli.phar

    In so einem Fall würde ich das vorher einfach im Dump ersetzen.Aber die Domain soll hier ja garnicht geändert werden.

    Habe jetzt auch nochmal die Datenbank exportiert/importiert.

    Grundlagenwissen? Du wirst die betreffenden Teile der Datenbank schon anpassen müssen! Neu importieren bringt da wenig.


    Und ich dachte immer, Wordpress sei so einfach, dass es jeder kann.

    Es ist schon recht einfach. Aber dieses eine Plugin scheint irgendwo absolute Pfade zu nutzen. Da muss man dann halt schon mal in's phpMyAdmin gehen und das ausbessern.

    Den Dokumentenstamm im Kundencenter stellst du auf das Verzeichnis, wo deine Wordpress-Installation liegt, also da wo die index.php ist.


    Die Pfade zum Webspace speichert WordPress in der Datenbank.

    SQL
    SELECT * FROM `wp_options` WHERE `option_value` LIKE '%web886%';


    Wenn's dann läuft und du deine Permalinks wieder haben willst, leg' wieder eine .htaccess direkt im WordPress-Verzeichnis an, und schreib das rein:

    Code
    FallbackResource /index.php

    Ob ein bestimmtes grafisches Tool jetzt jede Konfiguration unterstützt oder nicht, ist ein ganz anderes Thema. An sich hab' ich nichts gegen grafische Werkzeuge, auch wenn ich sie nicht auf einem Server installieren würde. Das Problem bei grafischen Werkzeugen ist aber, dass sie meist lange nicht an die Möglichkeiten heran kommen, die man auf der Kommandozeile hat. Gparted kann dir z.B. Dateisysteme anlegen, aber man hat keine Kontrolle über die dafür verwendeten Parameter. Um LVM komplett zu unterstützen, bräuchte man ein eigenes Tool. Ich kenne zwar das von KDE nicht, aber es würde mich wundern, wenn es auch nur einen Bruchteil von dem unterstützte, was mit LVM möglich ist. Das liegt zum Einen daran, dass die Entwicklung grafischer Oberflächen sehr viel aufwändiger ist (ich kenne GTK+), und zum Anderen daran, dass sie oft für die Zielgruppe der weniger versierten Benutzer entwickelt werden, weshalb man eher auf Automatiken setzt, um den Benutzer nicht zu überfordern.

    Live-Migration wird z.B. darüber gemacht, aber auch Speicherverwaltung ("ballooning"). Betriebssysteme wie Linux sind zunächst mal auf physikalische Hardware ausgelegt. Es gibt aber einiges, das innerhalb einer virtualisierten Umgebung besser und damit performanter gelöst werden kann, wenn es in Absprache mit dem Hypervisor geregelt werden kann. Das Stichwort heißt hier Paravirtualisierung. Deshalb gibt es den Guest-Agent, und der sollte immer aktiviert sein. Darin ein Sicherheitsrisiko zu sehen, ist ungerechtfertigte Paranoia. Der Hypervisor hat die VM sowieso in der Hand.


    Was das starten des Daemons angeht, so ist es zumindest bei Debian so, dass dieser mit Hilfe von Udev gestartet wird, sobald die dafür notwendige Schnittstelle zur Verfügung steht. Das bedeutet leider auch, dass er beendet wird, wenn man das Target mit Hilfe von `systemctl isolate` wechselt. Aber üblicherweise macht man das ja eher selten, so dass er nach der Installation des Pakets eigentlich von selbst aktiviert sein sollte.

    LVM ist im Grunde eine flexiblere Version einer Partitionstabelle. Innerhalb eines verschlüsselten Containers ist das nützlich, weil man dadurch halt mehrere Dateisysteme in einen einzelnen LUKS-Container packen kann. Aber man kann es auch einsetzen, um ein RAID zu bauen, oder einfach um flexibel zu sein. Ich setze es hier auch nicht ein, da ich finde, dass es bei einer so simplen Konfiguration keine Vorteile bringt, aber das kann jeder für sich entscheiden. Es schadet jedenfalls nicht.


    Ich glaube, die Netcup-Images setzen auch auf LVM. Von verschiedenen Volumes oder Partitions für Systemverzeichnisse bin ich aber weg gekommen, da es meiner Erfahrung nach eher stört als Vorteile bringt. Den Speicherplatz von Benutzern kann man über Quotas besser beschränken.

    Wenn du das zusätzliche Level nicht in dein Zertifikat aufnehmen kannst: Gar nicht. HTTP passiert ja erst innerhalb der TLS-Verbindung. Das Zertifikat wird also geprüft, bevor die Anfrage überhaupt ausgewertet wird. Das "Versehen" kannst du leicht vermeiden, indem du solche DNS-Einträge einfach nicht anbietest.

    Marketing ist das passende Stichwort. ;)

    Käufliches Vertrauen. Ich wage zu behaupten, dass 99% aller Besucher sich das ohnehin niemals ansehen. Wichtig ist eigentlich nur, dass man ein Zertifikat nutzt, das zur Domain passt und im Trust-Store ist.


    BTW: Warum heißt das Netcup-Wiki eigentlich "Wiki", wenn man es nicht bearbeiten kann? Es wäre doch eigentlich ganz schön, wenn auch versierte Kunden dort Dinge ausbessern oder aktualisieren könnten.

    Hier ist ein Beispiel für eine statische Netzwerk-Konfiguration mittels systemd-networkd. Man legt einfach eine Datei unter "/etc/systemd/network/20-netcup.network" an, und schreibt soetwas rein:

    MAC-Adresse, IPs und Gateway müssen natürlich entsprechend den Angaben im Kundencenter angepasst werden. Bei der IPv6 hängt man einfach das gewünschte Suffix an, wie hier im Beispiel die "::1".