VPN dans DMZ, où placer le PIX 501 ?

Nicob wrote:

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
Oui. Il faudrait que je bricole avec mais a priori OUI.

Question de méthode de connexion (pas de relation directe avec une
quelconque adresse IP publique hormis la gateway VPN) et, accessoirement,
de ne pas laisser traîner tout et n'importe quoi sur le portable (j'ai
écris que si je m'écoutais, le portable serait réduit à un zBasic :-)).

Si j'ai l'occasion, un jour, je ferai faire une détection d'intrusion sur
des portables (Win32, MacOX/x, Linux, BSD) configurés par moi-même au sein
d'un hotspot. Ce sera instructif je pense : permettant peut-être de fixer
un compromis (temporaire) entre un strict minimum utilisable sans danger
(99%) et ce qui est tolérable par l'usager nomade.

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.

Oui étant donné la simplicité de la chose mais s'il n'y avait aucune parade
on aurait fermé la boutique depuis longtemps.
A moins que tout le monde se voile la face (l'hypocrisie est quasiment une
religion parfois) ou espère passer entre les gouttes. :-)

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

J'ai zieuté. C'est long. J'y reviendrai tout à l'heure.

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.

Tout à fait. Le fait de devoir rechercher ce qu'il faut modifier dans le cas
d'architectures compliquées dénuées de compétences locales adaptées,
effectuer des tests la nuit de manière à ne perturber personne faire
partie, à mon sens, des coûts cachés.

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.
Ca, je ne te le fais pas dire. C'est une honte pour la profession.

C'est débile au niveau et technique (voire même conceptuel) mais au niveau
psychologique (pour le client) et financier (pour le soumissionnaire) c'est
tout à fait valable.
Le tout est de savoir ce que l'on vend : des dispositifs de sécurité et la
compétence qui va autour ou de l'assurance.
Un serrurier ne doit pas avoir trop de mal à vendre 3 portes blindées (en
série) chez certains clients fortunés.

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

Certes mais à l'époque (1997) il n'y avait pas trop le choix non plus.

Il devait p'têt y avoir Netscreen je crois mais c'est tout le bout.

db
--
email : usenet blas net

Cedric Blancher wrote:

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 ?
J'en ai même conçus et déployés. :-)

Et j'avoue que j'ai surtout utilisé ceux que j'ai déployés.

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...

Pas tous. Certains fonctionnent à l'aide d'authentification basée sur une
clé USB possédant une carte SIM (WeRoam). D'autres encore à l'aide de ton
téléphone portable (Excilan). Dans les 2 cas on ne passe pas par un
portail.
Mais il est vrai que le mode d'accès principal est l'authentification via un
portail HTTPS (Tiscali, etc).

