jeudi 17 novembre 2011

Vote électronique: Critique, Réponses, Coïncidences

La Critique

  Le jeudi 20 octobre 2011, le journal 24 heures publiait en courrier des lecteurs (page 26) une lettre signée de "P. Santschi, ancien député au grand conseil et ancien directeur du centre de calcul de l'EPFL". M. Santschi y évoque un système de vote électronique développé au sein du canton de Genève, et mentionne l'absence de garantie cryptographique du secret de vote. Il fait également référence a l'affaire des chevaux de troie utilisés sans cadre légal précis par la police pour traquer la criminalité en ligne. Il évoque, mais sans les préciser, les dangers posés par la combinaison de ces deux technologies.

 Ces dangers méritent un éclaircissement. L'opposition à l'utilisation des chevaux de troie ne se justifie pas, comme certains voudraient le faire croire, par un désir de préserver la vie privée. Elle provient d'une part de l'absence d'un cadre légal clair qui devrait être de mise, comme il en est pour les autres prérogatives des services de police; et d'autre de considérations purement techniques liés a la qualité douteuse des logiciels utilisés.

Il a en effet été révélé que le cheval de troie utilisé par la police allemande, insuffisamment sécurisé, laissait les ordinateurs ouverts a l'abus de tous. Imaginez qu'un enquêteur de police, plutôt que de procéder a la fouille du domicile d'un suspect, fracture systématiquement toutes les serrures et les laisse en l'état, pour faciliter les fouilles ultérieures. Imaginez qu'un cambrioleur en profite pour entrer dans ce domicile, y voler tous les objets de valeur, et y cacher son stock de drogue. Y voyez-vous un problème ?

L'observation de M. Santschi soulève donc un problème intéressant et souligne l'importance de la création de bases légales claires, et d'une assurance sur la qualité des outils utilisés par les enquêteurs.

La remarque concernant le non respect du secret de vote est un problème à part, et qui mériterait un article en lui-même.

Les Réponse

Suite à cette lettre, le 24 heures publie, le 31 octobre 2011, toujours dans son courrier des lecteurs (page 27) trois réponses à la lettre de M. Santschi.

Le site de 24 heures ne répond pas, mais les réponses sont encore dans le cache de google:

http://webcache.googleusercontent.com/search?q=cache:KoOBKA6nVsoJ:archives.24heures.ch/VQ/LAUSANNE/-/article-2011-10-3706/a-propos-de-la-lettre-de-lecteur-de-m+claude+bonard+ours+vaudois&hl=fr&client=firefox-a&gl=ch&strip=1

La première, signée Sonia Lardi, de Genthod, titrée "Difficile de le prendre au sérieux", rejette la critique de M. Santschi sur l'absence de secret de vote. A juste titre, Mme Lardi rappelle que les méthodes de vote papier dépendent aussi de la confiance envers l'administration, et qu'il n'y a pas lieu de critiquer un vote électronique qui offre une sécurité aussi bonne que le vote traditionnel.

Cet argument est incomplet, car il ne prend en considération que le risque d'une action malveillante de la part d'un agent de l'administration, sans considérer la portée de ce risque. Or en gestion du risque, il est nécessaire de quantifier ces deux aspects. La portée d'une action malveillante est beaucoup plus grande avec le vote électronique: si des scrutateurs entrent en collusion pendant le dépouillement pour modifier le compte des bulletins, ils pourront au pire falsifier les résultats d'une circonscription, sans compter le risque d'une recompte. Un informaticien malveillant ayant le contrôle total du système pourra, lui, aisément altérer le vote entier. Il est donc faux de comparer ainsi la sécurité du vote électronique et du vote traditionnel: il est normal d'exiger d'un vote électronique, dont les conséquences sont beaucoup plus graves en cas de faille, une réduction du risque d'attaque, tout comme on doit soumettre (en théorie) les centrales nucléaires à des controles techniques plus stricts que ceux d'une chaudière individuelle.

Si Mme Lardi se fourvoie dans son raisonnement, elle a au moins le mérite d'apporter un argument concret a l'encontre de la lettre de M. Santschi. Ce n'est pas le cas des deux suivants.

La deuxième lettre est signée Claude Bonard, de Vernier. Celle-ci met les griefs de M. Santschi envers le système de vote genevois sur le compte d'une rivalité entre cantons, sans plus argumenter.

