Affichage des articles dont le libellé est Sécurité Cisco. Afficher tous les articles
Affichage des articles dont le libellé est Sécurité Cisco. Afficher tous les articles

5 novembre 2010

Simple acces list limiter l’acces au telnet /ssh à un pool

Tout administrateur se doit de limiter les accès à son réseau.
c’est pour cela que l’on a crée les acces list.
Donner l’accès en http ou https qu’à l’acces list 23
On crée l’acl, ici une access list simple
access-list 23 permit 10.10.10.0 0.0.0.7   ->> autorise 10.10.10.0/29
access-list 23 permit 10.2.50.0 0.0.0.255 –> autorise 10.2.50.0/24
Vous remarquerez que cisco utilise ce que l’on appèle les masques inversés.
ip http access-class 23        –> on applique comme ceci une acl à ip http qui est le serveur web
ip http authentication local –> autentification local ip
http secure-server                  –> serveur web securisé par ssl
configuration de l’interface vty 0 4
line vty 0 4
access-class 23 in                  –> on lui applique l’access list
privilege level 15                   –> privilege necessaire
login local                                  –> autentification localtransport input telnet ssh   –> activation de ssh et telnet pour le transport

Utiliser un Cisco PIX ou ASA sous GNS3

Ce petit billet va vous expliquer rapidement comment intégrer un PIX/ASA de son dernier nom à votre projet GNS3. Tout d’abord, nous partons du principe que vous possédez déjà une image de PIX/ASA avec le numéro de série qui va bien. Si cela n’est pas le cas, vous ne trouverez malheureusement pas de binaire disponible ici.
Les images de PIX sont packagées par défaut. Afin de les lire dans le logiciel PEMU (Pix Emulator) dont GNS3 est aussi une interface graphique, il est nécessaire d’effectuer un léger traitement préalable. Pour cela, je vous invite à télécharger le binaire Cisco Image Unpacker gracieusement fourni sur le site de gns3 http://downloads.sourceforge.net/gns-3/Unpack-0.1_win.zip?download. Ce binaire s’utilise en ligne de commande classique :
unpack.exe [--output file] [--format ]
Vous aurez donc compris que l’option –format est liée à la version d’IOS utilisée. Pour ma part, la ligne de commande entrée a été simplement la suivante :
unpack.exe –format ASA7 pix722.bin
Une fois le traitement achevé (cela est quasi instantanné), vous disposez alors d’un fichier .unpacked. C’est donc celui-ci qui va être utilisé comme image PIX dans GNS3. Passons donc à la configuration de ce dernier :
  • Dans GNS3, il faut se rendre dans « Editer » puis « Préférences »
  • Sélectionner le menu « Pemu »
  • Renseigner les champs « Image PIX », « Clé » et « Numéro de série » avec les informations de licensing dont vous disposez.
Après avoir accepté ces modifications, il ne vous reste plus qu’à intégrer un objet « Pare-feu PIX » dans votre topologie, de le démarrer et de lancer la console.
Une fois le PIX démarré, il est nécessaire de procéder à l’étape d’activation pour le licensing. Pour cela, rien de plus simple :
# conf t
(conf-t) # activation-key 0×4823984 0×48239 0×489922 0×48239842
(conf-t) # write mem
# reload

Dernières failles de sécurité Cisco

Les mises à jour de sécurité des équipements réseaux opérés dans une infrastructure sont cruciales, dans la mesure où des équipements présentant de nombreuses failles rendront caduques la plupart des mesures de sécurité implémentées.
Le mois de juillet a été assez défavorable à l’équipementier Cisco, pour lequel certaines failles ont été trouvées au sein des équipements. Si vous souhaitez obtenir plus d’informations sur celles-ci ou consulter régulièrement la sortie de nouveaux advisories, je vous recommande le site PacketStormSecurity.
  • Cisco Unified Contact Center Express (Cisco Unified CCX) contient une faille sur son serveur permettant l’injection de scripts dans les pages d’administration des produits Customer Response (CRS) et Cisco Unified Unified IP Interactive Voice Response (Cisco Unified IP IVR). Les conséquences potentielles de cette attaque sont le DoS ou l’élévation de privilège. Consulter les détails de cette faille
  • Multiples failles de sécurité sur les équipements Cisco Wireless LAN Controllers causant pour la plupart des DoS ou des modifications de configuration via des requêtes HTTP(S) mal formées.Consulter les détails de cette faille
  • Cisco Unity 4, 5 et 7 repose sur l’utilisation de la Microsoft Active Template Library, laquelle possède des entêtes potentiellement sujette à l’exécution de code à distance. Consulter les détails de cette faille
  • Les derniers IOS Cisco supportent le codage du numéro d’AS sur 4 octets et peuvent être victimes de deux attaques différentes de type DoS au niveau de certains paquets de type « update » pour le protocole BGP. Consulter les détails de cette faille
