• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

Webseite auf php und msql auf eigenen 2000 Server bereitstellen-Anfängerfrage

anfänger69

New Member
Hallo bin absolut neu hier und habe folgende Frage > Möchte meine derzeitige Webseite auf meinen Windows 2000 Server Servicepack 3, komplett upgedated für das WWW bereitstellen, nun ich hab Sicherheitslücken geschlossen und auch sehr viel darüber gelesen komm nur damit nicht kar wie ich meine Webseite von meinen Server aus für meine User ins Netz bringe, ich habe keinen Apache oder dergleichen auf meinen Server, brauch ich einen und was noch?

Ich schreibe zwar php und html und msql aber in der Servertechnik bin ich noch ein absoluter Anfänger!

Würde mich freuen wenn mir jemand weiterhelfen könnte!



PS: Meine Serverlizenen sind alle Legal gekauft worden!!
 
anfänger69 said:
Ich schreibe zwar php und html und msql aber in der Servertechnik bin ich noch ein absoluter Anfänger!
Das sind natürlich keine guten Anforderrungen für einen eigenen Server.

Wenn es wirklich nur eine Website ist mit php und MySQL, tut es nicht dann auch ein einfacher Webspace?

Naja, um auf deine Frage zurück zu kommen, Ja du brauchst einen Webserver mit php und MySQL unterstützung.

Als Webserver kann ich dir den Apache2 empfhelen Leistungsstarke rund einfach zu bedinender Webserver.

Aber bei windows müsste doch auch der IIS dabei sien oder? den könntest du auch nehmen.

Gruß
Ich
 
Danke-Stimmt ist auch drauf IIS

Das sind natürlich keine guten Anforderrungen für einen eigenen Server.

Wenn es wirklich nur eine Website ist mit php und MySQL, tut es nicht dann auch ein einfacher Webspace?

Naja, um auf deine Frage zurück zu kommen, Ja du brauchst einen Webserver mit php und MySQL unterstützung.

Als Webserver kann ich dir den Apache2 empfhelen Leistungsstarke rund einfach zu bedinender Webserver.

Aber bei windows müsste doch auch der IIS dabei sien oder? den könntest du auch nehmen.

Gruß
Ich

Ja stimmt ist auch drauf uns soweit eingerichtet nur weiss ich leider nicht wo ich meine Webseite ablegen muss damit man diese über einen Client aufrufen kann, nun ich hab mich mit meiner Ausdrucksweise etwas vertan, denn meine Webseite besteht aus einen CMS mit Blog und vielen mehr (Spiele u.s.w) also ist etwas größer wie eine normale HTML Webseite, ich hatte sie bis vor kurzen auf einen Freehoster gehabt , aber die ständigen Serverausfälle und nicht Erreichbarkeit hatten mich total geärgert und meine User auch!

Danke dir für deine schnelle Antwort!
 
Also, mit dem IIS kenne Ich mich Persönlich jetzt nicht so gut aus hatte ihn nur eine kurze Zeit mal benutzt.

Aber Ich meine in erinnerung zu haben, dass die dateien in C:\inetpub\wwwroot rein müssen.

Andere Frage, betreibst du den Server zuhause?
 
Danke für deine Antwort

ja ich betreibe meinen Server von Zuhause aus, deswegen habe ich ihn auch nochmals gesondert abgesichert, Sicherheit ist mir sehr wichtig hab mich auch 3 Monate vorher eingelesen wegen Sicherheitsrichtlinien und das Rechtliche eben!Gruß Robert
 
mhm, Ich kann dir nur empfhelen schalte deinen Server zuhause ab und hol dir vernünftigen Webspace.

Damit bist du viel günstiger dran, brauchst keien Server kenntnisse etc.

Edit: Soweit ich was ist es auch vom Internet Provider nicht erlaubt Server von zuhause zu betreiben.
 
Last edited by a moderator:
...Möchte meine derzeitige Webseite auf meinen Windows 2000 Server Servicepack 3, komplett upgedated für das WWW bereitstellen...


Der Support für Windows 2000 Server ist doch schon vor 1,5 Jahren eingestellt worden, oder bin ich gerade auf dem falschen Dampfer?

Solltest du also tatsächlich den Betrieb eines eigenen Servers in Erwägung ziehen, ist der Einsatz aktueller Software, für die es regelmäßige Updates gibt die wesentliche Grundvoraussetzung, die erfüllt sein muss.
 
danke für deine antwort

Der IPS kann da überhaupt nichts machen und hat auch keinerlei Einfluss, denn diese Entscheidung liegt immer beim Kunden, dazu wenn man eine Ultrahochgeschwindigkeitsleitung hat und weitere andere Genehmigungen besitzt ist das kein Thema und zu deiner Aussage "gescheiter webspace" da wirst du im Internet eher nichts finden, glaub mir bin schon zulange dabei um diese Aussage treffen zu können, dazu kommt warum gibt es Homeserver und dergleichen, den IPS ist des soweit egal hauptsache deren Kohle stimmt! Gruß Robert
 
Der IPS kann da überhaupt nichts machen und hat auch keinerlei Einfluss, denn diese Entscheidung liegt immer beim Kunden, dazu wenn man eine Ultrahochgeschwindigkeitsleitung hat und weitere andere Genehmigungen besitzt...

ISP (Internet Service Provider) meinst du wahrscheinlich. IPS (Intrusion Prevention System) ist etwas anderes ;)

Prinzipiell kann der Provider schon was machen, wenn er z.B. genau diese Nutzung in seinen AGBs ausschließt. Wie wahrscheinlich es ist, dass er dich erwischt und Maßnahmen ergreift steht natürlich auf einem anderen Blatt, aber darum soll es hier ja auch nicht gehen.

Prinzipiell kann man aber sagen, dass ein handelsüblicher asymmetrischer DSL-Anschluss durch seinen geringen Upstream für das Bereitstellen von Serverdiensten eher ungeeignet ist. Je nach Verwendungszweck und Anzahl der Nutzer kann es aber ausreichend sein.

Aber darum geht es ja nicht, sondern es geht ja um die Servertechnik an sich. Vor allem würde ich empfehlen, direkt auf die aktuellste Version vom Windows Server zu wechseln, da er sich in der Bedienung stark von den Vorgängerversionen unterscheidet und du so am wenigstens Zeit damit vergeudest, überholte Dinge zu lernen ;)
 
