Donald: Apache soll Angriffe erkennen

Hallo,

Ich hab einen Apache der eine Webseite betreibt. Ich finde in den error-Logs aber beinahe täglich die Liste der Seiten die aufgerufen wurden um auf Lücken zu scannen:

[Sat Jun 21 04:18:27 2008] [error] [client 151.9.70.133] File does not exist: C:/MYSITE_HP/MYSITE_PUBLIC/db
[Sat Jun 21 04:18:28 2008] [error] [client 151.9.70.133] File does not exist: C:/MYSITE_HP/MYSITE_PUBLIC/web
[Sat Jun 21 04:18:28 2008] [error] [client 151.9.70.133] File does not exist: C:/MYSITE_HP/MYSITE_PUBLIC/PMA
[Sat Jun 21 04:18:28 2008] [error] [client 151.9.70.133] File does not exist: C:/MYSITE_HP/MYSITE_PUBLIC/admin
[Sat Jun 21 04:18:28 2008] [error] [client 151.9.70.133] File does not exist: C:/MYSITE_HP/MYSITE_PUBLIC/dbadmin
[Sat Jun 21 04:18:29 2008] [error] [client 151.9.70.133] File does not exist: C:/MYSITE_HP/MYSITE_PUBLIC/PMA2006
[Sat Jun 21 04:18:29 2008] [error] [client 151.9.70.133] File does not exist: C:/MYSITE_HP/MYSITE_PUBLIC/pma2006
[Sat Jun 21 04:18:29 2008] [error] [client 151.9.70.133] File does not exist: C:/MYSITE_HP/MYSITE_PUBLIC/sqlmanager
[Sat Jun 21 04:18:29 2008] [error] [client 151.9.70.133] File does not exist: C:/MYSITE_HP/MYSITE_PUBLIC/mysqlmanager
[Sat Jun 21 04:18:30 2008] [error] [client 151.9.70.133] File does not exist: C:/MYSITE_HP/MYSITE_PUBLIC/p
[Sat Jun 21 04:18:30 2008] [error] [client 151.9.70.133] File does not exist: C:/MYSITE_HP/MYSITE_PUBLIC/PMA2005
[Sat Jun 21 04:18:30 2008] [error] [client 151.9.70.133] File does not exist: C:/MYSITE_HP/MYSITE_PUBLIC/pma2005
[Sat Jun 21 04:18:30 2008] [error] [client 151.9.70.133] File does not exist: C:/MYSITE_HP/MYSITE_PUBLIC/phpmanager
[Sat Jun 21 04:18:30 2008] [error] [client 151.9.70.133] File does not exist: C:/MYSITE_HP/MYSITE_PUBLIC/php-myadmin
[Sat Jun 21 04:18:31 2008] [error] [client 151.9.70.133] File does not exist: C:/MYSITE_HP/MYSITE_PUBLIC/phpmy-admin
[Sat Jun 21 04:18:31 2008] [error] [client 151.9.70.133] File does not exist: C:/MYSITE_HP/MYSITE_PUBLIC/mysql
[Sat Jun 21 04:18:31 2008] [error] [client 151.9.70.133] File does not exist: C:/MYSITE_HP/MYSITE_PUBLIC/myadmin
[Sat Jun 21 04:18:31 2008] [error] [client 151.9.70.133] File does not exist: C:/MYSITE_HP/MYSITE_PUBLIC/webadmin
[Sat Jun 21 04:18:32 2008] [error] [client 151.9.70.133] File does not exist: C:/MYSITE_HP/MYSITE_PUBLIC/sqlweb
[Sat Jun 21 04:18:32 2008] [error] [client 151.9.70.133] File does not exist: C:/MYSITE_HP/MYSITE_PUBLIC/websql
[Sat Jun 21 04:18:32 2008] [error] [client 151.9.70.133] File does not exist: C:/MYSITE_HP/MYSITE_PUBLIC/webdb
[Sat Jun 21 04:18:32 2008] [error] [client 151.9.70.133] File does not exist: C:/MYSITE_HP/MYSITE_PUBLIC/mysqladmin
[Sat Jun 21 04:18:32 2008] [error] [client 151.9.70.133] File does not exist: C:/MYSITE_HP/MYSITE_PUBLIC/mysql-admin
[Sat Jun 21 04:18:33 2008] [error] [client 151.9.70.133] File does not exist: C:/MYSITE_HP/MYSITE_PUBLIC/phpmyadmin2
[Sat Jun 21 04:18:33 2008] [error] [client 151.9.70.133] File does not exist: C:/MYSITE_HP/MYSITE_PUBLIC/phpMyAdmin2
[Sat Jun 21 04:18:33 2008] [error] [client 151.9.70.133] File does not exist: C:/MYSITE_HP/MYSITE_PUBLIC/phpMyAdmin-2
[Sat Jun 21 04:18:33 2008] [error] [client 151.9.70.133] File does not exist: C:/MYSITE_HP/MYSITE_PUBLIC/php-my-admin
[Sat Jun 21 04:18:33 2008] [error] [client 151.9.70.133] File does not exist: C:/MYSITE_HP/MYSITE_PUBLIC/phpMyAdmin-2.2.3
[Sat Jun 21 04:18:34 2008] [error] [client 151.9.70.133] File does not exist: C:/MYSITE_HP/MYSITE_PUBLIC/phpMyAdmin-2.2.6
[Sat Jun 21 04:18:34 2008] [error] [client 151.9.70.133] File does not exist: C:/MYSITE_HP/MYSITE_PUBLIC/phpMyAdmin-2.5.1

und so weiter... Seitenweise...

Kann man dem Apache nicht beibringen, dass nach zB 10 Zugriffen mit Fehler von der selben IP die IP für eine Stunde gesperrt werden soll? Das würde die Sache für den Scanner deutlich erschweren, oder?

Gibt es da ein Modul oder eine Extension oder sowas?

Grüsse,

Donald

  1. Kann man dem Apache nicht beibringen, dass nach zB 10 Zugriffen mit Fehler von der selben IP die IP für eine Stunde gesperrt werden soll? Das würde die Sache für den Scanner deutlich erschweren, oder?

    Auf welche Obscurity vertraust du?
    Unzugängliches schützt man entweder mit .htaccess oder stellt es ausserhalb von http docs.

    Btw. Und was wenn die 404er durch deine Dusseligkeit verursacht sind?

    mfg Beat

    --
    Selber klauen ist schöner!
    1. Hallo,

      Auf welche Obscurity vertraust du?

      wo siehst du hier irgendeinen Ansatz von Obscurity? Wenn ich den OP richtig verstehe, ist er nur genervt von zahllosen Requests, die zwar ins Leere gehen, in ihrer Gesamtheit aber erkennen lassen, dass da jemand geduldig sucht und probiert.

      @Donald: Solche Einträge habe ich auch zu Hunderten in meinen Logs; sie gehen mir irgendwie auch auf den Senkel, aber es lohnt sich nicht, etwas dagegen tun zu wollen. Lass den "Hacker" doch nach irgendwelchen Dokumenten oder Scripten suchen, wenn's ihm Spaß macht. Solange dein Webserver ordentlich konfiguriert ist, wird er nichts finden und gibt irgendwann auf. Okay, dann kommt der nächste und probiert wieder rum ...

      Unzugängliches schützt man entweder mit .htaccess oder stellt es ausserhalb von http docs.

      Richtig.

      Btw. Und was wenn die 404er durch deine Dusseligkeit verursacht sind?

      Das sollte man schon daran erkennen, *welche* Ressourcen da angefordert und nicht gefunden werden. Hier sehen die Protokolleinträge nicht so aus, als ob die angeforderten Dokumente zu einer regulären Website gehören ...

      Schönes Wochenende,
       Martin

      --
      Ein guter Lehrer muss seinen Schülern beibringen können,
      eine Frage so zu stellen, dass auch der Lehrer lernen muss,
      um die Frage beantworten zu können.
        (Hesiod, griech. Philosoph, um 700 v.Chr.)
      1. Auf welche Obscurity vertraust du?
        wo siehst du hier irgendeinen Ansatz von Obscurity?

        In diesem Satz des OP:
        "Das würde die Sache für den Scanner deutlich erschweren, oder?"

        Btw. Und was wenn die 404er durch deine Dusseligkeit verursacht sind?
        Das sollte man schon daran erkennen, *welche* Ressourcen da angefordert und nicht gefunden werden. Hier sehen die Protokolleinträge nicht so aus, als ob die angeforderten Dokumente zu einer regulären Website gehören ...

        Der OP sagt:
        "Kann man dem Apache nicht beibringen, dass nach zB 10 Zugriffen mit Fehler von der selben IP die IP für eine Stunde gesperrt werden soll?"

        Ergo vereinfacht. Kann man nach 10 x 404 eine automatisch IP sperren?
        Automatisches Unterscheiden von "absichtlich" fehlenden Ressourcen
        von "unabsichtlich" fehlenden Ressourcen ist keine triviale Sache.

        Darauf bezog sich mein btw.

        mfg Beat

        --
        Selber klauen ist schöner!
      2. Hi,

        Btw. Und was wenn die 404er durch deine Dusseligkeit verursacht sind?

        Das sollte man schon daran erkennen, *welche* Ressourcen da angefordert und nicht gefunden werden. Hier sehen die Protokolleinträge nicht so aus, als ob die angeforderten Dokumente zu einer regulären Website gehören ...

        Wie oft schlagen Anfaenger hier im Forum auf, die ihre Seite mit irgendeinem obskuren Editor gebastelt haben, der dabei froehlich externe Ressourcen von der lokalen Festplatte einbindet ...?

        Soo unwahrscheinlich ist die Vermutung, dass 404er a la "C:/MYSITE_HP/MYSITE_PUBLIC/..." auch daher ruehren koennten(!), also wohl nicht.

        MfG ChrisB

        --
        "The Internet: Technological marvel of marvels - but if you don't know *what* you're lookin' for on the Internet, it is nothing but a time-sucking vortex from hell."
  2. Moin Moin!

    Böse gefragt: WO IST DAS PROBLEM?

    Müll in den Logfiles? Na und? Rotieren, komprimieren, löschen. rotatelogs bzw. logrotate helfen.

    Angriffe wirken? Dann bringt die Sperre auch nichts, denn dann verrammelst Du den Brunnen, wenn das Kind schon reingefallen ist.

    404 Not Found macht dem Apachen zu viel Arbeit? Dann würde ich mal den 386er gegen etwas schnelleres eintauschen. ;-)

    Kann man dem Apache nicht beibringen, dass nach zB 10 Zugriffen mit Fehler von der selben IP die IP für eine Stunde gesperrt werden soll? Das würde die Sache für den Scanner deutlich erschweren, oder?

    IP-Adressen sperren trifft oft auch unschuldige Rechner, das ist nur ein allerletztes Mittel. Sperren sollte das eine Firewall vor dem Webserver, nicht der Webserver selbst (dann ist es schon zu spät).

    Gibt es da ein Modul oder eine Extension oder sowas?

    Was haben Deine Recherchen mit gängigen Suchmaschinen und auf der Apache-Webseite ergeben?

    Alexander

    --
    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
  3. echo $begrüßung;

    Kann man dem Apache nicht beibringen, dass nach zB 10 Zugriffen mit Fehler von der selben IP die IP für eine Stunde gesperrt werden soll? Das würde die Sache für den Scanner deutlich erschweren, oder?

    Was würde sich dadurch vereinfachen? Wenn der Apache nichts findet gibt es einen 404 und gut ist. Der Angriff ging ins Leere. Wenn du deine gewünschte Erweiterung implementiert bekommst, ist bei jedem Zugriff eine Prüfung notwendig. Die ungewünschten Zugriffsversuche werden nicht weniger, dein Apache hat nur sowohl bei gewünschten als auch ungewünschten Zugriffen mehr zu tun.

    echo "$verabschiedung $name";

  4. Hallo,

    Also jetzt bin ich doch überrascht. Ich dachte es sind Experten hier? Der einzige ders in etwa verstanden hat ist Der Martin. Also gut, dann erkläre ich was ich meine:

    Argument, Prüfung braucht Performance:
    Es wird ja nur bei Fehlern (zB 404) geprüft. Das normale ausliefern von Webseiten wird dadurch nicht beeinträchtigt.

    Argument, schütze doch per .htaccess:
    Ja, das tue ich. Aber machen das alle?

    Argument, ich sei zu dusselig und bekomme desshalb 404:
    Hallo? Was ist das für ein Argument und was ist das für ein Tipp? Keine der gemeldeten URL's kommt aus defekten Links oder anderen verweisen. Das kann man doch sehen...

    Argument, "was nützt das"?
    Es wird bergeweise XAMPP Installationen geben (und auch andere) die die Administrationstools (phpMyAdmin, CMS-Admin etc.) noch offen haben. Wenn nun ein Scanner nach 10 Versuchen keine Antwort mehr bekommt, dann ist die Chance, dass eine evtl. tatsächlich bestehende Lücke ausgenutzt wird, viel geringer (wird ja nicht mehr bei den sonst noch folgenden 200 Versuchen entdeckt). Es würde doch allgemein mehr Sicherheit im Internet bringen.

    Naja, mich stören die Einträge nicht. Ich dachte nur, ich könnte "meine Hacker" damit ein wenig ärgern.

    So long,

    Donald

    1. Moin Moin!

      Argument, "was nützt das"?
      Es wird bergeweise XAMPP Installationen geben (und auch andere) die die Administrationstools (phpMyAdmin, CMS-Admin etc.) noch offen haben.

      Daran wirst Du nichts ändern können, auch nicht durch das Blocken von IP-Adressen.

      Wenn nun ein Scanner nach 10 Versuchen keine Antwort mehr bekommt, dann ist die Chance, dass eine evtl. tatsächlich bestehende Lücke ausgenutzt wird, viel geringer (wird ja nicht mehr bei den sonst noch folgenden 200 Versuchen entdeckt).

      Zwei oder drei Versuche reichen vollkommen, und sie kommen nicht notwendigerweise von der selben IP-Adresse. Sehr schön z.B. in http://www.honeynet.org/papers/webapp/index.html nachzulesen.

      Es würde doch allgemein mehr Sicherheit im Internet bringen.

      Nein.

      Naja, mich stören die Einträge nicht. Ich dachte nur, ich könnte "meine Hacker" damit ein wenig ärgern.

      Das sind in aller Regel vollautomatische Angriffe. Wenn Du jemanden ärgern willst, und nebenbei noch Gutes tun willst, sorge dafür, dass der Angreifer möglichst lange mit Deinem Server beschäftigt ist, und währenddessen keinen anderen, möglicherweise angreifbaren Server bearbeiten kann. Antworte unter den typischerweise angegriffenen URLs mit 10 Bytes pro Sekunde, oder antworte mit megabyte-großen, völlig irrelevanten Daten, z.B. aus /dev/urandom, Bibeltexte, Linux-Kernel-Sources, X11 Sources. Wenn Du typische Angriffmuster erkennst, SIMULIERE einen erfolgreichen Angriff, nur um den Angreifer anschließend mit noch mehr Daten vollzumüllen.

      Alexander

      --
      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
    2. echo $begrüßung;

      Also jetzt bin ich doch überrascht. Ich dachte es sind Experten hier? Der einzige ders in etwa verstanden hat ist Der Martin.

      Wie definierst du Experten? Jemand, der dir eine Lösung für dein Problem präsentiert ohne die Sinnhaftigkeit des Unterfangens zu hinterfragen? Ich habe deinen Wunsch sehr wohl verstanden, kenne doch auch ich solche ständigen Versuche.

      Argument, Prüfung braucht Performance:
      Es wird ja nur bei Fehlern (zB 404) geprüft. Das normale ausliefern von Webseiten wird dadurch nicht beeinträchtigt.

      Angenommen, du hast eine ungeschützte Ressource rumliegen, die ein potenzielles Angriffsziel wäre. Diese wird bei einer Nur-404er-Prüfung nicht abgedeckt, weil sie brav mit 200 ausgeliefert wird. Du benötigst also doch bei jedem Request eine Prüfung gegen die Blacklist.

      Argument, schütze doch per .htaccess:
      Ja, das tue ich. Aber machen das alle?

      Nein, aber dagegen kannst du nicht ankommen. Dein Lösungswunsch wird sich weder per Verordnung noch per Default in einer späteren Webserver-Version nennenswert verbreiten. Für ersteres wirst du nicht genügend mitmachende Gesetzgeber finden. Für letzteres werden sich nicht genügend "Experten" finden, die deine Lösung befürworten werden, selbst wenn sie keine konzeptionellen Fehler mehr enthält.

      Argument, "was nützt das"?
      Es wird bergeweise XAMPP Installationen geben (und auch andere) die die Administrationstools (phpMyAdmin, CMS-Admin etc.) noch offen haben. Wenn nun ein Scanner nach 10 Versuchen keine Antwort mehr bekommt, dann ist die Chance, dass eine evtl. tatsächlich bestehende Lücke ausgenutzt wird, viel geringer (wird ja nicht mehr bei den sonst noch folgenden 200 Versuchen entdeckt). Es würde doch allgemein mehr Sicherheit im Internet bringen.

      Bringt es nicht. Denn bei den 10 Versuchen sind garantiert Treffer dabei. Was nützt so ein halber Schutz, wenn man sich dadurch nur zu Unrecht in Sicherheit wiegt? Wenn dieser "Schutzmechanismus" ausreichend verbreitet ist, kennen ihn auch die Angreifer und denken sich was neues aus. Angreifern stehen heutzutage mehr als eine IP-Adresse zur Verfügung. Sie müssen die Angriffe nur auf mehrere Quellen verteilen und haben dann x-mal 10 Versuche. Du beendest das Wettrüsten damit nicht.

      Naja, mich stören die Einträge nicht. Ich dachte nur, ich könnte "meine Hacker" damit ein wenig ärgern.

      Teergruben sind ein schon recht lange bekanntes Mittel, um ungewünschte Anfrager auszubremsen. Ernsthaften Angreifer dürften solche Verteidigungsmittel nicht unbekannt sein, zumal man diese durch einen niedrig gesetzten Timeout auf einfachste Weise in ihrer Wirkung deutlich mildern kann. Eine Teergrube zu programmieren ist dagegen deutlich aufwendiger.

      echo "$verabschiedung $name";

    3. Donald,

      ein weiteres Problem mit deinem Ansatz ist noch, dass durch dein Server unglaublich gut mit einer DOS Attacke angreifbar wird. Geht ein böswilliger Spitzbub hin und scant 10 nichtexistierende Seiten auf deinem Server von sagen wir einer Million unterschiedlichen IP Adressen aus (die IP Pakete kann er ja gestalten, wie er will), sperrt dein Server die besagte Million von Adressen und da werden auch viele deiner erwünschten User dabei sein.

      Wenn du wirklich sauer bist, dann sind Teergruben das beste Mittel, wie es bereits in diesem Thread erwähnt wurde. Sie sind aufwendig zu konstruieren und müssen mit Bedacht am besten nur auf 404 Antworten eingesetzt werden, damit deine liebsten User nicht in die Grube fallen.

      Gruß,
      Cruz

    4. Moin!

      Also jetzt bin ich doch überrascht. Ich dachte es sind Experten hier? Der einzige ders in etwa verstanden hat ist Der Martin. Also gut, dann erkläre ich was ich meine:

      Die Antwort von dedlfix geht vollkommen in die Richtung, die ich dir auch geantwortet hätte. Insofern hast du durchaus Expertenantworten bekommen.

      Argument, Prüfung braucht Performance:
      Es wird ja nur bei Fehlern (zB 404) geprüft. Das normale ausliefern von Webseiten wird dadurch nicht beeinträchtigt.

      Was ist das für ein Argument? Du siehst in deinen Logfiles die automatisierten Scanversuche nach öffentlich erreichbaren Admin-Interfaces. Wenn auf keiner dieser untersuchten URLs ein zugängliches Interface existiert, müllt das dein Logfile zu, ja. Wenn doch eines existiert, wird das nicht im Error-Log auftauchen. Niemand zwingt die Angreifer aber, immer in derselben Reihenfolge zu scannen, d.h. auch die Mechanik "nach 10 verursachten 404ern die IP sperren" garantiert dir keinen Schutz, weil ja durch Zufall auch schon die erste URL ein Treffer sein kann.

      Abgesehen davon sind nicht nur böse Buben Verursacher von 404-Status. Auch Suchmaschinenspider verursachen durchaus absichtlich Requests auf nicht vorhandene Seiten, um das Serververhalten in diesem Fall zu untersuchen: Kommt dann ein 404, oder kommt (aufgrund von falscher Konfiguration etc.) vielleicht ein Redirect auf eine Contentseite?

      Fakt ist: Dein Server kriegt in jedem Fall den Request und muß ihn verarbeiten. Jetzt ist nur die Frage, was man am effektivsten damit macht? Wenn du gesteigertes Interesse an einer Scan-Analyse hast, kannst du dir ja gerne einen Honeypot zusammenschrauben, aber ein produktiver Server sollte solche Requests mit dem minimal möglichen Rechenaufwand beantworten - und das ist in meinen Augen nunmal der 404. Wenn dich das zusätzliche Error-Logfile stört (im Access-Log tauchen die 404-Requests ja auch alle nochmal auf), kannst du das abschalten oder nach /dev/null leiten. Jegliche spezielle Sonderbehandlung von solchen Requests, die Verwaltung einer IP-Blackliste, das notwendige Lookup der IP in der Liste - das sind alles Extraaufgaben, die mindestens so aufwendig sind, wie die direkte Generierung des 404, sie müssen zudem IMMER stattfinden, nicht nur bei 404 (was wäre sonst gewonnen, der IP statt 404 einen anderen Statuscode zu liefern, den Zugriff auf existierende Sicherheitslücken aber zu erlauben) - unter dem Strich belastet das alles den Server mit Extraaufwand, den man sich in Produktivsystemen liebend gern sparen sollte.

      Andererseits: Wer XAMPP unter Windows produktiv einsetzt, handelt ohnehin eher fragwürdig in meinen Augen. XAMPP liefert zweifelsfrei ein sehr leicht installierbares Paket zur Webentwicklung, es ist aber hinsichtlich diverser Defaultwerte (Passworte, Admin-URLs) leicht ausrechen- und angreifbar, wenn man nicht aktiv gegensteuert.

      Argument, schütze doch per .htaccess:
      Ja, das tue ich. Aber machen das alle?

      Was andere auf ihren Servern machen, geht dich nichts an und ist bei dieser Fragestellung auch irrelevant, da du diese anderen Server ja sowieso nicht beeinflussen kannst.

      Argument, "was nützt das"?
      Es wird bergeweise XAMPP Installationen geben (und auch andere) die die Administrationstools (phpMyAdmin, CMS-Admin etc.) noch offen haben. Wenn nun ein Scanner nach 10 Versuchen keine Antwort mehr bekommt, dann ist die Chance, dass eine evtl. tatsächlich bestehende Lücke ausgenutzt wird, viel geringer (wird ja nicht mehr bei den sonst noch folgenden 200 Versuchen entdeckt). Es würde doch allgemein mehr Sicherheit im Internet bringen.

      Dasselbe Argument: Was interessieren dich fremde Server, die du nicht betreust und sichern kannst?

      Naja, mich stören die Einträge nicht. Ich dachte nur, ich könnte "meine Hacker" damit ein wenig ärgern.

      Doch, dich stören die Einträge, sonst hättest du ja den Thread nicht gestartet.

      Kann man ein automatisiertes Scanprogramm ärgern? Ich glaube nicht. Den dahinter sitzenden Hacker interessieren nur die positiven Meldungen, bei allen anderen ist ihm egal, ob der Server 404, 403, 401, 500 oder gar nichts mehr geantwortet hat.

      - Sven Rautenberg

      --
      "Love your nation - respect the others."