Beiträge von Andi22

    Ich habe gerade einen weiteren Wiki.js-Server aufgesetzt, und dieses Mal in /var/www/wikijs installiert. Allerdings habe ich den Fehler gemacht und nvm in das home meines sudo zu installieren. node befindet sich somit unter /home/bud/.nvm/versions/node/v18.18.1/bin/node. Diesen Pfad habe ich dann in der config.yml unter /var/www/wikijs angegeben. Ist das schlimm / falsch?

    Ich würde Dir davon abraten das so zu machen, und statt dessen node entweder von https://deb.nodesource.com/ oder von Deiner Distribution installieren.


    wiki.js soll ja als System-Dienst laufen. Wenn ein wichtiger Teil der Ressourcen in einem normalen Benutzer-Konto liegen, muss man immer daran denken, dass man da nichts kaputt macht.

    Die lieben Seiteneffekte halt ;)


    Zum Beispiel könnte Dir jemand raten Dein Benutzerverzeichnis zu verschlüsseln, oder ...

    Wenn dann wiki.js plötzlich nicht mehr tut, fällt einem das zwar schnell wieder ein, aber dann ist es schon zu spät und man hat extra Aufwand.

    Und wenn jemand anderes die Administration übernommen hat, muss der zuerst einmal debuggen, oder im wiki nachlesen, wo es zwar hoffentlich dokumentiert ist, aber das jetzt ja nicht mehr geht :P


    Ein weiterer Vorteil von einem der obengenannten Repositories ist, dass Du Sicherheitsupdates einfach über apt update/upgrade bekommst.

    Mit nvm musst Du Dich extra darum kümmern. z.B. mittels:

    Code
    nvm install node --reinstall-packages-from=node
    # oder
    nvm install "lts/*" --reinstall-packages-from="$(nvm current)"

    Und das muss dann natürlich mit Deinem bud User passieren. Wenn eine anderer user (z.B. terence) das macht, hat das ja keine Auswirkung auf das verwendete node.


    Dass Dein User bud sudo-Rechte hat ist hier übrigens egal. Das gibt Deinem User nur die Möglichkeit Befehle als anderer User (root) auszuführen.

    Da über die letzten Wochen oder teilweise gar Monate meine fail2ban´s auf 6 Servern nichts gebannt haben, bin ich ein bisschen misstrauisch geworden. Oder habe ich einfach nur Glück?

    Auf jeden Fall wollte ich es an einem Server selbst testen, und habe einfach mal bei folgenden Regeln fünfmal telnet IP Port versucht.

    Hattest Du nicht Deinen SSH-Port geändert?


    Dann kann es Monate dauern bis die Deinen Server finden und Login-Versuche starten.


    fail2ban bannt ja nur dann, wenn es Angriffe gab. Das kannst Du selbst auch checken indem Du in die Logs schaust:


    Code
    journalctl -u ssh
    
    # oder falls vorhanden
    
    more /var/log/auth.log

    Wenn Du einen Angriff simulieren willst, kannst Du versuchen dich mit SSH, einem nicht vorhandenen Benutzer und/oder falschen Passwort anzumelden. Nicht vergessen Deinen Port mit anzugeben:


    Code
    ssh -p 12345 wronguser@server


    Kannst das ja von einem Deiner anderen Server aus machen, statt von Deiner IP daheim. Dann kannst Du Dich immer noch einloggen.


    Vergiss folgenden Satz. Du hattest es ja 5 mal versucht: Außerdem reicht ein Versuch nicht aus. Du musst den Login mehrfach versuchen, oder maxretry auf 1 setzen.


    Außerdem solltest Du noch


    Code
    [sshd]
    port    = 12345 #was-auch-immer-dein-port-ist


    hinzufügen.

    Ich würde ihn ausschalten, um ihn dann wieder anzuschalten sobald ich die Zeit finde, ein paar Anwendungen zu testen, die mich schon lange interessieren.

    So wie ich mich kenne, ist das 1 Tag vor Ablauf des kostenlosen Jahres ;(


    ich würde ihn an joas für sein vorhaben abtreten.


    Das hört sich doch auch gut an.

    Dann mach ich meine Tests in der ersten Woche und geb ihn dann an joas weiter.

    Das ist in der Konfigurationsdatei des Nodes schon so realisiert.

    Dort muss man die ip des Masters freigeben, nur dorthin gibt munin dann über 4949 was raus.

    Das ist ja vorbildlich. Super!


    Man sollte halt nichts zu Sachen schreiben die man nicht kennt :D


    Wegen dem Thema eigene Distro installieren:


    Genau für solche Situationen wollte ich mal netboot.xyz ausprobieren. https://github.com/netbootxyz/netboot.xyz

    Vielleicht hat ja jemand Lust das mal zu probieren, und dann zu berichten ;)


    Einfach im laufenden System, oder in der Rettungskonsole (/dev/sda evtl anpassen)

    Code

    Code
    wget https://boot.netboot.xyz/ipxe/netboot.xyz.img
    
    dd if=netboot.xyz.img of=/dev/sda
    
    sync
    
    reboot

    Und dann nach dem reboot das system auswählen dass man installieren möchte.

    Sollte theoretisch funktionieren (Hoffe ich :whistling: )

    ich habe nochmals eine Fragen zu Munin. An meinem Master-Munin verwende ich eine Sub-Domain (per DNS A-Record eingerichtet) welche https verwendet und hinter einer htaccess sich befindet.


    Muss ich auf den node welche ich hinzufüge (jeweils an den node auch noch was explizit zwecks Web absichern wenn ich keine Sub-Domain jeweils eingerichtet habe?

    Ich kenne munin nicht, aber ich hab in den letzten Posts gesehen, dass die Nodes über Port 4949 angesprochen werden.

    Keine Ahnung, wie munin das absichert, aber da jeder im Internet auf den Port zugreifen kann, könnte das ein potentielles Sicherheitsrisiko darstellen.


    Da aber in dem Fall ganz genau bekannt ist, wer auf den Port zugreifen will, kann man das in der Firewall sehr gut absichern:


    indem man per default deny hat, und dann


    Code
    sudo ufw allow from 1.2.3.4 to any port 4949

    Wobei 1.2.3.4 die IP des masters sein sollte. dann kann nur der darauf zugreifen.


    Für den master selbst, da er ja auch ein Node ist, wäre das dann


    Code
    sudo ufw allow from 127.0.0.1 to any port 4949


    Gegebenenfalls noch IPv6, aber das scheint hier ja nicht zu gehen.


    So würde ich das zumindest machen :)

    Ich schlafe nochmal drüber, aber ich denke, ich breche das an der Stelle ab und kündige den Server wieder. Das installierte Debian-System umzubauen ist mir zu viel Aufwand, falls es denn überhaupt funktionieren würde. Wo ich auch hinschaue, die Unterschiede zu meinen bestehenden Servern sind groß. Oder kann man vielleicht irgendwie ein System selbst komplett neu installieren, netinstall oder so? Also abgesehen von den vorgegebenen Images. Ich fürchte nein, finde jedenfalls nichts, was darauf hindeuten würde. Geht wohl nur bei den Cloudservern.


    Genau für solche Situationen wollte ich mal netboot.xyz ausprobieren. https://github.com/netbootxyz/netboot.xyz

    Vielleicht hast Du ja Lust das mal zu probieren, und dann zu berichten ;)


    Einfach im laufenden System, oder in der Rettungskonsole (/dev/sda evtl anpassen)

    Code
    wget https://boot.netboot.xyz/ipxe/netboot.xyz.img
    
    dd if=netboot.xyz.img of=/dev/sda
    
    sync
    
    reboot

    Und dann nach dem reboot das system auswählen dass Du installieren möchtest.

    Sollte theoretisch funktionieren (Hoffe ich :whistling: )

    Brauch ich mit Docker eigentlich Apache und seine Geschwister?

    Das hängt davon ab was Du machen möchtest.

    Zum einen wirst Du wahrscheinlich Docker Images verwenden die Apache intern verwenden,

    zum anderen kannst Du Docker und ein mit apt installierten Apache gleichzeitig betreiben wenn Du das willst.

    z.B. weil Du eine Anwendung verwenden möchtest die es noch nicht als Docker Image gibt (und Du kein eigenes Image erstellen möchtest).

    Oder auch schlichtweg aus historischen Gründen.


    Zuerst einmal ist es wichtig zu verstehen, was Docker überhaupt ist/macht.


    Ein Docker Image beinhaltet alle Programme, Bibliotheken, Daten, ... die es benötigt um ein Programm laufen zu lassen.

    Ein Image könnte z.B. ein komplettes Debian Minimal mit installiertem Apache+PHP+MariaDB sowie Deinen PHP-Dateien enthalten.

    Ein Programm zu installieren kann recht aufwändig sein, weil es viele Voraussetzungen haben kann.

    Wenn Du z.B. Nextcloud in einer aktuellen Version installieren möchtest musst Du z.B. Apache,PHP, eine Datenbank,... installieren.

    Also viele Dienste die Du per apt-get installieren musst, Berechtigungen anpassen, ...


    Darum hat sich der Maintainer eines Docker Images schon gekümmert.


    Du hast auf Seite 9 aufgelistet was Du bisher alles gemacht hast. Diese Befehle könnte man auch verwenden um ein eigenes Docker Image daraus zu machen, das dann genau das selbe kann, wie Deine jetzige Installation eben.


    Außerdem kann es auf einem Server auch noch Probleme mit den Abhängigkeiten geben.

    Vielleicht benötigt das aktuelle Nextcloud mindesten PHP 8. Du hast aber gerade nur PHP 7.4.

    Also installierst Du mittels sury.org PHP 8.

    Leider hast Du noch eine andere PHP Anwendung am Laufen, die PHP 8 noch nicht unterstützt.

    Und schon hast Du ein Problem.


    Wenn die Anwendungen allerdings als Docker Images vorliegen bringt jedes Image ja alles mit was es braucht. Also Nextcloud PHP 8 und die ominöse andere Anwendung PHP 7.


    Um wieder auf Deine ursprüngliche Frage zurück zu kommen. Da viele Images Apache enthalten ist es auf jeden Fall eine gute Idee die Grundlagen der Apache Konfiguration zu kennen. Das kann helfen die Konfiguration solcher Docker Images besser zu verstehen.


    Da dadurch evtl mehrere Apache, Nginx, etc gleichzeitig laufen, aber nur ein Programm sich an Port 80 (bzw 443) binden kann benötigt man noch einen Proxy, der sich dann an den Port bindet und die Datenpakete an die entsprechenden Docker Anwendungen verteilt. z.B. der bereits hier erwähnte https://github.com/NginxProxyManager/nginx-proxy-manager.


    Ich würde jetzt am liebsten noch etwas zum Thema Sicherheitsupdates schreiben.

    Aber dazu habe ich heute keine Zeit mehr.


    Nur noch schnell zu dem Thema: So wie Du derzeit "sudo ufw default deny outgoing" verwendest würde ich nicht glücklich werden. Solange das ohne Ausnahmen aktiv ist hat Dein Server keine Verbindung ins Internet. Es können nicht nur keine Sicherheitsupdate mit apt update/upgrade installiert werden, auch vieles anderes tut nicht, wie z.B. DNS Abfragen. Das kann z.B. bei einem Nginx der als Proxy mit Domainnamen verwendet wird dazu führen, dass Nginx nicht mehr startet.


    P.S: Oh je, oh je, ich merk gerade, dass ich wohl etwas übers Ziel hinaus geschossen bin :whistling:

    Ich hoffe es hilft Dir trotzdem.

    Ich nehme an, du willst keinen kompletten Mailserver aufsetzen? (Falls doch, viel "Spaß" :evil: )

    Also nur die Möglichkeit des Versenden von Systemmails vom Server und kein Empfang?

    Dann ist das keine große Sache,

    Das nehme ich auch an.

    Ich verweise einfach mal auf meinen ersten Post. Da hab ich die config gepostet um das mit msmtp zu erledigen.

    Das sieht doch schon mal echt gut aus.

    Ich muss mir nachher nochmal den ganzen Thread duchlesen.


    Neuere PHP Versionen gibt es von https://packages.sury.org/php/README.txt

    Das ist übrigens einer der Debian PHP Maintainer. Also vertrauenswürdig.


    In 5 Wochen (10.6) kommt übrigens Debian 12 raus. Da ist dann PHP8.2 mit dabei


    Den 80er Port darfst Du nicht zumachen, weil darüber alle 2 Monate das neue Zertifikat verifiziert wird. Die Letsencrypt Zertifikate sind ja nur 3 Monate lang gültig

    Doch, da geht aber iirc kein Copy Paste

    Wenn ich zum Tippen keine Lust habe, bzw für Befehle die ich oft in VNC o.ä. benötige, lege ich einen Eintrag in KeePassXC (https://keepassxc.org/) an.


    Dann kann ich mittels "Auto-Ausfüllen" den Befehl tippen lassen.


    Ist zwar mehr Aufwand als direktes Copy&Paste, aber immer noch weniger als die Befehle selbst zu tippen.


    Und damit ich bei den komischen Benutzernamen (also den Befehlen) nicht durcheinander komme hab ich ne extra Keepass-Datenbank dafür :D

    KeePass sollte das auch können. Aber ich bevorzuge halt KeePassXC :)

    Zusätzlich zu oben genanntem haben die RS mehr CPU-Features durchgereicht.

    Es gab hier z.B. einen Thread dass neuere MongoDB Versionen auf den VPS nicht mehr laufen (wegen fehlendem AVX).


    Hier noch ein paar Benchmark-Werte meiner Server. Mein RS G7 ist schneller als die VPS G8 (pro Core).


    Geekbench 5 (Single / Multi Core)


    vps500 G8 2 vCores 490 817
    vps 200 G8 1 vCores 486 483
    rs1000 G7 plus (6core xeon E5-2680 v4 6 Kerne 694 3177
    rs1000 G9.5 (EPYC 7702P) 4 Kerne 1003 3692



    Zu den ersten Schritten auf einem neuen Server zählen bei mir:


    - eigenen Benutzer anlegen und sudo Rechte geben (Mach ich schon während der Installation)


    - SSH: Passwörter verbieten, nur noch Keys erlauben.

    Wenn man das nicht macht (und gute Passwörter verwendet) geht die Welt nicht unter. Trotzdem empfehlenswert.


    - SSH: root verbieten, und mittels 'AllowUsers username1 username2' nur bestimmte user den SSH Zugang erlauben.

    Auch hier geht die Welt nicht unter, aber wenn man root nicht verbietet hat der Angreifer schon mal einen existierenden User. Also die halbe Miete ;)


    - SSH: Port ändern.

    Reduziert die Anzahl der Logeinträge enorm, bzw entlastet den Server von unnötigen Arbeiten.


    - evtl fail2ban damit Angreifer eine Zeit lang blockiert werden.


    - Firewall (ufw) installieren und nur die benötigten Ports öffnen.

    Wie oben, auch hier geht die Welt nicht unter wenn man es (noch) nicht sofort macht.


    - Mailversand einrichten, damit man mails vom System bekommen kann.

    z.B. mittels postfix oder für den Anfang leichter: msmtp (https://wiki.debian.org/msmtp)

    In der msmtp config trägt man die SMTP Daten von einem ganz normalen Netcup Mailkonto ein (Username:passort).


    Und jetzt noch das für mich wichtigste, und ein guter Grund den Mailversand einzurichten:


    - unattended-upgrades (https://wiki.debian.org/UnattendedUpgrades) (apt install unattended-upgrades apt-listchanges)

    Damit werden die updates automatisch eingespielt, und wenn man es konfiguriert bekommt man Mails was getan wurde, und ob ein reboot notwendig ist.

    Selbst wenn man ein paar Monate keine Zeit hat sich um den Server zu kümmern, muss man sich mit unattended-upgrades keine große Sorgen machen.

    Es gibt ein minimales Risiko dass durch ein Update etwas nicht mehr richtig tut, ohne dass man es sofort merkt. Ist mir aber in vielen Jahren mit diversen Servern noch nie passiert.


    - backup mittels borg-backup. https://github.com/witten/borgmatic ist hierzu ein beliebtes script (apt install borgmatic)

    Gibt natürlich auch viele andere Backup Lösungen.


    Ich wünsch Dir viel Erfolg und Spaß mit Deinem Server :)



    Nochmal das Wichtigste (alle Befehle als root, oder mittels sudo):


    Wenn Du keine mail willst, sollte folgendes funktionieren:

    sudo apt install --no-install-recommends fail2ban


    Weil mailx keine dependency ist. Siehe https://packages.debian.org/bullseye/fail2ban


    iptables/nftables, ... musst Du dann halt noch dazu installieren.

    Mhh ok danke.


    Gibt es generell eine Möglichkeit bei einem normalen Webserver eine persistant connection mit z.B. ssh aufzubauen (die eine PHP Seite dauerhaft offen hat).

    Also das ich z.B. darüber einen RCON Chat auslesen kann und diesen zumindest in eine Datenbank schreiben kann?

    Du könntest im Webhosting einen Cronjob anlegen, der regelmäßig ein Script aufruft.

    Mit dem Script kannst Du dann die gewünschten Daten herunterladen und in die Datenbank schreiben.

    Ist zwar nicht persistent, sollte aber für den Zweck ausreichen.

    Ich fühle mich gerade richtig blöd. Hab gar nicht an die gesetzten Berechtigungen gedacht ^^

    Das löst zwar dieses Problem, aber leider sehen die Benutzer dann direkt alles in dem Ordner. Ist natürlich sowieso öffentlich erreichbar, aber könnte nach einer Weile schon recht chaotisch werden im eigenen Client (ShareX) :/


    Damit könnte ich aber prinzipiell leben, falls es nicht doch noch einen anderen Kniff gibt.

    Muss es zwingend mit SFTP sein, oder ginge auch eine Lösung mit einem kleinen golang Programm, in dem man dann die User verwaltet?

    https://github.com/filebrowser/filebrowser


    Edit: Wenn man zu vorschnell antwortet. Hab gerade erst gesehen, dass Du nur das löschen verhindern willst. Ich weiß nicht, ob das mit filebrowser geht. Also doch keine Lösung

    Wie verschlüsselt ihr auf Windows, wenn ihr etwas in der Cloud speichern wollt? zB um physischen Einbrüchen zuvorzukommen.

    Ich verwende entweder https://cryptomator.org/ (kommt aus Dutschland) oder https://github.com/bailey27/cppcryptfs (USA)


    Beide enthalten Filesystemtreiber die jede Datei einzeln verschlüsseln, und lassen sich so leicht synchronisieren. Die unverschlüsselten Dateien werden unter einem Laufwerksbuchstaben bereit gestellt.

    Beide kann man z.B: auch unter Linux verwenden, wobei cppcryptfs ein C++ Clone von gocryptfs (Österreich) ist.


    Auf der Seite von gocryptfs gibt es einen (etwas älteren) Vergleich von verschiedenen Datei Verschlüsselungsfilesystemen mit einigen sehr interessanten Infos, u.a. Geschwindigkeitsvergleich, Programmiersprache, verwendete Verschlüsselung, ...:

    https://nuetzlich.net/gocryptfs/comparison/

    Und falls Du ein großes verschlüsseltes Image möchtest, dann ist VeraCrypt der Klassiker.

    Auch bei verschlüsselten Partitionen?
    Meiner Erfahrung nach geht das nicht.

    Ich hab gerade auf einem LUKS verschlüsselten Rootserver einen Snapshot ausprobiert, und es hat funktioniert.


    Ist allerdings LVM/Ext4, und nicht BTRFS.

    OS ist Debian 11


    Speichernutzung 5 GiB von 60 GiB belegt


    fstrim/discard funktioniert bei mir.


    Ich hab die Image Sektoren allerdings nicht mit random Werten initialisieren lassen.


    dmsetup table zeigt bei mir, dass allow_discards aktiv ist.


    Womit bewiesen wäre, dass es mit verschlüsselten Partitionen prinzipiell geht :)