Sicherheit der Default FreeBSD 12 qcow2-Installation

G

ghostfish

Well-Known Member
Hallo zusammen,

ich würde gerne als kleines Lernprojekt und nicht zuletzt auch aus praktischen Gründen (Hosten von TeamSpeak und später vielleicht einer kleinen PHP-Seite) einen virtuellen Server mieten und dort FreeBSD installieren (das wäre bei dem Anbieter wohl das "FreeBSD-12.0-RELEASE-amd64.qcow2.xz"-Image für KVM).

Während es auf OpenBSD.org heißt: "Only two remote holes in the default install, in a heck of a long time!" legt FreeBSD meines Wissens andere Schwerpunkte. Ich bewundere das OpenBSD-Projekt und einige der offiziellen Unterprojekte (LibreSSL, OpenSSH, Pf) sehr, aber als Neuling ist es vielleicht (auch in Anbetracht der verfügbaren Ports) sinnvoller, mit FreeBSD zu starten.

Jetzt zu meiner Frage: sichert ihr eure FreeBSD-Installation auf einem vom Internet aus zugänglichen System in besonderer Weise ab? Und falls ja, wie sehen diese Sicherungsmaßnahmen aus?
Ich hatte mir überlegt, als grundlegende Maßnahme alle nicht benötigten Ports zu schließen, und mit fortschreitendem Wissen (über die offizielle Dokumentation, die Bücher von Michael Warren Lucas und diesem Forum) dann nach und nach gegebenenfalls weitere Maßnahmen (vielleicht dem Ausschalten nicht benötigter Deamons oder ähnliches) zu ergreifen.

Ist dieser Ansatz riskant? Über hilfreiche Kommentare wäre ich sehr dankbar! :)

Viele Grüße
 
Bin kein FreeBSD experte, aber ich denke so generell macht man so fast nichts falsch, als Ergänzung evtl. noch:
  • Lange Passwörter verwenden, beim SSH vill. gleich nur noch schlüssel erlauben.
  • Auf die richtigen Dateisystemrechte / Ownership achten
  • Die Software aktuell halten - Webserver (Apache?), PHP, PHP-Anwendungen, Teamspeak sowieso, aber auch den rest.
Denke damit dürfte man das "gros" generischer Angriffe und auch durchaus den ein-oder-anderen gezielten abwehren können.

Ich verwende zusätzlich für meinen OpenBSD Webserver zuhause eine ähnlich installierte Testumgebung, bei der ich die Updates von Webanwendungen e.t.c. erstmal auf dem trockenen übe.
 
Hallo ghostfish,

zu den erwähnten Dingen würde ich bei der Installation von Diensten darauf achten, dass die nur auf IP-Adressen lauschen, die wirklich nötig sind, eventuell reichen ja auch Sockets. In der Regel muss z.B. ein DB-Server nur vom Webserver aus erreichbar sein und nicht von außen. Für den administrativen Zugriff gibt es SSH-Tunnel. Apropos SSH, da würde ich nur den Login mit Schlüsseln erlauben, wenn Passwörter, dann nur mit 2FA. Ach, und ich würde das System auf eine verschlüsselte Partition installieren, wenn Du beim Systemstart die Passphrase eingeben kannst.

Eventuell auch über Jails nachdenken, wenn Du Dienste mit Webanwendungen aus fremden Quellen hosten willst. Ich pack alles in eigene Jails rein. Bei meinem Server laufen z.B. 5 Webserver in jeweils einem eigenen Jail plus ein Jail für den DB-Server. Ob man den 'Aufwand' treiben muss, sei dahin gestellt.
Sollten es mehrere Anwendungen sein, die auch eine DB benötigen, dann pro Anwendung eine DB mit eigenen DB-Usern, die nur an ihrer DB minimale Rechte zum Betrieb haben. Auf keinen Fall einen root Account anlegen und darüber laufen alle Datenbankverbindungen. Damit bekommt man die Anwendung zwar schnell an den Start, aber ein Einbrecher kann genauso schnell alles auf einen Schlag hopsnehmen.

Und nicht vergessen, regelmäßige Backups machen.
 
ghostfish schrieb:
Jetzt zu meiner Frage: sichert ihr eure FreeBSD-Installation auf einem vom Internet aus zugänglichen System in besonderer Weise ab? Und falls ja, wie sehen diese Sicherungsmaßnahmen aus?
Zum Vergrößern anklicken....
so etwas habe ich nicht und kenne mich auch nicht aus. Das muss ich vorweg sagen, damit kein falscher Eindruck entsteht.

