VPN dans DMZ, où placer le PIX 501 ?

Dominique Blas

25/01/2005 à 14:55

HRT wrote:

[...]

La question serait mieux placée dans fcsecurite.

le but du vpn est de pouvoir atteindre depuis un site distant, notre LAN.

Je me demande où placer le Cisco Pix 501 dans la dmz ?
comment pouvoir atteindre le PIX depuis le site distant ?

au niveau d'iptables quelles sont les modifications à apporter ?
- j'ai mis en forward le port 500 udp
- j'ai mis en forward le protocole 50 et 51

si vous voulez plus d'info n'hésitez pas.
Et pourquoi ne pas le placer sur le LAN ? C'est sa place en tant que tête de

pont VPN.
Qui plus est, dans la mesure où je suppose qu'il y a de la translation
d'adresses le proto 51 ne sert à rien. D'ailleurs qui l'utilise ?
Tu as confiance dans le PIX tout de même, non ? C'est plus sophistiqué et
performant qu'un Iptables.

Si ce n'est pas le cas le placer dans la DMZ en limitant les services
auxquels ont droit les nomades. Mais le placer dans la DMZ c'est compliqué
en terme de config.

Et pourquoi ne pas lui faire jouer le rôle de firewall ? Un PIX c'est un
firewall avant tout non ? Ca simplifierait l'archi.

db

--
email : usenet blas net

Cedric Blancher

25/01/2005 à 15:21

Le Tue, 25 Jan 2005 13:55:31 +0000, Dominique Blas a écrit :

La question serait mieux placée dans fcsecurite.

Ben alors faut pas mettre de fu2 retour sur fr.comp.resaux.ip :))) Je
repositionne.

Et pourquoi ne pas le placer sur le LAN ? C'est sa place en tant que
tête de pont VPN.

Si tu considères que tes nomades ont le même niveau de sécurité que
les postes de ton LAN, tu peux le voir comme ça. Maintenant, prenons le
problème différemment. Est-ce que tu mettrais un hotspot WiFi au milieu
de ton LAN ? Non ? Ben si un gars se connecter en VPN depuis un hotspot
WiFi, il vient d'ouvrir une avenue entre le-dit hotspot et ton LAN...

Dans la pratique, tu ne peux pas considérer qu'un nomade à le même
niveau de sécurité qu'un poste de ton LAN. Dans le cas d'un lien
inter-site, c'est à peine différent. Comment est administré la réseau
distant ? Est-on sûr de la sécurité du réseau en question ? Bref, pas
mal de raisons qui poussent à filtrer les accès VPN.

Exemple par le pratique : voir le nombre de boîtes qui ont ramassé
Blaster ou Sasser à travers un lien VPN...

Qui plus est, dans la mesure où je suppose qu'il y a de la translation
d'adresses le proto 51 ne sert à rien.

Soit on fait de la NAT sur le chemin du lien IPSEC, auquel cas AH va plus
que servir à rien, il va empêcher le tunnel de fonctionner.
Soit le lien IPSEC débouche sur la DMZ avec un LAN natté, mais je ne
vois pas le rapport avec la choucroute.

D'ailleurs qui l'utilise ?

Moi, et plein de monde aussi.

Tu as confiance dans le PIX tout de même, non ?

En ce qui me concerne, non. Un constructeur qui laisse traîner des mots
de passe non documentés dans certaines de ses appliances, j'ai du mal à
lui faire confiance...

C'est plus sophistiqué et performant qu'un Iptables.

Surtout un PIX501. Même mon Linksys avec un firmware maison il en fait
autant (même un peu plus en VPN). Et puis les PIX, c'est pas comme les
routeurs, c'est du bon gros PC (cf. 535, 525, 515 par exemple) avec un
PIX OS Cisco dessus.

Si ce n'est pas le cas le placer dans la DMZ en limitant les services
auxquels ont droit les nomades. Mais le placer dans la DMZ c'est
compliqué en terme de config.

Ben ouais, dès qu'on veut faire de la sécurité, ça devient chiant.
C'est lourd ça. Pour moi, c'est une simple question de routage/filtrage,
dont la "difficulté" dépend essentiellement des connexions qui seront
amenées à transiter par le lien.

Et pourquoi ne pas lui faire jouer le rôle de firewall ? Un PIX c'est
un firewall avant tout non ? Ca simplifierait l'archi.

Et pourquoi l'utiliser ? Je veux dire, le firewall Linux, c'est aussi un
passerelle IPSEC. Ça simplifierait l'archi :) Et pourquoi alors payer
cher un PIX501* alors qu'un Linux ferait exactement la même chose
avec de meilleures performances (en utilisant OpenS/WAN ou Racoon) ?

* qui fait quand même cher du kilo et du kilobit/s
Jusqu'à 60Mbps de BP (i.e. sans règle je suppose), rien de transcendant
3Mbps en 3DES et 4.5Mbps en AES, bof...
10 SA maximum en IPSEC :(

--
panic ("No CPUs found. System halted.n");
2.4.3 linux/arch/parisc/kernel/setup.c

Le Tue, 25 Jan 2005 13:55:31 +0000, Dominique Blas a écrit :

La question serait mieux placée dans fcsecurite.

Ben alors faut pas mettre de fu2 retour sur fr.comp.resaux.ip :))) Je
repositionne.

Et pourquoi ne pas le placer sur le LAN ? C'est sa place en tant que
tête de pont VPN.

Si tu considères que tes nomades ont le même niveau de sécurité que
les postes de ton LAN, tu peux le voir comme ça. Maintenant, prenons le
problème différemment. Est-ce que tu mettrais un hotspot WiFi au milieu
de ton LAN ? Non ? Ben si un gars se connecter en VPN depuis un hotspot
WiFi, il vient d'ouvrir une avenue entre le-dit hotspot et ton LAN...

Dans la pratique, tu ne peux pas considérer qu'un nomade à le même
niveau de sécurité qu'un poste de ton LAN. Dans le cas d'un lien
inter-site, c'est à peine différent. Comment est administré la réseau
distant ? Est-on sûr de la sécurité du réseau en question ? Bref, pas
mal de raisons qui poussent à filtrer les accès VPN.

Exemple par le pratique : voir le nombre de boîtes qui ont ramassé
Blaster ou Sasser à travers un lien VPN...

Qui plus est, dans la mesure où je suppose qu'il y a de la translation
d'adresses le proto 51 ne sert à rien.

Soit on fait de la NAT sur le chemin du lien IPSEC, auquel cas AH va plus
que servir à rien, il va empêcher le tunnel de fonctionner.
Soit le lien IPSEC débouche sur la DMZ avec un LAN natté, mais je ne
vois pas le rapport avec la choucroute.

D'ailleurs qui l'utilise ?

Moi, et plein de monde aussi.

Tu as confiance dans le PIX tout de même, non ?

En ce qui me concerne, non. Un constructeur qui laisse traîner des mots
de passe non documentés dans certaines de ses appliances, j'ai du mal à
lui faire confiance...

C'est plus sophistiqué et performant qu'un Iptables.

Surtout un PIX501. Même mon Linksys avec un firmware maison il en fait
autant (même un peu plus en VPN). Et puis les PIX, c'est pas comme les
routeurs, c'est du bon gros PC (cf. 535, 525, 515 par exemple) avec un
PIX OS Cisco dessus.

Si ce n'est pas le cas le placer dans la DMZ en limitant les services
auxquels ont droit les nomades. Mais le placer dans la DMZ c'est
compliqué en terme de config.

Ben ouais, dès qu'on veut faire de la sécurité, ça devient chiant.
C'est lourd ça. Pour moi, c'est une simple question de routage/filtrage,
dont la "difficulté" dépend essentiellement des connexions qui seront
amenées à transiter par le lien.

Et pourquoi ne pas lui faire jouer le rôle de firewall ? Un PIX c'est
un firewall avant tout non ? Ca simplifierait l'archi.

Et pourquoi l'utiliser ? Je veux dire, le firewall Linux, c'est aussi un
passerelle IPSEC. Ça simplifierait l'archi :) Et pourquoi alors payer
cher un PIX501* alors qu'un Linux ferait exactement la même chose
avec de meilleures performances (en utilisant OpenS/WAN ou Racoon) ?

* qui fait quand même cher du kilo et du kilobit/s
Jusqu'à 60Mbps de BP (i.e. sans règle je suppose), rien de transcendant
3Mbps en 3DES et 4.5Mbps en AES, bof...
10 SA maximum en IPSEC :(

--
panic ("No CPUs found. System halted.n");
2.4.3 linux/arch/parisc/kernel/setup.c

Vous avez filtré cet utilisateur ! Consultez son message

Le Tue, 25 Jan 2005 13:55:31 +0000, Dominique Blas a écrit :

La question serait mieux placée dans fcsecurite.

Ben alors faut pas mettre de fu2 retour sur fr.comp.resaux.ip :))) Je
repositionne.

Et pourquoi ne pas le placer sur le LAN ? C'est sa place en tant que
tête de pont VPN.

Si tu considères que tes nomades ont le même niveau de sécurité que
les postes de ton LAN, tu peux le voir comme ça. Maintenant, prenons le
problème différemment. Est-ce que tu mettrais un hotspot WiFi au milieu
de ton LAN ? Non ? Ben si un gars se connecter en VPN depuis un hotspot
WiFi, il vient d'ouvrir une avenue entre le-dit hotspot et ton LAN...

Dans la pratique, tu ne peux pas considérer qu'un nomade à le même
niveau de sécurité qu'un poste de ton LAN. Dans le cas d'un lien
inter-site, c'est à peine différent. Comment est administré la réseau
distant ? Est-on sûr de la sécurité du réseau en question ? Bref, pas
mal de raisons qui poussent à filtrer les accès VPN.

Exemple par le pratique : voir le nombre de boîtes qui ont ramassé
Blaster ou Sasser à travers un lien VPN...

Qui plus est, dans la mesure où je suppose qu'il y a de la translation
d'adresses le proto 51 ne sert à rien.

Soit on fait de la NAT sur le chemin du lien IPSEC, auquel cas AH va plus
que servir à rien, il va empêcher le tunnel de fonctionner.
Soit le lien IPSEC débouche sur la DMZ avec un LAN natté, mais je ne
vois pas le rapport avec la choucroute.

D'ailleurs qui l'utilise ?

Moi, et plein de monde aussi.

Tu as confiance dans le PIX tout de même, non ?

En ce qui me concerne, non. Un constructeur qui laisse traîner des mots
de passe non documentés dans certaines de ses appliances, j'ai du mal à
lui faire confiance...

C'est plus sophistiqué et performant qu'un Iptables.

Surtout un PIX501. Même mon Linksys avec un firmware maison il en fait
autant (même un peu plus en VPN). Et puis les PIX, c'est pas comme les
routeurs, c'est du bon gros PC (cf. 535, 525, 515 par exemple) avec un
PIX OS Cisco dessus.

Si ce n'est pas le cas le placer dans la DMZ en limitant les services
auxquels ont droit les nomades. Mais le placer dans la DMZ c'est
compliqué en terme de config.

Ben ouais, dès qu'on veut faire de la sécurité, ça devient chiant.
C'est lourd ça. Pour moi, c'est une simple question de routage/filtrage,
dont la "difficulté" dépend essentiellement des connexions qui seront
amenées à transiter par le lien.

Et pourquoi ne pas lui faire jouer le rôle de firewall ? Un PIX c'est
un firewall avant tout non ? Ca simplifierait l'archi.

Et pourquoi l'utiliser ? Je veux dire, le firewall Linux, c'est aussi un
passerelle IPSEC. Ça simplifierait l'archi :) Et pourquoi alors payer
cher un PIX501* alors qu'un Linux ferait exactement la même chose
avec de meilleures performances (en utilisant OpenS/WAN ou Racoon) ?

* qui fait quand même cher du kilo et du kilobit/s
Jusqu'à 60Mbps de BP (i.e. sans règle je suppose), rien de transcendant
3Mbps en 3DES et 4.5Mbps en AES, bof...
10 SA maximum en IPSEC :(

--
panic ("No CPUs found. System halted.n");
2.4.3 linux/arch/parisc/kernel/setup.c

Dominique Blas

25/01/2005 à 17:16

Cedric Blancher wrote:

Le Tue, 25 Jan 2005 13:55:31 +0000, Dominique Blas a écrit :
La question serait mieux placée dans fcsecurite.

Ben alors faut pas mettre de fu2 retour sur fr.comp.resaux.ip :))) Je
repositionne.

Et pourquoi ne pas le placer sur le LAN ? C'est sa place en tant que
tête de pont VPN.

Si tu considères que tes nomades ont le même niveau de sécurité que
les postes de ton LAN, tu peux le voir comme ça. Maintenant, prenons le
problème différemment. Est-ce que tu mettrais un hotspot WiFi au milieu
de ton LAN ? Non ?
Un hostspot est par définition public. Là nous parlons d'une population

d'entreprise utilisant un moyen d'accès public comme c'est généralement le
cas qu'il s'agisse du RTC, du réseau local d'une autre entreprise ou d'un
hotspot. Cette population est privée.

Ben si un gars se connecter en VPN depuis un hotspot
WiFi, il vient d'ouvrir une avenue entre le-dit hotspot et ton LAN...

Si le VPN est chiffré (l'inverse est un non-sens de nos jours) que
risque-t-il ? Mises à part les perturbations locales ... pas grand chose.
Tant que la NSA ne traîne pas dans le coin et elle n'y traînera pas si le
nomade n'appartient pas à un secteur stratégique.
Du reste nous ne sommes plus en 199x où, la plupart des employés étant
géographiquement localisés au sein de l'entreprise on pouvait se permettre
de mettre l'accent sur la sécurité des quelques rares postes nomades.
Désormais les usages ont bien évolué (qui reste encore dans son
entreprise ?) et la technologie également, favorisant le télétravail dans
de bonnes conditions.

Dans la pratique, tu ne peux pas considérer qu'un nomade à le même
niveau de sécurité qu'un poste de ton LAN.

Certes. Et encore ... Je suis plus enclin à autoriser l'accès à mes serveurs
depuis des postes que je sais verrouillés que depuis des postes locaux
relativement ouverts sur lesquels tout et n'importe quoi peut être installé
(surtout lorsqu'il y a des stagiaires au mois d'août).
80% des menaces viennent toujours de l'intérieur géographique à ce jour.
Et si filtrage il doit y avoir je le préfère sincèrement en terme de
machines pouvant être accédées depuis les nomades ce qui est plus simple
si firewall et tête de pont VPN sont fusionnés.

Dans le cas d'un lien
inter-site, c'est à peine différent. Comment est administré la réseau
distant ? Est-on sûr de la sécurité du réseau en question ? Bref, pas
mal de raisons qui poussent à filtrer les accès VPN.

Oui, intranet et réseau local sont des choses différentes. Voir mon §
précédent.

Exemple par le pratique : voir le nombre de boîtes qui ont ramassé
Blaster ou Sasser à travers un lien VPN...

Elles le rammasseront dès que le nomade se connectera en interne ou via la
DMZ, ça ne change rien.
Ou la politique associe périmètre interne de sécurité au périmètre
géographique ou elle l'associe au niveau fonctionnel ce qui fait rentrer
les nomades dedans qu'ils soient à l'intérieur de l'entreprise ou à
l'extérieur.
Les 2 ont des inconvénients et des avantages vis-à-vis des nomades.
La première est permissive face aux postes nomades qui se raccordent au
réseau local mais ne veut pas entendre parler du monde extérieur.
Donc s'il n'y a pas la batterie suffisante d'antivirus téléchargés et
exécutés dès le raccordement au réseau ... pas de chance : Sasser à rien.

La seconde a mis en place des moyens efficaces minimisant les risques
d'infection ou de détournement des postes (comptes utilisateurs,
pratiquement aucun droit sur la machine nomade, antivirus permanent se
mettant à jour dès la connexion au réseau d'entrperise, les gosses ne
peuvent pas jouer avec, chiffrement des partitions, etc) qu'ils soient
nomades ou fixes et, dans ce cas, ma foi, que le poste de travail soit au
sein de l'entreprise géographique ou pas, cela ne change pas grand chose.
J'aurais même tendance à être plus confortable (oh, un anglissisme), à
l'aise, avec les postes nomades.

