Re: [FRnOG] [ALERT] Datacenter down

[Alexis Vachette]

Lequel ?

Alexis

2018-07-27 16:06 GMT+02:00 Thomas :

> C'est moi où tout le DC est down ?
>
> Thomas
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Grosse panne OVH ce matin

[Alexis VACHETTE]

De mon côté ça repart tranquillement j'ai l'impression. (sur RBX)

Cordialement,

Alexis VACHETTE.

On 09/11/2017 10:17, Jules-Henri Gavetti wrote:

Salut,

Moi je pense aux équipes techniques, c'est une véritable épreuve psychologique.

Bon courage

Jules

-Message d'origine-
De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de 
Dominique Rousseau
Envoyé : jeudi 9 novembre 2017 09:54
À : frnog@frnog.org
Objet : Re: [FRnOG] [TECH] Grosse panne OVH ce matin

Le Thu, Nov 09, 2017 at 09:32:20AM +0100, Julien Escario [esca...@azylog.net] a 
écrit:

Bonjour,
Ca ne vaut probablement pas trop le coup de faire les kékés sur cette liste.

+1
Je pense que pas grand monde ici n'a des infra du ampleur comparable a celles 
d'OVH pour pouvoir donner son avis...


Je ne vous rappelle qu'un truc : Redbus, 2006. Nous étions nombreux à
ne pas faire les malins à cette époque.

J'espere pour eux qu'ils auront assez de café et un bbq (crepes, whatever, hein 
;-)  pour se reconforter apres.


Courage aux équipes d'Oles qui doivent bien être sous pression avec
une obligation de résultat (rapide) dans une situation déjà bien
dégradée. Et aux autres qui font le support pour les clients qui ne savent plus 
vers qui se tourner.

Carrement, bon courage a ceux qui sont sur le pont, et a tous ceux qui vont 
devoir repondre aux clients.


--
Dominique Rousseau
Neuronnexion, Prestataire Internet & Intranet
21 rue Frédéric Petit - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop


---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Cherche retours d'expérience SFR - fibre 100M en ZVS

[Alexis VACHETTE]

Par expérience SFR en pro et particulier.

Le service n'est clairement plus au rendez-vous.

On 03/10/2017 17:01, Nathan delhaye wrote:

Le 3 octobre 2017 à 11:25, Sébastien Lesimple <
sebastien.lesim...@iguanetel.fr> a écrit :


Le 03/10/2017 à 11:08, Felix Defrance a écrit :

Le service est-il au rendez-vous?

NON!



+1

Sur un lien SFR hérité de l'infra Completel y'a 2 semaines j'ai eu 3 jours
de coupure avec comme justification : "Bha on as eu une coupure physique
sur un gros FO du coup c'est un incident générique alors la GTR s'applique
pas"

1. Faut m'expliquer comment UNE coupure, surtout sur un gros FO, ca down un
lien en plein Paris pendant 3 jours
2. La GTR s'applique pas parce qu'on est plusieurs a être impacté!?!?  WTF
!?!? Business plan parfait en somme...
3. Des explications genre "Ils arrivent sur site à 8h30" et le même jour
l'aprem à 15h "Ha l'équipe viens d'arriver sur place", c'est moyen niveau
com. Ou peut être que SFR as tellement baissé les prix qu'ils peuvent plus
acheter de GPS aux équipes de terrain.
4. Mon incident n'était pas listé dans les "incidents génériques" a ce
moment là et je n'ai pas recu de mail de déclaration d'incident, encore une
fois, niveau com" c'est pas génial.

+700€ le lien 100Mbps avec ca comme réponse et comme service, ca fait mal
au c..

En tout cas pour moi, fibre noire, lambda, "fibre internet", ADSL, SDSL, IP
over Avian Carrier ou Minitel, à n'importe quel prix SFR c'est fini.




---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] Problème SFR ?

[Alexis VACHETTE]

Bonjour,

Je confirme également un KO sur le netcenter de Courbevoie depuis 13h 
également.


On 18/08/2017 14:15, Olivier Lange wrote:

Pareil, on a une trentaine de lien ADSL qui sont tombé, sur du SFR.
Ils confirment un incident majeur sur leurs infrastructure, mais pas
plus d'info pour le moment.

Le 18 août 2017 à 14:04, Olivier Benghozi
 a écrit :

Tout à fait, ça semble HS sur plusieurs sites.


Le 18 août 2017 à 13:53, Emmanuel D.  a écrit :

Nous rencontrons un problème de connectivité depuis peu avant 13h00 sur 4
liens SFR partant de Telehouse2 et Interxion 5.
La couche physique (link up) et ethernet (via CDP) semble OK mais l'IP est
KO.

Est-ce que vous constateriez des problèmes similaires de votre côté ?


---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Adresses RFC 1918 dans l'infrastructure

[Alexis VACHETTE]

A la lecture du document c'est plus cons?quent que ce que pensais.

Envoy? de mon iPhone

Le 2 mai 2016 ? 12:36, Alexis VACHETTE 
<avache...@sisteer.com<mailto:avache...@sisteer.com>> a ?crit :


Bonjour Kave,

Il ne me semble pas que l'Iran soit sur un Intranet ? l'heure actuelle ? Sauf 
erreur de ma part.

Je sais que lors d'un r?cent voyage l?-bas, le DNS menteur ?tait l?gion.

