Comment empêcher un paquet UDP particulier de parvenir à Linphone ?

22 réponses
Avatar
Geo Cherchetout
Bonjour,

Je pense avoir identifié la cause exacte de mes échecs répétés quand je
tente d'envoyer un fax à l'aide de Linphone dans le rôle de transmetteur.
Quand Linphone reçoit une requête INVITE décrivant une session T38, au lieu
de répondre par un message du genre 488 (not acceptable here), il répond OK
et c'est le début d'un dialogue de sourd qui ne prend fin que quand le
télécopieur de mon correspondant décide de raccrocher.
Je précise que ni ce télécopieur ni mon fax-modem ne connaissent le
protocole T38. C'est apparemment la passerelle entre OVH et Orange qui prend
l'initiative malencontreuse de me faire envoyer ce paquet pour une raison
que j'ignore.

Je voudrais donc voir ce qu'il se passerait si le paquet UDP fautif de
trouble était escamoté silencieusement avant de parvenir à Linphone.

Ce paquet est reconnaissable en ce qu'il comporte une fois la chaîne de
caractères t38 et plusieurs fois T38. Je suppose qu'iptables est l'outil
adéquat mais il serait absurde que je passe des jours à apprivoiser cette
usine à gaz si un aimable contributeur pouvait en une minute me donner la
recette. ;-) Merci d'avance à lui ou elle.

10 réponses

1 2 3
Avatar
yamo'
Salut,

Geo Cherchetout a tapoté, le 13/12/2013 11:16:
Ce paquet est reconnaissable en ce qu'il comporte une fois la chaîne de
caractères t38 et plusieurs fois T38. Je suppose qu'iptables est l'outil
adéquat mais il serait absurde que je passe des jours à apprivoiser cette
usine à gaz si un aimable contributeur pouvait en une minute me donner la
recette. ;-) Merci d'avance à lui ou elle.




Pour avoir une réponse, je pense qu'il faudrait donner plus d'informations.

Est-ce que le port udp est toujours le même?
Qui initie cette connexion? Si ce n'est pas toi, ce doit être filtrable.

Peut-être que le résultat de la commande suivante peut donner des pistes :

netstat -altunp | grep -i linphone
#j'ai présumé que l'exécutable s’appelle linphone




--
Stéphane <http://pasdenom.info/fortune/?>
électromécanicienne ici n'a ce mort celé
-- Esposito-Farese, Gilles
Avatar
Geo Cherchetout
Le 13/12/2013 13:23, *yamo'* a écrit fort à propos :
Pour avoir une réponse, je pense qu'il faudrait donner plus
d'informations.

Est-ce que le port udp est toujours le même?



Oui, les ports source (5060) et destination (5061) des paquets relatifs à la
signalisation sont invariables ainsi que l'IP source (91.121.129.20) dès
lors que j'utilise Linphone configuré par mes soins et le « sip provider »
OVH, mais cela ne suffit pas pour caractériser le paquet indésirable parce
que quelques paquets utiles ont déjà été reçus auparavant répondant à ces
seuls critères.

Qui initie cette connexion? Si ce n'est pas toi, ce doit être filtrable.



La communication téléphonique est initiée par moi et semble devoir se
dérouler normalement pendant quelques secondes jusqu'à la réception de cette
requête incongrue. (À l'initiative, donc, de l'extrémité distante.)
Pas sûr de comprendre la signification du mot connexion dans cette question...

Peut-être que le résultat de la commande suivante peut donner des pistes
:

netstat -altunp | grep -i linphone #j'ai présumé que l'exécutable
s’appelle linphone



J'essaierai ça prochainement, merci. La suite en fin d'après-midi.
Avatar
Geo Cherchetout
Le 13/12/2013 13:23, *yamo'* a écrit fort à propos :

Peut-être que le résultat de la commande suivante peut donner des pistes :

netstat -altunp | grep -i linphone
#j'ai présumé que l'exécutable s’appelle linphone



J'ai envoyé cette commande plusieurs fois lors d'un essai (voué à l'échec
comme toujours) et j'obtiens chaque fois la même réponse :

# netstat -altunp | grep -i linphone
udp 0 0 0.0.0.0:7078 0.0.0.0:* 20541/linphone
udp 0 0 0.0.0.0:7079 0.0.0.0:* 20541/linphone
udp 0 0 0.0.0.0:5061 0.0.0.0:* 20541/linphone

Pour Linphone, le port 7078 est dédié aux flux audio.
Les captures que j'ai pu faire avec wireshark ne révèlent aucun échange
passant par le port 7079, ou du moins je n'ai rien vu de tel.
J'ai choisi le port 5061 comme port sip dans la configuration de linphone
dans l'intention d'éviter les conflits avec l'ATA de mon modem-routeur qui
utilise le 5060.
Avatar
Benoit Izac
Bonjour,

le 13/12/2013 à 11:16, Geo Cherchetout a écrit dans le message
<l8emp3$tqr$ :

Je pense avoir identifié la cause exacte de mes échecs répétés quand
je tente d'envoyer un fax à l'aide de Linphone dans le rôle de
transmetteur. Quand Linphone reçoit une requête INVITE décrivant une
session T38, au lieu de répondre par un message du genre 488 (not
acceptable here), il répond OK et c'est le début d'un dialogue de
sourd qui ne prend fin que quand le télécopieur de mon correspondant
décide de raccrocher.
Je précise que ni ce télécopieur ni mon fax-modem ne connaissent le
protocole T38. C'est apparemment la passerelle entre OVH et Orange qui
prend l'initiative malencontreuse de me faire envoyer ce paquet pour
une raison que j'ignore.