ghostfish schrieb:
Ich hatte mir überlegt, als grundlegende Maßnahme alle nicht benötigten Ports zu schließen,
Zum Vergrößern anklicken....
Ich glaube nicht, dass bei FreeBSD irgendwelche Ports offen sind, die nicht auch benutzt werden, zu denen also nicht auch ein Service gestartet ist. Ich wüsste auch nicht wirklich, wie so etwas überhaupt aussehen oder funktionieren sollte. Wenn doch kein Service läuft, wie soll dann denn ein Port genutzt werden? Wofür auch immer.
Zudem gibt es in FreeBSD auch mehrere Möglichkeiten für Firewalls. Persönlich bin ich aber überzeugt, dass Firewalls dort laufen müssen, wo der Verkehr zum fremden Netz stattfindet und nicht auf meinem Endgerät im heimischen Netz. Deshalb kenne ich mich auch damit nicht aus, ich nutze so etwas nicht auf meinen PCs.

ghostfish schrieb:
Während es auf OpenBSD.org heißt: "Only two remote holes in the default install, in a heck of a long time!" legt FreeBSD meines Wissens andere Schwerpunkte. Ich bewundere das OpenBSD-Projekt und einige der offiziellen Unterprojekte (LibreSSL, OpenSSH, Pf) sehr, aber als Neuling ist es vielleicht (auch in Anbetracht der verfügbaren Ports) sinnvoller, mit FreeBSD zu starten.
Zum Vergrößern anklicken....
Der OpenBSD-Satz ist Reklame und sollte so verstanden werden. Es gibt "fast nie" irgendwelche Remoten-Löcher in einer Basis-Installation. Woher sollten die denn auch kommen. Alles, was dann auf dem System läuft und Services zur Verfügung stellt, hat ja quasi (fast) nichts mehr mit dem System zu tun. Wenn du Apache als Webserver nutzt, ist der unter FreeBSD oder OpenBSD oder GNU/Linux gleich (meiner bescheidenen Erfahrungen nach eher in FreeBSD sogar aktueller) und das soll nur ein Beispiel sein. Egal, was auch immer, es ist zum größten Teil third-Party-SW, die ein System erst mal zu einem brauchbaren System macht. Das Basis-System macht ja so gut wie nichts.
Damit will ich den Sicherheitsbestrebungen und der (wie ich mühsam gelernt habe) hoch stehenden Code-Kultur nicht die Bedeutung nehmen. Auch ich bewundere das und nehme es auch ernst. Kann aber pragmatisch betrachtet für mich als Endanwender (immer noch) keinen Vorteil ableiten.
Ich vergesse so schnell. Wie hießen diese Dinger letztens, die die Welt in Aufruhr versetzten? Spectre und Meltdown oder so? Wo Lücken bei Intel und AMD entdeckt wurden und wo auch OpenBSD betroffen war, obwohl die ja genau über solche Schwachstellen schon seit Jahren nachgedacht hatten. Auch sie mussten einen Patch liefern und machten das auch, nur eben etwas langsamer, als andere Systeme. Klar, die haben nicht die Man-Power und die wollen es dann auch ganz genau machen und das kostet eben Zeit. Ich verstehe das, ich respektiere das, ich mag das, aber unterm Strich hätte ich mich mit OpenBSD damals etwas länger ungeschützt fühlen müssen, als mit manchen anderen Systemen. Ich glaube, damals waren GNU/Linux am schnellsten, aber das will ja wirklich nichts heißen.

Denn: all dies zeigt ja nur, dass es tatsächliche Sicherheit innerhalb der IT nicht gibt.
Damit will ich keinesfalls sagen, dass man dann auch nicht darüber nachdenken sollte, wie man sie sicher machen kann und nochmal: ich mag das OpenBSD-Projekt alleine deshalb schon sehr. Aber es genügt einfach nicht, OpenBSD zu nehmen und sich dann sicher zu fühlen. Die Gefahren, die FreeBSD vielleicht gegenüber OpenBSD mehr mitbringt oder auch ein GNU/Linux gegenüber OpenBSD anfälliger macht, sind im Vergleich zu den Gefahren, die aus den weiteren Anwendungen kommen, allesamt zu vernachlässigen.
Meiner Meinung nach.

