Homeserver - Tutorial gesucht!

[Günther Raab]

Hallo,
ich habe hier zu Hause einen Rechner mit Mandrake, das ganze hängt an einem Router, an dem noch 2 Rechner hängen.

Nun möchte ich mir einen Homeserver einrichten.

Also einen Usernamen und eine Domain von DynDNS und auf dem Rechner nen FTP Dämon und nen Webserver installieren.

Ich brauche für den Webserver keine Besonderheiten, muss also nicht PHP oder sonstige Module können, einfach nur n Server dass man auf meine Dateein zugreifen kann.

Das soll dan etwa so aussehen, dass ich einen extra User anlege, z.B. "netz" und da dann die unterordner "ftp" und "http" anlege.

In http lege ich dann meine ganzen Datein rein, die frei zugänglich sind und in ftp will ich zugänge einrichten können, mit username und passwort.

dass ich also irgendwie dort user anlegen kann, die dann einen ordner im verzeichnis ftp bekommen (z.b. dann in /home/netz/ftp/username)

Soweit alles klar, aber nun meine Fragen:
Welchen Webserver soll ich da nehmen?
Welchen FTP-Dämon soll ich nehmen?
Wie funktioniert das mit DynDNS?
Was muss ich an meinem Router einstellen?
Wenn ich mal den Rechner ausschalte bekomm ich ja ne neue IP, wie wird die auf DynDNS wiueder eingerichtet, geht das automatisch?

Da gibts doch bestimmt n nettes Tutorial, sowas wie "Homelinux für Dummies" oderso ;)

Wäre nett wenn mir da jemand Links geben könnte und mir Empfehlungen aussprechen könnte.

Danke, Günther.

[Christoph Schnauß]

morgens,

ich habe hier zu Hause einen Rechner mit Mandrake, das ganze hängt an einem Router, an dem noch 2 Rechner hängen.

Schön.

Nun möchte ich mir einen Homeserver einrichten.

Was verstehst du darunter?

Also einen Usernamen und eine Domain von DynDNS

Überflüssig  -  es sei denn, du hast eine Standleitung oder eine Satellitenverbindung.

und auf dem Rechner nen FTP Dämon

Wozu der? Der Rechner steht bei dir, also kannst du ihn völlig ohne FTP warten.

und nen Webserver

Der ist allerdings kein Problem.

Das soll dan etwa so aussehen, dass ich einen extra User anlege, z.B. "netz" und da dann die unterordner "ftp" und "http" anlege.

Der Webserver hat mit FTP nichts zu tun. Du kannst dafür zwar einen extra user anlegen, das ist aber in der Regel völlig überflüssig. Es kommt auch nicht so sehr auf den "user" an, sondern mehr auf die "group", in der der dann stecken soll. Welche hast du vorgesehen?

In http lege ich dann meine ganzen Datein rein, die frei zugänglich sind

Wie meinst du das? Findest du nicht, daß du _deutlich_ besser fährst, wenn du deine "frei zugänglichen" Dateien bei einem öffentlichen Provider auf gemietetem Webspace ablegst?

und in ftp will ich zugänge einrichten können, mit username und passwort.

Für wen und warum?

Soweit alles klar

Nein, bis auf den Webserver ist gar nichts klar.

Welchen Webserver soll ich da nehmen?

Apache.

Welchen FTP-Dämon soll ich nehmen?

Keinen.

Wie funktioniert das mit DynDNS?

Steht dort zu lesen, aber du solltest das lieber bleiben lassen.

Was muss ich an meinem Router einstellen?

Nichts.

Wenn ich mal den Rechner ausschalte bekomm ich ja ne neue IP, wie wird die auf DynDNS wiueder eingerichtet, geht das automatisch?

Ja. Und was macht ein "user" in dieser Zeit? Warum willst du den unbedingt auf dem Schlauch stehen lassen? Nein, wenn überhaupt, wird dein Rechner und auch dein Router künftig im Dauerbetrieb laufen, ununterbrochen. Und damit du diese "Schwankungen" der IP nicht berücksichtigen mußt, brauchst du natürlich eine fixe IP-Adresse, und wenn du die hast, ist der Schnickschnack mit DYNDNS unsinnig und überflüssig.

Da gibts doch bestimmt n nettes Tutorial

Für den Webserver gibts eins, das du auch selber hättest finden können: http://aktuell.de.selfhtml.org/artikel/server/apacheconf/index.htm

Alles andere solltest du dir dringend nochmal überlegen. Diverse Debatten dazu findest du selbstverständlich im Forums-Archiv, das dir zur Recherche dringend empfohlen werden kann.

Grüße aus Berlin

Christoph S.

[Jeena Paradies]

Hallo,

Nun möchte ich mir einen Homeserver einrichten.
Was verstehst du darunter?

Einen Server zu Hause, den man auch aus dem Internet erreichen kann?

Also einen Usernamen und eine Domain von DynDNS
Überflüssig  -  es sei denn, du hast eine Standleitung oder eine Satellitenverbindung.

Ähm kann es sein, dass du heute ein bischen benommen bist? Wozu eine Standleitung, wenn er doch nur ein paar Leuten Seine Daten zur verfügung stellen will, bzw. nur sich selbst wenn er mal gerade nicht zu Hause ist? Eine Standleitung wäre ja der overkill! Und was eine Satellitenverbindung damit zu tun hat musst du mir jetzt mal erklären.

Wozu der? Der Rechner steht bei dir, also kannst du ihn völlig ohne FTP warten.

Hö, naja das Ding heißt ja File Transfer Protocol - das weißt du hoffentlich - und genau dazu will er es wohl benutzen.

Wie meinst du das? Findest du nicht, daß du _deutlich_ besser fährst, wenn du deine "frei zugänglichen" Dateien bei einem öffentlichen Provider auf gemietetem Webspace ablegst?

Warum sollte das besser sein, bzw. was ist daran besser? Das einzige was mir einfällt ist, dass die daten dann wirklich 24 Stunden ununterbrochen erreichbar sind. Wenn er sich schon für eine solche Dynamische Adresse entscheidet, dann ist ihm das schon bewusst dass es den 24h disconnect gibt. Ich habe es genau so gemacht wie er, um 1. den traffic, der Geld kostet zu minimieren und zweitens ist es viel einfacher eine Datei einfach in einem bestimmten Verzeichnis abzuspeichern und schon ist sie für alle von außen erreichbar, ohne dass ich ein ftp programm starten muss und sie dann rauf verschieben muss. Das benutze ich vor allem für Sachen wie Bilder und Beispiele für selfhtml: http://jeenaparadies.servebeer.com/open/selfbilder/ was spricht denn dagegen? Dass es nicht immer 100%ig erreichbar ist? Naja damit können die Leute auf jeden Fall leben, wenn sie was von mir wollen.

