[Cisco] Un problème d'ACL

Un problème d'ACL [Cisco] - Réseaux - Systèmes & Réseaux Pro

Marsh Posté le 27-03-2015 à 10:51:26    

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 :)  

Reply

Marsh Posté le 27-03-2015 à 10:51:26   

Reply

Marsh Posté le 27-03-2015 à 14:00:16    

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
Reply

Marsh Posté le 27-03-2015 à 16:31:48    

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
Reply

Marsh Posté le 27-03-2015 à 17:23:58    

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
Reply

Marsh Posté le 27-03-2015 à 17:51:53    

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 ? )

Reply

Marsh Posté le 30-03-2015 à 09:03:00    

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.
 
 

Reply

Marsh Posté le 31-03-2015 à 13:24:22    

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 ?

Reply

Marsh Posté le 01-04-2015 à 11:31:36    

Si effectivement

Reply

Marsh Posté le 01-04-2015 à 18:30:18    

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

Reply

Marsh Posté le 01-04-2015 à 21:06:20    

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
Reply

Marsh Posté le 01-04-2015 à 21:06:20   

Reply

Marsh Posté le 01-04-2015 à 22:45:19    

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 !
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed