root-server, Ubuntu oder Debian, IspCP oder andere?

[doc]

ich glaube(hoffe) die aussage von angel, war nicht so gemeint, wie ihr sie verstanden habt.
selbstverständlich muss man sein system immer aktualisieren, die version einer distri kann aber ruhig älter sein, wenn es weiterhin aktuelle patches gibt.

Okay, also mein Etch kann ich ja dann knicken als Möglichkeit für
einen recht aktuellen Server

das problem gabs bei ubuntu ebenso

Und dabei bin ich so ein Fan von apt, oder hat gentoo das auch

nee, aber was viel besseres ...

 

[Gast1]

Hm.. Okay, also mein Etch kann ich ja dann knicken als Möglichkeit für
einen recht aktuellen Server..

[ ] Du hast die Bedeutung von "System aktuell halten" für einen Serveradmin verstanden.

Aber mal so als Frage, Lenny ist dann auch
nicht wirklich besser, oder?

Nein, ganz und gar nicht besser, schlechter ...

Denn es ist ja eine Testing und so wie ich das gesehen habe noch eine Beta!

eben => NoGo.

Mal morgen noch Gentoo runterladen und mal angucken..
Und dabei bin ich so ein Fan von apt, oder hat gentoo das auch?!

Nein und von einer Distribution, von der Du weniger Ahnung als von Deiner offenbar bevorzugten hast, solltest Du gleich dreimal die Finger lassen, egal wie toll sie Dir irgendwelche User dieser Distribution anpreisen.

Die "beste" Distribution für einen Server ist die, mit der der Admin am besten zu recht kommt, alles andere ist Unsinn.

 

[saeckereier]

Ich habe irgendwann mal gesagt, nimm Gentoo zum Lernen von Grundlagen die bei den anderen Distris durch den Installer verborgern werden. Bleib ruhig bei deinem Debian, es steht durchaus auch in dem Ruf sicher zu sein (aktuelle Ereignisse mal ausgenommen)

Es gibt aber einen Unterschied zwischen aktuell und neuester Stand (bleeding edge):
Aktuell bedeutet: Regelmässig neue Versionen und Patches einspielen, insbesondere Security Updates. Aktuell heißt nicht immer die allerneueste Beta Version der gerade in Mode gekommenen Software zu installieren. Wenn du einen Root-Server betreibst, ist es Pflicht *mindestens* die Security Mailingliste der Distribution zu abonnieren und sofort wenn Bedrohungen ersichtlich werden nötige Updates vorzunehmen. Hier eine Besonderheit von Debian stable: Die Software ist zwar nicht die neueste, Sicherheitsupdates werden aber vom Debian Team auf die alte Software angepasst, so dass man trotz des Verwendens einer alten Version von Sicherheitspatches profitieren kann, Debian stable ist durchaus eine sinnvolle Distribution für Server (Ich benutze Debian seit längerem nicht mehr, gehe aber davon aus, dass dies immer noch so ist, man korrigiere mich bitte falls ich mich irre)
.
.
.
EDIT (autom. Beitragszusammenführung) :
.

Nein und von einer Distribution, von der Du weniger Ahnung als von Deiner offenbar bevorzugten hast, solltest Du gleich dreimal die Finger lassen, egal wie toll sie Dir irgendwelche User dieser Distribution anpreisen.

Gentoo hat natürlich auch so etwas wie apt, nur heisst das dort Portage und ist um einiges mächtiger aber auch zeitintensiver weil Software immer aus dem Quellcode automatisiert kompiliert wird, das aber nur so zur Info.

Ich stimme Rain_Maker zwar nicht im Stil zu, aber es ist richtig und von mir auch schonmal gesagt worden, dass die beste Distribution eine ist, die du im Schlaf beherrschst.

 

[Gast1]

