Diskussionsthread zur Konfiguration von sarge-amd64

Nero24

Administrator
Teammitglied
Mitglied seit
01.07.2000
Beiträge
24.066
Renomée
10.445
  • BOINC Pentathlon 2019
  • BOINC Pentathlon 2020
  • BOINC Pentathlon 2018
  • BOINC Pentathlon 2021
Hallo allerseits,

so, nachdem das passende Betriebssystem für unsere Zwecke dank Euch gefunden wurde, gilt es nun, möglichst viele pfiffige Ideen für die Konfiguration zusammen zu tragen. Dazu zählt noch nicht, mit welchen Compiler-Flags man am besten irgendwelche Sources übersetzt, um das letzten Quäntchen Leistung herauszuquetschen. Dafür machen wir nochmal einen eigenen Thread, wenn der Server läuft ;)

Hier geht's vorwiegend darum, welche Software-Pakete man für die genannten Zwecke verwendet und wie man sie bestmöglichst mit der zur Verfügung stehenden Hardware (siehe Thread) konfigurieren könnte, sodass sowohl in Sachen Sicherheit, als auch in Sachen Performance das Maximum heraus springt.

Zur Erinnerung: wir haben EINEN Server, mit ZWEI CPUs, zwei als Raid-1 laufende SCSI-Platten. Auf dem Server soll ein HTTP samt CGI und PHP laufen, ein MySQL-Server, ein eMail-Server. Irgendwie müssen die Admins (die der Seite, nicht des Systems) auch Dateien hochladen können. Ob per FTP oder anders gilt es zu diskutieren.

Dann mal los :)
 
Irgendwie müssen die Admins (die der Seite, nicht des Systems) auch Dateien hochladen können. Ob per FTP oder anders gilt es zu diskutieren.
Ein FTP-Server ist eigentlich nur als Sicherheitslücke brauchbar.
Datenaustausch ist problemlos, komfortabel und sicher über SCP möglich.
 
Mein Tipp zur Ganzen Sache lautet. macht nicht zuviel neu!

Ihr kennt euer bisheriges System ja nicht erst seit gestern, Ihr nehmt eine komplett neue Hardware Basis, also holt euch jetzt nicht noch mehr Probleme ins Haus.

Will heißen, kein anderes Forensystem, keine neue Datenbank.Von Gentoo auf debian wechseln würde ich auch nur wenn Ihr euch Privat auch Debian installiert! Zumal Ihr ja nur einen Server habt ....

Administration würde ich auch über ssh/scp handhaben. Bevor ich mir Portknocking für Webmin konfigurieren würde, würde ich lieber über Webmin nachdenken- ich denke nicht das man das braucht. Für eure Dienste müsst Ihr lieber früher als später lernen wie man sie konfiguriert.

Macht am Besten ne Liste der Software die Ihr jetzt habt und stimmt genau ab welche ihr ersetzt / ersetzen müsst.
 
apt-get install apache2-mpm-worker
apt-get install libapache2-mod-fastcgi
apt-get install libapache2-mod-php5 (oder eben 4)
apt-get install mysql-server-5.0 (oder eben 4.1)
apt-get install proftpd (wenn ftp gebraucht wird) den dann mit Verschlüsselung konfigurieren


ssh ist standard und webmin wird nicht benötigt meiner meinung nach.

da läuft dann schon mal remotezugriff und ein webserver mit datenbank
 
Ach ja nochwas, schaut euch doch auch mal an was vergleichbare Forenbetreiber so machen, 3dwin.net oder hardwareluxx, kaltmacher.de ... viell. haben die Mods noch gute Erfahrungen zu Hardware/Distri usw....ich kann mich dunkel erinnern das Heise.de auch mal nen Artikel zum eingesetzten System hatte ist zwar ne andere Liga aber viell. kann man sich Ideen holen.

Gefunden, naja zumindest teilw:
http://www.heise.de Technik
 
Moin,

Da auf dem System eine mysql laufen soll, ist es umbedingt anzuraten die gepatchte libc6 aus sarge-unsupported aka "stinkypete" zu benutzen:

deb http://amd64.debian.net/debian/ stinkypete main

Diese libc6 hat eine gepatchte NPTL die sporadische Lockups einzelner Mysql Threads beim INSERT fixt.

