« HackBBS Reloaded » : différence entre les versions
Aucun résumé des modifications |
Aucun résumé des modifications |
||
(95 versions intermédiaires par 3 utilisateurs non affichées) | |||
Ligne 1 : | Ligne 1 : | ||
== Introduction == | == Introduction == | ||
Avec l'age, de nombreuses fonctionnalitées ont été rajoutées à HackBBS. La qualité originelle du code et les modifications successives ne permettent plus d'avoir quelque chose de maintenable. | |||
C'est dans cette optique que la refonte du site a été envisagée. | |||
== Équipe == | |||
* Korigan : CDP, dev | |||
* Sliim : Root | |||
* Neomoloch : Admin | |||
* Neib : Admin | |||
* TorTukiTu : Architecte, dev | |||
* Lancien : dev | |||
* heaven : GDP (Gestionnaire de projet), dev | |||
* fredo2009 : dev | |||
* Vous ? :-) | |||
=== Les rôles === | |||
L'[[administration des roles|administration des rôles]] doit se faire via un accès à la BDD. | |||
Les utilisateurs peuvent exercer différentes activités liées à des rôles. | |||
# '''Pilot''' | |||
# '''RH (Ressources Humaines)''' | |||
# '''Trainer''' | |||
# '''Architect''' | |||
# '''Developer''' | |||
# '''Renseignement (Intel)''' | |||
# '''Pentester''' | |||
Chaque rôle offre différentes possibilités, telles que décrites dans les sections ci-dessous. | |||
=== Pilot === | |||
L'équipe PILOTE joue un rôle central dans la coordination des activités de recherche et de développement. Les membres de cette équipe sont chargés de diriger les recherches, de donner des instructions à l'équipe INTEL pour définir les objectifs de collecte d'informations, et de collaborer avec les architectes pour concevoir de nouvelles solutions. | |||
==== Responsabilités Principales : ==== | |||
# '''Coordination des Recherches :''' Les pilotes sont responsables de la planification et de la coordination des recherches. Ils définissent les domaines prioritaires et orientent les efforts de l'équipe INTEL en fonction des besoins stratégiques. | |||
# '''Instructions à l'Équipe INTEL :''' Les membres de l'équipe PILOTE travaillent en étroite collaboration avec l'équipe INTEL, leur fournissant des instructions claires sur les informations spécifiques à collecter. Cela peut inclure des données sur les menaces potentielles, les vulnérabilités critiques, ou toute autre information pertinente. | |||
# '''Demandes aux Architectes :''' Les pilotes intéragissent avec l'équipe d'architectes pour concevoir de nouvelles solutions en fonction des exigences identifiées au cours des recherches. Ils spécifient les besoins en termes d'infrastructures, de sécurité, et d'innovations technologiques. | |||
# '''Alignement Stratégique :''' Les membres de l'équipe PILOTE s'assurent que les recherches et les développements sont alignés sur les objectifs stratégiques globaux de l'organisation. Ils ajustent les priorités en fonction des évolutions du paysage technologique et des menaces émergentes. | |||
==== Intéraction avec les Autres Équipes : ==== | |||
* '''INTEL :''' Collaboration étroite pour définir les objectifs de collecte d'informations. | |||
* '''ARCHITECT :''' Demande de conception de solutions adaptées aux besoins identifiés. | |||
* '''TRAINER :''' Identification des besoins en formation pour renforcer les compétences des différentes équipes. | |||
* '''RH :''' Implication dans le recrutement et la constitution d'équipes performantes. | |||
==== Attentes : ==== | |||
Les membres de l'équipe PILOTE sont attendus pour faire preuve de leadership, de vision stratégique, et de compétences analytiques approfondies. Ils doivent être capables de prendre des décisions éclairées, de gérer des projets complexes, et de collaborer efficacement avec d'autres équipes pour atteindre les objectifs organisationnels. En outre, la communication claire des objectifs et des directives est cruciale pour assurer la cohérence dans l'ensemble des opérations de l'entreprise. | |||
=== Ressources Humaines (RH) === | |||
L'équipe RH joue un rôle essentiel dans la gestion des ressources humaines au sein de l'organisation. Leur responsabilité principale est de recruter de nouveaux membres pour les différentes équipes et de gérer la communication autour des différents projets. | |||
==== Responsabilités Principales : ==== | |||
# '''Recrutement :''' L'équipe RH est chargée d'identifier les compétences nécessaires pour chaque équipe et de recruter des membres qualifiés. Cela implique la rédaction d'offres d'emploi, la participation à des salons professionnels, la recherche de profils adéquats, et la réalisation d'entretiens. | |||
# '''Gestion des Effectifs :''' Ils veillent à la constitution d'équipes diversifiées et complémentaires en termes de compétences. L'équipe RH travaille en collaboration avec les responsables d'équipes pour anticiper les besoins en personnel en fonction des projets à venir. | |||
# '''Communication Interne :''' Les membres de l'équipe RH sont chargés de faciliter la communication interne au sein de l'organisation. Ils veillent à ce que les informations pertinentes concernant les projets, les nouveaux membres, et les événements internes soient partagées de manière efficace. | |||
# '''Gestion des Projets RH :''' Ils coordonnent les projets liés aux ressources humaines, tels que les programmes de formation, les évaluations de performance, et les activités de renforcement d'équipe. | |||
# '''Relations Membres :''' L'équipe RH est la première ligne de soutien pour les membres, traitant les préoccupations, résolvant les conflits, et favorisant un environnement de collaboration positif. | |||
==== Intéraction avec les Autres Équipes : ==== | |||
* '''PILOTE :''' Collaboration pour comprendre les besoins en recrutement liés aux projets en cours et à venir. | |||
* '''INTEL :''' Coopération pour identifier les compétences spécifiques requises pour les activités de renseignement. | |||
* '''ARCHITECTE :''' Communication sur les compétences et profils nécessaires pour les nouveaux projets d'architecture. | |||
* '''FORMATEUR :''' Coordination pour s'assurer que les nouvelles recrues reçoivent une formation adéquate. | |||
==== Attentes : ==== | |||
Les membres de l'équipe RH doivent posséder d'excellentes compétences en communication, être capables de comprendre les besoins spécifiques de chaque équipe, et être orientés vers la construction d'équipes performantes. Ils doivent également être proactifs dans la gestion des ressources humaines, anticipant les besoins futurs et assurant un suivi continu pour garantir la satisfaction et le développement professionnel des employés. En outre, la confidentialité et le professionnalisme sont essentiels dans le traitement des informations sensibles liées aux ressources humaines. | |||
=== TRAINER === | |||
L'équipe TRAINER (FORMATEUR) participe à la formation des membres en partageant des documentations, tutoriels, et articles. Elle trie également les demandes d'aide et organise des événements pour former sur différents sujets. Cela peut aller du pilotage, au recrutement en passant par des formations purement techniques afin d'expliquer comment attaquer ou défendre un système. | |||
Les sources d'information de l'équipe FORMATEUR peuvent être catégorisées en diverses catégories telles que : | |||
* Cryptographie/Stéganographie | |||
* Reverse Engineering | |||
* Programmation Réseau | |||
* Management | |||
* ... | |||
(TBC) | |||
=== ARCHITECT === | |||
(TBC) | |||
=== DEVELOPER === | |||
(TBC) | |||
=== INTEL (RENSEIGNEMENT) === | |||
'''Définition :''' L'équipe INTEL a pour mission de collecter et d'organiser des renseignements stratégiques afin d'anticiper les menaces et de renforcer la posture de sécurité de l'organisation. Les sources de données peuvent être issues de l'OSINT (open source intelligence) ou bien de sources privées. | |||
L'information est généralement classifiée en 3 catégories : {Noire, Grise, Blanche}. | |||
* Les informations Noires sont privées et généralement confidentielles ou hautement confidentielles. | |||
* Les données Grises appartiennent généralement à des entreprises ou groupes d'individus. Accessibles aux seuls membres autorisés à y accéder, ces informations ne sont pas confidentielles mais ne sont pas non plus publiques. Ce sont généralement des données issues de réseaux privés. | |||
* Les données Blanches sont publiques. L'OSINT consomme généralement des données blanches et les organise et/ou les met en valeur. | |||
L'équipe INTEL a pour principal but de collecter et d'organiser les données blanches afin que les autres équipes puissent travailler sur des données à jour. Elle collabore avec l'équipe PILOTE qui définit les objectifs à atteindre. Les membres de l'équipe INTEL réalisent des tâches unitaires, chacun aidant comme il le désire. Cependant, le travail est de préférence intégré et intégrable dans des objectifs ayant une portée plus large. Par exemple, l'identification et la caractérisation de cibles (identification d'IP, ports ouverts, versions des serveurs en écoute, CVE des cibles), qui sont des tâches propres à l'équipe INTEL, peuvent aider les équipes EXEC à travailler sur des données précises, et avoir été requises par l'équipe PILOTE qui a besoin d'identifier la source d'une attaque contre nos infrastructures. Les tâches sont donc attribuées par les membres de l'équipe PILOTE de manière individuelle ou collective en fonction des besoins. | |||
Les membres de l'équipe INTEL peuvent souhaiter se subdiviser en plusieurs catégories telles que : | |||
* Reconnaissance | |||
* Collecte d'informations | |||
* Analyse de vulnérabilités | |||
* ... | |||
La collecte de l'intel peut se faire via differentes methodes tel que: | |||
* SIGINT: Le SIGINT est un renseignement dérivé de signaux et de systèmes électroniques utilisés par des cibles étrangères, tels que des systèmes de communication. | |||
* MASINT: MASINT, ou Measurement and Signature Intelligence, est une discipline de renseignement fondée sur la capture et la mesure des caractéristiques et des composants intrinsèques d'un objet ou d'une activité. | |||
* HUMINT : L’intelligence humaine – également connue sous le nom de HUMINT – désigne essentiellement les informations collectées et fournies par une personne. C’est probablement l’un des principaux moyens de collecte de renseignements qui vient à l’esprit lorsque la plupart des gens pensent à l’espionnage. | |||
==== Responsabilités Principales : ==== | |||
# '''Collecte d'Intelligence :''' Les membres de l'équipe INTEL sont chargés de collecter des informations provenant de sources variées, y compris l'OSINT (Open Source Intelligence) et des sources privées. Ils rassemblent des données pertinentes pour comprendre les tendances, les acteurs, et les menaces potentiels. | |||
# '''Classification de l'Information :''' Les données collectées sont classifiées en trois catégories : Noire (confidentielle), Grise (semi-confidentielle), et Blanche (publique). Cette classification permet de déterminer le niveau de sensibilité et de partager les informations de manière appropriée. | |||
# '''Collaboration avec l'Équipe PILOTE :''' L'équipe INTEL travaille en étroite collaboration avec l'équipe PILOTE pour définir les objectifs de collecte d'informations alignés sur la stratégie globale de l'organisation. Ils fournissent des informations cruciales pour orienter les recherches et les opérations. | |||
# '''Analyse de l'Information :''' Les membres de l'équipe INTEL analysent les données collectées pour identifier des tendances, des vulnérabilités potentielles, et des menaces émergentes. Ils produisent des rapports d'analyse détaillés pour informer les prises de décisions au niveau stratégique. | |||
# '''Participation à des Opérations Spécifiques :''' L'équipe INTEL peut être impliquée dans des opérations spécifiques, telles que la recherche approfondie sur des acteurs malveillants, la surveillance d'infrastructures ciblées, et la collecte d'informations sensibles. | |||
==== Interaction avec les Autres Équipes : ==== | |||
* '''PILOTE :''' Définition des objectifs de collecte d'informations et partage des analyses pour orienter les décisions stratégiques. | |||
* '''ARCHITECTE :''' Informations sur les menaces actuelles et potentielles pour guider la conception de nouvelles solutions sécurisées. | |||
* '''EXEC :''' Collaboration pour comprendre les tactiques et techniques d'attaques émergentes, et ajustement des scénarios de tests d'intrusion en conséquence. | |||
* '''FORMATEUR :''' Partage de connaissances sur les dernières tendances en matière de sécurité et de renseignement. | |||
* '''RH :''' Identification des compétences spécifiques nécessaires au sein de l'équipe INTEL. | |||
==== Attentes : ==== | |||
Les membres de l'équipe INTEL doivent avoir des compétences avancées en collecte de renseignements, une compréhension approfondie des menaces cybernétiques, et la capacité à produire des analyses de qualité. La discrétion et le respect des protocoles de sécurité sont impératifs étant donné la nature sensible des informations manipulées. La collaboration et la communication efficace avec les autres équipes sont également essentielles pour garantir une réponse proactive aux menaces. | |||
=== PENTESTER (Execution / Red Team) === | |||
L'équipe EXEC est chargée de mener des attaques de type Red Team, contribuant ainsi à renforcer la sécurité de l'organisation en identifiant les vulnérabilités et en évaluant l'efficacité des mesures de défense. | |||
==== Responsabilités Principales : ==== | |||
# '''Exécution d'Attaques Red Team :''' Les membres de l'équipe EXEC sont des spécialistes en test d'intrusion, chargés de simuler des attaques réalistes pour évaluer la résilience du système de sécurité. Ils utilisent des techniques d'attaques avancées pour identifier les faiblesses potentielles. | |||
# '''Évaluation des Vulnérabilités :''' Ils analysent les systèmes, les réseaux, les applications, et les infrastructures pour découvrir des vulnérabilités susceptibles d'être exploitées par des attaquants réels. Cela inclut la recherche de CVE, l'analyse des configurations, et la recherche de points faibles. | |||
# '''Rapports d'Incidents :''' Les membres de l'équipe EXEC documentent de manière détaillée les résultats de leurs tests d'intrusion, fournissant des rapports complets sur les vulnérabilités découvertes, les vecteurs d'attaque utilisés, et les recommandations pour renforcer la sécurité. | |||
# '''Collaboration avec les Autres Équipes :''' Ils interagissent avec les équipes PILOTE, INTEL, ARCHITECTE, et FORMATEUR pour partager des informations sur les scénarios d'attaques simulées, les résultats des tests, et les leçons apprises. Cette collaboration permet d'améliorer constamment les défenses de l'organisation. | |||
==== Interaction avec les Autres Équipes : ==== | |||
* '''PILOTE :''' Présentation des résultats des attaques simulées, ajustement des scénarios en fonction des objectifs stratégiques. | |||
* '''INTEL :''' Partage d'informations sur les techniques d'attaque émergentes et collaboration pour intégrer ces informations dans les stratégies défensives. | |||
* '''ARCHITECTE :''' Recommandations pour renforcer l'architecture des systèmes en fonction des vulnérabilités identifiées. | |||
* '''FORMATEUR :''' Contribution à la formation de l'équipe sur les dernières techniques d'attaques et les moyens de défense. | |||
* '''RH :''' Participation aux processus de recrutement pour s'assurer que l'équipe EXEC dispose des compétences nécessaires. | |||
==== Attentes : ==== | |||
Les membres de l'équipe EXEC doivent démontrer une expertise approfondie en matière de sécurité informatique, de compréhension des tactiques d'attaques, et de capacité à penser comme un attaquant. Ils doivent être capables de travailler de manière autonome et en équipe, avec un souci du détail pour identifier des vulnérabilités subtiles. La communication claire et la capacité à documenter de manière exhaustive sont cruciales pour garantir la valeur des tests d'intrusion et la mise en place de solutions de sécurité efficaces. | |||
== Liste des tâches pour le developement de HackBBS Reloaded == | |||
* <span style="color:#008000">FAIT</span> - Concevoir et Développer la GUI (IHM) - Korigan / Neib | |||
* <span style="color:#008000">FAIT</span> - Concevoir le noyau - Tortukitu | |||
* <span style="color:#008000">FAIT</span> - Développer des modules testant toutes les fonctionnalitées de base du noyau - Tortukitu / Korigan / Neib | |||
* <span style="color:#008000">FAIT</span> - Créer le dépot [[GIT reloadedHackBBS]] - Korigan | |||
* <span style="color:#008000">FAIT</span> - (Optionnel) Créer le système de gestion de projet et des tickets (Redmine ? autre ?) - Korigan | |||
* <span style="color:#008000">FAIT à revoir avec Korigan</span> - [[Migrer devBBS vers le wiki]] - Neomoloch, Zer00cool, Lancien - <span style="color:#FF0000">Manque 2 fichiers .sql</span> | |||
* <span style="color:#008000">FAIT</span> - Mettre en place un environnement de test et de dev avec une bdd propre et vidée de ses véritables infos - Korigan et? | |||
* <span style="color:#008000">FAIT</span> - Écrire le code métier du noyau - Tortukitu, Korigan | |||
* <span style="color:#008000">FAIT</span> - Écrire le code de la couche consumer du noyau - Tortukitu, Korigan | |||
* <span style="color:#ff0000">A faire</span> - Développer une API pour brancher les challenges (Sous forme d'un Web service SOAP pour pouvoir y brancher facilement des challs situés sur des serveurs externes)- Anybody :) | |||
* <span style="color:#ff0000">En cours</span> - Référencement, campagne publicitaire. - Neomoloch / GoldenBoy | |||
* <span style="color:#008000">FAIT</span> - Traduction de certains passages en langue Bambara (dialecte Africain) - Neomoloch. | |||
Pour une liste complete, voir la [[Roadmap]] | |||
== Contraintes == | == Contraintes == | ||
Ligne 19 : | Ligne 184 : | ||
* PDO | * PDO | ||
* Ajax | * Ajax | ||
* HTML5 | |||
* gitlab? (Cf heaven, sliim et korigan) | |||
== Architecture == | == Architecture == | ||
Ligne 30 : | Ligne 196 : | ||
Le diagramme ci dessous vous présente l'architecture retenue. Une ligne pleine représente une notion de dépendance, une ligne pointillée un flux de communication. | Le diagramme ci dessous vous présente l'architecture retenue. Une ligne pleine représente une notion de dépendance, une ligne pointillée un flux de communication. | ||
[[Fichier:hackbbs_reloaded_architecture.png]] | |||
La communication entre les couches '''DOIT''' suivre le sens indiqué par les flèches. Par exemple, appeller des fonctions dans la couche Consumer depuis la couche Business est autorisé. Par contre appeller des fonctions de la couche Business depuis la couche Consumer est interdit. | La communication entre les couches '''DOIT''' suivre le sens indiqué par les flèches. Par exemple, appeller des fonctions dans la couche Consumer depuis la couche Business est autorisé. Par contre appeller des fonctions de la couche Business depuis la couche Consumer est interdit. | ||
Ligne 43 : | Ligne 209 : | ||
=== Couche provider (Interface utilisateur) === | === Couche provider (Interface utilisateur) === | ||
Une interface de type "terminal" a été | Une interface de type "terminal" a été retenue. Ce type d'interface pose en temps normal des problèmes d'expérience utilisateur, mais s'agissant d'un site de chall, ceci n'entre pas vraiment en ligne de compte. | ||
La gestion du terminal est | La gestion du terminal est effectuée par des fonctions javascript utilisant la lirairie JQuery et ses extensions jTerminal et JQueryUI. | ||
La communication | La communication du serveur vers le client se fait en JSON. C'est en fait un objet DataBusVO sérialisé qui est envoyé du serveur vers le client. La sérialisation est gérée par le script dispatcher.php | ||
L'ensemble du travail des modules consiste donc à générer une instance de DataBusVO qui sera récupérée par dispatcher.php pour modifier l'affichage côté client. | L'ensemble du travail des modules consiste donc à générer une instance de DataBusVO qui sera récupérée par dispatcher.php pour modifier l'affichage côté client. | ||
Les fichiers de cette couche sont situés dans le répertoire '''/ et /resources'''. | Les fichiers de cette couche sont situés dans le répertoire '''/''' et '''/resources'''. | ||
=== Couche business (métier) === | === Couche business (métier) === | ||
Ligne 69 : | Ligne 235 : | ||
Les fichiers de cette couche sont situés dans le répertoire '''/php/core_services/consumer'''. | Les fichiers de cette couche sont situés dans le répertoire '''/php/core_services/consumer'''. | ||
'''Pour consommer des services de cette couche, il faut TOUJOURS le faire via la facade.''' | |||
Voici un diagramme de classes partiel (il manque les méthodes et les attributs...) de la couche consumer : | |||
[[Fichier:class_diagram_consumer.png]] | |||
Pas d'ORM pour ce projet. Pour savoir comment gérer le relationnel, voir la couche transversale modèle. | |||
=== Couche transversale : modèle === | === Couche transversale : modèle === | ||
Ligne 75 : | Ligne 249 : | ||
Les fichiers de cette couche sont situés dans le répertoire '''/php/model'''. | Les fichiers de cette couche sont situés dans le répertoire '''/php/model'''. | ||
Les différents objets du modèle étendent la classe persistent, ce qui permet de donner à chaque instance un identifiant unique. les relations entre objets se font indirectement via leurs identifiants. Il ne faut pas mettre une instance d'un objet dans la variable d'un autre (ce pour éviter les sauvegardes et les chargement en cascade (et éviter un éventuel chargement paresseux d'expérience casse geule à implémenter et à utiliser...)). On a donc opté pour un chargement dynamique des objets a chaque fois que nécéssaire a partir de leurs dentifiants. | |||
Dans notre cas, le coût de cette solution en terme de performances ne devrait pas être un problème. | |||
Dans le cas de relations 1-N, il faut utiliser des arrays d'entiers (identifiants) pour représenter cette relation. | |||
=== Couche transversale : sécurité === | === Couche transversale : sécurité === | ||
Ligne 83 : | Ligne 263 : | ||
TODO. | TODO. | ||
== Infrastructure == | |||
HackBBS Reloaded met a disposition des membre des workspaces qui leurs sont privee. Ces workspace sont situe sur le serveur dans <b>/opt/jail/tmp/workspace/<username></b> | |||
Un second espace de travail en dehors de /var/www est egalement utiliser pour acceuillir les donnees issue de l'activitee <b>intel</b>. Les informations traitee sont situee dans <b>/opt/jail/tmp/intel</b> | |||
== Configuration == | == Configuration == | ||
Ligne 104 : | Ligne 289 : | ||
* function canHandleData($data) : $data est la String que l'utilisateur a entré dans le terminal. Renvoyez true si votre module doit se charger de réaliser l'opération demandée par l'utilisateur, false sinon. | * function canHandleData($data) : $data est la String que l'utilisateur a entré dans le terminal. Renvoyez true si votre module doit se charger de réaliser l'opération demandée par l'utilisateur, false sinon. | ||
* function manageData($data) : $data est la String que l'utilisateur a entré dans le terminal. Ici, réalisez vos traitements, puis renvoyez une instance de DataBusVO contenant les actions que vous voulez effectuer sur le terminal. | * function manageData($data) : $data est la String que l'utilisateur a entré dans le terminal. Ici, réalisez vos traitements, puis renvoyez une instance de DataBusVO contenant les actions que vous voulez effectuer sur le terminal. Voir la page [[Contrôle du terminal via DataBusVO]]. | ||
* function getPrototype() : Renvoie String contenant une description rapide de la commande en HTML. Typiquement <b>macommande</b> : Ce que fait ma commande. | * function getPrototype() : Renvoie String contenant une description rapide de la commande en HTML. Typiquement <b>macommande</b> : Ce que fait ma commande. | ||
Ligne 128 : | Ligne 313 : | ||
} | } | ||
</tt> | </tt> | ||
Cette implémentation est à placer dans le répertoire '''/php/modules'''. | |||
=== Modification du fichier de configuration === | === Modification du fichier de configuration === | ||
Ligne 140 : | Ligne 327 : | ||
Contient tous les fichiers spécifiques au mondule monmodule. Si nécéssaire, découper en couches business, model et consumer. | Contient tous les fichiers spécifiques au mondule monmodule. Si nécéssaire, découper en couches business, model et consumer. | ||
Ce répertoire est à placer dans le répertoire '''/php/modules'''. | |||
'''REMARQUE''' : ''Entorse à l'architecture pendant la partie refonte de HackBBS.. Un développeur de modules ne devrait jamais toucher au noyau. Or, '''<span style="color:#ff0000">la plupart du métier (et modèle) développé aujourd'hui sera nécéssaire à un grand nombre de futur modules. Il est donc de bon ton d'ajouter au métier du noyau les fonctions et services que l'on saura réutilisés dans la suite des développements</span>'''. Ceci est laissé à l'appréciation du développeur. Lorsque la refonte sera terminé, il deviendra interdit aux futurs développeurs de toucher au code du noyau pour y ajouter de nouvelles fonctionnalitées. Les modules préexistants seront alors fusionnés avec le noyau.'' | |||
== Règles générales (A toujours avoir sous les yeux !) == | |||
* A toute classe son interface. | |||
* Jamais de copier coller | |||
* '''Respectez l'architecture''' | |||
* Ne jamais utiliser directement $_SESSION, toujours passser par le service SessionService (sauf exceptions autorisées par l'architecte) | |||
* '''Chaque classe et fonction doit être commentée''' | |||
* '''Pensez sécurité...''' Vous développez un site de hack. Il sera attaqué de la facon la plus tordue possible. Vous avez un service de nettoyage des entrées, alors utilisez-le ! | |||
* Choisissez toujours la convention sur la configuration | |||
* (Optionnel) Écrire une page de wiki par module | |||
* (Optionnel) Si vous avez le temps, les tests unitaires, c'est bien | |||
== FAQ / HOWTO == | |||
* [[FAQ : Développement de modules]] | |||
* [[HOWTO : Modification du modèle du noyau]] | |||
* [[HOWTO : La WebSocket todo.py]] |
Dernière version du 26 septembre 2024 à 21:49
Introduction
Avec l'age, de nombreuses fonctionnalitées ont été rajoutées à HackBBS. La qualité originelle du code et les modifications successives ne permettent plus d'avoir quelque chose de maintenable.
C'est dans cette optique que la refonte du site a été envisagée.
Équipe
- Korigan : CDP, dev
- Sliim : Root
- Neomoloch : Admin
- Neib : Admin
- TorTukiTu : Architecte, dev
- Lancien : dev
- heaven : GDP (Gestionnaire de projet), dev
- fredo2009 : dev
- Vous ? :-)
Les rôles
L'administration des rôles doit se faire via un accès à la BDD.
Les utilisateurs peuvent exercer différentes activités liées à des rôles.
- Pilot
- RH (Ressources Humaines)
- Trainer
- Architect
- Developer
- Renseignement (Intel)
- Pentester
Chaque rôle offre différentes possibilités, telles que décrites dans les sections ci-dessous.
Pilot
L'équipe PILOTE joue un rôle central dans la coordination des activités de recherche et de développement. Les membres de cette équipe sont chargés de diriger les recherches, de donner des instructions à l'équipe INTEL pour définir les objectifs de collecte d'informations, et de collaborer avec les architectes pour concevoir de nouvelles solutions.
Responsabilités Principales :
- Coordination des Recherches : Les pilotes sont responsables de la planification et de la coordination des recherches. Ils définissent les domaines prioritaires et orientent les efforts de l'équipe INTEL en fonction des besoins stratégiques.
- Instructions à l'Équipe INTEL : Les membres de l'équipe PILOTE travaillent en étroite collaboration avec l'équipe INTEL, leur fournissant des instructions claires sur les informations spécifiques à collecter. Cela peut inclure des données sur les menaces potentielles, les vulnérabilités critiques, ou toute autre information pertinente.
- Demandes aux Architectes : Les pilotes intéragissent avec l'équipe d'architectes pour concevoir de nouvelles solutions en fonction des exigences identifiées au cours des recherches. Ils spécifient les besoins en termes d'infrastructures, de sécurité, et d'innovations technologiques.
- Alignement Stratégique : Les membres de l'équipe PILOTE s'assurent que les recherches et les développements sont alignés sur les objectifs stratégiques globaux de l'organisation. Ils ajustent les priorités en fonction des évolutions du paysage technologique et des menaces émergentes.
Intéraction avec les Autres Équipes :
- INTEL : Collaboration étroite pour définir les objectifs de collecte d'informations.
- ARCHITECT : Demande de conception de solutions adaptées aux besoins identifiés.
- TRAINER : Identification des besoins en formation pour renforcer les compétences des différentes équipes.
- RH : Implication dans le recrutement et la constitution d'équipes performantes.
Attentes :
Les membres de l'équipe PILOTE sont attendus pour faire preuve de leadership, de vision stratégique, et de compétences analytiques approfondies. Ils doivent être capables de prendre des décisions éclairées, de gérer des projets complexes, et de collaborer efficacement avec d'autres équipes pour atteindre les objectifs organisationnels. En outre, la communication claire des objectifs et des directives est cruciale pour assurer la cohérence dans l'ensemble des opérations de l'entreprise.
Ressources Humaines (RH)
L'équipe RH joue un rôle essentiel dans la gestion des ressources humaines au sein de l'organisation. Leur responsabilité principale est de recruter de nouveaux membres pour les différentes équipes et de gérer la communication autour des différents projets.
Responsabilités Principales :
- Recrutement : L'équipe RH est chargée d'identifier les compétences nécessaires pour chaque équipe et de recruter des membres qualifiés. Cela implique la rédaction d'offres d'emploi, la participation à des salons professionnels, la recherche de profils adéquats, et la réalisation d'entretiens.
- Gestion des Effectifs : Ils veillent à la constitution d'équipes diversifiées et complémentaires en termes de compétences. L'équipe RH travaille en collaboration avec les responsables d'équipes pour anticiper les besoins en personnel en fonction des projets à venir.
- Communication Interne : Les membres de l'équipe RH sont chargés de faciliter la communication interne au sein de l'organisation. Ils veillent à ce que les informations pertinentes concernant les projets, les nouveaux membres, et les événements internes soient partagées de manière efficace.
- Gestion des Projets RH : Ils coordonnent les projets liés aux ressources humaines, tels que les programmes de formation, les évaluations de performance, et les activités de renforcement d'équipe.
- Relations Membres : L'équipe RH est la première ligne de soutien pour les membres, traitant les préoccupations, résolvant les conflits, et favorisant un environnement de collaboration positif.
Intéraction avec les Autres Équipes :
- PILOTE : Collaboration pour comprendre les besoins en recrutement liés aux projets en cours et à venir.
- INTEL : Coopération pour identifier les compétences spécifiques requises pour les activités de renseignement.
- ARCHITECTE : Communication sur les compétences et profils nécessaires pour les nouveaux projets d'architecture.
- FORMATEUR : Coordination pour s'assurer que les nouvelles recrues reçoivent une formation adéquate.
Attentes :
Les membres de l'équipe RH doivent posséder d'excellentes compétences en communication, être capables de comprendre les besoins spécifiques de chaque équipe, et être orientés vers la construction d'équipes performantes. Ils doivent également être proactifs dans la gestion des ressources humaines, anticipant les besoins futurs et assurant un suivi continu pour garantir la satisfaction et le développement professionnel des employés. En outre, la confidentialité et le professionnalisme sont essentiels dans le traitement des informations sensibles liées aux ressources humaines.
TRAINER
L'équipe TRAINER (FORMATEUR) participe à la formation des membres en partageant des documentations, tutoriels, et articles. Elle trie également les demandes d'aide et organise des événements pour former sur différents sujets. Cela peut aller du pilotage, au recrutement en passant par des formations purement techniques afin d'expliquer comment attaquer ou défendre un système.
Les sources d'information de l'équipe FORMATEUR peuvent être catégorisées en diverses catégories telles que :
- Cryptographie/Stéganographie
- Reverse Engineering
- Programmation Réseau
- Management
- ...
(TBC)
ARCHITECT
(TBC)
DEVELOPER
(TBC)
INTEL (RENSEIGNEMENT)
Définition : L'équipe INTEL a pour mission de collecter et d'organiser des renseignements stratégiques afin d'anticiper les menaces et de renforcer la posture de sécurité de l'organisation. Les sources de données peuvent être issues de l'OSINT (open source intelligence) ou bien de sources privées.
L'information est généralement classifiée en 3 catégories : {Noire, Grise, Blanche}.
- Les informations Noires sont privées et généralement confidentielles ou hautement confidentielles.
- Les données Grises appartiennent généralement à des entreprises ou groupes d'individus. Accessibles aux seuls membres autorisés à y accéder, ces informations ne sont pas confidentielles mais ne sont pas non plus publiques. Ce sont généralement des données issues de réseaux privés.
- Les données Blanches sont publiques. L'OSINT consomme généralement des données blanches et les organise et/ou les met en valeur.
L'équipe INTEL a pour principal but de collecter et d'organiser les données blanches afin que les autres équipes puissent travailler sur des données à jour. Elle collabore avec l'équipe PILOTE qui définit les objectifs à atteindre. Les membres de l'équipe INTEL réalisent des tâches unitaires, chacun aidant comme il le désire. Cependant, le travail est de préférence intégré et intégrable dans des objectifs ayant une portée plus large. Par exemple, l'identification et la caractérisation de cibles (identification d'IP, ports ouverts, versions des serveurs en écoute, CVE des cibles), qui sont des tâches propres à l'équipe INTEL, peuvent aider les équipes EXEC à travailler sur des données précises, et avoir été requises par l'équipe PILOTE qui a besoin d'identifier la source d'une attaque contre nos infrastructures. Les tâches sont donc attribuées par les membres de l'équipe PILOTE de manière individuelle ou collective en fonction des besoins.
Les membres de l'équipe INTEL peuvent souhaiter se subdiviser en plusieurs catégories telles que :
- Reconnaissance
- Collecte d'informations
- Analyse de vulnérabilités
- ...
La collecte de l'intel peut se faire via differentes methodes tel que:
- SIGINT: Le SIGINT est un renseignement dérivé de signaux et de systèmes électroniques utilisés par des cibles étrangères, tels que des systèmes de communication.
- MASINT: MASINT, ou Measurement and Signature Intelligence, est une discipline de renseignement fondée sur la capture et la mesure des caractéristiques et des composants intrinsèques d'un objet ou d'une activité.
- HUMINT : L’intelligence humaine – également connue sous le nom de HUMINT – désigne essentiellement les informations collectées et fournies par une personne. C’est probablement l’un des principaux moyens de collecte de renseignements qui vient à l’esprit lorsque la plupart des gens pensent à l’espionnage.
Responsabilités Principales :
- Collecte d'Intelligence : Les membres de l'équipe INTEL sont chargés de collecter des informations provenant de sources variées, y compris l'OSINT (Open Source Intelligence) et des sources privées. Ils rassemblent des données pertinentes pour comprendre les tendances, les acteurs, et les menaces potentiels.
- Classification de l'Information : Les données collectées sont classifiées en trois catégories : Noire (confidentielle), Grise (semi-confidentielle), et Blanche (publique). Cette classification permet de déterminer le niveau de sensibilité et de partager les informations de manière appropriée.
- Collaboration avec l'Équipe PILOTE : L'équipe INTEL travaille en étroite collaboration avec l'équipe PILOTE pour définir les objectifs de collecte d'informations alignés sur la stratégie globale de l'organisation. Ils fournissent des informations cruciales pour orienter les recherches et les opérations.
- Analyse de l'Information : Les membres de l'équipe INTEL analysent les données collectées pour identifier des tendances, des vulnérabilités potentielles, et des menaces émergentes. Ils produisent des rapports d'analyse détaillés pour informer les prises de décisions au niveau stratégique.
- Participation à des Opérations Spécifiques : L'équipe INTEL peut être impliquée dans des opérations spécifiques, telles que la recherche approfondie sur des acteurs malveillants, la surveillance d'infrastructures ciblées, et la collecte d'informations sensibles.
Interaction avec les Autres Équipes :
- PILOTE : Définition des objectifs de collecte d'informations et partage des analyses pour orienter les décisions stratégiques.
- ARCHITECTE : Informations sur les menaces actuelles et potentielles pour guider la conception de nouvelles solutions sécurisées.
- EXEC : Collaboration pour comprendre les tactiques et techniques d'attaques émergentes, et ajustement des scénarios de tests d'intrusion en conséquence.
- FORMATEUR : Partage de connaissances sur les dernières tendances en matière de sécurité et de renseignement.
- RH : Identification des compétences spécifiques nécessaires au sein de l'équipe INTEL.
Attentes :
Les membres de l'équipe INTEL doivent avoir des compétences avancées en collecte de renseignements, une compréhension approfondie des menaces cybernétiques, et la capacité à produire des analyses de qualité. La discrétion et le respect des protocoles de sécurité sont impératifs étant donné la nature sensible des informations manipulées. La collaboration et la communication efficace avec les autres équipes sont également essentielles pour garantir une réponse proactive aux menaces.
PENTESTER (Execution / Red Team)
L'équipe EXEC est chargée de mener des attaques de type Red Team, contribuant ainsi à renforcer la sécurité de l'organisation en identifiant les vulnérabilités et en évaluant l'efficacité des mesures de défense.
Responsabilités Principales :
- Exécution d'Attaques Red Team : Les membres de l'équipe EXEC sont des spécialistes en test d'intrusion, chargés de simuler des attaques réalistes pour évaluer la résilience du système de sécurité. Ils utilisent des techniques d'attaques avancées pour identifier les faiblesses potentielles.
- Évaluation des Vulnérabilités : Ils analysent les systèmes, les réseaux, les applications, et les infrastructures pour découvrir des vulnérabilités susceptibles d'être exploitées par des attaquants réels. Cela inclut la recherche de CVE, l'analyse des configurations, et la recherche de points faibles.
- Rapports d'Incidents : Les membres de l'équipe EXEC documentent de manière détaillée les résultats de leurs tests d'intrusion, fournissant des rapports complets sur les vulnérabilités découvertes, les vecteurs d'attaque utilisés, et les recommandations pour renforcer la sécurité.
- Collaboration avec les Autres Équipes : Ils interagissent avec les équipes PILOTE, INTEL, ARCHITECTE, et FORMATEUR pour partager des informations sur les scénarios d'attaques simulées, les résultats des tests, et les leçons apprises. Cette collaboration permet d'améliorer constamment les défenses de l'organisation.
Interaction avec les Autres Équipes :
- PILOTE : Présentation des résultats des attaques simulées, ajustement des scénarios en fonction des objectifs stratégiques.
- INTEL : Partage d'informations sur les techniques d'attaque émergentes et collaboration pour intégrer ces informations dans les stratégies défensives.
- ARCHITECTE : Recommandations pour renforcer l'architecture des systèmes en fonction des vulnérabilités identifiées.
- FORMATEUR : Contribution à la formation de l'équipe sur les dernières techniques d'attaques et les moyens de défense.
- RH : Participation aux processus de recrutement pour s'assurer que l'équipe EXEC dispose des compétences nécessaires.
Attentes :
Les membres de l'équipe EXEC doivent démontrer une expertise approfondie en matière de sécurité informatique, de compréhension des tactiques d'attaques, et de capacité à penser comme un attaquant. Ils doivent être capables de travailler de manière autonome et en équipe, avec un souci du détail pour identifier des vulnérabilités subtiles. La communication claire et la capacité à documenter de manière exhaustive sont cruciales pour garantir la valeur des tests d'intrusion et la mise en place de solutions de sécurité efficaces.
Liste des tâches pour le developement de HackBBS Reloaded
- FAIT - Concevoir et Développer la GUI (IHM) - Korigan / Neib
- FAIT - Concevoir le noyau - Tortukitu
- FAIT - Développer des modules testant toutes les fonctionnalitées de base du noyau - Tortukitu / Korigan / Neib
- FAIT - Créer le dépot GIT reloadedHackBBS - Korigan
- FAIT - (Optionnel) Créer le système de gestion de projet et des tickets (Redmine ? autre ?) - Korigan
- FAIT à revoir avec Korigan - Migrer devBBS vers le wiki - Neomoloch, Zer00cool, Lancien - Manque 2 fichiers .sql
- FAIT - Mettre en place un environnement de test et de dev avec une bdd propre et vidée de ses véritables infos - Korigan et?
- FAIT - Écrire le code métier du noyau - Tortukitu, Korigan
- FAIT - Écrire le code de la couche consumer du noyau - Tortukitu, Korigan
- A faire - Développer une API pour brancher les challenges (Sous forme d'un Web service SOAP pour pouvoir y brancher facilement des challs situés sur des serveurs externes)- Anybody :)
- En cours - Référencement, campagne publicitaire. - Neomoloch / GoldenBoy
- FAIT - Traduction de certains passages en langue Bambara (dialecte Africain) - Neomoloch.
Pour une liste complete, voir la Roadmap
Contraintes
- Utiliser l'installation et la configuration actuelle du serveur Apache2
- Utiliser des technologies les plus connues et les plus répandues possibles. (Ce qui permettra une implication plus large de la communautée)
- Utiliser des technologies permettant une modularité
- Utiliser des technologies pouvant s'interfacer avec MySQL (Réutilisation de la base de données existante)
- Limiter au maximum l'utilisation de frameworks pour que le projet soit maintenable avec un bagage de connaissances minimum
Technologies retenues
- PHP
- PDO
- Ajax
- HTML5
- gitlab? (Cf heaven, sliim et korigan)
Architecture
Il s'agit d'une architecture 3 couches:
- Une couche gère l'interface utiisateur
- Une couche contient le code métier
- Une couche consomme les différents services (Tape dans les bases de données, envoie les emails, etc.).
Le diagramme ci dessous vous présente l'architecture retenue. Une ligne pleine représente une notion de dépendance, une ligne pointillée un flux de communication.
Erreur lors de la création de la vignette : Impossible d’enregistrer la vignette sur la destination
La communication entre les couches DOIT suivre le sens indiqué par les flèches. Par exemple, appeller des fonctions dans la couche Consumer depuis la couche Business est autorisé. Par contre appeller des fonctions de la couche Business depuis la couche Consumer est interdit.
Une approche par script de transaction a été choisie. Ce qui signifie que les objets du modèle ne DOIVENT JAMAIS comporter des fonctions métier de traitement.
D'une manière plus générale, retenez seulement que vos modules ne devraient accéder QUE a la couche business du noyau (et les couches transversales tel que le modèle ou la sécurité).
L'ensemble de l'application est extensible via l'utilisation de modules (cf. schéma).
Couche provider (Interface utilisateur)
Une interface de type "terminal" a été retenue. Ce type d'interface pose en temps normal des problèmes d'expérience utilisateur, mais s'agissant d'un site de chall, ceci n'entre pas vraiment en ligne de compte. La gestion du terminal est effectuée par des fonctions javascript utilisant la lirairie JQuery et ses extensions jTerminal et JQueryUI.
La communication du serveur vers le client se fait en JSON. C'est en fait un objet DataBusVO sérialisé qui est envoyé du serveur vers le client. La sérialisation est gérée par le script dispatcher.php
L'ensemble du travail des modules consiste donc à générer une instance de DataBusVO qui sera récupérée par dispatcher.php pour modifier l'affichage côté client.
Les fichiers de cette couche sont situés dans le répertoire / et /resources.
Couche business (métier)
La couche métier présente des services aux couches supérieures. Ces services consistent en des singletons ou, plus exotiquement, des fonctions statiques. Les services présentés sont les suivants:
- LoaderService : Gère le chargement dynamique des modules.
- SecurityService : Fourni des fonctions de vérification des permissions des utilisateurs
- SessionService : Gère l'étanchéité des variables de sessions entre différents modules, fournis des fonctions de récupération de l'utilisateur courant
- UserService : Fournis des fonctions de CRUD des utilisatuers, de vérification de connection d'un utilisateur
- SanitizerService : Fournis des fonctions de nettoyage des variables utilisateur.
Les fichiers de cette couche sont situés dans le répertoire /php/core_services/business et /php/modules.
Couche consumer (consommateur de services)
Cette couche conient des services de manipulation de la base de données et d'envoi d'emails.
Les fichiers de cette couche sont situés dans le répertoire /php/core_services/consumer.
Pour consommer des services de cette couche, il faut TOUJOURS le faire via la facade.
Voici un diagramme de classes partiel (il manque les méthodes et les attributs...) de la couche consumer :
Erreur lors de la création de la vignette : Impossible d’enregistrer la vignette sur la destination
Pas d'ORM pour ce projet. Pour savoir comment gérer le relationnel, voir la couche transversale modèle.
Couche transversale : modèle
Cette couche contient des objets porteurs de données dont les instances sont transportés d'une couche à l'autre. Par exemple, la couche consumer crée une instance de User qui est renvoyé à la couche Business.
Les fichiers de cette couche sont situés dans le répertoire /php/model.
Les différents objets du modèle étendent la classe persistent, ce qui permet de donner à chaque instance un identifiant unique. les relations entre objets se font indirectement via leurs identifiants. Il ne faut pas mettre une instance d'un objet dans la variable d'un autre (ce pour éviter les sauvegardes et les chargement en cascade (et éviter un éventuel chargement paresseux d'expérience casse geule à implémenter et à utiliser...)). On a donc opté pour un chargement dynamique des objets a chaque fois que nécéssaire a partir de leurs dentifiants.
Dans notre cas, le coût de cette solution en terme de performances ne devrait pas être un problème.
Dans le cas de relations 1-N, il faut utiliser des arrays d'entiers (identifiants) pour représenter cette relation.
Couche transversale : sécurité
TODO.
Couche transversale : logging
TODO.
Infrastructure
HackBBS Reloaded met a disposition des membre des workspaces qui leurs sont privee. Ces workspace sont situe sur le serveur dans /opt/jail/tmp/workspace/<username>
Un second espace de travail en dehors de /var/www est egalement utiliser pour acceuillir les donnees issue de l'activitee intel. Les informations traitee sont situee dans /opt/jail/tmp/intel
Configuration
La configuration (données d'accès aux bases, définition des modules à charger) se trouve dans le fichier hackbbsConf.ini dans le répertoire /php/conf/
Détail du fichier de confguration
Développement de modules
Un module (ici Monmodule) est consitué de trois éléments:
- Une implémentation de l'interface IModule (obligatoire) appellé par convention MonmoduleModule.
- Un dossier (optionnel) appellé par convention monmoduleModule.
- Une déclaration names[] = Monmodule dans le fichier de configuration hackbbsConf.ini (obligatoire).
ATTENTION ! Tous les modules doivent se trouver dans le dossier /php/modules. Veillez à bien respecter les conventions de nommage. Sinon, votre module ne sera pas chargé par le LoaderService et ne sera pas disponible dans le terminal.
Implémentation de IModule
L'interface à implémenter (/php/contract/IModule) compte 3 fonctions :
- function canHandleData($data) : $data est la String que l'utilisateur a entré dans le terminal. Renvoyez true si votre module doit se charger de réaliser l'opération demandée par l'utilisateur, false sinon.
- function manageData($data) : $data est la String que l'utilisateur a entré dans le terminal. Ici, réalisez vos traitements, puis renvoyez une instance de DataBusVO contenant les actions que vous voulez effectuer sur le terminal. Voir la page Contrôle du terminal via DataBusVO.
- function getPrototype() : Renvoie String contenant une description rapide de la commande en HTML. Typiquement macommande : Ce que fait ma commande.
Ci dessous une implémentation de démonstration de IModule
class MonmoduleModule implements IModule{
public function canHandleData($data) { $ans = false; if($data == "macommande"){ $ans = true; } return $ans; } public function getPrototype() { return "macommande : Ce que fait ma commande"; } public function manageData($data) { $dataBus = new DataBusVO(); $dataBus->setHtmlData("Cette comande ne fait rien de particulier."); return $dataBus; }
}
Cette implémentation est à placer dans le répertoire /php/modules.
Modification du fichier de configuration
Ajouter la ligne :
names[] = Monmodule
A la fin de la section [modules] du fichier /php/conf/hackbbsConf.ini
Répertoire monmoduleModule
Contient tous les fichiers spécifiques au mondule monmodule. Si nécéssaire, découper en couches business, model et consumer. Ce répertoire est à placer dans le répertoire /php/modules.
REMARQUE : Entorse à l'architecture pendant la partie refonte de HackBBS.. Un développeur de modules ne devrait jamais toucher au noyau. Or, la plupart du métier (et modèle) développé aujourd'hui sera nécéssaire à un grand nombre de futur modules. Il est donc de bon ton d'ajouter au métier du noyau les fonctions et services que l'on saura réutilisés dans la suite des développements. Ceci est laissé à l'appréciation du développeur. Lorsque la refonte sera terminé, il deviendra interdit aux futurs développeurs de toucher au code du noyau pour y ajouter de nouvelles fonctionnalitées. Les modules préexistants seront alors fusionnés avec le noyau.
Règles générales (A toujours avoir sous les yeux !)
- A toute classe son interface.
- Jamais de copier coller
- Respectez l'architecture
- Ne jamais utiliser directement $_SESSION, toujours passser par le service SessionService (sauf exceptions autorisées par l'architecte)
- Chaque classe et fonction doit être commentée
- Pensez sécurité... Vous développez un site de hack. Il sera attaqué de la facon la plus tordue possible. Vous avez un service de nettoyage des entrées, alors utilisez-le !
- Choisissez toujours la convention sur la configuration
- (Optionnel) Écrire une page de wiki par module
- (Optionnel) Si vous avez le temps, les tests unitaires, c'est bien