Websites herunterladen, die TornadoServer nutzen

Über TornadoServer

Läuft auf einem Host TornadoServer, sagt er das meist selbst, in klaren Worten, in einem Header, den er jeder Antwort mitgibt. Ein Name, der auf diese Weise freiwillig genannt wird, ist ein direkter Beleg und nicht etwas, das aus dem vom Browser geladenen Code erschlossen wird. Das Vertrauen in diesen Eintrag ist deshalb höher als bei einer clientseitigen Bibliothek, und auch die typische Fehlerquelle ist eine andere.

Es lohnt sich, genauer anzusehen, was der Header verrät. Tornado ist ein asynchrones Web-Framework und eine Netzwerkbibliothek, geschrieben in Python. Gebaut ist Tornado für langlebige Verbindungen und hohe Nebenläufigkeit statt für das Rendern von Seiten, und deshalb taucht es hinter Echtzeitfunktionen auf: offen gehaltene Sockets, Streaming-Endpunkte, Benachrichtigungsdienste, Schnittstellen von Geräten und Appliances, interne Dashboards und APIs, die mit etwas anderem als einem Browser sprechen. Antwortet es direkt auf einem öffentlichen Port, ist außerdem kein Reverse Proxy vorgeschaltet, der den Header umschreibt, was für sich genommen schon aufschlussreich ist. Installationen dieser Art sind eher klein, für einen bestimmten Zweck gebaut oder eingebettet und haben seltener die betrieblichen Schichten, die ein großer Bestand an Websites hätte.

Die Herkunft erklärt einen Teil des Musters. Das Framework entstand in einem Startup und wurde 2009 von Facebook (Meta) unter der Lizenz Apache 2.0 als Open Source veröffentlicht, zu einer Zeit, als Python keine überzeugende Antwort auf gleichzeitige Verbindungen hatte. Die Nutzerschaft besteht seit jeher aus Entwicklern, die Dienste bauen, und nicht aus Betreibern, die Websites bauen, weshalb die Kategorie Web servers besser passt, als es jede Kategorie für Inhalte oder E-Commerce täte. Stand Oktober 2026 erkennen wir TornadoServer auf 342 Websites.

An den Versionsdaten zeigt sich, was ein Eintrag für einen Server wert ist. Wir sehen 39 verschiedene Versionen, die antworten, und am häufigsten erfassen wir Version 6.1. Eine so breite Streuung innerhalb eines einzigen Frameworks beschreibt eher Deployment-Gewohnheiten als die Software: Langlebige Dienste werden gebaut, in Container gepackt und dann in Ruhe gelassen, und ein Framework, das jahrelang unauffällig läuft, wird selten nach Plan aktualisiert. Für ein Sicherheitsteam ist ein nach Versionen gekennzeichnetes Inventar öffentlich erreichbarer Dienste ein Werkzeug zur Eingrenzung, denn ein Sicherheitshinweis gilt für einen Versionsbereich, und dieser Bereich muss zu einer Liste von Hosts werden, bevor jemand handeln kann.

Die offensichtliche Einschränkung weist in die andere Richtung als die Versionsdaten. Viele Tornado-Anwendungen laufen hinter einem Proxy oder einem Cloud-Load-Balancer, der den Server-Header ersetzt oder entfernt, und solche Deployments bleiben für uns unsichtbar, ganz gleich, wie stark sie genutzt werden. Unsere Liste ist keine installierte Basis. Unsere Liste ist die Menge der Endpunkte, an denen das Framework selbst Auskunft gibt, und in ihr sind exponierte Dienste über- und verwaltete Produktionsumgebungen unterrepräsentiert.

Genau diese Unterscheidung macht den Export nützlich statt dekorativ. Die Prüfung eines Hosts zeigt, was ein einzelner Server von sich preisgibt. Eine Liste aller Domains, auf denen das Framework geantwortet hat, erlaubt einem Sicherheitsforscher, die Gefährdung über einen Versionsbereich einzugrenzen, einem Infrastrukturanbieter, Teams mit selbst verwalteten Diensten zu finden, die vielleicht einen verwalteten Dienst kaufen würden, und einem Analysten zu messen, wie ein Framework altert, das aus der Mode gekommen, aber noch nicht aus der Produktion verschwunden ist. Keine dieser Fragen lässt sich Hostname für Hostname beantworten.