Configuration du port SMB DCE

L’inspecteur binder configure le port SMB DCE. Pour obtenir plus d'informations, reportez-vous à la Présentation de l’inspecteur de binder.

[
   {
       "when": {
           "role":"any",
           "service":"netbios-ssn",
           "ports": ""
       },
        "use": {
            "type":"dce_smb"
       }
   }
]

max_frag_len

Spécifie la longueur maximale des fragments (en octets) pour la défragmentation. Pour traiter les fragments de grande taille, l’inspecteur analyse le contenu du paquet jusqu’à la taille spécifiée avant de le défragmenter.

Remarque

La valeur spécifiée dans ce paramètre doit être supérieure ou égale à la profondeur d’analyse nécessaire aux règles pour assurer la détection. Pour que toutes les données soient soumises à la détection, utilisez la valeur par défaut.

Type : entier

Plage valide : de 1 514 à 65 535

Valeur par défaut : 65 535

smb_max_compound

Spécifie le nombre maximal de commandes à traiter dans une demande SMB.

Type : entier

Plage valide : de 0 à 255

Valeur par défaut : 3

smb_max_chain

Spécifie le nombre maximal de commandes SMB AndX en chaîne autorisé. En règle générale, plusieurs commandes AndX en chaîne représentent un comportement anormal et peuvent indiquer une tentative d’évitement. Spécifiez 1 pour n’autoriser aucune commande en chaîne ou 0 pour désactiver la détection du nombre de commandes en chaîne.

L’inspecteur dce_smb commence par compter le nombre de commandes en chaîne et génère un événement si les règles associées de l’inspecteur SMB sont activées et que le nombre de commandes en chaîne est égal ou supérieur à la valeur configurée. Le traitement se poursuit ensuite.

Vous pouvez activer la règle 133:20 afin de générer des événements et, dans le cadre d’un déploiement en ligne, abandonner les paquets incriminés en lien avec ce paramètre.

Type : entier

Plage valide : de 0 à 255

Valeur par défaut : 3

disable_defrag

Spécifie s’il faut défragmenter le trafic DCE/RPC fragmenté. Lorsqu’il est activé, l’inspecteur dce_smb détecte les anomalies et envoie les données DCE/RPC au moteur de règles, mais au risque de manquer des exploits dans les données DCE/RPC fragmentées.

Bien que le paramètre disable_defrag permette de ne pas défragmenter le trafic et d’accélérer le traitement, il convient de noter que la plupart des exploits DCE/RPC tentent de tirer parti de la fragmentation pour dissimuler leur présence. L’activation de ce paramètre contournerait la plupart des exploits connus, ce qui entraînerait un grand nombre de faux négatifs.

Type : booléen

Valeurs valides : true, false

Valeur par défaut : false

limit_alerts

Indique si les alertes DCE doivent être limitées à un maximum d’une par signature et par flux.

Type : booléen

Valeurs valides : true, false

Valeur par défaut : true

reassemble_threshold

Spécifie le nombre minimal d’octets qui doivent être mis en file d’attente dans les tampons de désegmentation et de défragmentation DCE/RPC avant d’envoyer un paquet réassemblé au moteur de règles. Ce paramètre est particulièrement utile en mode en ligne, car il peut permettre de détecter un exploit à un stade précoce, avant qu’une défragmentation complète ne soit effectuée.

Notez qu’une valeur faible augmente la probabilité d’une détection précoce, mais peut avoir un impact négatif sur les performances. Si vous activez ce paramètre, vous devez tester son incidence sur les performances.

La valeur 0 désactive le réassemblage.

Type : entier

Plage valide : de 0 à 65 535

Valeur par défaut : 0

politique

Spécifie l’implémentation Windows ou Samba DCE/RPC utilisée par les hôtes ciblés sur votre segment de réseau supervisé.

Type : énumération

Valeurs valides : une chaîne sélectionnée dans la liste suivante : Win2000, WinXP, WinVista, Win2003, Win2008, Win7, Samba, Samba-3.0.37, Samba-3.0.22, Samba-3.0.20

