Outils pour utilisateurs

Outils du site


Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision
Révision précédente
215snmp:50_plus [le 10/07/2010 à 14:29] prof215snmp:50_plus [le 21/04/2019 à 14:07] (Version actuelle) – [Particularité Debian] prof
Ligne 7: Ligne 7:
 La version 3 apporte des fonctions de sécurité (chiffrement et authentification) qui permettent d'utiliser SNMP dans un environnement « hostile », mais n'est pas implémenté sur tous les matériels. Cette version n'apportant rien de plus pour la compréhension du fonctionnement de SNMP, nous n'en parlerons pas d'avantage. La version 3 apporte des fonctions de sécurité (chiffrement et authentification) qui permettent d'utiliser SNMP dans un environnement « hostile », mais n'est pas implémenté sur tous les matériels. Cette version n'apportant rien de plus pour la compréhension du fonctionnement de SNMP, nous n'en parlerons pas d'avantage.
  
-La version 1 est généralement implémentée sur tous les équipements proposant SNMP, de même que la version 2c, qui ne fait qu'ajouter des compteurs sur 64 bits. Ces deux versions offrent une sécurité tout à fait indigente. Il n'y a ni chiffrement des données, ni authentification (aussi bien de l'agent que du manager). Dans un environnement « hostile » il restera possible de pallier cet inconvénient par l'usage de tunnels chiffrés, de vlans etc. Voyons tout de même ce que proposent les versions 1 et 2 en termes de restrictions d'accès.+La version 1 est généralement implémentée sur tous les équipements proposant SNMP, de même que la version 2c, qui ne fait qu'ajouter des compteurs sur 64 bits et une commande supplémentaire : ''GetBulk-Request''. Cette nouvelle commande donne le même résultat que la commande ''Get-next-request'', mais de façon plus efficace. Nous verrons cela plus loin dans les analyses de trames. 
 + 
 +Ces deux versions offrent une sécurité tout à fait indigente. Il n'y a ni chiffrement des données, ni authentification (aussi bien de l'agent que du manager). Dans un environnement « hostile » il restera possible de pallier cet inconvénient par l'usage de tunnels chiffrés, de vlans etc. Voyons tout de même ce que proposent les versions 1 et 2 en termes de restrictions d'accès. 
 ==== Les communautés et leurs privilèges ==== ==== Les communautés et leurs privilèges ====
  
Ligne 18: Ligne 21:
 La communauté ''public'' n'a généralement accès qu'en lecture, et pas forcément à toute l'étendue des informations exposées. La communauté ''public'' n'a généralement accès qu'en lecture, et pas forcément à toute l'étendue des informations exposées.
  
-La communauté ''private'' est généralement exploitée pour écrire (donc reconfigurer) un équipement. Il est donc nécessaire d'en réserver l'accès qu'aux administrateurs autorisés, mais ceci ne peut se faire que sur la base des adresses IP des managers, ce qui reste très rudimentaire.+La communauté ''private'' est généralement exploitée pour écrire (donc reconfigurer) un équipement et disposer de la totalité des informations que l'agent sait exposer. Il est donc nécessaire d'en réserver l'accès aux seuls administrateurs autorisés, mais ceci ne peut se faire que sur la base des adresses IP des managers, ce qui reste très rudimentaire.
  
 Il est clair que dans un environnement hostile, il reste assez simple d'utiliser SNMP (v 1 et 2) à des fins tout à fait malveillantes. Il est clair que dans un environnement hostile, il reste assez simple d'utiliser SNMP (v 1 et 2) à des fins tout à fait malveillantes.
Ligne 29: Ligne 32:
 com2sec readonly  default         public com2sec readonly  default         public
 com2sec readwrite default         private com2sec readwrite default         private
 +
 group MyROGroup v1         readonly group MyROGroup v1         readonly
 group MyROGroup v2c        readonly group MyROGroup v2c        readonly
 group MyRWGroup v1         readwrite group MyRWGroup v1         readwrite
 group MyRWGroup v2c        readwrite group MyRWGroup v2c        readwrite
 +
 view all    included  .1 view all    included  .1
 +
 access MyROGroup ""      any       noauth    exact  all    none   none access MyROGroup ""      any       noauth    exact  all    none   none
 access MyRWGroup ""      any       noauth    exact  all    all    none access MyRWGroup ""      any       noauth    exact  all    all    none
 </code> </code>
  
