# Tipps und Anregungen für Router

## trikolon

hallo gentoogemeinde.

wie der titel schon verrät, suche ich ein paar ideen, tipps usw was den neubau meines routers angeht. 

zur hardware: P3 - 800 mit 512mb ram und als /root dient eine 20gb festplatte. 

der server hat folgende aufgaben: routen inklusive traffic shaping und ipp2p, samba/nfs, apache mit mysql und php, ftp, dyndns, und noch ein paar kleinere spielerein. also nix besonders. das netzwerk, wo er läuft, umfasst ca 10-15 pcs..

inspiriert von der ct-server geschichte und im hinblick auf mehr sicherheit, wollte ich den server wie folgt konfigurieren. gentoo mit xen, auf dem host sollen sachen laufen die das intranet angehen wie dhcp, samba, nfs, antivir. dann 2 clients (domU - auch gentoo). der erste soll nur fürs internet zuständig sein und eben nur die einwahl per dsl managen und die firewall. der zweite soll nur die sachen wie apache, mysql, php usw bereitstellen. als xen howto wollte ich den artikel auf gentoo-wiki hernehmen. 

könnte man hier zb für alle 3 systeme ein portage verzeichnis benutzen?

gebt mir doch ein paar erfahrungen und meinungen ob das sinn macht oder totaler quatsch ist. danke im voraus.

gruß ben

----------

## Max Steel

Das mit den /usr/portage Verzeichnis kannst du natürlich so machen, keine Frage.

----------

## trikolon

was ich zb auch noch fragen wollte ist, ob die hardware reicht oder der kleine einfach zu schwach dafür ist und wie die config sinn macht, also wieviel ram die einzelnen domu bekommen. wenn ich die sache mit den netzwerkkarten richtig verstanden habe, sollten die als "bridged" konfoguriert werden und dann im prinzip für jedes system eine eigene ip bekommen, oder?

----------

## Knieper

 *trikolon wrote:*   

> 
> 
> wie der titel schon verrät, suche ich ein paar ideen, tipps usw was den neubau meines routers angeht. 
> 
> zur hardware: P3 - 800 mit 512mb ram und als /root dient eine 20gb festplatte. 
> ...

 

Virtualisierungen bringen eigentlich selten Vorteile (Testumgebungen, Kinderbackup etc.), sicherer sind sie nicht, daher wuerde ich an Deiner Stelle XEN weglassen und die nicht gerade ueppigen Ressourcen sparen. Samba finde ich persoenlich nicht gerade schoen, vsftpd, dyndns, traffic shaping etc. duerften ohne Probleme laufen. Zum Apache/Mysql/Php-Teil muesstest Du noch sagen, ob Du wirklich diese Kombination benoetigst und in welchem Umfang die genutzt werden.

----------

## trikolon

apache/mysql/php wird von ein paar sachen wie amarok, torrentflux und ein forum/gästebuch genutzt.

um samba komme ich nicht herum da hier 90% windowskisten laufen und die lieben leute sich nicht zu linux bekehren lassen wollen *g*

----------

## dertobi123

Dom0 plus zwei DomU auf der Hardware _kann_ eng werden, im Zweifelsfall mag auch ein LAMP-System allein schonmal 512MB schnell "fressen". Ich hatte mal mit XEN auf ähnlicher Hardware (P3 933, 1G Ram, U320-SCSI Disks) gespielt, Probleme wirst du mit dem RAM (imho zu wenig) und der Festplatte bekommen - 20G IDE aus der Vorsteinzeit sind jetzt nicht grade die I/O-Sensation um es vorsichtig zu formulieren  :Wink: 

----------

## tuxianer

 *Quote:*   

> Samba finde ich persoenlich nicht gerade schoen,

 

Wo hast du den ein Problem mit Samba, ich finde gerade in den letzten zügen des momentanen Projekts der Version 3.* hat sich Samba richtig gut gemacht?

Ansonsten ließe sich überlegen, ich meine es geb für Windows einen NFS Patch habe ich mal gelesen, wenn es nur um Export von Daten ginge wäre das auch eine Lösung, wobei ich selber mit Samba gut klar komme und es nur weiter empfehlen kann.

MfG

----------

## Knieper

 *tuxianer wrote:*   

> 
> 
> Wo hast du den ein Problem mit Samba, ich finde gerade in den letzten zügen des momentanen Projekts der Version 3.* hat sich Samba richtig gut gemacht?

 

Ehrlich? Bei mir kackt das oefter mal ab, daher bin ich nicht sehr ueberzeugt davon, ausserdem verwurschtelt es teilweise die Dateirechte.

 *trikolon wrote:*   

> apache/mysql/php wird von ein paar sachen wie amarok, torrentflux und ein forum/gästebuch genutzt.

 

torrentflux? War das nicht das Teil, das das lahme Bloatpythonskript nutzt und es dann tatsaechlich noch gegen noch mehr Bloat bastelt? Ich nutze auf dem Router rtorrent im screen, aber ob man das W*-Nutzern beibringen kann? (Eigentlich muss man nur die torrent-Datei in ein Verzeichnis kopieren und warten.) Bei amarok weiss ich nicht, was Du damit anstellst - und bei Foren/Gaestebuechern gibt es sicherlich Alternativen zu PHP/Apache. Evtl. im lighttpd (auch nicht gerade fuer Sicherheitsfanatiker geeignet), gatling... laufen lassen oder kleine DBs benutzen (Gaestebuch zB. in cdb, da es selten veraendert wird oder bdb oder...). Haengt natuerlich auch von den Zugriffszahlen ab.

