Analyse des protocoles légers

Traditionnellement, Censys se concentre sur les analyses "approfondies", c'est-à-dire les analyses qui effectuent une analyse complète du service sous-jacent et qui répartissent les valeurs clés dans des champs pouvant faire l'objet de recherches ultérieures. Certains protocoles ont été capturés par des bannières de services "UNKNOWN" et n'ont pas été marqués, ce qui permet de les rechercher, mais difficilement. Par exemple, les serveurs IRC peuvent être trouvés sur Censys Search en recherchant "irc" sur le port 6667. Cela permet de réduire le nombre de services, mais passe à côté de nombreux serveurs IRC qui ne présentent pas "irc" dans leur bannière ou qui ne fonctionnent pas sur le port 6667. Cela donne également quelques faux positifs, certains résultats étant simplement des serveurs HTTP sur le port 6667 qui contiennent l'expression "irc".

De nombreux autres protocoles n'ont pas été pris en compte ; ils ne sont pas suffisamment bavards pour fournir des données de bannière sans une sonde spécifique pour les obtenir. Par exemple, le protocole Printer Job Language (PJL dans Censys Search) est intéressant à voir, mais il ne répond qu'à quelques sondes spécifiques, que Censys n'utilisait pas auparavant pour son port par défaut de 9100. Pour nous, cela inclut tous les protocoles UDP, puisque nous ne collectons aucune sorte de données de bannière sur les ports UDP. En outre, dans certains cas de protocoles basés sur TCP, Censys n'a pas encore analysé le port sur lequel ces services fonctionnent généralement.

Censys a entrepris d'accroître sa couverture protocolaire en juin et a commencé à étiqueter les données des bannières qui pouvaient être attribuées à un protocole particulier. Nous avons découvert des services qui n'étaient pas présents dans nos données. La plupart des protocoles que nous avons cherché à ajouter étaient très simples à détecter par rapport à la nuance associée à l'analyse d'un protocole comme le DNS. Le principal obstacle à leur ajout a été l'infrastructure requise pour ajouter la prise en charge d'un nouveau protocole, qui a été conçue en partant de l'hypothèse que les analyses seraient des opérations complexes, consistant en de nombreux paquets envoyés dans les deux sens pour extraire les différents champs de données que Censys souhaite exposer. Dans notre nouveau cas, nous voulions envoyer une sonde très basique et effectuer une comparaison avec la réponse.

Pour répondre à ce nouveau scénario, Censys a mis en œuvre un cadre d'analyse de protocole "léger" au-dessus de notre moteur d'analyse existant. Ce cadre nous a permis d'ajouter rapidement et facilement la prise en charge de nouveaux protocoles sans écrire de code. Nous pouvions spécifier le port et la méthode de balayage dans un fichier de configuration, l'ajouter à la liste des sondes existantes et être en mesure d'ajouter la prise en charge complète d'un nouveau protocole en une heure, ce qui réduisait le temps de développement (souvent) de plusieurs jours nécessaire à l'ajout de ces protocoles dans le cadre existant.

Grâce à ce nouveau cadre, Censys a pu faire passer le nombre de protocoles pris en charge par notre scanner de 40 à 78 en seulement deux jours de hackathon. La majeure partie du travail effectué pour ajouter ces protocoles n'a pas consisté à écrire du code ou à câbler des choses, mais à décider quels protocoles seraient les plus utiles à ajouter à la plateforme et à en prendre l'empreinte. Nous avons repris cet effort pour porter le nombre de protocoles de 78 à 100.

Priorités

Nous avons réduit le nombre de protocoles que nous allions ajouter à partir d'une longue liste de protocoles possibles. Nous avons donné la priorité à l'ajout de protocoles entrant dans l'une de ces catégories :

1. Protocoles indiquant un problème évident. Par exemple, Kerberos, ARD, ATG, Andromouse.
2. Protocoles de base de données (Cassandra, Zookeeper, Bolt)
3. Protocoles de contrôle industriel (GE_SRTP, PCWORX, FINS...)
4. Des protocoles qui étaient tout simplement... cool ! (et qui ne nécessitaient pas beaucoup d'efforts pour disséquer le protocole). Par exemple, Terraria, QOTD, Teamspeak.

Des avantages rafraîchissants

Nous exposons les données relatives à ces nouveaux protocoles de la même manière que nous le ferions pour une bannière "inconnue" - la seule différence se situe au niveau du champ service_name. Ceci peut être vu en regardant la vue de la table pour un hôte dans la recherche. Notez que les champs de données sont appelés banner_grab bien qu'il s'agisse d'un serveur Murmur.

Auparavant, nous n'exposions pas les données relatives aux services de cette manière. Chaque service ajouté avait un nouveau champ et format dédié (par exemple, services.openvpn), qui était alors permanent. Il était donc difficile d'ajouter une sonde "temporaire". Nous nous serions engagés à supporter un champ pour toujours. Comme nous disposons d'un champ dédié (banner_grab) pour toutes les sondes "légères", nous sommes désormais en mesure d'ajouter une sonde temporaire que nous pouvons supprimer plus tard si elle n'apporte plus de valeur. En outre, cela a permis de modifier les données, car il n'est plus nécessaire de changer les noms des chemins de recherche, mais seulement de modifier la valeur du nom du service. Nous avons déjà dû faire cela lors de notre premier sprint d'ajout de protocole. Nous avons ajouté une sonde pour "RDP_UDP" et avons décidé qu'il serait préférable d'appeler cette sonde RDP. Nous avons renommé le service dans notre fichier de configuration, et les noms problématiques ont été filtrés et remplacés par le nom le plus sensé.

Nouveaux protocoles

Vous trouverez ci-dessous un tableau de tous les services que Censys scanne actuellement, et le nombre de chacun d'entre eux que nous avions sur Internet en date du 2021-08-16. Ces chiffres peuvent varier considérablement, mais en général, ils restent à peu près les mêmes par ordre de popularité. En vert figurent les protocoles que nous avons ajoutés au cours des huit dernières semaines en utilisant le nouveau cadre de recherche. Ce rapport a été généré à l'aide de la fonction de rapport de Search 2.0. Nous avons ajouté manuellement Andromouse ici, car nous ne voyons pas de services actifs pour ce protocole pour le moment.

nom_du_service	compter
HTTP	751232939
INCONNU*	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
PME	1300404
VNC	1053140
POSTGRES	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
RECHERCHE D'ÉLASTIQUES	34844
IKETTLE	32530
FOX	26336
IRC	24184
VALVE	24061
ARD	20990
CHARGEN	17470
MURMUR	16860
IDENT	16490
GARDIEN DE ZOOS	15992
BACNET	14391
QOTD	13138
KAFKA	12155
SKINNY	10486
NETIS	9070
ICAP	7984
WDBRPC	7884
PJL	7732
PC_ANYWHERE	7297
S7	7027
PIE	6317
TEAM_VIEWER	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