Jump to content
InvisionCommunity.de - Der Deutsche Invision Community Support
Sign in to follow this  
Chrisso

conf_global "umbennen"

Recommended Posts

Hallo,

hier haben wir ja über die Einbruchsicherheit des Forums diskutiert und ich bin nun zu dem Entschluss gekommen, die von Blackman angesprochene Methode zu testen: die conf_global umzubennen.

Nur wie stell ich das an? Ich hab schon die Daten des Forums auf conf_global durchsucht (gut mit der Windows Suche...) und hab abgesehen von ein paar HTMLs nichts gefunden.

Hat jemand eine Idee die Einträge alle aufzuspüren?

Share this post


Link to post

Sorry, aber meiner Meinung würde ich das lieber per .htaccess schützen, da ich die conf_global nicht einfach so umbenennen würde, weil einfach zu viele Funktionen, Mods etc. auf genau diese Datei bzw. dessen Daten zurück greifen müssen, und es mit sicherheit einen riesen Rattenschwanz hinter sich herziehen würde, wenn Du diese Datei ändern würdest. Ich halte es also für vollkommen unnötig ;)

Erstelle Dir doch einfach ne .htaccess Datei, und schütze somit Deine conf_global.php, sollte doch eigentlich kein Problem sein, und Du kannst die lokal erstellte .htaccess Datei ja per FTP Client auf Deinem Server ablegen.

Wenn Du das tun möchtest, hier mal die Zeilen:

AuthType Basic

AuthName "Restricted File"

AuthUserFile /pfad/.htpasswd

<Files conf_global.php>

require user ABC

</Files>

Bei "AuthUserFile /pfad/.htpasswd" musst Du natürlich anstelle von /pfad Deinen Pfad angeben, den solltest Du ja schon einmal eingetragen haben in der conf_global.php. Natürlich solltest Du das ganze 2 mal machen, und auch die conf_global-bak.php Datei sichern :D

So jedenfalls sollte das Funktionieren ;)

Share this post


Link to post

Besten Dank, damit kann ich doch schon mal was anfangen!

Ich hab leider keine Ahnung von .htaccess - einfach so eine Datei anlegen und mit dem og. Inhalt füllen?

Was meint require user? Hier den FTP User eintragen, den ich selbst benutze?

Würde also so funktionieren und verhindert ein "Aussaugen" durch PHP Skript?

Share this post


Link to post

einfach so eine Datei anlegen und mit dem og. Inhalt füllen?

Jo, einfach mit einem Texteditor erstellen ;)

Was meint require user? Hier den FTP User eintragen, den ich selbst benutze?

Davon hatte ich doch gar nichts geschrieben, oder ? :D

Also, kannst Du so lassen wie es ist, kannst natürlich auch statt ABC z.B. Maschendrahtzaun eintragen :D

Würde also so funktionieren und verhindert ein "Aussaugen" durch PHP Skript?

Mehr oder weniger kann man eh nicht die PhP Datei Aussaugen, die einzigste Gefahr die man generell mal haben könnte, wenn mal der php Parser Ausfallen würde, und wenn Du diese .htaccess Datei anlegst, so kommt immer eine Passwortaufforderung, wenn man versucht die Datei per Browser aufzurufen.

Wie gesagt, das einzigste was Du anpassen musst, ist der direkte Pfad zu Deinem Webserver.

Share this post


Link to post

OK, soweit klar, verstehe ich das richtig, dass durch

AuthUserFile /pfad/.htpasswd

und

require user ABC

das Ding dann einfach ins Leere läuft, weil weder User ABC, noch die htpass erstellt wurden?

Share this post


Link to post

Auf jeden fall solltest Du da eben den Absoluten Pfad eintragen, also hier

AuthUserFile /absoluterPfadzudeinemBoard/.htpasswd

Natürlich dann auch nicht vergessen, die .htpasswd Datei auf den Server zu laden ;)

Mach das doch einfach mal, und versuch die Datei in Deinem Browser aufzurufen, den Rest siehst Du doch dann :D

Share this post


Link to post

Andy, ich mag mich irren, aber ihm geht es darum, das ein php-Script, welches auf SEINEM SERVER liegt, die conf_global.php nicht auslesen soll.

Da nützt ihm htaccess aber garnichts, weil nicht der apache drauf zugreift, sondern der php Interpreter ...

Oder seh ich das jetzt komplett falsch ? Wohl kaum ...

BLACK

Share this post


Link to post

Genau das ist der Punkt... :huh:

Schützt htaccess da jetzt oder nicht? Ich hab gestern noch ne Stunde gegooglet, aber nichts konkretes finden können...

Share this post


Link to post

Naja, du versuchst auch deinen Webspace vor deiner eigenen Person abzusichern und das ist in meinen Augen recht unlogisch. ;)

Einzige Lösung, die mir auch einfällt, ist die open_basedir Option.

Share this post


Link to post

Wer den anderen Thread grob verfolgt hat, weiss, dass es sich hier um eine Art Versuch oder kontrollierten Hack handelt.

Ein Moderator unseres Teams hat Zugriff auf den modules Ordner, weil er eine selbst erstellte Galerie pflegt.

Es geht darum, dass er behauptet durch diesen FTP Zugriff ein PHP Skritp hochladen zu können, welches das SQL Passwort aus der conf_global ausliest, um zB. Adminrechte neu zu verteilen und so ins Board einzubrechen.

Ich will dagegen halten.

Share this post


Link to post

Aber mal ganz ehrlich: Wem du FTP Zugang gibst (auch zu anderen Verzeichnissen auf dem Server) da solltest du schon soviel vertrauen haben das der jenige nicht versucht auf deine Daten zuzugreifen ;)

Share this post


Link to post

@stefan ...

Er hat keinen Zugriff auf die Konfiguration, deswegen kein open_basedir !

Und deswegen hab ich gemeint, wenn die conf_global umbenannt ist, kann man sie nicht mehr einfach auslesen, da man den neuen Dateinamen braucht !

Natürlich ist es eine futzelei alle dateien so umzustellen, das die conf_global anders heißt, aber zumindest beim ipb 2.0 waren das nur so um die 8 stück, bild ich mir ein !

Und wenn derjenige keinen zugriff auf die Forendateiien hat, sondern nur auf einen unterordner, kann er den echten namen auch ned herausfinden !

Oder seh ich da was falsch ?

BLACK

Share this post


Link to post

Also wenn ich das richtig verstehe, ist diese besagte Galerie ein Modul für das Forum?

Wenn das der Fall ist, braucht man sich keine Gedanken mehr darüber machen, wie man die conf_global.php umbenennt, denn man hat immer Zugriff auf die Daten über die Klasseninstanz $ibforums. ;)

Dann müßte man schon so sensible Daten direkt nach der Datenbankverbindung innerhalb der index.php entfernen, damit die Module das Passwort nicht auslesen können.

Aber mal ehrlich, wenn ich jemanden nicht hundertprozentig vertraue, dann geb ich ihm auch keinen Zugriff auf den Webspace, aber das ist nur meine Meinung. :)

Share this post


Link to post

Das ist ja auch alles richtig, was du sagst Stefan, und der User hat das volle Vertrauen. Es geht eben darum, dass ich mir nicht einfach auf der Nase rumtanzen lassen kann ;) deswegen der kontrollierte Einbruchversuch, um ihm zu zeigen, dass er nicht einfach machen kann, was er will, wenn er will.

Blackman hat das soweit durchschaut, das Modul (Galerie) ist für das Forum, genau. Der User hat FTP Zugriff auf /html/ivb/galerie <- und nur auf Galerie.

Die Galerie dient zum Upload von Bildern, erstellt automatisch einen Ordner mit dem Usernamen, läuft alles voll automatisch. Inwiefern auf einzelne Tabellen der DB zugegriffen wird, kann ich nicht 100%ig beantworten.

Wer sich das mal ansehen möchte, kann gern mal hier klicken.

Share this post


Link to post

Also wie gesagt, als Modul fürs Forum hat dieses auch die gleichen Zugriffsrechte wie das Forum auch. Da kannst du die conf_global.php dreimal umbenennen, es wird nichts bringen.

Innerhalb seines Moduls braucht er nur folgendes aufrufen und schon hat er die entsprechenden Informationen:

function beispiel ()
{
    global $ibforums;
   
    echo $ibforums->vars['sql_pass']; // Ausgabe des Passworts
    echo $ibforums->vars['sql_user']; // Ausgabe des Benutzers
}

Da er selbst SQL Statements absetzen kann, könnte er sich auch mit einem einfachen Befehl zu einem Adminuser machen oder die anderen aussperren.

Es ist nicht möglich, das Forum gegen sich selber abzusichern. In meinen Augen kannst du nur die oben erwähnten Variablen auf NULL setzen, bevor der Modulloader aufgerufen wird und natürlich die conf_gloabl.php umbenennen.

Dennoch kann er mittels SQL Statements das Forum ein wenig aushebeln oder du müßtest die MySQL Klasse so umschreiben, das diese beim Aufruf des Moduls bestimmte Statements nicht mehr akzeptiert bzw. nur noch auf einige Tabellen zugreift.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

×