2 votes

Sources (protocoles) pour les échecs d'audit (ID d'événement 4625) dans le journal des événements de Windows

J'ai une machine virtuelle Windows Server 2016 accessible au public. Le port du bureau à distance a été changé de sa valeur par défaut à un nombre supérieur à 20 000.

Il n'y a rien d'intéressant hébergé sur cette machine virtuelle. Je l'utilise simplement comme un banc d'essai pour le développement de logiciels.

Cependant, je reçois toujours des échecs d'audit quotidiens (ID d'événement 4625) dans le journal des événements Windows.

L'adresse réseau source est généralement en Europe (je suis aux États-Unis et aucun trafic d'utilisateur n'est attendu en provenance d'Europe ou d'ailleurs. Comme je l'ai mentionné ci-dessus, la machine virtuelle n'héberge pas vraiment grand-chose, mais IIS est en cours d'exécution). Les noms d'utilisateur semblent provenir d'une sorte de dictionnaire de noms souvent utilisés, y compris des comptes par défaut de Windows comme Administrateur (qui a été renommé sur ma machine virtuelle)

Y a-t-il un moyen de savoir quel protocole ils utilisent? C'est-à-dire, s'agit-il du Bureau à distance ou pourrait-il s'agir de quelque chose d'autre (essayent-ils de parcourir des partages réseau? Je n'en ai pas créé)? Je ne peux pas le dire en regardant le journal des événements.

Avant de changer le port du Bureau à distance par défaut pour un nombre compris dans la plage des 20 000 et plus, je ne serais pas surpris que ce soit le Bureau à distance. Mais maintenant, je trouve cela difficile à croire. Est-ce que quelqu'un scannerait vraiment tous les ports jusqu'à 20 000 et plus juste pour trouver un port du Bureau à distance ouvert sur une adresse IP aléatoire?

2voto

Ryan Ries Points 54671

Si vous voulez vraiment savoir, vous pouvez utiliser la Stratégie d'Audit Avancée et activer l'audit pour le Pare-feu Windows. Vous pouvez le configurer pour enregistrer les événements de sécurité chaque fois qu'une connexion est autorisée (et/ou refusée) à travers le pare-feu Windows.

Cela étant dit, vous ne devriez jamais mettre un hôte directement sur internet sans savoir exactement quels sont les ports du pare-feu ouverts. Par exemple, vous devriez utiliser soit le pare-feu Windows soit le pare-feu fourni par le réseau Azure et vous assurer que seul votre port de RDP personnalisé à numéro élevé est exposé. Ainsi, il n'y a aucun doute que chaque fois que quelqu'un accède à votre serveur, vous savez que le protocole doit être RDP car vous savez que c'est le seul port ouvert.

wfp audit

Si vous ne voulez pas activer l'audit du pare-feu Windows, vous pouvez également jeter un œil à l'observateur d'événements RemoteDesktopServices-RdpCoreTS. Il enregistre également les tentatives de connexion avec les adresses IP.

rdp log

Et oui, les gens scannent des hôtes sur internet depuis aussi longtemps qu'il y a un internet. Juste pour voir ce qui existe.

0 votes

À ma surprise, en vérifiant le journal d'événements RemoteDesktopServices-RdpCoreTS, j'ai confirmé que toutes les erreurs d'audit étaient des tentatives de connexion RD échouées. Est-ce que cela signifie qu'ils ont réellement essayé le bon port? Ou est-ce qu'une entrée serait générée même si le mauvais port (par défaut) était utilisé? De plus, le pare-feu Windows est activé (bien sûr), mais mon hôte n'offre pas d'autres pare-feu en dehors de cela (comme le font Amazon AWS ou Azure). Je vais me pencher sur la politique d'audit avancée (est-ce qu'elle enregistre également le numéro de port?).

1 votes

Oh, désolé d'avoir mentionné Azure alors - j'ai somehow got l'impression que vous utilisiez Azure IaaS. Anyway, oui ces événements dans le journal Remote Desktop indiquent que les ne'er-do-wells ont découvert votre port RDP personnalisé. :) Cela ne signifie pas qu'ils se sont authentifiés avec succès cependant. Seulement qu'ils ont établi une connexion TCP. Donc utilisez only des mots de passe très forts sur cette boîte. :) De plus, oui l'audit logging mentionne le numéro de port. Ajouté une capture d'écran au post.

0 votes

Je comprends d'où tu viens. Mais réfléchis-y - balayer les ports TCP avec un processus multi-thread peut être très rapide - cela prend quelques secondes. Et une grande partie de ce balayage est probablement effectuée par des machines infectées. Une fois le balayage terminé, ils se retrouveront probablement avec seulement quelques ports. Et une fois qu'un port est déterminé ouvert, ils peuvent assez facilement deviner ce que c'est - ou dans le pire des cas, tenter les protocoles les plus courants. Quels services les serveurs vont-ils probablement fournir? Ce sera probablement RDP, SSH et d'autres protocoles de gestion à distance courants, donc ce sera probablement plus facile que ça en a l'air.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X