Beiträge von flotte

    Anregung:


    Das mit dem Backup ist schon ein Argument, aber ich würde die Passwortdatei dennoch außerhalb eines Webrootverzeichnisses ablegen (nicht bei jedem Hosting möglich).

    Normalerweise erzeugt man die Passwortschutzfunktion über das Hostingpanel des Hosters und kann auf diese Weise einen defekten Schutz wieder einrichten oder auch manuell leicht neu erstellen oder deaktivieren (.htaccess löschen).

    Die htpasswd sollte niemals im gleichen Verzeichnis liegen wie die .htaccess. Du kannst das ja selbst durch ändern der Pfade in den Dateien anpassen...


    Unabhängig davon gibts doch vermutlich in jedem Hostingpanel die Funktion einen Verzeichnisschutz einzurichten. Das man dazu heute noch externe Scripte braucht...

    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.

    Ab Debian 9 (Stretch) lauten die Befehle so:


    ## Start command ##
    systemctl start apache2.service

    ## Stop command ##
    systemctl stop apache2.service

    ## Restart command ##
    systemctl restart apache2.service


    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
    1. 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.