Ferner ist natürlich auch die Benutzung von Paketen aus Volatile anzuraten, zb wenn der clamav als Virenscanner zum Einsatz kommen soll:

deb http://volatile.debian.net/debian-volatile/ sarge/volatile main

HTH
bofh
 
Ihr werdet mit Debian Probleme bekommen, wenn ihr 32bit-Apps ausführen müsst (z.B. Verwaltungstools von einem RAID-Controller). Debian ist (noch) nicht multiarch, so dass wirklich nur 64bit-Anwendungen unterstützt werden. Solltet ihr vielleicht nochmal überdenken.
 
Moin,

Ihr werdet mit Debian Probleme bekommen, wenn ihr 32bit-Apps ausführen müsst (z.B. Verwaltungstools von einem RAID-Controller). Debian ist (noch) nicht multiarch, so dass wirklich nur 64bit-Anwendungen unterstützt werden. Solltet ihr vielleicht nochmal überdenken.

3ware hat 64bit tools, icp-vortex hat einen statisch gelinktes consolen-tool, und das meiste andere sollte mit ia32-libs problemlos funktionieren.

HTH
bofh
 
Stimme RLZ zu.... Zum Uppen von Files muss man nicht mehr FTP benutzen.

Unter Windows exestiert zB. winscp. Hat ne ähnliche Oberfläche wie der Explorer und lässt sich genau so handhaben wie ein FTP-Client.

ALso, auch hier nochmal die Unterstützung für ssh (aber bitte v2).

Mit ssh kann man sich auch mal die Oberfläche auf den eigenen rechner holen (falls es Grafisch sein soll....)
 
Mit ssh kann man sich auch mal die Oberfläche auf den eigenen rechner holen (falls es Grafisch sein soll....)

Also ich würde auf dem Server nichtmal ein X installieren, insofern erübrigt sich X-forward. Ich denke die angesprochenen Dienste lassen sich auch gut ohne X administrieren.
 
warum wollt ihr eigentlich von gentoo weg wenn man fragen darf?

lg s.
 
hallo leute,

es ist wenig sinnvoll die entscheidung fuer debian sarge in diesem thread wieder in frage zu stellen. auf diese weise kommt das projekt leider nicht voran.

wie wäre es statt dessen vorerst bei der entscheidung fuer debian zu bleiben und parallel zu diesem thread, einen weiteren thread fuer bedenken oder sinnvolle gegenvorschläge zu eröffnen.

weiterhin wäre es vielleicht praktisch wenn sich admins mit erfahrungen beim aufsetzen von debian-server bei nero melden würden. damit wären ansprechpartner fuer das project gesichert die im zweifelsfall während der umsetzung mit rat und tat zur seite stehen können.

mfg, Gandalf20000
 
weiterhin wäre es vielleicht praktisch wenn sich admins mit erfahrungen beim aufsetzen von debian-server bei nero melden würden. damit wären ansprechpartner fuer das project gesichert die im zweifelsfall während der umsetzung mit rat und tat zur seite stehen können.

Die Idee find ich gut! Hab Nero ne PM mit nem kurzem Abriss meiner Erfahrungen geschickt, hoffe das sich noch ein paar mehr Leute finden!

Ist auf jeden Fall ein spannendes Projekt.
 
Also ihr habt natürlich recht, dass Webmin nicht notwendig ist. Ich kann nur aus eigener Erfahrung sprechen, dass ich am Anfang froh darum war. Natürlich kann man aber alles auch ohne webmin administrieren - es wäre halt vielleicht anfangs eine willkommene Unterstützung...
Und Portknocking würde ich so oder so zur Absicherung von ssh einsetzen. Es ist einfach eine Massnahme mehr, die Sicherheit vor einem Angriff zu erhöhen, die einfach einzurichten und zu handhaben ist. Deswegen erübrigen sich natürlich nicht die weiteren Massnahmen so strikt wie möglich zu handhaben. Beispielsweise das Ändern des Standardports von ssh oder eine strikte Konfiguration der iptables und der daemons. Ich meine auch trotz einer Alarmanlage lässt man seine Wertsachen ja nicht im Wohnzimmer rumliegen, sondern schafft sich zusätzlich einen Tresor an ;D Im konkreten Fall scheinen sich ja einige übliche Absicherungsmassnahmen nicht durchführen zu lassen. Da, wie Nero schrieb, das P3Dnow! Projekt viel in der Freizeit und in der Pause gepflegt wird, lässt sich beispielsweise nur schwierig eine restriktiv sinnvolle IP-Beschränkung einrichten, da ich davon ausgehe, dass er und sein Team von diversen IPs, womöglich dynamischer Art aus Zugriff haben müssen, ohne die im Vorfeld alle zu kennen.

