RE: [FRnOG] [TECH] Attaques par amplification NTP

2014-01-17 Par sujet Michel Py
 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

2014-01-17 Par sujet Florent Daigniere
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

2014-01-17 Par sujet Florent Daigniere
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

2014-01-17 Par sujet Sylvain Vallerot



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

2014-01-17 Par sujet Radu-Adrian Feurdean
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.

vendredi
Comme il y a generalement beaucoup plus de gens pour du BGP38 a
l'aveugle que contre:

A MORT BCP38 !

/vendredi

--
RAF - Strohller de vendredi


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


Re: [FRnOG] [TECH] Attaques par amplification NTP

2014-01-17 Par sujet Clement Cavadore
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

2014-01-17 Par sujet Dominique Rousseau
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

2014-01-17 Par sujet Michel Py
 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

2014-01-17 Par sujet Radu-Adrian Feurdean
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

2014-01-16 Par sujet Solarus

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/