Prevention des vers sur un reseau d'entreprise

:: Bonsoir,
::
:: Sur un reseau d'entreprise disons de 200 machines, proteger par un
:: firewall, et tous les postes clients sont equipes d'un antivirus.
::
:: Imaginons : Un weekend, un commercial, emmene son ordinateur
:: portable à la maison, et se connecte à Internet [Pratique non
:: autorise par la societe].
::
:: Le lundi matin, il arrive au boulot, et bien gentiellment connecte
:: son portable sur le reseau de l"entreprise. Et là, il diffuse
:: largement à tout le reseau le dernier vers à la mode.
::
:: [On a pas eu le temps de patcher les 200 machines].
::
:: Quelle solutions preconisez vous ? Merci

Juste une idée comme ca, sur laquelle je commence à reflechir. Certains
firewalls d'entreprise commerciaux disposent de clients VPN incluent un
firewall. Si tu es équipé de ce type de produit, tu peux tenter un rule set
du genre suivant :
- autoriser l'établissement du VPN
- autoriser le trafic HTTP, HTTPS et FTP vers le proxy interne de la société
- autoriser la lecture de mails (POP, IMAP, SMTP, Webmail ou protocoles
propriétaires) sur les serveur de la société
- autoriser l'accès aux serveurs de fichiers et d'impressions de la société
(NFS, SMB, NetBios...)
- refuser tout le reste
- parametrer le client VPN pour du Nat Transversal
Ainsi, le nomade qui va prendre son portable configuré en DHCP va se
brancher chez lui, se connecter à Internet. Et la, il ne pourra rien faire
de plus que si il était dans la société.
Bien sur, l'utilisateur ne doit pas etre admin de sa machine, pour éviter
qu'il flingue le client VPN-Firewall.
Dans mon cas, le ruleset est balancé automatiquement par le firewall quand
le client monte son tunnel VPN. Si le process de la montée du VPn en
demandait pas un password, on pourrait presque envisager que la machine
execute son script d'ouverture de session Windows (mise à jour d'antivirus,
déploiement des derniers patchs via SUS...).

Patrick

On 07 Jun 2004 16:32:19 GMT, Michel Arboi <arboi@alussinan.org> wrote:

Est-ce que ça vaut encore le coup de donner un portable à
l'utilisateur, dans ce cas ?

La question : pourquoi lui donner un portable ?

Si c'est pour utiliser un petit nombre de logiciels (Par exemple,
OpenOffice + un ou deux autres du même acabit, juste pour que
l'utilisateur puisse taper son rapport chez lui ou en déplacement),
bloquer tout le reste (la possibilité d'installer des logiciels ou du
matériel) me paraît tout à fait normal.

Si c'est pour qu'il puisse l'utiliser à des fins perso (installer des
jeux et tutti quanti), là effectivement, tout bloquer n'est pas
envisageable.

--
;-)
FLL, Epagneul Breton

martin <martin@noreply.fr> wrote:
| Bonsoir,

| Sur un reseau d'entreprise disons de 200 machines, proteger par un firewall,
| et tous les postes clients sont equipes d'un antivirus.

| Imaginons : Un weekend, un commercial, emmene son ordinateur portable à la
| maison, et se connecte à Internet [Pratique non autorise par la societe].

| Le lundi matin, il arrive au boulot, et bien gentiellment connecte son
| portable sur le reseau de l"entreprise. Et là, il diffuse largement à tout
| le reseau le dernier vers à la mode.

| [On a pas eu le temps de patcher les 200 machines].

| Quelle solutions preconisez vous ? Merci

1. Sur le plan technique :

1.1. Au niveau réseau

Si l'arrosage en interne est détecté, au niveau
des ACL de sortie du réseau de l'entreprise ou au niveau d'un
routeur interne :
=> désactiver le port de commutateur ou de répéteur auquel est
connectée physiquement le portable ;
=> au niveau du routeur le plus proche lui introduire une
adresse non routable en ARP ;
=> si vous avez un serveur DHCP, supprimer son adresse
physique du fichier de configuration ;
=> s'il est connecté en sans-fil bloquer son adresse MAC au
niveau du PA le plus proche ;
=> si l'accès aux commutateurs en interne est authentifié
en 802.1X, fermer le compte de l'utilisateur.

[N1] Attention toutefois, si l'utilisateur est vraiment mal
intentionné (volonté délibérée de disséminer un ver Windows en
interne) alors toutes ces mesures sont contournables.

[N2] Ces mesures n'empêcheront pas les premières réplications
de ver, jusqu'à détection.

1.2. Niveau système

Prévoir des systèmes où l'accès administrateur est un tant soit
protégé, et configurer l'interface réseau en dur sur une
adresse interne de l'entreprise.
Si vous avez des adresses IP publiques, alors toute connexion à
tout autre réseau nécessitera des interventions clairement
identifiables comme malveillantes.

[N1] S'applique, à moins d'envisager l'utilisation de systèmes
Unix où même le démarrage en mode SU est protégé au niveau du
matériel.

1.3. Gestion globale du risque

Prévoir une automatisation des mises à jour des divers systèmes
et des diverses BD de signatures anti-virales.
Mais avec un différé permettant d'éviter le coup de la mise à
jour qui tue.

Prévoir une diversification du parc micro-informatique de façon
à inhiber à la base tous les mécanismes qui s'appuient sur
l'homogénéité matérielle et logicielle.

