BSD und Sicherheit

asg

push it, don´t hype
Moin,

wie sichert Ihr Eure *BSD Server ab? Ja, wirkliche Sicherheit gibt es nicht, aber man kann ja im Zwiebelschichtprinzip die Sicherheit "steigern".
Dabei würden mich an dieser Stelle weniger Programme/Tools aus den Ports interessieren, sondern das was die *BSDs von Hause aus schon mitbringen.

Klar eine Firewall, aber da beginnt es ja gerade mal. Passwörter auf blf umstellen? pam_passwdqc? Jails? reboots mittels strg-alt-ent verbieten,...

Also, welche Möglichkeiten bietet *BSD von Hause aus um das System abzusichern?

Wäre interessant zu erfahren was ihr alles unternehmt, konfiguriert, evtl. auch mit einer kurzen Erklärung zu den jeweiligen Punkten.
 
asg schrieb:
... Ja, wirkliche Sicherheit gibt es nicht...
In 10 hoch 99 Jahren hat sich das Weltall bis an die Grenze ausgedehnt, zieht sich wieder zusammen und es gibt dann irgendwann den nächsten Urknall oder Schöpfung.
In Ernst, wieviel Sicherheit soll es denn sein?
So viel wie möglich oder so viel wie nötig?
An meinem privaten Web-Server unter OpenBSD genügt mir die default-Installation und unter Linux ist es uns egal ob ein User sich root-Rechte auf der Konsole verschaffen kann. Er müßte sich zuvor einen Schlüssel und dann noch ne Chipkarte "besorgen", um an die Konsole zu gelangen.
 
Zuletzt bearbeitet:
Neben der von maus erwähnten Standardinstallation von OpenBSD fallen mir spontan gerade zwei Dinge ein.
Zertifikatbasierende Authentifikation (ssh) statt mit Passwort. Sudo um ausgesuchten Benutzern ein bisschen mehr zu erlauben.
 
Ich benutze ssh key auth, sudo und pf um meinen Laptop zu sichern.
Mehr aber auch nicht, da das Ding nicht wirklich von großer Bedeutung ist :)
 
Gude!

Warum nur Server?
Ein Laptop hat doch ein viel herausforderndes Bedrohungspotential!

asg schrieb:
Klar eine Firewall,
immer

Passwörter auf blf umstellen?
Jawoll

Vielleicht bin ich ja nur schwer von Begriff :), aber die Konfiguration ist alles andere als KISS.
pam_cracklib ist aber auch nicht viel besser!
Gibt es das eigenlich auch für FreeBSD?
Bis jetzt habe ich noch nichts gefunden.

Da ich auf dem Laptop keinen von aussen erreichbaren Dienst laufen habe
suche ich noch nach einer sinnvollen Anwendung.
Vielleicht sollte ich den einzigen Nutzer des Laptops in ein Jail sperren :).

reboots mittels strg-alt-ent verbieten,...
Was ist denn in FreeBSD das Äquivalent zum ca-Eintrag in der inittab?

Also, welche Möglichkeiten bietet *BSD von Hause aus um das System abzusichern?
Ein normaler Nutzer sieht doch viel zu viele Informationen über das Betriebssystem und andere Nutzer, daher security.bsd.see_other_udis=0.

Wäre interessant zu erfahren was ihr alles unternehmt, konfiguriert, evtl. auch mit einer kurzen Erklärung zu den jeweiligen Punkten.
Was mich an der Basisinstallation stört ist die mangelnde Granularität.
Ich habe bei FreeBSD wesentlich mehr SUID-Programme drauf als bei Debian.
Ich weis, dass es sich dabei oft um Hardlinks auf ein Programm handelt.
Trotzdem würde ich mir beispielsweise keine yp*_programme drauf installieren.
Besonders weil die Sache auch noch heute sicherheitsrelevant Bugs offenbart, wie diesen.
Das war zwar in dem Fall der Server, der nicht SUID ist.
Aber als vertrauensbildend würde ich das trotzdem nicht bezeichenen.
Leider habe ich noch keine saubere Entfernungsmöglichkeit für die redundaten Programme gefunden.
Da würde ein durchgehends Packetierungssystem helfen.
Was übrigens auch Percival so sieht.

