Prise en charge des interfaces

darcosion commented 2 years ago

Actuellement, les interfaces ne sont pas prises en compte, Echosounder ne "voit" pas le routage et ne joue pas avec.

Il serait intéressant d'ajouter au backend la prise en charge d'interface pour permettre à l'utilisateur de faire des choses plus avancées (et de permettre de connaître éventuellement plus de CIDR).

étapes, transposés de https://github.com/darcosion/Echosounder/issues/66#issuecomment-1079943642 :

[x] Créer une fonction backend de récupération de la liste des interfaces & sa route
[x] Créer un appel front pour en récupérer la valeur au lancement d'une page web
[x] Créer un widget général spécifiant l'interface choisie
[x] intégrer son emploie à toutes les requêtes de scan pour qu'elles se déroulent sur la même API

darcosion commented 2 years ago

A priori, le module https://github.com/al45tair/netifaces a été ajouté par @AlixCheval pour cette raison.

Néanmoins, il ne semble plus maintenu, il faut préalablement explorer les alternatives solides. voir https://github.com/al45tair/netifaces/issues/78

darcosion commented 2 years ago

Je commence à réfléchir à la méthodologie itérative de développement. C'est un gros morceau, et donc il doit être découpé par étapes.

[ ] Créer une fonction backend de récupération de la liste des interfaces & sa route
[ ] Créer un appel front pour en récupérer la valeur au lancement d'une page web
[ ] Créer un widget général spécifiant l'interface choisie
[ ] intégrer son emploie à toutes les requêtes de scan pour qu'elles se déroulent sur la même API

darcosion commented 2 years ago

Bon, je reprend mon com' https://github.com/darcosion/Echosounder/issues/66#issuecomment-1079943642

A priori, la communauté est consciente de la fin de maintient de netiface si j'en crois le pypi : https://pypi.org/project/netifaces/ Il y a un second maintainer qui s'occupe de fournir de nouvelle version de release mais qui n'adresse plus les issues on dirait.

Pour moi, faute d'alternative, c'est utilisable tant que pypi indique qu'il se compile sous linux/windows.

darcosion commented 2 years ago

Avec netifaces, on fait un appel backend qui semble très simple : 8a0dc8f5c6a6e2178cf10462034392fd593eeeed

Pour la partie front, c'est assez similaire à l'appel health, je suis un peu circonspect. Peut être utile de fusionner ces fonctions ? Voir df73c4d7117e418c9443362b2afe3fa247c37af2

darcosion commented 2 years ago

On a un second appel backend qui récupère les info affilié à une interface : 179097c0ea3958a0783924819d0541e4e058daf4

Par contre, les données renvoyés sont du genre :

{
  "2": [
    {
      "addr": "127.0.0.1",
      "netmask": "255.0.0.0",
      "peer": "127.0.0.1"
    }
  ],
  "10": [
    {
      "addr": "::1",
      "netmask": "ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff"
    }
  ],
  "17": [
    {
      "addr": "00:00:00:00:00:00",
      "peer": "00:00:00:00:00:00"
    }
  ]
}

jveux démarrer personne dans le monde de la réseautique, mais on fait quoi avec ça ?

A priori, il va falloir creuser dans la doc de netiface et dans ce qui existe dans la communauté concernant la notion même d'interface.

darcosion commented 2 years ago

Ok, je suis un connard, c'est fix ici : fcd248d2aa074428e6693067d95894086f7ba240

A prioi, on peut récupérer les "nombre" associé aux famille d'adresse qui peuvent changer en fonction de notre OS. Je déconne pas c'est dans la doc officielle de netifaces, le gars qui l'a écrit semble aussi choqué que moi.

On obtiens via mon nouvel appel API des trucs dans ce genre :

{
  "Ethernet": 17, 
  "IPv4": 2, 
  "IPv6": 10
}

Parfaitement exploitable pour la suite. On pourrais même peut-être résoudre #43 avec ça !

darcosion commented 2 years ago

La prochaine problématique est de régler le choix des IP quand plusieurs IP sont proposés pour une interface (je déconne pas, c'est toujours dans la doc de netifaces).

A priori, je peux balancer dans un second select la liste des IP dans une interface sélectionné : 8106c5cf01cb2b006438911c5cf0ede7ba9e754d

Néanmoins, je me retrouve avec ce genre de donnée :

{"addr":"192.168.1.121","broadcast":"192.168.1.255","netmask":"255.255.255.0"}

Je sais que mon subnet/CIDR est 192.168.1.0/24, mais comment l'obtenir mathématiquement avec ces 3 informations ?

darcosion commented 2 years ago

Ok, a priori, j'ai trouvé :

>>> import ipaddress
>>> net = ipaddress.ip_network('192.168.1.121/255.255.255.0', strict=False)
>>> print(net)
192.168.1.0/24

Plus qu'à créer une route pour ça et on obtiens les données qu'on veut au format qu'on veut. Et pas besoin du broadcast (qui apparaîtra pas toujours...) !

darcosion commented 2 years ago

Route créé, on peut maintenant exploiter pleinement les interfaces et les IP associés via 93ab86f2064dd2235cdb1d8fe826772357a56bc1

darcosion commented 2 years ago

A priori, il faut traiter individuellement les 4 modules.

Donc pour nmap :

nmap -e <INTERFACE> <cible>

Pour scapy, dans chaque fonction qui envoie des packets :

sendp(..., iface='<nom>', ...)

Pour Impacket ça parais compliqué et dnspython ne semble pas avoir cette option...

darcosion commented 2 years ago

Bon, a priori c'est un moyen d'avoir un binding d'interface en dur ce qui est décrit.

Néanmoins la sélection automatique d'IP fonctionne tout aussi bien. Au niveau graph, cela risque de générer des doublons d'IP (heureusement, il y a l'adresse mac). Et les refacto #75 & #83 devraient résoudre ou du moins permettre d'y voir plus clair là dedans.

darcosion / Echosounder

Prise en charge des interfaces #66