BSD und Sicherheit

Athaba schrieb:
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.

Was heißt denn aktiviert? Wird der Code von nicht vorhandenen Geräten denn geladen? AFAIK nicht.

Und ansonsten:

http://www.openbsd.org/cgi-bin/man....manpath=OpenBSD+Current&arch=i386&format=html

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?

Ja, aber das entscheidet der User. Per Default ist "Internet" nunmal deaktiviert, im Gegensatz zu einem OS aus einer anderen Ecke, das sich ohne ja kaum noch installieren lässt. Du entscheidest selber, was Du zulässt. Eben "Secure by default", und dann muss der Admin das Risiko abwägen.

Genauso wie bei X. Natürlich ist es unsicher. Es gibt aber im Moment keine andere (ausgereifte) Möglichkeit einer ordentlichen grafischen Oberfläche. Aber auch hier: default ist aus, auch die Aperture ist nicht aktiviert.

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.

Richtig. Bei OpenBSD ist am Anfang alles zu. Erst nach der Installation schießt Du Löcher ins System, hoffentlich nur die die Du wirklich brauchst. Aber das ist dann Dein Problem. Es gibt keine versteckten Dienste, die im Hintergrund auf einem externen Interface lauschen. Eben "Secure by default".

Nochwas zu dem angepassten Kernel: meine erste OpenBSD-Installation (3.6 wars, also noch gar nicht so lange her) lief auf meinem ausgedienten P3-800 als kleiner Heimserver. Der (genauer: das Mainboard) ging dann kaputt. Auf einem Samstag. Zwei Tage, bevor ich einen Vortrag in einer Vorlesung halten musste, und die einzige Version dieses Vortrags natürlich auf der Festplatte eben diesem lag. Bullshit!

Schnell in einen nicht vertrauenswürdigen PC-Schuppen gelaufen, gesagt was ich wollte (ein Board für meinen P3), ausgelacht worden, in die saure Gurke gebissen und einen Sempron auf Board mit VIA-Chipsatz gekauft. Aber hey, der GENERIC-Kernel startete. Sofort. Ohne Murren. Vortrag gerettet.

Stell Dir mal vor, ich hätte mir den Kernel großartig angepasst. Und den Treiber für den VIA-Chipsatz rausgeschmissen. Ups.

OK, ist mit OpenBSD jetzt auch nicht das Problem, da hat man recht schnell wieder einen GENERIC drauf. Aber ich hoffe, das Problem konnte ich verdeutlichen.

Gruß
Baseballbatboy
 
Ich hab auch immer nen GENERIC-Kernel zum Fehler reproduzieren und für generischen Hardwaresupport.
Ist nicht bei allen BSDs das Internet per Default deaktiviert?
Der Vorschlag war wie gesagt eher für die anderen BSDs. Zum Beispiel in NetBSD INSECURE deaktivieren. Auch die Fähigkeit Module zu laden wird nicht immer benötigt und kann gefährlich sein.
 
Ist das nicht eine Möglichkeit eine weitere Barriere hinzuzufügen?
Schafft man es den Securelevel zu ändern muss man noch dem Kernel die Fähigkeit geben Module zu laden und nen Kernel im laufenden Betrieb zu wechseln ist wohl kaum machbar.

Naja, jetzt bin ich schön langsam am Ende mit meinem Latein. Wenigstens weiß ich, mit was ich mich beschäftigen kann :)
 
Athaba schrieb:
Ist das nicht eine Möglichkeit eine weitere Barriere hinzuzufügen?
Schafft man es den Securelevel zu ändern muss man noch dem Kernel die Fähigkeit geben Module zu laden und nen Kernel im laufenden Betrieb zu wechseln ist wohl kaum machbar.

Du kannst den Securelevel nur durch einen Reboot wieder senken. Wenn du dann noch ein schg-Flag auf die rc.securelevel legst, kann man den Securelevel nur im Singleuser-Mode aendern.
 
Maxx schrieb:
Du kannst den Securelevel nur durch einen Reboot wieder senken. Wenn du dann noch ein schg-Flag auf die rc.securelevel legst, kann man den Securelevel nur im Singleuser-Mode aendern.
Ich weiß, dass man ihn nur durch einen reboot wieder senken koennen sollte. Mit Securelevels kenne ich mich von der Anwenderseite her aus. Nur weiß ich nicht, ob es nicht mal eine Lücke geben könnte, die das erlaubt. Bin eben kein Entwickler oder Sicherheitsexperte. Ich verwende halt möglichst alles, was ne Barriere für nen Angreifer darstellen könnte.

lars schrieb:
Btw, Athaba, das Buch 'Security Engineering' von Ross Anderson,
das ich dir mal empfohlen habe, ist jetzt online kostenlos verfügbar:
http://www.cl.cam.ac.uk/~rja14/book.html
Wow, das kam gelegen. Bin gerade damit fertig mir Grundkentnisse (also ohne zu viel Mathematik) in Kryptographie anzueignen. Wollte mir jetzt mal was über "allgemeine Security" kaufen, bevor ich mit dem mathematischen Teil weitermache.
Danke! :)

Athaba
 
Das meiste wurde hier schon erwähnt.

Zum Zwibelschalen system:
Ich kann das für den FTP sehr empfehlen.

Prinzip (OpenBSD)
FTP Starten mit:
Code:
/usr/local/libexec/ftpd -AUDl
Kann natuerlich auch mit inetd zusammen verwendet werden.

Danach die FTP User im
Code:
/etc/ftpchroot
Eintragen, und die nicht erlaubten User im
Code:
/etc/ftpusers

Wichtig dabei:
Ein User welcher zugriff auf FTP hat, bekommt kein zugriff via ssh (nologin)
Ein SSH user bekommt kein zugriff via FTP (etc/ftpusers).

// Edit //
Hmm, vl. ist das mal ein wiki eintrag...?
 
Zurück
Oben