[FRnOG] Re: RFC 6092: Recommended Simple Security Capabilities in CPE for Providing Residential IPv6 Internet Service
On Tue, Jan 25, 2011 at 11:49:01AM +0100, Thomas Samson kooll...@gmail.com wrote a message of 61 lines which said: Un ordinateur est menacé si il est joignable, le numéro de port n'indique plus vraiment la 'taille' de la menace, surtout quand le but n'est pas de 'rooter' la machine mais de l'ajouter dans un botnet. et en faire un relai de spam, une source de ddos, un proxy anonymisant. Pas besoin de port en écoute inférieur à 1024, pas besoin de droits administrateurs. Les attaques les plus courantes sur le PC de M. Michu aujourd'hui sont en effet par « charge utile » (i.e. par malware dans une page Web), pas par connexion IP. C'est d'ailleurs pour cela que le refus de certains d'abandonner le NAT « pour des raisons de sécurité » n'est pas rationnel (le NAT n'empêche pas ces attaques). Néanmoins, en matière de sécurité, ce n'est jamais tout blanc ou tout noir. Les programmes qui écoutent sur des ports 1024 sont en général particulièrement sensibles et l'idée de Rémi Bouhl de les protéger ne me semble pas mauvaise. Pour le reste, je ne sais pas quelle solution est préférable pour Mme Michu, mais de plus en plus d'applications supporte l'UPnP Non-standard, protocole spécifique Microsoft. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: RFC 6092: Recommended Simple Security Capabilities in CPE for Providing Residential IPv6 Internet Service
On Tue, Jan 25, 2011 at 11:49:01AM +0100, Thomas Samson kooll...@gmail.com wrote a message of 61 lines which said: Un ordinateur est menacé si il est joignable, le numéro de port n'indique plus vraiment la 'taille' de la menace, surtout quand le but n'est pas de 'rooter' la machine mais de l'ajouter dans un botnet. et en faire un relai de spam, une source de ddos, un proxy anonymisant. Pas besoin de port en écoute inférieur à 1024, pas besoin de droits administrateurs. Les attaques les plus courantes sur le PC de M. Michu aujourd'hui sont en effet par « charge utile » (i.e. par malware dans une page Web), pas par connexion IP. C'est d'ailleurs pour cela que le refus de certains d'abandonner le NAT « pour des raisons de sécurité » n'est pas rationnel (le NAT n'empêche pas ces attaques). Et pourquoi ces attaques sur les clients web sont-elles devenues les plus courantes ? Tout simplement parce que joindre directement une machine sur Internet est devenu de plus en plus difficile avec le NAT. Derrière une IP publique on peut avoir tout le LAN d'une entreprise, un attaquant n'a donc pas beaucoup d'autres solutions que de passer par du SE puis une attaque sur le client web / mail (coucou I love you) / whatever. Avec IPv6, on augmente la surface d'attaque sur les postes clients, ce sera le retour des bons vieux scans, des sasser et autres blaster si personne n'apprend des erreurs passées. Néanmoins, en matière de sécurité, ce n'est jamais tout blanc ou tout noir. Les programmes qui écoutent sur des ports 1024 sont en général particulièrement sensibles et l'idée de Rémi Bouhl de les protéger ne me semble pas mauvaise. Une application avec un remote command execution bug -qu'elle tourne sur un port ou à 1024- est dangereuse. La seule chose qui change c'est la probabilité de la trouver en faisant un scan sur un bloc d'adresses IP. Je tiens à redire que pour transformer une machine en zombie, pas besoin des privilèges admin dans la plupart des cas. Au pire, l'attaquant pas trop mauvais trouvera un moyen de faire une escalade de privilèges. Pour le reste, je ne sais pas quelle solution est préférable pour Mme Michu, mais de plus en plus d'applications supporte l'UPnP Non-standard, protocole spécifique Microsoft. Et qui détient 95% du marché des postes clients ? :) --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] Re: RFC 6092: Recommended Simple Security Capabilities in CPE for Providing Residential IPv6 Internet Service
Bonjour, Pour le reste, je ne sais pas quelle solution est préférable pour Mme Michu, mais de plus en plus d'applications supporte l'UPnP Non-standard, protocole spécifique Microsoft. Tu peux expliquer ce que tu vois de spécifique Microsoft? Il me semblait que UPnP est un standard (ISO/IEC 29341). Cf. http://www.iso.org/iso/pressrelease.htm?refid=Ref1185 Siegfried --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: RFC 6092: Recommended Simple Security Capabilities in CPE for Providing Residential IPv6 Internet Service
Le 25/01/11, Julien Reveretshad...@c0a8.org a écrit : Avec IPv6, on augmente la surface d'attaque sur les postes clients, ce sera le retour des bons vieux scans, des sasser et autres blaster si personne n'apprend des erreurs passées. Des scans en IPv6? Ça m'étonnerait: avec l'attribution pseudo-aléatoire des IPv6, il est impossible de trouver les machines d'un abonné à partir de la plage attribuée par son FAI. Les bienfaits de la surabondance :) Rémi. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: RFC 6092: Recommended Simple Security Capabilities in CPE for Providing Residential IPv6 Internet Service
On Tue, Jan 25, 2011 at 01:37:32PM +0100, Rémi Bouhl remibo...@gmail.com wrote a message of 21 lines which said: Ça m'étonnerait: avec l'attribution pseudo-aléatoire des IPv6, il est impossible de trouver les machines d'un abonné à partir de la plage attribuée par son FAI. C'est un peu plus compliqué que cela : RFC 5157 : IPv6 Implications for Network Scanning http://www.bortzmeyer.org/5157.html Auteur(s) du RFC: T. Chown (University of Southampton) Une technique classique des méchants craqueurs qui cherchent à pénétrer un gentil réseau est de *balayer* (to scan) l'ensemble des adresses IP à l'intérieur du réseau, pour voir lesquelles répondent et ainsi trouver des cibles. Par exemple, Slammer l'utilisait. Mais en IPv6, où le nombre d'adresses possibles est infiniment plus grand, cette tactique est-elle encore efficace ? Imaginons que le craqueur aie déterminé que le préfixe IP du réseau de sa victime est le 192.0.2.128/25. Il reste 7 bits pour les machines soit 128 victimes potentielles à interroger, ce qui ne prend que quelques secondes pour un programme comme fping. Cette technique est donc très utilisée pour avoir une liste des adresses IP utilisées... et donc des cibles possibles. Mais en IPv6, si la victime a le réseau de préfixe 2001:DB8:AF:42::/64, comment le balayer de manière efficace ? Cela fait 64 bits pour les machines donc 18446744073709551616 adresses à examiner, ce qui ne peut pas se faire en un temps raisonnable (sections 2.1 et 2.2 du RFC). Certains en ont donc déduit que le balayage (scanning) était impossible en IPv6 et que donc, sur ce point, IPv6 offrait d'avantage de sécurité qu'IPv4. Mais notre RFC montre que ce n'est pas si simple et qu'il existe d'autres méthodes que la force brute pour trouver les machines allumées (un excellent article (http://www.cs.columbia.edu/~smb/papers/v6worms.pdf) de Steve Bellovin avait déjà déblayé ce terrain). La section 2.3 parle par exemple de l'exploitation de conventions d'adressage. Si l'administrateur du réseau 2001:DB8:AF:42::/64 cité plus haut numérote ses machines 2001:DB8:AF:42::1, 2001:DB8:AF:42::2, 2001:DB8:AF:42::3, etc, l'attaquant n'aura à tester qu'une petite partie des adresses théoriques. Si au lieu d'adresses calculées ainsi, on utilise la traditionnelle autoconfiguration sans état d'IPv6 (RFC 4862), la connaissance du fournisseur des cartes Ethernet fournit déjà un bon moyen de sérieusement réduire l'espace de recherche. Les sections 3 et 4 du RFC listent l'ensemble des techniques connues et que le méchant pourrait utiliser pour arriver néanmoins à balayer un réseau IPv6. La section 4 concerne les cas où l'attaquant est lui-même sur ce réseau et le problème est alors assez simple (il lui suffit d'espionner les paquets ND (Neighbor Discovery, cf. RFC 4861). La section 3 parle des cas où l'attaquant n'est pas sur le réseau. Sa tâche est alors plus difficile mais reste faisable : par exemple la section 3.3 détaille l'information qu'on peut tirer d'un transfert de zone DNS (http://www.bortzmeyer.org/recuperer-zone-dns.html), et la 3.4 l'intérêt qu'on peut trouver à regarder les journaux d'un gros serveur, journaux où on trouvera les adresses de clients qui sont autant de cibles potentielles. Plus moderne est l'observation des pairs dans un réseau P2P (section 3.5). La plupart des protocoles de P2P, par exemple BitTorrent, mettent en rapport direct les « offreurs » et les « preneurs » et, en offrant du contenu intéressant, on peut récolter beaucoup d'adresses IP de machines. La section 5 passe aux recommandations et contre-mesures : utilisation d'adresses « vie privée » (RFC 4941), dont la durée de vie est limitée, utilisation d'adresses EUI-64 (RFC 4291, cf. section 5.1) mais sans l'adresse MAC (section 5.3), configuration du serveur DHCP (RFC 3315) pour ne pas attribuer les adresses séquentiellement à partir de ::1 (section 5.4), etc. Enfin, en guise de synthèse, la section 7, qui résume le problème et les moyens de le limiter, rappelle que dissimuler les adresses IP des machines est de la Sécurité par l'obscurité : cela peut ralentir l'attaquant, mais cela ne doit certainement pas être utilisé comme unique moyen de défense, car, tôt ou tard, l'attaquant trouvera ces adresses. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: RFC 6092: Recommended Simple Security Capabilities in CPE for Providing Residential IPv6 Internet Service
On Tue, Jan 25, 2011 at 12:01:07PM +0100, Stephane Bortzmeyer bortzme...@nic.fr wrote a message of 29 lines which said: Non-standard, protocole spécifique Microsoft. Oups, rectification. Comme l'ISO, frustrée de n'avoir pas eu de rôle dans le développement de l'Internet, met son tampon sur tout et n'importe quoi, il y a une norme ISO UPnP, ISO/IEC 29341-1:2008. Comme les autres normes du dinosaure, c'est payant, 192 francs helvètes http://www.iso.org/iso/catalogue_detail?csnumber=52674. Mais je suppose que le texte est peu ou prou le même que celui distribué par le club privé UPnP http://upnp.org/resources/upnpresources.zip. Merci aux lecteurs vigilants qui ont répéré cette impardonnable inexactitude. --- Liste de diffusion du FRnOG http://www.frnog.org/