Und natürlich habt ihr auch recht, dass ein FTP Server nicht unbedingt notwendig ist. Ich weiss ja nicht wie der Bedarf aussieht - aber ein FTP Server könnte schon Sinn machen, weil man ja nicht unbedingt alle Leute, die Files uppen gleichzeitig einen Konsolenzugriff gewähren will. Ich denke an Redaktionsmitglieder, die für einen Artikel Bilder hochladen wollen oder Gastkolumnisten, die ihre Artikel hochladen wollen, ohne dass sie in ssh/scp eingeführt werden müssten. Von der Systembelastung her, dürfte ein FTP-Server ja nicht ins Gewicht fallen.
Im Endeffekt kommt es auf den Bedarf an.

Eine Ergänzung zur bisherigen Ausstattung, wäre vielleicht noch "munin": ein Tool zur grafischen Bereitstellung von Informationen aller Art (z.B. Memory- und CPU-Auslastung, mysql/apache-Stati, Temperaturen/Voltages/FAN-speed, Mailqueue usw.). Munin nützt rdd und ist ebenfalls bei debian im repository.
So sehen Beispiel-Auswertungen dann aus: https://supervision.globenet.org/munin/globenet.org/index.html
 
Zuletzt bearbeitet:
Ihr werdet mit Debian Probleme bekommen, wenn ihr 32bit-Apps ausführen müsst (z.B. Verwaltungstools von einem RAID-Controller). Debian ist (noch) nicht multiarch, so dass wirklich nur 64bit-Anwendungen unterstützt werden. Solltet ihr vielleicht nochmal überdenken.
Moechte diese Bedenken unterstreichen, ich finde jene Entscheidung wurde ein wenig zu hastig getroffen.

Nero, was die BSDs angeht, hoere nicht auf die Leute, die behaupten, *BSD waere eine Freakloesung und schwierig um Umgang. BSD bedient schon viel laenger als Linux oder Windows den Servermarkt aeusserst erfolgreich, siehe hotmail. BSD ist auch nicht schwehrer zu handhaben, es ist minimal anders als Linux, viele Einstellungen sind uebersichtlicher, weil im Grunde das ganze Basissystem von einem Team kommt. Auf Binaerkompatiblitaet und Aehnliches wird extrem viel Wert gelegt, und die Fehlerbehandlung ist sehr ueberschaubar, man muss die entsprechende Mailingliste verfolgen und umfangreich ueber Probleme, Updates und Sicherheitsrisiken informiert zu werden. Wobei das Debian-Team das auch mit extrem viel Manpower und Arbeitsaufwand auch hinbekommt wie kaum ein anderes Gnu/Linux Projekt.

Was oft fuer Verwirrung sorgt, ist die Entscheidung der BSD Projekte, Services solange nicht laufen zu lassen, oder kritische Zugriffe auf das System wie Rootzugriff ueber ssh, bis es ausdruecklich verlangt wird -- eine Sicherheits- und Performance-Frage.

Dazu ist zu sagen, dass FreeBSD das am besten dokumentierte Unix ist, bei dem ich angehalten wurde es zu nutzen und die Liste ist lang. Anfaenglich bin ich aus diesem Grund bei FreeBSD geblieben, die hervorragend Dokumentation hilft ungemein. Dazu kommt, dass man sich nicht mit Unmengen alter Dokumentation herumschlagen muss, wie es bei vielen Linux-Howtos der Fall ist

