\documentclass[pdftex,a4paper,fleqn,twoside,final,12pt]{article}
\usepackage[latin1]{inputenc}
\usepackage[OT1]{fontenc} 
\usepackage{vmargin}
\usepackage{relsize}
\usepackage{xr}
\usepackage{graphicx}
\usepackage[pdftex]{hyperref}
\usepackage[french]{babel}

\setpapersize      {A4}

%Pour une sortie avec serrodo
\setmarginsrb      {2cm}%marge gauche
                   {2cm}%marge en haut
                   {2cm}%marge droite
                   {2cm}%marge en bas
                   {0.5cm}%hauteur du header
                   {1cm}%separation header
                   {0.5cm}%hauteur du bas
                   {1cm}%separation du bas


\begin{document}
%\vskip 1cm
\noindent\rule{\linewidth}{1pt}
\begin{center}
\Huge\relsize{-1}\textbf{Quelques propositions pour une organisation\\
des ressources réseaux  prenant en compte\\
les besoins du LACL}
\end{center}
\noindent\rule{\linewidth}{1pt}
\vskip 2cm
\normalfont\normalsize
\noindent{}Document de travail proposé par Olivier \textsc{Michel}\\
LACL - P2 240 - \texttt{olivier.michel@univ-paris12.fr}\\
Version du \today.

\vskip 5cm
%\relsize{-1}
\setcounter{tocdepth}{1}     % Fonctionne que avec \tableofcontents
\tableofcontents
%\relsize{1}
\clearpage


\section{Introduction}

À l'heure où les missions de l'université évoluent considérablement et
où la demande de performance et de réactivité se fait de plus en plus
forte, il nous apparaît clairement que la mise en {\oe}uvre actuelle des
ressources informatiques par le CRI ne permet pas au LACL d'atteindre
les objectifs d'excellence qu'il s'est fixé. En effet, de par ses
activités de recherche en informatique (section 27 du CNU), le LACL a
des besoins spécifiques que nous allons essayer de rendre explicites
dans la section~\ref{sec:besoins} ; nous proposerons une solution aux
problèmes dans la section~\ref{sec:solution}. Enfin, nous montrerons en
section~\ref{sec:conclusion} combien l'approche proposée peut
s'instancier avec les ressources dont dispose le laboratoire.

\section{Les besoins du LACL} \label{sec:besoins}

Nous donnons dans cette section la liste des services qui ne sont pas
accessibles actuellement\footnote{Certains services sont parfois disponibles,
l'accès ssh par exemple, mais avec de telles restrictions que leur usage est
rendu difficile, sinon inutilisable.}. Nous insistons sur le fait que ces
services sont des services standard qui représentent le minimum qu'un
laboratoire est en droit d'attendre d'une université. 

La liste qui suit n'est pas une liste figée dans le temps car le laboratoire est
un lieu qui évolue constamment au grès des besoins de ses membres. On
distingue trois types de services nécessaires
\begin{enumerate}
 \item les services indispensables que l'on souhaite mettre en place
       pour les membres du laboratoire,
 \item les ressources  internes du laboratoires devant êtres accessibles
       depuis l'extérieur du laboratoire,
 \item et enfin la protection des ressources du laboratoire.
\end{enumerate}
Nous détaillons ces éléments dans les sections suivantes.

\subsection{Services indispensables à mettre en place}

Ces services concernent des outils permettant un travail efficace et
une mise en commun des ressources du laboratoire. Ils représentent de
plus (pour les CMS/Wiki par exemple), des éléments requis dans le cadre
de projets (ANR, RNSC...) :
\begin{enumerate}
 \item serveur CVS/SVN pour permettre le développement collaboratif, accessible
       via un serveur Web et ssh,

 \item serveurs de CMS/Wiki pour les projets scientifiques (ANR et autres),

 \item serveurs applicatifs dédiés reposant sur des technologies en
       développement,

 \item serveur CIFS et NFS permettant la mise en commun d'espace disque,

 \item adresses mails pérennes (et temporaires pour les visiteurs du laboratoire) en\\
       \texttt{@lacl.univ-paris12.fr},

 \item services \texttt{imaps} et \texttt{pop3s} ainsi que webmail en \texttt{https},

 \item liste de diffusions (internes et externes),

 \item utilisation, en interne au laboratoire, de protocoles exotiques (JXTA,
       p2p...),

 \item utilisation de logiciels de téléconférences.
\end{enumerate}

