Je suis un n00b total en sécurité et c'est même pour cette raison que je
n'ai pas encore l'ADSL chez moi.
Je viens de faire un test sur hackercheck.com et il apparait que le port
22 est ouvert alors que ssh ne tourne pas.
Laisser ce port ouvert sans ssh derrière présente-t-il un risque ?
Si oui, comment fermer ce port ?
Si je passe à l'ADSL (faut vivre avec son temps) quelles règles de
sécurité adopter pour pour laisser tourner un ssh sur le port 22 en
limitant les risques ?
Config Debian Sarge 2.6.7 sur PC
Merci de toute aide (voir de tout RTFM, en français si possible)
--
> > Tu veux pas changer un peu de disque ? Ça devient lassant.
> 1) Je croyais que j'etais dans ta BL 2) Tu veux pas m'y remettre ?
> 3) Ca t'emmerde ? alors ca me fait plaisir.
-+- Bien configurer son kill-file (Le Retour...) -+-
Je viens de faire un test sur hackercheck.com et il apparait que le port 22 est ouvert alors que ssh ne tourne pas.
Si je ne m'abuse, dire qu'un port est ouvert signifie qu'une application écoute sur ce port. Si ce n'est pas ssh, c'est autre chose.
-- ;-)
Eric Razny
Bonsoir,
Je suis un n00b total en sécurité et c'est même pour cette raison que je n'ai pas encore l'ADSL chez moi.
Aie, mauvais départ, tu peux très bien te faire rooter en étant en rtc!
Je viens de faire un test sur hackercheck.com et il apparait que le port 22 est ouvert alors que ssh ne tourne pas.
Peut être pas ssh mais "quelque chose" si.
Laisser ce port ouvert sans ssh derrière présente-t-il un risque ? Si oui, comment fermer ce port ?
Voir plus bas.
Pour savoir ce qui tourne fait un petit netstat -ntap et tu verras... ssh! :)
(sauf si vraiment tu t'es fait hacker et que tu as un rootkit qui va bien par exemple.)
Si je passe à l'ADSL (faut vivre avec son temps) quelles règles de sécurité adopter pour pour laisser tourner un ssh sur le port 22 en limitant les risques ?
Lire ce qui a déjà été dit ici même.
Sinon impossible de te répondre pécisément si tu n'a aucune connaissance sur, disons au moins IP, TCP, UDP et un chouia d'ICMP [1](pour les autres ça peut attendre tes besoins!)
Pour ce qui est d'un PC connecté, bloque au moins les flux entrant que tu n'a pas initié
Config Debian Sarge 2.6.7 sur PC
Et a l'install tu as problablement sshd par défaut (accessoirement le 2.6.9 est la dernière version stable du kernel et depuis la 2.6.7 il y a quelques bugs chiants qui ont étés corrigés)
Merci de toute aide (voir de tout RTFM, en français si possible)
Là tu provoque! Ca va être un search the fucking web alors... :)
...un peu de formation sur les réseaux, IP, tout çaaa :)
Sérieusement, ça aide de *comprendre* ce qu'il se passe et d'un coup la sécurité te paraitra plus "simple" à mettre en oeuvre.
Nota : Linux est un Unix-like. Comme tout OS il a aussi ses pièges : mauvaises permission suid positionné où il ne faut pas etc.... Je vois trop souvent à mon gout des gens qui pense que "le réseau est tout". Certes si tu es seul sur ta machine et que personne ne passe ça va, mais si ta machine est partagée, ou si tu ouvre des comptes etc, il importe de se former un peu à l'OS <troll> sinon on se retrouve comme sous windows avec un clikodrome qu'on ne sait pas correctement utiliser</troll>
Eric.
[1] plus précisément tu semble ne pas vraiment savoir ce qu'est un port par exemple ; sinon tu n'imaginerais pas un "port ouvert sans rien derrière".
-- L'invulnérable : Je ne pense pas etre piratable, infectable par un trojen oui! Vu sur fcs un jour de mars 2004.
Bonsoir,
Je suis un n00b total en sécurité et c'est même pour cette raison que je
n'ai pas encore l'ADSL chez moi.
Aie, mauvais départ, tu peux très bien te faire rooter en étant en rtc!
Je viens de faire un test sur hackercheck.com et il apparait que le port
22 est ouvert alors que ssh ne tourne pas.
Peut être pas ssh mais "quelque chose" si.
Laisser ce port ouvert sans ssh derrière présente-t-il un risque ?
Si oui, comment fermer ce port ?
Voir plus bas.
Pour savoir ce qui tourne fait un petit netstat -ntap et tu verras...
ssh! :)
(sauf si vraiment tu t'es fait hacker et que tu as un rootkit qui va
bien par exemple.)
Si je passe à l'ADSL (faut vivre avec son temps) quelles règles de
sécurité adopter pour pour laisser tourner un ssh sur le port 22 en
limitant les risques ?
Lire ce qui a déjà été dit ici même.
Sinon impossible de te répondre pécisément si tu n'a aucune connaissance
sur, disons au moins IP, TCP, UDP et un chouia d'ICMP [1](pour les
autres ça peut attendre tes besoins!)
Pour ce qui est d'un PC connecté, bloque au moins les flux entrant que
tu n'a pas initié
Config Debian Sarge 2.6.7 sur PC
Et a l'install tu as problablement sshd par défaut (accessoirement le
2.6.9 est la dernière version stable du kernel et depuis la 2.6.7 il y a
quelques bugs chiants qui ont étés corrigés)
Merci de toute aide (voir de tout RTFM, en français si possible)
Là tu provoque! Ca va être un search the fucking web alors... :)
...un peu de formation sur les réseaux, IP, tout çaaa :)
Sérieusement, ça aide de *comprendre* ce qu'il se passe et d'un coup la
sécurité te paraitra plus "simple" à mettre en oeuvre.
Nota : Linux est un Unix-like. Comme tout OS il a aussi ses pièges :
mauvaises permission suid positionné où il ne faut pas etc....
Je vois trop souvent à mon gout des gens qui pense que "le réseau est
tout". Certes si tu es seul sur ta machine et que personne ne passe ça
va, mais si ta machine est partagée, ou si tu ouvre des comptes etc, il
importe de se former un peu à l'OS <troll> sinon on se retrouve comme
sous windows avec un clikodrome qu'on ne sait pas correctement
utiliser</troll>
Eric.
[1] plus précisément tu semble ne pas vraiment savoir ce qu'est un port
par exemple ; sinon tu n'imaginerais pas un "port ouvert sans rien
derrière".
--
L'invulnérable :
Je ne pense pas etre piratable, infectable par un trojen oui!
Vu sur fcs un jour de mars 2004.
Je suis un n00b total en sécurité et c'est même pour cette raison que je n'ai pas encore l'ADSL chez moi.
Aie, mauvais départ, tu peux très bien te faire rooter en étant en rtc!
Je viens de faire un test sur hackercheck.com et il apparait que le port 22 est ouvert alors que ssh ne tourne pas.
Peut être pas ssh mais "quelque chose" si.
Laisser ce port ouvert sans ssh derrière présente-t-il un risque ? Si oui, comment fermer ce port ?
Voir plus bas.
Pour savoir ce qui tourne fait un petit netstat -ntap et tu verras... ssh! :)
(sauf si vraiment tu t'es fait hacker et que tu as un rootkit qui va bien par exemple.)
Si je passe à l'ADSL (faut vivre avec son temps) quelles règles de sécurité adopter pour pour laisser tourner un ssh sur le port 22 en limitant les risques ?
Lire ce qui a déjà été dit ici même.
Sinon impossible de te répondre pécisément si tu n'a aucune connaissance sur, disons au moins IP, TCP, UDP et un chouia d'ICMP [1](pour les autres ça peut attendre tes besoins!)
Pour ce qui est d'un PC connecté, bloque au moins les flux entrant que tu n'a pas initié
Config Debian Sarge 2.6.7 sur PC
Et a l'install tu as problablement sshd par défaut (accessoirement le 2.6.9 est la dernière version stable du kernel et depuis la 2.6.7 il y a quelques bugs chiants qui ont étés corrigés)
Merci de toute aide (voir de tout RTFM, en français si possible)
Là tu provoque! Ca va être un search the fucking web alors... :)
...un peu de formation sur les réseaux, IP, tout çaaa :)
Sérieusement, ça aide de *comprendre* ce qu'il se passe et d'un coup la sécurité te paraitra plus "simple" à mettre en oeuvre.
Nota : Linux est un Unix-like. Comme tout OS il a aussi ses pièges : mauvaises permission suid positionné où il ne faut pas etc.... Je vois trop souvent à mon gout des gens qui pense que "le réseau est tout". Certes si tu es seul sur ta machine et que personne ne passe ça va, mais si ta machine est partagée, ou si tu ouvre des comptes etc, il importe de se former un peu à l'OS <troll> sinon on se retrouve comme sous windows avec un clikodrome qu'on ne sait pas correctement utiliser</troll>
Eric.
[1] plus précisément tu semble ne pas vraiment savoir ce qu'est un port par exemple ; sinon tu n'imaginerais pas un "port ouvert sans rien derrière".
-- L'invulnérable : Je ne pense pas etre piratable, infectable par un trojen oui! Vu sur fcs un jour de mars 2004.
Jeremy JUST
On 30 Oct 2004 19:48:22 GMT Hugolino wrote:
Je viens de faire un test sur hackercheck.com et il apparait que le port 22 est ouvert alors que ssh ne tourne pas.
Ce ne serait pas xinetd qui écoute derrière?
quelles règles de sécurité adopter pour pour laisser tourner un ssh sur le port 22 en limitant les risques ?
Déjà, il est impératif d'avoir des mots de passe en béton. Ensuite, tu peux t'inspirer de ce qui vient d'être dit dans le thread « tentatives intrusion ssh », dont le message .
Si tu sais que tu ne te connecteras que depuis certaines adresses IP, tu peux configurer ça au niveau du pare-feu.
-- Jérémy JUST
On 30 Oct 2004 19:48:22 GMT
Hugolino <hugolino@fri.fr> wrote:
Je viens de faire un test sur hackercheck.com et il apparait que le
port 22 est ouvert alors que ssh ne tourne pas.
Ce ne serait pas xinetd qui écoute derrière?
quelles règles de sécurité adopter pour pour laisser tourner un ssh
sur le port 22 en limitant les risques ?
Déjà, il est impératif d'avoir des mots de passe en béton.
Ensuite, tu peux t'inspirer de ce qui vient d'être dit dans le thread
« tentatives intrusion ssh », dont le message
<pan.2004.10.29.09.23.12.688791@imag.fr>.
Si tu sais que tu ne te connecteras que depuis certaines adresses IP,
tu peux configurer ça au niveau du pare-feu.
Je viens de faire un test sur hackercheck.com et il apparait que le port 22 est ouvert alors que ssh ne tourne pas.
Ce ne serait pas xinetd qui écoute derrière?
quelles règles de sécurité adopter pour pour laisser tourner un ssh sur le port 22 en limitant les risques ?
Déjà, il est impératif d'avoir des mots de passe en béton. Ensuite, tu peux t'inspirer de ce qui vient d'être dit dans le thread « tentatives intrusion ssh », dont le message .
Si tu sais que tu ne te connecteras que depuis certaines adresses IP, tu peux configurer ça au niveau du pare-feu.
-- Jérémy JUST
Eric Razny
Pour savoir ce qui tourne fait un petit netstat -ntap et tu verras... ssh! :)
Oops, ou comme l'a suggéré Jeremy JUST un wrapper quelconque (inetd, xinetd...).
Je ne sais plus si j'ai viré machinalement xinetd (je ne crois pas, mais comme je n'en ai pas l'usage s'il avait été là, couic! :) ), mais sur ma dernière install sarge j'ai sshd qui bind directement le port.
Une dernière chose, quand tu as un port quelconque "connu" d'ouvert (et que tu a le droit de te connecter à la machine) un coup de telnet ou du client du service présumé peut être la plus simple des solutions[1]
Eric.
[1] Mais bon, si un service répond, et que tu n'as pas (mais *réellement* pas!) installé le service directement ou indirectement... tu es bon pour une réinstall complète (de préférence en ayant trouvé la faille).
-- L'invulnérable : Je ne pense pas etre piratable, infectable par un trojen oui! Vu sur fcs un jour de mars 2004.
Pour savoir ce qui tourne fait un petit netstat -ntap et tu verras...
ssh! :)
Oops, ou comme l'a suggéré Jeremy JUST un wrapper quelconque (inetd,
xinetd...).
Je ne sais plus si j'ai viré machinalement xinetd (je ne crois pas, mais
comme je n'en ai pas l'usage s'il avait été là, couic! :) ), mais sur ma
dernière install sarge j'ai sshd qui bind directement le port.
Une dernière chose, quand tu as un port quelconque "connu" d'ouvert (et
que tu a le droit de te connecter à la machine) un coup de telnet ou du
client du service présumé peut être la plus simple des solutions[1]
Eric.
[1] Mais bon, si un service répond, et que tu n'as pas (mais
*réellement* pas!) installé le service directement ou indirectement...
tu es bon pour une réinstall complète (de préférence en ayant trouvé la
faille).
--
L'invulnérable :
Je ne pense pas etre piratable, infectable par un trojen oui!
Vu sur fcs un jour de mars 2004.
Pour savoir ce qui tourne fait un petit netstat -ntap et tu verras... ssh! :)
Oops, ou comme l'a suggéré Jeremy JUST un wrapper quelconque (inetd, xinetd...).
Je ne sais plus si j'ai viré machinalement xinetd (je ne crois pas, mais comme je n'en ai pas l'usage s'il avait été là, couic! :) ), mais sur ma dernière install sarge j'ai sshd qui bind directement le port.
Une dernière chose, quand tu as un port quelconque "connu" d'ouvert (et que tu a le droit de te connecter à la machine) un coup de telnet ou du client du service présumé peut être la plus simple des solutions[1]
Eric.
[1] Mais bon, si un service répond, et que tu n'as pas (mais *réellement* pas!) installé le service directement ou indirectement... tu es bon pour une réinstall complète (de préférence en ayant trouvé la faille).
-- L'invulnérable : Je ne pense pas etre piratable, infectable par un trojen oui! Vu sur fcs un jour de mars 2004.
Alain Montfranc
Il se trouve que Hugolino a formulé :
Si oui, comment fermer ce port ?
sous root, "netstat -tan --program | grep ':22 '" te diras qui utilise le port 22...
Il se trouve que Hugolino a formulé :
Si oui, comment fermer ce port ?
sous root, "netstat -tan --program | grep ':22 '" te diras qui utilise
le port 22...
sous root, "netstat -tan --program | grep ':22 '" te diras qui utilise le port 22...
Cedric Blancher
Le Sun, 31 Oct 2004 10:12:37 +0000, Patrick Lamaiziere a écrit :
On peut le spécifier dans hosts.allow, et ne se servir du pare-feu que comme sécurité supplémentaire ? Par exemple pour autoriser le réseau local : sshd : 192.168.0. : allow ALL : ALL : deny
On peut aussi dire au sshd de ne se lancer que l'interface internet s'il est en standalone, ou laisser xinetd le faire.
De toute manière, en terme de filtrage, ceinture et bretelles ne font pas de mal.
-- J'en ai marre des signatures bidons avec des citations nulles.....surtout sur les forums autour de linux. -+- AS in GFA : "Cachez ces signatures que je ne saurai voir"
Le Sun, 31 Oct 2004 10:12:37 +0000, Patrick Lamaiziere a écrit :
On peut le spécifier dans hosts.allow, et ne se servir du pare-feu que
comme sécurité supplémentaire ? Par exemple pour autoriser le réseau
local :
sshd : 192.168.0. : allow
ALL : ALL : deny
On peut aussi dire au sshd de ne se lancer que l'interface internet s'il
est en standalone, ou laisser xinetd le faire.
De toute manière, en terme de filtrage, ceinture et bretelles ne font pas
de mal.
--
J'en ai marre des signatures bidons avec des citations nulles.....surtout
sur les forums autour de linux.
-+- AS in GFA : "Cachez ces signatures que je ne saurai voir"
Le Sun, 31 Oct 2004 10:12:37 +0000, Patrick Lamaiziere a écrit :
On peut le spécifier dans hosts.allow, et ne se servir du pare-feu que comme sécurité supplémentaire ? Par exemple pour autoriser le réseau local : sshd : 192.168.0. : allow ALL : ALL : deny
On peut aussi dire au sshd de ne se lancer que l'interface internet s'il est en standalone, ou laisser xinetd le faire.
De toute manière, en terme de filtrage, ceinture et bretelles ne font pas de mal.
-- J'en ai marre des signatures bidons avec des citations nulles.....surtout sur les forums autour de linux. -+- AS in GFA : "Cachez ces signatures que je ne saurai voir"
Cedric Blancher
Le Mon, 01 Nov 2004 01:08:14 +0000, Patrick Lamaiziere a écrit :
On peut aussi dire au sshd de ne se lancer que l'interface internet s'il est en standalone, Euh, j'ai du mal à piger cette phrase ?
Le meilleur moyen de ne pas accepter de connexion sur une interface (externe typiquement) est de ne pas y faire écouter le démon. Si tu lances le SSHd en standalone (i.e. pas via (x)inetd), tu peux le faire.
-- BOFH excuse #75:
There isn't any problem
Le Mon, 01 Nov 2004 01:08:14 +0000, Patrick Lamaiziere a écrit :
On peut aussi dire au sshd de ne se lancer que l'interface internet
s'il est en standalone,
Euh, j'ai du mal à piger cette phrase ?
Le meilleur moyen de ne pas accepter de connexion sur une interface
(externe typiquement) est de ne pas y faire écouter le démon. Si tu
lances le SSHd en standalone (i.e. pas via (x)inetd), tu peux le faire.
Le Mon, 01 Nov 2004 01:08:14 +0000, Patrick Lamaiziere a écrit :
On peut aussi dire au sshd de ne se lancer que l'interface internet s'il est en standalone, Euh, j'ai du mal à piger cette phrase ?
Le meilleur moyen de ne pas accepter de connexion sur une interface (externe typiquement) est de ne pas y faire écouter le démon. Si tu lances le SSHd en standalone (i.e. pas via (x)inetd), tu peux le faire.
-- BOFH excuse #75:
There isn't any problem
Nicolas George
Cedric Blancher wrote in message :
Le meilleur moyen de ne pas accepter de connexion sur une interface (externe typiquement) est de ne pas y faire écouter le démon.
Ce n'est pas fiable, ça. Si la machine est routeur¹, et que quelqu'un se débrouille pour faire arriver sur l'interface A (disons l'interface publique) un paquet adressé à l'IP de l'interface B (disons l'interface privée), alors ce paquet sera effectivement reçu par le démon qui n'écoute que sur l'interface privée.
Évidemment, le risque est assez faible dans les cas pratiques, car les fournisseurs d'accès et les hébergeurs ne routeront certainement pas un paquet adressé à une adresse de réseau privée vers l'interface publique d'un client, et la plupart refusent le routage à la source. Mais il y a un élément de confiance envers un tiers, et quand on parle de sécurité, il faut en être conscient.
Si tu lances le SSHd en standalone (i.e. pas via (x)inetd), tu peux le faire.
xinetd a également des fonctionnalités pour faire ça, en particulier la directive bind. D'une manière générale, xinetd a plutôt des fonctionnalités de contrôle d'accès généralistes (c'est à dire non liées à un protocole, comme des distinctions sur la méthode d'authentification de SSH ou le répertoire pour un serveur web) plus expressives que la plupart des serveurs.
1 : D'aucuns parlent de weak end model vs. strong end model, mais je trouve ça assez oiseux, la distinction pertinente à mon avis devrait être si la machine fait du routage entre ses interfaces réseau.
Cedric Blancher wrote in message
<pan.2004.11.01.09.24.10.434178@cartel-securite.fr>:
Le meilleur moyen de ne pas accepter de connexion sur une interface
(externe typiquement) est de ne pas y faire écouter le démon.
Ce n'est pas fiable, ça. Si la machine est routeur¹, et que quelqu'un se
débrouille pour faire arriver sur l'interface A (disons l'interface
publique) un paquet adressé à l'IP de l'interface B (disons l'interface
privée), alors ce paquet sera effectivement reçu par le démon qui n'écoute
que sur l'interface privée.
Évidemment, le risque est assez faible dans les cas pratiques, car les
fournisseurs d'accès et les hébergeurs ne routeront certainement pas un
paquet adressé à une adresse de réseau privée vers l'interface publique d'un
client, et la plupart refusent le routage à la source. Mais il y a un
élément de confiance envers un tiers, et quand on parle de sécurité, il faut
en être conscient.
Si tu
lances le SSHd en standalone (i.e. pas via (x)inetd), tu peux le faire.
xinetd a également des fonctionnalités pour faire ça, en particulier la
directive bind. D'une manière générale, xinetd a plutôt des fonctionnalités
de contrôle d'accès généralistes (c'est à dire non liées à un protocole,
comme des distinctions sur la méthode d'authentification de SSH ou le
répertoire pour un serveur web) plus expressives que la plupart des
serveurs.
1 : D'aucuns parlent de weak end model vs. strong end model, mais je trouve
ça assez oiseux, la distinction pertinente à mon avis devrait être si la
machine fait du routage entre ses interfaces réseau.
Le meilleur moyen de ne pas accepter de connexion sur une interface (externe typiquement) est de ne pas y faire écouter le démon.
Ce n'est pas fiable, ça. Si la machine est routeur¹, et que quelqu'un se débrouille pour faire arriver sur l'interface A (disons l'interface publique) un paquet adressé à l'IP de l'interface B (disons l'interface privée), alors ce paquet sera effectivement reçu par le démon qui n'écoute que sur l'interface privée.
Évidemment, le risque est assez faible dans les cas pratiques, car les fournisseurs d'accès et les hébergeurs ne routeront certainement pas un paquet adressé à une adresse de réseau privée vers l'interface publique d'un client, et la plupart refusent le routage à la source. Mais il y a un élément de confiance envers un tiers, et quand on parle de sécurité, il faut en être conscient.
Si tu lances le SSHd en standalone (i.e. pas via (x)inetd), tu peux le faire.
xinetd a également des fonctionnalités pour faire ça, en particulier la directive bind. D'une manière générale, xinetd a plutôt des fonctionnalités de contrôle d'accès généralistes (c'est à dire non liées à un protocole, comme des distinctions sur la méthode d'authentification de SSH ou le répertoire pour un serveur web) plus expressives que la plupart des serveurs.
1 : D'aucuns parlent de weak end model vs. strong end model, mais je trouve ça assez oiseux, la distinction pertinente à mon avis devrait être si la machine fait du routage entre ses interfaces réseau.
Michel Arboi
On Mon Nov 01 2004 at 15:02, Nicolas George wrote:
1 : D'aucuns parlent de weak end model vs. strong end model, mais je trouve ça assez oiseux, la distinction pertinente à mon avis devrait être si la machine fait du routage entre ses interfaces réseau.
C'est une autre façon de présenter la chose. Mais trompeuse AMHA, car je ne crois pas que ça ne soit directement lié au routage actif ou non. Je crains qu'en "weak", les paquets atteignent les interfaces locales dans tous les cas de figure. Quelqu'un a fait des expériences sur ce sujet ?
-- http://arboi.da.ru FAQNOPI de fr.comp.securite http://faqnopi.da.ru/ NASL2 reference manual http://michel.arboi.free.fr/nasl2ref/
On Mon Nov 01 2004 at 15:02, Nicolas George wrote:
1 : D'aucuns parlent de weak end model vs. strong end model, mais je trouve
ça assez oiseux, la distinction pertinente à mon avis devrait être si la
machine fait du routage entre ses interfaces réseau.
C'est une autre façon de présenter la chose. Mais trompeuse AMHA, car
je ne crois pas que ça ne soit directement lié au routage actif ou
non.
Je crains qu'en "weak", les paquets atteignent les interfaces locales
dans tous les cas de figure. Quelqu'un a fait des expériences sur ce
sujet ?
On Mon Nov 01 2004 at 15:02, Nicolas George wrote:
1 : D'aucuns parlent de weak end model vs. strong end model, mais je trouve ça assez oiseux, la distinction pertinente à mon avis devrait être si la machine fait du routage entre ses interfaces réseau.
C'est une autre façon de présenter la chose. Mais trompeuse AMHA, car je ne crois pas que ça ne soit directement lié au routage actif ou non. Je crains qu'en "weak", les paquets atteignent les interfaces locales dans tous les cas de figure. Quelqu'un a fait des expériences sur ce sujet ?
-- http://arboi.da.ru FAQNOPI de fr.comp.securite http://faqnopi.da.ru/ NASL2 reference manual http://michel.arboi.free.fr/nasl2ref/
Cedric Blancher
Le Mon, 01 Nov 2004 14:02:39 +0000, Nicolas George a écrit :
Ce n'est pas fiable, ça. Si la machine est routeur [...]
Si la machine est un routeur entre deux réseaux public et privés, elle doit mettre en oeuvre un set minimum de règle de firewalling, en particulier tout ce qui est antispoofing et verrouillage de l'accès au réseau interne, donc une règle interdisant l'accès au réseau interne depuis l'extérieur, et ce de manière générale.
-- Patricia, mon petit, je ne voudrais pas te paraitre vieux jeu, ni encore moins grossier.. l'homme de la Pampa, parfois rude, reste toujours courtois...mais la verite m'oblige à te le dire: ton Antoine commence à me les briser menues !!!... -+- Lino Ventura, les Tontons Flingueurs
Le Mon, 01 Nov 2004 14:02:39 +0000, Nicolas George a écrit :
Ce n'est pas fiable, ça. Si la machine est routeur [...]
Si la machine est un routeur entre deux réseaux public et privés, elle
doit mettre en oeuvre un set minimum de règle de firewalling, en
particulier tout ce qui est antispoofing et verrouillage de l'accès au
réseau interne, donc une règle interdisant l'accès au réseau interne
depuis l'extérieur, et ce de manière générale.
--
Patricia, mon petit, je ne voudrais pas te paraitre vieux jeu, ni encore moins
grossier.. l'homme de la Pampa, parfois rude, reste toujours courtois...mais
la verite m'oblige à te le dire: ton Antoine commence à me les briser
menues !!!... -+- Lino Ventura, les Tontons Flingueurs
Le Mon, 01 Nov 2004 14:02:39 +0000, Nicolas George a écrit :
Ce n'est pas fiable, ça. Si la machine est routeur [...]
Si la machine est un routeur entre deux réseaux public et privés, elle doit mettre en oeuvre un set minimum de règle de firewalling, en particulier tout ce qui est antispoofing et verrouillage de l'accès au réseau interne, donc une règle interdisant l'accès au réseau interne depuis l'extérieur, et ce de manière générale.
-- Patricia, mon petit, je ne voudrais pas te paraitre vieux jeu, ni encore moins grossier.. l'homme de la Pampa, parfois rude, reste toujours courtois...mais la verite m'oblige à te le dire: ton Antoine commence à me les briser menues !!!... -+- Lino Ventura, les Tontons Flingueurs
