Performance-Vergleich: Slackware-Linux vs. FreeBSD

Perdurabo schrieb:
Man sollte mit seinen Assoziationen etwas vorsichtiger sein.

Ja, du sagst es. Die Assoziation hast im übrigen DU gezogen. Im übrigen hatte ich mir fast gedacht, dass du Gentoo nutzt. Tut mir leid, wenn ich das so pauschal sagen muss, aber sobald Gentoo auch nur in der nähe von einem schlechten Wort steht, werden diese Jünger pissig bis aufs Letzte. Man verzeihe mir die Ausdrucksweise.
Oder die gemäßigteren von denen fallen einfach nicht auf.

Im übrigen. Bevor du andere der Unfähigkeit bezichtigst. Nicht benötigte Programme haben auf einer Firewall tatsächlich nichts zu suchen. Das gilt auch für einen gcc. Natürlich kann ein erfolgreicher Einbrecher auf den meisten Systemen, seine Tools nachinstallieren. Aber dies bedeutet auch einen Mehraufwand und in den meisten Fällen werden sowieso vorgefertigte Binaries eingeschleust und nicht erst auf dem System erstellt. Insofern ist diese Diskussion mehr als theoretisch. Nicht theoretisch ist dagegen, dass wenn ich den Platzbedarf einer Firewall so bemesse, dass nur der Betrieb gesichert ist und jedes größere zusätzliche Programm schon aus dem einfachen Grund der Platznot verhindert wird.

Natürlich kannst du auch ein System dicht bekommen, wenn du die Programme drauf läßt der Aufwand ist aber immens.

Lediglich der, aus meiner Sicht, äußerst schwachsinnige Bedarf an den hochintegrierten Systemen (FireWall + IDS + VirusWall + Spamfilter + Webinterface mit Reporting + VPN + eingebauter Kühlschrank mit akustischer Inhaltswarnung + Loadbalancing und Urlaubsvertretung) hat zu diesen üppig ausgestatteten Kisten geführt, die inzwischen unter dem Sammelbegriff FW laufen.

Ich kann nur schmunzeln, wenn für Produkte wie die Astaro 5 Dualprozessorsysteme empfohlen werden.
 
Zuletzt bearbeitet:
OM_A schrieb:
Schlank würde ich so auslegen: Weglassen oder Entfernen nicht gewünschter Komponenten;
z.B. die GNU Compiler Collection (gcc) nicht zu installieren ist unter FreeBSD im Gegensatz zu den meisten Linux-Distribution und Net- oder OpenBSD nicht möglich.

Das gleitet ja fast (wieder) in eine Diskussion ab was der Unterschied zwischen Linux (Distribution) und *BSD ist. Das eine sehr modular alles um den kernel, das andere ein Basesystem mit einem ganzen System und nicht nur ein kernel...
 
Was die security angeht, wenn mir jemand seine binaries in Verzeichnisse legen kann, oder den gcc dazu verwendet um diese zu erstellen und dann abzulegen, habe ich ein anderes Problem als einen installierten gcc/tendra/icc/$whatever.
 
Perdurabo schrieb:
So und was steht in Deinem schlauen Buch drin? Nicht nur das runterleiern von irgendwelchen Dingen ist gefragt. So mal auf die schnelle ein Thread aus der BSD-Newsgroup, die das Thema betrifft.



Der kurze zum nachlesen: Thread

Auf die Frage, wer das denn behauptetet kam die Antwort:
Eric "Sendmail" A. in einer Empfehlung von 1987. Habe ich ausgedruckt in
einem Bilderrahmen haengen, um mich daran zu erinnern, dass Genialitaet auch
nicht vor Ausrutschern schuetzt.

Hmm, angenommen jmd bekommt durch nen remote exploit ne shell mit eingeschränkten user rechten mit der es ihm nicht möglich ist ne datei auf den rechner runterzulagen (kein ftp/http/nfs/samba/whatever).

binarys bekommt er nicht drauf aber er kann sehr wohl nen c code abtippen bzw. pasten. hat er nun noch zugriff auf nen compiler brauch er nur noch nen passenden local root exploit....

