Leichtgewichtiges Protokoll-Scanning

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:

1. Protokolle, die ein offensichtliches Problem darstellten. Z.B. Kerberos, ARD, ATG, Andromouse
2. Datenbankprotokolle (Cassandra, Zookeeper, Bolt)
3. Industrielle Steuerungsprotokolle (GE_SRTP, PCWORX, FINS...)
4. 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