PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Umfrage: Sicheres Linux für Server / Rootserver



cane
14.04.06, 04:27
Hallo @all,

zuerst einmal würde ich mich freuen wenn ihr bei der Umfrage mitmacht :)

Ich teste momentan verschiedene, auf Sicherheit zugeschnittene, Distributionen und wundere mich wirklich warum diese, in Zeiten immer billigerer Rootserver, nicht stärker nachgefragt und auch entwicckelt werden.

Es gibt mittlerweile ja einige interessante Projekte, die versuchen ein auf Sicherheit optimiertes Linux-Betriebssystem zu realisieren und das System gegenüber einer Standarddistribution viel sicherer machen.

Deswegen würde ich gerne zusätzlich zur Umfrage wissen ob und warum ihr Sachen wie RSBAC, Pax, SSP, SELinux und ähnliches benutzt.

Kompiliert ihr selbst alles oder stützt ihr euch auf Distributionen wie Adamantix Hardened-Gentoo, Trustix...

mfg
cane

mfg
cane

BedriddenTech
14.04.06, 13:16
Ich benutze eigentlich nur grsec. Ich amg daran den Adressbereichschutz und z.B. die Randomisierung der PIDs; aber generell bin ich der Meinung, daß ein gutes IPTables-Regelset und richtig konfigurierte Dienste schon ausreichend sind.

bla!zilla
14.04.06, 14:20
Für gehärtete Systeme (Webserver, Mailrelays usw.) verwende ich im Job eigentlich Adamantix oder ein per Hand gehärteten SLES.

solarix
14.04.06, 14:25
Die beste Absicherung ist meiner Meinung immer noch die das jemand weiss was er tut. Wenn ich an die letzten Threads zum Thema Rootie/Vserver denke, kommt mir sowieso die Galle hoch.

Ich härte meine Systeme von Hand.
Wenn die Dienste vernünftig gesichert sind, ist sowieso der größte Problemkreis erschlagen.

bla!zilla
14.04.06, 18:05
Per default ist kein System sicher. ;)

Taktloss
14.04.06, 22:24
grSEC weil:
-No Exec Stack
-sicherere chroots
-Random PIDs
-Random TCP Src Ports
-keine schreiben auf /dev/mem /dev/kmem möglich
und noch ne ganze ecke mehr ;)
Ich denke dass ne Kiste mit grSec auf jeden fall mehr Sichereit bietet. Ich kann so jedenfalls beruhigter schlafen :D

X-Dimension
14.04.06, 22:55
Ich habe den Sinn von diesen "Sicheren Distributionen" noch nicht ganz erkannt. Im Prinzip kann man doch alles auch mit einem normalen Linux so konfigurieren das es genauso sicher ist.

Mandriva hat dafür zum Beispiel die Tools "msec" und "draksec", bei denen man zwischen verschiedenen Sicherheitsstufen ("Schwach" bis "Paranoid") wählen kann. Zusätzlich lassen sich diese Einstellungen auch noch manuell anpassen.
Etwas vergleichbares habe ich bisher in keiner anderen Distribution gefunden.
Daher setze ich Mandriva auch für jegliche Anwendungsgebiete ein, egal ob High-Secure Server, Cluster-System oder Home-Desktop.

XD

solarix
14.04.06, 23:06
Per default ist kein System sicher. ;)


Das hat auch niemand behauptet ;-)

Aber man kann viel dafür tun, in dem man sich "bildet" ;-)

suck
15.04.06, 05:25
Derzeit interessiert mich in diesem Bereich Hardened-LFS am ehesten - das habe ich in der Auflistung vermisst. Ich überlege dieses für einen extrem schlanken Web-Server (apache, ssh, PHP, firewall, mysql) zu nutzen. Es sind ja nicht so viele Pakete, die man im Auge behalten muss, um seinen Rechner aktuell/sicher zu halten. Eine starke Alternative wäre OpenBSD, passt aber nicht in dieses Forum. Ach ja, die Namen der sicherheitsrelevanten Pakete, würde ich in einen Filter meines Mail-Clients einfügen und dann z.B. die bugtraq ML gezielt nach für mich interessanten Beiträgen durchsuchen. Auf eine Distribution im eigentlichem Sinne möchte ich verzichten.