Evidemment, je ne vais pas retranscrire ici l’intégralité des contenus des advisories cités et c’est pour cette raison que ceux-ci sont consultables directement sur le site de PacketStormSecurity.

Cisco ASA failover – mode actif / passif

La gamme ASA de chez Cisco propose un fonctionnement intéressant dès son plus petit modèle, le 5505 qui permet de créer rapidement et efficacement une topologie active – passive fonctionnelle. Le principe est simple, le contexte qui est mis en place sur une unité qui sera déclarée comme primaire est répliqué sur l’unité déclaré comme passive, et lorsque le nominal tombe, le passif reprend intégralement le contexte du primaire.
Nous allons prendre ici une configuration relativement simple, pour vous exposer le mode de configuration. Soit un ASA de base avec deux interfaces, une inside et une outside paramétrée comme ceci :
interface Ethernet0/0
nameif outside
security-level 0
ip address 1.1.1.1 255.255.255.0 standby 1.1.1.2
no shut
!
interface Ethernet0/1
nameif inside
security-level 100
ip address 10.0.0.1 255.255.255.0 standby 10.0.0.2
no shut
!
La première chose que vous avez probablement notifié est la présence du mot clé standby, qui permet de définir l’adresse IP affectée au noeud secondaire lorsqu’il est en mode passif.
Regardons maintenant de plus près la configuration de l’unité principale :
failover
failover lan unit primary
failover lan interface failoverlink Ethernet0/7
failover key *****
failover link failover Ethernet0/7
failover interface ip failover 192.168.1.1 255.255.255.0 standby 192.168.1.2
  • La commande failover permet simplement d’activer ce mode sur notre ASA.
  • La commande failover lan unit primary indique à l’ASA qu’il doit être le primaire lorsqu’il échange avec l’autre unité.
  • La commande failover lan interface failoverlink Ethernet0/7 indique le lien qui sera utilisé pour les échanges liés au failover entre l’unité primaire et la secondaire. Il s’agit donc ici de l’interface Ethernet 0/7 nous interconnecterons directement nos deux ASA. Le mot failoverlink est simplement le nom de l’interface que nous lui attribuons.
  • La commande failover key permet de définir une clé d’authentification entre les deux unités du mode failover
  • La commande failover interface ip failover 192.168.1.1 255.255.255.0 standby 192.168.1.2 permet de définir l’adressage utiliser pour les échanges entre les deux unités concernant le failover. Il s’agit donc ici de 192.168.1.1 pour l’unité primaire et de 192.168.1.2 pour la secondaire.