Alexis VACHETTE | Network and System Engineer
On 02/05/2016 12:29, Kave Salamatian wrote:

Tr?s utilis? en Iran, Chine, Russie. bref tout pays qui souhaiterait pouvoir 
basculer son r?seau "internet" en intranet rapidement. Pour l'Iran bonne ?tude 
faite par Collin Anderson http://arxiv.org/abs/1209.6398
Nv
Envoy? de mon iPhone



Le 2 mai 2016 ? 12:03, Stephane Bortzmeyer 
<bortzme...@nic.fr><mailto:bortzme...@nic.fr> a ?crit :

Ce petit truc de s?curit?
<https://twitter.com/farrokhi/status/727052382920658944/><https://twitter.com/farrokhi/status/727052382920658944/>
 repose sur
l'hypoth?se que rares sont les op?rateurs s?rieux qui num?rotent leur
infra avec du RFC 1918.

Je me demande s'il existe des chiffres pr?cis ? ce sujet. Je sais que
cette (mauvaise) pratique existe mais a-t-on une id?e de l'ampleur ?


---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Adresses RFC 1918 dans l'infrastructure

[Alexis VACHETTE]

Je viens de me rendre compte que cette personne est en Iran en plus !

Cordialement,

*Alexis VACHETTE | Network and System Engineer*
On 02/05/2016 12:03, Stephane Bortzmeyer wrote:

Ce petit truc de sécurité
<https://twitter.com/farrokhi/status/727052382920658944/> repose sur
l'hypothèse que rares sont les opérateurs sérieux qui numérotent leur
infra avec du RFC 1918.

Je me demande s'il existe des chiffres précis à ce sujet. Je sais que
cette (mauvaise) pratique existe mais a-t-on une idée de l'ampleur ?


---
Liste de diffusion du FRnOG
http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [MISC] Re: Problems sur plateformes Centile

[Alexis VACHETTE]

Bonjour David,

Nous n'avons aucun détail sur cette attaque.

Je doute que cela soit disclose sur une liste publique.

En revanche, il serait bon de savoir si plusieurs clients sont impactés 
par ce genre de comportement.


Pour avoir comme contact un vendeur de solution Centile, pas de retour 
alarmant à ce jour.


Comme le souligne la personne juste avant moi est-ce que ce Centrex 
avait des logins de type ipbx/ipbx voir root/root.


La sécurité d'une interconnexion avec un prestataire tiers est essentiel 
à mon sens.


Cordialement,
Alexis.

On 11/03/2016 12:40, ADENIS | David MARCIANO wrote:

C'est assez grave comme information, si qq a plus d'informations, je veux bien 
partager en private 




Bonne réception
David Marciano


163 Avenue Gallieni - 93170 Bagnolet - France
Tel : +33 (0)1 48 24 07 07 - Fax : +33 (0)1 48 24 07 08
Mail : dmarci...@adenis.fr




-Message d'origine-
De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de 
slesim...@laposte.net
Envoyé : jeudi 10 mars 2016 13:14
À : Alexis VACHETTE
Cc : Frnog misc
Objet : Re: [FRnOG] [MISC] Problems sur plateformes Centile

Parceque du forensic a été fait sur les deux machines concernées.

- Mail original -

De: "Alexis VACHETTE" <avache...@sisteer.com>
À: slesim...@laposte.net, "Frnog misc" <frnog-m...@frnog.org>
Envoyé: Jeudi 10 Mars 2016 13:08:59
Objet: Re: [FRnOG] [MISC] Problems sur plateformes Centile

Bonjour,

RAS sur un Centrex.

Pourquoi est-ce que tu affirmes que ça vient du VPN de Centile ?

Cordialement,
Alexis VACHETTE.
On 10/03/2016 11:21, slesim...@laposte.net wrote:

Hello,

Un petit mot pour informer la communauté qu'un problème est apparu ce WE sur 
deux instance Centiles de ma connaissance.

- Pour l'une, un binaire a été installé via le VPN de service Centile
et lancé des attaque en amplification DNS à partir de la machine;
(accès au VPN plus connexion à la VM sans aucuns brute-force,
suppression des historiques et 500meg open bar sur la machine!)
- Pour l'autre, toujours via le VPN Centile, une attaque en DDoS de ladite 
machine cette fois, du type ICMP flood.

Certains d'entre vous on-t-ils constatés des soucis avec leur Centile ce WE?
Sont-ce deux cas totalement isolés ou tous le monde a-t-il eu droit a son lot 
de soucis?

Bonne journée à tous!
Seb.

---
Liste de diffusion du FRnOG
http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Problems sur plateformes Centile

[Alexis VACHETTE]

Bonjour,

RAS sur un Centrex.

Pourquoi est-ce que tu affirmes que ça vient du VPN de Centile ?

Cordialement,
Alexis VACHETTE.
On 10/03/2016 11:21, slesim...@laposte.net wrote:

Hello,

Un petit mot pour informer la communauté qu'un problème est apparu ce WE sur 
deux instance Centiles de ma connaissance.

- Pour l'une, un binaire a été installé via le VPN de service Centile et lancé 
des attaque en amplification DNS à partir de la machine;
(accès au VPN plus connexion à la VM sans aucuns brute-force, suppression des 
historiques et 500meg open bar sur la machine!)
- Pour l'autre, toujours via le VPN Centile, une attaque en DDoS de ladite 
machine cette fois, du type ICMP flood.

