RE: [FRnOG] [MISC] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP

[Michel Py]

> Alexandre Bruyelles a écrit :
> [...]

Généralement je partage ton point de vue à propos des optimiseurs BGP, mais :

> Au passage, n'oublions pas que l'AS qui n'a pas vocation de faire du
> réseau n'est pas supposé avoir de T1 : il va plutôt avoir une paire de
> T2 qui vont lui proposer un panel qualitatif de destination;

Pourquoi ? Le client final (qui n'est pas en IX ou colo) n'a généralement pas 
tellement le choix de ses transitaires, en tout cas ici. Dans le cas récent, çà 
ne me surprends pas du tout qu'il ait acheté du transit d'un T1 et d'un T2.


> Francois Devienne a écrit :
> Par ailleurs l’Internet est une masse mouvante qui subit parfois des soucis, 
> y compris
> sur des transitaires de très bonne qualité. Même chose sur les IX, même les 
> meilleurs.
> Cela arrive qu’il y ait des dysfonctionnements que BGP ne voit pas.

Certes, mais c'est du aux limitations inhérentes qui viennent du fait que BGP 
soit un protocole path-vector.
Pour améliorer les chose, "yàkà" modifier BGP ou le remplacer, je que je ne 
vois pas arriver.
Personne n'a l'expérience de faire du distance-vector ou du link-state à 
l'échelle de l'Internet, et depuis la nuit des temps toutes les tentatives qui 
ont essayé de changer le principe de la patate chaude ont échoué.

Les optimiseurs BGP, je vois çà un peu comme QOS : sur son propre réseau dont 
on a le contrôle, oui. Sur l'Internet public dont on connait très peu, on s'y 
est tous cassé les dents et on en est presque tous arrivés à la même conclusion 
qui est que mettre un meilleur tuyau çà marche à chaque fois.

Cà a l'air d'une solution qui cherche un problème.

Michel.


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

Re: [FRnOG] [TECH] BGP multihomé : comment controller le trafic entrant

[David Ponzone]

> Le 2 juil. 2019 à 23:50, Pierre Colombier  a écrit :
> 
> intéressant. J'ajouterai une question.
> 
> si un de mes transitaire tombe, mon trafic sortant bascule presque 
> immédiatement. par contre, sur l'entrant, il faut bien 5 minutes avant que le 
> report n'ait lieu sur un autre transitaire et le trou se voit carrément !
> 
> Comment font les gros pour que ce genre d'incidents soient (presque) 
> invisibles ?
> 

Hmmm quels gros ? :)

Evidemment les Tier1 n’ont pas de transitaires, ont de multiples PNI entre eux 
et de très nombreux peerings, donc ils peuvent en perdre 1.
Les Tier2 récupèrent probablement au moins (à la louche) 70% de leur traffic 
par leurs peerings, donc perdre un transitaire a un impact sur du traffic qu’on 
pourrait qualifier de peu critique.

Ceci dit, j’ai plutôt constaté en temps < 2 min pour que le report se fasse.


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

Re: [FRnOG] [ALERT] Cloudflare

[Vincent Tondellier]

Le Tuesday 02 July 2019 16:22:35 Fabien Germain a écrit :
> Hello,
> 
> Le 02/07/2019 16:10, Maxence Rousseau a écrit :
> > Des soucis chez Cloudflare ?
> > 
> > Cela passe un peu mieux sur AMSIX (genre 5 min de temps de
> > chargement), rien ne marchait sur Equinix
> > 
> > Pas de twit', pas d'info, donc je me sens un peu seul, allo ?
> 
> De notre côté ça semble revenu, mais effectivement peu d'info. Juste ça : 
> https://www.cloudflarestatus.com/incidents/tx4pgxs6zxdr

Ils ont publié le post mortem :

https://blog.cloudflare.com/cloudflare-outage/

Pour croiser avec les autres sujets du jour, c'est pas du DDoS ni un 
optimiseur BGP, c'est une règle de WAF foireuse (regex mal écrite) qui est la 
cause


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

Re: [FRnOG] [TECH] BGP multihomé : comment controller le trafic entrant

[Pierre Colombier]

intéressant. J'ajouterai une question.

si un de mes transitaire tombe, mon trafic sortant bascule presque 
immédiatement. par contre, sur l'entrant, il faut bien 5 minutes avant 
que le report n'ait lieu sur un autre transitaire et le trou se voit 
carrément !


Comment font les gros pour que ce genre d'incidents soient (presque) 
invisibles ?




On 29/06/2019 05:51, Michel Py wrote:

On a eu cette discussion récemment mais il y a pas eu trop de participants, 
donc je relance.

Données :

Tier-1 exclus. Ce que font les Tier-1 c'est pour MISC.
Inclus : tout le reste, y compris les AS non-FAI.
Ce qui veut dire : achète du transit à 2 ou plus upstream, possiblement paire 
dans un IX.

Qu'est-ce qu'on peut faire pour controler le trafic BGP entrant ?

- Evident : PREPEND.
Cà défavorise un ou plusieurs upstreams, la version simple est que plus gros 
l'upstream est plus il faut prépender, car si on achète du transit à un T1 et à 
un T2, sans prépender le trafic entrant va avoir tendance à venir du T1, 
puisque l'AS-PATH va souvent être plus court. Pour équilibrer, faut prépender.
Défaut : le prépend n'a rien à voir avec la destination.

- Evident mais pas simple : si on paire dans un IX, discuter le bout de gras 
avec les pairs pour qu'ils configurent localpref ou autres dans leur route-map.
Problème : quand quelqu'un a un optimiseur BGP qui génère des préfixes plus 
longs, c'est comme pisser dans un violon.

Solution : annoncer une chiée de /24 pour l'ensemble de son espace.
Pas taper, pas taper. (1)


- Moins courant : certaines communautés. Suivant l'upstream, le cas typique 
étant un gros T2 qui paire avec un T1 à plusieurs endroits, on peut bidouiller 
la localpref du upstream en question et faire arriver le trafic à un endroit 
plutôt qu'un autre. Pas standard, aucune garantie.

- Après çà, je laisse mes camarades expliquer comment çà marche.

La boiboite qui dit à l'Internet comment m'envoyer mon trafic, j'ai pas encore 
vu.
Comme d'habitude, si je dis des conneries, merci d'envoyer un lien en disant 
que c'est des conneries.

Michel.

(1) Mon transitaire préféré redistribue OSPF dans BGP, et je vois plein de leur 
préfixes plus longs.
A bien y réfléchir, je ne filtre pas. Comme à la maison c'est mon FAI, je 
préfère voir leur réseau interne dans mon feed.
Voir le /24 de mon aDSL à la maison dans le feed eBGP du bureau, çà coute pas 
cher et vu que l'AS-PATH est 1 cà évite les détournements intempestifs.


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



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

[FRnOG] [TECH] Question Proxmox et disques raw corrompus

[Anthony Frnog]

Bonsoir la liste,

Je me permets de poser ma question ici car je ne pense pas être le seul à
avoir rencontré le problème suivant.

J'utilise Proxmox 5.3 (3 noeuds) avec une connexion nfs et 2 serveurs DRBD
(version 9 , maître/esclave)

Pour une raison inconnue, mon cluster proxmox s'est mis à monter en charge
CPU au point de perdre la connexion nfs puis ensuite, mon cluster (mes 3
noeuds) a rebooté.

Suite à ce reboot environ 30% de mes vm en disques raw n'ont pas redémarré.
L'unique information que j'avais au boot de mes VM est :

"booting from hard disk
boot failed: not a bootable disk
no bootable device"

 En vérifiant sur ma baie de disques, les disk.raw étaient présents dans
les répertoires de chaque VM, et la taille du disque raw indiqué lors de
l'exécution de la commande ls -alsh était la bonne.


L'un d'entre vous a-t-il était confronté à cette défaillance et si oui,
y'a-t-il un moyen de réparer  le disque sans avoir à repartir sur un ancien
backup du disque?

De plus, auriez-vous une explication sur le fait que mes proxmox sont
montés en pleine charge sans raison apparente?

Merci par avance pour vos idées/remarques.

