Beiträge von flotte

zeig doch mal dein komplettes Ergebnis.

Mit 100% Sicherheit gehackt. Sofort offline nehmen - nicht nur offline schalten, sondern komplett unzugänglich machen. FTP-Account ändern und dann die Analyse starten. Anleitungen dazu gibt es ja genug.

Mit der Mail()-Funktion von PHP erhälst Du meistens keine Bounces (Email-Rückläufer), weil oft über Systemadressen/User gesendet wird. Stelle auf jeden Fall auf SMTP-Verandt um und benutze eine Absendeadresse dessen Postfach auch abgefragt wird. Am besten eine eigene Adresse, die nur dazu benutzt wird.
Achte auch darauf das die Absendeadresse zur Domain gehört unter der das Joomla gehört. Keine GMX, Web.de oder ähnliches benutzen. Das veringert die Wahrscheinlichkeit einer SPAM-Erkennung, wenn der versendene Mailserver auch für die Sendedomain zuständig ist.

Prüfe ob die Server-IP des Mailserver ggf. geblacklistet ist. Geht z.B. hier:
http://zy0.de/
http://mxtoolbox.com/blacklists.aspx

Oh, keine Ahnung... da muss ich mal meine Frau fragen :-)))
Im Ernst, weiss ich noch nicht.

Leider keine Zeit... Wäre gerne mal dabei gewesen, aber geht leider ünberhaupt nicht.

Ich denke mal der Opener meint die Art des Ladens der Seite, die sich in einigen Browser etwas unterscheidet, wie er ja selbst schreibt.
Wenn ich einen Menüpunkt anklicke passiert erst mal 2 bis 3 sek gar nichts. Dann zeigt sich die Seite schlagartig. So, also ob alles im Hintergrund geladen wird und erst wenn alles fix und fertig ist, wird etwas angezeigt. Dadurch ensteht ein gefühlt langsames und "hackliges/ruckartiges" Surfen auf der Seite.
Ich denke das hängt mit den JavaScripten zusammen, möglichweise dem Slider. Deshalb würde ich den mal testweise deaktivieren. Ggf. auch mal ein anderes Template testen.

Laß doch mal den Slider auf allen Unterseiten weg und zeig das Ding nur auf der Startseite.

Wurde migriert auf 3.6.2... nach den Postings zu schließen ja. Allerdings ist eine wesentliche Funktion, die Kontaktfunktion nun außer Kraft gesetzt:
http://hundkatzeschmaus.com/de…=com_dfcontact&Itemid=169
DFconact ist nicht mehr da - ist ja auch korrekt, weil inkompatibel
Unabhängig davon ist die Seite unerträglich langsam. War das vorher auch schon so?

Funktioniert denn das Kontaktformular?

Eine Datenschutzerklärung sollte auf jede Website. Am besten wie der Link zum Impressum mindestens von der Startseite aus erreichbar, am besten immer auf jeder Unterseite erreichbar. Das sollte doch eigentlich keinerlei Problem darstellen. Quasi alle Templates haben daür Footer-Bereiche oder ähnliche Stelle wo das leicht einbaubar ist. Damit wäre dann auch ein Kontaktformular soweit "abgesichert". Das ein solcher Link direkt in das Formular muss ist reine Panikmache und bei dem gerne zitierte Abmahnungsfall des Steuerbüros der im Netz kursiert gab es glaube ich keinerlei Datenschutzerklärung.
Die rechtlichen Anforderungen an die Homepage kann man auch wirklich selten pauschal diskutieren, weil es nun mal auf die individuelle Seite ankommt. Für diese Art Fragen nun aber einen Link zur Seite zu senden ist wiederum in Foren nicht anzuraten, denn dann kommen wir in den Bereich der nicht erlaubten Rechtsberatung .... tja auch Anwälte müssen leben

Zur SSL-Verschlüsselung:
Ich persönlich bin der Meinung -ganz unabhängig von einer rechtlichen Bewertung- das eine Seite auf der man personenbezogne Daten eingeben und übermitteln kann, das so eine Seite unbedingt SSL-verschlüsselt sein sollte. Stell Dir selbst die Frage, was Du erwartest wenn Du selbst Deine Daten irgendwo eintippst.
Falls es Dir aus technischen oder finanziellen Gründen nicht möglich sein sollte ein SSL-Zertifikat bei Deinem Hoster zu buchen, dann laß das Formular doch einfach weg und stell einen EMail-Link zur Verfügung.

Ich kann dem nur zustimmen: Es gibt DEFINITIV keinen Scanner der Schadcode/Hacks in Webscripten komplett findet! Bei allen von mir untersuchten Hacks (und das sind hunderte), habe ich fast immer Code gefunden, für den sich kein Scanner interessierte. Fast immer ist es auch so, das bei Entdeckung eines Hacks, z,B., aufgrund von Spam-Aktivitäten oder ähnlichem nur eine der letzten Folgen von Hacks sind und ältere Backdoors versteckt irgendwo liegen. Nicht selten Monate alt...

