Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
2095 connectés 

  FORUM HardWare.fr
  Systèmes & Réseaux Pro
  Réseaux

  [Cisco] Un problème d'ACL

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

[Cisco] Un problème d'ACL

n°129788
siefgreed
Posté le 27-03-2015 à 10:51:26  profilanswer
 

Bonjour !  
 
je travaille actuellement sur un Switch cisco sur lequel je dois mettre des ACLs, mais je n'arrive pas à trouver de solutions satisfaisante.
 
L'idée est que le Switch propose une API de programmation accessible en https mais il n'est pas possible d'en restreindre l'accès autrement que par le login/password.
Nous voulons donc mettre des ACLs afin de sécuriser l'accès.
 
Nous voudrions donc autoriser TOUT le traffic quel qu'en soit sa nature et la source/destination SAUF le traffic ayant pour destination l'IP du switch et le port 443(https) qui serait restreint a une seule IP source (l'ip du serveur de management).
 
A votre avis, est-ce possible ? Si oui, comment s'y prendre ?  
 
Je ne voi pas comment organiser mes acls pour faire cela. (Surtout que je suis un peu une bille dans ce domaine ^^)
 
Merci d'avance pour vos réponses :)  

mood
Publicité
Posté le 27-03-2015 à 10:51:26  profilanswer
 

n°129805
okinawa02
Posté le 27-03-2015 à 14:00:16  profilanswer
 

Salut,
 
des acl du style :
 
permit host "ip du serveur" host "ip du switch" eq 443
deny any host "ip du switch" eq 443
 
 
Tu as déjà essayé ça ?


Message édité par okinawa02 le 27-03-2015 à 14:03:35
n°129816
siefgreed
Posté le 27-03-2015 à 16:31:48  profilanswer
 

Salut,  
 
Merci pour ta réponse ! :jap:  
 
J'avais cru comprendre que les acls fonctionnaient de la manière suivante :
 
1. Recherche de correspondance (examen de chaque paquet)
2. Action (deny ou permit)
Ensuite ,
3. Si pas de correspondance, instruction suivante
4. Si aucune correspondance, l'instruction implicite est appliquée sachant qu'une instruction implicite rejette tout le trafic à la fin de chaque liste d'accès
 
Donc en toute logique, tous les autres types de trafic seraient bloqué, non ?  
Ou alors il faut rajouter un " permit any any" pour autoriser le reste du trafic et qu'il ne soit pas bloqué ? (mais auquel cas, ca n'annulerais pas les règles précédentes ? )  
 
J'avoue que je suis un peu perdu là :pt1cable:


Message édité par siefgreed le 27-03-2015 à 16:32:06
n°129819
okinawa02
Posté le 27-03-2015 à 17:23:58  profilanswer
 

J'ai bossé sur les ACL dans mon réseau hier donc c'est encore frais dans ma tête, je viens de refaire le test pour ton cas à l'instant ( je suis motivé pour un vendredi à quelques minutes du week end  :bounce: )
 
par exemple : je veux bloquer le bureau à distance sur les serveurs (port 3389)
 
j'ai mis comme acl sur le vlan en question
 
10 deny tcp any any eq 3389
20 permit tcp any any  
 
ça bloque bien le bureau à distance tout en laissant passer les requêtes DHCP et HTTP etc...  
 
Donc dans ton cas, je pense que tu peux appliquer  
10 permit tcp host "ip du serveur" host "ip du switch" eq 443
20 deny tcp any host "ip du switch" eq 443
30 permit tcp any any
 
Fais les tests, logiquement ça devrait être bon :jap:


Message édité par okinawa02 le 27-03-2015 à 17:25:43
n°129820
siefgreed
Posté le 27-03-2015 à 17:51:53  profilanswer
 

Merci beaucoup pour les precisions :)  
 
Je n'ai malheureusement plus acces au switch pour aujourd'hui, mais je bosse demain, donc je testerais tout ça demain !  
 
Donc si je comprend bien, les protocoles sur lesquels ont ne définie aucune ACLs seront autorisés par default ?  
 
