Guide d'utilisation du pare-feu ASA sécurisé

Introduction

Ce document décrit les informations qui vous aident à sécuriser les périphériques Cisco ASA, ce qui augmente la sécurité globale de votre réseau.

Conditions préalables

Exigences

Aucune exigence spécifique n'est associée à ce document.

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• Appliance de sécurité active Cisco (ASA) 9.16(1) et versions ultérieures.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Ce document est structuré en 4 sections.

1.     Durcissement du plan de gestion : s'applique à tout le trafic lié à la gestion/à l'installation ASA, comme SNMP, SSH, etc.
2.     Sécurisation de la configuration : commandes permettant d'arrêter le remplissage des mots de passe, etc. pour la configuration en cours, etc.
3.     Journalisation et surveillance : s'applique à tous les paramètres liés à la connexion à ASA.
4.     Trafic direct : s'applique au trafic qui passe par l'ASA.

La couverture des fonctions de sécurité dans ce document fournit souvent assez de détails pour que vous configuriez la fonctionnalité. Cependant, dans les cas où elle ne le fait pas, la fonctionnalité est expliquée de telle manière que vous puissiez évaluer si une attention supplémentaire à la fonctionnalité est requise. Si possible et approprié, ce document contient des recommandations qui, si mises en application, aident à sécuriser un réseau.

Produits connexes

Cette configuration peut également être utilisée avec le logiciel Cisco ASA version 9.1x.

Conventions

Pour plus d’informations sur les conventions utilisées dans ce document, reportez-vous aux Conventions relatives aux conseils techniques Cisco.

Opérations sécurisées

Les opérations sécurisées du réseau sont un sujet substantiel. Bien que la majeure partie de ce document soit consacrée à la configuration sécurisée d'un périphérique Cisco ASA, les configurations seules ne sécurisent pas complètement un réseau. Les procédures opérationnelles en service sur le réseau contribuent autant à la sécurité que la configuration des périphériques sous-jacents.

Ces sujets contiennent les recommandations opérationnelles que vous êtes avisé de mettre en application. Ces sujets mettent en valeur des domaines critiques spécifiques des fonctionnements du réseau et ne sont pas complets.

Surveiller les avis et les réponses de la sécurité Cisco

L'équipe de résolution d´incidents de sécurité des produits Cisco (PSIRT) crée et maintient des publications, généralement désignées sous le nom d´Avis PSIRT, pour les problèmes liés à la sécurité des Produits Cisco. La méthode utilisée pour la transmission des questions moins graves est Cisco Security Response. Les avis et les réponses en matière de sécurité sont disponibles au PSIRT.

Des informations supplémentaires au sujet de ces véhicules de transmission sont disponibles dans Politique de vulnérabilité de la sécurité Cisco.

Afin de maintenir un réseau sécurisé, vous devez être au courant des avis et réponses de la sécurité Cisco qui ont été publiés. Vous devez avoir la connaissance d'une vulnérabilité avant que la menace qu'elle peut constituer au réseau puisse être évaluée. Référez-vous à Triage des risques pour les annonces de vulnérabilité de sécurité pour l'aide dans ce processus d'évaluation.

Exploiter Authentication, Authorization, and Accounting (AAA)

Le cadre AAA (authentification, autorisation et administration) est essentiel pour sécuriser les périphériques réseau. Le cadre AAA fournit l'authentification des sessions de gestion et peut également limiter les utilisateurs à des commandes spécifiques définies par l´administrateur et enregistrer toutes les commandes saisies par tous les utilisateurs. Consultez la section Authentification, autorisation et administration du présent document pour savoir comment tirer parti du modèle AAA.

Centraliser la collection et la surveillance du journal

Afin d’acquérir des connaissances sur les événements existants, émergents et historiques liés à des incidents de sécurité, votre entreprise doit disposer d’une stratégie unifiée pour la journalisation et la corrélation des événements. Cette stratégie doit exploiter la journalisation de tous les périphériques réseau et utiliser les capacités de corrélation pré-packaged et personnalisables.

Après que la journalisation centralisée soit mise en application, vous devez développer une approche structurée pour l'analyse du journal et le suivi des incidents. Basé sur les besoins de votre organisation, cette approche peut aller d'un examen diligent simple des données de journal jusqu´à l'analyse avancée basée sur des règles.

