Modèle Cisco Access List IPv4
L'access-list suivante part du principe que l'interface à protéger route le réseau 192.168.1.0/24 (le routeur possédant l'adresse 192.168.1.1).
Dans cette access-list, nous partons avec quelques contraintes :
- Le serveur DNS primaire est hors de notre réseau (adresse DNS1_IP)
- Le serveur DNS secondaire est hors de notre réseau (adresse DNS2_IP)
- Le serveur DHCP est hors de notre réseau et nous utilisons du dhcp relay (adresse DHCPD_IP)
- Le serveur SMTP est hors de notre réseau (adresse SMTP_IP)
Nous n'interdisons rien aux utilisateurs qui sont dans ce réseau (si ce n'est des protocoles très dynamique dans l'utilisation des ports comme H.323)
Interface
dans la configuration de l'interface, il faut ajouter une référence aux access-list
interface Ethernet0 ip address 192.168.1.1 255.255.255.0 ip access-group aclModeleIn in ip access-group aclModeleOut out
Un mot sur int et out : Pour éviter les erreurs de "sens", il faut s'imaginer la tête dans le routeur. "in" est ce qui vient de l'exterieur et entre dans le routeur par l'interface Ethernet0, "out" est ce qui vient du routeur (généralement d'une autre interface) et sort par l'interface Ethernet0.
Access-list IN
ce qui vient de l'intérieur ce réseau, et qui veut sortir...
ip access-list extended aclModeleIn remark **** BLOCK UNKNOW SMTP (only smtp.univ-pau.fr) permit tcp 192.168.1.0 0.0.0.255 host SMTP_IP eq smtp deny tcp any any eq smtp log remark **** ALLOW LOCAL NETWORK (antispoofing) permit ip 192.168.1.0 0.0.0.255 any remark **** ALLOW DHCP RELAY permit udp any any eq bootps remark **** DENY/LOG ALL deny ip any any log
Quelques petites explications :
- Seul le serveur SMTP "connu" est joignable en tcp/25 (ceci évite à certains vers de ce connecter à des relais exterieurs... et donc de ce retrouver avec des plages IP blacklistées !)
- On autorise tout le reste si l'adresse IP source est correct
- On autorise les requetes DHCP à passer...
- On interdit le reste (et donc les adresses sources spoofée)
Access-list OUT
ce qui vient de l'extérieur de ce réseau, et qui veut y rentrer... (comme à la douane des USA : DON'T EXCEED THE BLACK LINE)
ip access-list extended aclModeleOut remark **** MULTICAST permit ip any 224.0.0.0 15.255.255.255 remark **** ANTI-SPOOFING deny ip 192.168.1.0 0.0.0.255 192.168.1.0 0.0.0.255 log deny ip 127.0.0.0 0.255.255.255 any log remark **** TCP ESTABLISHED, ICMP, NTP, IDENT permit tcp any any established permit icmp any any permit udp any eq ntp any permit tcp any any eq ident remark **** DHCP RESPONSES permit udp host DHCPD_IP eq bootps any eq bootpc remark **** DNS RESPONSES (only our DNS servers) permit udp host DNS1_IP eq domain any gt 1023 permit udp host DNS1_IP eq domain any eq netbios-ns permit udp host DNS2_IP eq domain any gt 1023 permit udp host DNS2_IP eq domain any eq netbios-ns remark **** ALLOW FTP MODE PORT permit tcp any eq ftp-data any gt 1023 remark **** ADD CUSTOM RULES HERE remark **** DENY/LOG ALL deny ip any any log
Quelques petites explications :
- established permet de laisser passer les réponses à toutes les transactions TCP initiée par un client de "l'intérieur" (ex: un client 192.168.1.3 fait une requête http sur un serveur exterieur, la réponse du serveur pour pénétrer dans le réseau)
Règles spécifiques
dans l'access-list OUT, il y a une remark appelée ADD CUSTOM RULES HERE. C'est exactement l'endroit pour ajouter les règles propres à ce réseau.
Imaginons les contraintes suivantes :
- La machine 192.168.1.100 est un serveur HTTP/HTTPS accessible du monde entier
- La machine 192.168.1.150 est un serveur NTP
- La machine 10.1.1.1 doit pouvoir ce connecter en ssh sur toutes les machines de notre réseau
- La machine 192.168.1.200 effectue une supervision SNMP d'équipements hors du réseau
Nous allons alors ajouter les rêgles suivantes :
permit tcp any host 192.168.1.100 eq www permit tcp any host 192.168.1.100 eq 443 permit udp any host 192.168.1.150 eq ntp permit tcp host 10.1.1.1 any eq 22 permit udp any eq 161 host 192.168.1.200 any
Remarques :
UDP n'est pas un protocole avec suivi (established n'a aucun impact). Donc, même si une client efféctue une requete SNMP sur l'exterieur, il faut explicitement autoriser la réponse dans l'access-list OUT.