Re: [FRnOG] [TECH] Attaques en série

2017-09-26 Par sujet David Ponzone 
Oui, si j'en crois:

http://www.cogentco.com/files/docs/customer_service/guide/global_cogent_customer_user_guide.pdf

Y a pas grand chose à part arrêter d'annoncer tes préfixes à leurs peers et 
clients :)

Bon, comme ton problème est de nettoyer ton lien 10G au départ de Cogent pour 
le désaturer, t'as pas bcp de solution si Cogent n'a pas de solution type uRPF.
Changer de transit en urgence semble peut-être le mieux si ça dure.
C'est peut-être le moment de savoir qui a de l'uRPF en offre standard (sans te 
faire payer des $ pour rentabiliser le Arbor).

Concernant les Mikrotik, j'imagine que le "bug" dont tu parles, c'est le fait 
que quand tu ouvres le resolver interne (avec allow-remote-requests = yes), il 
est ouvert pour le monde entier car il répond sur toutes les IP du routeur, 
donc tu dois impérativement mettre des ACL, ce qui n'est pas implicite pour 
quelqu'un qui est habitué à un CPE classique.
C'est vrai que c'est pénible, ça serait pas mal qu'ils rajoutent un champ pour 
binder le resolver  sur une ou plusieurs IP, mais aucune par défaut.


Le 26 sept. 2017 à 22:58, Jeremy a écrit :

> Le plus simple serait de faire un blackhole pour refuser les routes d'un AS 
> spécifique. (ChinaNet comme d'hab... AS4134).
> Le problème c'est que Cogent ne propose pas -à ma connaissance- de leur 
> envoyer une communauté pour blackholer les routes provenant d'un AS.
> 
> 
> Le 26/09/2017 à 22:50, David Ponzone a écrit :
>> Tu peux pas l'alléger en filtrant de manière statique les blocs d'IP source 
>> les plus fréquents ?
>> 
>> 
>> Le 26 sept. 2017 à 22:38, Jeremy a écrit :
>> 
>>> Nop, pas d'antiddos chez Cogent...
>>> On a un routeur en MITM (Wanguard Filter BGP) mais bon, même si il est 
>>> costaux, il en peu plus là ...
>>> 
>>> Le 26/09/2017 à 22:34, David Ponzone a écrit :
 Y a pas des origines géographiques que tu pourrais filtrer en inbound en 
 ajoutant un routeur MITM (Linux par exemple) pour nettoyer un peu ?
 Pas d'offre anti-DDoS chez Cogent ?
 
 
 Le 26 sept. 2017 à 22:23, Jeremy a écrit :
 
> C'est du "tout ou rien" chez Cogent. Soit il bloque tout ce qui passe sur 
> le port 53, soit ils bloquent rien. Pas possible de faire des ACL 
> excluant nos serveurs dns par exemple :(
> Là, l'attaque vient de changer, elle cible notre site public. Pour le 
> coup, je m'en fou tant que mes clients sont tranquille. Mais ça deviens 
> relou là.
> 
> Le 26/09/2017 à 22:21, David Ponzone a écrit :
>> J'ai peut-être raté un truc mais si tu demandes à Cogent de filtrer les 
>> paquets en outbound vers ton port 53, sauf pour tes DNS, ça limite pas 
>> la casse ?
>> J'ai cru comprendre que tes DNS n'étaient pas la cible, donc ça doit le 
>> faire.
>> 
>> Le 26 sept. 2017 à 22:08, Jeremy a écrit :
>> 
>>> Bonjour,
>>> 
>>> Depuis quelques jours, nous recevons de nombreuses attaques semblant 
>>> provenir d'un bot commandé (probablement un booter payant facturé à 
>>> l'heure). On a relevé énormément de routeurs Mikrotik pas à jour qui 
>>> sont commandés pour faire de l'amplification DNS avec spoofing. On 
>>> tourne autour de 40-60 Gb/s en continue.
>>> 
>>> La particularité de l'attaque est que le mec s'amuse à faire une 
>>> rotation d'IP en piochant au pif dans les prefix qu'on annonce (on 
>>> annonce l'équivalent d'un /19). Ca a tendance à fortement saturer les 
>>> tuyaux (transport), et à faire sérieusement ramer notre infra Wanguard 
>>> qui a du mal à suivre (de toute façon, comme ça sature au dessus...).
>>> J'ai l'idée de demander à Cogent (transitaire par lequel ça passe le 
>>> plus, logique...) de rajouter une ACL pour filtrer le port 53 mais quid 
>>> de notre capacité à résoudre les hostname depuis les root dns servers 
>>> ?! Je pense que si on fait ça, on peut dire adieux à notre indépendance 
>>> et bonjour à 8.8.8.8 partout (grosse galère en perspective). Pour le 
>>> moment, je garde cette option en solution ultime.
>>> 
>>> Bref, comme j'en ai marre de jouer avec BGP depuis samedi pour limiter 
>>> la casse, je vais finir par rajouter un transitaire protégé le temps 
>>> que ça passe. L'idée d'un tunnel GRE permettant de nettoyer le trafic 
>>> avant d'arriver chez nous peut avoir du sens, ou alors un nouveau port 
>>> de transit en 10G sur lequel on nous livrerais du transit déjà nettoyé.
>>> 
>>> Si certains d'entre-vous ont une solution technique efficace capable de 
>>> traiter très efficacement cette typologie, de mettre en place une 
>>> solution d'urgence pour nous filer un coup de main, et si possible sans 
>>> nous facturer les deux reins, ça serait très très apprécié.
>>> 
>>> En MP si vous avez besoin de plus d'infos !
>>> Merci,
>>> Jérémy
>>> 
>>> 
>>> ---
>>> Liste de diffusion du FRnOG
>>>

[FRnOG] [JOBS] Recherche Alternance Systèmes et Réseaux - Lyon

2017-09-26 Par sujet Grégory Madru 
Bonjour, je suis actuellement à la recherche d'une alternance (contrat de 
professionnalisation) pour faire un Titre Administrateur Systèmes et Réseaux 
(BAC+4) en deux ans à l'école It-Akademy ; j'ai actuellement un BTS Services 
Informatiques aux Organisations ainsi qu'une Licence Professionnelle de Réseaux 
Industriels et Informatiques.


Je n'ai pour le moment qu'une année d’expérience, en alternance en tant que 
technicien réseaux LAN mais je souhaiterais vraiment reprendre de l'alternance 
avant de commencer à travailler définitivement.


Je recherche une alternance en Administration (en support ou en projet), en 
tant qu'admin ou que technicien, ou encore en support (préférence sur site).


Je suis disponible à partir du 2 Octobre 2017, sur Lyon, véhiculé.
Si quelqu'un a une entreprise/personne à me recommander, j'accepterais 
volontiers, je crois avoir fait le tour des candidatures spontanées sur mon 
secteur 


Bonne fin de journée :)