Utiliser les protocoles sécurisés quand c'est possible

Beaucoup de protocoles sont utilisés afin de transporter des données sensibles de gestion de réseau. Vous devez utiliser des protocoles sécurisés chaque fois que c´est possible. Un choix de protocole sécurisé inclut l'utilisation de SSH au lieu de Telnet de sorte que les données d'authentification et les informations de gestion soient chiffrées. En outre, vous devez utiliser des protocoles de transfert de fichiers sécurisés quand vous copiez des données de configuration. Un exemple est l'utilisation du Secure Copy Protocol (SCP) au lieu de FTP ou TFTP.

Obtenir la visibilité du trafic avec Netflow

Netflow vous permet de surveiller les flux de trafic du réseau. Initialement destiné à exporter les informations de trafic vers des applications de gestion de réseau, Netflow peut également être utilisé afin de montrer les informations de flux sur un routeur. Cette capacité vous permet de voir quel trafic traverse le réseau en temps réel. Que les informations de flux soient exportées ou non vers un collecteur distant, vous êtes avisés de configurer les périphériques de réseau pour Netflow de sorte qu'il puisse être utilisé réactivement si nécessaire.

Gestion de la configuration

La gestion de la configuration est un processus par lequel des modifications de configuration sont proposées, passées en revue, approuvées et déployées. Dans le contexte de la configuration d'un périphérique Cisco ASA, deux aspects supplémentaires de la gestion de la configuration sont essentiels : l'archivage de la configuration et la sécurité.

Vous pouvez employer les archives de configuration pour abandonner les modifications qui sont apportées aux périphériques de réseau. Dans un contexte de sécurité, les archives de configuration peuvent également être utilisées afin de déterminer quelles modifications de la sécurité ont été apportées et quand ces modifications se sont produites. En même temps que les données du journal de l'AAA, ces informations peuvent aider aux audits de sécurité des périphériques de réseau.

La configuration d'un périphérique Cisco ASA contient de nombreux détails sensibles. Les noms d'utilisateur, les mots de passe et le contenu des listes de contrôle d'accès sont des exemples de ce type d'information. Le référentiel que vous utilisez pour archiver les configurations des périphériques Cisco ASA doit être sécurisé. Un accès non sécurisé à ces informations peut nuire à la sécurité de tout le réseau.

Gestion Plan

Le plan de gestion se compose de fonctions qui accomplissent les buts de gestion du réseau. Il s’agit notamment des sessions de gestion interactives qui utilisent SSH, ainsi que la collecte de statistiques avec SNMP ou NetFlow. Quand vous considérez la sécurité d'un périphérique de réseau, il est critique que le plan de gestion soit protégé. Si un incident lié à la sécurité peut miner les fonctions du plan de gestion, il peut vous être impossible de rétablir ou de stabiliser le réseau.

Renforcement du plan de gestion

Le plan de gestion est utilisé afin d'accéder, configurer et gérer un périphérique, ainsi que pour surveiller ses opérations et le réseau sur lequel il est déployé. Le plan de gestion est le plan qui reçoit et envoie le trafic pour les opérations de ces fonctions. Cette liste des protocoles est utilisée par le plan de gestion :

• Protocole SNMP (Simple Network Management Protocol)
• Secure Shell Protocol
• Protocole FTP (File Transfer Protocol)
• Protocole TFTP (Trivial File Transfer Protocol)
• Secure Copy Protocol
• TACACS+
• RADIUS
• NetFlow
• Protocole NTP
• Syslog
• ICMP
• PME

Remarque : l'activation de TELNET n'est pas recommandée, car il s'agit de texte brut.

Gestion des mots de passe