Anthony

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

Re: [FRnOG] [TECH] Transit et déni de service

[Hugues Voiturier]

Ce n’est pas un DDoS : https://twitter.com/jgrahamc/status/1146078278278635520 



Hugues
AS57199 - AS50628

> On 2 Jul 2019, at 20:32, Erwan David  wrote:
> 
> 
> Le 02/07/2019 à 19:59, Paul Rolland (ポール・ロラン) a écrit :
>> Rooohh... le pessimiste ;)
>> Sur ce coup-la, je suis en phase avec Michel. On peut pas tous avoir les
>> moyens de se payer 200G juste pour que l'attaque, on s'en moque (et si on
>> pouvait le faire, alors les attaques feraient 10T, et on aurait juste
>> deplacer le probleme).
>> Si qq'un est capable de faire en sorte que tu recoives du traffic que tu ne
>> devrais pas, ca serait bien de pouvoir configurer finement ce que tu
>> blackhole (genre pouvoir specifier des sources - ports et/ou ip -, voire
>> meme faire du filtre passant - drop tout sauf ca - pour preserver certains
>> choses).
>> 
>> Est-ce que c'est du long term ? Non, c'est clair, mais si c'est facile et
>> rapide a mettre en oeuvre, alors tu as au moins deja rendu un coup.
>> 
> À propos de gros tuyaux, j'ai vu passer (mais sans sources) que la panne
> de cloudflare aujourd'hui était due à un dDDOS : quel taille de transit
> aurait-il fallu pour tenir face à un dDOS capable de faire tomber
> cloudflare ?
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Transit et déni de service

[Erwan David]

Le 02/07/2019 à 19:59, Paul Rolland (ポール・ロラン) a écrit :
> Rooohh... le pessimiste ;)
> Sur ce coup-la, je suis en phase avec Michel. On peut pas tous avoir les
> moyens de se payer 200G juste pour que l'attaque, on s'en moque (et si on
> pouvait le faire, alors les attaques feraient 10T, et on aurait juste
> deplacer le probleme).
> Si qq'un est capable de faire en sorte que tu recoives du traffic que tu ne
> devrais pas, ca serait bien de pouvoir configurer finement ce que tu
> blackhole (genre pouvoir specifier des sources - ports et/ou ip -, voire
> meme faire du filtre passant - drop tout sauf ca - pour preserver certains
> choses).
>
> Est-ce que c'est du long term ? Non, c'est clair, mais si c'est facile et
> rapide a mettre en oeuvre, alors tu as au moins deja rendu un coup.
>
À propos de gros tuyaux, j'ai vu passer (mais sans sources) que la panne
de cloudflare aujourd'hui était due à un dDDOS : quel taille de transit
aurait-il fallu pour tenir face à un dDOS capable de faire tomber
cloudflare ?


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

Re: [FRnOG] [TECH] Transit et déni de service

[Paul Rolland (ポール・ロラン)]

Hello,

On Tue, 2 Jul 2019 15:57:48 +
Michel Py  wrote:

> Justement j'étais en train de travailler là-dessus avec UTRS avec le même
> raisonnement : Si mon site principal est saturé par une attaque, la seule
> solution c'est d'avoir une session, probablement multihop, venant d'un
> site satellite. Disons que de la maison ou de MacDo je me connectes à mon
> site satellite pour configure parce que ce que je fais du site principal
> c'est down. Pour l'instant, pas possible. C'est clair que tout ce qui est
> BGP il faut avoir une infra d'injection indépendante.

Mouais, du coup, l'interet de BGP dans l'histoire, je vois moins... En
fait, une API, ca le fait... pas besoin qu'elle s'appelle BGP. Il te suffit
d'un acces mobile, d'une bonne authentif securisee, et hop, tu postes tes
regles de drop.
 
> > Raphael Maunier a écrit :
> > Pour moi le blackhole n’est pas une solution, l’attaquant a gagné :)  

Rooohh... le pessimiste ;) 
Sur ce coup-la, je suis en phase avec Michel. On peut pas tous avoir les
moyens de se payer 200G juste pour que l'attaque, on s'en moque (et si on
pouvait le faire, alors les attaques feraient 10T, et on aurait juste
deplacer le probleme).
Si qq'un est capable de faire en sorte que tu recoives du traffic que tu ne
devrais pas, ca serait bien de pouvoir configurer finement ce que tu
blackhole (genre pouvoir specifier des sources - ports et/ou ip -, voire
meme faire du filtre passant - drop tout sauf ca - pour preserver certains
choses).

Est-ce que c'est du long term ? Non, c'est clair, mais si c'est facile et
rapide a mettre en oeuvre, alors tu as au moins deja rendu un coup.

Paul


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

Re: [FRnOG] [MISC] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP

[Francois Devienne]

ReBonjour,

Ce qui est dit ici me semble être plein de bon sens mais je mettrais un bémol. 
Ne serait-ce que pour disposer d’une réelle diversités des chemins, on 
recommande de prendre 2 ou 3 transits de Tiers 1 et autant d’IX que possible.
Ainsi on a l’assurance de disposer de chemins différenciés dans les deux sens.

Alors que si l’on a par exemple 1 seul Tier 1 et 2 transits Tier 2, il est 
possible, voire même probable que certaines destinations soient joignables par 
des chemins qui convergent quelque part. En cas de panne, il y a alors besoin 
de se reposer sur la résilience des Tiers 2 pour éventuellement récupérer un 
chemin acceptable. Et en cas de congestion, c’est pire on ne peut rien faire 
sauf espérer que le transitaire Tier 1 ait un moyen de détecter la panne ….
C’est dommage car il n’y a pas réellement de Tiers 1 hexagonaux mais 
techniquement, c’est mieux et c’est pas vraiment plus cher. Autrement dit si on 
veut joindre uniquement des destinations bien identifiées et bien connectées à 
des tiers 2 locaux on peut faire le choix poétique et patriotique d’aller vers 
cette solution. Sinon non.

Par ailleurs l’Internet est une masse mouvante qui subit parfois des soucis, y 
compris sur des transitaires de très bonne qualité. Même chose sur les IX, même 
les meilleurs. Cela arrive qu’il y ait des dysfonctionnements que BGP ne voit 
pas. Je ne veux incriminer personne donc je m’arrête là.

Bonne soirée,
François.