Maintenant si je note que ce genre de mode d'accès pose un problème de
sécurité incontournable (genre propice à l'injection) ma recommandation
sera de ne pas l'utiliser.

db

--
email : usenet blas net

Dominique Blas wrote:

Cedric Blancher wrote:
[host spot public "classique" (orange & co) => possibilité d'injection

avec ensuite utilisation de failles]

Mais il est vrai que le mode d'accès principal est l'authentification via un
portail HTTPS (Tiscali, etc).

Maintenant si je note que ce genre de mode d'accès pose un problème de
sécurité incontournable (genre propice à l'injection) ma recommandation
sera de ne pas l'utiliser.

Préalable : aucune provoc dans ce qui suit.

"si je note que [...] ma recommandation sera" (futur) semble montrer que
tu n'avais pas envisagé ce cas de figure qui a déjà pu se produire.

En remontant plus haut dans la discution je pense que tu peux maintenant
admettre que l'arrivée de la tête vpn et les droits sur les flux
associés ont belle et bien une grosse importance et qu'il importe donc
d'envisager dès le départ qu'un poste nomade à une probabilité d'être
rooté sinon supérieure à celle d'un poste local[1] du moins non négligeable.

Et en tant que tel on doit éviter de faire arriver la tête dans le
lan[2], filtrer le tout et interdire tout ce qui peut être interdit sans
empêcher le gars de bosser (le cas échéant en lui permettant de bosser
"différement")

Le nomadisme a un coût bien supérieur à celui de l'achat des machines et
de l'anti-virus. Je pense qu'il est sage d'admettre que ce surcoût ne se
limite pas à la simple installation de vpn.

Le reste est effectivement (je suis d'accord avec toi sur ce point) une
question de compromis "utilisabilité"/sécurité/coût avec des priorités
qui varient en fonctions des entreprises et des architectures (le vol
d'une base peut être sans conséquence chez certains, chez d'autres la
modif d'infos ne génèrera qu'une gêne temporaire-c'est plus rare- etc).

Eric.

[1] c'est vraiment pour ne pas ajouter de l'huile sur le feu, parce que
pour moi il n'y a pas photo :)

[2] en restant général, on trouvera toujours des cas particuliers.

--
L'invulnérable :
Je ne pense pas etre piratable, infectable par un trojen oui!
Vu sur fcs un jour de mars 2004.

Eric Razny wrote:

Dominique Blas wrote:

Cedric Blancher wrote:
[host spot public "classique" (orange & co) => possibilité d'injection

avec ensuite utilisation de failles]

Mais il est vrai que le mode d'accès principal est l'authentification via
un portail HTTPS (Tiscali, etc).

Maintenant si je note que ce genre de mode d'accès pose un problème de
sécurité incontournable (genre propice à l'injection) ma recommandation
sera de ne pas l'utiliser.

Préalable : aucune provoc dans ce qui suit.
C'est bien. Car désormais je fuis les fils qui partent en troll injurieux.

"si je note que [...] ma recommandation sera" (futur) semble montrer que
tu n'avais pas envisagé ce cas de figure qui a déjà pu se produire.

En fait, je n'y ai jamais été confronté directement.
Dans le cadre des missions de sécurité, lorsque les nomades étaient inclus
dans le périmètre d'accès ceux-ci n'étaient pas équipés d'interfaces
sans-fil ou celles-ci étaient volontairement désactivées. Ce qui n'excluait
pas le rootage via un intermédiaire sur le réseau mais largement moins
probable et donc ... écarté, la probabilité de vol étant plus importante.

De l'autre côté, chez l'opérateur sans-fil, la problématique était
différente : offrir des conditions d'accès sécurisé (WeRoam, Excilan) tout
en restant ouvert (portail classique via HTTPS), la sécurité des postes
nomades n'étant pas de notre ressort.

Mais je n'ai pas non plus été confronté à la sécurisation des téléphones
Bluetooth (et il y a du boulot là), des terminaux Blueberry (pardon
Blackberry)
de téléphones VoIP avec ou sans-fil (là aussi il y a du travail) et,
pourtant, le jour où j'y serai confronté il faudra bien que j'établisse un
plan.
A partir du moment où une technologie est
connue, que les failles potentielles y sont détectées (failles
technologiques) voire, mieux, que les failles réelles sont démontrées
(exploits [à cause du code]) il est facile d'établir un cadre de travail où
les vulnérabilités
et les menaces sont mises en rapport et les risques qui en découlent
évalués.

Ma responsabilité est (et cela réclame pas mal de connaissances actualisées
régulièrement et c'est sans doute le plus gros défi de ce métier) de
clairement identifier les vulnérabilités voire les menaces et d'exposer des
parades ayant le rapport qualité/prix le plus important.
A la rigueur, la conclusion ne me concerne pratiquement pas.

En remontant plus haut dans la discution je pense que tu peux maintenant
admettre que l'arrivée de la tête vpn et les droits sur les flux
associés ont belle et bien une grosse importance et qu'il importe donc
d'envisager dès le départ qu'un poste nomade à une probabilité d'être
rooté sinon supérieure à celle d'un poste local[1] du moins non
négligeable.

J'admets tout ce que tu veux.
En fait, je remarque j'ai sans doute beaucoup trop insisté sur le côté
négociateur que sur le degré de prise de conscience. Mais bon ce n'est pas
plus mal, au final.

Bien entendu le fait de placer le 501 sur la DMZ et même sa PROPRE DMZ est
la ** meilleure ** solution (en présence du 501 sinon la meilleure reste la
fusion). Toutefois des considérations annexes (coûts, compétences) peuvent
faire que la présence sur le LAN soit une solution envisageable. Dans ce
cas précis on ne savait rien d'autres sur l'environnement, le personnel,
donc ... restons dans l'absolu soit.

Mais je me refuse à tenir le discours qui consiste à hurler :
<< c'est de la merde ton truc, il faut fermer là, là et là, mettre des
pitbulls et basta ! Tout le reste c'est de la merde. Vous comprenez rien,
d'toute façon, j'me casse. >>.
Ce discours là Dieu sait si on l'a entendu ici !

Et en tant que tel on doit éviter de faire arriver la tête dans le
lan[2], filtrer le tout et interdire tout ce qui peut être interdit sans
empêcher le gars de bosser (le cas échéant en lui permettant de bosser
"différement")

Justement, j'en ai qui m'ont interdit de remplacer l'IE des postes de
travail fixes (et j'en ai d'autres qui ne pouvaient pas concevoir autre
chose que Mozilla) parce qu'entre le confort offert aux utilisateurs par IE
et la menace que réprésente IE, ben, le choix avait été fait.
Ok, très bien, je prends en compte et on adopte une autre stratégie. Combien
coûte cette stratégie ?
Plus chère que de remplacer les IE monsieur le client ! C'est pas grave ?
Très bien on continue : on n'autorise que certains sites (sur le proxy) pour
limiter la casse alors. Non ?
Ok, tant pis, vous risquez gros ! Ah, le confort importe davantage ?
Très bien, c'est vous le client mais vous êtes prévenu et c'est écrit là.
Etc, etc. Je caricature mais c'est à peu près ça.
Si vous (Cédric, Eric) vous avez des clients qui vous écoutent TOUJOURS je
veux bien qu'on échange.

Le nomadisme a un coût bien supérieur à celui de l'achat des machines et
de l'anti-virus. Je pense qu'il est sage d'admettre que ce surcoût ne se
limite pas à la simple installation de vpn.

Je connais bien le sans-fil (le 802.11) et il m'est facile, à partir de là,
d'imaginer les méthodes d'interception possibles visant à se retrouver en
situation classique : à savoir MITM sur un réseau filaire.
Mon métier n'est pas de connaître sur le bout des doigts les attaques, cela
réclame bien trop de technicité et une veille de chaque instant. Il y a des
gens que cela passionne et je leur laisse bien volontiers.

Mon métier (je considère que) est d'identifier les types/scenarios
d'attaques et
d'intrusion possibles (*) dans un contexte donné et d'imaginer (**),
proposer voire mettre en
place les systèmes permettant de minimiser la probabilité d'occurrence de
ces attaques/intrusions ou au pire, imaginer et proposer, voire mettre en
place les
dispositifs permettant de minimiser ** l'impact ** de ces
attaques/intrusions.
Il est donc important, de mon point de vue, de se tenir au courant
1. du mode de fonctionnement des technologies ;
2. des failles découvertes dans un produit

plus que des << exploits >> disponibles au jour le jour.

Lorsqu'on connaît PHP et son système de variables de formulaire et que l'on
a déjà développé (sous PHP ou autre chose) on imagine sans peine qu'il est
facile d'y injecter des choses qui peut-être permettront de questionner un
serveur SQL ou d'exécuter des commandes système. Même chose en ce qui
concerne la QUERY_STRING.

De même lorsqu'on sait comment fonctionne le 802.11 au niveau MAC, on
imagine
sans peine comment on peut perturber un réseau existant ou comment on peut
se faire passer pour un AP (du reste j'en ai fabriqués).
Et, du coup, on développe sans (trop de) peine des logiciels (sous Linux,
avec HostAP ou MadWifi c'est plus facile) de perturbation avec 2 cartes et
de leurre classique comme dans le monde militaire.
Je pensais à ça en lisant l'article de theta44, ce n'est pas directement
relié mais c'est de la même famille : j'ai utilisé ce leurre qu'on pourrait
utiliser en contre-attaque vis-à-vis d'un intrus passif en lui faisant
croire que,
d'un coup, il a affaire à une dizaine de nouveaux clients qui, chacun, font
du HTTPS, l'espace d'une seconde : quelle est l'adresse MAC légitime ? On
pourrait imaginer un leurre qui s'associerait successivement avec chaque AP
qu'il peut capter pour chaque trame TCP émise.
Bref, porter ce genre de système sur un PC grand public est une hérésie
d'autant que peu de hotspot en nombre dispose de plusieurs AP.

Je ne connaissais pas l'existence de theta44 mais ce dispositif
d'interception sophistiqué faisait partie des dispositifs imaginables
d'interception automatisés il y a 2 ans. Mais entre imaginer et le réaliser
il y a un monde.

Je dis que j'imagine ceci ou cela mais je n'avais pas imaginé l'histoire des
canaux cachés sous IRC (ou tout autre protocole dont ICMP). C'est con car je
savais depuis longtemps (avant IP) que c'était ainsi que fonctionnaient les
capteurs passsifs
(microphones, badges d'identification [Navigo, TCL] et RFID maintenant).
Mais je n'avais pas fait la transposition.
D'où l'intérêt, malgré tout, de se plonger régulièrement dans les failles
récemment découvertes pour rester << aware >>. Et le jour où je
n'aurais plus cette volonté là, ce sera fini.

Je le répète : je n'ai pas de souci avec les postes
nomades (avec ou sans-fil) si tant est que l'on m'écoute sur mes
recommandations.
J'ai effectivement un gros souci si les points sur lesquels j'insiste ne
sont pas accordés, là oui.
Dans ce cas, poru ce qui est du sans-fil je n'aurais qu'une parade (qui sera
plus ou moins
respectée) : imposer que les nomades n'aillent pas dans les hotspots très
fréquentés. Et encore ... dans un hôtel, le gérant n'a-t-il pas mis en
place, à demeure, un dispositif d'interception ? Je plaisante.

Il y a une seule chose contre laquelle je ne peux rien dans l'absolu : le
déni de service volontaire. Mais bon ça aussi c'est rare.

Le reste est effectivement (je suis d'accord avec toi sur ce point) une
question de compromis "utilisabilité"/sécurité/coût avec des priorités
qui varient en fonctions des entreprises et des architectures (le vol
d'une base peut être sans conséquence chez certains, chez d'autres la
modif d'infos ne génèrera qu'une gêne temporaire-c'est plus rare- etc).

Eric.

[1] c'est vraiment pour ne pas ajouter de l'huile sur le feu, parce que
pour moi il n'y a pas photo :)

Mais nous sommes d'accord mon cher Eric : il n'y a pas photo et il faut même
une DMZ à part.
Mais bon autant tu affirmeras cela à une moyenne PME -> grand compte sans
ambages (et même légèrement agressif pour être bien compris) autant
être aussi péremptoire vis-à-vis d'une TPME de 10 personnes ... c'est un peu
comme pisser dans un violon.

Et puis même le 501 c'est du bas de gamme. Je n'avais pas regardé avant
d'entamer ce fil mais c'est vraiment petit, petit ce truc.
Dans l'absolu le conseil serait même d'abandonner ce machin.

[2] en restant général, on trouvera toujours des cas particuliers.
Mais, c'est une citation ! :-)

db

(*) Je devrais écrire potentielles. Il ne s'agit pas forcément de failles
existantes ni même de dispositifs d'attaques/intrusion existants simplement
de potentialités laissées par la technologie, le code employé, etc.
Or, étant donné le temps dont disposent les hackers en herbe dans certaines
régions du monde, je considère que les potentialités sont, au final, des
possibilités.
Alors, effectivement, avec des possiblités on ferme la boutique. D'où
l'intérêt de se tenir un peu à jour pour savoir ce qui existe (ne serait-ce
qu'à cause du code, souvent inacessible, qui présentera forcément des
failles non potentielles celles-là) et de placer
malgré tout une probabilité d'occurrence sur ces possibilités et ainsi ne
pas systèmatiquement conseiller de virer toute l'informatique et couper
l'électricité.

(**) Imaginer : je pense que c'est là que réside tout l'intérêt de ce métier
pour moi. Le systématique, l'habituel, très peu.
Il y a une dizaine d'années un pote avec lequel je travaillais était inquiet
au sujet des vols de voiture. Il avait peur pour la sienne et au fil de la
discussion nous en sommes arrivés à une conclusion : les vieilles voitures
ou, du moins, les modèles d'actualité mais qui paraissaient vieux étaient
moins sujets au vol que ceux qui paraissaient sortir du garage.
J'ai donc imaginer un truc tout simple qui fait apparaître un véhicule comme
vieux alors qu'il est neuf. Ca réclame un peu de bricolage toutefois et ce
n'est pas très légal. Je pense que de centaines d'automobilistes résidant
dans des zones sensibles ont dû un jour ou l'autre utilisé ce truc (avant
que j'en ai l'idée). Hélas ce << truc >> n'est pratiquement plus utilisable
aujourd'hui à cause de l'électronique galopante dans les habitacles
récents. Mais d'un autre côté il devait être bien connu chez les voleurs.

--
email : usenet blas net

On Tue, 01 Feb 2005 02:47:01 +0000, Dominique Blas wrote:

Hélas ce << truc >> n'est pratiquement plus utilisable aujourd'hui à
cause de l'électronique galopante dans les habitacles récents. Mais
d'un autre côté il devait être bien connu chez les voleurs.

Que ce soit en sécurité informatique, en sécurité physique
(lock-picking/génération de masters) ou en sécurité électronique
(antivol de grande surface/clé à carte pour les voitures), les méchants
sont toujours en avance sur les gentils, vu qu'il ne leur suffit que de
connaître une seule faille exploitable, alors que le gentil doit *toutes*
les boucher.

Et on serait HS si on parlait des voitures, mais pourtant, il y aurait
beaucoup à dire sur leur sécurité (coup de la balle de ping-pong,
ouverture centralisée avec détecteur de choc, alarme volumétrique
inactive si une fenêtre est ouverte, ...)

Euh ... c'était quoi ton "truc" ?
Réponse en privé, on risque de ne pas passer la modération ...


Nicob