darcosion / echosounder Goto Github PK

Actuellement le titre placé dans le <header> est dans une police normale avec quasiment aucun style. J'ai légèrement modifié la forme du titre pour qu'il colle au reste, mais placer des styles appropriés serait intéressant.

Implémenter une technique de resolve autour de LLMNR pour les machines Windows. Cette technique va permettre notamment de récupérer un hostname. Il est aussi possible de récupérer d'autres informations (à voir). Si vous avez d'autres idées mettez les ici.

Actuellement, les menu sont actionnables depuis des petits carrés à droite & gauche.

Je propose d'ajouter dans ces carrés des images SVG ou PNG disposant de petites icônes qui indiquerais le type de chaque menu proposé (réseau, machine, autre, visu machine, visu service, visu autre).

Cette issue devrait (de bon alloi) être résolue après #43
Actuellement, on scan uniquement le réseau local sur lequel on se situe.

Or on pourrais récupérer la liste des réseaux locaux pour avoir plus de visibilité. De plus du fuzzing d'IP local en traceroute permettrait la découverte de réseaux locaux cachés (dont les routes ne sont pas transmises par les routeurs locaux).

Voici une liste d'élément à implémenter :

• fonction de traceroute classique scapy (https://scapy.readthedocs.io/en/latest/usage.html#tcp-traceroute)
• Route API retournant pour une cible son traceroute pour une IP
• Route API retournant pour une cible son traceroute pour un CIDR
• Implémentation front du bouton de scan traceroute pour un CIDR
• Implémentation front du bouton de scan traceroute pour une IP
• Affichage/rendu graph pour les résultats de scan traceroute

Actuellement, les noeuds mettent dans un attribut "data" les informations qui lui sont associés.

Cet attribut pourrait être employé pour permettre un affichage détaillé aux utilisateur des informations associés à un noeud dans un panel spécifique (à droite ? ).

Une implémentation naïve de la fonctionnalité va être réalisé afin de s'approprier cette fonctionnalité et couvrir ses cas d'usages.

Actuellement, il n'y a pas de reset CSS, on peut donc avoir potentiellement des colisions en fonction de l'approche d'affichage de chaque navigateur.

Je propose d'ajouter un fichier de reset CSS au lancement afin d'avoir un modèle de construction unifié.

Il est possible de placer un ensemble de noeud dans un groupe, je l'ai fait pour Epic stamina.

Je propose d'effectuer la même chose, mais pour les noeuds que nous arrivons à lier à une gateway.

Implémenter fonctionnalité de scan DHCP. Permet notamment d'extraire les champs :

• Type d'OS.
• Vendor ID.

Il serait intéressant de regarder ce qu'on pourrait faire avec ce genre d'information (Vendor ID) et quelles sont les types d'attaques possibles si un attaquant dispose de cette information.

Actuellement le front appelle la découverte réseau continuellement, ce qui était considéré comme une fonctionnalité (affichage temps réel), mais que je considère comme un bug.

Il faut donc remplacer la découverte réseau automatique par une interface de découverte.

Actuellement, l'API ne dispose pas de fonctionnalités permettant d'assurer un debug propre, il serait intéressant de rajouter une route indiquant au front l'état du backend sous la forme GET /health. Et coté front, une fonction qui à l'ouverture de la page, en vérifie l'état et donne à l'utilisation l'information sur le sujet.

Voici une suite de fonctionnalité décrite formellement :

• fonction de vérification des dépendances python & shell (nmap)
• route API flask /health
• fonction d'appel de /health coté front
• appel de la fonction et affichage d'un toast à l'utilisateur
• ajout de bouton dans le 3ème menu du panel de droite pour requêter l'API

Actuellement, d'après la doc de nmap, on peut faire un scan optimisé des 100 ports les plus communs : https://nmap.org/book/reduce-scantime.html (partie --top-ports), on pourrais créer un scan de service spécifique pour cela à ajouter dans la liste des scans d'IP.

Permet d'implémenter la fonctionnalité Reverse PTR. On peut trouver de la doc pour scapy DNS ici.

Une fois l'issue #5 réalisé, ajouter dans l'interface la possibilité pour une IP ou pour un bulk d'IP de faire la découverte de leurs services pour aller plus loin dans l'analyse.

Dans l'idée, un nmap agressif spécifique à chaque machine pourrais être lancé lorsque demandé.

Un widget indiquant via de petites notification en bas de page les effets donné au backend serait utilise pour que l'utilisateur puisse avoir connaissance de problèmes ou des effets de ce sur quoi il clic.

Actuellement, un soucis réside quand à la façon dont on effectue les affichages :

Il n'existe que deux méthodes de scan et si l'une renvoie un certain nombre de donnée sur une machine, l'autre n'actualise pas lesdites données.

De la même façon, si pour une même adresse mac, deux IP sont renvoyés, alors deux machines s'afficheront dans le réseau.

Il faut donc trouver une solution à la problématique de l'affichage cohérent.

Une façon de faire serait de décorréler les "noeuds" de la notion d'IP ou d'adresse MAC. Cela en plaçant une fonction intermédiaire qui s'occuperait de construire des noeuds en fonction d'un ensemble d'information (IP, MAC, méta données) lié à la topologie du réseau.

Une autre façon serait de travailler dans une fonction intermédiaire la notion de couple IP-MAC pour trouver un moyen de lier les IP ayant la même mac dans une notion de réseau rapproché.

Actuellement, nous utilisons nmap qui nous retourne pour une mac un potentiel OS, mais il serait plus intéressant pour une mac donnée d'utiliser une fonction de recherche qui retourne depuis une base local le vendor name.

Exemple ici : https://gist.github.com/aallan/b4bb86db86079509e6159810ae9bd3e4

Actuellement, un subnet qui peut potentiellement englober un autre (un /20 englobant un /24) ne l'englobe pas. Une fonctionnalité de reconstruction du réseau avec l'assemblage des subnet serait intéressante.

Actuellement, le quadrillage est fixé, chaque carré fait 62 pixels de taille.

Cela génère un défaut bête : les écrans et les pages proposés ne sont pas en nombre de pixel des multiples de 62 pixels.

Si l'on souhaite avoir des boites de travaille de tailles multiples à 62 pixels, nous allons avoir des soucis comme cela :

Il y aurait plusieurs solutions à cela :

• Trouver un multiple cohérent pour l'ensemble des tailles d'écran possibles
• utiliser des propriétés CSS pour régler automatiquement la taille de pixels des blocs en multiples de taille d'écran
• autres solutions ?

A priori, l'idée intéressante serait de prendre une taille d'écran X * Y et de dire qu'on divise cette taille par le nombre de blocs que l'on souhaite (64 par exemple ?), ce qui donnerait (X * Y) / 64 = nb de pixels d'un bloc ?

Donc en utilisant des propriétés CSS comme :

--nb_bloc : 64;
--size_bloc : calc(calc(100vh * 100vw) / 64);

Pour définir des variables que l'on pourrais utiliser, cela me semblerais possible ?

Cette phase consiste en l'implémentation des fonctions permettant d'extraire des informations intéressantes via SMB. Les informations qu'on peut retirer sont :

• Domain.
• Forest.
• Hostname.
• Les shares disponibles.
• Le type d'OS.

Actuellement, le scan de subnet contient une valeur hardcodé en front :

Il serait plus intéressant d'avoir une requête backend pour cela qui mettrais à jour le front, en effet, le réseau local peut avoir des IP/CIDR différentes de 192.168.1.0/24 comme 172.168.1.0/24 ou 10.10.0.0/24...

Actuellement, depuis la résolution de l'issue #5 on scan une machine sur ses ports 0-400 uniquement. Proposer à l'utilisateur des variations pour les scans de port comme nmap le propose serait bien plus intéressant. Les widgets du second menu devront être retravaillés en conséquence.

Cette fonctionnalité permettra de récupérer le hostname ainsi que le domain d'une machine en utilisant RDP (Win-RM).

Cette issue à pour but de documenter et d'exploiter au mieux les possibilités du système d'affichage et de visualisation par graph proposé.

Actuellement, le programme s'ouvre et affiche le réseau ciblé.

L'objectif va être de construire un panel d'interface avec un ensemble de fonctionnalité de découverte réseau.

Pour cela, il est nécessaire de :

• Créer un panel au niveau design qui s'ouvre et se referme #15
• Ajouter des widgets visuels de formulaire de scan
• ajouter une animation de requête & une animation de retour de requête (éventuellement une animation de chargement de requête) #20
• Implémenter les appels backend nécessaires (pour le moment seulement deux routes, le scan arp et le fast scan)

Quand un nœud est inutile, il serait de bon aloi de le supprimer, cette fonctionnalité pourrait être rajouté dans le menu "Manipulations du graph" et proposer une vue avec le titre du nœud ainsi que son logo afin d'être certain de ce que l'on supprime.

Je suis globalement instatisfait de visjs qui a été choisi en premier pour des raisons d'accessibilité du code visjs comparé à d'autres lib.

Si on regarde de près les exemples de visjs : https://visjs.github.io/vis-network/examples/
On constate que l'attention est portée sur la capacité à faire des représentations techniques intéressantes à moindre coup basés sur un JSON varié en terme de structure de donnée.

D'autres approches comme celles de la lib cytoscape me semble plus intéressantes (construction non agnostique JSON avec intégration de propriétés plus variés dans le fonctionnement interne des nodes/edges).

Une tentative d'implémentation va être effectué pour voir si le fonctionnement de cytoscape serait plus adapté.

Actuellement, dans le code il y a cette fonctionnalité qui n'est pas exploité :

Elle sert à déterminer quel est le niveau de "confiance" d'un scan identifiant le type de device que l'on a en face.

Cette issue vise à implémenter sa route API ainsi que son implémentation vis a vis du front.

Cette issue vise à trouver les polices de caractères sympa pour l'affichage des éléments visuels.

Actuellement, des recherches ont été faites pour retrouver une police similaire à celle de Arkham Night, sans succès, voir #3 (comment).

La question des différentes couleurs de text se pose aussi par ailleurs.

Le but est de récupérer des informations concernant :

• 600 anciens clients.
• peer NTP, synchro IP.
• IP clients.

Cette découverte me parait un peu flou, je sais pas comment elle peut être exploité et utilisé. Si quelqu'un a des ressources sur le sujet ou des idées.

Actuellement, l'IP + CIDR 192.168.0.0/24 est spécifié en dur. C'est une erreur car un réseau local peut prendre une forme très diverse suivant la gateway et le DHCP qui nous donne les indications ainsi que les routes qui sont donnés sur la machine.

Il faut donc spécifier ces éléments là depuis l'interface web pour s'éviter un maximum de problèmes.

Création de panels visuels permettant de faire de la manipulation de graphs.

• créer des boutons générant les menu
• générer les menu en CSS
• travailler le style & la transparence de ces menu pour coller au design général

Actuellement, le menu de gauche quand il contient trop d'informations, dépasse la taille de l'écran et crée un effet de scrolling malvenu.

On voit bien la barre de scroll tout à droite qui casse tout le styling effectué sur la page et induit un resizing du viewport de la fenêtre entière.

idéalement, une barre de scrolling présent dans le menu de gauche serait plus approprié car il permettrait de ne pas avoir de risque de scroll sur l'écran entier.

L'HTML sur lequel travailler se situe ici :

La classe la plus proche de notre problématique est la classe echo_menu_right en CSS, néanmoins, une nouvelle classe pour gérer les overflow serait peut-être approprié car elle serait généralisable à l'ensemble des menu.

Un favicon au format ico ou png serait un plus :)