Certains d'entre vous on-t-ils constatés des soucis avec leur Centile ce WE?
Sont-ce deux cas totalement isolés ou tous le monde a-t-il eu droit a son lot 
de soucis?

Bonne journée à tous!
Seb.

---
Liste de diffusion du FRnOG
http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] réseau OVH en carafe ?

[Alexis VACHETTE]

Bonjour,

Disons qu'en BGP il faut faire attention à ce que tu annonces.

Si tu annonces des routes que tu ne dois pas annoncer, forcément tu as 
un risque que ça génère des choses incohérentes pour d'autres personnes.


Cordialement,
*Alexis VACHETTE | Network and System Engineer
* Sisteer France: 43 rue Pierre Valette, 92240 Malakoff – France
Direct line: +33 1 70 95 51 19 | Fax: +33 1 70 95 50 90
www.sisteer.com <http://www.sisteer.com>
On 12/02/2016 10:11, gael_aj...@yahoo.fr wrote:

Bonjour à tous,

Je reviens un petit peu sur les déboires d'OVH hier pour en comprendre. Pour 
cela j'avoue compter sur vos lumières :)

Pour moi, le BGP c'est encore un peu nouveau, et j'aimerai mieux saisir ce 
qu'il s'est passé.

J'ai pu lire ceci :

This leak has impacted some of our routers (6k) which could pass in TCAM 
exception.
-> Je comprend que la mémoire TCAM était pleine et donc ça à vite posé un 
problème. Suis-je dans le vrai ?


J'ai également lu ceci :
L'origine du problème vient d'un point de peering DECIX à Francfort où l'un des réseaux 
AS31500 nous a annoncé via le BGP "tout Internet". Conséquence, 75% de notre 
trafic a été aspiré par ce réseau, à travers Francfort.
-> Sur ce point, j'ai un peu plus de mal. Le principe même d'un routeur BGP 
n'est il pas d'annoncé l'ensemble des meilleurs routes qu'il connaient ? Charge, 
au routeur qui les reçoit de choisir ses best routes si il a plusieurs point de 
peering  Il y a forcement un point que je n'ai pas saisi.

Pourriez vous éclairer ma lanterne ?

Merci d'avance à celui qui prendra quelque minutes pour m'aider à comprendre.

Cordialement

G. A.

---
Liste de diffusion du FRnOG
http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] réseau OVH en carafe ?

[Alexis VACHETTE]

David,

Le full-feed j'ai l'impression mais attention je ne suis pas un expert BGP.

Le TCAM exception d'OVH dans le task n'indique pas justement ce soucis ?

J'avais cru voir que c'était une espace de stockage software sur le 
nainternet.


Pour Francfort, je pense qu'il n'y a même pas de débat.

Cordialement,
**
On 12/02/2016 10:48, David Ponzone wrote:

Oui.
Plus précisément, sur un point de peering comme le DECIX, tu échanges tes 
routes avec celles de ton peer.
Tes routes, c’est tes IP, et éventuellement celles de tes clients qui t’achètent du 
transit. Dans le jargon, on dit "les AS derrière toi".
Ton peer fait de même.
C’est un principe de réciprocité qui justifie la gratuité du peering, dans la 
plupart des cas. Quand les 2 peers sont disproportionnés, il est fréquent que 
le gros refuse le peering au petit, car le petit a plus à y gagner que le gros.
Il va alors souvent lui faire un devis si son métier est de vendre du transit 
(Orange, HE, etc…), soit lui dire de revenir plus tard quand il aura plus de 
trafic (Facebook, Microsoft, Akamai, …).
La seule fois où tu annonces tout internet à un peer, c’est donc justement si 
tu lui vends du transit.
Tu imagines bien que tu n’a pas envie qu’un autre gus passe par toi et tes 
transits, qui te coûtent de l’argent, gratuitement.

Dans le cas précis de l’AS 31500, il annonce en temps normal environ 117 routes 
sur un point de peering.
Et donc il s’est mis à annoncer peut-être tout Internet, donc 570 000 routes, à 
OVH.
2 problèmes possibles:
-le routeur d’OVH là-bas n’était pas capable de gérer un full-feed (inquiétant…)
et/ou
-si pour une raison X ou Y dans l’algo de sélection du best-path (un peu long à 
décrire ici, mais généralement, on met des poids forts sur les routes venant 
des peering pour les privilégier puisque pas chères), les routeurs d’OVH 
partout en France se sont mis
à envoyer une grosse partie du trafic vers le DECIX, peut-être que les liaisons 
vers Francfort n’étaient pas dimensionnées pour supporter ça (c’est même quasi 
sûr).



Le 12 févr. 2016 à 10:19, Alexis VACHETTE <avache...@sisteer.com> a écrit :

Bonjour,

Disons qu'en BGP il faut faire attention à ce que tu annonces.

Si tu annonces des routes que tu ne dois pas annoncer, forcément tu as un 
risque que ça génère des choses incohérentes pour d'autres personnes.

Cordialement,
*Alexis VACHETTE | Network and System Engineer
* Sisteer France: 43 rue Pierre Valette, 92240 Malakoff – France
Direct line: +33 1 70 95 51 19 | Fax: +33 1 70 95 50 90
www.sisteer.com <http://www.sisteer.com>
On 12/02/2016 10:11, gael_aj...@yahoo.fr wrote:

Bonjour à tous,

Je reviens un petit peu sur les déboires d'OVH hier pour en comprendre. Pour 
cela j'avoue compter sur vos lumières :)

Pour moi, le BGP c'est encore un peu nouveau, et j'aimerai mieux saisir ce 
qu'il s'est passé.

J'ai pu lire ceci :

This leak has impacted some of our routers (6k) which could pass in TCAM 
exception.
-> Je comprend que la mémoire TCAM était pleine et donc ça à vite posé un 
problème. Suis-je dans le vrai ?


J'ai également lu ceci :
L'origine du problème vient d'un point de peering DECIX à Francfort où l'un des réseaux 
AS31500 nous a annoncé via le BGP "tout Internet". Conséquence, 75% de notre 
trafic a été aspiré par ce réseau, à travers Francfort.
-> Sur ce point, j'ai un peu plus de mal. Le principe même d'un routeur BGP 
n'est il pas d'annoncé l'ensemble des meilleurs routes qu'il connaient ? Charge, 
au routeur qui les reçoit de choisir ses best routes si il a plusieurs point de 
peering  Il y a forcement un point que je n'ai pas saisi.

Pourriez vous éclairer ma lanterne ?

Merci d'avance à celui qui prendra quelque minutes pour m'aider à comprendre.

Cordialement

G. A.

---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] réseau OVH en carafe ?

[Alexis VACHETTE]

SDSL et dedicated cloud.

J'ai l'impression que ça va mieux maintenant.

Cordialement,
On 11/02/2016 17:03, Romain Valentin wrote:

Bonjour,

Vous avez aussi des problème sur le réseau OVH?

Merci

---
Liste de diffusion du FRnOG
http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Le pare-feu du geek barbu

[Alexis VACHETTE]

Merci, ça fait plaisir de lire quelque chose de sensé.

Cordialement,
Alexis.

On 04/01/2016 16:23, Edouard Chamillard wrote:

non, une adresse IP identifie un périphérique sur le réseau, pas une
personne. c'est pas parce que la distinction est suffisamment peu claire
pour le législateur qu'il nous pond régulièrement ce genre d’aberration
que c'est magiquement vrai.

qui plus est, justement parce que cette relation d'identité n'est que un
concept juridique, elle n'est pas vraie partout, et donc encore moins
utilisable en production.

Le 04/01/2016 16:03, Renaud a écrit :

Edouard Chamillard a écrit :

Par ailleurs, je trouve un peu problématique d'associer identité et

adresse IP. Au mieux une adresse IP est une indication géographique.
Mais il existe de nos jours beacoup trop de points d'accès ouverts ou
d'adresses IPs partagées par de nombreuses personnes pour qu'on puisse
continuer à considérer qu'une adresse IP permet d'identifier une
personne.

Quoiqu'il en soit, si ton réseau ne permet d'accéder qu'à des services
privées, je peux comprendre le filtre. Ceci dit, il empêchera également
de faire tourner un relai Tor à l'intérieur : un relai a besoin de
pouvoir contacter tous les autres relais.


et soit dit en passant, une adresse IP c'est pas une identité. qu'elle
soit v4 ou v6. si tu as besoin d'identifier des utilisateurs, y'a des
mécanismes pour ça. sinon le mème raisonnement conduit a bloquer les
hotspots, les opérateur qui font du CGN, etc...

l'adresse IP est une donnée à caractère personnelle, justement car elle
permet l'identification. Sans moyen "de brouillage" un utilisateur peut
être suivi  dans la plus part des cas sur la seule base de cette IP.

Dans le cas des Hotspot et des CGN il y a une obligation de pouvoir
suivre des connexions IP (principalement IP+PORT/TCP) à l'IP qui est
derrière le NAT qui elle même est reliée à une identité.

Il existe biensur plein de moyen de contourner ceci et TOR en fait
parti. Le but étant avant tout de garder controle sur mes données (et
les meta aussi).

Renaud

---
Liste de diffusion du FRnOG
http://www.frnog.org/





---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Le pare-feu du geek barbu

[Alexis VACHETTE]

David,

Je ne parlais que de l'identification d'une personne physique avec une IP.

Chez toi quand tu as une famille tu te rends compte qu'hormis faire la 
police et encore le blocage des services pour faire des choses pas net 
c'est pas forcément le plus simple.


Je suis au niveau de l'accès ADSL bien entendu.

De plus je n'ai jamais dit qu'Internet était une zone de non droit, bien 
que certains le pensent.


Cordialement,
Alexis.

On 04/01/2016 16:53, David Ponzone wrote:
il y a un flou artistique pour les hotspot public, ce qui rejoint les 
discussions récentes à ce sujet.
Pour l’accès Internet depuis ton ADSL ou ton mobile, je pense quand 
même que le détenteur du contrat d’abonnement est la personne qui sera 
identifiée comme utilisant l’IP publique (avec éventuellement les logs 
du CGN dans certains cas).
Après, on retombe sur le problème: est-ce qu’un particulier est censé 
être capable de sécuriser complètement son accès WIFI ? Evidemment que 
non, sauf avec un moyen très simple: pas de WIFI.
Peut-il se protéger de toute malware/bot/… ? Non, sauf en coupant 
Internet, auquel cas le problème de départ ne se pose plus.