-La logique séquentielle de ce fichier n'est pas forcément la meilleure. Commençons donc par les ''view''+La logique séquentielle de ce fichier n'est pas forcément la meilleure pour en comprendre le principe. Commençons donc par les ''view''
  
 == Les « view » == == Les « view » ==
Ligne 86: Ligne 92:
 Veut dire qu'il existe deux groupes, ''MyROGroup'' et ''MyRWGroup'' : Veut dire qu'il existe deux groupes, ''MyROGroup'' et ''MyRWGroup'' :
   * ''MyROGroup'' peut lire dans la vue ''all'' mais ne peut y écrire et ce, en utilisant aussi bien les protocoles v1 que v2c ;   * ''MyROGroup'' peut lire dans la vue ''all'' mais ne peut y écrire et ce, en utilisant aussi bien les protocoles v1 que v2c ;
-  * ''MyRWGroup'' peut aussi bien lire qu'écrire dans la vue ''all'' aussi vien en v1 qu'en v2c.+  * ''MyRWGroup'' peut aussi bien lire qu'écrire dans la vue ''all'' aussi bien en v1 qu'en v2c.
 == Le « com2sec » == == Le « com2sec » ==
 C'est ici que l'on recolle tous les morceaux, en ajoutant en prime les communautés. De la forme : C'est ici que l'on recolle tous les morceaux, en ajoutant en prime les communautés. De la forme :
   com2sec  [-Cn CONTEXT] SECNAME SOURCE COMMUNITY   com2sec  [-Cn CONTEXT] SECNAME SOURCE COMMUNITY
 +
   * ''CONTEXT'' n'a toujours pas de sens en v1 ni en v2c) ;   * ''CONTEXT'' n'a toujours pas de sens en v1 ni en v2c) ;
   * ''SECNAME'', ça vient d'un peu plus haut dans l'explication ;   * ''SECNAME'', ça vient d'un peu plus haut dans l'explication ;