Hacks in Datenbanken? Habe ich bislang noch nie gesehen, aber ich muss dazu sagen, danach auch nur selten gesucht zu haben. Das wäre eh nur eine Folge eines Hacks.
Nach meiner fest Überzeugung macht es nur wirklich Sinn den "Ersthack" zu bestimmen. Seinen Zeitpunkt und seine Ursache. Nur dann kann man ein Backup von VOR diesem Zeitpunkt benutzen, um eine Seite neu aufzusetzen und alle Lücken zu schließen.
Falls es kein Backup gibt - tja dann Pech gehabt. Dann von vorne anfangen.... Manchmal kann man auch Inhalte über Export/Importools aus der alten Datenbank holen. Ja dann spielt Schadcode in der Datenbank wieder ein Rolle - neben den dort definierten Usern natürlich, die allesamt zu prüfen sind und mit neuen Passwörtern vesehen werden müssen.

Um es gleich vorweg zu nehmen: Normale Tyische Hostingpakete sind hier ungeeignet.

Wurde der Hack untersucht und die Lücke gefunden?
Wenn nicht, wird Dein Web bald neu gehackt sein?

PS: Das Viren/Schadcode in der Datenbank sind, ist eher unwahrscheinlich. Aber Du musst alle unbekannte User entfernen und alle Passwörter ändern.

Mir ist das vollkommen klar :-))
Wenn ich mich jedoch in die Lage vieler Kunden versetze, die dann vielleicht nicht so schnell den Durchblick und die Erfahrungen haben, ist der Ärger aber auch verständlich.

Mag sein, das es bei anderen auch solche Problem gibt, aber das macht es ja nicht besser

Wir haben hier mal eine Anleitung mit Screenshots auf Basis typischer Migrationen erstellt, wie sie ablaufen würde wenn man mit Bordmitteln vorgeht für eine Migration 2.5.28 -> 3.6.2. Nicht enthalten sein können natürlich die vielen typischen vorbereitenden Maßnahmen zur Herstellung der Kompatibilität 2.5 --> 3.x, die von der jeweiligen Komplexität des eigenen Joomla abhängen.
Vielleicht hilft es dem einen oder anderen...

Solche Reaktionen in einem Community-Forum bringen nichts, wenn wir haben das Problem ja gar nicht produziert. Wende Dich mit solcher Kritik -ggf. in einer anderen Form- an die Entwickler.
Unabhängig davon kann ich solchen Ärger aber verstehen - ganz ehrlich. Die Fälle wo nach Updates Fehler auftreten, die dann ganz schnell mit einem neuen Update korrigiert wurden, häufen sich. Das kann man nicht leugnen und man kann sich tatsächlich fragen, warum das in einigen Fällen passiert. Das Tokenproblem hatte ich beispielsweise bei JEDEM Upate von 3.6.0 auf 3.6.1... Kann es also tatsächlich sein, das dies die Entwickler bei den Freigabetests eines Updates nicht hatten??? Kann man nur spekulieren. Ich würde mich freuen, wenn Freigaben neuer Updates besser vorab getest werden. Der Eindruck, das man zu sehr "in the wild" testet kann ich nicht ganz ablegen.

Ich rate deshalb schon dazu -bei wichtigen/komlexen Seiten- ein paar Tage zu warten, bevor man ein Update einspielt, um die Reaktionen in der Community abzuwarten - es sei denn ein Update beseitigt eine massive Sicherheitslücken, dann muss man natürlich sofort updaten. Natürlich gehört auch ein Backup VOR dem Update zum Standardprogramm, so dann man schnell den vorherigen Zustand herrichten kann, falls es zu Problemen kommt.

Zum Thema:
Neben den Größenangaben in der php.ini ist auch die Laufzeitbegrenzung in PHP ein ggf. begrenzendes Kriterium, wenn man mit kleiner Upload-Bandbreite große Datenmengen hochladen möchte. Das muss ja innerhlab der erlaubtren Scriptlaufzeit erfolgen, sofern keine besonderen Ajax-Techniken benutzt werden.

Ja doppeltes Zippen kann Probleme machen. Das Problem ist mir auch bekannt. Kommt seltzen und nur sporadisch vor, aber kommt vor. Es macht aber auch keinen Sinn und erzeugt nur CPU-Last. Die GZIP-Funktion auf PHP-Ebene sopllt enur aktiviert werden, wenn der Server nicht schon selbst autom. komprimiert.

Ist die Seite für die Öffentlichkeit gesperrt worden? Ist ist sicher das die Seite gehackt wurde - also jetzt SOFORT den Account sperren, damit kein weiterer Schaden bei Dritten entsteht. Am besten FTP-Account sofort ändern, und .htaccess-Schuz setzen oder das Webrootverzeichnis umbenennen.

Dann fängt die Arbeit erst an:
* Logs besorgen (FTP ud Webserver)
* prüfen welche Langzeitbackups vorhanden sind
--> Analyse der Vorgänge

Nach Deinen bisherge Äußerungen HPDoepeles ist ziemlich klar, das Du dies nicht selbst schafft. Hilfe findest Du z.B. hier oder bei einem der anderen Anbieter für die Bereinigung gehackter Seiten. Wenn eine Analyse aufgrund fehlender Daten oder Alters des Hacks nicht möglich ist, lösche alles und mach die Seite neu. Eine "Auf-gut-Glück-Bereinigung" ist das letzte was Du erwägen solltest. Ggf. ist es noch möglich die Inhalte der Artikel/Menüeinträge etc. zu exportieren - dafür gibt es Tools.