Beiträge von flotte

    Vor etwa einem Jahr wurde die Seite gehackt. Von damals war wohl noch eine Malware übrig geblieben. Dass sie nicht kürzlich installiert wurde, kann ich an einem alten backup erkennen, da ist der Code auch schon drin.

    Geh mal davon aus, das keine saubere Bereinigung des Hacks stattgefunden hat und das es weitere Backdoors gibt. leider kein Einzelfall. So etwas so lange nach dem Hack zu bereinigen ist fast unmöglich. Du solltest auf jeden Fall Fachleute einsetzen, die das versuchern können. Gibt die Bereiniung also besser in Auftrag.

    Es gibt nichts "umsonst" von Google und Co. ...


    Ach ja und dran denken die Datenschutzerklärung zu ergänzen. Das reCAPTCHA sollte da allerdings immer schon ein Bestandteil darin sein - wird aber wohl oft vergessen.

    Es geht auch mit anderen Datenbankbenutzern, was aber voraussetzt, das Du diese eangelgt hast und die richtigen Rechte vergeben hast. In lokaler Umgebung kannst Du aber auch mit root arbeiten. Das Joomla wird ja vermutlich nicht von außen über das Internet erreichbar sein.

    Nein nicht ganz kostenfrei, sondern das wird mit einer kleinen Pauschalgebühr abgerechnet und ist Vertragsbestandteil, womit unsere Arbeit jedoch kaum ausgeglichen wird, denn der Aufwand ist deutlich größer. Wir machen das um die Server möglichst sauber zu halten, denn das ist ja auch in unserem Interesse. Die Vorgehsenweise hat sich in den letzten 10 Jahren als vorteilhaft erwiesen und 99% aller Kunden ärgern sich weniger über die Kosten, sondern freuen sich über ein schnell bereinigtes Web und minimierte Offlinezeiten. Also besser als einfach nur zu sperren und die Kunden im Regen stehen zu lassen...

    Und nein, das gilt für alle Scripte, nicht nur für Joomla.

    dann trag mal das ein:


    Die Mittel von Hostern zur Identifizierung von Hacks sind ungenügend. Es gibt nur diese Varianten: Wenn sie was finden, kannst sicher sein, dass du gehackt bist. Wenn sie nichts finden, kannst du NICHT sicher sein, dass du nicht gehackt bist.


    Und auch die Liste mit Dateien, in denen vom Hoster VIELLEICHT Schadcode gefunden wurde, ist nahezu NIE vollständig

    Ich denke Du beziehst Dich hier auf die großen Massenhoster und nicht auf spezialisierte kleinere Hoster. Was genau andere machen kann ich nicht sagen, aber wir agieren hier ganz anders als die meisten Hoster und analysieren einen Hack vollumfänglich, soweit es die vorhandenen Daten zulassen. Das heisst wir prüfen anhand der Logs, Dateiinhalten, IP-Verfolgung etc.pp. (alles was da ist) in manueller Recherchearbeit einen Hack und der Kunde bekommt eine vollständige Analyse präsentiert (sofern möglich) und kein Ergebnis eines Scanners. Gleichzeitig prüfen wir nach vorhanden Backups von _vor_ dem Hackzeitpunkt und geben Anweisungen welche Sicherheitslücken zu schließen sind. Fast immer ist en gehacktes Web nach wenigen Stunden wieder abgesichert online.

    Sorry die Pauschalaussage oben konnte ich also nicht ganz so stehen lassen :)

    Die Antwort von All-INKL halte ich für nicht richtig. Vielleicht kann ja einer der Hoster hier, kenne nur Supporter flotte von fc-hosting.de , da was zu sagen?


    Auch das Google-Tool sagt bei mir "Antwortzeit des Servers zu lang".


    Das meint, so meine ich, bevor überhaupt die von All-Inkl beschriebenen "Hits" relevant sind, bevor die Seite an den Browser zur Anzeige ausgeliefert wird, der dann wiederum die Hits auslöst. Ich kann mich täuschen!

    Ich habe den Thread jetzt erst gesehen.


    Antwort von All-Inkl.:

    Ja, eine einzelne Seite kann sich aus 100 Hits zusammensetzen. Jede Anfrage an den Server ist ein Hit.

    Und ... umziehen oder langsame Seiten akzeptieren.


    Mit "Hits" ist jedes auf einer Seite verlinkte Objekt/Datei gemeint. Also alles das woraus sich die fertige HTML-Seite später zusammensetzt. Mit der Netzwerkanalyse kann man jeden Hit dann in einer Zeile sehen.


    Viele Inhalte kommen aus dem Cache und erzeugen keinen Request (Hit) an den Server. Bei extrem vielen Requests kann dies eine Seite natürlich spürbar verlangsamen, wobei man aber immer unterscheiden muss zwischen den serverseitigen und cleintseitigen Anteilen bezüglich der Wartezeit bis eine Seite dargestellt wird. Wenn also beispielsweise große Datenmenmgen übertragen werden, dann wird der clientseite Anteil groß werden, auch in Anhängigkeit zur Bandbreite der Internetverbindung.


    Um die prinzipielle serverseitige Performance zu beurteilen oder zu vergleichen messe ich mit curl die TTFB-Zeiten (Time to first byte).

    Als Client nutze ich aber grundsätzlich Server in Rechenzentren und nicht die Office-Anbindung.

    Messen kann man so:

    Code
    curl -o /dev/null -w "Connect: %{time_connect} TTFB: %{time_starttransfer} Total time: %{time_total} \n" http://www.website.de/

    Gemessen wird somit die Verarbeitungsdauer einer Anfrage auf dem Server. Also PHP parsen, Mysql ausführen etc.pp. Schlechte Werte bedeuten nun aber nicht pauschal das der Server langsam ist. Meistens stellt sich heraus, das die Seiten sehr komplex sind, viele Datenbankabfragen haben, die dann auch noch wenig optimiert sind usw. Wenn es um Joomla geht, kann man ja auch den Debug-Modus nutzen, um noch tiefer zu schauen.

    Die TTFB-Messung nutze ich i.d.R. so, das ich mit ähnlichen Seiten auf dem selben Host vergleiche. In der Summer verschiedener Messungen/Untersuchungen kann man dann Aussagen machen, das ein Server prinzipiel langsam oder ggf. überlastet ist und ein Serverwechsel Sinn macht. Einzelmessungen trügen oft.

    Vieles kann ein normaler User ohne root-Rechte gar nicht sehen. Also beispielsweis wie viel CPU-Leistung ein einzelner PHP-Prozess braucht und vieles andere. Man ist also auch auf den Hoster seines Vertrauens angewiesen und (jetzt etwas Eigenwerbung), das findet man in dieser umfangreichen und detaillierten Form einer Analyse nicht bei den Massenhostern. Wenn wir beispielsweise einem Shared-Hosting-Kunden den Umzug auf einen eigenen Server anraten, werden solche Untersuchungen durchgeführt und mit dem Kunden kommuniziert.

    Sag erst mal an, für was Du so etwas brauchst,. Die beiden Beispiele unterscheiden sich gravierend und können sich nicht gegenseitig ersetzen - von daher weiss ich nicht was Du erreichen willst.

    Ich vermute die hast einen root-Server?

    Ein Web-cronjob geht immer. Also wenn das Script über eine URL aufgerufen wird. Die Zeitsteuerung kann über einen Dienstleister wie cronjob.de oder vom Wettkampfserver aufgerufen werden.

    Du braucht aber die entsprechenden Scripte. Einmal eines welches einen SQL-Export auf dem Wettkampserver erzeugt und eines welches auf den Hostingserver den Export importiert. Die Übertragung von Server zu Server kann im einfachsten Fall einfach über eine Text-Datei erfolgen die auf dem Wettkampfserver irgendwo per URL erreichbar abgerufen werden kann. Ggf. mit Passwortschutz...


    Fertige Scripte oder ein fertiges Konzept kann man hier nicht über das Forum liefern. Wenn man sich mit PHP auskennt, sollte das eigentlich relativ einfach realisierbar sein.

    Die Denic läßt mittlerweile keine öffentlichen whois-Abfragen mehr zu. (diverse andere Registries auch). Man kann sich also nicht mehr sinnvoll informieren, wem eine Domain gehört. Eine Impressumspflicht auf einer leeren Seite ohne Inhalt (Wartungsmodus oder geparkte Domain etc.pp.) würde dem entgegenstehen - vom Preinzip her. Mir ist natürlich klar, das das nicht dasselbe ist.

    Tja, Updates bei solchen Hostern führt nicht selten dazu das dein Account auf anderen Servern liegt und die Pfade sich geändert haben. Das muss man dann inder configuration.php anpassen.
    Du kannst das mit dem Tool "joom-Config" prüfen und auch direkt korrigieren. Wichtig: Nicht vergessen das Tool danach vom Server zu löschen.

    Wenn ich sauberen Code haben will, dann kopiere ich Text (egal aus welche Quelle wie Word/html/pdf etc.) vorab in einen Texteditor und kopiere diesen dann dort heraus und füge ihn in mein Zielsystem ein, wie z.B. in den Joomla-Editor.