Quelltext schützen?!

Ja, das geht. Nenn mal ein Szenario, in dem dir der bestehende Schutz nicht ausreicht.

--

Es ist nur so ein Gedanke von mir...
So kann ich mir doch den Quelltext jeder einzelnen Seite ansehen, birgt das nicht Gefahren (Sicherheitslücken aufdecken, Seite kopieren)? Oder schätze ich diese, vielleicht nicht vorhandene Gefahr, zu hoch ein. Was genau meinst du mit bestehendem Schuzt? Den vorhandenen Aufbau der Seite oder gibt´s noch optionen die ich einstellen kann um den Schutz zu erhöhen?

Es ist nicht schlimm, das du den Quelltext jeder einzelnen Seite ansehen kannst. Schließlich ist es ja deine Seite. Oder hast du Angst, daß andere Benutzer den Quelltext sehen? Wenn dem so ist: welchen Quelltext meinst du?

• Den PHP-Quelltext (von Drupal)
• Den HTML-Quelltext (den Drupal erzeugt)

Drupal besteht zu einem großen Teil aus "Modulen". Vereinfacht gesagt sind das PHP-Dateien, die die Endung ".module" haben. Der Webserver weiß i.A. nicht, das es sich dabei um PHP-Dateien handelt. Wenn jemand also z.B. http://example.com/modules/node/node.module aufrufen würde, dann würde der Webserver die Datei einfach an den Benutzer senden. Das ist ein Sicherheitsrisiko, da der Benutzer diese Datei auf Schwachstellen untersuchen könnte.

Um das zu verhindern, liegt im Stammverzeichnis von Drupal eine Datei namens ".htaccess". Diese Datei bewirkt unter Anderem, das der Benutzer in oben beschriebenem Fall "403: Zugriff verweigert" bekommt.

--

.... vielleicht ist "Quelltext" das falsche Wort?! Ich meine jeder hat doch die Möglichkeit sich über "Ansicht - Seitenquelltext anzeigen (wohl der html-Text)" im Mozilla den Text anzusehen, kann da nicht wirklich jemand etwas mit anfangen?

Es gibt keine wirkliche Möglichkeiten den Quelltext auszublenden - nur ein paar Tricks, die aber nichts bringen. Du kannst ja jede Seite mit dem Browser auch speichern und damit kommt man immer an den Quelltext. Der Quellltext ist aber auch nicht 'gefährlich'. Auch auf Online-Banking Sites sieht man den Quelltext.

Gefährlich sind User-Eingaben. Die solltest du immer mit den entsprechenden Funktionen von Drupal 'behandeln'! (z.B. alle Texteingaben der Funktion check_plain() übergeben)

vg
--
md - DrupalCenter

mdwp* :: Drupal Services

Es gibt Möglichkeiten, den Zugriff darauf zu erschwehren. Allerdings kann solcher "Schutz" auf so triviale Weise ausgehebelt werden, das kaum jemand sich die Mühe macht. Lösungen basieren meistens auf Javascript, z.B. der ionCube HTML Encoder. Aber schon der DOM Inspector vom Firefox zeigt dir das erzeugte HTML an.

--

Dein Ziel sollte es sein deine Energien dahingehend einzusetzen, deine Systeme weitestgehend abzusichern und nicht Energie zu verschwenden, um Mängel zu verschleiern.

--
"Look, Ma, I'm dead!"
Cell, Stephen King

Daher sind solche Tipps wie: (z.B. alle Texteingaben der Funktion check_plain() übergeben)...
Sehr hilfreich!

Würde mich freuen wenn mir jemand noch einige Dinge nennen kann um die Sicherheit zu erhöhen.

Gruß, der Jenzen!!

Die Quelltext-Frage zielt auf die Sicherheit hin...

Was kann ich noch tun?

- Sicherheit der PHP-Skripete erhöhen
- vermeiden das fremder Code eingeschleust werden kann (Eingabeformat ändern?)

Reicht es aus immer die aktuellste Version von Drupal zu verwenden?
Was genau bedeutet diese Angabe in der Statusabfrage "Dateisystem Beschreibbar (öffentliche Download-Methode)"

Eigentlich möchte ich nur wissen was ich tun kann/muss und was mein managed-Server-Provider tun muss/kann, worauf ich da achten muss.

Vielen Dank für Eure Infos!

Gruß, der Jenzen!

Managed Server Leute machen meist gar nichts - zumindest nichts anderes als auf allen anderen Managed Servern. Oft gibt es Probleme, wenn man bestimmte Anpassungen der Konfiguration oder Installationen benötigt, diese vom Hoster auch durchgeführt zu bekommen. Es würde sich bei den Preisen einfach nicht rechnen seitens des Hosters noh groß manuell auf Kundenwunsch an den Systemen zu frickeln, außer der Kunde zahlt nach Aufwand zusätzlich.

Im Zweifelsfalle kann man sich nur einen externen Crack suchen, der was drauf hat und halbwegs humane Preise hat, oder man muss selber ein Crack werden. Es wäre eine schier endlose Liste hier diverse mehr oder weniger gängige Sicherheitsmaßnahmen für Unix-Root-Server aufzuzählen. Auch wenn der eine oder andere hier das Fachwissen haben mag, ist das auch nicht Drupal-spezifisch und gehört eher in eine Umgebung wie rootforum.de und howtoforge.com, wo dererlei Sachen alle Nase lang gefragt und mit Hinweis auf bestehende Threads beantwortet werden ;)

--
"Look, Ma, I'm dead!"
Cell, Stephen King

für deine Stellungnahme!!

Vielleicht kann ich meine Frage auf den Punkt bringen:
Was machen Leute die eine Seite betreiben die auf Drupal basiert und etwa 10.000/20.000 angemeldete User haben?? Gehen sie diesem "Problem" nach oder ist das System so ausgereift das man sich da keine Gedanken drum machen muss und der Admin des managed-Servers die Sicherheit gewährleistet?!

Möchte keinen Freibrief für Sicherheit, ich möchte nur wissen ob die Gedanken die ich mir evtl. mache sowieso erst bei extrem großen Webseiten angebracht sind?! Vielleicht in Größenordnungen in denen es dann sowieso um andere Summe geht?!

Würde mich über weitere Statements freuen!

Gruß, der Jenzen!!

Ich denke das kann man so allgemein nicht beantworten. Wenn man eine solche Community plant, zum Aufbau des Systems Geld in die Hand nimmt, mit dem Business Plan zur Bank läuft, etc., dann hat man sich zum Aufbau sicher einen Partner gesucht, der die Umsetzung macht und vertraut auf diesen. Ob einem Sicherheit in den Sinn kommt und in welchem Maße, hat dann wohl etwas damit zu tun wie sensitiv die jeweiligen Personen sind, die die Verantwortung tragen.

Eine gute Agentur sollte natürlich Wert auf Sicherheit legen. Niemand möchte sich später gerne den schwarzen Peter zuschieben lassen, wenn etwas schief gelaufen ist, auch wenn es im Einzelfall äußerst schwierig sein kann überhaupt computerforensisch zu ermitteln, wie ein System komprommitiert wurde.

Ich für meinen Teil administriere unsere Server selbst. Es sind Debian Systeme, auf denen ich beinahe täglich nach Updates schaue. AN Services läuft jeweils nur das Nötigste und die Firewall lässt auch nur Ports nach außen, die ich freigegeben habe, bzw. diese sind im Service wenn möglich gleih deaktiviert (MySQL). Bei der Konfiguration der Services wird ausreichend Literatur gewälzt (bzw. mittlerweile hat man seine Einstellungen soweit gefunden), gerade bei Webservern mit PHP gibt es ja diverse Möglichkeiten (apache oder lighthttpd, mod_php, suphp, suhosin, fastcgi, ...). Grundsätzlich setze ich noch ModSecurity ein, dessen Konfiguration im Entwicklungsprozess ggf. angepasst wird, wenn Probleme auftreten. Via fail2ban und eigens erstellte Regeln werden mir Probleme per Mail berichtet. Die Absicherung von SSH versteht sich von selbst (kein direktes Einloggen als root möglich, ggf. Verlegen des Ports), ebenso wie Monitoring des Systems, um Auffälligkeiten, Entwicklungen der Auslastung und evtl. Hardware-Probleme (HDD via SMART) beobachten und reagieren zu können. Der Einsatz von rkhunter und anderen Tools, um Kompromittierungen aufzudecken versteht sich ebenso von selbst wie ein nächtliches Backup auf einen externen Server.
Natürlich hat man sich auch bei der Wahl des Hosters so seine Gedanken gemacht.
Usw., usf.

Grundsätzlich muss man sich immer klar machen, dass es keine absolute Sicherheit gibt. Sicherheit ist immer realtiv und auch wenn man sich noch so viel Mühe gibt, gibt es immer jemanden der schlauer ist. Man hofft dann eben, dass der eigene Rechner / eine darauf laufende Site nicht interessant genug ist.

Ich kenne Root-Server, deren Distribution seit Jahren nicht mehr supportet wird und die entsprechend viele alte und bekannte Sicherheitslücken aufweisen und noch zudem direktes root-Login auf dem Standard-Port erlauben. Trotz aller Scans und Attacken, die tagein tagaus auf die Server einprasseln ist da noch nie etwas passiert. Auf dem Vorgänger dieses Servers dagegen wurde mal ne Sicherheitslücke im Apache benutzt um die Website zu hacken. Bei einem Kunden von uns hat der ehemalige Dienstleister mal das Problem gehabt eine veraltete Plesk-Version einzusetzen. Schwupps hackte sich einer rein und löschte alle Kunden. Dadurch stellte sich heraus, dass es um das angebliche tägliche Backup nicht gut bestellt war (es konnte nur noch ein Backup von vor einigen Monaten gefunden werden).

Nun, der Teufel ist ein Eichhörnchen und Shit happens. Man kann nur sein bestes tun und hoffen, dass der Worst Case nie eintritt. Als Kunde ist das wie überall im (Geschäfts-)Leben eine Sache des Vertrauens gegenüber dem Dienstleister. Man hofft darauf, dass man es nicht strapazieren muss aber wenn es dazu kommt, sollte der Dienstleister es rechtfertigen. Mehr kann man als Kunde kaum tun.

Gerade bei den Do-it-yourself-Codern ist das Wissen um Sicherheit bei der Entwicklung von Web-Software oft praktisch nicht vorhanden. Es beschweren sich heute noch Leute beim Umzug von Websites von irgendwelchen uralt Accounts, wenn auf einmal die REGISTER_GLOBALS = off ist und sie sich erstmal einlesen müssen, wie sie nun an ihre Variablen kommen....

--
"Look, Ma, I'm dead!"
Cell, Stephen King

kann mir bitte jemand sagen wie ich das einrichten/einstellen kann?
Danke,
mfg

Das kannst du nicht einrichten oder einstellen. Du kannst dich nur daran orientieren und den Rat bei der Entwicklung eigener / der Anpassung fremder Module berücksichtigen. Es handelt sich um eine Empfehlung von Drupal-Entwicklern an Drupal-Entwickler, aber es gibt keinen Verwendungszwang.

--
"Look, Ma, I'm dead!"
Cell, Stephen King

Den Thread will ich mal wieder ausgraben, denn ich frage mich grad auch, ob es ein Modul gibt, dass den HTML-Output von Drupal bspw von Leerzeichen und Zeilenumbrüchen zwischen den spitzen Klammern befreit.
Damit wird der Quellcode zwar nicht unlesbar, aber etwas erschwert (mal abgesehen von den Bytes, die man sich bei der Übermittlung an den Client spart.

MfG
Passer

Ehrlich gesagt erschließt sich mir der Sinn einer solchen Aktion nicht so ganz. Weder was die Bytes angeht die man 'spart' (das dürfte in der Summe der Bytes absolut vernachlässigbar sein) noch was 'unerwünschte Lesbarkeit' angeht. Was ist so schlimm wenn jemand den (statischen) html-Code lesen kann?

Die Seiten werden doch, soweit ich weiß, in den tpl-Dateien erzeugt. Da könnte man mit dem Löschen von Zeilenumbrüchen und Leerzeichen ja mal anfangen ;-)

Danke, dass man so leicht über den "$content" gewissen Änderungsfunktionen jagen kann, istg mir doch glatt entgangen ;)

Und was das ganze bringen soll?

Du benutzt sicher auch keinen JS oder CSS Aggregator, oder? ;)

Ein CSS / JS Aggregation hat primär die Aufgabe die Anzahl der notwendigen Requests an den Server zu senken und nicht Leerzeichen zu sparen. Gehörst du etwa auch zu den Leuten, die nicht kommentieren, weil das Platz kostet?

Optimierungen sind gut und schön, sollten sich aber auf Maßnahmen beschränken, die einen spürbaren Effekt haben, wie beispielsweise die serverseitige automatische Komprimierung von HTML, CSS und JS.

Mikooptimierungen wie von dir beabsichtigt sehe ich im Alltag eher als verschwendete Zeit an, die man andernorts für das Projekt besser investieren kann, schlichtweg weil Zeitaufwand und Nutzen in keinem annehmbaren Verhältnis stehen.

--
Drupal: Too much fun to be work.

webseiter.de

Vielleicht will ich auch einfach nur das Lesen des HTML Quelltextes erschweren...

Es geht um das wie und nicht das warum!

Bringt in Zeiten von Firebug, MS Developer Toolbar, Safari "Develop", ... rein gar nichts?
Von den 1001 Code Beautifiern mal ganz abgesehen.

Bester Tipp, wer seinen HTML Quellcode schützen will:
Seite offline nehmen. Wirkt garantiert, ganz ohne jedes Wenn und Aber.

--
Drupal: Too much fun to be work.

webseiter.de