FreeBSD Installation auf Dedicated Server: V 13 vs 12.2(3)

testit

Well-Known Member
Hallo,

ich möchte auf einer "frischen" Maschine (headless Server) ein FreeBSD aufsetzen. Auf einer anderen habe ich 12.2 (12.3 steht ja inzwischen bereit!) laufen und bin damit eigentlich zufrieden!

Würdet Ihr an meiner Stelle aus irgendwelchen Gründen bei einer Neuinstallation trotzdem zur 13er raten?

Falls ja: Für Tipps, die ich gleich bei der Installation der 13er berücksichtigen könnte/sollte wäre ich dankbar.

Die Maschine hat 64GB RAM und zwei 4TB-HDDs, die ich als Softwareraid laufen lassen möchte.

Ehrlich gesagt, müsste ich mich auch mit ZFS einmal mehr beschäftigen.
Ist hinsichtlich ZFS schon bei der Installation etwas zu beachten, was ich ansonsten später nur mit mehr Aufwand korrigieren könnte?


Herzlichen Dank und viele Grüße
testit
 
Würdet Ihr an meiner Stelle aus irgendwelchen Gründen bei einer Neuinstallation trotzdem zur 13er raten?
Andersrum: es gibt keinen Grund, 13 nicht zu nehmen.

Die Maschine hat 64GB RAM und zwei 4TB-HDDs, die ich als Softwareraid laufen lassen möchte.
Das ist ordentlich. Auch das schreit danach, ZFS zu nutzen. (Was dagegen spricht, ist nur dass du dich damit noch nicht beschäftigt hast)

Ist hinsichtlich ZFS schon bei der Installation etwas zu beachten, was ich ansonsten später nur mit mehr Aufwand korrigieren könnte?
Überlege dir im Vorfeld, ob du Verschlüsselung nutzen möchtest (normalerweise sollte und will man das, der Installer nimmt dir alles ab). Du musst nur sicherstellen, dass du das PW vor der Netzverbindung anderweitig eingeben kannst (wegen headless).
Aber auch nicht schlimm, dann installiert man eben erneut frisch, das stellt sich ja dann direkt raus.
 
Wenn du keine Features von 13.0 brauchst spricht erstmal nichts dafür. Andererseits spricht auch nichts dagegen wie @mr44er schon richtig angemerkt hat.

Du machst einen neuen Server, wirst sowieso alles neu einrichten und testen. Da kanns auch gleich 13.0 sein. Damit erhältst du länger Updates. Einzig was dagegensprechen würde, wenn du fixe Configs vom 12.2er übernehmen möchtest (und die nicht so einfach auf 13.0 Funktionieren), oder du irgendwelche fertigen Testcases für 12.2 hast.
 
Das ist ordentlich. Auch das schreit danach, ZFS zu nutzen. (Was dagegen spricht, ist nur dass du dich damit noch nicht beschäftigt hast)

Das spricht erst einmal prinzipiell nicht dagegen, da ich ZFS schon mehrere Jahre auf einem anderen Server einsetze.
Allerdings bin ich mir sicher, dass ich die Möglichkeiten von ZFS viel zu wenig ausreize, weswegen ich mich nun einmal etwas näher damit beschäftigen möchte.

Überlege dir im Vorfeld, ob du Verschlüsselung nutzen möchtest (normalerweise sollte und will man das, der Installer nimmt dir alles ab).
Wenn ich mir diesen Thread durchlese, bin ich mir nicht so sicher, ob ich die Verschlüsselung nutzen sollte.
@Satriani hatte sich seinerzeit zunächst ja wohl auch erst einmal hinauskatapultiert, nachdem er das OpenZFS installiert und rebootet hat.

Korrigiert mich, wenn ich falsch liege: Aber eine derartige Verschlüsselung bringt einem ja "nur" bei Abhandenkommen des Datenträgers etwas.
Zur Laufzeit sind die auf dem verschlüsselten Datenträger befindlichen Daten ja trotzdem problemlos und somit auch für Exploits u. ä. lesbar.