> On 2 Jul 2019, at 16:13, Alexandre Bruyelles  
> wrote:
> 
> Les optimiseurs bgp, ce sont de mauvaises solutions à un vrai problème
> 
> Le vrai problème : quand tu as X liens pourris vers une destination X,
> ta "qualité" n'est pas terrible (voir problématique)
> 
> La fausse solution : faisont du vaudoo pour essayer de "choisir" le
> meilleur des mauvais liens
> 
> La bonne solution : mettre en production de bons liens
> 
> 
> En effet, plusieurs possibilités:
> - soit tu te moques de la destination X (c'est un vague AS en
> biélorussie, OSEF). Dans ce cas, tu te moques aussi de la qualité que tu
> as vers cet AS.
> - soit la destination X est importante pour ton business, et du coup, au
> choix:
>  - tu setup un PNI avec X
>  - tu te connectes à un IX pour joindre X
>  - tu te connectes à un transitaire qui est bon pour communiquer avec X
> 
> 
> Si tu deploies l'algorithme, il n'y a pas de place saine pour les
> "optimisateurs bgp"
> 
> Au passage, n'oublions pas que l'AS qui n'a pas vocation de faire du
> réseau n'est pas supposé avoir de T1 : il va plutôt avoir une paire de
> T2 qui vont lui proposer un panel qualitatif de destination;
> 
> Cordialement,
> 
> On 7/2/19 3:25 PM, Francois Devienne wrote:
>> Bonjour FRNOG,
>> 
>> Je me permets d’apporter quelques précisions au sujet des optimiseurs BGP.
>> 
>> En avant propos, la notion d’optimisation BGP ne revêt pas une forme unique. 
>> Elle était d’ailleurs souvent effectuée manuellement, de manière artisanale.
>> Quel est l’objectif de ces optimisations en général ? —> Influencer les 
>> chemins entrant ou sortant afin :
>>  - d’éviter la saturation d’une interface IX/peer ou transit connecté à 
>> l’AS concerné,
>>  - d'empêcher ou limiter des dépassements de CDR, en sollicitant une 
>> capacité sous exploitée,
>>  - de contourner un chemin qui perd des paquets (une congestion 
>> franche), alors qu’un autre chemin, de meilleure qualité est disponible,
>>  - de contourner un blackhole involontaire,
>>  - d’améliorer les performances (RTD) avec une destination pour laquelle 
>> BGP a choisi un chemin sous-optimal.
>> 
>> Pour ce faire, la manoeuvre d’optimisation s’appuie sur des mesures de 
>> performance et qualité des chemins ainsi que des collectes de données de 
>> trafic et de topologie (Flows, SNMP, BGP), éventuellement travaillées par 
>> des outils statistiques.
>> Les décisions de routage sont obtenues par l’exécution d’une politique de 
>> routage, disons un algorithme dont la forme et les paramètres sont 
>> déterminés par l’utilisateur.
>> Ensuite des configurations ou de nouvelles routes BGP sont envoyées aux 
>> routeurs BGP à l’edge.
>> 
>> On pourrait alors argumenter que BGP suffit largement et que l’Internet 
>> marche très bien sans optimisation. Les statistiques montrent néanmoins que 
>> cela est faux. Sur un échantillon d’une dizaine d’AS en France, 
>> essentiellement connectées à des tiers 1 (deux transitaires au moins :-), 
>> plus de 50% des décisions de BGP sont sous-optimales. Parfois pour des 
>> différences négligeables, parfois pour quelques dizaines de millisecondes, 
>> ou encore pour 5% de perte de paquets. BGP ne voyant naturellement ni le RTD 
>> ni le packet loss end-to-end. Idem pour la gestion de capacité contractuelle 
>> ou physique.
>> 
>> Décrire le ROI d’un optimiseur BGP de façon absolue est néanmoins 
>> impossible. Chaque AS écoule un trafic de typologie propre et exploite des 
>> connectivités qui acheminent ces flux particuliers selon des paramètres et 

Re: [FRnOG] [TECH] solution WAF

[Renaud Chaput]

 C’est pas on-premise, mais j’aimerais aussi mentionner
https://www.sqreen.com qui est une bonne alternative / complément au WAF.
La différence est que c’est chargé dans votre application, donc ça a une
meilleure vue de ce qui s’y passe et peut détecter plus de choses, plus
facilement (genre attention, là votre process web essaie de lire
/etc/shadow, c’est pas très normal, ou inspecter directement les requêtes
SQL qui sont faites depuis l'app).

C’est tout jeune et français, mais bien novateur et efficace. Je ne bosse
pas pour eux, je connais juste les fondateurs et j’utilise, mais l’approche
est vraiment smart.

Renaud

On 2 Jul 2019 at 17:23 +0200, Wallace , wrote:

Pour avoir testé deux offres avec dépendances, j'ai vu les très gros
inconvénients.

Je peux citer :

- le délai de traitement qui se rallonge de quelques minutes à quelques
heures pour du traitement que j'aurais espéré pratiquement temps réel parce
que l'infra cloud rame

- la même lorsque bien sur un client est bloqué par le waf, qu'il faut
aller éditer des règles de filtrage et que l'interface web / api ne
fonctionne plus pour maintenance ou indisponibilité ...

- dans une de nos solutions éprouvées, l'entreprise est tombée en silence
radio du jour au lendemain, plus de news, plus personne joignable, problème
l'intelligence du produit n'est pas chez nous, on est pas autonome si la
partie cloud s'arrête en cas de faillite ou autre. Il en va de même pour
une entreprise qui déciderait de changer brutalement le mode économique

- le fait que pour gérer des règles, des configurations il faille passer
par une interface web ou api alors qu'on sait très bien gérer des
configurations en fichier ou BD à partir d'outils d'infras as a code. Coder
tous les 4 matins des interfaces API ça nous botte pas surtout quand elles
changent sans prévenir.

- avoir des limites dans les possibilités de réglage parce que l'interface
ne l'a pas encore prévu ou que c'est by design, en full local s'il faut
monter un contournement on est autonome pour le faire et régler comme on le
souhaite

C'est pour cela que nous nous orientons doucement vers modsecurity / naxsi
où l'on aura pleine maitrise des réglages, néanmoins je ne suis pas fermé à
découvrir d'autres produits. On ne cherche pas de l'open source à tout
prix, seulement d'avoir une solution autonome et ne pas dépendre de tiers,
donc des logiciels sous Linux avec licence oui c'est possible.


Le 02/07/2019 à 15:48, Stephane Pham a écrit :

hey,

Le on prem sans dépendance dans le "cloud" est vraiment un pré-requis ?

Le lun. 1 juil. 2019 à 16:08, Laurent-Charles Fabre  a
écrit :

Bonjour,

nous pour les clients Denyall qui a fusionné avec beware et qui maintenant
ça s’appelle Rohde 

Directeur technique disponible pour causer
appliance ou vm
modèle commercial adaptable pour les hébergeurs.
Accessoirement, c’est béni par l'ANSSI

Laurent-Charles Fabre



> Le 1 juil. 2019 à 08:32, Ludovic RAMOSFILIPE  a
écrit :
>
> Salut,
>
> Sinon il y a aussi fortinet fortiweb
>
> Le dim. 30 juin 2019 à 18:30, Alexandre DERUMIER  a
> écrit :
>
>> Wallarm ca marche pas mal en effet, par contre c'est hors de prix.
>>
>> et pour avoir négocier avec leur commerciaux, c'est vraiment pas le genre
>> de démarche commerciale que j'aime.
>> (tarif non public, à la tete du client, tu fais le mort , bam t'as une
>> ristourne de 50%)
>>
>> Enfin bref...
>>
>>
>>
>>
>> Perso, j'utilise pour mes clients
>>
>> https://bitninja.io/   (entre 10-40€ par mois/par serveur. ca dépend du
>> nombre d'utilisateur sur le serveur. (uid>1000)
>>
>>
>> ca fait en autre waf (basé sur modsecurity), mais le plus interessant
>> c'est la réputation d'ip collaborative (whitelist/greylist + captcha).
>>
>> j'avais testé justement avec wallarm derriere, il me restait quelques
>> injections sql qui passait encore derrière, on va dire 1% avec dedans pas
>> mal de faux positif.
>>
>>
>>
>> sinon j'attend avec impatience la sortie de darwin du projet vulture, qui
>> sera un waf machine learning intégré à haproxy.
>> https://2018.pass-the-salt.org/files/talks/13-vulture.pdf
>>
>>
>>
>> - Mail original -
>> De: "Wallace" 
>> À: "frnog-tech" 
>> Envoyé: Jeudi 27 Juin 2019 13:00:40
>> Objet: [FRnOG] [TECH] solution WAF
>>
>>
>>
>> Bonjour à tous,
>>
>> On exploite du WAF en amont de certains clients, on est passé par les
>> étapes Naxsi, IngenSec (qui a fermé), Wallarm.
>>
>> On est assez content de Wallarm même s'il reste des améliorations à faire
>> et que techniquement on est pas fan d'une partie on premise avec une
>> dépendance dans le cloud que l'on ne maitrise pas. Par contre leur modèle
>> commercial n'est pas adapté à ce que l'on désire mettre en place se
basant
>> sur un coût par host au lieu d'un coût par domaine / site ou hits.
>>
>> Du coup qu'avez-vous testé et éprouvé en solutions WAF on premise
tournant
>> sous Linux?
>>
>>
>> Merci par avance.
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
> --
>
>
>

RE: [FRnOG] [TECH] Transit et déni de service

[Michel Py]

> Paul Rolland a écrit :
> Marrant, c'est la question que je me posais justement hier en lisant les 
> posts et les articles... Si tu
> te fais DDoS ton port, effectivement, BGP, c'est comme le reste de ton 
> traffic, ca a du mal a passer.
> Du coup, est-ce qu'il y a eu des debuts de reflexion sur le fait de faire 
> passer une session dedie BGP
> flowspec en OoB / multihops ? Parce que la, comme le fait remarquer Raph, en 
> cas de saturation du port,
> je vois pas comment ca va le faire.

Justement j'étais en train de travailler là-dessus avec UTRS avec le même 
raisonnement :
Si mon site principal est saturé par une attaque, la seule solution c'est 
d'avoir une session, probablement multihop, venant d'un site satellite. Disons 
que de la maison ou de MacDo je me connectes à mon site satellite pour 
configure parce que ce que je fais du site principal c'est down. Pour 
l'instant, pas possible. C'est clair que tout ce qui est BGP il faut avoir une 
infra d'injection indépendante.


> Raphael Maunier a écrit :
> Pour moi le blackhole n’est pas une solution, l’attaquant a gagné :)

