traffic etrange

Le
cc
salut

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}

--

merci
a+
--
cc
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Le #889124
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
Le #889123
@@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


Stephane Catteau
Le #889122
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.

Publicité
Poster une réponse
Anonyme