Accès par contrôle de mots de passe aux ressources ou aux périphériques. Ceci est accompli par la définition d´un mot de passe ou secret qui est utilisé afin d'authentifier les demandes. Quand une demande est reçue pour l'accès à une ressource ou à un périphérique, la demande est contestée pour la vérification du mot de passe et de l'identité, et l'accès peut être accordé, refusé ou limité basé sur le résultat. Comme meilleure pratique de sécurité, les mots de passe doivent être gérés avec un serveur d'authentification TACACS+ ou RADIUS. Notez toutefois qu’un mot de passe configuré localement pour l’accès privilégié est toujours nécessaire en cas de panne des services TACACS+ ou RADIUS. Un périphérique peut également avoir d'autres informations relatives au mot de passe présentes dans sa configuration, comme une clé NTP, la chaîne de communauté SNMP ou la clé du protocole de routage.

ASA 9.7(1) a introduit le hachage PBKDF2 pour les mots de passe locaux. Le nom d'utilisateur local et les mots de passe enable de toutes les longueurs sont stockés dans la configuration à l'aide d'un hachage PBKDF2 (Password-Based Key Derivation Function 2). Auparavant, les mots de passe de 32 caractères et moins utilisaient la méthode de hachage MD5. Les mots de passe existants continuent d'utiliser le hachage MD5, sauf si vous entrez un nouveau mot de passe. Reportez-vous au chapitre relatif aux logiciels et aux configurations du Guide de configuration des opérations générales pour obtenir des instructions de mise à niveau.

Activer le service HTTP

Pour utiliser l'ASDM, vous devez activer le serveur HTTPS et autoriser les connexions HTTPS à l'ASA. L'appliance de sécurité autorise un maximum de 5 instances ASDM simultanées par contexte, si disponible, avec un maximum de 32 instances ASDM entre tous les contextes. Pour configurer l'accès ASDM, utilisez :

http server enable <port>

Autorisez uniquement les adresses IP nécessaires dans la liste de contrôle d’accès. Permettre un accès étendu n'est pas une bonne pratique.

http 0.0.0.0 0.0.0.0 <interface> 

Configurer le contrôle d'accès ASDM :

http <remote_ip_address> <remote_subnet_mask> <interface_name>

// Set server version
ASA(config)# ssl server-version tlsv1 tlsv1.1 tlsv.1.2

// Set client version
ASA(config) # ssl client-version tlsv1 tlsv1.1 tlsv.1.2

Ces chiffrements sont activés par l'ASA dans l'ordre indiqué par défaut.

La valeur par défaut est high.

• Le mot clé all spécifie l'utilisation de tous les chiffres : hmac-sha1 hmac-sha1-96 hmac-sha2-256 hmac-md5 hmac-md5-96

• Le mot clé custom spécifie une chaîne de configuration de chiffrement de chiffrement personnalisée, séparée par des deux-points.

• Le mot clé fips ne spécifie que les chiffrements compatibles FIPS : hmac-sha1 hmac-sha2-256

• Le mot-clé high ne spécifie que des chiffrements de haute puissance (valeur par défaut) : hmac-sha2-256

• Le mot-clé low spécifie des chiffres de force faible, moyenne et élevée : hmac-sha1 hmac-sha1-96 hmac-md5 hmac-md5-96 hmac-sha2-256

• Le mot clé medium spécifie les chiffres moyens et de haute puissance : hmac-sha1 hmac-sha1-96hmac-sha2-256

L'ASA utilise par défaut un certificat temporaire auto-signé qui change à chaque redémarrage. Si vous recherchez un seul certificat, vous pouvez utiliser ce lien pour générer un certificat auto-signé permanent.

ASA prend en charge TLS version 1.2 pour la transmission sécurisée des messages pour ASDM, VPN sans client et VPN AnyConnect. Ces commandes ont été introduites ou sont des commandes modifiées : ssl client-version, ssl server-version, ssl cipher, ssl trust-point, ssl dh-group, show ssl, show ssl cipher, show vpn-sessiondb.

ASA-1/act(config)# ssl server-version ?

configure mode commands/options:
  tlsv1    Enter this keyword to accept SSLv2 ClientHellos and negotiate TLSv1
           (or greater)
  tlsv1.1  Enter this keyword to accept SSLv2 ClientHellos and negotiate
           TLSv1.1 (or greater)
  tlsv1.2  Enter this keyword to accept SSLv2 ClientHellos and negotiate
           TLSv1.2 (or greater)

ASA-1/act(config)# ssl cipher ?

configure mode commands/options:
  default  Specify the set of ciphers for outbound connections
  dtlsv1   Specify the ciphers for DTLSv1 inbound connections
  tlsv1    Specify the ciphers for TLSv1 inbound connections
  tlsv1.1  Specify the ciphers for TLSv1.1 inbound connections
  tlsv1.2  Specify the ciphers for TLSv1.2 inbound connections

Activer SSH

L'ASA autorise les connexions SSH à l'ASA à des fins de gestion. L'ASA permet un maximum de 5 connexions SSH simultanées par contexte, si disponible, avec un maximum de 100 connexions réparties entre tous les contextes.

hostname <device_hostname>
domain-name <domain-name>
crypto key generate rsa modulus 2048

Le type de paire de clés par défaut est general key. La taille de module par défaut est 1024. La quantité d'espace NVRAM pour le stockage des paires de clés varie en fonction de la plate-forme ASA. Vous pouvez atteindre une limite si vous générez plus de 30 paires de clés. 

Pour supprimer les paires de clés du type indiqué (rsa ou dsa),

crypto key zeroize { rsa | eddsa | ecdsa } [ label key-pair-label ] [ default ] [ noconfirm ]

Configurez SSH pour l'accès à distance aux périphériques :

ssh <remote_ip_address> <remote_subnet_mask> <interface_name>

Pour échanger des clés à l'aide de la méthode Diffie-Hellman (DH) Group 1, DH Group 14 ou Curve25519 key-exchange, utilisez la commande ssh key-exchange en mode de configuration globale, à partir de la version 9.1(2). ASA prend en charge dh-group14-sha1 pour SSH.

ASA(config)#ssh key-exchange group dh-group14-sha256

Configurer le délai d'attente des sessions de connexion

// Configure Console timeout
ASA(config)#console timeout 10

// Configure Console timeout
ASA(config)#ssh timeout 10

Gestion des mots de passe

Accès par contrôle de mots de passe aux ressources ou aux périphériques. Ceci est accompli par la définition d´un mot de passe ou secret qui est utilisé afin d'authentifier les demandes. Quand une demande est reçue pour l'accès à une ressource ou à un périphérique, la demande est contestée pour la vérification du mot de passe et de l'identité, et l'accès peut être accordé, refusé ou limité basé sur le résultat. Comme meilleure pratique de sécurité, les mots de passe doivent être gérés avec un serveur d'authentification TACACS+ ou RADIUS. Notez toutefois qu’un mot de passe configuré localement pour l’accès privilégié est toujours nécessaire en cas de panne des services TACACS+ ou RADIUS. Un périphérique peut également avoir d'autres informations relatives au mot de passe présentes dans sa configuration, comme une clé NTP, la chaîne de communauté SNMP ou la clé du protocole de routage.

Configurer l'utilisateur local et le mot de passe chiffré

username <local_username> password <local_password> encrypted

Configurer le mot de passe actif

enable password <enable_password> encrypted

Configurer l'authentification AAA pour le mode Enable

ASA(config)#aaa authentication enable console LOCAL

Authentification, autorisation et administration (AAA)

Le cadre AAA est essentiel pour sécuriser l’accès interactif aux périphériques réseau. Ce cadre offre un environnement grandement configurable qui peut être adapté en fonction des besoins du réseau.

Authentification TACACS+

TACACS+ est un protocole d'authentification qu'ASA peut utiliser pour l'authentification des utilisateurs de gestion sur un serveur AAA distant. Ces utilisateurs de gestion peuvent accéder au périphérique ASA via SSH, HTTPS, Telnet ou HTTP.

L'authentification TACACS+, ou plus généralement l´authentification AAA, fournit la capacité d'utiliser les comptes d'utilisateurs individuels pour chaque administrateur réseau. Si vous n’êtes pas dépendant d’un mot de passe unique partagé, la sécurité du réseau est alors améliorée, et votre responsabilité est renforcée.

RADIUS est un protocole dont l'objectif est similaire à TACACS+ ; toutefois, il ne chiffre que le mot de passe envoyé sur le réseau. En revanche, TACACS+ chiffre l’intégralité de la charge utile TCP, y compris le nom d’utilisateur et le mot de passe. Pour cette raison, TACACS+ peut être utilisé de préférence à RADIUS lorsque TACACS+ est pris en charge par le serveur AAA. Référez-vous à Comparaison de TACACS+ et RADIUS pour une comparaison plus détaillée de ces deux protocoles.

