RootForum Community

sledge0303 wrote: Ich geh mal von aus das du mich mit deinem Beitrag angesprochen hast:

Nein, warum auch?

Du hast vollkommen Recht chroots haben ihre Berechtigung. Das unterschreibe ich doch sofort! Mailserver, Apache und MySQL gehören je in ihre eigene, sofern sie nicht ohnehin auf verschiedener Hardware sind. Wenn du Webspace hostest macht es vielleicht auch Sinn denen jeweils ihren eigenen cage zu geben.

Ich kann aber sehr gut nachfühlen, was es heißt, wenn da eine Betriebsleitung ist(natürlich BWL studiert), bei der Du Wetten abschliessen kannst, wann Sie den falschen Button trifft(FW mit Erlaubnis) und darauf besteht, daß Sie auch ihre Viren auf ihren Rechner ausführen darf aber dann keine Rechnung zwecks Entfernung dieser zahlen will. So und dann höre ich XY schief von der Seite: "hättste doch für jeden ein Jail angelegt" während $admin gerade die Nächte im Severraum verbringt und Platten putzt, dessen Kunden drohen abzuspringen, wenn nicht sofort die Mails wieder gehen oder vorrechnen, welche Kosten gerade entstehen.

aubergine wrote:

sledge0303 wrote: Ich geh mal von aus das du mich mit deinem Beitrag angesprochen hast:

Nein, warum auch?

Erstmal fettes Sorry an dich. Hatte gestern eine Begegnung im ICQ der "netten" Art und Weise gehabt und dachte zuerst das wärst du gewesen wegen der Wortwahl...Nochmals Entschuldigung für meine rüde Art!
Hatte schon sehr oft Leuten mit wenig Ahnung oder speziellen Fragen weiter geholfen im ICQ, gestern wurden aber neben meine Person ziemlich alle Admins/Moderatoren und Mitglieder im AC aufgrund mancher Aussagen gegenüber unbeholfenen gestellter OP Anfragen der letzten Zeit übelst beleidigt. Naja, ICQ "Support" gehört nun der Vergangenheit an...

@lucki2

Jep, es macht wirklich Sinn jedem seinen eigenen Cage zu geben. Kommt auch immer drauf an wie viele User man auf der Kiste hat. Da hat Pennywize ebenfalls meine Zustimmung. Besonders die Aussage mit dem Fort Knox würde ich blind unterschreiben.
Bei mir sind erstmal noch Web- Mail und Datenbanken auf einer Hardware drauf. Demnächst wird mein Angebot noch erweitert und denke auch darüber nach noch einen zusätzlichen Server zu bestellen oder gar noch einen zusätzlichen.
Ein Vserver als Backupserver steht schon bereit, neuer Root für Kunden und ein anderer Vserver könnte den Mailserverdienst ggf sogar MySQL mit übernehmen... Performance muss aber vorher getestet werden zum wohle des Kunden ;)

melde mich jetzt auch nochmal zu wort..

habe meinen server jetzt neu aufgesetzt. habe versucht, es diesmal besser zu machen..

neues system:
- suse10
- plesk8.0.1
- php4.4
- mod_security
- globals off
- fopen auch off

und clamav wird auch alle 3 tage mal komplett drüber gejagt..

phpinfo ist zur zeit einsehbar unter: http://briefbox.org/index.php

habt ihr noch weitere anregungen, ideen?

und eine frage hab ich noch:
der watchdog von plesk erzählt mir folgendes, woraus ich nicht so wirklich ganz schlau werde..
das soll doch nur bedeuten, dass es momentan prinzipiell möglich ist, sich als root einzuloggen (wenn man das 27stellige passwort weiß ;) ), oder?

grüße,
johannes..

version 4.4.0 is wohl out of date....würde mal auf 4.4.4 updaten, schon wegen den bugs und Sicherheitslücken.

kostakimu wrote: [...]
Checking for allowed root login... Watch out. Root login possible. Possible risk!
[...]
das soll doch nur bedeuten, dass es momentan prinzipiell möglich ist, sich als root einzuloggen (wenn man das 27stellige passwort weiß ;) ), oder?
[...]

Jep das wird's wohl heissen. Wobei es schon seinen Grund hat, warum das erwähnt wird. Würde ich jedenfalls deaktivieren. Und dann mittels User per PubKey einloggen und zu root switchen.

static

blnsnoopy26 wrote:version 4.4.0 is wohl out of date....würde mal auf 4.4.4 updaten, schon wegen den bugs und Sicherheitslücken.

Du hast das mit den Backports immer noch nicht verstanden, oder?

Roger Wilco wrote:

blnsnoopy26 wrote:version 4.4.0 is wohl out of date....würde mal auf 4.4.4 updaten, schon wegen den bugs und Sicherheitslücken.

Du hast das mit den Backports immer noch nicht verstanden, oder?

Was willste mir damit sagen hmm?

blnsnoopy26 wrote:Was willste mir damit sagen hmm?

Dass dein Beitrag "PHP X.X ist veraltet, nimm PHP Y.Y" in diesem Kontext nicht sinnvoll ist.

Sicherheitspatches werden von den Distributoren für die in der jeweiligen Distribution angebotenen Pakete zurückportiert...

@kostakimu:

Du könntest noch ein hostbasiertes IDS (wie z. B. tripwire) installieren, einen Kernel mit Grsecurity und PaX oder RSBAC-Unterstützung selber bauen. Zusätzlich solltest Du bestimmte Funktionen wie exec o. ä. in PHP verbieten.

Das wichtigste ist jetzt aber, regelmäßig Dein System auf den neuesten Stand zu bringen - und zwar nicht nur per Yast, sondern auch installierte PHP-Skripts ect.

Roger Wilco wrote:

blnsnoopy26 wrote:Was willste mir damit sagen hmm?

Dass dein Beitrag "PHP X.X ist veraltet, nimm PHP Y.Y" in diesem Kontext nicht sinnvoll ist.

Sicherheitspatches werden von den Distributoren für die in der jeweiligen Distribution angebotenen Pakete zurückportiert...

Wenn du veraltete software bei dir drauf hast ist ja dein ding, nur ich empfehle immer auf das neuste upzudaten, da kann ich ruhiger schlafen.

blnsnoopy26 wrote:Wenn du veraltete software bei dir drauf hast ist ja dein ding, nur ich empfehle immer auf das neuste upzudaten, da kann ich ruhiger schlafen.

Dann hättest Du konsequenterweise 5.1.6 statt 4.4.4 empfehlen müssen ;)

Ernsthaft: Die 4.4.0 ist sicherheitstechnisch auf dem Stand von 4.4.4, lediglich die seit 4.4.0 neu hinzugekommenen Features fehlen...

blnsnoopy26 wrote:Wenn du veraltete software bei dir drauf hast ist ja dein ding, nur ich empfehle immer auf das neuste upzudaten, da kann ich ruhiger schlafen.

Definiere veraltet. Ich würde ein "altes" PHP 4.4.0 oder gar 4.3.10 gepflegt mit den Patches von Debian, Ubuntu, RedHat oder SuSE jederzeit einem Vanilla PHP 4.4.4 vorziehen.
Wenn du mit der neuesten Version ruhig schlafen kannst, ist das schön für dich. Nur sinnvoll ist es meiner Meinung nach nicht.

danke.

tripwire seh ich mir mal an.

im prinzip würde ich den shell-login ganz unterbieten. denn bei strato habe ich die remote-console und die funktioniert sehr gut. wie mache ich das am besten, ohne mir den login ganz zu sperren?

Sofern der Zugriff via serieller Konsole problemlos klappt (ausprobieren!), kannst du den sshd einfach abschalten.