Bonjour,
 
j'aimerais savoir quel sont les bonne pratiques ( chez Cisco)  entre des ACL nommés sur des switchs et des ACL sur un Parefeu ASA. N'est ce pas un peu redondant?
 
Chez nous les switchs ( coeur de réseau) ont des extended ACL ou tout est fermé sauf ce qui doit l'être (bon, logique), sauf qu'au final, à force d'ouvrir des trucs pour X ou Y raisons, ça fait un peu usine à gaz. et derrière on a un ASA qui lui aussi à une tonne de règle de filtrage.  
Tout ça n'est il pas redondant? Quel sont les bonne pratiques?

Hello,
 
En général, tes core switch vont filtrer le traffic entrant pour le côté administratif : SNMP, NTP, SSH (VTY),AAA,etc.
Bref bloquer tout ce qui n'est pas censé entrer dans le réseau, jusqu'au pare-feu.
Ton pare-feu viendra ensuite filtrer toute la partie opération : serveurs, imprimantes,etc..
Ce n'est donc pas redondant. Ça peut effectivement l'être si vous devez ouvrir votre traffic des 2 côtés. Dans ce cas, oui, ça serait clairement pas optimisé.

Les ACL c'est chiant à administrer comparé à des règles de pare-feu. Du coup on préfère router et donc gérer les règles au niveau pare-feu plutôt que switch.
Le problème, c'est que pour des raisons de performances, on doit router au niveau switchs sur des réseaux avec un fort trafic à router car un pare-feu a un throughput très limité comparé à un switch (ou alors partir sur des trucs très chers pour opérateurs et compagnie)
A voir selon le réseau...
Après, il existe maintenant des switchs type Meraki où on peut tout gérer en web et du coup c'est un peu plus simple de faire des ACL.

Ca dépend sutout comment est fait le réseau.
Si le réseau de management n'est pas derrière un Firewall, des acl sur les routeurs/switch sont nécessaires pour filtrer ce traffic de management : SNMP, NTP, SSH (VTY),AAA,etc.  
Pour le traffic applicatif, il faut laisser cela au Firewall.

ok, merci de vos retour.  
 
Niveau applicatif, c'est sur le pare feu.  
 
Niveau inférieur, c'est sur les switchs. Disons que le truc chiant, que le réseau a été totalement refait, c'est qu'on a de multiples vlan, , que les extended acl leur sont associés tout en étant assez restrictives et qu'au fil de l'eau, et des remontés de problèmes par des utilisateurs, on ajoute bcp de règles sur les acl des switchs. Il faut dire qu'on a énormément d'appli métier, donc pas mal ancienne, avec des fonctionnement qui font que certains postes client doivent pouvoir avoir des accès sur certaines choses.
Évidemment, après le filtre degrossi des  acl des switch, tout va sur le firewall et on affine un peu. Après, oui c'est vrai que j'imagine que faire un premier tri niveau switch core, ça dégage pas mal de chose et évite d'encombrer.  
 
Comme on a refait totalement le réseau, on a fonctionné en parallèle avec ancien coeur de réseau / nouveau coeur de réseau. C'est là qu'on s'aperçoit qu'il y a un gros toilettage à faire sur les ACL car certaines, noyé dans la masse,  concernent des équipements qui n'existent même plus. Idem côté ASA
 
C'est pas mon taf d'origine, mais c'est intéressant  

Le problème c'est que très souvent on fait plein de VLANs pour rien. Les VLANs devraient être envisagés pour vraiment segmenter des réseaux qui n'ont pas pour vocation à parler ensemble constamment...
Par exemple séparer le serveur de fichier sur un VLAN à part des users sous prétexte que c'est un serveur, c'est couillon. On va passer son temps à router entre ces 2 VLANs pour un gain de sécu de... 0 !

il y a d'autres considérations, par exemple séparer en vlans permet de garantir qu'un utilisateur n'ira pas se renuméroter avec l'adresse IP du serveur ou de la gateway. Et il ne faut pas penser qu'au trafic local mais aussi aux échanges au niveau global, on peut vouloir accorder plus de confiance à un réseau maîtrisé uniquement par l'équipe d'administration qu'un réseau qui contient des machines sur lesquelles les utilisateurs ont la main.