...dass ich grundsaetzlich BSD fuer hochwertiger halte als jedes Linux-system ist eine Frage dessen was ich weiss, das kann der naechste schon anders sehen. Jedoch wuerde ich dieser Tage fuer ein AMD64 System den NetBSD AMD64 benutzen, denn die haben den aeltesten und ausgereiftesten AMD64 Port. (Juli 2001 lief er erstmalig) Zudem kommt NetBSD 3.0 die Tage und NetBSD hat in letzter oft bewiesen wie schnell ist sein kann.

Zum Thema MySQL:
Wenn schon MySQL dann stellt sicher, dass ihr InnoDB benutzt, denn MyISAM ist datenbanktechnisch gesehen eine Katastrophe, der MySQL ihren schlechten Ruf verdankt.
 
Moin,

<off-topic>

Jedoch wuerde ich dieser Tage fuer ein AMD64 System den NetBSD AMD64 benutzen, denn die haben den aeltesten und ausgereiftesten AMD64 Port. (Juli 2001 lief er erstmalig) Zudem kommt NetBSD 3.0 die Tage und NetBSD hat in letzter oft bewiesen wie schnell ist sein kann.

NetBSD ist prima wenn man exotische Hardware hat, auf der sonst nix läuft, zb alte RS600er - aber als Server-Betriebssystem für einen Dual-Opteron ist das nix, alleine wegen der viel zu jungen Unterstüzung für SMP (auch noch auf dem Big Kernel Lock basierend, wie Linux 2.0 vor 6 Jahren), viel zu junger posix threads implementation, etc.

Was in diesem Fall im vergleich zu NetBSD für GNU/Linux spricht, sind das granulare SMP Locking im 2.6er Kernel, durchgehender NPTL support, der 0(1) sceduler, die ausgereifte ACPI unterstützung, wesentlich breitere Treiber-Unterstützung, usw.

Ausserdem hat NetBSD gerade mal knapp 3 Wochen vor dem ersten GNU/Linux kernel _Release_ mit AMD64 Support (6 Juli 2001) ein erstes Grundgerüst für den Port ins CVS committed (19 Juni 2001), da grosspurig vom "aeltesten und ausgereiftesten AMD64 Port" zu sprechen ist dann doch etwas hoch gegriffen, nicht wahr ;-)

</off-topic>

MfG
bofh
 
Also ihr habt natürlich recht, dass Webmin nicht notwendig ist. Ich kann nur aus eigener Erfahrung sprechen, dass ich am Anfang froh darum war. Natürlich kann man aber alles auch ohne webmin administrieren - es wäre halt vielleicht anfangs eine willkommene Unterstützung...
Und Portknocking würde ich so oder so zur Absicherung von ssh einsetzen. Es ist einfach eine Massnahme mehr, die Sicherheit vor einem Angriff zu erhöhen, die einfach einzurichten und zu handhaben ist. Deswegen erübrigen sich natürlich nicht die weiteren Massnahmen so strikt wie möglich zu handhaben. Beispielsweise das Ändern des Standardports von ssh oder eine strikte Konfiguration der iptables und der daemons. Ich meine auch trotz einer Alarmanlage lässt man seine Wertsachen ja nicht im Wohnzimmer rumliegen, sondern schafft sich zusätzlich einen Tresor an ;D Im konkreten Fall scheinen sich ja einige übliche Absicherungsmassnahmen nicht durchführen zu lassen. Da, wie Nero schrieb, das P3Dnow! Projekt viel in der Freizeit und in der Pause gepflegt wird, lässt sich beispielsweise nur schwierig eine restriktiv sinnvolle IP-Beschränkung einrichten, da ich davon ausgehe, dass er und sein Team von diversen IPs, womöglich dynamischer Art aus Zugriff haben müssen, ohne die im Vorfeld alle zu kennen.

Und natürlich habt ihr auch recht, dass ein FTP Server nicht unbedingt notwendig ist. Ich weiss ja nicht wie der Bedarf aussieht - aber ein FTP Server könnte schon Sinn machen, weil man ja nicht unbedingt alle Leute, die Files uppen gleichzeitig einen Konsolenzugriff gewähren will. Ich denke an Redaktionsmitglieder, die für einen Artikel Bilder hochladen wollen oder Gastkolumnisten, die ihre Artikel hochladen wollen, ohne dass sie in ssh/scp eingeführt werden müssten. Von der Systembelastung her, dürfte ein FTP-Server ja nicht ins Gewicht fallen.
Im Endeffekt kommt es auf den Bedarf an.

