Beiträge von flotte

    Wenn Du meinst WordPress wäre sicherer, dann muss ich Dich enttäuschen! Alle Scripte werden stetig und massenhaft sofort angegriffen, wenn Sicherheitslücken bekannt werden. Und die gibt es immer wieder bei JEDEM Script. Je beliebter ein Script, desto mehr Angriffe und mehr Lücken werden gefunden. Ganz egal, ob Joomla, Typo3, WordPress, Drupal... das ist vom Sicherheitsstandpunkt aus alles sehr ähnlich.
    Wer Scripte einsetzt muss diese Regeln beachten:
    * Zeitnah updaten
    * Regelmäßige autm. Backups mit Langzeitarchiv
    * Regelmäßig ein Blick in die Statistiken werfen.

    "CGI-limits reached" bedeuted das keine Slots mehr für PHP-Prozesse mehr frei sind. Die Anzahö parallel zugreifender Prozesse ist in der Serverkonfiguration limitiert. Möglichweise hat Du DDos-Angriffe oder einfach zu viele Besucher oder viele Bot/Spiderzugriffe oder die Konfig nicht nicht optimal abgestimmt auf Deinen Server.
    Letzteres ist mit Sicherheit (auch) der Fall, muss jetzt aber nicht das Grundproblem sein. Ein Managed Server wird sicherlich nur eine Default-Konfiguration beinhalten und keine Anpassung an ein bestimmtes Probjekt.


    Die ganze Zeit drehst Du dich im Kreis. Das musst Du doch langsam auch mal merken. Ich verstehe ja Dein Bemühen alles selst lösen zu wollen, aber ich glaube nicht das es klappt - erst recht nicht mit einem Server aus den Du selbst keinen root-Zugriff hast.


    ...
    FastCGI: an/aus (Eingestellt ist aus)
    ...
    Einbindung von PHP al: Modul/CGI (Eingestellt ist Modul; bis vor Kurzem war CGI eingestellt)
    ...


    Ich weiss nicht wo die Angaben herkommen, aber offenbar läuft PHP nun als Modul und nicht mehr fastcgi/fcgi ?
    Dann kann es sein das du nun das "wwwrun-Problem" hast. Das solltest Du umgehend prüfen, denn damit holst Du Dir nun noch mehr Probleme ins Haus.

    Ja das kan ich nachvollziehen und offenbar bist Du auch sehr motiviert. Vielleicht macht es Sinn einen root-Server zu buchen, damit Du auch auf Serverebene alles selbst kontrollieren/einstellen kannst.
    Sollten Ergebnisse vorliegen bitte ich unbedingt um das Bereistellen dieser Infos!

    Dieses Rätzelraten ist doch Unsinn. Der Openener muss erst einmal festellen, wo die Überlastung stattfindet. Wird der Server überlastet, dann sieht man das auf dem Server. Die bisherigen Informationen deuten darauf hin, das es auf jeden Fall keine clientseitige Ursache ist. Siehe schon den Screenshot im ersten Postings. Da muss man nun also nicht mit mootools oder großen Bilder etc.pp kommen.

    Ich kenne keine Details und in solchen Fällen sind Mutmaßungen sehr schwer von außen zu machen. Hier muss ein Profi ran der sich mit Joomla und gleichzeitig Servern auskennt.
    Wir haben einen ähnlichen Fall eines Kunden, der einen eigenen (leistungsstarken) Server betreibt auf dem quasi nur seine eigene Seite läuft. Mit Joomla 1.5 lief alles reibungslos und jetzt ist seit ein paar Tagen auf J 3.4 migriert worden. Die Last ist brutal nach oben gezogen und die Seite ist kaum noch nutzbar. Es wurde bereits stundenlang untersucht und momentan mit einem neuen PHP-Opcode-Cache und dem Nonumber Cache Cleaner etwas (oberflächliche) Ruhe in die Situation gebracht. Der erweiterte Joomla-Cache sorgt dafür das sich DB-Queries minimiert wurden, aber das Grundproblem das die PHP-Prozesse extrem CPU-lastig sind, wurde nicht beseitigt. Kommen Bots vorbei und gibt es Peaks bei den Zugriffen, bricht die Maschine gnadenlos zusammen - obwohl baugleiche Server hunderte anderer Joomla mit mehrfach vielen Zugriffen kaum spürbar verarbeiten kann...


    Will damit sagen, das solche Probleme nicht mit Standardtipps von außen gelöst werden können. Hier muss man genau hinschauen und erst einmal die Ursache erkennen. Beispielsweise ob es die Queries sind oder die PHP-Prozesse. Beim Server schauen, was genau überlastet wird. Reicht der RAM nicht aus, swappt die Maschine, ist MySQL optimal konfiguriert usw. Bestimmte Parameter verändern und die Wirkung prüfen (Komprimierungsverfahren, Cache-Techniken, insbesondere die MySQL-Konfig usw.)
    Die Serverhardware wird vermutlich nicht die Ursache sein, wenn vorher mit einer andere Scriptversion alles einwandfrei lief. Wenn es ein typischer Managed-Server einer der großen Anbieter ist (also ohne root-Zugriff), wirst Du keine Chance haben die Parameter des Servers einzusehen oder diese gar zu ändern. Dann heisst es normalerweise: Bitte stärkere Maschine buchen.

    Ich denke man muss hier nicht paranoider sein als unbedingt notwendig.
    Selbstverständlich gibt es in der Joomla-Szene verschiedene vertrauenswürdige Dritte die selbst auch die Downloads bereitstellen oder auf die offiziellen Quellen verlinken etc.pp. Wir selbst haben seit Jahren ein umfängliches Archiv mit ensprechenden Downloads diverser Versionsstände und holen die Sourcen aus offizillen Quellen. Alle Downloads sind überprüft und werden auch selbst genutzt.


    Dieses Vorgehen ist zu begrüßen und dient dem Nutzererlebnis und dem Bestreben dem Nutzer das bestmögliche und relevanteste Ergebnis zu liefern. Eine nicht mobilfähige Website ist am Smartphone oder Tablet ganz und gar nicht relevant - sondern schlicht unnützer Datenmüll!


    Das ist nur bedingt richtig. Auf meinem Tablett ärgere ich mich jedesmal wenn ich automatisch auf irgend so eine mobile Version einer Website weitergeleitet werden. EIn typisches Tablett kann eine normale Website i.d.R. problemlos darstellen, sofern keine feste Überbreite definiert wurde. Die mobilen Versionen verschiedener Sites sind schlicht inhaltsleer oder funktionslos.


    PS: Auch die meisten der aktuell "hochmodernen" und allseits beliebten Responsive-Designs sind unerträglich lahm (JS ohne Ende) und sehen alle fast geich aus. Ich mag nur wenige dieser Designs und von der Usability solche Seiten auf normalen Bildschirmauflösungen sage ich lieber erst gar nichts. :) Insbesondere diese One-Page-Designs sind überflüssige Spielerei.

    Grundsätzlich ist die Syntax richtig. Es wird ein Pfad auf dem Server einer neuen URL zugewiesen:
    Redirect 301 /ein-pfad eine-URL


    Ich vermute deine .htaccess steht im Verzeichnis des Joomla? Also innerhalb der URL http://bs-wasch.de
    Dann ist Deine Syntax falsch. Es muss so heissen:


    Code
    Redirect 301 / http://waschanlage-braunschweig.de/


    Damit leitest Du alle Aufrufe inklusive alle UNteseiten auf die neue Domain waschanlage-braunschweig.de
    Für die Unterseiten ist wichtig, das hier der abschließende Slash "/" nicht fehlt.


    Auf der neuen Website kannst Du nun einzelne Links umbiegen:


    Code
    Redirect 301 /seite.html http://www.neue-domain.de/seite.html


    Statt 301 kann man auch "permanent" schreiben

    Weiss jetzt nicht genau welche Technik das ist. Wenn man damit aber trotzdem irgendwelche Dateien einzelne aufrufen kann, schützt das auch nur den Login aber nicht das gesamte Verzeichnis samt Unterverzeichnisse.


    teste es einfach mit einer Datei die in jedem Joomla existieren sollte:
    deinedomain.de/administrator/help/helpsites.xml


    "deinedomain.de" natürlich ersetzen!

    Ich meinte "zu viel" im Zusammenhang mit der 2FA. Dann hätte ich drei Paßwörter bis zum Login.


    Alles klar, das hatte ich anders verstanden.


    Mit der .htaccess hast du recht, aber auch diese kann ich ganz leicht überwinden, wenn das PW zu einfach ist. Und das ist bestimmt bei ganz vielen Anwendern der Fall.


    Wer keine sinnvollen Passwörter benutzt ist natürlich selbst schuld.



    Eine 2FA kann ich nicht überwinden, zumindestens ist mir nichts in dieser Richtung bekannt. Also für mich der eindeutig bessere Schutz einer Webseite.


    Ja aber dieser Schutz schützt eben nur vor dem Aufruf der Loginfunktion des Backend. Hacks laufen aber fast immer über Direktaufrufe einzelne Scriptdateien innerhalb von /administrator. Und genau davor schützt eben nur der .htaccess-Schutz. Genau DAS ist der Punkt! Das Login in Joomla spielt nur eine untergeordnete Rolle.

    Das mit der .htaccess ist mir bekannt, aber ist dann für mich persönlich doch ein wenig zu viel. ...


    Wirklich??
    Ein .htaccess-Passwortschutz kann man doch in der Regel über die Hoster-Verwaltungsoberfläche erzeugen und sollte nicht länger als 1 bis 2 Min in Anspruch nehmen. Dieser Schutz schützt gefühlt vor ca. 50% aller typischen Attacken auf Joomla (wenn nicht sogar noch mehr) und ist absolut simpel in der Anwendung. Die 2-Faktor-Authentifizierung und alle andere Aufsatzfunktionen sind dann überflüssig.
    Ich kann nur jedem Webmaster raten diesen Schutze IMMER bei JEDEM Joomla zu setzen - unabhängig davon ob man mit einer Seite Geld verdient oder wie wichtig einem die Seite ist. Es geht ja nicht nur darum die Zerstörung der eigenen Seite zu verhindern (das kann man i.d.R. leicht reparieren mit Backups), aber durch Hacks besteht die Gefahr für Schäden Dritter und damit ist absolt nicht zu spassen. Von Anzeigen bis hin zu Bürodurchsuchungen haben wir das alles schon erlebt... und das "nur" als sogenannter "Mitstörer", der die Seite ja gar nicht betreut, aber auf dessen Servern eine Seite läuft. Was glaubst Du wer in solchen Fällen im Endeffekt die Kosten tragen muss?

    ... ja ein wenig viel Spielerei in der Forensoftware. Ist mir auch schon aufgefallen. Hat mit guter Usability nicht viel zu tun... allein das Suchen der Suchfunktion ist sehr gewöhnungsbedürftig, obwohl genau das jedem Neu-User sofort ins Augen springen müsste. Denn das Suchen in einem Support-Forum ist eines wesentliche Basisfunktion.
    Ich würde diesen gesamten "Headerbereich" zwischen der oberne schwarzen Zeile und Beginn der Navigation ersatzlos streichen. Da steht nix relevantes an mit der besten Position im Fenster.

    Ich schließe mich den Erfolgswünschen gerne an. Joomla-Foren boomen aktuell ja - ein Schelm wer Böses dabei denkt! :)
    Freue mich auf anregenden und informativem Austausch!