Wurde mein apache webserver gehackt?

Rene Peters schrieb:
> Woran kann es noch liegen

was steht denn im Access log so drin?

Jörg Wunsch schrieb:
> Ich würde sowas ja in der Konfiguration des Servers selbst eintragen.

Wie heißt die Datei für die Konfiguration? httpd.conf? Die ist leer.

Peter II schrieb:
> was steht denn im Access log so drin?

Wo finde ich den access log?

A. K. schrieb:
> Möglicherweise sowas wie /etc/apache2/sites-enabled/000-default
> Wenn darin kein override zugelassen wurde, dann sind .htaccess Files
> wirkungslos.

Rene Peters schrieb:
> Trage ich meine IP-Adresse ein bekomme ich weder eine Mail noch habe ich
> Zugriff auf die Seiten.

die logs findest du normalerweise unter /var/log/apache2/

Was ist denn das:

GET /w00tw00t.at.ISC.SANS.Win32:) HTTP/1.1

war ein Request, wurde mit 400 quittiert. Es gab sogar eine ganze Menge 
davon: http://pastebin.com/YsrBSWPu

Dann gab es vor kurzem folgenden Request:

POST 
/?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2 
D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6 
E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65 
%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73% 
65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5 
F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66 
%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65% 
64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%64+%61%75%7 
4%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%7 
0%75%74+%2D%6E  HTTP/1.1

übersetzt

  POST /?-d allow_url_include=on -d safe_mode=off -d 
suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d 
auto_prepend_file=php://input -d cgi.force_redirect=0 -d 
cgi.redirect_status_env=0 -d auto_prepend_file=php://input -n HTTP/1.1

das mit einem 200 quittiert wurde!


Und dann noch ein

  GET 
http://24x7-allrequestsallowed.com/?PHPSESSID=7jy745aa00143YWMVWR_EABFUOT 
HTTP/1.1

und ein

  GET http://91.188.124.233/index.html HTTP/1.1

das auch mit einem 200 quittiert wurde.

Was tun?

Rufus Τ. Firefly schrieb:
> Rene Peters schrieb:
>> Wie heißt die Datei für die Konfiguration? httpd.conf? Die ist leer.
>
> Das ist eher ... unwahrscheinlich. Wo hast Du nach dieser Datei gesucht?

find / -name httpd.conf.

Es gab einen Treffer.

Zum eigentlichen Problem: was muß ich in der apache2.conf ändern um das 
Problem zu beheben?

Hallo.

Da kannst du nicht viel tun. Manche Leute haben ne Menge Zeit und 
scannen das ganze Web nach allen möglichen Dingen ab.
Ich nutze ein Fail2Ban nach 3 Scans und die IP kommt nicht mehr an den 
Server dran.


Martin

Nachdem ich fail2ban per apt-get geholt und per fail2ban start gestartet 
habe, läuft es dann automatisch immer weiter?

Hallo.

Man kann fail2ban auch für mehrere 200 von einer IP in zB 10 Minuten 
konfigurieren.


Martin

Immer diese halbgaren Antworten. Statt "Auch fail2ban Konfiguriert?" 
schreibst du in Zukunft. Um fail2ban zu konfigurieren machst du a, b und 
c.

Nicht persönlich nehmenm, die Kids spielen mit DFind rum.
htaccess ist ein guter Startpunkt, für solche Sachen kann ich dir aber 
empfehlen sich mit mod_security auseinander zu setzen. Ach ja, ich habe 
auf meinem Server damals noch folgenden trick angewandt:
robots.txt anlegen mit folgendem Inhalt.

User-agent: *
Disallow: /auf/wiederseen

Normale Menschen gucken sich die Datei nicht an, einige "Hackertools" 
schon. Sobald jemand probiert diesen Ordner anzusteuern -> Ban.

Rene Peters schrieb:
> Wie heißt die Datei für die Konfiguration? httpd.conf? Die ist leer.