Je pensais qu'à partir du moment ou l'on en plaçait une, il fallait explicitement autoriser tout le reste (par exemple dans ce cas les paquets dhcp passent car aucune règle n'est définie sur l'udp ? )

n°129827
okinawa02
Posté le 30-03-2015 à 09:03:00  profilanswer
 

Oui ton raisonnement est le bon, il faut que tu explicites tout le reste.
Si tu mets juste un "permit tcp any any eq 3389" tu vas autoriser le bureau à distance mais tout le reste sera rejeté.  
Il faut donc mettre en place une acl pour chaque type de requête que tu veux autoriser ou alors comme on l'a dit au dessus, tu mets un permit tcp any any à la fin de tes ACL.
 
 

n°129878
siefgreed
Posté le 31-03-2015 à 13:24:22  profilanswer
 

Salut !  
 
Pour etre sur que tout le trafic soit bien autorisé, un permit ip any any ne serait pas plus adapté qu'un permit tcp any any ?

n°129901
okinawa02
Posté le 01-04-2015 à 11:31:36  profilanswer
 

Si effectivement

n°129913
siefgreed
Posté le 01-04-2015 à 18:30:18  profilanswer
 

En tout cas je te remercie ! tout fonctionne parfaitement maintenant ! :)

n°129914
bardiel
Debian powa !
Posté le 01-04-2015 à 21:06:20  profilanswer
 

siefgreed a écrit :

Pour etre sur que tout le trafic soit bien autorisé, un permit ip any any ne serait pas plus adapté qu'un permit tcp any any ?


Tout dépend de ce qui doit transiter sur son réseau.
En bloquant l'UDP, il bloque de fait tout ce qui l'utilise, comme par exemple les propagations et requêtes DNS, SNMP, la VoIP...
 
Rien n'empêche aussi de faire un permit tcp any any puis d'ajouter ce qu'il a besoin par la suite en UDP, sans débloquer tout l'UDP.
 
Important aussi, à voir s'il fait son drop en entrée ou en sortie :D


---------------
Grippe ? Coronavirus ? Portez votre masque correctement ! :D
mood
Publicité
Posté le 01-04-2015 à 21:06:20  profilanswer
 

n°129915
o'gure
Multi grognon de B_L
Posté le 01-04-2015 à 22:45:19  profilanswer
 

siefgreed a écrit :

Salut !

 

Pour etre sur que tout le trafic soit bien autorisé, un permit ip any any ne serait pas plus adapté qu'un permit tcp any any ?


si, être explicite dans la dernière est une bonne pratique.

bardiel a écrit :


Tout dépend de ce qui doit transiter sur son réseau.
En bloquant l'UDP, il bloque de fait tout ce qui l'utilise, comme par exemple les propagations et requêtes DNS, SNMP, la VoIP...

 

Rien n'empêche aussi de faire un permit tcp any any puis d'ajouter ce qu'il a besoin par la suite en UDP, sans débloquer tout l'UDP.

 

Important aussi, à voir s'il fait son drop en entrée ou en sortie :D


Il dit lui même dans le premier post : tout doit être autorisé sauf l'accès à l'admin du switch restreint au seul admin. Donc tout = ip.
(Au passage, icmp ça peut être pratique pour recevoir les messages d'erreur d'IP.)
Autorisation de l'admin vers le swtich
Refus de tout vers le switch
Autorisation de tout


Message édité par o'gure le 01-04-2015 à 23:03:01

---------------
Relax. Take a deep breath !

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Systèmes & Réseaux Pro
  Réseaux

  [Cisco] Un problème d'ACL

 

Sujets relatifs
Problème intégration serveur 2012 essential dans forêtproblème de connexion aux lecteurs réseaux.
Problème de détection de boucle - HP ProcurveProblème MDT - Ca bloque
Problème gimagexProblème de login depuis client 7/2K8 vers serveur en 2K8
Logiciel CTI problème pc <<<==>>>> telProblème de performance CPU sous Hyper-V
Borne wifi CiscoProblème avec un profil sur AD [résolu] merci tout seul
Plus de sujets relatifs à : [Cisco] Un problème d'ACL


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR