Guide Cisco pour renforcer le pare-feu Cisco ASA

Introduction

Ce document contient des informations pour vous aider à sécuriser les périphériques Cisco ASA, ce qui augmente la sécurité globale de votre réseau. Ce document est structuré en 4 sections

    Durcissement du plan de gestion - Ceci s'applique à tous les trafics liés à ASA/Au trafic de boîte comme SNMP, SSH, etc.
    Sécurisation de la configuration - Commandes permettant d'arrêter le remplissage des mots de passe, etc. pour la configuration en cours, etc.
    Journalisation et surveillance - Ceci s'applique à tous les paramètres liés à la connexion à ASA.
    Trafic via - Ceci 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.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Components Used

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

• Cisco ASA5500-X 9.4(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. If your network is live, make sure that you understand the potential impact of any command.

Produits connexes

Cette configuration peut également être utilisée avec le logiciel de la gamme Cisco ASA 5500-X Security Appliance Version 9.x.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à 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 à elles 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. Des avis et des réponses sur la 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 au Triage du risque pour des annonces de vulnérabilité de sécurité pour assistance dans cette é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 : archivage et sécurité de la configuration.

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 de 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.

Plan de gestion renforcé

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

Note: L'activation de TELNET n'est pas recommandée car il s'agit d'un 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 utilise Message Digest 5 (MD5) pour le hachage de mot de passe. Cet algorithme a eu une revue publique considérable et n'est pas connu pour être réversible. Cependant, l'algorithme est sujet à des attaques de dictionnaire. Dans une attaque de dictionnaire, un attaquant essaye chaque mot d´un dictionnaire ou autre liste de mots de passe candidats afin de rechercher une correspondance. Par conséquent, les fichiers de configuration doivent être stockés de manière sécurisée et seulement partagés avec des personnes de confiance.

Activer le service HTTP

Pour utiliser 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>

Autoriser uniquement les adresses IP nécessaires dans la liste de contrôle d’accès. Permettre un accès étendu est une mauvaise 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>

À partir de la version 9.1(2) du logiciel ASA, 8.4(4.1), l'ASA prend désormais en charge les suites de chiffrement SSL Diffie-Hellman (DHE) suivantes.

DHE-AES128-SHA1
DHE-AES256-SHA1

Ces suites de chiffrement sont spécifiées dans la RFC 3268, AES (Advanced Encryption Standard) Ciphersuites for Transport Layer Security (TLS).

Lorsqu'il est pris en charge par le client, le chiffrement DHE est le chiffrement préféré car il fournit une confidentialité de transfert parfaite. Reportez-vous aux limitations suivantes :

DHE n'est pas pris en charge sur les connexions SSL 3.0, alors assurez-vous d'activer également TLS 1.0 pour le serveur SSL.

// Set server version
ASA(config)# ssl server-version tlsv1 sslv3

// Set client version
ASA(config) # ssl client-version any

Certaines applications courantes ne prennent pas en charge DHE. Incluez donc au moins une autre méthode de cryptage SSL pour vous assurer qu'une suite de chiffrement commune au client et au serveur SSL peut être utilisée. Certains clients peuvent ne pas prendre en charge DHE, notamment AnyConnect 2.5 et 3.0, Cisco Secure Desktop et Internet Explorer 9.0.

Par défaut, les algorithmes de chiffrement ci-dessous sont activés dans l'ordre ci-dessous.

ASA(config)#ssl encryption rc4-sha1 dhe-aes128-sha1 dhe-aes256-sha1 aes128-sha1 aes256-sha1 3des-sha1

ssl server-version any (par défaut)

Par défaut, l'ASA utilise un certificat auto-signé temporaire qui change à chaque redémarrage. Si vous recherchez un certificat unique, vous pouvez suivre le lien ci-dessous pour générer un certificat auto-signé permanent.

Maintenant, ASA prend en charge TLS version 1.2 à partir de la version 9.3.1du logiciel pour la transmission sécurisée des messages pour ASDM, SSVPN sans client et AnyConnect VPN. Les commandes suivantes ont été introduites ou 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 autorise 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 clé générale . La taille du module par défaut est 1024. La quantité d'espace NVRAM pour le stockage des paires de clés varie selon la plate-forme ASA. Vous pouvez atteindre une limite si vous générez plus de 30 paires de clés. Les clés RSA 4096 bits sont uniquement prises en charge sur les plates-formes ASA5580, 5585 ou ultérieures.

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

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

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

ssh <remote_ip_address> <remote_subnet_mask> <interface_name>

Pour limiter la version de SSH acceptée par l'ASA, utilisez la commande ssh version en mode de configuration globale. Pour limiter l'ASA à utiliser uniquement la version 2, utilisez la commande ci-dessous.

ASA(config)#ssh version 2

Pour échanger des clés à l'aide de la méthode Diffie-Hellman (DH) Group 1 ou DH Group 14 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 dh-group14-sha1

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 enable

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 semblable à TACACS+; toutefois, il chiffre uniquement 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+ devrait être utilisé de préférence à RADIUS quand TACACS+ est supporté 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 à cet exemple :

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

Signature et vérification des images ASA

À partir de la version 9.3.1 du logiciel, les images ASA sont maintenant 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>

Configurer 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 est de configurer les périphériques réseau avec le fuseau horaire local. 

ntp server ip_address [ key 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, définit l'ID de clé de confiance pour ce serveur. Si vous activez l'authentification, l'ASA communique uniquement avec un serveur NTP s'il utilise la clé de confiance 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 serveur DHCP (si non utilisé)

clear configure dhcpd
no dhcpd enable <interface_name>

Note: ASA ne prend pas en charge CDP.

Liste d'accès au plan de contrôle

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, ce trafic de gestion autorisé sera autorisé à entrer même s'il est explicitement refusé par la liste d'accès to-the-box.

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

De 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
•  SCP (Secure Copy Client) à partir de la version 9.1(5), ASA prend en charge le client SCP pour transférer des fichiers vers et depuis un serveur SCP.

Pour le trafic via

Randomisation du numéro de séquence TCP

Chaque connexion TCP comporte deux ISN : une générée par le client et une générée par le serveur. L'ASA randomise l'ISN du SYN TCP passant dans les directions entrante et sortante.

L’aléatoirement du numéro de service intégré de l’hôte protégé empêche un pirate de devancer le prochain numéro de service intégré pour une nouvelle connexion et de détourner potentiellement la nouvelle session.

L'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 exécutent 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 brise 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.

Décalage TTL

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 un saut de routeur lors de 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

Configurer les contrôles de fragmentation de la chaîne de fragmentation

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

Les moteurs d'inspection sont requis 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 nécessitent que l'ASA effectue une inspection approfondie des paquets au lieu de les transmettre par le chemin rapide. Par conséquent, les moteurs d'inspection peuvent affecter le débit global. Pour plus d'informations sur l'inspection du protocole de couche application, reportez-vous au Guide de configuration ASA 9.4.

L'inspection sur ASA peut être activée à l'aide de la commande ci-dessous

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, ASA a « global_policy » activé globalement.

Configurer le transfert inverse de monodiffusion

ip verify reverse-path interface <interface_name>

 Lorsque le trafic est abandonné en raison d'un contrôle RPF, le compteur ci-dessous « show asp drop » 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

La détection des menaces fournit aux administrateurs de pare-feu les outils nécessaires pour identifier, comprendre et arrêter les attaques avant qu'elles n'atteignent l'infrastructure réseau interne. Pour ce faire, la fonction repose sur un certain nombre de déclencheurs et de statistiques différents, qui sont décrits plus en détail dans ces sections.

Reportez-vous à Fonctionnalité et configuration de détection des menaces ASA pour obtenir des explications détaillées sur la détection des menaces sur ASA.

Filtre de botnets

Le filtre de trafic BotNet surveille les requêtes et les réponses du serveur de noms de domaine (DNS) 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 vérifié par rapport à la base de données des domaines malveillants connus. En cas de correspondance, tout trafic supplémentaire vers l’adresse IP présente dans la réponse DNS est bloqué.

Les programmes malveillants sont des logiciels malveillants installés sur un hôte inconnu. Les programmes malveillants qui tentent d'exercer une activité réseau, tels que l'envoi de données privées (mots de passe, numéros de carte de crédit, touches ou données propriétaires), peuvent être détectés par le filtre de trafic de botnets lorsque le programme malveillant démarre 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 incorrects connus (liste noire), puis consigne ou bloque toute activité suspecte.

Vous pouvez également compléter la base de données dynamique Cisco par les adresses de votre choix, en les ajoutant à une liste de blocage statique ; si la base de données dynamique inclut des adresses mises en liste noire qui ne devraient pas être mises en liste noire, vous pouvez les entrer manuellement dans une liste blanche statique. Les adresses listes blanches génèrent toujours des messages syslog, mais comme vous ne ciblez que les messages syslog de liste noire, ils sont informatifs. Pour plus d'informations, reportez-vous à Configuration du filtre de trafic des botnets.

Compléments 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 au même sous-réseau IP de l'interface ASA, nous devrons activer « arp permit-nonconnected » sur ASA à proxy-ARP pour l'adresse IP NATted.

arp permit-nonconnected

Il est toujours recommandé de disposer du routage correct sur les périphériques en amont et en aval pour que NAT fonctionne sans activer la commande ci-dessus.

Journalisation et surveillance

Configuration du protocole SNMP

Cette section présente plusieurs méthodes qui peuvent être utilisées pour sécuriser le déploiement de SNMP au sein des 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 doivent être protégées des utilisateurs malveillants qui souhaitent se servir de ces données pour lancer des attaques contre le réseau.

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

Les chaînes de communauté sont des mots de passe appliqués à un périphérique ASA pour restreindre l'accès, en lecture seule et en lecture-écriture, aux données SNMP du périphérique. Ces chaînes de caractères de la communauté, comme avec tous les mots de passe, devraient être soigneusement choisies pour assurer qu'elles ne sont pas insignifiantes. Les chaînes de caractères de la communauté devraient être changées à intervalles réguliers et conformément aux stratégies de sécurité du réseau. Par exemple, les chaînes de caractères devraient être changées quand un administrateur réseau change des rôles ou quitte la société.

Activer l'accès en lecture SNMP :

snmp-server host <interface_name> <remote_ip_address>

Activer les interruptions 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. Notez que les messages Syslog sont transmis de manière peu fiable par UDP et en libellé. C’est pourquoi les protections qu’offre un réseau pour le trafic de gestion (p. ex., le chiffrement ou l’accès hors bande) doivent être élargies afin d’intégrer le trafic syslog. Les journaux peuvent être configurés pour être envoyés à la destination suivante à partir d'ASA :

• ASDM
• Tampon
• Flash
• Courriel
• Serveur FTP
• Serveur SNMP comme interruptions
• Serveur Syslogs

Configurer le niveau de gravité de la journalisation de la console

logging console critical

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

Texte clair

logging host nom_interface syslog_ip [ tcp/ port

Chiffré

logging host nom_interface syslog_ip [ tcp/ port | [sécurisé ]

Si une connexion TCP ne peut pas être établie avec le serveur syslogs, toutes les nouvelles connexions seront 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 plus d'informations sur syslog, reportez-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 implémentations ASA et ASASM de NSEL fournissent une méthode de suivi de flux IP dynamique qui exporte uniquement les enregistrements qui indiquent des événements significatifs dans un flux. Dans le suivi dynamique des flux, 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.

Pour plus d'informations sur Netflow sur ASA, reportez-vous au Guide de mise en oeuvre de Cisco ASA NetFlow :

Sécurisation de la configuration

Vérification des images sur ASA

À partir des versions 9.1(2) et 8.4(4.1), la prise en charge de la vérification de l'intégrité des images SHA-512 a été ajoutée. Pour vérifier la somme de contrôle d’un fichier, utilisez la commande verify en mode d’exécution privilégié.

Calcule et affiche la valeur MD5 de l'image logicielle spécifiée. Comparez cette valeur avec la valeur disponible sur Cisco.com pour cette image.

verify [ /md5 path ] [ md5-value ]

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 n'indique 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 doit être effectué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. Veuillez vous reporter au chiffrement de mot de passe pour plus d'informations.

Récupération du mot de passe du service

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

Dépannage

Il n'y a pas de section de dépannage pour ce document.