Server administrieren - wo fange ich an?

Paul · 12. September 2023

Zitat von Bud
In /etc/apache2/sites-available/
Code: apache2 -t -D DUMP_VHOSTS
bud@netcup:~$ sudo apache2 -t -D DUMP_VHOSTS
[Tue Sep 12 10:29:52.120864 2023] [core:warn] [pid 1443791] AH00111: Config variable ${APACHE_RUN_DIR} is not defined
apache2: Syntax error on line 80 of /etc/apache2/apache2.conf: DefaultRuntimeDir must be a valid directory, absolute or relative to ServerRoot
DefaultRuntimeDir ist ${APACHE_RUN_DIR}

In /etc/apache2/envvars habe ich dazu folgendes gefunden:
Code
export APACHE_RUN_DIR=/var/run/apache2$SUFFIX
Und daraus werde ich dann spätestens nicht mehr schlau...

Edit: Ich verstehe nicht, warum mein Apache bei dem Fehler problemlos läuft. Das macht doch keinen Sinn, oder?
Alles anzeigen

Ich vermute, Apache liest die /etc/apache/envvars nur, wenn du den apache2ctl Befehl ausführst. Könnte sein, dass apache2 selbst das gar nicht berücksichtigt (nur ein Schuss ins Blaue). Kannst du die gleichen Befehle mal mit apache2ctl ausführen?

Ich habe in meiner apache2.conf "DefaultRuntimeDir" gar nicht explizit gesetzt. Evtl. ging es daher bei mir.

Bud · 12. September 2023

Tatsächlich, hat funktioniert.

Code

VirtualHost configuration:
*:443                  example.com (/etc/apache2/sites-enabled/000-default-le-ssl.conf:2)
*:80                   example.com (/etc/apache2/sites-enabled/example.com.conf:1)

Aufgrund der Ausgabe vermute ich das er zuerst den Port 443 und die dafür hinterlegte Konfigurationsdatei 000-default-le-ssl.conf anschaut, und deswegen gar nicht zum Port 80 weiter? Den sonst müsste meine Config ja funktionieren, was sie aktuell leider nicht tut. Also muss ich den ReverseProxy in die 443-Conf bereits mit einbauen?

Spoiler anzeigen

Ecki · 12. September 2023

Das hats DU gemacht ?

sudo a2enmod proxy

sudo a2enmod rewrite

dann sollte die Konfig eigentlich funktionieren.

Paul · 12. September 2023

Super. Das ist doch schon mal gut. Die Datei wird also geladen. Die Reihenfolge spielt bei den Ports keine Rolle. Wenn du auf Port 80 zugreifst, dann sollte der vHost auch geladen werden. Die wird in der Ausgabe nur alphabetisch anhand des Dateinamens angezeigt.

Zitat von Bud

Leider funktioniert mein Reverse Proxy mit Apache nicht.

Was passiert denn, wenn du die Seite aufrufst? Was genau funktioniert denn nicht?

Bud · 12. September 2023

Zitat von Ecki

Das hats DU gemacht ?

sudo a2enmod proxy

sudo a2enmod rewrite

dann sollte die Konfig eigentlich funktionieren.

Alles anzeigen

Code

bud@netcup:~$ sudo a2enmod proxy
Module proxy already enabled
bud@netcup:~$ sudo a2enmod rewrite
Module rewrite already enabled

Leider ein Griff ins Leere... Hat keine Änderung gebracht.

Zitat von Paul

Super. Das ist doch schon mal gut. Die Datei wird also geladen. Die Reihenfolge spielt bei den Ports keine Rolle. Wenn du auf Port 80 zugreifst, dann sollte der vHost auch geladen werden. Die wird in der Ausgabe nur alphabetisch anhand des Dateinamens angezeigt.

Aber müsste ich meinen ReverseProxy dann nicht für 443 erstellen? Denn wenn jemand auf http:// zugreift, wird er ja automatisch auf https:// umgeleitet, und dann greift die 443-Conf?

Zitat von Paul

Was passiert denn, wenn du die Seite aufrufst? Was genau funktioniert denn nicht?

Wenn ich die Domain aufrufe, funktioniert das Zertifikat und ich sehe die Apache2 Debian Default Page.

Stattdessen versuche ich Wiki.js unter Port 3000 dort anzeigen zu lassen.

Paul · 12. September 2023