Cordialement

MADRU Grégory




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

Re: [FRnOG] [TECH] Attaques en série

2017-09-26 Par sujet Jeremy 
Le plus simple serait de faire un blackhole pour refuser les routes d'un 
AS spécifique. (ChinaNet comme d'hab... AS4134).
Le problème c'est que Cogent ne propose pas -à ma connaissance- de leur 
envoyer une communauté pour blackholer les routes provenant d'un AS.



Le 26/09/2017 à 22:50, David Ponzone a écrit :

Tu peux pas l'alléger en filtrant de manière statique les blocs d'IP source les 
plus fréquents ?


Le 26 sept. 2017 à 22:38, Jeremy a écrit :


Nop, pas d'antiddos chez Cogent...
On a un routeur en MITM (Wanguard Filter BGP) mais bon, même si il est costaux, 
il en peu plus là ...

Le 26/09/2017 à 22:34, David Ponzone a écrit :

Y a pas des origines géographiques que tu pourrais filtrer en inbound en 
ajoutant un routeur MITM (Linux par exemple) pour nettoyer un peu ?
Pas d'offre anti-DDoS chez Cogent ?


Le 26 sept. 2017 à 22:23, Jeremy a écrit :


C'est du "tout ou rien" chez Cogent. Soit il bloque tout ce qui passe sur le 
port 53, soit ils bloquent rien. Pas possible de faire des ACL excluant nos serveurs dns 
par exemple :(
Là, l'attaque vient de changer, elle cible notre site public. Pour le coup, je 
m'en fou tant que mes clients sont tranquille. Mais ça deviens relou là.

Le 26/09/2017 à 22:21, David Ponzone a écrit :

J'ai peut-être raté un truc mais si tu demandes à Cogent de filtrer les paquets 
en outbound vers ton port 53, sauf pour tes DNS, ça limite pas la casse ?
J'ai cru comprendre que tes DNS n'étaient pas la cible, donc ça doit le faire.

Le 26 sept. 2017 à 22:08, Jeremy a écrit :


Bonjour,

Depuis quelques jours, nous recevons de nombreuses attaques semblant provenir 
d'un bot commandé (probablement un booter payant facturé à l'heure). On a 
relevé énormément de routeurs Mikrotik pas à jour qui sont commandés pour faire 
de l'amplification DNS avec spoofing. On tourne autour de 40-60 Gb/s en 
continue.

La particularité de l'attaque est que le mec s'amuse à faire une rotation d'IP 
en piochant au pif dans les prefix qu'on annonce (on annonce l'équivalent d'un 
/19). Ca a tendance à fortement saturer les tuyaux (transport), et à faire 
sérieusement ramer notre infra Wanguard qui a du mal à suivre (de toute façon, 
comme ça sature au dessus...).
J'ai l'idée de demander à Cogent (transitaire par lequel ça passe le plus, 
logique...) de rajouter une ACL pour filtrer le port 53 mais quid de notre 
capacité à résoudre les hostname depuis les root dns servers ?! Je pense que si 
on fait ça, on peut dire adieux à notre indépendance et bonjour à 8.8.8.8 
partout (grosse galère en perspective). Pour le moment, je garde cette option 
en solution ultime.

Bref, comme j'en ai marre de jouer avec BGP depuis samedi pour limiter la 
casse, je vais finir par rajouter un transitaire protégé le temps que ça passe. 
L'idée d'un tunnel GRE permettant de nettoyer le trafic avant d'arriver chez 
nous peut avoir du sens, ou alors un nouveau port de transit en 10G sur lequel 
on nous livrerais du transit déjà nettoyé.

Si certains d'entre-vous ont une solution technique efficace capable de traiter 
très efficacement cette typologie, de mettre en place une solution d'urgence 
pour nous filer un coup de main, et si possible sans nous facturer les deux 
reins, ça serait très très apprécié.

En MP si vous avez besoin de plus d'infos !
Merci,
Jérémy


---
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] Attaques en série

2017-09-26 Par sujet David Ponzone 
Tu peux pas l'alléger en filtrant de manière statique les blocs d'IP source les 
plus fréquents ?


Le 26 sept. 2017 à 22:38, Jeremy a écrit :