Sur ce coup-là je ne suis pas d'accord avec toi. Ca permet de limiter la casse, 
dans certaines situations. Si j'ai une saturation de port et que de blackholer 
1 IP en amont çà me permet de garder le reste du réseau, je vais pas réfléchir 
trop longtemps et malheureusement sacrifier la victime pour sauver le reste. Je 
vois la situation comme çà : l'attaquant avait déjà gagné; intellectuellement, 
j'aimerais bien avoir les moyens de m'offrir arbor, dans la pratique je ne les 
ai pas. Le blackhole, c'est la solution du pauvre.

Oh et aucune relation avec ce fil, mais je viens de tomber sur çà :
https://github.com/tarraschk/richelieu/blob/master/french_passwords_top5000.txt

Michel.


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

Re: [FRnOG] [TECH] solution WAF

[Alexis Prodhomme]

J'ai lu en zigzag ce fil, mais je n'ai pas vu passer Vulture Project.

C'est un WAF local (ou plutôt une surcouche) basé sur FreeBSD, Apache et 
Mod_Security. Il y a tout de même, si je ne m'abuse, des dépendances "cloud" 
dans le sens ou les listes de filtrage sont récupérées depuis l'OWASP ... Mais 
en cas de soucis, ça supprime juste le côté "automagique" sans trop être 
pénalisant (suffit juste d'adapter les regex contenues dans les fichiers).

Les devs sont français (Lille). Il y a quelques releases de temps en temps, le 
projet avance régulièrement.

L'interface est assez propre, la documentation est relativement bien faite 
(mais mal indexée sur Google).
Y'a du mongodb (pour la conf répliquée), du haproxy, du redis, du packetfilter, 
du elastic, bref, plein de technos géniales et jeunes.
Ça gère la compression, les certificats, la haute dispo, le SSO, la répartition 
de charge nativement par exemple.

Vulture a probablement des défauts, mais il peut faire le job suivant vos 
besoins.

Il répondait vraiment à notre besoin quand nous avions creusé le sujet y'a ~2 
ans.
Je n'ai aucune expérience sur d'autres WAF, donc je ne sais pas si les autres 
sont mieux, pires, si Vulture est génial ou mauvais  Il répond juste à ce 
que nous voulions :D

Lien du produit : https://www.vultureproject.org/
Doc : https://www.vultureproject.org/doc/

Alexis

Le 02/07/2019 à 17:21, Wallace a écrit :

Pour avoir testé deux offres avec dépendances, j'ai vu les très gros 
inconvénients.

Je peux citer :

- le délai de traitement qui se rallonge de quelques minutes à quelques heures 
pour du traitement que j'aurais espéré pratiquement temps réel parce que 
l'infra cloud rame

- la même lorsque bien sur un client est bloqué par le waf, qu'il faut aller 
éditer des règles de filtrage et que l'interface web / api ne fonctionne plus 
pour maintenance ou indisponibilité ...

- dans une de nos solutions éprouvées, l'entreprise est tombée en silence radio 
du jour au lendemain, plus de news, plus personne joignable, problème 
l'intelligence du produit n'est pas chez nous, on est pas autonome si la partie 
cloud s'arrête en cas de faillite ou autre. Il en va de même pour une 
entreprise qui déciderait de changer brutalement le mode économique

- le fait que pour gérer des règles, des configurations il faille passer par 
une interface web ou api alors qu'on sait très bien gérer des configurations en 
fichier ou BD à partir d'outils d'infras as a code. Coder tous les 4 matins des 
interfaces API ça nous botte pas surtout quand elles changent sans prévenir.

- avoir des limites dans les possibilités de réglage parce que l'interface ne 
l'a pas encore prévu ou que c'est by design, en full local s'il faut monter un 
contournement on est autonome pour le faire et régler comme on le souhaite

C'est pour cela que nous nous orientons doucement vers modsecurity / naxsi où 
l'on aura pleine maitrise des réglages, néanmoins je ne suis pas fermé à 
découvrir d'autres produits. On ne cherche pas de l'open source à tout prix, 
seulement d'avoir une solution autonome et ne pas dépendre de tiers, donc des 
logiciels sous Linux avec licence oui c'est possible.


Le 02/07/2019 à 15:48, Stephane Pham a écrit :
hey,

Le on prem sans dépendance dans le "cloud" est vraiment un pré-requis ?

Le lun. 1 juil. 2019 à 16:08, Laurent-Charles Fabre 
mailto:lc.fa...@gmail.com>> a écrit :
Bonjour,

nous pour les clients Denyall qui a fusionné avec beware et qui maintenant ça 
s’appelle Rohde 

Directeur technique disponible pour causer
appliance ou vm
modèle commercial adaptable pour les hébergeurs.
Accessoirement, c’est béni par l'ANSSI

Laurent-Charles Fabre



> Le 1 juil. 2019 à 08:32, Ludovic RAMOSFILIPE 
> mailto:l.ra...@sct-telecom.fr>> a écrit :
>
> Salut,
>
> Sinon il y a aussi fortinet fortiweb
>
> Le dim. 30 juin 2019 à 18:30, Alexandre DERUMIER 
> mailto:aderum...@odiso.com>> a
> écrit :
>
>> Wallarm ca marche pas mal en effet, par contre c'est hors de prix.
>>
>> et pour avoir négocier avec leur commerciaux, c'est vraiment pas le genre
>> de démarche commerciale que j'aime.
>> (tarif non public, à la tete du client, tu fais le mort , bam t'as une
>> ristourne de 50%)
>>
>> Enfin bref...
>>
>>
>>
>>
>> Perso, j'utilise pour mes clients
>>
>> https://bitninja.io/   (entre 10-40€ par mois/par serveur. ca dépend du
>> nombre d'utilisateur sur le serveur. (uid>1000)
>>
>>
>> ca fait en autre waf (basé sur modsecurity), mais le plus interessant
>> c'est la réputation d'ip collaborative (whitelist/greylist + captcha).
>>
>> j'avais testé justement avec wallarm derriere, il me restait quelques
>> injections sql qui passait encore derrière, on va dire 1% avec dedans pas
>> mal de faux positif.
>>
>>
>>
>> sinon j'attend avec impatience la sortie de darwin du projet vulture, qui
>> sera un waf machine learning intégré à haproxy.
>> https://2018.pass-the-salt.org/files/talks/13-vulture.pdf
>>
>>
>>
>> - Mail original -
>> De: "Wallace" 

Re: [FRnOG] [TECH] solution WAF

[Wallace]

Pour avoir testé deux offres avec dépendances, j'ai vu les très gros
inconvénients.

Je peux citer :

- le délai de traitement qui se rallonge de quelques minutes à quelques
heures pour du traitement que j'aurais espéré pratiquement temps réel
parce que l'infra cloud rame

- la même lorsque bien sur un client est bloqué par le waf, qu'il faut
aller éditer des règles de filtrage et que l'interface web / api ne
fonctionne plus pour maintenance ou indisponibilité ...

- dans une de nos solutions éprouvées, l'entreprise est tombée en
silence radio du jour au lendemain, plus de news, plus personne
joignable, problème l'intelligence du produit n'est pas chez nous, on
est pas autonome si la partie cloud s'arrête en cas de faillite ou
autre. Il en va de même pour une entreprise qui déciderait de changer
brutalement le mode économique

- le fait que pour gérer des règles, des configurations il faille passer
par une interface web ou api alors qu'on sait très bien gérer des
configurations en fichier ou BD à partir d'outils d'infras as a code.
Coder tous les 4 matins des interfaces API ça nous botte pas surtout
quand elles changent sans prévenir.

- avoir des limites dans les possibilités de réglage parce que
l'interface ne l'a pas encore prévu ou que c'est by design, en full
local s'il faut monter un contournement on est autonome pour le faire et
régler comme on le souhaite

C'est pour cela que nous nous orientons doucement vers modsecurity /
naxsi où l'on aura pleine maitrise des réglages, néanmoins je ne suis
pas fermé à découvrir d'autres produits. On ne cherche pas de l'open
source à tout prix, seulement d'avoir une solution autonome et ne pas
dépendre de tiers, donc des logiciels sous Linux avec licence oui c'est
possible.


Le 02/07/2019 à 15:48, Stephane Pham a écrit :
> hey, 
>
> Le on prem sans dépendance dans le "cloud" est vraiment un pré-requis ?
>
> Le lun. 1 juil. 2019 à 16:08, Laurent-Charles Fabre
> mailto:lc.fa...@gmail.com>> a écrit :
>
> Bonjour,
>
> nous pour les clients Denyall qui a fusionné avec beware et qui
> maintenant ça s’appelle Rohde 
>
> Directeur technique disponible pour causer
> appliance ou vm
> modèle commercial adaptable pour les hébergeurs.
> Accessoirement, c’est béni par l'ANSSI
>
> Laurent-Charles Fabre
>
>
>
> > Le 1 juil. 2019 à 08:32, Ludovic RAMOSFILIPE
> mailto:l.ra...@sct-telecom.fr>> a écrit :
> >
> > Salut,
> >
> > Sinon il y a aussi fortinet fortiweb
> >
> > Le dim. 30 juin 2019 à 18:30, Alexandre DERUMIER
> mailto:aderum...@odiso.com>> a
> > écrit :
> >
> >> Wallarm ca marche pas mal en effet, par contre c'est hors de prix.
> >>
> >> et pour avoir négocier avec leur commerciaux, c'est vraiment
> pas le genre
> >> de démarche commerciale que j'aime.
> >> (tarif non public, à la tete du client, tu fais le mort , bam
> t'as une
> >> ristourne de 50%)
> >>
> >> Enfin bref...
> >>
> >>
> >>
> >>
> >> Perso, j'utilise pour mes clients
> >>
> >> https://bitninja.io/   (entre 10-40€ par mois/par serveur. ca
> dépend du
> >> nombre d'utilisateur sur le serveur. (uid>1000)
> >>
> >>
> >> ca fait en autre waf (basé sur modsecurity), mais le plus
> interessant
> >> c'est la réputation d'ip collaborative (whitelist/greylist +
> captcha).
> >>
> >> j'avais testé justement avec wallarm derriere, il me restait
> quelques
> >> injections sql qui passait encore derrière, on va dire 1% avec
> dedans pas
> >> mal de faux positif.
> >>
> >>
> >>
> >> sinon j'attend avec impatience la sortie de darwin du projet
> vulture, qui
> >> sera un waf machine learning intégré à haproxy.
> >> https://2018.pass-the-salt.org/files/talks/13-vulture.pdf
> >>
> >>
> >>
> >> - Mail original -
> >> De: "Wallace" mailto:wall...@morkitu.org>>
> >> À: "frnog-tech"  >
> >> Envoyé: Jeudi 27 Juin 2019 13:00:40
> >> Objet: [FRnOG] [TECH] solution WAF
> >>
> >>
> >>
> >> Bonjour à tous,
> >>
> >> On exploite du WAF en amont de certains clients, on est passé
> par les
> >> étapes Naxsi, IngenSec (qui a fermé), Wallarm.
> >>
> >> On est assez content de Wallarm même s'il reste des
> améliorations à faire
> >> et que techniquement on est pas fan d'une partie on premise
> avec une
> >> dépendance dans le cloud que l'on ne maitrise pas. Par contre
> leur modèle
> >> commercial n'est pas adapté à ce que l'on désire mettre en
> place se basant
> >> sur un coût par host au lieu d'un coût par domaine / site ou hits.
> >>
> >> Du coup qu'avez-vous testé et éprouvé en solutions WAF on
> premise tournant
> >> sous Linux?
> >>
> >>
> >> Merci par avance.
> >>
> >>
> >> ---
> >> Liste de 

Re: [FRnOG] [ALERT] Cloudflare

[Fabien Germain]

Hello,

Le 02/07/2019 16:10, Maxence Rousseau a écrit :

Des soucis chez Cloudflare ?

Cela passe un peu mieux sur AMSIX (genre 5 min de temps de
chargement), rien ne marchait sur Equinix

Pas de twit', pas d'info, donc je me sens un peu seul, allo ?


De notre côté ça semble revenu, mais effectivement peu d'info. Juste ça 
: https://www.cloudflarestatus.com/incidents/tx4pgxs6zxdr


Fabien


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

Re: [FRnOG] [MISC] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP

[Alexandre Bruyelles]

Les optimiseurs bgp, ce sont de mauvaises solutions à un vrai problème

Le vrai problème : quand tu as X liens pourris vers une destination X,
ta "qualité" n'est pas terrible (voir problématique)

La fausse solution : faisont du vaudoo pour essayer de "choisir" le
meilleur des mauvais liens

La bonne solution : mettre en production de bons liens


En effet, plusieurs possibilités:
- soit tu te moques de la destination X (c'est un vague AS en
biélorussie, OSEF). Dans ce cas, tu te moques aussi de la qualité que tu
as vers cet AS.
- soit la destination X est importante pour ton business, et du coup, au
choix:
  - tu setup un PNI avec X
  - tu te connectes à un IX pour joindre X
  - tu te connectes à un transitaire qui est bon pour communiquer avec X


Si tu deploies l'algorithme, il n'y a pas de place saine pour les
"optimisateurs bgp"

Au passage, n'oublions pas que l'AS qui n'a pas vocation de faire du
réseau n'est pas supposé avoir de T1 : il va plutôt avoir une paire de
T2 qui vont lui proposer un panel qualitatif de destination;

Cordialement,

On 7/2/19 3:25 PM, Francois Devienne wrote:
> Bonjour FRNOG,
> 
> Je me permets d’apporter quelques précisions au sujet des optimiseurs BGP.
> 
> En avant propos, la notion d’optimisation BGP ne revêt pas une forme unique. 
> Elle était d’ailleurs souvent effectuée manuellement, de manière artisanale.
> Quel est l’objectif de ces optimisations en général ? —> Influencer les 
> chemins entrant ou sortant afin :
>   - d’éviter la saturation d’une interface IX/peer ou transit connecté à 
> l’AS concerné,
>   - d'empêcher ou limiter des dépassements de CDR, en sollicitant une 
> capacité sous exploitée,
>   - de contourner un chemin qui perd des paquets (une congestion 
> franche), alors qu’un autre chemin, de meilleure qualité est disponible,
>   - de contourner un blackhole involontaire,
>   - d’améliorer les performances (RTD) avec une destination pour laquelle 
> BGP a choisi un chemin sous-optimal.
> 
> Pour ce faire, la manoeuvre d’optimisation s’appuie sur des mesures de 
> performance et qualité des chemins ainsi que des collectes de données de 
> trafic et de topologie (Flows, SNMP, BGP), éventuellement travaillées par des 
> outils statistiques.
> Les décisions de routage sont obtenues par l’exécution d’une politique de 
> routage, disons un algorithme dont la forme et les paramètres sont déterminés 
> par l’utilisateur.
> Ensuite des configurations ou de nouvelles routes BGP sont envoyées aux 
> routeurs BGP à l’edge.
> 
> On pourrait alors argumenter que BGP suffit largement et que l’Internet 
> marche très bien sans optimisation. Les statistiques montrent néanmoins que 
> cela est faux. Sur un échantillon d’une dizaine d’AS en France, 
> essentiellement connectées à des tiers 1 (deux transitaires au moins :-), 
> plus de 50% des décisions de BGP sont sous-optimales. Parfois pour des 
> différences négligeables, parfois pour quelques dizaines de millisecondes, ou 
> encore pour 5% de perte de paquets. BGP ne voyant naturellement ni le RTD ni 
> le packet loss end-to-end. Idem pour la gestion de capacité contractuelle ou 
> physique.
> 
> Décrire le ROI d’un optimiseur BGP de façon absolue est néanmoins impossible. 
> Chaque AS écoule un trafic de typologie propre et exploite des connectivités 
> qui acheminent ces flux particuliers selon des paramètres et événements non 
> déterministes.
> Néanmoins, certains AS pensent avoir des performances et une qualité 
> convenables parce qu’ils n’ont aucun outil de mesures fiable. La “logique” 
> étant alors “Tant que je n’ai pas l’impression que ça déconne, c’est 
> certainement que ça marche très bien”.
> 
> Il existe aujourd’hui deux grandes familles de solutions “d’optimiseurs”.
>   - Fait-maison : un certain nombre de grands producteurs de contenus, 
> d’hébergeurs, de CDN ou d’opérateurs ont développé leurs propres solutions de 
> mesure et d’automatisation du routage. Elles implémentent entièrement ou 
> partiellement ce que font les solutions commerciales. Il s’agit alors de code 
> propriétaire ou souvent d’agrégats de briques open source notamment pour la 
> collecte d’échantillons de trafic.
>   - Commerciaux : principalement trois solutions aujourd’hui :
>   - Internap MIRO / FCP = assez confidentiel
>   - Noction IRP = celui incriminé dans ce problème
>   - Border 6 NSI (Expereo XCA-Edge) = C’est nous, pour enlever 
> toute ambiguité. Technologie Française !
> Ainsi, il n’existe aucune norme / RFC ou définition communément admise de la 
> façon dont ces optimisations doivent être faites. 
> Chacun fait donc comme bon lui semble et certains apprennent de leurs erreurs.
> 
> L’exemple du problème cité ici montre en effet que certains optimiseurs 
> découpent les subnets en deux pour les rendre “plus spécifiques” et qu’ils 
> deviennent ainsi préférés dans la table BGP et la table de routage.
> Si 8.8.8.0/24 est routé via transit “A” avec 

Re: [FRnOG] [ALERT] Cloudflare

[Manuel Guesdon]

Hello,

On Tue, 2 Jul 2019 16:10:07 +0200
Maxence Rousseau  wrote:
>| Des soucis chez Cloudflare ?
>| 
>| 
>| Cela passe un peu mieux sur AMSIX (genre 5 min de temps de chargement), 
>| rien ne marchait sur Equinix

Problèmes aussi il y a quelques minutes pour accéder à un site qui passe par
chez eux: "Bad gateway" alors que le site en direct est OK...
La c'est mieux...

Manuel 

--
__
Manuel Guesdon - OXYMIUM


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

Re: [FRnOG] [TECH] Problème chez SFR ?

[Arthur Pellissier]

Oui problème généralisé chez Cloudflare, tout est down 
https://www.cloudflarestatus.com/incidents/tx4pgxs6zxdr 



  Arthur Pellissier
   M. : 06 88 02 14 17 
  arthurpelliss...@gmail.com

> Le 2 juil. 2019 à 16:09, David Fontaine  a écrit :
> 
> Ca ne serait pas un pb avec cloudfare? 
> 
> Mes utilisateurs me remontent des pb d'accès sur des sites utilisant leurs 
> services (doctolib, eurecia etc..)
> 
> Leur site est down https://www.cloudflare.com/fr-fr/ , erreur 502
> 
> David
> 
> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de Sebastien
> Envoyé : mardi 2 juillet 2019 16:00
> À : frnog-t...@frnog.org
> Objet : [FRnOG] [TECH] Problème chez SFR ?
> 
> Bonjour,
> 
> Plusieurs clients nous remontent des problème d'accès à notre réseau, 
> visiblement les quelques MTR que nous avons pu avoir semblent indiquer des 
> pertes de paquets sur le réseau de SFR.
> 
> Sommes nous les seuls à constater le problème ?
> 
> Merci d'avance.
> 
> Séb
> 
> 
> ---
> 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] Cloudflare

