1. #1

    Registriert seit
    19.11.2011
    Beiträge
    229
    Thanked 102 Times in 64 Posts

    Standard [Apache/nginx] High Level Honeypot

    Hi,
    ich betreibe aktuell einen Apache Webserver mit nginx als reverse proxy. Auf diesem Server laufen mehrere Webseiten als einzelne vhosts.

    Szenario:
    vhost1 liefert eine reine HTML Seite ohne CMS aus (d.h. kein PHP -> alles statisch). Ich weiß nun, wenn jemand vhost1.de/wp-login.php aufruft, handelt es sich vermutlich, um einen (potentiell gefährlichen) crawler.

    Da ich diesen Crawler nicht auf der Seite haben möchte oder ggf. auch auf anderen Seiten auf meinem Server, würde ich diesen gerne für 12 Stunden aussperren (Keine Connection zulassen oder ggf. redirecten).

    Gibt es so etwas generell schon? d.h. ein modul welchem ich URL pattern geben kann, um folglich events zu triggern (e.g. add ip to iptables).
    Falls nicht, hat jemand eine Idee für einen Ansatz?


  2. The Following User Says Thank You to DANP For This Useful Post:

    Negok (03.09.2016)

  3. #2
    Avatar von DMW007
    Registriert seit
    15.11.2011
    Beiträge
    6.080
    Thanked 9.118 Times in 2.995 Posts
    Blog Entries
    5

    Standard AW: [Apache/nginx] High Level Honeypot

    Was du beschreibst ist kein Honeypot, sondern vom Prinzip her ein Intrusion-Prevention-Systeme (IPS). Sollten von dir keine klarstellenden Einwände kommen, werde ich das Thema daher umbenennen. Für Apache und auch nginx gibt es in der Richtung beispielsweise das Modul mod_security, wobei nginx dafür wie üblich selbst kompiliert werden muss. Es erkennt potenzielle Angreifer anhand verschiedener Muster, beispielsweise NullByte- oder SQL-Injections in URL-Parametern. Diese lassen sich auch um eigene Regeln ergänzen - Im Beispiel deiner wp-login.php etwa so:
    Code:
    SecRule "REQUEST_URI" "wp-login.php" "log,deny,status:404"
    Beim Aufruf dieser Datei liefert der Webserver eine 404 Fehlermeldung und protokolliert das Ereignis. Mit dieser Log kann fail2ban gefüttert werden, und beispielsweise die IP über eine Firewallregel dauerhaft blockieren.

    Wenn der Server ohnehin keine dynamisch generierten Seiten ausliefert frage ich mich nur, wozu das gut sein soll. Die Angriffsfläche ist bereits minimal und lässt sich damit nicht weiter reduzieren. Ressourcentechnisch ist nginx bereits sehr effizient. Ein paar statische Anfragen die ins leere Laufen verbrauchen keine nennenswerten Ressourcen. Selbst in Massen wäre es schwierig, nennenswerte Last zu verursachen, geschweige denn den Server damit down zu bekommen (DoS/DDoS). Wesentlich mehr dürfte dabei der unnötige Umweg über zwei Webserver ins Gewicht fallen. Das macht in der von dir beschriebenen Konstellation keinen Sinn.

    Nginx eignet sich sehr gut zur Auslieferung statischer Inhalte. Durch den Umweg über den Apache als Backend wird unnötiger Overhead erzeugt, das ist eher kontraproduktiv für Performance und Sicherheit. Aber selbst in dieser Konstellation müsstest du schon sehr viele Besucher oder einen sehr kleinen und schlecht konfigurierten Server haben, damit das von der Leistung her spürbare Probleme erzeugt.

    Ich würde ein solches System wenn dann nur als zusätzlichen Sicherheitslayer nutzen. Gerade mit CMS und deren Plugins ist die Qualität des Codes fragwürdig. Schlecht geschriebene Software die z.B. SQL-Injections ermöglicht, gibt es leider selbst heute immer noch recht oft. Und selbst in hochwertigem Code kann mal ein menschlicher Fehler zu Sicherheitsrisiken führen. Der Gedanke so etwas präventiv bereits zu verhindern ist daher sinnvoll, zumindest bei sensiblen Anwendungen. Man sollte sich aber im klaren sein, dass dies potenziell eine weitere Fehlerquelle darstellt. Je nachdem was die Seite/Anwendung macht kann es gut sein, dass fälschlicherweise legitime Anfragen (z.B. Dateiuploads oder bestimmte URLs) blockiert werden. Nach der Einführung eines IPS empfiehlt es sich daher, zumindest alle wichtigen Funktionalitäten zu testen.


  4. The Following User Says Thank You to DMW007 For This Useful Post:

    DotNet (05.09.2016)

  5. #3
    Avatar von Linux
    Registriert seit
    02.11.2018
    Beiträge
    6
    Thanked 1 Time in 1 Post

    Standard AW: [Apache/nginx] High Level Honeypot

    Dein Ansatz ist zudem lückenhaft, da nicht alle Crawler/Bots stupide bestimmte Standard-URLs von Systemen wie Wordpress aufrufen.
    Manche durchsuchen z.B. nur verlinkte Inhalte und wenn man wissen möchte ob dort Wordpress läuft, gibt es oft viel einfachere Methoden (z.B. das Generator-Meta Feld im Quelltext).

    Da du von potenziell gefährlichen Crawlern sprichst, geht es dir vermutlich weniger darum, grundsätzlich alle Bots auszusperren. Bei SEO-Crawlern wäre das ja auch über die robots.txt möglich.
    Für den Apache gibt es mittlerweile Config-Sammlungen wie apache-ultimate-bad-bot-blocker
    Hier wird einfach anhand verschiedener Muster gefiltert, die z.B. von Bots bekannt sind.

    Man sollte sich aber im klaren sein, dass so was auf die Performance geht. Der Apache muss ja bei jedem Request die Listen durcharbeiten, ob etwas matcht.
    Und es ist natürlich bei weitem auch kein vollwertiger "Schutz", wenn man das so nennen kann. Teils basiert die Erkennung auf dem User-Agent, den man wie jeden anderen Header auch beliebig setzen kann.

Ähnliche Themen

  1. Win7 XAMPP Apache Problem
    Von Bazs im Forum Windows
    Antworten: 4
    Letzter Beitrag: 25.06.2013, 00:25
  2. [TUT] Honeypot - Ab jetzt wird verdient !
    Von MoneyMaker im Forum Tutorials
    Antworten: 5
    Letzter Beitrag: 23.12.2012, 19:08
  3. [Apache] Benchmarking mit siege
    Von Devon im Forum Server-Administration
    Antworten: 1
    Letzter Beitrag: 05.09.2012, 21:14
  4. [Artikel] Server Load Balancing (SLB) mit nginx
    Von Devon im Forum Server-Administration
    Antworten: 0
    Letzter Beitrag: 15.08.2012, 23:03
  5. [HowTo] Nginx as reverse Proxy
    Von Ta1lor im Forum Server-Administration
    Antworten: 0
    Letzter Beitrag: 04.02.2012, 15:07

Stichworte

Diese Seite nutzt Cookies, um das Nutzererlebnis zu verbessern. Klicken Sie hier, um das Cookie-Tracking zu deaktivieren.