> Nop, pas d'antiddos chez Cogent...
> On a un routeur en MITM (Wanguard Filter BGP) mais bon, même si il est 
> costaux, il en peu plus là ...
> 
> Le 26/09/2017 à 22:34, David Ponzone a écrit :
>> Y a pas des origines géographiques que tu pourrais filtrer en inbound en 
>> ajoutant un routeur MITM (Linux par exemple) pour nettoyer un peu ?
>> Pas d'offre anti-DDoS chez Cogent ?
>> 
>> 
>> Le 26 sept. 2017 à 22:23, Jeremy a écrit :
>> 
>>> C'est du "tout ou rien" chez Cogent. Soit il bloque tout ce qui passe sur 
>>> le port 53, soit ils bloquent rien. Pas possible de faire des ACL excluant 
>>> nos serveurs dns par exemple :(
>>> Là, l'attaque vient de changer, elle cible notre site public. Pour le coup, 
>>> je m'en fou tant que mes clients sont tranquille. Mais ça deviens relou là.
>>> 
>>> Le 26/09/2017 à 22:21, David Ponzone a écrit :
 J'ai peut-être raté un truc mais si tu demandes à Cogent de filtrer les 
 paquets en outbound vers ton port 53, sauf pour tes DNS, ça limite pas la 
 casse ?
 J'ai cru comprendre que tes DNS n'étaient pas la cible, donc ça doit le 
 faire.
 
 Le 26 sept. 2017 à 22:08, Jeremy a écrit :
 
> Bonjour,
> 
> Depuis quelques jours, nous recevons de nombreuses attaques semblant 
> provenir d'un bot commandé (probablement un booter payant facturé à 
> l'heure). On a relevé énormément de routeurs Mikrotik pas à jour qui sont 
> commandés pour faire de l'amplification DNS avec spoofing. On tourne 
> autour de 40-60 Gb/s en continue.
> 
> La particularité de l'attaque est que le mec s'amuse à faire une rotation 
> d'IP en piochant au pif dans les prefix qu'on annonce (on annonce 
> l'équivalent d'un /19). Ca a tendance à fortement saturer les tuyaux 
> (transport), et à faire sérieusement ramer notre infra Wanguard qui a du 
> mal à suivre (de toute façon, comme ça sature au dessus...).
> J'ai l'idée de demander à Cogent (transitaire par lequel ça passe le 
> plus, logique...) de rajouter une ACL pour filtrer le port 53 mais quid 
> de notre capacité à résoudre les hostname depuis les root dns servers ?! 
> Je pense que si on fait ça, on peut dire adieux à notre indépendance et 
> bonjour à 8.8.8.8 partout (grosse galère en perspective). Pour le moment, 
> je garde cette option en solution ultime.
> 
> Bref, comme j'en ai marre de jouer avec BGP depuis samedi pour limiter la 
> casse, je vais finir par rajouter un transitaire protégé le temps que ça 
> passe. L'idée d'un tunnel GRE permettant de nettoyer le trafic avant 
> d'arriver chez nous peut avoir du sens, ou alors un nouveau port de 
> transit en 10G sur lequel on nous livrerais du transit déjà nettoyé.
> 
> Si certains d'entre-vous ont une solution technique efficace capable de 
> traiter très efficacement cette typologie, de mettre en place une 
> solution d'urgence pour nous filer un coup de main, et si possible sans 
> nous facturer les deux reins, ça serait très très apprécié.
> 
> En MP si vous avez besoin de plus d'infos !
> Merci,
> Jérémy
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>> 
> 


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

Re: [FRnOG] [TECH] Attaques en série

2017-09-26 Par sujet Jeremy 

Nop, pas d'antiddos chez Cogent...
On a un routeur en MITM (Wanguard Filter BGP) mais bon, même si il est 
costaux, il en peu plus là ...


Le 26/09/2017 à 22:34, David Ponzone a écrit :

Y a pas des origines géographiques que tu pourrais filtrer en inbound en 
ajoutant un routeur MITM (Linux par exemple) pour nettoyer un peu ?
Pas d'offre anti-DDoS chez Cogent ?


Le 26 sept. 2017 à 22:23, Jeremy a écrit :


C'est du "tout ou rien" chez Cogent. Soit il bloque tout ce qui passe sur le 
port 53, soit ils bloquent rien. Pas possible de faire des ACL excluant nos serveurs dns 
par exemple :(
Là, l'attaque vient de changer, elle cible notre site public. Pour le coup, je 
m'en fou tant que mes clients sont tranquille. Mais ça deviens relou là.

Le 26/09/2017 à 22:21, David Ponzone a écrit :

J'ai peut-être raté un truc mais si tu demandes à Cogent de filtrer les paquets 
en outbound vers ton port 53, sauf pour tes DNS, ça limite pas la casse ?
J'ai cru comprendre que tes DNS n'étaient pas la cible, donc ça doit le faire.

Le 26 sept. 2017 à 22:08, Jeremy a écrit :


Bonjour,

Depuis quelques jours, nous recevons de nombreuses attaques semblant provenir 
d'un bot commandé (probablement un booter payant facturé à l'heure). On a 
relevé énormément de routeurs Mikrotik pas à jour qui sont commandés pour faire 
de l'amplification DNS avec spoofing. On tourne autour de 40-60 Gb/s en 
continue.

La particularité de l'attaque est que le mec s'amuse à faire une rotation d'IP 
en piochant au pif dans les prefix qu'on annonce (on annonce l'équivalent d'un 
/19). Ca a tendance à fortement saturer les tuyaux (transport), et à faire 
sérieusement ramer notre infra Wanguard qui a du mal à suivre (de toute façon, 
comme ça sature au dessus...).
J'ai l'idée de demander à Cogent (transitaire par lequel ça passe le plus, 
logique...) de rajouter une ACL pour filtrer le port 53 mais quid de notre 
capacité à résoudre les hostname depuis les root dns servers ?! Je pense que si 
on fait ça, on peut dire adieux à notre indépendance et bonjour à 8.8.8.8 
partout (grosse galère en perspective). Pour le moment, je garde cette option 
en solution ultime.

Bref, comme j'en ai marre de jouer avec BGP depuis samedi pour limiter la 
casse, je vais finir par rajouter un transitaire protégé le temps que ça passe. 
L'idée d'un tunnel GRE permettant de nettoyer le trafic avant d'arriver chez 
nous peut avoir du sens, ou alors un nouveau port de transit en 10G sur lequel 
on nous livrerais du transit déjà nettoyé.

Si certains d'entre-vous ont une solution technique efficace capable de traiter 
très efficacement cette typologie, de mettre en place une solution d'urgence 
pour nous filer un coup de main, et si possible sans nous facturer les deux 
reins, ça serait très très apprécié.

En MP si vous avez besoin de plus d'infos !
Merci,
Jérémy


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





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

Re: [FRnOG] [TECH] Attaques en série

2017-09-26 Par sujet David Ponzone 
Y a pas des origines géographiques que tu pourrais filtrer en inbound en 
ajoutant un routeur MITM (Linux par exemple) pour nettoyer un peu ?
Pas d'offre anti-DDoS chez Cogent ?


Le 26 sept. 2017 à 22:23, Jeremy a écrit :