La troisième, signée Michel Chevallier, de Mies, intitulé "Quelle bêtise !", reproche à M. Santschi de décrédibiliser l'EPFL et le Conseil National en signant de ces titres ce que M. Chevallier considère comme, je cite, "une ânerie pareille", là encore sans argumenter,.


Les Coïncidences

Cette troisième lettre m'a interpellé parce que le nom de son auteur ne m'est pas inconnu. En effet, l'article du Flash Informatique de Juin 2011 (http://flashinformatique.epfl.ch/spip.php?article2314) qui décrit l'architecture du système de vote genevois, est signé du même nom. Coïncidence ?

(Au passage, mon avis personnel, en tant qu'ingénieur diplômé EPF et candidat doctoral en cryptographie, est que ce design présente plusieurs erreurs grossières: transmission de la partie privée d'une clef asymétrique sur le réseau, création d'une table pour inverser un hash, utilisation redondante de chiffrement, et mixage inopérant) Espérons que les schémas présentés soient faux et ne soient pas le reflet du fonctionnement actuel du système.)

Une recherche sur internet nous apprend qu'une Mme Sonia Lardi a travaillé auprès de la Chancellerie d'Etat. On apprend également qu'un Claude Bonard aurait occupé le poste de secrétaire général de la Chancellerie d'Etat de 2000 à 2010.

Coïncidences ?

jeudi 27 octobre 2011

Failover IP sur une VM en proxy-arp

Le proxy-arp est une technique intéressante qui permet de se passer d'un bridge lorsqu'on héberge des machines virtuelles. Elle empêche également l'admin de la VM de voler des addresses dans le subnet local comme c'est le cas avec un bridge. Cepandant, attention à cette intéraction néfaste avec le failover IP...

Avec une VM bridgée classique, l'hôte établit un pont entre l'interface réseau physique et les interfaces réseau virtuelles. Les requêtes ARP sur le subnet local sont transmises à toutes les VM, et chaque VM décide ou non d'y répondre, sans contrôle de l'hôte (bien sur on peut utiliser ebtables pour filtrer)

Au lieu d'utiliser des interfaces virtuelles de type ethernet, on peut également utiliser des liens point-à-point virtuels. Côté VM, l'interface a donc une addresse unique /32, et une addresse p2p fixe (typiquement 10.64.64.64) qui sert de passerelle par défaut. Côté hôte, pas de problème pour avoir une addresse unique sur plusieurs interfaces, parce que les interfaces sont point-à-point, il n'y a donc pas d'ambiguité sur la source. Mais dans cette configuration, comment le routeur du subnet local sait-il qu'il doit addresser les paquets a destination des VM sur l'addresse de l'hôte ?

En activant le proxy-arp sur l'interface physique de l'hôte, l'hôte répondra en arp pour toutes les addresses qu'il est capable de router. Il suffit donc d'ajouter une route statique vers le bon tunnel point-a-point pour chaque VM. C'est ce que fait, d'ailleurs, le script fourni avec openvz pour la gestion des addresses des VMs.

Mais que se passe-il si, par mégarde, une VM vient a déconfigurer une addresse qui lui a été allouée, sans en avertir l'hôte ?

La route statique étant en place, l'hôte va continuer a router les paquets à destination de cette addresse vers le tunnel. Et si le guest a le forwarding activé, il va joyeusement transmettre les même paquets à sa passerelle par défaut, dans le même tunnel, dans l'autre sens.

Chez moi, ça se traduit par un load average de 12, ksoftirqd qui prend 60% du cpu, et 5 secondes de latence entre chaque caractère tapé en ssh.

En bridge, ça marche mieux...

samedi 8 octobre 2011

Tutorial: un VPN ipv6 pour la maison, sous Gentoo

Voici comment se fournir un bloc IPv6 statique a domicile, a partir d'un serveur ayant une addresse v4 stable, avec 6to4 et OpenVPN.


Mes machines, toutes deux sous Gentoo:
* Xolus: serveur housé avec une IP statique sur eth0
* Glokrik: serveur de la maison, IP NAT sur eth0


6to4


La configuration de 6to4 est facile avec Gentoo. J'ajoute dans /etc/conf.d/net sur xolus:



link_6to4="eth0"
config_6to4="ip6to4"
depend_6to4() { need net.eth0 }


Et je crée le service correspondant:



ln -s net.lo /etc/init.d/net.6to4
rc-update add net.6to4 default
rc


Et on teste:



ping6 www.kame.net


OpenVPN


On emerge openvpn sur les deux machines, et on commence par créer les clefs cryptographiques nécessaires. Pour deux machines les clefs statiques sont plus simples, mais dans l'hypothèse d'un ajout ultérieur de machines je vais utiliser une PKI. Il y a des scripts d'aide dans /usr/share/openssl/easy-rsa/. On copie ce répertoire vers un rep de travail.


On y édite le fichier vars et on ajuste les champs des dernières lignes. Puis on source ce fichier et on génère la CA et les clefs des serveurs:



. ./vars
./clean-all
./build-ca
./build-key-server xolus
./build-key glokrik
./build-dh


On viole techniquement un principe des PKI en générant les clefs client sur le serveur, mais bon ;)