Actuellement, le graph se présente sous la forme d'un ensemble de "bulles" de taille différentes.

C'est assez moche en plus de ne pas faciliter le travail de placement de graph, je propose une refonte complète de cet aspect là.

Actuellement, le layout est actualisé lorsque l'on génère un scan général, un bouton permettant d'actualiser le placement layout serait intéressant.

Actuellement, les services liés à une IP sont représentés sous la forme de donnée dans sa variable data. Depuis la résolution de l'issue #5

Nous avons pour objectif de les mettre dans des nœuds liés à l'IP afin de les associer visuellement.

Actuellement, l'utilisateur doit deviner ce que fait chaque menu en cliquant dessus. Un nommage par titre visuel pour chaque menu résoudrais une partie des problèmes que cela engendre.

Le code JSON de scan de service est imbriqué dans du protocol -> port -> data

refaire cela en simple liste contenant le protocol et le port serait beaucoup plus propre pour le front.

Actuellement, une machine a un nœud octogonal avec un fond vert et c'est tout.

Pour différencier les machines, il serait intéressant de mettre en background-image des SVG ou des PNG associé pour chacun à des types de machine génériques, comme "poste utilisateur", "server", "router", "mobile device", etc...

Cette partie de la documentation cytoscape est à prendre en considération obligatoirement btw : https://js.cytoscape.org/#style/background-image