solarix
15.04.06, 12:32
Derzeit interessiert mich in diesem Bereich Hardened-LFS am ehesten - das habe ich in der Auflistung vermisst. Ich überlege dieses für einen extrem schlanken Web-Server (apache, ssh, PHP, firewall, mysql) zu nutzen. Es sind ja nicht so viele Pakete, die man im Auge behalten muss, um seinen Rechner aktuell/sicher zu halten. Eine starke Alternative wäre OpenBSD, passt aber nicht in dieses Forum. Ach ja, die Namen der sicherheitsrelevanten Pakete, würde ich in einen Filter meines Mail-Clients einfügen und dann z.B. die bugtraq ML gezielt nach für mich interessanten Beiträgen durchsuchen. Auf eine Distribution im eigentlichem Sinne möchte ich verzichten.


Wieso passt Open BSD nicht in dieses Forum? Da wie du richtig angeführt hast Open BSD durchaus eine Alternative ist kann man es auch anführen, über den Tellerrand zu schauen hat noch niemand geschadet. :-)

Aber auch Open BSD ist nicht perfekt, selbst wenn es Theo gerne so sieht. :-)

Meiner Meinung und Erfahrung nach kann man jedes System "sicher" machen wenn man sich an ein sinnvolles Installationslayout hält und die zu bereitstellenden Dienste sorgsam konfiguriert.

Ein Punkt dem oftmals weniger Beachtung geschenkt wird, ist die eigentliche Applikation die oftmals auf einem Webserver (wenn wir jetzt von Webservern reden) bereitgestellt wird. Der sicherste Webserver nützt nichts, wenn die Applikation von Exploits zerfressen ist, oder so tolle Sachen wie Register Globals_ON benötigt. Oftmals, denken darüber einige Leute nicht nach, sondern legen ihren Fokus auf die Konfiguration des Systems und der Dienste.

suck
16.04.06, 02:39
Meiner Meinung und Erfahrung nach kann man jedes System "sicher" machen wenn man sich an ein sinnvolles Installationslayout hält und die zu bereitstellenden Dienste sorgsam konfiguriert.

Genau an dieser Stelle bin ich exakt deiner Meinung, auch wenn ich "jedes" in Anführungszeichen setzen würde. QNX (mathematisch bewiesen und daher extrem sicher) wäre übrigens auch äussert interessant - kostet bei gewerblicher Nutzung jedoch Geld. Zurück zum Linuxsystem: Das Installationslayout ist das wichtigste. Der von mir geplante Server z.B. sollte auf LFS basieren, damit ich volle Kontrolle und vor allem - und das ist das Wichtigste - den Überblick habe. Ein weiterer Vorteil ist, dass ich auf niemanden warten muss, der neue Versionen in irgendeinen Paketmanager einflickt. Kombiniert mit sicherheitsrelevanten Patches aus verschiedensten Quellen (Stichwort HLFS) sollte das System recht sicher sein. Jedoch ist auch für mich irgendeine Art der Paketverwaltung von Bedeutung - sowas ist einfach nützlich. Ein besonders interessanter Ansatz findet sich in den LFS-Hints. Dort beschreibt jemand (übrigens aus Deutschland) wie man alle Pakete ohne eigentlichen Paketmangager verwalten kann. Für jedes Paket wird ein User und eine Gruppe erstellt. Die gesamte Verwaltung kann man anschliessend via "find" und co erledigen. Ich bin derzeit damit beschäftigt basierend auf dieser und noch anderen Ideen meine eigene Version eines solchen Paketmanagers zu scripten. Anbei noch der Link zu dem Hint und ein Ausschnitt daraus. Eure Meinungen zur Sicherheit eines solchen Systems interessieren mich natürlich sehr. Prinzipiell scripte ich den Kram übrigens auch und eher für mein Desktopsystem - der Aufwand soll sich ja lohen.


DESCRIPTION:
-You want to know which packages your files belong to ?
-You want to deinstall software that doesn't have make uninstall ?
-You are bothered by programs installed setuid root behind your back ?
-You don't like packages quietly overwriting files from other packages ?
-You don't like package managers like RPM ?
-YOU WANT TOTAL CONTROL USING ONLY UNIX BUILTINS ?

Link zu LFS-Hint (http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt)

suck
16.04.06, 02:52
grSEC weil:
-No Exec Stack
-sicherere chroots
-Random PIDs
-Random TCP Src Ports
-keine schreiben auf /dev/mem /dev/kmem möglich
Inwiefern ist dies eigenltich bei einem System ohne wirkliche User sinnvoll? (von den chroots mal abgesehen ; )