Sur xolus, je copie ca.crt, dh1024.pem, xolus.crt et xolus.key dans /etc/openvpn/. Je transfère ensuite ca.crt, glokrik.key et glokrik.pem au meme endroit sur la machine glokrik.


Sur xolus, je crée la définition suivante dans /etc/openvpn/openvpn.conf:



port 1194
proto udp
dev openvpn
dev-type tun
tun-ipv6
tls-server
ca ca.crt
cert xolus.crt
key xolus.key
dh dh1024.pem


Sur glokrik, dans /etc/openvpn/xolus.conf:



port 1194
proto udp
remote 213.162.22.228
dev xolus
dev-type tun
tun-ipv6
tls-client
ca ca.crt
cert glokrik.crt
key glokrik.key


On ajoute les services openvpn au démarrage. Les machines disposent maintenant chacune d'une interface réseau tunnel supplémentaire, qu'il faut maintenant configurer


On vérifie sur les deux machines, avec ip link show, que les deux interfaces sont actives (flag LOWER_UP).


Tunnel IPv6


On commence par calculer le bloc 6to4 à disposition. L'IP fixe de ma machine est 213.162.22.228, mon bloc 6to4 est donc 2002:d5a2:16e4::/48. (Prefixe 2002, suivi de l'addresse v4 convertie en hexadécimal). Il y a ensuite 16 bits disponibles pour le subnet, je vais utiliser 00ff pour le VPN, et 0001 pour le subnet de ma maison. Dans le subnet vpn, l'addresse ::ff sera attribuée au serveur, et l'addresse ::xxxx au client responsable du subnet xxxx.


Sur xolus, dans /etc/conf.d/net:



config_openvpn=( "2002:d5a2:16e4:ff::ff/64" )
routes_openvpn=( "2002:d5a2:16e4:1::/64 via 2002:d5a2:16e4:ff::1" )
depend_openvpn() {
need openvpn
}


Sur glokrik:



config_xolus=( "2002:d5a2:16e4:ff::1/64" )
routes_xolus=( "2000::/3 via 2002:d5a2:16e4:ff::ff" )
depend_xolus() {
need openvpn.xolus
}


On ajoute ces deux services au démarrage, on les lance, et on teste le fonctionnement du tunnel:



glokrik # ping6 2002:d5a2:16e4:ff::ff
PING gw.vpn.xolus.net(2002:d5a2:16e4:ff::ff) 56 data bytes
64 bytes from 2002:d5a2:16e4:ff::ff: icmpseq=1 ttl=64 time=8.54 ms
64 bytes from 2002:d5a2:16e4:ff::ff: icmp
seq=2 ttl=64 time=8.11 ms


On active ensuite le forwarding sur la passerelle:



echo "net.ipv6.conf.all.forwarding = 1" >>/etc/sysctl.conf
sysctl -p


Glokrik peut maintenant pinguer des sites ipv6 publics:



glokrik # ping6 www.kame.net
PING www.kame.net(2001:200:dff:fff1:216:3eff:feb1:44d7) 56 data bytes
64 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7: icmp_seq=1 ttl=58 time=340 ms


RADVD


Il faut maintenant fournir la connectivité ipv6 aux hôtes de la maison. Pour celà il suffit d'installer radvd sur glokrik, et d'y ajouter la conf qui va bien dans /etc/radvd.conf_



interface eth0 {
AdvSendAdvert on;
prefix 2002:d5a2:16e4:1::1/64 {
AdvOnLink on;
AdvAutonomous on;
};
};