Grüße
Jeena Paradies

[nuss]

Moinsen,

morgens,

ich habe hier zu Hause einen Rechner mit Mandrake, das ganze hängt an einem Router, an dem noch 2 Rechner hängen.

Schön.

Sehr sinnvolle Antwort, du musst auch nicht alles kommentieren.

Nun möchte ich mir einen Homeserver einrichten.

Was verstehst du darunter?

Hättest du mal weitergelesen bevor du irgendnen Quark geschrieben haettest, er hat doch geschrieben was er darunter versteht.

Also einen Usernamen und eine Domain von DynDNS

Überflüssig  -  es sei denn, du hast eine Standleitung oder eine Satellitenverbindung.

Wenn er eine DynDNS will - wo ist das Problem?
Wenn du schon so eine plume Scheissantwort gibst dann begruende Sie wenigstens.

und auf dem Rechner nen FTP Dämon

Wozu der? Der Rechner steht bei dir, also kannst du ihn völlig ohne FTP warten.

Haettest du nur weitergelesen.
Hat er was von "warten" gesagt?
Er wollte seinen Freunden und Bekannten per FTP Zugriff auf seinen Rechner verschaffen.

und nen Webserver

Der ist allerdings kein Problem.

Genausowenig wie ein FTPD.

Das soll dan etwa so aussehen, dass ich einen extra User anlege, z.B. "netz" und da dann die unterordner "ftp" und "http" anlege.

Der Webserver hat mit FTP nichts zu tun.

Hat er das behauptet?

Du kannst dafür zwar einen extra user anlegen, das ist aber in der Regel völlig überflüssig.

Es ist nicht ueberfluessig, es ist wie ich finde eine gute Idee, da man dann nicht mal eben versehentlich irgendwelche persoenlichen Dokumente ins oeffentliche Verzeichnis kopieren kann - Das Risiko ist zumindest kleiner.

In http lege ich dann meine ganzen Datein rein, die frei zugänglich sind

Wie meinst du das? Findest du nicht, daß du _deutlich_ besser fährst, wenn du deine "frei zugänglichen" Dateien bei einem öffentlichen Provider auf gemietetem Webspace ablegst?

Findet er sicher nicht, sonst haette er nicht gefragt.
Ich meinerseits bin von den Vorteilen meines "Homeservers" ueberzeugt.
Wenn ich z.B. jemandem einige Dokumente schickien will, dann hardlinke ich Sie einfach in /etc/public und der kann sich da bedienen.
ansonsten muesste ich das ganze noch auf nen server hochladen und nachher wieder loeschen.
Und vor allem werden aenderungen sofort uebernommen, ich muss nicht nac jeder aenderung den scheiss nochmal hochladen.

und in ftp will ich zugänge einrichten können, mit username und passwort.

Für wen und warum?

Na fuer Bekannte wahrscheinlich.
Weil man nicht die Schwiegermutter auf den "Server" lotsen kann und da dann Pornofilmchen fuer den Kumpel drin sind.
Nicht alles ist "public".

Soweit alles klar

Nein, bis auf den Webserver ist gar nichts klar.

Fuer dich nicht, ich und eine ganze Menge andere Leute haben ihn verstanden.
Ich wuerde mir mal Gedanken ueber mich machen an deiner Stelle!?

Welchen Webserver soll ich da nehmen?

Apache.

die einzige, zumindest einigermassen sinnvolle Aussage in deinem Posting

Welchen FTP-Dämon soll ich nehmen?

Keinen.

das mit dem Sinnvollen war wohl eine Ausnahme...

Wie funktioniert das mit DynDNS?

Steht dort zu lesen, aber du solltest das lieber bleiben lassen.

Lass ihn doch probieren und _wenn_ du schon davon abraetst, dann begruende das bitte.

Wenn ich mal den Rechner ausschalte bekomm ich ja ne neue IP, wie wird die auf DynDNS wiueder eingerichtet, geht das automatisch?

Und was macht ein "user" in dieser Zeit?

Was soll er machen?
Warten!
Wo ist das Problem?
Auf nem Homeserver sind eh fast nie Leute drauf.

Warum willst du den unbedingt auf dem Schlauch stehen lassen?

ARGH!

Nein, wenn überhaupt, wird dein Rechner und auch dein Router künftig im Dauerbetrieb laufen, ununterbrochen. Und damit du diese "Schwankungen" der IP nicht berücksichtigen mußt, brauchst du natürlich eine fixe IP-Adresse, und wenn du die hast, ist der Schnickschnack mit DYNDNS unsinnig und überflüssig.

DynDNS ist _nicht_ ueberfluessig weil _normale_ MEnschen merken sich lieber sowas wie guenther.homelinux.net als 157.245.914.125

Da gibts doch bestimmt n nettes Tutorial

Für den Webserver gibts eins, das du auch selber hättest finden können: http://aktuell.de.selfhtml.org/artikel/server/apacheconf/index.htm

wieder einigermassen sinnvoll.

Alles andere solltest du dir dringend nochmal überlegen. Diverse Debatten dazu findest du selbstverständlich im Forums-Archiv, das dir zur Recherche dringend empfohlen werden kann.

.oO(...)

Grüße aus Berlin

Christoph S.

Gruss/Danke/Bitte
mfg nuss

[Jeena Paradies]

Hallo,

DynDNS ist _nicht_ ueberfluessig weil _normale_ MEnschen merken sich lieber sowas wie guenther.homelinux.net als 157.245.914.125

Außerdem kann man, wenn man nicht gerade an genau diesem Rechner sitzt nicht wirklich einfach seine neue IP Adresse herausfinden um von irgendwo anders mal schnell auf ihn zugreifen zu können.

Grüße
Jeena Paradies

[Christoph Zurnieden]

Hi,

was'n hier schon wieder los? ;-)

Mein Vornamensvetter mag etwas kurz angebunden gewesen sein, aber Recht hat er: ein Homeserver ist nicht zu empfehlen und schon mal gar nicht für Anfänger. Auch wenn über DSL nicht viel Unfug getrieben werden kann.