BTW: Ich suche immer noch eine Lösung, mit der E-Mails auf dem Datenträger verschlüsselt abgelegt werden und erst zum Zeitpunkt der Abfrage durch den Client "on the fly" entschlüsselt werden.

Du musst nur sicherstellen, dass du das PW vor der Netzverbindung anderweitig eingeben kannst (wegen headless).
Kannst Du mir bitte genauer sagen, wie Du das meinst?

Danke und viele Grüße
testit
 
Wenn du keine Features von 13.0 brauchst spricht erstmal nichts dafür. Andererseits spricht auch nichts dagegen wie @mr44er schon richtig angemerkt hat.

Du machst einen neuen Server, wirst sowieso alles neu einrichten und testen. Da kanns auch gleich 13.0 sein. Damit erhältst du länger Updates. Einzig was dagegensprechen würde, wenn du fixe Configs vom 12.2er übernehmen möchtest (und die nicht so einfach auf 13.0 Funktionieren), oder du irgendwelche fertigen Testcases für 12.2 hast.
In der Tat habe ich ein paar VMs mit dem GuestOS FreeBSD 12.2 laufen. Ich empfinde es als sehr angenehm, vorr größeren Updates/Upgrades, Konfigurationsänderungen usw. am Host OS alles erst einmal in der VM "vorwegzunehmen" und die Hürden zu nehmen, um die so gesammelten Erfahrungen dann für den HOST zu nutzen.

Viele Grüße
testit
 
Wenn ich mir diesen Thread durchlese, bin ich mir nicht so sicher, ob ich die Verschlüsselung nutzen sollte.
@Satriani hatte sich seinerzeit zunächst ja wohl auch erst einmal hinauskatapultiert, nachdem er das OpenZFS installiert und rebootet hat.

Korrigiert mich, wenn ich falsch liege: Aber eine derartige Verschlüsselung bringt einem ja "nur" bei Abhandenkommen des Datenträgers etwas.
Zur Laufzeit sind die auf dem verschlüsselten Datenträger befindlichen Daten ja trotzdem problemlos und somit auch für Exploits u. ä. lesbar.

Das ist erstmal korrekt. Aber auf modernen Rechnern "kostet" dich die Verschlüsselung auch nichts. Im schimmsten Fall bringt es dir nichts und du hast beim installieren 10 Min mehr Aufwand. Im "besten" Fall wirst du oder das RZ ausgeraubt und die Diebe können die Daten nicht lesen. Oder Hausdurchsuchung oder ähnliches. Gabs ja alles schon.

Probleme mit Verschlüsselung gibts eigentlich nicht, ich verschlüssle meine BSD Systeme seit 8.0er Zeiten.

BTW: Ich suche immer noch eine Lösung, mit der E-Mails auf dem Datenträger verschlüsselt abgelegt werden und erst zum Zeitpunkt der Abfrage durch den Client "on the fly" entschlüsselt werden.


Kannst Du mir bitte genauer sagen, wie Du das meinst?

Danke und viele Grüße
testit

Es gibt Webmailer die das können. Ansonsten aber PGP oder eben kein Mail nutzen. Hilft leider nicht, für solche Anwendungen ist Mail kacke.

Er meint - bei einer Vollverschlüsselung must du beim booten irgendwie das PW eingeben. Du hast da ja noch kein SSH. Aber wenn der Rechner bei dir ist, kannst du das ja über eine Tastatur eingeben. Falls RZ, hat jedes ordentliche RZ eine remoteconsole.
 
Er meint - bei einer Vollverschlüsselung must du beim booten irgendwie das PW eingeben. Du hast da ja noch kein SSH. Aber wenn der Rechner bei dir ist, kannst du das ja über eine Tastatur eingeben. Falls RZ, hat jedes ordentliche RZ eine remoteconsole.
Ich würde über ein Rescue-System vom gleichen Anbieter installieren und rebooten müssen, wie in dem von mir angesprochenen Thread.
Daher meine "Nervosität"! :D

Ich müsste folglich beim Rebooten wohl auf eine KVM zurückgreifen, um das Passwort eingeben zu können.
Und auch bei späteren FreeBSD Upgrades, die ein Reboot voraussetzen, hätte ich ja immer wieder das Problem, eine KVM ordern zu müssen.

Vielleicht wäre für mich die bessere Alternative, die VM-interne Verschlüsselungsmöglichkeit zu nutzen, die unabhängig vom Host ist.


Viele Grüße
testit
 
Ich glaube in dem Szenario macht "Verschlüselung" nur dann sinn wenn du einen sicheren weg hast dann nach nem neustart auch das Kennwort einzugeben.

Das ist bei den meisten Hostern eher nicht der Fall.

Der Schutz ist hier vor allem gegen manipulationen (ink. auslesen aber nicht exklusiv) durch den Hoster selbts und ggf. dritte (Behören?) die Zugang zum RZ des hosters und damit auch auf deinen Server haben. Wie wichtig dir das ist, und ob so jemand nicht ggf. diverse weitere Methoden anwenden könnte um das Kennwort auszulesen (USB-Logger etc bei der KVM Lösung etc) ... ganz ehrlich: Ich würde das nicht machen und auf die Verschlüsselung verzichten.
 
Allerdings bin ich mir sicher, dass ich die Möglichkeiten von ZFS viel zu wenig ausreize, weswegen ich mich nun einmal etwas näher damit beschäftigen möchte.
Du musst sie ja nicht 'aktiv' ausreizen. Es reicht ja schon als Vorteil, wenn du z.B. checksums und compression auf Blockebene 'passiv' bekommst. Wenn du später ZFS einsetzen willst und hast aber auf ein anderes FS installiert, wäre das so eine Einbahnstraße, die du vermeiden willst (nach dem, was ich so rauslese).

Wenn ich mir diesen Thread durchlese, bin ich mir nicht so sicher, ob ich die Verschlüsselung nutzen sollte.
@Satriani hatte sich seinerzeit zunächst ja wohl auch erst einmal hinauskatapultiert, nachdem er das OpenZFS installiert und rebootet hat.
Der Thread ist bald zwei Jahre alt, es geht um 12.1 auf 12.2 mit Modulwechsel. Das passiert mit 13 nicht, weil openzfs schon verwendet wird.

Korrigiert mich, wenn ich falsch liege: Aber eine derartige Verschlüsselung bringt einem ja "nur" bei Abhandenkommen des Datenträgers etwas.
Zur Laufzeit sind die auf dem verschlüsselten Datenträger befindlichen Daten ja trotzdem problemlos und somit auch für Exploits u. ä. lesbar.
Das stimmt so. Daher ja die Überlegung, ob du es haben willst oder nicht. Ich rate dazu, weil es nichts kostet und das Fitzelchen Sicherheit gegen Diebstahl bietet. Man hat ja auch Versicherungen abgeschlossen, obwohl nie was passiert ist und die bezahlt man sogar.
Abraten würde ich nur, wenn es eine lahme Krücke mit 20 Jahren auf dem Buckel ohne aesni ist oder du notorischer Passwortvergesser bist, das rescue system nicht existiert oder wenn du dem nicht vertraust. Wie auch immer, schädlich sehe ich Verschlüsselung nicht.

Kannst Du mir bitte genauer sagen, wie Du das meinst?
Wie verwaltest du den Server im nicht hochgefahrenen Zustand aus der Ferne? Kommst du aus der Ferne ins BIOS? IPMI oder sowas? Wenn ja, gibts kein Problem mit der Passworteingabe. Ich meine, wenn der Server vor Boot auf die Passworteingabe wartet, ob dir das ein Problem bereitet, weil du headless erwähntest.
 
Ich glaube in dem Szenario macht "Verschlüselung" nur dann sinn wenn du einen sicheren weg hast dann nach nem neustart auch das Kennwort einzugeben.

Das ist bei den meisten Hostern eher nicht der Fall.

Dann würde ich den Hoster wechseln, eigentlich hat man überall eine Management Konsole. Ich würde Hetzner empfehlen, die sind auch halbwegs BSD kompetent.
 
Hallo,

ich hatte doch oben bereits erwähnt, dass eine KVM-Konsole angefordert werden kann.
Allerdings möchte man so etwas ja auch nicht überstrapazieren. Spezielle ZFS-Features würde ich lieber erst einmal in den FreeBSD-VMs testen.

Aktuell tendiere ich eher dazu, die VM-interne-Verschlüsselung zu nutzen. Da wird auch beim Start nach dem Key gefragt, was aber in diesem Kontext dann kein Problem ist. Und wenn der "Host"-Datenträger im Rechenzentrum in der Tat einmal "abhanden" käme, wäre die VM-Disk trotzdem gecrypted.

Die "on-the-fly"-Verschlüsselung der IMAP-Mail-Dateien interessiert mich, weil man natürlich heutzutage beim Einsatz gängiger Open Source Lösungen immer damit rechnen muss, dass durch einen Exploit die Mail-Dateien ausgelesen werden.

Viele Grüße
testit
 
ich hatte doch oben bereits erwähnt, dass eine KVM-Konsole angefordert werden kann.
Allerdings möchte man so etwas ja auch nicht überstrapazieren.
Normalerweise hat man das als Feature dabei. Ohne Zeitbegrenzung, ohne den Support anstupsen zu müssen.

Dann würde ich den Hoster wechseln, eigentlich hat man überall eine Management Konsole.
Exakt.
 
Normalerweise hat man das als Feature dabei. Ohne Zeitbegrenzung, ohne den Support anstupsen zu müssen.
Eine Rescue-Konsole JA, eine KVM dagegen nicht!
Dies ist auch bei Hetzner nicht anders:
Die Anzahl an KVM-Konsolen ist in den RZs begrenzt. Wir empfehlen Kunden im Voraus über den Robot eine KVM-Konsole zu bestellen.
Quelle: https://docs.hetzner.com/de/robot/dedicated-server/maintainance/kvm-console/

Viele Grüße
testit
 
Also ich würde auch sagen, bei meiner Recherche, das ein server mit eingebauter MGMT-Löung (Inkl. KVM-Over-IP zb) oder Serial zumindest) erst preislich dteutlich, deutlich höher anfängt als zb so ein basis-hetzner-server u.ä.

Hinzu kommt halt, wenn du das Ding für jeden reboot anfordert, ob du dem Ding selbst vertraust. Das sind ja dann externe Lösungen wenn sie nicht eingebaut sind. Der markt dafür ist sagen wir mal überschaubar, und sicherheitsupdates für die Firmware (Dubios zusammengeschustertes Linux o.ä. was drauf läuft) gibts alle 2-5 Jahre.

Und da es ja sehr stark darum geht das man dem Hoster und/oder Behören misstraust, kannst du natürlich nicht wissen ob er nen USB-Keylogger dazwischen schaltet oder sonst wie zb was direkt an der Firmware des Servers manipuliert etc.

Wenn man da sehr hohe Sicherheitsansprüche hat macht es vermutlich mehr sinn selbst einen Server mit integrierter MGMT Lösung zu kaufen und den irgendwo unterzubringen, was dann aber auch wieder (so) recht teuer ist. Ich glaube aber das ist insb. für den "privaten" und "kleinere Firmen" Bereich etwas übertrieben.

(Warum es sinn macht die VMs zu verschlüsseln den Host aber nicht ergibt sich mir so garnicht. Wenn ich zugriff das das Host-System habe kann ich doch mega entspannt alles machen um auch auf die VMs bzw deren Schlüssel etc zuzugreifen - das einzige szenario wo das alles mir wirklich relevant erscheint ist das der Hoster versehentlich den Server außer Betrieb nimmt und ihn oder die Platten einem weiteren Kunden ohne Löschung zu verfügung stellt, also kein Angriff sondern (ggf. auch eigene) Schusseligkeit)
 