On édite ensuite le script de démarrage /etc/init.d/radvd pour changer la dépendance:



depend() {
need net.xolus
}


Ce qui empêche radvd de démarrer tant que le lien vpn n'est pas up.


Notez qu'il n'y a pas besoin d'activer le forwarding ipv6 sur glokrik, le script de démarrage de radvd s'en charge.


radvd démarré, ma machine de bureau reçoit presque immédiatement une addrese v6, et je peux pinguer des sites publics.


6to4reverse


Une fois la connexion 6to4 active, il suffit d'aller sur https://6to4.nro.net et d'enregistrer ses serveurs de noms pour disposer du reverse.

mercredi 5 octobre 2011

Une conférence avec Michel Riguidel

  J'ai eu le plaisir, cet après-midi, d'assister à une conférence ayant pour thème les dangers et futurs enjeux de la guerre électronique. Parmi les invités, un certain Michel Riguidel, dont le nom m'est alors inconnu, cité comme "conseiller pour le gouvernement français" en matière de cybersécurité, et auteur de plusieurs  brevets liés a la sécurité.

  Dès la première slide, bien remplie de texte, on comprend que la présentation sera technique et concrète, loin des généralités banales du conférencier précédent. Je m'en réjouis.

 Pas pour longtemps, hélas.

  Je vais immédiatement mentionner le SEUL point de son discours avec lequel je me trouve en accord: les géants comme Facebook présentent un danger significatif pour la vie privée (pour M. Riguidel, un tel pouvoir est une prérogative d'état.)

M. Rigidel accumule dans son discours tellement de "WTF"s et d'apparentes inepties que je n'ai la présence d'esprit de tous les noter. Ce dont je me rappelle, en vrac:

- TCP/IP est complètement obsolète (je suis d'accord pour TCP, mais avec LTE et les futurs réseaux téléphoniques tout IP, on peut se poser la question)
 - la liberté sur Internet conduira au nivellement par le bas de la culture (LOL)
 - PGP est une catastrope politique (LOL)
 - Le chiffrement ne sert qu'aux entreprises désirant narguer le gouvernement en l'empêchant de surveiller ses flux (parce que le gouvernement est incapable d'obtenir une clef de chiffrement par des moyens non-techniques, le citoyen doit renoncer au chiffrement même si cela l'expose aux abus de son ISP ou d'un fournisseur de cloud)
 - Cloud et P2P sont des technologies opposées, et populairs par effet de mode mais de nature éphémère.
 - L'anonymat sur internet est une catastrophe, des personnalités (dont lui-même) se font diffamer sans aucun contrôle (Effet Streisand, il ne connaît pas ?)
 - Les "hippies" soutenant le libre sont une minorité de hackers marginaux dont le travail n'est bénéfique que très occasionnellement (il ne doit pas être au courant de la représentation de Linux dans le top500, tiens).
 - Internet est tellement centralisé qu'il se résume aujourd'hui a 300 serveurs
 - Puisque la loi de Moore s'est arrêtée en 2008, et comme il est impossible de scaler un système a plus de 4 processeurs, l'arrêt brutal de la performance amènera un "crépuscule numérique". (Larrabee ça n'existe pas)
 - L'informatique sera obsolète en 2100 et remplacée par la nanotechnologie.
 - Le progrès cryptographique en occident est arrêté depuis 10 ans et les chinois sont largement en avance sur l'europe ou les états-unis.

  Ces positions déraisonnables relèvent au mieux de l'incompétence, au pire d'une totale malhonnêteté intellectuelle. Je me demande si M. Riguidel croit vraiment à ce qu'il raconte, ou s'il déforme volontairement la réalité pour pousser un agenda politique.

  Pour le dernier point de la liste, je me suis fendu d'une question simple: pourquoi, si la chine est tellement en avance en matière de crypto, les universités chinoises représentent moins de 20% des publications soumises à Asiacrypt 2011 ? réponse de M. Riguidel: "ah mais dans ces conférences le jury est pipé de toute façon." Ben voyons. Et d'étayer son raisonnement par le fait que Xiaoyun Wang, d'origine chinoise, est l'auteure de plusieurs papiers sur des collisions de hachage. Je n'ai pas eu le coeur de lui rappeler qui est a l'origine des collisions sur certificats x509, ou de la factorisation de RSA-768, ou des milliers d'autres problèmes actuels en crypto. Mais bon.

  J'ai pu ainsi me faire, par moi-même, une opinion assez claire du personnage. Mais je suis quand meme allé voir sur google, histoire de voir de quelle "diffamation" il parlait. Je constate que S. Bortzmeyer, personnage avec qui j'ai eu le plaisir de discuter occasionnellement sur IRC, et dont je respecte hautement les compétences techniques, le qualifie ni plus ni moins de "Bogdanoff du net". Même son de cloche auprès de mes autres connaissances au sein du FrNOG.

  Je suis ébahi que l'UNIL offre une telle tribune à ce personnage, qui se permet de prendre position avec une arrogance incroyable sur des sujets sur lesquels le consensus est quasi universel au sein de la communauté scientifique, et sans offrir aucune démonstration ou justification à ses propos. Ebahi et un peu dégoûté.

  Dieu merci, les intervenants qui lui ont succédé ont fait preuve de raison et de pragmatisme, sans quoi je serais certainement parti avant la fin.

mardi 4 octobre 2011

Tuning NFS pour démarrer un cluster

  Le cluster AMD64 du LACAL comporte 90 noeuds, pour l'instant tous servis depuis un frontend unique qui héberge leurs racines NFS. En cas de coupure, si tous les noeuds redémarrent en même temps, le serveur NFS se retrouve légèrement surchargé, et plusieurs noeuds se retrouvent dans un état bloqué (kernel panic).

  Une partie des noeuds ne dispose ni de contrôleur IPMI ni de watchdog, ce qui rend les redémarrages un peu chaotiques. Mais la situation peut être grandement améliorée par trois règlages:

1) Augmenter le nombre de processus pour le démon nfsd. Avec Gentoo ceci se règle par la variable OPTS_RPC_NFSD dans /etc/conf.d/nfsd

2) Utiliser le port 627 pour le démon mountd (même fichier, variable OPTS_RPC_MOUNTD). C'est le port spécifié n dur dans le noyau au cas ou le portmapper serait trop lent a répondre.

3) Augmenter la tolérance du client nfs, en passant l'option adéquate au noyau. Ici, dans la config pxelinux de chaque machine:

  append root=/dev/nfs nfsroot=10.1.0.2:/var/nfs/nodexx,retrans=10,timeo=30

lundi 26 septembre 2011

Software CPU Upgrade

Q: What to do when an annoying customer insists that he wants a CPU from a different brand on his Linux dedicated server ?
A: This: http://bitbucket.org/maugier/cpufake

Dégoûter les démarcheurs téléphoniques avec Asterisk

Les démarcheurs téléphoniques, c'est chiant. Débarassons-nous en avec Aterisk. Au menu: un menu vocal horripilant, et un raccrochage dans la face au bout de quelques minutes.

D'abord, le matériel: un petit serveur de récup', déja allumé en permanence pour les diverses tâches de la maison. J'y ajoute une interface téléphonique analogique, une A400P de chez OpenVox, avec un module FXO (pour y brancher la ligne téléphonique) et un module FXS (pour y brancher mon ancien téléphone). J'intercale donc mon PBX entre mon téléphone et ma ligne.

Le serveur est sous Gentoo, j'y installe Asterisk 1.8 ainsi que le driver DAHDI. J'ajoute le module wctdm dans /etc/modules.autoload.d/kernel-2.6.

Il faut ensuite générer la config du driver avec dahdi_genconf, vérifier que les modules FXO et FXS sont bien détectés. Voici le contenu auto-généré de /etc/asterisk/dahdi.channels.conf:

;;; line="1 WCTDM/4/0 FXSKS"
signalling=fxs_ks
callerid=asreceived
context=sunrise
channel => 1

;;; line="2 WCTDM/4/1 FXOKS"
signalling=fxo_ks
callerid="Maison" <1>
context=maison
channel => 2

Notez que la terminologie est inversée pour le signaling: le module FXO, qui se comporte comme un téléphone, utilise le signaling FXS (car il cause avec la ligne FXS de mon fournisseur) alors que le module FXS, qui cause à mon téléphone, utilise le signaling FXO pour parler a mon téléphone FXO)

A ce stade on peut lancer Asterisk avec le script système, et attacher la console avec

glokrik # asterisk -r
...
=========================================================================
Connected to Asterisk 1.8.5.0 currently running on glokrik (pid = 31554)
glokrik*CLI>

On teste en passant un appel bidon, d'abord vers le téléphone (la ligne 2)

glokrik*CLI> originate DAHDI/2 application sayphonetic ABCDEF

Le téléphone sonne, parle quand on décroche, puis raccroche, youpie.

On teste un appel sur la ligne sortante:

glokrik*CLI> originate DAHDI/1/076xxxxxxx application sayphonetic ABCDEF

Cette fois-ci j'ai un petit bug, Asterisk ne détecte pas correctement le décrochage de la ligne et envoie le message immédiatement. A investiguer, mais sans conséquence pour ce que nous voulons faire.

Premièrement, rendons le PBX transparent en lui permettant de passer des appels entrants et sortants vers et depuis le combiné de la ligne 2. J'ajoute dans /etc/asterisk/extensions.conf

[maison]
exten => _X.,1,Dial(DAHDI/1/${EXTEN})
exten => _X.,2,Hangup()

[sunrise]
exten => s,1,Dial(DAHDI/2&SIP/monpc)
exten => s,2,Hangup()

Au passage, je fais un tour dans sip.conf et y ajoute un compte pour mon PC, que je nomme monpc, dans le contexte maison; mon PC peut maintenant passer des appels sortants. Notez la définition dans le contexte sunrise qui fait également sonner mon pc quand un appel entrant arrive (le premier qui décroche prend l'appel.)

Maintenant, la partie rigolote: enregistrons un menu vocal idiot. J'utilise Asterisk pour me lancer des appels sur le pc et m'enregistrer:

glokrik*CLI> originate SIP/monpc application record torture-main.gsm

Je décroche, et récite trèèèèès lentement, en me pincant le nez, et de manière générale avec une voix stupide: "Bonjour, vous êtes bien chez XXXXXX, meeeerci de choisir une des options suivantes: si vous appelez dans le contexte de blablabla, appuuuuuyez sur 1,..."

Asterisk enregistre ceci dans le fichier torture-main.gsm. Je procède de la même manière pour enregistrer chaque message, avec torture-submenu1.gsm, torture-submenu2.gsm, ..

J'ajoute maintenant dans extensions.conf le contexte [torture] dans lequel je perds les indésirables:


[torture]
exten => s,1,Background(torture-main)
exten => s,2,Goto(torture,s,1)
exten => 1,1,Goto(torture-submenu1)
exten => 2,1,Goto(torture-submenu2)

[torture-submenu1]
exten => s,1,Background(torture-submenu1)
exten => s,2,Goto(torture,s,1)
exten => 1,1,Goto(torture-sub-sub1)
exten => 2,1,Goto(torture-sub-sub2)

etc etc...

Note le Goto(torture,s,1) à la fin de chaque s de chaque contexte; si l'utilisateur attend la fin du message, il retourne a la racine du menu. Oui, il faut être rapide !

A la fin de la farce, en divers endroits, un Hangup() se débarasse purement et simplement de l'individu.

Notre contexte torture défini, reste à y envoyer les télémarketeurs. Commençons par une blacklist statique. On modifie le contexte de la ligne entrante:

 
[sunrise]
exten => s/_00494542801.,1,Goto(torture,s,1)
exten => s,1,Dial(DAHDI/2&SIP/monpc)
exten => s,2,Hangup()

Ce qui a pour effet d'envoyer tous les numéros commençant par le préfixe mentionné (qui appartient, je crois, à un institut de sondage) vers le menu insupportable.

Ajoutons maintenant une redirection dynamique, pour ceci je vais utiliser une featuremap.
Je modifie encore le contexte entrant:

[sunrise]
exten => s,1,Set(DYNAMIC_FEATURES=torture)
exten => s/_00494542801.,2,Goto(torture,s,1)
exten => s,2,Dial(DAHDI/2&SIP/monpc)
exten => s,3,Hangup()

Et j'ajoute dans /etc/asterisk/features.conf, dans la section [applicationmap], la ligne suivante:

torture => *,self/callee,ChannelRedirect(DAHDI/1-1,torture,s,1)

Qui a pour effet de rediriger l'appel de la ligne extérieure, la ligne 1, vers le contexte cible. "callee" indique que seul le destinataire (donc mon téléphone local) peut utiliser la fonction.

Et voila, il me suffit donc d'appuyer sur * pendant un appel, pour me débarasser du télémarketeur intempestif.