> C'est du "tout ou rien" chez Cogent. Soit il bloque tout ce qui passe sur le 
> port 53, soit ils bloquent rien. Pas possible de faire des ACL excluant nos 
> serveurs dns par exemple :(
> Là, l'attaque vient de changer, elle cible notre site public. Pour le coup, 
> je m'en fou tant que mes clients sont tranquille. Mais ça deviens relou là.
> 
> Le 26/09/2017 à 22:21, David Ponzone a écrit :
>> J'ai peut-être raté un truc mais si tu demandes à Cogent de filtrer les 
>> paquets en outbound vers ton port 53, sauf pour tes DNS, ça limite pas la 
>> casse ?
>> J'ai cru comprendre que tes DNS n'étaient pas la cible, donc ça doit le 
>> faire.
>> 
>> Le 26 sept. 2017 à 22:08, Jeremy a écrit :
>> 
>>> Bonjour,
>>> 
>>> Depuis quelques jours, nous recevons de nombreuses attaques semblant 
>>> provenir d'un bot commandé (probablement un booter payant facturé à 
>>> l'heure). On a relevé énormément de routeurs Mikrotik pas à jour qui sont 
>>> commandés pour faire de l'amplification DNS avec spoofing. On tourne autour 
>>> de 40-60 Gb/s en continue.
>>> 
>>> La particularité de l'attaque est que le mec s'amuse à faire une rotation 
>>> d'IP en piochant au pif dans les prefix qu'on annonce (on annonce 
>>> l'équivalent d'un /19). Ca a tendance à fortement saturer les tuyaux 
>>> (transport), et à faire sérieusement ramer notre infra Wanguard qui a du 
>>> mal à suivre (de toute façon, comme ça sature au dessus...).
>>> J'ai l'idée de demander à Cogent (transitaire par lequel ça passe le plus, 
>>> logique...) de rajouter une ACL pour filtrer le port 53 mais quid de notre 
>>> capacité à résoudre les hostname depuis les root dns servers ?! Je pense 
>>> que si on fait ça, on peut dire adieux à notre indépendance et bonjour à 
>>> 8.8.8.8 partout (grosse galère en perspective). Pour le moment, je garde 
>>> cette option en solution ultime.
>>> 
>>> Bref, comme j'en ai marre de jouer avec BGP depuis samedi pour limiter la 
>>> casse, je vais finir par rajouter un transitaire protégé le temps que ça 
>>> passe. L'idée d'un tunnel GRE permettant de nettoyer le trafic avant 
>>> d'arriver chez nous peut avoir du sens, ou alors un nouveau port de transit 
>>> en 10G sur lequel on nous livrerais du transit déjà nettoyé.
>>> 
>>> Si certains d'entre-vous ont une solution technique efficace capable de 
>>> traiter très efficacement cette typologie, de mettre en place une solution 
>>> d'urgence pour nous filer un coup de main, et si possible sans nous 
>>> facturer les deux reins, ça serait très très apprécié.
>>> 
>>> En MP si vous avez besoin de plus d'infos !
>>> Merci,
>>> Jérémy
>>> 
>>> 
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>> 
> 


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

Re: [FRnOG] [BIZ] Refonte infrastructure

2017-09-26 Par sujet Raphael Mazelier 



On 26/09/2017 15:30, Sébastien FOUTREL wrote:

Pour relativiser le propos, il faut faire la différence entre les infras
que tu opères pour toi et celles que tu opères pour les autres.


Oui complètement.


Pour moi, dans mon coin faire du Docker/k8s pourquoi pas. Si ça pète c'est
moi que ça regarde.
Mais quand je dois opérer pour un autre avec des SLA et des avocats et que
je lui dit que mes contraintes ne vont pas avec son contrat et ses SLA
qu'il veut c'est plus pareil.


On est d'accord.


Et sur l'idée même du conteneur fait par et pour les devs (alors que PXE
install, Debian et [Ansible,Chef,Puppet] ça marche tres bien et vite) je
dirai que si on en est au point de ne pas savoir faire causer les gens du
dev et du systeme on a pas des problèmes de technologies mais des problèmes
de communication interne.



Je crois que l'on dit la même chose. La technologie ne peut et ne dois 
jamais remplacer la communication. Encore une fois ce ne sont que des 
outils. Chacun utilise ce qu'il juge le plus opportun.




Et pour finir je citerai un philosophe : "YOU BUILD IT, YOU RUN IT"



Oula c'est très devops çà :)

--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Attaques en série

2017-09-26 Par sujet Jeremy 
C'est du "tout ou rien" chez Cogent. Soit il bloque tout ce qui passe 
sur le port 53, soit ils bloquent rien. Pas possible de faire des ACL 
excluant nos serveurs dns par exemple :(
Là, l'attaque vient de changer, elle cible notre site public. Pour le 
coup, je m'en fou tant que mes clients sont tranquille. Mais ça deviens 
relou là.


Le 26/09/2017 à 22:21, David Ponzone a écrit :

J'ai peut-être raté un truc mais si tu demandes à Cogent de filtrer les paquets 
en outbound vers ton port 53, sauf pour tes DNS, ça limite pas la casse ?
J'ai cru comprendre que tes DNS n'étaient pas la cible, donc ça doit le faire.

Le 26 sept. 2017 à 22:08, Jeremy a écrit :


Bonjour,

Depuis quelques jours, nous recevons de nombreuses attaques semblant provenir 
d'un bot commandé (probablement un booter payant facturé à l'heure). On a 
relevé énormément de routeurs Mikrotik pas à jour qui sont commandés pour faire 
de l'amplification DNS avec spoofing. On tourne autour de 40-60 Gb/s en 
continue.

La particularité de l'attaque est que le mec s'amuse à faire une rotation d'IP 
en piochant au pif dans les prefix qu'on annonce (on annonce l'équivalent d'un 
/19). Ca a tendance à fortement saturer les tuyaux (transport), et à faire 
sérieusement ramer notre infra Wanguard qui a du mal à suivre (de toute façon, 
comme ça sature au dessus...).
J'ai l'idée de demander à Cogent (transitaire par lequel ça passe le plus, 
logique...) de rajouter une ACL pour filtrer le port 53 mais quid de notre 
capacité à résoudre les hostname depuis les root dns servers ?! Je pense que si 
on fait ça, on peut dire adieux à notre indépendance et bonjour à 8.8.8.8 
partout (grosse galère en perspective). Pour le moment, je garde cette option 
en solution ultime.

Bref, comme j'en ai marre de jouer avec BGP depuis samedi pour limiter la 
casse, je vais finir par rajouter un transitaire protégé le temps que ça passe. 
L'idée d'un tunnel GRE permettant de nettoyer le trafic avant d'arriver chez 
nous peut avoir du sens, ou alors un nouveau port de transit en 10G sur lequel 
on nous livrerais du transit déjà nettoyé.