Je voudrais donc voir ce qu'il se passerait si le paquet UDP fautif de
trouble était escamoté silencieusement avant de parvenir à Linphone.

Ce paquet est reconnaissable en ce qu'il comporte une fois la chaîne
de caractères t38 et plusieurs fois T38. Je suppose qu'iptables est
l'outil adéquat mais il serait absurde que je passe des jours à
apprivoiser cette usine à gaz si un aimable contributeur pouvait en
une minute me donner la recette. ;-) Merci d'avance à lui ou elle.



Le patch string devrait convenir pour faire ton test :
<http://www.netfilter.org/documentation/HOWTO/fr/netfilter-extensions-HOWTO-3.html#ss3.18>

Un petit modprobe xt_string avant ou recompiler avec
CONFIG_NETFILTER_XT_MATCH_STRING.

Après, c'est peu être aussi rapide de dire à linphone (que je ne connais
pas) de ne pas utiliser T38.

--
Benoit Izac
Avatar
Geo Cherchetout
Le 13/12/2013 19:05, *Benoit Izac* a écrit fort à propos :

Le patch string devrait convenir pour faire ton test :
<http://www.netfilter.org/documentation/HOWTO/fr/netfilter-extensions-HOWTO-3.html#ss3.18>

Un petit modprobe xt_string avant ou recompiler avec
CONFIG_NETFILTER_XT_MATCH_STRING.



Le module se charge bien à ma demande, voila un truc à ma portée que
j'essaie dès demain. :-)

Après, c'est peu être aussi rapide de dire à linphone (que je ne connais
pas) de ne pas utiliser T38.



Oui mais il faudrait modifier le code et j'en suis bien incapable. J'en ai
parlé sur la liste de discussion des développeurs de Linphone mais sans
aucun écho à ce jour. (Linphone ignore T38 et moi j'ignore pourquoi il
accepte ce genre de requête.)
Avatar
Geo Cherchetout
Le 13/12/2013 19:05, *Benoit Izac* a écrit fort à propos :

Le patch string devrait convenir pour faire ton test :
<http://www.netfilter.org/documentation/HOWTO/fr/netfilter-extensions-HOWTO-3.html#ss3.18>



# iptables -A INPUT -m string --string 't38' -j QUEUE
iptables v1.4.17: string: option "--algo" must be specified

Try `iptables -h' or 'iptables --help' for more information.


# iptables -A INPUT -m string --string 't38' -j DROP
iptables v1.4.17: string: option "--algo" must be specified

Try `iptables -h' or 'iptables --help' for more information.


# iptables -A INPUT -m string --string [!] 't38' -j DROP
Bad argument `t38'
Try `iptables -h' or 'iptables --help' for more information.


Qu'est-ce que je mets pour cette option --algo dont le manuel ne dit rien ?
Avatar
Geo Cherchetout
Le 13/12/2013 21:36, j'ai écrit :

Qu'est-ce que je mets pour cette option --algo dont le manuel ne dit rien ?



Réponse ici : http://spamcleaner.org/fr/misc/w00tw00t.html

Bon, deux arguments sont possibles, bm et kmp et le premier est accepté :

# iptables -A INPUT -m string --string 't38' --algo bm -j DROP


# iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP all -- anywhere anywhere STRING match "t38" ALGO name bm
TO 65535

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination


Me voila paré pour quelques essais.
Avatar
Benoit Izac
Bonjour,

le 13/12/2013 à 21:36, Geo Cherchetout a écrit dans le message
<l8fr4u$59s$ :

Le patch string devrait convenir pour faire ton test :
<http://www.netfilter.org/documentation/HOWTO/fr/netfilter-extensions-HOWTO-3.html#ss3.18>



# iptables -A INPUT -m string --string 't38' -j QUEUE
iptables v1.4.17: string: option "--algo" must be specified

Try `iptables -h' or 'iptables --help' for more information.


# iptables -A INPUT -m string --string 't38' -j DROP
iptables v1.4.17: string: option "--algo" must be specified

Try `iptables -h' or 'iptables --help' for more information.


# iptables -A INPUT -m string --string [!] 't38' -j DROP
Bad argument `t38'
Try `iptables -h' or 'iptables --help' for more information.


Qu'est-ce que je mets pour cette option --algo dont le manuel ne dit rien ?



Tu cherches au mauvais endroit, les extensions sont documentées dans
iptables-extensions(8) :

--algo {bm|kmp}
Select the pattern matching strategy. (bm = Boyer-Moore, kmp Knuth-Pratt-Morris)

<http://fr.wikipedia.org/wiki/Algorithme_de_Boyer-Moore>
<http://fr.wikipedia.org/wiki/Algorithme_de_Knuth-Morris-Pratt>

--
Benoit Izac
Avatar
Geo Cherchetout
Le 13/12/2013 23:20, *Benoit Izac* a écrit fort à propos :

Tu cherches au mauvais endroit, les extensions sont documentées dans
iptables-extensions(8) :



OK, merci.
Avatar
Pascal Hambourg
Salut,

Geo Cherchetout a écrit :

# iptables -A INPUT -m string --string 't38' --algo bm -j DROP



C'est un peu large. Par exemple cette règle risque d'empêcher la
réception de ce message en bloquant le segment qui contient 't38'.
Il faudrait affiner en ajoutant le protocole UDP et les ports 5060:5061,
voire l'adresse source de la passerelle SIP.
1 2 3