Je vois ce qui semble être une activité étrange sur mon routeur principal (le seul routeur connecté au modem du fournisseur de services Internet) à partir d'un périphérique Android. Il se peut que je ne l'ai jamais vu auparavant, car la journée approche, et la plupart des autres personnes sont parties et cette personne chargée de la maintenance est la seule autre personne du réseau. Cependant, ce que je vois n’a aucun sens pour moi dans le contexte de ce que le NAT est censé faire pour les périphériques clients, du moins tel que je le comprends. C'est la première fois que je regarde une table NAT.
J'ai donc eu quelques problèmes ce matin en établissant une connexion avec un périphérique connecté au routeur principal (via le commutateur principal vers un autre commutateur). J'ai dû redémarrer le routeur et le commutateur. Une fois que tout était fait pour la journée, je devais refaire la même chose pour éteindre l'appareil. C'est ce qui m'a amené à regarder la table NAT sur le routeur principal pour rechercher un indice sur la cause de l'interruption temporaire. Le routeur principal est modifié par DD-WRT et j'ai pu y établir une connexion telnet et chatter la table.
J'ai trouvé une adresse IP privée étrangère dans le tableau! Le routeur principal a une plage d'adresses côté réseau local de 192.168.1.1/255. J'ai deux autres routeurs (5 en fait mais seulement deux autres sont impliqués dans cette activité) connectés au commutateur principal et ont une adresse côté réseau local de 192.168.2.1/255et 192.168.4.1/255. La première fois que j'ai trouvé 192.168.2.108! Je me suis connecté à la page d'administration à distance du routeur et j'ai constaté qu'il avait été attribué à un téléphone Android connecté sans fil. J'ai bloqué l'adresse MAC du téléphone et j'ai attendu de voir qui c'était (quand ils se sont plaints de me connecter). J'ai attendu une heure et personne ne s'est plaint.
Plus tard, j'ai vérifié à nouveau et trouvé une autre adresse IP étrangère, mais cette fois-ci, c'était le cas 192.168.4.30! Je me suis donc connecté au routeur d'où provient l'adresse IP et j'ai découvert qu'il s'agissait du même téléphone Android. Je me suis souvenu que le responsable de la maintenance avait un téléphone Android, je lui ai donc demandé directement de constater que c’était bien son téléphone.
La première fois que je l'ai vu, il s'agissait d'une connexion à une adresse IP en Chine. La deuxième fois, il s'agissait d'une connexion à un serveur Amazon EC2. Je n'ai pas enregistré la première instance mais j'ai toujours la seconde:
tcp 6 1096 ESTABLISHED src=192.168.4.30 dst=23.21.225.144 sport=53993 dport=443 packets=9 bytes=1131 [UNREPLIED] src=23.21.225.144 dst=192.168.4.30 sport=443 dport=53993 packets=0 bytes=0 mark=0 use=2
N'oubliez pas que cette entrée provient d'un routeur modifié DD-WRT avec une plage d'adresses IP du côté réseau local de 192.168.1.1/255.
Est-ce une activité rare mais normale ou cela indique-t-il un téléphone Android compromis?
Edit:
La topologie du réseau est assez simple. Le routeur principal est le seul routeur connecté au modem du FAI avec NAT et DHCP activés et est modulé par DD-WRT, pour diverses raisons. Tous les autres routeurs ont également NAT et DHCP activés (avec leurs propres sous-réseaux pour diverses raisons) et sont connectés (via un commutateur principal) au routeur principal. Il n'y a pas de triple NAT. Tous les routeurs sont de qualité commerciale (résidentielle) non commerciale. Lorsque j'affiche un IP/255, je fais référence au sous-réseau par défaut de classe C pour les plages d'adresses IP privées côté réseau local; c'est-à-dire 192.168.1.1/255= 192.168.1.1-192.168.1.255. Désolé de toute confusion, la terminologie et la notation de mon réseau sont obsolètes.
Réponses:
Cela doit être une activité non autorisée sur votre réseau local.
Votre XXXX / 255 n’a aucun sens - ce n’est pas un masque de réseau valide - Obtenir le bon masque de réseau sur votre routeur est la première étape pour réduire l’espace avec lequel le périphérique non autorisé peut fonctionner.
La deuxième étape consiste à consulter la table ARP (arp -an) et à rechercher la liste des adresses IP non reconnues. Vous pouvez prendre les 3 premiers octets de ces adresses et faire une recherche qui, si l’activité est innocente, peut vous aider à préciser le périphérique que vous recherchez en vous informant du fabricant. Notez que cela peut facilement être simulé parfois. son méchant, il pourrait ne pas vous en dire beaucoup.
Vous pouvez également utiliser tcpdump (par exemple, tcpdump -n -i eth0 src ou dst 192.168.4.30) pour afficher, en temps réel, avec quoi ce périphérique communique.
la source