Si certains d'entre-vous ont une solution technique efficace capable de traiter 
très efficacement cette typologie, de mettre en place une solution d'urgence 
pour nous filer un coup de main, et si possible sans nous facturer les deux 
reins, ça serait très très apprécié.

En MP si vous avez besoin de plus d'infos !
Merci,
Jérémy


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





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

Re: [FRnOG] [TECH] Attaques en série

2017-09-26 Par sujet David Ponzone 
J'ai peut-être raté un truc mais si tu demandes à Cogent de filtrer les paquets 
en outbound vers ton port 53, sauf pour tes DNS, ça limite pas la casse ?
J'ai cru comprendre que tes DNS n'étaient pas la cible, donc ça doit le faire.

Le 26 sept. 2017 à 22:08, Jeremy a écrit :

> Bonjour,
> 
> Depuis quelques jours, nous recevons de nombreuses attaques semblant provenir 
> d'un bot commandé (probablement un booter payant facturé à l'heure). On a 
> relevé énormément de routeurs Mikrotik pas à jour qui sont commandés pour 
> faire de l'amplification DNS avec spoofing. On tourne autour de 40-60 Gb/s en 
> continue.
> 
> La particularité de l'attaque est que le mec s'amuse à faire une rotation 
> d'IP en piochant au pif dans les prefix qu'on annonce (on annonce 
> l'équivalent d'un /19). Ca a tendance à fortement saturer les tuyaux 
> (transport), et à faire sérieusement ramer notre infra Wanguard qui a du mal 
> à suivre (de toute façon, comme ça sature au dessus...).
> J'ai l'idée de demander à Cogent (transitaire par lequel ça passe le plus, 
> logique...) de rajouter une ACL pour filtrer le port 53 mais quid de notre 
> capacité à résoudre les hostname depuis les root dns servers ?! Je pense que 
> si on fait ça, on peut dire adieux à notre indépendance et bonjour à 8.8.8.8 
> partout (grosse galère en perspective). Pour le moment, je garde cette option 
> en solution ultime.
> 
> Bref, comme j'en ai marre de jouer avec BGP depuis samedi pour limiter la 
> casse, je vais finir par rajouter un transitaire protégé le temps que ça 
> passe. L'idée d'un tunnel GRE permettant de nettoyer le trafic avant 
> d'arriver chez nous peut avoir du sens, ou alors un nouveau port de transit 
> en 10G sur lequel on nous livrerais du transit déjà nettoyé.
> 
> Si certains d'entre-vous ont une solution technique efficace capable de 
> traiter très efficacement cette typologie, de mettre en place une solution 
> d'urgence pour nous filer un coup de main, et si possible sans nous facturer 
> les deux reins, ça serait très très apprécié.
> 
> En MP si vous avez besoin de plus d'infos !
> Merci,
> Jérémy
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

[FRnOG] [TECH] Attaques en série

2017-09-26 Par sujet Jeremy 

Bonjour,

Depuis quelques jours, nous recevons de nombreuses attaques semblant 
provenir d'un bot commandé (probablement un booter payant facturé à 
l'heure). On a relevé énormément de routeurs Mikrotik pas à jour qui 
sont commandés pour faire de l'amplification DNS avec spoofing. On 
tourne autour de 40-60 Gb/s en continue.


La particularité de l'attaque est que le mec s'amuse à faire une 
rotation d'IP en piochant au pif dans les prefix qu'on annonce (on 
annonce l'équivalent d'un /19). Ca a tendance à fortement saturer les 
tuyaux (transport), et à faire sérieusement ramer notre infra Wanguard 
qui a du mal à suivre (de toute façon, comme ça sature au dessus...).
J'ai l'idée de demander à Cogent (transitaire par lequel ça passe le 
plus, logique...) de rajouter une ACL pour filtrer le port 53 mais quid 
de notre capacité à résoudre les hostname depuis les root dns servers ?! 
Je pense que si on fait ça, on peut dire adieux à notre indépendance et 
bonjour à 8.8.8.8 partout (grosse galère en perspective). Pour le 
moment, je garde cette option en solution ultime.


Bref, comme j'en ai marre de jouer avec BGP depuis samedi pour limiter 
la casse, je vais finir par rajouter un transitaire protégé le temps que 
ça passe. L'idée d'un tunnel GRE permettant de nettoyer le trafic avant 
d'arriver chez nous peut avoir du sens, ou alors un nouveau port de 
transit en 10G sur lequel on nous livrerais du transit déjà nettoyé.


Si certains d'entre-vous ont une solution technique efficace capable de 
traiter très efficacement cette typologie, de mettre en place une 
solution d'urgence pour nous filer un coup de main, et si possible sans 
nous facturer les deux reins, ça serait très très apprécié.


En MP si vous avez besoin de plus d'infos !
Merci,
Jérémy


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

Re: [FRnOG] [TECH] EFM et synchro lonnnnguuue

2017-09-26 Par sujet Varicap 
Bonsoir

J ais déjà eu une bi paire à 10mn qui était stable pendant plusieurs heures et 
avoir de très fortes perturbations très aléatoires 

Richard

Envoyé de mon BP2 ( silent circle inside )

> Le 26 sept. 2017 à 17:59, David Ponzone  a écrit :
> 
> Quelqu'un a déjà vu un EFM (4Mbps 1 paire donc SHDSL.bis) mettre 30 minutes 
> au total pour que toutes les paires se synchronisent sans erreurs ?
> 
> En gros:
> -au boot: 1 paire UP seulement, une autre qui bagote, 2 DOWN
> -5/10 min après: 3 paires UP et 1 qui bagote
> -environ 25/30 min après le boot: les 4 UP
> 
> J'avais déjà eu du 5 min mais jamais un comportement aussi délirant.
> 
> Ca fait maintenant 5h que c'est up et pas un CRC, ni rien.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

[FRnOG] [TECH] EFM et synchro lonnnnguuue

2017-09-26 Par sujet David Ponzone 
Quelqu'un a déjà vu un EFM (4Mbps 1 paire donc SHDSL.bis) mettre 30 minutes au 
total pour que toutes les paires se synchronisent sans erreurs ?

En gros:
-au boot: 1 paire UP seulement, une autre qui bagote, 2 DOWN
-5/10 min après: 3 paires UP et 1 qui bagote
-environ 25/30 min après le boot: les 4 UP

