Prise en charge des interfaces

[darcosion]

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 #66 (comment) :

• 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]

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 al45tair/netifaces#78

[darcosion]

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]

Bon, je reprend mon com' #66 (comment)

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]

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

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

[darcosion]

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

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]

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

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]

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é : 8106c5c

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]

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]

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

[darcosion]

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]

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.