Refactor the backend code so it is easier to read and follows better the best practices.

Actuellement, le code javascript est directement écrit dans la page HTML.

Au niveau du dossier template, nous proposons de séparer cela en deux fichier et de placer le javascript dans le dossier static.

Cette phase permet d'implémenter les fonctions nécessaires à l'extraction d'informations via le protocole SSH. Il est possible d'utiliser HASSH pour obtenir des informations telles que :

• OS.
• Server type/version.

En utilisant le fingerprint ssh.

Actuellement, toute la partie JS a été développé from scratch en visjs sans faire appel à du code AngularJS pour profiter des fonctionnements des directives, components & constructeurs AngularJS.

Je propose de faire une refactoring afin de faciliter les échanges "front-back-end" ainsi que les échanges entre les différents composants de la page au niveau javascript.

Le protocole SNMP n'avait pas été ajouté avec scapy car trop bruyant. Cette proposition vise à l'implémenter pour la découverte avancée.

Ici on liste & référence les méthodes de découverte réseau connues et/ou on ajoute les exemples d'implémentations que l'on trouve.

Actuellement, il manque un try catch dans le cas où une machine scanné ne répond pas.

Cette ligne crash :

En raison de l'absence de l'IP dans nm puisqu'elle n'a pas pu être scanné.
Cela peut être identifié via le retour de commande nmap :

