Hallo noch mal alle zusammen,
woran erkennt man den einen guten Hoster, der auf Sicherheit bedacht ist?
Lasst uns mal darüber diskutieren.
Gruß
Markus
Hallo noch mal alle zusammen,
woran erkennt man den einen guten Hoster, der auf Sicherheit bedacht ist?
Lasst uns mal darüber diskutieren.
Gruß
Markus
Aktuelle Datei des Sicherheitsleitfadens hier im ersten Post des Threads: [HIER]
Wenn man Anderen hilft, kann man selbst eine Menge lernen.
Hallo alle zusammen,
ich habe soeben die Datei aktualisiert. Hier ist Sie.
Ich brauche noch Hilfe in Richtung sichere FTP-Verbindung und guter Hoster.
Laßt und diskutieren!
Gruß
Markus
PS: Die aktuelle Datei findet sich auf Seite 3!!!
Geändert von Worti (18.11.2009 um 22:58 Uhr) Grund: Datei aktualisiert auf Seite 3
Aktuelle Datei des Sicherheitsleitfadens hier im ersten Post des Threads: [HIER]
Wenn man Anderen hilft, kann man selbst eine Menge lernen.
Die Idee ist ehrenwert.
Ich hatte allerdings in den Jahren, in denen ich Joomlas für meine Kunden hoste (vorher MOS), keinen einzigen Einbruch. Kunden, die tonnenweise Komponenten benutzen und keine Updates machen, gelegentlich schon.
Ich würde immer zuerst den Verstand, falls vorhanden, ansprechen.
Secure-FTP und FTPS
* PHP wird als CGI ausgeführtworan erkennt man den einen guten Hoster, der auf Sicherheit bedacht ist?
* hat eine kundenfreundliche Backupstrategie (bspw. tgl. Backups der Webs, Datenbanken, Mails + Langzeitbackups)
* jederzeit Backup und Restore im Kundenpanel auf Mausklicks zu erledigen
* Joomlaupdate im Kundenpanel auf Mausklick zu erledigen
Weiterhin diverse PHP-Einstellungen bzgl. register_globals, Safe_Mode, fopen, etc. Aber das ist immer in der Gesamtheit der Serverkonfig zu sehen und von außen für den Laien nicht zu erkennen. Sicherheit ist kein Programm/Software, sondern ein System.
Naja das halte ich für problematisch. Sobald der Kunde irgendwas drin hat an optionalen Dingen, soll er das lieber händisch machen, finde ich.
Alle anderen Sachen gibts zum Beispiel bei mir.##
Sobald PHP als cgi oder suphp läuft, ist Savemode, OpenBaseDir usw. eh quatsch. Wenn der Server prinzipiell gut gesichert ist, dann soll doch der Kunde machen was er will, dann darf er doch nur machen, was nobody auf dem Server darf. Da alle Sachen unter seinem User laufen, betriffts nur ihn.
Mal davon abgesehen ist suphp/cgi für PHP auch für Hoster einfach besser. Es lässt sich dann nämlich nach einem Einbruch sehr schön feststellen, wers gewesen war, da auch in gemeinsam genutzen Ordnern die Datei dann die entsprechenden Eigentümer-Infos hat.
Aber auch das ist Quatsch, denn ein gescheiter Hoster,der hat keine gemeinsam genutzen Ordner, wie /tmp, sondern da hat jeder User sein eignes ./tmp außerhalb der Web-Root und das sollte auch in den Variablen session save path, upload tmp dir usw entsprechend konfiguriert sein.
Außerdem hat die Fehlerausgabe auf der Webseite aus zu sein, dann sollte der Kunde aber auch die Möglichkeit haben, diese einzuschalten, oder ein Logfile einschalten zu können.
Also ein guter Hoster sollte in jedem Fall für jeden Kunden eigene Sicherheitsbereiche anlegen. Am technischen Support erkennt man gute Hoster wohl am besten. Wenn Sie Fragen freundlich & direkt beantworten. - Dann erhällt man einen Eindruck von ihrem System.
Gruß, reservoir Dog
Gibt der Klügere immer nach,herrscht die Diktatur der Dummen. - Wo Unrecht zu Recht wird,wird Widerstand zur Pflicht. - Doch: Das Einzige das einen davon abhalten kann die Wahrheit zu finden,ist zu denken man kenne sie bereits.
ERLEBE ABENTEUER e.V.
Meine Meinung:
-kein mod_php
-auf den 404 Seiten des Servers eine Admin-Email
-gesetzeskonformes Impressum
-Alle Dienste, auch Admin-Panel, Email (pop/imap), FTP mit Verschlüsselung
-Unterdrückung der Versionsnummern in http headern
-Einsatz eines einfach wartbaren OS (zum Beispiel Debian Linux)
-Vermeidung selbst kompilierter Komponenten, wie Apache usw., da solche Admins dann oft keine Updates machen
-Vermeidung schlecht designter Tools, wie Plesk
Das einfache Ändern der ID des Super-Admins von 62 in eine andere ganze Zahl (>62) direkt in der Datenbank (wie in Punkt 8, 2.Alternative beschrieben) mündet bei mir in einer Fehlermeldung, wenn ich das Backend via example.org/administrator aufrufen will.
Hallo alle zusammen,
bei mir ist im Moment Pause, weil
1. Kirmes und
2. eine Freundin von meiner Frau und mir zu Besuch ist.
Bis spätestens Donnerstag.
Gruß
Markus
Aktuelle Datei des Sicherheitsleitfadens hier im ersten Post des Threads: [HIER]
Wenn man Anderen hilft, kann man selbst eine Menge lernen.
hallo
gute Sache, finde ich!
Das Thema CHMOD gehört da noch rein...
Ordner 755, Dateien 644, Config, index im Templateordner 444 usw.....
Du suche Template? Klick me hard.
Von Vögeln und röhrenden Hirschen.
Lesezeichen