Re: [FRnOG] [TECH] Attaques par amplification NTP
On Fri, Jan 17, 2014, at 21:08, Michel Py wrote: > Dans un monde parfait, le client ferait un prepend Meme pas. C'est comme ca qu'on arrive a des AS-path de plus de 32 entrees, qui au passage ne servent a rien, le localpref (et pas que) etant prioritaire sur la longueur de l'AS-path. Sans parler du fait que parfois on a juste pas envie d'etre vus via un certain upstream (qui peut etre un peer du reseau que tu vises pour du peering, mais qui ne veut pas peerer avec les clients de ses peers existants). --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Attaques par amplification NTP
On Fri, Jan 17, 2014, at 18:15, Dominique Rousseau wrote: > Pourquoi tu devrais forcément filter, au niveau forwarding en fonction > des préfixes *annoncés* ? > Ça pourrait aussi bien être filtré sur la base des préfixes > *annonçables* (ie, ceux que tu mets dans la prefix list in), et ça > n'empêche personne de faire du traffic engineering. Selon la definition d'annoncable et la situation ca peut etre un compromis acceptable ou non. Et eoncore une fois, en transit BGP ca risque d'etre plus complique en pratique qu'en theorie. Pas necessairement techniauement, pas cote operationnel ou politique. Jamais oublier le "Layer 8" --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Attaques par amplification NTP
> Dominique Rousseau a écrit: > Pourquoi tu devrais forcément filter, au niveau forwarding en fonction > des préfixes *annoncés* ? Ça pourrait aussi bien être filtré sur la base > des préfixes *annonçables* (ie, ceux que tu mets dans la prefix list in), > et ça n'empêche personne de faire du traffic engineering. Je pense que Radu tout comme moi avait URPF en tête. A large échelle, c'est pratiquement la seule méthode qui ne soit pas ingérable. http://www.cisco.com/web/about/security/intelligence/urpf.pdf http://www.cisco.com/en/US/docs/solutions/Enterprise/Security/Baseline_Security/sec_chap6.html Ca marche comment avec Juniper, d'ailleurs? > Radu-Adrian Feurdean a écrit: > Une fois passe aux clients qui ont leur propres AS, le client est dans > son "droit naturel" de ne pas t'annoncer *TOUS* ses prefixes pour du > traffic entrant (au pif parce-qu;il a d'autres providers et qu'il peut > utiliser des annonces conditionnels), mais de vouloir quand-meme sortir > du traffic pour ces prefixes en question. Malheureusement, oui. Dans un monde parfait, le client ferait un prepend de son AS et annoncerait tous ses préfixes, mais dans la réalité pas toujours. Et il y a des fois ou pour tester tu arrêtes d'annoncer certains préfixes à certains de tes pairs BGP pour aller voir le résultat dans un looking glass quelque part. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Attaques par amplification NTP
Le Fri, Jan 17, 2014 at 05:29:22PM +0100, Radu-Adrian Feurdean [fr...@radu-adrian.feurdean.net] a écrit: [...] > Une fois passe aux clients qui ont leur propres AS, le client est dans > son "droit naturel" de ne pas t'annoncer *TOUS* ses prefixes pour du > traffic entrant (au pif parce-qu;il a d'autres providers et qu'il peut > utiliser des annonces conditionnels), mais de vouloir quand-meme sortir > du traffic pour ces prefixes en question. > Pour un client bien engage dans du peering et qui a ses propres clients > BGP, ca peut meme etre prejudiciable (bonjour le traffic-engineering > communities). Pourquoi tu devrais forcément filter, au niveau forwarding en fonction des préfixes *annoncés* ? Ça pourrait aussi bien être filtré sur la base des préfixes *annonçables* (ie, ceux que tu mets dans la prefix list in), et ça n'empêche personne de faire du traffic engineering. -- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 21 rue Frédéric Petit - 8 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Attaques par amplification NTP
Salut Radu, On Fri, 2014-01-17 at 17:29 +0100, Radu-Adrian Feurdean wrote: > Voulez-vous que je prepare par exemple une presentation "BCP38 > sometimes considered harmhul" pour le prochain FRNOG, histoire de > clarifier un peu ces cas ? > Bien que je trouve qu'il puisse être intéressant de traiter le sujet, à la base, l'assistance est supposée connaitre les tenants est les aboutissant de la (non) application de la BCP38. Bon, c'est à la base, ca, parce qu'on a beaucoup de cravattes aux réunions, à présent :) Bref, ca pourrait peut être, AMHA, être bien d'en faire un mini talk... -- Clément Cavadore --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Attaques par amplification NTP
On Fri, Jan 17, 2014, at 10:31, Florent Daigniere wrote: > On Fri, 2014-01-17 at 01:17 -0800, Michel Py wrote: > > BCP38 c'est bien sympa, mais c'est un de ces paratonnerres à emmerdes: > > T'as raison; appliques la logique jusqu'au bout... le transit que tu lui > vends > (et qui est utilise pour une attaque, vu que tu n'es pas regardant) il n'est > plus a vendre. Tiens, vendredi + BCP38 + transit, je ne peux plus m'abstenir. BCP38 c'est bien gentil, mais il y a bien des cas legitimes ou il faut s'abstenir de l'appliquer. Non pas de l'appliquer de facon moderee, mais tout simplement de s'abstenir. ... et le cas le plus flagrant est justement le transit IP en BGP avec full-table. Plus clairement, il y a client et client (et client et client ): - mme Michu avec son ADSL grand-public - l'entreprise "standard" qui prend un acces "manage" - la boite "internet" (dont une partie importante de l'activite a des choses a faire avec l'internet), qui elle peut avoir ou non un AS, un bloc PI ou une allocation PA - l'AS de taille pas si petite que ca (un AS, unou plusieurs /20 ou plus, des activites divers et varies et avec des clients a son tour), - "grands FAI" - tous les FAI eyeball francais (oui, ils achenten tous du transit a quelqu'un) - les "grands Tier-2" (pareil). Si dans la partie "basse du spectre" (cote mme Michu) le BCP38 est a appliquer afin d'eviter certains desagrements, plus ca monte en gamme, plus il faut considerer la possibilite de (pouvoir) ne pas l'appliquer. Cote "FAI pro" c'est deja un bon debut ou pouvoir le desaactiver a la demande justifie du client. Pour des solutions de "rendondance Internet" du pauvre, le fait de pouvoir sortir via un FAI avec l'IP de l'autre peut sauver certains. Des qu'on passe aux clients "boite Internet", le meme chose peut etre encore plus envisageable. Une fois passe aux clients qui ont leur propres AS, le client est dans son "droit naturel" de ne pas t'annoncer *TOUS* ses prefixes pour du traffic entrant (au pif parce-qu;il a d'autres providers et qu'il peut utiliser des annonces conditionnels), mais de vouloir quand-meme sortir du traffic pour ces prefixes en question. Pour un client bien engage dans du peering et qui a ses propres clients BGP, ca peut meme etre prejudiciable (bonjour le traffic-engineering communities). Et pour les "clients" en fin de liste, certains etant presents sur la liste (quelques noms au pif: NeoT, OVH, Jaguar, NC, SFR, ByTel, ) je craint que ca devient tout betement ingerable. Pour eux, ce n'est pas leurs upstream(s) qui doivent appliquer BCP38, mais eux-meme qui doivent l'appliquer a une partie de leurs clients (voir plus haut, en fonction du type de client). J'ai personellement vecu des cas ou la non-application du BCP38 m'avait enormement facilite les choses (tout comme des cas ou son application me les a rendu bien difficiles). Voulez-vous que je prepare par exemple une presentation "BCP38 sometimes considered harmhul" pour le prochain FRNOG, histoire de clarifier un peu ces cas ? Donc BCP38 et uRPF a tout va, ou plus generalement securite a tout va - faut arreter la consomation de substances interdites a un certain moment. Il y a des endroits ou il faut la faire, des endroits ou il faut penser si/quand la faire, et des endroits ou il faut la fuir comme la peste. Comme il y a generalement beaucoup plus de gens pour du "BGP38 a l'aveugle" que contre: A MORT BCP38 ! -- RAF - Strohller de vendredi --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Attaques par amplification NTP
On 16/01/2014 13:48, Solarus wrote: Le 2014-01-16 10:42, Jérémy Martin a écrit : A ceux qui n'ont pas peur de limiter les attaques en SORTIE de leur réseau, n'oubliez pas d'intégrer un petit shapping sur vos routeurs pour le port 123 UDP, vous rendrez service à plein de petits réseaux (80% des AS). Effectivement, comme pour DNS il faut restreindre l'accès aux serveurs NTP, soit par AS ou par préfixe, soit par shapping sur le port 123 si le serveur doit rester public. En parler au client concerné n'est-il pas la meilleure solution ? Soit il réagit correctement, soit il ne le fait pas et dans ce cas assume tout simplement son risque financier et opérationnel. A moins que ça pose un problème au réseau du fournisseur, mais vu ce dont on parle ça ne devrait pas arriver. Toutefois dans ce cas extrème l'action se justifie par la sauvegarde technique de ce réseau et peut probablement s'appuyer sur les lignes du contrat qui parlent de bonnes pratiques et de bons usages. Mais je ne vois pas de raison que ça se fasse sans informer le client. Quand à l'option de laisser faire parce que trafic = pognon, elle est tout simplement lamentable et malhonnête, et probablement pas compatible avec l'obligation de conseil du professionnel vis à vis de son client (même si il aura du mal à le prouver). Bonne fin de trolldi Sylvain --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Attaques par amplification NTP
On Fri, 2014-01-17 at 01:46 -0800, Michel Py wrote: > >> Michel Py a écrit: > >> Le client que tu bloques au nom de BCP38 et qui perd des paquets parce > >> qu'il > >> a merdé une route-map, il est perdu à jamais. Dans la moitié des cas, il ne > >> t'annonce plus le préfixe parce qu'il veut troubleshooter quelque chose, > >> l'autre moitié c'est qu'il est 3 heures du mat et qu'il a plus important à > >> penser. Dans les deux cas, tu aggraves son problème. Même si il a merdé > >> dans sa config, en le bloquant tu amplifies ses emmerdes, et comme il te > >> paie ça devient les tiennes. > > > Florent Daigniere a écrit: > > T'as raison; appliques la logique jusqu'au bout... le transit que > > tu lui vends (et qui est utilise pour une attaque, vu que tu n'es > > pas regardant) il n'est plus a vendre. > > Ah pardon, il est déjà vendu. Dans le cas typique ou tu factures à 95% tile, > plus le client héberges des attaqueurs plus tu gagnes du pognon. La logique est la même dans l'autre sens: plus t'héberges de gens qui se font attaquer plus tu gagnes du pognon... donc attaques = pognon. > Comme tu veux garder le client, tu as l'appeler et lui dire que si il arrête > pas la connerie ça va lui coûter la peau des glaouis, mais là tu deviens le > héro qui le prévient qu'il a un problème, au lieu du monkey script qui bloque. Heuh, appeler le client ça veut dire passer du temps a faire quelque chose qui va limiter l'entrée de pognon... alors que c'est du temps que tu pourrait passer a démarcher de nouveaux clients. > Le problème de BCP38 c'est que c'est trop automatisé. Personne n'appelle le > client pour lui dire qu'on bloque son trafic parce qu'il a merdé quelque > chose dans sa config. > J'ai raté une étape là... c'est trop ou pas assez automatisé? > Le client est roi. Si tu le fais chier un jour ou il n'y a aucune attaque en > cours, tes concurrents te remercient. > Si tu ne fais rien tes concurrents te remercient aussi. Ils sont dans le même business que toi: attaque => pognon. Ca reste vrai que tu sois la source ou la destination. Florent signature.asc Description: This is a digitally signed message part
RE: [FRnOG] [TECH] Attaques par amplification NTP
>> Michel Py a écrit: >> Le client que tu bloques au nom de BCP38 et qui perd des paquets parce qu'il >> a merdé une route-map, il est perdu à jamais. Dans la moitié des cas, il ne >> t'annonce plus le préfixe parce qu'il veut troubleshooter quelque chose, >> l'autre moitié c'est qu'il est 3 heures du mat et qu'il a plus important à >> penser. Dans les deux cas, tu aggraves son problème. Même si il a merdé >> dans sa config, en le bloquant tu amplifies ses emmerdes, et comme il te >> paie ça devient les tiennes. > Florent Daigniere a écrit: > T'as raison; appliques la logique jusqu'au bout... le transit que > tu lui vends (et qui est utilise pour une attaque, vu que tu n'es > pas regardant) il n'est plus a vendre. Ah pardon, il est déjà vendu. Dans le cas typique ou tu factures à 95% tile, plus le client héberges des attaqueurs plus tu gagnes du pognon. Comme tu veux garder le client, tu as l'appeler et lui dire que si il arrête pas la connerie ça va lui coûter la peau des glaouis, mais là tu deviens le héro qui le prévient qu'il a un problème, au lieu du monkey script qui bloque. Le problème de BCP38 c'est que c'est trop automatisé. Personne n'appelle le client pour lui dire qu'on bloque son trafic parce qu'il a merdé quelque chose dans sa config. Le client est roi. Si tu le fais chier un jour ou il n'y a aucune attaque en cours, tes concurrents te remercient. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Attaques par amplification NTP
On Fri, 2014-01-17 at 01:17 -0800, Michel Py wrote: > >> Jérémy Martin a écrit: > >> A ceux qui n'ont pas peur de limiter les attaques en SORTIE de leur > >> réseau, n'oubliez pas d'intégrer un petit shapping sur vos routeurs > >> pour le port 123 UDP, vous rendrez service à plein de petits réseaux > >> (80% des AS). > > +1, à condition que ça ne devienne pas un trou noir pour des jours. Un client > NTP qui perd un paquet, c'est pas important. Par contre, faut pas que ça dure > éternellement, donc lire les traps. > > > > Rémi Bouhl a écrit: > > Ou BCP38 : http://tools.ietf.org/html/bcp38 pour ceux > > qui hébergent à leur insu les machines attaquantes, non ? > > BCP38 c'est bien sympa, mais c'est un de ces paratonnerres à emmerdes: ca > suppose que le client n'est pas con, et qu'il ne fait jamais d'erreurs. C'est > doublement faux: 1. Les clients cons, on les garde tant qu'ils paient et 2. > Quand ils arrivent aux stade "j'en connais juste assez pour être dangereux" > c'est encore pire. Tu leurs vends du transit, ils ont le droit de d'utiliser > comme route par défaut même venant d'un préfixe qu'ils ne t'annoncent pas. > > Le client que tu bloques au nom de BCP38 et qui perd des paquets parce qu'il > a merdé une route-map, il est perdu à jamais. Dans la moitié des cas, il ne > t'annonce plus le préfixe parce qu'il veut troubleshooter quelque chose, > l'autre moitié c'est qu'il est 3 heures du mat et qu'il a plus important à > penser. Dans les deux cas, tu aggraves son problème. Même si il a merdé dans > sa config, en le bloquant tu amplifies ses emmerdes, et comme il te paie ça > devient les tiennes. > > Michel. > T'as raison; appliques la logique jusqu'au bout... le transit que tu lui vends (et qui est utilise pour une attaque, vu que tu n'es pas regardant) il n'est plus a vendre. CQFD. Florent signature.asc Description: This is a digitally signed message part
RE: [FRnOG] [TECH] Attaques par amplification NTP
>> Jérémy Martin a écrit: >> A ceux qui n'ont pas peur de limiter les attaques en SORTIE de leur >> réseau, n'oubliez pas d'intégrer un petit shapping sur vos routeurs >> pour le port 123 UDP, vous rendrez service à plein de petits réseaux >> (80% des AS). +1, à condition que ça ne devienne pas un trou noir pour des jours. Un client NTP qui perd un paquet, c'est pas important. Par contre, faut pas que ça dure éternellement, donc lire les traps. > Rémi Bouhl a écrit: > Ou BCP38 : http://tools.ietf.org/html/bcp38 pour ceux > qui hébergent à leur insu les machines attaquantes, non ? BCP38 c'est bien sympa, mais c'est un de ces paratonnerres à emmerdes: ca suppose que le client n'est pas con, et qu'il ne fait jamais d'erreurs. C'est doublement faux: 1. Les clients cons, on les garde tant qu'ils paient et 2. Quand ils arrivent aux stade "j'en connais juste assez pour être dangereux" c'est encore pire. Tu leurs vends du transit, ils ont le droit de d'utiliser comme route par défaut même venant d'un préfixe qu'ils ne t'annoncent pas. Le client que tu bloques au nom de BCP38 et qui perd des paquets parce qu'il a merdé une route-map, il est perdu à jamais. Dans la moitié des cas, il ne t'annonce plus le préfixe parce qu'il veut troubleshooter quelque chose, l'autre moitié c'est qu'il est 3 heures du mat et qu'il a plus important à penser. Dans les deux cas, tu aggraves son problème. Même si il a merdé dans sa config, en le bloquant tu amplifies ses emmerdes, et comme il te paie ça devient les tiennes. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Attaques par amplification NTP
Le 2014-01-16 10:42, Jérémy Martin a écrit : A ceux qui n'ont pas peur de limiter les attaques en SORTIE de leur réseau, n'oubliez pas d'intégrer un petit shapping sur vos routeurs pour le port 123 UDP, vous rendrez service à plein de petits réseaux (80% des AS). Effectivement, comme pour DNS il faut restreindre l'accès aux serveurs NTP, soit par AS ou par préfixe, soit par shapping sur le port 123 si le serveur doit rester public. Same old song. Solarus --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Attaques par amplification NTP
Le 16/01/2014, Jérémy Martin a écrit : > A ceux qui n'ont pas peur de limiter les attaques en SORTIE de leur > réseau, n'oubliez pas d'intégrer un petit shapping sur vos routeurs pour > le port 123 UDP, vous rendrez service à plein de petits réseaux (80% des > AS). Ou BCP38 : http://tools.ietf.org/html/bcp38 pour ceux qui hébergent à leur insu les machines attaquantes, non ? --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Attaques par amplification NTP
Bonjour à tous, Un petit message à ceux qui gèrent des réseaux :) Nous voyons arriver depuis quelques semaines de plus en plus d'attaques par amplification sur protocole NTP. C'est la petite nouveauté de la rentrée quoi. Bon, en fait, ça fait des années que ça existe (depuis l'invention de l'attaque par amplification et spoofing d'ip source), mais il semble que les petits malins qui commercialisent ce type d'attaque l'ont intégré à leur catalogue désormais. Il faut adapter un peu nos filtres pour prendre en compte ce type de protocole (ceux qui bossent sur l'UDP de base n'ont rien à changer), notamment pour ceux qui configurent leurs ACL et leurs outils de surveillance de manière assez fine. A ceux qui n'ont pas peur de limiter les attaques en SORTIE de leur réseau, n'oubliez pas d'intégrer un petit shapping sur vos routeurs pour le port 123 UDP, vous rendrez service à plein de petits réseaux (80% des AS). Merci tout plein, Bisous, -- Jérémy __ FreeHeberg.com : Osez l'hébergement gratuit de qualité professionnelle ! PHP + Mysql + Espace 2 à 20 Go --- Liste de diffusion du FRnOG http://www.frnog.org/