\documentclass{beamer}
%\documentclass[handout]{beamer}
%\usepackage{pgfpages}
%\pgfpagesuselayout{2 on 1}[a4paper,border shrink=5mm]
\usetheme{Afnic}
\usepackage[french]{babel}
\usepackage[utf8]{inputenc}
\usepackage{bortzmeyer-utils}

\title{Sécurité d'IPv6}
\author{Stéphane Bortzmeyer\\AFNIC\\\texttt{bortzmeyer@nic.fr}}
\date{21 février 2012}

\begin{document}

\maketitle

\begin{frame}
  \titlepage
\end{frame}

\begin{frame}
  \frametitle{Introduction}
  \begin{itemize}
  \item<2->IPv6 est la version d'IP normalisée en 1995-1998 (RFC 2460)
  \item<3->Principale motivation, avoir davantage d'adresses IP. Permet de retrouver l'adressage, donc les communications, de bout en bout. Les
    bricolages IPv4, genre CGN, ne fournissent pas cela.
  \item<4->Déploiement plutôt lent et laborieux (par exemple, bien des
    enseignants ne parlent toujours que d'IPv4 en cours)
  \item<5->Des évolutions depuis dix ans~: pas mal d'articles sur des
    problèmes de sécurité d'IPv6 sont maintenant dépassés.
  \end{itemize}
\end{frame}

\begin{frame}
\frametitle{Nouveautés techniques d'IPv6 intéressantes pour la sécurité}
\begin{itemize}
\item<2->Adresses plus longues (128 bits). A des conséquences pour le
  \foreign{scan} ou pour les pare-feux avec état.
\item<3->Auto-configuration sans état possible (mais pas
  obligatoire). Les routeurs émettent des RA (\foreign{Router
    Advertisement}) sur le réseau local. Les machines combinent le
  préfixe du réseau, appris dans le RA, avec un suffixe (par exemple
  dérivé de l'adresse MAC).
\end{itemize}
\end{frame}

\begin{frame}
 \frametitle{Appréciation générale}
 \begin{block}
   {IPv6, c'est IP}
   \only<2->{Cela veut dire que 95~\% des questions de sécurité sont 
     les mêmes en IPv4 et IPv6.

   \only<3->{Cet exposé est spécifique à IPv6 et se focalise donc sur les 5~\%
   restants. Mais ne perdez pas de vue ce chiffre de 95~\%~!}
   }
 \end{block}
\end{frame}

\begin{frame}
 \frametitle{Les 95~\% communs}
 \begin{itemize}
 \item<2->Usurpation d'adresse IP source triviale\only<2>{ (OK, il y a
   les CGA du RFC 3972, mais c'est très peu utilisé)}
 \item<3->Pas d'authentification ou de chiffrement par défaut, au
   niveau IP\only<3>{ (IPsec est peu déployé)}
 \item<4->Attaques par déni de service volumétriques (force brute)
 \item<5->Attaques contre les protocoles de transport\only<5>{  (\foreign{TCP
   SYN flood})} ou contre les applications\only<5>{ (CMS en PHP ou Java\ldots)}
 \item<6->Protocoles de résolution d'adresses sur le réseau local
   différents (ARP vs. NDP) mais posant des problèmes similaires
 \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Les 5~\% restants}
  \begin{enumerate}
  \item<2->Entre v4 et v6, il y a des différences \emph{contingentes} qui sont liées à
    l'état \emph{actuel} des mises en œuvre et aux compétences
    actuelles des administrateurs. Celles-ci vont disparaître avec le
    temps.
  \item<3->Et il y a des différences qui sont des différences de
    protocole (et resteront donc pour toujours),
  \item<4->Certaines de ces différences sont en faveur d'IPv4,
    d'autres d'IPv6 et d'autres encore sont neutres.
  \end{enumerate}
\end{frame}

\begin{frame}
  \frametitle{Différences contingentes}
  \begin{enumerate}
  \item<1->Configuration incohérente, exemple une ACL en v4 sans
    équivalent en v6\only<1>{ (en 2013, des gens font encore les ACL à la main~???)},
  \item<2->Logiciels limités (exemple~: un pare-feu qui gère IPv4 mais
    pas IPv6),
  \item<3->Logiciels peu performants\only<3>{ (exemple~: un pare-feu qui
    gérerait IPv4 dans les ASIC mais IPv6 en logiciel)},
  \item<4->Logiciels bogués\only<4>{  (marchent bien en IPv4 mais n'ont jamais
    été réellement testés au feu en IPv6)},
  \item<5->Techniques de transition/coexistence compliquées et qui
    viennent avec de nouveaux risques,
  \item<6->Administrateurs incompétents (par exemple parce qu'ils
    croient à tort qu'IPv6 est différent d'IPv4). 
   \item<7->Heureusement, les attaquants aussi sont incompétents. On
     ne voit quasiment jamais d'attaques en IPv6, même lorsqu'il y a
     des vulnérabilités énormes.
  \end{enumerate}
\end{frame}

\begin{frame}
  \frametitle{Exemple du retard du déploiement d'IPv6}
  J'ai reçu mon premier spam en IPv6 en 2012 seulement.

  \only<2->{Mes serveurs SSH font l'objet d'innombrables tentatives de connexion
  en IPv4 et
  \emph{jamais} en IPv6 (alors que fail2ban n'est pas installé en
  v6\ldots).}  

  \only<3->{Donc, IPv6 a de vrais atouts en sécurité :-)}
\end{frame}

\begin{frame}
 \frametitle{État des logiciels}
 \begin{block}
   {Pour quasiment tous les logiciels, c'est moins bon ou équivalent
     en IPv6}
   \only<2->{
     \begin{itemize}
     \item<3->Pare-feux. Ne gèrent pas IPv6 ou le font lentement
       (\foreign{slow path}). Pas toujours adaptés au grand nombre
       d'adresses (table pour le filtrage à état).
     \item<4->Bogues. Exemple~: envoyer un RA avec \emph{beaucoup} de
       préfixes listés tue Mac OS X, dont les programmeurs ne
       connaissaient pas la notion de dépassement de tableau \url{http://samsclass.info/ipv6/proj/RA_flood2.htm}
     \end{itemize}
   }
 \end{block}
\end{frame}

\begin{frame}[fragile]
  \frametitle{Un contre-exemple~: Netfilter}
Le pare-feu de Linux marche très bien en IPv6 (mais je ne jurerais pas
qu'il ait 100~\% des fonctions qu'il a en v4).
\begin{info}
ip6tables -A INPUT --protocol tcp --dport ssh --jump ACCEPT
ip6tables -A INPUT --jump REJECT                           
\end{info}
Tout ce qui n'est pas SSH sera bloqué. Sur le client~:
\begin{info}
From 2a01:e35:8bd9:8bb0:ba27:ebff:feba:9094 \
     icmp_seq=8 Destination unreachable: Port unreachable
\end{info}
\end{frame}

\begin{frame}[fragile]
  \frametitle{Netfilter avec des fonctions plus avancées}
On va limiter le trafic ICMP echo (ping)~:
\begin{info}
ip6tables -A INPUT -p icmpv6 --icmpv6-type echo-request \
          -m hashlimit --hashlimit-name ICMP \
          --hashlimit-above 1/second --hashlimit-burst 1 \
          --hashlimit-mode srcip \
          --hashlimit-srcmask 64 -j DROP
\end{info}

On teste en envoyant 10 p/s~:
\begin{info}
ping6 -i 0.1 2001:db8:8bd9:8bb0:ba27:ebff:feba:9094 
\end{info}

Et on constate effectivement une limitation à 1 p/s~:
\begin{info}
81 packets transmitted, 8 received, 90% packet loss, time 8577ms
\end{info}
Essayez-cela sur un pare-feu commercial et revenez me dire si ça a marché.

\end{frame}

\begin{frame}
  \frametitle{Sécurité des techniques de transition}
   Techniques souvent à base de tunnels, avec aucune sécurité et des
   possibilités d'usurpation supplémentaires
  \only<2>{\begin{block}
    {Teredo est particulièrement vulnérable. Ne l'utilisez pas.}
    {6to4 est à peine meilleur. Lire le RFC 6180}
  \end{block}}
  \only<3->{

    Ces vulnérabilités sont souvent celles de tous les tunnels
    (donc exploitables en v4 pur)}
\end{frame}

\begin{frame}
  \frametitle{Différences de protocole}
  \begin{block}
    {Certains différences ne vont pas disparaître avec le temps}
    {Elles relèvent de vraies différences entre IPv4 et IPv6. Là
      encore, certaines sont favorables à IPv6, d'autres à IPv4.}
  \end{block}
\end{frame}

\begin{frame}
  \frametitle{RAcailles}
  \begin{enumerate}
    \item<2->Les RA (annonces des routeurs), comme DHCP, ne sont pas sécurisées/authentifiées.
    \item<3->Comme avec DHCP, une machine peut jouer au routeur et émettre des
RAcailles (\foreign{rogue RA}). Problème décrit dans le RFC 6104.
    \item<4->Comme avec DHCP, la meilleure protection semble être du
filtrage par le commutateur (\foreign{RA Guard}, RFC 6105)~: services appelés
\foreign{IPv6 First Hop Security} chez Cisco,
par exemple
  \end{enumerate}

\end{frame}

\begin{frame}
  \frametitle{Vie privée et adresse MAC}
  \begin{enumerate}
  \item<2->Par défaut, le mode le plus courant de configuration d'une
    adresse est automatique, avec le préfixe au début et un dérivé de l'adresse MAC
    à la fin.
  \item<3->Si on change de réseau, on garde l'adresse MAC et on peut
    donc être suivi. À noter que les gens qui se plaignent de ce
    risque sont probablement les mêmes qui utilisent Facebook et acceptent tous les cookies.
  \item<4->Solution~: adresses aléatoires (RFC 4941).
  \item<5->Mise en œuvre dans tous les systèmes (pas forcément activée
    par défaut).
  \end{enumerate}
\end{frame}

\begin{frame}
  \frametitle{Analyse des en-têtes}
  \begin{enumerate}
  \item<2->Des tas de logiciels de sécurité ont besoin de «~sauter~»
    l'en-tête du paquet, pour aller au contenu. En IPv4, c'est pénible
    (en-tête de taille variable) mais connu.
   \item<3->En IPv6, nombre quelconque d'en-têtes et, jusqu'à
     récemment, pas de gabarit commun $\rightarrow$ impossible à
     analyser \url{http://www.bortzmeyer.org/analyse-pcap-ipv6.html}. Ajouter un seul en-tête suffit parfois pour échapper à la détection.
   \item<4->Depuis le RFC 6564, un algorithme fiable est possible.
   \item<5->Les commentaires dans le code source de Wireshark ou
     Net::Pcap ne sont pas flatteurs pour IPv6\ldots
   \item<6->Attention aussi à la fragmentation (RFCs en cours pour insister sur le risque).
  \end{enumerate}
\end{frame}

\begin{frame}
\frametitle{Énumération des adresses}
  \begin{enumerate}
    \item<2->En IPv4, balayer \emph{toutes} les adresses est réaliste (un /16
      en moins de 2 h, à 10 adr./s). Cela permet de trouver des
      machines discrètes.
    \item<3->En IPv6, une telle énumération \emph{naïve} est hors de question (un /64 prendrait des
      milliards d'années).
    \item<4->Cela ne veut pas dire qu'on ne peut pas être trouvé~:
      adresses prévisibles (\computer{...::1}), connexions sortantes\ldots Le RFC 5157
      donne plein d'idées.
  \end{enumerate}  
\end{frame}

\begin{frame}
  \frametitle{Plus de NAT~? Moins de sécurité~?}
  \begin{itemize}
  \item<2->En IPv4, le NAT est quasi-indispensable (manque
    d'adresses).
  \item<3->En IPv6, le NAT n'est pas indispensable (mais permis, RFC
    5902 et 6296).
  \item<4->Le NAT sera-t-il déployé en IPv6~? On ne le sait pas
    encore.
  \item<5->Est-ce que cela aura des conséquences sur la sécurité~?
  \item<6->Le NAT n'apporte \emph{pas} de sécurité
    \url{http://www.bortzmeyer.org/nat-et-securite.html}.
  \item<7->En IPv6 comme en IPv4, les outils de sécurité sont du code
    correct, des pare-feux, des utilisateurs prudents.
  \end{itemize}
\end{frame}

\begin{frame}[fragile]
  \frametitle{Et c'est tout~?}
  \begin{block}
    {Non, il y a encore des tas de points à voir mais on manque de
      temps.}
    {J'ai cité les plus importants. Pour approfondir,
      \computer{IPV6\_V6ONLY} dans les applications
      \url{http://stackoverflow.com/a/2798432/15625}, l'attaque
      \foreign{Neighbor cache}
      \url{http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf}, le
      filtrage d'ICMP «~pour des raisons de sécurité~» qui est une
      énorme erreur en IPv6 et bien d'autres \ldots}
  \end{block}
\end{frame}

\begin{frame}
  \frametitle{Mesures à prendre}
  \begin{block}
    {Plutôt que de se demander gravement «~IPv6 est-il plus ou moins sûr~?~»\ldots}
    {Mieux vaut parler de mesures concrètes de sécurité.}
  \end{block}
  \only<2->{«~Ne pas déployer IPv6~» n'est pas une bonne idée~: on a
  besoin de ces adresses en plus. En prime, IPv6 tourne peut-être déjà
  sur votre réseau local.}
\end{frame}

\begin{frame}
  \frametitle{Mesures}
  \begin{itemize}
  \item<2->Connaître son réseau~: déployer des outils équivalents à
    l'arpwatch d'IPv4 comme ndpmon
    \url{http://ndpmon.sourceforge.net/} ou ramond ou rafixd.
  \item<3->Vérifier que les outils de sécurité comme l'IDS, gèrent
    aussi IPv6. \emph{Ne pas hésiter à demander aux fournisseurs sinon~!}
  \item<4->Le système SEND sécurise les RA par certificats
    cryptographiques et signatures. Très complexe et très peu déployé.
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Conclusion~: IPv6 est-il plus ou moins sûr~?} 
  \begin{enumerate}
  \item<2->Peu de différences
  \item<3->Mais, en sécurité, il faut connaître ces différences
  \end{enumerate}
\end{frame}

\begin{frame}
  \frametitle{Références}
  \begin{enumerate}
   \item Il existe relativement peu de références solides sur la
     sécurité d'IPv6 (mais pas mal de trucs produits par des trolls).
   \item RFC 6092 et 6204~: recommandation de filtrage dans les
     \foreign{boxes} de M. Michu. Attention, documents nuancés.
   \item Pas mal de RFC en cours de travail ou de publication sur des
     problèmes concrets (comme le fait que les RA avaient le droit
     d'être fragmentés).
  \end{enumerate}
\end{frame}
\end{document}
