Was spricht dagegen Xampp als Webserver für die live Site zu verwenden?

    Ah interessant...
    "Alles neu machen" macht Sinn, wenn man den Hack nicht zeitlich exakt einstufen kann, wenn man diesen auch nicht analysieren kann und wenn es kein Backup von zeitlich vor(!) dem Hack gibt. Bei den Hacks bei unseren Kunden gibt es fast immer ein passendes Backup (wir machen Langzeitbackups) und wir untersuchen jeden von uns erkannten Hack selbst. Aus Erfahrung wissen wir das 90% der "normalen" Kunden das eh nicht schaffen würden oder teuer Drittleistung zubuchen müssten. Wir machen das daher für 'nen "Appel und nen Ei" wie man so schon sagt (nicht ganz umsonst, aber locker bezahlbar) und erzielen damit gute Ergebniss womit auch die allermeisten Kunden zufrieden sind. 100% kann man es eh nie recht machen. Jedenfalls gab es bislang keinen Hack der aus einer unsauberen Bereinung erneut stattgefunden hat.
    Vermutlich meinte das mein Mitarbeiter mit "alles neu machen" - aus einem Backup, wenn verfügbar. Oder tatsächlich ganz neu machen, wenn der Hack nicht entsprechend eingegrenzt werden kann.


    Dein geschilderte Hack hat aber nichts mit xampp zu tun oder der Serverkonfiguration - das muss man schon sagen. Auch schützt ein anderes Betriebssystem oder andere Webserversoftware nicht besser vor solchen und ähnlichen Hacks aufgrund unsicherer Scripte. Die Absicherung des Servers muss aber dafür sorgen, das der Server selbst nicht gehackt werden kann oder ein Hack in einem Nachbarweb auf dem Host nicht Dein Web verseuchen kann.

    Hallo,


    ja @flotte genau das ist das Problem.. es gibt kein Backup von vor dem Hack! Und seither ist auch sehr viel neues auf der Seite dazu gekommen.Was also schon praktisch das zurück datieren auf den damaligen Stand unmöglich macht.. Das der Hack nicht wegen dem Xampp war, sondern wegen der Lücke in jdownloads ,,das ist bereits erörtert und klar! Alles ist derzeit auf dem neuesten Stand.. also Joomla und alle genutzten Komponenten sind tagesaktuell!! So dass auch die neueste Version von jdownloads läuft!


    Auch ich denke, dass der Hack und die Lücke hoffentlich Geschichte sind, aber die Vorraussetzungen zum Analysieren, sind bei den beiden Herren nicht gegeben,, so dass es mich schon wundern darf woher Sie ihr fundiertes Wissen haben...auf die Schnelle!


    Weil derzeit alles aktuell ist denke ich auch, dass wir jetzt nicht in akute Panik verfallen müssen.. es geht mir eigentlich darum, dass ich die Problematik nicht erkenne? Dass das derzeit genutzte System nicht optimal ist.. und sich damit abgeärgert werden muss, das müsste doch nicht sein!!


    Keiner will das der Hoster gewechselt werden muss!! Er soll lediglich eine optimale Umgebung schaffen, mit der künftig sauber und ohne Probleme gearbeitet werden kann. Das könnte er von mir aus auch gerne mit einer Buchung bei Dir erledigen.. Es geht da auch um weitere Recourcen (email accounts) welche in nicht unerheblichen Maße vorhanden sind.. diese könnte er doch lassen wo Sie sind,, nämlich auf einen seiner sicheren MS Server.


    Die Homepage alleine.. um die geht es mir.. da soll alles funken..ohne jedesmal Hand anlegen zu müssen.. die Seite hat ca. 2.5GB und das ist nicht klein!

    Da kann ich mich Flotte nur anschließen. Gute Karten hat man eigentlich immer dann wenn nach einem Hack nicht mehr viel an einem Projekt gemacht wurden. Dann ist es möglich per Software nach geänderten Dateien zu suchen und diese mit dem Log zu vergleichen So kann man sich von einer Manipulation zur nächsten "hangeln" bis man schließlich beim eigentlich "Hack" und der Schwachstelle im System angekommen ist.


    Wurden aber zwischenzeitlich Arbeiten an einer infizierten Seite vorgenommen, am besten noch in Form von irgendwelchen Updates, dann verwischt man die Spuren und es bleiben nur noch zwei Optionen übrig...


    1. Backup von einem Zeitpunkt einspielen, an dem die Seite ganz sicher noch nicht infiziert war. Und wenn das nicht möglich ist...
    2. Das Projekt "sauber" und von Grund auf mit den gleichen Erweiterungen "nachbauen" und dann die Inhalte manuell übertragen. Am besten von Hand und mit einem Filter der wirklich nur Bilder, PDF und andere "sichere" Dateien übernimmt die nicht betroffen sein können. Macht relativ viel Arbeit, aber man kann recht gut ausschließen das man sich Dateien einhandelt die dort nicht hingehören und die als Hintertür zum System fungieren sollen.


    PS: Als eines der wenigen kostenfreie Programm die für die Suche auf einem Server geeignet sind, ist beispielsweise "FileZilla". Dort kann man eine ganze Reihe von Filtern setzen die die Suche auf bestimmte Dateitypen, Zeiträume und Verzeichnisse beschränkt.


    Gruß Jan

    Hallo,


    @Pest Jan es wurde genau analysiert wann und wie der Hack kam.alles klar und leider nicht mehr änderbar.. auch nicht vom Hoster.Backup nix da und auch nicht nutzbar da zu weit zurück liegend! das Problem hast du wirklich gut erkannt. :thumbup: . Seither sind eine weitere Sprache mit ca. 90 Kategorien, unzählige dazugehörige Artikel usw usw.. dazu gekommen.


    Deshalb habe ich die von Dir erwähnte Option nr.2 vorgeschlagen! Und zwar fast ähnlich wie du es vorschlägst.. lediglich hätte ich die J2XML Komponente genutzt. Oder ist das nicht anzuraten?

    Der damalige JDownloads-Hack war bei den meisten Webs relativ unkritisch, weil die hochgeladenen Hackerfiles in einem Verzeichnis landeten, welches per Default mit einer .htaccess-Sperre für direkten Browseraufruf versehen war. Sofern dies nicht aus irgendwelchen Gründen verändert war, konnte man die Files nicht aufrufen und damit keinen weiteren Schaden verbreiten. Das innerhalb des Verzeichnisses teilweise hunderte Dateien und Ordner erzeugt wurden spielte dann auch keine Rolle.

    • Hilfreich

    Es geht einfacher. Die Hacks beziehen sich normalerweise nur auf Dateien und maximal zusätzliche erstellten oder veränderten Benutzeraccounts mit Zugang zum Backend. Die Inhalte der Datenbank selbst bleiben eigentlich "verschont".


    Du kannst also hergehen und das Joomla mit seinen Komponenten "nachbauen" und dann die "alte" Datenbank damit verknüpfen. Wichtig ist hierbei allerdings, dass du alle wichtigen Zugangsdaten änderst und genau überprüfst wer dort in das Backend kommen kann und ob der Account wirklich diesem Benutzer gehört. Am besten aber auch dort allen Anwendern mit Zugang zum Backend neue Passwörter erstellen und zusenden.


    Problematisch ist es halt bei den Dateien, dass man nicht aus Versehen doch eine kompromittierte PHP oder das manipulierte Gif erwischt, mit dem der Hack damals gestartet wurden.


    Bei PHP-Dateien ist es klar, die kann man per Filter aussortieren und überhaupt nicht erst anzeigen lassen (Test auf Plausibilität / PHP und JS gehören nicht in ein Image-Verzeichnis).


    Bei Bildern kannst du dir diese auf deinen heimischen Rechner übertragen und dort im Verzeichnis als kleine Vorschaubilder anzeigen lassen. Alles was keine Vorschau produziert, wird hierbei mit höchster Wahrscheinlichkeit auch kein Bild sein, sondern z.B. eine PHP-Shell mit bewusst falscher Dateiendung, die später per htaccess ausführbar gemacht werden soll.


    Gruß Jan

    @flotte ja dazu habe ich deinen damaligen threat bereits gelesen. Rein von der Webpage her, könnte also wenn nicht sowieso Änderungen gemacht werden wollen, alles so bleiben.. ändert jedoch nix an der Xampp Nutzung.. diese ist suboptimal.. um mal so zu sagen. Welche Lösung würdest du da vorschlagen?

    Zitat von SilOrs67

    .. ändert jedoch nix an der Xampp Nutzung.. diese ist suboptimal.. um mal so zu sagen. Welche Lösung würdest du da vorschlagen?


    Was soll ich da vorschlagen? Wenn an dem Hoster festgehalten wird, bleibt ja nur das was er anbieten kann. Was ein anderer Hoster -also auch ich- hier vorschlagen würde ist ja sonnenklar :)


    Sorge grundsätzlich mit den allgemein bekannten Sicherheitsmaßnahmen für eine bessre Absicherung des Web und treffe Vorsichtmaßnamen, die dann im Fall eins weiteren Hacks das Leben erleichtern.


    Also:
    * Alles up2date halten
    * regelmäßige autom. Backups außerhalb des Accounts machen (->Langzeitbackups)
    * .htaccess-Passwortschutz auf das administrator-Verzeichnis
    * regelmäßig einen Blick in die Logfile-Statisken werden, um Auffälligkeiten zu erkennen
    * regelmäßig einen Blick auf die Dateien werfen. Ggf. auf aktuelle Datumsstempel achten
    * sichere Passwörter
    * FTP löschen und nur temporär einrichten
    ...

    Hallo Uwe,


    vielen Dank, das wurde eh immer so gemacht, wir hätten Backups genug, aber leider wächst die Seite zu schnell um ohne erhebliche Nacharbeiten, z.B. nur von vor 2 Monaten einzuspielen.. deshalb ist das Backup von damals praktisch nicht nutzbar.


    alle anderen Punkte habe ich eh immer so viel wie möglich abgesichert.. die logfiles kann ich gar nicht sehen! Nur Zugriff ab Ebene Joomla..
    alles andere wird eingehalten! Und dann hoffen wir mal!


    Mache jetzt verdienten Feierabend beer vielen Dank für eure Antworten und schönen Abend noch!

    SilOrs67


    ganz einfach


    XAMPP for Windows <= 1.6.0a mssql_connect() Remote BoF Exploit | ./windows/remote/3738.php
    XAMPP for Windows 1.6.3a - Local Privilege Escalation Exploit | ./windows/local/4325.php
    XAMPP 1.6.8 - (CSRF) Change Administrative Password Exploit | ./windows/remote/7384.txt
    XAMPP 1.7.2 Change Administrative Password | ./php/webapps/10391.txt
    XAMPP <= 1.7.3 - Multiple vulnerabilites | ./php/webapps/15370.txt
    XAMPP WebDAV PHP Upload | ./windows/remote/18367.rb
    XAMPP Phonebook.PHP Multiple Remote HTML Injection Vulnerabilities | ./multiple/remote/25391.txt
    XAMPP Insecure Default Password Disclosure Vulnerability | ./multiple/dos/25393.txt
    XAMPP 1.8.1 (lang.php WriteIntoLocalDisk method) - Local Write Access Vulnerability | ./php/webapps/28654.txt
    XAMPP for Windows 1.8.2 - Blind SQL Injection | ./windows/webapps/29292.txt
    XAMPP Linux 1.6 - ming.php text Parameter XSS | ./linux/remote/32165.txt
    XAMPP Linux 1.6 - iart.php text Parameter XSS | ./linux/remote/32166.txt
    XAMPP for Windows 1.6.8 - 'cds.php' SQL Injection Vulnerability | ./windows/remote/32457.txt
    XAMPP for Windows 1.6.8 - 'phonebook.php' SQL Injection Vulnerability | ./windows/remote/32460.txt
    XAMPP 3.2.1 & phpMyAdmin 4.1.6 - Multiple Vulnerabilities | ./php/webapps/32721.txt
    XAMPP 1.6.x - Multiple Cross-Site Scripting Vulnerabilities | ./multiple/remote/33577.txt
    XAMPP 1.6.x - 'showcode.php' Local File Include Vulnerability | ./multiple/remote/33578.txt
    XAMPP 1.7.4 Multiple Cross Site Scripting Vulnerabilities | ./windows/remote/36258.txt
    XAMPP 1.7.7 'PHP_SELF' Variable Multiple Cross Site Scripting Vulnerabilities | ./windows/remote/36291.txt
    XAMPP for Windows 1.7.7 Multiple Cross Site Scripting and SQL Injection Vulnerabilities


    bist du den bereit das ständig zu aktuallisieren?
    hast du ein sicherheitskonzept entwickelt?
    ist vorgesehen das du die standardconfiguration änderst?
    werden alle nicht benötigten module und komponente entfernt?
    gibt es eine bedarfsanforderung an software?


    ich bin ein sicherheitsexperte und berücksichtige das bsi sicherheitsmodell für webapplications.


    wenn du sicher gehen willst dann:
    hosteurope (je nach anforderung) ein größeren normalhosting nehmen und das zusatz sicherheits pakett.


    wenn dazu noch jommla eingesezt wird ist mehr als sinnvoll das sicherheitspakett zu nehmen.
    ich bin auch ein joomla experte und entwickler, da ich joomla liebe gebe ich dir diese tipps.


    falls du zwecks templates php 7 einsetzt nicht die version 7.0 nehmen weil darüber remote exploits möglich sind


    es sollte sichergestellt werden das alle module, plugins etc. aufgelistet werden und regelmäßig auf updates
    überprüft werden, was kann dir schlimstens passieren?


    das einer deine webseite hackt und spambots einspielt, dass wieder zu cleanen bedarf viel zeit und mühe, unter
    umständen je nachdem welche spamdatenbank erfasst hat, kostet das geld.


    viel erfolg bei deinem projekt


    bye

    ethical-byte Du möchtest uns nun aber doch nicht wirklich erzählen, das hosteurope ein guter Hoster ist ? Da trittst du hier eine Diskusion los die nach hinten los geht ! Ich hatte da schon Leute die zu dämlich waren den Authcode von Gn2 zu benutzen. Die Domain habe ich dann begraben. Der der sie wollte hat geheult.
    Du arbeitest da ?


    Zitat

    wenn dazu noch jommla eingesezt wird ist mehr als sinnvoll das sicherheitspakett zu nehmen.


    verstehe ich jetzt gar nicht. Das heisst für mich Joomla ist unsicher und man braucht nun unbedingt das Sicherheitspaket von Hosteurope. Ich möchte nicht deine Fähigkeiten anzweifeln aber das ist doch alles irgendwie komisch und ergibt für mich keinerlei Sinn.

    Hallo @ethical-byte,


    die Treatfrage war von mir gestellt worden um klar darzulegen, dass es keine gute Idee ist das Xampp system für eine live site zu verwenden. Dies hatte auch bei den Profis hier den überwiegenden Zuspruch.. Ich selbst würde das nie verwenden, eben auch wegen den von dir schön aufgelisteten Punkte...


    Deshalb habe ich das damals auch auf "erledigt" gestellt.

    Ich habe eher positive Erfahrungen mit Hosteurope gemacht, möchte hier aber auch keine Grundsatzdiskussion lostreten.


    Allerdings gehört der werbliche Beitrag von ethycal-byte eigentlich durch einen Admin redigiert, sonst könnte ja jeder hier Uralt-Threads ausgraben und seine Werbung dahinter schreiben.

    Zitat von addi


    Allerdings gehört der werbliche Beitrag von ethycal-byte eigentlich durch einen Admin redigiert, sonst könnte ja jeder hier Uralt-Threads ausgraben und seine Werbung dahinter schreiben.


    Ich persönlich hätte den nicht als werblich interpretiert, falls es doch so angedacht war ist es ja schon fast eher kontraproduktiv ;)