Hier eine Besonderheit von Debian stable: Die Software ist zwar nicht die neueste, Sicherheitsupdates werden aber vom Debian Team auf die alte Software angepasst, so dass man trotz des Verwendens einer alten Version von Sicherheitspatches profitieren kann, Debian stable ist durchaus eine sinnvolle Distribution für Server (Ich benutze Debian seit längerem nicht mehr, gehe aber davon aus, dass dies immer noch so ist, man korrigiere mich bitte falls ich mich irre)

Das machen auch alle Distributoren mit "stable" Releases so, eine Distribution, die das nicht macht, ist deshalb zweite Wahl, es sei denn, man kennt sich gut genug aus, selbst Patches einzupflegen falls absolut "Not am Mann" ist.

Gentoo als Serversystem macht eigentlich (nur) dann besonderen Sinn, wenn man schon zu Beginn selbst Hand anlegt und z.B. das System "härtet", das ist aber etwas für Admins mit ordentlicher Erfahrung.

http://www.gentoo.org/proj/en/hardened/

Frage in die Runde:

Wie handhabt man das dann eigentlich? Auf einer Binärdistribution ist das ja kein Problem, da brauchts keinen GCC&Co. und der hat ja auf einer Produktivkiste streng genommen auch nichts zu suchen.

Parallell installiertes Testsystem auf Kiste @HOME mit möglichst identischer Konfiguration?

Den Kram dort bauen und dann rüberschieben?

(Wäre jedenfalls die sicherste Variante, falls das so einfach geht.)

Build-Umgebung in Chroot? (oder Äquivalent dafür)

Auch keine Ideallösung aber zumindest besser als eine schön vollständige Buildumgebung, die zugänglich für jeden Dödel ist, der sich gerade z.B. über eine unsichere Webapplikation eine Usershell geholt hat.

Irgendwie muss man dieses potentielle Leck ja stopfen, sonst ist jede Metadistribution, die selbst Bauen erfordert, um ein potentielles Leck "reicher", da aber auch die ganzen BSD-Derivate sehr beliebte Serversysteme sind, muss es da ja eine anerkannt sichere Lösung geben.

 

[bitmuncher]

Ich nutze prinzipiell VMs zum Bauen der Pakete, soweit ich welche aus dem Source brauche. Hab selten mit Servern zu tun, die man auch noch mit Compiler-Prozessen belasten kann, von daher kommt chroot-Umgebung zumeist eh nicht in Frage.

 

[saeckereier]

Wie handhabt man das dann eigentlich? Auf einer Binärdistribution ist das ja kein Problem, da brauchts keinen GCC&Co. und der hat ja auf einer Produktivkiste streng genommen auch nichts zu suchen.

Parallell installiertes Testsystem auf Kiste @HOME mit möglichst identischer Konfiguration?

Den Kram dort bauen und dann rüberschieben?

(Wäre jedenfalls die sicherste Variante, falls das so einfach geht.)

Build-Umgebung in Chroot? (oder Äquivalent dafür)

Naja, eine Annahme ist falsch: GCC auf dem Server ist ziemlich egal, meistens kann der Angreifer den zur Not auch selbst hochladen oder selbst was kompiliertes hochschieben, der GCC sorgt wirklich nicht für einen unruhigen Schlaf bei mir, insofern kann man auch locker auf dem Server kompilieren (Resourcen vorausgesetzt)

Zu dem, wie macht mans in der Praxis: Gentoo kann auch Pakete erstellen (nicht wirklich mehr als ne tar.gz mit den dateien) und automatisch diese von einem anderen Rechner downloaden, du kannst also kompilieren auf einem Home Rechner in ner VM oder so und dann diese Pakete verwenden, dafür ist auch kein gleiches System notwendig (aber ne gute Idee, so kann man dann auch schonmal testen, meistens willst du ja eh nicht auf dem Produktivserver probieren ob die neue Version genauso läuft wie die alte :-) ) Das ist eigentlich die schlaueste und einfachste Methode, weil auch durch die Distribution unterstützt...

 