An der Stelle möchte ich dann auch noch auf https://hardenedbsd.org/ hinweisen (ich hoffe, auf die Schnelle den richtigen Link genommen zu haben). Die wollen FreeBSD auch sicherer einstellen. Davon kann man sich auch für sein eigenes FreeBSD durchaus einiges ab-schauen, finde ich. Man muss vielleicht nicht alles übernehmen, aber mich hat das durchaus nachdenklich gemacht und auch meine Einstellungen dann beeinflusst.
 
Es gilt bei FreeBSD dasselbe wie bei allen Systemen, die am Internet hängen: SSH nur mit Schlüssel, das ist schon mal die halbe Miete, und dann eine Firewall benutzen, die standardmäßig erstmal alles blockt. Dann noch sshguard oder sowas in der Art verwenden, um potentielle Angreifer direkt zu blockieren.

Ansonsten was die anderen schon sagten: Software aktuell halten und keine unnötigen Ports öffnen.
 
Vielen Dank für die ganzen hilfreichen Beiträge! :)

@CommanderZed:
Das sind sehr gute Anregungen und ich werde versuchen, über Gruppenmitgliedschaften nur die notwendigsten Zugriffe einzuräumen. Der Punkt mit der Software ist tatsächlich mit ein Grund dafür, dass ich einen virtuellen Server mieten möchte und nicht auf eine fertige Lösung zurückgreifen.. Wenn beispielsweise eine neue PHP Version erscheint, möchte ich diese schnellstmöglich nutzen oder auch eigene Erweiterungen wie beispielsweise die für OpenPGP einbinden können.
Dabei hatte ich mir auch einen Ansatz wie in deinem OpenBSD-System vorgestellt, also ein nahezu identisches System im lokalen Netz, um zu testen, ob die eingesetzte Software und Konfiguration überhaupt funktioniert wie erhofft.

@crotchmaster:
Den Zugriff auf bestimmte IPs zu beschränken ist eine Idee, die ich grundsätzlich für sehr sinnvoll erachte, aber da ich mich selbst über einen VPN-Server einwähle, kenne ich im Vorfeld meine eigene IP-Adresse gar nicht. Eventuell könnte ich aber eine IP-Range freischalten, sofern dann noch genug ausgeschlossen werden, um einen Sicherheitsgewinn zu erzielen.
Ich kenne mich allerdings leider noch nicht besonders gut aus, was die ganze Netzwerkthematik anbelangt.. wenn es also einen guten Ansatz für genau diesen Fall gibt, wäre ich sehr dankbar für Hinweise :)
Mit "Sockets" und "Jails" hast du mir gute Stichpunkte genannt, die ich mir notiert habe, und über die ich auf jeden Fall mehr herausfinden möchte. Mein angedachter Ansatz war es, ein Datenbanksystem zu betreiben, und lediglich Anfragen vom localhost zu erlauben. (Ich habe gelesen, dass man zwar Systeme immer trennen sollte, aber aus finanziellen Gründen kann ich nicht für jede Aufgabe einen eigenen Server mieten und aufsetzen.. da muss mir ein einzelner ausreichen.. :) )
Und die Datenbankbenutzer, ähnlich wie du es schon erwähnt hast, wären dann auf Tabellen- und Aufgabenebene präzise abgestimmt mit den Berechtigungen (..ein vielleicht etwas paranoider Ansatz, aber ich lese immer wieder vom Grundprinzip der möglichst geringen Berechtigungen).

Leider bin ich noch nicht ganz so weit mit der Doku, aber ich befürchte, dass ich durch das qcow2-Image keinen Einfluss mehr auf die Verschlüsselung nehmen kann, oder habe ich das falsch verstanden? Allerdings wäre das glaube ich ohnehin auf Partitionsebene und da der Server ja meist läuft, sind die Daten nur während eines Neustarts kurzzeitig verschlüsselt, oder?
Ich hätte mich dafür mit "VeraCrypt" beschäftigt, um eine Verschlüsselung bei laufendem System auf Ordnerebene zu realisieren, bei dem dann nur während der Nutzung die Daten im Klartext vorliegen.