Daher habe ich weitest gehend SUDI/SGID-Bits entfernt und verwende sudo,
was leider nicht im Basissystem enthalten ist :(.
 
Aber macht es bei einer "Man In The Middle"-Attacke noch einen Unterschied, ob man ein Zertifikat+Passwort oder nur ein Passwort benutzt?? Kann ja dann beides "abgefangen" werden...

edit:
Sorry! Hatte eine falsche Überlegung im Kopf.... :ugly:
 
asg schrieb:
Passwort und Zertifikat. Wenn man nicht beides hat, Pustekuchen.
Meinst du jetzt sowohl PasswordAuthentication als auch PublickeyAuthentication, oder einfach den Passphrase des Schlüssels/Zertifikats?
Oder versteh ich das jetzt ganz falsch?

Ich hab PasswordAuth ganz abgeschaltet und nur einen ssh User zugelassen.
Witzig in den Logs zu sehen, wie die Kiddies versuchen den richtigen User zu erraten. Aber nach 3 Connections in 120 Minuten ist die IP eh ausgesperrt.
 
asg schrieb:
Passwort und Zertifikat. Wenn man nicht beides hat, Pustekuchen.
Ich wollte das gerade einwerfen.
Irgendwie muss das Zertifikat auf den entsprechenden Rechner.

Wie sagen meine Tivoli-Kollege immer:

Ich brauche kein root-Passwort, solange der Endpoint läuft :).
 
Immer wieder gerne vernachlaessigt: Schadensbegrenzung.

Ich habe Connections vom Server nach aussen fuer fast alle (inklusive User www) gesperrt und zusaetzlich Quotas angeschaltet. Sollte also jemand einen den Webserver exploiten, kann er sich lokal begrenzt austoben, aber dem Rest der Welt keinen Schaden zufuegen.
 
Immer wieder gerne vernachlaessigt: Schadensbegrenzung.

Ich habe Connections vom Server nach aussen fuer fast alle (inklusive User www) gesperrt und zusaetzlich Quotas angeschaltet. Sollte also jemand einen den Webserver exploiten, kann er sich lokal begrenzt austoben, aber dem Rest der Welt keinen Schaden zufuegen.

wenn er root ist, kann er deine filterregeln einfach rausschmeissen oder ändern? oder wie meinst du dass? irgendwie versteh ich dass nicht... oder läuft die fw auf nem adneren rechner? und was haben quotas mit security zu tun? damit beschränkt man doch nur wieviel ein user speichern kann? *brett vorm kopf hab*

ich hab keinen server (leider), also ist es auch nciht nötig hier großartige sicherheitsmßnahmen zu ergreifen... Jails gibts nicht, wozu auch, es läuft kein von aussen erreichbarer dienst..
 
-ec- schrieb:
wenn er root ist, kann er deine filterregeln einfach rausschmeissen oder ändern?

Ja. Wenn jemand root-Rechte bekommt, hat man automatisch verloren. Ich gehe aber erstmal davon aus, dass jemand "nur" die Rechte des Webservers bekommt.

und was haben quotas mit security zu tun? damit beschränkt man doch nur wieviel ein user speichern kann? *brett vorm kopf hab*

Ein potentieller Angreifer kann, solange er keine Root-Rechte bekommt, nur begrenzt viel schreiben -- wie gesagt: Schadensbegrenzung.

ich hab keinen server (leider), also ist es auch nciht nötig hier großartige sicherheitsmßnahmen zu ergreifen... Jails gibts nicht, wozu auch, es läuft kein von aussen erreichbarer dienst..

Hast Du Windows-Rechner im lokalen Netz? Die sind mitunter recht gespraechig.
 
Im Kernel moeglichst alles deaktivieren, was man nicht braucht. Das bringt neben Sicherheit auch einen kleinen Performanceboost!
 
Hellau,

im Heimnetz: ein Server (NFS, X-Window, PostgreSQL, Applikationen, Proxy) mit PF als Firewall und drei Jails (Apache, DNS, Mail-SMTP mit Spamassissin und ClamAV).
Warum Jails: Damit das Wirtsystem nicht durch Zugriffe von außen kompromitiert werden kann. Alle Passwörter sind grundsätzlich 16 Zeichen lang und sind durch Blowfish verschlüsselt. Das wird nicht durch Software kontrolliert, sondern einfach durch ein menschliches Gehirn :D
Auf dem Wirt werkelt als Virenschutz ClamAV, der sich im Halbstundenrhythmus aktualisiert und stündlich die Homedirs scannt.
SSH-Verbindungen von außen sind noch nicht zugelassen, da ich dafür erst PF konfigurieren muß. Bis jetzt nur http/https Zugriffe möglich.
Dadurch, dass der Server "X-Server" für meine X-Terminals ist, kann ich keinen anderen security-level als -1 nehmen.
Ach ja, die Datei hosts.allow habe ich entsprechend angepaßt.

