Jump to content
xt:Commerce Community Forum

Backup? DB sichern etc..?


Sebastian05

Recommended Posts

Hallo,

für kleine Datenbanken reicht die Funktion im ACP. Wenn dir das Programm eine Fehlermeldung bringt, weißt du dass die Datenbank zu groß wird und du eine anderer Lösung brauchst. Mit der Suche findest du hier im Forum einige Programmvorschläge zum sichern einer Mysql-Datenbank.

LG

Beedle

Link to comment
Share on other sites

Jetzt wirds interessant, könntest du dazu mehr Infos geben ?

Kann das auch mit den normalen Shopdaten passieren, also nicht nur bei einem Backup (.gz) ?

Ja, nun...

wenn ihr Backups von Euren Webanwendungen oder SQL-Dumps (auch gezipptes) als Backup auf Euren Servern liegen habt, LÖSCHT SIE!

Mit Google Codesearch ist es möglich, in fremdem Quelltext zu suchen. Kriminell wird's dann, wenn man z.B. ungeparste PHP-Files auf dem Server hat (z.B. innerhalb eines ZIP-Backups oder dämlicherweise umbenannt nach xyz.php.bak anstelle von xyz.bak.php).

Hier mal ein einfaches Beispiel der Codesuche: PHP Suche nach db.php

Google zeigt zwar Variablen, die Password o.ä. heissen nicht (mehr...) an, dennoch gilt es hier zu handeln! Hier entsteht ein Sicherheitsproblem, was viel schwerer wiegt als irgendwelche register_globals: Hier das ganze Problem noch etwas detaillierter

Für alle, für die Google Code Search noch neu ist: Erste Seite mit Treffern lesen!

Google hält sich zwar an die Anweisungen der robots.txt, trotzdem:

Reicht es aus, an einer Baustelle ein Schild hinzustellen "Spielen verboten"?

Aber bevor man in Panik verfällst, es geht hier um ungeparste Files. Ein "normal" konfigurierter Webserver wird PHP/ASP/PERL/Wasauchimmer-Dateien ODER Daten aus einer SQL-Datenbank nicht im Quelltext ausliefern, sondern sie vor der Ausgabe durch den Parser schicken oder - im Falle der Datenbank - gar nicht erst ausliefern. Wenn auf dem Server allerdings solche Dateien in einem ZIP-Archiv liegen oder ganz allgemein eine ungeeignete Dateiendung haben, wird nix geparst...

Problematisch sind hier SQL-Backups (.sql, .txt, .gz), die ja i.d.R. unverschlüsselt sind. Hast Du nun ein Backup von z.B. "kundendaten_2006.sql" in einem öffentlich zugänglichen Verzeichnis, so findet Google die, zeigt in der Codesuche aber wie gesagt keine Passwords (mehr...) an. Nichtsdestotrotz kann man so wunderbar den Pfad zur Datei ergoogeln und die dann runterladen.

Dann noch einen MD5-Cracker drauf ansetzen und Du bist der Passwortkönig

Ich sehe da in der Tat nur *zwei* mögliche Gegenmassnahmen, wobei die erste die zweite impliziert:

1) Betroffene Dateien sofort löschen oder dafür sorgen, dass sie nicht in einem öffentlichen Verzeichnis abgelegt sind

2) Backups also - wenn überhaupt - an einen Ort ausserhalb htdocs (eine Ebene höher) ablegen. Das geht nur leider nicht überall. In sofern ist die Lösch-Methode Mittel der Wahl. Runter vom Server, auf CD brennen und ab ins Bankschliessfach...

Wer jetzt fragt: Wann kommt wohl die "Google Account Number With PIN Search"?

Das ist es doch schon Search for SQL + account + pin

"Don't be evil"...

IaN

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
  • Create New...