Le législateur, il a besoin de légiférer. Depuis des dizaines d’année, 
un abonnement EDF identifie une personne physique (les piratages sont 
quand même assez rares), de même pour l’eau, et même le téléphone 
(quand un mec vous collait 10kF d’appels internationaux avec des 
pinces crocos, je pense qu’il était difficile d’expliquer à Orange que 
vous étiez innocents).
Il n’y a pas de raison qu’un accès Internet soit une zone de non-droit 
sous prétexte que la technique est défaillante.


Le 4 janv. 2016 à 16:35, Alexis VACHETTE <avache...@sisteer.com 
<mailto:avache...@sisteer.com>> a écrit :


Merci, ça fait plaisir de lire quelque chose de sensé.

Cordialement,
Alexis.

On 04/01/2016 16:23, Edouard Chamillard wrote:

non, une adresse IP identifie un périphérique sur le réseau, pas une
personne. c'est pas parce que la distinction est suffisamment peu claire
pour le législateur qu'il nous pond régulièrement ce genre d’aberration
que c'est magiquement vrai.

qui plus est, justement parce que cette relation d'identité n'est que un
concept juridique, elle n'est pas vraie partout, et donc encore moins
utilisable en production.

Le 04/01/2016 16:03, Renaud a écrit :

Edouard Chamillard a écrit :

Par ailleurs, je trouve un peu problématique d'associer identité et

adresse IP. Au mieux une adresse IP est une indication géographique.
Mais il existe de nos jours beacoup trop de points d'accès 
ouverts ou
d'adresses IPs partagées par de nombreuses personnes pour qu'on 
puisse

continuer à considérer qu'une adresse IP permet d'identifier une
personne.

Quoiqu'il en soit, si ton réseau ne permet d'accéder qu'à des 
services
privées, je peux comprendre le filtre. Ceci dit, il empêchera 
également

de faire tourner un relai Tor à l'intérieur : un relai a besoin de
pouvoir contacter tous les autres relais.


et soit dit en passant, une adresse IP c'est pas une identité. qu'elle
soit v4 ou v6. si tu as besoin d'identifier des utilisateurs, y'a des
mécanismes pour ça. sinon le mème raisonnement conduit a bloquer les
hotspots, les opérateur qui font du CGN, etc...

l'adresse IP est une donnée à caractère personnelle, justement car elle
permet l'identification. Sans moyen "de brouillage" un utilisateur peut
être suivi  dans la plus part des cas sur la seule base de cette IP.

Dans le cas des Hotspot et des CGN il y a une obligation de pouvoir
suivre des connexions IP (principalement IP+PORT/TCP) à l'IP qui est
derrière le NAT qui elle même est reliée à une identité.

Il existe biensur plein de moyen de contourner ceci et TOR en fait
parti. Le but étant avant tout de garder controle sur mes données (et
les meta aussi).

Renaud

---
Liste de diffusion du FRnOG
http://www.frnog.org/





---
Liste de diffusion du FRnOG
http://www.frnog.org/





---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] RFC 7610: DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers

[Alexis VACHETTE]

Bonjour Stéphane,

Si je comprends bien c'est un compromis et non une solution clé en main ?

Cordialement,
Alexis VACHETTE.*
*<http://www.sisteer.com>
On 07/09/2015 10:15, Stephane Bortzmeyer wrote:

Pour ceux qui gèrent des data centers avec IPv6 et DHCP :

http://www.bortzmeyer.org/7610.html



Auteur(s) du RFC: F. Gont (SI6 Networks / UTN-FRH), W. Liu (Huawei 
Technologies), G. Van de Velde (Alcatel-Lucent)




 Un peu de sécurité IPv6 sur le réseau local : comment protéger les
pauvres machines Ipv6 contre un méchant serveur DHCP, qui répond à la
place du serveur légitime, et plus rapidement que lui ? Pas de
surprise, la solution est la même qu'en IPv4 ("DHCP snooping") et est
détaillée dans ce RFC : le commutateur bloque les réponses DHCP qui
viennent d'un port où aucun serveur DHCP n'est censé être présent.

 Le mécanisme porte le doux nom de "DHCP Shield". DHCP, normalisé dans
le RFC 3315, est très proche en IPv6 et en IPv4 et, dans les deux cas,
n'offre quasiment aucune sécurité. Sur un réseau sans serveur DHCP
officiel, une machine peut prétendre être serveur DHCP et tout le monde
va la croire et accepter ses annonces. C'est une des plaies des réseaux
locaux, d'autant plus qu'authentifier le serveur DHCP est très
difficile puisqu'on utilise justement DHCP pour ne rien avoir à
configurer sur les machines clientes. Sur un réseau avec serveur DHCP
légitime, un faux serveur peut parfois se faire écouter, par exemple
s'il répond plus vite. Et, même quand il n'y a qu'un seul serveur DHCP,
rien ne garantit que les machines utiliseront uniquement les adresses
IP qui leur ont été allouées officiellement.

 Pour "DHCP Shield", le mode de fonctionnement normal est que