[...]

D'ailleurs qui l'utilise ?

Moi, et plein de monde aussi.
Comme plein de monde a des virus aussi :-) Ce n'est pas une raison.

Mais au final, c'est pour faire joli ou c'est vraiment utile ?
Dans quel contexte ?

Tu as confiance dans le PIX tout de même, non ?

En ce qui me concerne, non. Un constructeur qui laisse traîner des mots
de passe non documentés dans certaines de ses appliances, j'ai du mal à
lui faire confiance...
Il sont TOUS comme ça (y'a eu un troll récemment sur le sujet). Linux a ses

tares, xBSD également il ne faut pas l'oublier mais elles sont rendues
publiques (enfin dès que quelqu'un s'en aperçoit) c'est un avantage.
J'ai bien plus tendance à utiliser les logiciels libres pour cette dernière
raison notamment (et pour le côté gratuit bien entendu).
Car prétendre faire de la sécurité avec des matériels et des logiciels
propriétaires dont on ne sait pas grand chose est, avouons-le, un léger
non-sens ! Mais le marché est le marché.
Mais là n'était pas la question. Le PIX est déjà là !

C'est plus sophistiqué et performant qu'un Iptables.

Surtout un PIX501. Même mon Linksys avec un firmware maison il en fait
autant (même un peu plus en VPN). Et puis les PIX, c'est pas comme les
routeurs, c'est du bon gros PC (cf. 535, 525, 515 par exemple) avec un
PIX OS Cisco dessus.
C'est l'IOS qui est performant : pratiquement 20 ans d'expérience dans les

réseaux. Bon BSD aussi tu me diras.
D'aucuns prétendront que l'IOS est lourd est plus adapté à ce qu'il est
sensé faire aujourd'hui. Soit.

[...]

Et pourquoi l'utiliser ? Je veux dire, le firewall Linux, c'est aussi un
passerelle IPSEC. Ça simplifierait l'archi :) Et pourquoi alors payer
cher un PIX501* alors qu'un Linux ferait exactement la même chose
avec de meilleures performances (en utilisant OpenS/WAN ou Racoon) ?
J'ai proposé l'inverse pour la raison suivante.

Le PIX est plus fin dans ses caractéristiques de gestion dynamique du
filtrage. Netfilter gratte progressivement mais n'est pas encore à ce
niveau.
Par ailleurs le 501, le gars semble déjà le posséder et peut donc
reconvertir le Linux en poste de travail alors qu'un PIX ça ne se
reconvertit en rien d'autre que PIX (support de pot de fleurs ?).

Maintenant il fait ce qu'il veut. S'il ne subit pas de pression qu'il
poursuive avec le Linux.

En effet, le Linux est bien plus évolutif (peut servir de serveur de
certificats), le 501 non.
Le Linux peut gérer des dizaines de nomades simultanés plus des quantités de
tunnels fixes haut-débit SIMULTANEMENT pour peu que la CPU soit rapide (> 2 Ghz), le 501 non.
Le 501 a des réglages de filtrage fin le Linux non (mais en a-t-on besoin
ici ?).
Le 501 coute relativement cher (au moins autant que la machine qui supporte
le Linux), c'est con de le mettre de côté mais il peut toujours être
réutilisé en tant que routeur d'agences.

En conclusion, dans l'ordre décroissant des priorités :
fusionner firewalling et tête de pont VPN ;
et, selon politique de sécurité adoptée :
tête de pont VPN au sein du LAN (préférable en terme de simplicité si
politique adéquate observée)
ou
tête de pont VPN au sein de la DMZ.

db

PS : ah, encore une chose. En ce qui concerne l'aspect proclamé CHIANT de la
sécurité des SI, je ne suis pas d'accord. Une bonne sécurité est avant tout
une sécurité simple et de bon sens. Son degré d'application et de respect
est inversement proportionnel à son degré de complexité.
En d'autres termes si c'est trop pénible à appliquer, un jour, une nuit,
l'administrateur (ou l'administateur délégué) oubliera un élément
(fondamental) et laissera la porte ouverte.
Alors oui, on peut très bien installer le SELinux, régler au minimum les
capacités (capabilities) du noyau Linux autorisant le minimum de permission
à chaque application mais une machine doit vivre également et s'il faut
systématiquement passer par tout un système de commandes avant de pouvoir
mettre à jour un site Web, changer une zone ou installer une nouvelle
application c'est tellement pénible que soit on n'installe rien ou on
débride un peu plus à chaque fois.

La sécurité maximale vaut toutefois le coup (je n'ai pas écrit le contraire)
mais dans des organisations conséquentes où le personnel est conséquent et
bien sensibilisé/formé. Ce qui est extrêmement rare en dehors des grands
comptes (et encore).
--
email : usenet blas net

Cedric Blancher wrote:

Le Tue, 25 Jan 2005 13:55:31 +0000, Dominique Blas a écrit :

La question serait mieux placée dans fcsecurite.

Ben alors faut pas mettre de fu2 retour sur fr.comp.resaux.ip :))) Je
repositionne.

Et pourquoi ne pas le placer sur le LAN ? C'est sa place en tant que
tête de pont VPN.

Si tu considères que tes nomades ont le même niveau de sécurité que
les postes de ton LAN, tu peux le voir comme ça. Maintenant, prenons le
problème différemment. Est-ce que tu mettrais un hotspot WiFi au milieu
de ton LAN ? Non ?
Un hostspot est par définition public. Là nous parlons d'une population

d'entreprise utilisant un moyen d'accès public comme c'est généralement le
cas qu'il s'agisse du RTC, du réseau local d'une autre entreprise ou d'un
hotspot. Cette population est privée.

Ben si un gars se connecter en VPN depuis un hotspot
WiFi, il vient d'ouvrir une avenue entre le-dit hotspot et ton LAN...

Si le VPN est chiffré (l'inverse est un non-sens de nos jours) que
risque-t-il ? Mises à part les perturbations locales ... pas grand chose.
Tant que la NSA ne traîne pas dans le coin et elle n'y traînera pas si le
nomade n'appartient pas à un secteur stratégique.
Du reste nous ne sommes plus en 199x où, la plupart des employés étant
géographiquement localisés au sein de l'entreprise on pouvait se permettre
de mettre l'accent sur la sécurité des quelques rares postes nomades.
Désormais les usages ont bien évolué (qui reste encore dans son
entreprise ?) et la technologie également, favorisant le télétravail dans
de bonnes conditions.

Dans la pratique, tu ne peux pas considérer qu'un nomade à le même
niveau de sécurité qu'un poste de ton LAN.

Certes. Et encore ... Je suis plus enclin à autoriser l'accès à mes serveurs
depuis des postes que je sais verrouillés que depuis des postes locaux
relativement ouverts sur lesquels tout et n'importe quoi peut être installé
(surtout lorsqu'il y a des stagiaires au mois d'août).
80% des menaces viennent toujours de l'intérieur géographique à ce jour.
Et si filtrage il doit y avoir je le préfère sincèrement en terme de
machines pouvant être accédées depuis les nomades ce qui est plus simple
si firewall et tête de pont VPN sont fusionnés.

Dans le cas d'un lien
inter-site, c'est à peine différent. Comment est administré la réseau
distant ? Est-on sûr de la sécurité du réseau en question ? Bref, pas
mal de raisons qui poussent à filtrer les accès VPN.

Oui, intranet et réseau local sont des choses différentes. Voir mon §
précédent.

Exemple par le pratique : voir le nombre de boîtes qui ont ramassé
Blaster ou Sasser à travers un lien VPN...

Elles le rammasseront dès que le nomade se connectera en interne ou via la
DMZ, ça ne change rien.
Ou la politique associe périmètre interne de sécurité au périmètre
géographique ou elle l'associe au niveau fonctionnel ce qui fait rentrer
les nomades dedans qu'ils soient à l'intérieur de l'entreprise ou à
l'extérieur.
Les 2 ont des inconvénients et des avantages vis-à-vis des nomades.
La première est permissive face aux postes nomades qui se raccordent au
réseau local mais ne veut pas entendre parler du monde extérieur.
Donc s'il n'y a pas la batterie suffisante d'antivirus téléchargés et
exécutés dès le raccordement au réseau ... pas de chance : Sasser à rien.

La seconde a mis en place des moyens efficaces minimisant les risques
d'infection ou de détournement des postes (comptes utilisateurs,
pratiquement aucun droit sur la machine nomade, antivirus permanent se
mettant à jour dès la connexion au réseau d'entrperise, les gosses ne
peuvent pas jouer avec, chiffrement des partitions, etc) qu'ils soient
nomades ou fixes et, dans ce cas, ma foi, que le poste de travail soit au
sein de l'entreprise géographique ou pas, cela ne change pas grand chose.
J'aurais même tendance à être plus confortable (oh, un anglissisme), à
l'aise, avec les postes nomades.

[...]

D'ailleurs qui l'utilise ?

Moi, et plein de monde aussi.
Comme plein de monde a des virus aussi :-) Ce n'est pas une raison.

Mais au final, c'est pour faire joli ou c'est vraiment utile ?
Dans quel contexte ?

Tu as confiance dans le PIX tout de même, non ?

En ce qui me concerne, non. Un constructeur qui laisse traîner des mots
de passe non documentés dans certaines de ses appliances, j'ai du mal à
lui faire confiance...
Il sont TOUS comme ça (y'a eu un troll récemment sur le sujet). Linux a ses

tares, xBSD également il ne faut pas l'oublier mais elles sont rendues
publiques (enfin dès que quelqu'un s'en aperçoit) c'est un avantage.
J'ai bien plus tendance à utiliser les logiciels libres pour cette dernière
raison notamment (et pour le côté gratuit bien entendu).
Car prétendre faire de la sécurité avec des matériels et des logiciels
propriétaires dont on ne sait pas grand chose est, avouons-le, un léger
non-sens ! Mais le marché est le marché.
Mais là n'était pas la question. Le PIX est déjà là !

C'est plus sophistiqué et performant qu'un Iptables.

Surtout un PIX501. Même mon Linksys avec un firmware maison il en fait
autant (même un peu plus en VPN). Et puis les PIX, c'est pas comme les
routeurs, c'est du bon gros PC (cf. 535, 525, 515 par exemple) avec un
PIX OS Cisco dessus.
C'est l'IOS qui est performant : pratiquement 20 ans d'expérience dans les

réseaux. Bon BSD aussi tu me diras.
D'aucuns prétendront que l'IOS est lourd est plus adapté à ce qu'il est
sensé faire aujourd'hui. Soit.

[...]

Et pourquoi l'utiliser ? Je veux dire, le firewall Linux, c'est aussi un
passerelle IPSEC. Ça simplifierait l'archi :) Et pourquoi alors payer
cher un PIX501* alors qu'un Linux ferait exactement la même chose
avec de meilleures performances (en utilisant OpenS/WAN ou Racoon) ?
J'ai proposé l'inverse pour la raison suivante.

Le PIX est plus fin dans ses caractéristiques de gestion dynamique du
filtrage. Netfilter gratte progressivement mais n'est pas encore à ce
niveau.
Par ailleurs le 501, le gars semble déjà le posséder et peut donc
reconvertir le Linux en poste de travail alors qu'un PIX ça ne se
reconvertit en rien d'autre que PIX (support de pot de fleurs ?).

Maintenant il fait ce qu'il veut. S'il ne subit pas de pression qu'il
poursuive avec le Linux.

En effet, le Linux est bien plus évolutif (peut servir de serveur de
certificats), le 501 non.
Le Linux peut gérer des dizaines de nomades simultanés plus des quantités de
tunnels fixes haut-débit SIMULTANEMENT pour peu que la CPU soit rapide (> 2 Ghz), le 501 non.
Le 501 a des réglages de filtrage fin le Linux non (mais en a-t-on besoin
ici ?).
Le 501 coute relativement cher (au moins autant que la machine qui supporte
le Linux), c'est con de le mettre de côté mais il peut toujours être
réutilisé en tant que routeur d'agences.

En conclusion, dans l'ordre décroissant des priorités :
fusionner firewalling et tête de pont VPN ;
et, selon politique de sécurité adoptée :
tête de pont VPN au sein du LAN (préférable en terme de simplicité si
politique adéquate observée)
ou
tête de pont VPN au sein de la DMZ.

db

PS : ah, encore une chose. En ce qui concerne l'aspect proclamé CHIANT de la
sécurité des SI, je ne suis pas d'accord. Une bonne sécurité est avant tout
une sécurité simple et de bon sens. Son degré d'application et de respect
est inversement proportionnel à son degré de complexité.
En d'autres termes si c'est trop pénible à appliquer, un jour, une nuit,
l'administrateur (ou l'administateur délégué) oubliera un élément
(fondamental) et laissera la porte ouverte.
Alors oui, on peut très bien installer le SELinux, régler au minimum les
capacités (capabilities) du noyau Linux autorisant le minimum de permission
à chaque application mais une machine doit vivre également et s'il faut
systématiquement passer par tout un système de commandes avant de pouvoir
mettre à jour un site Web, changer une zone ou installer une nouvelle
application c'est tellement pénible que soit on n'installe rien ou on
débride un peu plus à chaque fois.

La sécurité maximale vaut toutefois le coup (je n'ai pas écrit le contraire)
mais dans des organisations conséquentes où le personnel est conséquent et
bien sensibilisé/formé. Ce qui est extrêmement rare en dehors des grands
comptes (et encore).
--
email : usenet blas net

Vous avez filtré cet utilisateur ! Consultez son message

Cedric Blancher wrote:

Le Tue, 25 Jan 2005 13:55:31 +0000, Dominique Blas a écrit :
La question serait mieux placée dans fcsecurite.

Ben alors faut pas mettre de fu2 retour sur fr.comp.resaux.ip :))) Je
repositionne.

Et pourquoi ne pas le placer sur le LAN ? C'est sa place en tant que
tête de pont VPN.

Si tu considères que tes nomades ont le même niveau de sécurité que
les postes de ton LAN, tu peux le voir comme ça. Maintenant, prenons le
problème différemment. Est-ce que tu mettrais un hotspot WiFi au milieu
de ton LAN ? Non ?
Un hostspot est par définition public. Là nous parlons d'une population

