N'autoriser que deux ordinateurs à accéder à un site "web"
L'accès doit être pour le moment ultra-limité et très sûr, or je pense que
les solutions de filtrage par adresse IP sont contournables, de même que que
les solutions de filtrage par adresse MAC.
Un VPN SSL ? Quel hébergeur proposerait cette solution pour un site tournant
en ASP avec SQL Server ?
Merci de vos réponses, observations, suggestions, questions, réflexions
...................
or je pense que les solutions de filtrage par adresse IP sont contournables, de même que que les solutions de filtrage par adresse MAC.
Sur un LAN, on peut effectivement "contrefaire" facilement son adresse IP et son adresse MAC.
Sur Internet, contrefaire son adresse IP est nettement plus difficile, du moins en TCP, car il faut que les paquets puissent trouver leur chemin du serveur vers les clients. Quant au filtrage par adresse MAC, il n'a pas vraiment de sens : de toute façon, le serveur ne voit que l'adresse MAC du routeur auquel il est directement connecté.
Un VPN SSL ?
Ça peut être une solution, effectivement.
Quel hébergeur proposerait cette solution pour un site tournant en ASP avec SQL Server ?
Sous Linux, ce serait trivial : tu prends un serveur dédié (une Dedibox coûte 15 EUR/mois) ou un VPS, et tu y installes OpenVPN. Bien sûr, le serveur web ne doit écouter que sur l'interface réseau VPN, et pas sur les interfaces physiques. Avec du Microsoft, ça doit être possible aussi (OpenVPN fonctionne sous Windows), mais faut payer les licences en plus.
On Sun, 9 Oct 2011 10:17:56 +0200, "DaVinche" <xardius@hotmail.com>:
or je pense que
les solutions de filtrage par adresse IP sont contournables, de même que que
les solutions de filtrage par adresse MAC.
Sur un LAN, on peut effectivement "contrefaire" facilement son adresse
IP et son adresse MAC.
Sur Internet, contrefaire son adresse IP est nettement plus difficile,
du moins en TCP, car il faut que les paquets puissent trouver leur
chemin du serveur vers les clients. Quant au filtrage par adresse MAC,
il n'a pas vraiment de sens : de toute façon, le serveur ne voit que
l'adresse MAC du routeur auquel il est directement connecté.
Un VPN SSL ?
Ça peut être une solution, effectivement.
Quel hébergeur proposerait cette solution pour un site tournant
en ASP avec SQL Server ?
Sous Linux, ce serait trivial : tu prends un serveur dédié (une
Dedibox coûte 15 EUR/mois) ou un VPS, et tu y installes OpenVPN. Bien
sûr, le serveur web ne doit écouter que sur l'interface réseau VPN, et
pas sur les interfaces physiques.
Avec du Microsoft, ça doit être possible aussi (OpenVPN fonctionne
sous Windows), mais faut payer les licences en plus.
or je pense que les solutions de filtrage par adresse IP sont contournables, de même que que les solutions de filtrage par adresse MAC.
Sur un LAN, on peut effectivement "contrefaire" facilement son adresse IP et son adresse MAC.
Sur Internet, contrefaire son adresse IP est nettement plus difficile, du moins en TCP, car il faut que les paquets puissent trouver leur chemin du serveur vers les clients. Quant au filtrage par adresse MAC, il n'a pas vraiment de sens : de toute façon, le serveur ne voit que l'adresse MAC du routeur auquel il est directement connecté.
Un VPN SSL ?
Ça peut être une solution, effectivement.
Quel hébergeur proposerait cette solution pour un site tournant en ASP avec SQL Server ?
Sous Linux, ce serait trivial : tu prends un serveur dédié (une Dedibox coûte 15 EUR/mois) ou un VPS, et tu y installes OpenVPN. Bien sûr, le serveur web ne doit écouter que sur l'interface réseau VPN, et pas sur les interfaces physiques. Avec du Microsoft, ça doit être possible aussi (OpenVPN fonctionne sous Windows), mais faut payer les licences en plus.
Nicolas George
"DaVinche" , dans le message <4e9158b4$0$591$, a écrit :
Un VPN SSL ?
Faire un VPN avec un protocole de flux est une très mauvaise idée car les délais de retransmission du protocole de flux sous le VPN et ceux à l'intérieur du VPN vont interagir de manière catastrophique.
"DaVinche" , dans le message <4e9158b4$0$591$426a74cc@news.free.fr>, a
écrit :
Un VPN SSL ?
Faire un VPN avec un protocole de flux est une très mauvaise idée car les
délais de retransmission du protocole de flux sous le VPN et ceux à
l'intérieur du VPN vont interagir de manière catastrophique.
"DaVinche" , dans le message <4e9158b4$0$591$, a écrit :
Un VPN SSL ?
Faire un VPN avec un protocole de flux est une très mauvaise idée car les délais de retransmission du protocole de flux sous le VPN et ceux à l'intérieur du VPN vont interagir de manière catastrophique.
Nicolas George
Fabien LE LEZ , dans le message , a écrit :
du moins en TCP, car il faut que les paquets puissent trouver leur chemin du serveur vers les clients.
On peut espérer que les opérateurs réseaux sérieux jettent les paquets dont l'adresse source est clairement incompatible avec l'origine.
Fabien LE LEZ , dans le message
<fus297dj7grp0dbtqsuverog87snaf9s3k@4ax.com>, a écrit :
du moins en TCP, car il faut que les paquets puissent trouver leur
chemin du serveur vers les clients.
On peut espérer que les opérateurs réseaux sérieux jettent les paquets dont
l'adresse source est clairement incompatible avec l'origine.
du moins en TCP, car il faut que les paquets puissent trouver leur chemin du serveur vers les clients.
On peut espérer que les opérateurs réseaux sérieux jettent les paquets dont l'adresse source est clairement incompatible avec l'origine.
Stéphane Catteau
Nicolas George devait dire quelque chose comme ceci :
du moins en TCP, car il faut que les paquets puissent trouver leur chemin du serveur vers les clients.
On peut espérer que les opérateurs réseaux sérieux jettent les paquets dont l'adresse source est clairement incompatible avec l'origine.
Ce n'est évidement pas aussi trivial que cela semble l'être sur le papier, mais il suffit de compromettre le bon routeur pour régler ce problème. Soit celui en bordure du réseau dont l'on veut usurper une adresse IP, soit celui en bordure du réseau attaqué. Un petit tunnel pour faire le lien entre la machine de l'attaquant et le routeur, et voilà l'adresse IP usurpée et les paquets qui transitent tranquillement sur le réseau. Comme l'a dit Fabien Le lez, c'est "nettement plus difficile", autrement dit ce n'est pas impossible pour autant.
Après c'est comme tout le reste, un juste équilibre entre les risques encourus, les mesures mises en oeuvre pour les éviter et les mesures à mettre en oeuvre pour les contourner. Si l'accès au site doit être ultra-limité parce qu'il s'agit d'une béta du nouveau concept de la mort qui tue qui va révolutionner le réseau, un filtrage sur l'adresse IP suffit. Le risque en cas de fuite est mitigé, les mesures à prendre pour l'éviter assez simple et les mesures à prendre pour contourner les sécurités demande une réelle volonté d'y arriver ainsi que de vraiment bonnes compétences. Par contre, si l'accès au site doit être ultra-limité parce qu'il s'agit de données hyper méga sensibles, il en va autrement. En effet, dans ce cas le risque en cas de fuite est très élevé et, *en comparaison*, les mesures à prendre pour usurper l'adresse IP deviennent triviales.
-- 17/06/1969 - 18/01/2011
Repose en paix mon amour :'(
Nicolas George devait dire quelque chose comme ceci :
du moins en TCP, car il faut que les paquets puissent trouver leur
chemin du serveur vers les clients.
On peut espérer que les opérateurs réseaux sérieux jettent les paquets dont
l'adresse source est clairement incompatible avec l'origine.
Ce n'est évidement pas aussi trivial que cela semble l'être sur le
papier, mais il suffit de compromettre le bon routeur pour régler ce
problème. Soit celui en bordure du réseau dont l'on veut usurper une
adresse IP, soit celui en bordure du réseau attaqué. Un petit tunnel
pour faire le lien entre la machine de l'attaquant et le routeur, et
voilà l'adresse IP usurpée et les paquets qui transitent tranquillement
sur le réseau.
Comme l'a dit Fabien Le lez, c'est "nettement plus difficile",
autrement dit ce n'est pas impossible pour autant.
Après c'est comme tout le reste, un juste équilibre entre les risques
encourus, les mesures mises en oeuvre pour les éviter et les mesures à
mettre en oeuvre pour les contourner.
Si l'accès au site doit être ultra-limité parce qu'il s'agit d'une
béta du nouveau concept de la mort qui tue qui va révolutionner le
réseau, un filtrage sur l'adresse IP suffit. Le risque en cas de fuite
est mitigé, les mesures à prendre pour l'éviter assez simple et les
mesures à prendre pour contourner les sécurités demande une réelle
volonté d'y arriver ainsi que de vraiment bonnes compétences.
Par contre, si l'accès au site doit être ultra-limité parce qu'il
s'agit de données hyper méga sensibles, il en va autrement. En effet,
dans ce cas le risque en cas de fuite est très élevé et, *en
comparaison*, les mesures à prendre pour usurper l'adresse IP
deviennent triviales.
Nicolas George devait dire quelque chose comme ceci :
du moins en TCP, car il faut que les paquets puissent trouver leur chemin du serveur vers les clients.
On peut espérer que les opérateurs réseaux sérieux jettent les paquets dont l'adresse source est clairement incompatible avec l'origine.
Ce n'est évidement pas aussi trivial que cela semble l'être sur le papier, mais il suffit de compromettre le bon routeur pour régler ce problème. Soit celui en bordure du réseau dont l'on veut usurper une adresse IP, soit celui en bordure du réseau attaqué. Un petit tunnel pour faire le lien entre la machine de l'attaquant et le routeur, et voilà l'adresse IP usurpée et les paquets qui transitent tranquillement sur le réseau. Comme l'a dit Fabien Le lez, c'est "nettement plus difficile", autrement dit ce n'est pas impossible pour autant.
Après c'est comme tout le reste, un juste équilibre entre les risques encourus, les mesures mises en oeuvre pour les éviter et les mesures à mettre en oeuvre pour les contourner. Si l'accès au site doit être ultra-limité parce qu'il s'agit d'une béta du nouveau concept de la mort qui tue qui va révolutionner le réseau, un filtrage sur l'adresse IP suffit. Le risque en cas de fuite est mitigé, les mesures à prendre pour l'éviter assez simple et les mesures à prendre pour contourner les sécurités demande une réelle volonté d'y arriver ainsi que de vraiment bonnes compétences. Par contre, si l'accès au site doit être ultra-limité parce qu'il s'agit de données hyper méga sensibles, il en va autrement. En effet, dans ce cas le risque en cas de fuite est très élevé et, *en comparaison*, les mesures à prendre pour usurper l'adresse IP deviennent triviales.
-- 17/06/1969 - 18/01/2011
Repose en paix mon amour :'(
Aéris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Le 09/10/2011 10:17, DaVinche a écrit :
tr�s s�r,
… snip …
un site tournant en ASP avec SQL Server
Y'a des jours comme ça où on rigole bien en lisant les NG =)
- -- Aeris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
On 09 Oct 2011 10:47:26 GMT, Nicolas George <nicolas$:
Un VPN SSL ?
Faire un VPN avec un protocole de flux
De quel "protocole de flux" parles-tu ? Si je ne m'abuse, OpenVPN utilise SSL/TLS, et fonctionne en UDP.
Ascadix
DaVinche a exposé le 09/10/2011 :
Bonjour,
Le problème serait même plutot :
N'autoriser que deux ordinateurs à accéder à un site "web"
L'accès doit être pour le moment ultra-limité et très sûr, or je pense que les solutions de filtrage par adresse IP sont contournables, de même que que les solutions de filtrage par adresse MAC.
Un VPN SSL ? Quel hébergeur proposerait cette solution pour un site tournant en ASP avec SQL Server ?
Merci de vos réponses, observations, suggestions, questions, réflexions ...................
DaVinche
Tu peux pas plutot enviseager d'authentifier au niveau utilisateur que "par IP / PC " ?
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
DaVinche a exposé le 09/10/2011 :
Bonjour,
Le problème serait même plutot :
N'autoriser que deux ordinateurs à accéder à un site "web"
L'accès doit être pour le moment ultra-limité et très sûr, or je pense que
les solutions de filtrage par adresse IP sont contournables, de même que que
les solutions de filtrage par adresse MAC.
Un VPN SSL ? Quel hébergeur proposerait cette solution pour un site tournant
en ASP avec SQL Server ?
Merci de vos réponses, observations, suggestions, questions, réflexions
...................
DaVinche
Tu peux pas plutot enviseager d'authentifier au niveau utilisateur que
"par IP / PC " ?
--
@+
Ascadix
adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça
arrive.
N'autoriser que deux ordinateurs à accéder à un site "web"
L'accès doit être pour le moment ultra-limité et très sûr, or je pense que les solutions de filtrage par adresse IP sont contournables, de même que que les solutions de filtrage par adresse MAC.
Un VPN SSL ? Quel hébergeur proposerait cette solution pour un site tournant en ASP avec SQL Server ?
Merci de vos réponses, observations, suggestions, questions, réflexions ...................
DaVinche
Tu peux pas plutot enviseager d'authentifier au niveau utilisateur que "par IP / PC " ?
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
Nicolas George
Fabien LE LEZ , dans le message , a écrit :
De quel "protocole de flux" parles-tu ?
TLS :
Client message boundaries are not preserved in the record layer (i.e., multiple client messages of the same ContentType MAY be coalesced into a single TLSPlaintext record, or a single message MAY be fragmented across several records).
Ça dit bien que c'est un protocole de flux. Et aussi dans l'introduction :
At the lowest level, layered on top of some reliable transport protocol (e.g., TCP [TCP]), is the TLS Record Protocol.
Donc TLS fonctionne par dessus un protocole de flux.
Si je ne m'abuse, OpenVPN utilise SSL/TLS, et fonctionne en UDP.
OpenVPN utilise la même crypto que TLS, et peut-être des formats de paquets très similaires, mais ce n'est pas le protocole lui-même.
Fabien LE LEZ , dans le message
<6d5397de34nhbcpe6ena4t7c50979qenbm@4ax.com>, a écrit :
De quel "protocole de flux" parles-tu ?
TLS :
Client
message boundaries are not preserved in the record layer (i.e.,
multiple client messages of the same ContentType MAY be coalesced
into a single TLSPlaintext record, or a single message MAY be
fragmented across several records).
Ça dit bien que c'est un protocole de flux. Et aussi dans l'introduction :
At the lowest level, layered on top of some reliable
transport protocol (e.g., TCP [TCP]), is the TLS Record Protocol.
Donc TLS fonctionne par dessus un protocole de flux.
Si je ne m'abuse, OpenVPN
utilise SSL/TLS, et fonctionne en UDP.
OpenVPN utilise la même crypto que TLS, et peut-être des formats de paquets
très similaires, mais ce n'est pas le protocole lui-même.
Client message boundaries are not preserved in the record layer (i.e., multiple client messages of the same ContentType MAY be coalesced into a single TLSPlaintext record, or a single message MAY be fragmented across several records).
Ça dit bien que c'est un protocole de flux. Et aussi dans l'introduction :
At the lowest level, layered on top of some reliable transport protocol (e.g., TCP [TCP]), is the TLS Record Protocol.
Donc TLS fonctionne par dessus un protocole de flux.
Si je ne m'abuse, OpenVPN utilise SSL/TLS, et fonctionne en UDP.
OpenVPN utilise la même crypto que TLS, et peut-être des formats de paquets très similaires, mais ce n'est pas le protocole lui-même.
Bruno Tréguier
Le 09/10/2011 à 15:42, Nicolas George a écrit :
TLS :
Client message boundaries are not preserved in the record layer (i.e., multiple client messages of the same ContentType MAY be coalesced into a single TLSPlaintext record, or a single message MAY be fragmented across several records).
Ça dit bien que c'est un protocole de flux. Et aussi dans l'introduction :
At the lowest level, layered on top of some reliable transport protocol (e.g., TCP [TCP]), is the TLS Record Protocol.
Donc TLS fonctionne par dessus un protocole de flux.
Bonjour,
Il en existe une version UDP nommée DTLS (voir http://tools.ietf.org/html/rfc4347), que le client VPN AnyConnect de Cisco utilise et qui est également implémentée dans OpenSSL depuis la version 0.9.8 (mais là je ne connais pas d'outil l'utilisant).
Il est vrai que l'empilage de 2 couches TCP (ou plus) peut être problématique si la liaison est pourrie, à cause de l'interaction entre les mécanismes de retransmission, mais dans la pratique, ça ne fonctionne pas trop mal dans beaucoup de cas... J'ai eu il y a quelques années un lien à monter "à l'arrache", j'ai utilisé les canaux SSH pour cela, mais le principe est le même: 2 couches TCP empilées. Et je n'ai jamais eu aucun souci pendant les quelques mois où cela a dû être en place. J'ai eu l'occasion de refaire ça à plusieurs reprises, toujours sans aucun problème (même si, je le sais, c'est "mal").
Je serais donc tenté de penser que pour l'utilisation qui est prévue ici, ça doit suffire.
Cela étant dit, un système d'autorisation basé sur IP + login/mot de passe (avec du HTTPS histoire que ça ne passe pas en clair) ne doit pas être mal non plus...
Cordialement,
-- Bruno Tréguier
Le 09/10/2011 à 15:42, Nicolas George a écrit :
TLS :
Client
message boundaries are not preserved in the record layer (i.e.,
multiple client messages of the same ContentType MAY be coalesced
into a single TLSPlaintext record, or a single message MAY be
fragmented across several records).
Ça dit bien que c'est un protocole de flux. Et aussi dans l'introduction :
At the lowest level, layered on top of some reliable
transport protocol (e.g., TCP [TCP]), is the TLS Record Protocol.
Donc TLS fonctionne par dessus un protocole de flux.
Bonjour,
Il en existe une version UDP nommée DTLS (voir
http://tools.ietf.org/html/rfc4347), que le client VPN AnyConnect de
Cisco utilise et qui est également implémentée dans OpenSSL depuis la
version 0.9.8 (mais là je ne connais pas d'outil l'utilisant).
Il est vrai que l'empilage de 2 couches TCP (ou plus) peut être
problématique si la liaison est pourrie, à cause de l'interaction entre
les mécanismes de retransmission, mais dans la pratique, ça ne
fonctionne pas trop mal dans beaucoup de cas... J'ai eu il y a quelques
années un lien à monter "à l'arrache", j'ai utilisé les canaux SSH pour
cela, mais le principe est le même: 2 couches TCP empilées. Et je n'ai
jamais eu aucun souci pendant les quelques mois où cela a dû être en
place. J'ai eu l'occasion de refaire ça à plusieurs reprises, toujours
sans aucun problème (même si, je le sais, c'est "mal").
Je serais donc tenté de penser que pour l'utilisation qui est prévue
ici, ça doit suffire.
Cela étant dit, un système d'autorisation basé sur IP + login/mot de
passe (avec du HTTPS histoire que ça ne passe pas en clair) ne doit pas
être mal non plus...
Client message boundaries are not preserved in the record layer (i.e., multiple client messages of the same ContentType MAY be coalesced into a single TLSPlaintext record, or a single message MAY be fragmented across several records).
Ça dit bien que c'est un protocole de flux. Et aussi dans l'introduction :
At the lowest level, layered on top of some reliable transport protocol (e.g., TCP [TCP]), is the TLS Record Protocol.
Donc TLS fonctionne par dessus un protocole de flux.
Bonjour,
Il en existe une version UDP nommée DTLS (voir http://tools.ietf.org/html/rfc4347), que le client VPN AnyConnect de Cisco utilise et qui est également implémentée dans OpenSSL depuis la version 0.9.8 (mais là je ne connais pas d'outil l'utilisant).
Il est vrai que l'empilage de 2 couches TCP (ou plus) peut être problématique si la liaison est pourrie, à cause de l'interaction entre les mécanismes de retransmission, mais dans la pratique, ça ne fonctionne pas trop mal dans beaucoup de cas... J'ai eu il y a quelques années un lien à monter "à l'arrache", j'ai utilisé les canaux SSH pour cela, mais le principe est le même: 2 couches TCP empilées. Et je n'ai jamais eu aucun souci pendant les quelques mois où cela a dû être en place. J'ai eu l'occasion de refaire ça à plusieurs reprises, toujours sans aucun problème (même si, je le sais, c'est "mal").
Je serais donc tenté de penser que pour l'utilisation qui est prévue ici, ça doit suffire.
Cela étant dit, un système d'autorisation basé sur IP + login/mot de passe (avec du HTTPS histoire que ça ne passe pas en clair) ne doit pas être mal non plus...
Cordialement,
-- Bruno Tréguier
Gloops
DaVinche a écrit, le 09/10/2011 10:17 :
Bonjour,
Le problème serait même plutot :
N'autoriser que deux ordinateurs à accéder à un site "web"
L'accès doit être pour le moment ultra-limité et très sûr, or je pense que les solutions de filtrage par adresse IP sont contournables, de même que que les solutions de filtrage par adresse MAC.
Un VPN SSL ? Quel hébergeur proposerait cette solution pour un site t ournant en ASP avec SQL Server ?
Ce n'est pas tellement à l'hébergeur de proposer une solution, c'est plutôt au code de la page de réaliser le traitement. Ou bien tu parla is d'un site de blog tout prêt ?
On peut connaître l'adresse du lecteur et lui afficher un contenu en conséquence, mais comme dit Stéphane c'est plus dur de s'assurer qu'e lle n'est pas contrefaite.
DaVinche a écrit, le 09/10/2011 10:17 :
Bonjour,
Le problème serait même plutot :
N'autoriser que deux ordinateurs à accéder à un site "web"
L'accès doit être pour le moment ultra-limité et très sûr, or je pense que
les solutions de filtrage par adresse IP sont contournables, de même que que
les solutions de filtrage par adresse MAC.
Un VPN SSL ? Quel hébergeur proposerait cette solution pour un site t ournant
en ASP avec SQL Server ?
Ce n'est pas tellement à l'hébergeur de proposer une solution, c'est
plutôt au code de la page de réaliser le traitement. Ou bien tu parla is
d'un site de blog tout prêt ?
On peut connaître l'adresse du lecteur et lui afficher un contenu en
conséquence, mais comme dit Stéphane c'est plus dur de s'assurer qu'e lle
n'est pas contrefaite.
N'autoriser que deux ordinateurs à accéder à un site "web"
L'accès doit être pour le moment ultra-limité et très sûr, or je pense que les solutions de filtrage par adresse IP sont contournables, de même que que les solutions de filtrage par adresse MAC.
Un VPN SSL ? Quel hébergeur proposerait cette solution pour un site t ournant en ASP avec SQL Server ?
Ce n'est pas tellement à l'hébergeur de proposer une solution, c'est plutôt au code de la page de réaliser le traitement. Ou bien tu parla is d'un site de blog tout prêt ?
On peut connaître l'adresse du lecteur et lui afficher un contenu en conséquence, mais comme dit Stéphane c'est plus dur de s'assurer qu'e lle n'est pas contrefaite.