Eine Ergänzung zur bisherigen Ausstattung, wäre vielleicht noch "munin": ein Tool zur grafischen Bereitstellung von Informationen aller Art (z.B. Memory- und CPU-Auslastung, mysql/apache-Stati, Temperaturen/Voltages/FAN-speed, Mailqueue usw.). Munin nützt rdd und ist ebenfalls bei debian im repository.
So sehen Beispiel-Auswertungen dann aus: https://supervision.globenet.org/munin/globenet.org/index.html

Trotzdem ist es sinnlos bei einem öffentlichen Server dieser Größe Standardports umzumappen oder Portknocking einzuführen. Port 80 muss sowieso frei zugänglich sein und jedes Script-Kiddie kann heutzutage einen Portscanner bedienen.

Was nützt es dann, das sehr sichere SSH zu "tarnen", wenn ein Hack über eine potentielle Schwachstelle im Apache bzw. CMS viel einfacher ist. Vergleichbar wäre die Haustür mit Panzerschloß und Keycard zu sichern, wenn hinten die Balkontür offen steht.

Richtig wäre eine andere Herangehensweise. Nämlich nur Dienste anzubieten und Ports zu öffnen die unbedingt notwendig sind. Und da ist Webmin schon mal eine Schwachstelle mehr. FTP sollte man - wenn möglich - nicht mehr einsetzen, da dort Passwörter unverschlüsselt übertragen werden, wenn dann entweder SCP oder S-FTP. Email, wie es erforderlich ist, wobei ein rein sendender Betrieb ohne von außen sichtbaren SMTP das sicherste wäre.

Port-Knocking hat auch immer die Gefahr, dass es aus einem dummen Grund (Benutzerfehler, höhere Komplexität führt auch zu höherer Ausfallrate auf technischer Ebene) plötzlich nicht mehr funktioniert. Ich kenne genug Fälle aus eigener Erfahrung, wo man sich schon bei "normaler" Firewall ausgesperrt hat.
 
NetBSD ist prima wenn man exotische Hardware hat, auf der sonst nix läuft, zb alte RS600er - aber als Server-Betriebssystem für einen Dual-Opteron ist das nix, alleine wegen der viel zu jungen Unterstüzung für SMP (auch noch auf dem Big Kernel Lock basierend, wie Linux 2.0 vor 6 Jahren)
Moechtest du mir sagen Linux 2.2 und 2.4 haetten gute SMP Performance?
Das kann nicht dein ernst sein. 2.2 und SMP war absolut grauenvoll und 2.4 war bis 4 CPUs akzeptabel aber deutlich langsamer als Windows NT.

Dein Vergleich stimmt so nicht.

Des weiteren ist ein Datenbank/Webserver mit 2 CPUs noch nicht darauf angewiesen, da kaum ein Prozess in den Kernel wechselt, waehrend sich ein paar Threads mit dem RDBMS und dem Webserver herumschlagen. Die Warscheinlichkeit, dass gerade 2 Prozesse in Kernelspace wechseln wollen ist bei solch einem Vorhaben und nur 2 CPUs verschwindend gering, daher sind deine Einwaende uebertrieben.

NetBSD Threading ist beispielweise 8 mal schneller beim Erstellen, Starten und Zerstoeren eines Threads als GNU PTH und LinuxThreads --- beim locken und unlocken eines Mutex' etwas langsamer als GNU PTH und etwas schneller als LinuxThreads --- und beim context switching sind sie aehnlich wie GNU PTH doch langsamer als die LinuxThreads.