L'authentification TACACS+ peut être activée sur un périphérique Cisco ASA avec une configuration similaire à celle de l'exemple suivant :

aaa authentication serial console Tacacs 
aaa authentication ssh console Tacacs
aaa authentication http console Tacacs
aaa authentication telnet console Tacacs

Signature et vérification de l'image ASA

À partir de la version 9.3.1 du logiciel, les images ASA sont désormais signées à l'aide d'une signature numérique. La signature numérique est vérifiée après le démarrage de l'ASA.

ASA-1/act(config)# verify flash:/asa941-smp-k8.bin
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!                                                                                        !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!Done!
Embedded Hash SHA-512: 0e707a0e45b1c7c5afa9ef4e802a273677a5e46f7e1d186292abe1154                                                                                        c948a63c625463b74119194da029655487659490c2873506974cab78b66d6d9742ed73e
Computed Hash SHA-512: 0e707a0e45b1c7c5afa9ef4e802a273677a5e46f7e1d186292abe1154                                                                                        c948a63c625463b74119194da029655487659490c2873506974cab78b66d6d9742ed73e
CCO Hash      SHA-512: 1b6d41e893868aab9e06e78a9902b925227c82d8e31978ff2c412c18a                                                                                        c99f49f70354715441385e0b96e4bd3e861d18fb30433d52e12b15b501fa790f36d0ea0
Signature Verified


ASA(config)# verify /signature running
Requesting verify signature of the running image...

Starting image verification
Hash Computation:    100% Done!
Computed Hash   SHA2: 2fbb0f62b5fbc61b081acfca76bddbb2
                      26ce7a5fb4b424e5e21636c6c8a7d665
                      1e688834203dfb7ffa6eaefc7fdf9d3d
                      1d0a063a20539baba72c2526ca37771c


Get key records from key storage: PrimaryASA, key_store_type: 6
Embedded Hash   SHA2: 2fbb0f62b5fbc61b081acfca76bddbb2
                      26ce7a5fb4b424e5e21636c6c8a7d665
                      1e688834203dfb7ffa6eaefc7fdf9d3d
                      1d0a063a20539baba72c2526ca37771c

Returned. rc: 0, status: 1
The digital signature of the running image verified successfully

ASA-1/act(config)# show software authenticity running
Image type : Release
 Signer Information
 Common Name : abraxas
 Organization Unit : ASAv
 Organization Name : CiscoSystems
 Certificate Serial Number : 550DBBD5
 Hash Algorithm : SHA2 512
 Signature Algorithm : 2048-bit RSA
 Key Version : A

Configurer le fuseau horaire

clock timezone GMT <hours offset>

Configuration de NTP

Le Network Time Protocol (NTP) n'est pas un service particulièrement dangereux, mais n'importe quel service inutile peut représenter un vecteur d'attaque. Si le NTP est utilisé, il est important de configurer explicitement une source temporelle de confiance et d'utiliser l'authentification appropriée. Une heure précise et fiable est requise pour Syslog, comme pendant les investigations légales d´attaques potentielles, ainsi que pour la connectivité réussie de VPN en cas de dépendance sur les certificats pour l´authentification de phase 1.

• NTP Time Zone [fuseau horaire NTP] : Lorsque vous configurez le protocole NTP, le fuseau horaire doit être configuré de sorte que les horodatages puissent être corrélés avec précision. En général, deux approches peuvent servir à configurer le fuseau horaire pour les périphériques d’un réseau ayant une présence globale. Une méthode est de configurer tous les périphériques réseau avec l´UTC (Coordinated Universal Time) (précédemment heure GMT (Greenwich Mean Time)). L’autre approche consiste à configurer les périphériques réseau avec le fuseau horaire local. ntp server ip_address [ key_id ] [ source interface_name ] [ prefer ]

