Traditionell hat sich Censys auf "tiefe" Scans konzentriert - Scans, die eine vollständige Analyse des dahinter stehenden Dienstes durchführen und Schlüsselwerte in Felder aufteilen, nach denen später gesucht werden kann. Einige Protokolle wurden von Bannern mit "UNBEKANNTEN" Diensten erfasst und waren einfach nicht gekennzeichnet, so dass sie zwar durchsuchbar, aber nicht leicht zu finden waren. So konnten beispielsweise IRC-Server auf Censys Search gefunden werden, indem man nach "irc" auf Port 6667 suchte. Dies grenzt die Dienste ein, lässt aber viele IRC-Server außer Acht, die "irc" nicht in ihrem Banner haben oder nicht auf Port 6667 laufen. Es gibt auch einige falsch-positive Ergebnisse, bei denen es sich nur um HTTP-Server an Port 6667 handelt, die zufällig den Ausdruck "irc" enthalten.
Viele andere Protokolle wurden ganz ausgelassen; sie sind nicht gesprächig genug, um Bannerdaten zu liefern, ohne dass eine spezielle Sonde sie auslöst. Das Printer Job Language-Protokoll (PJL in Censys Search ) ist zum Beispiel sehr interessant, antwortet aber nur auf einige wenige spezifische Anfragen, die Censys bisher nicht für seinen Standard-Port 9100 verwendet hat. Für uns schließt dies alle UDP-Protokolle ein, da wir keine Bannerdaten über UDP-Ports sammeln. Außerdem hat Censys in einigen Fällen für TCP-basierte Protokolle noch nicht den Port gescannt, auf dem diese Dienste normalerweise laufen.
Censys hat im Juni damit begonnen, die Protokollabdeckung zu verbessern und die Banner-Grabbing-Daten zu markieren, die einem bestimmten Protokoll zugeordnet werden konnten. Wir entdeckten Dienste, die in unseren Daten nicht enthalten waren. Die meisten der Protokolle, die wir hinzufügen wollten, waren sehr einfach zu erkennen, verglichen mit den Feinheiten, die mit dem Scannen eines Protokolls wie DNS verbunden sind. Die größte Hürde bei der Hinzufügung dieser Protokolle war die Infrastruktur, die für die Unterstützung eines neuen Protokolls erforderlich ist. Sie wurde unter der Annahme entwickelt, dass Scans komplexe Vorgänge sind, die aus vielen Paketen bestehen, die hin- und hergeschickt werden, um die verschiedenen Datenfelder zu extrahieren, die Censys offenlegen möchte. In unserem neuen Fall wollten wir eine sehr einfache Prüfung senden und einen Mustervergleich mit der Antwort durchführen.
Um diesem neuen Szenario gerecht zu werden, implementierte Censys ein "leichtgewichtiges" Framework für das Scannen von Protokollen zusätzlich zu unserer bestehenden Scan-Engine. Dieses Framework ermöglichte es uns, schnell und einfach Unterstützung für neue Protokolle hinzuzufügen, ohne Code schreiben zu müssen. Wir konnten den Port und die Methode, mit der gescannt werden sollte, in einer Konfigurationsdatei angeben, sie zur Liste der vorhandenen Sonden hinzufügen und innerhalb einer Stunde die vollständige Unterstützung für ein neues Protokoll hinzufügen.
Mit diesem neuen Framework konnte Censys die Anzahl der von unserem Scanner unterstützten Protokolle in nur einem zweitägigen Hackathon von 40 auf 78 erhöhen. Der Großteil der Arbeit, die in das Hinzufügen dieser Protokolle floss, bestand nicht im Schreiben von Code oder in der Verkabelung, sondern in der Entscheidung, welche Protokolle am wertvollsten für die Plattform wären, und in der Erstellung von Fingerabdrücken für diese. Wir kehrten zu dieser Arbeit zurück, um die Zahl der Protokolle von 78 auf 100 zu erhöhen.
Prioritäten
Wir haben aus einer langen Liste von möglichen Protokollen diejenigen ausgewählt, die wir hinzufügen wollten. Wir haben Protokolle, die in eines dieser Felder passen, nach Priorität geordnet:
- Protokolle, die ein offensichtliches Problem darstellten. Z.B. Kerberos, ARD, ATG, Andromouse
- Datenbankprotokolle (Cassandra, Zookeeper, Bolt)
- Industrielle Steuerungsprotokolle (GE_SRTP, PCWORX, FINS...)
- Protokolle, die einfach... cool waren! (und nicht viel Aufwand beim Sezieren des Protokolls erforderten). Z.B. Terraria, QOTD, Teamspeak
Coole Vorteile
Die Daten zu diesen neuen Protokollen werden auf dieselbe Art und Weise wie bei einem "unbekannten" Bannergrab angezeigt - der einzige Unterschied besteht im Feld service_name. Der einzige Unterschied ist das Feld service_name, das in der Tabellenansicht für einen Host in der Suche zu sehen ist. Beachten Sie, dass die Datenfelder banner_grab genannt werden, obwohl es sich um einen Murmur-Server handelt.
Früher haben wir die Daten der Dienste nicht auf diese Weise offengelegt. Jeder hinzugefügte Dienst hatte ein eigenes Feld und ein eigenes Format (z. B. services.openvpn), das dann dauerhaft war. Dies machte es schwierig, irgendeine Art von "temporärer" Sonde hinzuzufügen. Wir würden uns damit verpflichten, ein Feld für immer zu unterstützen. Da wir ein spezielles Feld (banner_grab) für alle "leichtgewichtigen" Sonden haben, können wir jetzt eine temporäre Sonde hinzufügen, die wir später entfernen können, wenn sie keinen Wert mehr hat. Außerdem war es dadurch möglich, in den Daten die Namen der Suchpfade zu ändern, was nun nicht mehr erforderlich ist, sondern nur noch den Wert des Namens des Dienstes. Wir mussten dies bereits während unseres ersten Sprints zum Hinzufügen von Protokollen tun. Wir fügten eine Sonde für "RDP_UDP" hinzu und beschlossen, dass es besser wäre, diese Sonde einfach RDP zu nennen. Wir benannten den Dienst in unserer Konfigurationsdatei um, und problematische Namen wurden herausgefiltert und durch den sinnvolleren ersetzt.
Neue Protokolle
Nachfolgend finden Sie eine Tabelle mit allen Diensten, nach denen Censys jetzt scannt, und wie viele von ihnen wir im Internet hatten (Stand: 16.08.2021). Diese Zahlen können stark schwanken, aber im Allgemeinen bleiben sie in der Reihenfolge ihrer Beliebtheit ungefähr gleich. Grün sind die Protokolle, die wir in den letzten acht Wochen mit dem neuen Scan-Framework hinzugefügt haben. Dies wurde mit der Berichtsfunktion auf Search 2.0 erstellt. Wir haben Andromouse hier manuell hinzugefügt, weil wir im Moment keine aktiven Dienste dafür sehen.
| dienst_name |
zählen |
| HTTP |
751232939 |
| UNBEKANNT* |
57736598 |
| SSH |
25103704 |
| SMTP |
17031251 |
| FTP |
10060171 |
| NTP |
8178526 |
| IMAP |
7854411 |
| POP3 |
7290299 |
| DNS |
6203423 |
| RDP |
5926254 |
| MYSQL |
4801300 |
| CWMP |
4681776 |
| TELNET |
4188493 |
| PPTP |
3458950 |
| RTSP |
2999565 |
| SNMP |
1683421 |
| OPENVPN |
1549015 |
| PORTMAP |
1539872 |
| NETBIOS |
1504529 |
| SMB |
1300404 |
| VNC |
1053140 |
| POSTGRESSE |
713984 |
| MSSQL |
425856 |
| MQTT |
411738 |
| IPP |
311755 |
| PIGEONHOLE |
280083 |
| REDIS |
278636 |
| SIP |
266511 |
| MDNS |
234625 |
| RSYNC |
200553 |
| AMQP |
178414 |
| XMPP |
176961 |
| TFTP |
163148 |
| MONGODB |
147907 |
| NATPMP |
140234 |
| COAP |
130349 |
| WS_DISCOVERY |
126274 |
| SSDP |
103325 |
| KUBERNETES |
99080 |
| RIPV1 |
85936 |
| ORACLE |
84369 |
| MEMCACHED |
79251 |
| POPPASSD |
75301 |
| UBIQUITI |
74833 |
| KERBEROS |
51294 |
| TEAMSPEAK |
46165 |
| X11 |
44451 |
| PROMETHEUS |
44005 |
| IPMI |
39224 |
| SCCM |
37095 |
| MODBUS |
36720 |
| ELASTICSEARCH |
34844 |
| IKETTLE |
32530 |
| FOX |
26336 |
| IRC |
24184 |
| VENTIL |
24061 |
| ARD |
20990 |
| CHARGEN |
17470 |
| MURMUR |
16860 |
| IDENT |
16490 |
| ZOOKEEPER |
15992 |
| BACNET |
14391 |
| QOTD |
13138 |
| KAFKA |
12155 |
| SKINNY |
10486 |
| NETIS |
9070 |
| ICAP |
7984 |
| WDBRPC |
7884 |
| PJL |
7732 |
| PC_ANYWHERE |
7297 |
| S7 |
7027 |
| EIP |
6317 |
| TEAM_ANSCHAUER |
5778 |
| BITCOIN |
5627 |
| XDMCP |
4905 |
| BOLT |
4811 |
| DIGI |
4481 |
| IEC60870_5_104 |
3508 |
| BEANSTALKD |
3338 |
| SENTINEL |
3315 |
| CITRIX |
2987 |
| RADIUS |
2880 |
| BITTORRENT_TRACKER |
2831 |
| CASSANDRA |
2785 |
| TERRARIA |
2528 |
| DB2 |
2414 |
| CODESYS |
2201 |
| LDAP |
2090 |
| FINS |
1726 |
| STATSD |
1502 |
| ATG |
1126 |
| DNP3 |
705 |
| RETHINKDB |
662 |
| PCWORX |
207 |
| PRO_CON_OS |
101 |
| GE_SRTP |
75 |
| DICT |
27 |
| TORCONTROL |
14 |
| BITTORRENT |
2 |
| HART |
1 |
| ANDROMOUSE |
0 |
*UNBEKANNT ist aus Gründen des Vergleichs mit
"Wie viele Dienste erkennt Censys nicht?"
