SMPFR

Salut la compagnie,

Comme le montre la capture ci-dessous, trafic louche en sortie.

@IP différente, mais tjrs le même port 5555.



Conf firewall en entrée, port 5555 : fermé

@IP source 192.168.1.254 = IP WAN du firewall (USG20-VPN)
Ce port WAN est connecté à la Livebox.

Afin de soulager le firewall, j'ai créé une règle qui drop ce trafic, mais j'aimerais comprendre à quoi il correspond...

Est-il possible qu'un poste de travail, ce cache derrière cette IP ?

Yo !

J'imagine que tu peux pas voir sur la LB ce qui requête ce port ?
Après des trucs qui viennent chez toi y'en à toujours plein. Sur mon dédié je te montre pas les logs du FW...

t'as rebooté le routeur ?

le firmware est a jour ?
ya eu une faille ya quelques années qui transformait les routeur en BOT avec ce port.....

un coup de packetcapture sur ce port pour voir ce qu'il y a dans les packets ?

Vu la geoloc des ips, ça m'étonnerai pas que dsebire soit dans le vrai

je pensais à ça pour être précis: https://www.enisa.europa.eu/publication ... me-routers

Dodo29 a écrit : ↑mer. 12 déc. 2018 06:33J'imagine que tu peux pas voir sur la LB ce qui requête ce port ?

Effectivement...

dsebire a écrit : ↑mer. 12 déc. 2018 08:04 t'as rebooté le routeur ?

le firmware est a jour ?
ya eu une faille ya quelques années qui transformait les routeur en BOT avec ce port.....

un coup de packetcapture sur ce port pour voir ce qu'il y a dans les packets ?

Le routeur a été redémarré cette nuit, mais cela n'a rien changé et non, il n'est pas à jour.

Je vais essayer de capturer le trafic.

Merci à tous.

Voici la capture.

https://framabin.org/p/?ef2f32552d54552 ... oKFRKaQQk=

ya rien a part une tentative d'ouverture de connexion....

en ssh sur le routeur:
debug system netstat socket

ça liste les connexions.
tu regarde quel process lance toutes ces connexions vers le port 5555 et après tu regarde si c'est un programme légitime

Rien d'anormal.

Du coup, j'ai contacté l'assistance. Le tech ne comprend pas non plus.

J'ai ouvert un ticket, wait & see.

kalistyan a écrit : ↑jeu. 13 déc. 2018 17:29 Rien d'anormal.

cad ?
tu vois le process qui lancent toutes les connexions vers les ports 5555 ?

Aucune trace du port 5555.

donc t'as des connexions initiées mais aucun process qui le fait? oO

Exactement, entre-temps j'ai eu une réponse du support.

D'après l'équipe R&D, le pare-feu servait de relais, le trafic venait de l'extérieur pour ensuite repartir.

La preuve via une capture de trafic, Ci-dessous, une copie d'une tentative.
https://framabin.org/p/?63ae4c61221bebe ... 9kP9BaBlw=

Contrairement à mes logs, qui indiquait en source l'@IP local du pare-feu, eux ont réussi à obtenir les adresses public.


Malheureusement, à la question, comment le trafic pouvait-il passer sans se faire intercepter par le firewall, je n'ai pas eu de réponse...

Genre pour masquer une IP source ?

Exactement, étant donné que tout sortait du pare-feu de mon client, c'était son @IP public.