Comme vous venez de le voir, il n’y a pas de difficulté majeure pour l’unité primaire.Maintenant, regardons celle de l’unité secondaire, qui est est encore plus simple  :
failover
failover lan unit secondary
failover lan interface failover Ethernet0/7
failover key *****
failover interface ip failover 192.168.1.1 255.255.255.0 standby 192.168.1.2
La seule différence est donc la commande failover lan unit secondary qui spécifie le mode de fonctionnement de notre seconde unité.
Pour vérifier et éventuellement débugguer la configuration, la commande show failover peut s’avérer utile :
ciscoasa(config)# sh failover
Failover On
Failover unit Primary
Failover LAN Interface: failoverlink Ethernet0/7 (up)
Unit Poll frequency 1 seconds, holdtime 15 seconds
Interface Poll frequency 5 seconds, holdtime 25 seconds
Interface Policy 1
Monitored Interfaces 2 of 250 maximum
Version: Ours 7.2(2), Mate 7.2(2)
Last Failover at: 11:24:53 UTC Dec 1 2009
This host: Primary – Active
Active time: 1214 (sec)
slot 0: ASA5510 hw/sw rev (1.1/7.2(2)) status (Up Sys)
Interface outside (1.1.1.1): Normal
Interface inside (10.0.0.1): Normal
slot 1: empty
Other host: Secondary – Standby Ready
Active time: 871 (sec)
slot 0: ASA5510 hw/sw rev (1.1/7.2(2)) status (Up Sys)
Interface outside (1.1.1.1): Normal
Interface inside (10.0.0.1): Normal
slot 1: empty
!
Stateful Failover Logical Update Statistics
Link : failover Ethernet0/3 (up)
Stateful Obj xmit xerr rcv rerr
General 1278 0 1256 0
sys cmd 4212 0 2352 0
up time 0 0 0 0
RPC services 0 0 0 0
TCP conn 0 0 0 0
UDP conn 0 0 0 0
ARP tbl 226 0 2 0
Xlate_Timeout 0 0 0 0
VPN IKE upd 0 0 0 0
VPN IPSEC upd 0 0 0 0
VPN CTCP upd 0 0 0 0
VPN SDI upd 0 0 0 0
VPN DHCP upd 0 0 0 0
!
Logical Update Queue Information
Cur Max Total
Recv Q: 0 2 3292
Xmit Q: 0 2 19308
Enfin, il existe quelques commandes qui peuvent s’avérer bien utiles. La commande failover active permet par exemple de forcer le passage d’un noeud passif entre actif. Pour l’opération inverse, il suffit de faire unno failover active. Vous pouvez aussi procéder au redémarrage de l’unité standby via la commande failover reload-standby. Le dernier point de configuration sur lequel il peut être intéressant de se pencher concerne la configuration du monitoring des interfaces conditionnant la bascule de failover. Il serait un peu plus long de détailler l’ensemble des commandes disponibles, c’est pour cela que je vous invite à consulter la documentation Cisco concernant les commandes de failover disponibles, consultable ici :

ASDM et problème de connexion aux équipements

Une petite astuce pour les personnes qui rencontrent parfois soudainement des problèmes pour se connecter à leurs équipements via l’ASDM et sans raison apparente. Vous le savez probablement, l’ASDM repose sur l’utilisation de la machine virtuelle Java permettant d’exécuter donc ce client lourd.
Selon le paramétrage de votre navigateur web, il se peut que la machien virtuelle récupère le paramétrage proxy de ce dernier par défaut. Il est donc nécessaire de désactiver cette option en la modifiant dans les paramètres de la machine virtuelle pour que la connexion se fasse en directe sans passer le proxy (sauf si cela est nécessaire bien entendu).

Installer ASDM sur un PIX sous GNS3

Ce billet s’adresse aux personnes ayant déjà installé un équipement virtuel (et si possible un PIX ;-) ) et réalisé l’interconnexion entre leur machine physique et cet équipement virtuel. Si l’un de ces deux pré-requis vous manque, n’hésitez pas à consulter les deux billets suivants :
Ensuite, il vous faudra un serveur TFTP qui permettra le transfert de l’image ASDM que vous souhaitez utiliser. Si vous n’en connaissez pas en particulier, 3CDAEMON ou PUMPKIN feront amplement l’affaire. Attention toutefois à bien les binder sur les interfaces réseaux que vous souhaitez.
adsm_gns3_thumb
Le nuage est configuré pour être connecté à une interface loopback déclaré sur la machine hôte. Celle-ci est configurée en 10.0.0.10 / 24. Nous allons à présent réaliser la configuration du PIX pour pouvoir y accéder depuis notre machine :
# conf t
(config) # interface e0
(config-if) # ip address 10.0.0.1 255.255.255.0
(config-if) # nameif inside
(config-if) # no shutdown
(config-if) # write mem
Voilà, notre interface est configurée pour qu’on puisse la pinger depuis la machine hôte. A ce stade de la configuration, j’ai rencontré des problèmes qui m’empêchaient d’effectuer le transfert TFTP de l’image depuis la console telnet par défaut utilisée via GNS3 (un étrange bug). En conséquence, j’ai activé le telnet et réalisé la commande depuis la machine hôte directement et cela a fonctionné. Si vous êtes dans le même cas, voici la procédure pour activer le telnet :
# conf t
(config) # telnet 0.0.0.0 0.0.0.0 inside
(config-if) # passwd cisco
(config-if) # write mem
 Les lignes de commande ci-dessus ne sont pas spécialement optimales dans la mesure où elles autorisent n’importe quelle machine à accéder en telnet au PIX dans la mesure où elle a accès à une interface inside et connait le mot de passe. L’objectif étant de faire un lab de démo, je vous laisse donc le soin de peaufiner ces restrictions en fonction de vos besoins. Vous pouvez normalement prendre la main en telnet sur votre pix via le shell DOS de votre machine hôte.
