Projekt

Allgemein

Profil

Aktionen

Aufgabe #1714

offen

Verbesserungsvorschläge proxy für tls für www (cms (plone))

Von PaulRiegel vor 9 Monaten hinzugefügt. Vor 9 Monaten aktualisiert.

Status:
Neu
Priorität:
Normal
Zugewiesen an:
Kategorie:
Instanz Plone
Beginn:
13.08.2023
Abgabedatum:
31.08.2023 (seit etwa 8 Monaten verspätet)
% erledigt:

0%

Geschätzter Aufwand:

Beschreibung

spontane Verbesserungsvorschläge (zur "Missverkonfiguration")

habe gerade mal "zufällig"
top
gemacht.


dhcpcd läuft da?

systemctl status dhcpcd.service

running? (beim setzen einer bestimmten adresse für ip?)

aus meiner sicht gehört das ausgeschaltet.


ipv6 ist aktiviert?

ip a

aus meiner sicht gehört das (leider) ausgeschaltet.


der container versteht sich als stura?

hostname

aus meiner sicht wäre www richtiger.


sind da (bewusst) andere recommended*_Settings_, neben
recommendedProxySettings
nicht aktiviert?

aus meiner sicht könnten (sollten) immer auch die anderen "recommended_*_Settings_" aktiviert sein (, außer ein bestimmter Grund spricht dagegen).


sind irgendwo die gemachten änderungen (wesentliche erhöhung der größe von dateien die hochgeladen werden dürfen) von der alten instanz (tkl nginx) "vermerkt"?


der port für ssh muss offen sein, wegen deployment als flake, oder?


Aktionen #1

Von GoeranHeinemann vor 9 Monaten aktualisiert

In der von nix generierten dhcpd config ist eth0 deaktiviert, weil es eine feste IP zugewiesen hat, da dachte ich dass das nicht explizit deaktiviert werden muss. Daher kommt auch die IPv6 Adresse, weil die glaube ich per slaac random generiert wird.

IPv6 ist nicht explizit deaktiviert und hat nur eine fe80 LinkLocal Adresse, die ist von nirgends erreichbar, können wir gerne ausschalten, erschien mir nur nicht wichtig, da alle Firewall regeln auch hier greifen. Das einzige was aus meiner sicht an der Stelle zu verbessern wäre, ist nftables statt iptables zu verwenden, um wirklich einheitliche Firewall regeln zu haben.

Der hostname muss stura sein, weil sonst die generierung von letsencrypt Zertifikaten nicht über den fqdn gemacht werden kann. www.stura wird als alternativer Name mit vom Zertifikat abgedeckt (serverAliases).

Die recomended Nginx settings werden in der gesamten StuRa-Flake allen systemen aus den nixosModules/default/nginx.nix vererbt.

Der ssh-Port ist für das deployment offen, akzeptiert aber nur Login mit Public-Key, das stellt solange keine NSA-edcsa Kurven mit Backdoor verwendet werden :D meiner Meinung nach kein Risiko dar (außer der Mossad hat da einen 0Day). Man könnte gerne fail2ban oder so aktivieren, alternativ bietet sich Port-Knocking an, das müsste auch mit der Firewall gehen, habe ich nur noch nicht gemacht.

Aktionen #2

Von SoerenBoxberger vor 9 Monaten aktualisiert

was den Hostnamen angeht, sollte doch www möglich sein, wenn die Domain stura.htw-dresden.de lautet. Der fqdn ist der selbe und dann wird eben stura.htw-dresden.de als Alias verwendet.

Aktionen #3

Von SoerenBoxberger vor 9 Monaten aktualisiert

was den Hostnamen angeht, sollte doch www möglich sein, wenn die Domain stura.htw-dresden.de lautet. Der fqdn ist der selbe und dann wird eben stura.htw-dresden.de als Alias verwendet.

Aktionen #4

Von SoerenBoxberger vor 9 Monaten aktualisiert

was den Hostnamen angeht, sollte doch www möglich sein, wenn die Domain stura.htw-dresden.de lautet. Der fqdn ist der selbe und dann wird eben stura.htw-dresden.de als Alias verwendet.

Aktionen #5

Von SoerenBoxberger vor 9 Monaten aktualisiert

was den Hostnamen angeht, sollte doch www möglich sein, wenn die Domain stura.htw-dresden.de lautet. Der fqdn ist der selbe und dann wird eben stura.htw-dresden.de als Alias verwendet.

Aktionen

Auch abrufbar als: Atom PDF