Roger Wilco
16.04.06, 15:08
Definiere "ohne wirkliche User". Sobald ein Dienst eine Lücke hat, über die man beliebige Kommandos ausführen kann, hast du "einen wirklichen User", um den du dir Sorgen machen musst. Von daher sind die Ergänzungen, die grsec dem Kernel hinzufügt sehr nützlich.

suck
16.04.06, 21:34
Definiere "ohne wirkliche User". Stimmt, blöde Formulierung. Als ich das schrieb, stellte ich mir ein System samt "chroot"-Umgebung vor, in der ein Dienst unter einem eingeschränkten User läuft. Man muss davon ausgehen, dass ein Angreifer Userrechte in der chroot Umgebung erlangt und dort schlimmstenfalls root wird. Ich wollte also eigentlich fragen, was die Erweiterungen in diesem speziellen Fall bringen. Gut, /dev/mem und /dev/kmem sollten im chroot abgesichert sein - das ist allerdings schon in der Formulierung "sichere chroots" enthalten. Aber was bringen die zufälligen PIDS und Ports und der fehlende "Exec-Stack"?

Roger Wilco
16.04.06, 21:59
Man muss davon ausgehen, dass ein Angreifer Userrechte in der chroot Umgebung erlangt und dort schlimmstenfalls root wird.
Aus einer chroot-Umgebung kann man problemlos ausbrechen. Die Erweiterungen von grsec bezüglich des chroot()-Aufrufs machen das etwas schwerer.


Aber was bringen die zufälligen PIDS und Ports und der fehlende "Exec-Stack"?
Der Exec-Stack fehlt nicht. ;)
Das ist ein "No Exec"-Stack, d. h. du kannst keine Daten auf dem Stack oder dem Heap direkt ausführen. Das erschwert die Ausnutzung von Buffer Overflows.

Zufällige PIDs und Quellports verhindern, dass ein Angreifer einfache Annahmen über das System machen kann und erschwert die Ausnutzung bestimmter Arten von Sicherheitslücken.

suck
17.04.06, 01:16
Aus einer chroot-Umgebung kann man problemlos ausbrechen. Die Erweiterungen von grsec bezüglich des chroot()-Aufrufs machen das etwas schwerer. Das "etwas schwerer" klingt irgendwie nach "Wer Ahnung hat kommt trotzdem raus". Wie bricht man eigentlich aus nem (evtl. sogar abgesichertem) chroot aus? Sind "jails" vielleicht eher zu empfehlen bzw. sicherer?



Das ist ein "No Exec"-Stack, d. h. du kannst keine Daten auf dem Stack oder dem Heap direkt ausführen. Das erschwert die Ausnutzung von Buffer Overflows. Das macht Sinn. Kann ich einem normalem Linux denn tatsächlich "führe jetzt den Code an genau dieser Stelle im Speicher aus" befehlen? ...auch wenn "/dev/mem" und "/dev/kmem" geschützt sind?


Zufällige PIDs und Quellports verhindern, dass ein Angreifer einfache Annahmen über das System machen kann und erschwert die Ausnutzung bestimmter Arten von Sicherheitslücken. Hier würde mich ein Beispiel sehr interessieren. Ich wüsste nicht, wie aufgrund von Ports und PID's Rückschlüsse auf das System gezogen werden können. Die Quellports sollten allesamt jenseits von 1024 liegen. Gibt es typische PID's oder Ports für bestimme Prozesse?

Roger Wilco
17.04.06, 11:04
Wie bricht man eigentlich aus nem (evtl. sogar abgesichertem) chroot aus?
Siehe http://talby.csu.umist.ac.uk/~isd/_unix_security/unix_security_intro.10.html
In Phrack gibt es auch einige Artikel darüber.


Sind "jails" vielleicht eher zu empfehlen bzw. sicherer?
Wenn du FreeBSD einsetzt, warum nicht? ;)
Wenn du damit generell eine Virtualisierung (Xen, OpenVZ, UML, VServer) meinst, so sind diese von der Architektur her sicherlich schwieriger zu knacken, als ein popeliges chroot-Environment. Mit Aussagen wie "die sind sicher" würde ich mich aber zurückhalten.