@pit234a:
Das ist ja umso besser :)
Ich dachte, dass ich mich erst mit der FreeBSD-Variante vom OpenBSD PF (oder "Pf"?) hätte auseinander setzen müssen, aber wenn ohnehin schon eine Art "Grundschutz" besteht, dann kommt mir das sehr entgegen.

Deine Gedanken zum Thema Systemsicherheit habe ich mit großem Interesse gelesen. Ich hoffe, dass ich mich nicht missverständlich ausgedrückt habe.. mir ist bewusst, dass es keine perfekte Sicherheit gibt und mein Ziel ist es lediglich, die Hürde etwas anzuheben. Zudem finde ich die Thematik einfach spannend und beim Versuch ein System abzusichern, gewinnt man unter Umständen auch einfach einen Überblick darüber, auf welchen Wegen überhaupt etwas schief laufen kann, an die man im Vorfeld vielleicht überhaupt gar nicht gedacht hat.

Mit https://hardenedbsd.org/ hast du mir eine schöne Quelle genannt, die ich mit Sicherheit zukünftig beim Pendeln zur Arbeit des öfteren aufsuchen werde.

@zuglufttier:
SSHGuard ist auch ein Punkt, den ich mir notiert habe und den ich mir unbedingt ansehen möchte.

Ich danke euch allen vielmals für eure Gedanken und Hinweise! Und der durchgängige Punkt mit den SSH Schlüsseln wird zum Glück auch in "SSH Mastery" beschrieben, sodass ich das hoffentlich korrekt umsetzen kann.

Nochmals Dankeschön und einen guten Start in die neue Woche! :)
 
ghostfish schrieb:
Jetzt zu meiner Frage: sichert ihr eure FreeBSD-Installation auf einem vom Internet aus zugänglichen System in besonderer Weise ab? Und falls ja, wie sehen diese Sicherungsmaßnahmen aus?
Zum Vergrößern anklicken....

Ja. Die IP liegt im jail, und in diesem jail läuft nur das, was auch wirklich da laufen muss. Alles andere (also zB. die Datenbanken zu den Web-Anwendungen, Support-Tools, sonstiges Backend-Zeug, aber auch schon die Web-Anwendungen selber) läuft woanders (idealerweise auf einem anderen Blech, aber da ich Privatmensch bin und Strom Geld kostet...) Dazu ein ipfw, der nicht nur als "wall" (mit zwei seiten) arbeitet, sondern in jeglicher Relation nur das durchläßt was tatsächlich genutzt wird.
Dazu vieles von dem was schon gesagt wurde. Deine Applikation und Deinen Anbieter kenn ich nicht, kann dazu also nix sagen - meine Inst. läuft zuhause und wird aus der Source gebaut.

Ist dieser Ansatz riskant? Über hilfreiche Kommentare wäre ich sehr dankbar! :)
Zum Vergrößern anklicken....

Wenn ich in meine Logs gucke, kommt da im 10-Sekundentakt irgendwelcher Mist an der nichts auf meiner Kiste verloren hat. Momentan spiele ich mit suricata rum, das erzählt dann was das für ein Mist ist (und könnte wohl im zusammenwirken mit ipfw auch filtern - aber man muss die Regeln dafür irgendwie auftreiben). Ist schon lustig. Also, ich denke, völlig risikofrei ist eine IP in-the-open nie. Aber meine läuft schon über zehn Jahre.

ghostfish schrieb:
Und die Datenbankbenutzer, ähnlich wie du es schon erwähnt hast, wären dann auf Tabellen- und Aufgabenebene präzise abgestimmt mit den Berechtigungen (..ein vielleicht etwas paranoider Ansatz, aber ich lese immer wieder vom Grundprinzip der möglichst geringen Berechtigungen).
Zum Vergrößern anklicken....

Man kanns sogar noch paranoider machen und der Web-App nur VIEWs der genutzten Tabellen zeigen, wo nur die Records und Felder drin sind, die grad wirklich genutzt werden müssen. Das artet dann halt in Programmiererei aus, aber für mich ist zB unverständlich, wenn Kreditkartendaten en masse via Web abgegriffen wurden: die könnten schon von der Datenbank write-once-read-never gehandhabt werden (und den Abgleich mit dem Aquirer könnte eine andere Anwendung machen, die dann nicht aus dem Web zugreifbar ist).
 
PMc schrieb:
https://www.finanz-szene.de/payment...rd-panne-volle-kreditkartennummern-kursieren/