Viele Grüße

Jürgen
 
Unter FreeBSD gibt es Secure Level, siehe init(8).

Du darfst dich übrigens gerne aus meiner Sig bedienen, kein Problem.


Das mit dem securelevel hab ich total vergessen.. Wie gesagt, ich habe keinen Server, also brauch ich das Ding auch nicht grossartig absichern..

Hast Du Windows-Rechner im lokalen Netz? Die sind mitunter recht gespraechig.


Meine Eltern und meine dumme Schwester haben Windosen, aber was hat das mit meiner Box zu tun?

MfG
 
Find ich sehr seltsam: Auf der einen Seite heisst es "deaktivieren wir alle Services, dann stoeren sie uns mal nicht" und auf der anderen Seite "lass den kernel so voll mit Features, die du womoeglich nie brauchen wirst".

Wenn man ein sicheres System haben will, dann sollte man sich nunmal mit seinem System auskennen, dann darf man's ja.
 
Das OpenBSD-Projekt gewichtet es höher, dass die OS-Setups mit dem immer
gleichen generischen Kernel einfacher zu warten und durch das Projekt zu supporten sind.

Darum wird vom OpenBSD-Projekt so sehr von der Kompilation eines eigenen Kernels abgeraten.

Prinzipielle hast du aber IMHO recht, dass es sicherer ist auch im Kernel
so wenig Interaktionsmöglichkeiten zu bieten, wie möglich.
 
athaba: services != treiber. Wenn ein treiber im kernel ist, aber keine treiberhardware dafuer integriert, springt der sowieso nicht in den Quelltextteil.
 
-ec- schrieb:
Das mit dem securelevel hab ich total vergessen.. Wie gesagt, ich habe keinen Server, also brauch ich das Ding auch nicht grossartig absichern..

Zu securelevel(7) ein Theo[tm]: anyone who thinks that securelevels ever really helped solve any security problems hasn't got a brain, or they have not used it in a while.


Meine Eltern und meine dumme Schwester haben Windosen, aber was hat das mit meiner Box zu tun?

Ich bin jetzt mal von einer *BSD-Firewall ausgegangen, die das gesamte lokale Netz schuetzen soll. Speziell fuer Windows-Rechner besteht der Schutz dann aber auch darin, ausgehenden Traffic zu filtern, sonst kann ggf. die gesamte Welt auf C:\Eigene Probleme zugreifen ;-)
 
Athaba schrieb:
Find ich sehr seltsam: Auf der einen Seite heisst es "deaktivieren wir alle Services, dann stoeren sie uns mal nicht" und auf der anderen Seite "lass den kernel so voll mit Features, die du womoeglich nie brauchen wirst".

Dass Treiber != Service ist, wurde ja schon erwaehnt.

Generell gilt bei OpenBSD:

  • Die GENERIC-Kernel werden ausgiebig getestet, im Gegensatz zu Custom-Kernel
  • Wenn das Abschalten diverser Features im Kernel dessen Sicherheit erhoehen wuerde, dann wuerden diese Features rausfliegen.
  • Das Tuning des Kernels durch Entfernen von Features kann sogar dazu fuehren, dass das System erst unsicher wird, und zwar z.T. ziemlich heftig.

Zum letzten Punkt kann ich mich noch vage an einen Thread auf einer der OpenBSD-Mailinglisten erinnern, in der jemand unbedingt IPv6 aus der Kernelkonfiguration rauswerfen wollte, weil das ja angeblich "sicherer" waere. Wenn ich mich richtig erinnere, dann war der Witz bei der Sache allerdings der, dass dann die PF-Rules nicht mehr korrekt geladen wurden. Ich kann mich aber irren, ist schon einige Zeit her.

Und ein weiterer Grund, warum non-GENERIC nicht supported wird: es kostet einfach zu viel Zeit, fuer jede erdenkliche Custom-Konfiguration erstmal nachzusehen, ob sie denn nun harmlos ist oder einen gemeldeten Bug erst verursacht.

