Suport technique et veille technologique
Aujourd’hui, les grandes entreprises et administrations publiques hésitent entre continuer à utiliser des logiciels propriétaires ou basculer vers les Logiciels Libres. Pourtant, la plupart des logiciels libres sont capables de bien traiter les données issues des logiciels propriétaire, et parfois avec une meilleur compatibilité.
C’est alors la barrière de la prise en main qui fait peur, et pourtant...
Les logiciels libres
L’aspect « Logiciel Libre » permet une évolution rapide et une plus grande participation des utilisateurs. Les aides et tutoriels foisonnent sur Internet ou sont directement inclus dans le logiciel lui-même.
Enfin, les concepteurs sont plus proches des utilisateurs, ce qui rend les logiciels libres plus agréable à utiliser et conviviaux.
Grâce à la disponibilité des logiciels libres, vous trouverez facilement des services de support techniques et la licence n’est plus un frein à l’utilisation de ces logiciels par votre personnel.
Notre support technique concerne essentiellement les logiciels libres, que ce soit sous forme de services ponctuels ou de tutoriels.
- Janvier 2017 -
C'est quoi, un « fragment atomique » ? Décrits dans le RFC 6946, ces charmants objets sont des
datagrammes IPv6 qui
sont des fragments... sans en être. Ils ont un en-tête de fragmentation sans
être fragmentés du tout. Ce RFC estime qu'ils ne
servent à rien, et sont dangereux, et devraient donc ne plus être
générés.
Le mécanisme de fragmentation
d'IPv6 (assez différent de celui
d'IPv4) est décrit dans le RFC 2460, sections 4.5 et 5. Que se passe-t-il si un
routeur génère un message
ICMP Packet Too Big
(RFC 4443, section 3.2) en indiquant une
MTU inférieure à 1 280
octets, qui est normalement la MTU minimale d'IPv6 ? (Le plus
beau, c'est que ce routeur n'est pas forcément en tort, cf. RFC 6145, qui décrivait leur utilisation pour être
sûr d'avoir un identificateur de datagramme.) Eh bien, dans ce cas, l'émetteur du
datagramme trop gros doit mettre un en-tête « Fragmentation » dans
les datagrammes suivants, même s'il ne réduit pas sa MTU en
dessous de 1 280 octets. Ce sont ces datagrammes portant un
en-tête « Fragmentation » mais pas réellement fragmentés (leur bit
M est à 0), qui sont
les fragments atomiques du RFC 6946.
Malheureusement, ces fragments atomiques permettent des
attaques contre les machines IPv6 (section 2 du RFC). Il existe
des attaques liées à la fragmentation (RFC 6274 et RFC 7739). Certaines
nécessitent que les datagrammes soient réellement fragmentés mais
ce n'est pas le cas de toutes : il y en a qui marchent aussi bien
avec des fragments atomiques. Un exemple d'une telle attaque
exploite une énorme erreur de certaines
middleboxes, jeter les
datagrammes IPv6 ayant un en-tête d'extension, quel qu'il soit (y
compris, donc, l'en-tête Fragmentation). Ce comportement est
stupide mais hélas répandu (cf. RFC 7872). Un attaquant peut exploiter cette violation de la
neutralité du réseau pour faire une attaque par déni de
service : il émet des faux messages ICMP Packet
Too Big avec une MTU inférieur à
1 280 octets, la source se met à générer des fragments atomiques,
et ceux-ci sont jetés par ces imbéciles de
middleboxes.
Le RFC décrit aussi une variante de cette attaque, où deux
pairs BGP jettent les fragments reçus
(méthode qui évite certaines attaques contre le plan de contrôle
du routeur) mais reçoivent les ICMP Packet Too
Big et fabriquent alors des fragments atomiques. Il
serait alors facile de couper la session entre ces deux
pairs. (Personnellement, le cas me parait assez tiré par les
cheveux...)
Ces attaques sont plus faciles à faire qu'on ne pourrait le
croire car :
- Un paquet ICMP peut être
légitimement émis par un routeur intermédiaire et l'attaquant
n'a donc pas besoin d'usurper l'adresse IP de la destination
(donc, BCP 38 ne sert à rien).
- Certes, l'attaquant doit usurper les adresses IP contenues
dans le message ICMP lui-même mais c'est trivial : même si on
peut en théorie envisager des contrôles du style BCP 38 de ce
contenu, en pratique, personne ne le fait aujourd'hui.
- De toute façon, pas mal de mises en œuvres d'IP ne font
aucune validation du contenu du message ICMP (malgré les
recommandations du RFC 5927).
- Un seul message ICMP suffit, y compris pour plusieurs
connexions TCP, car la MTU réduite est typiquement mémorisée
dans le cache de l'émetteur.
- Comme la seule utilisation légitime connue des fragments
atomiques était celle du RFC 6145 (qui a
depuis été remplacé par le RFC 7915), on
pourrait se dire qu'il suffit de limiter leur génération aux cas
où on écrit à un traducteur utilisant le RFC 6145. Mais cela ne marche pas, car il n'y a pas de
moyen fiable de détecter ces traducteurs.
Outre ces problèmes de sécurité, le RFC note (section 3) que
les fragments atomiques ne sont de toute façon pas quelque chose
sur lequel on puisse compter. Il faut que la machine émettrice les
génère (elle devrait, mais la section 6 du RFC 6145 note que beaucoup ne le font pas), et,
malheureusement, aussi bien les messages ICMP Packet Too
Big que les fragments sont souvent jetés par des
machines intermédiaires.
D'ailleurs, il n'est même pas certain que la méthode du RFC 6145 (faire générer des fragments atomiques
afin d'obtenir un identificateur par datagramme) marche vraiment,
l'API ne donnant pas toujours accès à cet
identificateur de fragment. (Au passage, pour avoir une idée de la
complexité de la mise en œuvre des fragments IP, voir cet
excellent article sur le noyau Linux.)
En conclusion (section 4), notre RFC demande qu'on abandonne
les fragments atomiques :
- Les traducteurs du RFC 7915 (la
seule utilisation légitime connue) devraient arrêter d'en faire
générer.
- Les machines IPv6 devraient désormais ignorer les messages
ICMP Packet Too Big lorsqu'ils indiquent une
MTU inférieure à 1 280 octets.
RFC 9562: Universally Unique IDentifiers (UUIDs)
- 12 mai -
Ce RFC normalise les UUID, une famille d'identificateurs uniques, obtenus sans registre central. Il remplace l'ancienne norme, le RFC 4122, avec (...)
RFC 9490: Report from the IAB Workshop on Management Techniques in Encrypted Networks (M-TEN)
- 9 mai -
Aujourd'hui, l'essentiel du trafic sur l'Internet est chiffré, et pour d'excellentes raisons. Pas question de revenir là-dessus, mais, ceci dit, il (...)
RFC 9557: Date and Time on the Internet: Timestamps with Additional Information
- 29 avril -
Ce RFC modifie légèrement le format des estampilles temporelles du RFC 3339, changeant à la marge une définition et, surtout, permettant d'y attacher (...)
RFC 9567: DNS Error Reporting
- 27 avril -
Lorsqu'un résolveur DNS détecte un problème avec une zone, l'empêchant de résoudre les noms dans cette zone, il n'avait pas de moyen simple et (...)
RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)
- 8 avril -
Ces deux nouveaux types d'enregistrement DNS, SVCB et sa variante HTTPS, permettent de donner des informations supplémentaires à un client réseau (...)