cisco
VLAN et Trunk 802.1q
par guiguiabloc le 03 fév, 2009, sous OpenBSD, architecture, cisco, linux, réseau
En relisant quelques anciens billets, je me suis rendu compte que je n’avais pas abordé précisément la notion de vlan et de trunk dans une architecture réseau.
Corrigeons donc cela rapidement.
Un VLAN est un réseau Virtuel. Dans un réseau local physique, vous pouvez donc mettre en place des réseaux logiques, séparés les uns de autres, on parle alors de « segmentation ».
Pour pouvoir mettre cela en place, il vous faut donc un switch qui supporte cette fonctionnalité.
Si maintenant vous désirez propager plusieurs VLANs sur un même lien physique, il faut configurer un « trunk » et la norme établie est la 802.1q aussi appelé couramment : dot1q.
Pour cela, il faudra que vos paquets soit « taggués », c’est à dire qu’ils contiennent dans leurs en-têtes le numéro du vlan (VLAN ID) pour lequel ils sont destinés.
(Cisco supporte bien évidemment cette norme sur ses équipements, mais également sa propre norme propriétaire, ISL « Inter Swtich Link », dont je ne parlerais pas ici).
En situation, nous aurons quelque chose de ressemblant a ceci :
Outre un switch supportant les VLANs, il vous faudra bien évidemment un routeur pour les routages inter-vlan (ou un pc faisant office de routeur).
Bref, a la fin, vous risquez de vous retrouvez avec cela (vous avez de la chance, je vous ouvre les arcanes de mon installation personnelle 
)
Réseau Perso Guiguiabloc
(Vous trouverez un billet sur la naissance de cette baie ICI )
Les exemples suivants se basent sur un Switch Catalyst 2924 XL et un Routeur 2611-XM, mais ils restent standard pour tout IOS récent (comprendre qui n’a pas 10 ans…)
La création d’un VLAN sur le switch est très simple :
catalyst#vlan database catalyst(vlan)#vlan 2 name vlan_base_de_donnees VLAN 2 added: Name: vlan_base_de_donnees
Sur l’interface du switch où est branché votre pc/serveur, vous définissez alors sur quel VLAN il est relié :
catalyst#conf t Enter configuration commands, one per line. End with CNTL/Z. catalyst(config)#int fastEthernet 0/1 catalyst(config-if)# switchport mode access catalyst(config-if)# switchport access vlan 2 Ce qui donne : interface FastEthernet0/1 description serveur Mysql port block multicast switchport access vlan 2 spanning-tree portfast no cdp enable
La variable « switchport access » définit le droit d’accès au VLAN.
Attention : Il existe un VLAN un peu particulier, le VLAN 1, qui est le VLAN de Management des équipements Cisco. Eviter donc d’y mettre des machines accessibles par tous.
Certains recommandent de déplacer le VLAN 1 sur un autre VLAN, personnellement, ça ne m’a pas porté chance de jouer à cela, donc un peu de rigueur suffit en changeant les vlans natifs sur les interfaces.
Sachez que sur le Catalyst 2924, il existe une petite commande sympa et peu documentée :
switchport mode multi swichport multi vlan 1,2,3
Cela permet a une machine d’accéder à plusieurs VLANs sans avoir à tagguer ses trames.
Dans ce mode de configuration, les machines connectées aux interfaces du switch n’ont pas besoin de tagguer leurs paquets, donc une configuration réseau toute basique (avec en passerelle l’interface définit dans votre routeur par exemple).
La connectivité entre notre routeur et notre switch par contre sera différente.
Nous avons 1 (voire 2) interfaces physiques sur le Cisco 2600 et c’est sur cette interface que nous allons faire passer l’ensemble des VLANs afin de permettre au routeur de… router 
Coté Switch :
interface FastEthernet0/2 description Trunk fastEthernet 0/0 rt-2611 duplex full speed 100 switchport trunk encapsulation dot1q switchport mode trunk spanning-tree portfast no cdp enable
Ici, le mode du switch est « trunk » et l’encapsulation, 802.1q.
Sans spécifications particulières, nous passons l’intégralité des VLANs définis sur le switch sur cette interface.
Vous pouvez bien sur être plus restrictif sur cette configuration :
switchport trunk allowed vlan 2,3 # autorise que l'accès aux VLANS 2 et 3
Attention : Dans ce genre de configuration, un paquet non taggué partira dans le vlan par défaut qui est le VLAN 1.
N’oubliez donc pas d’indiquer explicitement le VLAN par défaut en cas de trames non tagguées :
switchport trunk native vlan 2 # on envoie sur le vlan 2 si pas de tag
Côté Routeur 2600 :
interface FastEthernet0/0.1 encapsulation dot1Q 1 native ip address 192.168.0.254 255.255.255.0 ip virtual-reassembly no cdp enable
Il ne vous reste plus qu’a définir vos interfaces « virtuelles » sur votre routeur Cisco :
Pour le VLAN 2 par exemple :
interface FastEthernet0/0.2 encapsulation dot1Q 2 ip address 192.168.2.254 255.255.255.0 no cdp enable
NB : Si vous voulez faire sortir vos machines par votre passerelle générale (exemple le pix :-p) n’oubliez pas les nat inside/outside sur vos interfaces, ainsi que des ACL bien placées.
Côté Linux :
Si vous voulez faire du trunk sur Linux, il suffit d’activer le support 802.1q dans le noyau.
Sous Debian, apt-get install vlan
Sous RedHat, le support est natif
Création de l’interface :
Debian :
vconfig add eth0 2 (pourt créer le VLAN 2)
Modification du fichier /etc/network/interfaces :
auto eth0.2 iface eth0.2 inet static address 192.168.2.254 netmask 255.255.255.0 network 192.168.2.0 broadcast 192.168.2.255 vlan_raw_device eth0
RedHat :
Création du fichier /etc/sysconfig/network-scripts/ifcfg-eth0.2
DEVICE=eth0.2 BOOTPROTO=static HWADDR=XX:XX:XX:XX:XX:XX IPADDR=192.168.2.254 NETMASK=255.255.255.0 NETWORK=192.168.2.0 ONBOOT=yes TYPE=Ethernet VLAN=yes
Rédémarrage des services réseaux bien entendu.
Dans les 2 cas, pour supprimer l’interface, il faudra passer un :
vconfig rem eth0.2
(ps: l’écriture d’un alias d’une interface « vlan » se note : eth0.2:1 par exemple)
Côté OpenBSD :
création du fichier /etc/hostname.vlan2 (vlandev étant votre interface réseau physique)
inet 192.168.2.254 255.255.255.0 vlan 2 vlandev sis0
Sous Windows, ce n’est absolument pas natif, tout dépend de la carte réseau et du pilote du fabricant fourni… (en même temps, qui voudrait faire un routeur avec windows )
Voilà, j’espère que ces explications vous aideront a mettre en oeuvre des VLANs chez vous, et surtout à l’utiliser car en cloisonnement, c’est quand même l’idéal.
Switch applicatif avec OpenBSD, un Altéon à la maison ?…
par guiguiabloc le 14 jan, 2009, sous OpenBSD, architecture, cisco
Dans une infrastructure informatique sensible, la disponiblité des applicatifs est primordiale.
Pour répondre à cette exigence, les solutions mises en oeuvre se basent donc sur de la haute-disponibilité et de l’équilibrage de charge (communément appelé LoadBalancing).
J’avais déjà évoquer la haute-disponibilité sous Linux dans ce billet et abordé ce type d’architecture dans celui ci.
Je vais donc aller un peu plus loin dans ce concept et tenter de mettre en oeuvre un équivalent « open-source » d’un produit commercial.
Ceux qui d’entre vous travaillent ou ont travaillé dans ce genre d’environnement, doivent avoir de fortes chances d’avoir croiser dans les baies des boitiers « Alteons ».
(merci à Morgan pour les Altéons ))
Alteon WebSytems est une société américaine spécialisée dans la haute-disponibilité et rachetée par Nortel fin 2000.
Les produits s’appellent désormais AS (pour Application Switch) et vous trouverez un comparatif des boiboites ICI, mais par facilité, le terme « Alteon » est toujours employé.
Sachez que chez CISCO également il existe ce genre de solution (ACE).
Je ne rentrerais pas dans les arcanes d’un altéon mais en voir rapidement le principe et d’en construire un équivalent chez soi.
Globalement, le principe est le suivant :
(source image IBM)
La configuration se fait sur 4 points principaux donc je vais vous détailler la configuration ci-dessous.
Il s’agit d’une configuration de base pour un loadbalancing en haute-dispo sur 2 serveurs web.
Spécial grand Merci à Steven pour son aide sur l’Alteon 
1 – Les serveurs réels
Il s’agit des applications à « load balancer ».
/cfg/slb/real 1 enable rip aa.bb.cc.dd #l'ip du serveur réel 1 retry 2 #nombre d'essai avant de considérer le serveur comme down restr 2 #nombre d'essai avant de considérer le serveur comme up inter 15 #intervalle entre 2 checks en secondes name lenom /cfg/slb/real 2 enable rip aa.bb.cc.ee retry 2 restr 2 inter 15 name lenom
2 – Le groupe
On regroupe ensuite les applications à « load balancer » au sein d’un même groupe. Le groupe comprend les Real Servers ainsi que le « jeu » de test permettant de vérifier leur bon état.
cfg/slb/group 1 health http #service concernée, ici http mais peut être : link|arp|icmp|tcp|http|httphead|dns|pop3|smtp| nntp|ftp|imap|sslh|radius-auth|radius-acc|radius-aa|script|udpdns|wsp|wtp|wtls|ldap|snmp|tftp|rtsp|sip|wts|dhcp viphl disable #désactive le check VIP lié au DSR (Direct Server Return) content "/status.html" #la page a checker add 1 #ajout du serveur réel 1 dans le groupe add 2 #ajout serveur 2 dans le groupe name lenomdugroupe
3 – Le virtual server
Un Virtual Server se caractérise par son adresse virtuelle (VIP), son port d’écoute virtuel (service), le groupe de Real server auquel il est associé et les ports d’écoute des Real Servers
/cfg/slb/virt 1 enable vip 10.1.1.1 /cfg/slb/virt 1/service 80 group 1 hname lenom epip ena #on force la sélection par egress ou VLAN
4 – le virtual router
Le routeur virtuel qui contient la VIP, le groupe, l’interface physique et la priorité par rapport à son « voisin ».
/cfg/l3/vrrp/vr 1 (avec le chiffre égale au virt associé) ena vrid n # le numero du Virtual Routeur if 1 # l'interface prio 99 #la priorité (plus le chiffre est haut plus l'atéon est prioritaire par rapport a l'altéon de backup) addr 10.1.1.1 #la VIP share dis #on désactive l'extension Nortel VRRP
Un dessin valant toujours mieux qu’un long discours , nous allons imaginer l’architecture suivante :
- 2 Altéons
- 1 VLAN dédié aux IP loadbalancées en 10.0.0.0/24
- 1 VLAN dédié aux serveurs Web en 192.168.1.1/24
- 2 serveurs Web
C’est forcément simplifié au maximum mais cela donne une idée de ce que nous allons mettre en place.
Avec des « Altéons », nous aurions donc ce genre de schéma :
Shématisation Alteon
Le but étant de reproduire a peu près la même chose chez soi, il y a un système d’exploitation qui contient déjà tout ce qu’il faut pour cela : OpenBSD.
Alors, oui, on pourrait faire la même chose avec Linux, en se tapant l’installation d’Ucarp, Balance, LVS et/ou autres joyeusetés, mais personnellement, je préfère laisser cela a OpenBSD qui peut le faire nativement et qui a fait ses preuves en environnement réseau critique.
Après tout, OpenBSD est amour, avec du poil autour, et c’est tout.
Reprenons notre schéma et adaptons le à une solution basée sur 2 serveurs sous OpenBSD pour remplacer les « Altéons » :
Schématisation OpenBSD
Ne reste qu’a configurer tout cela
- CARP + VLAN (optionnel)
Définir une VIP sur nos OpenBSD (une interface CARP sur interface physique ou sur interface VLAN)
/etc/sysctl.conf net.inet.carp.preempt=1 net.inet.carp.allow=1 #ifconfig carp0 create #ifconfig carp0 vhid 1 pass motdepasse carpdev em0 advskew 1 10.0.0.1 netmask 255.255.255.0 Pour un VLAN (exemple): cat /etc/hostname.vlan3 inet 10.0.0.3 255.255.255.0 vlan 3 vlandev em0 cat /etc/hosname.carp0 inet 10.0.0.1 255.255.255.0 10.0.0.255 vhid 1 carpdev vlan3 advskew 1 pass motdepasse
Je ne m’attarde pas la dessus, en ayant déjà parler sur CE BILLET.
- PFSYNC
ifconfig pfsync0 syncpeer "ip openbsd en face" syncdev em1 ifconfig pfsync0 up
- Partie PF / Hoststated
/etc/pf.conf
rdr-anchor "hostatetd/*"
table persist { 192.168.1.1, 192.168.1.2 }
rdr on $carp0 from any to $ipcarp port 80 -> round-robin sticky-address
# la variable sticky-address signifie que PF maintient la session du client sur le même serveur
/etc/hoststated.conf
real1="192.168.1.1"
real2="192.168.1.2"
vip="10.0.0.1" # VIP CARP
interval 5 #on vérifie l'état des serveurs toutes les 5 secondes
table messerveurs {
check http "/status.html" code 200
timeout 300
real port 80
host $real1
host $real2
}
service www {
virtuel ip $vip port 80
table messerveurs
}Petite explication :
On utilise une table « messerveurs » qui contient la liste des serveurs à « loadbalancer ».
PF redirige les requètes entrantes sur la VIP (10.0.0.1) alternativement (round-robin) et maintient la session du client sur le même serveur (sticky-address).
Bien évidemment, tout cela est optionnel et à vous d’adapter selon vos applis (man pf ).
Le démon Hoststated vérifie que les serveurs réels sont bien vivants en appelant la page status.html sur chacun des serveurs de sa liste.
En cas de non réponse (code retour http différent de 200), il considérera le serveur comme down et le retirera de la table « messerveurs ».
C’est pas beau tout cela ?
La commande # hoststatectl show vous donnera l’état des serveurs et vous pouvez manuellement les sortir ou les remettre dans le pool (# hoststatectl host disable/enable 192.168.1.x).
Et petit bonus, vous pouvez agir directement sur la couche 7
Exemple de relais load-balancé HTTPS :
protocol monchteuteupeucrypte {
protocol http
header append "$REMOTE_ADDR" to "X-Forwarder-For"
header append "$SERVER_ADDR:$SERVER_PORT" to "X-Forwarder-By"
header change "Keep-Alive" to "$TIMEOUT"
url hash "sessid"
cookie hash "sessid"
path filter "*command=*" from "/cgi-bin/index.cgi"
ssl { sslv2, ciphers "MEDIUM:HIGH" }
tcp { nodelay, sack, socket buffer 65536, backlog 128 }
}
relay wwwssl {
listen on $vip port 443 ssl
protocol monchteuteupeucrypte
table messerveurs loadbalance
}Maintenant que je vous ai titillé avec tout cela, je vous invite, outre à manger les MAN d’OpenBSD, mais aussi à lire cet excellent ouvrage :
The Book of PF
A No-Nonsense Guide to the OpenBSD Firewall
Par Peter N.M. Hansteen
Vous le trouverez chez Amazon par exemple :
http://www.amazon.fr/Book-PF-No-nonsense-Guide-Firewall/dp/1593271654
Conclusion :
Loin de moi l’idée de vous dire qu’une architecture comme celle-ci sera tout aussi efficace qu’un Switch Applicatif hors de prix, il existe des fonctions sur ces boitiers que l’on peut évidemment reproduire mais qui demanderons du temps…
Par contre, ce type d’architecture n’a pas a rougir en Production pour load-balancer des applications se prétant à ce jeu.
Amusez vous bien
Gestion d’une PKI : Installation d’un répondeur OCSP
par guiguiabloc le 05 jan, 2009, sous cisco, linux, sécurité
Déjà avant tout, Excellente Année 2009 à vous tous
La gestion des certificats SSL et/ou X509 est une très bonne chose pour le contrôle et la sécurité de l’accès à vos systèmes d’informations.
Je ne parlerais pas de la façon de monter une PKI chez soi, j’avais écris un précédent billet ICI sur lequel vous pouvez vous baser.
OSCP ??? C’est quoi ce truc encore ….
OCSP signifie Online Certificate Status Protocol. C’est un protocole définit dans la RFC 2560 qui permet de valider un Certificat numérique X509.
En clair, cela vous permet d’offrir à vos « clients, amis, potes…. » une fonction de vérification en ligne de la validité d’une certificat.
Petit exemple (source Wikipédia) :
- Alice et Bob sont des clients d’Ivan, l’autorité de certification (AC). Ils possèdent le certificat de clé publique d’Ivan.
- Alice et Bob possèdent chacun un certificat de clé publique émis par Ivan.
- Alice veut effectuer une transaction avec Bob. Elle lui envoie donc son certificat contenant sa clé publique.
- Bob veut s’assurer que le certificat d’Alice n’a pas été révoqué. Il crée une requête OCSP contenant l’empreinte du certificat d’Alice et l’envoi à Ivan.
- Le répondeur OCSP d’Ivan vérifie le statut du certificat d’Alice dans la base de données de la CA.
- Le répondeur OCSP confirme la validité du certificat d’Alice en envoyant une réponse OCSP positive signée à Bob.
- Bob vérifie la signature cryptographique de la réponse.
- Bob effectue sa transaction avec Alice.
Je vous invite donc fortement, avant de continuer, à lire cet article explicatif.
Il existe un projet libre de répondeur OCSP , qui est inclus dans l’excellentissime projet OpenCA :
http://www.openca.org/projects/ocspd/
Commencons donc par télécharger les sources ICI (dernière version disponible, la 1.5.1-rc1).
L’installation est des plus basiques (a vous de voir pour le prefix) :
$ ./configure --prefix=/opt/ocspd $ make $ su # make install
On créer un groupe et un user dédié et on affecte les droits :
pki:/opt/ocspd# groupadd ocspd pki:/opt/ocspd# useradd -d /opt/ocspd -g ocspd -s /bin/false ocspd pki:/opt/ocspd# chown -R ocspd:ocspd /opt/ocspd
Avec votre système de PKI préférée, générer un certificat publique et un certificat privé pour votre serveur OCSP. (attention au hostname, dans mon cas, ocsp.guiguiabloc.fr)
Copier les, ainsi que votre certificat CA, dans /opt/ocspd/etc/ocspd/certs
Il ne reste qu’a configurer votre répondeur :
cat /opt/ocspd/etc/ocspd/ocspd.conf [ ocspd ] default_ocspd = OCSPD_default # The default ocspd section #################################################################### [ OCSPD_default ] dir = /opt/ocspd/etc/ocspd # Where everything is kept db = $dir/index.txt # database index file. md = sha1 ca_certificate = $dir/certs/CA_Guiguiabloc-cert.pem # The CA certificate ocspd_certificate = $dir/certs/ocsp-cert.crt # The OCSP server cert ocspd_key = $dir/certs/ocsp-key.pem # The OCSP server key pidfile = $dir/ocspd.pid # Main process pid user = ocspd group = ocspd bind = 192.168.1.1 (l'ip sur laquelle écouter ou * pour toutes les interfaces) port = 2560 crl_auto_reload = 3600 crl_reload_expired = yes response = ocsp_response .... [ ocsp_response ] dir = /opt/ocspd/etc/ocspd ocsp_add_response_keyid = yes ... [ first_ca ] crl_url = file:////opt/ocspd/etc/ocspd/crls/crl-Guiguiabloc.pem (la liste de révocation de certificat) ca_url = file:////opt/ocspd/etc/ocspd/certs/CA_Guiguiabloc-cert.pem
Je vous laisse consulter le fichier conf en entier pour en comprendre le contenu et le modifier suivant vos besoins, mais la configuration ci-dessous, très simple, fonctionne pour un premier test.
Ne reste qu’a lancer le démon et verifier le syslog :
pki:#/opt/ocspd/sbin/ocspd -c /opt/ocspd/etc/ocspd/ocspd.conf -v & Jan 5 14:56:15 pki ocspd[22154]: OpenCA OCSPD v1.5.1 - starting. Jan 5 14:56:15 pki ocspd[22154]: reading certificate file (/opt/ocspd/etc/ocspd/certs/ocsp-cer t.crt). Jan 5 14:56:15 pki ocspd[22154]: Reading Private Key file /opt/ocspd/etc/ocspd/private/ocsp-ke y.pem Jan 5 14:56:15 pki ocspd[22154]: reading CA certificate file. Jan 5 14:56:15 pki ocspd[22154]: OCSP Daemon setup completed Jan 5 14:56:15 pki ocspd[22154]: variable lookup failed for OCSPD_default::chroot_dir Jan 5 14:56:15 pki ocspd[22154]: Auto CRL reload every 3600 secs Jan 5 14:56:15 pki ocspd[22154]: Reload on expired CRLs enabled Jan 5 14:56:15 pki ocspd[22154]: Number of CAs in configuration is 1 Jan 5 14:56:15 pki ocspd[22154]: INFO::FORMAT::CA Cert [//opt/ocspd/etc/ocspd/certs/CA_Guiguiabloc-cert.pem] is PEM formatted Jan 5 14:56:15 pki ocspd[22154]: CA CERT for first_ca loaded successfully. Jan 5 14:56:15 pki ocspd[22154]: CA List Entry added (CA list num 0) Jan 5 14:56:15 pki ocspd[22154]: INFO::CRL RELOAD::File Protocol Jan 5 14:56:15 pki ocspd[22154]: INFO::FILE::CRL is in PEM format Jan 5 14:56:15 pki ocspd[22154]: CRL loaded [ first_ca ] Jan 5 14:56:15 pki ocspd[22154]: CRL and CA cert [0:1] check ok Jan 5 14:56:15 pki ocspd[22154]: CRL matching CA cert ok [ 1 ] Jan 5 14:56:15 pki ocspd[22154]: INFO::CRL::Verify 1 [OK=1] Jan 5 14:56:15 pki ocspd[22154]: INFO::CRL is Valid Jan 5 14:56:15 pki ocspd[22154]: INFO::CRL::16 Entries [ first_ca ] Jan 5 14:56:15 pki ocspd[22154]: CRL loaded successfully [first_ca] Jan 5 14:56:15 pki ocspd[22154]: variable lookup failed for ocsp_response::ocsp_add_response_c erts Jan 5 14:56:15 pki ocspd[22154]: variable lookup failed for OCSPD_default::crl_check_validity Jan 5 14:56:15 pki ocspd[22154]: Configuration loaded and parsed Jan 5 14:56:15 pki ocspd[22154]: INFO::Local Address 192.168.1.1 [2560] Jan 5 14:56:15 pki ocspd[22154]: INFO::OPENCA_SRV_INFO_TREAD::new thread created
Bien évidemment, vous fournissez au répondeur OCSP, la Liste de révocation des certificats (fichier CRL) et la database (index.txt).
Si vous utilisez easyCA, ils sont générés sous $DIR et $DIR/crl par défaut (voir votre fichier openssl.cnf).
Et maintenant, interrogeons le serveur OCSP pour savoir si mon Certificat (ici webmail.guiguiabloc.fr) est encore valable :
pki:# openssl ocsp -issuer CA_Guiguiabloc-cert.pem -CAfile CA_Guiguiabloc-cert.pem -cert webmail.guiguiabloc.fr.crt -url http://192.168.1.1:2560 -text
OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 4A694097441CA470D697E82AF367D1F196B59680
Issuer Key Hash: 6490C296FF639D9B75A899E2DB29DC7DA42EE38D
Serial Number: 13
Request Extensions:
OCSP Nonce:
0410DDDA8DFEF460BA0C13ACCEBE7CDFDCB9
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: C = FR, ST = Bretagne, O = Guiguiabloc, OU = Guiguiabloc, CN = ocsp.guiguiabloc.fr, emailAddress = pki@guiguiabloc.fr
Produced At: Jan 5 14:21:40 2009 GMT
Responses:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 4A694097441CA470D697E82AF367D1F196B59680
Issuer Key Hash: 6490C296FF639D9B75A899E2DB29DC7DA42EE38D
Serial Number: 13
Cert Status: good
This Update: Jan 5 14:16:51 2009 GMT
Next Update: Jan 5 14:26:40 2009 GMT
Response Extensions:
OCSP Nonce:
0410DDDA8DFEF460BA0C13ACCEBE7CDFDCB9
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 16 (0x10)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=FR, ST=Bretagne, L=Brest, O=Guiguiabloc, OU=Guiguiabloc, CN=Guiguiabloc CA Authority/emailAddress=pki@guiguiabloc.fr
Validity
Not Before: Jul 18 08:08:25 2008 GMT
Not After : Jul 17 08:08:25 2013 GMT
Subject: C=FR, ST=Bretagne, O=Guiguiabloc, OU=Guiguiabloc, CN=ocsp.guiguiabloc.fr/emailAddress=pki@guiguiabloc.fr
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:bb:c8:c3:c0:78:26:88:8c:45:6c:2a:1b:88:fd:
71:57:c0:bb:23:e1:1e:40:86:d2:94:af:fc:e7:74:
41:3d:41:39:ac:a6:51:dc:4d:e8:80:53:a3:73:5d:
74:0e:1f:04:b1:78:dc:ad:45:65:5b:4f:0e:b2:92:
3c:bc:64:bb:3e:70:2c:ca:b8:ea:dc:fc:33:31:01:
d2:05:b2:e2:60:0c:d2:a6:c1:e9:83:b0:ca:d9:42:
98:44:8b:c3:df:63:dc:17:02:51:b6:f2:da:0e:c6:
81:fa:78:1c:d2:ca:56:52:f3
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature
X509v3 Extended Key Usage:
OCSP Signing
X509v3 Issuer Alternative Name:
X509v3 Subject Key Identifier:
1A:18:4A:7A:BC:DB:3E:CD:60:87:0B:A3:11:4D:4F:E6:CE:19:17:27
X509v3 Authority Key Identifier:
keyid:64:90:C2:96:FF:63:9D:9B:75:A8:99:E2:DB:29:DC:7D:A4:2E:E3:8D
DirName:/C=FR/ST=Bretagne/L=Brest/O=GuiGuiabloc/OU=Guiguiabloc/CN=Guiguiabloc CA Authority/emailAddress=pki@guiguiabloc.fr
serial:B9:0E:D5:3E:0F:DA:79:FF
Authority Information Access:
OCSP - URI:http://ocsp.guiguiabloc.fr/
Signature Algorithm: md5WithRSAEncryption
0c:3a:3f:79:7e:e4:21:be:1b:d1:d4:ef:8f:1d:33:af:f2:88:
eb:0f:40:cb:24:50:9b:47:cc:61:e2:a9:a3:6e:c5:4f:2a:7c:
b5:03:f1:a1:b8:b7:23:c7:e1:00:61:3a:c0:7c:8f:c6:2f:c7:
6a:c9:98:ad:af:ff:28:db:c6:1f:17:d3:54:f3:d7:1a:96:51:
19:04:6c:f8:92:74:70:de:54:c1:55:d3:9d:27:99:8b:09:be:
98:27:e6:5b:1e:14:a2:a9:d2:cb:a2:d7:52:8a:e1:ac:9b:a7:
52:a2:5b:90:dc:cc:8f:33:4b:7a:99:60:4d:5e:b9:e6:71:ed:
be:92
-----BEGIN CERTIFICATE-----
MIID/DCCA2WgAwIBAgIBEDANBgkqhkiG9w0BAQQFADCBnDELMAkGA1UEBhMCRlIx
ETAPBgNVBAgTCEJyZXRhZ25lMQ4wDAYDVQQHEwVCcmVzdDEVMBMGA1UEChMMU3R5
eCBOZXR3b3JrMRAwDgYDVQQLEwdTdHl4bmV0MSIwIAYDVQQDExlTdHl4IE5ldHdv
cmsgQ0EgQXV0aG9yaXR5MR0wGwYJKoZIhvcNAQkBFg5wa2lAc3R5eG5ldC5mcjAe
Fw0wODA3MTgwODA4MjVaFw0xMzA3MTcwODA4MjVaMIGCMQswCQYDVQQGEwJGUjER
MA8GA1UECBMIQnJldGFnbmUxFTATBgNVBAoTDFN0eXggTmV0d29yazEQMA4GA1UE
CxMHU3R5eG5ldDEYMBYGA1UEAxMPb2NzcC5zdHl4bmV0LmZyMR0wGwYJKoZIhvcN
AQkBFg5wa2lAc3R5eG5ldC5mcjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
psHpg7DK2UKYRIvD32PcFwJRtvLaDsaB+ngc0spWUvMCAwEAAaOCAWQwggFgMAkG
A1UdEwQCMAAwCwYDVR0PBAQDAgeAMBMGA1UdJQQMMAoGCCsGAQUFBwMJMAkGA1Ud
EgQCMAAwHQYDVR0OBBYEFBoYSnq82z7NYIcLoxFNT+bOGRcnMIHRBgNVHSMEgckw
gcaAFGSQwpb/Y52bdaiZ4tsp3H2kLuONoYGipIGfMIGcMQswCQYDVQQGEwJGUjER
MA8GA1UECBMIQnJldGFnbmUxDjAMBgNVBAcTBUJyZXN0MRUwEwYDVQQKEwxTdHl4
IE5ldHdvcmsxEDAOBgNVBAsTB1N0eXhuZXQxIjAgBgNVBAMTGVN0eXggTmV0d29y
ayBDQSBBdXRob3JpdHkxHTAbBgkqhkiG9w0BCQEWDnBraUBzdHl4bmV0LmZyggkA
uQ7VPg/aef8wMwYIKwYBBQUHAQEEJzAlMCMGCCsGAQUFBzABhhdodHRwOi8vb2Nz
cC5zdHl4bmV0LmZyLzANBgkqhkiG9w0BAQQFAAOBgQAMOj95fuQhvhvR1O+PHTOv
8ojrD0DLJFCbR8xh4qmjbsVPKny1A/GhuLcjx+EAYTrAfI/GL8dqyZitr/8o28Yf
F9NU89callEZBGz4knRw3lTBVdOdJ5mLCb6YJ+ZbHhSiqdLLotdSiuGsm6dSoluQ
3MyPM0t6mWBNXrnmce2+kg==
-----END CERTIFICATE-----
Response verify OK
webmail.guiguiabloc.fr.crt: goodRéponse : GOOD tout va bien
La réponse peut être: GOOD – REVOKED – UNKNOWN
Vous pouvez inclure directement dans votre certificat l’adresse de votre répondeur OCSP en ajoutant des extensions à votre openssl.cnf :
[OCSP] basicConstraints = CA:FALSE keyUsage = digitalSignature extendedKeyUsage = OCSPSigning issuerAltName = issuer:copy subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer:always authorityInfoAccess = OCSP;URI:http://ocsp.guiguiabloc.fr/ [SERVEUR_OCSP] nsComment = "Guiguiabloc Certificate" subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer:always issuerAltName = issuer:copy basicConstraints = critical,CA:FALSE keyUsage = digitalSignature, nonRepudiation, keyEncipherment nsCertType = server extendedKeyUsage = serverAuth authorityInfoAccess = OCSP;URI:http://ocsp.guiguiabloc.fr/ [CLIENT_OCSP] nsComment = "Certificat Client SSL" subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer:always issuerAltName = issuer:copy basicConstraints = critical,CA:FALSE keyUsage = digitalSignature, nonRepudiation nsCertType = client extendedKeyUsage = clientAuth authorityInfoAccess = OCSP;URI:http://ocsp.guiguiabloc.fr/
Puis d’invoquer l’extension lors de la création du certificat avec openssl (-extensions CLIENT_OCSP (par exemple).
Dans Firefox, pour configurer l’interrogation automatique du répondeur OCSP, allez dans Outils/Options/Avance/Chiffrement et cliquez sur « Vérification ».
Génial non ?
Petit bonus, sur votre Cisco préféré, on peut aussi faire de l’OCSP
rt-2611>en Password: rt-2611#conf t Enter configuration commands, one per line. End with CNTL/Z. rt-2611(config)#crypto pki trustpoint guiguiabloc rt-2611(ca-trustpoint)#ocsp url http://ocsp.guiguiabloc.fr:2560 rt-2611(ca-trustpoint)#revocation-check ocsp none
La dernière ligne est la méthode de vérification, l’option none spécifie que le routeur passera la vérification OSCP si le répondeur ne répond pas.
Pour les IOS 12.3 et supérieure (la page chez Cisco LA )
Amusez vous bien
Sauvegarde et Versionning automatique des confs Cisco avec Rancid
par guiguiabloc le 29 juil, 2008, sous cisco
Je discutais dernièrement avec Pascal_1, un fidèle lecteur du blog (merci ) , et utilisateur d’un Cisco Pix (donc quelqu’un de bien ).
Donc ce petit billet lui est spécialement dédicacé mais je ne doute pas qu’ils servent à d’autres .
Précédemment, je vous avais expliqué comment mettre en oeuvre une authentification centralisée via Tacacs+ sur vos Ciscos.
Nous allons nous servir de cette fonctionnalité pour sauvegarder automatiquement nos configurations et bien entendu, mettre en place un versionning CVS nous permettant de comparer les modifications apportés et pouvoir faire un retour arrière en cas de soucis.
Je partirais d’un serveur sous Gnu/Linux Debian qui servira de centralisateur des confs.
Les paquets à installer :
#apt-get install apache2 #apt-get install expect #apt-get install cvs #apt-get install cvsweb
Création d’un user « rancid » pour l’application :
#useradd -d /opt/rancid rancid
(j’installe mes programmes compilés toujours sous /opt mais je vous laisse libre de votre choix )
On récupère l’excellentissime logiciel RANCID :
ftp://ftp.shrubbery.net/pub/rancid/rancid-2.3.1.tar.gz
#tar xvfz rancid-2.3.1.tar.gz
Maintenant, nous pouvons compiler et installer Rancid :
#cd /usr/local/src/rancid-2.3.1#./configure --prefix=/opt/rancid #checkinstall
Ceci va installer Rancid dans le dossier /opt/rancid. Si vous n’avez pas la commande checkinstall sur votre système ou si vous désirez des informations sur cet outil, un article ICI.
Maintenant, nous pouvons débuter le paramétrage de Rancid. Nous allons configurer le fichier /opt/rancid/etc/rancid.conf pour créer des groupes d’équipements. Au moins un groupe doit être configuré.
L’ajout des lignes ci-dessous crée un groupe appelé « Mes_confs_a_moi » où tous les configurations des équipements sont stockées:
LIST_OF_GROUPS= »Mes_confs_a_moi »
Il peut être utile de créer plusieurs groupes si vous avez une grand nombre d’équipements et vous voulez les séparer par localisation géographique par exemple, pour améliorer la lisibilité.
LIST_OF_GROUPS= »Brest Toulon Trifouilly-les-oies »
Les noms de groupe doivent être séparés par un espace.
Il est nécessaire de configurer un fichier appelé “.cloginrc” contenant les mot de passe nécessaire à accéder aux composants réseaux.
Pour le créer, il faut renommer le fichier “cloginrc.sample” en “.cloginrc”.
#cp /opt/rancid/share/rancid/cloginrc.sample /opt/rancid/.cloginrc
Ensuite, nous éditons le nouveau fichier “.cloginrc” où on peut trouver des exemples de syntaxe basées sur le type d’équipement (Cisco, Juniper, etc…) et de connexion (telnet, ssh, …)
Dans notre exemple, nous allons utiliser ssh pour accéder à un switch Cisco ayant une adresse IP de 10.156.1.1 (et donc la connexion est controlé par notre serveur Tacacs+)
Ouvrez /opt/rancid/.cloginrc :
add user 10.156.1.1 lulu (l’utilisateur lulu, opérateur que j’avais crée dans mon tac_plus.conf)
add password 10.156.1.1 motdepasse_de_lulu motdepasse_mode_enable
Ajouter un # au début de chaque ligne à l’exception bien entendu des lignes qui paramètrent vos connexions.
Soyez EXTRÊMEMENT attentif avec les permissions du fichier .cloginrc parce que les mots de passe inclus dans ce fichier ne sont pas encryptés.
Donc le seul moyen de protéger ces mots de passe critiques est de restreindre les droits d’accès au fichier.
Pour le faire, changez les droits d’accès à 600, ce qui veut dire que le propriétaire du fichier a les permissions lecture et écriture tandis que les autres utilisateurs n’ont aucune permission du tout.
Puis, la propriété du dossier /opt/rancid ainsi que tous les fichiers et dossiers qu’il inclus est transféré à l’utilisateur rancid.
#chmod 600 /opt/rancid/.cloginrc #chown -R rancid:rancid /opt/rancid #chmod 770 /opt/rancid
Création de l’architecture CVS :
Connectez-vous en temps que rancid:
#su rancid rancid@linux#/opt/rancid/bin/rancid-cvs
Ajouter des équipements aux groupes:
/opt/rancid/var/rancid/"group_name"/router.db
La syntaxe est la suivante:
"ip_address or FQDN":"device_type":"status"
10.156.1.1:cisco:up nom_dns:cisco:up
Un script permet de vérifier les paramétrages de connexion qui sont présents dans le fichier .cloginrc:
rancid@linux:~/bin$ /opt/rancid/bin/clogin 10.156.1.1
10.156.1.1 spawn telnet 10.156.1.1 Trying 10.156.1.1… Connected to 10.156.1.1. Escape character is ‘^]’.
User Access Verification
Password: Router>enable Password: Router#
Démarrez rancid:
rancid@linux$/opt/rancid/bin/rancid-run
Vous pouvez vérifier les journaux (logs) dans le répertoire /opt/rancid/var/rancid/logs/ .
Nous devons maintenant installer la plate-forme pour voir les configurations avec un navigateur web.
CVSWEB
Nous devons ajouter une ligne dans le fichier /etc/cvsweb/cvsweb.conf avec l’utilisateur root pour créer le nouveau dépôt (repository) CVS.
Rechercher la ligne commençant par “@CVSrepositories” et ajouter la ligne en gras ci-dessous:
@CVSrepositories = (
#'local' => ['Local Repository', '/var/lib/cvs'],
'rancid' => ['rancid', '/opt/rancid/var/CVS/'],
#'freeebsd' => ['FreeBSD', '/var/ncvs'],
#'openbsd' => ['OpenBSD', '/var/ncvs'],
#'netbsd' => ['NetBSD', '/var/ncvs'],
#'ruby' => ['Ruby', '/var/anoncvs/ruby'],
);
Si le dossier contenant les icônes csvweb et les fichiers css sont pas dans le dossier /var/www, il est nécessaire d’ajouter un lien symbolique:
ln -s /usr/share/cvsweb /var/www/cvsweb
Nous pouvons tester l’interface cvsweb avec un navigateur internet :
http://127.0.0.1/cgi-bin/cvsweb
Optionnellement, vous pouvez configurer Rancid pour vous envoyer un mail quand une configuration a été changée après le lancement du script rancid-run.
L’outil Rancid est paramètré pour envoyer des courriels à deux destinataires par groupe.
rancid-"nom_du_groupe" rancid-admin-"nom_du_groupe"
Le premier destinataire ci-dessus va recevoir un rapport après un changement de configuration, le deuxième est envoyé quand il y a des messsages d’erreur.
Pour rappel le ou les groupes sont configurés dans le fichier /opt/rancid/etc/rancid.conf.
Par exemple, si vous avez un groupe appelé Mes_confs_a_moi, les mails seront envoyés aux adresses rancid-Mes_confs_a_moi et rancid-admin-Mes_confs_a_moi.
La dernière chose à faire est de créer des aliases pour vos destinataires. Ouvrez le fichier /etc/aliases:
rancid-mes_confs_a_moi
votre_email@chezvous.com rancid-admin-mes_confs_a_moi
votre_email@chezvous.com
Nous avons utilisés ici notre groupe exemple appelé Mes_confs_a_moi.
Pour terminer, initialiser la base de données d’alias:
#newaliases
Nous avons besoin de créer un cron job pour lancer rancid-run régulièrement.
crontab -e -u rancid
# Veuillez, svp, lancer le script rancid-run tous les jours à 00:30 30 00 * * * /opt/rancid/bin/rancid-run
La commande crontab va mettre à jour le fichier /var/spool/cron/crontabs/rancid.
La très utile commande “find” peut être ajoutée au crontab pour supprimer les anciens logs.
La commande suivante supprime les fichiers de plus de 30 jours dans le dossier /opt/rancid/var/logs/:
# supprime les anciens logs tous les premiers jours de chaque mois à 00:15
15 00 1 * * find /opt/rancid/var/logs -type f -mtime +30 -exec rm {} \;
Et voila, désormais vous retrouverez l’intégralité de vos configurations préférées avec un versionning vous permettant de réparer vos erreurs que heureusement, nous faisons tous :-p
Bon courage