Ich müsste folglich beim Rebooten wohl auf eine KVM zurückgreifen, um das Passwort eingeben zu können.
Und auch bei späteren FreeBSD Upgrades, die ein Reboot voraussetzen, hätte ich ja immer wieder das Problem, eine KVM ordern zu müssen.
Eine Möglichkeit wäre hier noch, erst ein unverschlüsseltes Minimalsystem zu booten, das keinerlei sensible Daten enthält, sich dort einzuloggen, das eigentliche System zu entsperren und dann dieses mit reboot -r zu starten. So mache ich das bei meinem verschlüsselten, kleinen FreeBSD Server.
 
...

(Warum es sinn macht die VMs zu verschlüsseln den Host aber nicht ergibt sich mir so garnicht. Wenn ich zugriff das das Host-System habe kann ich doch mega entspannt alles machen um auch auf die VMs bzw deren Schlüssel etc zuzugreifen - das einzige szenario wo das alles mir wirklich relevant erscheint ist das der Hoster versehentlich den Server außer Betrieb nimmt und ihn oder die Platten einem weiteren Kunden ohne Löschung zu verfügung stellt, also kein Angriff sondern (ggf. auch eigene) Schusseligkeit)
Genau um Letzters geht es aber: Wenn ein unverschlüsselter Datenträger Dritten, die man selbst nicht als befugt einstuft, in die Hände fällt!
Und natürlich hast Du hier für die VM den gleichen Vorteil der Verschlüsselung wie Du ihn beim Verschlüsseln des Hosts hättest: Beim Nutzen des Datenträgers und Starten der VM ist ebenso bei einem verschlüsselten Datenträger (inkl. Boot-Partition) zunächst das Passwort einzugeben.

Verlagert man folglich sensible Daten in das "verschlüsselte" Gastbetriebssystem, hat man den gleichen Effekt erzielt wie bei einer Verschlüsselung des HOSTS, unter dem die VM läuft, wenn die Platte nicht mehr im System eingebunden ist, sondern bspw. ausgebaut wird.

Letztlich nutzt das alles aber nichts, wenn die eigentlichen "Angriffe" zur Laufzeit erfolgen und innerhalb des Systems durch Exploits etc. auf die entschlüsselten Daten zugegriffen werden kann.

Viele Grüße
testit
 
Eine Rescue-Konsole JA, eine KVM dagegen nicht!
Dies ist auch bei Hetzner nicht anders:

Quelle: https://docs.hetzner.com/de/robot/dedicated-server/maintainance/kvm-console/

Viele Grüße
testit

An die günstigen Dedicated bei Hetzner hab ich jetzt grad garnicht gedachte, aber ist es da nicht sowieso besser einen Cloudserver zu verwenden? Bzw. mehrere wenn du sowieso alles in VMs packen möchtest?

Ansonsten haben die "ordetnlichen" dedicated Server natürlich Fernzugriff dabei, richtige Serverhardware gibts eigentlich auch nicht ohne auf dem Markt. Ich rede hier nicht von KVM Consolen auf die man irgendwie zugriff bekommt, sondern ein Managementbard direkt im Server wie Lightsout oder Drac.
 
An die günstigen Dedicated bei Hetzner hab ich jetzt grad garnicht gedachte, aber ist es da nicht sowieso besser einen Cloudserver zu verwenden? Bzw. mehrere wenn du sowieso alles in VMs packen möchtest?

Ich packe nicht ALLES in VMs!

Ansonsten haben die "ordetnlichen" dedicated Server natürlich Fernzugriff dabei, richtige Serverhardware gibts eigentlich auch nicht ohne auf dem Markt. Ich rede hier nicht von KVM Consolen auf die man irgendwie zugriff bekommt, sondern ein Managementbard direkt im Server wie Lightsout oder Drac.
Nun, man kann halt nicht alles haben: Einigermaßen kostengünstig und trotzdem angemessen performant!
Und wenn ich mir überlege, wie selten ich bspw. HPE iLO im Jahr benötige, weil keine andere Zugriffsmöglichkeit mehr existiert, ist das KVM-Konsolensharing m. E. absolut zu verkraften.

Viele Grüße
testit
 
Zurück
Oben