ich habe hier zu Hause einen Rechner mit Mandrake, das ganze hängt an einem Router, an dem noch 2 Rechner hängen.

Schön.

Sehr sinnvolle Antwort, du musst auch nicht alles kommentieren.

Doch dsa sollte er, denn diese Zusammenstellung ist genau das: schön. Nicht perfekt, aber auch nicht so - mit Verlaub - Scheiße, wie ein WinXP direkt am Netz mit zwei angehangene Win98 Clients. Die technischen Vorraussetzungen stimmen also schon mal.
"Schön" ist aber schon etwas _sehr_ kurz angebunden, zugegeben ;-)

Also einen Usernamen und eine Domain von DynDNS

Überflüssig  -  es sei denn, du hast eine Standleitung oder eine Satellitenverbindung.

Wenn er eine DynDNS will - wo ist das Problem?
Wenn du schon so eine plume Scheissantwort gibst dann begruende Sie wenigstens.

Wenn er keine Zeit hat, dann mache ich das: weil es überflüssig ist. Wie Christoph schon ganz richtig sagte: es gibt jede Menge billiger und zuverlässiger Hoster, die haben das gelernt, die können das. Muß ich erst darauf hinweisen, was so eine Maschine in 24h alleine an Strom verbraucht? Zudem ist in den allermeisten Anbindungsverträgen ein Betrieb von Servern eh verboten.

Haettest du nur weitergelesen.
Hat er was von "warten" gesagt?
Er wollte seinen Freunden und Bekannten per FTP Zugriff auf seinen Rechner verschaffen.

FTP ist heutzutage unsinnig, da gibt es bessere Mittel und Wege. Meist reicht da schon der Apache. Ja, auch für Upload.

und nen Webserver

Der ist allerdings kein Problem.

Genausowenig wie ein FTPD.

Ein FTPD _ist_ problematisch, da kriegst Du graue Haare! Wenn er nicht _unbedingt_ sein muß (der Kunde das z.B. bezahlt) würde ich sowas nicht einbauen.

Das soll dan etwa so aussehen, dass ich einen extra User anlege, z.B. "netz" und da dann die unterordner "ftp" und "http" anlege.

Der Webserver hat mit FTP nichts zu tun.

Hat er das behauptet?

Ja, denn der User "netz" hat hier beides unter sich, das ist tunlichst zu vermeiden. Wenn der User dann sogar noch eine Shell hat ging's wirklich daneben.

Es ist nicht ueberfluessig, es ist wie ich finde eine gute Idee, da man dann nicht mal eben versehentlich irgendwelche persoenlichen Dokumente ins oeffentliche Verzeichnis kopieren kann - Das Risiko ist zumindest kleiner.

Bei einem regulärem User ist das Risiko höher wg der Shell.
Aber die normalen begrenzten User/Groups ohne Login (meist wwwrun/wwwrun o.ä.) sind tatsächlich zu empfehlen. Ist dann zumindest etwas aufgeräumter.
Achso: ein user ist wirklich nicht per se nötig, das funktioniert alles auch ganz ohne!

Ich meinerseits bin von den Vorteilen meines "Homeservers" ueberzeugt.
Wenn ich z.B. jemandem einige Dokumente schickien will, dann hardlinke ich Sie einfach in /etc/public und der kann sich da bedienen.
ansonsten muesste ich das ganze noch auf nen server hochladen und nachher wieder loeschen.

Na, ob Du sie nun nach /etc/public (Global? Schlecht, lieber in /home etwas einrichten) kopierst und nachher wieder löscht oder auf den Server kopierst und nachher wieder löscht ist beides Mal die gleiche Arbeit.

Und vor allem werden aenderungen sofort uebernommen, ich muss nicht nac jeder aenderung den scheiss nochmal hochladen.

Dafür gibt es spezielle Services wie CVS u.ä., die das wunderbar unterstützen. Dann muß sich der Kollege ebenfalls nicht alles runterladen sondern kann sich mit dem Diff begnügen.
Ein CVS zu betreiben wäre z.B. ein guter Grund für einen Homeserver, aber den gibt's bei Sourceforge billiger, wenn's ein OpenSource Projekt ist.

Weil man nicht die Schwiegermutter auf den "Server" lotsen kann und da dann Pornofilmchen fuer den Kumpel drin sind.
Nicht alles ist "public".

Und wofür dann FTP, wenn's der Apache genausogut, wenn nicht besser kann?

Welchen FTP-Dämon soll ich nehmen?

Keinen.

das mit dem Sinnvollen war wohl eine Ausnahme...

Wieso? Ich finde das sehr sinnvoll von dem Betrieb eines FTP-Servers abzuraten. Vor allem Anfängern.

Auf nem Homeserver sind eh fast nie Leute drauf.

Nunja, muß nur einer auf die blöde Idee kommen und die Adresse bei /. posten, schon "raucht's aus'm Karton" ;-)

DynDNS ist _nicht_ ueberfluessig weil _normale_ MEnschen merken sich lieber sowas wie guenther.homelinux.net als 157.245.914.125

Es gibt mitunter gute Gründe für den Einsatz von DynDNS, aber der gehört da nicht zu ;-)
(Hauptsinn von DynDNS ist es heutzutage, eine _wechselnde_ IP zu maskieren. Das man sich Worte besser merken kann als Zahlen ist dabei nur beiläufig, wird aber natürlich gerne mitgenommen)
DynDNS ist mittlerweile auch deshalb schwieriger geworden, weil nicht nur alle 24h die IP wechseln kann, sondern auch zwischendurch. Je nach Anbieter und Tageszeit kann das auch häufiger passieren. Beim Surfen nicht weiter lästig, für einen DynDNS-Server Benutzer hingegen ziemlich.

so short

Christoph Zurnieden

[nuss]

Moinsen,

was'n hier schon wieder los? ;-)

Der Schnauss geht mir auf die Eier ;-)

Gruss/Danke/Bitte
mfg nuss

[Sven Rautenberg]

Moin!

Ja, denn der User "netz" hat hier beides unter sich, das ist tunlichst zu vermeiden. Wenn der User dann sogar noch eine Shell hat ging's wirklich daneben.

Vollkommen richtig. Jeder Webservice sollte seinen eigenen Benutzeraccount erhalten, welcher hinsichtlich seiner Zugriffsrechte so weit wie möglich eingeschränkt ist auf das zum Betrieb notwendige, aber keinesfalls mehr.

Also: Apache kriegt seinen eigenen Benutzer (oft wwwrun oder apache genannt), und FTP kriegt ebenfalls einen eigenen Benutzer (ob man den jetzt ftp nennt, ist wohl eine Geschmacksfrage). Entsprechend sollte jeder dieser Accounts auch eine eigene Gruppe erhalten, in der er und alle anderen Benutzeraccounts, die in dem jeweiligen Bereich Zugriff erhalten sollen, untergebracht werden. Die richtige Account- und Gruppenplanung zusammen mit der entsprechenden Zuweisung der Dateizugehörigkeiten und -rechte ist essentiell für einen sicheren Betrieb.

Aber die normalen begrenzten User/Groups ohne Login (meist wwwrun/wwwrun o.ä.) sind tatsächlich zu empfehlen. Ist dann zumindest etwas aufgeräumter.

Es geht nicht ums Aufgeräumtsein, es geht um handfeste Sicherheitsüberlegungen: Wenn ein Angreifer einen Webservice erfolgreich angreift, hat er die Zugriffsrechte des Benutzeraccounts, unter dem der Webservice läuft. Würde es also nur einen einzigen Netz-Account geben, der für HTTP und FTP gleichzeitig genutzt wird, so könnte ein Angreifer z.B. via FTP eindringen und auch den HTTP-Server manipulieren - sind ja dieselben Accounts, also sind auch alle Dateien, die dieser Account lesen oder schreiben darf, zugriffsfähig.

Achso: ein user ist wirklich nicht per se nötig, das funktioniert alles auch ganz ohne!

Ein User ist immer zwingend nötig, ohne mindestens einen User läuft Linux nämlich nicht. Aber es versteht sich irgendwie von selbst, dass man Webservices nicht als root laufen läßt - außer man möchte eine adrenalinerhöhende Extremsportart betreiben, ohne zuviele Kalorien zu verbrennen.

Wenn ich z.B. jemandem einige Dokumente schickien will, dann hardlinke ich Sie einfach in /etc/public und der kann sich da bedienen.
ansonsten muesste ich das ganze noch auf nen server hochladen und nachher wieder loeschen.

Wo der Unterschied zwischen hardlinken und hochladen so rein von der Vorgehensweise ist, entzieht sich etwas meinem Verständnis. Beides erfordert manuelles Eingreifen, beides kann schiefgehen, bei beidem wird für die Zeit der Datenübertragung die Leitung ausgenutzt. Ist es nun wirklich einfacher, einen Hardlink auf der Festplatte herzustellen (wobei anzumerken ist: Hardlinks funktionieren nur, wenn Quelle und Ziel im selben Filesystem liegen, ansonsten sind Softlinks notwendig), oder per Shellskript mal eben einen Upload auf einen externen Server zu starten.

Letzeres ist jedenfalls wesentlich sicherer, insbesondere wird da die Leitung dann belegt, wenn ICH es will, und nicht, wenn jemand anderes den Downloadversuch startet.

Und vor allem werden aenderungen sofort uebernommen, ich muss nicht nac jeder aenderung den scheiss nochmal hochladen.

rsync wäre die Antwort.

Außerdem besteht ja durchaus die Gefahr, dass du derartig hart verlinkte Dokumente vergißt und später mit Inhalten füllst, die eigentlich doch nicht veröffentlicht werden sollten.

Dafür gibt es spezielle Services wie CVS u.ä., die das wunderbar unterstützen. Dann muß sich der Kollege ebenfalls nicht alles runterladen sondern kann sich mit dem Diff begnügen.

Ich würde dafür nicht unbedingt CVS nehmen. Dieses System hat mit großen Dateien so seine Probleme, insbesondere mit Binärdateien.

DynDNS ist mittlerweile auch deshalb schwieriger geworden, weil nicht nur alle 24h die IP wechseln kann, sondern auch zwischendurch. Je nach Anbieter und Tageszeit kann das auch häufiger passieren. Beim Surfen nicht weiter lästig, für einen DynDNS-Server Benutzer hingegen ziemlich.

Das Wechselintervall ist hinsichtlich der lästigen Erreichbarkeitsunterbrechung irrelevant. Im Zweifel ist der eigene Besuch exakt genau dann betroffen, wenn man gerade auf die interessanteste Webseite gehen wollte. DynDNS stört sich da nicht sonderlich dran, solange die IP sich ändert, wird diese Änderung online verfügbar gemacht und fertig.

Genau diese Unterbrechungen sind aber ein handfester Grund, gewisse Webservices eben gerade NICHT auf DynDNS-Servern anzubieten. Denn wenn die eigene IP gerade verlorengegangen ist und an einen anderen Benutzer vergeben wurde, laufen bei dem ja alle neu aufgebauten Verbindungen solange auf, bis das DNS die neue IP verteilt hat. Sowas ist durchaus ein Risiko. Was ist z.B., wenn man einen eigenen Mailserver betreibt - dann landen die eigenen Mails alle in fremden Händen (abgesehen davon: Man betreibt auf dynamischen IPs keine Mailserver, weder für eingehende, aber erst recht nicht für ausgehende Mails - zuviele Viren tun dasselbe, so dass die eigene Mail fast sicher in Spamfiltern hängen bleiben wird). Ebenso, wenn man sich mit Passwortabfrage auf dem DynDNS-Server anmeldet: Die Passworte gehen an den falschen Server, was ist, wenn der das munter mitschreibt und gegen einen verwendet?

- Sven Rautenberg

[Christoph Zurnieden]

Hi,

Aber die normalen begrenzten User/Groups ohne Login (meist wwwrun/wwwrun o.ä.) sind tatsächlich zu empfehlen. Ist dann zumindest etwas aufgeräumter.

Es geht nicht ums Aufgeräumtsein, es geht um handfeste Sicherheitsüberlegungen: Wenn ein Angreifer einen Webservice erfolgreich angreift, hat er die Zugriffsrechte des Benutzeraccounts, unter dem der Webservice läuft. Würde es also nur einen einzigen Netz-Account geben, der für HTTP und FTP gleichzeitig genutzt wird, so könnte ein Angreifer z.B. via FTP eindringen und auch den HTTP-Server manipulieren - sind ja dieselben Accounts, also sind auch alle Dateien, die dieser Account lesen oder schreiben darf, zugriffsfähig.

Ja, das mag stimmen, ich bin da vielleicht etwas zu paranoid: für mich ist bei einem erfolgreichem Angriff jedweder Art stets anzunehmen, das das gesamte System beschädigt ist und dementsprechend zu handeln. Dementsprechend bringt eine Trennung nicht sonderlich viel. Es sollte pro Box ja normalerweise auch nur ein einziger Dienst laufen, aber das ist ja aus einsehbaren Gründen nur selten möglich, mindestens ein SSHD o.ä. läuft ja immer mit.

Achso: ein user ist wirklich nicht per se nötig, das funktioniert alles auch ganz ohne!

Ein User ist immer zwingend nötig, ohne mindestens einen User läuft Linux nämlich nicht.

Da muß ich Dich enttäuschen, Linux läuft auch ohne User. Dann läuft aber maximal ein Programm. Wird im Embeded-Bereich öfter mal genutzt. Da aber dadurch kein Remotezugriff möglich ist (der würde ja ein paar Programme mehr benötigen), könnte man das Dingen natürlich nur ein- und ausschalten, mehr nicht. Reicht aber auch in vielen Fällen, wenn TRON nicht reicht und QNX o.ä. zu teuer ist.

Aber es versteht sich irgendwie von selbst, dass man Webservices nicht als root laufen läßt - außer man möchte eine adrenalinerhöhende Extremsportart betreiben, ohne zuviele Kalorien zu verbrennen.

_Rein theoretisch_ ginge das, aber darauf würde ich mich freiwillig bestimmt nicht einlassen, wie schnell wird da 'was vergessen ;-)
Hätte dann aber auch die gleichen Nachteile, wie ganz ohne User: da keine Shell da sein darf, auch kein Remotezugriff vorhanden ist.

Wo der Unterschied zwischen hardlinken und hochladen so rein von der Vorgehensweise ist, entzieht sich etwas meinem [...]

Softlinks notwendig), oder per Shellskript mal eben einen Upload auf einen externen Server zu starten.

Das war doch mein Reden, aber mir glaubt ja keiner! ;-)

Dafür gibt es spezielle Services wie CVS u.ä., die das wunderbar unterstützen. Dann muß sich der Kollege ebenfalls nicht alles runterladen sondern kann sich mit dem Diff begnügen.

Ich würde dafür nicht unbedingt CVS nehmen. Dieses System hat mit großen Dateien so seine Probleme, insbesondere mit Binärdateien.

Was denn, immer noch?
Naja, meine größten Dateien sind eh nur C-Header mit vielen ifdef's, da kommen vielleicht mal 50 kib zusammen, mehr nicht ;-)

DynDNS ist mittlerweile auch deshalb schwieriger geworden, weil nicht nur alle 24h die IP wechseln kann, sondern auch zwischendurch. Je nach Anbieter und Tageszeit kann das auch häufiger passieren. Beim Surfen nicht weiter lästig, für einen DynDNS-Server Benutzer hingegen ziemlich.

Das Wechselintervall ist hinsichtlich der lästigen Erreichbarkeitsunterbrechung irrelevant. Im Zweifel ist der eigene Besuch exakt genau dann betroffen, wenn man gerade auf die interessanteste Webseite gehen wollte.

Davon ist auszugehen, ja. Aber einmal ist ja bekannt, nur wenn das mehrmals in kurzer Zeit vorkommt, ist das lästiger, als nur einmal. Der normale Windowsuser verzeiht nunmal, aus welchen Gründen auch immer, kurzfristige Störungen, fühlt sich mittlerweile bei Wiederholungen aber dann doch genervt.

Ebenso, wenn man sich mit Passwortabfrage auf dem DynDNS-Server anmeldet: Die Passworte gehen an den falschen Server, was ist, wenn der das munter mitschreibt und gegen einen verwendet?

Dagegen gäbe es kryptographische Mittel und Wege, aber die sind kaum einem Fortgeschrittenem, geschweige denn einem Anfänger zuzumuten. Zumal sie auch noch zum Teil auf der unkontrollierbaren Clientseite passieren müssen.

so short

Christoph Zurnieden

[Sven Rautenberg]

Moin!

Ja, das mag stimmen, ich bin da vielleicht etwas zu paranoid: für mich ist bei einem erfolgreichem Angriff jedweder Art stets anzunehmen, das das gesamte System beschädigt ist und dementsprechend zu handeln. Dementsprechend bringt eine Trennung nicht sonderlich viel. Es sollte pro Box ja normalerweise auch nur ein einziger Dienst laufen, aber das ist ja aus einsehbaren Gründen nur selten möglich, mindestens ein SSHD o.ä. läuft ja immer mit.

Es gibt doch sehr viele Bugmeldungen der Art "erlaubt die Ausführung beliebigen Codes mit den Rechten des jeweiligen Users".

Es ist also vollkommen im Sinne einer mehrschichtigen Abschottungsstrategie, wenn man es einem Angreifer so schwer wie möglich macht. Genau deswegen laufen Webservices nicht als root-User, sondern unter einem separaten Account, und auch jeder unter einem eigenen Account. qmail beispielsweise ist so paranoid, dass da für jeden einzelnen Daemon, der läuft, ein eigener User eingerichtet wird. Aber sowas begrenzt halt erst einmal den möglichen Schaden: Fehler in einem Daemon oder sonstigen Programmen, beispielsweise ein unachtsames Remote-Code-Include in PHP, führen zunächst nur dazu, dass man als der User dieses Daemons böse Dinge anstellen kann. Um von dort aus root zu werden, sind nochmal ganz andere Anstrengungen notwendig. Ohne Abschottung der Daemons in unterschiedlichen Usern wäre ein wesentlich größerer Systemzugriff schon an diesem Punkt möglich.

Davon abgesehen hast du natürlich Recht: Ein irgendwie kompromittiertes System sollte unbedingt einer forensischen Analyse unterzogen werden, und dann komplett neu aufgesetzt. Ansonsten setzt man sich unnötigen Restrisiken aus. Das ist aber erst die Strategie für "danach" - warum sollte man nicht schon "davor" alle Möglichkeiten nutzen, um den Angriff so schwer wie möglich zu machen? Insbesondere, wenn sie so leicht umsetzbar sind, wie verschiedene Useraccounts.