Nous sommes désormais prêts pour réaliser prêts pour réaliser la copie en tftp :
# conf t
(config) # copy tftp: flash:
IP_DU_SERVEUR_TFTP
NOM_FICHIER_ASDM_SOURCE
NOM_FICHIER_ASDM_DEST
Le temps de la copie de fichier terminé (prévoir quelques minutes), il reste ensuite à autoriser les flux http sur la patte inside de notre PIX :
# conf t
(config) # asdm image flash:asdm-522.bin
(config) # http server enable
(config) # http 0.0.0.0 0.0.0.0 inside
(config) # write mem
A l’image des restrictions pour le telnet, l’objet n’est pas ici de faire de notre PIX une forteresse :-) . 
Nous allons ensuite ajouter un utilisateur pour se connecter via ASDM :
# conf t
(config) # username remy password cisco privilege 15
Nous sommes arrivés à la fin de la configuration du PIX, et, si tout s’est correctement déroulé, vous devriez pouvoir accéder à l’interface ASDM via votre navigateur web préféré en vous connectant en https sur l’adresse de l’interface inside de votre PIX  ;-)

4 novembre 2010

Laboratoire CISCO Collaboratif


Voici une exclusivité mondiale,
Jeremy Stretch de www.packetlife.net à monté un laboratoire Cisco accessible gratuitement,
mais sur réservation par tous les membres de son site www.packetlife.net sur des créneaux qui peuvent atteindre 8 heures.
Le laboratoire est composé des équipements suivants:
  • 2x Cisco ASA 5505
  • 2x Cisco 2811 (2xWIC-2T)
  • 4x Cisco 1841 (1xWIC-2T)
  • 1x Juniper J2300
  • 1x TBD
  • 4x Catalyst 3550-24
Les équipements sont accessibles directement à distance par leurs ports console (pour un contrôle total) via un gestionnaire de consoleOpengear CM4116.
J’ai dors et déjà réservé un créneau pour demain soir, j’essayerai de faire un petit feedback de ce premier essai dans les commentaires.
Merci Jeremy!
Topologie Ethernet
Topologie Série


ASA 8.3 released!


I’m going here to show some of the new features that comes with!
Some are good… and others not ^^
Let’s start with the bad news
Memory Upgrade
To upgrade your ASA with 8.3 release, you will need to upgrade your hardware.
Memory requirement is more than the double default memory. 512 Mb for a 5505, 1GB for 5510 …
You will still be able to install the new release, but you’ll get some error message in CLI and in ASDM. The full features set will be not supported until you’ll get some memory.
Licencing Features
With the ASA ( and IOS 15.0 ) comes the new licensing feature. Time-based licences are required
now to unblock features.
The good news is that time-based licenses are stackable.
let’s say you purchased a licence for 1 one year, you won’t have to wait the last day to renew your licence. The count will be just incremented using your new licence.
You can also use multiples licenses at the same time and if you do not require a feature anymore, you can deactivate it and reactivate later.
Master Passphrase
The Master Passphrase is not new for IOS. This feature is the same as the IOS command service password-encryption. But instead of type 7, you will
get with ASA an encryption using AES.
Monitoring
High Performance Monitoring for ASDM is the ability to check the inside hosts connections ( who and how much )
to set it up :
ciscoasa(config)#hpm topn enable
Firewall features
New interface is coming! the global one! You can configure access-list and others things in a global way, not only in an interface-specific way
NAT can be configured directly in the network object
And to finish, the NAT configuration is… quite simple as how we did earlier!
Others new features here:
http://www.cisco.com/en/US/docs/security/asa/asa83/release/notes/asarn83.html