Configuration du port TCP DCE

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

[
   {
        "when": {
            "role": "any",
            "proto": "tcp",
            "service": "dcerpc",
            "ports": ""
        },
        "use": {
            "type": "dce_tcp"
        }
    }
]

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

disable_defrag

Spécifie s’il faut défragmenter le trafic DCE/RPC fragmenté. Lorsque ce paramètre est défini sur true, l’inspecteur détecte toujours les anomalies et envoie les données DCE/RPC au moteur de règles, mais avec un risque accru de manquer les exploits présents dans les données DCE/RPC fragmentées.

Bien que ce paramètre 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.

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

Activez les règles de l’inspecteur dce_tcp 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;