Ich würde dafür nicht unbedingt CVS nehmen. Dieses System hat mit großen Dateien so seine Probleme, insbesondere mit Binärdateien.

Was denn, immer noch?

Ich rede von megabytegroßen Binärdateien.

Wobei die Probleme keine von CVS-Programmcode sind, sondern schlicht ein Ressourcenproblem. Ich hatte mal Bilddateien, die um die 60 MB groß waren. Diese zum CVS hinzuzufügen ("add") hat noch funktioniert, sie danach hochzuspielen auf den Server wurde schwierig und scheiterte letztendlich daran, dass für das DIFF zuwenig RAM zur Verfügung stand, bzw. sich der Server (ok, so eine Höllenmaschine war es nicht, aber wenn der Server 194 MB RAM hat, und ansonsten nichts zu tun außer für CVS dazusein, aber an 60 MB Binärdaten scheitert, dann stimmt da was nicht... :)

Naja, meine größten Dateien sind eh nur C-Header mit vielen ifdef's, da kommen vielleicht mal 50 kib zusammen, mehr nicht ;-)

Alles im Bereich bis 9,99 Megabyte würde ich als unkritisch einschätzen, und auch all das, was Textdatei ist - denn das läßt sich ja gut als DIFF komprimieren. Binärdateien aber sind in CVS nicht wirklich gut aufgehoben, zumindest keine großen.

Ebenso, wenn man sich mit Passwortabfrage auf dem DynDNS-Server anmeldet: Die Passworte gehen an den falschen Server, was ist, wenn der das munter mitschreibt und gegen einen verwendet?

Dagegen gäbe es kryptographische Mittel und Wege, aber die sind kaum einem Fortgeschrittenem, geschweige denn einem Anfänger zuzumuten. Zumal sie auch noch zum Teil auf der unkontrollierbaren Clientseite passieren müssen.

SSL mit Zertifikat wären ja für die Benutzeranmeldung schon eine vernünftige Absicherung. Das löst aber keinesfalls das Mailproblem.

- Sven Rautenberg

[Christoph Zurnieden]

Hi,

Falls noch andere hier mitlesen: das Folgende ist eine rein theoretische Diskussion, bitte stattdessen bei der Serversicherung die bekannten Maßnahmen zu ergreifen und nichts von mir zu übernehmen! Ich mache das schließlich auch so!
(Das ich nichts von mir übernehme? Naja, gut ... ;-)

Es gibt doch sehr viele Bugmeldungen der Art "erlaubt die Ausführung beliebigen Codes mit den Rechten des jeweiligen Users".

Es gibt auch viele Bugmeldungen mit privilege escalating Exploits (im Weiterem P.E.) - lokal oder auch remote, aber das ist von keinem wesentlichem Unterschied, zumindest in der Behandlungsweise. Da es nicht anzunehmen ist, das von fehlender Bugmeldung auf fehlenden Bug zu schließen ist, ist die genaue Art der Sicherheitslücke nicht wirklich relevant. Es gibt kein "nicht so schlimm", genausowenig wie "ein bischen schwanger".

Das führt dazu, das die übliche - und auch durchaus beizubehaltende - Gepflogenheit, jedem Service eine eigene User/Group Kombination zu verpassen nicht _in_ das Zwiebelmodell "Sicherheit" hineingehört sondern "nur noch" als Tüpfelchen auf dem 'i'. Ungefähr in den selben Rahmen, wie die Empfehlung, das Services ihre Versionsnummer nicht verraten sollten; der Apache also z.B. nur verraten sollte, welche Protokolle er unterstützt, aber nicht womit und auch nicht, wie er heißt.

Es ist also vollkommen im Sinne einer mehrschichtigen Abschottungsstrategie, wenn man es einem Angreifer so schwer wie möglich macht.

Ja, durchaus, aber man fängt von innen an. Es kostet schließlich alles Geld und da wird zuerst eingerichtet, was am meisten Effekt ergibt, nicht unbedingt, was am billigsten ist. Ja, ein wenig Hoffnung schwebt da mit ;-)

Die Einrichtung der Services mit verschiedenen Usern/Gruppen ist aber meist eh schon vorgegeben. Bei der Installation der Programme oder gar von der gewählten Distribution. Das zu ändern würde nur in extremen Ausnahmefällen Vorteile bringen, in den allermeisten anderen Fällen jedoch nur Nachteile. Also läßt man es.

Genau deswegen laufen Webservices nicht als root-User, sondern unter einem separaten Account, und auch jeder unter einem eigenen Account.

Dazu ist aber auch, das gebe ich zu bedenken, eine Multiuserumgebung erforderlich, die dann auch wieder andere Probleme aufwirft. Wenn also ein einziger Service als dedizierter Server im Singleusermode läuft, würde ich mir es dreimal überlegen, das zu ändern. Vorausgesetzt natürlich, das sich dabei jemand etwas gedacht hat und es nicht schlichte Unfähigkeit war.
Für eine Readonly Datenhaltung und entsprechender Hardwaresicherung (NX-Speicher etc) könnte das z.B. gehen. Ein Vorteil davon ist, das es klein genug wäre als kompletter Zustand, als RAM-Abbild aus einem ROM geladen zu werden. Alles im restlichem Speicher sei dann prinzipiell nicht ausführbar und reine Datenhaltung.
Dadurch wäre die Universalität der heutzutage gängigen von-Neumann-Maschinen allerdings stark in Frage gestellt. Ähnlich, wie es heute beim BIOS geht, würde aus einem Baukasten alles zusammengesteckt und wäre nur noch komplett austauschbar.
Und ob das wirklich soviel sicherer wäre?

Aber sowas begrenzt halt erst einmal den möglichen Schaden: Fehler in einem Daemon oder sonstigen Programmen, beispielsweise ein unachtsames Remote-Code-Include in PHP, führen zunächst nur dazu, dass man als der User dieses Daemons böse Dinge anstellen kann. Um von dort aus root zu werden, sind nochmal ganz andere Anstrengungen notwendig.