oder nicht?
 
balu schrieb:
Hmm, angenommen jmd bekommt durch nen remote exploit ne shell mit eingeschränkten user rechten mit der es ihm nicht möglich ist ne datei auf den rechner runterzulagen (kein ftp/http/nfs/samba/whatever).

binarys bekommt er nicht drauf aber er kann sehr wohl nen c code abtippen bzw. pasten. hat er nun noch zugriff auf nen compiler brauch er nur noch nen passenden local root exploit....

oder nicht?

oder nicht! ;)

binaerdateien lassen sich mit den verschiedesten verfahren in ascii codieren. am haeufigsten nutzt du diese methode, wenn du per mail anhaenge verschickst.

mit der bash als shell hast du bereits einen auesserst maechtigen interpreter um so etwas zu realisieren.

meistens ist es dir nicht nur moeglich eine shell zu starten, sondern jedes beliebige programm. z.B. perl oder gawk. beide ermoeglichen dir z.B. auch eine netzwerkkommunikation aufzubauen.

das entfernen des gcc verkompliziert lediglich die weiteren schritte, wenn ein system komprimitiert wurde.

das reduzieren des verfuegbaren systemplatzes um das kopieren von diesen binaries einzuschraenken ist auch nur eine weitere massnahme. mit dem entsprechenden knowhow muss man noch nicht mal ein einziges binary in ein filesystem kopieren, sondern fuehrt gleich alles im memory aus. EDIT: kleine freudsche korrektur, von stack -> memory...
 
Zuletzt bearbeitet:
minuseins schrieb:
oder nicht! ;)

binaerdateien lassen sich mit den verschiedesten verfahren in ascii codieren. am haeufigsten nutzt du diese methode, wenn du per mail anhaenge verschickst.

mit der bash als shell hast du bereits einen auesserst maechtigen interpreter um so etwas zu realisieren.

meistens ist es dir nicht nur moeglich eine shell zu starten, sondern jedes beliebige programm. z.B. perl oder gawk. beide ermoeglichen dir z.B. auch eine netzwerkkommunikation aufzubauen.

das entfernen des gcc verkompliziert lediglich die weiteren schritte, wenn ein system komprimitiert wurde.

das reduzieren des verfuegbaren systemplatzes um das kopieren von diesen binaries einzuschraenken ist auch nur eine weitere massnahme. mit dem entsprechenden knowhow muss man noch nicht mal ein einziges binary in ein filesystem kopieren, sondern fuehrt gleich alles im memory aus. EDIT: kleine freudsche korrektur, von stack -> memory...

hmm, jo, gcc wäre halt arbeitserleichterung da nix erst encoded und dann wieder decoded werden müsste. ausserdem liegen viele exploits nur im source vor, wenn das ziel nen anderes sys ist muss er sich auch noch mit cross compiling rumschlagen, evl. ist es sogar nen ganz anderes os.

noch schlimmer wäre es wenn er root erlangt und auf der kiste sowohl gcc als auch /usr/src installiert sind. backdoor lässt grüssen. und die sourcen läd er nicht so einfach mal nach ;)

aber ok, gcc ist wahrscheinlich nen relativ geringes risiko, aber auch das würde ich ausmerzen. wo wir gerade dabei sind, kann man bei bsd im kernel den support für module deaktivieren?
 
@balu
Was Module angeht, so kannst Du den securelevel auf "1" oder höher setzen, dann ist das laden und entladen von Modulen nicht mehr möglich --> man securelevel
 
asg schrieb:
@balu
Was Module angeht, so kannst Du den securelevel auf "1" oder höher setzen, dann ist das laden und entladen von Modulen nicht mehr möglich --> man securelevel

thx

wobei wenn jmd root bekommt kann er den auch wieder anders setzen oder nicht?

beim linux kernel kann man beim kompiliieren den support für module ausschalten, sowas hatte ich gesucht....
 
@balu

Schau mal: man securelevel

Der securelevel lässt sich auch als root nur per reboot wieder ändern. Somit fällt das für einen Remote-Angreifer wohl aus.... ;)
 
Zuletzt bearbeitet:
Zurück
Oben