Das macht Sinn. Kann ich einem normalem Linux denn tatsächlich "führe jetzt den Code an genau dieser Stelle im Speicher aus" befehlen?
Ja, wobei das nicht vom Betriebssystem, sondern von der Hardware-Architektur abhängig ist. Bei neueren Prozessoren gibt es aber entsprechende Ansätze, das zu verhindern, siehe z. B. NX-Bit (http://de.wikipedia.org/wiki/NX-Bit) von AMD (das im Übrigen nicht so wirkungsvoll ist (http://www.heise.de/newsticker/meldung/64624), wie man es gerne hätte).


...auch wenn "/dev/mem" und "/dev/kmem" geschützt sind?
Ja. Mit /dev/mem bzw. /dev/kmem könntest du aber beliebig den Speicher bzw. Kernelspeicher manipulieren, um z. B. ein Rootkit nachzuladen usw.

[QUOTE=suck]Hier würde mich ein Beispiel sehr interessieren. Ich wüsste nicht, wie aufgrund von Ports und PID's Rückschlüsse auf das System gezogen werden können. Die Quellports sollten allesamt jenseits von 1024 liegen. Gibt es typische PID's oder Ports für bestimme Prozesse?
Es gibt eine statistische Erhebung, welche Nameserver welche Quellports für Antworten verwenden. Das ergab bei den meisten ein relativ eindeutiges Muster, so dass ein Angreifer damit auf die verwendete Software schließen kann. Zufällige Quellports vermindern außerdem die Erfolgschancen für DNS Cache Poisoning, siehe http://www.lurhq.com/cachepoisoning.html.

Und durch nicht-zufällige PIDs lässt sich von einem Angreifer bestimmen, wieviele Prozesse auf dem System laufen bzw. wieviele Prozesse eine bestimmte Aktion auf dem Rechner verursacht.

cane
18.04.06, 08:17
Aber was bringen die zufälligen PIDS und Ports und der fehlende "Exec-Stack"?

Zufällig gewählte Ports erschweren es einem Angreifer beispielsweise wichtige TCP/IP Verbindungen (BGP-Sessions wären ein Beispiel) via RST-Paket zu beenden.

mfg
cane

OliverH
13.12.07, 01:36
Wir setzen in der Firma auf Grsecurity auf allen Servern in Kombination mit PAX.
Die Vorteile sind klar:
-Randomized PIDs
-Speicher wird nach freigabe mit NULL überschrieben
-/proc restrictions
-härtere chroots
-Nonexecutable Stack
Zusätzlich härten wir die Maschinen mit Bastille und chrooten z.B. Bind9 und Postfix _immer_.
Desweiteren werden alle Systemdateien per Tripwire überwacht und regelmäßig überprüft.
Ich denke, dass wir damit relativ sicher fahren ;)

EDIT:
Wir verwenden _keine_ Module auf unseren Servern und haben die Schreibrechte für /dev/kmem natürlich per grsecurity "abgeschaltet".
Somit dürfte ein Kernelrootkit ausgeschlossen sein :)
Oder liege ich da falsch?

MannOhMann
13.12.07, 22:25
nen älteren thread hast nicht gefunden?

403
13.12.07, 22:58
Zufällig gewählte Ports erschweren es einem Angreifer beispielsweise wichtige TCP/IP Verbindungen (BGP-Sessions wären ein Beispiel) via RST-Paket zu beenden.

mfg
cane

Wo wir schon dabei sind, kannst du hier mal ein genaueres Beispiel geben?
Ich haette sonst gedacht du meinst zufaellige TCP-Sequence Nummern.

Wenn man ohne die richtige TCP-Sequence Nummer ein RST sendet duerfte das doch eigentlich keine Konsequenzen haben? Oder hattest du die als
bekannt vorausgesetzt?

Gruss 403

cane
14.12.07, 13:24
http://www.google.de/search?q=BGP+RST&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:de:official&client=firefox-a

mfg
cane

derRichard
18.02.08, 23:57
hallo!

man sollte in die umfrage noch "exec-shield" aufnehmen :)

//richard

Roger Wilco
23.05.08, 17:17
Dann aber bitte auch Smack und AppArmor und ...

Naja, die Umfrage ist wohl eh schon veraltet.

EDIT: Mist, wer sorgt denn auch dafür, dass die Umfrage-Threads bei Abgabe einer neuen Stimme wieder nach oben kommen?

CRAZyBUg
01.09.08, 22:16
Servus,
es gibt keine sicheren distributionen. es gibt nur distris die ihren fokus auf sicherheit legen.
btw. kann ein debian viel unsicherer sein als ein suse, wenn der admin keine ahnung von debian hat, jedoch für suse z.b. geschult wurde. - mein fazit: alle distris sind gleich, aber die mit der man am besten klarkommt wird auch das beste ergebnis liefern.

(Ich arbeite derzeit mit'n paar debian und freebsd servern, die mag ich am liebsten :-X)