Valeur par défaut : WinXP

smb_max_credit

Spécifie le nombre maximal de demandes en attente.

Type : entier

Plage valide : de 1 à 65 536

Valeur par défaut : 8 192

smb_file_depth

Spécifie le nombre d’octets inspectés lorsqu’un fichier est détecté dans le trafic SMB, en commençant à l’emplacement spécifié par l’option de règle IPS file_data (décrite dans la documentation ouverte (Open Source) de Snort 3, disponible à l’adresse https://www.snort.org/snort3).

Spécifiez -1 pour désactiver l’inspection des fichiers.

Spécifiez 0 pour une inspection de fichiers illimitée.

Type : entier

Plage valide : de -1 à 32 767

Valeur par défaut : 16 384

Lorsqu’un fichier est détecté dans le trafic SMB, le paramètre smb_file_ depth indique le nombre d’octets de données de fichier que l’inspecteur examinera à partir du pointeur défini dans l’option de règle IPS file_data. Pour inspecter le type de fichier et la signature, dce_smb utilise les paramètres enable_type, type_depth, enable_signature et signature_depth définis dans l’inspecteur file_id. Pour plus de renseignements sur l’inspecteur file_id, consultez la documentation ouverte (Open Source) de Snort, disponible à l’adresse https://www.snort.org/snort3.

memcap

Spécifie la limite maximale de mémoire (en octets) allouée à l’inspecteur. Lorsque le plafond de mémoire est atteint ou dépassé, l’inspecteur dce_smb supprime les données les moins récemment utilisées pour libérer de l’espace.

Type : entier

Plage valide : de 512 à 9 007 199 254 740 992 (maxSZ)

Valeur par défaut : 8 388 608

smb_fingerprint_policy

L’inspecteur détecte la version de Windows ou de Samba identifiée dans les demandes et réponses de Session Setup AndX. Lorsque la version détectée est différente de la version de Windows ou de Samba configurée pour le paramètre policy de l’inspecteur, la version détectée remplace la version configurée, mais seulement pour la durée de la session en cours.

Par exemple, si vous définissez policy sur Windows XP et que l’inspecteur détecte Windows Vista, il utilise une politique Windows Vista pendant cette session. Les autres paramètres restent en vigueur.

Type : énumération

Valeurs valides : none, client, server ou both

• Utilisez client afin d’inspecter le trafic serveur-client pour le type de politique.

• Utilisez server afin d’inspecter le trafic client-serveur pour le type de politique.

• Utilisez both afin d’inspecter le trafic serveur-client et client-serveur pour le type de politique.

• Utilisez none pour désactiver l’inspection de la version de Windows ou de Samba.

Valeur par défaut : none

smb_legacy_mode

Lorsque smb_legacy_mode est défini sur true, le système n’applique les règles de prévention des intrusions SMB qu’au trafic SMB version 1, tandis que les règles DCE/RPC ciblent le trafic DCE/RPC utilisant SMB version 1 comme protocole de transport.

Lorsque smb_legacy_mode est défini sur false, le système applique les règles de prévention des intrusions SMB au trafic utilisant les versions 1 et 2 de SMB, et :

• Concernant les versions 7.0 et 7.0.x, le système n’applique les règles de prévention des intrusions DCE/RPC au trafic DCE/RPC utilisant SMB comme protocole de transport que pour la version 1 de SMB.

• Concernant les versions 7.1 et ultérieures, le système applique les règles de prévention des intrusions DCE/RPC au trafic DCE/RPC utilisant SMB comme protocole de transport pour les versions 1 et 2 de SMB.

Type : booléen

Valeurs valides : true, false

Valeur par défaut : false

valid_smb_versions

Spécifie les versions de SMB à inspecter. Utilisez un espace comme séparateur entre les différentes versions de SMB.

Type : chaîne

Valeurs valides : v1, v2, v3, all

Valeur par défaut : all

Activez les règles de l’inspecteur dce_smb pour générer des événements et, dans un déploiement en ligne, supprimer les paquets incriminés.

dce_iface

Spécifie les éléments suivants, séparés par des virgules :

• L’UUID d’une interface de service.

• La version de l’interface (facultatif). Le paramètre par défaut correspond à n’importe quelle version.

• Un indicateur permettant de déterminer si une règle doit trouver une correspondance sur n’importe quel fragment d’une demande (facultatif). Par défaut, la règle ne s’applique qu’au premier fragment.

Dans le cadre du protocole DCE/RPC, un client doit établir une liaison avec un service avant de pouvoir l’appeler. Lorsqu’un client envoie une demande de liaison au serveur, il peut spécifier une ou plusieurs interfaces de service. Chaque interface est représentée par un UUID, et chaque UUID d’interface est associé à un index unique (ou ID de contexte) que les demandes futures peuvent utiliser pour référencer le service appelé par le client. Le serveur répond en indiquant les UUID d’interface qu’il considère comme valides et permet au client d’adresser des demandes à ces services. Lorsqu’un client effectue une demande, il spécifie l’ID de contexte afin que le serveur sache à quel service la demande est adressée.

L’option de règle dce_iface permet à une règle de demander à l’inspecteur si le client a établi une liaison avec un UUID d’interface donné et si la demande du client est destinée à cette interface. Cela peut éliminer les faux-positifs lorsque plusieurs services sont associés avec succès, car l’inspecteur peut corréler l’UUID de liaison à l’ID de contexte utilisé dans la demande.

L’option dce_iface requiert que l’inspecteur assure le suivi des demandes Bind et Alter Context du client ainsi que des réponses Bind Ack et Alter Context du serveur dans le cadre du DCE/RPC orienté connexion. Pour chaque demande Bind et Alter Context, le client spécifie une liste d’UUID d’interface ainsi qu’un identifiant (ou ID de contexte) pour chaque UUID d’interface qui sera utilisé pendant la session DCE/RPC pour référencer l’interface. La réponse du serveur indique les interfaces auxquelles il autorise le client à adresser des demandes. Il approuve ou refuse la liaison du client à une interface donnée. Ce suivi permet de mettre en corrélation l’ID de contexte d’une demande avec l’UUID de l’interface qu’il représente lors du traitement.

L’option de règle dce_iface trouve une correspondance si :

• l’UUID de l’interface spécifiée correspond à l’UUID de l’interface (telle qu’elle est désignée par l’ID de contexte) de la demande DCE/RPC,

et

• l’argument version n’est pas fourni, ou l’argument version est fourni et correspond à l’UUID de l’interface de la demande DCE/RPC,

et

• l’argument any_frag est fourni, ou l’argument any_frag est absent et l’option dce_iface correspond aux critères d’UUID et de version du fragment de demande initial.

Exemples :

dce_iface:4b324fc8-1670-01d3-1278-5a47bf6ee188;

dce_iface:4b324fc8-1670-01d3-1278-5a47bf6ee188, <2;

dce_iface:4b324fc8-1670-01d3-1278-5a47bf6ee188,any_frag;

dce_iface:4b324fc8-1670-01d3-1278-5a47bf6ee188, =1, any_frag;

dce_iface.uuid

Dans une demande DCE/RPC, il est possible de spécifier si les UUID sont représentés en gros boutiste ou en petit boutiste. La représentation de l’UUID de l’interface dans une demande est différente selon le boutisme spécifié. L’inspecteur dce_rpc normalise l’UUID. Cela signifie que la spécification de l’UUID dans l’option de règle dce_iface doit être écrite de la même manière, quel que soit le boutisme de la demande.

Par exemple, un UUID serait représenté comme suit dans une demande de liaison petit boutiste :

|f8 91 7b 5a 00 ff d0 11 a9 b2 00 c0 4f b6 e6 fc|

et ce même UUID serait représenté comme suit dans une demande de liaison gros boutiste :

|5a 7b 91 f8 ff 00 11 d0 a9 b2 00 c0 4f b6 e6 fc|

Dans les règles Snort 3 qui emploient l’option dce_iface, l’UUID doit être représenté en gros-boutiste sous forme de chaîne, quel que soit le boutisme de la demande :

5a7b91f8-ff00-11d0-a9b2-00c04fb6e6fc

Type : chaîne

Syntaxe : dce_iface: <UUID>;

Valeurs valides : où  l’UUID est composé de 32 chiffres hexadécimaux, affichés en cinq groupes séparés par des traits d’union, sous la forme xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Exemples : dce_iface: 5a7b91f8-ff00-11d0-a9b2-00c04fb6e6fc;

dce_iface.version

Une version est associée à chaque interface de service. Certaines versions peuvent ne pas être vulnérables à certains exploits. Par conséquent, vous pouvez spécifier un ou plusieurs numéros de version dans l’option dce_iface pour déterminer s’il est nécessaire de rechercher la présence d’un exploit particulier.

Type : intervalle

Syntaxe : dce_iface: <range_operator><positive integer>; ou dce_iface: <positive integer><range_operator><positive integer>;

Valeurs valides : un ensemble d’un ou plusieurs numéros de version positifs et un opérateur range_operator, comme spécifié dans le tableau Formats de plages.

Exemples : dce_iface: =6;

dce_iface.any_frag

Une demande DCE/RPC peut être divisée en un ou plusieurs fragments. Des indicateurs sont définis dans l’en-tête DCE/RPC pour déterminer si le fragment actuel correspond au premier fragment, à un fragment intermédiaire ou au dernier fragment de la demande. La mise en œuvre de nombreuses vérifications de données au sein de la demande DCE/RPC n’est pertinente que si la demande DCE/RPC porte sur un premier fragment (ou une demande complète). Ainsi, les fragments qui suivent le premier fragment contiennent des données situées plus loin dans la demande DCE/RPC. Par exemple, une règle conçue pour examiner les cinq premiers octets de la demande (comme un champ de longueur) ne fonctionnera pas correctement si elle est appliquée à un fragment autre que le premier, car les données recherchées ne s’y trouveront pas. Le début des fragments suivants est décalé d’une certaine longueur par rapport au début de la demande. Cela peut être une source de faux-positifs dans le trafic DCE/RPC fragmenté.

De ce fait, l’inspecteur DCE/RPC est configuré par défaut pour ne cibler que le fragment initial d'une demande. Pour forcer l’inspecteur à examiner tous les fragments d’une demande afin de trouver une correspondance, ajoutez any_frag à l’option de règle dce_iface. Notez qu’une demande DCE/RPC défragmentée est considérée comme une demande complète.

Syntaxe : dec_iface: any_frag;

Exemples : dce_iface: any_frag;

dce_opnum

Établit une correspondance avec un numéro d’opération d’appel RPC DCE, une plage de numéros d’opération ou une liste de numéros d’opération. Cette option représente un ou plusieurs appels de fonction spécifiques qui peuvent être adressés à une interface. Une fois qu’un client a établi une liaison avec une interface de service donnée et lui a envoyé une demande, des règles doivent déterminer l’appel de fonction que le client adresse au service pour y rechercher la présence d’éventuels exploits. Les appels de fonctions sont spécifiés sous la forme d’une liste de numéros d’opération (opnums) entre guillemets doubles.

Type : chaîne

Syntaxe : dce_opnum: <opnum_list>;

Où opnum_list correspond à l’un des éléments suivants :

• Un seul entier

• Une liste d’entiers séparés par des virgules

• Une plage d’entiers spécifiés avec un trait d’union séparant le nombre le plus petit et le nombre le plus grand de cette plage

• Une combinaison des éléments ci-dessus

Valeurs valides : une liste d’opnums de demande DCE/RPC.

Exemples :

dce_opnum: "15";

dce_opnum: "15-18";

dce_opnum: "15, 18-20";

dce_opnum: "15, 17, 20-22";

dce_stub_data

Cette option place le curseur de détection (utilisé pour parcourir la charge utile des paquets lors du traitement des règles) au début des données de stub DCE/RPC, quelles que soient les options de règles précédentes. Cette option s’applique si des données de stub DCE/RPC sont présentes.

Syntaxe : dce_stub_data;

Exemples : dce_stub_data;