[N3] La diversification ne supprime pas le risque, elle l'étale
et par là le rend plus facile à encaisser. C'est ce qu'on appelle
aussi ne pas mettre tous ses oeufs dans le même panier.

1.4. Mise en place d'un SAS

Prévoir un sous-réseau ne permettant l'accès qu'aux serveurs
de mise à jour et à des outils d'audit.
Rendre le passage par ce sas de décontamination obligatoire avant
tout raccordement dans le réseau.
Cette procédure me semble particulièrement lourde en temps humain
et très difficile à rendre obligatoire techniquement. Pour la rendre
techniquement fiable, il faut aussi définir une procédure de sortie
de façøn à ce que lors de sa sortie un portable soit invalidé
dans le réseau interne (par l'une des méthodes en 1.1.).

2. Sur le plan humain

2.1. Communication

Profitez de cet incident pour rappeler quel risque représente
systématiquement la connexion multiple (bien plus que la mobilité
en soi).
En effet une connexion double en interne dans l'entreprise
avec d'une part une carte Etherent sur le réseau interne et l'autre
sur un modem ADSL raccordé à un FAI peut avoir les mêmes
conséquences déplorables avec un poste fixe qui avait été
simplement prévu pour permettre de la maintenance à distance
à une entreprise spécialisée.

Profitez de cette épidémie plus ou moins maîtrisée pour rappeler
que l'outil informatique est un outil appartenant à
l'entreprise et confié à un salarié à la condition qu'il le
maintienne en bon état. Ce qui veut dire selon les systèmes
utilisés (Windows, Linux, MacOS X) plus ou moins de tâches vitales
d'entretien :
- mise à jour du système,
- mise à jour des BD de signatures anti-virales,
opérations à réaliser depuis le réseau interne
(éventuellement depuis les serveurs internes pour éviter le coup
de la mise à jour qui tue).

2.2. Décontamination

Faites passer le PC en question par une procédure
d'audit puis de décontamination radicale :
- recherche des traces de connexions et conservation sur
un support externe ;
[ opération à réaliser en présence de l'utilisateur
du portable, et qui n'est possible que si ça a été prévu dans les
limitations d'usage et possibilité de contrôle portées à
sa connaissance : note de service ou R.I. ]
- formattage des disques durs ;
- réinstallation de l'image système standard ;
- réinstallation éventuelle des données utilisateurs à partir
des dernières sauvegardes faites en interne.

2.3. Bilan

Faites un bilan de ce qu'ont gagné et perdu l'utilisateur
du portable, l'entreprise, les vendeurs de logiciel de mauvaise
qualité, et les vendeurs d'anti-virus et de coupe-feu individuel
qui vivent à leurs dépens.
Amandez éventuellement le R.I. pour insister sur l'interdiction de
connexion multiple

Si vous avez mieux, j'achète.
--
daniel Azuelos Pôle informatique - Institut Pasteur

On 07 Jun 2004 22:22:49 GMT, Daniel Azuelos <dan@pasteur.fr> wrote:

Si l'arrosage en interne est détecté

... c'est trop tard.

--
;-)
FLL, Epagneul Breton

Le Mon, 07 Jun 2004 16:32:19 +0000, Michel Arboi a écrit :

Je n'ai pas l'impression que ça réponde à la question initiale...
Il veut empêcher les portables corporate de se connecter ailleurs, pas
l'inverse.

S'il ne veut pas que ses postes aillent se connecter ailleurs, ben il file
pas de laptop et c'est réglé. Ni plus, ni moins. Parce que même avec
une configuration durcie, l'utilisateur motivé arrivera toujours à
adapter la configuration de son LAN pour pouvoir se connecter sans avoir
besoin de modifier la conf réseau de son laptop.

Donc pour moi, le problème, ce n'est pas tant de pouvoir se connecter
dehors, mais surtout de pouvoir le faire dans un cadre très stricte, avec
des outils de sécurité (AV, PFW, etc.) non désactivable. À partir de
là, il doit contrôler que ce qui rentre est bien conforme à la
politique de sécurité. À partir du moment où on a un switch qui
supporte EAP, monter un RADIUS en PEAP ou EAP-TLS, c'est peanuts.


--
Moi je dis : 3 lignes c'est suspect, c'est fait pour le GCU.
-+- SP in Guide du Neuneu sur Usenet : Allez hop ! Au GNoUf -+-

Fabien LE LEZ <gramster@gramster.com> wrote:
| On 07 Jun 2004 22:22:49 GMT, Daniel Azuelos <dan@pasteur.fr> wrote:

|>Si l'arrosage en interne est détecté

| ... c'est trop tard.

[ Je remets la fin de ma phrase, parce que ça se tenait un peu ]
... au niveau
des ACL de sortie du réseau de l'entreprise ou au niveau d'un
routeur interne :

Non il n'est pas « trop » tard, puisque ces paquets, s'ils sont arrêtés
au niveau des ACL de sortie du réseau (typiquement Egress filtering,
135/udp, 445/udp...) c'est qu'ils ne passent pas, et c'est que les
virus qui ne veulent se propager à l'aise doivent :
- éviter de tuer leur hôte trop vite ;
- éviter de tuer leur réseau local trop vite ;
- éviter de tuer leur chemin de sortie trop vite.

Donc ils essayent de se propager un peu plus loin,
exactement comme les ronds de sorcières.

Enfin c'est vérifié par la pratique :
tu as raison, c'est tard, mais les dégâts sont faibles en interne,
et vite circonscrits.
--
daniel Azuelos Pôle informatique - Institut Pasteur