Je cherche à établir les regles dénéssaires sur un fierwall (kerio) afin
d'établir les accès nécésssaires pour que le poste d'un réseau local puisse
se connecter à AD et bénéficier des services sans réduire sa sécurité.
Pour faire simple, il y a deux type de VPN : - PPTP qui est une encapsulation GRE négociée en TCP, il y a donc un flux en TCP (port 1723) du client vers le serveur VPN, et ensuite il y a une communication GRE (protocole IP 47) entre les deux,
<troll> Hop, je marche dedans...
C'est moyen VPN non ? pasque l'aspect privé et sécurisé dans PPTP il est un poil réduit.
L'aspect sécurité est inexistant, par contre tu sépares bien les flux des zones privées (qui sont à chaque bout du tunnel) autres flux qui sont transmis sur les mêmes supports...
Je préfère parler de tunnel que de VPN, qui comme tu le disais, est un terme trop souvent employé pour désigner un peu tout ce qui permet de faire de l'encapsulation (et le T de PPTP est bien pour tunneling) Sus aux VPNs à tout va !! :-)
C'est vrai que c'est un VPN par tunnel, par contre on peut aussi faire des réseaux virtuels privé (dans mon acceptation, que je partage avec d'autres) en utilisant d'autres techniques comme le marquage de trame et/ou des circuits virtuels. Par contre on a pas forcément le même type de sécurité que sur un VPN IPSEC par exemple et la sécurité si elle existe ne porte pas sur le même périmètre.
</troll>
-- Julien
T0t0 a écrit :
Pour faire simple, il y a deux type de VPN :
- PPTP qui est une encapsulation GRE négociée en TCP, il y a donc un
flux en TCP (port 1723) du client vers le serveur VPN, et ensuite
il y a une communication GRE (protocole IP 47) entre les deux,
<troll>
Hop, je marche dedans...
C'est moyen VPN non ? pasque l'aspect privé et sécurisé dans PPTP il
est un poil réduit.
L'aspect sécurité est inexistant, par contre tu sépares bien les flux
des zones privées (qui sont à chaque bout du tunnel) autres flux qui
sont transmis sur les mêmes supports...
Je préfère parler de tunnel que de VPN, qui comme tu le disais, est un
terme trop souvent employé pour désigner un peu tout ce qui permet
de faire de l'encapsulation (et le T de PPTP est bien pour tunneling)
Sus aux VPNs à tout va !! :-)
C'est vrai que c'est un VPN par tunnel, par contre on peut aussi faire
des réseaux virtuels privé (dans mon acceptation, que je partage avec
d'autres) en utilisant d'autres techniques comme le marquage de trame
et/ou des circuits virtuels. Par contre on a pas forcément le même type
de sécurité que sur un VPN IPSEC par exemple et la sécurité si elle
existe ne porte pas sur le même périmètre.
Pour faire simple, il y a deux type de VPN : - PPTP qui est une encapsulation GRE négociée en TCP, il y a donc un flux en TCP (port 1723) du client vers le serveur VPN, et ensuite il y a une communication GRE (protocole IP 47) entre les deux,
<troll> Hop, je marche dedans...
C'est moyen VPN non ? pasque l'aspect privé et sécurisé dans PPTP il est un poil réduit.
L'aspect sécurité est inexistant, par contre tu sépares bien les flux des zones privées (qui sont à chaque bout du tunnel) autres flux qui sont transmis sur les mêmes supports...
Je préfère parler de tunnel que de VPN, qui comme tu le disais, est un terme trop souvent employé pour désigner un peu tout ce qui permet de faire de l'encapsulation (et le T de PPTP est bien pour tunneling) Sus aux VPNs à tout va !! :-)
C'est vrai que c'est un VPN par tunnel, par contre on peut aussi faire des réseaux virtuels privé (dans mon acceptation, que je partage avec d'autres) en utilisant d'autres techniques comme le marquage de trame et/ou des circuits virtuels. Par contre on a pas forcément le même type de sécurité que sur un VPN IPSEC par exemple et la sécurité si elle existe ne porte pas sur le même périmètre.
</troll>
-- Julien
GG
Oui, sauf que dans ce mode là ISA server est en mandataire.
Oui, je pense qu'aujourd'hui si on parle d'une bonne sécurité il faut parler d'un pare-feu mandataire, le reste je n'y crois pas dans un proche avenir et un environnement sérieux.
Si on place un firewall digne de ce nom dans la même situation il est aussi capable de faire de l'analyse de niveau 7.
CheckPoint par exemple, ;-) il est couteux aussi, les Rolls sont toutes belles et couteuses. :-)
Je me plaçais dans le cas d'un firewall qui ne déchiffrait pas les flux.
Certes, je ne parle de pare-feu personnel. :-)
ISA server aurait autant de mal à faire l'analyse dans la même situation.
Pas ISA 2004, me semble-t-il, mais ce n'est que de la beta me semble-t-il ;-)
Et comme tu le dis on place ses oeufs dans le même panier car les couches réseau et applicative viennent de la même base et sont donc suceptibles d'avoir une faille en même temps.
Non pas pour ISA me semble-t-il, mais ceci est une consideration qui dépasse notre débat, si MS veut communiquer il faut leur demander.
La brisure technologique à ses avantages en terme de sécurité même si elle apporte indubitablement une hétérogénéïté en terme d'administration et de gestion.
Oui mais si l'éditeur brise aussi le lien géographique de developpement et qu'il limite réellement la communication entre les équipes cela peut être aussi très correct, ce qui est le cas parfois. :-)
situations type de l'oeuf et de la poule, si on ne fait pas attention.
<troll on> administrateur a la petite semaine dehors. <troll off>
C'est vrai, que encapusler directement le niveau 2 du 802.11b, c'est plus chouette que de faire l'encapuslation au niveau 3.
Pour moi ce n'est pas obligatoire, c'est obligatoire aujourd'hui, mais bon cela implique des moyen qui ne peut peut-être pas forcement se mettre en oeuvre dans une petite entreprise avec un niveau de connaisdsance de "clicodormeur". :-) -- Cordialement GG.
Oui, sauf que dans ce mode là ISA server est en mandataire.
Oui, je pense qu'aujourd'hui si on parle d'une bonne sécurité il
faut parler d'un pare-feu mandataire, le reste je n'y crois pas dans
un proche avenir et un environnement sérieux.
Si on place un firewall digne de
ce nom dans la même situation il est aussi capable de faire de
l'analyse de niveau 7.
CheckPoint par exemple, ;-) il est couteux aussi, les Rolls
sont toutes belles et couteuses. :-)
Je me plaçais dans le cas d'un firewall qui ne déchiffrait pas les
flux.
Certes, je ne parle de pare-feu personnel. :-)
ISA server aurait
autant de mal à faire l'analyse dans la même situation.
Pas ISA 2004, me semble-t-il, mais ce n'est que de la beta
me semble-t-il ;-)
Et comme tu le dis on place ses oeufs dans le même panier car les
couches réseau et applicative viennent de la même base et sont donc
suceptibles d'avoir une faille en même temps.
Non pas pour ISA me semble-t-il, mais ceci est une consideration qui
dépasse notre débat, si MS veut communiquer il faut leur demander.
La brisure technologique
à ses avantages en terme de sécurité
même si elle apporte
indubitablement une hétérogénéïté en terme d'administration et de
gestion.
Oui mais si l'éditeur brise aussi le lien géographique de developpement
et qu'il limite réellement la communication entre les équipes cela peut être
aussi très correct, ce qui est le cas parfois. :-)
situations type de l'oeuf et de la poule, si on ne fait pas attention.
<troll on>
administrateur a la petite semaine dehors.
<troll off>
C'est vrai, que encapusler directement le niveau 2 du 802.11b, c'est
plus chouette que de faire l'encapuslation au niveau 3.
Pour moi ce n'est pas obligatoire, c'est obligatoire aujourd'hui,
mais bon cela implique des moyen qui ne peut peut-être pas
forcement se mettre en oeuvre dans une petite entreprise avec
un niveau de connaisdsance de "clicodormeur". :-)
--
Cordialement
GG.
Oui, sauf que dans ce mode là ISA server est en mandataire.
Oui, je pense qu'aujourd'hui si on parle d'une bonne sécurité il faut parler d'un pare-feu mandataire, le reste je n'y crois pas dans un proche avenir et un environnement sérieux.
Si on place un firewall digne de ce nom dans la même situation il est aussi capable de faire de l'analyse de niveau 7.
CheckPoint par exemple, ;-) il est couteux aussi, les Rolls sont toutes belles et couteuses. :-)
Je me plaçais dans le cas d'un firewall qui ne déchiffrait pas les flux.
Certes, je ne parle de pare-feu personnel. :-)
ISA server aurait autant de mal à faire l'analyse dans la même situation.
Pas ISA 2004, me semble-t-il, mais ce n'est que de la beta me semble-t-il ;-)
Et comme tu le dis on place ses oeufs dans le même panier car les couches réseau et applicative viennent de la même base et sont donc suceptibles d'avoir une faille en même temps.
Non pas pour ISA me semble-t-il, mais ceci est une consideration qui dépasse notre débat, si MS veut communiquer il faut leur demander.
La brisure technologique à ses avantages en terme de sécurité même si elle apporte indubitablement une hétérogénéïté en terme d'administration et de gestion.
Oui mais si l'éditeur brise aussi le lien géographique de developpement et qu'il limite réellement la communication entre les équipes cela peut être aussi très correct, ce qui est le cas parfois. :-)
situations type de l'oeuf et de la poule, si on ne fait pas attention.
<troll on> administrateur a la petite semaine dehors. <troll off>
C'est vrai, que encapusler directement le niveau 2 du 802.11b, c'est plus chouette que de faire l'encapuslation au niveau 3.
Pour moi ce n'est pas obligatoire, c'est obligatoire aujourd'hui, mais bon cela implique des moyen qui ne peut peut-être pas forcement se mettre en oeuvre dans une petite entreprise avec un niveau de connaisdsance de "clicodormeur". :-) -- Cordialement GG.