[Aurelien Kempiak]

Salut Maxence,

Oui => https://www.cloudflarestatus.com/

Cdt,

Le 02/07/2019 à 16:10, Maxence Rousseau a écrit :

Bonjour à tous,


Des soucis chez Cloudflare ?


Cela passe un peu mieux sur AMSIX (genre 5 min de temps de 
chargement), rien ne marchait sur Equinix



Pas de twit', pas d'info, donc je me sens un peu seul, allo ?



--



*Aurélien* *Kempiak*
*System & Network Engineer*

*Fixe :* 03 59 82 20 05

125 Avenue de la République 59110 La Madeleine
12 rue Marivaux 75002 Paris

 
 
 




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

Re: [FRnOG] [ALERT] Cloudflare

[Michel 'ic' Luczak]

C’est écrit sur leur page de statut :)

https://www.cloudflarestatus.com 

Même si c’est un peu “understated"

> On 2 Jul 2019, at 16:10, Maxence Rousseau  wrote:
> 
> Bonjour à tous,
> 
> 
> Des soucis chez Cloudflare ?
> 
> 
> Cela passe un peu mieux sur AMSIX (genre 5 min de temps de chargement), rien 
> ne marchait sur Equinix
> 
> 
> Pas de twit', pas d'info, donc je me sens un peu seul, allo ?
> 
> 
> -- 
> Maxence Rousseau
> mrouss...@ate.info
> ATE - Avenir télématique
> http://www.ate.info
> +33(0)3.28.800.300
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Problème chez SFR ?