viel zu junger posix threads implementation, etc.
NetBSD gehoert zu den schnelleren BSDs derzeit, und supported heisst unter BSD noch etwas anderes als unter Linux.
Was in diesem Fall im vergleich zu NetBSD für GNU/Linux spricht, sind das granulare SMP Locking im 2.6er Kernel, durchgehender NPTL support, der 0(1) sceduler, die ausgereifte ACPI unterstützung, wesentlich breitere Treiber-Unterstützung, usw.
  • Ich halte nicht viel vom "granularen SMP Locking", aber wenn du das fuer so wichtig erachtest, dann ist FreeBSD eine Alternative. Mit Release 6.0 ist denen ein beachtenswerter Sprung gelungen, nachdem die 5er Reihe durch die starken Umstellungen deutlich gelitten hat. Ich halte jedoch nichts von diesem "fine grained locking", daher fand ich DragonFly als bessere Forsetzung von FreeBSD 4
  • 0(1) -- Wo ist da jetzt der Vorteil? Meine Erfahrung hat mir bisher gezeigt, dass BSDs unter Last sich deutlich besser verhalten als Linux, auch wenn noch 10mal soviel Wind um diesen Scheduler gemacht wird, auch wenn die Veraenderungen der BSDs in den Medien nicht so breitgetreten werden, sind sie trotzdem nicht schlechter. Was genau macht der NetBSD Sched. schlechter als der Linux 0(1) mal abgesehen von der Publicity.
  • ACPI -- benutzen alle das Intel Referenzmodell, Linux bietet mehr Workarounds fuer Herstellerquirks, halte ich jedoch fuer ueberfluessig bei einem Server der staendig unter Last steht. Solange das Interrupt handling vernuenftig funktioniert, ist der Rest irrelevant, einen Werbserver lasse ich nicht hybernaten.
Ausserdem hat NetBSD gerade mal knapp 3 Wochen vor dem ersten GNU/Linux kernel _Release_ mit AMD64 Support (6 Juli 2001) ein erstes Grundgerüst für den Port ins CVS committed (19 Juni 2001), da grosspurig vom "aeltesten und ausgereiftesten AMD64 Port" zu sprechen ist dann doch etwas hoch gegriffen, nicht wahr ;-)
Das Basesystem lief nach dem Commit von Wasabisystems, das vom ersten autauchen des Ports im Linuxkernel zu behaupten waere unrealistisch. Der Kernel war keinesfalls auch nur irgendwie vernuenftig lauffaehig und das GNU Userland etwa 2 Jahre von einer Benutzbarkeit entfernt. Der Vorsprung NetBSDs war enorm.

Auch ist die Arbeitsweise von Wasabisystems dabei zu beachten, denn hier wurde ein lauffaehiger Port commited, wahrend im Linuxkernel irgendwo unter "experimentell" die ersten Arbeiten zu finden waren, weil gerade der Bitkeeperstatus eingefroren und released worden ist, oder findest du AMD64 war unter Linux 2.4.6 lauffaehig?
 
Zuletzt bearbeitet:
hallo leute,

es tut mir wirklich leid, aber ich denke dieser thread hilft nero nicht wirklich weiter!
ihr fangt an grabenkriege gegeneinander zu führen. diese sind zwar sehr interessant und stellenweise amüsant zu lesen, helfen aber bei der sache nicht weiter.

ich persönlich betrachte die entscheidung fuer debian als sinnvoll. schon allein auf grund der tatsache da es auf dem board einige leute gibt die ueber viel erfahrung damit verfügung.

in anbetracht der tatsache das nero einen zeitrahmen fuer das projekt gesetzt hatte, würde ich vorschlagen diese diskussion wieder zielgerichtet zu führen! es geht also darum ein debian system zu konfigurieren... weiterhin wäre fuer das projekt eine kleine risiko abschätzung und eine genauere zeitschiene nicht schlecht. diese kann allerdings nur von den verantwortlichen abgegeben werden.

also, nochmals die bitte ... führt eure grabenkämpfe woanders. jeder hat seine vorlieben als server betriebssystem.

bringt eure erfahrungen ein, aber um mit dem projekt voran zu kommen wäre es sinnvoll sich mit der konfiguration zu beschäftigen. sonst läuft die diskussion ob debian, netbsd, solaris, usw. noch nächstes weihnachten.

mfg, Gandalf20000
 
weiterhin wäre fuer das projekt eine kleine risiko abschätzung und eine genauere zeitschiene nicht schlecht. diese kann allerdings nur von den verantwortlichen abgegeben werden.
Zur Zeitschiene - siehe hier :)
http://www.planet3dnow.de/vbulletin/showthread.php?p=2506226#post2506226