Rene Peters schrieb:
> Wo finde ich den access log?

Du solltest m.E. keinen Server betreiben der öffentlich erreichbar ist, 
da du offensichtlich nicht über die notwendigen Fähigkeiten verfügst das 
Ding zu warten und vor allem abzusichern.

Rene Peters schrieb:
> Um fail2ban zu konfigurieren machst du a, b und
> c.

Ja, klar, ist alles so einfach, dann kann jeder Depp ohne 
Hintergrundwissen einen Server absichern, man muss nur a, dann b und zum 
Schluss c machen... man muss dafür nur mal in einem Forum nachfragen und 
das reicht dann schon.

Dir ist hoffentlich klar dass du dafür veantwortlich bist falls jemand 
deine Maschine für illegale Sachen missbraucht.

Einen sog. Managed Server zu mieten mag anfangs mehr kosten, aber dann 
machen andere für dich die Arbeit.

Mein Ung schrieb:
> Du solltest m.E. keinen Server betreiben

Du solltest nicht antworten wenn deine Antworten weiterhin diese 
niedrige Qualität haben.

Läubi .. schrieb:
> Öhm... normal ist das sicher nicht, seit wann gehört das Protokoll und
> der Host in die GET Anfrage?

Das ist zwar unüblich, aber der Standard erlaubt es ;D

Rene Peters schrieb:
> POST /?-d allow_url_include=on -d safe_mode=off -d
> suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d
> auto_prepend_file=php://input -d cgi.force_redirect=0 -d
> cgi.redirect_status_env=0 -d auto_prepend_file=php://input -n HTTP/1.1
>
> das mit einem 200 quittiert wurde!
Hier wird wohl versucht falsch als CGI eingebundenes PHP anzugreifen.
Sofern die Lücke nicht tatsächlich vorhanden ist, wird aber einfach das 
Standarddokument ausgeliefert (also vermutlich index.html oder 
index.php)

>
> Und dann noch ein
>
>   GET
> http://24x7-allrequestsallowed.com/?PHPSESSID=7jy745aa00143YWMVWR_EABFUOT
> HTTP/1.1
Sofern das mit 200 beantwortet wird und dein Host nicht 
'24x7-allrequestsallowed.com' ist, betreibst du womöglich einen offenen 
Proxy-Server!

Ein Blick in die access_log wäre wohl schon interessant ;D

Jörg Wunsch schrieb:
> Rene Peters schrieb:
>> Du solltest nicht antworten wenn deine Antworten weiterhin diese
>> niedrige Qualität haben.
>
> Recht hat er aber

Recht hat er nicht.

bluppdidupp schrieb:
> Sofern das mit 200 beantwortet wird und dein Host nicht
> '24x7-allrequestsallowed.com' ist, betreibst du womöglich einen offenen
> Proxy-Server!

Ich habe meine Serveradresse mit allen offenen Ports als Proxyserver auf 
meinem Heimrechner eingetragen und ich konnte keine Seite aufrufen.

Die Verbindung zum Proxyserver konnte nicht hergestellt werden. Der 
Zugriff wurde verweigert.

Ich habe keinen ungewollten Proxyserver.

Tobias Frost schrieb:
> Allerdings -- dass muss ihm klar sein -- kann man das
> sehr einfach umgehen.

Und schon wieder Ende.

Wie kann man das umgehen.

Tobias Frost schrieb:
> z.b: Anderen Internetzugang verwenden? z.B vom Handy, daheim,
> Freund
> .... Evtl. hat die IP in Frage noch einen Backup-zugang?
Der, um den es geht hat einen gehosteten Server mit IP-range. Einmal 
ordentlich geblockt und es gibt kein Problem mehr.

> Da fehlts an den Basics. :(

Nein, da fehlt es nicht an den Grundlagen.

Mark Brandis schrieb:
> Rene Peters schrieb:
>> Nein, da fehlt es nicht an den Grundlagen.

Du hast in diesem Thread dein Wissen noch nicht unter Beweis gestellt, 
warum fängst du nicht mal langsam damit an - oder ist es etwa nicht 
vorhanden?

Hallo Rene.

Ich finde deine Reaktion auf Hilfestellungen hier im Forum auch nicht 
gut.
Die Leute helfen freiwillig, du machst keine genauen Angaben zum Setup 
und forderst nur.
Ich würde endlich mal im Logfile nachschauen was dort steht im Falle 
eines deny der 123.x.x.x. IP.
Ich habe da auch schon böse Überraschungen erlebt mit einem Leerzeichen 
an der falschen Stelle in der .htaccess Syntax.


Martin

Hier die default unter sites-available:

    <VirtualHost *:80>
            ServerAdmin webmaster@localhost

            DocumentRoot /var/www
            <Directory />
                    Options FollowSymLinks
                    AllowOverride None
            </Directory>
            <Directory /var/www/>
                    Options Indexes FollowSymLinks MultiViews
                    AllowOverride None
                    Order allow,deny
                    allow from all
                    deny from 123.123.123.123
            </Directory>

            ScriptAlias cgi-bin /usr/lib/cgi-bin/
            <Directory "/usr/lib/cgi-bin">
                    AllowOverride None
                    Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
                    Order allow,deny
                    Allow from all
            </Directory>

            ErrorLog ${APACHE_LOG_DIR}/error.log

            # Possible values include: debug, info, notice, warn, error, 
crit,
            # alert, emerg.
            LogLevel warn

            CustomLog ${APACHE_LOG_DIR}/access.log combined

        Alias doc "/usr/share/doc/"
        <Directory "/usr/share/doc/">
            Options Indexes MultiViews FollowSymLinks
            AllowOverride None
            Order deny,allow
            Deny from all
            Allow from 127.0.0.0/255.0.0.0 ::1/128
        </Directory>

    </VirtualHost>

Habe AllowOverride nicht geändert, sondern gleich die IP(meine IP) 
reingeschrieben, wie es besser ist.

Habe es gespeichert, habe den Server neugestartet, die Seite liegt in 
einem Unterverzeichnis von /var/www

Trotzdem kann ich darauf zugreifen, verdammt nochmal.

AK. In welchem Logfile finde ich das unter /var/log/?

Um dem Fehler näherzukommen mehr details:

So sieht es aus:

1

Domain-root/ordner1/ordner2

unter domain-root ist eine index.php. In dieser steht etwa

1

<?php echo "Wurzel"; ?>

Ist in Domain-root auch eine htaccess mit deny from <meineIP> dann 
bekomme ich ein denied wie gewünscht.

In Domain-root/ordner1 ist auch eine index.php und eine htaccess mit 
deny from <meineIP>.

In dieser index.php steht

1

<?php  

2

require('ordner2/1.php');

3

  ?>               

4

      <div class="blah">  

5

6

<?php require("ordner2/2.php"); 

7

require('ordner2/3.php');

8

require('ordner2/4.php');

9

require('ordner2/5.php');

10

?>  

11

<?php require("ordner2/6.php"); ?>    

12

<?php require("ordner2/7.php"); ?>     

13

<?php require("ordner2/8.php"); ?>                

14

      </div>  

15

16

<?php

17

require 'ordner2/9.php';

18

  ?>

In Domain-root/ordner1/ordner2 sind die 1.php bis 9.php und eine 
htaccess mit deny from <meineIP>.

Habe ich die htaccess dort nicht, wird die Seite angezeigt und die 
htaccess in Domain-root/ordner1 und Domain-root ignoriert. Habe ich sie, 
wird die Seite trotzdem angezeigt aber nur als Text, jedes Bild, jede 
CSS-Formatierung fehlt.

Scheint ein selektives deny from zu sein, Text kommt durch Bilder nicht. 
Der Text findet sich in den 1 bis 9.php ohne weitere requires als 
schlichtes echo.

In den Server-Logs steht nichts darüber.

Ich glaube du zeigst uns nicht das richtige Config File.
Denn in dieser Config werden weitere .htaccess expliziet unterbunden.
Wenn du dann noch schreibst, dass deine .htaccess im Unterverzeichnis
funktioniert, stimmen was nicht. Ev. Apache noch nie neu gestartet ?
Ansonsten ist der Fehler schnell ersichtlich, deine Access rule stimmt 
nicht.
Wenn du dir ein Howto oder Doku mal durchgelesen haettest, dann waere 
dir
dieser Fehler nicht unterlaufen, weil extra auf dies dort hingewiesen 
wird.
                    Order allow,deny
muss so lauten:
                    Order deny,allow

chris schrieb:
> Ich glaube du zeigst uns nicht das richtige Config File.
> Denn in dieser Config werden weitere .htaccess expliziet unterbunden.
> Wenn du dann noch schreibst, dass deine .htaccess im Unterverzeichnis
> funktioniert, stimmen was nicht. Ev. Apache noch nie neu gestartet ?
> Ansonsten ist der Fehler schnell ersichtlich, deine Access rule stimmt
> nicht.
> Wenn du dir ein Howto oder Doku mal durchgelesen haettest, dann waere
> dir
> dieser Fehler nicht unterlaufen, weil extra auf dies dort hingewiesen
> wird.
>                     Order allow,deny
> muss so lauten:
>                     Order deny,allow

Hat nichts geändert.

> Ev. Apache noch nie neu gestartet ?

Rene Peters schrieb:
> Habe es gespeichert, habe den Server neugestartet, die Seite liegt in
> einem Unterverzeichnis von /var/www

Kann es sein, daß eine Datei, die wichtiger ist als die default diese 
ignorieren läßt?

Schreib doch den Order um, und stell auch sicher, dass in deiner
Htaccess im Unterordner nicht wieder der order allow,deny steht.

Es ist ganz einfach.
 Order allow,deny heisst, erlaube alle, und nachdem alle erlaubt sein, 
sperre  133. ... . Da alle erlaubt sind, ist auch 133. ... erlaubt.

Wenn du aber den order umdrehst, also order deny,allow
dann sperrt er den 133. ... und wenn es kein 133. ... ist, dann erlaubt 
er
diese.

Rene Peters schrieb:
> Was ist denn das:
>
> GET /w00tw00t.at.ISC.SANS.Win32:) HTTP/1.1
>
> war ein Request, wurde mit 400 quittiert. Es gab sogar eine ganze Menge
> davon: http://pastebin.com/YsrBSWPu
>
> Dann gab es vor kurzem folgenden Request:
>
> POST
> /?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2 
D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6 
E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65 
%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73% 
65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5 
F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66 
%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65% 
64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%64+%61%75%7 
4%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%7 
0%75%74+%2D%6E
> HTTP/1.1

ist ein automatisierter scan nach verwundbaren php-http servern.


>   POST /?-d allow_url_include=on -d safe_mode=off -d ...
siehe https://www.google.de/search?q=POST+/%3F-d+allow_url_include%3Don

was der exploit macht weiß ich nicht, deine sache.
normalerweise versucht man auf webservern eigenen code unterzubringen, 
also z.b. eigene php/perl/shell (je nachdem was dein webserver 
interpretiert) scripte im filesystem unterzubringen und diese vom 
webserver ausführen zu lassen.
das kann beliebig komplex werden, bis hin zu base64 encodierten binaries 
die zeilenweise hochgeladen und dort wieder zusammengebaut werden - ziel 
wäre in dem fall z.b. einen telnetd zu plazieren um sich die weitere 
arbeit leichter zu machen.

du willst wissen was (eventuell) auf deinem server passiert ist? hol dir 
professionelle hilfe, vor allem wenn du schon probleme hast die ganz 
normalen access/error-logs zu finden (die übrigens gefälscht sein 
können, je nachdem wie tief jemand ins system eingrdrungen ist.).