l'administrateur réseaux configure le commutateur en lui disant sur
quels ports du commutateur se trouve le serveur DHCP légitime. Le
commutateur examine alors tous les messages et rejette les réponses
DHCP qui viendraient d'un autre port. Le problème d'un serveur DHCP
pirate est très proche de celui d'un routeur IPv6 pirate qui envoie des
"Router Advertisement" (RFC 4861, section 4.2) trompeurs et la solution
est donc très proche (pour les RAcailles, les RA illégitimes, le
problème était exposé dans le RFC 6104 et la solution, "RA Guard", dans
les RFC 6105 et RFC 7113).

 Voilà pour le principe, les détails maintenant. Un commutateur
ordinaire ne protège pas contre les serveurs DHCP pirates. Il faut un
"DHCPv6 Shield Device" (section 3 du RFC), commutateur « intelligent »
capable de mettre en œuvre la technique décrite dans ce RFC. Demandez à
votre vendeur avant d'acheter, s'il y a bien les fonctions de "DHCP
Shield".

 Il faut ensuite le configurer explicitement (le commutateur pourrait
apprendre seul, en regardant les réponses mais c'est risqué : si le
serveur pirate est déjà en service au moment où le commutateur démarre,
ce dernier pourrait prendre le pirate pour le serveur légitime). Cette
configuration est faite par l'administrateur réseaux, qui désigne le ou
les ports du commutateur qui peuvent légitimement voir arriver des
réponses DHCPv6, car un serveur légitime se trouve derrière (section 4
du RFC).

 Dit comme cela, ça a l'air simple. Mais, dans les réseaux réels, plein
de complications peuvent survenir et la section 5 du RFC, sur les
problèmes possibles, est *beaucoup* plus longue que la section 4 qui
décrit l'algorithme. Premier gag possible, les en-têtes d'extension
IPv6 qui sont très difficiles à analyser
<http://www.bortzmeyer.org/analyse-pcap-ipv6.html>. Notre RFC impose
donc aux mises en œuvre de "DHCP shield" d'analyser *tout* le paquet,
de ne pas se limiter arbitrairement aux N premiers octets, car la liste
des en-têtes peut être longue. (La section 6 note que cela peut être
difficile sur le "fast path" - mis en oeuvre dans le matériel - des
commutateurs et suggère de jeter le paquet si on ne peut pas l'analyser
complètement, mais avec une liste de protocoles de transport qui soit
configurable, pour éviter de bloquer les nouveaux protocoles apparus
après la vente du commutateur.)

 Pour aider un peu les pauvres commutateurs, le RFC 7112 impose que,
dans un paquet fragmenté, la *totalité* des en-têtes soit dans le
premier fragment (autrement, un serveur DHCPv6 pirate pourrait
« tricher » en « cachant » la réponse IPv6 dans le deuxième fragment et
en espérant qu'il en soit pas analysé). Le commutateur doit donc jeter
les paquets fragmentés dont le premier fragment ne contient pas toute
la chaîne des en-têtes. (Interdire que les réponses DHCP soient
fragmentées aurait été encore plus efficace mais pouvait être gênant
dans certains cas, où il y a un besoin légitime d'envoyer de grandes
réponses.) Cette politique peut sembler violente mais, de toute façon,
un paquet fragmenté n'incluant pas la totalité des en-têtes n'a déjà
quasiment a

[FRnOG] Re: [TECH] RFC 7610: DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers

[Alexis VACHETTE]

Je n'ai surement pas employé le bon terme.

Ce que je voulais dire c'est que finalement la mise en oeuvre n'est pas 
forcément si simple dans certains cas.


Espèrons également que les constructeurs suivent ses recommandations.

Cordialement,
Alexis VACHETTE.

On 07/09/2015 10:31, Stephane Bortzmeyer wrote:

On Mon, Sep 07, 2015 at 10:24:41AM +0200,
  Alexis VACHETTE <avache...@sisteer.com> wrote
  a message of 465 lines which said:


Si je comprends bien c'est un compromis et non une solution clé en
main ?

Là, c'est moi qui ne comprends pas. C'est une solution technique à un
problème. Elle est classique puisque c'est la même que le "DHCP
snooping" d'IPv4.

Elle est clé en main si votre vendeur de commutateurs l'a mise en œuvre
dans son firmware. Sinon, parlez à votre commercial.





---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] OVH down ?

[Alexis VACHETTE]

Même constat, sauf que ça commence à faire beaucoup.

Cordialement,
On 29/07/2015 15:47, Charles-Henri BERNARD wrote:

Le POP de Globalswitch est down. Nous investiguons.

Ca semble remonté à l'instant

Le 29 juillet 2015 15:44,  varenn...@free.fr a écrit :

Bonjour,

je sais pas si le sujet à déjà été ouvert.
ovh semble down.
5 serveurs HS chez nous, et plusieurs liens SIP HS également

mon mail est chez OVH... j'ai du me réinscrire sur la liste avec un mail 
perso:'(

vous avez des nouvelles?


---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/




---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [ALERT] OVH down ?

[Alexis VACHETTE]

Encore un peu de lag.

Cordialement,
On 29/07/2015 15:55, Stephane Bortzmeyer wrote:

On Wed, Jul 29, 2015 at 01:47:53PM +,
  ALDO aldo_t...@yahoo.fr wrote
  a message of 32 lines which said:


