Contenu réservé aux membres du site
Expert Réseau
15 ans d’expérience
CCNP Routing and Switching
Fondateur du site FingerInTheNet
CURSUS DE FORMATION
Administrateur Réseau
Présentation
Les protocoles
En pratique
Les options
Présentation
Les bases
Les tables OSPF
La Sécurité
Autres
Présentation
Les échanges
Choix de la route
Choix du masque
Sécurité
Comments (10)
Merci beaucoup pour le travail et bon résumé
Merci 🙂
Félicitations ! Quelques questions.
1 – Dans la section “ACL réflexive”, je suis un peu confus au sujet de ACL_DYN_CLT-SRV. Est-ce que cette ACL est crée automatiquement par l’IOS, à partir du moment où on spécifie “reflect” ?
2 – Ce que la conclusion dit “Une ACL se place toujours au plus près de la source”, ce n’est pas ce que j’avais appris sur les ACLs. J’avais appris que “l’ACL standard doit être très proche de la cible” et “l’ACL étendue doit être très proche de la source”.
3 – Une différence important entre l’ACL Standard et l’ACL est étendue est que l’ACL Standard ne peut être édité qu’en bloc (si on veut corriger l’ACL, il faut l’enlever au complet et la rééditer) ; alors que l’ACL Étendue permet d’éditer règle par règle, en utilisant des numéros de règle.
4 – Ça serait utile d’ajouter les précisions suivantes :
– Quand un paquet est reçu sur le port, les règles sont évaluées du haut ver le bas.
– Dès que le paquet match une règle de l’ACL, l’évaluation des règles s’arrête.
– À la fin de toutes les règles, le “deny all” est implicite.
pourriez m’aider sur comment configurer un firewall ASA
Bonjour Constantin,
Dans quel cadre tu souhaites configurer un firewall ASA ?
Salut KayouMT !
J’ai enfin fini de mettre à jour cet article 🙂
Pour répondre à tes questions :
1 –
– Dès qu’un flux est matché par notre access-list ACL_CLIENTS_VERS_SERVEUR, une règle de filtrage temporaire autorisant la réponse à cette requête vas être créer de manière dynamique dans l’ACL_SERVEUR_VERS_CLIENTS.
– Lorsque la réponse à la requête est passé par l’access-list reflexive, cette règle de flux sera supprimée.
2 – J’ai dit en conclusion qu’une access-list ce met au plus près de la source car cela évite que des paquets non autorisé ne soit routé et circule pour rien ! Après cela dépend du contexte. Je pense qu’il est difficile de sortir des règles de bonne usage des ACL. Pour les access-list standard, on va souvent les utiliser pour les line VTY, le SNMP et pleins d’autres !! Elles représentent vraiment un dernier rempart de sécurité ! Personnellement je vais en amont bloquer toutes les connexions SSH venant du WAN (Au plus proche de la source) et je vais mettre un dernier rempart de sécurité sur ma line VTY pour les demandes de connexion interne. Je n’ai pas envie que ces demandes de connexion traverse tout mon réseau pour rien 🙂
3 et 4 – J’ai rajouté tout ça dans l’article, effectivement c’est important de précisé ça 🙂
Encore merci à toi pour ta contribution et pour ton aide !
Merci beaucoup pour les réponses, Noel.
C’est OK pour 3 et 4. Sur 3, tu fais bien de me corriger. C’est “ip access-list” (et non l’ACL étendu) qui offre les avantages que j’ai cités.
Sur 1 ; il y a encore une petite confusion. ACL_CLIENTS_VERS_SERVEUR et ACL_SERVEUR_VERS_CLIENTS sont définis dans R1, mais sont configurés sur une interface de SW_D_01. À ma connaissance ; une ACL est locale à un routeur (ou une switch).
Sur 2 ; dans les livres de CCNA, les règles sont très claires. Ils disent pratiquement tous ce qui est dit dans le blog suivant : http://www.ccnablog.com/acls-access-control-lists-part-i/.
– For the extended type of ACLs, you should place them closest to the source of the traffic.
– Standard ACLs do not look at the destination address, therefore, you should place them closest to the destination network that you are filtering packets to.
C’est avec grand plaisir d’échanger avec quelqu’un d’aussi pointilleux que moi 🙂
– Pour la 1 (ACL reflexive) , tu as entièrement raison. Faute de frappe 🙂
– Pour la 2 …. Cela va peut être paraître choquant mais je ne suis pas tout à fait d’accord avec ce qui est dit. Je ne trouve pas pertinent de dire et faire apprendre cette règle aux gens car la mise en place d’une access-list se doit d’être intellect.
Petit cas de figure :
– J’ai un Switch ACCESS de niveau 2.
– Je décide que mon Vlan EQUIPEMENT_RESEAU est le Vlan 40.
– Je met l’adresse IP de mon switch sur l’interface vlan 40 de ce dernier.
– Toutes les autres interfaces Vlans (Clients / Serveurs / Voip / ect … ) sont sur mon coeur de réseau.
Je peux tout à fait filtrer les connexions SSH au niveau de mon coeur de réseau avec une acl étendu !!
Ce type de configuration est très courant .
Si on suis cette règle du CCNA, le fait de mettre une ACL standard sur les line VTY de nos équipements n’à aucune utilité … Pour moi il faut OBLIGATOIREMENT mettre une ACL sur les Line VTY ! Ça prend deux lignes dans la conf et rien en ressources physique en vue du trafic.
Je suis allé voir dans le CCNP SWITCH et ROUTE. Ils ne reprennent pas cette règles d’utilisation … Du moins je ne l’ai pas retrouvé.
Aujourd’hui les access-list standard ne sont utilisé uniquement pour les protocoles qui ne supporte pas les access-list étendu (Line VTY, SNMP ou autre …. De mémoire ils ne les supporte pas mais je ne mettrait pas ma main à coupé non plus … à vérifier ).
Dans ce cas , ma phrase « Une ACL se place toujours au plus près de la source » est encore moins valable ….
Je pourrais mettre un truc de ce style :
Une access-list prévu pour filtrer le flux de donnée (Data Plane) se place au plus près de la source et les access-list prévu pour protéger un service particulier présent dans la Management Plane se place directement sur le service à protéger. Le fait de filtrer le flux de donnée ne doit pas empêcher de sécurisé notre managment plane.
Mais j’ai peur de semer plus de troubles qu’autre chose … Qu’en pense tu ?
Le top ce serait de faire un article regroupant toutes les utilités que peut avoir une ACL :
– Pour la QOS
– Pour les Class-Map
– Pour le filtrage
et pleins d’autre !!
Salut Noel.
Je te remercie pour la correction du point 1. Je le testerai dans un lab, quand je vais avoir un peu plus de temps.
Concernant le point 2 ; je ne pense pas que ça soit une bonne idée que tu écrives un nouvel article pour ça. Il faut évidemment éviter “de semer plus de troubles”. En réalité, il n’y a pas de contradiction entre ce que tu dis et ce que le CCNA dit. C’est simplement que vous ne l’abordez pas sous le même angle. Toi, tu développes les différentes problématiques qu’on peut régler avec l’Étendu ou le Standard. Tandis que le CCNA a suggéré simplement l’emplacement idéal où placer l’ACL (selon que tu optes pour l’Étendu ou pour le Standard).
Si tu comptes développer un peu plus le sujet, tu pourrais t’inspirer du chapitre 35 du document suivant : https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/25ew/configuration/guide/conf.pdf. Tu peux être plus précis que le document en séparant le sujet sur 4 articles :
– Introduction à ACL (article actuel)
– ACL pour sécuriser le Management Plane
– ACL pour sécuriser le Data Plane
– ACL pour sécuriser le Control Plane
Bonne continuation.
Re-Salut.
J’ajoute un point-5 et non des moins importants. Le schéma “Mise en évidence des ACL réflexive” aurait, selon moi, besoin de beaucoup d’améliorations.
L’enjeu ici, selon moi, ce n’est pas l’activation (ou la désactivation) du firewall sur le PC. L’enjeu c’est l’activation des Reply ICMP dans une Switch ou Routeur. De ce fait ; il est important que tu mettes le Routeur (ou le Switch) entre les deux PCs.
Pour exprimer la problématique de l’ACL réflexive, les deux PCs doivent être prêts à traiter des ICMP Request/Reply. Les exceptions doivent donc être mises en place, de facto, sur le Firewall des 2 PCs, pour laisser passer les ICMP Request/Reply.
L’enjeu selon moi est de montrer que pour que la Switch (ou le Routeur) envoie au PC1 un Reply, l’ACL Réflexive doit être activée.
Ça serait aussi utile de faire deux schémas séparés :
– Avant l’activation de l’.ACL réflexive.
– Après l’activation de l’.ACL réflexive.
Je crois que type d’ACL est surtout pertinent pour des équipements comme ASA (Adaptive Security Appliance). Je présume que pour ce type d’équipements, il y une “ACL implicite” qui bloque certains protocoles ? Il faut donc demander une exception, en activant l’ACL Réflexive.