Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Identity Services Engine (ISE) version 1.3 prend en charge une nouvelle API appelée pxGrid. Ce protocole moderne et flexible qui prend en charge l'authentification, le chiffrement et les privilèges (groupes) permet une intégration facile avec d'autres solutions de sécurité. Ce document décrit l'utilisation de l'application pxLog qui a été écrite comme une preuve de concept. pxLog est capable de recevoir des messages syslog du système de prévention des intrusions (IPS) et d'envoyer des messages pxGrid à l'ISE afin de mettre en quarantaine le pirate. Par conséquent, ISE utilise RADIUS Change of Authorization (CoA) afin de modifier l'état d'autorisation du terminal qui limite l'accès au réseau. Tout cela se passe de manière transparente pour l'utilisateur final.
Dans cet exemple, Snort a été utilisé comme IPS, mais n'importe quelle autre solution peut être utilisée. En fait, il ne doit pas nécessairement s'agir d'un IPS. Il suffit d'envoyer le message syslog à pxLog avec l'adresse IP de l'attaquant. Cela permet d'intégrer un grand nombre de solutions.
Ce document présente également comment dépanner et tester les solutions pxGrid, avec les problèmes et limitations typiques.
Avertissement : l'application pxLog n'est pas prise en charge par Cisco. Cet article a été écrit comme une preuve de concept. L'objectif principal était de l'utiliser lors du meilleur test de la mise en oeuvre de pxGrid sur ISE.
Cisco vous recommande de faire l’essai de la configuration du système informatique unifié Cisco (ISE) et de connaître la base sur les sujets suivants :
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
Voici le flux de trafic, comme illustré dans le schéma du réseau :
La solution consiste à installer un ensemble d'applications sur une machine Linux :
L'application pxLog utilise les bibliothèques suivantes :
Toutes ces bibliothèques sont déjà dans le répertoire lib du projet, il n'est donc pas nécessaire de télécharger d'autres fichiers Java ARchive (JAR).
Afin d'installer l'application :
Cet article ne se concentre pas sur un IPS spécifique, c'est pourquoi seule une brève explication est fournie.
Snort est configuré en ligne avec la prise en charge DAQ. Le trafic est redirigé avec iptables :
iptables -I FORWARD -j ACCEPT
iptables -I FORWARD -j NFQUEUE --queue-num 1
Ensuite, après inspection, il est injecté et transféré selon les règles iptable par défaut.
Quelques règles Snort personnalisées ont été configurées (le fichier /etc/snort/rules/test.rules est inclus dans la configuration globale).
alert icmp any any -> any any (itype:8; dsize:666<>686; sid:100122)
alert icmp any any -> any any (itype:8; ttl: 6; sid:100124)
Snort envoie un message syslog lorsque la durée de vie (TTL) du paquet est égale à 6 ou que la taille de la charge utile est comprise entre 666 et 686. Le trafic n'est pas bloqué par Snort.
Des seuils doivent également être configurés pour s'assurer que les alertes ne sont pas déclenchées trop souvent (/etc/snort/threshold.conf) :
event_filter gen_id 1, sig_id 100122, type limit, track by_src, count 1, seconds 60
event_filter gen_id 1, sig_id 100124, type limit, track by_src, count 1, seconds 60
Ensuite, le serveur syslog pointe vers la machine pxLog (/etc/snort/snort.conf) :
output alert_syslog: host=10.222.0.61:514, LOG_AUTH LOG_ALER
Pour certaines versions de Snort, il y a des bogues liés à la configuration syslog, puis les paramètres par défaut pourraient être utilisés qui pointent vers l'hôte local et syslog-ng pourrait être configuré afin de transférer des messages spécifiques à l'hôte pxLog.
EPS doit être activé (désactivé par défaut) dans Administration > Settings :
Cela vous permet d'utiliser la fonctionnalité de mise en quarantaine/non-quarantaine.
La première règle n'est rencontrée que lorsque le point d'extrémité est mis en quarantaine. L'accès limité est ensuite dynamiquement appliqué par la société RADIUS CoA. Le commutateur doit également être ajouté aux périphériques réseau avec le secret partagé correct.
L'état de pxGrid peut être vérifié à l'aide de la CLI :
lise/admin# show application status ise
ISE PROCESS NAME STATE PROCESS ID
--------------------------------------------------------------------
Database Listener running 6717
Database Server running 51 PROCESSES
Application Server running 9486
Profiler Database running 7804
AD Connector running 10058
M&T Session Database running 7718
M&T Log Collector running 9752
M&T Log Processor running 9712
Certificate Authority Service running 9663
pxGrid Infrastructure Service running 14979
pxGrid Publisher Subscriber Service running 15281
pxGrid Connection Manager running 15248
pxGrid Controller running 15089
Identity Mapping Service running 9962
Il existe également des débogages distincts pour pxGrid (Administration > Logging > Debug Log Configuration > pxGrid). Les fichiers de débogage sont stockés dans le répertoire pxGrid. Les données les plus importantes se trouvent dans les répertoires pxgrid/pxgrid-jabberd.log et pxgrid/pxgrid-controller.log.
L'application pxLog est automatiquement déployée au démarrage de Tomcat.
pxLog doit traiter les messages syslog et exécuter les actions qui en découlent. Afin d'ajouter une nouvelle règle, sélectionnez Manage Rules :
Maintenant, le module d'application recherche cette expression régulière (RegExp) dans le message syslog : "snort[". S'il est trouvé, il recherche toutes les adresses IP et sélectionne celle qui précède la dernière. Cela correspond à la plupart des solutions de sécurité. Référez-vous à la section Syslog pour plus d'informations. Cette adresse IP (attaquant) est mise en quarantaine via pxGrid. Une règle plus granulaire peut également être utilisée (par exemple, elle peut inclure le numéro de signature).
La station Microsoft Windows 7 lance une session point1x filaire. Cisco Anyconnect NAM a été utilisé comme demandeur. La méthode EAP-PEAP (Extensible Authentication Protocol-Protected EAP) est configurée.
Le profil d'autorisation d'accès complet ISE Dot1x est sélectionné. Le commutateur télécharge la liste d'accès afin d'accorder un accès complet :
3750#show authentication sessions interface g0/17
Interface: GigabitEthernet0/17
MAC Address: 0050.b611.ed31
IP Address: 10.221.0.240
User-Name: cisco
Status: Authz Success
Domain: DATA
Security Policy: Should Secure
Security Status: Unsecure
Oper host mode: single-host
Oper control dir: both
Authorized By: Authentication Server
Vlan Policy: N/A
ACS ACL: xACSACLx-IP-PERMIT_ALL-53fc9dbe
Session timeout: N/A
Idle timeout: N/A
Common Session ID: 0A01000C000037E6BAB267CF
Acct Session ID: 0x00003A70
Handle: 0xA100080E
Runnable methods list:
Method State
dot1x Authc Success
3750#show ip access-lists interface g0/17
permit ip any any
Ceci montre ce qui se passe si vous envoyez un paquet Microsoft Windows avec TTL = 7 :
c:\> ping 10.222.0.61 -i 7 -n 1
Cette valeur est diminuée sur Snort dans la chaîne de transfert et une alarme est déclenchée. Par conséquent, un message syslog vers pxLog est envoyé :
Sep 6 22:10:31 snort snort[6310]: [1:100124:0] ALERT {ICMP} 10.221.0.240 ->
10.222.0.61
Le pxLog reçoit le message syslog, le traite et demande la mise en quarantaine de cette adresse IP. Cela peut être confirmé si vous vérifiez les journaux :
L'ISE signale que l'adresse IP a été mise en quarantaine :
Par conséquent, il examine la stratégie d'autorisation, choisit la quarantaine et envoie RADIUS CoA afin de mettre à jour l'état d'autorisation sur le commutateur pour ce point d'extrémité spécifique.
Il s'agit du message de fin de la CoA qui force le demandeur à lancer une nouvelle session et à obtenir un accès limité (Permit_ICMP) :
Le résultat peut être confirmé sur le commutateur (accès limité pour le terminal) :
3750#show authentication sessions interface g0/17
Interface: GigabitEthernet0/17
MAC Address: 0050.b611.ed31
IP Address: 10.221.0.240
User-Name: cisco
Status: Authz Success
Domain: DATA
Security Policy: Should Secure
Security Status: Unsecure
Oper host mode: single-host
Oper control dir: both
Authorized By: Authentication Server
Vlan Policy: N/A
ACS ACL: xACSACLx-IP-PERMIT_ICMP-53fc9dc5
Session timeout: N/A
Idle timeout: N/A
Common Session ID: 0A01000C000037E7BAB7D68C
Acct Session ID: 0x00003A71
Handle: 0xE000080F
Runnable methods list:
Method State
dot1x Authc Success
3750#show ip access-lists interface g0/17
permit icmp any any
À ce stade, l'administrateur décide de mettre ce point final hors quarantaine :
La même opération peut être exécutée directement à partir de l'ISE :
L'ISE examine à nouveau les règles et met à jour l'état d'autorisation sur le commutateur (un accès réseau complet est accordé) :
Le rapport confirme :
L'application pxLog a été écrite afin de démontrer la fonctionnalité de l'API pxGrid. Il vous permet de :
D'autres fonctionnalités sont prévues à l'avenir.
Voici quelques exemples de captures d'écran de pxLog :
Le client (utilisateur) peut être membre d'un groupe à la fois. Les deux groupes les plus couramment utilisés sont les suivants :
Comme mentionné précédemment, les deux applications clientes, pxLog et le contrôleur pxGrid (ISE), doivent avoir des certificats configurés pour pouvoir communiquer. L'application pxLog conserve ces éléments dans les fichiers Java KeyStore :
Les fichiers sont protégés par mot de passe (par défaut : cisco123). L'emplacement du fichier et les mots de passe peuvent être modifiés dans WEB-INF/web.xml.
Voici les étapes à suivre pour générer un nouveau KeyStore Java :
pxgrid store # keytool -import -alias ca -keystore root.jks -file cert-ca.der
pxgrid store # keytool -import -alias mnt -keystore root.jks -file cert-mnt.der
pxgrid store # keytool -import -alias ca -keystore client.jks -file cert-ca.der
pxgrid store # keytool -genkey -alias clientcert -keyalg RSA -keystore client.jks -
keysize 2048
pxgrid store # keytool -certreq -alias clientcert -keystore client.jks -
file cert-client.csr
pxgrid store # keytool -import -alias clientcert -keystore client.jks -file cert-
client.der
pxgrid store # keytool -list -v -keystore client.jks
pxgrid store # keytool -list -v -keystore root.jks
Attention : lorsque le noeud ISE 1.3 est mis à niveau, il existe une option permettant de conserver le certificat d'identité, mais la signature de l'autorité de certification est supprimée. Par conséquent, l'ISE mis à niveau utilise un nouveau certificat mais n'attache jamais le certificat CA dans le message SSL/ServerHello. Cela déclenche l'échec sur le client qui s'attend (selon RFC) à voir une chaîne complète.
L'API pxGrid pour plusieurs fonctions (comme le téléchargement de session) effectue une validation supplémentaire. Le client contacte l’ISE et reçoit le nom d’hôte ISE, qui est défini par la commande hostname dans l’interface de ligne de commande. Ensuite, le client tente d'effectuer une résolution DNS pour ce nom d'hôte et tente de contacter et d'extraire des données de cette adresse IP. Si la résolution DNS du nom d'hôte ISE échoue, le client n'essaie pas d'obtenir des données.
Attention : notez que seul le nom d'hôte est utilisé pour cette résolution, qui est lise dans ce scénario, et non le nom de domaine complet (FQDN), qui est lise.example.com dans ce scénario.
Cisco publie et prend en charge l'API pxGrid. Il y a un paquet nommé comme ceci :
pxgrid-sdk-1.0.0-167
A l'intérieur :
Voici la liste des solutions de sécurité qui envoient des messages syslog avec l'adresse IP de l'attaquant. Ils peuvent être facilement intégrés à pxLog tant que vous utilisez la règle RegExp correcte dans la configuration.
Snort envoie des alertes Syslog au format suivant :
host[id] [sig_gen, sig_id, sig_sub] [action] [msg] [proto] [src] [dst]
Voici un exemple :
snort[6310]: [1:100124:0] ALERT {ICMP} 10.221.0.240 -> 10.222.0.61
L'adresse IP de l'attaquant est toujours la deuxième avant la dernière (destination). Il est facile de créer une RegExp granulaire pour une signature spécifique et d'extraire l'adresse IP de l'attaquant. Voici un exemple RegExp pour la signature 100124 et le message ICMP (Internet Control Message Protocol) :
snort[\.*:100124:.*ICMP.*
Lorsque l'ASA est configuré pour l'inspection HTTP (exemple), le message syslog correspondant ressemble à ceci :
Mar 12 2014 14:36:20: %ASA-5-415006: HTTP - matched Class 23:
MS13-025_class in policy-map MS_Mar_2013_policy, URI matched -
Dropping connection from inside:192.168.60.88/2135 to
outside:192.0.2.63/80
Encore une fois, un RegExp granulaire pourrait être utilisé pour filtrer ces messages et extraire l'adresse IP de l'attaquant, la deuxième avant la dernière.
Voici un exemple de message envoyé par le capteur Sourcefire :
Jan 28 19:46:19 IDS01 SFIMS: [CA IDS][Policy1][119:15:1] http_inspect: OVERSIZE
REQUEST-URI DIRECTORY [Classification: Potentially Bad Traffic] [Priority: 2]
{TCP} 10.12.253.47:55504 -> 10.15.224.60:80
Encore une fois, il est simple d'extraire l'adresse IP de l'attaquant, car la même logique s'applique. Le nom de la stratégie et la signature sont également fournis, de sorte que la règle pxLog peut être granulaire.
Voici un exemple de message envoyé par l'ancien système de détection et de prévention des intrusions Juniper (IDP) :
dayId="20061012" recordId="0" timeRecv="2006/10/12
21:52:21" timeGen="2006/10/12 21:52:21" domain="" devDomVer2="0"
device_ip="10.209.83.4" cat="Predefined" attack="TROJAN:SUBSEVEN:SCAN"
srcZn="NULL" srcIntf="NULL" srcAddr="192.168.170.20" srcPort="63396"
natSrcAddr="NULL" natSrcPort="0" dstZn="NULL" dstIntf="NULL"
dstAddr="192.168.170.10" dstPort="27374" natDstAddr="NULL" natDstPort="0"
protocol="TCP" ruleDomain="" ruleVer="5" policy="Policy2" rulebase="IDS"
ruleNo="4" action="NONE" severity="LOW" alert="no" elaspedTime="0" inbytes="0"
outbytes="0" totBytes="0" inPak="0" outPak="0" totPak="0" repCount="0"
packetData="no" varEnum="31" misc="<017>'interface=eth2" user="NULL"
app="NULL" uri="NULL"
L'adresse IP de l'attaquant peut être extraite de la même manière.
JunOS est similaire :
Jul 16 10:09:39 JuniperJunOS: asp[8265]:
ASP_IDS_TCP_SYN_ATTACK: asp 3: proto 6 (TCP),
ge-0/0/1.0 10.60.0.123:2280 -> 192.168.1.12:80, TCP
SYN flood attack
Voici quelques exemples d'iptables Linux.
Jun 15 23:37:33 netfilter kernel: Inbound IN=lo OUT=
MAC=00:13:d3:38:b6:e4:00:01:5c:22:9b:c2:08:00 src=10.0.0.1 DST=10.0.0.100 LEN=60
TOS=0x10 PREC=0x00 TTL=64 ID=47312 DF PROTO=TCP SPT=40945 DPT=3003 WINDOW=32767
RES=0x00 SYN URGP=0
Vous pouvez envoyer des informations syslog pour tout type de paquet avec les fonctionnalités avancées fournies par les modules iptable comme le suivi de connexion, xtables, rpfilters, la correspondance de modèle, etc.
Voici un exemple de message pour les fragments de blocage IPFW :
Sep 7 15:03:14 delta ipfw: 11400 Deny UDP 10.61.216.50 10.81.199.2 in via fxp0
(frag 52639:519@1480)
L'ISE est capable de reconnaître le type de sessions en termes de gestion de la CoA.
Le module EPS est simple. Lorsqu'il exécute une quarantaine, il envoie toujours un paquet de fin CoA. Pour les sessions filaires/sans fil, ce n'est pas un problème (tous les demandeurs 802.1x peuvent lancer une deuxième session EAP de manière transparente). Mais lorsque l'ASA reçoit la fin CoA, il abandonne la session VPN et l'utilisateur final se voit présenter ceci :
Il existe deux solutions possibles pour forcer la reconnexion automatique du VPN AnyConnect (configuré dans le profil XML) :
Même lorsque la nouvelle session est établie, l'ASA choisit le nouvel ID de session d'audit. Du point de vue d'ISE, il s'agit d'une nouvelle session et il n'y a aucune chance de rencontrer la règle de quarantaine. De même, pour les VPN, il n'est pas possible d'utiliser l'adresse MAC du point d'extrémité comme identité, contrairement au point 1x filaire/sans fil.
La solution consiste à forcer l'EPS à se comporter comme l'ISE et à envoyer le type de CoA correct en fonction de la session. Cette fonctionnalité sera introduite dans la version ISE 1.3.1.
Voici une liste de partenaires et de solutions pxGrid :
Voici d'autres partenaires et solutions :
Reportez-vous au catalogue de solutions Marketplace pour la liste complète des solutions de sécurité.
Il existe trois types d'API disponibles sur la version 1.3 d'ISE.
Voici une comparaison :
REPOS | RESTful externe | pxGrid | |
---|---|---|---|
Authentification client | username + password (authentification HTTP de base) |
username + password (authentification HTTP de base) |
certificat |
Séparation des privilèges | non |
limité (administrateur ERS) |
oui (groupes) |
Accès | MTn | MTn | MTn |
Transport | tcp/443 (HTTPS) | tcp/9060 (HTTPS) | tcp/5222 (XMPP) |
Méthode HTTP | GET | GET/POST/PUT | OBTENIR/PUBLIER |
Activé par défaut | oui | non | non |
Nombre d'opérations | peu nombreux | nombreux | peu nombreux |
Fin CoA | pris en charge | non | pris en charge |
Réauthentification CoA | pris en charge | non | pris en charge* |
Opérations utilisateur | non | oui | non |
Opérations sur les terminaux | non | oui | non |
Opérations de groupe Identité du terminal | non | oui | non |
Quarantaine (IP, MAC) | non | non | oui |
Désactivation de la quarantaine (IP, MAC) | non | non | oui |
PortBounce/Arrêt | non | non | oui |
Opérations utilisateur invité | non | oui | non |
Opérations du portail invité | non | oui | non |
Fonctionnement des périphériques réseau | non | oui | non |
Opérations de groupe de périphériques réseau | non | oui | non |
* La quarantaine utilise la prise en charge de la CoA unifiée de la version 1.3.1 d'ISE.
pxLog peut être téléchargé depuis Sourceforge .
Le kit de développement logiciel (SDK) est déjà inclus. Pour obtenir la documentation la plus récente sur le SDK et l'API pour pxGrid, contactez votre partenaire ou l'équipe Cisco chargée du compte.
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
23-Dec-2014 |
Première publication |