Je veux ouvrir le port 8767 pour le logiciel "TeamSpeak 2
server" qui est sur le routeur-serveur avec l'adresse IP 192.168.1.1
Je veux que l'on puisse avoir accès à "TeamSpeak 2 server" à
partir de l'Internet comme à partir du réseaux local.
Cela fonctionne à partir du réseau local : Shorewall laisse
passer les paquets pour le port 8767.
Par contre, cela ne fonctionne pas dans le sens Internet --->
Serveur
Voici le résultat que me donne le fichier log /var/log/messages
lorsque je me connecte avec mon client
TeamSpeak sur la machine client (192.168.1.20) sur le serveur
(192.168.1.1)
ACCEPT net fw udp 8767 -
ACCEPT fw net udp 8767 -
ACCEPT loc fw udp 8767 -
ACCEPT fw loc udp 8767 -
Je tiens à préciser que je n'ai pas de problème avec les autres
ports comme le port 80 ou le port 21 par exemple.
http://lox.ath.cx:80 fonctionne...
J'ai "fermé" le service FTP, vous ne pourrais donc pas le
vérifier mais je l'ai fait pour vous...
Je suppose que j'ai mal configurer les règles de shorewall. Mais
que dois-je modifier SVP ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
patrik
Tu peux aussi utiliser le panneau de configuration de Mandrake (drakconf) et paramétrer shorewall pour ouvrir dans les deux sens le n° de port à utiliser, mais il faut utiliser l'onglet "avancé" pour faire cette manipulation .
Patrik
Tu peux aussi utiliser le panneau de configuration de Mandrake
(drakconf) et paramétrer shorewall pour ouvrir dans les deux sens le n°
de port à utiliser, mais il faut utiliser l'onglet "avancé" pour faire
cette manipulation .
Tu peux aussi utiliser le panneau de configuration de Mandrake (drakconf) et paramétrer shorewall pour ouvrir dans les deux sens le n° de port à utiliser, mais il faut utiliser l'onglet "avancé" pour faire cette manipulation .
Patrik
nicolas
Le Sun, 26 Sep 2004 23:20:02 +0200, Loïc Prouvèze nous exposa quelques reflexions personnelles :
Bonjour,
Je veux ouvrir le port 8767 pour le logiciel "TeamSpeak 2 server" qui est sur le routeur-serveur avec l'adresse IP 192.168.1.1
Je veux que l'on puisse avoir accès à "TeamSpeak 2 server" à partir de l'Internet comme à partir du réseaux local.
Cela fonctionne à partir du réseau local : Shorewall laisse passer les paquets pour le port 8767.
Par contre, cela ne fonctionne pas dans le sens Internet ---> Serveur
Voici le résultat que me donne le fichier log /var/log/messages lorsque je me connecte avec mon client TeamSpeak sur la machine client (192.168.1.20) sur le serveur (192.168.1.1)
ACCEPT net fw udp 8767 - ACCEPT fw net udp 8767 - ACCEPT loc fw udp 8767 - ACCEPT fw loc udp 8767 -
Je tiens à préciser que je n'ai pas de problème avec les autres ports comme le port 80 ou le port 21 par exemple. http://lox.ath.cx:80 fonctionne... J'ai "fermé" le service FTP, vous ne pourrais donc pas le vérifier mais je l'ai fait pour vous...
Je suppose que j'ai mal configurer les règles de shorewall. Mais que dois-je modifier SVP ?
Merci d'avance, Loïc
Attention à bien tenir compte du port source et du port destination, ils faut les paramétrer séparément.
Dans l'exemple que tu donnes, je comprends que shorewall a bloqué un message partant du serveur (.1.1) ,SPT (source port) = 8767 vers le client (.1.20) , DST (destination port) = 2140
Or quand je regarde tes règles, celà me parait normal, puisqu'il n'y a pas de règle laissant passer le 8767 comme port source. (8767 est donné dans tes règles toujours comme port destination).
Refait à mon avis une passe sur le type de port (source ou destination) au niveau des règles. Je te conseille d'utiliser webmin (sauf si tu l'utilises déjà), qui dispose de pages permettant de paramétrer shorewall de façon très pratique.
Le Sun, 26 Sep 2004 23:20:02 +0200, Loïc Prouvèze nous exposa quelques
reflexions personnelles :
Bonjour,
Je veux ouvrir le port 8767 pour le logiciel "TeamSpeak 2
server" qui est sur le routeur-serveur avec l'adresse IP 192.168.1.1
Je veux que l'on puisse avoir accès à "TeamSpeak 2 server" à
partir de l'Internet comme à partir du réseaux local.
Cela fonctionne à partir du réseau local : Shorewall laisse
passer les paquets pour le port 8767.
Par contre, cela ne fonctionne pas dans le sens Internet --->
Serveur
Voici le résultat que me donne le fichier log /var/log/messages
lorsque je me connecte avec mon client
TeamSpeak sur la machine client (192.168.1.20) sur le serveur
(192.168.1.1)
ACCEPT net fw udp 8767 -
ACCEPT fw net udp 8767 -
ACCEPT loc fw udp 8767 -
ACCEPT fw loc udp 8767 -
Je tiens à préciser que je n'ai pas de problème avec les autres
ports comme le port 80 ou le port 21 par exemple.
http://lox.ath.cx:80 fonctionne...
J'ai "fermé" le service FTP, vous ne pourrais donc pas le
vérifier mais je l'ai fait pour vous...
Je suppose que j'ai mal configurer les règles de shorewall. Mais
que dois-je modifier SVP ?
Merci d'avance,
Loïc
Attention à bien tenir compte du port source et du port destination, ils
faut les paramétrer séparément.
Dans l'exemple que tu donnes, je comprends que shorewall a bloqué un
message partant du serveur (.1.1) ,SPT (source port) = 8767 vers le client
(.1.20) , DST (destination port) = 2140
Or quand je regarde tes règles, celà me parait normal, puisqu'il n'y a
pas de règle laissant passer le 8767 comme port source. (8767 est donné
dans tes règles toujours comme port destination).
Refait à mon avis une passe sur le type de port (source ou destination)
au niveau des règles. Je te conseille d'utiliser webmin (sauf si tu
l'utilises déjà), qui dispose de pages permettant de paramétrer
shorewall de façon très pratique.
Le Sun, 26 Sep 2004 23:20:02 +0200, Loïc Prouvèze nous exposa quelques reflexions personnelles :
Bonjour,
Je veux ouvrir le port 8767 pour le logiciel "TeamSpeak 2 server" qui est sur le routeur-serveur avec l'adresse IP 192.168.1.1
Je veux que l'on puisse avoir accès à "TeamSpeak 2 server" à partir de l'Internet comme à partir du réseaux local.
Cela fonctionne à partir du réseau local : Shorewall laisse passer les paquets pour le port 8767.
Par contre, cela ne fonctionne pas dans le sens Internet ---> Serveur
Voici le résultat que me donne le fichier log /var/log/messages lorsque je me connecte avec mon client TeamSpeak sur la machine client (192.168.1.20) sur le serveur (192.168.1.1)
ACCEPT net fw udp 8767 - ACCEPT fw net udp 8767 - ACCEPT loc fw udp 8767 - ACCEPT fw loc udp 8767 -
Je tiens à préciser que je n'ai pas de problème avec les autres ports comme le port 80 ou le port 21 par exemple. http://lox.ath.cx:80 fonctionne... J'ai "fermé" le service FTP, vous ne pourrais donc pas le vérifier mais je l'ai fait pour vous...
Je suppose que j'ai mal configurer les règles de shorewall. Mais que dois-je modifier SVP ?
Merci d'avance, Loïc
Attention à bien tenir compte du port source et du port destination, ils faut les paramétrer séparément.
Dans l'exemple que tu donnes, je comprends que shorewall a bloqué un message partant du serveur (.1.1) ,SPT (source port) = 8767 vers le client (.1.20) , DST (destination port) = 2140
Or quand je regarde tes règles, celà me parait normal, puisqu'il n'y a pas de règle laissant passer le 8767 comme port source. (8767 est donné dans tes règles toujours comme port destination).
Refait à mon avis une passe sur le type de port (source ou destination) au niveau des règles. Je te conseille d'utiliser webmin (sauf si tu l'utilises déjà), qui dispose de pages permettant de paramétrer shorewall de façon très pratique.
Loïc Prouvèze
nicolas a écrit :
Le Sun, 26 Sep 2004 23:20:02 +0200, Loïc Prouvèze nous exposa quelques reflexions personnelles :
<SNIP> Je suppose que j'ai mal configurer les règles de shorewall. Mais que dois-je modifier SVP ?
Attention à bien tenir compte du port source et du port destination, ils faut les paramétrer séparément.
Ha... Je me disais bien que c'était quelque chose dans ce goût là...
Dans l'exemple que tu donnes, je comprends que shorewall a bloqué un message partant du serveur (.1.1) ,SPT (source port) = 8767 vers le client (.1.20) , DST (destination port) = 2140
Or quand je regarde tes règles, celà me parait normal, puisqu'il n'y a pas de règle laissant passer le 8767 comme port source. (8767 est donné dans tes règles toujours comme port destination).
Tiens, j'avais pas remarqué le DST!40
Refait à mon avis une passe sur le type de port (source ou destination) au niveau des règles. Je te conseille d'utiliser webmin (sauf si tu l'utilises déjà), qui dispose de pages permettant de paramétrer shorewall de façon très pratique.
Je vais faire encore de nouveaux essais. J'en ai dèjà fait mais quelque chose à dû m'échaper...
Pour ce qui est de webmin, je ne vois pas ce qu'il m'apporte par rapport à une connexion SSH dans laquelle je modifie directement le fichier avec Vim.
Webmin est peut-être plus sécurisé qu'une connexion SSH ?
Merci beaucoup, en tous les cas. Tu m'ouvres une nouvelle piste.
Je reviendrais dès que j'ai fait mes essais.
A bientöt, Loïc.
nicolas a écrit :
Le Sun, 26 Sep 2004 23:20:02 +0200, Loïc Prouvèze nous exposa quelques
reflexions personnelles :
<SNIP>
Je suppose que j'ai mal configurer les règles de shorewall. Mais
que dois-je modifier SVP ?
Attention à bien tenir compte du port source et du port destination, ils
faut les paramétrer séparément.
Ha... Je me disais bien que c'était quelque chose dans ce goût là...
Dans l'exemple que tu donnes, je comprends que shorewall a bloqué un
message partant du serveur (.1.1) ,SPT (source port) = 8767 vers le client
(.1.20) , DST (destination port) = 2140
Or quand je regarde tes règles, celà me parait normal, puisqu'il n'y a
pas de règle laissant passer le 8767 comme port source. (8767 est donné
dans tes règles toujours comme port destination).
Tiens, j'avais pas remarqué le DST!40
Refait à mon avis une passe sur le type de port (source ou destination)
au niveau des règles. Je te conseille d'utiliser webmin (sauf si tu
l'utilises déjà), qui dispose de pages permettant de paramétrer
shorewall de façon très pratique.
Je vais faire encore de nouveaux essais. J'en ai dèjà fait mais
quelque chose à dû m'échaper...
Pour ce qui est de webmin, je ne vois pas ce qu'il m'apporte par
rapport à une connexion SSH dans laquelle je modifie directement
le fichier avec Vim.
Webmin est peut-être plus sécurisé qu'une connexion SSH ?
Merci beaucoup, en tous les cas. Tu m'ouvres une nouvelle piste.
Le Sun, 26 Sep 2004 23:20:02 +0200, Loïc Prouvèze nous exposa quelques reflexions personnelles :
<SNIP> Je suppose que j'ai mal configurer les règles de shorewall. Mais que dois-je modifier SVP ?
Attention à bien tenir compte du port source et du port destination, ils faut les paramétrer séparément.
Ha... Je me disais bien que c'était quelque chose dans ce goût là...
Dans l'exemple que tu donnes, je comprends que shorewall a bloqué un message partant du serveur (.1.1) ,SPT (source port) = 8767 vers le client (.1.20) , DST (destination port) = 2140
Or quand je regarde tes règles, celà me parait normal, puisqu'il n'y a pas de règle laissant passer le 8767 comme port source. (8767 est donné dans tes règles toujours comme port destination).
Tiens, j'avais pas remarqué le DST!40
Refait à mon avis une passe sur le type de port (source ou destination) au niveau des règles. Je te conseille d'utiliser webmin (sauf si tu l'utilises déjà), qui dispose de pages permettant de paramétrer shorewall de façon très pratique.
Je vais faire encore de nouveaux essais. J'en ai dèjà fait mais quelque chose à dû m'échaper...
Pour ce qui est de webmin, je ne vois pas ce qu'il m'apporte par rapport à une connexion SSH dans laquelle je modifie directement le fichier avec Vim.
Webmin est peut-être plus sécurisé qu'une connexion SSH ?
Merci beaucoup, en tous les cas. Tu m'ouvres une nouvelle piste.
Je reviendrais dès que j'ai fait mes essais.
A bientöt, Loïc.
Loïc Prouvèze
patrik a écrit :
Tu peux aussi utiliser le panneau de configuration de Mandrake (drakconf) et paramétrer shorewall pour ouvrir dans les deux sens le n° de port à utiliser, mais il faut utiliser l'onglet "avancé" pour faire cette manipulation .
Merci Patrick.
Oui, j'ai déjà essayé ça mais drakconf m'efface certaines règles comme, entre autre, les redirections dans mon fichier /etc/shorewall/rules. Je ne peux donc pas l'utiliser.
@+, Loïc
patrik a écrit :
Tu peux aussi utiliser le panneau de configuration de Mandrake
(drakconf) et paramétrer shorewall pour ouvrir dans les deux sens le n°
de port à utiliser, mais il faut utiliser l'onglet "avancé" pour faire
cette manipulation .
Merci Patrick.
Oui, j'ai déjà essayé ça mais drakconf m'efface certaines règles
comme, entre autre, les redirections dans mon fichier
/etc/shorewall/rules.
Je ne peux donc pas l'utiliser.
Tu peux aussi utiliser le panneau de configuration de Mandrake (drakconf) et paramétrer shorewall pour ouvrir dans les deux sens le n° de port à utiliser, mais il faut utiliser l'onglet "avancé" pour faire cette manipulation .
Merci Patrick.
Oui, j'ai déjà essayé ça mais drakconf m'efface certaines règles comme, entre autre, les redirections dans mon fichier /etc/shorewall/rules. Je ne peux donc pas l'utiliser.
@+, Loïc
Loïc Prouvèze
Loïc Prouvèze a écrit :
nicolas a écrit :
Attention à bien tenir compte du port source et du port destination, ils faut les paramétrer séparément.
Ha... Je me disais bien que c'était quelque chose dans ce goût là...
Merci !
C'était bien ça ! En fait, mon fichier rules ressemble maintenant à ça :
ACCEPT net fw udp 8767 - ACCEPT net fw udp - 8767 ACCEPT fw net udp 8767 - ACCEPT fw net udp - 8767 ACCEPT loc fw udp 8767 - ACCEPT loc fw udp - 8767 ACCEPT fw loc udp 8767 - ACCEPT fw loc udp - 8767
Dans l'exemple que tu donnes, je comprends que shorewall a bloqué un message partant du serveur (.1.1) ,SPT (source port) = 8767 vers le client (.1.20) , DST (destination port) = 2140
Or quand je regarde tes règles, celà me parait normal, puisqu'il n'y a pas de règle laissant passer le 8767 comme port source. (8767 est donné dans tes règles toujours comme port destination).
Tiens, j'avais pas remarqué le DST!40
C'est quand même bizarre... Il choisi un port aléatoirement au lieu de reprendre par défaut celui qui est défini dans la règle...
Refait à mon avis une passe sur le type de port (source ou destination) au niveau des règles. Je te conseille d'utiliser webmin (sauf si tu l'utilises déjà), qui dispose de pages permettant de paramétrer shorewall de façon très pratique.
Pour ce qui est de webmin, je ne vois pas ce qu'il m'apporte par rapport à une connexion SSH dans laquelle je modifie directement le fichier avec Vim.
Webmin est peut-être plus sécurisé qu'une connexion SSH ?
Loïc Prouvèze a écrit :
nicolas a écrit :
Attention à bien tenir compte du port source et du port destination, ils
faut les paramétrer séparément.
Ha... Je me disais bien que c'était quelque chose dans ce goût là...
Merci !
C'était bien ça ! En fait, mon fichier rules ressemble
maintenant à ça :
ACCEPT net fw udp 8767 -
ACCEPT net fw udp - 8767
ACCEPT fw net udp 8767 -
ACCEPT fw net udp - 8767
ACCEPT loc fw udp 8767 -
ACCEPT loc fw udp - 8767
ACCEPT fw loc udp 8767 -
ACCEPT fw loc udp - 8767
Dans l'exemple que tu donnes, je comprends que shorewall a bloqué un
message partant du serveur (.1.1) ,SPT (source port) = 8767 vers le
client
(.1.20) , DST (destination port) = 2140
Or quand je regarde tes règles, celà me parait normal, puisqu'il n'y a
pas de règle laissant passer le 8767 comme port source. (8767 est donné
dans tes règles toujours comme port destination).
Tiens, j'avais pas remarqué le DST!40
C'est quand même bizarre... Il choisi un port aléatoirement au
lieu de reprendre par défaut celui qui est défini dans la règle...
Refait à mon avis une passe sur le type de port (source ou destination)
au niveau des règles. Je te conseille d'utiliser webmin (sauf si tu
l'utilises déjà), qui dispose de pages permettant de paramétrer
shorewall de façon très pratique.
Pour ce qui est de webmin, je ne vois pas ce qu'il m'apporte par rapport
à une connexion SSH dans laquelle je modifie directement le fichier avec
Vim.
Webmin est peut-être plus sécurisé qu'une connexion SSH ?
Attention à bien tenir compte du port source et du port destination, ils faut les paramétrer séparément.
Ha... Je me disais bien que c'était quelque chose dans ce goût là...
Merci !
C'était bien ça ! En fait, mon fichier rules ressemble maintenant à ça :
ACCEPT net fw udp 8767 - ACCEPT net fw udp - 8767 ACCEPT fw net udp 8767 - ACCEPT fw net udp - 8767 ACCEPT loc fw udp 8767 - ACCEPT loc fw udp - 8767 ACCEPT fw loc udp 8767 - ACCEPT fw loc udp - 8767
Dans l'exemple que tu donnes, je comprends que shorewall a bloqué un message partant du serveur (.1.1) ,SPT (source port) = 8767 vers le client (.1.20) , DST (destination port) = 2140
Or quand je regarde tes règles, celà me parait normal, puisqu'il n'y a pas de règle laissant passer le 8767 comme port source. (8767 est donné dans tes règles toujours comme port destination).
Tiens, j'avais pas remarqué le DST!40
C'est quand même bizarre... Il choisi un port aléatoirement au lieu de reprendre par défaut celui qui est défini dans la règle...
Refait à mon avis une passe sur le type de port (source ou destination) au niveau des règles. Je te conseille d'utiliser webmin (sauf si tu l'utilises déjà), qui dispose de pages permettant de paramétrer shorewall de façon très pratique.
Pour ce qui est de webmin, je ne vois pas ce qu'il m'apporte par rapport à une connexion SSH dans laquelle je modifie directement le fichier avec Vim.
Webmin est peut-être plus sécurisé qu'une connexion SSH ?
nicolas
Le Fri, 01 Oct 2004 18:11:13 +0200, Loïc Prouvèze nous exposa quelques reflexions personnelles :
Pour ce qui est de webmin, je ne vois pas ce qu'il m'apporte par rapport à une connexion SSH dans laquelle je modifie directement le fichier avec Vim.
Webmin est peut-être plus sécurisé qu'une connexion SSH ?
Webmin est simplement une interface web permettant, entre autres, de configurer shorwall avec une interface par menus, listes, ....
Bien sur, tu peux aussi agir directement dans les fichiers sous vi.
Le Fri, 01 Oct 2004 18:11:13 +0200, Loïc Prouvèze nous exposa quelques
reflexions personnelles :
Pour ce qui est de webmin, je ne vois pas ce qu'il m'apporte par
rapport à une connexion SSH dans laquelle je modifie directement
le fichier avec Vim.
Webmin est peut-être plus sécurisé qu'une connexion SSH ?
Webmin est simplement une interface web permettant, entre autres,
de configurer shorwall avec une interface par menus, listes, ....
Bien sur, tu peux aussi agir directement dans les fichiers sous vi.
Le Fri, 01 Oct 2004 18:11:13 +0200, Loïc Prouvèze nous exposa quelques reflexions personnelles :
Pour ce qui est de webmin, je ne vois pas ce qu'il m'apporte par rapport à une connexion SSH dans laquelle je modifie directement le fichier avec Vim.
Webmin est peut-être plus sécurisé qu'une connexion SSH ?
Webmin est simplement une interface web permettant, entre autres, de configurer shorwall avec une interface par menus, listes, ....
Bien sur, tu peux aussi agir directement dans les fichiers sous vi.
nicolas
Le Fri, 01 Oct 2004 19:35:03 +0200, Loïc Prouvèze nous exposa quelques reflexions personnelles :
Loïc Prouvèze a écrit :
nicolas a écrit :
Attention à bien tenir compte du port source et du port destination, ils faut les paramétrer séparément.
Ha... Je me disais bien que c'était quelque chose dans ce goût là...
Merci !
C'était bien ça ! En fait, mon fichier rules ressemble maintenant à ça :
ACCEPT net fw udp 8767 - ACCEPT net fw udp - 8767 ACCEPT fw net udp 8767 - ACCEPT fw net udp - 8767 ACCEPT loc fw udp 8767 - ACCEPT loc fw udp - 8767 ACCEPT fw loc udp 8767 - ACCEPT fw loc udp - 8767
En effet, ça me parait beaucoup plus approprié !
Dans l'exemple que tu donnes, je comprends que shorewall a bloqué un message partant du serveur (.1.1) ,SPT (source port) = 8767 vers le client (.1.20) , DST (destination port) = 2140
Or quand je regarde tes règles, celà me parait normal, puisqu'il n'y a pas de règle laissant passer le 8767 comme port source. (8767 est donné dans tes règles toujours comme port destination).
Tiens, j'avais pas remarqué le DST!40
C'est quand même bizarre... Il choisi un port aléatoirement au lieu de reprendre par défaut celui qui est défini dans la règle...
Je pense qu'il s'agit ici du message de retour vers le client, donc le port est celui que le client a indiqué précedement dans son message montant
Le Fri, 01 Oct 2004 19:35:03 +0200, Loïc Prouvèze nous exposa quelques
reflexions personnelles :
Loïc Prouvèze a écrit :
nicolas a écrit :
Attention à bien tenir compte du port source et du port destination, ils
faut les paramétrer séparément.
Ha... Je me disais bien que c'était quelque chose dans ce goût là...
Merci !
C'était bien ça ! En fait, mon fichier rules ressemble
maintenant à ça :
ACCEPT net fw udp 8767 -
ACCEPT net fw udp - 8767
ACCEPT fw net udp 8767 -
ACCEPT fw net udp - 8767
ACCEPT loc fw udp 8767 -
ACCEPT loc fw udp - 8767
ACCEPT fw loc udp 8767 -
ACCEPT fw loc udp - 8767
En effet, ça me parait beaucoup plus approprié !
Dans l'exemple que tu donnes, je comprends que shorewall a bloqué un
message partant du serveur (.1.1) ,SPT (source port) = 8767 vers le
client
(.1.20) , DST (destination port) = 2140
Or quand je regarde tes règles, celà me parait normal, puisqu'il n'y a
pas de règle laissant passer le 8767 comme port source. (8767 est donné
dans tes règles toujours comme port destination).
Tiens, j'avais pas remarqué le DST!40
C'est quand même bizarre... Il choisi un port aléatoirement au
lieu de reprendre par défaut celui qui est défini dans la règle...
Je pense qu'il s'agit ici du message de retour vers le client, donc le
port est celui que le client a indiqué précedement dans son message
montant
Le Fri, 01 Oct 2004 19:35:03 +0200, Loïc Prouvèze nous exposa quelques reflexions personnelles :
Loïc Prouvèze a écrit :
nicolas a écrit :
Attention à bien tenir compte du port source et du port destination, ils faut les paramétrer séparément.
Ha... Je me disais bien que c'était quelque chose dans ce goût là...
Merci !
C'était bien ça ! En fait, mon fichier rules ressemble maintenant à ça :
ACCEPT net fw udp 8767 - ACCEPT net fw udp - 8767 ACCEPT fw net udp 8767 - ACCEPT fw net udp - 8767 ACCEPT loc fw udp 8767 - ACCEPT loc fw udp - 8767 ACCEPT fw loc udp 8767 - ACCEPT fw loc udp - 8767
En effet, ça me parait beaucoup plus approprié !
Dans l'exemple que tu donnes, je comprends que shorewall a bloqué un message partant du serveur (.1.1) ,SPT (source port) = 8767 vers le client (.1.20) , DST (destination port) = 2140
Or quand je regarde tes règles, celà me parait normal, puisqu'il n'y a pas de règle laissant passer le 8767 comme port source. (8767 est donné dans tes règles toujours comme port destination).
Tiens, j'avais pas remarqué le DST!40
C'est quand même bizarre... Il choisi un port aléatoirement au lieu de reprendre par défaut celui qui est défini dans la règle...
Je pense qu'il s'agit ici du message de retour vers le client, donc le port est celui que le client a indiqué précedement dans son message montant
Loïc Proucèze
nicolas a écrit :
Le Fri, 01 Oct 2004 19:35:03 +0200, Loïc Prouvèze nous exposa quelques reflexions personnelles :
Dans l'exemple que tu donnes, je comprends que shorewall a bloqué un message partant du serveur (.1.1) ,SPT (source port) = 8767 vers le client (.1.20) , DST (destination port) = 2140
Or quand je regarde tes règles, celà me parait normal, puisqu'il n'y a pas de règle laissant passer le 8767 comme port source. (8767 est donné dans tes règles toujours comme port destination).
Tiens, j'avais pas remarqué le DST!40
C'est quand même bizarre... Il choisi un port aléatoirement au lieu de reprendre par défaut celui qui est défini dans la règle...
Je pense qu'il s'agit ici du message de retour vers le client, donc le port est celui que le client a indiqué précedement dans son message montant
Si je comprend bien, le client lancant la demande au serveur décide du port sur lequel va se faire leur communication ?
J'avais déjà remarquer ce phénomène avec ssh dont le port par défaut était bien désigné mais un logiciel me signalait que Open SSH utilisait un autre port pour communiquer... Enfin, si j'ai bien tout compris... :-/
nicolas a écrit :
Le Fri, 01 Oct 2004 19:35:03 +0200, Loïc Prouvèze nous exposa quelques
reflexions personnelles :
Dans l'exemple que tu donnes, je comprends que shorewall a bloqué un
message partant du serveur (.1.1) ,SPT (source port) = 8767 vers le
client
(.1.20) , DST (destination port) = 2140
Or quand je regarde tes règles, celà me parait normal, puisqu'il n'y a
pas de règle laissant passer le 8767 comme port source. (8767 est donné
dans tes règles toujours comme port destination).
Tiens, j'avais pas remarqué le DST!40
C'est quand même bizarre... Il choisi un port aléatoirement au
lieu de reprendre par défaut celui qui est défini dans la règle...
Je pense qu'il s'agit ici du message de retour vers le client, donc le
port est celui que le client a indiqué précedement dans son message
montant
Si je comprend bien, le client lancant la demande au serveur
décide du port sur lequel va se faire leur communication ?
J'avais déjà remarquer ce phénomène avec ssh dont le port par
défaut était bien désigné mais un logiciel me signalait que Open
SSH utilisait un autre port pour communiquer...
Enfin, si j'ai bien tout compris... :-/
Le Fri, 01 Oct 2004 19:35:03 +0200, Loïc Prouvèze nous exposa quelques reflexions personnelles :
Dans l'exemple que tu donnes, je comprends que shorewall a bloqué un message partant du serveur (.1.1) ,SPT (source port) = 8767 vers le client (.1.20) , DST (destination port) = 2140
Or quand je regarde tes règles, celà me parait normal, puisqu'il n'y a pas de règle laissant passer le 8767 comme port source. (8767 est donné dans tes règles toujours comme port destination).
Tiens, j'avais pas remarqué le DST!40
C'est quand même bizarre... Il choisi un port aléatoirement au lieu de reprendre par défaut celui qui est défini dans la règle...
Je pense qu'il s'agit ici du message de retour vers le client, donc le port est celui que le client a indiqué précedement dans son message montant
Si je comprend bien, le client lancant la demande au serveur décide du port sur lequel va se faire leur communication ?
J'avais déjà remarquer ce phénomène avec ssh dont le port par défaut était bien désigné mais un logiciel me signalait que Open SSH utilisait un autre port pour communiquer... Enfin, si j'ai bien tout compris... :-/
Loïc Prouvèze
Loïc Prouvèze a écrit :
Loïc Prouvèze a écrit :
nicolas a écrit :
Attention à bien tenir compte du port source et du port destination, ils faut les paramétrer séparément.
Ha... Je me disais bien que c'était quelque chose dans ce goût là...
Merci !
C'était bien ça ! En fait, mon fichier rules ressemble maintenant à ça :
ACCEPT net fw udp 8767 - ACCEPT net fw udp - 8767 ACCEPT fw net udp 8767 - ACCEPT fw net udp - 8767 ACCEPT loc fw udp 8767 - ACCEPT loc fw udp - 8767 ACCEPT fw loc udp 8767 - ACCEPT fw loc udp - 8767
Puisque j'y suis, j'en profite pour demander à Nicolas et aux autres :-)...
J'ai scanner les ports de mon serveur avec nmap et je trouve les ports suivant ouverts :
111/tcp open rpcbind 139/tcp open netbios-ssn 445/tcp open microsoft-ds
Alors que je n'ai ouvert que les ports suivant avec shorewall : 80,443,20,21,25,109,110,143,10000
Comment cela peut-il ce produire ? Et comment je peux fermer ces ports ?
Merci d'avance, Loïc.
Loïc Prouvèze a écrit :
Loïc Prouvèze a écrit :
nicolas a écrit :
Attention à bien tenir compte du port source et du port destination, ils
faut les paramétrer séparément.
Ha... Je me disais bien que c'était quelque chose dans ce goût là...
Merci !
C'était bien ça ! En fait, mon fichier rules ressemble maintenant à ça :
ACCEPT net fw udp 8767 -
ACCEPT net fw udp - 8767
ACCEPT fw net udp 8767 -
ACCEPT fw net udp - 8767
ACCEPT loc fw udp 8767 -
ACCEPT loc fw udp - 8767
ACCEPT fw loc udp 8767 -
ACCEPT fw loc udp - 8767
Puisque j'y suis, j'en profite pour demander à Nicolas et aux
autres :-)...
J'ai scanner les ports de mon serveur avec nmap et je trouve les
ports suivant ouverts :
111/tcp open rpcbind
139/tcp open netbios-ssn
445/tcp open microsoft-ds
Alors que je n'ai ouvert que les ports suivant avec shorewall :
80,443,20,21,25,109,110,143,10000
Comment cela peut-il ce produire ?
Et comment je peux fermer ces ports ?
Attention à bien tenir compte du port source et du port destination, ils faut les paramétrer séparément.
Ha... Je me disais bien que c'était quelque chose dans ce goût là...
Merci !
C'était bien ça ! En fait, mon fichier rules ressemble maintenant à ça :
ACCEPT net fw udp 8767 - ACCEPT net fw udp - 8767 ACCEPT fw net udp 8767 - ACCEPT fw net udp - 8767 ACCEPT loc fw udp 8767 - ACCEPT loc fw udp - 8767 ACCEPT fw loc udp 8767 - ACCEPT fw loc udp - 8767
Puisque j'y suis, j'en profite pour demander à Nicolas et aux autres :-)...
J'ai scanner les ports de mon serveur avec nmap et je trouve les ports suivant ouverts :
111/tcp open rpcbind 139/tcp open netbios-ssn 445/tcp open microsoft-ds
Alors que je n'ai ouvert que les ports suivant avec shorewall : 80,443,20,21,25,109,110,143,10000
Comment cela peut-il ce produire ? Et comment je peux fermer ces ports ?
Merci d'avance, Loïc.
nicolas
Le Sat, 02 Oct 2004 20:13:31 +0200, Loïc Prouvèze nous exposa quelques reflexions personnelles :
Loïc Prouvèze a écrit :
Loïc Prouvèze a écrit :
nicolas a écrit :
Attention à bien tenir compte du port source et du port destination, ils faut les paramétrer séparément.
Ha... Je me disais bien que c'était quelque chose dans ce goût là...
Merci !
C'était bien ça ! En fait, mon fichier rules ressemble maintenant à ça :
ACCEPT net fw udp 8767 - ACCEPT net fw udp - 8767 ACCEPT fw net udp 8767 - ACCEPT fw net udp - 8767 ACCEPT loc fw udp 8767 - ACCEPT loc fw udp - 8767 ACCEPT fw loc udp 8767 - ACCEPT fw loc udp - 8767
Puisque j'y suis, j'en profite pour demander à Nicolas et aux autres :-)...
J'ai scanner les ports de mon serveur avec nmap et je trouve les ports suivant ouverts :
111/tcp open rpcbind 139/tcp open netbios-ssn 445/tcp open microsoft-ds
Alors que je n'ai ouvert que les ports suivant avec shorewall : 80,443,20,21,25,109,110,143,10000
Comment cela peut-il ce produire ? Et comment je peux fermer ces ports ?
Merci d'avance, Loïc.
nmap recense les ports pour lesquels il constate une possibilité de connexion, cad ceux pour lesquels il voit un serveur en écoute. Celà ne signifie pas forcément que les ports soient visibles depuis le réseau, justement à cause du firewall.
Les ports 139 et 445 (NetBIOS) sont ouverts très certainement par samba. Si le firewall ne laisse pas passer ces ports, tu ne pourra pas faire du partage réseau avec des postes windows.
le 111 correspond aux services rpc.
Si tu veux savoir comment ton réseau est visible depuis l'internet, essaies les 2 sites suivants :
Le Sat, 02 Oct 2004 20:13:31 +0200, Loïc Prouvèze nous exposa quelques
reflexions personnelles :
Loïc Prouvèze a écrit :
Loïc Prouvèze a écrit :
nicolas a écrit :
Attention à bien tenir compte du port source et du port destination, ils
faut les paramétrer séparément.
Ha... Je me disais bien que c'était quelque chose dans ce goût là...
Merci !
C'était bien ça ! En fait, mon fichier rules ressemble maintenant à ça :
ACCEPT net fw udp 8767 -
ACCEPT net fw udp - 8767
ACCEPT fw net udp 8767 -
ACCEPT fw net udp - 8767
ACCEPT loc fw udp 8767 -
ACCEPT loc fw udp - 8767
ACCEPT fw loc udp 8767 -
ACCEPT fw loc udp - 8767
Puisque j'y suis, j'en profite pour demander à Nicolas et aux
autres :-)...
J'ai scanner les ports de mon serveur avec nmap et je trouve les
ports suivant ouverts :
111/tcp open rpcbind
139/tcp open netbios-ssn
445/tcp open microsoft-ds
Alors que je n'ai ouvert que les ports suivant avec shorewall :
80,443,20,21,25,109,110,143,10000
Comment cela peut-il ce produire ?
Et comment je peux fermer ces ports ?
Merci d'avance,
Loïc.
nmap recense les ports pour lesquels il constate une possibilité de
connexion, cad ceux pour lesquels il voit un serveur en écoute. Celà ne
signifie pas forcément que les ports soient visibles depuis le réseau,
justement à cause du firewall.
Les ports 139 et 445 (NetBIOS) sont ouverts très certainement par samba.
Si le firewall ne laisse pas passer ces ports, tu ne pourra pas faire du
partage réseau avec des postes windows.
le 111 correspond aux services rpc.
Si tu veux savoir comment ton réseau est visible depuis l'internet,
essaies les 2 sites suivants :
Le Sat, 02 Oct 2004 20:13:31 +0200, Loïc Prouvèze nous exposa quelques reflexions personnelles :
Loïc Prouvèze a écrit :
Loïc Prouvèze a écrit :
nicolas a écrit :
Attention à bien tenir compte du port source et du port destination, ils faut les paramétrer séparément.
Ha... Je me disais bien que c'était quelque chose dans ce goût là...
Merci !
C'était bien ça ! En fait, mon fichier rules ressemble maintenant à ça :
ACCEPT net fw udp 8767 - ACCEPT net fw udp - 8767 ACCEPT fw net udp 8767 - ACCEPT fw net udp - 8767 ACCEPT loc fw udp 8767 - ACCEPT loc fw udp - 8767 ACCEPT fw loc udp 8767 - ACCEPT fw loc udp - 8767
Puisque j'y suis, j'en profite pour demander à Nicolas et aux autres :-)...
J'ai scanner les ports de mon serveur avec nmap et je trouve les ports suivant ouverts :
111/tcp open rpcbind 139/tcp open netbios-ssn 445/tcp open microsoft-ds
Alors que je n'ai ouvert que les ports suivant avec shorewall : 80,443,20,21,25,109,110,143,10000
Comment cela peut-il ce produire ? Et comment je peux fermer ces ports ?
Merci d'avance, Loïc.
nmap recense les ports pour lesquels il constate une possibilité de connexion, cad ceux pour lesquels il voit un serveur en écoute. Celà ne signifie pas forcément que les ports soient visibles depuis le réseau, justement à cause du firewall.
Les ports 139 et 445 (NetBIOS) sont ouverts très certainement par samba. Si le firewall ne laisse pas passer ces ports, tu ne pourra pas faire du partage réseau avec des postes windows.
le 111 correspond aux services rpc.
Si tu veux savoir comment ton réseau est visible depuis l'internet, essaies les 2 sites suivants :