J'avais déjà eu du 5 min mais jamais un comportement aussi délirant.

Ca fait maintenant 5h que c'est up et pas un CRC, ni rien.


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

[FRnOG] [JOBS] Marketing Intelligence

2017-09-26 Par sujet Laurent Seror 
Bonjour à tous,

OUTSCALE recrute toujours ! Fort de 140 collaborateurs dans le monde,
notre activité s'étend de plus et j'ai besoin de vous pour notre
activité MARKETING.
Oui, vous avez bien lu, je post sur FRNOG un job pour marketeux. Mais
pas n'importe lequel, je suis à la recherche du 007 du Cloud !

Il s'agit d'un poste de Marketing Intelligence, il faut tester les
offres disponibles potentiellement en compétition avec les nôtres, les
étudier et aider les responsables produits à proposer des alternatives
tout en étant concurrentiel.

C'est un job à la fois technique et marketing, dans le sens de l'étude
du marché et non de la symphonie de flutes, qui demande des
compétences fortes pour mettre en oeuvre les solutions concurrentes
QUI FONCTIONNENT !

En plus des compétences techniques, il faut être capable de rédiger
des specs et de construire des matrices de
fonctionnalités/compatibilités mais globalement les compétences
nécessaires sont celles d'un admin sys avec si possible des
connaissances AWS, Azure, VMWare, etc. (mais il peut apprendre sur le
tas).

Si cela vous intéresse, le poste est basé sur Saint Cloud et le
salaire varie entre 40-50k€ selon l'expérience.

Merci pour vos candidatures. D'autres offres d'emploi sont disponibles
sur : https://fr.outscale.com/carrieres/#joblist

Laurent Seror.


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

Re: [FRnOG] [BIZ] Refonte infrastructure

2017-09-26 Par sujet Sébastien FOUTREL 
Pour relativiser le propos, il faut faire la différence entre les infras
que tu opères pour toi et celles que tu opères pour les autres.

Pour moi, dans mon coin faire du Docker/k8s pourquoi pas. Si ça pète c'est
moi que ça regarde.
Mais quand je dois opérer pour un autre avec des SLA et des avocats et que
je lui dit que mes contraintes ne vont pas avec son contrat et ses SLA
qu'il veut c'est plus pareil.

Et sur l'idée même du conteneur fait par et pour les devs (alors que PXE
install, Debian et [Ansible,Chef,Puppet] ça marche tres bien et vite) je
dirai que si on en est au point de ne pas savoir faire causer les gens du
dev et du systeme on a pas des problèmes de technologies mais des problèmes
de communication interne.

Et pour finir je citerai un philosophe : "YOU BUILD IT, YOU RUN IT"

Cordialement

Le 22 septembre 2017 à 10:39, Kirth Gersen  a écrit :

> Docker c'est relativement 'bas niveau' par rapport au besoin  exprimé.
> je partirai plutôt sur du Kubernetes (abrégé en k8s) ou au dessus
> (OpenShift, Tectonic, etc).
> Les 3 gros cloud providers du moment (Google GCP, Amazon AWS , Microsoft
> Azure) ont des solutions k8s avec un net avantage a Google pour docker/k8s
> (c'est la techno interne utilisé chez Google donc en terme de 'ca marche en
> prod' c'est plus rassurant que chez Microsoft par exemple)
>
> Mais être 'provider' agnostic ca ne va pas être forcement simple et
> introduite une complexité plus grande que de modif le code en cas de
> changement de provider. C'est l'avantage de k8s: c'est juste des fichiers
> de conf a changer pour passer du stockage Google au stockage AWS par
> exemple, le 'driver' de k8s s'occupe du reste. Avec la notion de namespace
> (prod, preprod, dev) çà rejoint  un peu le 'rêve' exprimé par l'OP.
>
> Et pour ce qui est des anti-Docker en prod, ils sont soient resté bloqués
> quelques années en arrière soit leur job est menacé par ce genre de techno
> donc leur propos sont a relativiser fortement :)
>
>
>
> Le ven. 22 sept. 2017 à 08:35, Stéphane Cottin  vixns.net>> a écrit :
> Bonjour Gaël,
>
> Je peux te faire un retour d'expérience sur du docker en prod, ça
> fonctionne très bien ... si tu n'utilises pas docker ( ça c pour
> trolldi )
>
> J'ai monté plusieurs archis avec Apache Mesos, qui te permet
> d'instancier des containers à partir d'images docker sans avoir a
> installer aucun outil docker.
> Par rapport à la génération précédente (Mesos < 1.0) qui utilisait
> le daemon docker, cela n'a plus rien à voir en terme de stabilité /
> fluidité (plus de GC, tout est en c++) / consommation CPU "à vide" /
> heures de support.
>
> ArangoDB dispose d'un framework Mesos, cela peut être une bonne
> solution pour ton besoin.
>
> Stéphane
>
> On 21 Sep 2017, at 23:04, Gaël Demette wrote:
>
> > Bonsoir la liste,
> >
> > Aujourd'hui se pose la question de modifier notre infrastructure,
> > actuellement exclusivement chez AWS (Ireland), en effet notre stack à
> > la base assez simple commence à se complexifier avec nos évolutions
> > à venir. Du coup, Elastic Beanstalk commence à ne plus être
> > suffisant. On voudrait surtout en profiter pour abstraire le
> > fournisseur de Cloud. Malheureusement, notre petite startup n'a pas le
> > temps de faire tout cela, et souhaiterait étudier la possibilité
> > d'externaliser ces évolutions.
> >
> > J'avais en tête de tout passer sur Docker. Il faudrait donc faire
> > cette prestation, ainsi que nous former sur le fonctionnement de
> > l'infrastructure faite.
> >
> > Stack actuel :
> >
> > * S3 pour deux applications EmberJS (SPA)
> > * AWS Elastic Beanstalk (Avec nginx + NodeJS) -> Deux environnements,
> > le premier l'API (REST et websockets), le second une app NuxtJS (SPA
> > avec server-side rendering)
> > * AWS ElastiCache (Redis)
> > * Simple replicaset MongoDB (sur des EC2)
> >
> > Stack cible :
> >
> > * ArangoDB
> > * RabbitMQ (non fixé, si vous avez des suggestions sur des
> > alternatives, on est ouvert)
> > * MongoDB (On ne souhaite pas tout migrer sur ArangoDB d'un coup sans
> > plus de feedbacks)
> > * Plus de EmberJS
> > * Probablement plus de Redis (Pub/Sub couverte par RabbitMQ, key-value
> > storage couvert par ArangoDB), ça ne me gène pas de rester sur
> > ElastiCache le temps que nos devs fassent le nécessaire ;)
> > * Trois environnements "AWS Elastic Beanstalk like", API + Website
> > (NuxtJS) + Backoffice (Anciennement les deux apps EmberJS,
> > nouvellement NuxtJS avec Server side rendering)
> >
> > Mon rêve serait d'avoir une infra qu'on puisse utiliser tant pour
> > mettre en place des environnements à la volée, identiques à la
> > prod, et ce de manière agnostique du fournisseur de serveurs / cloud,
> > Docker semblait faire sens ici. "Plus qu'à" ajouter un système
> > permettant de scale, monitor, et self heal et on est bon.
> >
> > Il me faudrait des propositions commerciales pour ce genre de
> > prestation, n'hésitez pas à me contacter en privé,