• NTP Authentication [authentification NTP] : Si vous configurez l’authentification NTP, celle-ci garantit que les messages NTP seront échangés entre les homologues NTP de confiance. Activez l'authentification à l'aide de la commande ntp authenticate et définissez l'ID de clé approuvée pour ce serveur. Si vous activez l'authentification, l'ASA communique uniquement avec un serveur NTP s'il utilise la clé approuvée correcte dans les paquets. Pour activer l'authentification avec un serveur NTP, utilisez la commande ntp authenticate en mode de configuration globale.

ASA(config)#ntp authenticate

Service de serveur DHCP (si non utilisé)

clear configure dhcpd
no dhcpd enable <interface_name>

Remarque : ASA ne prend pas en charge le protocole CDP.

Control-Plane Access-list

Les règles de contrôle d'accès pour le trafic de gestion prêt à l'emploi (définies par des commandes telles que http, ssh, ou telnet) ont une priorité plus élevée qu'une liste d'accès appliquée avec l'option de plan de contrôle. Par conséquent, un tel trafic de gestion autorisé peut être autorisé à entrer même s'il est explicitement refusé par la liste d'accès prête à l'emploi.

access-list <name> in interface <Interface_name> control-plane

Depuis ASA

Voici les protocoles qui peuvent être utilisés pour copier/transférer des fichiers vers ASA.

Texte clair :

• FTP
• HTTP
• TFTP
• PME

Sécurisé :

•  HTTPS
•  Secure Copy Client (SCP) ASA prend en charge le client SCP pour transférer des fichiers vers et depuis un serveur SCP.

Pour le trafic direct

Randomisation du numéro de séquence TCP

Chaque connexion TCP comporte deux réseaux ISN : un généré par le client et un généré par le serveur. L'ASA rend aléatoire l'ISN du SYN TCP passant dans les directions entrante et sortante.

La randomisation du numéro ISN de l’hôte protégé empêche un pirate de devancer le numéro ISN suivant pour une nouvelle connexion et de potentiellement détourner la nouvelle session.

La randomisation du numéro de séquence initial TCP peut être désactivée si nécessaire. Exemple :

• Si un autre pare-feu en ligne randomise également les numéros de séquence initiaux, il n'est pas nécessaire que les deux pare-feu effectuent cette action, même si cette action n'affecte pas le trafic.
• Si vous utilisez eBGP à sauts multiples via l'ASA, et que les homologues eBGP utilisent MD5. La randomisation casse la somme de contrôle MD5.
• Si nous utilisons un périphérique WAAS qui nécessite que l'ASA ne randomise pas les numéros d'ordre des connexions.

Diminution du temps de vie

Par défaut, ne décrémente pas la durée de vie dans l'en-tête IP en raison de laquelle ASA n'apparaît pas comme saut de routeur lors de l'exécution de la commande Traceroute.

dnsguard

Applique une réponse DNS par requête. Il peut être activé à l'aide de la commande en mode de configuration globale.

ASA(config)#dns-guard

Configuration des contrôles de fragmentation de la chaîne de fragments

Pour fournir une gestion supplémentaire de la fragmentation des paquets et améliorer la compatibilité avec NFS, utilisez la commande fragment en mode de configuration globale.

fragment reassembly { full | virtual } { size | chain | timeout limit } [ interface ]

Configurer l’inspection de protocole

Des moteurs d’inspection sont nécessaires pour les services qui intègrent des informations d’adressage IP dans le paquet de données utilisateur ou qui ouvrent des canaux secondaires sur des ports affectés dynamiquement. Ces protocoles exigent que l'ASA effectue une inspection approfondie des paquets au lieu de les faire passer par le chemin rapide. Par conséquent, les moteurs d'inspection peuvent affecter le débit global. Référez-vous au Guide de configuration ASA 9.4 pour des informations détaillées sur l'inspection du protocole de couche application.

L'inspection sur ASA peut être activée à l'aide de cette commande. 

policy-map <Policy-map_name>
 class inspection_default
  inspect <Protocol>

service-policy <Policy-map_name> interface <Interface_name> (Per Interface)
service-policy <Policy-map_name> global (Globally)

Par défaut, la stratégie globale est activée globalement sur ASA.

Configuration du transfert de chemin inverse de monodiffusion

ip verify reverse-path interface <interface_name>

 Lorsque le trafic est abandonné en raison de la vérification RPF, cela montre le compteur d'abandon asp sur les incréments ASA.