Achso. Ja, wenn du dein Wiki über https erreichen willst, musst du dafür natürlich auch einen vHost mit Port 443 konfigurieren (analog zu 80). In diesem wird dann aber auch der Pfad zum SSL Zertifikat benötigt. Ich dachte, dir geht es erst einmal nur um die generelle Erreichbarkeit über Port 80. Aber moderne Browser gehen mittlerweile ja direkt auf https, sobald das der Server unterstützt. Daher bekommst du in diesem wohl auch die Apache Status Seite. Hast du denn bereits ein Zertifikat erfolgreich beantragt? Denn ohne kannst du den Port 443 vHost nicht konfigurieren.

Ich würde aber als erstes mal mit curl die Seite auf der Shell aufrufen und schauen, was da zurück kommt, zumindest um dein reverse proxy Setup zu verifizieren.

Bud · 12. September 2023

Vielen lieben Dank Paul , es funktioniert!

Nachdem ich...

Code

ProxyPass / http://***.***.***.***:3000/
ProxyPassReverse / http://***.***.***.***:3000/
ProxyRequests Off

...in die Conf für 443 hinzugefügt habe, hat es auf Anhieb funktioniert. Das Zertifikat hatte ich ja vorher schon.

Mal wieder ein Denkfehler von mir, aber einer bei dem ein bisschen was dazugelernt habe. Danke euch!

Aber, zwei Fragen habe ich gleich noch im Anschluss:

Sollte ich statt http:// nicht lieber https:// in die Conf schreiben?

Und ist es egal wo welches Argument dieser Conf steht?

Hat die Reihenfolge irgendeine Relevanz?

Paul · 12. September 2023

Prima, freut mich zu hören

Zitat von Bud

Sollte ich statt http:// nicht lieber https:// in die Conf schreiben?

Nein, das ist schon ok. Das ist ja nur das Protokoll ins "Backend", sprich die Verbindung von Apache zu dem Node Webserver. Die läuft unverschlüsselt. Ist aber ok, ist ja derselbe Server. Die Verbindung zum User ist ja dann https. Daher passt das schon. Sonst müsste dein Wikijs selbst auch nochmal SSL terminieren. Wäre technisch möglich, wäre in diesem Fall aber unnötig.

Die Reihenfolge ist in diesem Fall egal, da brauchst du dir keine Gedanken machen.

hoedlmoser · 13. September 2023

Zitat von Bud

ProxyPass / http://***.***.***.***:3000/

dein wiki.js läuft aber schon auf der selben maschine, oder? dann kannst statt der IP localhost oder 127.0.0.1 angeben. denn wenn der proxy funktioniert willst Du eigentlich nicht mehr, dass wiki.js auf der öffentlichen IP am port 3000 lauscht sondern nur mehr eben am localhost.

Bud · 13. September 2023

Zitat von hoedlmoser

dein wiki.js läuft aber schon auf der selben maschine, oder? dann kannst statt der IP localhost oder 127.0.0.1 angeben. denn wenn der proxy funktioniert willst Du eigentlich nicht mehr, dass wiki.js auf der öffentlichen IP am port 3000 lauscht sondern nur mehr eben am localhost.

Danke für den Hinweis, habe ich geändert

Mir ist auf meinem Smartphone unter Safari aufgefallen, dass in der Fußzeile Nicht sicher - example.com steht. SSL Labs bringt mir als Overall Rating ein A - wie kann ich der Sache auf die Spur gehen?

Summary

Bud · 13. September 2023

Gerade gesehen das bei mir im "normalen" Browser das Zertifikat anerkannt wird, aber im Gastmodus nicht. Woran kann das liegen?

RAD750 · 13. September 2023

Vielleicht hängt das Zertifikat im Cache, im Gastmodus wird der Cache aber ignoriert. Wäre ein indiz, dass etwas mit dem Zertifikat nicht in Ordnung ist.

Paul · 13. September 2023

Wie rufst du die Seite denn auf? Schon mit https://, oder? Du hast ja im Moment deinen vHost auf Port 80 ebenfalls noch offen. Dort könntest du (da jetzt der https vHost funktioniert), einen http->https redirect einrichten. Das wäre jetzt mal das erste, was mir einfallen würde.

Um das zu erreichen kannst du in deinem Port 80 vHost die ganze Proxy Konfiguration raus nehmen und stattdessen das hier eintragen

Code

Redirect / https://deine.wiki.url/

Bekommst du im Gastmodus das Apache Default Zertifikat angezeigt?

Bud · 13. September 2023

Bevor ich mich mit euren Antworten befasse, kurze Frage vorab. Ich habe in /etc/apache2/sites-available/ vier Dateien:

000-default.conf
000-default-le-ssl.conf
example.com.conf
default-ssl.conf

Kann ich die 000-default.conf und default-ssl.conf löschen?

Kann ich die 000-default-le-ssl.conf einfach in example.com-ssl.conf umbenennen?

Wenn ich das richtig verstehe, gibt es für jede (Sub-)Domain zwei Konfigurationen, eine für den Port 80 und ggf. noch eine für den Port 443, richtig?

Bud · 14. September 2023

Hab den Unterschied zwischen sites-available und sites-enabled mittlerweile auch verstanden

Allerdings ergab der Redirect keine Wirkung. Ein Apache Zertifikat wurde mir nicht angezeigt.

Code

<VirtualHost *:80>

    ServerAdmin apache@example.com

    DocumentRoot /var/www/html
    ServerName example.com
    ServerAlias www.example.com

    # ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:3000/
    ProxyPassReverse / http://127.0.0.1:3000/
    ProxyRequests Off

    Redirect / https://example.com/

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

</VirtualHost>

Alles anzeigen

Code

<IfModule mod_ssl.c>

    <VirtualHost *:443>

        ServerAdmin apache@example.com

        DocumentRoot /var/www/html
        ServerName example.com
        ServerAlias www.example.com

        ProxyPass / http://127.0.0.1:3000/
        ProxyPassReverse / http://127.0.0.1:3000/
        ProxyRequests Off

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

        Include /etc/letsencrypt/options-ssl-apache.conf
        SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

    </VirtualHost>

</IfModule>

Alles anzeigen

Bud · 15. September 2023

Woran kann es liegen, dass UptimeKuma mir meldet, dass ein Server (kurz) down war, aber der Server selbst sagt, er ist durchgehend gelaufen?

UptimeKuma - Telegram

Code

bud@pangar:~$ uptime
 09:17:52 up 20 days, 22:39,  1 user,  load average: 0,16, 0,03, 0,01

aRaphael · 15. September 2023

Dass man ihn nicht anpingen konnte, heißt ja nicht unbedingt dass er komplett down war.

Evtl. waren es nur Netzwerkprobleme.

TBT · 15. September 2023

Hatte ich auch gestern um 19:42 bis 19:44 Uhr Richtung heimischer Internetzugang, obwohl da nix down war.

Bud · 23. September 2023

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.

Code

[DEFAULT]
bantime = 24h
findtime = 10m
maxretry = 3

[sshd]
enabled = true
backend = systemd

[recidive]
enabled = true

Alles anzeigen

Das Ergebnis war: Nichts. Hätte fail2ban mich nicht aussperren müssen? Laut sudo systemctl status fail2ban ist auf allen Servern alles in Ordnung...

Code

● fail2ban.service - Fail2Ban Service
     Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; preset: enabled)
     Active: active (running) since Thu 2023-08-17 16:33:33 CEST; 1 month 6 days ago
       Docs: man:fail2ban(1)
   Main PID: 9458 (fail2ban-server)
      Tasks: 7 (limit: 1028)
     Memory: 17.2M
        CPU: 34min 51.727s
     CGroup: /system.slice/fail2ban.service
             └─9458 /usr/bin/python3 /usr/bin/fail2ban-server -xf start

Aug 17 16:33:33 atlantis systemd[1]: Started fail2ban.service - Fail2Ban Service.
Aug 17 16:33:33 atlantis fail2ban-server[9458]: 2023-08-17 14:33:33,584 fail2ban.configreader   [9458]: WARNING 'allowipv6' not defined in 'Definition'. Using default one: 'auto'
Aug 17 16:33:33 atlantis fail2ban-server[9458]: Server ready

Alles anzeigen

tab · 23. September 2023

Welches OS und welche Version hast du installiert? Wird da ins Journal geloggt oder hast du noch "klassische" Logfiles? Das "backend = systemd" überwacht das Journal und nicht die auth.log soweit ich weiss. Ausserdem, ich glaube nicht, dass ein einfaches telnet auf den SSH Port schon reicht, oder hast du auch ein falsches Passwort eingegeben? Dass allerdings auf 6 Servern monatelang gar nichts gebannt wird deutet schon darauf hin, dass eventuell was schief läuft. Andererseits, viele "Angreifer" sind vorsichtig geworden und benutzen Botnetze anstatt einfach brute force Zugangsdaten auszuprobieren mit ein und derselben IP. Teilweise probieren sie es nur zweimal mit der selben IP oder mit längeren Zeitabständen. Was sagt die fail2ban.log? Wurden Versuche erkannt? Existiert sie überhaupt?

Server administrieren - wo fange ich an?

Ähnliche Themen

vServer - Webserver absichern gegen Bad IPs

OS Reinstall "stuck"

Netcup Vps Problem

Windows Server als Terminal Server

Windows Server 2019 & Wireguard

WindowsServer19: nach Juni 22 Patchday kein NAT + RDP über VPN möglich