Bonjour, suite appel à OVH, le support me demande de suivre sur
travaux.ovh.net, mais injoignable. OVH.com injoignable également.OVH
ne prévoit aucune communication.Bon courage!

Ça semble remarcher, Jean-Kevin a fini de recâbler.


---
Liste de diffusion du FRnOG
http://www.frnog.org/




---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Routeur intermediaire pour aiguiller le trafic vers différentes adsl

[Alexis VACHETTE]

Bonjour,

Pour un budget minimum, c'est une solution envisageable s'il dispose 
d'une machine avec suffisament de carte réseau.


Cordialement,
On 28/07/2015 10:43, Clement Cavadore wrote:

Hello,

Tu peux aussi utiliser un firewall sous linux et classifier a la mimine
le type de traffic qu'il route. J'ai eu fait ca quand j'étais étudiant:

Par exemple, avec la table mangle et -j MARK de iptables, tu marques
les paquets qui correspondent aux ports de surf (80/443) et de mail
(25/465/110/995/143/993), et les renvoient sur la liaison 1, et une
route par défaut sur la liaison 2.

Clément Cavadore

On Tue, 2015-07-28 at 07:59 +0100, Antoine Durant wrote:

Bonjour,

Actuellement j'ai une ADSL qui est utilisé pour monter un VPN vers un autre 
bureau afin d'utiliser les ressources de là bas. Le problème est que de temps 
en temps ça rame un peux quand on utilise le VPN et qu'on surf en même temps.

Je voudrais rajouter une seconde ADSL qui serait uniquement utilisé pour le 
surf/mail. L'ADSL 1 serait utilisée pour le VPN et l'ADSL 2 serait utilisée 
pour le reste du trafic.

Déjà est-ce que cela est possible a faire ?
Il va falloir que j'intercalle un routeur en dessous de mes deux box ADSL afin 
de créer une route VPN vers la BOX1 et le reste vers la BOX2.

Est-ce que c'est faisable ? Quel routeur CISCO me conseillez vous (très petit 
budget - de 500€)

Merci pour vos retours.


---
Liste de diffusion du FRnOG
http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/




---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Routeur intermediaire pour aiguiller le trafic vers différentes adsl

[Alexis VACHETTE]

Je confirme pour l'APU et la RAM, ça fonctionne parfaitement.

Cordialement,
On 28/07/2015 13:22, Vincent wrote:

Bonjour,

J’appuie le choix d’un PC Engine. J’utilise un APU¹ pour mon routeur (et
ce qui doit rester dans un tmux, style mutt, IRC et XMPP) à la maison,
ça marche nickel.

[1] http://www.pcengines.ch/apu1d.htm


Pour ma part, j'emploie la petite sœur de chez PC Engine à base de Géode
pour faire de la QOS, du routage, du vpn, point d'accès etc. sous
openwrt. Ca marche vraiment bien : http://www.pcengines.ch/alix2d13.htm
J'ai voulu a un moment y mettre du pfsense, mais c'est trop court en
RAM... Par contre sur une APU, ça doit fonctionner sans soucis.



---
Liste de diffusion du FRnOG
http://www.frnog.org/




---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] Banques CIC et CM HS ?

[Alexis VACHETTE]

Du moins le prestataire qui s'occupe de l'hébergement.

*Cordialement,*http://www.sisteer.com
On 20/07/2015 18:22, Alexis VACHETTE wrote:

Bonjour,

Etant en relation avec eux sur un projet.

Ils avaient un problème de connectivité Internet, pour ma part ça 
semble résolu.


Cordialement,
On 20/07/2015 18:17, Arthur Mayrand wrote:
Pour info, voici le mail reçu la semaine dernière par les sites 
utilisant

la solution de paiement du CIC et du Crédit Mutuel, la date de
l'intervention correspond...

[...]

Nous sommes amenés à renouveler les certificats présents sur nos 
serveurs

car la fonction de hachage cryptographique SHA-1 employée par les
certificats de nos serveurs Internet ne sera plus reconnue comme
suffisamment sécurisée en 2016. Ce changement est une amélioration de la
sécurité globale de la solution mais ne remet absolument pas en 
question la

sécurisation actuelle des échanges.



Le renouvellement de nos certificats prévu le 20/07/2015 impose un
changement d'autorité racine et il y a un risque pour que ce changement
bloque les requêtes de service que vous réalisez actuellement sur nos
serveurs.

Les applications de service potentiellement touchées chez vous sont:
capture_paiement.cgi, emulationtpe.cgi, emulation3ds.cgi, 
etatpaiement.cgi,

gestion_aliascb.cgi et recredit_paiement.cgi. Ce seront des erreurs
intervenant lors de l'établissement de la connexion qui seront 
détectées de
votre point de vue si notre nouveau certificat est signé par une 
autorité

non reconnue sur votre système.



Nous vous invitons à valider dès que possible votre compatibilité 
avec la

nouvelle autorité en réalisant des requêtes en remplaçant votre URL
habituelle par « paiement.e-i.com/api ».

Exemples:

https://paiement.creditmutuel.fr/emulation3ds.cgi sera remplacé pour ce
test par https://paiement.e-i.com/api/emulation3ds.cgi

https://ssl.paiement.cic-banques.fr/test/etatpaiement.cgi sera remplacé
pour ce test par https://paiement.e-i.com/api/test/etatpaiement.cgi