ASA(config)# show asp drop 

Frame drop:
  Invalid TCP Length (invalid-tcp-hdr-length)                  21
  Reverse-path verify failed (rpf-violated)                    90

// Check Reverse path statistics

ASA(config)# sh ip verify statistics
interface inside: 11 unicast rpf drops
interface outside: 79 unicast rpf drops 

Détection des menaces

Threat Detection fournit aux administrateurs de pare-feu les outils nécessaires pour identifier, comprendre et stopper les attaques avant qu'elles n'atteignent l'infrastructure réseau interne. Pour ce faire, la fonctionnalité s'appuie sur un certain nombre de déclencheurs et de statistiques différents, qui sont décrits plus en détail dans ces sections.

Référez-vous à Fonctionnalité et configuration de détection des menaces ASA pour une explication détaillée sur la détection des menaces sur ASA.

Filtre Botnet

Le filtre de trafic BotNet surveille les demandes et les réponses DNS (Domain Name Server) entre les clients DNS internes et les serveurs DNS externes. Lorsqu'une réponse DNS est traitée, le domaine associé à la réponse est comparé à la base de données des domaines malveillants connus. En cas de correspondance, tout autre trafic vers l’adresse IP présente dans la réponse DNS est bloqué.

Un programme malveillant est un logiciel malveillant installé sur un hôte inconnu. Les programmes malveillants qui tentent d'effectuer des activités sur le réseau, telles que l'envoi de données privées (mots de passe, numéros de carte de crédit, frappes de touches ou données propriétaires), peuvent être détectés par le filtre de trafic Botnet lorsque le programme malveillant établit une connexion à une adresse IP incorrecte connue. Le filtre de trafic de botnets vérifie les connexions entrantes et sortantes par rapport à une base de données dynamique de noms de domaine et d'adresses IP (la liste des adresses bloquées) incorrects connus, puis consigne ou bloque toute activité suspecte.

Vous pouvez également compléter la base de données dynamique Cisco avec les adresses de liste bloquée de votre choix en les ajoutant à une liste bloquée statique. Si la base de données dynamique inclut des adresses de liste bloquée qui, selon vous, ne peuvent pas être bloquées, vous pouvez les entrer manuellement dans une liste statique autorisée. Les adresses de liste autorisées génèrent toujours des messages syslog, mais comme vous ciblez uniquement les messages syslog de liste bloquée, elles sont informatives. Référez-vous à Configuration du filtre de trafic de botnets pour des informations détaillées.

Ajout de cache ARP pour les sous-réseaux non connectés

Par défaut, ASA ne répond pas au protocole ARP pour les adresses IP de sous-réseau non directement connectées. Si vous avez une adresse IP NAT sur ASA qui n'appartient pas à la même adresse IP de sous-réseau de l'interface ASA, vous pouvez avoir à activer arp permit-nonconnected sur ASA vers proxy-ARP pour l'adresse IP NATted.

arp permit-nonconnected

Il est toujours recommandé d'avoir le routage correct sur les périphériques en amont et en aval pour que la NAT fonctionne sans activer la commande précédente.

Journalisation et surveillance

Configuration de SNMP

Cette section met en évidence plusieurs méthodes qui peuvent être utilisées afin de sécuriser le déploiement de SNMP dans les périphériques ASA. Il faut absolument que le protocole SNMP soit correctement sécurisé pour protéger la confidentialité, l’intégrité et la disponibilité des données du réseau et des périphériques réseau par où transitent ces données. SNMP vous fournit une grande quantité d'informations sur la santé des périphériques réseau. Ces informations peuvent être protégées contre les utilisateurs malveillants qui souhaitent exploiter ces données afin d'attaquer le réseau.

Chaînes de caractères de la communauté SNMP

Les chaînes de communauté sont des mots de passe qui sont appliqués à un périphérique ASA pour restreindre l'accès, en lecture seule et en lecture-écriture, aux données SNMP sur le périphérique. Ces chaînes de communauté, comme tous les mots de passe, peuvent être soigneusement choisies pour s'assurer qu'elles ne sont pas triviales. Les chaînes de communauté peuvent être modifiées à intervalles réguliers et conformément aux politiques de sécurité du réseau. Par exemple, les chaînes peuvent être modifiées lorsqu'un administrateur réseau change de rôle ou quitte l'entreprise.