d'entreprise utilisant un moyen d'accès public comme c'est généralement le
cas qu'il s'agisse du RTC, du réseau local d'une autre entreprise ou d'un
hotspot. Cette population est privée.

Ben si un gars se connecter en VPN depuis un hotspot
WiFi, il vient d'ouvrir une avenue entre le-dit hotspot et ton LAN...

Si le VPN est chiffré (l'inverse est un non-sens de nos jours) que
risque-t-il ? Mises à part les perturbations locales ... pas grand chose.
Tant que la NSA ne traîne pas dans le coin et elle n'y traînera pas si le
nomade n'appartient pas à un secteur stratégique.
Du reste nous ne sommes plus en 199x où, la plupart des employés étant
géographiquement localisés au sein de l'entreprise on pouvait se permettre
de mettre l'accent sur la sécurité des quelques rares postes nomades.
Désormais les usages ont bien évolué (qui reste encore dans son
entreprise ?) et la technologie également, favorisant le télétravail dans
de bonnes conditions.

Dans la pratique, tu ne peux pas considérer qu'un nomade à le même
niveau de sécurité qu'un poste de ton LAN.

Certes. Et encore ... Je suis plus enclin à autoriser l'accès à mes serveurs
depuis des postes que je sais verrouillés que depuis des postes locaux
relativement ouverts sur lesquels tout et n'importe quoi peut être installé
(surtout lorsqu'il y a des stagiaires au mois d'août).
80% des menaces viennent toujours de l'intérieur géographique à ce jour.
Et si filtrage il doit y avoir je le préfère sincèrement en terme de
machines pouvant être accédées depuis les nomades ce qui est plus simple
si firewall et tête de pont VPN sont fusionnés.

Dans le cas d'un lien
inter-site, c'est à peine différent. Comment est administré la réseau
distant ? Est-on sûr de la sécurité du réseau en question ? Bref, pas
mal de raisons qui poussent à filtrer les accès VPN.

Oui, intranet et réseau local sont des choses différentes. Voir mon §
précédent.

Exemple par le pratique : voir le nombre de boîtes qui ont ramassé
Blaster ou Sasser à travers un lien VPN...

Elles le rammasseront dès que le nomade se connectera en interne ou via la
DMZ, ça ne change rien.
Ou la politique associe périmètre interne de sécurité au périmètre
géographique ou elle l'associe au niveau fonctionnel ce qui fait rentrer
les nomades dedans qu'ils soient à l'intérieur de l'entreprise ou à
l'extérieur.
Les 2 ont des inconvénients et des avantages vis-à-vis des nomades.
La première est permissive face aux postes nomades qui se raccordent au
réseau local mais ne veut pas entendre parler du monde extérieur.
Donc s'il n'y a pas la batterie suffisante d'antivirus téléchargés et
exécutés dès le raccordement au réseau ... pas de chance : Sasser à rien.

La seconde a mis en place des moyens efficaces minimisant les risques
d'infection ou de détournement des postes (comptes utilisateurs,
pratiquement aucun droit sur la machine nomade, antivirus permanent se
mettant à jour dès la connexion au réseau d'entrperise, les gosses ne
peuvent pas jouer avec, chiffrement des partitions, etc) qu'ils soient
nomades ou fixes et, dans ce cas, ma foi, que le poste de travail soit au
sein de l'entreprise géographique ou pas, cela ne change pas grand chose.
J'aurais même tendance à être plus confortable (oh, un anglissisme), à
l'aise, avec les postes nomades.

[...]

D'ailleurs qui l'utilise ?

Moi, et plein de monde aussi.
Comme plein de monde a des virus aussi :-) Ce n'est pas une raison.

Mais au final, c'est pour faire joli ou c'est vraiment utile ?
Dans quel contexte ?

Tu as confiance dans le PIX tout de même, non ?

En ce qui me concerne, non. Un constructeur qui laisse traîner des mots
de passe non documentés dans certaines de ses appliances, j'ai du mal à
lui faire confiance...
Il sont TOUS comme ça (y'a eu un troll récemment sur le sujet). Linux a ses

tares, xBSD également il ne faut pas l'oublier mais elles sont rendues
publiques (enfin dès que quelqu'un s'en aperçoit) c'est un avantage.
J'ai bien plus tendance à utiliser les logiciels libres pour cette dernière
raison notamment (et pour le côté gratuit bien entendu).
Car prétendre faire de la sécurité avec des matériels et des logiciels
propriétaires dont on ne sait pas grand chose est, avouons-le, un léger
non-sens ! Mais le marché est le marché.
Mais là n'était pas la question. Le PIX est déjà là !

C'est plus sophistiqué et performant qu'un Iptables.

Surtout un PIX501. Même mon Linksys avec un firmware maison il en fait
autant (même un peu plus en VPN). Et puis les PIX, c'est pas comme les
routeurs, c'est du bon gros PC (cf. 535, 525, 515 par exemple) avec un
PIX OS Cisco dessus.
C'est l'IOS qui est performant : pratiquement 20 ans d'expérience dans les

réseaux. Bon BSD aussi tu me diras.
D'aucuns prétendront que l'IOS est lourd est plus adapté à ce qu'il est
sensé faire aujourd'hui. Soit.

[...]

Et pourquoi l'utiliser ? Je veux dire, le firewall Linux, c'est aussi un
passerelle IPSEC. Ça simplifierait l'archi :) Et pourquoi alors payer
cher un PIX501* alors qu'un Linux ferait exactement la même chose
avec de meilleures performances (en utilisant OpenS/WAN ou Racoon) ?
J'ai proposé l'inverse pour la raison suivante.

Le PIX est plus fin dans ses caractéristiques de gestion dynamique du
filtrage. Netfilter gratte progressivement mais n'est pas encore à ce
niveau.
Par ailleurs le 501, le gars semble déjà le posséder et peut donc
reconvertir le Linux en poste de travail alors qu'un PIX ça ne se
reconvertit en rien d'autre que PIX (support de pot de fleurs ?).

Maintenant il fait ce qu'il veut. S'il ne subit pas de pression qu'il
poursuive avec le Linux.

En effet, le Linux est bien plus évolutif (peut servir de serveur de
certificats), le 501 non.
Le Linux peut gérer des dizaines de nomades simultanés plus des quantités de
tunnels fixes haut-débit SIMULTANEMENT pour peu que la CPU soit rapide (> 2 Ghz), le 501 non.
Le 501 a des réglages de filtrage fin le Linux non (mais en a-t-on besoin
ici ?).
Le 501 coute relativement cher (au moins autant que la machine qui supporte
le Linux), c'est con de le mettre de côté mais il peut toujours être
réutilisé en tant que routeur d'agences.

En conclusion, dans l'ordre décroissant des priorités :
fusionner firewalling et tête de pont VPN ;
et, selon politique de sécurité adoptée :
tête de pont VPN au sein du LAN (préférable en terme de simplicité si
politique adéquate observée)
ou
tête de pont VPN au sein de la DMZ.

db

PS : ah, encore une chose. En ce qui concerne l'aspect proclamé CHIANT de la
sécurité des SI, je ne suis pas d'accord. Une bonne sécurité est avant tout
une sécurité simple et de bon sens. Son degré d'application et de respect
est inversement proportionnel à son degré de complexité.
En d'autres termes si c'est trop pénible à appliquer, un jour, une nuit,
l'administrateur (ou l'administateur délégué) oubliera un élément
(fondamental) et laissera la porte ouverte.
Alors oui, on peut très bien installer le SELinux, régler au minimum les
capacités (capabilities) du noyau Linux autorisant le minimum de permission
à chaque application mais une machine doit vivre également et s'il faut
systématiquement passer par tout un système de commandes avant de pouvoir
mettre à jour un site Web, changer une zone ou installer une nouvelle
application c'est tellement pénible que soit on n'installe rien ou on
débride un peu plus à chaque fois.

