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.
- Juillet 2017 -
Ce RFC est très court, mais concerne un
problème fréquent sur l'Internet : les
fuites de routes BGP. Traditionnellement,
un routeur BGP acceptait par défaut toutes
les routes, et annonçait par défaut à ses
voisins toutes
les routes qu'il connaissait. Il fallait une configuration
explicite pour ne pas le faire. En cas d'erreur, ce comportement
menait à des fuites (RFC 7908). Notre RFC
normalise désormais le comportement inverse : un routeur BGP ne
doit, par défaut, rien accepter et rien annoncer. Il faut
qu'il soit configuré explicitement si on veut le faire.
Avec l'ancien comportement, la configuration de certains
routeurs BGP, les plus imprudents, indiquait les pairs avec qui on échangeait de
l'information, plus un certain nombre de routes qu'on n'envoyait
pas. Si une erreur faisait qu'on recevait
tout à coup des routes imprévues, on les acceptait, et on les renvoyait telles quelles,
propageant la fuite (RFC 7908). Des cas
fameux de fuites ne manquent pas (voir par exemple celle d'un opérateur malaisien). L'idée derrière
ce comportement était d'assurer la
connectivité du graphe de
l'Internet. Aujourd'hui, on est plutôt plus sensibles aux risques
de sécurité qu'à ceux de partitionnement du graphe, et les bonnes
pratiques demandent depuis longtemps qu'on indique explicitement
ce qu'on accepte et ce qu'on envoie. Voyez par exemple les
recommandations de l'ANSSI.
En pratique, ce très court RFC ajoute juste deux paragraphes à la
norme BGP, le RFC 4271. Dans sa section 9.1,
les paragraphe en question disent désormais qu'il ne doit pas y avoir
du tout d'exportation ou d'importation de routes, par
défaut. Notez donc que cela ne change pas le protocole BGP, juste
le comportement local.
Du moment qu'on change le comportement par défaut, il va y
avoir un problème de transition (et ce point a soulevé des
discussions à l'IETF). Si le logiciel du routeur
s'adaptait au nouveau RFC, certains opérateurs seraient bien
surpris que leurs routes ne soient tout coup plus
annoncées. L'annexe A du RFC recommande une stratégie en deux
temps :
- D'abord introduire une nouvelle option « BGP non sécurisé » qui
serait à Vrai par défaut (mais que les opérateurs pourraient
changer), ce qui garderait le comportement actuel mais avec un
avertissement émis quelque part « attention, vous exportez des
routes sans décision explicite »,
- Ensuite, dans la version suivante du
logiciel, faire que cette option soit à Faux par défaut.
Les routeurs Cisco utilisant
IOS-XR ont déjà ce comportement.
Et pour finir sur une note d'humour, à une réunion IETF (IETF 97), le projet
qui a finalement mené à ce RFC était illustré… de photos de
préservatifs. Pratiquez
donc le BGP safe, l'Internet vous remerciera.