PHP und Apache duerften hier der Schweizer Kaese in der Konfiguration sein.

----------

## tuxianer

 *Quote:*   

> Ehrlich? Bei mir kackt das oefter mal ab, daher bin ich nicht sehr ueberzeugt davon, ausserdem verwurschtelt es teilweise die Dateirechte. 

 

Also ich kann dir gerne einmal so ein paar der Features schreiben wofür ich Samba verwende:

1) Domain Controll System ( dir Nutzer der Windows Clients melden sich mit ihrem Unix Usernamen an dieser wird an die LDAP Datenbank übergeben und geprüft)

2) Home Verzeichniss Export ( Laufwerk Z: im Arbeitsplatz ist das Homeverzeichniss)

3)Full Access Controll aller Windows Maschienen, da sich die Maschienen über Samba bei mir im Netzwerk melden kann ich auch sehen was sie machen

_________

 *Quote:*   

> PHP und Apache duerften hier der Schweizer Kaese in der Konfiguration sein.

 

Vollkommen richtig, gerade PHP bietet viele offnen Lücken die zwar " immer wieder neu geschlossen werden ", aber so findig die Programmierer auch immer sind, Spione die die Daten haben will bekommen sie. Apache halte ich für weniger Kritisch da Apache nur im Hintergrund steht, kleiner Tipp von mir sei vorsichtig mit Running Scripts gerade in CGI, damit können sich andere schnell mal Root Rechte holen

----------

## trikolon

erstmals vielen dank für die tipps.

ok, dann lass ich xen mal lieber sein. und versuch erstmal soviel wie möglich über die firewall zu unterbinden und apache/php mit minimaler config einzurichten. 

amarok: nun wir haben alle unser musikarchiv auf dem router gelegt und der verwaltet die amarok datenbank zentral für die 4-5 linux rechner.

würde es denn sinn machen apache und php in einer chroot umgebung laufen zu lassen um ein wenig mehr sicherheit beim schweizer käse zu erhalten?

----------

## cfreak200

Ich wollt mal noch was zu dem Thema LAMP schreiben:

Seit ungefähr 2 Jahren betreibe ich einen kleinen EPIA-Rechner (600MHz und 512 MB RAM) als Router mit LAMP,FTP,NFS,Samba und ab und an nochmal was anderes und hatte bisher keine wirklichen Performance Probleme, der Rechner ist halt nicht der schnellste (auch wenn nur ein Dienst läuft) aber für die "normale" Nutzung reicht das allemal. Ich habe die einzelnen Dienste nicht in virtuelle Maschienen o.Ä. aufgeteilt sondern alles direkt unter der Installation laufen und hatte auch dort noch keine Sicherheitsprobleme (evtl. Glück?  :Smile:  )

----------

## trikolon

@ cfreak200:

js so ist es bei mri im moment eben auch und ich hab mir da gedanken gemacht wie man das absichern könnte und deswegen hat mir diese virtualisierungssache auf den ersten blick recht gut gefallen..

----------

## moe

Ich teile nicht Kniepers Meinung bzgl. Virtualisierung. Alleine bringts sicher keine absolute Sicherheit (gerade in Xen wurde vor ein paar Tagen erst ne Lücke entdeckt), aber trotzdem bringt Virtualisierung imho mehr Sicherheit, als alle benötigten Dienste auf einem Rechner laufen zu lassen. Aber wie schon mehrfach hier gesagt, ich würde bei dieser Hardware, und bei diesen Anforderungen nicht Xen nehmen. Da du nur Linux virtualisieren willst, bietet sich VServer bzw. OpenVZ mit nahezu keinem Overhead an.

Gruss Maurice

----------

## trikolon

also ich habe mit nun die genannten möglichkeiten angesehen und denke, ich werde openvz benutzen. scheint mir das richtige für mein projekt zu sein.

was meint ihr? ist es sinnvoller den router ganz neu aufzusetzen oder einfach nur umbauen? beim umbauen befürchte ich, dass viele "müll" dabei übrig bleibt da ich ja dann das "hauptsystem" im nachhinein abspecken muss.

----------

## Anarcho

 *moe wrote:*   

> Ich teile nicht Kniepers Meinung bzgl. Virtualisierung. Alleine bringts sicher keine absolute Sicherheit (gerade in Xen wurde vor ein paar Tagen erst ne Lücke entdeckt), aber trotzdem bringt Virtualisierung imho mehr Sicherheit, als alle benötigten Dienste auf einem Rechner laufen zu lassen. Aber wie schon mehrfach hier gesagt, ich würde bei dieser Hardware, und bei diesen Anforderungen nicht Xen nehmen. Da du nur Linux virtualisieren willst, bietet sich VServer bzw. OpenVZ mit nahezu keinem Overhead an.
> 
> Gruss Maurice

 

Dem kann ich mich nur anschliessen. Mein nächster Server/Router wird ebenfalls für DSL/Routing ne eigene Virtuelle Maschine haben. Die zusätzliche Sicherheit ist nicht zu verachten. Man muss allersings ein paar Regel beachten z.B. unterschiedliche Passwörter usw.

----------

## Knieper

 *moe wrote:*   

> Ich teile nicht Kniepers Meinung bzgl. Virtualisierung. Alleine bringts sicher keine absolute Sicherheit (gerade in Xen wurde vor ein paar Tagen erst ne Lücke entdeckt), aber trotzdem bringt Virtualisierung imho mehr Sicherheit, als alle benötigten Dienste auf einem Rechner laufen zu lassen.

 

Das ist der uebliche Trugschluss, genau wie bei Personal Firewalls. Ein ordentlicher Server ist in mehrere verschieden privilegierte Prozesse unterteilt. Jeder von denen darf nur das, was seine Aufgabe erfordert. Zusaetzlich in einem chroot mit normaler Rechteueberwachung des Systems ist es sicherer, als eine Virtualisierungsloesung, da

1.) Diese im Normalfall weit mehr Rechte hat.

2.) Sie einen zusaetzlichen Angriffspunkt darstellt.

3.) Bisher so ziemlich alle Varianten geknackt worden sind.

4.) DOS-Angriffe aus Ressourcenmangel weit einfacher sind.

5.) Sobald ein Dienst kompromittiert wurde, die Virtualisierungsloesung dahinter egal ist, da das System eh neu aufgesetzt werden muss.

...

----------

## Anarcho

 *Knieper wrote:*   

>  *moe wrote:*   Ich teile nicht Kniepers Meinung bzgl. Virtualisierung. Alleine bringts sicher keine absolute Sicherheit (gerade in Xen wurde vor ein paar Tagen erst ne Lücke entdeckt), aber trotzdem bringt Virtualisierung imho mehr Sicherheit, als alle benötigten Dienste auf einem Rechner laufen zu lassen. 
> 
> Das ist der uebliche Trugschluss, genau wie bei Personal Firewalls. Ein ordentlicher Server ist in mehrere verschieden privilegierte Prozesse unterteilt. Jeder von denen darf nur das, was seine Aufgabe erfordert. Zusaetzlich in einem chroot mit normaler Rechteueberwachung des Systems ist es sicherer, als eine Virtualisierungsloesung, da
> 
> 1.) Diese im Normalfall weit mehr Rechte hat.

 

Das stimmt, aber die Dienste innerhalb der VM können genauso gesichert werden wie von dir oben beschrieben. Auch in einer VM läuft der Apache nicht mit root rechten.

 *Knieper wrote:*   

> 2.) Sie einen zusaetzlichen Angriffspunkt darstellt.

 

Das ist richtig.

 *Knieper wrote:*   

> 3.) Bisher so ziemlich alle Varianten geknackt worden sind.

 

Das wüsste ich jetzt so nicht. Was meinst du mit "genknackt"? Den Ausrbruch ins Hostsystem? Da hätte ich gerne entsprechende Links.

 *Knieper wrote:*   

> 4.) DOS-Angriffe aus Ressourcenmangel weit einfacher sind.

 

Ja und Nein! Einmal sind natürlich mehr resourcen im Einsatz. ABER z.b. eine Applikation die in einer auf 256 MB RAM beschränkte VM läuft kann nun nicht mehr den ganzen RAM zumüllen sondern nur noch die 256 MB der VM.

 *Knieper wrote:*   

> 5.) Sobald ein Dienst kompromittiert wurde, die Virtualisierungsloesung dahinter egal ist, da das System eh neu aufgesetzt werden muss.
> 
> ...

 

Aber bei einer VM kann man sehr viel einfach das Backup des Images einspielen und ohne den Server neustartetn zu müssen neu installieren.

Dazu kommt die Sicherheit das sollte bei einer Applikation mit Root-Rechten ein Sicherheitsproblem bestehen und jemand darüber ins System einsteigen kann er halt nur die eine VM kompormietiert hat. Das heisst natürlich nicht das er auch weitere Systeme befallen kann aber die Wahrscheinlichkeit sinkt.

Dazu kommt auch noch das es gutes Design ist pro Maschine nur eine Aufgabe zu haben. Also Router ist Router, Webserver eben nur Webserver usw.

----------

## think4urs11

 *Anarcho wrote:*   

>  *Knieper wrote:*   Das ist der uebliche Trugschluss, genau wie bei Personal Firewalls. Ein ordentlicher Server ist in mehrere verschieden privilegierte Prozesse unterteilt. Jeder von denen darf nur das, was seine Aufgabe erfordert. Zusaetzlich in einem chroot mit normaler Rechteueberwachung des Systems ist es sicherer, als eine Virtualisierungsloesung, da
> 
> 1.) Diese im Normalfall weit mehr Rechte hat. 
> 
> Das stimmt, aber die Dienste innerhalb der VM können genauso gesichert werden wie von dir oben beschrieben. Auch in einer VM läuft der Apache nicht mit root rechten.
> ...

 Das ist richtig.

Eine zusätzliche Virtualisierung verkompliziert aber das Setup und widerspricht damit evtl. dem KISS-Prinzip.

 *Anarcho wrote:*   

>  *Knieper wrote:*   3.) Bisher so ziemlich alle Varianten geknackt worden sind. 
> 
> Das wüsste ich jetzt so nicht. Was meinst du mit "genknackt"? Den Ausrbruch ins Hostsystem? Da hätte ich gerne entsprechende Links.

  http://lists.grok.org.uk/pipermail/full-disclosure/2007-September/065902.html