Danke Mr.Check

ISP (Internet Service Provider) meinst du wahrscheinlich. IPS (Intrusion Prevention System) ist etwas anderes ;)

Prinzipiell kann der Provider schon was machen, wenn er z.B. genau diese Nutzung in seinen AGBs ausschließt. Wie wahrscheinlich es ist, dass er dich erwischt und Maßnahmen ergreift steht natürlich auf einem anderen Blatt, aber darum soll es hier ja auch nicht gehen.

Prinzipiell kann man aber sagen, dass ein handelsüblicher asymmetrischer DSL-Anschluss durch seinen geringen Upstream für das Bereitstellen von Serverdiensten eher ungeeignet ist. Je nach Verwendungszweck und Anzahl der Nutzer kann es aber ausreichend sein.

Aber darum geht es ja nicht, sondern es geht ja um die Servertechnik an sich. Vor allem würde ich empfehlen, direkt auf die aktuellste Version vom Windows Server zu wechseln, da er sich in der Bedienung stark von den Vorgängerversionen unterscheidet und du so am wenigstens Zeit damit vergeudest, überholte Dinge zu lernen ;)
Klar meinte ich ISP und nicht IPS, ein Tipfehler von mir -sorry!Nun sicherlich hast du damit Recht mit der aktuellesten Win Version aber selbst die älteren Versionen kann man noch sehr gut absichern!Dazu gibt es ja noch Linux!

Mir ging es ja nur darum meine Webseite ins WWW zubringen und meinen Usern zugänglich zumachen, ich habe vor ca. 10 diesen tollen Artkel gelesen:

HOSTING EINES WEBSERVERS ZU HAUSE