Ligne 102: Ligne 109:
  
 L'ennui, c'est que si le manager se déclare de la communauté ''private'', qui est attachée au groupe de sécurité ''readwrite'' (qui aurait pu s'appeler ?...) depuis n'importe où (''default'') et que ce groupe de sécurité est attribué au groupe ''MyRWGroup'' (qui aurait pu s'appeler ?...), lequel peut lire dans ''all'' mais aussi y écrire, alors ce manager pourra modifier tout ce qui est modifiable sur notre hôte, preuve que notre configuration est complètement nulle. En fait, elle est là pour l'exemple, nous en ferons une moins sale par la suite. L'ennui, c'est que si le manager se déclare de la communauté ''private'', qui est attachée au groupe de sécurité ''readwrite'' (qui aurait pu s'appeler ?...) depuis n'importe où (''default'') et que ce groupe de sécurité est attribué au groupe ''MyRWGroup'' (qui aurait pu s'appeler ?...), lequel peut lire dans ''all'' mais aussi y écrire, alors ce manager pourra modifier tout ce qui est modifiable sur notre hôte, preuve que notre configuration est complètement nulle. En fait, elle est là pour l'exemple, nous en ferons une moins sale par la suite.
 +== Particularité Debian ==
 +(Et dérivées)
  
-===== C'est compris ? ===== +Le fichier ''/etc/default/snmpd'' contient des options ajoutées lors du lancement du service ''snmpd''. Ces optionspar défautlimitent le service à écouter sur 127.0.0.1 :
-Bien sûr ! Et ceci va nous permettre de créer une configuration un peu plus complète de la façon suivante : +
-  * une communauté ''public'', qui aura droit à l'accès en lecture seule, mais seulement à la branche ''system'' pour tous ceux qui peuvent joindre notre agentquelle que soit leur adresse IP ; +
-  * une communauté ''private'' aura droit à la lecture seule de toutes les informations possiblesmais seulement à partir d'un réseau IP particulier ; +
-  * une communauté ''admin'' pourra lire et écrire partout où c'est possible, mais depuis une adresse IP bien particulière. +
- +
- +
-agent snmp en 192.168.0.112 +
- +
-poste client en 172.16.254.20+
 <html><pre class="code"> <html><pre class="code">
-venus:~snmpwalk -c public -v 2c 192.168.0.112 .1 +This file controls the activity of snmpd and snmptrapd
-SNMPv2-MIB::sysDescr.0 = STRING: Linux lucid-snmp 2.6.32-23-generic #37-Ubuntu SMP Fri Jun 11 07:54:58 UTC 2010 i686 +
-SNMPv2-MIB::sysDescr.0 = No more variables left in this MIB View (It is past the end of the MIB tree) +
-venus:~# snmpwalk -c private -v 2c 192.168.0.112 .1 +
-Timeout: No Response from 192.168.0.112 +
-</pre></html>+
  
 +# MIB directories.  /usr/share/snmp/mibs is the default, but
 +# including it here avoids some strange problems.
 +export MIBDIRS=/usr/share/snmp/mibs
  
-poste client en 192.168.0.95+# snmpd control (yes means start daemon). 
 +SNMPDRUN=yes
  
-snmpwalk -c public -v 2c 192.168.0.112 .1 +snmpd options (use syslog, close stdin/out/err)
-SNMPv2-MIB::sysDescr.0 STRING: Linux lucid-snmp 2.6.32-23-generic #37-Ubuntu SMP Fri Jun 11 07:54:58 UTC 2010 i686 +SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -g snmp --smux -p /var/run/snmpd.pid <span class="hly">127.0.0.1</span>'
-SNMPv2-MIB::sysDescr.0 = No more variables left in this MIB View (It is past the end of the MIB tree)+
  
-snmpwalk -c private -v 2c 192.168.0.112 .1 +snmptrapd control (yes means start daemon).  As of net-snmp version 
-SNMPv2-MIB::sysDescr.0 = STRING: Linux lucid-snmp 2.6.32-23-generic #37-Ubuntu SMP Fri Jun 11 07:54:58 UTC 2010 i686 +# 5.0, master agentx support must be enabled in snmpd before snmptrapd 
-SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10 +# can be run See snmpd.conf(5) for how to do this
-DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (2155460:35:55.46 +TRAPDRUN=no
-SNMPv2-MIB::sysContact.0 = STRING: Root <root@lucid-virt.nain-t.net+
-SNMPv2-MIB::sysName.0 = STRING: lucid-snmp +
-SNMPv2-MIB::sysLocation.0 = STRING: Monde virtuel +
-SNMPv2-MIB::sysORLastChange.0 = Timeticks: (00:00:00.00 +
-SNMPv2-MIB::sysORID.1 = OID: SNMP-FRAMEWORK-MIB::snmpFrameworkMIBCompliance +
-SNMPv2-MIB::sysORID.2 = OID: SNMP-MPD-MIB::snmpMPDCompliance +
-SNMPv2-MIB::sysORID.3 = OID: SNMP-USER-BASED-SM-MIB::usmMIBCompliance +
-SNMPv2-MIB::sysORID.4 = OID: SNMPv2-MIB::snmpMIB +
-SNMPv2-MIB::sysORID.5 = OID: TCP-MIB::tcpMIB +
-SNMPv2-MIB::sysORID.6 = OID: IP-MIB::ip +
-SNMPv2-MIB::sysORID.7 = OID: UDP-MIB::udpMIB +
-SNMPv2-MIB::sysORID.8 = OID: SNMP-VIEW-BASED-ACM-MIB::vacmBasicGroup +
-SNMPv2-MIB::sysORDescr.1 = STRING: The SNMP Management Architecture MIB. +
-SNMPv2-MIB::sysORDescr.2 = STRING: The MIB for Message Processing and Dispatching+
-SNMPv2-MIB::sysORDescr.3 STRING: The management information definitions for the SNMP User-based Security Model. +
-SNMPv2-MIB::sysORDescr.4 = STRING: The MIB module for SNMPv2 entities +
-SNMPv2-MIB::sysORDescr.5 = STRING: The MIB module for managing TCP implementations +
-SNMPv2-MIB::sysORDescr.6 = STRING: The MIB module for managing IP and ICMP implementations +
-...+
  
-snmpwalk -c admin -v 2c 192.168.0.112 .1  +snmptrapd options (use syslog). 
-Timeout: No Response from 192.168.0.112+TRAPDOPTS='-Lsd -p /var/run/snmptrapd.pid'
  
 +# create symlink on Debian legacy location to official RFC path
 +SNMPDCOMPAT=yes
 +</pre></html>
 +Un simple ''man snmpd'' nous indiquera clairement (une fois n'est pas coutume) qu'il suffit d'enlever l'adresse locale dans la ligne d'options pour que ''snmpd'' écoute sur toutes les interfaces. Notez que si nous avons deux interfaces, dont par exemple une attachée à un vlan (un vlan pourquoi pas réservé à l'administration des équipements), nous pouvons forcer ''snmpd'' à n'écouter que sur cette interface, ce qui permettrait de sécuriser quelque peu le dispositif.
  
 +Après modification de cette ligne et redémarrage du service, nous pouvons constater que :
 +<html><pre class="code">
 +# netstat -lupn
 +Connexions Internet actives (seulement serveurs)
 +Proto Recv-Q Send-Q Adresse locale          Adresse distante        Etat       PID/Program name
 +udp        0      0 0.0.0.0:68              0.0.0.0:                          639/dhclient    
 +udp        0      0 0.0.0.0:47712           0.0.0.0:                          618/avahi-daemon: r
 +udp        0      0 0.0.0.0:5353            0.0.0.0:                          618/avahi-daemon: r
 +<span class="hly">udp        0      0 0.0.0.0:161             0.0.0.0:                          1507/snmpd</span>
 +</pre></html>
  
 +===== C'est compris ? =====
 +Bien sûr ! Et ceci va nous permettre de créer une configuration un peu plus complète de la façon suivante :
 +  * une communauté ''public'', qui aura droit à l'accès en lecture seule, mais seulement à la branche ''system'' pour tous ceux qui peuvent joindre notre agent, quelle que soit leur adresse IP ;
 +  * une communauté ''private'' aura droit à la lecture seule de toutes les informations possibles, mais seulement à partir d'un réseau IP particulier ;
 +  * une communauté ''admin'' pourra lire et écrire partout où c'est possible, mais depuis une adresse IP bien particulière.
 +Voici la configuration proposée :
 +<code>
 +com2sec voirUnPeu     default                public
 +com2sec voirTout      192.168.0.0/24         private
 +com2sec voirEtToucher 192.168.0.16           admin
  
-poste client en 192.168.0.16+group touristes v1         voirUnPeu 
 +group touristes v2c        voirUnPeu 
 +group riverains v1         voirTout 
 +group riverains v2c        voirTout 
 +group proprio   v1         voirEtToucher 
 +group proprio   v2c        voirEtToucher
  
 +view system included       .1.3.6.1.2.1.1.1
 +view all    included       .1
  
 +access touristes ""      any       noauth    exact  system none   none
 +access riverains ""      any       noauth    exact  all    none   none
 +access proprio   ""      any       noauth    exact  all    all    none
 +</code>
 +==== Interro surprise 2 ====
 +  - Quelqu'un se déclarant de la communauté ''public'' pourra-t-il
 +    - se connecter depuis n'importe quelle adresse IP ?
 +    - obtenir les informations de la branche ''.iso.org.dod.internet.mgmt.mib-2.interfaces'' ? (on pourra s'aider de ''snmptranslate'' pour obtenir la version numérique de cette branche)
 +  - Quelqu'un se déclarant de la communauté ''private'' pourra-t-il
 +    - obtenir les informations de la branche ''.iso.org.dod.internet.mgmt.mib-2.interfaces'' s'il dispose de l'adresse 192.168.1.25 ?
 +    - obtenir les informations de la branche ''.iso.org.dod.internet.mgmt.mib-2.interfaces'' s'il dispose de l'adresse 192.168.0.25 ?
 +  - Quelqu'un se déclarant de la communauté ''admin'' depuis l'adresse IP 192.168.0.17
 +    - pourra-t-il obtenir les informations de la branche ''.1.3.6.1.2.1.2'' ?
 +    - pourra-t-il modifier une valeur accessible en écriture (SNMPv2-MIB::sysLocation par exemple) ?
 + 
 +Réponses toujours en dernière page.
  
-interrogation du switch 
-  snmpwalk -m /usr/share/mibs/ietf/BRIDGE-MIB -OX -v 2c -c public sw-hp-2.eme.org dot1dTpFdbPort 
En savoir un peu plus: Dernière modification le: 10/07/2010 à 14:29 par prof