# Frage zu einem HowTo bzw. zur Konfiguration eines Debian Servers



## M. Zink (18. Juni 2009)

Hallo,

wie ich gesehen habe kann ich ISPC 3 nicht ohne weiteres auf einem Server installieren auf dem schon ISPC 2 läuft und ein Import usw. ist nicht möglich. Ist auch so gesehen egal da mein Webserver nun fast 3 Jahre alt ist und ich deshalb gerne einen neuen hätte, alleine schon weil die Festplatten auch so alt sind und ich keine Lust habe das mir ein Ausfall droht zu einem Zeitpunkt wo ich eigentlich keine Zeit hab.

Wie dem auch sei, den Server habe ich nach dem HowTo von hier aufgesetzt mit Debian Edge 4.0 und ISPC 2 und bin auch zu 99% zufrieden damit. Es funktioniert alles was soll und ich kommt gut zurecht. Allerdings einen kleinen Punkt gibt es den ich gerne anders hätte. Und zwar bei meinem jetzigen Server hat jeder Web User seinen eigenen User und seine Usergroup. Der Apache läuft aber dennoch unter www-run und das sorgt bei mir für ein paar Probleme. Wenn ich z.B. eine Webseite per FTP auf den Server lade dann klappt alles gut bis zu dem Zeitpunkt wo der Server selbst eine Datei anlegt. Ich habe ein Web Formular mit welchem ich ein Bild auf den Server lade. Das Bild wird danach mittels PHP in der Größe verändert und in 3 Dateien abgelegt. Die Dateien gehören daraufhin dem User www-run und spätestens bei safe_mode ist das Drama komplett. Auch wenn ich via FTP die Dateien löschen möchte geht das nicht.

Was muss man also bei dem HowTo für Debian 5.0 Lenny beachten, damit der Apache für jeden Web User auch unter dem entsprechenden ftp User läuft? Machbar ist das wohl aber wie weiß ich nicht.


----------



## fuxifux (18. Juni 2009)

Schau dir doch mal dieses Howto an:

suPHP 

Damit wird PHP mit den Rechten des jeweiligen WebUsers ausgeführt.
(Apache nutzt weiter www-run, aber der legt auch keine neuen Dateien an..)


----------



## Till (18. Juni 2009)

Du musst garnichts weiter beachten, wenn Du ISPConfig 3 nimmst. ISPConfig 3 hat suphp immer mit dabei genauso wie fcgi mit suexec, also einfach nur auf suphp oder php-fcgi + suexec in den Webseiteneinstellungen auswählen. Das obige Howto also bitte nur bei ISPConfig 2 anwenden aber nicht bei iSPConfig 3.


----------



## M. Zink (18. Juni 2009)

Nur um sicher zu sein, dass ich nichts falsch verstanden habe.

Bei Neuinstallation eines Server mit Debian Lenny und ISPC 3 muss ich NUR das HowTo durch arbeiten und alles ist schön.

Bei meinem bestehenden Server mit Debian Edge und ISPC 2 müsste ich das genannte HowTo für suPHP durcharbeiten, was aber hinfällig ist, da ich ja einen neuen Server möchte.

Richtig oder?


----------



## Till (18. Juni 2009)

Zitat von M. Zink:


> Bei Neuinstallation eines Server mit Debian Lenny und ISPC 3 muss ich NUR das HowTo durch arbeiten und alles ist schön.


Ja, und zwar diesem:

http://www.howtoforge.com/perfect-server-debian-lenny-ispconfig3



> Bei meinem bestehenden Server mit Debian Edge und ISPC 2 müsste ich das genannte HowTo für suPHP durcharbeiten, was aber hinfällig ist, da ich ja einen neuen Server möchte.


ja.


----------



## M. Zink (18. Juni 2009)

Das HowTo hab ich nun auf einem Testrechner lokal bei mir im Büro grade mal durch gearbeitet. Es funktioniert auch super und ISPC 3 gefällt mir gut. Bekomme am Ende lediglich von ClamAV irgend ne Meldung das meine Programmversion zu alt ist oder sowas aber damit wollte ich mich nicht beschäftigen.

Was ich in dem HowTo ein klein wenig vermisse sind Erklärungen in Bezug auf die installierten Zusätze. Ab Punkt 9 geht es so gesehen damit los. Apache ist mir klar und MySQL und so auch aber was sind das teilweise für Besonderheiten die installiert werden? Damit mir nicht einfach das ganze HowTo erklären muss hier mal die Dinge die installiert werden und welche ich nicht zuordnen kann.

Saslauthd, rkhunter, binutils, FCGI, suExec, Pear, mcrypt, Vlogger, Jailkit, fail2ban


----------



## feelx (18. Juni 2009)

Hellau!

Eins nach dem anderen 

Wegen dem "abgelaufenen" Clamav... da musst du die Debian Volatile Repositories installieren (d.h. in die apt-sources) eintragen. Quasi die letzten beiden Zeilen wie -hier- beschrieben, nach einem "update" und "upgrade" sollte der Fehler weg sein (steht aber auch da)

Wegen den Paketen - alle kann ich dir nmed erklären... aber ich fang mal kurz (und oberflächlich) an.. sonst musst du googeln... da findest genug:
- rkhunter = ein rootkit "jäger"
- pear = eine PHP Erweiterung (Bibliothek)
- mcrypt = Verschlüsselungsprogramm
- vlogger = ein Tool für virtualisierte Hosts in Apache. Teilt die Logs auf 
- jailkit = um User mit Shell-Access in deren "Home" einzusprerren / Jail=Gefängnis
- fail2ban = Sicherheitstool, welches logfiles überwacht. Z.B. nach 3x falscher User/Passworteingabe wird eine "Regel" in die Firewall geschrieben (iptables), welche die IP für xx Minuten sperrt

PS: Kennst du _apt-cache show rkhunter_ bzw. _apt-cache show rkhunter_ - Teilweise noch recht hilfreich (alles findest du allerdings nicht)


----------



## M. Zink (19. Juni 2009)

Hallo!

vielen Dank für die Erklärung.

Heißt das nun ich brauch mir in Sachen Sicherheit keine bis kaum Gedanken machen wenn ich mich genau an dieses HowTo halte? Ein AV ist drauf, die Logs werden überwacht, die SH User sind eingesperrt usw. und das klingt für mich fast so als wäre das Thema Sicherheit auch komplett abgehandelt oder?

Ich frage deshalb weil ich bei meinem Anbieter bis jetzt immer 2 Stunden "Remote Hands" gebucht habe der mir den Server auf Sicherheit prüfen sollte und alles machen sollte um ihn so sicher wie möglich zu machen. Vor einigen Jahren noch wo ich in den "Kinderschuhen" steckte was Linux Server betrifft ist es mir passiert, dass mein Server geknackt wurde und mit meinem Server dann Angriffe auf zig andere Server gestartet wurden. Das möchte ich nicht noch mal erleben weil man dadurch über Nacht 5000 neue Feinde hat die einem alle ans Leder wollen.

Bezüglich der Einrichtung denke ich werde ich in ca. einer Woche noch mal nervös hier posten wenn ich merke, dass auf dem neuen Server doch alles nicht so laufen möchte wie ich gehofft habe.

P.S.: Der neue Server wird ein Core i7 920 sein mit 12 GB Ram. Gibts irgendwas zu beachten bei dem HowTo um die Leistung optimal zu nutzen außer dem Gesichtspunkt das ich 64 Bit nutzen sollte?


----------



## Till (19. Juni 2009)

Also um die Sicherheit muss man sich immer sorgen, es gibt einfach kein Setup das per Default 100% Sicher ist und vor allem auch sicher bleibt. Das wichtigste ist adss Du Dein System immer aktuell hältst, also dass Du alle Sicherheitsupdates der Von Dir verwendeten Linuxdistribution regelmäßig einspielst und auch bei Webseiten darauf achtest, dass z.B. Sicherheitslücken in CMS Systemen wie Joomla etc. geschlossen werden.

Zum Thema Lesitung gibt es nichts weiter zu beachten, nimm einfach einen 64Bit Kernel. Dann kann man immer noch später was an der leistung des apache und bei mysql tunen, das ist aber eine Geschichte für sich und da gibt es auch eine Reihe Anleitungen dazu im Internet.


----------



## M. Zink (22. Juni 2009)

Gut, dass man das Thema Sicherheit nur dadurch das man ein HowTo zur Installation benutzt nicht außer Acht lassen kann ist klar und verständlich. Mir ging es aber mehr darum, dass man auf verschiedenen Seiten zum Thema Linux auch die verschiedensten Tips ließt um einen Server sicher zu machen. Die einen sagen IPTables mit richtiger Konfig ist absolut ausreichend und andere sagen IPTables sollte man gar nicht erst nutzen und besser was richtiges einsetzen.

Gibt es denn irgendwelche Möglichkeiten um z.B. die Updates von Debian automatisch ein mal am Tag prüfen und installieren zu lassen? Normal mache ich das immer ganz nachdem wie ich dazu komme mit apt-get update und apt-get upgrade. Oder kann ich die beiden Befehle auch per Cronjob laufen lassen? Oder spricht da was dagegen?


----------



## Till (22. Juni 2009)

Du kannst updates automatisch einspielen:

http://www.debianadmin.com/automatic-update-of-packages-using-cron-apt.html

wäre ich aber sehr vorsichtig damit, da es  natürlich auh theoretisch immer sein kann, das ein automatisch eingespieltes Update zu einem Fehler führt und dann der Server offline ist, bis Du es bemerkst und das Problem reparierst.

Zu iptables. Eine iptables Firewall ist auf einem Server kann nie genug sein, da sie ja nur auf der IP Ebene filtern kann und somit nicht gegen Exploits oder Probleme in website Scripten schützt. Generell solltest Du auf Deinem Server nur die Dienste gestartet haben, die Du auch nutzt. Also macht eine Firewall nicht so viel Sinn, wenn sowieso nur Dienste laufen die Du brauchst, gibt es auch nichts weiter zu blocken. IPTables wird dann wieder interessat wenn Du z.B. fail2ban einsetzt wie es bei ISPConfig der Fall ist, da hier aktiv Loginversuche untersucht werden und somit Brute Force Attacken abgefangen werden können.


----------



## M. Zink (22. Juni 2009)

Ich hab es selbst schon mal erlebt, dass ein unsauberes PHP Skript dafür sorgte, dass jemand vollen Zugriff auf einen Server bekommen hat. Wenn ich nun an ISPC3 / Debian Lenny / suPHP denke, bin ich da dann ehr auf der sicheren Seite was sowas betrifft, da der Eindringlich so oder so nur bis zu dem Punkt kommt wo der aktuelle Webuser zugriff hat oder besteht selbst da noch die Gefahr das der User vollen Zugriff bekommt?

Macht es denn Sinn einen Root Server mit OpenVZ auszustatten und im eigentlichen Hostsystem gar nichts laufen zuhaben außer OpenVZ selbst und dann in den virtuellen Systemen die ganzen Dinge wie Apache usw? Oder macht man sowas eigentlich nicht?


----------



## Till (22. Juni 2009)

> Ich hab es selbst schon mal erlebt, dass ein unsauberes PHP Skript dafür sorgte, dass jemand vollen Zugriff auf einen Server bekommen hat. Wenn ich nun an ISPC3 / Debian Lenny / suPHP denke, bin ich da dann ehr auf der sicheren Seite was sowas betrifft, da der Eindringlich so oder so nur bis zu dem Punkt kommt wo der aktuelle Webuser zugriff hat oder besteht selbst da noch die Gefahr das der User vollen Zugriff bekommt?


Es ist auf jeden Fall schonmal sicherer und um noch sicherer zu sein kannst Du bei suphp auch noch eine separate php.ini pro Website angeben in der Du Funktionen wie exec, passthru etc. deaktivieren kannst.



> Macht es denn Sinn einen Root Server mit OpenVZ auszustatten und im eigentlichen Hostsystem gar nichts laufen zuhaben außer OpenVZ selbst und dann in den virtuellen Systemen die ganzen Dinge wie Apache usw? Oder macht man sowas eigentlich nicht?


Macht nur teilweise Sinn. Es ist dann sinnvoll wenn Du den mail vom webserver Teil trennen willst, aber ein hack auf dem webserver würde natürlich auch noch andere Webs in Mitleidenschaft ziehen, daher also möglichst php und cgi Sachen entsprechend absichern und immer nur die Rechte un Features aktivieren, die auch wirklich gebraucht werden.


----------



## M. Zink (22. Juni 2009)

Muss ich denn bei dem Debian Lenny HowTo irgendwas beachten wenn ich den Server aufsetze? oder kann ich einfach das HowTo durch arbeiten und nachträglich dann eine php.ini pro Webuser angeben irgendwo? Das mit dem suPHP kann ja so wie ich gelesen hab direkt in ISPC angegeben werden. Gibts dazu dann weitere Konfigurationen?

Edit:
Zum Thema OpenVZ ist mir noch was eingefallen. Zumindest denke ich das es so ist. Wenn ich jetzt auf dem Server selbst ein Grundsystem installiere und dann den eigentlichen Webserver mit Apache und allem was dazu gehört dann habe ich doch quasie einen Container in dem der virtuelle Server läuft. Und wenn ich dann mal den Webserver tausche muss ich dann nicht lediglich wieder ein minimales System installieren, OpenVZ installieren und den Container kopieren und alles ist schön? Außerdem erhalte ich durch virtualisierung doch auch die Möglichkeit bei einem Versionswechsel einfach eine neue virtuelle Maschine zu erzeugen, das neue System installieren und dann von einem virtuellen Server zum anderen die Daten portieren und fertig oder? Denn im Moment hab ich ja das Problem, dass ich zwingend einen neuen Server nehmen muss weil ich Debian Lenny und ISPC 3 nicht installieren kann ohne den alten Server platt zu machen. Bei Virtualisierung stellt sowas doch kein Problem mehr dar oder?

Oder kann man sagen bei virtuellen Servern habe ich leistungsverluste und andere Nachteile die rechtfertigen, sowas bei einem Webserver nicht zu machen?


----------

