|
|||
|
Hi@all
also, wie ich über FTP und KIS Login (hosteurope) meine daten sicher, ist mir "fast" klar ![]() Nun, wie sicher aber die allgemeinen, shop sachen, kann ich das einfach im ACP--->datenabnk mangaer tätige, sprich einfach BACKUP machen und gut ist? Reicht das schon aus
|
|
|||
|
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 |
|
|||
|
das ist wirklich ma interessant zu wissen. Denn ich müsste ma wisen ob mein provider bzw hoster das backup auf deren server legen lässt oder auf mein
Aber ich habe die lösung gefunden.... mysql kannte ich voher auch schon, nur SQL und ich sind noch nie wirklich freunde geworden^^ |
|
|||
|
Zitat:
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 |
|
|||
|
Vielen Dank für die ausführliche Hilfe !
Da ich meine Backups hier zu hause speichere, aber auch noch auf einem zweiten Server liegen habe muss ich da mal sehen was ich mache. "Offen" liegen sie nicht rum, das sollte sowieso klar sein (also .htacces usw. machen!). |
![]() |
| Lesezeichen |
| Stichworte |
| backup, sichern |
| Themen-Optionen | |
| Ansicht | |
|
|
Ähnliche Themen
|
||||
| Thema | Autor | Forum | Antworten | Letzter Beitrag |
| Backup Gemacht, Webspace Gel?scht, Wieder | pilot0815 | Installation und Konfiguration | 2 | 04.05.2005 22:37 |