[Sebastien CHATEAU-DUTIER]

Merci du retour, mais rien qui passe par cloudfare pour nous...


Le 02/07/2019 à 16:07, donkish...@neuf.fr a écrit :


Cloudflare a un problème, si vos services sont "proxifiés" chez eux 
cela peut venir de là.


Le 02/07/2019 à 15:59, Sebastien a écrit :

Bonjour,

Plusieurs clients nous remontent des problème d'accès à notre réseau, 
visiblement les quelques MTR que nous avons pu avoir semblent 
indiquer des pertes de paquets sur le réseau de SFR.


Sommes nous les seuls à constater le problème ?

Merci d'avance.

Séb


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



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

[FRnOG] [TECH] Problème chez SFR ?

[donkish...@neuf.fr]

  
  
Cloudflare a un problème, si vos services sont "proxifiés" chez
  eux cela peut venir de là. 

Le 02/07/2019 à 15:59, Sebastien a
  écrit :

Bonjour,
  
  
  Plusieurs clients nous remontent des problème d'accès à notre
  réseau, visiblement les quelques MTR que nous avons pu avoir
  semblent indiquer des pertes de paquets sur le réseau de SFR.
  
  
  Sommes nous les seuls à constater le problème ?
  
  
  Merci d'avance.
  
  
  Séb
  
  
  
  ---
  
  Liste de diffusion du FRnOG
  
  http://www.frnog.org/
  

  

[FRnOG] [ALERT] Cloudflare

[Maxence Rousseau]

Bonjour à tous,


Des soucis chez Cloudflare ?


Cela passe un peu mieux sur AMSIX (genre 5 min de temps de chargement), 
rien ne marchait sur Equinix



Pas de twit', pas d'info, donc je me sens un peu seul, allo ?


--
Maxence Rousseau
mrouss...@ate.info
ATE - Avenir télématique
http://www.ate.info
+33(0)3.28.800.300


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

RE: [FRnOG] [TECH] Problème chez SFR ?

[David Fontaine]

Ca ne serait pas un pb avec cloudfare? 

Mes utilisateurs me remontent des pb d'accès sur des sites utilisant leurs 
services (doctolib, eurecia etc..)

Leur site est down https://www.cloudflare.com/fr-fr/ , erreur 502

David

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Sebastien
Envoyé : mardi 2 juillet 2019 16:00
À : frnog-t...@frnog.org
Objet : [FRnOG] [TECH] Problème chez SFR ?