Ansonsten möchte ich die Teilnehmer bitten, zum eigentlich Thema zurück zu kommen, das da lautet "Konfiguration von sarge-amd64". Sicherlich gibt es unzaehlige weitere Distributionen oder Betriebssysteme und jedes einzelne hat seine Vor- und Nachteile. Aber für irgendeines mussten wir uns entscheiden und das war nun einmal Debian.

Man möge uns verzeihen, dass der Thread von unserer Seite aus momentan noch nicht so stark moderiert/frequentiert wird. Das liegt daran, dass wir momentan noch gar nichts zum konfigurieren haben *chatt* Wenn die Hardware komplett und zusammen gebaut ist und ich vor dem Teil sitze, dann wird sich das vermutlich schlagartig aendern ;)
 
Zur Zeitschiene - siehe hier :)
http://www.planet3dnow.de/vbulletin/showthread.php?p=2506226#post2506226

Ansonsten möchte ich die Teilnehmer bitten, zum eigentlich Thema zurück zu kommen, das da lautet "Konfiguration von sarge-amd64". Sicherlich gibt es unzaehlige weitere Distributionen oder Betriebssysteme und jedes einzelne hat seine Vor- und Nachteile. Aber für irgendeines mussten wir uns entscheiden und das war nun einmal Debian.
Aus welchen Gruenden habt ihr euch denn entschieden? Wisst ihr womit ihr beim amd64 Port von sarge, der immerhin bis 'etch' inoffiziell bleiben wird, zu rechnen habt?

Ich hab das Gefuehl, dass auf Pucks Warnung nicht eingegangen wird und wenn dann die Arbeit ansteht, gibt's ploetzlich Probleme und eine ungeplante Testphase um alte Entscheidungen aufzurollen und damit wie so oft in IT Projekten, die bekannten Verzoegerungen.

Anstatt seine Entscheidung gefaellt haben zu wollen bevor die Hardware da ist, halte ich eine Testphase mit Hard- und Software fuer viel sinnvoller.

Es ist einfach wichtig sich nicht nur theoretisch neuen Problematiken zu stellen, sondern gezielt Probleme in der Praxis auszuloten und das bedeuted, vermutete Probleme auf ihre Auswirkungen hin in einer Testphase, fuer die man sich Zeit nimmt, anzugehen.
 
Zuletzt bearbeitet:
Die Entscheidung pro Debian ist gefallen
a.) aufgrund der vielen Empfehlungen im Diskussionsthread
b.) da sich das Wartungspersonal vor Ort mit Debian auskennt (mit BSD nicht)
c.) da es einige Teammember gibt, die sich mit Debian sehr gut auskennen (mit BSD nicht)
(d.) um dem bekennenden BSD-Verfechter Tom24 absichtlich eine reinzuwürgen ;))

Sollte es wegen der von Puck angesprochenen Einschraenkung tatsaechlich zu Schwierigkeiten bei der Installation kommen, dann treten die normalerweise bereits am ersten Tag auf. Sollte das wirklich der Fall sein, kann man immer noch auf die "sichere Bank" RedHat oder SuSe wechseln. Die "IT-typischen Verzögerungen", die Du angesprochen hast, dürfte es daher nur sehr eingeschraenkt geben. Entweder es laeuft oder es laeuft nicht. Letzteres werde ich aber sehr schnell merken ;) (dann kommt Windows drauf *chatt* ;))

Aber eine Entscheidung in welche Richtung es gehen soll ist notwendig, um den Usern genügend Zeit zu geben, sich mit Ideen und Lösungen in diesem Thread einzubringen. Wenn die Hardwareteile ein paar Tage vor Weihnachten erst kommen (und davon ist auszugehen, da AMD die Opterons z.B. aus USA liefern laesst), brauche ich nicht mehr daher zu kommen und auf großartige Tips hoffen. Da sollte es dann nur noch um Details gehen.
 
Was nützt es dann, das sehr sichere SSH zu "tarnen", wenn ein Hack über eine potentielle Schwachstelle im Apache bzw. CMS viel einfacher ist. Vergleichbar wäre die Haustür mit Panzerschloß und Keycard zu sichern, wenn hinten die Balkontür offen steht.
Wie bitte? "Sehr sicheres ssh" ? Erstens ist imho sehr sicherheitsrelevant und imho ist es nicht verkehrt ein paar Vorkehrungen zu treffen und drittens ein beliebtes "Angriffsziel".