Und ich sags noch... leute, ich sags noch... (nein, ich wusste zu dem Zeitpunkt noch nichts davon, bin aber auch betroffen)
Zum Vergrößern anklicken....

Da muss ich allerdings zu sagen, dass das nicht immer trivial umzusetzen ist. Ich hatte vor ca. 10J. eine Anwendung mit dem Zend Framework 1 umzusetzen. Da mussten auch Kontodaten gespeichert werden. Meine Idee war, für das Frontend einen nur schreiben DB-User anzulegen, der eben nur schreiben darf. Sollte da jemand einbrechen, kann er Müll reinschreiben, aber eben nicht lesen. Das musste nur das Backend können, was nochmal besonders abgesichert war. Es ist letztendlich am drecks ZF1 gescheitert, da das automatisch die Tabellenstruktur lesen wollte, um diverse Lookups im Zusammenhang mit dem Model der Anwendung zu machen. Ich habe dann angefangen, die Definitionen händisch zu pflegen, aber es dann irgendwann einfach aufgegeben und einen ganz normalen DB-Useraccount genommen.

Dann bekommst du als Entwickler noch Druck, weil es fertig werden muss und nicht zu teuer werden soll und schon passiert sowas.
Und am Ende wird trotzdem eine arme Sau rundgemacht, entweder der Entwickler, oder in diesem Fall der Dienstleister, der bestimmt mit einem Hungerlohn abgespeist wurde.

@ghostfish Wenn das für Deine Anwendung ausreicht, dass der DB-Server auf localhost lauscht, dann ist das vollkommen okay. Das meinte ich damit, die IP-Adresse einzuschränken. Oft muss der Server nicht über eine öffentliche IP-Adresse erreichbar sein.
Und per SSH-Tunnel kannst Du dann trotzdem von zuhause aus mit dem Client Deiner Wahl auf den Server zugreifen.
 
crotchmaster schrieb:
Da muss ich allerdings zu sagen, dass das nicht immer trivial umzusetzen ist. Ich hatte vor ca. 10J. eine Anwendung mit dem Zend Framework 1 umzusetzen. Da mussten auch Kontodaten gespeichert werden. Meine Idee war, für das Frontend einen nur schreiben DB-User anzulegen, der eben nur schreiben darf. Sollte da jemand einbrechen, kann er Müll reinschreiben, aber eben nicht lesen. Das musste nur das Backend können, was nochmal besonders abgesichert war. Es ist letztendlich am drecks ZF1 gescheitert, da das automatisch die Tabellenstruktur lesen wollte, um diverse Lookups im Zusammenhang mit dem Model der Anwendung zu machen. Ich habe dann angefangen, die Definitionen händisch zu pflegen, aber es dann irgendwann einfach aufgegeben und einen ganz normalen DB-Useraccount genommen.
Zum Vergrößern anklicken....

Ich habs mal mit RoR ausprobiert - grundsätzlich geht es, d.h. das Rails (das auch die Datenbankstruktur liest und sich danach konfiguriert) ist zufrieden, wenn es einen VIEW statt der Tabelle kriegt. Aber freilich muss man sich dann dransetzen und die Logik mit Triggers und Constraints gestalten und dann auch pflegen, und das ist ein Haufen Arbeit. Ob das jemand bezahlen will - keine Ahnung.
Das war halt eine der Möglichkeiten, über die ich gestolpert bin. Unc ich denke ja, dass man über Sicherheit heutzutage nachdenkt.

Dann bekommst du als Entwickler noch Druck, weil es fertig werden muss und nicht zu teuer werden soll und schon passiert sowas.
Und am Ende wird trotzdem eine arme Sau rundgemacht, entweder der Entwickler, oder in diesem Fall der Dienstleister, der bestimmt mit einem Hungerlohn abgespeist wurde.
Zum Vergrößern anklicken....

Bei dem verlinkten Happening hat man sich gedacht, dass man ganz einfach Promotion machen kann: die MC-Kunden kriegen ein Bonusprogramm, die Händler stellen ein paar Incentives zur Verfügung, keinen kostet's was und alle machen Reibach.
Dass einer der größten globalen Finanzdienstleister das dann einfach an eine Web-Klitsche auslagert und man offenbar nicht groß darüber nachdenkt, dass man es mit sensiblen daten zu tun hat - nunja, Treffer, versenkt.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben