Missbrauch von Diensten durch Malware

  • Moin,


    ich stehe vor einem interessantem Problem.
    Mein "kleiner" API Service http://ip.anysrc.net wird seit einigen Wochen gut besucht.


    In den letzten 24 Stunden 12.431.956 Hits von 2.185.354 eindeutigen IP Adressen. Ich habe das ganze mit NGINX, Caches und Begrenzung der Anzahl an Requests pro IP recht gut in den Griff bekommen.


    Nun habe ich mit etwas Suchaufwand raus bekommen, wo das "Interesse" herkommt. Der Dienst wird von diverser Malware verwendet. Als erste Gegenmaßnahme habe ich jetzt einfach erst mal alle Aufrufe ohne einen Useragent (Header fehlt, macht 90% des Traffics aus) im NGINX geblockt.


    Allerdings wird das nur eine temporäre Lösung sein, bis die Penner entsprechend Anpassungen vorgenommen haben.


    Wie seht ihr das? Ich war bisher nie einer so großen Last ausgeliefert und sehe es eigentlich auch nicht ein aufzurüsten. Im Zweifelsfall verschiebe ich den Dienst auf eine separate VM und reglementiere das ganze so, dass die meisten User einfach nur nen "Bad Request" bekommen. Nur dann könnte ich den Dienst auch gleich ganz einstellen.


    Irgendwelche Ideen?


    Man kann die Malware aktuell nur am fehlenden Useragent erkennen.
    Ansonsten gibt es keine Auffälligkeiten.

  • Wie wäre es, wenn Du eine vorherige Registrierung erzwingst? Der Aufruf funktioniert nachher nur noch mit einem persönlichen Token. Das erzeugt zwar auch Last zur Überprüfung, Du könntest den Übeltäter aber schneller blockieren, wenn der Token woanders fix hinterlegt ist und er ihn nicht direkt ändern kann. So könntest Du auch ein Ratelimit pro Account festlegen und die Registrierung beliebig einschränken.


    Das ganze x Wochen vorher ankündigen und danach umschalten auf Token-Only.



    MfG Christian

  • Könnte man machen, ja.


    Allerdings würde da auch der administrative Aufwand steigen. Denn man muss das ganze ja auch ein bisschen im Auge behalten. Entweder man muss jeden User manuell freischalten oder man muss die Anzahl der Registrierungen im Auge behalten.


    Das Projekt gibt es schon mehrere Jahre, und bisher lief das immer brav "unbeobachtet".


    Wäre halt doof da jetzt was daraus zu machen, um was man sich kümmern muss.

  • Das ist ja kein Missbrauch an sich, dein Dienst scheint einfach nur gut benutzbar zu sein. Ich würde mich glaube ich geschmeichelt fühlen und eventuell eine Lösung wie Cloudflare davor schalten, um einen Teil der Requests zu filtern. ;)

  • Das ist ja kein Missbrauch an sich, dein Dienst scheint einfach nur gut benutzbar zu sein. Ich würde mich glaube ich geschmeichelt fühlen und eventuell eine Lösung wie Cloudflare davor schalten, um einen Teil der Requests zu filtern. ;)

    Naja, funktionieren tut er aktuell nur, weil 80% des Traffics nicht zur Anwendung durch kommen sondern vom NGINX weggefiltert werden. Heute morgen haben 2/3 der Anfragen einen Bad Request bekommen.


    Zum Captcha: Naja, auch nur wieder Kampf gegen Windmühlen...

  • Ich schmunzel ja darüber ein wenig mit dem Gedanken, dass der Dienst ja anscheinend von einem Botnet/Malware genutzt um die externe IP-Adresse festzustellen. Warum nicht einfach bei falschen Abfragen (ohne Agent) einfach zufällige eine IP-Adresse aus dem Adressraum verschiedener "Nationaler Sicherheitsbehörden" ausgeben? :D


    Der Captcha-Vorschlag klingt okay, es kommt nur auf die Art an, ich meine mich aber noch an Gespräch im IRC erinnern zu können dass der Dienst ja auch mit curl Abrufbar sein soll, was ja dann nicht mehr gegeben ist.


    Hast du feststellen können woher der Traffic hauptsächlich kommt? Anschlussart und Region?

  • Ich schmunzel ja darüber ein wenig mit dem Gedanken, dass der Dienst ja anscheinend von einem Botnet/Malware genutzt um die externe IP-Adresse festzustellen. Warum nicht einfach bei falschen Abfragen (ohne Agent) einfach zufällige eine IP-Adresse aus dem Adressraum verschiedener "Nationaler Sicherheitsbehörden" ausgeben? :D

    Ich denke da werde ich die Arschkarte bekommen, da an mich einfacher ranzukommen ist als an die Malware-Autoren oder die Anschlussinhaber. Außerdem wird das "Nullrouten" über "Kein Useragent" eh nicht lange funktionieren. Der Spuk wird bald mit normalen Mozilla Useragents von vorne los gehen.


    Der Captcha-Vorschlag klingt okay, es kommt nur auf die Art an

    Der Captcha Ansatz würde nur zusammen mit einer "Userverwaltung" und entsprechenden Limit Auswertungen funktionieren. Was wieder zusätzlich Last erzeugen würde. Außer ich bau da ein NGINX Plugin für oder so. --> Zu viel Aufwand, zumindest aktuell


    Hast du feststellen können woher der Traffic hauptsächlich kommt? Anschlussart und Region?

    Ne bin ich noch nicht zu gekommen. Am Wochenende vielleicht, falls der Spuk dann noch nicht vorbei ist.

  • Ich sehe keine Lösung. Malware ist es egal, ob irgendein automatisch generierter Token in einer gesonderten Abfrage angefordert oder gar in aufwändiger Berechnung ermittelt werden muss, da es pro Opfer eine einmalige Angelegenheit auf dessen Rechner ist. Danach kennt die Malware die IP.


    Die einzige denkbare Lösung ist, eine Interaktion zu erfordern. Dann ist aber wahrscheinlich der Sinn des Dienstes dahin.

  • Eventuell gibt es auch folgende Möglichkeit:


    Der NGINX wird mit einer GEO-IP Database ausgestattet. Die Information, aus welcher Region eine Anfrage kommt, wird an die Applikation weitergegeben.
    Der Kanckpunkt:
    Gleichzeitig ist der Webservice nicht mehr unter der bisherigen Domain, sondern unter einer Domain folgenden Formates erreichbar: <Ländercode>.<bisherige_domain>. z.B. de.ip.anysrc.net
    Nur wenn die Domain mit der GEO-IP-Information übereinstimmt, wird eine Antwort gesendet.


    Folglich muss der Anfragende wissen, in welchem Land er sitzt, so dass er eine Antwort erhält. Für jedermann, der nur per Script seine IP abfragen möchte, kein Problem. Für einen Malware schon etwas unpraktisch. Man müsste am besten die Spracheinstellungen des PCs abfragen.


    Aber es gilt (denke ich): der Service muss nur unbequem genug für die Entwickler werden, dann nehmen sie sich einen anderen...



    Was haltet ihr von der Idee?


    Edit: natürlich kann man auch den Pfad und nicht die Domain anpassen ;)

  • So etwas setzt voraus, dass die Geolocation-DB einigermaßen vollständig ist. Das dürfte bei den veralteten 32 Bit breiten IP-Adressen sogar einigermaßen der Fall sein. Hier stellt sich eher die Frage der Aktualität, sonst wird daraus für den Anwender ein lustiges Ratespiel. Sind bei den 128 Bit breiten IP-Adressen die Geolocation-DB vollständig.


    Und es setzt weiterhin voraus, dass der TK-Markt sich auch künftig nach den Landesgrenzen richtet, sonst habe ich als Anwender wieder das lustige Ratespiel.

  • Mit einem Rate-Limit kommt man hier nicht weiter. Egal ob GeoIP oder nicht. Dafür kommen einfach viel zu wenig Requests von der jeweiligen Unique IP.


    Bisher haben die Entwickler nicht nachgezogen, und die meisten Anfragen enden brav in einem 400 Bad Request.


    Sollte sich dies noch mal ändern, werde ich wahrscheinlich die API nur noch mit Authentifizierung erlauben. Ist dann halt so. Lässt sich ja im kleinen Kreis schön ohne weitere Abfragerei direkt im NGINX machen.


    Alternativ hat mir ein Kumpel angeboten das ganze auf seiner Infrastruktur mit 4 dedizierten Servern im Round Robin zu hosten. Juckt mich ja schon in den Fingern... :) Mal schauen wie es so läuft.


    Danke auf jedenfalls für eure Gedanken.

  • Kleines Status Update:


    Vorgestern hat ein einzelner Host so viele Anfragen (10-20 pro Sekunde) geschickt, dass die Platte vom Webserver im Monitoring auf Critical gegangen ist. (Access Log vollgelaufen)


    Ich musste tatsächlich diese eine IP explizit via iptables aussperren. Auch sonst sieht es aktuell immer noch spannend aus:


    Unbenannt.PNG


    HTTP Status 503: Zu viele Anfragen von einzelnen Client

    HTTP Status 500: PHP Backend überlastet

    HTTP Status 400: Anfrage ohne Useragent

    HTTP Status 200: Valide Anfrage, valide Antwort


    Gut 5% der Anfragen werden also beantwortet.

    Irgendwie schon krank. :D