Sur notre reseau nous avaons une sonde securactive
Notre fournisseur d'acces est FT. Regulierement sur la sonde je vois
des requetes ICMP venant d'une ip de chez FT à destination de mon poste
(en IP fixe)
voila le message de la sonde : "ICMP Destination Unreachable
Communication Administratively Prohibited "
Payload
length = 32
000 : 00 00 00 00 45 00 00 30 A6 FA 40 00 7E 06 9D CD
....E..0..@.~...
010 : AC 10 01 66 0A 00 00 8A 04 81 00 50 7D B6 80 F1
...f.......P}...
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
cc wrote:
salut
Bonjour,
Sur notre reseau nous avaons une sonde securactive Notre fournisseur d'acces est FT. Regulierement sur la sonde je vois des requetes ICMP venant d'une ip de chez FT à destination de mon poste (en IP fixe)
Votre poste est en IP fixe et publique ?
voila le message de la sonde : "ICMP Destination Unreachable Communication Administratively Prohibited "
Payload
length = 32
000 : 00 00 00 00 45 00 00 30 A6 FA 40 00 7E 06 9D CD ~... 010 : AC 10 01 66 0A 00 00 8A 04 81 00 50 7D B6 80 F1 ...f.......P}...
Si votre IP est publique, cela peut venir du fait que l'IP de FT en question est scannée par des paquets dont l'adresse de provenance apparente est justement _votre_ adresse (peut-être du spoofing ?)... Cela dit, si ce trafic apparait régulièrement, ce n'est peut-être pas la bonne explication.
La sonde surveille-t-elle également le trafic sortant ? Si c'est le cas, vérifiez tout de même que votre machine n'a pas de comportement suspect qui pourrait expliquer ces refus de la part de l'IP de chez FT. L'infection par un trojan, un ver ou autre n'est pas à écarter non plus.
Do-Remi
cc wrote:
salut
Bonjour,
Sur notre reseau nous avaons une sonde securactive
Notre fournisseur d'acces est FT. Regulierement sur la sonde je vois des
requetes ICMP venant d'une ip de chez FT à destination de mon poste (en
IP fixe)
Votre poste est en IP fixe et publique ?
voila le message de la sonde : "ICMP Destination Unreachable
Communication Administratively Prohibited "
Payload
length = 32
000 : 00 00 00 00 45 00 00 30 A6 FA 40 00 7E 06 9D CD ....E..0..@.~...
010 : AC 10 01 66 0A 00 00 8A 04 81 00 50 7D B6 80 F1 ...f.......P}...
Si votre IP est publique, cela peut venir du fait que l'IP de FT en
question est scannée par des paquets dont l'adresse de provenance
apparente est justement _votre_ adresse (peut-être du spoofing ?)...
Cela dit, si ce trafic apparait régulièrement, ce n'est peut-être pas la
bonne explication.
La sonde surveille-t-elle également le trafic sortant ? Si c'est le cas,
vérifiez tout de même que votre machine n'a pas de comportement suspect
qui pourrait expliquer ces refus de la part de l'IP de chez FT.
L'infection par un trojan, un ver ou autre n'est pas à écarter non plus.
Sur notre reseau nous avaons une sonde securactive Notre fournisseur d'acces est FT. Regulierement sur la sonde je vois des requetes ICMP venant d'une ip de chez FT à destination de mon poste (en IP fixe)
Votre poste est en IP fixe et publique ?
voila le message de la sonde : "ICMP Destination Unreachable Communication Administratively Prohibited "
Payload
length = 32
000 : 00 00 00 00 45 00 00 30 A6 FA 40 00 7E 06 9D CD ~... 010 : AC 10 01 66 0A 00 00 8A 04 81 00 50 7D B6 80 F1 ...f.......P}...
Si votre IP est publique, cela peut venir du fait que l'IP de FT en question est scannée par des paquets dont l'adresse de provenance apparente est justement _votre_ adresse (peut-être du spoofing ?)... Cela dit, si ce trafic apparait régulièrement, ce n'est peut-être pas la bonne explication.
La sonde surveille-t-elle également le trafic sortant ? Si c'est le cas, vérifiez tout de même que votre machine n'a pas de comportement suspect qui pourrait expliquer ces refus de la part de l'IP de chez FT. L'infection par un trojan, un ver ou autre n'est pas à écarter non plus.
Do-Remi
cc
@@mail.aioe.or avait prétendu :
cc wrote:
salut
Bonjour,
Sur notre reseau nous avaons une sonde securactive Notre fournisseur d'acces est FT. Regulierement sur la sonde je vois des requetes ICMP venant d'une ip de chez FT à destination de mon poste (en IP fixe)
Votre poste est en IP fixe et publique ? fixe oui en locale
et on a un ip fixe publique les deux sont differentes.
voila le message de la sonde : "ICMP Destination Unreachable Communication Administratively Prohibited "
Payload
length = 32
000 : 00 00 00 00 45 00 00 30 A6 FA 40 00 7E 06 9D CD ~... 010 : AC 10 01 66 0A 00 00 8A 04 81 00 50 7D B6 80 F1 ...f.......P}...
Si votre IP est publique, cela peut venir du fait que l'IP de FT en question est scannée par des paquets dont l'adresse de provenance apparente est justement _votre_ adresse (peut-être du spoofing ?)... Cela dit, si ce trafic apparait régulièrement, ce n'est peut-être pas la bonne explication.
La sonde surveille-t-elle également le trafic sortant ?
oui elle surveille tout le traffic
Si c'est le cas, vérifiez tout de même que votre machine n'a pas de comportement suspect qui pourrait expliquer ces refus de la part de l'IP de chez FT. L'infection par un trojan, un ver ou autre n'est pas à écarter non plus.
J'ai passe a square, adaware, spy bot et hijack this rien trouve nul part
Do-Remi
--
merci a+ -- cc
@doremi@fasolla.sido@mail.aioe.or avait prétendu :
cc wrote:
salut
Bonjour,
Sur notre reseau nous avaons une sonde securactive
Notre fournisseur d'acces est FT. Regulierement sur la sonde je vois des
requetes ICMP venant d'une ip de chez FT à destination de mon poste (en IP
fixe)
Votre poste est en IP fixe et publique ?
fixe oui en locale
et on a un ip fixe publique
les deux sont differentes.
voila le message de la sonde : "ICMP Destination Unreachable Communication
Administratively Prohibited "
Payload
length = 32
000 : 00 00 00 00 45 00 00 30 A6 FA 40 00 7E 06 9D CD ....E..0..@.~...
010 : AC 10 01 66 0A 00 00 8A 04 81 00 50 7D B6 80 F1 ...f.......P}...
Si votre IP est publique, cela peut venir du fait que l'IP de FT en question
est scannée par des paquets dont l'adresse de provenance apparente est
justement _votre_ adresse (peut-être du spoofing ?)... Cela dit, si ce trafic
apparait régulièrement, ce n'est peut-être pas la bonne explication.
La sonde surveille-t-elle également le trafic sortant ?
oui elle surveille tout le traffic
Si c'est le cas,
vérifiez tout de même que votre machine n'a pas de comportement suspect qui
pourrait expliquer ces refus de la part de l'IP de chez FT. L'infection par
un trojan, un ver ou autre n'est pas à écarter non plus.
J'ai passe a square, adaware, spy bot et hijack this
rien trouve nul part
Sur notre reseau nous avaons une sonde securactive Notre fournisseur d'acces est FT. Regulierement sur la sonde je vois des requetes ICMP venant d'une ip de chez FT à destination de mon poste (en IP fixe)
Votre poste est en IP fixe et publique ? fixe oui en locale
et on a un ip fixe publique les deux sont differentes.
voila le message de la sonde : "ICMP Destination Unreachable Communication Administratively Prohibited "
Payload
length = 32
000 : 00 00 00 00 45 00 00 30 A6 FA 40 00 7E 06 9D CD ~... 010 : AC 10 01 66 0A 00 00 8A 04 81 00 50 7D B6 80 F1 ...f.......P}...
Si votre IP est publique, cela peut venir du fait que l'IP de FT en question est scannée par des paquets dont l'adresse de provenance apparente est justement _votre_ adresse (peut-être du spoofing ?)... Cela dit, si ce trafic apparait régulièrement, ce n'est peut-être pas la bonne explication.
La sonde surveille-t-elle également le trafic sortant ?
oui elle surveille tout le traffic
Si c'est le cas, vérifiez tout de même que votre machine n'a pas de comportement suspect qui pourrait expliquer ces refus de la part de l'IP de chez FT. L'infection par un trojan, un ver ou autre n'est pas à écarter non plus.
J'ai passe a square, adaware, spy bot et hijack this rien trouve nul part
Do-Remi
--
merci a+ -- cc
Stephane Catteau
cc devait dire quelque chose comme ceci :
Sur notre reseau nous avaons une sonde securactive Notre fournisseur d'acces est FT. Regulierement sur la sonde je vois des requetes ICMP venant d'une ip de chez FT à destination de mon poste (en IP fixe) voila le message de la sonde : "ICMP Destination Unreachable Communication Administratively Prohibited "
La machine de FT reçoit des paquets UDP ayant ton adresse IP comme origine et les refuses en retournant une erreur. Donc :
1) Ces paquets viennent-ils vraiment de ton adresse IP ? Configurer le firewall pour qu'il loggue tous les paquets à destination de cette adresse IP, attendre une journée et regarder ce que disent les logs, après avoir vérifié bien entendu que la sonde à bien émis les alertes habituelles. Etant entendu que la sonde n'a aucune raison de déclencher une alarme sur des paquets sortants qui ont 99,99% de chances d'être tout ce qu'il y a de plus conformes, c'est bien au niveau du firewall qu'il faut travailler.
2) Si les logs ne donnent rien, demander au firewall de bloquer le message ICMP en question lorsqu'il provient de cette adresse IP. Ca ne changera rien pour FT, mais ça arrêtera de pourrir tes logs.
Dans le cas contraire :
3) Demander au firewall de bloquer la sortie des paquets UDP à destination de cette adresse IP, et logguer tous les bloquages. On commence par interrompre l'hémoragie et ensuite seulement on recherche sa cause. Et les paquets UDP seulement parce qu'autant c'est une machine que tu solicites tous les jours via TCP.
4) Quelle est cette machine de FT ? Reverse sur l'adresse IP, traceroute (non UDP évidement), WhoIs en dernier recourt, devraient te donner plus d'infos et te permettre, peut-être, de comprendre l'origine du problème (par exemple une erreur de saisie d'une adresse IP ou du protocole[1] dans un fichier de conf').
5) Si l'identification de la machine ne t'en apprend pas plus, parser les fichiers de conf' de la machine émettrice à la recherche de cette adresse IP (traditionnellement, une erreur de saisie de l'adresse IP d'un DNS).
6) Parser les logs de la machine, à la recherche de toutes les informations qui indiqueraient qu'une tache liée au réseau n'a pas pu être effectuée. Regarder la configuration de l'application à l'origine de cette tache.
7) Utiliser les logs du firewall et ceux de la machine pour essayer de trouver une corrélation temporelle entre les deux et ainsi identifier la source. Comparer aussi les logs à l'utilisation humaine de la machine (donc tout ce qui ne serait pas loggué).
8) Sniffer les paquets à destination de cette adresse IP, et essayer d'identifier leur nature et leur origine. A ce stade là ça peut toujours être une banale erreur d'aiguillage.
9) Sauvage mais efficace, logguer la liste des processus toutes les 10 secondes, puis regarder le(s)quel(s)s est/sont présent(s) à chaque fois que les paquets sont envoyés. Pour chacun d'eux, identifier son rôle, la raison de sa présence, son uid, vérifier sa configuration, contrôler son intégrité, l'ejecter du disque (enfin, le renomer quoi) et regarder si la machine explose ou s'il ne s'agit vraiment que d'un parasite.
10) Revenir ici en disant que tout le reste n'a rien donné.
Evidement, chaque point s'entend "si le précédent n'a rien donné".
[1] J'ai un temps utilisé une windowserie où il fallait mettre "1" pour TCP et "0" pour UDP, et qui m'a pourri la vie pendant un moment avant que je ne comprenne mon erreur.
cc devait dire quelque chose comme ceci :
Sur notre reseau nous avaons une sonde securactive
Notre fournisseur d'acces est FT. Regulierement sur la sonde je vois
des requetes ICMP venant d'une ip de chez FT à destination de mon poste
(en IP fixe)
voila le message de la sonde : "ICMP Destination Unreachable
Communication Administratively Prohibited "
La machine de FT reçoit des paquets UDP ayant ton adresse IP comme
origine et les refuses en retournant une erreur.
Donc :
1) Ces paquets viennent-ils vraiment de ton adresse IP ? Configurer le
firewall pour qu'il loggue tous les paquets à destination de cette
adresse IP, attendre une journée et regarder ce que disent les logs,
après avoir vérifié bien entendu que la sonde à bien émis les alertes
habituelles.
Etant entendu que la sonde n'a aucune raison de déclencher une alarme
sur des paquets sortants qui ont 99,99% de chances d'être tout ce qu'il
y a de plus conformes, c'est bien au niveau du firewall qu'il faut
travailler.
2) Si les logs ne donnent rien, demander au firewall de bloquer le
message ICMP en question lorsqu'il provient de cette adresse IP. Ca ne
changera rien pour FT, mais ça arrêtera de pourrir tes logs.
Dans le cas contraire :
3) Demander au firewall de bloquer la sortie des paquets UDP à
destination de cette adresse IP, et logguer tous les bloquages. On
commence par interrompre l'hémoragie et ensuite seulement on recherche
sa cause. Et les paquets UDP seulement parce qu'autant c'est une
machine que tu solicites tous les jours via TCP.
4) Quelle est cette machine de FT ? Reverse sur l'adresse IP,
traceroute (non UDP évidement), WhoIs en dernier recourt, devraient te
donner plus d'infos et te permettre, peut-être, de comprendre l'origine
du problème (par exemple une erreur de saisie d'une adresse IP ou du
protocole[1] dans un fichier de conf').
5) Si l'identification de la machine ne t'en apprend pas plus, parser
les fichiers de conf' de la machine émettrice à la recherche de cette
adresse IP (traditionnellement, une erreur de saisie de l'adresse IP
d'un DNS).
6) Parser les logs de la machine, à la recherche de toutes les
informations qui indiqueraient qu'une tache liée au réseau n'a pas pu
être effectuée. Regarder la configuration de l'application à l'origine
de cette tache.
7) Utiliser les logs du firewall et ceux de la machine pour essayer de
trouver une corrélation temporelle entre les deux et ainsi identifier
la source. Comparer aussi les logs à l'utilisation humaine de la
machine (donc tout ce qui ne serait pas loggué).
8) Sniffer les paquets à destination de cette adresse IP, et essayer
d'identifier leur nature et leur origine. A ce stade là ça peut
toujours être une banale erreur d'aiguillage.
9) Sauvage mais efficace, logguer la liste des processus toutes les 10
secondes, puis regarder le(s)quel(s)s est/sont présent(s) à chaque fois
que les paquets sont envoyés. Pour chacun d'eux, identifier son rôle,
la raison de sa présence, son uid, vérifier sa configuration, contrôler
son intégrité, l'ejecter du disque (enfin, le renomer quoi) et regarder
si la machine explose ou s'il ne s'agit vraiment que d'un parasite.
10) Revenir ici en disant que tout le reste n'a rien donné.
Evidement, chaque point s'entend "si le précédent n'a rien donné".
[1]
J'ai un temps utilisé une windowserie où il fallait mettre "1" pour
TCP et "0" pour UDP, et qui m'a pourri la vie pendant un moment avant
que je ne comprenne mon erreur.
Sur notre reseau nous avaons une sonde securactive Notre fournisseur d'acces est FT. Regulierement sur la sonde je vois des requetes ICMP venant d'une ip de chez FT à destination de mon poste (en IP fixe) voila le message de la sonde : "ICMP Destination Unreachable Communication Administratively Prohibited "
La machine de FT reçoit des paquets UDP ayant ton adresse IP comme origine et les refuses en retournant une erreur. Donc :
1) Ces paquets viennent-ils vraiment de ton adresse IP ? Configurer le firewall pour qu'il loggue tous les paquets à destination de cette adresse IP, attendre une journée et regarder ce que disent les logs, après avoir vérifié bien entendu que la sonde à bien émis les alertes habituelles. Etant entendu que la sonde n'a aucune raison de déclencher une alarme sur des paquets sortants qui ont 99,99% de chances d'être tout ce qu'il y a de plus conformes, c'est bien au niveau du firewall qu'il faut travailler.
2) Si les logs ne donnent rien, demander au firewall de bloquer le message ICMP en question lorsqu'il provient de cette adresse IP. Ca ne changera rien pour FT, mais ça arrêtera de pourrir tes logs.
Dans le cas contraire :
3) Demander au firewall de bloquer la sortie des paquets UDP à destination de cette adresse IP, et logguer tous les bloquages. On commence par interrompre l'hémoragie et ensuite seulement on recherche sa cause. Et les paquets UDP seulement parce qu'autant c'est une machine que tu solicites tous les jours via TCP.
4) Quelle est cette machine de FT ? Reverse sur l'adresse IP, traceroute (non UDP évidement), WhoIs en dernier recourt, devraient te donner plus d'infos et te permettre, peut-être, de comprendre l'origine du problème (par exemple une erreur de saisie d'une adresse IP ou du protocole[1] dans un fichier de conf').
5) Si l'identification de la machine ne t'en apprend pas plus, parser les fichiers de conf' de la machine émettrice à la recherche de cette adresse IP (traditionnellement, une erreur de saisie de l'adresse IP d'un DNS).
6) Parser les logs de la machine, à la recherche de toutes les informations qui indiqueraient qu'une tache liée au réseau n'a pas pu être effectuée. Regarder la configuration de l'application à l'origine de cette tache.
7) Utiliser les logs du firewall et ceux de la machine pour essayer de trouver une corrélation temporelle entre les deux et ainsi identifier la source. Comparer aussi les logs à l'utilisation humaine de la machine (donc tout ce qui ne serait pas loggué).
8) Sniffer les paquets à destination de cette adresse IP, et essayer d'identifier leur nature et leur origine. A ce stade là ça peut toujours être une banale erreur d'aiguillage.
9) Sauvage mais efficace, logguer la liste des processus toutes les 10 secondes, puis regarder le(s)quel(s)s est/sont présent(s) à chaque fois que les paquets sont envoyés. Pour chacun d'eux, identifier son rôle, la raison de sa présence, son uid, vérifier sa configuration, contrôler son intégrité, l'ejecter du disque (enfin, le renomer quoi) et regarder si la machine explose ou s'il ne s'agit vraiment que d'un parasite.
10) Revenir ici en disant que tout le reste n'a rien donné.
Evidement, chaque point s'entend "si le précédent n'a rien donné".
[1] J'ai un temps utilisé une windowserie où il fallait mettre "1" pour TCP et "0" pour UDP, et qui m'a pourri la vie pendant un moment avant que je ne comprenne mon erreur.