Re: [FRnOG] [BIZ] Refonte infrastructure

2017-09-26 Par sujet Wallace 


Le 25/09/2017 à 21:57, Raphael Mazelier a écrit :
>
>
> On 25/09/2017 12:24, Wallace wrote:
>> Bien résumé Eric et pour avoir tenu un discours comme celui de Raphael à
>> des boites qui faisaient n'importe quoi en conteneur, la réponse est ha
>> oui mais c'est super compliqué et trop abstrait de faire comme cela. En
>> gros le côté éphémère leur fait super peur et c'est complètement
>> abstrait = risque +++ pour les directions donc ils ne font pas.
>>
>
> OK donc tu critiques la mauvaise mise en place des containers pas les
> containers en tant que tel. Mais c'est exactement pareil sinon pire de
> multiplier plein de petite vm(s) en terme de sécurité.
> Un container ne devrait être vu que comme une instance (dans le vrai
> sens instanciation objet) d'une application/service.
Je répond sous le paragraphe suivant puisque c'est lié.
>
>> Après même avec une superbe archi conteneur, si tu fais toutes tes
>> images pour être iso27001, pcidss et HDS le côté éphémère complexifie
>> grandement le traitement des métriques / logs et le suivi qualité.
>>
>
> Non c'est l'inverse. Évidement il faut prendre cela en compte dès la
> création du container. Par exemple chez nous toutes les applications
> "dockerisé" ont obligation d'envoyer leurs logs de manière structuré à
> un système de log central (graylog en l’occurrence).
>
> Au final j'ai l'impression que l'on parle de deux choses différentes.
> Remplacer des vm(s) par des containers n'a aucun sens en effet.
>
> Développer une nouvelle stack/SI dans un environnement container est
> une grande opportunité. La où je te rejoins c'est qu'il y a une grande
> courbe d'apprentissage que ce soit coté dev ou coté ops.

Et là on reboucle sur le sujet, les conteneurs c'est super si on les
fait soit même, on met ce que l'on veut : la sécurité, le déport de
métriques / logs, les mises à jour, ... mais cela implique de faire ses
images. Ca ne va clairement pas dans le sens des dirigeants qui y voient
le gain financier temps / emmerdement à cours terme. Le pire ce sont les
images officielles des applications, c'est officiel donc ça ne peut pas
être foncièrement mauvais dixit des DSI et de DT.
>
>> Faut penser aussi aux audits externes qui peuvent être imposés genre
>> suite à une fuite de données, la CNIL / ANSI qui vient auditer. Aucune
>> des boites que j'ai vu faire du conteneur n'est apte à répondre à la
>> moindre question d'extraction de donnée. Et quand on pense aux données
>> que ces boites voient transiter c'est pas du tout rassurant pour nos
>> profils persos.
>>
>
> Parce c'est différent dans un environnement classique ?
On reboucle sur le souci des images stock ou custom, en stock oui y a
une différence parce qu'en VM l'OS peut être modifié facilement (à la
main, script, automate) en conteneur c'est trop complexe pour les
équipes qu'on croise. Du coup l'option de facilité c'est de dire ces
mesures de sécurité, ces conformité c'est pas bien grave on relancera
l'instance en cas de soucis ...
>
>> C'est aussi ça le rôle d'un hébergeur infogéreur, être sûr que son
>> client soit apte à répondre à la loi en cas de besoin.
>>
>> Je trouve qu'une solution Ansible telle qu'on l'a monté chez nous qui
>> permet de faire du on demand sur différents hosteurs c'est tout aussi
>> souple. L'intégration d'une VM ça prend 5 min max avec le déroulé
>> Ansible mettant tout aux normes. Avantage on peut aussi commander des
>> baremetal et avoir des ressources bien différentes qui s'intègrent en
>> 10/15 min max si le hosteur livre rapidement.
>>
>
> Je ne vois toujours pas en quoi cela serait plus difficile dans un
> environnement container. Ne pas oublier qu'un container n'est rien de
> plus qu'un ensemble de process un peu isolé. Donc sécuriser n'importe
> quelle application ou un container c'est pareil.
Ca implique toujours une image conteneur custom. Sinon lancer un outil
automate dans un OS conteneur qui est censé se regénérer toutes les x
minutes / heures n'a que peu de sens.
>
>> Et là aussi même constat dans tous les boites et mêmes administrations
>> qui utilisent Amazon ou Azur j'ai jamais vu une seule donnée chiffrée.
>> C'est complètement irresponsable. J'ai vu des données santé brutes
>> (image IRM, doc rapport du médecin, fichier txt avec le mot de passe par
>> défaut 12345 pour en faire un mémo, nom des patients dans le nom de
>> fichier, ...) aller chez Amazon et Azur pour le PRA. A titre personnel
>> ça ne me donne même plus envie d'aller voir des médecins qui ont du
>> matériel connecté. Et quand on fait réagir le client sur ce point, ha
>> mais les médecins on peut rien leur demander, c'est les maîtres ici,
>> 12345 c'est déjà trop compliqué pour eux comme mot de passe ils
>> appellent le support quand le verr num n'est pas activé ... Et le cloud
>> public c'est pratique on a pas d'infra à mettre en place et à gérer.
>>
>
> Là encore tu critiques des mauvaises pratiques. Je ne penses pas que
> les gros encouragent ce genre de choses. D'ailleurs Amazon (pour ne
> citer