La sécurité maximale vaut toutefois le coup (je n'ai pas écrit le contraire)
mais dans des organisations conséquentes où le personnel est conséquent et
bien sensibilisé/formé. Ce qui est extrêmement rare en dehors des grands
comptes (et encore).
--
email : usenet blas net

Cedric Blancher

25/01/2005 à 18:12

Le Tue, 25 Jan 2005 16:16:09 +0000, Dominique Blas a écrit :

Un hostspot est par définition public. Là nous parlons d'une population
d'entreprise utilisant un moyen d'accès public comme c'est généralement le
cas qu'il s'agisse du RTC, du réseau local d'une autre entreprise ou d'un
hotspot. Cette population est privée.

La population oui, mais quel est ta maîtrise de son moyen d'accès à ton
VPN ? S'il peut accéder au VPN via un RTC, qu'est-ce qui va l'empêcher
de le faire via un hotspot, environnement nettement moins sûr, voire
carrément pas du tout.

Si le VPN est chiffré (l'inverse est un non-sens de nos jours) que
risque-t-il ?

De se faire rooter et que l'attaque passe _dans_ le VPN. Le VPN, c'est
chouette, ça sécurise la communication entre deux bouts. Mais qu'est-ce
qui t'assure la sécurité de l'un et l'autre des deux bouts ? En
particulier quand le lien VPN est monté, dans la mesure où on sait
contourner le filtrage mis en place par le client VPN quand il en met un ?

Dans ce cas là, tu ne t'attaque même pas au chiffrement. Même mieux, tu
vas t'en servir pour atteindre ton but.

Certes. Et encore ... Je suis plus enclin à autoriser l'accès à mes
serveurs depuis des postes que je sais verrouillés que depuis des
postes locaux relativement ouverts sur lesquels tout et n'importe quoi
peut être installé (surtout lorsqu'il y a des stagiaires au mois
d'août).

Tu veux donc dire que tes portables ne sont pas utilisés par des
commerciaux et autres VRP non informaticiens ? La tendance que j'ai pu
constater en audit, c'est que les portables confiés à ce genre de
population dérivent nettement plus vite que les postes fixes. D'une part
parce que tu ne peux pas maîtriser la mise à jour des ces postes
constamment en vadrouille, et d'autre part parce l'utilisateur se prend
souvent à installer des trucs (genre une carte WiFi).

80% des menaces viennent toujours de l'intérieur géographique à ce jour.

Cette étude du FBI a 5 ans, et elle ne tient pas compte du phénomène de
rebond. Si par exemple mon attaque vient d'un de tes postes nomades via le
VPN, elle sera comptée comme interne.

Et si filtrage il doit y avoir je le préfère sincèrement en terme
de machines pouvant être accédées depuis les nomades ce qui est plus
simple si firewall et tête de pont VPN sont fusionnés.

Fusionner tête de VPN et firewall n'empêche pas de mettre en place du
filtrage. Quand tu dis de mettre la tête de VPN dans le LAN parce que la
faire arriver en DMZ complique la configuration, perso, je comprends
tête de VPN sans filtrage.

Elles le rammasseront dès que le nomade se connectera en interne ou via
la DMZ, ça ne change rien.

Pour la connexion en interne oui. Pour la connexion en DMZ, pas d'accord.
tout dépend de ce que tu laisses passer et comment tu le laisses passer.

Ou la politique associe périmètre interne de sécurité au périmètre
géographique ou elle l'associe au niveau fonctionnel ce qui fait
rentrer les nomades dedans qu'ils soient à l'intérieur de l'entreprise
ou à l'extérieur.

Aucune de ces politique ne tient la route. Tu peux définir des niveaux de
sécurité intermédiaires entre le dehors et le dedans, tout en gardant
un réseau fonctionnel. Mais ça demande de mettre un peu le nez au-dessus
de la planche à dessin. J'ai déjà vu des SI avec un réseau pour les
laptops et un autre pour les postes fixes, avec chacun leur domaine et du
filtrage entre les deux empêchant l'un de polluer l'autre à tout va,
tout en conservant les fonctionnalités nécessaires à un travail
efficace, et ce, avec des moyens somme toute assez classiques.

Mais au final, c'est pour faire joli ou c'est vraiment utile ? Dans quel
contexte ?

Dans un contexte ou je veux que mes paquets IP ne soient pas altérés sur
le chemin. Ça m'assure que le paquet IP que je reçoit est celui qui a
été émis de l'autre côté. Pas d'option IP à la con en plus en
particulier.

Car prétendre faire de la sécurité avec des matériels et des
logiciels propriétaires dont on ne sait pas grand chose est,
avouons-le, un léger non-sens ! Mais le marché est le marché.

Le marché est le marché, certes, mais s'il ne répond pas à tes
besoins, tu n'es pas obligé de le suivre, juste parce qu'un commercial te
dit que c'est bien. Typiquement, fournir un PIX501 pour faire terminaison
VPN, c'est le genre de situation qui ne devrait pas se produire si on
réfléchissait à ses besoins plutôt qu'au marché.

Mais là n'était pas la question. Le PIX est déjà là !

Bon ben autant s'en servir alors. Mais dans ce cas là, j'avoue que je
m'en servirais plus comme firewall que comme terminaison VPN.

C'est l'IOS qui est performant
[...]

D'aucuns prétendront que l'IOS est lourd est plus adapté à ce qu'il
est sensé faire aujourd'hui.

Les PIX ne tournent pas sous IOS. D'ailleurs, un port i386 d'IOS a été
fait, Compaq vendait ce genre de trucs. Ben franchement, les 20 ans
d'expérience, ils ramaient sec...
Le truc qui fait que l'IOS va vite, c'est qu'il tourne sur des
plate-formes spécialisées et accélérées. Ce qui, pour autant que je
sache, n'est pas le cas des PIX, ni dans un sens, ni dans l'autre (OK, il
y a des cartes crypto pour les PIX).

pratiquement 20 ans d'expérience dans les réseaux.

C'est comme le Nutella, ça fait 20 ans qu'il a le même goût, mais c'est
de l'expérience. Cisco fait des switches, des routeurs et l'IOS qui va
avec de manière remarquable. Ils maîtrisent moins certains autre champs
d'application. Les PIX en ont fait partie. Même si on ne peut pas dire
que ce soient de mauvais produit, ce n'est clairement pas le cas, on peut
difficilement faire valoir l'expérience de Cisco dans les autres domaines
pour appuyer leur qualité. C'est un peu comme dire que les CSS sont des
bons produits parce que Cisco a de l'expérience...

J'ai proposé l'inverse pour la raison suivante. Le PIX est plus fin
dans ses caractéristiques de gestion dynamique du filtrage.

Ah ?

--
Objet: cherche personne pro pour...
qu'il me donne quelques conseil... une sorte de parrain...
-+- nekio in Guide du Fmblien Assassin : "El Padrino..." -+-

Le Tue, 25 Jan 2005 16:16:09 +0000, Dominique Blas a écrit :

Un hostspot est par définition public. Là nous parlons d'une population
d'entreprise utilisant un moyen d'accès public comme c'est généralement le
cas qu'il s'agisse du RTC, du réseau local d'une autre entreprise ou d'un
hotspot. Cette population est privée.

La population oui, mais quel est ta maîtrise de son moyen d'accès à ton
VPN ? S'il peut accéder au VPN via un RTC, qu'est-ce qui va l'empêcher
de le faire via un hotspot, environnement nettement moins sûr, voire
carrément pas du tout.

Si le VPN est chiffré (l'inverse est un non-sens de nos jours) que
risque-t-il ?

De se faire rooter et que l'attaque passe _dans_ le VPN. Le VPN, c'est
chouette, ça sécurise la communication entre deux bouts. Mais qu'est-ce
qui t'assure la sécurité de l'un et l'autre des deux bouts ? En
particulier quand le lien VPN est monté, dans la mesure où on sait
contourner le filtrage mis en place par le client VPN quand il en met un ?

Dans ce cas là, tu ne t'attaque même pas au chiffrement. Même mieux, tu
vas t'en servir pour atteindre ton but.

Certes. Et encore ... Je suis plus enclin à autoriser l'accès à mes
serveurs depuis des postes que je sais verrouillés que depuis des
postes locaux relativement ouverts sur lesquels tout et n'importe quoi
peut être installé (surtout lorsqu'il y a des stagiaires au mois
d'août).

Tu veux donc dire que tes portables ne sont pas utilisés par des
commerciaux et autres VRP non informaticiens ? La tendance que j'ai pu
constater en audit, c'est que les portables confiés à ce genre de
population dérivent nettement plus vite que les postes fixes. D'une part
parce que tu ne peux pas maîtriser la mise à jour des ces postes
constamment en vadrouille, et d'autre part parce l'utilisateur se prend
souvent à installer des trucs (genre une carte WiFi).

80% des menaces viennent toujours de l'intérieur géographique à ce jour.

Cette étude du FBI a 5 ans, et elle ne tient pas compte du phénomène de
rebond. Si par exemple mon attaque vient d'un de tes postes nomades via le
VPN, elle sera comptée comme interne.

Et si filtrage il doit y avoir je le préfère sincèrement en terme
de machines pouvant être accédées depuis les nomades ce qui est plus
simple si firewall et tête de pont VPN sont fusionnés.

Fusionner tête de VPN et firewall n'empêche pas de mettre en place du
filtrage. Quand tu dis de mettre la tête de VPN dans le LAN parce que la
faire arriver en DMZ complique la configuration, perso, je comprends
tête de VPN sans filtrage.

Elles le rammasseront dès que le nomade se connectera en interne ou via
la DMZ, ça ne change rien.

Pour la connexion en interne oui. Pour la connexion en DMZ, pas d'accord.
tout dépend de ce que tu laisses passer et comment tu le laisses passer.

Ou la politique associe périmètre interne de sécurité au périmètre
géographique ou elle l'associe au niveau fonctionnel ce qui fait
rentrer les nomades dedans qu'ils soient à l'intérieur de l'entreprise
ou à l'extérieur.

Aucune de ces politique ne tient la route. Tu peux définir des niveaux de
sécurité intermédiaires entre le dehors et le dedans, tout en gardant
un réseau fonctionnel. Mais ça demande de mettre un peu le nez au-dessus
de la planche à dessin. J'ai déjà vu des SI avec un réseau pour les
laptops et un autre pour les postes fixes, avec chacun leur domaine et du
filtrage entre les deux empêchant l'un de polluer l'autre à tout va,
tout en conservant les fonctionnalités nécessaires à un travail
efficace, et ce, avec des moyens somme toute assez classiques.

Mais au final, c'est pour faire joli ou c'est vraiment utile ? Dans quel
contexte ?

Dans un contexte ou je veux que mes paquets IP ne soient pas altérés sur
le chemin. Ça m'assure que le paquet IP que je reçoit est celui qui a
été émis de l'autre côté. Pas d'option IP à la con en plus en
particulier.

Car prétendre faire de la sécurité avec des matériels et des
logiciels propriétaires dont on ne sait pas grand chose est,
avouons-le, un léger non-sens ! Mais le marché est le marché.

Le marché est le marché, certes, mais s'il ne répond pas à tes
besoins, tu n'es pas obligé de le suivre, juste parce qu'un commercial te
dit que c'est bien. Typiquement, fournir un PIX501 pour faire terminaison
VPN, c'est le genre de situation qui ne devrait pas se produire si on
réfléchissait à ses besoins plutôt qu'au marché.

Mais là n'était pas la question. Le PIX est déjà là !

Bon ben autant s'en servir alors. Mais dans ce cas là, j'avoue que je
m'en servirais plus comme firewall que comme terminaison VPN.

C'est l'IOS qui est performant
[...]

D'aucuns prétendront que l'IOS est lourd est plus adapté à ce qu'il
est sensé faire aujourd'hui.

Les PIX ne tournent pas sous IOS. D'ailleurs, un port i386 d'IOS a été
fait, Compaq vendait ce genre de trucs. Ben franchement, les 20 ans
d'expérience, ils ramaient sec...
Le truc qui fait que l'IOS va vite, c'est qu'il tourne sur des
plate-formes spécialisées et accélérées. Ce qui, pour autant que je
sache, n'est pas le cas des PIX, ni dans un sens, ni dans l'autre (OK, il
y a des cartes crypto pour les PIX).

pratiquement 20 ans d'expérience dans les réseaux.

C'est comme le Nutella, ça fait 20 ans qu'il a le même goût, mais c'est
de l'expérience. Cisco fait des switches, des routeurs et l'IOS qui va
avec de manière remarquable. Ils maîtrisent moins certains autre champs
d'application. Les PIX en ont fait partie. Même si on ne peut pas dire
que ce soient de mauvais produit, ce n'est clairement pas le cas, on peut
difficilement faire valoir l'expérience de Cisco dans les autres domaines
pour appuyer leur qualité. C'est un peu comme dire que les CSS sont des
bons produits parce que Cisco a de l'expérience...

J'ai proposé l'inverse pour la raison suivante. Le PIX est plus fin
dans ses caractéristiques de gestion dynamique du filtrage.

Ah ?

--
Objet: cherche personne pro pour...
qu'il me donne quelques conseil... une sorte de parrain...
-+- nekio in Guide du Fmblien Assassin : "El Padrino..." -+-

Vous avez filtré cet utilisateur ! Consultez son message

Le Tue, 25 Jan 2005 16:16:09 +0000, Dominique Blas a écrit :

Un hostspot est par définition public. Là nous parlons d'une population
d'entreprise utilisant un moyen d'accès public comme c'est généralement le
cas qu'il s'agisse du RTC, du réseau local d'une autre entreprise ou d'un
hotspot. Cette population est privée.

La population oui, mais quel est ta maîtrise de son moyen d'accès à ton
VPN ? S'il peut accéder au VPN via un RTC, qu'est-ce qui va l'empêcher
de le faire via un hotspot, environnement nettement moins sûr, voire
carrément pas du tout.

Si le VPN est chiffré (l'inverse est un non-sens de nos jours) que
risque-t-il ?

De se faire rooter et que l'attaque passe _dans_ le VPN. Le VPN, c'est
chouette, ça sécurise la communication entre deux bouts. Mais qu'est-ce
qui t'assure la sécurité de l'un et l'autre des deux bouts ? En
particulier quand le lien VPN est monté, dans la mesure où on sait
contourner le filtrage mis en place par le client VPN quand il en met un ?

Dans ce cas là, tu ne t'attaque même pas au chiffrement. Même mieux, tu
vas t'en servir pour atteindre ton but.

Certes. Et encore ... Je suis plus enclin à autoriser l'accès à mes
serveurs depuis des postes que je sais verrouillés que depuis des
postes locaux relativement ouverts sur lesquels tout et n'importe quoi
peut être installé (surtout lorsqu'il y a des stagiaires au mois
d'août).

Tu veux donc dire que tes portables ne sont pas utilisés par des
commerciaux et autres VRP non informaticiens ? La tendance que j'ai pu
constater en audit, c'est que les portables confiés à ce genre de
population dérivent nettement plus vite que les postes fixes. D'une part
parce que tu ne peux pas maîtriser la mise à jour des ces postes
constamment en vadrouille, et d'autre part parce l'utilisateur se prend
souvent à installer des trucs (genre une carte WiFi).

80% des menaces viennent toujours de l'intérieur géographique à ce jour.

Cette étude du FBI a 5 ans, et elle ne tient pas compte du phénomène de
rebond. Si par exemple mon attaque vient d'un de tes postes nomades via le
VPN, elle sera comptée comme interne.

Et si filtrage il doit y avoir je le préfère sincèrement en terme
de machines pouvant être accédées depuis les nomades ce qui est plus
simple si firewall et tête de pont VPN sont fusionnés.

Fusionner tête de VPN et firewall n'empêche pas de mettre en place du
filtrage. Quand tu dis de mettre la tête de VPN dans le LAN parce que la
faire arriver en DMZ complique la configuration, perso, je comprends
tête de VPN sans filtrage.

Elles le rammasseront dès que le nomade se connectera en interne ou via
la DMZ, ça ne change rien.

Pour la connexion en interne oui. Pour la connexion en DMZ, pas d'accord.
tout dépend de ce que tu laisses passer et comment tu le laisses passer.

Ou la politique associe périmètre interne de sécurité au périmètre
géographique ou elle l'associe au niveau fonctionnel ce qui fait
rentrer les nomades dedans qu'ils soient à l'intérieur de l'entreprise
ou à l'extérieur.

Aucune de ces politique ne tient la route. Tu peux définir des niveaux de
sécurité intermédiaires entre le dehors et le dedans, tout en gardant
un réseau fonctionnel. Mais ça demande de mettre un peu le nez au-dessus
de la planche à dessin. J'ai déjà vu des SI avec un réseau pour les
laptops et un autre pour les postes fixes, avec chacun leur domaine et du
filtrage entre les deux empêchant l'un de polluer l'autre à tout va,
tout en conservant les fonctionnalités nécessaires à un travail
efficace, et ce, avec des moyens somme toute assez classiques.

Mais au final, c'est pour faire joli ou c'est vraiment utile ? Dans quel
contexte ?

Dans un contexte ou je veux que mes paquets IP ne soient pas altérés sur
le chemin. Ça m'assure que le paquet IP que je reçoit est celui qui a
été émis de l'autre côté. Pas d'option IP à la con en plus en
particulier.

Car prétendre faire de la sécurité avec des matériels et des
logiciels propriétaires dont on ne sait pas grand chose est,
avouons-le, un léger non-sens ! Mais le marché est le marché.

Le marché est le marché, certes, mais s'il ne répond pas à tes
besoins, tu n'es pas obligé de le suivre, juste parce qu'un commercial te
dit que c'est bien. Typiquement, fournir un PIX501 pour faire terminaison
VPN, c'est le genre de situation qui ne devrait pas se produire si on
réfléchissait à ses besoins plutôt qu'au marché.

Mais là n'était pas la question. Le PIX est déjà là !

Bon ben autant s'en servir alors. Mais dans ce cas là, j'avoue que je
m'en servirais plus comme firewall que comme terminaison VPN.

C'est l'IOS qui est performant
[...]

D'aucuns prétendront que l'IOS est lourd est plus adapté à ce qu'il
est sensé faire aujourd'hui.

Les PIX ne tournent pas sous IOS. D'ailleurs, un port i386 d'IOS a été
fait, Compaq vendait ce genre de trucs. Ben franchement, les 20 ans
d'expérience, ils ramaient sec...
Le truc qui fait que l'IOS va vite, c'est qu'il tourne sur des
plate-formes spécialisées et accélérées. Ce qui, pour autant que je
sache, n'est pas le cas des PIX, ni dans un sens, ni dans l'autre (OK, il
y a des cartes crypto pour les PIX).

pratiquement 20 ans d'expérience dans les réseaux.

C'est comme le Nutella, ça fait 20 ans qu'il a le même goût, mais c'est
de l'expérience. Cisco fait des switches, des routeurs et l'IOS qui va
avec de manière remarquable. Ils maîtrisent moins certains autre champs
d'application. Les PIX en ont fait partie. Même si on ne peut pas dire
que ce soient de mauvais produit, ce n'est clairement pas le cas, on peut
difficilement faire valoir l'expérience de Cisco dans les autres domaines
pour appuyer leur qualité. C'est un peu comme dire que les CSS sont des
bons produits parce que Cisco a de l'expérience...

J'ai proposé l'inverse pour la raison suivante. Le PIX est plus fin
dans ses caractéristiques de gestion dynamique du filtrage.

Ah ?

--
Objet: cherche personne pro pour...
qu'il me donne quelques conseil... une sorte de parrain...
-+- nekio in Guide du Fmblien Assassin : "El Padrino..." -+-

Dominique Blas

27/01/2005 à 03:42

Cedric Blancher wrote:

La population oui, mais quel est ta maîtrise de son moyen d'accès à ton
VPN ? S'il peut accéder au VPN via un RTC, qu'est-ce qui va l'empêcher
de le faire via un hotspot, environnement nettement moins sûr, voire
carrément pas du tout.

Je n'ai pas de souci vis-à-vis de la sécurité offerte à un usager du
Hotspot disposant d'une machine bien configurée. Je me fais plus de soucis
au sujet de la sécurité intrinsèque du fournisseur vis-à-vis de tout ce qui
traîne sur un hotspot. Mais ce n'est pas mon pb.
Le seul truc qui me dérange, dans un hotspot, est la qualité de service que
je peux annoncer à mon usager professionnel.
En effet, il a, selon moi, très peu risque de se faire pirater (s'il
respecte les consignes et si le poste est correctement configuré) mais il
a, en revanche, beaucoup de risques d'être désassocié, d'avoir une bande
passante réduite à une peau de chagrin (a fortiori s'il est souvent
désassocié).
Je dis peu de risque et non aucun risque car je ne suis jamais à l'abri
d'une faille dans une négociation sécurisée quelconque (SSH ou IPSEC).
Et le risque zéro sur le rézo hein ?

Si le VPN est chiffré (l'inverse est un non-sens de nos jours) que
risque-t-il ?

De se faire rooter et que l'attaque passe _dans_ le VPN. Le VPN, c'est
chouette, ça sécurise la communication entre deux bouts. Mais qu'est-ce
qui t'assure la sécurité de l'un et l'autre des deux bouts ? En
particulier quand le lien VPN est monté, dans la mesure où on sait
contourner le filtrage mis en place par le client VPN quand il en met un ?

Dans ce cas arrêtons tout et stoppons les VPN et fermons la boutique.
Le rootage viendra plus sûrement de l'intérieur à mon sens, au prorata.

Si tu veux, je privilégie une méthode risque / coûts (dans mon boulot) au
sein d'une approche progressive (dans les ng) de la sécurité :-).
C'est à dire que je me place entre la vision minimaliste AOSI (*) et les
considérations intégristes (**) de certains.
J'écris progressive car j'espère qu'à force de répéter et râbacher et de
participer à l'effort de guerre comme toi-même ainsi que tous ceux
qui pratiquent la sécurité au quotidien, ceux qui peinent à se connecter à
Internet et sont envahis de saloperies se rapprocheront progressivement
de ceux qui manipulent les règles Snort ou ipf digites in naso.
Pour la méthode risque / coûts voir plus bas.

Donc pourquoi ne pas placer une tête de pont sur la DMZ ?
Dans l'absolu on s'en tape. En effet, on ne sait rien de l'environnement du
gars qui a posé la question. Est-il seul dans l'administration ou
dispose-t-il d'un service informatique digne de ce nom ? On ne sait pas.
Toujours est-il que s'il s'agit d'une boîte de quelques centaines de
salariés elle dispose à coup sûr des compétences locales (quitte à les
former) pour administrer des situations relativement complexes. Et pour ces
entreprises la question ne se pose même pas : ou on fusionne les services
ou c'est la solution que je préconise plus bas.
Maintenant parlons du cas où il n'y a pas de compétence locale. Dans ce cas
on va essayer de faire simple de manière à être en mesure de faire évoluer
le truc sans trop de casse. Et ma foi, tant pis pour les considérations de
sécurité avancées.
Il ne faut jamais oublier que tout niveau de sécurité supplémentaire se
traduit automatiquement par des coûts supplémentaires et récurrents
qu'il est important d'intégrer dans l'équation, les exploitants étant
rarement les consultants/intégrateurs (pour lesquels plus c'est complexe
mieux c'est, of course).

Dans ce cadre là (absence de compétences), je considère que placer le 501
dans la DMZ n'offre
pas une augmentation phénoménale du niveau de sécurité (***) alors
qu'elle complique de manière plus conséquente l'administration.
Le niveau requis est bien entendu plus important si aucune précaution n'a
été prise vis-à-vis des nomades
que si des précautions ont été mises en oeuvre (lesquelles ?). Et dans le
premier cas ça vaut le coup (de placer le 501 dans la DMZ).

Alors, au final, dans la mesure où, effectivement, on ne sait rien des
nomades allons
jusqu'au bout de la démarche ! Quitte à placer la tête de pont VPN sur la
DMZ plaçons-la sur sa PROPRE DMZ ! Le surcoût par rapport à la solution
précédente est négligeable (une carte Ethernet en plus) tout en augmentant,
à mon avis, bien mieux le niveau de sécurité et simplifiant le jeu de
règles à adopter (les règles se concentrent sur le firewall, plus besoin de
jouer avec le filtrage sur le 501). Cela donne 4 pattes au firewall.
Ce qui exclut d'emblée le PIX dans ce rôle.

[...]

Tu veux donc dire que tes portables ne sont pas utilisés par des
commerciaux et autres VRP non informaticiens ? La tendance que j'ai pu
constater en audit, c'est que les portables confiés à ce genre de
population dérivent nettement plus vite que les postes fixes. D'une part
parce que tu ne peux pas maîtriser la mise à jour des ces postes
constamment en vadrouille, et d'autre part parce l'utilisateur se prend
souvent à installer des trucs (genre une carte WiFi).

Le conseil que je donne et que j'impose parfois (pour faire reepecter la
politique définie de concert) car là ma responsabilité est engagée) est le
suivant :
poste fourni par l'entreprise = poste verrouillé et chiffré. Interdiction
d'y installer quoi que ce soit. Et si je pouvais y mettre du zBasic je le
ferais (y compris sur les postes fixes d'ailleurs).

Poste non fourni par l'entreprise : pas de connexion que ce soit à distance
ou en local (contrôle MAC au niveau des switches [COP]).
Maintenant il y en a qui suivent et d'autres non. Je suis missionné pour
sécuriser pas pour écouter les pleurs des uns et les malheurs des autres.
De toute manière on sent
bien dès la revue de contrat ce qui sera applicable et ce qui ne le sera
pas dans l'entreprise que l'on a en face de soi.
Lorsqu'on prête une voiture d'entreprise à un employé on ne s'attend pas à
ce qu'il joue aux auto-tamponeuses avec mais on tolère malgré tout qu'il
parte en vacances avec.

80% des menaces viennent toujours de l'intérieur géographique à ce jour.

Cette étude du FBI a 5 ans, et elle ne tient pas compte du phénomène de
rebond. Si par exemple mon attaque vient d'un de tes postes nomades via le
VPN, elle sera comptée comme interne.

C'est pour cela que j'ai parlé de géographie (ou personnel sédentaire) et
l'étude à laquelle je me réfère date de 1997 (le CLUSIF) régulièrement mise
à jour (2002 je crois).
M'enfin si c'est 70% ça ne change pas grand chose. De l'intérieur la
fourchette des vulnérabilités est bien plus étendue. Il faudrait comparer
à périmètre équivalent et là ... pas de chiffres actualisés.

Fusionner tête de VPN et firewall n'empêche pas de mettre en place du
filtrage. Quand tu dis de mettre la tête de VPN dans le LAN parce que la
faire arriver en DMZ complique la configuration, perso, je comprends
tête de VPN sans filtrage.

Euh non, j'ai été un peu rapide sur le coup là, c'est vrai mais non, dans
les 2 cas le 501 est équipé de règles de filtrage. C'est pour cela, du
reste, que la configuration globale est plus compliquée dans le cas où le
501 est placé sur la DMZ que lorsqu'il est placé sur le LAN.
D'où l'intérêt de placer le 501 sur sa propre DMZ, ça simplifie pas mal de
choses.

Elles le rammasseront dès que le nomade se connectera en interne ou via
la DMZ, ça ne change rien.

Pour la connexion en interne oui. Pour la connexion en DMZ, pas d'accord.
tout dépend de ce que tu laisses passer et comment tu le laisses passer.

Admettons que le poste de travail typique possède une application
client-serveur (disons de suivi de clientèle) dialoguant avec le SQL server
de l'entreprise.
Le nomade possède donc cette application. Je puis donc attaquer le serveur
SQL que ma tête de pont soit sur une DMZ ou sur le réseau local.
L'avantage de la DMZ dédiée est de pouvoir placer une autre machine entre la
DMZ et le firewall (détection/prévention d'intrusion) mais là encore au
prix d'une certaine complexité.

[...]

Aucune de ces politique ne tient la route. Tu peux définir des niveaux de
sécurité intermédiaires entre le dehors et le dedans, tout en gardant
un réseau fonctionnel. Mais ça demande de mettre un peu le nez au-dessus
de la planche à dessin. J'ai déjà vu des SI avec un réseau pour les
laptops et un autre pour les postes fixes, avec chacun leur domaine et du
filtrage entre les deux empêchant l'un de polluer l'autre à tout va,
tout en conservant les fonctionnalités nécessaires à un travail
efficace, et ce, avec des moyens somme toute assez classiques.

Oui, je ne prétends pas le contraire. La technologie permet de faire pas mal
de choses : VLAN, MPLS, double-attachement (on en a parlé récemment) et
même des Qos différentes dont la discipline est pilotée par un détecteur
d'intrusions.
Mais la question est toujours la même : quel est le bénéfice marginal ?
Combien ça coûte vs l'exploitation ? On peut définir des politiques
ultra-complexes ... tant qu'il y a du monde pour les respecter et les
appliquer.

Comme je l'ai annoncé plus haut j'utilise une pseudo-méthode qu'on pourrait
également appelé risque asymptotique / coût marginal. C'est parfois
subjectif je ne le cache pas (comment chiffrer un risque ?), vachement
tiré de l'expérience et du reste ce n'est pas applicable partout.
Exemple : dans le domaine militaire ou chez les grands comptes où les
problématiques sont tout autres (c'est un autre monde).
Mais je ne pense pas que l'un comme l'autre viennent poser des questions
ici. Ils leur suffit d'interpeler un consultant traînant dans les couloirs.

Je ne suis pas contre sécuriser au maximum (**) mais je suis d'un naturel
paresseux et surtout comment prouver au client que c'est mieux ? (****) Par
un audit ?
S'il n'a déjà pas le fric pour s'acheter un PIX plus performant je doute
qu'il finance un audit.

Mais au final, c'est pour faire joli ou c'est vraiment utile ? Dans quel
contexte ?

Dans un contexte ou je veux que mes paquets IP ne soient pas altérés sur
le chemin. Ça m'assure que le paquet IP que je reçoit est celui qui a
été émis de l'autre côté. Pas d'option IP à la con en plus en
particulier.

Ca d'accord mais je demandais dans quel contexte est-on suffisamment
paranoïaque pour se dire qu'on risque une attaque du milieu (au sens propre
et figuré) dans un tunnel confidentiel et déjà authentifié ?

[...]

Bon ben autant s'en servir alors. Mais dans ce cas là, j'avoue que je
m'en servirais plus comme firewall que comme terminaison VPN.

Certes mais il y a déjà un firewall.
Finalement le moins cher et le plus élégant reste encore la fusion tête de
pont et firewall la première solution.
De toute manière si le gars a besoin de 20 tunnels le choix sera vite fait !

C'est l'IOS qui est performant
[...]

D'aucuns prétendront que l'IOS est lourd est plus adapté à ce qu'il
est sensé faire aujourd'hui.

Les PIX ne tournent pas sous IOS.

Ah oui mince, bordel, désolé !
Entre nous cela fait 7 ans que je n'ai pas touché un PIX et depuis je n'ai
touché que des Cisco classiques et je fusionne allègrement PIX et Cisco
IOS-Firewall Feature Set. Qui plus est gros Cisco. Alors pour moi, 501 ou
525 même combat.
Après avoir regarder sse caractéristiques, effectivement le 501 c'est le
basbas de gamme. Punaise. Navré j'aurais dû consulter ma boule avant.
Mais le jeu de commandes actuel du PIX ressemble pourtant furieusement au
jeu de commandes IOS !

D'ailleurs, un port i386 d'IOS a été
fait, Compaq vendait ce genre de trucs. Ben franchement, les 20 ans

d'expérience, ils ramaient sec...

Un peu normal. Historiquement l'IOS a été développé sur Motorola comme
pratiquement TOUS les systèmes électroniques et automatiques des années 80
et 90. Et un développeur Motorola a beaucoup de mal avec l'architecture
i386. L'inverse doit être vrai également.

C'est un peu comme dire que les CSS sont des
bons produits parce que Cisco a de l'expérience...

Confusion. Sorry.

J'ai proposé l'inverse pour la raison suivante. Le PIX est plus fin
dans ses caractéristiques de gestion dynamique du filtrage.

Ah ?

Oui de mémoire (année 2000) l'ISO-Firewall disposait de commandes permettant
une réaction dynamique du filtrage : ip audit.

db

(*) A Oualpe Sur Internet : ça fonctionne, je ne touche plus à rien et je
ferme le yeux en priant.

(**) Laquelle consiste à livrer à chacun des mots de passe de 20 caractères
générés aléatoirement, renouvelés chaque semaine (et à usage unique pour le
srvice informatique), filtrer tout ce qui est filtrable 3 fois, via les
filtres réseaux, via des services mandataires et via les capacités
(capabilities)
du système auquel s'ajoute un premier anneau de 3 pitbulls (à 120° l'un de
l'autre) secondé par un second anneau de 3 dobermans (en alternance avec les
pitbulls ; les Dobermann sont à l'extérieur pour contenir les pitbulls) et,
on n'est jamais trop prudent, on rajoute un pack de C4 à l'intérieur de la
machine des fois que. Le pack de C4 est commandé électriquement et en
sans-fil, doublé par le GSM et le satellite. Et pour ête tout à fait sûr on
y ajoute un gardien.
Tout ça pour pouvoir affirmer : << voyez, ma machine n'a jamais été piratée
et ne le sera jamais >>.
Certes mais inutile de préciser que personne n'a jamais utilisé ni
installé d'applications sur cette machine car inacessible, trop
verrouilée et qui plus est, terrifiante.
Après une période plus ou moins longue où les mots de passe ont traîné
joyeusement sur les écrans ou sous les claviers et quelques collaborateurs
zélés en ont maquillé le menu à la cantine, les utilisateurs en sont revenus
à la bonne vieille méthode du P2P (le workgroup) et l'accès Internet passe
désormais par la liaison sans-fil qu'un collaborateur (toujours zélé) a
établi avec un résident (avec son accord) de l'immeuble d'en face.

(***) Du reste il nous manque des valeurs pour quantifier ce genre de <<
niveau >>. Chacun et chaque méthode disposant de ses propres critères ça
n'aide pas à être objectif dans les démarches.
Mais bon c'est peut-être pour ça également qu'on le fait, ce boulot. Ca
procure un certain sentiment de liberté.

(****) Il y a quelques années j'ai participé à un appel d'offres d'un grand
compte sur le sujet de l'hébergement d'un service Web y compris la
sécurisation depuis l'extérieur. A l'époque on ne parlait pas encore de
détecteur d'intrusion, uniquement de firewall.
Pas de réseau LAN interne à l'entreprise à protéger, uniquement le serveur
Web.
Celui qui a emporté le marché proposait 3 niveaux de firewall. Le grand
compte était content : il avait l'impression d'être sacrément bien protégé
et il lui semblait ainsi qu'il avait le temps de réagir si jamais le
premier firewall était piraté. Le soumissionnaire était lui aussi très
content eût égard à la dimension de la prestation. L'intégrateur aussi
était content : 3 FW-1 à fournir.
Tout ce beau monde était donc satisfait. Magnifique non ?

Ainsi, pourquoi multiplier par un facteur minimum de 3 l'investissement pour
gagner pas grand chose au final techniquement parlant (p'têt un facteur
1,5) ?
Mais dans ce cas précis le gain (bien supérieur à 3 à mon avis) était
psychologique (et donc irrationnel) côté client. Mais il s'agissait d'un
grand compte.

Autre contexte, pas un grand compte et plus récemment : un réseau
d'entreprise classique avec des nomades et plusieurs sites le tout raccordé
via des VPN IPSEC.
Rien à signaler de particulier, les employés ne peuvent pas accéder en
direct à Internet et doivent passer par 2 passerelles de courriers avant de
voir leur courriels sortir ou rentrer. Même chose pour la navigation avec
présence d'un proxy. Le serveur est un AS/400.
De temps en temps on trouve un virus sur un poste interne (ben oui jamais
sur les postes nomades, les consignes sont bien passées apparemment) qui ne
s'est pas raccordé au réseau depuis plusieurs semaines mais c'est tout le
bout et il est éradiqué dans les minutes qui suivent son raccordement.
Enfin, quand il arrive à récupérer une version à jour de signatures.
Bref. Jusqu'au jour où, ayant mis en place quelques règles de filtrages
destinées au pistage (une fois l'an un p'tit audit) je découvre 2 postes
qui communiquaient avec un serveur HTTPS à intervalle irrégulier. Intervalle
compris entre 1/2 heure et 1 heure et parfois, aux heures ouvrées,
plusieurs fois par minute avec, cette fois, un volume conséquent en
sortie ! Qui plus est, une fois interdit, il tentait (l'un mais pas
l'autre) de joindre une autre adresse (qui ne répondait pas) et
systématiquement, lorqu'on le bloquait il se mettait en quelque sorte en
veille (une tentative de contact toutes les heures environ).

L'enquête a été diligentée pour trouver qu'il s'agissait d'une DLL installée
suite à réception d'un courriel par les collègues d'un ancien stagiaire
(qui leur avait expédié ce courriel à l'issue de son stage). Et comme il
s'agisait d'une création ex-nihilo aucun antivirus ne l'avait détecté.
On a supposé que ce client créait un canal caché de commande/action comme
avec IRC.
Impossible de limiter les volumes sortants de HTTPS sur le proxy, certains
expédient légitimement des fichiers ainsi.

Tout cela pour dire quoi ? Pour dire que, dans ce cas, le coût marginal pour
atteindre le niveau de sécurité supérieur nous permettant d'éviter ce genre
de choses au préalable n'était pas supportable.

--
email : usenet blas net

Cedric Blancher wrote:

La population oui, mais quel est ta maîtrise de son moyen d'accès à ton
VPN ? S'il peut accéder au VPN via un RTC, qu'est-ce qui va l'empêcher
de le faire via un hotspot, environnement nettement moins sûr, voire
carrément pas du tout.

Je n'ai pas de souci vis-à-vis de la sécurité offerte à un usager du
Hotspot disposant d'une machine bien configurée. Je me fais plus de soucis
au sujet de la sécurité intrinsèque du fournisseur vis-à-vis de tout ce qui
traîne sur un hotspot. Mais ce n'est pas mon pb.
Le seul truc qui me dérange, dans un hotspot, est la qualité de service que
je peux annoncer à mon usager professionnel.
En effet, il a, selon moi, très peu risque de se faire pirater (s'il
respecte les consignes et si le poste est correctement configuré) mais il
a, en revanche, beaucoup de risques d'être désassocié, d'avoir une bande
passante réduite à une peau de chagrin (a fortiori s'il est souvent
désassocié).
Je dis peu de risque et non aucun risque car je ne suis jamais à l'abri
d'une faille dans une négociation sécurisée quelconque (SSH ou IPSEC).
Et le risque zéro sur le rézo hein ?

Si le VPN est chiffré (l'inverse est un non-sens de nos jours) que
risque-t-il ?

De se faire rooter et que l'attaque passe _dans_ le VPN. Le VPN, c'est
chouette, ça sécurise la communication entre deux bouts. Mais qu'est-ce
qui t'assure la sécurité de l'un et l'autre des deux bouts ? En
particulier quand le lien VPN est monté, dans la mesure où on sait
contourner le filtrage mis en place par le client VPN quand il en met un ?

Dans ce cas arrêtons tout et stoppons les VPN et fermons la boutique.
Le rootage viendra plus sûrement de l'intérieur à mon sens, au prorata.

Si tu veux, je privilégie une méthode risque / coûts (dans mon boulot) au
sein d'une approche progressive (dans les ng) de la sécurité :-).
C'est à dire que je me place entre la vision minimaliste AOSI (*) et les
considérations intégristes (**) de certains.
J'écris progressive car j'espère qu'à force de répéter et râbacher et de
participer à l'effort de guerre comme toi-même ainsi que tous ceux
qui pratiquent la sécurité au quotidien, ceux qui peinent à se connecter à
Internet et sont envahis de saloperies se rapprocheront progressivement
de ceux qui manipulent les règles Snort ou ipf digites in naso.
Pour la méthode risque / coûts voir plus bas.

Donc pourquoi ne pas placer une tête de pont sur la DMZ ?
Dans l'absolu on s'en tape. En effet, on ne sait rien de l'environnement du
gars qui a posé la question. Est-il seul dans l'administration ou
dispose-t-il d'un service informatique digne de ce nom ? On ne sait pas.
Toujours est-il que s'il s'agit d'une boîte de quelques centaines de
salariés elle dispose à coup sûr des compétences locales (quitte à les
former) pour administrer des situations relativement complexes. Et pour ces
entreprises la question ne se pose même pas : ou on fusionne les services
ou c'est la solution que je préconise plus bas.
Maintenant parlons du cas où il n'y a pas de compétence locale. Dans ce cas
on va essayer de faire simple de manière à être en mesure de faire évoluer
le truc sans trop de casse. Et ma foi, tant pis pour les considérations de
sécurité avancées.
Il ne faut jamais oublier que tout niveau de sécurité supplémentaire se
traduit automatiquement par des coûts supplémentaires et récurrents
qu'il est important d'intégrer dans l'équation, les exploitants étant
rarement les consultants/intégrateurs (pour lesquels plus c'est complexe
mieux c'est, of course).

Dans ce cadre là (absence de compétences), je considère que placer le 501
dans la DMZ n'offre
pas une augmentation phénoménale du niveau de sécurité (***) alors
qu'elle complique de manière plus conséquente l'administration.
Le niveau requis est bien entendu plus important si aucune précaution n'a
été prise vis-à-vis des nomades
que si des précautions ont été mises en oeuvre (lesquelles ?). Et dans le
premier cas ça vaut le coup (de placer le 501 dans la DMZ).

Alors, au final, dans la mesure où, effectivement, on ne sait rien des
nomades allons
jusqu'au bout de la démarche ! Quitte à placer la tête de pont VPN sur la
DMZ plaçons-la sur sa PROPRE DMZ ! Le surcoût par rapport à la solution
précédente est négligeable (une carte Ethernet en plus) tout en augmentant,
à mon avis, bien mieux le niveau de sécurité et simplifiant le jeu de
règles à adopter (les règles se concentrent sur le firewall, plus besoin de
jouer avec le filtrage sur le 501). Cela donne 4 pattes au firewall.
Ce qui exclut d'emblée le PIX dans ce rôle.

[...]

Tu veux donc dire que tes portables ne sont pas utilisés par des
commerciaux et autres VRP non informaticiens ? La tendance que j'ai pu
constater en audit, c'est que les portables confiés à ce genre de
population dérivent nettement plus vite que les postes fixes. D'une part
parce que tu ne peux pas maîtriser la mise à jour des ces postes
constamment en vadrouille, et d'autre part parce l'utilisateur se prend
souvent à installer des trucs (genre une carte WiFi).

Le conseil que je donne et que j'impose parfois (pour faire reepecter la
politique définie de concert) car là ma responsabilité est engagée) est le
suivant :
poste fourni par l'entreprise = poste verrouillé et chiffré. Interdiction
d'y installer quoi que ce soit. Et si je pouvais y mettre du zBasic je le
ferais (y compris sur les postes fixes d'ailleurs).

Poste non fourni par l'entreprise : pas de connexion que ce soit à distance
ou en local (contrôle MAC au niveau des switches [COP]).
Maintenant il y en a qui suivent et d'autres non. Je suis missionné pour
sécuriser pas pour écouter les pleurs des uns et les malheurs des autres.
De toute manière on sent
bien dès la revue de contrat ce qui sera applicable et ce qui ne le sera
pas dans l'entreprise que l'on a en face de soi.
Lorsqu'on prête une voiture d'entreprise à un employé on ne s'attend pas à
ce qu'il joue aux auto-tamponeuses avec mais on tolère malgré tout qu'il
parte en vacances avec.

80% des menaces viennent toujours de l'intérieur géographique à ce jour.

Cette étude du FBI a 5 ans, et elle ne tient pas compte du phénomène de
rebond. Si par exemple mon attaque vient d'un de tes postes nomades via le
VPN, elle sera comptée comme interne.

C'est pour cela que j'ai parlé de géographie (ou personnel sédentaire) et
l'étude à laquelle je me réfère date de 1997 (le CLUSIF) régulièrement mise
à jour (2002 je crois).
M'enfin si c'est 70% ça ne change pas grand chose. De l'intérieur la
fourchette des vulnérabilités est bien plus étendue. Il faudrait comparer
à périmètre équivalent et là ... pas de chiffres actualisés.

Fusionner tête de VPN et firewall n'empêche pas de mettre en place du
filtrage. Quand tu dis de mettre la tête de VPN dans le LAN parce que la
faire arriver en DMZ complique la configuration, perso, je comprends
tête de VPN sans filtrage.

Euh non, j'ai été un peu rapide sur le coup là, c'est vrai mais non, dans
les 2 cas le 501 est équipé de règles de filtrage. C'est pour cela, du
reste, que la configuration globale est plus compliquée dans le cas où le
501 est placé sur la DMZ que lorsqu'il est placé sur le LAN.
D'où l'intérêt de placer le 501 sur sa propre DMZ, ça simplifie pas mal de
choses.

Elles le rammasseront dès que le nomade se connectera en interne ou via
la DMZ, ça ne change rien.

Pour la connexion en interne oui. Pour la connexion en DMZ, pas d'accord.
tout dépend de ce que tu laisses passer et comment tu le laisses passer.

Admettons que le poste de travail typique possède une application
client-serveur (disons de suivi de clientèle) dialoguant avec le SQL server
de l'entreprise.
Le nomade possède donc cette application. Je puis donc attaquer le serveur
SQL que ma tête de pont soit sur une DMZ ou sur le réseau local.
L'avantage de la DMZ dédiée est de pouvoir placer une autre machine entre la
DMZ et le firewall (détection/prévention d'intrusion) mais là encore au
prix d'une certaine complexité.

[...]

Aucune de ces politique ne tient la route. Tu peux définir des niveaux de
sécurité intermédiaires entre le dehors et le dedans, tout en gardant
un réseau fonctionnel. Mais ça demande de mettre un peu le nez au-dessus
de la planche à dessin. J'ai déjà vu des SI avec un réseau pour les
laptops et un autre pour les postes fixes, avec chacun leur domaine et du
filtrage entre les deux empêchant l'un de polluer l'autre à tout va,
tout en conservant les fonctionnalités nécessaires à un travail
efficace, et ce, avec des moyens somme toute assez classiques.

Oui, je ne prétends pas le contraire. La technologie permet de faire pas mal
de choses : VLAN, MPLS, double-attachement (on en a parlé récemment) et
même des Qos différentes dont la discipline est pilotée par un détecteur
d'intrusions.
Mais la question est toujours la même : quel est le bénéfice marginal ?
Combien ça coûte vs l'exploitation ? On peut définir des politiques
ultra-complexes ... tant qu'il y a du monde pour les respecter et les
appliquer.

Comme je l'ai annoncé plus haut j'utilise une pseudo-méthode qu'on pourrait
également appelé risque asymptotique / coût marginal. C'est parfois
subjectif je ne le cache pas (comment chiffrer un risque ?), vachement
tiré de l'expérience et du reste ce n'est pas applicable partout.
Exemple : dans le domaine militaire ou chez les grands comptes où les
problématiques sont tout autres (c'est un autre monde).
Mais je ne pense pas que l'un comme l'autre viennent poser des questions
ici. Ils leur suffit d'interpeler un consultant traînant dans les couloirs.

Je ne suis pas contre sécuriser au maximum (**) mais je suis d'un naturel
paresseux et surtout comment prouver au client que c'est mieux ? (****) Par
un audit ?
S'il n'a déjà pas le fric pour s'acheter un PIX plus performant je doute
qu'il finance un audit.

Mais au final, c'est pour faire joli ou c'est vraiment utile ? Dans quel
contexte ?

Dans un contexte ou je veux que mes paquets IP ne soient pas altérés sur
le chemin. Ça m'assure que le paquet IP que je reçoit est celui qui a
été émis de l'autre côté. Pas d'option IP à la con en plus en
particulier.

Ca d'accord mais je demandais dans quel contexte est-on suffisamment
paranoïaque pour se dire qu'on risque une attaque du milieu (au sens propre
et figuré) dans un tunnel confidentiel et déjà authentifié ?

[...]

Bon ben autant s'en servir alors. Mais dans ce cas là, j'avoue que je
m'en servirais plus comme firewall que comme terminaison VPN.

Certes mais il y a déjà un firewall.
Finalement le moins cher et le plus élégant reste encore la fusion tête de
pont et firewall la première solution.
De toute manière si le gars a besoin de 20 tunnels le choix sera vite fait !

C'est l'IOS qui est performant
[...]

D'aucuns prétendront que l'IOS est lourd est plus adapté à ce qu'il
est sensé faire aujourd'hui.

Les PIX ne tournent pas sous IOS.

Ah oui mince, bordel, désolé !
Entre nous cela fait 7 ans que je n'ai pas touché un PIX et depuis je n'ai
touché que des Cisco classiques et je fusionne allègrement PIX et Cisco
IOS-Firewall Feature Set. Qui plus est gros Cisco. Alors pour moi, 501 ou
525 même combat.
Après avoir regarder sse caractéristiques, effectivement le 501 c'est le
basbas de gamme. Punaise. Navré j'aurais dû consulter ma boule avant.
Mais le jeu de commandes actuel du PIX ressemble pourtant furieusement au
jeu de commandes IOS !

D'ailleurs, un port i386 d'IOS a été
fait, Compaq vendait ce genre de trucs. Ben franchement, les 20 ans

d'expérience, ils ramaient sec...

Un peu normal. Historiquement l'IOS a été développé sur Motorola comme
pratiquement TOUS les systèmes électroniques et automatiques des années 80
et 90. Et un développeur Motorola a beaucoup de mal avec l'architecture
i386. L'inverse doit être vrai également.

C'est un peu comme dire que les CSS sont des
bons produits parce que Cisco a de l'expérience...

Confusion. Sorry.

J'ai proposé l'inverse pour la raison suivante. Le PIX est plus fin
dans ses caractéristiques de gestion dynamique du filtrage.

Ah ?

Oui de mémoire (année 2000) l'ISO-Firewall disposait de commandes permettant
une réaction dynamique du filtrage : ip audit.

db

(*) A Oualpe Sur Internet : ça fonctionne, je ne touche plus à rien et je
ferme le yeux en priant.

(**) Laquelle consiste à livrer à chacun des mots de passe de 20 caractères
générés aléatoirement, renouvelés chaque semaine (et à usage unique pour le
srvice informatique), filtrer tout ce qui est filtrable 3 fois, via les
filtres réseaux, via des services mandataires et via les capacités
(capabilities)
du système auquel s'ajoute un premier anneau de 3 pitbulls (à 120° l'un de
l'autre) secondé par un second anneau de 3 dobermans (en alternance avec les
pitbulls ; les Dobermann sont à l'extérieur pour contenir les pitbulls) et,
on n'est jamais trop prudent, on rajoute un pack de C4 à l'intérieur de la
machine des fois que. Le pack de C4 est commandé électriquement et en
sans-fil, doublé par le GSM et le satellite. Et pour ête tout à fait sûr on
y ajoute un gardien.
Tout ça pour pouvoir affirmer : << voyez, ma machine n'a jamais été piratée
et ne le sera jamais >>.
Certes mais inutile de préciser que personne n'a jamais utilisé ni
installé d'applications sur cette machine car inacessible, trop
verrouilée et qui plus est, terrifiante.
Après une période plus ou moins longue où les mots de passe ont traîné
joyeusement sur les écrans ou sous les claviers et quelques collaborateurs
zélés en ont maquillé le menu à la cantine, les utilisateurs en sont revenus
à la bonne vieille méthode du P2P (le workgroup) et l'accès Internet passe
désormais par la liaison sans-fil qu'un collaborateur (toujours zélé) a
établi avec un résident (avec son accord) de l'immeuble d'en face.

(***) Du reste il nous manque des valeurs pour quantifier ce genre de <<
niveau >>. Chacun et chaque méthode disposant de ses propres critères ça
n'aide pas à être objectif dans les démarches.
Mais bon c'est peut-être pour ça également qu'on le fait, ce boulot. Ca
procure un certain sentiment de liberté.

(****) Il y a quelques années j'ai participé à un appel d'offres d'un grand
compte sur le sujet de l'hébergement d'un service Web y compris la
sécurisation depuis l'extérieur. A l'époque on ne parlait pas encore de
détecteur d'intrusion, uniquement de firewall.
Pas de réseau LAN interne à l'entreprise à protéger, uniquement le serveur
Web.
Celui qui a emporté le marché proposait 3 niveaux de firewall. Le grand
compte était content : il avait l'impression d'être sacrément bien protégé
et il lui semblait ainsi qu'il avait le temps de réagir si jamais le
premier firewall était piraté. Le soumissionnaire était lui aussi très
content eût égard à la dimension de la prestation. L'intégrateur aussi
était content : 3 FW-1 à fournir.
Tout ce beau monde était donc satisfait. Magnifique non ?

Ainsi, pourquoi multiplier par un facteur minimum de 3 l'investissement pour
gagner pas grand chose au final techniquement parlant (p'têt un facteur
1,5) ?
Mais dans ce cas précis le gain (bien supérieur à 3 à mon avis) était
psychologique (et donc irrationnel) côté client. Mais il s'agissait d'un
grand compte.

Autre contexte, pas un grand compte et plus récemment : un réseau
d'entreprise classique avec des nomades et plusieurs sites le tout raccordé
via des VPN IPSEC.
Rien à signaler de particulier, les employés ne peuvent pas accéder en
direct à Internet et doivent passer par 2 passerelles de courriers avant de
voir leur courriels sortir ou rentrer. Même chose pour la navigation avec
présence d'un proxy. Le serveur est un AS/400.
De temps en temps on trouve un virus sur un poste interne (ben oui jamais
sur les postes nomades, les consignes sont bien passées apparemment) qui ne
s'est pas raccordé au réseau depuis plusieurs semaines mais c'est tout le
bout et il est éradiqué dans les minutes qui suivent son raccordement.
Enfin, quand il arrive à récupérer une version à jour de signatures.
Bref. Jusqu'au jour où, ayant mis en place quelques règles de filtrages
destinées au pistage (une fois l'an un p'tit audit) je découvre 2 postes
qui communiquaient avec un serveur HTTPS à intervalle irrégulier. Intervalle
compris entre 1/2 heure et 1 heure et parfois, aux heures ouvrées,
plusieurs fois par minute avec, cette fois, un volume conséquent en
sortie ! Qui plus est, une fois interdit, il tentait (l'un mais pas
l'autre) de joindre une autre adresse (qui ne répondait pas) et
systématiquement, lorqu'on le bloquait il se mettait en quelque sorte en
veille (une tentative de contact toutes les heures environ).

L'enquête a été diligentée pour trouver qu'il s'agissait d'une DLL installée
suite à réception d'un courriel par les collègues d'un ancien stagiaire
(qui leur avait expédié ce courriel à l'issue de son stage). Et comme il
s'agisait d'une création ex-nihilo aucun antivirus ne l'avait détecté.
On a supposé que ce client créait un canal caché de commande/action comme
avec IRC.
Impossible de limiter les volumes sortants de HTTPS sur le proxy, certains
expédient légitimement des fichiers ainsi.

Tout cela pour dire quoi ? Pour dire que, dans ce cas, le coût marginal pour
atteindre le niveau de sécurité supérieur nous permettant d'éviter ce genre
de choses au préalable n'était pas supportable.

--
email : usenet blas net

Vous avez filtré cet utilisateur ! Consultez son message

Cedric Blancher wrote:

La population oui, mais quel est ta maîtrise de son moyen d'accès à ton
VPN ? S'il peut accéder au VPN via un RTC, qu'est-ce qui va l'empêcher
de le faire via un hotspot, environnement nettement moins sûr, voire
carrément pas du tout.

Je n'ai pas de souci vis-à-vis de la sécurité offerte à un usager du
Hotspot disposant d'une machine bien configurée. Je me fais plus de soucis
au sujet de la sécurité intrinsèque du fournisseur vis-à-vis de tout ce qui
traîne sur un hotspot. Mais ce n'est pas mon pb.
Le seul truc qui me dérange, dans un hotspot, est la qualité de service que
je peux annoncer à mon usager professionnel.
En effet, il a, selon moi, très peu risque de se faire pirater (s'il
respecte les consignes et si le poste est correctement configuré) mais il
a, en revanche, beaucoup de risques d'être désassocié, d'avoir une bande
passante réduite à une peau de chagrin (a fortiori s'il est souvent
désassocié).
Je dis peu de risque et non aucun risque car je ne suis jamais à l'abri
d'une faille dans une négociation sécurisée quelconque (SSH ou IPSEC).
Et le risque zéro sur le rézo hein ?

Si le VPN est chiffré (l'inverse est un non-sens de nos jours) que
risque-t-il ?

De se faire rooter et que l'attaque passe _dans_ le VPN. Le VPN, c'est
chouette, ça sécurise la communication entre deux bouts. Mais qu'est-ce
qui t'assure la sécurité de l'un et l'autre des deux bouts ? En
particulier quand le lien VPN est monté, dans la mesure où on sait
contourner le filtrage mis en place par le client VPN quand il en met un ?

Dans ce cas arrêtons tout et stoppons les VPN et fermons la boutique.
Le rootage viendra plus sûrement de l'intérieur à mon sens, au prorata.

Si tu veux, je privilégie une méthode risque / coûts (dans mon boulot) au
sein d'une approche progressive (dans les ng) de la sécurité :-).
C'est à dire que je me place entre la vision minimaliste AOSI (*) et les
considérations intégristes (**) de certains.
J'écris progressive car j'espère qu'à force de répéter et râbacher et de
participer à l'effort de guerre comme toi-même ainsi que tous ceux
qui pratiquent la sécurité au quotidien, ceux qui peinent à se connecter à
Internet et sont envahis de saloperies se rapprocheront progressivement
de ceux qui manipulent les règles Snort ou ipf digites in naso.
Pour la méthode risque / coûts voir plus bas.

Donc pourquoi ne pas placer une tête de pont sur la DMZ ?
Dans l'absolu on s'en tape. En effet, on ne sait rien de l'environnement du
gars qui a posé la question. Est-il seul dans l'administration ou
dispose-t-il d'un service informatique digne de ce nom ? On ne sait pas.
Toujours est-il que s'il s'agit d'une boîte de quelques centaines de
salariés elle dispose à coup sûr des compétences locales (quitte à les
former) pour administrer des situations relativement complexes. Et pour ces
entreprises la question ne se pose même pas : ou on fusionne les services
ou c'est la solution que je préconise plus bas.
Maintenant parlons du cas où il n'y a pas de compétence locale. Dans ce cas
on va essayer de faire simple de manière à être en mesure de faire évoluer
le truc sans trop de casse. Et ma foi, tant pis pour les considérations de
sécurité avancées.
Il ne faut jamais oublier que tout niveau de sécurité supplémentaire se
traduit automatiquement par des coûts supplémentaires et récurrents
qu'il est important d'intégrer dans l'équation, les exploitants étant
rarement les consultants/intégrateurs (pour lesquels plus c'est complexe
mieux c'est, of course).

Dans ce cadre là (absence de compétences), je considère que placer le 501
dans la DMZ n'offre
pas une augmentation phénoménale du niveau de sécurité (***) alors
qu'elle complique de manière plus conséquente l'administration.
Le niveau requis est bien entendu plus important si aucune précaution n'a
été prise vis-à-vis des nomades
que si des précautions ont été mises en oeuvre (lesquelles ?). Et dans le
premier cas ça vaut le coup (de placer le 501 dans la DMZ).

Alors, au final, dans la mesure où, effectivement, on ne sait rien des
nomades allons
jusqu'au bout de la démarche ! Quitte à placer la tête de pont VPN sur la
DMZ plaçons-la sur sa PROPRE DMZ ! Le surcoût par rapport à la solution
précédente est négligeable (une carte Ethernet en plus) tout en augmentant,
à mon avis, bien mieux le niveau de sécurité et simplifiant le jeu de
règles à adopter (les règles se concentrent sur le firewall, plus besoin de
jouer avec le filtrage sur le 501). Cela donne 4 pattes au firewall.
Ce qui exclut d'emblée le PIX dans ce rôle.

[...]

Tu veux donc dire que tes portables ne sont pas utilisés par des
commerciaux et autres VRP non informaticiens ? La tendance que j'ai pu
constater en audit, c'est que les portables confiés à ce genre de
population dérivent nettement plus vite que les postes fixes. D'une part
parce que tu ne peux pas maîtriser la mise à jour des ces postes
constamment en vadrouille, et d'autre part parce l'utilisateur se prend
souvent à installer des trucs (genre une carte WiFi).

Le conseil que je donne et que j'impose parfois (pour faire reepecter la
politique définie de concert) car là ma responsabilité est engagée) est le
suivant :
poste fourni par l'entreprise = poste verrouillé et chiffré. Interdiction
d'y installer quoi que ce soit. Et si je pouvais y mettre du zBasic je le
ferais (y compris sur les postes fixes d'ailleurs).

Poste non fourni par l'entreprise : pas de connexion que ce soit à distance
ou en local (contrôle MAC au niveau des switches [COP]).
Maintenant il y en a qui suivent et d'autres non. Je suis missionné pour
sécuriser pas pour écouter les pleurs des uns et les malheurs des autres.
De toute manière on sent
bien dès la revue de contrat ce qui sera applicable et ce qui ne le sera
pas dans l'entreprise que l'on a en face de soi.
Lorsqu'on prête une voiture d'entreprise à un employé on ne s'attend pas à
ce qu'il joue aux auto-tamponeuses avec mais on tolère malgré tout qu'il
parte en vacances avec.

80% des menaces viennent toujours de l'intérieur géographique à ce jour.

Cette étude du FBI a 5 ans, et elle ne tient pas compte du phénomène de
rebond. Si par exemple mon attaque vient d'un de tes postes nomades via le
VPN, elle sera comptée comme interne.

C'est pour cela que j'ai parlé de géographie (ou personnel sédentaire) et
l'étude à laquelle je me réfère date de 1997 (le CLUSIF) régulièrement mise
à jour (2002 je crois).
M'enfin si c'est 70% ça ne change pas grand chose. De l'intérieur la
fourchette des vulnérabilités est bien plus étendue. Il faudrait comparer
à périmètre équivalent et là ... pas de chiffres actualisés.

Fusionner tête de VPN et firewall n'empêche pas de mettre en place du
filtrage. Quand tu dis de mettre la tête de VPN dans le LAN parce que la
faire arriver en DMZ complique la configuration, perso, je comprends
tête de VPN sans filtrage.

Euh non, j'ai été un peu rapide sur le coup là, c'est vrai mais non, dans
les 2 cas le 501 est équipé de règles de filtrage. C'est pour cela, du
reste, que la configuration globale est plus compliquée dans le cas où le
501 est placé sur la DMZ que lorsqu'il est placé sur le LAN.
D'où l'intérêt de placer le 501 sur sa propre DMZ, ça simplifie pas mal de
choses.

Elles le rammasseront dès que le nomade se connectera en interne ou via
la DMZ, ça ne change rien.

Pour la connexion en interne oui. Pour la connexion en DMZ, pas d'accord.
tout dépend de ce que tu laisses passer et comment tu le laisses passer.

Admettons que le poste de travail typique possède une application
client-serveur (disons de suivi de clientèle) dialoguant avec le SQL server
de l'entreprise.
Le nomade possède donc cette application. Je puis donc attaquer le serveur
SQL que ma tête de pont soit sur une DMZ ou sur le réseau local.
L'avantage de la DMZ dédiée est de pouvoir placer une autre machine entre la
DMZ et le firewall (détection/prévention d'intrusion) mais là encore au
prix d'une certaine complexité.

[...]

Aucune de ces politique ne tient la route. Tu peux définir des niveaux de
sécurité intermédiaires entre le dehors et le dedans, tout en gardant
un réseau fonctionnel. Mais ça demande de mettre un peu le nez au-dessus
de la planche à dessin. J'ai déjà vu des SI avec un réseau pour les
laptops et un autre pour les postes fixes, avec chacun leur domaine et du
filtrage entre les deux empêchant l'un de polluer l'autre à tout va,
tout en conservant les fonctionnalités nécessaires à un travail
efficace, et ce, avec des moyens somme toute assez classiques.

Oui, je ne prétends pas le contraire. La technologie permet de faire pas mal
de choses : VLAN, MPLS, double-attachement (on en a parlé récemment) et
même des Qos différentes dont la discipline est pilotée par un détecteur
d'intrusions.
Mais la question est toujours la même : quel est le bénéfice marginal ?
Combien ça coûte vs l'exploitation ? On peut définir des politiques
ultra-complexes ... tant qu'il y a du monde pour les respecter et les
appliquer.

Comme je l'ai annoncé plus haut j'utilise une pseudo-méthode qu'on pourrait
également appelé risque asymptotique / coût marginal. C'est parfois
subjectif je ne le cache pas (comment chiffrer un risque ?), vachement
tiré de l'expérience et du reste ce n'est pas applicable partout.
Exemple : dans le domaine militaire ou chez les grands comptes où les
problématiques sont tout autres (c'est un autre monde).
Mais je ne pense pas que l'un comme l'autre viennent poser des questions
ici. Ils leur suffit d'interpeler un consultant traînant dans les couloirs.

Je ne suis pas contre sécuriser au maximum (**) mais je suis d'un naturel
paresseux et surtout comment prouver au client que c'est mieux ? (****) Par
un audit ?
S'il n'a déjà pas le fric pour s'acheter un PIX plus performant je doute
qu'il finance un audit.

Mais au final, c'est pour faire joli ou c'est vraiment utile ? Dans quel
contexte ?

Dans un contexte ou je veux que mes paquets IP ne soient pas altérés sur
le chemin. Ça m'assure que le paquet IP que je reçoit est celui qui a
été émis de l'autre côté. Pas d'option IP à la con en plus en
particulier.

Ca d'accord mais je demandais dans quel contexte est-on suffisamment
paranoïaque pour se dire qu'on risque une attaque du milieu (au sens propre
et figuré) dans un tunnel confidentiel et déjà authentifié ?

[...]

Bon ben autant s'en servir alors. Mais dans ce cas là, j'avoue que je
m'en servirais plus comme firewall que comme terminaison VPN.

Certes mais il y a déjà un firewall.
Finalement le moins cher et le plus élégant reste encore la fusion tête de
pont et firewall la première solution.
De toute manière si le gars a besoin de 20 tunnels le choix sera vite fait !

C'est l'IOS qui est performant
[...]

D'aucuns prétendront que l'IOS est lourd est plus adapté à ce qu'il
est sensé faire aujourd'hui.

Les PIX ne tournent pas sous IOS.

Ah oui mince, bordel, désolé !
Entre nous cela fait 7 ans que je n'ai pas touché un PIX et depuis je n'ai
touché que des Cisco classiques et je fusionne allègrement PIX et Cisco
IOS-Firewall Feature Set. Qui plus est gros Cisco. Alors pour moi, 501 ou
525 même combat.
Après avoir regarder sse caractéristiques, effectivement le 501 c'est le
basbas de gamme. Punaise. Navré j'aurais dû consulter ma boule avant.
Mais le jeu de commandes actuel du PIX ressemble pourtant furieusement au
jeu de commandes IOS !

D'ailleurs, un port i386 d'IOS a été
fait, Compaq vendait ce genre de trucs. Ben franchement, les 20 ans

d'expérience, ils ramaient sec...

Un peu normal. Historiquement l'IOS a été développé sur Motorola comme
pratiquement TOUS les systèmes électroniques et automatiques des années 80
et 90. Et un développeur Motorola a beaucoup de mal avec l'architecture
i386. L'inverse doit être vrai également.

C'est un peu comme dire que les CSS sont des
bons produits parce que Cisco a de l'expérience...

Confusion. Sorry.

J'ai proposé l'inverse pour la raison suivante. Le PIX est plus fin
dans ses caractéristiques de gestion dynamique du filtrage.

Ah ?

Oui de mémoire (année 2000) l'ISO-Firewall disposait de commandes permettant
une réaction dynamique du filtrage : ip audit.

db

(*) A Oualpe Sur Internet : ça fonctionne, je ne touche plus à rien et je
ferme le yeux en priant.

(**) Laquelle consiste à livrer à chacun des mots de passe de 20 caractères
générés aléatoirement, renouvelés chaque semaine (et à usage unique pour le
srvice informatique), filtrer tout ce qui est filtrable 3 fois, via les
filtres réseaux, via des services mandataires et via les capacités
(capabilities)
du système auquel s'ajoute un premier anneau de 3 pitbulls (à 120° l'un de
l'autre) secondé par un second anneau de 3 dobermans (en alternance avec les
pitbulls ; les Dobermann sont à l'extérieur pour contenir les pitbulls) et,
on n'est jamais trop prudent, on rajoute un pack de C4 à l'intérieur de la
machine des fois que. Le pack de C4 est commandé électriquement et en
sans-fil, doublé par le GSM et le satellite. Et pour ête tout à fait sûr on
y ajoute un gardien.
Tout ça pour pouvoir affirmer : << voyez, ma machine n'a jamais été piratée
et ne le sera jamais >>.
Certes mais inutile de préciser que personne n'a jamais utilisé ni
installé d'applications sur cette machine car inacessible, trop
verrouilée et qui plus est, terrifiante.
Après une période plus ou moins longue où les mots de passe ont traîné
joyeusement sur les écrans ou sous les claviers et quelques collaborateurs
zélés en ont maquillé le menu à la cantine, les utilisateurs en sont revenus
à la bonne vieille méthode du P2P (le workgroup) et l'accès Internet passe
désormais par la liaison sans-fil qu'un collaborateur (toujours zélé) a
établi avec un résident (avec son accord) de l'immeuble d'en face.

(***) Du reste il nous manque des valeurs pour quantifier ce genre de <<
niveau >>. Chacun et chaque méthode disposant de ses propres critères ça
n'aide pas à être objectif dans les démarches.
Mais bon c'est peut-être pour ça également qu'on le fait, ce boulot. Ca
procure un certain sentiment de liberté.

(****) Il y a quelques années j'ai participé à un appel d'offres d'un grand
compte sur le sujet de l'hébergement d'un service Web y compris la
sécurisation depuis l'extérieur. A l'époque on ne parlait pas encore de
détecteur d'intrusion, uniquement de firewall.
Pas de réseau LAN interne à l'entreprise à protéger, uniquement le serveur
Web.
Celui qui a emporté le marché proposait 3 niveaux de firewall. Le grand
compte était content : il avait l'impression d'être sacrément bien protégé
et il lui semblait ainsi qu'il avait le temps de réagir si jamais le
premier firewall était piraté. Le soumissionnaire était lui aussi très
content eût égard à la dimension de la prestation. L'intégrateur aussi
était content : 3 FW-1 à fournir.
Tout ce beau monde était donc satisfait. Magnifique non ?

Ainsi, pourquoi multiplier par un facteur minimum de 3 l'investissement pour
gagner pas grand chose au final techniquement parlant (p'têt un facteur
1,5) ?
Mais dans ce cas précis le gain (bien supérieur à 3 à mon avis) était
psychologique (et donc irrationnel) côté client. Mais il s'agissait d'un
grand compte.

Autre contexte, pas un grand compte et plus récemment : un réseau
d'entreprise classique avec des nomades et plusieurs sites le tout raccordé
via des VPN IPSEC.
Rien à signaler de particulier, les employés ne peuvent pas accéder en
direct à Internet et doivent passer par 2 passerelles de courriers avant de
voir leur courriels sortir ou rentrer. Même chose pour la navigation avec
présence d'un proxy. Le serveur est un AS/400.
De temps en temps on trouve un virus sur un poste interne (ben oui jamais
sur les postes nomades, les consignes sont bien passées apparemment) qui ne
s'est pas raccordé au réseau depuis plusieurs semaines mais c'est tout le
bout et il est éradiqué dans les minutes qui suivent son raccordement.
Enfin, quand il arrive à récupérer une version à jour de signatures.
Bref. Jusqu'au jour où, ayant mis en place quelques règles de filtrages
destinées au pistage (une fois l'an un p'tit audit) je découvre 2 postes
qui communiquaient avec un serveur HTTPS à intervalle irrégulier. Intervalle
compris entre 1/2 heure et 1 heure et parfois, aux heures ouvrées,
plusieurs fois par minute avec, cette fois, un volume conséquent en
sortie ! Qui plus est, une fois interdit, il tentait (l'un mais pas
l'autre) de joindre une autre adresse (qui ne répondait pas) et
systématiquement, lorqu'on le bloquait il se mettait en quelque sorte en
veille (une tentative de contact toutes les heures environ).

L'enquête a été diligentée pour trouver qu'il s'agissait d'une DLL installée
suite à réception d'un courriel par les collègues d'un ancien stagiaire
(qui leur avait expédié ce courriel à l'issue de son stage). Et comme il
s'agisait d'une création ex-nihilo aucun antivirus ne l'avait détecté.
On a supposé que ce client créait un canal caché de commande/action comme
avec IRC.
Impossible de limiter les volumes sortants de HTTPS sur le proxy, certains
expédient légitimement des fichiers ainsi.

Tout cela pour dire quoi ? Pour dire que, dans ce cas, le coût marginal pour
atteindre le niveau de sécurité supérieur nous permettant d'éviter ce genre
de choses au préalable n'était pas supportable.

--
email : usenet blas net

Nicob

27/01/2005 à 09:21

On Thu, 27 Jan 2005 02:42:30 +0000, Dominique Blas wrote:

Je n'ai pas de souci vis-à-vis de la sécurité offerte à un usager du
Hotspot disposant d'une machine bien configurée.

Même vis-à-vis d'outils comme celui-ci ?
http://www.theta44.org/main.html#software

Dans ce cas arrêtons tout et stoppons les VPN et fermons la boutique.
Le rootage viendra plus sûrement de l'intérieur à mon sens, au prorata.

Pour moi, une compromission du LAN suite à un rebond depuis un portable
ayant un accès VPN est un scénario classique dans le domaines des
attaques ciblées.

Pour une (vieille) référence à ce type d'attaques, cf. la partie "Third
week" de http://www.viacorp.com/auditing.html

Il ne faut jamais oublier que tout niveau de sécurité supplémentaire
se traduit automatiquement par des coûts supplémentaires et
récurrents qu'il est important d'intégrer dans l'équation

Entre un coût récurrent et planifiable (installation de patchs, analyse
des logs) et un coût "caché"/imprévisible (compromission, perte de
données, ...), mon choix est vite fait.

Celui qui a emporté le marché proposait 3 niveaux de firewall [...]
L'intégrateur aussi était content : 3 FW-1 à fournir.

Ca, c'est débile. Tant qu'à mettre des fw en série, autant choisir des
produits différents (un FW-1, un Netfilter et un NetASQ par exemple).

Nicob

Cedric Blancher

27/01/2005 à 09:31

Le Thu, 27 Jan 2005 02:42:30 +0000, Dominique Blas a écrit :

Le seul truc qui me dérange, dans un hotspot, est la qualité de service que
je peux annoncer à mon usager professionnel.
En effet, il a, selon moi, très peu risque de se faire pirater (s'il
respecte les consignes et si le poste est correctement configuré) mais il
a, en revanche, beaucoup de risques d'être désassocié, d'avoir une bande
passante réduite à une peau de chagrin (a fortiori s'il est souvent
désassocié).

Je ne pensais pas à cela.

Observation : il est _trivial_ d'injecter des données dans
un flux WiFi. Cela a été démontré par la pratique à la dernière
BlackHat[1]. L'attaque est simple : on détecte les requête HTTP et on
injecte des réponses falsifiées. Cette attaque ne nécessite même pas
d'être associé.

Étendons le spectre de cette attaque. On sait qu'on est capable, sur un
lien WiFi qu'on peux lire (ce qui est le cas de tous les hotspots),
d'injecter du contenu HTML arbitraire à n'importe quelle requête. La
probabilité d'utilisation de IE étant ce qu'elle est, le nombre de
failles disponibles non patchées étant également assez impressionnant,
et, enfin, le délai de mise à jour d'un laptop étant plus long que pour
un poste sédentaire (vérification empirique), on a amha une probabilité
de réussite non négligeable de rooter le poste juste en injectant un
code malicieux au moment où le mec se connecte au portail captif.

Un fois que le poste est pourri, tu peux faire du SSH, de l'IPSEC, du
VPN-SSL avec les moyens les plus monstrueux du monde, ça ne changera rien.

Sur les reste, je suis globalement d'accord sur les compromis nécessaires
dans la pratique.

[1] http://www.evilscheme.org/defcon/

--
C aussi la dernière fois que je parlerais de warez
En donnant mes adresses, beaucoup plus de gens iront voir ces sites et
donc, le téléchargement deviendra de plus en plus impossible !
-+- Pip99 in GPJ : Le piratage c'est bien, mais que pour moi -+-

Le Thu, 27 Jan 2005 02:42:30 +0000, Dominique Blas a écrit :

Le seul truc qui me dérange, dans un hotspot, est la qualité de service que
je peux annoncer à mon usager professionnel.
En effet, il a, selon moi, très peu risque de se faire pirater (s'il
respecte les consignes et si le poste est correctement configuré) mais il
a, en revanche, beaucoup de risques d'être désassocié, d'avoir une bande
passante réduite à une peau de chagrin (a fortiori s'il est souvent
désassocié).

Je ne pensais pas à cela.

Observation : il est _trivial_ d'injecter des données dans
un flux WiFi. Cela a été démontré par la pratique à la dernière
BlackHat[1]. L'attaque est simple : on détecte les requête HTTP et on
injecte des réponses falsifiées. Cette attaque ne nécessite même pas
d'être associé.

Étendons le spectre de cette attaque. On sait qu'on est capable, sur un
lien WiFi qu'on peux lire (ce qui est le cas de tous les hotspots),
d'injecter du contenu HTML arbitraire à n'importe quelle requête. La
probabilité d'utilisation de IE étant ce qu'elle est, le nombre de
failles disponibles non patchées étant également assez impressionnant,
et, enfin, le délai de mise à jour d'un laptop étant plus long que pour
un poste sédentaire (vérification empirique), on a amha une probabilité
de réussite non négligeable de rooter le poste juste en injectant un
code malicieux au moment où le mec se connecte au portail captif.

Un fois que le poste est pourri, tu peux faire du SSH, de l'IPSEC, du
VPN-SSL avec les moyens les plus monstrueux du monde, ça ne changera rien.

Sur les reste, je suis globalement d'accord sur les compromis nécessaires
dans la pratique.

[1] http://www.evilscheme.org/defcon/

--
C aussi la dernière fois que je parlerais de warez
En donnant mes adresses, beaucoup plus de gens iront voir ces sites et
donc, le téléchargement deviendra de plus en plus impossible !
-+- Pip99 in GPJ : Le piratage c'est bien, mais que pour moi -+-

Vous avez filtré cet utilisateur ! Consultez son message

Cedric Blancher

27/01/2005 à 09:38

Le Thu, 27 Jan 2005 08:21:18 +0000, Nicob a écrit :

Je n'ai pas de souci vis-à-vis de la sécurité offerte à un usager du
Hotspot disposant d'une machine bien configurée.
Même vis-à-vis d'outils comme celui-ci ?

http://www.theta44.org/main.html#software

D'autant que pour le moment, je n'ai pas trouvé dans Windows comment
forcer une association ESSID/BSSID comme je peux le faire avec
wpa_supplicant par exemple. C'est à dire pour faire simple, m'assurer que
si je me connecte à un réseau donné, je le fais bien sur l'AP que je
connais. Même si cette condition peut-être réalisée par un attaquant
décidé et renseigné, ça évitera toujours de se faire plier par le
premier SK venu.

Ceci dit, j'étais à Pacsec lors de la présentation de l'outil. Même
s'il exploite des choses relativement connues et maîtrisée, l'outil est
extrêmement efficace et bien fini, en particulier la simulation des
services.

--
AC: Et je promet qu'elles seront disponibles avant la bouffe de samedi.
Ol: Tt tt... Tout développeur faisant des promesses sur des dates de
disponibilité tend le bazooka à clous pour se faire battre.
-+- Ol. in Guide du Macounet Pervers : fcsm : fouet.cuir.sado.maso ? -+-

Dominique Blas

27/01/2005 à 14:39

Cedric Blancher wrote:

Étendons le spectre de cette attaque. On sait qu'on est capable, sur un
lien WiFi qu'on peux lire (ce qui est le cas de tous les hotspots),
d'injecter du contenu HTML arbitraire à n'importe quelle requête. La
probabilité d'utilisation de IE étant ce qu'elle est, le nombre de
failles disponibles non patchées étant également assez impressionnant,
et, enfin, le délai de mise à jour d'un laptop étant plus long que pour
un poste sédentaire (vérification empirique), on a amha une probabilité
de réussite non négligeable de rooter le poste juste en injectant un
code malicieux au moment où le mec se connecte au portail captif.
De quel portail parlons-nous ? Je n'ai pas parlé de portail. Le gars dispose

d'un client IPSEC (*). Lequel est assorti d'un fw. Point.

db

(*) Et d'un Lynx ! Non, je rigole là.

--
email : usenet blas net

Cedric Blancher

27/01/2005 à 14:44

Le Thu, 27 Jan 2005 13:39:19 +0000, Dominique Blas a écrit :

De quel portail parlons-nous ? Je n'ai pas parlé de portail.

T'as déjà utilisé un hotspot public ?
Quand tu te connectes, tu dois d'abord valider ta connexion sur ce qu'on
appelle un portail captif avant de pouvoir sortir et faire en sorte que
ton client VPN puisse fonctionner. Et ce truc, ça commence par une
connexion HTTP...

--
Ca se fait pas du tout d'avoir donné toutes les adresses email des
votants C bon pour les spammers ça !
[suit la liste intégrale des votants mal quotée]
-+- AN in Guide du Neuneu Usenet : bien suivre sa logique -+-

VPN dans DMZ, où placer le PIX 501 ?

10 réponses

Veuillez sélectionner un problème