Gilt zwar nicht oder nur begrenzt für die hier angesprochenen Services aber trotzdem mal am Rande: Für einen normalen User mit Account ist es genauso schlimm, wenn in seinen eigenen Account eingebrochen wurde, als wenn root gefallen wäre. Es geht dem normalem User einzig und allein um seine Daten, nicht um das System, das in ein paar Minuten wieder vom Backup eingspielt werden kann, oder in ein paar Minuten mehr komplett neu aufgesetzt.
Wenn der Angreifer z.B. einen Browserexploit ausnutzt und schlicht 'for i in ~/*; do echo "" > $i;done' ausführt, dann sind des Users Daten weg. Dem nützt es dann rein gar nichts mehr, das das System dabei unbehelligt bleibt, es geht höchstens etwas schneller das Backup einzuspielen. Die Daten von einem Tag (wenn überhaupt täglich ein Backup gemacht wurde) sind schlicht weg.

Davon abgesehen hast du natürlich Recht: Ein irgendwie kompromittiertes System sollte unbedingt einer forensischen Analyse unterzogen werden, und dann komplett neu aufgesetzt. Ansonsten setzt man sich unnötigen Restrisiken aus. Das ist aber erst die Strategie für "danach" - warum sollte man nicht schon "davor" alle Möglichkeiten nutzen, um den Angriff so schwer wie möglich zu machen?

Ja, natürlich, aber schön in der vorgesehenen und lang erprobten Reihenfolge:
Erst in eine ordentliche Firewall investieren ( was ich unter "ordentlich" verstehe würde hier zu weit führen, aber ich nehme an, das da zwischen uns eh weitgehend Konsens herrschen würde). Ist das nicht möglich: laß es ganz, ich würde noch nicht einmal ein OpenBSD oder besser "nackicht" an's Netz hängen wollen.
Dann sollten alles Service auf möglichst viele Boxen verteilt erden, anzustreben ist ein Service pro Box. Ist aber meist aufgrund finanzieller Erwägungen nicht möglich. Auch praktische Erwägungen stehen dagegen, denn ohne zumindest ein SSHD o.ä. wäre ja nur Ein-ausschalten möglich.
Dann ist ausführlich auf Fehler zu prüfen: angefangen beim schlichtem Funktionstest, über einen oder besser mehrere Penetrations- und (D)DoS-Tests, bis hin zur Überprüfung des Codes falls Mittel und Fachpersonal zur Verfügung stehen. Es ist auch alle Hardware zu prüfen falls möglich (z.B. memtest86 u.ä.). Es sind nicht nur mehr oder weniger korrekte Usereingaben zu prüfen, sondern nach Möglichkeit auch aus /dev/random die Programme zu füttern.
(Insgesammt eine sehr unvollständige Liste, aber ich glaube eine gute Übersicht gegeben zu haben)

Dann und wirklich erst dann, sind solche Sachen wie Schadensbegrenzung zu bedenken: Versionsunterdrückung, Ausnutzung der Multiuserumgebung und was es alles so gibt.

Insbesondere, wenn sie so leicht umsetzbar sind, wie verschiedene Useraccounts.

Nun, bei extremen Zeitmangel, wenn Konventionalstrafe droht und der Kunde schon ständig seine Rolex bewundert, dann würde ich es nicht extra noch einrichten wollen ;-)

Aber wie gesagt: ist ja schon meist in der Installation von Programm oder Distribution mit drin, kost' im Grunde genommen gar nix, nimmt man also gerne mit.

[CVS]

Ich rede von megabytegroßen Binärdateien.

Wobei die Probleme keine von CVS-Programmcode sind,

[...]

an 60 MB Binärdaten scheitert, dann stimmt da was nicht... :)

Ja und zwar bei CVS (dem Programm). Wie man riesige Dateien schnell und sparsam sortiert steht schon ja schon im Sedgewick gut beschrieben und der hat's auch nicht selber erfunden. Von da zu einem Diff ist es nicht sehr weit. Finde es also sehr befremdlich, das das immer noch Probleme bereitet.

Alles im Bereich bis 9,99 Megabyte würde ich als unkritisch einschätzen, und auch all das, was Textdatei ist - denn das läßt sich ja gut als DIFF komprimieren. Binärdateien aber sind in CVS nicht wirklich gut aufgehoben, zumindest keine großen.

Wenn ich CVS allgemein nehme (Nicht als Programm, sondern als Abkürzung für "Concurrent Versioning System") macht das aber bei der Zunahme von digitalen Filmbearbeitungen schon Sinn. Könnte mir gut vorstellen, das dort ein CVS ganz praktisch wäre.

Dagegen gäbe es kryptographische Mittel und Wege, aber die sind kaum einem Fortgeschrittenem, geschweige denn einem Anfänger zuzumuten. Zumal sie auch noch zum Teil auf der unkontrollierbaren Clientseite passieren müssen.

SSL mit Zertifikat wären ja für die Benutzeranmeldung schon eine vernünftige Absicherung. Das löst aber keinesfalls das Mailproblem.

Eben, das läßt sich auf so einfache Weise nicht beherrschen.
Und wenn ich hier "SSL mit Zertifikat" als einfach bezeichne, dann kann man sich ja vorstellen, was da für Probleme auf einen zukämen ;-)

so short

Christoph Zurnieden

[Christoph Schnauß]

hallo Christoph ;-)

Mein Vornamensvetter mag etwas kurz angebunden gewesen sein

Ja, sorry, ich hätte ja vielleicht doch noch _ein kleines bißchen_ mehr Wörter verschwenden sollen.

ich habe hier zu Hause einen Rechner mit Mandrake, das ganze hängt an einem Router, an dem noch 2 Rechner hängen.
Schön.
Sehr sinnvolle Antwort, du musst auch nicht alles kommentieren.
Doch dsa sollte er, denn diese Zusammenstellung ist genau das: schön.

Sie ist immerhin sinnvoller als ein Einzelplatzrecher, der ohne davorgeschalteten Router (den man ja, wenn man es kann, ziemlich perfekt konfigurieren kann) ins Netz geht. Insofern ist die "Hardwareausstattung" beim OP schon etwas angenehmer als bei manchen anderen, die mit derselben Thematik hier hereingeplauzt kommen.

Also einen Usernamen und eine Domain von DynDNS
Überflüssig
Wenn er eine DynDNS will - wo ist das Problem?
Wenn du schon so eine plume Scheissantwort gibst dann begruende Sie wenigstens.
Wenn er keine Zeit hat

Zeit habe ich schon (und bin im übrigen durchaus bereit, ausführlicher zu werden und Begründungen nachzureichen), aber du warst einfach etwas schneller ;-)

FTP ist heutzutage unsinnig, da gibt es bessere Mittel und Wege. Meist reicht da schon der Apache. Ja, auch für Upload.