Bonjour,

Plusieurs clients nous remontent des problème d'accès à notre réseau, 
visiblement les quelques MTR que nous avons pu avoir semblent indiquer des 
pertes de paquets sur le réseau de SFR.

Sommes nous les seuls à constater le problème ?

Merci d'avance.

Séb


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

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

[FRnOG] [TECH] Problème chez SFR ?

[Sebastien]

Bonjour,

Plusieurs clients nous remontent des problème d'accès à notre réseau, 
visiblement les quelques MTR que nous avons pu avoir semblent indiquer 
des pertes de paquets sur le réseau de SFR.


Sommes nous les seuls à constater le problème ?

Merci d'avance.

Séb


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

Re: [FRnOG] [MISC] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP

[David Ponzone]

> À quoi ça sert d’optimiser le chemin de A vers B, quand on ne peut pas faire 
> en sorte d’utiliser le même chemin dans le sens B -> A ?

Je m’auto-corrige: ou tout autre chemin optimal de B vers A, qui ne sera pas 
forcément le même que de A vers B.


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

Re: [FRnOG] [MISC] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP

[David Ponzone]

Le 2 juil. 2019 à 15:25, Francois Devienne  a 
écrit :
> 
> Bonjour FRNOG,
> 
> Je me permets d’apporter quelques précisions au sujet des optimiseurs BGP.
> 
> 
> ...[long texte plein de choses très intéressantes, merci]…
> 

> Bon appétit,
> François.
> 

François,

Vous ne répondez pas avec précision à la question essentielle: 
À quoi ça sert d’optimiser le chemin de A vers B, quand on ne peut pas faire en 
sorte d’utiliser le même chemin dans le sens B -> A ?
Evidemment, ça limite un peu la casse quand on évite de A vers B un chemin qui 
droppe, mais c’est tout.
On devrait plutôt appeler ça un demi-optimiseur non ?
Sauf si évidemment, A et B utilisent le même optimiseur.

J’imagine la réaction du client à qui on a vendu une martingale le jour où il 
découvre que:
-faut continuer à faire du fine-tuning de son BGP pour faire passer l’entrant 
par là où on voudrait (ce qui est très limité, on le sait tous)
-s’il y a un chemin hors de son contrôle qui droppe des paquets à la pelle dans 
le sens Internet vers lui, l’optimiseur va rien voir/rien faire, et y a plus 
qu’à attendre les appels des clients mécontents

J’espère que ça coûte pas trop cher ces trucs là.



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

Re: [FRnOG] [TECH] solution WAF

[Stephane Pham]

hey,

Le on prem sans dépendance dans le "cloud" est vraiment un pré-requis ?

Le lun. 1 juil. 2019 à 16:08, Laurent-Charles Fabre  a
écrit :

> Bonjour,
>
> nous pour les clients Denyall qui a fusionné avec beware et qui maintenant
> ça s’appelle Rohde 
>
> Directeur technique disponible pour causer
> appliance ou vm
> modèle commercial adaptable pour les hébergeurs.
> Accessoirement, c’est béni par l'ANSSI
>
> Laurent-Charles Fabre
>
>
>
> > Le 1 juil. 2019 à 08:32, Ludovic RAMOSFILIPE  a
> écrit :
> >
> > Salut,
> >
> > Sinon il y a aussi fortinet fortiweb
> >
> > Le dim. 30 juin 2019 à 18:30, Alexandre DERUMIER  a
> > écrit :
> >
> >> Wallarm ca marche pas mal en effet, par contre c'est hors de prix.
> >>
> >> et pour avoir négocier avec leur commerciaux, c'est vraiment pas le
> genre
> >> de démarche commerciale que j'aime.
> >> (tarif non public, à la tete du client, tu fais le mort , bam t'as une
> >> ristourne de 50%)
> >>
> >> Enfin bref...
> >>
> >>
> >>
> >>
> >> Perso, j'utilise pour mes clients
> >>
> >> https://bitninja.io/   (entre 10-40€ par mois/par serveur. ca dépend du
> >> nombre d'utilisateur sur le serveur. (uid>1000)
> >>
> >>
> >> ca fait en autre waf (basé sur modsecurity), mais le plus interessant
> >> c'est la réputation d'ip collaborative (whitelist/greylist + captcha).
> >>
> >> j'avais testé justement avec wallarm derriere, il me restait quelques
> >> injections sql qui passait encore derrière, on va dire 1% avec dedans
> pas
> >> mal de faux positif.
> >>
> >>
> >>
> >> sinon j'attend avec impatience la sortie de darwin du projet vulture,
> qui
> >> sera un waf machine learning intégré à haproxy.
> >> https://2018.pass-the-salt.org/files/talks/13-vulture.pdf
> >>
> >>
> >>
> >> - Mail original -
> >> De: "Wallace" 
> >> À: "frnog-tech" 
> >> Envoyé: Jeudi 27 Juin 2019 13:00:40
> >> Objet: [FRnOG] [TECH] solution WAF
> >>
> >>
> >>
> >> Bonjour à tous,
> >>
> >> On exploite du WAF en amont de certains clients, on est passé par les
> >> étapes Naxsi, IngenSec (qui a fermé), Wallarm.
> >>
> >> On est assez content de Wallarm même s'il reste des améliorations à
> faire
> >> et que techniquement on est pas fan d'une partie on premise avec une
> >> dépendance dans le cloud que l'on ne maitrise pas. Par contre leur
> modèle
> >> commercial n'est pas adapté à ce que l'on désire mettre en place se
> basant
> >> sur un coût par host au lieu d'un coût par domaine / site ou hits.
> >>
> >> Du coup qu'avez-vous testé et éprouvé en solutions WAF on premise
> tournant
> >> sous Linux?
> >>
> >>
> >> Merci par avance.
> >>
> >>
> >> ---
> >> Liste de diffusion du FRnOG
> >> http://www.frnog.org/
> >>
> > --
> >
> >
> >
> >
> >
> >
> >
> > Ludovic Ramos | Responsable VOIP
> >
> > | *SCT TELECOM *| La plaine saint denis
> > | phone: 0 <892020220>892020220
> > | email: l.ra...@sct-telecom.fr
> > | site:  www.sct-telecom.fr
> > | skype: ludovic.ramos95
> > | address:  17-19 avenue de la metallurgie
> >  <
> https://twitter.com/SCT_Telecom_>
> > 
> > 
> >
> > ---
> > 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] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP

[Francois Devienne]

Bonjour FRNOG,

Je me permets d’apporter quelques précisions au sujet des optimiseurs BGP.

En avant propos, la notion d’optimisation BGP ne revêt pas une forme unique. 
Elle était d’ailleurs souvent effectuée manuellement, de manière artisanale.
Quel est l’objectif de ces optimisations en général ? —> Influencer les chemins 
entrant ou sortant afin :
- d’éviter la saturation d’une interface IX/peer ou transit connecté à 
l’AS concerné,
- d'empêcher ou limiter des dépassements de CDR, en sollicitant une 
capacité sous exploitée,
- de contourner un chemin qui perd des paquets (une congestion 
franche), alors qu’un autre chemin, de meilleure qualité est disponible,
- de contourner un blackhole involontaire,
- d’améliorer les performances (RTD) avec une destination pour laquelle 
BGP a choisi un chemin sous-optimal.

Pour ce faire, la manoeuvre d’optimisation s’appuie sur des mesures de 
performance et qualité des chemins ainsi que des collectes de données de trafic 
et de topologie (Flows, SNMP, BGP), éventuellement travaillées par des outils 
statistiques.
Les décisions de routage sont obtenues par l’exécution d’une politique de 
routage, disons un algorithme dont la forme et les paramètres sont déterminés 
par l’utilisateur.
Ensuite des configurations ou de nouvelles routes BGP sont envoyées aux 
routeurs BGP à l’edge.