La page de paiement (« paiement.cgi ») n’est pas concernée par cette
validation.



En cas d'erreur: il vous faudra intégrer à votre magasin de 
certificats la
nouvelle racine VeriSign Class 3 Public Primary Certification 
Authority -

G5 téléchargeable à l'adresse http://www.symantec.com/page.jsp?id=roots



Si la mise à niveau des certificats ne résolvait pas le problème de
connectivité: veuillez nous contacter à l'adresse infos...@e-i.com.


Cordialement,
*__*
}}} Euro-Information Développements

@rthur

Le 20 juillet 2015 17:38, Xavier ROCA x.r...@sdi.fr a écrit :


Depuis ce matin BPCA aussi.
Mais on avait bien leur site web, seule la partie cyberplus HS.
Un peu de temps après un jolie message de MAJ
Mdr copier coller du CIC ou inversement ...

A l'instant ca tombe en marche.


-Message d'origine-
De : Michel Luczak [mailto:fr...@shrd.fr]
Envoyé : lundi 20 juillet 2015 16:51
À : David Ponzone
Cc : Guillaume Tournat; frnog-al...@frnog.org
Objet : Re: [FRnOG] [ALERT] Banques CIC et CM HS ?


On 20 Jul 2015, at 16:41, David Ponzone david.ponz...@gmail.com 
wrote:


Soit c’est rétabli, soit c’est pas une coupure totale, j’accède 
bien aux

sites.

Tentative de paiement à l’instant sur un site qui les utilise, KO 
(erreur

bizarre par contre, 403).

++ ic


---
Liste de diffusion du FRnOG
http://www.frnog.org/




---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/






---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] Banques CIC et CM HS ?

[Alexis VACHETTE]

Bonjour,

Etant en relation avec eux sur un projet.

Ils avaient un problème de connectivité Internet, pour ma part ça semble 
résolu.


Cordialement,
On 20/07/2015 18:17, Arthur Mayrand wrote:

Pour info, voici le mail reçu la semaine dernière par les sites utilisant
la solution de paiement du CIC et du Crédit Mutuel, la date de
l'intervention correspond...

[...]

Nous sommes amenés à renouveler les certificats présents sur nos serveurs
car la fonction de hachage cryptographique SHA-1 employée par les
certificats de nos serveurs Internet ne sera plus reconnue comme
suffisamment sécurisée en 2016. Ce changement est une amélioration de la
sécurité globale de la solution mais ne remet absolument pas en question la
sécurisation actuelle des échanges.



Le renouvellement de nos certificats prévu le 20/07/2015 impose un
changement d'autorité racine et il y a un risque pour que ce changement
bloque les requêtes de service que vous réalisez actuellement sur nos
serveurs.

Les applications de service potentiellement touchées chez vous sont:
capture_paiement.cgi, emulationtpe.cgi, emulation3ds.cgi, etatpaiement.cgi,
gestion_aliascb.cgi et recredit_paiement.cgi. Ce seront des erreurs
intervenant lors de l'établissement de la connexion qui seront détectées de
votre point de vue si notre nouveau certificat est signé par une autorité
non reconnue sur votre système.



Nous vous invitons à valider dès que possible votre compatibilité avec la
nouvelle autorité en réalisant des requêtes en remplaçant votre URL
habituelle par « paiement.e-i.com/api ».

Exemples:

https://paiement.creditmutuel.fr/emulation3ds.cgi sera remplacé pour ce
test par https://paiement.e-i.com/api/emulation3ds.cgi

https://ssl.paiement.cic-banques.fr/test/etatpaiement.cgi sera remplacé
pour ce test par https://paiement.e-i.com/api/test/etatpaiement.cgi

La page de paiement (« paiement.cgi ») n’est pas concernée par cette
validation.



En cas d'erreur: il vous faudra intégrer à votre magasin de certificats la
nouvelle racine VeriSign Class 3 Public Primary Certification Authority -
G5 téléchargeable à l'adresse http://www.symantec.com/page.jsp?id=roots



Si la mise à niveau des certificats ne résolvait pas le problème de
connectivité: veuillez nous contacter à l'adresse infos...@e-i.com.


Cordialement,
*__*
}}} Euro-Information Développements

@rthur

Le 20 juillet 2015 17:38, Xavier ROCA x.r...@sdi.fr a écrit :


Depuis ce matin BPCA aussi.
Mais on avait bien leur site web, seule la partie cyberplus HS.
Un peu de temps après un jolie message de MAJ
Mdr copier coller du CIC ou inversement ...

A l'instant ca tombe en marche.


-Message d'origine-
De : Michel Luczak [mailto:fr...@shrd.fr]
Envoyé : lundi 20 juillet 2015 16:51
À : David Ponzone
Cc : Guillaume Tournat; frnog-al...@frnog.org
Objet : Re: [FRnOG] [ALERT] Banques CIC et CM HS ?



On 20 Jul 2015, at 16:41, David Ponzone david.ponz...@gmail.com wrote:

Soit c’est rétabli, soit c’est pas une coupure totale, j’accède bien aux

sites.

Tentative de paiement à l’instant sur un site qui les utilise, KO (erreur
bizarre par contre, 403).

++ ic


---
Liste de diffusion du FRnOG
http://www.frnog.org/




---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/




---
Liste de diffusion du FRnOG
http://www.frnog.org/