Wenn man ein sicheres System haben will, dann sollte man sich nunmal mit seinem System auskennen, dann darf man's ja.

Man kann auch ein sicheres System haben (und sicher administrieren), ohne die Sourcen bis zum letzten *c++ zu kennen. Nur leider hat sich irgendwie das Geruecht verbreitet, dass man jedes System nach der Erstinstallation erstmal "haerten" muss.

Ich find's regelmaessig witzig, wenn ich irgendwo solche "Hardening-XXX-HOWTOS" sehe, vor allem, wenn sie direkt auf der Homepage oder dem angegliederten Wiki eines Projekts zu finden sind (siehe z.B. Typo3). Wenn die Software *nicht* ab Werk sicher ist, aber anhand eines "HOWTOS" angeblich sicher gemacht werden kann, warum wird sie dann nicht gleich in diesem "gehaerteten" Zustand ausgeliefert? Das ist doch komplett unlogisch.
 
kili schrieb:
Dass Treiber != Service ist, wurde ja schon erwaehnt.
Echt?! :ugly:
Trotzdem wundert es mich, dass bei den Services drauf geachtet wird und auf der anderen Site gesagt wird man soll im Kernel alles aktiviert lassen.

Die GENERIC-Kernel werden ausgiebig getestet, im Gegensatz zu Custom-Kernel
Vertaenldich... und trotzdem sollte es das System nicht killen, wenn ich das eine oder andere deaktiviere. Wenn ich Probleme habe ist es doch logisch, dass ich's mal mit GENERIC probiere.

Wenn das Abschalten diverser Features im Kernel dessen Sicherheit erhoehen wuerde, dann wuerden diese Features rausfliegen.
Naja, das geht auch nicht wirklich, sonst läuft alles nur noch auf ganz spezillein Systemen, die ganz bestimmte Sachen machen sollen. Die Funktion in's Internet zu können ist doch auch potentiell gefährlich! Müsste man laut Theo de Raadt nicht generell jede Form von Unterstützung für X raus nehmen?
Das Tuning des Kernels durch Entfernen von Features kann sogar dazu fuehren, dass das System erst unsicher wird, und zwar z.T. ziemlich heftig.
Wie gesagt, man muss sich auskennen.

Und ein weiterer Grund, warum non-GENERIC nicht supported wird: es kostet einfach zu viel Zeit, fuer jede erdenkliche Custom-Konfiguration erstmal nachzusehen, ob sie denn nun harmlos ist oder einen gemeldeten Bug erst verursacht.
Bei nem Bugreport kann man ja GENERIC verwenden. Ich stimme die voll zu, es wäre eine Zumutung Costum Kernels direkt zu unterstützen.

Man kann auch ein sicheres System haben (und sicher administrieren), ohne die Sourcen bis zum letzten *c++ zu kennen. Nur leider hat sich irgendwie das Geruecht verbreitet, dass man jedes System nach der Erstinstallation erstmal "haerten" muss.

Ich find's regelmaessig witzig, wenn ich irgendwo solche "Hardening-XXX-HOWTOS" sehe, vor allem, wenn sie direkt auf der Homepage oder dem angegliederten Wiki eines Projekts zu finden sind (siehe z.B. Typo3). Wenn die Software *nicht* ab Werk sicher ist, aber anhand eines "HOWTOS" angeblich sicher gemacht werden kann, warum wird sie dann nicht gleich in diesem "gehaerteten" Zustand ausgeliefert? Das ist doch komplett unlogisch.
Ich finde so was auch immer witzig, aber eher weil das Howto, genau so wenig wie der Programmierer, wissen kann, was genau du haben willst. Für gewöhnlich hat es einen Grund, warum es so ist, wie es ist.

Nur muss man sein System halt anpassen. Du lässt ja auch nicht das root-Passwort leer, legst keine Benutzer an und installierst keine Software, oder? Da könnten wir ja gelich jede Dokumentation weglassen, wenn sowieso alles passt.

Wer sich mit etwas nicht auskennt soll die Finger davon lassen bzw. sich erst mal informieren oder sich im abgesicherten Bereich spielen. Außerdem ging es im Thread nicht nur um OpenBSD.
Ein Beispiel:
Unter NetBSD braucht es kein INSECURE, wenn man sowieso kein X verwendet.
Ist ja bei Routern und Servern oft der Fall.

Athaba, gute Nacht!
 
Zurück
Oben