Hosting-Friends.de ....
- Ersteller Querulant
- Erstellt am
- Status
tedlemegba
abgemeldet
- 20 April 2006
- 2.729
- 175
Jupp. Dooferweise. ^^Naja zur Zeit ist wohl der LindaServer down
Du weißt nicht zufällgi wie lang schon?
XFuture-Media.de
Gesperrt
- 24 April 2006
- 592
- 82
Maxtor S-ATA Platte ist abgeschmiert. Läuft nur noch auf Read Only mit Dateisystemfehlern.
Eine IDE Platte wurde eingehängt und darauf wird nun alles installiert und die Daten drauf kopiert.
mfg
X Future Media
tedlemegba
abgemeldet
- 20 April 2006
- 2.729
- 175
Danke.
(Daten draufkopiert? Also ein Backup eurerseits?)
(Daten draufkopiert? Also ein Backup eurerseits?)
XFuture-Media.de
Gesperrt
- 24 April 2006
- 592
- 82
Danke.
(Daten draufkopiert? Also ein Backup eurerseits?)
Die Daten von der S-ATA Platte. Den die steht ja auf Read Only. Wir versuche unser bestes. Alles was nicht von der Platte wiederherzustellen ist, kommt dann aus dem Backup von uns.
mfg
X Future Media
tedlemegba
abgemeldet
- 20 April 2006
- 2.729
- 175
Stimmt, macht Sinn! Danke!
Und wie alt wäre das Backup?
XFuture-Media.de
Gesperrt
- 24 April 2006
- 592
- 82
Wenn eins zum Einsatz kommt, dann das von heute Nacht zwischen 2 und 5 Uhr.
mfg
X Future Media
tedlemegba
abgemeldet
- 20 April 2006
- 2.729
- 175
Wie lange wird sich die Sache denn noch in etwa hinziehen?
XFuture-Media.de
Gesperrt
- 24 April 2006
- 592
- 82
Kann ich momentan nix genaues zu sagen, aber gehe mal von aus, heute noch.
mfg
X Future Media
XFuture-Media.de
Gesperrt
- 24 April 2006
- 592
- 82
So rennt wieder alles.
Von insgesamt 9 GB waren 5 GB beschädigt.
Die Mails konnten 100% gesichert werden, die Html Daten auch recht viele und bei den Mysql Daten auch fasst alles.
Es sind fast nur Logs defekt, also nicht die Welt.
Bei genauen Fragen bitte den Support anschreiben!
mfg
X future Media
Von insgesamt 9 GB waren 5 GB beschädigt.
Die Mails konnten 100% gesichert werden, die Html Daten auch recht viele und bei den Mysql Daten auch fasst alles.
Es sind fast nur Logs defekt, also nicht die Welt.
Bei genauen Fragen bitte den Support anschreiben!
mfg
X future Media
tedlemegba
abgemeldet
- 20 April 2006
- 2.729
- 175
https://www.knoob.de/blog/index.php
Wieso krieg ich nen 403er?
Edit: iwelche Probleme mit mod_rewrite? >.<
Wieso krieg ich nen 403er?
Edit: iwelche Probleme mit mod_rewrite? >.<
Zuletzt bearbeitet:
Mhhh. Gibts bei mir auch.. :
Außerdem gehen bei www.filespider.info die Images noch ned. Hoff es sind da sonst keine Files abhanden gekommen....
edit: Die Images sind zwar oben; aber werden nicht dargestellt
Was isn da nur los ~)
edit2:
9GB insgesamt... Uch; ich verwende derzeit 1GB Speicherplatz. Dann is ja von mir wohl am meisten beschädigt gewesen....
tedlemegba
abgemeldet
- 20 April 2006
- 2.729
- 175
Die Bilder gehen bei mir auch nicht, obwohl vorhanden (zumindest in FTP vorhanden). Hm.. sollten uns allerdings wohl eher per Mail melden.
gib mir mal den webnamen durch dan wirds aktiviert
ein globales "on" gibts beid en neueren servern schon lange nicht mehr (lediglich auf anfrage) - bis jetzt habes auf der kiste auch nur 3 leute vermisst
das problem ist die meisten lücken die auftreten werden durch register_globals verursacht... nehmen wir mal ein beispiel:
phpbb2, Joomla CMS / Mamboo CMS
-> code einschläusen via root_phat=https://....
nehmen wir mal die "einfachen" webseiten nach dem motto:
include($page);
index.php?page=https://...
gibt da nur 2 lösungen:
1. fopen deaktivieren - womit z.b. viele EF schnittstellen o.ä. nicht mehr laufen würden (um nur mal ein beispiel zu nennen)
oder
2. globals abschalten und einzeln freigeben wenn die wirklich benötigt werden
die möglichkeit das jeder programmierer weis was er tut (vor allen wenn viele einfach irgendwas kaufen und drauf packen) fällt leider raus... und für eine inhaltskontrolle nach dem motto "jede datei wird vor dem hoch laden durchgesehen ob der code unsauber ist" wird dir so ziemlich jeder techniker den A**** aufreißen weils einfach nicht machbar ist ^^
unsaubere scripte können z.b. dazu führen das ein mail() aufruf von einer etxternen quelle aus gestartet wird so das mal eben 10 000 spam mails mehr unterwegs sind.... und ich hab eehrlich gesagt keine lust jede woche einmal mit der staatsanwaltschaft über "herrausgabe von IP daten" zu sprechen
so ein problem lässt sich in den logs (relativ) schnell nach vollziehen... aber wieso soll ich HINTERHER jemanden verhauen wnen ich das problem vermeiden kann?
register globals wird seit AFAIK version 4.2 bzw. übergang zu 4.3 als unsicher eingestuft und per default auf off gestellt - nicht ohne grund...
es ist an sich auch sehr einfach so zu programmieren das es funktioniert... statt include($page); könnte man auch mit include($_GET['page']); arbeiten - funktioniert auch unter register_globals = on, genauso unter off -> in dem fall verhinderts aber nicht das $page=https://.... ist da hilft eher include("./".$_GET['page']); und eine abfrage mit if (file_exists($_GET['page'])) { ... } else { ... };
ich schweife schon wieder ab... naja... wenn noch jemand was hinzufügen will... ist sehr oberflächlich erklärt aber ich hoffe man versteht die sicherheitsaspekte...
ein globales "on" gibts beid en neueren servern schon lange nicht mehr (lediglich auf anfrage) - bis jetzt habes auf der kiste auch nur 3 leute vermisst
das problem ist die meisten lücken die auftreten werden durch register_globals verursacht... nehmen wir mal ein beispiel:
phpbb2, Joomla CMS / Mamboo CMS
-> code einschläusen via root_phat=https://....
nehmen wir mal die "einfachen" webseiten nach dem motto:
include($page);
index.php?page=https://...
gibt da nur 2 lösungen:
1. fopen deaktivieren - womit z.b. viele EF schnittstellen o.ä. nicht mehr laufen würden (um nur mal ein beispiel zu nennen)
oder
2. globals abschalten und einzeln freigeben wenn die wirklich benötigt werden
die möglichkeit das jeder programmierer weis was er tut (vor allen wenn viele einfach irgendwas kaufen und drauf packen) fällt leider raus... und für eine inhaltskontrolle nach dem motto "jede datei wird vor dem hoch laden durchgesehen ob der code unsauber ist" wird dir so ziemlich jeder techniker den A**** aufreißen weils einfach nicht machbar ist ^^
unsaubere scripte können z.b. dazu führen das ein mail() aufruf von einer etxternen quelle aus gestartet wird so das mal eben 10 000 spam mails mehr unterwegs sind.... und ich hab eehrlich gesagt keine lust jede woche einmal mit der staatsanwaltschaft über "herrausgabe von IP daten" zu sprechen
so ein problem lässt sich in den logs (relativ) schnell nach vollziehen... aber wieso soll ich HINTERHER jemanden verhauen wnen ich das problem vermeiden kann?
register globals wird seit AFAIK version 4.2 bzw. übergang zu 4.3 als unsicher eingestuft und per default auf off gestellt - nicht ohne grund...
es ist an sich auch sehr einfach so zu programmieren das es funktioniert... statt include($page); könnte man auch mit include($_GET['page']); arbeiten - funktioniert auch unter register_globals = on, genauso unter off -> in dem fall verhinderts aber nicht das $page=https://.... ist
da hilft eher include("./".$_GET['page']); und eine abfrage mit if (file_exists($_GET['page'])) { ... } else { ... }; ich schweife schon wieder ab... naja... wenn noch jemand was hinzufügen will... ist sehr oberflächlich erklärt aber ich hoffe man versteht die sicherheitsaspekte...
- Status