\subsection{Accès aux ressources internes de l'extérieur du laboratoire}

Les enseignants/chercheurs du laboratoires développent un grand nombre
de collaborations avec des collègues extérieurs à l'université. Ils sont
ainsi amenés à se déplacer, nationalement et internationalement. Lors de
ces déplacements, il est indispensable de leur permettre l'accès à
l'ensemble des ressources offertes par le laboratoire avec un maximum de
sécurité et d'efficacité. Pour cela, nous avons identifié les services
suivants :
\begin{enumerate}
 \item accès, depuis l'extérieur via le protocole crypté et sécurisé ssh, aux
       ressources internes du laboratoire,

 \item serveur VPN pour accéder, de l'extérieur du laboratoire, aux ressources
       internes de celui-ci.
\end{enumerate}

\subsection{Protection des ressources du laboratoire}


Vivant dans un monde connecté et ouvert où les attaques technologiques
ne sont pas rares, nous ne pouvons faire l'économie de protéger les
ressources du laboratoire en ayant une maîtrise maximale sur les accès
aux ressources. Ainsi, il nous semble essentiel de pouvoir offrir les
services suivants :
\begin{enumerate}
 \item ajout et retrait d'une ressource de calcul sur le réseau avec une adresse
       IP valide,
 \item accès aux imprimantes et aux serveurs du laboratoire restreint
       aux membres du laboratoire,
 \item protection à l'égard des attaques, virus... provenant du réseau
       (de l'université mais aussi d'Internet en général).
\end{enumerate}

\subsection{Un objectif permanent : la sécurisation des ressources}

Il est important de remarquer qu'une propriété transversale attendue de
tous ces services est la réactivité et l'évolutivité de ceux-ci. Bien
entendu, nous souhaitons que tous ces services soient disponibles avec
un niveau de sûreté et de sécurité maximal.

\section{Une proposition de schéma technique} \label{sec:solution}


\begin{figure}[!t]
\begin{center}
\includegraphics[bb=32 496 439 835, scale = 1]{lacl.pdf}
\end{center}
\caption{Proposition de schéma technique réseau pour le LACL.}
\end{figure}


Nous proposons dans cette section une solution technique simple, robuste et
éprouvée qui permettrait de répondre aux besoins de la section~\ref{sec:besoins}
par une gestion délocalisée de certaines ressources. 

En effet, une solution (classique) de type «~\emph{sous-réseau autonome sur une
classe IP privée avec une machine firewall en front-end}~» permet d'adresser les
problèmes précédemment décrits. Nous détaillons dans les sections suivantes les
éléments permettant de comprendre le schéma proposé.

\subsection{Placement des prises réseaux sur un même VLAN, isolé}

Le premier élément à mettre en place est de placer \emph{toutes les prises
réseau} (sauf une - voir point ci-dessous) du LACL sur un VLAN dédié, non routé
et distinct des réseaux existants (\emph{recherche}, \emph{enseignement} et
\emph{administration}) de l'université. En effet, de par la configuration
actuelle\footnote{Toutes les machines se trouvent actuellement sur le réseau
recherche. Cela a comme conséquence d'êtres accessibles par toutes les machines
de ce réseau : vers, virus, attaques diverses et autres sources de problèmes
mettent en danger les ressources informatiques du laboratoire.} il ne nous est
pas possible d'avoir une mise en commun des ressources du laboratoire,
\emph{distincte} des autres machines de l'université. 

Appelons ce VLAN le VLAN LACL. Il est essentiel que les prises de ce
VLAN ne soient pas routées afin de forcer les machines du réseau LACL à
passer par le routeur du laboratoire ; c'est lui qui aura la
responsabilité de gérer les adresses IP assignées aux machines du
VLAN. Ce routeur/firewall est présenté dans la section suivante.

\subsection{Administration d'une machine firewall}

Une machine effectuera le lien entre l'intérieur du sous-réseau LACL et
le reste du monde : le \emph{routeur/firewall}. Cette machine sera le
point de passage du flux réseau entre les machines du VLAN LACL et le
reste de l'université/internet. Inversement, elle sera le point de
passage obligé de tout flux entrant. Ce point de passage étant unique,
il sera plus facile pour le LACL de sécuriser l'accès à ses ressources.


\subsection{Gestion déléguée du sous-domaine \texttt{lacl.univ-paris12.fr}}

Dans cette configuration, la machine firewall gère tous les services réseaux se
situant à l'interface des deux mondes. Afin de disposer d'un contrôle sur les
services mail, web, ssh... il est essentiel que la sous-réseau
\texttt{lacl.univ-paris12.fr} soit délégué à cette machine qui gèrera le DNS et
tous les autres services de ce sous-réseau. La délégation de sous-réseau est un
acte technique simple qui permet de déléguer la gestion d'un sous-réseau à une
entité.

Afin de permettre la mise en {\oe}uvre des services décrits dans la
section~\ref{sec:besoins}, il est essentiels que les \emph{ports} de
cette machine ne soient pas filtrés par le firewall de
l'université. Ainsi (liste non exhaustive), les ports 22 (ssh), 25
(smtp), 80 (http), 443 (https), imaps (993), pop3s (995), 1194 (VPN),
2401 (cvs)8080 (http), ... \textbf{doivent êtres ouverts} et accessibles
depuis toutes machine connectée à Internet. C'est le firewall de ce VLAN
qui aura la responsabilité de filtrer le traffic indésirable, en accord
avec la politique de sécurité du CRI et de l'université.


\section{Mise en {\oe}uvre effective} \label{sec:conclusion}


Le schéma technique esquissé dans les sections qui précèdent est une solution
robuste, maîtrisée et évolutive car extrêmement standard dans les laboratoires
de recherche en informatique. La viabilité de ce projet repose sur deux éléments
clefs :
\begin{enumerate}
 \item Le laboratoire dispose en interne, via des enseignants/chercheurs
       spécialiste de la sécurité et de l'administration système, de toutes les
       ressources permettant une mise en place maîtrisée du schéma proposé. En
       particulier, ce schéma a déjà été mis en place, administré et validé pendant
       plusieurs années dans le cadre d'une précédente affectation d'un collègue.

 \item Le LACL dispose de plus d'un ingénieur système qui administre au
       quotidien les ressources du laboratoire. Ses compétences permettrons une mise
       en {\oe}uvre rapide du schéma qui aura été défini avec le CRI et un pilotage au
       jour le jour de celui-ci.
\end{enumerate}


\vfill{}Pour toutes ces raisons, nous aimerions entamer un cycle de
réflexion avec les instances responsables au sein de l'université pour
la mise en place et l'évolution des ressources informatiques. Pour que
ce projet puisse être mené à bien dans les meilleures conditions, il
nous semble essentiel que tous les acteurs - politiques et techniques -
soient impliqués.
\vfill{}
\end{document}


Bonjour a tous,
 
Peut-etre avez-vous remarque que l'acces ssh externe sur Soleil a ete
supprime par le CRI de l'universite ? Afin de mettre un terme a notre
dependance aux bons vouloirs du CRI, je vous propose que nous
etablissions la liste des besoins que nous avons en outils/ressources
reseaux et qui ne peuvent pas actuellement etre mis en place du fait
des contraintes trop fortes imposees par le CRI. Nous en avions parle
lors du dernier conseil de labo, mais j'ai un peu manque de temps pour
m'en occuper...
 
Comme toute equipe systeme, le CRI est d'une certaine facon dans son
'role' en nous bloquant le plus possible (chaque inge systeme a
presque pour ennemi objectif les utilisateurs !), mais, a l'heure de
l'autonomie et de l'excellence des universites, cette attitude n'est
plus tenable. On ne peut pas claironner partout que les universites
ont besoins d'equipes performantes et reactives et en meme temps ne
pas leur donner les moyens.
 
Actuellement, l'architecture mise en place par le CRI ne nous permet
pas d'avoir les services suivants :
 
  * acces ssh,
  * ajout de machines sur le reseau,
  * serveur VPN,
  * serveur CVS/SVN,
  * serveurs applicatifs dedies,
  * listes de diffusions,
  * banalisation des prises reseaux pour *tout usage*,
  * [vos avis ?]
 
et surtout nous place dans une situation de totale dependance
vis-a-vis des lubies du CRI (par exemple, une prise reseau ou du
traffic P2P aura ete detecte est bloquee !?!? Les distribution Linux
sont maintenant disponibles en P2P, des travaux de recherches sont
faits sur le sujet...).
 
Cela serait possible si nous avions une architecture (tres peu)
differente qui reposerait sur :
 
  * une unique prise reseau routee,
 
  * mise en place d'une machine faisant firewall/routeur (+ services
   associes) vers un sous-reseau en IP privees,
 
  * gestion du sous-domaine/sous-reseau sur le meme VLAN pour toutes
  les prises du labo ; aucun filtrage sur cette adresse ; ainsi, on
  pourrait gerer nos adresses mail @lacl, les listes de diffusion,
  serveurs CVS...
 
Cette organisation est standart et classique et requiert un minimum de
changement de la part du CRI. Elle est le garant de notre autonomie
(gestion des adresses IP, filtrage, reactivite accruee...), de notre
securite (seule la machine routeur est visible de l'exterieur) et du
meilleur fonctionnement de nos ressources. Actuellement, toutes les
machines sont visibles du reste de l'universite (en tout cas de tout
le sous-reseau des machines de recherche) et c'est une source
important de problemes potentiels...
 
J'attends vos remarques/ameliorations sur ce texte, en particulier la
partie [services qui ne sont pas possibles].
 


\end{document}