_Das_ ist eine durchaus strittige These, über die sich weiterzudiskutieren lohnt. Ich glaube, ich weiß, was du meinst  -  aber: FTP hat nun einmal eine sehr lange Tradition (ich benutze es selber, wenn auch nun wirklich nicht im lokalen Netz).

und nen Webserver
Der ist allerdings kein Problem.
Genausowenig wie ein FTPD.
Ein FTPD _ist_ problematisch, da kriegst Du graue Haare!

ACK! Ich bastle für einen der (sehr wenigen) "Kunden", die ich habe, an so einem FTP-Dämon bereits seit zwei Jahren herum und bin immer noch nicht wirklich fertig.

Das soll dan etwa so aussehen, dass ich einen extra User anlege, z.B. "netz" und da dann die unterordner "ftp" und "http" anlege.
Der Webserver hat mit FTP nichts zu tun.
Hat er das behauptet?
Ja, denn der User "netz" hat hier beides unter sich, das ist tunlichst zu vermeiden. Wenn der User dann sogar noch eine Shell hat ging's wirklich daneben.

Exakt, genau das ist das Problem dabei  -  und das wird eben von "Anfängern" in aller Regel völlig übersehen. Und übrigens von "Fortgeschrittenen" bisweilen auch, ich kann mich selber da keineswegs ausschließen, obwohl es höchstens zwei Stunden dauert, bis ich das dann bemerke.

Aber die normalen begrenzten User/Groups ohne Login (meist wwwrun/wwwrun o.ä.) sind tatsächlich zu empfehlen. Ist dann zumindest etwas aufgeräumter.
Achso: ein user ist wirklich nicht per se nötig, das funktioniert alles auch ganz ohne!

Nee. Ohne "user" rennt auch der Apache nicht los. Wenn du aber meinst, daß man keinen _neuen_ user extra anlegen muß, hast du recht. Es reicht der, den das System als "default" anlegt.

Ein CVS zu betreiben wäre z.B. ein guter Grund für einen Homeserver, aber den gibt's bei Sourceforge billiger

ACK.

DynDNS ist _nicht_ ueberfluessig weil _normale_ MEnschen merken sich lieber sowas wie guenther.homelinux.net als 157.245.914.125
Es gibt mitunter gute Gründe für den Einsatz von DynDNS

Es mag überraschen, wenn ich dir (aber ausdrücklich _nicht_  unserer nuss) hier zustimme. Ja, ich halte DYNDNS keineswegs "global" für unsinnig. Ich halte aber genau die Argumente, die die liebe "nuss" bisher vorgebracht hat und die auch beim OP vorzuliegen scheinen, für unsinnig. Wenn man versteht, was da wirklich passiert, kann es sich für bestimmte Aufgaben lohnen. Ich lasse zur Zeit zwei Foren über DYNDNS (und damit auch über meinen eigenen Rechner zuhause) laufen. Es ist also nicht so, daß ich DYNDNS "in Bausch und Bogen" ablehne. Ich möchte nur, daß man sich wirklich sehr ernsthaft überlegt, wann und wofür man sich dort registrieren läßt.

Christoph Zurnieden

Grüße aus Berlin

Christoph S.

[Christoph Zurnieden]

Hi,

FTP ist heutzutage unsinnig, da gibt es bessere Mittel und Wege. Meist reicht da schon der Apache. Ja, auch für Upload.

_Das_ ist eine durchaus strittige These, über die sich weiterzudiskutieren lohnt.

Es gibt nur wenige Dinge, für die sich ein FTP Zugang wirklich lohnen würde, aber dafür dieses Damoklesschwert? Nein, danke. Mit ein paar Zeilen Perl/PHP/Scheme/Lisp/WWI läßt sich da ganz wunderbar ein FTP Zugriff simulieren, falls es für die gemeine Clientel sein soll, die FTP eh nur über graphische Tools benutzen kann. WebDAV wäre auch noch eine Möglichkeit, wird aber auf Windows nicht wirklich allgemein unterstützt.

FTP hat nun einmal eine sehr lange Tradition (ich benutze es selber, wenn auch nun wirklich nicht im lokalen Netz).

Ich gehöre noch zu einer Generation, die auf Traditionen geschissen hat und das nicht immer nur sprichwörtlich. Ich befürchte Du hast mit dieser Argumentation nicht viel Erfolg bei mir ;-)

so short

Christoph Zurnieden

[Der Martin]

Hallo Günther,

zur grundsätzlichen Problematik hat Christoph dir ja schon eine Menge erzählt. Ich sehe das Thema zwar nicht ganz so negativ und ablehnend wie er, aber im Prinzip muss ich ihm Recht geben.

So eine Pseudo-Domain bei DynDNS habe ich allerdings auch, und bei mir zuhause läuft -hinter einem DSL-Router- ein Apache rund um die Uhr. Ich sehe das aber nicht so sehr als öffentlichen Server, sondern eher für meine eigenen Zwecke. Deswegen mache ich die Adresse auch nicht bekannt. Jedenfalls nicht absichtlich. ;)

Die Sache mit der gelegentlich wechselnden IP-Adresse ist eigentlich ganz einfach. Von DynDNS kannst du Software-Tools bekommen, die auf deinem zukünftigen Server laufen kontinuierlich die momentane IP-Adresse auslesen. Sobald sie sich geändert hat, melden diese Tools die aktuelle IP an DynDNS weiter. Dann dauert's ein paar Minuten, und dein Server ist wieder erreichbar.
Da vor allem DynDNS mittlerweile sehr beliebt und verbreitet ist, haben sogar schon viele DSL-Router einen Update-Client für DynDNS eingebaut. Das ist natürlich die beste Lösung, denn der Router weiß ja als erster, wie seine öffentliche (providerseitige) lautet.

Lies dir am besten mal die FAQ und die diversen Docs bei DynDNS durch, da kann man schon viel draus lernen. :)

Mit der Einrichtung des Servers fängst du wohl am besten so an, dass du ihn zuerst mal in deinem internen LAN zum Laufen bringst. Dann ist es nachher ein Klacks, auch Anfragen von draußen zu bearbeiten. Aber vergiss dabei nie, dass es "da draußen" viele Hobby-Hacker gibt, die nichts lieber tun als fremde Server zu hacken. Und sei es aus sportlichem Ehrgeiz...

So long,

Martin