Dank DSL mit großen Bandbreiten und Flatrate hat man heute nicht nur die Möglichkeit, ziemlich schnell und viel im Internet zu surfen. Es ist auch mit wenig Aufwand möglich, einen eigenen, kleinen Webserver zu Hause zu betreiben. In diesem Artikel beschreibe ich einmal den Aufbau eines solchen Webservers und zeige einige Vor- und Nachteile dieser Lösung auf.
Inhaltsverzeichnis
Provider-Hosting vs. Home-Hosting
Domain-Namen und wechselnde IP-Adressen
Hardwarefragen
Einrichtung des Servers
Auswahl des Betriebssystems
Grund-Konfiguration
Vernetzung
Firewall-Konfiguration
Apache-Konfiguration
Mail-Server-Konfiguration (Postfix)
Erfahrungen im Betrieb
Provider-Hosting vs. Home-Hosting
Zunächst einmal möchte ich die beiden Hosting-Varianten, also Server beim Provider vs. Server zu Haus, miteinander vergleichen:
Hosting beim Provider (z.B. Virtual Server)
Vorteile
hohe Verfügbarkeit, nicht von Funktion des heimischen DSL abhängig
hohe Bandbreite ins Internet (meist Gbit-Anbindung direkt beim Provider)
automatisches Backup des kompletten Servers oft inklusive
Nachteile
relativ hohe, monatliche Kosten (Stand November 2008 etwa 10 € für den Server, dazu kommen die Kosten für die Domänenregistrierung)
Webspace oft begrenzt (wenn auch heute meist großzügig bemessen)
Traffic-Volumen meist begrenzt, Überschreitung des Inklusivvolumens muss oft teuer bezahlt werden
Hosting zu Hause
Vorteile
sehr geringe Kosten (DSL-Anschluss ist ohnehin vorhanden, nur Kosten für Domain-Registrierung notwendig)
keinerlei Beschränkungen beim verfügbaren Webspace
meist keine Beschränkungen beim Traffic-Volumen
Nachteile
Verfügbarkeit direkt vom Funktionieren des DSL abhängig
geringe Bandbreite (meist etwa 700KBit/s)
Stromkosten
Backup muss selbst organisiert werden
Die größte Einschränkung, die gegen das Hosting zu Hause spricht, ist die beschränkte Bandbreite der meisten DSL-Anschlüsse. Hier handelt es sich meist um ADSL, bei dem lediglich die Übertragungsrichtung vom Internet zum Endanschluss mit 2 – 6 Mbit/s betrieben wird. Die Gegenrichtung, also vom Endanschluss ins Internet hat meist eine Bandbreite von weniger als 1 Mbit/s. Gerade diese Richtung ist es aber, die für einen Webserver, der zu Hause betrieben wird, interessant ist - er soll ja seine Inhalte ins Internet übertragen. Will man allerdings keinen Streaming-Content anbieten, und rechnet man auch nicht mit mehreren tausend Besuchern pro Tag, reichen die oft angebotenen 700KBit/s für eine einfache Webpräsenz völlig aus. Und das Schöne ist – das eigene Surfen wird durch den Betrieb des eigenen Servers kaum behindert. Man selbst benutzt schließlich die Gegenrichtung, die vom Webserver kaum belastet wird.
Aber auch Stromverbrauch und Verfügbarkeit des Servers sollten in die Kalkulation einbezogen werden. Wir verwenden einen sehr kleinen, verbrauchsoptimierten Server, der etwa 40 Watt an Leistung aus der Steckdose zieht, dafür aber auch keinen Spitzenleistung abliefert. Für einen normalen Webserver ist das in Ordnung, insbesondere, wenn man nicht viele Besucher erwartet. Ein handelsüblicher PC verbraucht allerdings schon mindestens 80-120 Watt, ein echter Server mit redundanten Festplatten noch einmal deutlich mehr. Dazu kommt, dass man, will man sicherstellen, dass zumindest im eigenen Einflussbereich so viel wie möglich gegen die Nicht-Verfügbarkeit des Servers getan wurde, eine unterbrechungsfreie Stromversorgung für den Server und den DSL-Router vorsehen sollte. Damit kann dann zumindest ein kurzer Stromausfall in der heimischen Wohnung wegen irgendeines Kurzschlusses im Toaster oder Fön überbrückt werden.
Fazit
Ich habe mich für die Variante des Servers zu Hause entschieden. Mein DSL-Anschluss hat eine ausreichende Bandbreite und wird den größten Teil des Tages ohnehin nicht benutzt - bezahlt aber wohl. Warum also diese Ressource einfach nur im Leerlauf surren lassen. Außerdem war es eine nette kleine Herausforderung, einen Server zu bauen, der einerseits auf der Stromrechnung nicht signifikant zu bemerken ist, aber gleichzeitig genug Leistung bereitstellt, um eine modernes ContentManagementSystem inklusive Datenbank zu betreiben.
Domain-Namen und wechselnde IP-Adressen
Will man seinen eigenen Webserver zu Hause betreiben, bietet es sich an, einen der zahlreichen Dynamic DNS-Provider zu verwenden. Eine normale DNS-Registrierung reicht nicht aus, da praktisch alle DSL-Anbieter alle 24 Stunden eine kurze Verbindungsunterbrechung erzwingen und dabei dem Anschluss eine neue IP-Adresse zuweisen. Eine normale Domain erlaubt es jedoch nicht, so häufig die mit dem Domänen-Namen verknüpfte IP-Adresse zu verändern, die die entsprechende Verknüpfung eine vordefinierte Lebensdauer von oft 24 Stunden hat. Die bei der Leitungsunterbrechung zugewiesene IP-Adresse würde also im ungünstigen Fall erst am darauffolgenden Tag gültig werden - und dann hat der DSL-Anschluss bereits die nächste Adresse zugewiesen bekommen.
Zum Glück gibt es die eben jene Dynamic-DNS-Provider. Die funktionieren im Wesentlichen so: Man meldet sich beim DynDNS-Provider an, erhält ein eignes Konto mit Benutzerkennung, Passwort und einem festen Domänen-Namen. Bei jeder Änderung der eigenen IP-Adresse teilt man die neue IP-Adresse dem DynDNS-Provider mit, der daraufhin den DNS-Datensatz, welcher den Domänen-Namen mit der IP-Adresse verknüpft, aktualisiert. Diese DNS-Datensätze haben jedoch eine Lebensdauer von nur 60 Sekunden. Das bedeutet, dass jede Anfrage an den Domänennamen weltweit einen maximal 60 Sekunden alten Domänendatensatz als Antwort erhält. Damit ist die Domäne nach Aktualisierung der IP-Adresse maximal 60 Sekunden nicht erreichbar. Für semiprofessionelle Zwecke eine sicher hinreichende Verfügbarkeit.
Einen kleinen Haken hat die Sache aber doch: Die meisten dynDNS-Provider bieten ihre Dienste zwar kostenlos an, dafür muß man aber mit einem mehr oder minder vorgegebenen Domänen-Namen vorlieb nehmen. Zumindest die Second-Level-Domäne verweist immer auf den dynDNS-Provider, was für den Besucher der Website immer ein direkter Hinweis darauf ist, dass er sich auf einer "privat" gehosteten Seite bewegt. Unschön. Die Lösung ist, dass man sich einen Provider sucht, der für einen gewissen Obulus die eigene Domäne direkt auf die dynamische IP-Adresse umleitet. In Deutschland, Österreich und der Schweiz macht das zum Beispiel selfhost, bei denen das Hosting der entsprechenden Domäne 1,50€ pro Monat kostet (Stand November 2008). Billiger ist das Hosting der Domäne bei einem klassischen Internetprovider auch nicht, also bietet sich hier der Umzug wirklich an. Der gestaltet sich unproblematisch: Die Domäne kann ganz unbürokratisch beim alten Provider als "freigegeben" markiert werden, der neue Provider erhält einen Transfer-Code, und im günstigsten Fall ist innerhalb von 24 Stunden der Umzug Geschichte.
Die Aktualisierung der IP-Adresse beim dynDNS-Provider sollte natürlich automatisch erfolgen. Dazu bieten viele dynDNS-Provider entsprechende Tools für Windows oder Linux an. Noch einfacher ist es, wenn der verwendete DSL-Router bereits eine entsprechende Option beinhaltet, wie es beispielsweise bei der Fritz!Box von AVM der Fall ist. Die kann dann auch gleich noch die Funktion der primären Firewall übernehmen - dazu aber später noch mehr.
Hardwarefragen
Ist die dynDNS-Domäne einmal konnektiert, erwarten potentielle Besucher am anderen Ende der Leitung natürlich auch einen funktionierenden Server. Bei der Auswahl der betreffenden Hardware muss man zwangsläufig Kompromisse eingehen.
Leider ist es so, daß sich die Anforderung nach hoher Leistung und Verfügbarkeit des Servers direkt mit dem Wunsch nach einem möglichst niedrigen Stromverbrauch beißt. Natürlich wäre es schön, einen Server zu Hause zu haben, der über redundante (also z.B. gespiegelte) Festplatten verfügt, um bei einem Plattencrash reibungslos weiter zu funktionieren. Wenn man es richtig ernst meint, könnte man sogar den kompletten Server redundant aufbauen - also einen Hochverfügbarkeitscluster aus zwei identischen Servern aufbauen. Aber je mehr Aufwand ich an dieser Stelle investiere, desto mehr Komponenten erhalte ich, die meine Stromrechnung belasten. Um die Größenordnung einschätzen zu können: Eine handelsübliche 3.5-Zoll-Festplatte hat eine Leistungsaufnahme im Betrieb von etwa 5-7 Watt. Ein RAID5-Verbund aus drei Festplatten hätte also (ohne den dazu ggf. notwendigen Controller) eine Leistungsaufnahme von 15-21 Watt. Auch bei der Wahl des Prozessors lohnt ein genauer Blick auf die Leistungsaufnahme. Für den stromsparenden Dauerbetrieb eignen sich momentan eigentlich nur Intels Atom-Prozessor, der Geode-Prozessor von AMD und der C3 von VIA in Frage. Alle anderen Prozessoren ziehen im Verbund mit ihrem jeweiligen Chipsatz allein mehr als 40 Watt Leistung. Zum Vergleich: Ein aktuelles Netbook kommt als Gesamtsystem (Festplatte, Prozessor, Mainboard, Speicher und Display) mit einem Stromverbrauch von unter 30 Watt daher. Das sollte der Wert sein, an dem man sich bei der Planung des eigenen Servers orientieren kann.
Wir verwenden für unsere stromsparenden Mini-Server Mainboards von VIA, auf denen der C3-Prozessor bereits fest aufgelöstet ist. Chipsatz und Prozessor harmonieren gut miteinander, wenngleich die Leistung für ein Desktop-System insbesondere im Grafikbereich kaum ausreichend wäre. Für einen Server spielt das jedoch keine Rolle - Hauptsache, der Energieverbrauch stimmt. Das System wird dann noch mit einer 3.5-Zoll-Festplatte (ein für den 24/7-Betrieb freigegebenes RAID-Modell versehen. Die ist zwar, was den Energieverbrauch angeht, nicht das Optimum - eine 2.5-Zoll-Notebookfestplatte wäre wesentlich sparsamer - aber dafür ist der Datendurchsatz sehr gut. Und das ist für den vorgesehenen Serverbetrieb wiederum nahezu unverzichtbar. Auf Redundanz bei den Festplatten wird verzichtet, statt dessen wird regelmäßig ein Komplett-Backup des Servers auf einer externen USB-Festplatte durchgeführt.
Insgesamt entsteht so ein kleiner Server, der im Betrieb deutlich unter einer Leistungsaufnahme von 50 Watt liegt. Damit kann man leben. Beim aktuellen Preis von 17,84 Cent/kWh bei unserem Stromanbieter kostet der Betrieb des Servers pro Tag rund 21 Cent, pro Jahr also rund 77 Euro. Zum Vergleich: Das Hosting des Servers bei einem Provider kostet Stand 2008 pro Monat mindestens 10 Euro, pro Jahr also 120 Euro. Macht also immer noch eine Ersparnis von 40 Euro beim Home-Hosting gegenüber dem Provider-Hosting. So ganz ehrlich ist diese Rechnung natürlich nicht, denn immerhin muss man den Stromverbrauch des DSL-Routers noch mit in die Rechnung einbeziehen. Und wenn die Strompreise weiter steigen und die Hostingpreise weiter fallen sollten, ist Home-Hosting sicher keine so günstige Alternative mehr.
Einrichtung des Servers
Auswahl des Betriebssystems
Es gibt viele Gründe, warum man einen Webserver nicht unter Windows laufen lassen sollte. Sicherheitsaspekte spielen dabei sicher eine große Rolle. Für den angepeilten Zweck des kleinen und sparsamen Homeservers ist Linux aber auf jeden Fall die bessere Wahl. Zum einen ist es als OpenSource-Produkt kostenfrei verfügbar. Zum anderen benötigen wir bei unserem Server keine grafische Benutzeroberfläche. Die entsprechenden Ressourcen benutzt man lieber für die produktiven Services wie den Web- oder Mailserver. Darüber hinaus läuft Linux, gerade weil es so ressourcenschonend konfiguriert werden kann, auf leistungsschwächeren Plattformen einfach viel schneller und oft auch stabiler als Windows. Und zu guter Letzt muss man berücksichtigen, daß durch die permanente Weiterentwicklung des Systems durch die weltweite Entwicklergemeinde Sicherheitslöcher sehr schnell entdeckt und gestopft werden. Also ist die Entscheidung klar und schnell getroffen - es kommt ein Linux-System zum Einsatz.
Grund-Konfiguration
Um einen Webserver zu betreiben, benötigt man zunächst nur eine minimale Linux-Installation ohne jede grafische Oberfläche. Egal, welche Distribution man verwendet, sollte man das System also ohne X11, KDE und Gnome installieren. Das spart erheblich an Ressourcen, zumal man am Server selbst später ohnehin nicht arbeiten wird - wozu also eine grafische Oberfläche?
Zusätzlich zur Basisinstallation sollten folgende Services auf dem Server nicht fehlen:
Apache als HTTP-Server
PHP als Apache-Modul (für den Betrieb des Content-Management-Systems)
mySQL als Datenbank-Backend
Sendmail oder Postfix als Mail-Server (ich bevorzuge aus irgendeinem Grund Postfix)
SpamAssassin als Spamfilter
BIND als lokaler Nameserver (man kann natürlich auch den Nameserver des Providers verwenden)
Zusätzlich kann man natürlich bei Bedarf noch einen DHCP-Server für die lokale Vergabe von IP-Adressen installieren, einen Samba-Server, um von Windows-Clients Dateien mit dem Server austauschen zu können und vielleicht einen FTP-Server (sehr empfehlenswert: vsftp), um auch aus dem Internet die Möglichkeit zur Dateiablage auf dem Server zu haben.
Vernetzung
Der Server selbst wird vermutlich innerhalt des eigenen, lokalen Netzwerkes stehen, also keine "offizielle" IP-Adresse besitzen. Es sei denn, man koppelt den Server direkt mit dem DSL-Modem und etabliert die Internet-Verbindung hardwareseitig über eine zweite Ethernet-Schnittstelle und softwareseitig über den PPPoE-Daemon. Da viele DSL-Router heute jedoch gleichzeitig WLAN-Router darstellen und in einigen Fällen auch Fax- und Anrufbeantworterfunktion für den ISDN-Anschluss beinhalten, ist es einfacher, die Internetverbindung über einen DSL-Router zu etablieren und dessen Firewall so zu konfigurieren, dass die gewünschten Dienste direkt an den im lokalen Netzwerk stehenden Server weitergeroutet werden.
Also muss der Server zunächst eine IP-Adresse aus einem der privaten Adressräume des TCP/IP-Protokolls erhalten. Es gibt drei solche Adressräume:
10.0.0.0/8:
Dieser Adressraum kann verwendet werden, wenn das lokale Netzwerk sehr viele Clients enthalten soll, wie das bei Firmennetzwerken der Fall ist. Für private Netze ist dieser Adressraum wohl in den meisten Fällen zu groß - wer hat schon rund 16.5 Millionen Computer zu Hause.
172.16.0.0/12:
Dieser Adressraum ist etwas kleiner als der des 10er-Adressraumes, aber für private Netzwerke immer noch viel zu groß. Außerdem ist die Berechnung der IP-Adressen und Netzmasken etwas komplizierter, da der Adressraum insgesamt eine Netzmaske von 12 Bit hat.
192.168.0.0/16:
In diesem Adressraum finden immer noch mehr als 60.000 Clients Platz, aber durch die einfache Berechnung der IP-Adressen und der Netzmasken ist dies sicher der Adressraum, der in den meisten privaten Netzwerken verwendet wird
Wer mehr über die Funktionsweise von TCP/IP und die Vergabe von IP-Adressen wissen will, dem sei der entsprechende Wikipedia-Artikel ans Herz gelegt.
Gehen wir einmal davon aus, dass unser internes LAN den IP-Adressbereich 192.168.1.0/24 benutzen soll. In diesem Adressbereich würden 255 Clients Platz haben, was sicher für die meisten häuslichen Zwecke ausreicht - selbst wenn man davon ausgeht, dass in absehbarer Zeit Fernseher, digitale Bilderrahmen, MP3-Player, Mobiltelefone sowieso und vielleicht sogar Kühlschrank und Waschmaschine nach einer IP-Adresse gieren.
Der DSL-Router erhält dabei die IP-Adresse 192.168.1.1. Diese IP-Adresse ist für alle weiteren Clients später insofern wichtig, als dass sie alle Datenpakete, die ins Internet gelangen sollen, an diese IP-Adresse zur Weiterleitung senden müssen. Als Netzmaske wird beim DSL-Router (genauso wie bei allen anderen Clients innerhalt des Netzwerkes) der Wert 255.255.255.0 festgelegt.
Der künftige Web- (und Mail-) Server erhält im Netzwerk nun z.B. die Adresse 192.168.1.2, Netzmaske 255.255.255.0. Als Standard-Gateway wird, wie eben schon erläutert, die IP-Adresse des DSL-Routers - also 192.168.1.1 - eingetragen. Damit sollte bei funktionierender DSL-Verbindung der Server bereits Kontakt zum Internet haben. Nur umgekehrt ist noch kein Datenverkehr möglich - der Server ist aus dem Internet noch vollkommen unsichtbar. Damit sich das ändert, muss auf dem DSL-Router sogenanntes Port-Forwarding aktiviert werden. Die meisten DSL-Router bieten in ihrem Konfigurationsmenü eine entsprechende Option an. Gleichzeitig wird sicher auch für leichtfertiger Benutzung dieser Option gewarnt, da man damit externen Clients aus dem Internet den Zugriff auf das lokale Netzwerk erlaubt. In unserem Fall ist das jedoch gewünscht und auch ungefährlich, wenn man bei der Konfiguration bestimmte Regeln beachtet.
Folgende Ports sollten auf dem DSL-Router für die Weiterleitung an unseren Server, also an die IP-Adresse 192.168.1.2 freigegeben werden:
Port 80 (HTTP):
Auf diesem Port beantwortet der Apache Anfragen zu Webseiten. Dieser Service ist ziemlich unkritisch, da er kaum mißbraucht werden kann. Der aktuelle Apache-Server ist gegen unberechtigtes Eindringen ziemlich gut geschützt.
Port 443 (HTTPS):
Auf diesem Port beantwortet der Apache Anfragen zu verschlüsselten Webseiten. Man benötigt diesen Port nur dann, wenn man verschlüsselte Webseiten anbieten will. Das macht zum Beispiel für einen E-Mail-Webclient durchaus Sinn. Man könnte dann auf die Öffnung des IMAP-Ports verzichten.
Port 25 (SMTP):
Auf diesem Port empfängt der Mailserver Nachrichten aus dem Internet. Auf dem Mailserver muss dann noch dafür gesorgt werden, dass der Mailserver nicht von Dritten zum Versand von Spam mißbraucht wird. Wie man das tut, werde ich später noch zeigen.
Port 143 (IMAP):
Auf diesem Port beantwortet der IMAP-Server Mailanfragen. Diese Portfreigabe wird benötigt, wenn man selbst aus dem Internet (z.B. unterwegs) Mails lesen möchte, die sich im heimischen Postfach befinden. Allerdings sollte man sich überlegen, ob die Verwendung eines E-Mail-Clients über verschlüsselte Webseiten nicht die bessere Alternative darstellt.
Port 993 (IMAPS):
Dieser Port stellt die SSL-verschlüsselte Version des Ports 143 dar, also die verschlüsselte Beantwortung von Mailanfragen. Auch diesen Port braucht man nur dann freizugeben, wenn man selbst aus dem Internet heraus Mails lesen will.
Die Auflistung beinhaltet nicht die Freigabe von Ports für einen FTP-Server, für den Remote-Zugriff auf der Server per SSH oder ähnliches. Die Freigabe dieser Ports funktioniert aber auf gleiche Weise. Dazu vielleicht später mehr.
Firewall-Konfiguration
Nach der Öffnung der Ports auf dem DSL-Router werden Pakete, die aus dem Internet auf den entsprechenden Ports ankommen, an unseren Server weitergeleitet. Bei nahezu allen aktuellen Linux-Distributionen kommen sie dann allerdings nicht weiter, da auf dem Server ebenfalls eine Firewall läuft, die den Server auf den betreffenden Ports standardmäßig unerreichbar macht und damit vor Angriffen schützt. In diese Firewall müssen wir nun ganz gezielt und mit etwas Vorsicht Löcher bohren.
Die meisten Linux-Firewalls verwenden das Paket IPTABLES als Firewall. Konfiguriert wird die Firewall über das Textfile iptables im Verzeichns /etc/sysconfig.Bei einem vollständig geschützten System hat diese Datei meist folgenden Inhalt:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT

*mangle
:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:pREROUTING ACCEPT [0:0]
:pOSTROUTING ACCEPT [0:0]
COMMIT

*nat
:OUTPUT ACCEPT [0:0]
:pREROUTING ACCEPT [0:0]
:pOSTROUTING ACCEPT [0:0]
COMMIT
Ohne hier weiter ins Detail zu gehen nur eine ganz kurze Erklärung für den Inhalt. IPTABLES arbeitet mit sogenannten Chains, also Ketten, welche alle Pakete, die durch das TCP/IP-Protokoll auf dem Server verarbeitet werden, durchlaufen müssen. Im dargestellten Beispiel interessiert die Definition mit dem Namen filter, welche die Filterung eingehender Datenpakete steuert. Hier müssen wir einige Ports durchlässig machen. Dazu ergänzt man die filter-Sektion folgendermaßen:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p udp --dport 25 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p udp --dport 80 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 143 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 143 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p udp --dport 443 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 993 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p udp --dport 993 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
Nach dieser Operation muss die Firewall des Servers neu gestartet werden, z.B. durch Eingabe des Befehls

[root@server /]# /etc/init.d/iptables restart

Anschließend sind die entsprechenden Ports auf dem Server geöffnet. Rein technisch könnten jetzt also Besucher aus dem Internet bereits Anfragen an Web- und Mailserver absenden. Höchste Zeit, die entsprechenden Dienste auf dem Server korrekt zu konfigurieren.
Apache-Konfiguration
Der erste und für die spätere Verwendung des Servers ja auch wichtigste Service ist der Apache. Er ist für die Beantwortung von Anfragen nach Webseiten verantwortlich. Nach der Installation des entsprechenden Pakets auf dem Server, welche je nach Linux-Distribution ganz unterschiedlich ablaufen kann, ist es bereits möglich den Service zu starten. Ein Aufruf des Servers im Webbrowser würde jedoch zunächst noch nichts anzeigen - bis auf eine Willkommensseite vielleicht.
Bei der Konfiguration des Apache sollte man wissen, dass dieser Webserver eigentlich beliebig viele sogenannte virtuelle Server steuert. Es gibt einen Standardserver, welcher alle Anfragen beantwortet, die von keinem anderen virtuellen Server beantwortet werden. Auf diese Weise kann ein physischer Webserver z.B. mehrere Domains betreiben, in dem für jede Domain ein eigener virtueller Server eingerichtet wird, der nur auf Anfragen zu seiner konfigurierten Domain antwortet. Dies ist aber für einen einfachen Webserver kaum notwendig. Wir beschränken uns hier auf Anpassungen in der Konfiguration des Standardservers.
Normalerweise werden in der Standardkonfiguration des Apache die Webseiten im Verzeichnis /var/www/html abgelegt. Dieses Verzeichnis wird auch als Webserver-Root bezeichnet. Jede HTML-Datei, welche hier abgelegt wird, kann über das Web über die entsprechende URL abgerufen werden. Soll das Webserver-Root auf ein anderes Verzeichnis umgelegt werden, zum Beispiel aus Ordnungsgründen, erfolgt dies in der Konfigurationsdatei des Apache httpd.conf im Verzeichnis /etc/httpd/conf. Dort gibt findet man für das Webserver-Root des Standard-Servers folgenden Eintrag
DocumentRoot /var/www/html
Eine Änderung dieses Wertes auf einen anderen Pfad bewirkt nach dem Neustart des Servers, dass Webseiten vom Standardserver an diesem Pfad gesucht werden. Der Server kann über den Befehl

[root@server /]# /etc/init.d/iptables restart

neu gestartet werden, alle vorgenommen Änderungen werden damit gültig. Man sollte jedoch mit Änderungen in der httpd.conf vorsichtig sein, der Apache bestraft selbst kleinste Schreibfehler in der Konfiguration mit sofortigem Nicht-Funktionieren. Es ist also eine gute Idee, sich vor dem Ändern der Konfiguration eine Kopie dieser Datei anzulegen.
Mail-Server-Konfiguration (Postfix)
Während die Einrichtung des Apache recht unkompliziert war - genau genommen muss man ja nur seine Webseiten an die richtige Stelle im Dateisystem kopieren und den Server starten - ist die Konfiguration des Mailservers etwas anspruchsvoller. Hier ist der Mißbrauchs des Servers viel wahrscheinlicher, daher müssen wir einige Vorkehrungen treffen.
Ich zeige die Konfiguration hier am Beispiel des Postfix-Mailservers. Vor einigen Jahren hat man dem Postfix-Server gerne den Vorzug gegenüber dem Sendmail gegeben, da dieser einige kleinere Sicherheitslöcher besaß und schwieriger zu konfigurieren war. Das mag sich heute geändert haben, ich bin jedoch beim Postfix geblieben.
Der Postfix-Server stellt im Prinzip nichts weiter als einen SMTP-Server zur Verfügung. Er muss genau eine Aufgabe erfüllen: E-Mails, die an die vom Server verwaltete(n) Domäne(n) gerichtet sind, entweder den lokalen Postfächern zuzuweisen oder weiterzuleiten. Diese Mails können aus drei verschiedenen Quellen stammen:
einem lokalen Benutzer auf dem Server (zum Beispiel einem am Webmail-Client angemeldeten Benutzer)
einem Benutzer im lokalen Netzwerk, der von seinem PC über den Server eine Mail versenden will
einem Benutzer im Internet, der eine Mail über den Server versenden will
Eine funktionierende Firewall (und eine immer abgeschlossene Wohnungstür) vorausgesetzt, können wir in den ersten beiden Szenarien dem Benutzer trauen und das Versenden einer Mail zulassen. Im letzten Szenario ist jedoch Vorsicht geboten. Nicht jeder soll über den Server Nachrichten versenden dürfen, ansonsten könnte der Server allzu leicht als Spam-Server mißbraucht werden. Hier ist also etwas Arbeit notwendig. Aber eins nach dem anderen. Die meisten Einstellungen werden bei Postfix in der Datei main.cf im Verzeichnis /etc/postfix vorgenommen.
Einstellen des Domänen-Namens für ausgehende Post
Wenn von unserem Server Mails an Empfänger im Internet gesandt werden sollen, müssen einige Dinge besonders beachtet werden. Durch das heute riesige Spam-Aufkommen werden bei den meisten Mail-Providern die eingehenden Nachrichten einer Prüfung auf Authentizität unterzogen. Zu dieser Prüfung gehört unter anderem, ob die Domäne des absendenden Servers mit der Domäne des Absenders übereinstimmt. Eine Nichtübereinstimmung ist ein Hinweis auf Spam - die Nachricht wird dann oft entweder nicht zugestellt oder als Spam gekennzeichnet. Wenn von unserem Mail-Server nun Mails versendet werden, wird diese von Postfix automatisch mit dem Domänennamen des Servers im lokalen Netzwerk gekennzeichnet, also z.B. meinserver.localdomain. Gleichzeitig steht aber als Absender der Mail z.B. username@meinedomain.org , weil wir diese Einstellung im Mailprogramm vorgenommen haben. Die Folge könnte wie erwähnt sein, daß die Mail vom empfangenden Server als Spam identifiziert wird - völlig unabhängig vom Inhalt. Um dies zu vermeiden, gibt es zwei Optionen in der Datei main.cf, mit der alle ausgehenden Mails automatisch als von einer bestimmten Domain kommend gekennzeichnet werden:
myorigin = meinedomain.org
masquerade_domains = meinedomain.org
Einstellen des Domänen-Namens für eingehende Post
In der Standardeinstellung stellt Postfix nur Mails an lokale Benutzer zu, die an die Domänen servername, localhost oder localhost.localdomain gerichtet sind - also intern versandte Mails. Damit auch Mails, die aus dem Netz an den Server übermitttelt werden, einem lokalen Benutzer zugestellt werden, muß die entsprechende Domäne für die Mailzustellung aktiviert werden. Das erledigt folgende Option:
mydestination = $myhostname, localhost.$mydomain, localhost, meinedomain.org
Ergänzt wurde im obigen Beispiel lediglich der Eintrag meinedomain.org.
Einstellen der für Mailweiterleitung berechtigten Clients
Diese Option ist eine der wichtigsten überhaupt. Wird hier ein Fehler gemacht, kann unter Umständen jeder Benutzer im Internet Mails über den Server versenden. Genaugenommen müssen aber nur lokale Benutzer oder ggf. Benutzer aus dem lokalen Netzwerk Mails über den Server versenden. Aus dem Internet soll niemand den Server als Relay verwenden dürfen. Diese Einstellung wird über die folgende Option vorgenommen:
relay_domains = 192.168.1.0/24
Aktivierung von Spam-Assassin als Spam-Filter
Es macht durchaus Sinn, beim heutigen Spam-Aufkommen einen Filter einzusetzen, der Mails direkt nach der Zustellung durch Postfix verarbeitet und ggf. als Spam markiert oder sogar direkt in einen Spam-Ordner im Eingangspostfach des Benutzers verschiebt. Einer der besten Spam-Filter, der genau diese Aufgabe zuverlässig und schnell erledigt, ist SpamAssassin. Es handelt sich dabei eigentlich um ein recht umfangreiches Pearl-Script, welches bei den meisten Linux-Distributionen enthalten ist und als Paket installiert werden kann.
Allerdings muss nach der Installation von SpamAssassin dem Postfix-Server noch mitgeteilt werden, dass die für lokale Benutzer bestimmte Mail nicht direkt zugestellt werden soll, sondern statt dessen zunächst an SpamAssassin weitergereicht werden soll. Dazu wird eine weitere Komponente benötigt, nämlich procmail. Dabei handelt es sich um ein weiteres Paket, welches aber bei den meisten Linux-Distributionen im Standard-Funktionsumfang enthalten sein sollte.
Zunächst stellen wir in der Postfix-Konfigurationsdatei main.cf ein, dass lokale zuzustellende Mails nicht direkt zugestellt werden, sondern an procmail weitergereicht werden. Das passiert durch folgenden Eintrag in der main.cf:
mailbox_command = /usr/bin/procmail
Im Verzeichnis /etc befindet sich die Konfigurationsdatei procmail.rc, mit der gesteuert werden kann, wie mit zu verarbeitenden Mails zu verfahren ist. Diese Datei könnte zum Beispiel folgenden Inhalt haben:

DROPPRIVS=yes
:0fw
| /usr/bin/spamc
:0
* ^X-Spam-Flag: Yes
$HOME/mail/spam
Für eine genaue Beschreibung aller möglichen Optionen sei wiederum auf den Wikipedia-Eintrag von procmail verwiesen. Hier sei nur kurz erläutert, dass die angegebenen Parameter eine Mail zunächst an das Programm /usr/bin/spamc weiterreichen. Wenn die Mail anschließend in den Kopfzeilen den Vermerk X-Spam-Flag: Yes enthält, wird sie im Mailbox-Verzeichnis des Empfängers im Verzeichnis spam abgelegt.
Konfiguration der Mail-Weiterleitung an den dynIP-Provider
Rein technisch könnte unser Mailserver - eine funktionierende DNS-Konfiguration vorausgesetzt - alle ausgehenden Mails direkt an ihre jeweiligen Empfänger senden. Praktisch ist das keine besonders gute Idee. Der Grund hierfür sind wieder einmal das hohe Spam-Aufkommen im Internet und daraus folgend die Maßnahmen, die praktisch alle großen Mailprovider dagegen unternehmen. Eine dieser Maßnahmen ist der sogenannte Reverse-Lookup, der vom Mailserver beim Empfangen einer Mail durchgeführt wird. Das folgende Beispiel zeigt leicht nachvollziehbar, was dabei passiert.
Als erstes führe ich einen Domain-Lookup meiner Mail-Domäne durch, die Eingabe:

[root@meinserver /]# nslookup meinedomain.org

liefert dabei als Antwort:

Server: 192.168.1.2
Address: 192.168.1.2#53

Non-authoritative answer:
Name: meinedomain.org
Address: 88.73.18.202
Es wird also festgestellt, dass der Domain meinedomain.org momentan die IP-Adresse 88.73.18.202 zugewiesen ist. Jetzt führen wir eine Gegenprüfung mit folgendem Befehl durch:

[root@meinserver /]# nslookup 88.73.18.202

und erhalten diesmal als Antwort:

Server: 192.168.1.2
Address: 192.168.1.2#53

Non-authoritative answer:
202.18.73.88.in-addr.arpa name = dslb-088-073-018-202.pools.arcor-ip.net.
Wie zu erwarten, wird die IP-Adresse nicht zur Domain meinedomain.org, sondern völlig korrekt zur Domain dslb-088-073-018-202.pools.arcor-ip.net aufgelöst, denn dort gehört die IP-Adresse ja schließlich auch hin. Dumm nur, dass deswegen direkt vom Mailserver unter dieser IP-Adresse versandte Mails kaum einmal ihren Empfänger erreichen werden, weil jeder Mailserver auf der Empfängerseite genau diese Prüfung durchführt und zu dem Ergebnis kommt, dass der Absender vorgibt, ein anderer zu sein als er ist. Im Anschluss wird die entsprechende Mail entweder gleich verworfen oder zumindest als Spam gekennzeichnet.
Das wissen natürlich auch die dynIP-Provider, weswegen viele von ihnen anbieten, die Mail über einen ihrer Mailserver zu versenden. Der Mailserver des Provider ist dabei als zweiter MX-Server im DNS-Record der jeweiligen Domain eingetragen und daher "berechtigt", Mails im Namen der Domain zu versenden.
Eine Hürde müssen wir nun allerdings noch nehmen: Natürlich lassen die dynIP-Provider auch nur für ihre Kunden den Versand von Mails über ihre Server zu. Um das zu gewährleisten, wird meist eine Anmeldung am SMTP-Server vor dem eigentlichen Versand gefordert. Diese passiert über das sogenannte smtp_auth.
Wir müssen jetzt also Postfix noch beibringen, die Mails nicht direkt zu versenden, sondern statt dessen an den Mailserver des Providers weiterzuleiten, sich bei diesem jedoch vorher per smtp_auth anzumelden. Und das geht so:
Zunächst wird in der Datei main.cf der folgende Parameter gesetzt:
relayhost = mail.meinprovider.org
Dabei ist mail.meinprovider.org selbstredend durch die korrekte Adresse des Provider-Mailservers zu ersetzen. Damit läuft zunächst mal alle ausgehende Post über diesen Server. Nun müssen wir uns noch um die Authentifizierung kümmern. Dazu sind noch folgende Zeilen in der main.cf nötig:
smtp_sasl_auth_enable=yes smtp_sasl_security_options = noanonymous smtp_sasl_password_maps = hash:/etc/postfix/smtp_auth
Der erste Parameter schaltet smpt_auth zunächst einmal ein, die zweite unterbindet den Versuch, sich anonym am Zielserver anzumelden. Die dritte Option verweist auf eine Datei, welche den/die Benutzeranmeldungen für den SMTP-Server beim Provider enthält. Diese Datei ist standardmäßig in der Postfix-Konfiguration nicht enthalten, also legen wir sie zunächst einmal an. Sie muss dabei folgenden Inhalt haben:
mail.meinprovider.org username:password
Auch hier gilt natürlich, dass die Angaben durch die tatsächliche Adresse des Provider-Mailservers sowie die von ihm gelieferten Benutzerangaben zu ersetzen sind. Anschließend muss die Textdatei noch ins Postfix-spezifische Datenbankformat umgewandelt werden. Das passiert durch Eingabe des Befehls:

[root@meinserver /]# postmap smtp_auth

Und damit wäre die Konfiguration von Postfix auch schon beendet. Jetzt muss die gesamte Konfiguration noch aktiviert werden. Dies erfolgt mit folgendem Befehl:

[root@server /]# /etc/init.d/postfix restart
Erfahrungen im Betrieb
Wie man sehen kann, ist die Einrichtung eines Web- und Mailservers wirklich kein Problem mehr. Sicher ist das auch ein Verdienst der inzwischen viel einfacher gewordenen Installationsroutinen der Linux-Distributionen. Und natürlich kann bei der Konfiguration noch jede Menge schief gehen.
Hat man es aber einmal bis an diesen Punkt geschafft, wird man im günstigsten Fall schon einige Tage später mit einem sehr viel besseren Ranking der eigenen Seite bei Google belohnt. Und leider auch mit zahllosen Versuchen, den Mailserver als Relay zu mißbrauchen - und einem höheren Spam-Aufkommen als bisher. Letzteres liegt daran, daß die meisten Mail-Provider heute standardmäßig die Mail von bekannten Spam-Versendern sofort ausfiltern und dem Benutzer überhaupt nicht mehr zustellen. Das passiert nun nicht mehr, darum muss sich jetzt der SpamAssassin kümmern. Um die Versuche, den eigenen Server als Relay zu mißbrauchen muss man sich keine Gedanken machen, denn das haben wir ja durch die entsprechende Postfix-Option bereits ausgeschlossen.
Das Surfen auf dem eigenen Webserver funktioniert jedenfalls prima. Klar, beim Ansehen von Webseiten, die viele und große Bilder beinhalten wird der Benutzer merken, dass der Server an einer Leitung mit geringer Bandbreite angeschlossen ist. Das zwingt einen aber letztlich nur zu einem angenehm spartanischen Webdesign ohne große Bilder und ressourcenfressende Flash-Intros.


Nun wie ich ja schon geschrieben habe, ist mein Kenntnisstand in der Servertechnik sowie Software nicht groß und ich suche selbst auch nach Lösungen, ich lese sehr viel (Nicht nur im Web) auch Bücher nur um das alles auch richtig umsetzen zu können brauche ich etwas Hilfe von Fachleuten oder Leuten die das alles schon Erfolgreich gemacht haben!
 
Nun sicherlich hast du damit Recht mit der aktuellesten Win Version aber selbst die älteren Versionen kann man noch sehr gut absichern!Dazu gibt es ja noch Linux!


Windows absichern mithilfe von Linux? Ich verstehe nicht.. Oder willst du deinen weiteren Linux-Server als Firewall vorschalten? Das würde auch nur bedingt helfen..
 
Danke Mr.Check

Windows absichern mithilfe von Linux? Ich verstehe nicht.. Oder willst du deinen weiteren Linux-Server als Firewall vorschalten? Das würde auch nur bedingt helfen..

sorry hab mich schon wieder etwas missverständlich ausgedrückt, ich wollte damit sagen das ich in meine Überlegung von Windows auf Linux umsteigen soll, habe mir gerade die neuste Linux Version heruntergeladen, klar ist das nicht die beste Möglichkeit mit Linux seinen WindowsServer abzusichern, obwohl man einige Linux Programme in einen WindwosServer sehr gut einbinden kann (so hab ich es gelesen in einen Artkiel)

So muss leider raus und was arbeiten (die Pflicht ruft) Man liest sich!

Gruß Robert
 
Einen Server zu Hause rund um die Uhr laufen zu lassen kostet etwa 10-15EUR Strom / Monat. Das ist also dein Budget, mit dem du losgehen kannst.

Für 10EUR bekommst du Webspace in einer solchen Qualität, wie man es zu Hause niemals umgesetzt bekommt. Stichworte sind hier KnowHow, professionelle Betreuung, Anbindung ans Internet, Monitoring, Verfügbarkeit, Backup, eingesetzte Hardware ...

Und da bin ICH lange genug unterwegs um einschätzen zu können, was in einem Rechenzentrum für 10EUR zu bekommen ist und wie das im Vergleich zu einem DSL-Anschluss und Home-PC abgeht.

Also, besorg dir ein passendes Webspace-Packet mit PHP und Datenbank und dann ab damit. Wenn du uns hier genaue Specs deines Setups reinreichst, helfen wir sogar ein wenig beim Suchen eines passenden Angebotes.
 
Für 10EUR bekommst du Webspace in einer solchen Qualität, wie man es zu Hause niemals umgesetzt bekommt
DAS kriegste sogar von einem Freehoster... Die Qualitaet eines DSL-Anschlusses mit entsprechender Hardware dahinter zu toppen ist naemlich nicht sehr schwer.
 
Back
Top