Bonjour,
J'ai configuré Kerio PF de la façon suivante pour les paquets ICMP :
Autorisation dans les deux sens pour :
- [0] Echo Reply et [8] Echo Request pour autoriser le ping dans les
deux sens (utile pour le p2p)
- [4] Source Quench, qui d'après ce que j'ai pu lire, sert aux hôtes à
signaler que l'expéditeur des données va trop vite (je pense aussi que
c'est utile pour le p2p)
- [11] Time Exceeded : je pense qu'il peut servir dans les 2 sens avec
le p2p
- [10] Router Solicitation : apparemment il faut l'autoriser dans les
deux sens, l'une pour la requête, l'autre pour la réponse. Mais est-il
vraiment utile ? J'ai vu quand je le bloquais que ça se trouvait
souvent dans mes logs en début de connexion.
Autorisation dans le sens entrant :
- [3] Destination Unreachable
Et je bloque tout le reste. Or mon log est plein de paquets Destination
Unreachable sortants. Qu'est-ce que ça signifie ? Est-il utile de le
bloquer ?
Plus généralement, ma configuration vous paraît-elle correcte ?
--
L'ennui dans ce monde, c'est que les idiots sont sûr d'eux et les gens
sensés pleins de doutes. (Bertrand Russell)
Bonjour,
J'ai configuré Kerio PF de la façon suivante pour les paquets ICMP :
Autorisation dans les deux sens pour :
- [0] Echo Reply et [8] Echo Request pour autoriser le ping dans les
deux sens (utile pour le p2p)
- [4] Source Quench, qui d'après ce que j'ai pu lire, sert aux hôtes à
signaler que l'expéditeur des données va trop vite (je pense aussi que
c'est utile pour le p2p)
- [11] Time Exceeded : je pense qu'il peut servir dans les 2 sens avec
le p2p
- [10] Router Solicitation : apparemment il faut l'autoriser dans les
deux sens, l'une pour la requête, l'autre pour la réponse. Mais est-il
vraiment utile ? J'ai vu quand je le bloquais que ça se trouvait
souvent dans mes logs en début de connexion.
Autorisation dans le sens entrant :
- [3] Destination Unreachable
Et je bloque tout le reste. Or mon log est plein de paquets Destination
Unreachable sortants. Qu'est-ce que ça signifie ? Est-il utile de le
bloquer ?
Plus généralement, ma configuration vous paraît-elle correcte ?
--
L'ennui dans ce monde, c'est que les idiots sont sûr d'eux et les gens
sensés pleins de doutes. (Bertrand Russell)
Bonjour,
J'ai configuré Kerio PF de la façon suivante pour les paquets ICMP :
Autorisation dans les deux sens pour :
- [0] Echo Reply et [8] Echo Request pour autoriser le ping dans les
deux sens (utile pour le p2p)
- [4] Source Quench, qui d'après ce que j'ai pu lire, sert aux hôtes à
signaler que l'expéditeur des données va trop vite (je pense aussi que
c'est utile pour le p2p)
- [11] Time Exceeded : je pense qu'il peut servir dans les 2 sens avec
le p2p
- [10] Router Solicitation : apparemment il faut l'autoriser dans les
deux sens, l'une pour la requête, l'autre pour la réponse. Mais est-il
vraiment utile ? J'ai vu quand je le bloquais que ça se trouvait
souvent dans mes logs en début de connexion.
Autorisation dans le sens entrant :
- [3] Destination Unreachable
Et je bloque tout le reste. Or mon log est plein de paquets Destination
Unreachable sortants. Qu'est-ce que ça signifie ? Est-il utile de le
bloquer ?
Plus généralement, ma configuration vous paraît-elle correcte ?
--
L'ennui dans ce monde, c'est que les idiots sont sûr d'eux et les gens
sensés pleins de doutes. (Bertrand Russell)
Bonjour,
J'ai configuré Kerio PF de la façon suivante pour les paquets ICMP :
Autorisation dans les deux sens pour :
- [0] Echo Reply et [8] Echo Request pour autoriser le ping dans les
deux sens (utile pour le p2p)
- [4] Source Quench, qui d'après ce que j'ai pu lire, sert aux hôtes à
signaler que l'expéditeur des données va trop vite (je pense aussi que
c'est utile pour le p2p)
- [11] Time Exceeded : je pense qu'il peut servir dans les 2 sens avec
le p2p
- [10] Router Solicitation : apparemment il faut l'autoriser dans les
deux sens, l'une pour la requête, l'autre pour la réponse. Mais est-il
vraiment utile ? J'ai vu quand je le bloquais que ça se trouvait
souvent dans mes logs en début de connexion.
Autorisation dans le sens entrant :
- [3] Destination Unreachable
Et je bloque tout le reste. Or mon log est plein de paquets Destination
Unreachable sortants. Qu'est-ce que ça signifie ? Est-il utile de le
bloquer ?
Plus généralement, ma configuration vous paraît-elle correcte ?
Bonjour,
J'ai configuré Kerio PF de la façon suivante pour les paquets ICMP :
Autorisation dans les deux sens pour :
- [0] Echo Reply et [8] Echo Request pour autoriser le ping dans les
deux sens (utile pour le p2p)
- [4] Source Quench, qui d'après ce que j'ai pu lire, sert aux hôtes à
signaler que l'expéditeur des données va trop vite (je pense aussi que
c'est utile pour le p2p)
- [11] Time Exceeded : je pense qu'il peut servir dans les 2 sens avec
le p2p
- [10] Router Solicitation : apparemment il faut l'autoriser dans les
deux sens, l'une pour la requête, l'autre pour la réponse. Mais est-il
vraiment utile ? J'ai vu quand je le bloquais que ça se trouvait
souvent dans mes logs en début de connexion.
Autorisation dans le sens entrant :
- [3] Destination Unreachable
Et je bloque tout le reste. Or mon log est plein de paquets Destination
Unreachable sortants. Qu'est-ce que ça signifie ? Est-il utile de le
bloquer ?
Plus généralement, ma configuration vous paraît-elle correcte ?
Bonjour,
J'ai configuré Kerio PF de la façon suivante pour les paquets ICMP :
Autorisation dans les deux sens pour :
- [0] Echo Reply et [8] Echo Request pour autoriser le ping dans les
deux sens (utile pour le p2p)
- [4] Source Quench, qui d'après ce que j'ai pu lire, sert aux hôtes à
signaler que l'expéditeur des données va trop vite (je pense aussi que
c'est utile pour le p2p)
- [11] Time Exceeded : je pense qu'il peut servir dans les 2 sens avec
le p2p
- [10] Router Solicitation : apparemment il faut l'autoriser dans les
deux sens, l'une pour la requête, l'autre pour la réponse. Mais est-il
vraiment utile ? J'ai vu quand je le bloquais que ça se trouvait
souvent dans mes logs en début de connexion.
Autorisation dans le sens entrant :
- [3] Destination Unreachable
Et je bloque tout le reste. Or mon log est plein de paquets Destination
Unreachable sortants. Qu'est-ce que ça signifie ? Est-il utile de le
bloquer ?
Plus généralement, ma configuration vous paraît-elle correcte ?
Fais gaffe au p2p.
Perso j'en faisais avec un deny complet d'icmp.
Mais si tu as ce type de paquet dans tes logs ton fw ne doit pas être
très bien configuré.
Ne fais pas de "reject" des services non autorisés en entrée, préfère
un "deny".
Plus généralement, ma configuration vous paraît-elle correcte ?
Il nous faudrait la liste complète de tes règles pour juger.
Fais gaffe au p2p.
Perso j'en faisais avec un deny complet d'icmp.
Mais si tu as ce type de paquet dans tes logs ton fw ne doit pas être
très bien configuré.
Ne fais pas de "reject" des services non autorisés en entrée, préfère
un "deny".
Plus généralement, ma configuration vous paraît-elle correcte ?
Il nous faudrait la liste complète de tes règles pour juger.
Fais gaffe au p2p.
Perso j'en faisais avec un deny complet d'icmp.
Mais si tu as ce type de paquet dans tes logs ton fw ne doit pas être
très bien configuré.
Ne fais pas de "reject" des services non autorisés en entrée, préfère
un "deny".
Plus généralement, ma configuration vous paraît-elle correcte ?
Il nous faudrait la liste complète de tes règles pour juger.
ddevil, in :Fais gaffe au p2p.
J'ai jamais constaté de problème avec.
Perso j'en faisais avec un deny complet d'icmp.
Et comment ta machine fait pour
- savoir qu'une IP/un port n'est pas accessible ?
- faire et recevoir des pings (utile pour trouver la source la plus
rapide) ?
- savoir et faire savoir que le délai de connexion est dépassé ?
- savoir et faire savoir que le débit est trop élevé ?
Mais si tu as ce type de paquet dans tes logs ton fw ne doit pas être
très bien configuré.
Ne fais pas de "reject" des services non autorisés en entrée, préfère
un "deny".
J'ai pas la possibilité de le configurer. Mais il me semble, d'après des
tests en ligne que j'ai fait, que Kerio PF est en mode 'stealth", et
donc ne renvoie rien quand il refuse un paquet. Je pense que les
'destination unreachable' sortants que j'ai dans mon log, trop peu
nombreux pour être des refus du firewall, viennent en fait de réponses
de mon poste à des demandes de connexion p2p, qui parviennent un temps
encore après la fermeture de l'application.
En effet, ces paquets
servent aussi à signaler qu'un port n'est pas ouvert.
Je vais donc les autoriser en sortie également.
Plus généralement, ma configuration vous paraît-elle correcte ?
Il nous faudrait la liste complète de tes règles pour juger.
Je parlais de ma config pour ICMP, et elle est toute là.
ddevil, in <180d162b.0309220247.2d348f1d@posting.google.com> :
Fais gaffe au p2p.
J'ai jamais constaté de problème avec.
Perso j'en faisais avec un deny complet d'icmp.
Et comment ta machine fait pour
- savoir qu'une IP/un port n'est pas accessible ?
- faire et recevoir des pings (utile pour trouver la source la plus
rapide) ?
- savoir et faire savoir que le délai de connexion est dépassé ?
- savoir et faire savoir que le débit est trop élevé ?
Mais si tu as ce type de paquet dans tes logs ton fw ne doit pas être
très bien configuré.
Ne fais pas de "reject" des services non autorisés en entrée, préfère
un "deny".
J'ai pas la possibilité de le configurer. Mais il me semble, d'après des
tests en ligne que j'ai fait, que Kerio PF est en mode 'stealth", et
donc ne renvoie rien quand il refuse un paquet. Je pense que les
'destination unreachable' sortants que j'ai dans mon log, trop peu
nombreux pour être des refus du firewall, viennent en fait de réponses
de mon poste à des demandes de connexion p2p, qui parviennent un temps
encore après la fermeture de l'application.
En effet, ces paquets
servent aussi à signaler qu'un port n'est pas ouvert.
Je vais donc les autoriser en sortie également.
Plus généralement, ma configuration vous paraît-elle correcte ?
Il nous faudrait la liste complète de tes règles pour juger.
Je parlais de ma config pour ICMP, et elle est toute là.
ddevil, in :Fais gaffe au p2p.
J'ai jamais constaté de problème avec.
Perso j'en faisais avec un deny complet d'icmp.
Et comment ta machine fait pour
- savoir qu'une IP/un port n'est pas accessible ?
- faire et recevoir des pings (utile pour trouver la source la plus
rapide) ?
- savoir et faire savoir que le délai de connexion est dépassé ?
- savoir et faire savoir que le débit est trop élevé ?
Mais si tu as ce type de paquet dans tes logs ton fw ne doit pas être
très bien configuré.
Ne fais pas de "reject" des services non autorisés en entrée, préfère
un "deny".
J'ai pas la possibilité de le configurer. Mais il me semble, d'après des
tests en ligne que j'ai fait, que Kerio PF est en mode 'stealth", et
donc ne renvoie rien quand il refuse un paquet. Je pense que les
'destination unreachable' sortants que j'ai dans mon log, trop peu
nombreux pour être des refus du firewall, viennent en fait de réponses
de mon poste à des demandes de connexion p2p, qui parviennent un temps
encore après la fermeture de l'application.
En effet, ces paquets
servent aussi à signaler qu'un port n'est pas ouvert.
Je vais donc les autoriser en sortie également.
Plus généralement, ma configuration vous paraît-elle correcte ?
Il nous faudrait la liste complète de tes règles pour juger.
Je parlais de ma config pour ICMP, et elle est toute là.
Stephane Faure wrote in messagePerso j'en faisais avec un deny complet d'icmp.
Et comment ta machine fait pour
- savoir qu'une IP/un port n'est pas accessible ?
- faire et recevoir des pings (utile pour trouver la source la
plus rapide) ?
- savoir et faire savoir que le délai de connexion est dépassé ?
- savoir et faire savoir que le débit est trop élevé ?
Elle ne faisait pas.
Je sais, monsieur RFC va surement me fouetter et me faire subir
les pires tortures pour ces manquements.
Stephane Faure <mysterion@alussinan.org> wrote in message
Perso j'en faisais avec un deny complet d'icmp.
Et comment ta machine fait pour
- savoir qu'une IP/un port n'est pas accessible ?
- faire et recevoir des pings (utile pour trouver la source la
plus rapide) ?
- savoir et faire savoir que le délai de connexion est dépassé ?
- savoir et faire savoir que le débit est trop élevé ?
Elle ne faisait pas.
Je sais, monsieur RFC va surement me fouetter et me faire subir
les pires tortures pour ces manquements.
Stephane Faure wrote in messagePerso j'en faisais avec un deny complet d'icmp.
Et comment ta machine fait pour
- savoir qu'une IP/un port n'est pas accessible ?
- faire et recevoir des pings (utile pour trouver la source la
plus rapide) ?
- savoir et faire savoir que le délai de connexion est dépassé ?
- savoir et faire savoir que le débit est trop élevé ?
Elle ne faisait pas.
Je sais, monsieur RFC va surement me fouetter et me faire subir
les pires tortures pour ces manquements.
Généralement quand on constate c'est déjà trop tard.
Et comment ta machine fait pour
- savoir qu'une IP/un port n'est pas accessible ?
- faire et recevoir des pings (utile pour trouver la source la plus
rapide) ?
- savoir et faire savoir que le délai de connexion est dépassé ?
- savoir et faire savoir que le débit est trop élevé ?
Elle ne faisait pas.
Je sais, monsieur RFC va surement me fouetter et me faire subir les
pires tortures pour ces manquements.
Je pense que les
'destination unreachable' sortants que j'ai dans mon log, trop peu
nombreux pour être des refus du firewall, viennent en fait de réponses
de mon poste à des demandes de connexion p2p, qui parviennent un temps
encore après la fermeture de l'application.
Possible. A vérifier
En effet, ces paquets
servent aussi à signaler qu'un port n'est pas ouvert.
Toutafait.
Et tu ne conclus rien de cette affirmation ?
Je parlais de ma config pour ICMP, et elle est toute là.
Perso je ne l'installerai pas chez moi.
Généralement quand on constate c'est déjà trop tard.
Et comment ta machine fait pour
- savoir qu'une IP/un port n'est pas accessible ?
- faire et recevoir des pings (utile pour trouver la source la plus
rapide) ?
- savoir et faire savoir que le délai de connexion est dépassé ?
- savoir et faire savoir que le débit est trop élevé ?
Elle ne faisait pas.
Je sais, monsieur RFC va surement me fouetter et me faire subir les
pires tortures pour ces manquements.
Je pense que les
'destination unreachable' sortants que j'ai dans mon log, trop peu
nombreux pour être des refus du firewall, viennent en fait de réponses
de mon poste à des demandes de connexion p2p, qui parviennent un temps
encore après la fermeture de l'application.
Possible. A vérifier
En effet, ces paquets
servent aussi à signaler qu'un port n'est pas ouvert.
Toutafait.
Et tu ne conclus rien de cette affirmation ?
Je parlais de ma config pour ICMP, et elle est toute là.
Perso je ne l'installerai pas chez moi.
Généralement quand on constate c'est déjà trop tard.
Et comment ta machine fait pour
- savoir qu'une IP/un port n'est pas accessible ?
- faire et recevoir des pings (utile pour trouver la source la plus
rapide) ?
- savoir et faire savoir que le délai de connexion est dépassé ?
- savoir et faire savoir que le débit est trop élevé ?
Elle ne faisait pas.
Je sais, monsieur RFC va surement me fouetter et me faire subir les
pires tortures pour ces manquements.
Je pense que les
'destination unreachable' sortants que j'ai dans mon log, trop peu
nombreux pour être des refus du firewall, viennent en fait de réponses
de mon poste à des demandes de connexion p2p, qui parviennent un temps
encore après la fermeture de l'application.
Possible. A vérifier
En effet, ces paquets
servent aussi à signaler qu'un port n'est pas ouvert.
Toutafait.
Et tu ne conclus rien de cette affirmation ?
Je parlais de ma config pour ICMP, et elle est toute là.
Perso je ne l'installerai pas chez moi.
ddevil nous disait récement dans fr.comp.securite
<news: :Stephane Faure wrote in messagePerso j'en faisais avec un deny complet d'icmp.
Et comment ta machine fait pour
- savoir qu'une IP/un port n'est pas accessible ?
- faire et recevoir des pings (utile pour trouver la source la
plus rapide) ?
- savoir et faire savoir que le délai de connexion est dépassé ?
- savoir et faire savoir que le débit est trop élevé ?
Elle ne faisait pas.
Je sais, monsieur RFC va surement me fouetter et me faire subir
les pires tortures pour ces manquements.
Ce n'est pas que monsieur RFC ne sera pas content, mais en filtrant
les messages ICMP d'erreurs, ton navigateur (et en fait tout tes
clients réseau) vont pédaler dans le vide à la moindre erreur, et tu ne
sauras pas pourquoi. Maintenant, si tu préfères "surfer" à
l'aveuglette, cela reste ton choix.
ddevil nous disait récement dans fr.comp.securite
<news:180d162b.0309290217.7786e29b@posting.google.com> :
Stephane Faure <mysterion@alussinan.org> wrote in message
Perso j'en faisais avec un deny complet d'icmp.
Et comment ta machine fait pour
- savoir qu'une IP/un port n'est pas accessible ?
- faire et recevoir des pings (utile pour trouver la source la
plus rapide) ?
- savoir et faire savoir que le délai de connexion est dépassé ?
- savoir et faire savoir que le débit est trop élevé ?
Elle ne faisait pas.
Je sais, monsieur RFC va surement me fouetter et me faire subir
les pires tortures pour ces manquements.
Ce n'est pas que monsieur RFC ne sera pas content, mais en filtrant
les messages ICMP d'erreurs, ton navigateur (et en fait tout tes
clients réseau) vont pédaler dans le vide à la moindre erreur, et tu ne
sauras pas pourquoi. Maintenant, si tu préfères "surfer" à
l'aveuglette, cela reste ton choix.
ddevil nous disait récement dans fr.comp.securite
<news: :Stephane Faure wrote in messagePerso j'en faisais avec un deny complet d'icmp.
Et comment ta machine fait pour
- savoir qu'une IP/un port n'est pas accessible ?
- faire et recevoir des pings (utile pour trouver la source la
plus rapide) ?
- savoir et faire savoir que le délai de connexion est dépassé ?
- savoir et faire savoir que le débit est trop élevé ?
Elle ne faisait pas.
Je sais, monsieur RFC va surement me fouetter et me faire subir
les pires tortures pour ces manquements.
Ce n'est pas que monsieur RFC ne sera pas content, mais en filtrant
les messages ICMP d'erreurs, ton navigateur (et en fait tout tes
clients réseau) vont pédaler dans le vide à la moindre erreur, et tu ne
sauras pas pourquoi. Maintenant, si tu préfères "surfer" à
l'aveuglette, cela reste ton choix.
ddevil, in :Généralement quand on constate c'est déjà trop tard.
Très rarement, quand on est prudent, ou qu'on a un firewall bien
configuré ou un antivirus (même non permanent). En 5 ans d'Internet par
RTC, les seuls problèmes que j'ai connus ont été les spywares, et les
virus, que je n'ai jamais ouverts. Et les lenteurs...Et comment ta machine fait pour
- savoir qu'une IP/un port n'est pas accessible ?
- faire et recevoir des pings (utile pour trouver la source la plus
rapide) ?
- savoir et faire savoir que le délai de connexion est dépassé ?
- savoir et faire savoir que le débit est trop élevé ?
Elle ne faisait pas.
Je sais, monsieur RFC va surement me fouetter et me faire subir les
pires tortures pour ces manquements.
C'est surtout que tu devais y perdre en performances, vu que ta machine
devait attendre son propre timeout plutôt que d'apprendre par ICMP
qu'une connexion était impossible. Et réciproquement.
Je pense que les
'destination unreachable' sortants que j'ai dans mon log, trop peu
nombreux pour être des refus du firewall, viennent en fait de réponses
de mon poste à des demandes de connexion p2p, qui parviennent un temps
encore après la fermeture de l'application.
Possible. A vérifier
Ca n'est pas ça en fait, je viens de remarquer que presque tous ces
paquets sont envoyés à mes DNS. A quoi cela sert-il ?
Par ailleurs, Kerio est sensé bloquer les paquets qui arrivent sur un
port non ouvert, donc ne pas générer de réponse.
Autre curiosités, j'ai eu quelques tentatives de connexion par le port
1214 (utilisé normalement par Kazaa) sur mon proxy local, qui écoute sur
un autre port (et uniquement en provenance de 127.0.0.1). J'ai aussi eu
des tentatives de connexion sur son véritable port d'écoute, venant de
mailgate.pegasus-internet.net et de 216.82.127.46. Un testeur de proxy
ouvert ? Une tentative de détournement ?
En effet, ces paquets
servent aussi à signaler qu'un port n'est pas ouvert.
Toutafait.
Et tu ne conclus rien de cette affirmation ?
Qu'il faut les autoriser pour éviter des ralentissements et l'envoi
d'autres paquets inutiles ?
Je parlais de ma config pour ICMP, et elle est toute là.
Perso je ne l'installerai pas chez moi.
J'espère que vous ne reprochez pas à Sarkozy sa politique
(pseudo-)sécuritaire...
ddevil, in <180d162b.0309290217.7786e29b@posting.google.com> :
Généralement quand on constate c'est déjà trop tard.
Très rarement, quand on est prudent, ou qu'on a un firewall bien
configuré ou un antivirus (même non permanent). En 5 ans d'Internet par
RTC, les seuls problèmes que j'ai connus ont été les spywares, et les
virus, que je n'ai jamais ouverts. Et les lenteurs...
Et comment ta machine fait pour
- savoir qu'une IP/un port n'est pas accessible ?
- faire et recevoir des pings (utile pour trouver la source la plus
rapide) ?
- savoir et faire savoir que le délai de connexion est dépassé ?
- savoir et faire savoir que le débit est trop élevé ?
Elle ne faisait pas.
Je sais, monsieur RFC va surement me fouetter et me faire subir les
pires tortures pour ces manquements.
C'est surtout que tu devais y perdre en performances, vu que ta machine
devait attendre son propre timeout plutôt que d'apprendre par ICMP
qu'une connexion était impossible. Et réciproquement.
Je pense que les
'destination unreachable' sortants que j'ai dans mon log, trop peu
nombreux pour être des refus du firewall, viennent en fait de réponses
de mon poste à des demandes de connexion p2p, qui parviennent un temps
encore après la fermeture de l'application.
Possible. A vérifier
Ca n'est pas ça en fait, je viens de remarquer que presque tous ces
paquets sont envoyés à mes DNS. A quoi cela sert-il ?
Par ailleurs, Kerio est sensé bloquer les paquets qui arrivent sur un
port non ouvert, donc ne pas générer de réponse.
Autre curiosités, j'ai eu quelques tentatives de connexion par le port
1214 (utilisé normalement par Kazaa) sur mon proxy local, qui écoute sur
un autre port (et uniquement en provenance de 127.0.0.1). J'ai aussi eu
des tentatives de connexion sur son véritable port d'écoute, venant de
mailgate.pegasus-internet.net et de 216.82.127.46. Un testeur de proxy
ouvert ? Une tentative de détournement ?
En effet, ces paquets
servent aussi à signaler qu'un port n'est pas ouvert.
Toutafait.
Et tu ne conclus rien de cette affirmation ?
Qu'il faut les autoriser pour éviter des ralentissements et l'envoi
d'autres paquets inutiles ?
Je parlais de ma config pour ICMP, et elle est toute là.
Perso je ne l'installerai pas chez moi.
J'espère que vous ne reprochez pas à Sarkozy sa politique
(pseudo-)sécuritaire...
ddevil, in :Généralement quand on constate c'est déjà trop tard.
Très rarement, quand on est prudent, ou qu'on a un firewall bien
configuré ou un antivirus (même non permanent). En 5 ans d'Internet par
RTC, les seuls problèmes que j'ai connus ont été les spywares, et les
virus, que je n'ai jamais ouverts. Et les lenteurs...Et comment ta machine fait pour
- savoir qu'une IP/un port n'est pas accessible ?
- faire et recevoir des pings (utile pour trouver la source la plus
rapide) ?
- savoir et faire savoir que le délai de connexion est dépassé ?
- savoir et faire savoir que le débit est trop élevé ?
Elle ne faisait pas.
Je sais, monsieur RFC va surement me fouetter et me faire subir les
pires tortures pour ces manquements.
C'est surtout que tu devais y perdre en performances, vu que ta machine
devait attendre son propre timeout plutôt que d'apprendre par ICMP
qu'une connexion était impossible. Et réciproquement.
Je pense que les
'destination unreachable' sortants que j'ai dans mon log, trop peu
nombreux pour être des refus du firewall, viennent en fait de réponses
de mon poste à des demandes de connexion p2p, qui parviennent un temps
encore après la fermeture de l'application.
Possible. A vérifier
Ca n'est pas ça en fait, je viens de remarquer que presque tous ces
paquets sont envoyés à mes DNS. A quoi cela sert-il ?
Par ailleurs, Kerio est sensé bloquer les paquets qui arrivent sur un
port non ouvert, donc ne pas générer de réponse.
Autre curiosités, j'ai eu quelques tentatives de connexion par le port
1214 (utilisé normalement par Kazaa) sur mon proxy local, qui écoute sur
un autre port (et uniquement en provenance de 127.0.0.1). J'ai aussi eu
des tentatives de connexion sur son véritable port d'écoute, venant de
mailgate.pegasus-internet.net et de 216.82.127.46. Un testeur de proxy
ouvert ? Une tentative de détournement ?
En effet, ces paquets
servent aussi à signaler qu'un port n'est pas ouvert.
Toutafait.
Et tu ne conclus rien de cette affirmation ?
Qu'il faut les autoriser pour éviter des ralentissements et l'envoi
d'autres paquets inutiles ?
Je parlais de ma config pour ICMP, et elle est toute là.
Perso je ne l'installerai pas chez moi.
J'espère que vous ne reprochez pas à Sarkozy sa politique
(pseudo-)sécuritaire...
Quand tu dis "mes DNS" tu veux parler des DNS de ton provider ?
Quel est le port précisé dans les messages "destination unreachable" ?
A moins que ce ne soient pas des "port unreachable".
Le plus simplement est peut-être que tu copies ici quelques lignes de
ton log.
Autre curiosités, j'ai eu quelques tentatives de connexion par le port
1214 (utilisé normalement par Kazaa) sur mon proxy local, qui écoute sur
un autre port (et uniquement en provenance de 127.0.0.1). J'ai aussi eu
des tentatives de connexion sur son véritable port d'écoute, venant de
mailgate.pegasus-internet.net et de 216.82.127.46. Un testeur de proxy
ouvert ? Une tentative de détournement ?
Si toutes ses connexions arrivent c'est bien qu'elles sont autorisés.
En effet, ces paquets
servent aussi à signaler qu'un port n'est pas ouvert.
Toutafait.
Et tu ne conclus rien de cette affirmation ?
Qu'il faut les autoriser pour éviter des ralentissements et l'envoi
d'autres paquets inutiles ?
Oui, ou qu'il faut les refuser pour éviter de se faire scanner
correctement.
Non, d'ailleurs je me suis installé un petit Sarkowall personnel il y
a quelques mois. Il me fait de belles stats avec pleins de chiffres et
en plus son éditeur prévoit pleins de nouvelles fonctions bientôt.
Quand tu dis "mes DNS" tu veux parler des DNS de ton provider ?
Quel est le port précisé dans les messages "destination unreachable" ?
A moins que ce ne soient pas des "port unreachable".
Le plus simplement est peut-être que tu copies ici quelques lignes de
ton log.
Autre curiosités, j'ai eu quelques tentatives de connexion par le port
1214 (utilisé normalement par Kazaa) sur mon proxy local, qui écoute sur
un autre port (et uniquement en provenance de 127.0.0.1). J'ai aussi eu
des tentatives de connexion sur son véritable port d'écoute, venant de
mailgate.pegasus-internet.net et de 216.82.127.46. Un testeur de proxy
ouvert ? Une tentative de détournement ?
Si toutes ses connexions arrivent c'est bien qu'elles sont autorisés.
En effet, ces paquets
servent aussi à signaler qu'un port n'est pas ouvert.
Toutafait.
Et tu ne conclus rien de cette affirmation ?
Qu'il faut les autoriser pour éviter des ralentissements et l'envoi
d'autres paquets inutiles ?
Oui, ou qu'il faut les refuser pour éviter de se faire scanner
correctement.
Non, d'ailleurs je me suis installé un petit Sarkowall personnel il y
a quelques mois. Il me fait de belles stats avec pleins de chiffres et
en plus son éditeur prévoit pleins de nouvelles fonctions bientôt.
Quand tu dis "mes DNS" tu veux parler des DNS de ton provider ?
Quel est le port précisé dans les messages "destination unreachable" ?
A moins que ce ne soient pas des "port unreachable".
Le plus simplement est peut-être que tu copies ici quelques lignes de
ton log.
Autre curiosités, j'ai eu quelques tentatives de connexion par le port
1214 (utilisé normalement par Kazaa) sur mon proxy local, qui écoute sur
un autre port (et uniquement en provenance de 127.0.0.1). J'ai aussi eu
des tentatives de connexion sur son véritable port d'écoute, venant de
mailgate.pegasus-internet.net et de 216.82.127.46. Un testeur de proxy
ouvert ? Une tentative de détournement ?
Si toutes ses connexions arrivent c'est bien qu'elles sont autorisés.
En effet, ces paquets
servent aussi à signaler qu'un port n'est pas ouvert.
Toutafait.
Et tu ne conclus rien de cette affirmation ?
Qu'il faut les autoriser pour éviter des ralentissements et l'envoi
d'autres paquets inutiles ?
Oui, ou qu'il faut les refuser pour éviter de se faire scanner
correctement.
Non, d'ailleurs je me suis installé un petit Sarkowall personnel il y
a quelques mois. Il me fait de belles stats avec pleins de chiffres et
en plus son éditeur prévoit pleins de nouvelles fonctions bientôt.