[Angel]

Hm.. Okay, ich musste gerad drei mal zwei Aussagen überlesen,
um meine Verwirrungen aus dem Weg zu räumen..

Zitat von Rain_Maker
Du hast die Bedeutung von "System aktuell halten" für einen Serveradmin verstanden.

Und

Zitat von doc
die version einer distri kann aber ruhig älter sein, wenn es weiterhin aktuelle patches gibt.

Irgend wie brannte sich eben in mein Gehirn ein, dass ich Etch nicht nutzen sollte.
Aber dann hab ich das von doc noch mal gelesen

Naja, und zum testen über die vmWare kann ich ja auch bedenkenlos mein etch verwenden
und gucken ob ich alles aktuell halten könnte und die Sicherheutsupdates rein bringe,
und den SSH Zugang mit Hilfe von einem Key-auth (richtig?) etwas mehr schütze.

Was das aktuell halten von Sicherheitsupdates etc. angeht,
ich glaube darüber braucht man nicht noch groß reden, denn auch ich als
kleiner Wald und Wiesen Admin (im Windows Bereich) weiß das solche
Geschichten eigentlich zu einer Selbstverständlichkeit gehören

Aber was den Server angeht..
Wenn die Prognosen hinkommen was ich bezüglich Lenny gelesen habe,
kann ich ja ende des Jahres mit einer Stable rechnen und mir das noch angucken

Gut ist ja zZ. auch, das ich auf meinen Etch (vmWare) schon mal Apache,
SQL Server, PHP zum laufen bekommen habe (was aber dank apt nicht schwer war).

Interessant wird es für mich (das hab ich bis dato noch nicht gemacht) ein
funktionierendes Mail-System (Postfix und Courier) auf zu setzen und das auch
richtig zum laufen zu bekommen

Mfg. Angel

 

[Gast1]

Naja, und zum testen über die vmWare kann ich ja auch bedenkenlos mein etch verwenden
und gucken ob ich alles aktuell halten könnte und die Sicherheutsupdates rein bringe,
und den SSH Zugang mit Hilfe von einem Key-auth (richtig?) etwas mehr schütze.

Noch mal im Klartext.

Wenn Debian für einen Server, dann immer stable.

Und ja, Key-Auth sollte man dem "normalen" Login mit Username/Passwort vorziehen, nur gerade bei Debian (und Derivaten) und SSL gab es vor ein paar Tagen eben dieses heftige Sicherheitsproblem, welches nun seine Kreise zieht und gerade in diesem Fall reichte ein simples "Sicherheitsupdates einspielen" nicht, obwohl das natürlich trotzdem erste "Adminpflicht" war.

Genauere Erklärungen finden sich in den geposteten Links.

 

[Angel]

Noch mal im Klartext.

Wenn Debian für einen Server, dann immer stable.

Genau das sind immer so aussagen, da hat man das Gefühl man denkt falsch.
Ich sage ich nutze dann mein etch und darauf kommt dann das man
immer eine stable benutzen soll und wenn man dann im Internet guckt weil
man durch solch einen Satz verunsichert ist, findet man folgendes...

Die aktuelle stabile Version, Debian Etch (4.0r3) genannt, wurde am 17. Februar 2008 veröffentlicht.

Quelle : http://de.wikipedia.org/wiki/Debian

Somit sollte dem dann nichts im weg stehen.
Und dann gucke ich gleich ob ich z.B. die Patches für SSL eingebaut bekomme ohne
große Komplikationen, denn mit solch einer Lücke kann selbst ich nicht leben

Mfg. Angel

 

[Tblue]

Und dann gucke ich gleich ob ich z.B. die Patches für SSL eingebaut bekomme ohne
große Komplikationen, denn mit solch einer Lücke kann selbst ich nicht leben

Die sind bereits in den Debian-Paketen gefixt (war ja auch ein Debian-Problem).

 