On pourrait alors argumenter que BGP suffit largement et que l’Internet marche 
très bien sans optimisation. Les statistiques montrent néanmoins que cela est 
faux. Sur un échantillon d’une dizaine d’AS en France, essentiellement 
connectées à des tiers 1 (deux transitaires au moins :-), plus de 50% des 
décisions de BGP sont sous-optimales. Parfois pour des différences 
négligeables, parfois pour quelques dizaines de millisecondes, ou encore pour 
5% de perte de paquets. BGP ne voyant naturellement ni le RTD ni le packet loss 
end-to-end. Idem pour la gestion de capacité contractuelle ou physique.

Décrire le ROI d’un optimiseur BGP de façon absolue est néanmoins impossible. 
Chaque AS écoule un trafic de typologie propre et exploite des connectivités 
qui acheminent ces flux particuliers selon des paramètres et événements non 
déterministes.
Néanmoins, certains AS pensent avoir des performances et une qualité 
convenables parce qu’ils n’ont aucun outil de mesures fiable. La “logique” 
étant alors “Tant que je n’ai pas l’impression que ça déconne, c’est 
certainement que ça marche très bien”.

Il existe aujourd’hui deux grandes familles de solutions “d’optimiseurs”.
- Fait-maison : un certain nombre de grands producteurs de contenus, 
d’hébergeurs, de CDN ou d’opérateurs ont développé leurs propres solutions de 
mesure et d’automatisation du routage. Elles implémentent entièrement ou 
partiellement ce que font les solutions commerciales. Il s’agit alors de code 
propriétaire ou souvent d’agrégats de briques open source notamment pour la 
collecte d’échantillons de trafic.
- Commerciaux : principalement trois solutions aujourd’hui :
- Internap MIRO / FCP = assez confidentiel
- Noction IRP = celui incriminé dans ce problème
- Border 6 NSI (Expereo XCA-Edge) = C’est nous, pour enlever 
toute ambiguité. Technologie Française !
Ainsi, il n’existe aucune norme / RFC ou définition communément admise de la 
façon dont ces optimisations doivent être faites. 
Chacun fait donc comme bon lui semble et certains apprennent de leurs erreurs.

L’exemple du problème cité ici montre en effet que certains optimiseurs 
découpent les subnets en deux pour les rendre “plus spécifiques” et qu’ils 
deviennent ainsi préférés dans la table BGP et la table de routage.
Si 8.8.8.0/24 est routé via transit “A” avec 35ms de RTD mais que transit “B” 
montre un délai de 2ms, l’optimiseur envoie deux routes BGP 8.8.8.0/25 et 
8.8.8.128/25 avec comme next-hop transit “B”.
Ceci pose un sérieux problème car si vos filtres sortants sont (très) mal 
configurés et que vos transitaires ou peer d’IX acceptent n’importent quoi, 
vous pouvez hijacker une partie de l’Internet et aspirer du trafic d’autres 
notamment.
Mais cela arrive quotidiennement à plus petite échelle avec des lascars qui 
font simplement n’importe quoi dans une configuration (sans optimiseur).

D’ailleurs, pourquoi diable découper ces subnets ? En général un routeur BGP 
“A” ne renvoie pas à un routeur BGP “B” une best route qu’il a apprise de 
routeur “B”. Je dis "en général" car cela semble être une règle 
d’implémentation mais il y a débat sur l’origine et l’universalité de cette 
règle. L’optimiseur perd alors la visibilité sur les routes potentiellement 
disponibles s’il ne les a pas découpées en les annonçant.

Il est dans tous les cas recommandé de tagger une communauté NO_EXPORT.
Il est aussi possible de désactiver ce découpage des subnets (en tout cas chez 
nous) et en apprenant les routes BGP autrement que par la session BGP.

Concernant les 

Re: [FRnOG] [TECH] Transit et déni de service

[Raphael Maunier]

Il y a plusieurs sujets dans ce cas :
- Attaque du routeur directement
- Avoir des filtres propre sur le routeur ou des ip non 
routées/routable sur le routeur de bordure vers les transitaires : Si tu as des 
peerings sur ce edge, ben le coup des ip , ça marche plus.
- Avoir largement la BP pour ne pas saturer les ports d’uplinks 
: Quand tu te prends 20/30G c’est gérable facilement. Quand tu te prends 200G, 
c’est un autre sujet
- Attague avec le routeur en “transit”
- Si l’attaque est petite (<50G) : ça passe  et avec un vrai 
routeur ( non, non je ne lance le trop sur les routeurs laiton), tu peux mettre 
des filtres (genre BCP38 et +++ ) et faire du flowspec sur ton reseau
- Si attaque moyenne >50G <200G : Tu peux te debrouiller pour 
n’exporter que le prefixe concerné sur un transitaire , le depref et sortir par 
ailleur et attendre que ça passe :)
- Si attaque >200G : Il faut acheter un service chez qqn stou

Pour moi le blackhole n’est pas une solution, l’attaquant a gagné :)

Raphael

> On 2 Jul 2019, at 10:04, Paul Rolland (ポール・ロラン)  wrote:
> 
> Hello,
> 
> On Tue, 2 Jul 2019 00:29:55 +0200
> Raphael Maunier  wrote:
> 
>> Flowspec seul en inter-isp ça ne suffit pas car des lors que ton bgp
>> flappe ( port full par ex ) bah… ça marche plus trop.
> 
> Marrant, c'est la question que je me posais justement hier en lisant les
> posts et les articles... Si tu te fais DDoS ton port, effectivement, BGP,
> c'est comme le reste de ton traffic, ca a du mal a passer.
> Du coup, est-ce qu'il y a eu des debuts de reflexion sur le fait de faire
> passer une session dedie BGP flowspec en OoB / multihops ? 
> 
> Parce que la, comme le fait remarquer Raph, en cas de saturation du port,
> je vois pas comment ca va le faire.
> 
> Paul
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Transit et déni de service

[Paul Rolland (ポール・ロラン)]

Hello,

On Tue, 2 Jul 2019 00:29:55 +0200
Raphael Maunier  wrote:

> Flowspec seul en inter-isp ça ne suffit pas car des lors que ton bgp
> flappe ( port full par ex ) bah… ça marche plus trop.

Marrant, c'est la question que je me posais justement hier en lisant les
posts et les articles... Si tu te fais DDoS ton port, effectivement, BGP,
c'est comme le reste de ton traffic, ca a du mal a passer.
Du coup, est-ce qu'il y a eu des debuts de reflexion sur le fait de faire
passer une session dedie BGP flowspec en OoB / multihops ? 

Parce que la, comme le fait remarquer Raph, en cas de saturation du port,
je vois pas comment ca va le faire.

Paul


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

Re: [FRnOG] [TECH] Transit et déni de service

[Alarig Le Lay]

Hello,

On jeu. 27 juin 20:28:47 2019, Xavier Beaudouin wrote:
> Après ça fait quelques temps et donc le paysage a peut-être changé...
> (eg je sais pas si des transitaires sont BGP Flowspec compatibles par
> exemple).

La dernière fois (il y a moins d’un an) que je me suis intéressé à du
BGP FlowSpec en eBGP personne n’a su m’en livrer. J’ai même des
transitaires qui m’ont demandé ce que c’était !

-- 
Alarig


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

Re: [FRnOG] [TECH] Transit et déni de service

[Emmanuel DECAEN]

Bonjour,

Le 01/07/2019 à 19:21, Alexandre BATON a écrit :
>>> Et pourquoi pas BGP flowspec mais là c'est carrément du rêve pour moi. Mon 
>>> transit principal il a jamais entendu parler des communautés :-(
>>
>> J'avoue que je ne l'avais pas envisagé initialement, mais vu que BGP
>> flowspec commence à être proposé, cela me tente pas mal :-).
>>
> BGP Flowspec me fait aussi de l’oeil mais mes transits actuels n’en font pas… 
> Vous avez une liste de fournisseurs de transit en France qui le propose ? 

Je suis également preneur d'une liste.

Pour le moment, j'ai un contact avec un opérateur français le mettant en
oeuvre pour son offre anti-DDoS.
Je le laisse réagir ici s'il le souhaite.

Merci.
-- 
*Emmanuel DECAEN*
E-Mail: e...@xsalto.com

www.xsalto.com
Tél: 04 92 36 60 06
Support: 04 92 36 60 07
Fax: 04 92 36 19 75

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