oxo888oxo: Was ist der User agent Go-http-client/2.0 ?

Hallo

In meinen Server-Logfiles finde ich sehr oft den Useragent Go-http-client/2.0. Ist das ein Bot? Oder ist das was anderes? Macht es Sinn, den bei mir auszusperren?

Gruß Ingo

  1. Hallo oxo888oxo,

    das ist der HTTP-Client aus der Standard-Bibliothek der Programmiersprache Go.

    Was der bei dir tut, kann man aus dem User-Agent nicht schliessen.

    Freundliche Grüße,
    Christian Kruse

    1. Hallo Christian

      Was der bei dir tut, kann man aus dem User-Agent nicht schliessen.

      Bei mir fragt unter anderem diese Ressourcen ab: /wp-admin /well-known/ /uploads /images /files /wso.php, /ee.php, /wp-content, /wp-info, /sett.php, /customize.php, /wp-l0gin.php, /media-admin.php, /wikindex.php, /wp-2020.php, /fox.php, /default.php, /wp-includes, /makhdmax.php, /modules, /mad.php, /clen.php, /marijuana.php, /cp.php, /ws.php, /style.php, /text.php, /customize.php, /sett.php, /wso112233.php, /shell20211028.php, /wp-blog, /autoload_classmap.php, /radio.php, /payout.php, sites/default/files/"

      Gruß Ingo

      1. Hallo oxo888oxo,

        klingt nach einem Script-Kiddie, das nach Schwachstellen sucht. Aber deshalb diesen Client zu sperren dürfte nicht helfen, das ist ein String, den man beliebig verändern kann.

        Die IP zu Bannen hilft zumeist auch nur 24h lang. Solange dein System ordentlich aufgesetzt ist und keine Angriffsfläche bietet, lass ihn scannen. Wenn nicht, sieh es als Chance, Schwachstellen bei Dir zu finden 😉

        Rolf

        --
        sumpsi - posui - obstruxi
        1. Moin,

          wenn solche Zugriffe „nerven“, kann man sie

          • etwas ausbremsen, indem ein HTTP-Status 4xx mit einer kleinen Verzögerung antwortet
          • „bannen“, so lange der Bot ein gleiches und eindeutiges Merkmal bietet (Cookie, IP-Adresse, …)

          Viele Grüße
          Robert

          1. Hallo Robert B.,

            etwas ausbremsen, indem ein HTTP-Status 4xx mit einer kleinen Verzögerung antwortet

            Das ist grundsätzlich eine prima Idee; eigentlich müsste man das so machen, dass man einfach gar nicht antwortet. Problem ist nur, dass man das auf TCP-Ebene lösen muss, weil es sonst auch auf dem eigenen Server Overhead im TCP-Stack erzeugt.

            Ein verzögertes Antworten erzeugt den Overhead dann im Webserver, weil ja ein Request offen ist, bis man antwortet. Dafür braucht's ein sehr leichtgewichtiges Delay-Tool, bzw. eins, das nicht für jeden Request einen eigenen Prozess oder Thread erschafft.

            Gibt's Tools, die einem dabei helfen?

            Rolf

            --
            sumpsi - posui - obstruxi
            1. Hallo Rolf,

              Ein verzögertes Antworten erzeugt den Overhead dann im Webserver, weil ja ein Request offen ist, bis man antwortet.

              Kaum der Rede wert. Lediglich den Verwaltungsoverhead.

              Dafür braucht's ein sehr leichtgewichtiges Delay-Tool, bzw. eins, das nicht für jeden Request einen eigenen Prozess oder Thread erschafft.

              Moderne Webserver starten nicht für jeden Request einen Thread oder, noch schlimmer, einen Prozess. Die arbeiten mit thread pools, in denen die Requests abgearbeitet werden. Und wenn ein Thread auf I/O warten müsste, wird halt solange ein andere Request bedient.

              That said, …

              Gibt's Tools, die einem dabei helfen?

              würde man sowas eher nicht im Webserver lösen. Dafür würde man ein Tool wie fail2ban verwenden.

              Entweder man würde so einen Client nach einem Request auf so eine bekannte Lücke ganz blocken oder man würde ihn mit einem Tool wie dem TARPIT target, dass man mit dem Paket xtables-addons-dkms (Ubuntu & Debian) bekommt, ausbremsen.

              Freundliche Grüße,
              Christian Kruse

      2. /wp-admin /well-known/ /uploads /images /files /wso.php, /ee.php, /wp-content, /wp-info, /sett.php, /customize.php, /wp-l0gin.php, /media-admin.php, /wikindex.php, /wp-2020.php, /fox.php, /default.php, /wp-includes, /makhdmax.php, /modules, /mad.php, /clen.php, /marijuana.php, /cp.php, /ws.php, /style.php, /text.php, /customize.php, /sett.php, /wso112233.php, /shell20211028.php, /wp-blog, /autoload_classmap.php, /radio.php, /payout.php, sites/default/files/

        Der Client ist egal, aber eine netter Teil dieser (und eine lange Liste weiterer) solcher Aufrufe führt nach einer kurzen Auswertung im für 404er zuständigen Skript bei mir (@home) dazu, dass Pakete von derselben IP 60 Minuten lang an der Firewall abprallen. Das gleiche Ereignis findet statt, wenn der falsche HTTP_HOST gesetzt ist…

        Seit heute 00:00 Uhr sind es 45. Gestern waren es 59. Das ist nur scheinbar fast nichts, denn das entlastet den Server: Weil die „Pentester“ sich ganz fix – statt stundenlang herumzuprobieren und doch nur die Logfiles zu füllen – ein anderes (prospektives) Opfer suchen.

  2. Hallo oxo888oxo,

    Grundsätzliche Infos findest Du hier

    Go ist eine von Google entworfene Sprache.

    Die Chance ist daher ganz gut, dass das ein Google Crawler ist. Es könnte aber auch sonst wer sein, der Go verwenden will. Ziemlich sicher ist es kein Browser, sondern ein anderes Programm, das HTTP-Requests macht.

    Rolf

    --
    sumpsi - posui - obstruxi
    1. Hallo Rolf,

      Die Chance ist daher ganz gut, dass das ein Google Crawler ist.

      Nein, das denke ich nicht. Go ist eine der am häufigsten benutzten Sprachen, du hast also eine sehr große Menge an Usern. Und Google gibt sich eigentlich als GoogleBot oder als Browser aus.

      Allein aus dem User-Agent auf Google zu schliessen ist nicht möglich.

      Freundliche Grüße,
      Christian Kruse