Translated ['src/network-services-pentesting/pentesting-voip/basic-voip-

src/network-services-pentesting/pentesting-voip/basic-voip-protocols/sip-session-initiation-protocol.md

@@ -4,71 +4,71 @@
 
 ## Informations de base
 
-SIP (Session Initiation Protocol) est un **protocole de signalisation et de contrôle des appels** largement utilisé pour établir, modifier et terminer des sessions multimédias, y compris la voix, la vidéo et la messagerie instantanée, sur des réseaux IP. Développé par l'**Internet Engineering Task Force (IETF)**, SIP est défini dans le **RFC 3261** et est devenu la norme de facto pour la VoIP et les communications unifiées.
+SIP (Session Initiation Protocol) est un **protocole de signalisation et de contrôle d'appel** largement utilisé pour établir, modifier et terminer des sessions multimédia, y compris la voix, la vidéo et la messagerie instantanée, sur les réseaux IP. Développé par l'**Internet Engineering Task Force (IETF)**, SIP est défini dans **RFC 3261** et est devenu le standard de facto pour la VoIP et les communications unifiées.
 
-Certaines caractéristiques clés de SIP incluent :
+Parmi les principales caractéristiques de SIP :
 
-1. **Protocole basé sur du texte** : SIP est un protocole basé sur du texte, ce qui le rend lisible par l'homme et plus facile à déboguer. Il est basé sur un modèle de requête-réponse, similaire à HTTP, et utilise des méthodes comme INVITE, ACK, BYE et CANCEL pour contrôler les sessions d'appel.
-2. **Scalabilité et flexibilité** : SIP est hautement évolutif et peut être utilisé dans des déploiements à petite échelle ainsi que dans des environnements d'entreprise et de niveau opérateur. Il peut être facilement étendu avec de nouvelles fonctionnalités, le rendant adaptable à divers cas d'utilisation et exigences.
-3. **Interopérabilité** : L'adoption et la normalisation généralisées de SIP garantissent une meilleure interopérabilité entre différents appareils, applications et fournisseurs de services, favorisant une communication fluide sur diverses plateformes.
-4. **Conception modulaire** : SIP fonctionne avec d'autres protocoles comme le **RTP (Real-time Transport Protocol)** pour la transmission multimédia et le **SDP (Session Description Protocol)** pour décrire les sessions multimédias. Cette conception modulaire permet une plus grande flexibilité et compatibilité avec différents types de médias et codecs.
-5. **Serveurs proxy et de redirection** : SIP peut utiliser des serveurs proxy et de redirection pour faciliter le routage des appels et fournir des fonctionnalités avancées comme le renvoi d'appels, le transfert d'appels et les services de messagerie vocale.
-6. **Présence et messagerie instantanée** : SIP n'est pas limité à la communication vocale et vidéo. Il prend également en charge la présence et la messagerie instantanée, permettant une large gamme d'applications de communication unifiée.
+1. **Protocole textuel** : SIP est un protocole textuel, ce qui le rend lisible par l'humain et plus facile à déboguer. Il est basé sur un modèle requête-réponse, similaire à HTTP, et utilise des méthodes comme INVITE, ACK, BYE et CANCEL pour contrôler les sessions d'appel.
+2. **Évolutivité et flexibilité** : SIP est hautement évolutif et peut être utilisé dans des déploiements de petite taille ainsi que dans des environnements d'entreprise et de niveau opérateur. Il peut être facilement étendu avec de nouvelles fonctionnalités, le rendant adaptable à divers cas d'utilisation et exigences.
+3. **Interopérabilité** : L'adoption généralisée et la normalisation de SIP assurent une meilleure interopérabilité entre différents appareils, applications et fournisseurs de services, favorisant une communication sans couture entre différentes plateformes.
+4. **Conception modulaire** : SIP fonctionne avec d'autres protocoles comme **RTP (Real-time Transport Protocol)** pour la transmission des médias et **SDP (Session Description Protocol)** pour décrire les sessions multimédia. Cette conception modulaire permet une plus grande flexibilité et compatibilité avec différents types de médias et codecs.
+5. **Serveurs proxy et de redirection** : SIP peut utiliser des serveurs proxy et de redirection pour faciliter le routage des appels et fournir des fonctionnalités avancées comme le renvoi d'appel, le transfert d'appel et la messagerie vocale.
+6. **Présence et messagerie instantanée** : SIP ne se limite pas à la communication voix et vidéo. Il prend également en charge la présence et la messagerie instantanée, permettant une large gamme d'applications de communication unifiée.
 
-Malgré ses nombreux avantages, SIP peut être complexe à configurer et à gérer, en particulier lorsqu'il s'agit de la traversée NAT et des problèmes de pare-feu. Cependant, sa polyvalence, sa scalabilité et son large soutien dans l'industrie en font un choix populaire pour la VoIP et la communication multimédia.
+Malgré ses nombreux avantages, SIP peut être complexe à configurer et à gérer, en particulier lorsqu'il s'agit de la traversal NAT et des problèmes de pare-feu. Cependant, sa polyvalence, son évolutivité et son large support industriel en font un choix populaire pour la VoIP et la communication multimédia.
 
 ### Méthodes SIP
 
-Les méthodes SIP de base définies dans le **RFC 3261** incluent :
+Les méthodes SIP de base définies dans **RFC 3261** incluent :
 
-1. **INVITE** : Utilisé pour **initier une nouvelle session (appel)** ou modifier une session existante. La méthode INVITE transporte la description de la session (généralement en utilisant SDP) pour informer le destinataire des détails de la session proposée, tels que les types de médias, les codecs et les protocoles de transport.
-2. **ACK** : Envoyé pour **confirmer la réception** d'une réponse finale à une demande INVITE. La méthode ACK garantit la fiabilité des transactions INVITE en fournissant une reconnaissance de bout en bout.
-3. **BYE** : Utilisé pour **terminer une session établie (appel)**. La méthode BYE est envoyée par l'une ou l'autre des parties dans la session pour indiquer qu'elles souhaitent mettre fin à la communication.
-4. **CANCEL** : Envoyé pour **annuler une demande INVITE** en attente avant que la session ne soit établie. La méthode CANCEL permet à l'expéditeur d'abandonner une transaction INVITE s'il change d'avis ou s'il n'y a pas de réponse du destinataire.
-5. **OPTIONS** : Utilisé pour **interroger les capacités d'un serveur SIP ou d'un agent utilisateur**. La méthode OPTIONS peut être envoyée pour demander des informations sur les méthodes prises en charge, les types de médias ou d'autres extensions sans établir réellement une session.
-6. **REGISTER** : Utilisé par un agent utilisateur pour **enregistrer sa position actuelle auprès d'un serveur d'enregistrement SIP**. La méthode REGISTER aide à maintenir une correspondance à jour entre l'URI SIP d'un utilisateur et son adresse IP actuelle, permettant le routage et la livraison des appels.
+1. **INVITE** : Utilisé pour **initier une nouvelle session (appel)** ou modifier une session existante. La méthode INVITE transporte la description de session (généralement en utilisant SDP) pour informer le destinataire des détails de la session proposée, comme les types de médias, les codecs et les protocoles de transport.
+2. **ACK** : Envoyé pour **confirmer la réception** d'une réponse finale à une requête INVITE. La méthode ACK assure la fiabilité des transactions INVITE en fournissant une reconnaissance de bout en bout.
+3. **BYE** : Utilisé pour **terminer une session établie (appel)**. La méthode BYE est envoyée par l'une ou l'autre des parties de la session pour indiquer qu'elles souhaitent mettre fin à la communication.
+4. **CANCEL** : Envoyé pour **annuler un INVITE en attente** avant l'établissement de la session. La méthode CANCEL permet à l'expéditeur d'abandonner une transaction INVITE s'il change d'avis ou si le destinataire ne répond pas.
+5. **OPTIONS** : Utilisé pour **interroger les capacités d'un serveur SIP ou d'un user agent**. La méthode OPTIONS peut être envoyée pour demander des informations sur les méthodes prises en charge, les types de médias ou d'autres extensions sans établir de session.
+6. **REGISTER** : Utilisé par un user agent pour **enregistrer sa localisation actuelle auprès d'un serveur registrar SIP**. La méthode REGISTER aide à maintenir une correspondance à jour entre l'URI SIP d'un utilisateur et son adresse IP actuelle, permettant le routage et la délivrance des appels.
 
 > [!WARNING]
-> Notez que pour appeler quelqu'un, il **n'est pas nécessaire d'utiliser le REGISTER** pour quoi que ce soit.\
-> Cependant, il est possible que pour effectuer un **INVITE**, l'appelant doive d'abord **s'authentifier** ou il recevra une réponse **`401 Unauthorized`**.
+> Notez que pour appeler quelqu'un il **n'est pas nécessaire d'utiliser REGISTER** pour quoi que ce soit.\
+> Cependant, il est possible que, pour effectuer un **INVITE**, l'appelant doive d'abord **s'authentifier** ou qu'il reçoive une réponse **`401 Unauthorized`**.
 
 En plus de ces méthodes de base, il existe **plusieurs méthodes d'extension SIP** définies dans d'autres RFC, telles que :
 
-1. **SUBSCRIBE** : Définie dans le RFC 6665, la méthode SUBSCRIBE est utilisée pour **demander des notifications** sur l'état d'une ressource spécifique, comme la présence d'un utilisateur ou l'état d'un appel.
-2. **NOTIFY** : Également définie dans le RFC 6665, la méthode NOTIFY est envoyée par un serveur pour **informer un agent utilisateur abonné** des changements dans l'état d'une ressource surveillée.
-3. **REFER** : Définie dans le RFC 3515, la méthode REFER est utilisée pour **demander que le destinataire effectue un transfert ou se réfère à un tiers**. Cela est généralement utilisé pour des scénarios de **transfert d'appel**.
-4. **MESSAGE** : Définie dans le RFC 3428, la méthode MESSAGE est utilisée pour **envoyer des messages instantanés entre des agents utilisateurs SIP**, permettant une communication textuelle au sein du cadre SIP.
-5. **UPDATE** : Définie dans le RFC 3311, la méthode UPDATE permet **de modifier une session sans affecter l'état du dialogue existant**. Cela est utile pour mettre à jour les paramètres de session, tels que les codecs ou les types de médias, pendant un appel en cours.
-6. **PUBLISH** : Définie dans le RFC 3903, la méthode PUBLISH est utilisée par un agent utilisateur pour **publier des informations d'état d'événement sur un serveur**, les rendant disponibles à d'autres parties intéressées.
+1. **SUBSCRIBE** : Définie dans RFC 6665, la méthode SUBSCRIBE est utilisée pour **demander des notifications** sur l'état d'une ressource spécifique, comme la présence d'un utilisateur ou l'état d'un appel.
+2. **NOTIFY** : Également définie dans RFC 6665, la méthode NOTIFY est envoyée par un serveur pour **informer un user agent abonné** des changements d'état d'une ressource surveillée.
+3. **REFER** : Définie dans RFC 3515, la méthode REFER est utilisée pour **demander au destinataire d'effectuer un transfert ou de référer à un tiers**. Elle est typiquement utilisée pour des scénarios de **transfert d'appel**.
+4. **MESSAGE** : Définie dans RFC 3428, la méthode MESSAGE est utilisée pour **envoyer des messages instantanés entre user agents SIP**, permettant la communication textuelle au sein du framework SIP.
+5. **UPDATE** : Définie dans RFC 3311, la méthode UPDATE permet de **modifier une session sans affecter l'état du dialog existant**. Cela est utile pour mettre à jour des paramètres de session, comme les codecs ou les types de médias, pendant un appel en cours.
+6. **PUBLISH** : Définie dans RFC 3903, la méthode PUBLISH est utilisée par un user agent pour **publier des informations d'état d'événement sur un serveur**, les rendant disponibles à d'autres parties intéressées.
 
 ### Codes de réponse SIP
 
-- **1xx (Réponses provisoires)** : Ces réponses indiquent que la demande a été reçue et que le serveur continue de la traiter.
-- 100 Trying : La demande a été reçue et le serveur y travaille.
-- 180 Ringing : Le destinataire est alerté et va prendre l'appel.
-- 183 Session Progress : Fournit des informations sur l'avancement de l'appel.
-- **2xx (Réponses réussies)** : Ces réponses indiquent que la demande a été reçue, comprise et acceptée avec succès.
-- 200 OK : La demande a été réussie et le serveur l'a remplie.
-- 202 Accepted : La demande a été acceptée pour traitement, mais elle n'est pas encore terminée.
-- **3xx (Réponses de redirection)** : Ces réponses indiquent qu'une action supplémentaire est requise pour satisfaire la demande, généralement en contactant une ressource alternative.
-- 300 Multiple Choices : Il existe plusieurs options disponibles, et l'utilisateur ou le client doit en choisir une.
-- 301 Moved Permanently : La ressource demandée a été assignée à un nouvel URI permanent.
-- 302 Moved Temporarily : La ressource demandée est temporairement disponible à un URI différent.
-- 305 Use Proxy : La demande doit être envoyée à un proxy spécifié.
-- **4xx (Réponses d'erreur client)** : Ces réponses indiquent que la demande contient une mauvaise syntaxe ou ne peut pas être satisfaite par le serveur.
-- 400 Bad Request : La demande était mal formée ou invalide.
-- 401 Unauthorized : La demande nécessite une authentification de l'utilisateur.
-- 403 Forbidden : Le serveur a compris la demande mais refuse de la satisfaire.
+- **1xx (Réponses provisoires)** : Ces réponses indiquent que la requête a été reçue et que le serveur continue de la traiter.
+- 100 Trying : La requête a été reçue et le serveur est en train de la traiter.
+- 180 Ringing : Le correspondant est en train d'être alerté et va prendre l'appel.
+- 183 Session Progress : Fournit des informations sur la progression de l'appel.
+- **2xx (Réponses réussies)** : Ces réponses indiquent que la requête a été reçue, comprise et acceptée avec succès.
+- 200 OK : La requête a réussi et le serveur l'a exécutée.
+- 202 Accepted : La requête a été acceptée pour traitement, mais elle n'est pas encore terminée.
+- **3xx (Réponses de redirection)** : Ces réponses indiquent qu'une action supplémentaire est requise pour satisfaire la requête, typiquement en contactant une ressource alternative.
+- 300 Multiple Choices : Il existe plusieurs options disponibles et l'utilisateur ou le client doit en choisir une.
+- 301 Moved Permanently : La ressource demandée s'est vue attribuer une nouvelle URI permanente.
+- 302 Moved Temporarily : La ressource demandée est temporairement disponible à une URI différente.
+- 305 Use Proxy : La requête doit être envoyée à un proxy spécifié.
+- **4xx (Erreurs client)** : Ces réponses indiquent que la requête contient une mauvaise syntaxe ou ne peut pas être satisfaite par le serveur.
+- 400 Bad Request : La requête était mal formée ou invalide.
+- 401 Unauthorized : La requête nécessite une authentification de l'utilisateur.
+- 403 Forbidden : Le serveur a compris la requête mais refuse de l'exécuter.
 - 404 Not Found : La ressource demandée n'a pas été trouvée sur le serveur.
-- 408 Request Timeout : Le serveur n'a pas reçu une demande complète dans le temps qu'il était prêt à attendre.
-- 486 Busy Here : Le destinataire est actuellement occupé et ne peut pas prendre l'appel.
-- **5xx (Réponses d'erreur serveur)** : Ces réponses indiquent que le serveur a échoué à satisfaire une demande valide.
-- 500 Internal Server Error : Le serveur a rencontré une erreur lors du traitement de la demande.
-- 501 Not Implemented : Le serveur ne prend pas en charge la fonctionnalité requise pour satisfaire la demande.
-- 503 Service Unavailable : Le serveur est actuellement incapable de traiter la demande en raison de maintenance ou de surcharge.
-- **6xx (Réponses d'échec global)** : Ces réponses indiquent que la demande ne peut pas être satisfaite par aucun serveur.
-- 600 Busy Everywhere : Tous les destinations possibles pour l'appel sont occupées.
-- 603 Decline : Le destinataire ne souhaite pas participer à l'appel.
+- 408 Request Timeout : Le serveur n'a pas reçu une requête complète dans le délai qu'il était prêt à attendre.
+- 486 Busy Here : Le correspondant est actuellement occupé et ne peut pas prendre l'appel.
+- **5xx (Erreurs serveur)** : Ces réponses indiquent que le serveur n'a pas pu satisfaire une requête valide.
+- 500 Internal Server Error : Le serveur a rencontré une erreur lors du traitement de la requête.
+- 501 Not Implemented : Le serveur ne prend pas en charge la fonctionnalité requise pour exécuter la requête.
+- 503 Service Unavailable : Le serveur est actuellement incapable de traiter la requête en raison de maintenance ou de surcharge.
+- **6xx (Échecs globaux)** : Ces réponses indiquent que la requête ne peut être satisfaite par aucun serveur.
+- 600 Busy Everywhere : Toutes les destinations possibles pour l'appel sont occupées.
+- 603 Decline : Le correspondant ne souhaite pas participer à l'appel.
 - 604 Does Not Exist Anywhere : La ressource demandée n'est disponible nulle part dans le réseau.
 
 ## Exemples
@@ -94,43 +94,43 @@ s=-
 c=IN IP4 pc33.example.com
 t=0 0
 m=audio 49170 RTP/AVP 0
-a=rtpmap:0 PCMU/8000te
+a=rtpmap:0 PCMU/8000
 ```
 <details>
 
-<summary>Chaque Paramètre Expliqué</summary>
+<summary>Chaque paramètre expliqué</summary>
 
-1. **Request-Line**: `INVITE sip:jdoe@example.com SIP/2.0` - Cette ligne indique la méthode (INVITE), l'URI de la requête (sip:[jdoe@example.com](mailto:jdoe@example.com)), et la version SIP (SIP/2.0).
-2. **Via**: `Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds` - L'en-tête Via spécifie le protocole de transport (UDP) et l'adresse du client (pc33.example.com). Le paramètre "branch" est utilisé pour la détection de boucle et la correspondance des transactions.
-3. **Max-Forwards**: `Max-Forwards: 70` - Ce champ d'en-tête limite le nombre de fois que la requête peut être transférée par des proxies pour éviter des boucles infinies.
-4. **To**: `To: John Doe <sip:jdoe@example.com>` - L'en-tête To spécifie le destinataire de l'appel, y compris son nom d'affichage (John Doe) et l'URI SIP (sip:[jdoe@example.com](mailto:jdoe@example.com)).
-5. **From**: `From: Jane Smith <sip:jsmith@example.org>;tag=1928301774` - L'en-tête From spécifie l'expéditeur de l'appel, y compris son nom d'affichage (Jane Smith) et l'URI SIP (sip:[jsmith@example.org](mailto:jsmith@example.org)). Le paramètre "tag" est utilisé pour identifier de manière unique le rôle de l'expéditeur dans le dialogue.
-6. **Call-ID**: `Call-ID: a84b4c76e66710` - L'en-tête Call-ID identifie de manière unique une session d'appel entre deux agents utilisateurs.
-7. **CSeq**: `CSeq: 314159 INVITE` - L'en-tête CSeq contient un numéro de séquence et la méthode utilisée dans la requête. Il est utilisé pour faire correspondre les réponses aux requêtes et détecter les messages hors ordre.
-8. **Contact**: `Contact: <sip:jsmith@pc33.example.com>` - L'en-tête Contact fournit un chemin direct vers l'expéditeur, qui peut être utilisé pour des requêtes et réponses ultérieures.
-9. **User-Agent**: `User-Agent: ExampleSIPClient/1.0` - L'en-tête User-Agent fournit des informations sur le logiciel ou le matériel de l'expéditeur, y compris son nom et sa version.
-10. **Allow**: `Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO` - L'en-tête Allow liste les méthodes SIP prises en charge par l'expéditeur. Cela aide le destinataire à comprendre quelles méthodes peuvent être utilisées lors de la communication.
-11. **Content-Type**: `Content-Type: application/sdp` - L'en-tête Content-Type spécifie le type de média du corps du message, dans ce cas, SDP (Session Description Protocol).
+1. **Request-Line**: `INVITE sip:jdoe@example.com SIP/2.0` - Cette ligne indique la méthode (INVITE), l'URI de requête (sip:jdoe@example.com) et la version SIP (SIP/2.0).
+2. **Via**: `Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds` - L'en-tête Via spécifie le protocole de transport (UDP) et l'adresse du client (pc33.example.com). Le paramètre "branch" est utilisé pour la détection de boucles et le matching des transactions.
+3. **Max-Forwards**: `Max-Forwards: 70` - Ce champ limite le nombre de fois que la requête peut être transférée par des proxies afin d'éviter des boucles infinies.
+4. **To**: `To: John Doe <sip:jdoe@example.com>` - L'en-tête To précise le destinataire de l'appel, incluant son nom affiché (John Doe) et l'URI SIP (sip:jdoe@example.com).
+5. **From**: `From: Jane Smith <sip:jsmith@example.org>;tag=1928301774` - L'en-tête From indique l'expéditeur de l'appel, incluant son nom affiché (Jane Smith) et l'URI SIP (sip:jsmith@example.org). Le paramètre "tag" sert à identifier de façon unique le rôle de l'expéditeur dans le dialog.
+6. **Call-ID**: `Call-ID: a84b4c76e66710` - L'en-tête Call-ID identifie de manière unique une session d'appel entre deux user agents.
+7. **CSeq**: `CSeq: 314159 INVITE` - L'en-tête CSeq contient un numéro de séquence et la méthode utilisée dans la requête. Il sert à associer les réponses aux requêtes et à détecter les messages hors d'ordre.
+8. **Contact**: `Contact: <sip:jsmith@pc33.example.com>` - L'en-tête Contact fournit une route directe vers l'expéditeur, utilisable pour les requêtes et réponses ultérieures.
+9. **User-Agent**: `User-Agent: ExampleSIPClient/1.0` - L'en-tête User-Agent donne des informations sur le logiciel ou le matériel de l'expéditeur, incluant son nom et sa version.
+10. **Allow**: `Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO` - L'en-tête Allow liste les méthodes SIP supportées par l'expéditeur. Cela aide le destinataire à comprendre quelles méthodes peuvent être utilisées pendant la communication.
+11. **Content-Type**: `Content-Type: application/sdp` - L'en-tête Content-Type précise le type de média du corps du message, dans ce cas SDP (Session Description Protocol).
 12. **Content-Length**: `Content-Length: 142` - L'en-tête Content-Length indique la taille du corps du message en octets.
 13. **Message Body**: Le corps du message contient la description de session SDP, qui inclut des informations sur les types de médias, les codecs et les protocoles de transport pour la session proposée.
 
 - `v=0` - Version du protocole (0 pour SDP)
-- `o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com` - Originateur et identifiant de session
-- `s=-` - Nom de session (un seul tiret indique qu'il n'y a pas de nom de session)
+- `o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com` - Initiateur et identifiant de session
+- `s=-` - Nom de la session (un tiret unique indique l'absence de nom de session)
 - `c=IN IP4 pc33.example.com` - Informations de connexion (type de réseau, type d'adresse et adresse)
-- `t=0 0` - Informations de timing (heures de début et de fin, 0 0 signifie que la session n'est pas limitée)
-- `m=audio 49170 RTP/AVP 0` - Description du média (type de média, numéro de port, protocole de transport et liste de formats). Dans ce cas, cela spécifie un flux audio utilisant RTP/AVP (Real-time Transport Protocol / Audio Video Profile) et le format 0 (PCMU/8000).
-- `a=rtpmap:0 PCMU/8000` - Attribut mappant le format (0) au codec (PCMU) et son taux d'horloge (8000 Hz).
+- `t=0 0` - Informations de timing (heures de début et de fin, 0 0 signifie que la session n'est pas bornée)
+- `m=audio 49170 RTP/AVP 0` - Description du média (type de média, numéro de port, protocole de transport et liste de formats). Ici, cela spécifie un flux audio utilisant RTP/AVP (Real-time Transport Protocol / Audio Video Profile) et le format 0 (PCMU/8000).
+- `a=rtpmap:0 PCMU/8000` - Attribut qui mappe le format (0) au codec (PCMU) et à sa fréquence d'horloge (8000 Hz).
 
 </details>
 
-### Exemple SIP REGISTER
+### Exemple de REGISTER SIP
 
-La méthode REGISTER est utilisée dans le protocole d'initiation de session (SIP) pour permettre à un agent utilisateur (UA), tel qu'un téléphone VoIP ou un softphone, de **s'enregistrer auprès d'un serveur d'enregistrement SIP**. Ce processus permet au serveur de savoir **où acheminer les requêtes SIP entrantes destinées à l'utilisateur enregistré**. Le serveur d'enregistrement fait généralement partie d'un serveur proxy SIP ou d'un serveur d'enregistrement dédié.
+La méthode REGISTER est utilisée dans le Session Initiation Protocol (SIP) pour permettre à un user agent (UA), tel qu'un téléphone VoIP ou un softphone, de **s'enregistrer auprès d'un SIP registrar server**. Ce processus permet au serveur de savoir **où acheminer les requêtes SIP entrantes destinées à l'utilisateur enregistré**. Le serveur registrar fait généralement partie d'un SIP proxy server ou d'un serveur d'enregistrement dédié.
 
 Voici un exemple détaillé des messages SIP impliqués dans un processus d'authentification REGISTER :
 
-1. Requête initiale **REGISTER** de l'UA au serveur d'enregistrement :
+1. Requête initiale **REGISTER** du user agent (UA) vers le serveur registrar :
 ```yaml
 REGISTER sip:example.com SIP/2.0
 Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
@@ -143,11 +143,11 @@ Contact: <sip:alice@192.168.1.100:5060>;expires=3600
 Expires: 3600
 Content-Length: 0
 ```
-Ce message REGISTER initial est envoyé par l'UA (Alice) au serveur d'enregistrement. Il inclut des informations importantes telles que la durée d'enregistrement souhaitée (Expires), l'URI SIP de l'utilisateur (sip:[alice@example.com](mailto:alice@example.com)), et l'adresse de contact de l'utilisateur (sip:alice@192.168.1.100:5060).
+Ce message initial REGISTER est envoyé par l'UA (Alice) au serveur d'enregistrement. Il contient des informations importantes telles que la durée d'enregistrement souhaitée (Expires), le SIP URI de l'utilisateur (sip:[alice@example.com](mailto:alice@example.com)), et l'adresse de contact de l'utilisateur (sip:alice@192.168.1.100:5060).
 
 2. **401 Unauthorized** réponse du serveur d'enregistrement :
-```css
-cssCopy codeSIP/2.0 401 Unauthorized
+```
+SIP/2.0 401 Unauthorized
 Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
 From: Alice <sip:alice@example.com>;tag=565656
 To: Alice <sip:alice@example.com>;tag=7878744
@@ -156,9 +156,9 @@ CSeq: 1 REGISTER
 WWW-Authenticate: Digest realm="example.com", nonce="abcdefghijk", algorithm=MD5, qop="auth"
 Content-Length: 0
 ```
-Le serveur d'enregistrement répond avec un message "401 Unauthorized", qui inclut un en-tête "WWW-Authenticate". Cet en-tête contient des informations nécessaires pour que l'UA s'authentifie, telles que le **domaine d'authentification, le nonce et l'algorithme**.
+Le serveur d'enregistrement répond par un message "401 Unauthorized", qui inclut un en-tête "WWW-Authenticate". Cet en-tête contient les informations requises pour que l'UA s'authentifie, telles que le **realm d'authentification, le nonce et l'algorithme**.
 
-3. Demande REGISTER **avec des informations d'identification d'authentification** :
+3. Requête REGISTER **avec des identifiants d'authentification** :
 ```vbnet
 REGISTER sip:example.com SIP/2.0
 Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
@@ -172,9 +172,9 @@ Expires: 3600
 Authorization: Digest username="alice", realm="example.com", nonce="abcdefghijk", uri="sip:example.com", response="65a8e2285879283831b664bd8b7f14d4", algorithm=MD5, cnonce="lmnopqrst", qop=auth, nc=00000001
 Content-Length: 0
 ```
-L'UA envoie une autre requête REGISTER, cette fois en incluant l'**en-tête "Authorization" avec les informations d'identification nécessaires, telles que le nom d'utilisateur, le domaine, le nonce et une valeur de réponse** calculée en utilisant les informations fournies et le mot de passe de l'utilisateur.
+L'UA envoie une autre requête REGISTER, cette fois en incluant l'en-tête **"Authorization"** avec les identifiants nécessaires, tels que le username, realm, nonce, et une valeur response calculée en utilisant les informations fournies et le mot de passe de l'utilisateur.
 
-Voici comment la **réponse d'Authorization** est calculée :
+Voici comment la **Authorization response** est calculée :
 ```python
 import hashlib
 
@@ -207,7 +207,7 @@ qop = "auth"
 response = calculate_sip_md5_response(username, password, realm, method, uri, nonce, nc, cnonce, qop)
 print(f"MD5 response value: {response}")
 ```
-4. **Réponse de registration** réussie du serveur d'enregistrement :
+4. **Réponse d'enregistrement réussie** du serveur d'enregistrement:
 ```yaml
 SIP/2.0 200 OK
 Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
@@ -219,13 +219,98 @@ Contact: <sip:alice@192.168.1.100:5060>;expires=3600
 Expires: 3600
 Content-Length: 0
 ```
-Après que le serveur d'enregistrement a vérifié les informations d'identification fournies, **il envoie une réponse "200 OK" pour indiquer que l'enregistrement a réussi**. La réponse inclut les informations de contact enregistrées et le temps d'expiration de l'enregistrement. À ce stade, l'agent utilisateur (Alice) est correctement enregistré auprès du serveur d'enregistrement SIP, et les demandes SIP entrantes pour Alice peuvent être acheminées vers l'adresse de contact appropriée.
+Après que le serveur registrar ait vérifié les identifiants fournis, **il envoie une réponse "200 OK" pour indiquer que l'enregistrement a réussi**. La réponse inclut les informations de contact enregistrées et la durée d'expiration de l'enregistrement. À ce stade, l'agent utilisateur (Alice) est correctement enregistré auprès du serveur registrar SIP, et les requêtes SIP entrantes destinées à Alice peuvent être acheminées vers l'adresse de contact appropriée.
 
 ### Exemple d'appel
 
 <figure><img src="../../../images/image (1101).png" alt=""><figcaption></figcaption></figure>
 
-> [!NOTE]
-> Il n'est pas mentionné, mais l'utilisateur B doit avoir envoyé un **message REGISTER à Proxy 2** avant de pouvoir recevoir des appels.
+> [!TIP]
+> Ce n'est pas mentionné, mais User B doit avoir envoyé un **REGISTER message à Proxy 2** avant de pouvoir recevoir des appels.
 
+
+
+---
+
+## SIP Sécurité et Pentesting Notes
+
+Cette section apporte des conseils pratiques, spécifiques au protocole, sans dupliquer les recommandations générales VoIP. Pour la méthodologie d'attaque VoIP de bout en bout, les outils et les scénarios, voir :
+
+{{#ref}}
+../README.md
+{{#endref}}
+
+### Empreinte et découverte
+
+- Envoyez une requête OPTIONS et examinez les en-têtes `Allow`, `Supported`, `Server` et `User-Agent` pour profiler les appareils et les stacks :
+
+```bash
+# nmap NSE (UDP 5060 by default)
+sudo nmap -sU -p 5060 --script sip-methods <target>
+
+# Minimal raw OPTIONS over UDP
+printf "OPTIONS sip:<target> SIP/2.0\r\nVia: SIP/2.0/UDP attacker;branch=z9\r\nFrom: <sip:probe@attacker>;tag=1\r\nTo: <sip:probe@<target>>\r\nCall-ID: 1@attacker\r\nCSeq: 1 OPTIONS\r\nMax-Forwards: 70\r\nContact: <sip:probe@attacker>\r\nContent-Length: 0\r\n\r\n" | nc -u -w 2 <target> 5060
+```
+
+### Comportement d'énumération des noms d'utilisateur/extensions
+
+- L'énumération abuse généralement des différences entre `401/407` et `404/403` sur `REGISTER`/`INVITE`. Durcissez les serveurs pour qu'ils répondent de manière uniforme.
+- Asterisk chan_sip : définissez `alwaysauthreject=yes` (général) pour éviter de divulguer des utilisateurs valides. Dans les versions récentes d'Asterisk (PJSIP), les appels guests sont désactivés sauf si un endpoint `anonymous` est défini et un comportement similaire de "always auth reject" est par défaut ; appliquez néanmoins des ACL réseau et fail2ban à la périphérie.
+
+### SIP Digest Authentication: algorithms and cracking
+
+- SIP utilise couramment un auth de type HTTP-Digest. Historiquement MD5 (et MD5-sess) sont répandus ; les stacks plus récents supportent SHA-256 et SHA-512/256 selon RFC 8760. Préférez ces algorithmes plus forts dans les déploiements modernes et désactivez MD5 quand c'est possible.
+- Le cracking hors ligne depuis un pcap est trivial pour les digests MD5. Après avoir extrait le challenge/response, vous pouvez utiliser hashcat mode 11400 (SIP digest, MD5) :
+
+```bash
+# Example hash format (single line)
+# username:realm:method:uri:nonce:cnonce:nc:qop:response
+echo 'alice:example.com:REGISTER:sip:example.com:abcdef:11223344:00000001:auth:65a8e2285879283831b664bd8b7f14d4' > sip.hash
+
+# Crack with a wordlist
+hashcat -a 0 -m 11400 sip.hash /path/to/wordlist.txt
+```
+
+> [!NOTE]
+> RFC 8760 définit SHA-256 et SHA-512/256 pour HTTP Digest (utilisé par SIP). L'adoption est inégale ; assurez-vous que vos outils gèrent ces algorithmes lorsque vous ciblez des PBX modernes.
+
+### SIP sur TLS (SIPS) et sur WebSockets
+
+- Chiffrement du signaling :
+- Les URI `sips:` et TCP/TLS sont typiquement sur le port 5061. Vérifiez la validation des certificats sur les endpoints ; beaucoup acceptent des certificats auto-signés ou wildcard, permettant des MitM dans des déploiements faibles.
+- Les softphones WebRTC utilisent souvent SIP over WebSocket selon RFC 7118 (`ws://` ou `wss://`). Si le PBX expose WSS, testez l'authentification et le CORS, et assurez-vous que des limites de taux sont appliquées également sur la couche HTTP frontale.
+
+### Vérifications rapides DoS (niveau protocole)
+
+- Le flooding d'INVITE, REGISTER ou de messages malformés peut épuiser le traitement des transactions.
+- Exemple simple de limitation de débit pour UDP/5060 (Linux iptables hashlimit) :
+
+```bash
+# Limit new SIP packets from a single IP to 20/s with burst 40
+iptables -A INPUT -p udp --dport 5060 -m hashlimit \
+--hashlimit-name SIP --hashlimit 20/second --hashlimit-burst 40 \
+--hashlimit-mode srcip -j ACCEPT
+iptables -A INPUT -p udp --dport 5060 -j DROP
+```
+
+### CVE récentes et pertinentes des stacks SIP à surveiller (Asterisk PJSIP)
+
+- CVE-2024-35190 (publié le 17 mai 2024) : dans certaines versions d'Asterisk, `res_pjsip_endpoint_identifier_ip` pouvait mal identifier des requêtes SIP non autorisées comme un endpoint local, pouvant potentiellement permettre des actions non autorisées ou une exposition d'informations. Corrigé dans les versions 18.23.1, 20.8.1 et 21.3.1. Validez la version de votre PBX lors des tests et signalez de manière responsable.
+
+### Checklist de durcissement (spécifique SIP)
+
+- Préférez TLS pour le signaling et SRTP/DTLS-SRTP pour les médias ; désactivez le cleartext lorsque c'est possible.
+- Imposer des mots de passe forts et des algorithmes de digest robustes (SHA-256/512-256 lorsqu'ils sont supportés ; éviter MD5).
+- Pour Asterisk :
+- chan_sip : `alwaysauthreject=yes`, `allowguest=no`, ACL CIDR `permit`/`deny` par endpoint.
+- PJSIP : ne créez pas d'endpoint `anonymous` sauf si nécessaire ; appliquez `acl`/`media_acl` par endpoint ; activez fail2ban ou équivalent.
+- Masquage de la topologie sur les proxies SIP (par ex., outbound proxy/edge SBC) to reduce information leakage.
+- Traitement strict des `OPTIONS` et limites de taux ; désactivez les méthodes inutilisées (par ex., `MESSAGE`, `PUBLISH`) si elles ne sont pas requises.
+
+
+
+## Références
+
+- RFC 8760 – Utilisation de SHA-256 et SHA-512/256 pour HTTP Digest (s'applique aussi à SIP Digest) : https://www.rfc-editor.org/rfc/rfc8760
+- Asterisk GHSA advisory for CVE-2024-35190: https://github.com/asterisk/asterisk/security/advisories/GHSA-qqxj-v78h-hrf9
 {{#include ../../../banners/hacktricks-training.md}}