Re: [FRnOG] [BIZ] Refonte infrastructure

2017-09-26 Par sujet Wallace 
Le 25/09/2017 à 23:26, Colin J. Brigato a écrit :
> « Les containers c’est mauvais – la preuve en est : regardez toute la merde 
> que les gens en font » 

C'est sans doute pas assez mis en avant mais on fait des conteneurs
juste qu'on le fait dans le contexte qui nous parait être le plus
approprié pour ne pas négliger la sécurité et les remontées nécessaires
aux équipes OPS et à la loi.
Par contre oui on refuse de faire du conteneur comme on le voit lors de
nos audits.




signature.asc
Description: OpenPGP digital signature

Re: [FRnOG] [MISC] Manger de la soupe ?

2017-09-26 Par sujet Ronan Fontenay 
Bonjour,

Je pense que l'aspect sécurité doit être géré comme pour toute intervention
en milieu industriel. L'entreprise utilisatrice et l'entreprise extérieure
doivent rédiger un plan de prévention :
https://www.legifrance.gouv.fr/affichCode.do?idSectionTA=LEGISCTA18529787=LEGITEXT06072050=20110627

- Un sous-traitant peut-il refuser de dépanner s'il n'a pas un accès
sécurisé à la baie ?
Oui. Cela doit être prévu et analysé par les deux parties AVANT
intervention.

- Qui est responsable s'il tombe et tue deux clients au passage ?
Dans ce cas précis, probablement l'entreprise utilisatrice : elle aurait du
prévoir ça dans le plan de prévention et prendre les mesures adaptées pour
éviter ce risque.

- Que dirait un inspecteur du travail s'il voyait un mec jouer à Tarzan ou
à Indiana Jones avec un escabeau sur une palette en haut d'un Clark sans
harnais ?
Jocker.

- Sachant qu'il est impossible actuellement de positionner une nacelle en
position de travail devant la baie, en tant que sous-traitant, quelle est
ma responsabilité (et de quoi ai-je besoin pour me couvrir) si je dois tout
de même intervenir sur une telle installation ?
Il faut ici une nacelle adaptée pour atteindre la zone. Si c'est
impossible, l'enterprise utilisatrice doit prendre des mesures adaptées. Si
il y a une intervention, les deux entreprises seront responsables.

Ronan


2017-09-26 10:24 GMT+02:00 Toussaint OTTAVI :

>
> Le 26/09/2017 à 07:30, Ducassou Laurent a écrit :
>
>> C'est dans des cas comme ça où tu te dis que un réseau "tout FTTx" même
>> en LAN est le bien... Car adieu les contraintes de distances de 100m
>>
>
> Le problème du tout FTTx, c'est que les équipements terminaux sont tous en
> connectique RJ45 cuivre, et donc qu'il faut rajouter des switches ou des
> convertisseurs. Moi, c'est ce que j'aurais fait : des mini-coffrets avec
> des switches au plus près de l'utilisation, intégrés dans le mobilier.
>
> --
>
> Pas de commentaires sur l'aspect sécurité ?
>
> - Un sous-traitant peut-il refuser de dépanner s'il n'a pas un accès
> sécurisé à la baie ?
> - Qui est responsable s'il tombe et tue deux clients au passage ?
> - Que dirait un inspecteur du travail s'il voyait un mec jouer à Tarzan ou
> à Indiana Jones avec un escabeau sur une palette en haut d'un Clark sans
> harnais ?
> - Sachant qu'il est impossible actuellement de positionner une nacelle en
> position de travail devant la baie, en tant que sous-traitant, quelle est
> ma responsabilité (et de quoi ai-je besoin pour me couvrir) si je dois tout
> de même intervenir sur une telle installation ?
>
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [SPAM] RE: [FRnOG] [MISC] Manger de la soupe ?

2017-09-26 Par sujet Toussaint OTTAVI 


Le 26/09/2017 à 07:36, br...@skiwebcenter.fr a écrit :

Et là tu penses à la bêtise des nouveaux réseaux FTTH avec les boitiers sur les 
poteaux à 1M70 du sol... à la portée du premier gamin venu qui va arracher les 
épissures :/


On a pareil sur le cuivre dans le rural par chez nous. Les nouveaux PC 
sont systématiquement installés à hauteur d'homme. Cà permet aux 
techniciens cuivre/xDSL d'intervenir immédiatement, là ou avant, il 
fallait des habilitations pour grimper aux poteaux (que plus personne 
n'a) ou des nacelles, ce qui rajoutait un ou deux jours pour la réparation.


A moins que cela ne soit parce que la très grande majorité des poteaux 
sont vétustes, et que d'y clouer une étiquette jaune "Montée interdite" 
coûte moins cher que de tous les remplacer ;-)



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

Re: [FRnOG] [MISC] Manger de la soupe ?

2017-09-26 Par sujet Toussaint OTTAVI 


Le 26/09/2017 à 07:30, Ducassou Laurent a écrit :

C'est dans des cas comme ça où tu te dis que un réseau "tout FTTx" même
en LAN est le bien... Car adieu les contraintes de distances de 100m


Le problème du tout FTTx, c'est que les équipements terminaux sont tous 
en connectique RJ45 cuivre, et donc qu'il faut rajouter des switches ou 
des convertisseurs. Moi, c'est ce que j'aurais fait : des mini-coffrets 
avec des switches au plus près de l'utilisation, intégrés dans le mobilier.


--

Pas de commentaires sur l'aspect sécurité ?

- Un sous-traitant peut-il refuser de dépanner s'il n'a pas un accès 
sécurisé à la baie ?

- Qui est responsable s'il tombe et tue deux clients au passage ?
- Que dirait un inspecteur du travail s'il voyait un mec jouer à Tarzan 
ou à Indiana Jones avec un escabeau sur une palette en haut d'un Clark 
sans harnais ?
- Sachant qu'il est impossible actuellement de positionner une nacelle 
en position de travail devant la baie, en tant que sous-traitant, quelle 
est ma responsabilité (et de quoi ai-je besoin pour me couvrir) si je 
dois tout de même intervenir sur une telle installation ?




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