À l'unanimité, les députés ont adopté mercredi soir les deux propositions de loi portées par Fanny Dombre-Coste (PS). L'enjeu ? Imposer aux candidats à une élection, comme c'est déjà le cas pour des centaines de métiers aujourd'hui, d'avoir un casier judiciaire "vierge". Sont concernées toutes les personnes condamnées pour infractions criminelles, manquements à la probité, fraude fiscale ou électorale, et violences sexuelles.

[...]

Le calendrier parlementaire très serré laisse peu d'espoir que cela arrive avant la fin des travaux du parlement, fin février. Ce sera donc à la prochaine vague de parlementaires de reprendre - ou non- à son compte, cette réforme...

La liste des infractions qui conduisent à l'inéligibilité me semble plutôt complète : toutes les infractions criminelles, fraude fiscale ou électorale, harcèlement et agression sexuelle, corruption, recel, blanchiment , trafic d'influence, etc.

Je vois plein de limites à cette zolie déclaration de principe :

• Quid des conseils municipaux, des conseils départementaux et des conseils régionaux ? La loi vise uniquement les déput-é-s, sénateur-rice-s et le-a président-e de la République.
  
  
• Ça ne s'appliquera pas aux personnes non-élu-e-s qui, pourtant, vivent et/ou manipulent de l'argent public. Ce n'est pas normal. Or, ces personnes-là seront utilisées/instrumentalisées par leur boss élu-e pour servir de fusible et lala le contournement facile. Ce n'est pas sain.
  
  
• Ce n'est que de la poudre aux yeux : une loi vise déjà les fonctionnaires (et d'autres professions) et pourtant, combien de hauts-fonctionnaires ont un casier et sont entrés quand même par copinage & compagnie ?! La vraie question est : qui veillera à l'application de cette loi ? D'après la proposition de loi, il s'agit du Conseil constitutionnel pour l'élection présidentielle (et rien n'est explicité pour les autres élections). En a-t-il les moyens, les capacités et l'envie ? Qui pourra/voudra aller en justice pour la faire appliquer ?
  
  
• Quid des condamnations sans inscription au casier comme celle de Lagarde dans l'affaire Tapie/Crédit Lyonnais ? Attention : un droit à l'oubli, qui découle de l'effacement à terme du casier est légitime àmha et ces propositions de lois ne changent pas ce mécanisme. D'une manière générale, quid des politocards magouilleurs qui échappent à la justice depuis des 10aines d'années ?

Via https://twitter.com/bluetouff/status/827159501295984640

Je me mets ça de côté parce que j'en ai marre de le retrouver de tête à chaque fois (et d'oublier des règles à chaque fois) :

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 134 -m comment --comment RA -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 135 -m comment --comment NS -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 136 -m comment --comment NA -j ACCEPT
-A INPUT -p udp --sport 546 --dport 547 -m comment --comment DHCPv6 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 128 -m comment --comment ping6 -j ACCEPT
COMMIT

Un jeu de règles de filtrage minimaliste pour IPv6, au format ip6tables-save (restaurable au boot avec netfilter-persistent).

Il est nécessaire d'autoriser les messages ICMPv6 Router Advertisement (RA) afin de prendre connaissance du ou des routeurs de sortie du réseau car cette information n'est plus distribuée via DHCP comme c'était le cas en IPv4.

Il est nécessaire d'autoriser les messages ICMPv6 Neighbor Solicitation (NS) afin de répondre aux demandes de résolution IP->MAC d'une de nos adresses IPv6, prérequis à tout échange réseau. Équivalent d'une requête ARP en IPv4.

Il est nécessaire d'autoriser les messages ICMPv6 Neighbor Advertisement (NA), qui sont les réponses aux NS afin de :

• Gérer les cas de redondance VRRP/CARP du routeur de sortie. Lors d'un basculement d'un routeur physique à un autre, il y aura émission de messages NA non sollicités donc sans état dans Netfilter donc qui ne passeront pas la première règle du jeu de règles ci-dessus ;

• Gérer le cache des associations MAC<->IPv6. En effet, pour établir une communication vers l'extérieur, il y aura un échange (RS-)RA afin de prendre connaissance des routeurs de sortie. L'adresse locale au lien et la MAC du routeur de sortie sont incluses dans le message RA. L'information sera mise en cache sur ta machine. Le cache expire. Ta machine enverra des messages NS afin de prendre connaissance de la MAC du routeur. Le routeur répondra. Ces messages RA ne sont pas reconnus/attrapés/mappés par Netfilter comme faisant partie d'une communication déjà établie ou relative à une communication déjà établie (probablement car les IP source et destination ne correspondent pas entre la question et la réponse à cause de l'utilisation du multicast et qu'il ne semble ne rien y avoir d'autre dans ICMPv6 pour créer un état) donc ils n'entreront pas sur notre machine via la première règle du jeu de règles ci-dessus. Donc la communication sera interrompue pendant plusieurs 10aines de secondes… … … jusqu'à ce que le routeur de sortie, ayant son cache qui expire, n'émette un NS (qui est autorisé à entrer sur notre machine par notre 4e règle de filtrage) qui permettra de renouveler notre cache (puisqu'il y a IP source et MAC source du routeur dans ce message ICMPv6 ;) ), permettant ainsi à la communication de reprendre jusqu'à la prochaine expiration et ainsi de suite.

  • Ces coupures imprévisibles et récurrentes peuvent faire croire à une perte de paquets quelque part sur le réseau alors qu'il n'en est rien ! Quelques éléments pour identifier ce problème de configuration du pare-feu : 1) un ping6 retourne un message de la forme « From icmp_seq=1 Destination unreachable: Address unreachable » ; 2) une capture réseau montrera une très forte proportion de message NS-NA entre ta machine et le routeur ; 3) un watch ip -6 n sh montrera un cycle anormal du cache MAC<->IPv6 c'est-à-dire beaucoup de longs passages par les états « INCOMPLETE », « FAILED » et « PROBE ».

Autoriser DHCPv6 permet de récupérer des informations complémentaires (serveurs DNS récursifs suggérés, serveurs NTP suggérés, etc.) aux RA sur les réseaux qui sont équipés d'un serveur DHCPv6.

Soit un réseau informatique sur lequel nous n'avons pas la main, nous sommes juste root sur une machine (que nous nommerons sonde ci-dessous) dans ce réseau.

En IPv4, aucun problème : on peut ping/traceroute/mtr. En IPv6, c'est plus compliqué : un ICMPv6 echo-request arrive à destination mais l'echo-reply n'arrive jamais jusqu'à la machine sondeuse. traceroute et mtr ne fonctionnent pas du tout dans le sens où aucun nœud réseau n'apparaît alors que les paquets sondeurs sortent pourtant bien de la machine. Aucun paquet ne parvient à la destination.

Plus étrange, un ssh -6 -p 22, un telnet -6 22 et un nmap -6 -p 22 fonctionnent, la machine qui sonde obtient bien un SYN-ACK. En revanche, un mtr -6 -T -P 22 ne fonctionne pas. Les paquets sont perdus sur le réseau et n'arrivent jamais à destination.

Les ports source sont identiques dans les deux cas : pris au pif dans la plage des ports éphémères.

Blusky m'a indiqué que cela pouvait être dû à une protection contre les scans de ports silencieux (nmap -sS), c'est-à-dire un scan qui contourne la poignée de main TCP : nmap envoie un SYN, la destination répond l'habituel SYN-ACK et la pile TCP de la sonde répond RST au lieu du drapeau ACK, ce qui montre que cette connexion n'était vraiment pas sérieuse donc scan "silencieux". Un scan "normal" (nmap -sT) est le défaut de nmap s'il n'est pas exécuté en root, sinon un scan silencieux sera réalisé. Certaines protections réseaux peuvent détecter les scans silencieux et les bloquer. Un tel blocage se détecte facilement : les premiers paquets passent puis, ho, pouf, plus rien. Or, dans mon cas, aucun paquet, même pas les premiers, ne parviennent à destination. De plus, nmap -sT -p 22 et nmap -sS -p 22 produisent le même résultat. Il ne s'agit donc pas de cela.

En comparant les paquets IP capturés avec Wireshark, je me dis que l'une des différences entre un traceroute/mtr et un ssh/telnet/nmap est le hop limit (le nom IPv6 du TTL IPv4). Il est positionné à au moins 64 pour ssh/telnet/nmap alors qu'il est positionné à 1 puis 2 puis 3 puis 4 puis… par traceroute/mtr dans l'optique que les routeurs renvoient des messages ICMPv6 « Time Exceeded » et dévoilant ainsi qu'ils sont sur le chemin de la communication. Pour tester cette hypothèse : ping6 -t 5 : rien n'arrive à destination. ping6 -t 10 : rien n'arrive à destination : ping6 -t 15 : hooo, les echo-request arrivent à destination !

On peut aussi mettre cela en évidence avec Scapy :

#!/usr/bin/python
#coding=utf-8

from scapy.all import *
import random

monPaquet = IPv6(dst="2a00:5881:8110:1000::1", hlim=15) / TCP(dport=22, flags="S")
monPaquet.payload.sport = random.randint(32768,61000)

send(monPaquet, verbose=0)

En faisant varier le hlim, on met clairement en évidence un filtrage basé sur le hop limit.

J'ignorais que des admins infos s'ennuyaient au point d'avoir le temps de mettre en place ce genre de craderies, et uniquement en IPv6. :(