IPT forward, c'est le prefixe defini par log pour dire que c'est un paquet
bloque sur la chaine FORWARD de netfilter
SRC DPT et SPT sont tres varie, DST varie aussi, beaucoup moins, et indique
toujours (il me semble) une IP de mon FAI. Bien sur DST n'est jamais mon
adresse IP, sinon ca ne passerais pas dans la chaine FORWARD.
j'ai compte certain jours (et en fait assez frequemment) jusqu'a 15000
lignes de ce type dans mes logs!
je suis sur une connexion ADSL.
en fait, cela ne m'inquiete pas vraiment, je ne pense pas que cela pose un
probleme de securite (mais de perf?) , de toute facon, tout est bloque sur
le fw, mais j'aimerais comprendre!
Si je comprend bien, quelqu'un quelque part dit a ces paquets que pour
atteindre DST, il faut passer par chez moi? c'est un mensonge!
je me pose plusieurs question :
est ce :
un bruit normal (mais l'intensite est forte)
le symptome d'un pb de routage quelque part ? chez mon FAI?
est ce que cela peut etre lie au comportement tres retrictif de mon fw qui
ne repond rien a personne et bloque tout (hors services legitimes offerts
par le LAN). Si j'assouplissais les regles sur la chaine FORWARD et
laissait sortir des ICMP, est ce que cela pourrait indiquer aux routeurs
fautifs qu'ils sont dans l'erreur?
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
Pierre LALET
Cela ressemble à du scan de port TCP, malheureusement il n'y a rien à faire pour l'empecher, il suffit de le bloquer.
Ca n'explique pas pourquoi son FAI (HRNet apparemment) lui envoie ces paquets. AMHA ils ont un petit problème de routage, et il faut donc les prévenir.
Tu n'aurais pas un démon buggé qui annoncerait des routes à-la-con (tm) ? Ca m'étonnerait, parce qu'il faudrait un démon buggué (sacrément) et une config lamentable chez ton FAI (si leurs routeurs peuvent apprendre des routes de leurs clients, bonjour la sécurité...) mais on ne sait jamais.
Sinon, je ne vois qu'une (très) mauvaise config de leurs routeurs, et disons que quand un client s'est déconnecté, et que l'adresse n'est plus utilisée, les paquets qui lui sont destinés vont échouer n'importe où chez l'un de leurs clients (si c'est ça, c'est un peu une honte quand même).
Cela ressemble à du scan de port TCP, malheureusement il n'y a rien à faire pour l'empecher, il suffit de le bloquer.
Ca n'explique pas pourquoi son FAI (HRNet apparemment) lui envoie ces
paquets. AMHA ils ont un petit problème de routage, et il faut donc les
prévenir.
Tu n'aurais pas un démon buggé qui annoncerait des routes à-la-con (tm)
? Ca m'étonnerait, parce qu'il faudrait un démon buggué (sacrément) et
une config lamentable chez ton FAI (si leurs routeurs peuvent apprendre
des routes de leurs clients, bonjour la sécurité...) mais on ne sait jamais.
Sinon, je ne vois qu'une (très) mauvaise config de leurs routeurs, et
disons que quand un client s'est déconnecté, et que l'adresse n'est plus
utilisée, les paquets qui lui sont destinés vont échouer n'importe où
chez l'un de leurs clients (si c'est ça, c'est un peu une honte quand même).
Cela ressemble à du scan de port TCP, malheureusement il n'y a rien à faire pour l'empecher, il suffit de le bloquer.
Ca n'explique pas pourquoi son FAI (HRNet apparemment) lui envoie ces paquets. AMHA ils ont un petit problème de routage, et il faut donc les prévenir.
Tu n'aurais pas un démon buggé qui annoncerait des routes à-la-con (tm) ? Ca m'étonnerait, parce qu'il faudrait un démon buggué (sacrément) et une config lamentable chez ton FAI (si leurs routeurs peuvent apprendre des routes de leurs clients, bonjour la sécurité...) mais on ne sait jamais.
Sinon, je ne vois qu'une (très) mauvaise config de leurs routeurs, et disons que quand un client s'est déconnecté, et que l'adresse n'est plus utilisée, les paquets qui lui sont destinés vont échouer n'importe où chez l'un de leurs clients (si c'est ça, c'est un peu une honte quand même).
Cela ressemble à du scan de port TCP, malheureusement il n'y a rien à faire pour l'empecher, il suffit de le bloquer.
aparemment, tu reponds a un message qui n'apparait pas sur mon serveur. je n'ai que ta reponse pour l'instant
Ca n'explique pas pourquoi son FAI (HRNet apparemment)
oui, et pour temperer l'impression que commence a donner cette discussion (j'aurais pu enlever les IP mais je n'y ai pas pense) je dois dire que j'en suis fort satisfait par ailleurs :)
paquets. AMHA ils ont un petit problème de routage, et il faut donc les prévenir.
je vais les appeler demain
Tu n'aurais pas un démon buggé qui annoncerait des routes à-la-con (tm) ? Ca m'étonnerait, parce qu'il faudrait un démon buggué (sacrément) et une config lamentable chez ton FAI (si leurs routeurs peuvent apprendre des routes de leurs clients, bonjour la sécurité...) mais on ne sait jamais.
a priori je ne vois pas : pas de protocoles de routage actives, ce qui peut causer avec l'exterieur: un apache et un proftpd /freebsd, avec du port mapping sur le fw/nat il y a aussi un bind, mais accessible seulement de l'interieur
Sinon, je ne vois qu'une (très) mauvaise config de leurs routeurs, et disons que quand un client s'est déconnecté, et que l'adresse n'est plus utilisée, les paquets qui lui sont destinés vont échouer n'importe où chez l'un de leurs clients (si c'est ça, c'est un peu une honte quand même).
pierre
question subsidiaire : est ce que cela peut influer sur les performances (debit, et surtout, stabilite des connexions, par ex pour le ftp?)
-- Black-ink.net ...les ecrits restent !
Pierre LALET wrote:
Cela ressemble à du scan de port TCP, malheureusement il n'y a rien à
faire pour l'empecher, il suffit de le bloquer.
aparemment, tu reponds a un message qui n'apparait pas sur mon serveur. je
n'ai que ta reponse pour l'instant
Ca n'explique pas pourquoi son FAI (HRNet apparemment)
oui, et pour temperer l'impression que commence a donner cette discussion
(j'aurais pu enlever les IP mais je n'y ai pas pense) je dois dire que j'en
suis fort satisfait par ailleurs :)
paquets. AMHA ils ont un petit problème de routage, et il faut donc les
prévenir.
je vais les appeler demain
Tu n'aurais pas un démon buggé qui annoncerait des routes à-la-con (tm)
? Ca m'étonnerait, parce qu'il faudrait un démon buggué (sacrément) et
une config lamentable chez ton FAI (si leurs routeurs peuvent apprendre
des routes de leurs clients, bonjour la sécurité...) mais on ne sait
jamais.
a priori je ne vois pas : pas de protocoles de routage actives,
ce qui peut causer avec l'exterieur:
un apache et un proftpd /freebsd, avec du port mapping sur le fw/nat
il y a aussi un bind, mais accessible seulement de l'interieur
Sinon, je ne vois qu'une (très) mauvaise config de leurs routeurs, et
disons que quand un client s'est déconnecté, et que l'adresse n'est plus
utilisée, les paquets qui lui sont destinés vont échouer n'importe où
chez l'un de leurs clients (si c'est ça, c'est un peu une honte quand
même).
pierre
question subsidiaire : est ce que cela peut influer sur les performances
(debit, et surtout, stabilite des connexions, par ex pour le ftp?)
Cela ressemble à du scan de port TCP, malheureusement il n'y a rien à faire pour l'empecher, il suffit de le bloquer.
aparemment, tu reponds a un message qui n'apparait pas sur mon serveur. je n'ai que ta reponse pour l'instant
Ca n'explique pas pourquoi son FAI (HRNet apparemment)
oui, et pour temperer l'impression que commence a donner cette discussion (j'aurais pu enlever les IP mais je n'y ai pas pense) je dois dire que j'en suis fort satisfait par ailleurs :)
paquets. AMHA ils ont un petit problème de routage, et il faut donc les prévenir.
je vais les appeler demain
Tu n'aurais pas un démon buggé qui annoncerait des routes à-la-con (tm) ? Ca m'étonnerait, parce qu'il faudrait un démon buggué (sacrément) et une config lamentable chez ton FAI (si leurs routeurs peuvent apprendre des routes de leurs clients, bonjour la sécurité...) mais on ne sait jamais.
a priori je ne vois pas : pas de protocoles de routage actives, ce qui peut causer avec l'exterieur: un apache et un proftpd /freebsd, avec du port mapping sur le fw/nat il y a aussi un bind, mais accessible seulement de l'interieur
Sinon, je ne vois qu'une (très) mauvaise config de leurs routeurs, et disons que quand un client s'est déconnecté, et que l'adresse n'est plus utilisée, les paquets qui lui sont destinés vont échouer n'importe où chez l'un de leurs clients (si c'est ça, c'est un peu une honte quand même).
pierre
question subsidiaire : est ce que cela peut influer sur les performances (debit, et surtout, stabilite des connexions, par ex pour le ftp?)