http://www.securiteam.com/securitynews/6Z00D0UHFU.html

http://securitytracker.com/alerts/2005/Dec/1015401.html

http://taviso.decsystem.org/virtsec.pdf

 *Anarcho wrote:*   

>  *Knieper wrote:*   4.) DOS-Angriffe aus Ressourcenmangel weit einfacher sind. 
> 
> Ja und Nein! Einmal sind natürlich mehr resourcen im Einsatz. ABER z.b. eine Applikation die in einer auf 256 MB RAM beschränkte VM läuft kann nun nicht mehr den ganzen RAM zumüllen sondern nur noch die 256 MB der VM.

 Außer der Admin war so 'clever' und hat für die VM's swapping aktiviert - früher oder später wird vielleicht die Platte (des Hostsystems) nicht vollaufen aber das Hostsystem trotzdem unbenutzbar langsam.

 *Anarcho wrote:*   

>  *Knieper wrote:*   5.) Sobald ein Dienst kompromittiert wurde, die Virtualisierungsloesung dahinter egal ist, da das System eh neu aufgesetzt werden muss.
> 
> ... Aber bei einer VM kann man sehr viel einfach das Backup des Images einspielen und ohne den Server neustartetn zu müssen neu installieren.

 Wenn man dem Hostsystem in diesem Zustand noch trauen kann - würde ich mir *sehr* genau überlegen...

 *Anarcho wrote:*   

> Dazu kommt die Sicherheit das sollte bei einer Applikation mit Root-Rechten ein Sicherheitsproblem bestehen und jemand darüber ins System einsteigen kann er halt nur die eine VM kompormietiert hat. Das heisst natürlich nicht das er auch weitere Systeme befallen kann aber die Wahrscheinlichkeit sinkt.

 Wenn es richtig aufgesetzt ist

 *Anarcho wrote:*   

> Dazu kommt auch noch das es gutes Design ist pro Maschine nur eine Aufgabe zu haben. Also Router ist Router, Webserver eben nur Webserver usw.

 ++

scheitert aber nicht selten an monetären Problemen, egal ob in der Firma oder privat.

----------

## Knieper

 *Anarcho wrote:*   

> Das stimmt, aber die Dienste innerhalb der VM können genauso gesichert werden wie von dir oben beschrieben. Auch in einer VM läuft der Apache nicht mit root rechten.

 

Das war nicht der Punkt. Du bettest Dein Programm in ein Layer (die VM), das weit mehr Rechte besitzt, die man ausnutzen kann.

Die naechsten Punkte hat Think4UrS11 schon beantwortet, soweit ich das ueberflogen habe...

 *Quote:*   

>  *Knieper wrote:*   4.) DOS-Angriffe aus Ressourcenmangel weit einfacher sind. 
> 
> Ja und Nein! Einmal sind natürlich mehr resourcen im Einsatz. ABER z.b. eine Applikation die in einer auf 256 MB RAM beschränkte VM läuft kann nun nicht mehr den ganzen RAM zumüllen sondern nur noch die 256 MB der VM.

 

Du sagst es selbst: Du brauchst mehr Ressourcen und eine Ressourcenbeschraenkung kann man auch ohne VM einrichten.

 *Quote:*   

> Aber bei einer VM kann man sehr viel einfach das Backup des Images einspielen und ohne den Server neustartetn zu müssen neu installieren.

 

Du willst damit aber nicht andeuten, dass das Hostsystem danach einfach so weiterlaeuft? Auweia...

 *Quote:*   

> Dazu kommt die Sicherheit das sollte bei einer Applikation mit Root-Rechten ein Sicherheitsproblem bestehen und jemand darüber ins System einsteigen kann er halt nur die eine VM kompormietiert hat. Das heisst natürlich nicht das er auch weitere Systeme befallen kann aber die Wahrscheinlichkeit sinkt.

 

Nix "Wahrscheinlichkeit sinkt". Die Wahrscheinlichkeit, dass er Zugriff auf das komplette System hat erhoeht sich, da er mehr Software angreifen kann.

 *Quote:*   

> Dazu kommt auch noch das es gutes Design ist pro Maschine nur eine Aufgabe zu haben. Also Router ist Router, Webserver eben nur Webserver usw.

 

Ja toll. Ich hoffe Du meinst jetzt nicht, dass "eine VM spielt lahmen Webserver und eine VM spielt lahmen Router" nur annaehernd etwas mit orthogonalem Design zu tun hat.

----------

## Anarcho

Dein theoretischer Ansatz mag vielleicht in einigen Punkten stimmen aber hat leider nicht viel mit der realität zu tun. Server konsolidierung per VM ist immer mehr im kommen und macht meiner Meinung nach durchaus Sinn.

In vielen Firmen wird pro Dienst eine eigene VM aufgesetzt, auch aus praktischen Gründen. Und ja, ich würde das Hostsystem weiterlaufen lassen denn ich gehe davon aus das nur die VM befallen ist. Wenn ich davon nicht ausgehen würde, dann würde es in der Tat wenig Sinn machen Dienste in VMs aufzuteilen.

Und zum Thema höhere Rechte durch VM: Wenn jemand einen root-exploit erfolgreich durchegführt hat ist es mir deutlich lieber er hat dies erstmal in ner VM gemacht und könnte dann weiter aufs Hostsystem wandern als wenn er direkt und ohne Umwege den ganzen Rechner befallen hat.

Für mich bieten VMs nachwievor eine erhöhte Sicherheit. Falls du aber natürlich alle Programme selber schreibst, den Sourcecode X-mal durchsehen lässt kann ich natürlich nicht helfen.

Und zum Thema zusätzliche Layer: Dann solltest du auch tunlichst nicht GRSecurity, RBAC, SE-Linux usw. einsetzen. Denn auch das sind wieder weitere Layer. Ebenso chroot. Irgendwo muss man hjalt die Grenze ziehen zu den Layer denen man vertraut. Und auch aus nem Chroot sind schon leute ausgebochen. Also lieber nicht einsetzen?

Bei aller Liebe zur Sicherheit - es muss auch praktikabel bleiben sonst könnten wir gleich den Netzwerkstecker ziehen um auf Nummer Sicher zu gehen.

----------

## Knieper

 *Anarcho wrote:*   

> hat leider nicht viel mit der realität zu tun

 

In der "Realitaet" sind auch die meisten Rechner und Server grottenschlecht konfiguriert. Wieso wohl? Weil den meisten "Admins" einfach das Wissen fehlt - genauso wie sich die meisten Programmierer nie mit Sicherheit auseinandersetzen. Das kann ich tagein tagaus beobachten, sogar bei IT-Spezialisten von Banken.

 *Quote:*   

> In vielen Firmen wird pro Dienst eine eigene VM aufgesetzt, auch aus praktischen Gründen.

 

Natuerlich. Einerseits weil der momentane Hype zum Verkauf von CPUs/RAM etc. fuehren soll, andererseits, weil unbedarfte BWLer in den Firmen an den Sicherheitsquatsch glauben. (Oder an das oben angesprochene Kinderbackup der VMs.)

 *Quote:*   

> Und ja, ich würde das Hostsystem weiterlaufen lassen denn ich gehe davon aus das nur die VM befallen ist.

 

Mit falschen Annahmen faengt es immer an...

 *Quote:*   

> Und zum Thema zusätzliche Layer: Dann solltest du auch tunlichst nicht GRSecurity, RBAC, SE-Linux usw. einsetzen. Denn auch das sind wieder weitere Layer. Ebenso chroot. Irgendwo muss man hjalt die Grenze ziehen zu den Layer denen man vertraut. Und auch aus nem Chroot sind schon leute ausgebochen. Also lieber nicht einsetzen?

 

Man muss die auch nicht unbedingt einsetzen, wenn man deren Funktionalitaet nicht braucht. Aus "chroot ausbrechen" ist eher trivial, da viele Systeme es ja explizit erlauben - es ist eher eine Design- denn eine Sicherheitsfrage.

 *Quote:*   

> Bei aller Liebe zur Sicherheit - es muss auch praktikabel bleiben sonst könnten wir gleich den Netzwerkstecker ziehen um auf Nummer Sicher zu gehen.

 

Nur was ist "praktikabel"? Fuer viele W*-IT-Trottel ist so gut wie nichts praktikabel, wenn man es nicht ueber ein skinnable Fenster mit drei Klicks erledigen kann. Fuer einen faehigen Admin/Programmierer der einen gewissen Anspruch hat und verantwortlich fuer eine Reihe von Unternehmen ist, sollte weit mehr "praktikabel" sein, als nur den Pseudoweisheiten der VM-Lobby zu vertrauen. Apropos "Stecker ziehen" - in manchen Firmen kann man das ruhig machen. Die Mitarbeiter konnten sich frueher schliesslich auch die Zeit in der Mittagspause vertreiben und die Angriffe aus zB. China treten zu gehaeuft auf, um nur aus "muss man heutzutage haben"-Motivationen heraus den Netzzugriff zu erlauben.

----------

## Anarcho

Gut, du hast nun alle meine Sicherheitsvorkehrungen ausgeschlossen. Dann erzähl doch bitte wie du deine Server absicherst? Stecker ziehen zählt natürlich nicht. ebenfalls darf es sich nur um einen Rechner handeln denn das war der Grundgedanke dieses Threads.

----------

## xraver

 *Anarcho wrote:*   

> Dann erzähl doch bitte wie du deine Server absicherst?

 

Ja, das würde mich auch interessieren. Mit VM´s kann ich mich auch nicht so richtig anfreunden das mein Server nicht über die Ressourcen verfügt um mehere VM´s zu betreiben.

Momentan laufen Dienste auf meinen Server eher ungeschützt. Und ich bin der Meinung das ein gut eingerichteter Server genauso "sicher" ist wie eine Maschiene die VM´s einsetzt. Und solange die laufenden Dienste keine Sicherheitslöcher aufweisen ist doch alles in Butter.

Sollte jemand über apache und Co einbrechen - dann ist es auch egal ob er nun gleich im Sys ist oder in einer VM gelandet ist.

Eingebrochen ist Eingebrochen und das System ist nicht mehr vertrauenswürdig.

Ich sehe den Vorteil von VMś eher in VServer. Aber jeden einzelnen Dienst in einer VM laufen lassen? - Nein danke.