{
    "nmap": {
        "command_line": "nmap -oX - -p 0-400 -sV 192.168.1.9",
        "scaninfo": {
            "tcp": {
                "method": "syn",
                "services": "0-400"
            }
        },
        "scanstats": {
            "timestr": "Sun Mar 13 18:09:42 2022",
            "elapsed": "0.67",
            "uphosts": "0",
            "downhosts": "1",
            "totalhosts": "1"
        }
    },
    "scan": {}
}

Néanmoins, le downhosts n'aidera pas dans un cas de scan multiples...

edit : liste des images d'exemple pour se simplifier la vie :

Dans la mesure où le graph propose un dataset JSON, il serait intéressant de pouvoir le charger/décharger pour en conserver la donnée à la volée.

Outre le scan nmap de base, il y a la possibilité de découvrir les services pour chaque machine, une route recevant comme entrée une IP pour que ça soit asynchrone serait intéressante.

Le bug est le suivant :

Comme dans le code, l'unicité d'un noeud est déterminé de cette façon:

Il faut donc revoir deux choses pour régler ce bug :

• La façon dont on souhaite assurer l'unicité (une façon propre serait de l'assurer via juste l'IP)
• La façon dont on souhaite afficher des données cohérentes (comment décider entre une identification d'OS et une autre ?)/