On a toute de suite inscriminer une faille de windows mais après réflection,
la faille ne serait elle pas humaine ?
En effet tous ces purs vers utilisent les ports du reseau local comme par
exemple le 445/TCP [SMB]. Pourquoi diable avoir ces ports ouverts
(445,137,138/UDP,139TCP...) ?
si quelqu'un a une explication...
Mais faut pas tout fermer non plus !!
Moi je ne peux plus acceder à un site https à partir de mon serveur car la
Fac a fermé le port 443 hi hi hi
je ne peux pas me synchroniser à une source de temps car le port 123 est
fermé. ha ha ha
pourquoi tant d'admin réseaux ferment tant de port en sortie ??? en entrée, je comprends, mais en sortie ...
Principalement :
- Pasque si tu choppes un troyen et que les ports sont ouverts t'es mort, tandis que si il sont fermés tu peux souffler un peu.
- Pasque trop d'utilisateurs font n'importe quoi sur le réseau et que le responsable en cas de pépin, c'est l'admin.
GuiGui
On a toute de suite inscriminer une faille de windows mais après réflection, la faille ne serait elle pas humaine ?
En effet tous ces purs vers utilisent les ports du reseau local comme par exemple le 445/TCP [SMB]. Pourquoi diable avoir ces ports ouverts (445,137,138/UDP,139TCP...) ?
si quelqu'un a une explication...
137, 138, 139 : Netbios sur ip donc indispensables au client microsoft donc ouverts par défaut depuis windows 95
445 : smb natif sur ip, idem, apparu avec windows 2000.
Mais faut pas tout fermer non plus !!
Moi je ne peux plus acceder à un site https à partir de mon serveur car la Fac a fermé le port 443 hi hi hi
Chez nous aussi, mais il suffit de passer par le proxy qui, lui, a le droit de sortir.
je ne peux pas me synchroniser à une source de temps car le port 123 est fermé. ha ha ha
chez nous aussi, mais il y a une source de temps locale qui, elle, a le droit de communiquer avec l'extérieur.
On a toute de suite inscriminer une faille de windows mais après réflection,
la faille ne serait elle pas humaine ?
En effet tous ces purs vers utilisent les ports du reseau local comme par
exemple le 445/TCP [SMB]. Pourquoi diable avoir ces ports ouverts
(445,137,138/UDP,139TCP...) ?
si quelqu'un a une explication...
137, 138, 139 : Netbios sur ip donc indispensables au client microsoft
donc ouverts par défaut depuis windows 95
445 : smb natif sur ip, idem, apparu avec windows 2000.
Mais faut pas tout fermer non plus !!
Moi je ne peux plus acceder à un site https à partir de mon serveur car la
Fac a fermé le port 443 hi hi hi
Chez nous aussi, mais il suffit de passer par le proxy qui, lui, a le
droit de sortir.
je ne peux pas me synchroniser à une source de temps car le port 123 est
fermé. ha ha ha
chez nous aussi, mais il y a une source de temps locale qui, elle, a le
droit de communiquer avec l'extérieur.
On a toute de suite inscriminer une faille de windows mais après réflection, la faille ne serait elle pas humaine ?
En effet tous ces purs vers utilisent les ports du reseau local comme par exemple le 445/TCP [SMB]. Pourquoi diable avoir ces ports ouverts (445,137,138/UDP,139TCP...) ?
si quelqu'un a une explication...
137, 138, 139 : Netbios sur ip donc indispensables au client microsoft donc ouverts par défaut depuis windows 95
445 : smb natif sur ip, idem, apparu avec windows 2000.
Mais faut pas tout fermer non plus !!
Moi je ne peux plus acceder à un site https à partir de mon serveur car la Fac a fermé le port 443 hi hi hi
Chez nous aussi, mais il suffit de passer par le proxy qui, lui, a le droit de sortir.
je ne peux pas me synchroniser à une source de temps car le port 123 est fermé. ha ha ha
chez nous aussi, mais il y a une source de temps locale qui, elle, a le droit de communiquer avec l'extérieur.
Guillaume Gielly
pourquoi tant d'admin réseaux ferment tant de port en sortie ??? en entrée, je comprends, mais en sortie ...
Principalement :
- Pasque si tu choppes un troyen et que les ports sont ouverts t'es mort, tandis que si il sont fermés tu peux souffler un peu.
- Pasque trop d'utilisateurs font n'importe quoi sur le réseau et que le responsable en cas de pépin, c'est l'admin.
Ca permet à l'admin qui a la flemme, de ne pas s'embeter : politique du 'je-ferme-tout-je-suis-penard-au-moins', comme ça t'es sur que tes utilisateurs ils vont pas sur leur popd, ntpd, ircd, httpsd, icqd et j'en passe...
Bref. Bloquer, oui, tout non.
Après bien souvent, tout traffic est bloqué en sortie, mais en LAN tout est accessible (DMZ?) de partout, donc c'est pas forcément mieux, voir pire que tout : une fois dedans, le hax0r il transforme le LAN en Beyrouth.
Mais ça, c'est un autre problème...
-- Guillaume Gielly
pourquoi tant d'admin réseaux ferment tant de port en sortie ???
en entrée, je comprends, mais en sortie ...
Principalement :
- Pasque si tu choppes un troyen et que les ports sont ouverts t'es
mort, tandis que si il sont fermés tu peux souffler un peu.
- Pasque trop d'utilisateurs font n'importe quoi sur le réseau et que le
responsable en cas de pépin, c'est l'admin.
Ca permet à l'admin qui a la flemme, de ne pas s'embeter : politique du
'je-ferme-tout-je-suis-penard-au-moins', comme ça t'es sur que tes
utilisateurs ils vont pas sur leur popd, ntpd, ircd, httpsd, icqd et
j'en passe...
Bref. Bloquer, oui, tout non.
Après bien souvent, tout traffic est bloqué en sortie, mais en LAN tout
est accessible (DMZ?) de partout, donc c'est pas forcément mieux, voir
pire que tout : une fois dedans, le hax0r il transforme le LAN en Beyrouth.
pourquoi tant d'admin réseaux ferment tant de port en sortie ??? en entrée, je comprends, mais en sortie ...
Principalement :
- Pasque si tu choppes un troyen et que les ports sont ouverts t'es mort, tandis que si il sont fermés tu peux souffler un peu.
- Pasque trop d'utilisateurs font n'importe quoi sur le réseau et que le responsable en cas de pépin, c'est l'admin.
Ca permet à l'admin qui a la flemme, de ne pas s'embeter : politique du 'je-ferme-tout-je-suis-penard-au-moins', comme ça t'es sur que tes utilisateurs ils vont pas sur leur popd, ntpd, ircd, httpsd, icqd et j'en passe...
Bref. Bloquer, oui, tout non.
Après bien souvent, tout traffic est bloqué en sortie, mais en LAN tout est accessible (DMZ?) de partout, donc c'est pas forcément mieux, voir pire que tout : une fois dedans, le hax0r il transforme le LAN en Beyrouth.
Mais ça, c'est un autre problème...
-- Guillaume Gielly
Fabien LE LEZ
On Tue, 18 May 2004 18:09:37 +0200, "kenny g." <eo%%@;.{}> wrote:
En effet tous ces purs vers utilisent les ports du reseau local comme par exemple le 445/TCP [SMB]. Pourquoi diable avoir ces ports ouverts (445,137,138/UDP,139TCP...) ?
Le principe de Windows, c'est que tout doit fonctionner sans que l'utilisateur n'ait à comprendre. Donc, tout est ouvert en permanence. De nos jours, un firewall est indispensable même si tu n'as qu'une connexion 56K :-(
-- ;-) FLL, Epagneul Breton
On Tue, 18 May 2004 18:09:37 +0200, "kenny g." <eo%%@;.{}> wrote:
En effet tous ces purs vers utilisent les ports du reseau local comme par
exemple le 445/TCP [SMB]. Pourquoi diable avoir ces ports ouverts
(445,137,138/UDP,139TCP...) ?
Le principe de Windows, c'est que tout doit fonctionner sans que
l'utilisateur n'ait à comprendre. Donc, tout est ouvert en permanence.
De nos jours, un firewall est indispensable même si tu n'as qu'une
connexion 56K :-(
On Tue, 18 May 2004 18:09:37 +0200, "kenny g." <eo%%@;.{}> wrote:
En effet tous ces purs vers utilisent les ports du reseau local comme par exemple le 445/TCP [SMB]. Pourquoi diable avoir ces ports ouverts (445,137,138/UDP,139TCP...) ?
Le principe de Windows, c'est que tout doit fonctionner sans que l'utilisateur n'ait à comprendre. Donc, tout est ouvert en permanence. De nos jours, un firewall est indispensable même si tu n'as qu'une connexion 56K :-(
-- ;-) FLL, Epagneul Breton
RAKOTOMALALA Renaud
Ca permet à l'admin qui a la flemme, de ne pas s'embeter : politique du 'je-ferme-tout-je-suis-penard-au-moins', comme ça t'es sur que tes utilisateurs ils vont pas sur leur popd, ntpd, ircd, httpsd, icqd et j'en passe...
Bref. Bloquer, oui, tout non.
Faut pour bloquer tous les ports de sortie ?
1er car on sait que des petits malin detourne l'utilisation des ports standards de leur utilisation
cas 1: l'utilisateur lambda trouve que son admin est con (ca arrive tout le temps), et celui-ci possède un serveur à l'exterieur. Pour avoir la paix il etablie une laision VPN entre sa machine dans le lieux dit et son serveur à l'exterieur permettant de n'avoir aucune limitation.
Alors comme l'admin est vraiment méchant, il n'a laissé ouvert que les services qu'il considère comme sûr, entre autre 443,80,23,25,110...
Donc que fait le mec malin, il fait ecouté au serveur VPN sur un de ces ports et voilà il a accès à Internet librement ni une ni deux.
Problème la machine est exposé à tous les problème de securité, la machine devient à electron libre sur le réseau et pour le coups si un cracker rentre sur la machine il contorune toutes les sécurités ... Bravo.
cas 2: L'administrateur cette fois-ci ferme tous les ports sans exception. Ensuite on met en place ce que l'on appel des serveurs mandataires pour les services légaux (il ne faut pas oublier qu'il s'agit de reseau d'organisme et non particuliers) sur le réseau.
Celà permet quoi:
1. de s'assurer qu'il n'y a pas de detournement de l'utilisation d'un port standard (celà vaut aussi pour les trojan ...)
2. de se proteger dans une certaine mesure des failles applicatives, qui sont aussi des points d'entrés possible pour un pirate (faille ActiveX ...)
voilà pourquoi lorsque l'on se trouve dans un environnement à risque il est interessant de tout fermer. Alors denigrer une politique de sécurité sans savoir réellement pourquoi sont peut être des raisons suffisantes pour ce dire qu'il vaut mieux ne pas faire confiance à l'utilisateur.
Après bien souvent, tout traffic est bloqué en sortie, mais en LAN tout est accessible (DMZ?) de partout, donc c'est pas forcément mieux, voir pire que tout : une fois dedans, le hax0r il transforme le LAN en Beyrouth.
C'ets vrai dans beacoup de réseau qui ne sont pas sécurisé, et c'est une raison supplémentaire pour justement minimiser le risque d'intrusion sur le LAN
Ca permet à l'admin qui a la flemme, de ne pas s'embeter : politique du
'je-ferme-tout-je-suis-penard-au-moins', comme ça t'es sur que tes
utilisateurs ils vont pas sur leur popd, ntpd, ircd, httpsd, icqd et
j'en passe...
Bref. Bloquer, oui, tout non.
Faut pour bloquer tous les ports de sortie ?
1er car on sait que des petits malin detourne l'utilisation des ports
standards de leur utilisation
cas 1:
l'utilisateur lambda trouve que son admin est con (ca arrive tout le
temps), et celui-ci possède un serveur à l'exterieur.
Pour avoir la paix il etablie une laision VPN entre sa machine dans le
lieux dit et son serveur à l'exterieur permettant de n'avoir aucune
limitation.
Alors comme l'admin est vraiment méchant, il n'a laissé ouvert que les
services qu'il considère comme sûr, entre autre 443,80,23,25,110...
Donc que fait le mec malin, il fait ecouté au serveur VPN sur un de ces
ports et voilà il a accès à Internet librement ni une ni deux.
Problème la machine est exposé à tous les problème de securité, la
machine devient à electron libre sur le réseau et pour le coups si un
cracker rentre sur la machine il contorune toutes les sécurités ... Bravo.
cas 2:
L'administrateur cette fois-ci ferme tous les ports sans exception.
Ensuite on met en place ce que l'on appel des serveurs mandataires pour
les services légaux (il ne faut pas oublier qu'il s'agit de reseau
d'organisme et non particuliers) sur le réseau.
Celà permet quoi:
1. de s'assurer qu'il n'y a pas de detournement de l'utilisation d'un
port standard (celà vaut aussi pour les trojan ...)
2. de se proteger dans une certaine mesure des failles applicatives, qui
sont aussi des points d'entrés possible pour un pirate (faille ActiveX ...)
voilà pourquoi lorsque l'on se trouve dans un environnement à risque il
est interessant de tout fermer. Alors denigrer une politique de sécurité
sans savoir réellement pourquoi sont peut être des raisons suffisantes
pour ce dire qu'il vaut mieux ne pas faire confiance à l'utilisateur.
Après bien souvent, tout traffic est bloqué en sortie, mais en LAN tout
est accessible (DMZ?) de partout, donc c'est pas forcément mieux, voir
pire que tout : une fois dedans, le hax0r il transforme le LAN en Beyrouth.
C'ets vrai dans beacoup de réseau qui ne sont pas sécurisé, et c'est une
raison supplémentaire pour justement minimiser le risque d'intrusion sur
le LAN
Ca permet à l'admin qui a la flemme, de ne pas s'embeter : politique du 'je-ferme-tout-je-suis-penard-au-moins', comme ça t'es sur que tes utilisateurs ils vont pas sur leur popd, ntpd, ircd, httpsd, icqd et j'en passe...
Bref. Bloquer, oui, tout non.
Faut pour bloquer tous les ports de sortie ?
1er car on sait que des petits malin detourne l'utilisation des ports standards de leur utilisation
cas 1: l'utilisateur lambda trouve que son admin est con (ca arrive tout le temps), et celui-ci possède un serveur à l'exterieur. Pour avoir la paix il etablie une laision VPN entre sa machine dans le lieux dit et son serveur à l'exterieur permettant de n'avoir aucune limitation.
Alors comme l'admin est vraiment méchant, il n'a laissé ouvert que les services qu'il considère comme sûr, entre autre 443,80,23,25,110...
Donc que fait le mec malin, il fait ecouté au serveur VPN sur un de ces ports et voilà il a accès à Internet librement ni une ni deux.
Problème la machine est exposé à tous les problème de securité, la machine devient à electron libre sur le réseau et pour le coups si un cracker rentre sur la machine il contorune toutes les sécurités ... Bravo.
cas 2: L'administrateur cette fois-ci ferme tous les ports sans exception. Ensuite on met en place ce que l'on appel des serveurs mandataires pour les services légaux (il ne faut pas oublier qu'il s'agit de reseau d'organisme et non particuliers) sur le réseau.
Celà permet quoi:
1. de s'assurer qu'il n'y a pas de detournement de l'utilisation d'un port standard (celà vaut aussi pour les trojan ...)
2. de se proteger dans une certaine mesure des failles applicatives, qui sont aussi des points d'entrés possible pour un pirate (faille ActiveX ...)
voilà pourquoi lorsque l'on se trouve dans un environnement à risque il est interessant de tout fermer. Alors denigrer une politique de sécurité sans savoir réellement pourquoi sont peut être des raisons suffisantes pour ce dire qu'il vaut mieux ne pas faire confiance à l'utilisateur.
Après bien souvent, tout traffic est bloqué en sortie, mais en LAN tout est accessible (DMZ?) de partout, donc c'est pas forcément mieux, voir pire que tout : une fois dedans, le hax0r il transforme le LAN en Beyrouth.
C'ets vrai dans beacoup de réseau qui ne sont pas sécurisé, et c'est une raison supplémentaire pour justement minimiser le risque d'intrusion sur le LAN
On Tue, 18 May 2004 22:53:34 +0200, RAKOTOMALALA Renaud <renaud+ wrote:
voilà pourquoi lorsque l'on se trouve dans un environnement à risque il est interessant de tout fermer.
Par contre, plus on ferme et plus l'administrateur doit être disponible. Si je tente d'expédier un fichier à un client ou un fournisseur par FTP, et que je me retrouve à lui expédier un CD-ROM parce que tout était bloqué et que l'admin avait autre chose à faire, la perte (en productivité) est plus importante que le gain (en sécurité).
-- ;-) FLL, Epagneul Breton
On Tue, 18 May 2004 22:53:34 +0200, RAKOTOMALALA Renaud
<renaud+news@w-consulting.fr> wrote:
voilà pourquoi lorsque l'on se trouve dans un environnement à risque il
est interessant de tout fermer.
Par contre, plus on ferme et plus l'administrateur doit être
disponible. Si je tente d'expédier un fichier à un client ou un
fournisseur par FTP, et que je me retrouve à lui expédier un CD-ROM
parce que tout était bloqué et que l'admin avait autre chose à faire,
la perte (en productivité) est plus importante que le gain (en
sécurité).
On Tue, 18 May 2004 22:53:34 +0200, RAKOTOMALALA Renaud <renaud+ wrote:
voilà pourquoi lorsque l'on se trouve dans un environnement à risque il est interessant de tout fermer.
Par contre, plus on ferme et plus l'administrateur doit être disponible. Si je tente d'expédier un fichier à un client ou un fournisseur par FTP, et que je me retrouve à lui expédier un CD-ROM parce que tout était bloqué et que l'admin avait autre chose à faire, la perte (en productivité) est plus importante que le gain (en sécurité).
-- ;-) FLL, Epagneul Breton
RAKOTOMALALA Renaud
On Tue, 18 May 2004 22:53:34 +0200, RAKOTOMALALA Renaud <renaud+ wrote:
Par contre, plus on ferme et plus l'administrateur doit être disponible. Si je tente d'expédier un fichier à un client ou un fournisseur par FTP, et que je me retrouve à lui expédier un CD-ROM parce que tout était bloqué et que l'admin avait autre chose à faire, la perte (en productivité) est plus importante que le gain (en sécurité).
C'est pour celà que l'on parle de politique de sécurité, à savoir connaitre les services légaux. Rien n'empeche de mettre le ou les fichiers à disposition via d'autres moyens.
Tel que un extranet par exemple ...
Bref le but de l'administrateur c'est être garant de part sa fonction de la sécurité (incluant securité des données, et disponibilités de celle-ci), et non celle de faciliter la vie des utilisateurs sans comprendre les besoins.
Si l'upload sur le ftp du client est vitale pour une raison X/Y et que celà n'a rien d'exeptionnel rien n'empeche de mettre un mandataire sécurisant l'echange. bref il n'y a rien qui remette en cause le raisonnement securitaire (certe) precedmeent développé.
Il y a une étude à faire, comme lorsqu'on développe une application on ne fait pas ça, sans connaitre le tenant et aboutissant de ce que l'on cherche à faire.
On Tue, 18 May 2004 22:53:34 +0200, RAKOTOMALALA Renaud
<renaud+news@w-consulting.fr> wrote:
Par contre, plus on ferme et plus l'administrateur doit être
disponible. Si je tente d'expédier un fichier à un client ou un
fournisseur par FTP, et que je me retrouve à lui expédier un CD-ROM
parce que tout était bloqué et que l'admin avait autre chose à faire,
la perte (en productivité) est plus importante que le gain (en
sécurité).
C'est pour celà que l'on parle de politique de sécurité, à savoir
connaitre les services légaux. Rien n'empeche de mettre le ou les
fichiers à disposition via d'autres moyens.
Tel que un extranet par exemple ...
Bref le but de l'administrateur c'est être garant de part sa fonction de
la sécurité (incluant securité des données, et disponibilités de
celle-ci), et non celle de faciliter la vie des utilisateurs sans
comprendre les besoins.
Si l'upload sur le ftp du client est vitale pour une raison X/Y et que
celà n'a rien d'exeptionnel rien n'empeche de mettre un mandataire
sécurisant l'echange. bref il n'y a rien qui remette en cause le
raisonnement securitaire (certe) precedmeent développé.
Il y a une étude à faire, comme lorsqu'on développe une application on
ne fait pas ça, sans connaitre le tenant et aboutissant de ce que l'on
cherche à faire.
On Tue, 18 May 2004 22:53:34 +0200, RAKOTOMALALA Renaud <renaud+ wrote:
Par contre, plus on ferme et plus l'administrateur doit être disponible. Si je tente d'expédier un fichier à un client ou un fournisseur par FTP, et que je me retrouve à lui expédier un CD-ROM parce que tout était bloqué et que l'admin avait autre chose à faire, la perte (en productivité) est plus importante que le gain (en sécurité).
C'est pour celà que l'on parle de politique de sécurité, à savoir connaitre les services légaux. Rien n'empeche de mettre le ou les fichiers à disposition via d'autres moyens.
Tel que un extranet par exemple ...
Bref le but de l'administrateur c'est être garant de part sa fonction de la sécurité (incluant securité des données, et disponibilités de celle-ci), et non celle de faciliter la vie des utilisateurs sans comprendre les besoins.
Si l'upload sur le ftp du client est vitale pour une raison X/Y et que celà n'a rien d'exeptionnel rien n'empeche de mettre un mandataire sécurisant l'echange. bref il n'y a rien qui remette en cause le raisonnement securitaire (certe) precedmeent développé.
Il y a une étude à faire, comme lorsqu'on développe une application on ne fait pas ça, sans connaitre le tenant et aboutissant de ce que l'on cherche à faire.
Problème la machine est exposé à tous les problème de securité, la machine devient à electron libre sur le réseau et pour le coups si un cracker rentre sur la machine il contorune toutes les sécurités ... Bravo.
Le cracker qui rentre dans la machine par le VPN en out, c'est sur TF1 ou dans les films.
Pour rentrer, il faut du tcp-in, or là on est sur de la sortie tcp (le out donc; tcp/udp peut importe également). Mais, vous allez me dire, et si c'est l'utilisateur qui par le biais de son VPN lance la connexion. Dans ce cas, l'utilisateur est pirate volontaire du réseau et complice, et veux tout saccager. Car dans l'idée, on va faire du point à point sur ce vpn vers un serveur distant. Donc il faudrait que le serveur VPN distant soit aussi compromis, qu'une machine tierce vienne se rajouter au serveur VPN et se connecte, etc etc..
</parano>
Sérieusement, je doute que ce scénario arrive, même si Murphy peut se glisser au milieu et que cela peut arriver oui, je ne nie pas ce fait.
Cela dit, trop de sécurité tue la sécurité, comme tu l'illustres avec le cas de l'utilisateur qui mets un VPN ou un socks5 chez lui (par exemple).
-- Guillaume Gielly
RAKOTOMALALA Renaud wrote:
Problème la machine est exposé à tous les problème de securité, la
machine devient à electron libre sur le réseau et pour le coups si un
cracker rentre sur la machine il contorune toutes les sécurités ... Bravo.
Le cracker qui rentre dans la machine par le VPN en out, c'est sur TF1
ou dans les films.
Pour rentrer, il faut du tcp-in, or là on est sur de la sortie tcp (le
out donc; tcp/udp peut importe également). Mais, vous allez me dire, et
si c'est l'utilisateur qui par le biais de son VPN lance la connexion.
Dans ce cas, l'utilisateur est pirate volontaire du réseau et complice,
et veux tout saccager. Car dans l'idée, on va faire du point à point sur
ce vpn vers un serveur distant. Donc il faudrait que le serveur VPN
distant soit aussi compromis, qu'une machine tierce vienne se rajouter
au serveur VPN et se connecte, etc etc..
</parano>
Sérieusement, je doute que ce scénario arrive, même si Murphy peut se
glisser au milieu et que cela peut arriver oui, je ne nie pas ce fait.
Cela dit, trop de sécurité tue la sécurité, comme tu l'illustres avec le
cas de l'utilisateur qui mets un VPN ou un socks5 chez lui (par exemple).
Problème la machine est exposé à tous les problème de securité, la machine devient à electron libre sur le réseau et pour le coups si un cracker rentre sur la machine il contorune toutes les sécurités ... Bravo.
Le cracker qui rentre dans la machine par le VPN en out, c'est sur TF1 ou dans les films.
Pour rentrer, il faut du tcp-in, or là on est sur de la sortie tcp (le out donc; tcp/udp peut importe également). Mais, vous allez me dire, et si c'est l'utilisateur qui par le biais de son VPN lance la connexion. Dans ce cas, l'utilisateur est pirate volontaire du réseau et complice, et veux tout saccager. Car dans l'idée, on va faire du point à point sur ce vpn vers un serveur distant. Donc il faudrait que le serveur VPN distant soit aussi compromis, qu'une machine tierce vienne se rajouter au serveur VPN et se connecte, etc etc..
</parano>
Sérieusement, je doute que ce scénario arrive, même si Murphy peut se glisser au milieu et que cela peut arriver oui, je ne nie pas ce fait.
Cela dit, trop de sécurité tue la sécurité, comme tu l'illustres avec le cas de l'utilisateur qui mets un VPN ou un socks5 chez lui (par exemple).
-- Guillaume Gielly
Fabien LE LEZ
On Wed, 19 May 2004 00:21:08 +0200, RAKOTOMALALA Renaud <renaud+ wrote:
Si l'upload sur le ftp du client est vitale pour une raison X/Y et que celà n'a rien d'exeptionnel rien n'empeche de mettre un mandataire sécurisant l'echange.
Généralement, personne n'est capable de prévoir à l'avance ce qui sera nécessaire. Plus une politique de sécurité est stricte, et plus les cas où l'administrateur devra "ouvrir" le bazar (= rajouter une possibilité de communication) seront fréquents -- d'où l'importance de la disponibilité de l'administrateur. Ou plutôt, _des_ administrateurs : si on a besoin d'une fonctionnalité non prévue (comme mon exemple de transfert de fichiers, ou n'importe quoi d'autre) et que le seul admin est en vacances pour un mois, on est dans la merde...
-- ;-) FLL, Epagneul Breton
On Wed, 19 May 2004 00:21:08 +0200, RAKOTOMALALA Renaud
<renaud+news@w-consulting.fr> wrote:
Si l'upload sur le ftp du client est vitale pour une raison X/Y et que
celà n'a rien d'exeptionnel rien n'empeche de mettre un mandataire
sécurisant l'echange.
Généralement, personne n'est capable de prévoir à l'avance ce
qui sera nécessaire. Plus une politique de sécurité est stricte, et
plus les cas où l'administrateur devra "ouvrir" le bazar (= rajouter
une possibilité de communication) seront fréquents -- d'où
l'importance de la disponibilité de l'administrateur. Ou plutôt, _des_
administrateurs : si on a besoin d'une fonctionnalité non prévue
(comme mon exemple de transfert de fichiers, ou n'importe quoi
d'autre) et que le seul admin est en vacances pour un mois, on est
dans la merde...
On Wed, 19 May 2004 00:21:08 +0200, RAKOTOMALALA Renaud <renaud+ wrote:
Si l'upload sur le ftp du client est vitale pour une raison X/Y et que celà n'a rien d'exeptionnel rien n'empeche de mettre un mandataire sécurisant l'echange.
Généralement, personne n'est capable de prévoir à l'avance ce qui sera nécessaire. Plus une politique de sécurité est stricte, et plus les cas où l'administrateur devra "ouvrir" le bazar (= rajouter une possibilité de communication) seront fréquents -- d'où l'importance de la disponibilité de l'administrateur. Ou plutôt, _des_ administrateurs : si on a besoin d'une fonctionnalité non prévue (comme mon exemple de transfert de fichiers, ou n'importe quoi d'autre) et que le seul admin est en vacances pour un mois, on est dans la merde...