----------

## misterjack

[OT]

 *xraver wrote:*   

> VM´s

 

Kannst du mir mal erzählen, warum du das Plural-s apostrophierst?

[/OT]

Bei mir auf dem Rootserver kommen VMs zum Einsatz, um die Dienste strikt zu trennen. Eine VM arbeitet zum Beispiel als Mailserver. Warum mach ich das? Weil ich mir mehrere Rootserver zur zeit nicht leisten kann und 2. der Root genug Ressourcen bietet. Im Zuge der Diskussion um Energie sparen ist es nur sinnvoll, mehrere VMs einzusetzen anstatt Energie zu verpulvern, indem der Server unnötig idlet.

Warum ich den Mailserver z.b. nicht mit auf dem Root selber installiert hab? Ganz einfach, einen Mailserver aufzusetzen ist nicht ganz trivial. So sicher ich einmal im Monat zu den normalen täglichen Datensicherungen die VM und wenn mir z.b. eine Platte kaputt geht, hab ich die VM wieder schnell oben, denn das Hostsystem ohne die später benötigten Dienste aufsetzen geht fixer. Auch finde ich die Trennung bedeutend besser. Z.b. ich zieh auf nen anderen Rootserver um, brauch ich nur die VMs zu transferieren anstatt wieder alles neu aufzusetzen.

Um mal die Diskussion ob VM oder nicht von der reinen sicherheitstechnischen Seite wegzurücken  :Smile: 

----------

## think4urs11

 *Anarcho wrote:*   

> Dann erzähl doch bitte wie du deine Server absicherst? Stecker ziehen zählt natürlich nicht. ebenfalls darf es sich nur um einen Rechner handeln denn das war der Grundgedanke dieses Threads.

 

Wie steht es doch so schön in meiner Signatur ... security is always a trade-off with usability.

Heißt nichts anderes als das man immer eine Balance zwischen 'sicher' und 'kann was alle wollen' finden muß.

