Greboca  

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.

Blog de Stéphane Bortzmeyer  -  Les drôles de pratiques BGP d'un opérateur bulgare et d'une université colombienne

 -  Juin 2017 - 

Aujourd'hui, nous allons un peu regarder un drôle de problème BGP, et en n'utilisant que des sources ouvertes. L'infrastructure de l'Internet est en effet largement ouverte aux investigations.

Alors, d'abord, le premier fait : l'opérateur bulgare Wireless Network Solutions annonçait en BGP un grand nombre de routes assez éloignées de ce qu'on attendrait de lui. L'annonce a cessé le 7 juin mais on peut toujours voir les anciennes annonces dans ce fichier issu de RIPE stat ou directement sur RIPE Stat :

Parmi les préfixes annoncés, on trouvait en effet des valeurs comme 168.176.219.0/24. Or, l'AS 34991 est situé en Bulgarie (ici, les données complètes, obtenues via whois). Alors que le préfixe 168.176.219.0/24 fait partie du 168.176.0.0/16 alloué à l'Université nationale de Colombie (ici, les données complètes via whois). Pourquoi donc un opérateur situé dans une petite ville de Bulgarie aurait-il comme client une université à Bogota ? Les liens économiques, historiques, linguistiques ou religieux, entre la Bulgarie et la Colombie semblent faibles. Creusons.

L'Université nationale de Colombie dispose d'un préfixe IPv4 de longueur 16 (cf. les données citées plus haut) mais ne l'annonce pas en BGP. On ne le voit pas sur RIPE stat, ou sur le looking glass de Hurricane Electric. Des sous-préfixes sont annoncés mais pas le /16 complet. Voyons sur RouteViews en telnet :

% telnet route-views.routeviews.org
Trying 2001:468:d01:33::80df:3367...
Connected to route-views.routeviews.org.
...
User Access Verification

Username: rviews

route-views>show ip route 168.176.219.0   
% Subnet not in table

route-views>show ip route 168.176.0.0  
Routing entry for 168.176.0.0/16, 46 known subnets
  Variably subnetted with 7 masks
B        168.176.0.0/18 [20/0] via 66.110.0.86, 2d02h
B        168.176.64.0/19 [20/0] via 66.110.0.86, 2d02h
B        168.176.72.0/22 [20/0] via 66.110.0.86, 2d02h
B        168.176.76.0/24 [20/0] via 66.110.0.86, 2d02h
...
    
Donc, l'université colombienne n'annonce qu'une petite partie de son /16. À une époque où tout le monde souffre de la pénurie d'adresses IPv4, c'est un peu curieux. L'annonce du sous-préfixe 168.176.219.0/24 par l'AS 34991 n'est donc pas un détournement BGP classique comme l'étaient ceux par Telekom Malaysia en 2015 ou bien lors du shunt de 2013. « Aucun préfixe BGP n'a été détourné pour le tournage de ce film. » Néanmoins, il ne semble pas non plus que cette annonce, qui n'a duré que dix jours, ait été légitime, à moins que le campus de Medellín n'ait eu envie pendant dix jours d'être connecté à l'Internet via la Bulgarie ? Une autre hypothèse, qui ne peut être formulée que par des gens pratiquant la méchanceté gratuite, serait que l'université a loué des /24 à des spammeurs bulgares…

Certains ont émis l'hypothèse que l'AS bulgare avait été pris par des méchants, à l'occasion d'une attaque flamant. Une attaque flamant est l'enregistrement d'un domaine qui n'existait pas, pour récupérer le courrier, y compris les demandes d'autorisation, d'un objet dont les contacts utilisaient des domaines disparus, ou mal enregistrés. Un exemple d'attaque flamant pour des TLD est par exemple documentée ici. La (je crois) première description publique date de 2007.

Les contacts techniques et administratifs de l'AS sont en @wirelessnetbg.info. Ils ont été modifiés juste avant les annonces bizarres, et le domaine créé peu de temps avant ces annonces (cf. les données récupérées par whois, le champ Creation Date). Mais rien ne prouve (en tout cas avec des données ouvertes) qu'il y a eu une attaque flamant contre l'AS, bien qu'elle soit possible. Notez enfin que l'entreprise derrière l'AS ne semble pas exister dans le registre des entreprises en Bulgarie.

Merci à Ronald F. Guilmette pour avoir détecté le cas et l'avoir publié, et à Rayna Stamboliyska pour des investigations.

par Stéphane Bortzmeyer

Blog de Stéphane Bortzmeyer

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 (...)


Un résolveur DNS public en Inde

 -  7 avril - 

J'avais raté l'information : il y a désormais un résolveur DNS public en Inde, dns.nic.in.Il ne semble pas y avoir eu beaucoup de communication (...)


IETF 119 hackathon: compact denial of existence for DNSSEC

 -  22 mars - 

On March 16 and 17 was the IETF hackathon in Brisbane. I worked on a DNSSEC feature called "compact denial of existence", and implemented it (...)


Eaten by the Internet

 -  22 mars - 

Ce court livre en anglais rassemble plusieurs textes sur les questions politiques liées à l'Internet comme la défense de la vie privée, le (...)


La faille DNSSEC KeyTrap

 -  19 mars - 

Le 16 février a été publiée la faille de sécurité DNSSEC KeyTrap. Je sais, c'est un peu tard pour en parler mais c'est quand même utile, non ?KeyTrap (...)