Il s’agit d’un exemple de fichier qui comprend des extraits de code JSON expliquant comment personnaliser la politique d’analyse
de réseau pour Snort 3. Vous pouvez choisir de remplacer une configuration de l’inspecteur des manières suivantes :
Avant de choisir l’une de ces options, consultez tous les détails et exemples pour vous aider à définir les remplacements
de politique d’analyse de réseau avec succès. Pour éviter les risques et les erreurs, lisez et comprenez les scénarios fournis
ici.
Si vous choisissez de remplacer une configuration de l’inspecteur dans le menu déroulant Actions, vous devez créer un fichier JSON pour les remplacements de politique d’analyse de réseau, puis téléverser le fichier.
Pour remplacer une configuration d’inspecteur dans la politique d’analyse de réseau, vous devez téléverser uniquement les
modifications dont vous avez besoin. Vous ne devez pas télécharger la configuration complète, car cela rend les remplacements
persistants par nature et, par conséquent, toute modification ultérieure des valeurs ou de la configuration par défaut dans
le cadre des mises à jour des LSP ne sera pas appliquée.
Voici des exemples pour différents scénarios :
Activation d’un inspecteur Singleton lorsque l’état par défaut dans la politique de base est désactivé
{
"rate_filter": {
"enabled": true,
"type": "singleton",
"data": []
}
}
Désactivation d’un inspecteur Singleton lorsque l’état par défaut dans la politique de base est activé
{
"rate_filter": {
"enabled": false,
"type": "singleton",
"data": []
}
}
Activation d’un inspecteur Multiton lorsque l’état par défaut dans la politique de base est désactivé
{
"ssh": {
"enabled": true,
"type": "multiton",
"instances": []
}
}
Désactivation d’un inspecteur Multiton lorsque l’état par défaut dans la politique de base est activé
{
"ssh": {
"enabled": false,
"type": "multiton",
"instances": []
},
"iec104": {
"type": "multiton",
"enabled": false,
"instances": []
}
}
Remplacement de la valeur par défaut de paramètres spécifiques pour l'inspecteur Singleton
{
"normalizer": {
"enabled": true,
"type": "singleton",
"data": {
"tcp": {
"block": true
},
"ip6": true
}
}
}
Remplacement des paramètres spécifiques d’une instance par défaut (lorsque le nom de l’instance correspond au type d’inspecteur)
dans l'inspecteur Multiton
{
"http_inspect": {
"enabled": true,
"type": "multiton",
"instances": [
{
"data": {
"unzip": false
},
"name": "http_inspect"
}
]
}
}
Ajout d’une règle de classeur pour une instance par défaut avec les modifications requises
Remarque
|
Les règles du classeur par défaut ne peuvent pas être modifiées, elles sont toujours ajoutées à la fin.
|
{
"binder": {
"enabled": true,
"type": "binder",
"rules": [
{
"use": {
"type": "http_inspect"
},
"when": {
"role": "server",
"service": "http",
"dst_nets": "10.1.1.0/24"
}
}
]
}
}
Ajout d’une nouvelle instance personnalisée
Remarque
|
L’entrée de règle de classeur correspondante doit être définie dans l’inspecteur de classeur.
|
{
"telnet": {
"enabled": true,
"type": "multiton",
"instances": [
{
"name": "telnet_my_instance",
"data": {
"encrypted_traffic": true
}
}
]
},
"binder": {
"enabled": true,
"type": "binder",
"rules": [
{
"when": {
"role": "any",
"service": "telnet"
},
"use": {
"type": "telnet",
"name": "telnet_my_instance"
}
}
]
}
}
Remplacement d’une instance Singleton, d’une instance par défaut de Multiton et de la création d’une nouvelle instance Multiton
dans un remplacement JSON unique
Exemple pour afficher les éléments suivants dans un seul remplacement JSON :
-
Remplacement d’une instance Singleton (inspecteur du normalisateur)
-
Remplacement d’une instance par défaut de Multiton (inspecteur http_inspect)
-
Création d’une nouvelle instance Multiton (inspecteur Telnet)
{
"normalizer": {
"enabled": true,
"type": "singleton",
"data": {
"tcp": {
"block": true
},
"ip6": true
}
},
"http_inspect": {
"enabled": true,
"type": "multiton",
"instances": [
{
"data": {
"unzip": false,
"xff_headers": "x-forwarded-for true-client-ip x-another-forwarding-header"
},
"name": "http_inspect"
}
]
},
"telnet": {
"enabled": true,
"type": "multiton",
"instances": [
{
"name": "telnet_my_instance",
"data": {
"encrypted_traffic": true
}
}
]
},
"binder": {
"enabled": true,
"type": "binder",
"rules": [
{
"when": {
"role": "any",
"service": "telnet"
},
"use": {
"type": "telnet",
"name": "telnet_my_instance"
}
},
{
"use": {
"type": "http_inspect"
},
"when": {
"role": "server",
"service": "http",
"dst_nets": "10.1.1.0/24"
}
}
]
}
}
Remarque
|
Vous n’avez pas besoin de fournir l’attribut de nom pour l’instance par défaut dans les règles de classeur.
|
Configuration de arp_spoof
Exemple de configuration de arp_spoof :
L’inspecteur arp_spoof n’a aucune configuration par défaut pour aucun attribut. Cela montre un cas où vous pouvez fournir les remplacements.
{
"arp_spoof": {
"type": "singleton",
"data": {
"hosts": [
{
"ip": "1.1.1.1",
"mac": "ff:0f:f1:0f:0f:ff"
},
{
"ip": "2.2.2.2",
"mac": "ff:0f:f2:0f:0f:ff"
}
]
},
"enabled": true
}
}
Configuration de rate_filter
{
"rate_filter": {
"data": [
{
"apply_to": "[10.1.2.100, 10.1.2.101]",
"count": 5,
"gid": 135,
"new_action": "alert",
"seconds": 1,
"sid": 1,
"timeout": 5,
"track": "by_src"
}
],
"enabled": true,
"type": "singleton"
}
}
Configuration des règles de classeur lors de l’utilisation de la politique d’analyse de réseau à plusieurs hiérarchies
Cet exemple illustre l’ajout d’une nouvelle instance personnalisée dans la politique enfant et la façon dont les règles de
classeur doivent être écrites. Les règles du classeur sont définies sous forme de liste et, par conséquent, il est important
de reprendre les règles définies dans la politique parente et de construire les nouvelles règles par-dessus, car les règles
ne seront pas fusionnées automatiquement. Les règles de classeur disponibles dans la politique enfant sont une source de réalité
en entier.
Dans Firewall Threat Defense, les règles de politique par défaut de Cisco Talos sont ajoutées pour ces remplacements définis par l’utilisateur.
Politique parente :
Nous avons défini une instance personnalisée sous le nom telnet_parent_instance et la règle de classeur correspondante.
{
"telnet": {
"type": "multiton",
"instances": [
{
"data": {
"normalize": true,
"encrypted_traffic": true
},
"name": "telnet_parent_instance"
}
],
"enabled": true
},
"binder": {
"enabled": true,
"type": "binder",
"rules": [
{
"when": {
"role": "any",
"service": "telnet"
},
"use": {
"type": "telnet",
"name": "telnet_parent_instance"
}
}
]
}
}
Politique enfant :
Cette politique d’analyse de réseau a la politique susmentionnée comme politique de base. Nous avons défini une instance personnalisée
sous le nom telnet_child_instance et avons également défini les règles de classeur pour cette instance. Les règles de classeur de la politique parente doivent
être copiées ici, puis les règles de classeur de la politique enfant peuvent être ajoutées au début ou par-dessus en fonction
de la nature de la règle.
{
"telnet": {
"type": "multiton",
"instances": [
{
"data": {
"normalize": true,
"encrypted_traffic": false
},
"name": "telnet_child_instance"
}
],
"enabled": true
},
"binder": {
"enabled": true,
"type": "binder",
"rules": [
{
"when": {
"role": "any",
"service": "telnet",
"nets": "10.2.2.0/24"
},
"use": {
"type": "telnet",
"name": "telnet_child_instance"
}
},
{
"when": {
"role": "any",
"service": "telnet"
},
"use": {
"type": "telnet",
"name": "telnet_parent_instance"
}
}
]
}
}
Configuration de l’attribut de l’inspecteur de listes en général
Lors de la modification des remplacements pour un attribut de type liste, il est important de transmettre le contenu complet
plutôt que le remplacement partiel. Cela signifie que si les attributs de politique de base sont définis comme :
{
"list-attribute": [
{
"entry1": {
"key1": "value1"
}
},
{
"entry2": {
"key2": "value2"
}
}
]
}
Si vous souhaitez modifier value1 en value1-new, la charge utile de remplacement doit ressembler à ce qui suit :
Méthode correcte :
{
"list-attribute": [
{
"entry1": {
"key1": "value1-new"
}
},
{
"entry2": {
"key2": "value2"
}
}
]
}
Méthode incorrecte :
{
"list-attribute": [
{
"entry1": {
"key1": "value1-new"
}
}
]
}
Vous pouvez comprendre cette configuration en prenant les valeurs diminuées de l’attribut alt_max_command_line_len dans l’inspecteur smtp. Supposons que la configuration de politique par défaut (de base) pour l’inspecteur smtp soit la suivante :
{
"smtp": {
"type": "multiton",
"instances": [
{
"name": "smtp",
"data": {
"decompress_zip": false,
"normalize_cmds": "ATRN AUTH BDAT CHUNKING DATA DEBUG EHLO
EMAL ESAM ESND ESOM ETRN EVFY EXPN HELO HELP IDENT MAIL
NOOP ONEX QUEU QUIT RCPT RSET SAML SEND SOML STARTTLS TICK
TIME TURN TURNME VERB VRFY X-ADAT XADR XAUTH XCIR X-DRCP X-
ERCP XEXCH50 X-EXCH50 X-EXPS XGEN XLICENSE X-LINK2STATE XQUE
XSTA XTRN XUSR",
"ignore_data": false,
"max_command_line_len": 512,
"max_header_line_len": 1000,
"log_rcptto": false,
"decompress_swf": false,
"max_response_line_len": 512,
"b64_decode_depth": -1,
"max_auth_command_line_len": 1000,
"log_email_hdrs": false,
"xlink2state": "alert",
"binary_data_cmds": "BDAT XEXCH50",
"auth_cmds": "AUTH XAUTH X-EXPS",
"log_filename": false,
"uu_decode_depth": -1,
"ignore_tls_data": false,
"data_cmds": "DATA",
"bitenc_decode_depth": -1,
"alt_max_command_line_len": [
{
"length": 255,
"command": "ATRN"
},
{
"command": "AUTH",
"length": 246
},
{
"length": 255,
"command": "BDAT"
},
{
"length": 246,
"command": "DATA"
}
],
"log_mailfrom": false,
"decompress_pdf": false,
"normalize": "none",
"email_hdrs_log_depth": 1464,
"valid_cmds": "ATRN AUTH BDAT CHUNKING DATA DEBUG EHLO
EMAL ESAM ESND ESOM ETRN EVFY EXPN HELO HELP IDENT MAIL
NOOP ONEX QUEU QUIT RCPT RSET SAML SEND SOML STARTTLS TICK
TIME TURN TURNME VERB VRFY X-ADAT XADR XAUTH XCIR X-DRCP X-
ERCP XEXCH50 X-EXCH50 X-EXPS XGEN XLICENSE X-LINK2STATE XQUE
XSTA XTRN XUSR",
"qp_decode_depth": -1
}
}
],
"enabled": true
}
}
Maintenant, si vous souhaitez ajouter deux autres objets à la liste alt_max_command_line_len :{
"length": 246,
"command": "XEXCH50"
},
{
"length": 246,
"command": "X-EXPS"
}
Le JSON de la politique d'analyse personnalisée du réseau ressemblerait alors à ce qui suit :{
"smtp": {
"type": "multiton",
"instances": [
{
"name": "smtp",
"data": {
"alt_max_command_line_len": [
{
"length": 255,
"command": "ATRN"
},
{
"command": "AUTH",
"length": 246
},
{
"length": 255,
"command": "BDAT"
},
{
"length": 246,
"command": "DATA"
},
{
"length": 246,
"command": "XEXCH50"
},
{
"length": 246,
"command": "X-EXPS"
}
]
}
}
],
"enabled": true
}
}
Configuration des remplacements lorsque la politique d’analyse de réseau multi-hiérarchisation est utilisée dans l'inspecteur
Multiton
Cet exemple illustre le remplacement des attributs dans la politique enfant et la façon dont la configuration fusionnée sera
utilisée dans la politique enfant pour toute instance. Tous les remplacements définis dans la politique enfant seront fusionnés
avec la politique parent. Par conséquent, si attribut1 et attribut2 sont remplacés dans la politique parente et que les attribut2
et attribut3 sont remplacés dans la politique enfant, les configurations fusionnées sont pour la politique enfant. Cela signifie
que l’attribut1 (défini dans la politique parente), l’attribut2 (défini dans la politique enfant) et l’attribut3 (défini dans
la politique enfant) seront configurés sur le périphérique.
Politique parente :
Ici, nous avons défini une instance personnalisée sous le nom telnet_parent_instance et remplacé deux attributs, à savoir normalize et encrypted_traffic dans l’instance personnalisée.
{
"telnet": {
"type": "multiton",
"instances": [
{
"data": {
"normalize": true,
"encrypted_traffic": false
},
"name": "telnet_parent_instance"
}
],
"enabled": true
},
"binder": {
"enabled": true,
"type": "binder",
"rules": [
{
"when": {
"role": "any",
"service": "telnet"
},
"use": {
"type": "telnet",
"name": "telnet_parent_instance"
}
}
]
}
}
Politique enfant :
Cette politique d’analyse de réseau a la politique susmentionnée comme politique de base. Nous avons remplacé l’attribut encrypted_traffic de la politique parente et remplacé le nouvel attribut ayt_attack_thresh.
{
"telnet": {
"type": "multiton",
"instances": [
{
"data": {
"encrypted_traffic": true,
"ayt_attack_thresh": 1
},
"name": "telnet_parent_instance"
}
],
"enabled": true
}
}
Avec le JSON de politique ci-dessus, lorsque vous déployez la politique d’analyse de réseau, le JSON fusionné suivant sera
configuré sur le périphérique.
{
"telnet": {
"type": "multiton",
"instances": [
{
"data": {
"normalize": true,
"encrypted_traffic": true,
"ayt_attack_thresh": 1
},
"name": "telnet_parent_instance"
}
],
"enabled": true
},
"binder": {
"enabled": true,
"type": "binder",
"rules": [
{
"when": {
"role": "any",
"service": "telnet"
},
"use": {
"type": "telnet",
"name": "telnet_parent_instance"
}
}
]
}
}
Cet exemple illustre les détails de la politique d’analyse de réseau personnalisée. Le même comportement se produit dans l’instance
par défaut. En outre, une fusion similaire serait effectuée pour les inspecteurs Singleton.
Suppression de tous les remplacements de l’inspecteur pour la politique d’analyse de réseau
Chaque fois que vous souhaitez supprimer tous les remplacements pour une politique d’analyse de réseau spécifique, vous pouvez
téléverser un fichier JSON vide. Lors du chargement des remplacements, choisissez l’option Remplacer les remplacements de l’inspecteur.
Commentaires