Es ist mit Sicherheit unsicher(er) einen (PHP'ten)-Web/Mail/Proxy/Datenbankserver/P2P-Host/.. auf dem gleichen System zu betreiben - völlig wurscht ob nun in VM getrennt, via chroot voneinander abgeschottet, mit SELinux eingesperrt oder 'whatever' - als diese Funktionen jeweils eigenen physikalischen Maschinen zuzuordnen.

Sicherheit heißt ja auch 'möglichst unempfindlich gegen DoS' - warum soll mein Mailhost 'leiden' nur weil mein Webserver gerade wg. eines verwundbaren PHP-Scripts angegriffen wird und endlos load erzeugt? Auf mehreren getrennten Maschinen ist die Auswirkung deutlich geringer/nicht vorhanden (die Auslastung der Internetanbindung lassen wir mal aussen vor)

Wenn man nur begrenzt Hardware zur Verfügung hat muß man eben Kompromisse eingehen. Ein immer aktuell gepatchtes System ist sowieso absolute Grundvoraussetzung, genauso wie eine Systeminstallation die nur die Dienste nach außen anbietet die auch gebraucht werden.

Ansonsten 'das übliche', d.h. mehrschichtige Security

- Key/Zertifikat-basierte Authentisierung, möglichst nie user/pwd, never ever plaintext

- Logins von extern auf die User einschränken die es wirklich brauchen (sshd_config AllowUsers/AllowGroups); evtl. hier auch portknocking nutzen

- sauberes Firewalling für ein- wie ausgehenden Traffic ggf. basierend auf UID/PID (wozu muß ein httpd von sich aus nach außen connecten? richtig, gar nicht)

- z.B. im Squid dafür sorgen das der nur für interne Adressen arbeitet, d.h. saubere ACL's in den Apps die das anbieten

- tcpwrapper benutzen wo möglich/sinnvoll

- evtl. sogar alles hinter einem VPN 'verstecken'; geht natürlich nicht für einen (incoming)-Mailserver

- minimale Rechte für die einzelnen Prozesse

- System härten; SELinux/RSBAC/hardened kernel+toolchain, je nach Geschmack und Paranoiagrad (und Wissen, GAAANZ Wichtig - SELinux nützt sehr wenig wenn man keine Ahnung davon hat)

- regelmäßiges Scannen des Systems von außen auf Schwachstellen (nessus, nmap, etc.)

- regelmäßiges Aide/tripwire'n gegen ein Medium mit den gesicherten Prüfsummen

- Logging auf einen anderen Host, dann sind dort evtl. Spuren eines Einbruchs zu finden (wenn möglich via stunnel o.ä.)

.....

 *misterjack wrote:*   

> Im Zuge der Diskussion um Energie sparen ist es nur sinnvoll, mehrere VMs einzusetzen anstatt Energie zu verpulvern, indem der Server unnötig idlet.

 Korrekt, ist absolut sinnvoll, vor allem wenn man sich anschaut wie wenig manche Systeme zu tun haben.

 *misterjack wrote:*   

> Auch finde ich die Trennung bedeutend besser. Z.b. ich zieh auf nen anderen Rootserver um, brauch ich nur die VMs zu transferieren anstatt wieder alles neu aufzusetzen.

 Hmm, je nach System ist ein Restore der benötigten Konfigdateien aber evtl. sogar schneller erledigt.

----------

## Anarcho

 *Think4UrS11 wrote:*   

>  *Anarcho wrote:*   Dann erzähl doch bitte wie du deine Server absicherst? Stecker ziehen zählt natürlich nicht. ebenfalls darf es sich nur um einen Rechner handeln denn das war der Grundgedanke dieses Threads. 
> 
> Wie steht es doch so schön in meiner Signatur ... security is always a trade-off with usability.

 

Das kann ich in meiner Signatur nicht finden....Ist aber richtig.

 *Think4UrS11 wrote:*   

> Heißt nichts anderes als das man immer eine Balance zwischen 'sicher' und 'kann was alle wollen' finden muß.
> 
> Es ist mit Sicherheit unsicher(er) einen (PHP'ten)-Web/Mail/Proxy/Datenbankserver/P2P-Host/.. auf dem gleichen System zu betreiben - völlig wurscht ob nun in VM getrennt, via chroot voneinander abgeschottet, mit SELinux eingesperrt oder 'whatever' - als diese Funktionen jeweils eigenen physikalischen Maschinen zuzuordnen.
> 
> Sicherheit heißt ja auch 'möglichst unempfindlich gegen DoS' - warum soll mein Mailhost 'leiden' nur weil mein Webserver gerade wg. eines verwundbaren PHP-Scripts angegriffen wird und endlos load erzeugt? Auf mehreren getrennten Maschinen ist die Auswirkung deutlich geringer/nicht vorhanden (die Auslastung der Internetanbindung lassen wir mal aussen vor)
> ...

 

Das kann man auch alles zusätzlich einer VM machen. Vielleicht bin einfach zu Lernresistent aber ich sehe immer noch keine Vorteile eine VM wegzulassen (wenn die Hardware stimmt). Aber nach wie vor Vorteile mit VM.

Ansonsten kann ich mich misterjack anschliessen.

----------

## Knieper

 *Anarcho wrote:*   

> Das kann man auch alles zusätzlich einer VM machen. Vielleicht bin einfach zu Lernresistent aber ich sehe immer noch keine Vorteile eine VM wegzulassen (wenn die Hardware stimmt). Aber nach wie vor Vorteile mit VM.

 

Ein DoS-anfaelliges System mit weiterer Hintertuer ist also toll? Gut, vlt. habe ich da andere Vorstellungen.

Genauso mit:

 *misterjack wrote:*   

> Im Zuge der Diskussion um Energie sparen ist es nur sinnvoll, mehrere VMs einzusetzen anstatt Energie zu verpulvern, indem der Server unnötig idlet.

 

Ich hielt es fuer einen Witz und ihm wird beigepflichtet? Vorher: unausgelasteter Server. Nachher: Server mit denselben Diensten, aber endlich an der Leistungsgrenze durch die VMs? Wo bitte ist das oekonomisch? Das ist einfach nur doof.

----------

## Anarcho

 *Knieper wrote:*   

>  *Anarcho wrote:*   Das kann man auch alles zusätzlich einer VM machen. Vielleicht bin einfach zu Lernresistent aber ich sehe immer noch keine Vorteile eine VM wegzulassen (wenn die Hardware stimmt). Aber nach wie vor Vorteile mit VM. 
> 
> Ein DoS-anfaelliges System mit weiterer Hintertuer ist also toll? Gut, vlt. habe ich da andere Vorstellungen.

 

Sehe ich beides immer noch nicht.

 *Knieper wrote:*   

> Genauso mit:
> 
>  *misterjack wrote:*   Im Zuge der Diskussion um Energie sparen ist es nur sinnvoll, mehrere VMs einzusetzen anstatt Energie zu verpulvern, indem der Server unnötig idlet. 
> 
> Ich hielt es fuer einen Witz und ihm wird beigepflichtet? Vorher: unausgelasteter Server. Nachher: Server mit denselben Diensten, aber endlich an der Leistungsgrenze durch die VMs? Wo bitte ist das oekonomisch? Das ist einfach nur doof.

 

Das hast du sicher falsch verstanden. Was gemeint war: Entweder ich nutze 5 Server die sich die meiste Zeit langweilen oder einen etwas dickeren Server + Virtualisierung der deutlich besser ausgelastet ist.

----------

## Knieper

 *Anarcho wrote:*   

> Das hast du sicher falsch verstanden. Was gemeint war: Entweder ich nutze 5 Server die sich die meiste Zeit langweilen oder einen etwas dickeren Server + Virtualisierung der deutlich besser ausgelastet ist.

 

Dann kann man gleich einen weniger dicken Server nehmen, die VMs weglassen und die Dienste raufschieben. Er laeuft dann immer noch genauso schnell und ist dank geringerer Codebasis sicherer. Aber VMs sind z.Zt. eben schick...

----------

## Anarcho

 *Knieper wrote:*   

>  *Anarcho wrote:*   Das hast du sicher falsch verstanden. Was gemeint war: Entweder ich nutze 5 Server die sich die meiste Zeit langweilen oder einen etwas dickeren Server + Virtualisierung der deutlich besser ausgelastet ist. 
> 
> Dann kann man gleich einen weniger dicken Server nehmen, die VMs weglassen und die Dienste raufschieben. Er laeuft dann immer noch genauso schnell und ist dank geringerer Codebasis sicherer. Aber VMs sind z.Zt. eben schick...

 

Wir haben da eben 2 völlig verschiedene Meinungen. Wenn du diese 5 Rechner an 5 verschiedene Leute vermietest dann kannst du denen nicht erzählen das sie sich jetzt das OS mit 4 weiteren teilen müssen und alle Adminrechte haben sollen...

Die Zukunft wird zeigen ob sich VMs durchsetzen oder nicht.

----------

## Knieper

 *Anarcho wrote:*   

> Wir haben da eben 2 völlig verschiedene Meinungen. Wenn du diese 5 Rechner an 5 verschiedene Leute vermietest dann kannst du denen nicht erzählen das sie sich jetzt das OS mit 4 weiteren teilen müssen und alle Adminrechte haben sollen...

 

Du wirst denen aber auch schlecht erzaehlen koennen, dass sie jetzt den Rechner mit 4 anderen teilen koennen, dafuer aber ganz doll sicher ueber eine VM abgschottet sind. Sowas bekommt man nur an Kleintierzuechtervereine und Schueler vermietet.

 *Quote:*   

> Die Zukunft wird zeigen ob sich VMs durchsetzen oder nicht.

 

Das ist wie mit Windows oder BIND oder ...

----------

## misterjack

 *Knieper wrote:*   

> Nachher: Server mit denselben Diensten, aber endlich an der Leistungsgrenze durch die VMs?

 

Das hab ich nirgends geschrieben   :Rolling Eyes: 

----------

## Knieper

Aber  *misterjack wrote:*   

> mehrere VMs einzusetzen anstatt Energie zu verpulvern

  ist nicht besser. Da braucht man gar nicht drueber lachen, das lacht schon von selbst.

Aber wir kommen hier wohl nicht weiter. Ich bin eher der Minimalist, der gerne Ressourcen und unnoetigen Code spart, andere verpulvern sie lieber, sei es weil es Mode ist, Bequemlichkeit oder Aberglaube.

----------

## think4urs11

 *Knieper wrote:*   

>  *Anarcho wrote:*   Wir haben da eben 2 völlig verschiedene Meinungen. Wenn du diese 5 Rechner an 5 verschiedene Leute vermietest dann kannst du denen nicht erzählen das sie sich jetzt das OS mit 4 weiteren teilen müssen und alle Adminrechte haben sollen... 
> 
> Du wirst denen aber auch schlecht erzaehlen koennen, dass sie jetzt den Rechner mit 4 anderen teilen koennen, dafuer aber ganz doll sicher ueber eine VM abgschottet sind. Sowas bekommt man nur an Kleintierzuechtervereine und Schueler vermietet.

 

Hmm na gut dann arbeite ich also bei den Kleintierzüchtern. Wenn ich gerade den richtigen Stand habe dann existieren bei uns im RZ 4 dicke ESX-Hosts mit (geschätzt) 70-80 VM-Instanzen.

Diverse alte Anwendungen die noch gebraucht werden aber nicht zusammen auf einem System laufen können wg. unterschiedlicher Libs, Andwendung 'x' läuft halt nur auf W2K, ne andere braucht zwingend min. W2K3, etc., Test/Dev/Stagingsysteme kommen noch dazu, ... Generell 'Virtualisierung=Krampf' zu setzen ist schlicht zu kurz gedacht. Hat absolut seine Daseinsberechtigung. Vielleicht nicht im (high-)Securitybereich aber in vielen anderen.

OpenVZ-Networkingfrage nach Netzwerk mit OpenVZ ausgegliedert.

----------

## Knieper

 *Think4UrS11 wrote:*   

> Generell 'Virtualisierung=Krampf' zu setzen ist schlicht zu kurz gedacht. Hat absolut seine Daseinsberechtigung. Vielleicht nicht im (high-)Securitybereich aber in vielen anderen.

 

Momentan setzt nur jeder Popanz¹ VMs ein, ob er es braucht oder nicht, um es dann mit fadenscheinigen und falschen Sicherheitsargumenten zu untermauern. Dagegen habe ich etwas. Konnte sich frueher ein Hoster um seine paar angebotenen Dienste kuemmern, so laufen Netzseiten heute parallel in x VMs, alle angreifbar, alle mit unterschiedlichen Systemen mit potenziertem Risiko.

Wenn man auf Nostalgiesoftware angewiesen ist und keinen anderen Rechner opfern kann, einheitl. Testsysteme braucht etc. sind VMs prima, aber das habe ich auch nie abgestritten:

 *Knieper wrote:*   

> Virtualisierungen bringen eigentlich selten Vorteile (Testumgebungen, Kinderbackup etc.)

 

¹ Ein Beispiel ist unser Themenstarter. Mickrige Hardware, Hang zu loechriger Bloatsoftware und dann noch eine VM mit der er nun Probleme hat. Das haette auch anders gehen koennen.

----------

## trikolon

 *Quote:*   

> ..und dann noch eine VM mit der er nun Probleme hat

 

naja ganz so würde ich das nicht sagen nur weil ich mit einer virtualisierungslösung rumspiele und da im moment mit der netzwerkconfig kämpfe. das system ist unverändert bis auf den openvz-kernel... aber könnten wir dieses streitthema nun beenden? ihr habt doch nun beide eure meinung kund getan und eben keinen gemeinsamen nenner gefunden!

----------