Activer l'accès en lecture SNMP

snmp-server host <interface_name> <remote_ip_address>

Activer les déroutements SNMP

snmp-server enable traps all

Configuration de Syslog

Il est conseillé d'envoyer les informations de journalisation à un serveur syslog distant. Ainsi, la corrélation et la vérification des événements du réseau et de sécurité peuvent être réalisées plus efficacement sur les périphériques réseau.

Pour cette raison, toutes les protections qu'un réseau offre au trafic de gestion (par exemple, le cryptage ou l'accès hors bande) peuvent être étendues afin d'inclure le trafic syslog. Les journaux peuvent être configurés pour être envoyés à cette destination depuis ASA :

• ASDM
• Tampon
• Éclair
• Courriel
• serveur FTP
• Serveur SNMP en tant que déroutements
• serveur Syslogs

Configurer le niveau de gravité de journalisation de console

logging console critical

Syslog basé sur TCP est également disponible. Tous les Syslog peuvent être envoyés au serveur Syslog en texte clair ou chiffrés en cas de TCP.

Texte clair

logging host interface_name ip_syslog [ tcp/ port

Chiffré

logging host interface_name ip_syslog [ tcp/ port | [ sécurisé ]

Si une connexion TCP ne peut pas être établie avec le serveur syslogs, toutes les nouvelles connexions peuvent être refusées. Vous pouvez modifier ce comportement par défaut en entrant la commande logging permit-hostdown.

Configurer les horodatages dans les messages du journal

La configuration des horodatages des journalisations vous aide à corréler des événements à travers les périphériques réseau. Il est important de mettre en application une configuration d´horodatage correct et cohérent des journalisations pour assurer que vous pouvez corréler les données de journalisation.

logging timestamp

Pour des informations supplémentaires relatives à syslog, référez-vous à Exemple de configuration de syslog ASA.

Configuration de Netflow

Parfois, vous pouvez devoir identifier rapidement le trafic sur le réseau et revenir en arrière, particulièrement pendant une réponse d'incident ou des mauvaises performances du réseau. Le Netflow peut fournir la visibilité dans tout le trafic du réseau. En outre, le Netflow peut être mis en application avec des collecteurs qui peuvent fournir les tendances à long terme et une analyse automatisée.

Cisco ASA prend en charge les services NetFlow version 9. Les mises en oeuvre ASA et ASASM de NSEL fournissent une méthode de suivi de flux IP avec état qui exporte uniquement les enregistrements qui indiquent des événements significatifs dans un flux. Dans le suivi de flux avec état, les flux suivis passent par une série de changements d'état. Les événements NSEL sont utilisés pour exporter des données sur l'état du flux et sont déclenchés par l'événement qui a provoqué le changement d'état.

Référez-vous au Guide de mise en oeuvre de Cisco ASA NetFlow pour plus d'informations sur Netflow sur ASA :

Sécurisation de la configuration

Mots de passe dans la configuration

Tous les mots de passe et les clés sont chiffrés ou masqués . La commande show running-config ne révèle pas les mots de passe réels.

Une telle sauvegarde ne peut pas être utilisée pour la sauvegarde/restauration sur ASA. La sauvegarde effectuée à des fins de restauration serait exécutée à l'aide de la commande more system:running-config. Les mots de passe de configuration ASA peuvent être chiffrés à l'aide d'une phrase de passe principale. Référez-vous à Cryptage de mot de passe pour des informations détaillées.

Récupération du mot de passe de service

La désactivation de cette option peut désactiver le mécanisme de récupération de mot de passe et désactiver l'accès à ROMMON. Le seul moyen de récupérer des mots de passe perdus ou oubliés peut être pour ROMMON d'effacer tous les systèmes de fichiers, y compris les fichiers de configuration et les images. Vous pouvez effectuer une sauvegarde de votre configuration et disposer d'un mécanisme de restauration des images à partir de la ligne de commande ROMMON.

Dépannage

Aucune information de dépannage n'est disponible.