[bitmuncher]

SSL-Zertifikate müssen aber neu erstellt werden.

 

[Lord_x]

Die sind bereits in den Debian-Paketen gefixt (war ja auch ein Debian-Problem).

Anscheinend betrifft es nicht nur Debian, Ubuntu ect.!
http://www.heise.de/newsticker/OpenSSL-Wirrwarr-verunsichert-Anwender-und-Admins--/meldung/108005

PS: Ubuntu 6.06.2 LTS ist nicht betroffen!

 

[Tblue]

Es sind nur andere Systeme betroffen, wenn du dort mit dem verwundbarem Debian-OpenSSL erstellte Schlüssel bzw. Zertifikate verwendest.

SSL-Zertifikate müssen aber neu erstellt werden.

Ja, das stimmt, aber Angel redete von Patches. Aber du hast natürlich Recht.

 

[Lord_x]

Es sind nur andere Systeme betroffen, wenn du dort mit dem verwundbarem Debian-OpenSSL erstellte Schlüssel bzw. Zertifikate verwendest.

Stimmt

 

[Angel]

Die sind bereits in den Debian-Paketen gefixt (war ja auch ein Debian-Problem).

Naja, ich glaube man muss aber ein aptitude dist-upgrade ausführen,
damit das schon mal gefixt wird, denn ganz von selbst macht das OS sowas nicht

SSL-Zertifikate müssen aber neu erstellt werden.

Hm.. Wenn ich das richtig sehe, dürfte das ja kein sehr großer akt sein.
Hab da einen kleinen Leitfaden gefunden...
-> http://www.werthmoeller.de/doc/microhowtos/openssl/

Ich muss sowieso mal ein Upgrade von etch auf der vmWare machen..
Aber mal was zu der Key geschichte, ich glaube ich hatte nen backport
in meiner sources.list drin und da quatschte er was von einem Key der mir wohl fehlt.
Das ist aber wieder etwas anderes, oder?

Ich würde jetzt gerne ein apt-get ausprobieren, aber das upgrade rennt momentan
und mit DSL384 dauert so etwas ein paar Minuten länger

 

[daboss]

Naja, ich glaube man muss aber ein aptitude dist-upgrade ausführen,
damit das schon mal gefixt wird, denn ganz von selbst macht das OS sowas nicht

apt-get upgrade reicht (mit apt-get update davor...)

Hm.. Wenn ich das richtig sehe, dürfte das ja kein sehr großer akt sein.
Hab da einen kleinen Leitfaden gefunden...
-> http://www.werthmoeller.de/doc/microhowtos/openssl/

Ich muss sowieso mal ein Upgrade von etch auf der vmWare machen..
Aber mal was zu der Key geschichte, ich glaube ich hatte nen backport
in meiner sources.list drin und da quatschte er was von einem Key der mir wohl fehlt.
Das ist aber wieder etwas anderes, oder?

Hm, normalerweiste steht bei den Backportlinks auch dabei, wie man den entpsrechenden Key hinzufügt?

 

[Angel]

Um.. okay, ich hab immer den aptitude dist-upgrade genommen.
Das erschien so logischer, aber gut zu wissen

Mal davon ab, ich werde wohl auch bei aptitude bleiben,
habe auf einer debian Seite gelesen das es "mächtiger" sein soll als apt-get,
weil es mehr Notizen macht und raus findet wo es Probleme geben könnte etc.

Was die Key Geschichte angeht, das hab ich auch lösen können..
Ist ganz easy wenn man weiß was man suchen soll..

Hab das ganze mit aptitude install debian-backports-keyring gelöst und
nun meckert er auch nicht mehr weil ich keinen Public Key besitze

Aber schon mal ein Danke für die Tipps und so..
Ich werde dann mal weiter arbeiten / spielen und gucken ob ich das alles
so eingerichtet bekomme wie ich mir das erhoffe

Mfg. Angel