Richtig wäre eine andere Herangehensweise. Nämlich nur Dienste anzubieten und Ports zu öffnen die unbedingt notwendig sind. Und da ist Webmin schon mal eine Schwachstelle mehr.
Ja - mit Webmin hast du natürlich Recht - aber nochmal - es geht ja AUCH darum, das System schnellstmöglich in den Griff zu bekommen.
Und ssh ist halt praktisch unverzichtbar - also geht's ja darum dies so sicher wie möglich zu bewerkstelligen.

FTP sollte man - wenn möglich - nicht mehr einsetzen, da dort Passwörter unverschlüsselt übertragen werden, wenn dann entweder SCP oder S-FTP. Email, wie es erforderlich ist, wobei ein rein sendender Betrieb ohne von außen sichtbaren SMTP das sicherste wäre.
Hierfür (PW unverschlüsselt) gibt es ja diverse Schutzmöglichkeiten (Auth TLS oder Auth SSL z.B.)

Port-Knocking hat auch immer die Gefahr, dass es aus einem dummen Grund (Benutzerfehler, höhere Komplexität führt auch zu höherer Ausfallrate auf technischer Ebene) plötzlich nicht mehr funktioniert. Ich kenne genug Fälle aus eigener Erfahrung, wo man sich schon bei "normaler" Firewall ausgesperrt hat.
Ja - aber Portknocking sperrt dich nicht aus - sondern "öffnet die Türe"...

Es ist übrigens Ironie, dass ausgerechnet das "Securing Debian Howto" als Schutzmöglichkeit vor dem "Ausperren" durch falsche Firewall (iptables) Settings Portknocking erwähnt - nämlich gerade weil es ja auf dem link-layer VOR der firewall läuft, mit einer Sequenz, welche die Firewall wieder "entsperrt". Vielleicht wäre es ja am Ende auch für dich noch was ;D (siehe Abschnitt 5.14.3.5 - knockd)

greets
 
Wie bitte? "Sehr sicheres ssh" ? Erstens ist imho sehr sicherheitsrelevant und imho ist es nicht verkehrt ein paar Vorkehrungen zu treffen und drittens ein beliebtes "Angriffsziel".

Ja - aber Portknocking sperrt dich nicht aus - sondern "öffnet die Türe"...

Es ist übrigens Ironie, dass ausgerechnet das "Securing Debian Howto" als Schutzmöglichkeit vor dem "Ausperren" durch falsche Firewall (iptables) Settings Portknocking erwähnt - nämlich gerade weil es ja auf dem link-layer VOR der firewall läuft, mit einer Sequenz, welche die Firewall wieder "entsperrt". Vielleicht wäre es ja am Ende auch für dich noch was ;D (siehe Abschnitt 5.14.3.5 - knockd)

greets

Also mir ist weder aus meinem persönlichem Umfeld noch allgemein ein einziger gehackter SSH-Zugang bekannt. Darunter sind Linux-Kisten, die seit über 6 Jahren direkt am Netz hängen. Nahc kurzem Durchschauen waren die SSH-Lücken alle aus den Jahren 2002 und vorher. Abgesehen davon gibt es für so etwas Patches, die über apt-get sehr schnell eingespielt werden können und sollten.

Beliebte Angriffsziele sind viel eher Webserver. Ein Defacement über Lücken im CMS oder Webserver ist viel Publicitywirksamer und häufig einfacher, als sich irgendwo einen SSH-Zugang zu verschaffen.

Portknocking halte ich trotzdem für nicht notwendig. Wenn man mal schnell unterwegs von einem fremden Rechner auf den Server zugreifen will, braucht man wieder spezielle Tools um etwas zu machen. Das ist aber nicht immer möglich und kostet zudem wieder Zeit und Aufwand.

Ich kenne keinen der es einsetzt. Wenn man eine Maschine "stealth" im Netz betreiben will, ist das vertretbar, das sehe ich ein. Aber bei einem Server, wo am Tag mehrere Zehntausend Menschen zugreifen, lohnt das Verstecken sicherer Ports nicht wirklich, wenn man unsicherere Dienste öffentlich anbietet.
 
Zurück
Oben Unten