| 05-04-2010 23:35:28 | #1 | |
| Valérian | Suite aux discussions qui ont eu lieux dans ce topic, il m'apparait utile de réfléchir à ce que peux faire un hackeur (et ne pas faire) une fois dans un noeud et comment le gérer en terme de règles. Le but est d'encadrer notamment ce que peux faire un hackeur ayant réussi à pénétrer dans un noeud avec un compte admin. Les limites des règles canon tiennent, selon moi, dans le fait que si elles gèrent une complexité accrue lors de la phase d'intrusion dans le noeud lorsque l'on désire obtenir un compte sécurité ou admin. Une fois dans le noeud (sans se faire repérer par le firewall), le hackeur n'a plus rien à craindre vu qu'il a le droit de désactiver les sécurités qui pourraient le menacer et peux facilement se débarrasser des spiders, CI et admin (en les déconnectant et en bloquant leur connexion par la suite), ce qui est un peu trop facile à mon goût. Règles alternatives proposées : Le processus pour s'introduire dans un noeud ne change pas par rapport aux règles canons, un hacker doit toujours choisir son niveau de privilège (utilisateur, sécurité ou admin) et tenter de s'introduire dans le noeud sans se faire repérer par le Firewall. Ce processus vise en fait à exploiter les failles du systèmes pour ouvrir une session sur le noeud associée à un compte bidon créé par le hackeur. Là où ces règles s'éloignent du canon, c'est que le niveau de privilèges associé au compte du hackeur (et qui a été choisi lors de l'intrusion) détermine uniquement ce à quoi le hackeur peut potentiellement accéder dans le noeud, mais sans lui donner pour autant la légitimité pour le faire (pour rappel, le hackeur utilise un compte bidon, lequel n'a aucune légitimité pour le système). Pour agir dans le noeud, le hackeur va donc être obligé de faire des jets de hacking pour passer outre les contrôles de légitimité que va faire le système quand le hackeur cherche à activer certaines commandes. Pour passer outre un contrôle de légitimité, le hackeur doit obtenir au moins un succès excédentaire sur un jet opposé à Système + Firewall. Le hackeur lance pour sa part : Hacking + Exploitation s'il veut forcer une commande à destination de l'OS du noeud. Hacking + Edition s'il veut forcer l'accès à des données stockées dans le noeud. Hacking + Commande s'il veut forcer une commande à destination d'une CI tournant sur le noeud. Si le hackeur n'obtient pas un nombre suffisant de succès, non seulement il échoue mais le système génère automatiquement une alarme anti-intrusion contre lui. A noter au passage que cela donne une vraie utilité à l'option de programme Silencieux (voir Unwired p112). Pour information, dans les règles canons, un hackeur peut faire tout ce qui est associé au niveau de privilège qu'il a pu obtenir sans faire de jet et sans que le système se pose la question de savoir s'il est légitime ou non pour faire une telle chose. Exemple 1 : un hackeur réussit à s'introduire dans un noeud corporatiste pour y voler des données, en obtenant un compte avec des privilèges de sécurité. Il repère aussitôt une CI venant vers lui pour l'examiner en tant que nouvel utilisateur connecté. Comme ses privilèges lui permettent de commander les CI du noeud, il décide de tenter d'interdire à la CI de l'examiner. Il fait donc pour cela un test de Hacking+Commande contre le Pilote + Firewall de la CI. Sa tentative réussit aussi la CI s'éloigne de lui sans l'avoir scanné. Le hackeur est donc libre de repérer le fichier de données qu'il est venu voler et de contrôler s'il contient une bombe matricielle (ces deux actions n'affectent pas le noeud et sont donc dépourvues d'un contrôle de légitimité). Pour copier le fichier auquel il n'est pas légitimement en droit d'accéder, le hackeur doit réussir un test opposé de Hacking+Edition contre Système+Firewall. C'est une réussite, le hackeur réussit donc à voler les données, il ne lui reste plus qu'à dissimuler ses traces. Comme le hackeur dispose d'un compte sécurité, il est en droit de supprimer un fichier du noeud, aussi il peut tenter de supprimer ses traces en supprimant le fichier d'historique d'accès via un jet de Hacking + Edition contre Système+Firewall. Par malheur, sa tentative échoue, aussi le noeud déclenche une alarme à son encontre et le Firewall reçoit un bonus de +4. Jugeant qu'il va être encore plus difficile de supprimer le fichier historique, le hackeur renonce à effacer ses traces et se déconnecte du noeud. Exemple 2 : la situation est la même que pour l'exemple 1, mais le hackeur ne dispose cette fois-ci que d'un compte utilisateur standard. Le hackeur ne peut rien faire pour empêcher la CI de venir examiner son icône via un test de perception matricielle : Pilote+Analyse contre Hacking+Furtivité. Heureusement, le programme Furtivité réussit à tromper la CI est cette dernière s'éloigne sans donner l'alerte. Le hackeur peut repérer le fichier qu'il est venu voler puis une fois trouvé, contrôler s'il est protégé ou non par une bombe matricielle. Pour copier le fichier auquel il n'est pas légitimement en droit d'accéder, le hackeur doit réussir un test opposé de Hacking+Edition contre Système+Firewall. Ce test étant réussit, le hackeur a pu voler le fichier, mais cette fois-ci, ses privilèges ne lui permettent pas de supprimer le fichier d'historique d'accès et encore moins d'en éditer le contenu. Règle optionnelle : si le MJ le souhaite, il peut autoriser un hackeur à tenter de faire quelque chose correspondant à un profil de privilèges supérieur au sien. Cela se résout par un test de Hacking+Programme (variable) contre Système+Firewall, mais avec un malus de -3 au jet de hacking si on veut faire une action réservée à un compte sécurité, ou bien un malus de -6 si l'action est réservée à un compte admin. Alerte anti-intrusion : lorsqu'une alerte est déclenchée à l'encontre d'un utilisateur, il n'est plus considéré par le système comme légitime (à noter que ca ne change rien pour un compte bidon créé par un hackeur) et s'il veut continuer à donner des ordres au système, il devra faire des tests de Hacking+Programme (variable) contre Système+Firewall+4 (le bonus de +4 provient de l'alerte). Déconnexion d'un utilisateur : le système peut recevoir de la part d'un admin ou d'un spider un ordre de déconnexion d'un utilisateur. Le système fait alors un test étendu de Système+Firewall (Exploitation, 1 tour de combat). Le seuil est augmenté de +2 si l'utilisateur dispose de privilèges sécurité et d'un +4 s'il dispose de privilèges d'admin et ce, même s'il ne fait pas tourner de programme Exploitation. A noter que certains spiders et admin font justement tourner un programme exploitation dans leur persona pour éviter d'être déconnecté trop rapidement si un hackeur réussit à s'introduire dans leur noeud avec des privilèges suffisants pour déconnecter des utilisateurs légitimes. | |
| 06-04-2010 09:26:57 | #2 | |
| Mephisto | Valérian a écrit: Une fois dans le noeud (sans se faire repérer par le firewall), le hackeur n'a plus rien à craindre vu qu'il a le droit de désactiver les sécurités qui pourraient le menacer et peux facilement se débarrasser des spiders, CI et admin (en les déconnectant et en bloquant leur connexion par la suite), ce qui est un peu trop facile à mon goût. Entièrement d'accord. Un hacker avec un bon programme de Furtivité n'a pas grand chose à craindre vu qu'il peut s'introduire pratiquement partout sans se faire repérer. Ensuite, une fois connecté en tant qu'admin, il fait plus ou moins ce qu'il veut. J'aime bien ton système et je pense que je vais le proposer à mes joueurs. | |
| 06-04-2010 14:02:14 | #3 | |
| okhin | Je suis pas d'acord avec ton interprétation des règles Val' (Si une atcion est illégitime pour un compte, c'est un jet avec Hacking et donc un jet du node pour tenter de repérer le hacker). Une proposition pourrait être de gérer ça avec une pile de sécurité à la SR3. Au lieu de faire un jet contre le Stealth du hacker, le node fait un jet _étendu_ contre le Stealth du hacker. Donc, plus le hacker prend du temps, plus il va avoir une probabilité de se faire basher. Eteindre une alarme ou autre, est une action de cybercombat (planter un programme ou un node) et donc, déclenche une alerte passive automatique (+4 au Firewall), ou une action de Falsification de commande (Spoof) et ne réussit pas forcément (et comme c'ets avec Hacking, le hacker va s'en prendre plein la tête). Le hacker peut faire baisser son indice de sécurité en faisant une action de Falsification de piste matricielle, le nombre de succès net faisant baisser l'indice de sécurtité du node. Quand le node dépasse le programme Stealth du hacker, il entre en alerte anti-intrusion. Et continue de faire ses jets. Quand il arrive à une nouvelle transche de succés équivalent au stealth du hacker, paf, re-alerte (donc envoi de CI par exemple, ou autre). Le problème de ta règle Val', c'ets que Stealth ne sert quasiment plus à rien (ou quelque chose m'échappes). Et que, au final, elle ne change pas de la norme. SI j'ai un compte root (en volant un mot de passe, en falsifiant des credentials ou en utilisant une escalade de privilège), je suis Dieu dans ce node. Et le système n'y peut rien. Mais, effectivement, c'est beaucoup plus dur. Sur de la planification, ça va me prendre 6 succès de plus (donc, en gros, doubler on nombre de jet, et donc le temps nécessaire à préparer ma connexion), sur du hack à la volée, il est probable que je rentre dans un serveur en état d'alerte (et donc, qui aura nécessité déjà 4 dés de plus, étant donné qu'il aura déclencher une alerte passive). Je comprends que cela puisse choquer les gens, masi une fois root dans la mahine, la sécurité système à perdu. Game Over. Tu peux rebooter ta machine en mode hors-loigne pour la diagnostiquer et la patcher. Et tu peux même mettre pas mal de temps avant de t'en apercevoir. Cela dit, je ne pense pas que ça soit si ultime que ça. Déjà, dans 90% des cas, ce n'est pas nécessaire (planter un node ou récupérer une info, ça se fait avec un compte user ou sécu au mieux, ps besoin de plus). Ce qu'il faudrait, c'ets une incitation pour que les joueurs ne prennent pas de compte admin quand ce n'est pas nécessaire. Déjà, en pénalisant l'usage de a RV hot-sim, qui est juste trop répandue (alors que ça reste une drogue) au profit de la RA. Pour trouver une faille, aps besoin de RV, juste des bonens routines d'exploitation et de temps. Donc, sur les jets de Hacking + Exploit, je mettrai tout le monde à 1 jour par jet pour préparer sa passe. De fait, beaucoup de hacker prendront un compte user ou sécu. Ensuite, il est toujours possible de faire des structures matricielles spéciales. C'est à dire qu'un admin ne peut se connecter qu'à un seul node de la structure, vu que ce login est réservé pour la maintenance. Du coup, Si je suis admin sur un node, je ne peux pas me connecter au node d'à côté. Ce qui va encourager les hackers à privilégier un compte de sécurité. Enfin, il n'est pas déconnant de dire que, si un utilisateur se connecte en Admin, il se retrouve automatqiuement avec uen alerte de sécurité. En gros, cette alerte est là pour signaler au spider qu'il est en mode admin, et donc, qu'il doit faire gaffeà ce qu'il fait. Cela prend en compte aussi les backups de logs supplémentaire et autre. Pour terminer, un compte admin est un compte trés bien protégé. Qui va, en égénral, éncessiter au moins une clef physique qu'il va donc falloir imiter avant de pouvoir se loguer. Avec tout ça tu as un compte admin qui est nettement moins intéressant à hacker, et qui va demander un peu plsu de finesse à tes hackers. Okhin | |
| 06-04-2010 14:08:10 | #4 | |
| Blade | D'autant plus que dans un node de parano même l'admin peut avoir à rentrer des mots de passe ou autre pour effectuer certaines opérations sensibles, ou peut lever des alertes si jamais il se connecte depuis un point d'accès différent de l'habituel, etc. | |
| 06-04-2010 14:41:28 | #5 | |
| Mephisto | okhin a écrit: Je comprends que cela puisse choquer les gens, masi une fois root dans la mahine, la sécurité système à perdu. Game Over. Tu peux rebooter ta machine en mode hors-loigne pour la diagnostiquer et la patcher. Et tu peux même mettre pas mal de temps avant de t'en apercevoir Ça me paraît normal. Cependant, c'est d'un intérêt très limité pour le jeu: tout se joue pratiquement lors de la tentative d'intrusion. De plus, le programme de Furtivité a beaucoup trop d'importance en comparaison aux autres programmes. Si tu le blindes correctement, tu ne risques pas grand chose à part les databombs. Ou alors avec des configurations vraiment tordues, genre l'admin qui déclenche une alerte automatiquement. Pour terminer, un compte admin est un compte trés bien protégé. Qui va, en égénral, éncessiter au moins une clef physique qu'il va donc falloir imiter avant de pouvoir se loguer. Le hacker peut quand même se créer un compte bidon sans avoir de clé. Déjà, en pénalisant l'usage de a RV hot-sim, qui est juste trop répandue (alors que ça reste une drogue) au profit de la RA. Pour trouver une faille, aps besoin de RV, juste des bonens routines d'exploitation et de temps. Donc, sur les jets de Hacking + Exploit, je mettrai tout le monde à 1 jour par jet pour préparer sa passe. De fait, beaucoup de hacker prendront un compte user ou sécu. Le cold-sim est tout à fait légal et permet de hacker aussi vite qu'en hot-sim. Et franchement, je préfère corser le run matriciel une fois que le hacker a réussi à s'introduire dans le nœud plutôt que d'augmenter le temps nécessaire à l'intrusion. Une proposition pourrait être de gérer ça avec une pile de sécurité à la SR3. Au lieu de faire un jet contre le Stealth du hacker, le node fait un jet _étendu_ contre le Stealth du hacker. Donc, plus le hacker prend du temps, plus il va avoir une probabilité de se faire basher. Eteindre une alarme ou autre, est une action de cybercombat (planter un programme ou un node) et donc, déclenche une alerte passive automatique (+4 au Firewall), ou une action de Falsification de commande (Spoof) et ne réussit pas forcément (et comme c'ets avec Hacking, le hacker va s'en prendre plein la tête). Le hacker peut faire baisser son indice de sécurité en faisant une action de Falsification de piste matricielle, le nombre de succès net faisant baisser l'indice de sécurtité du node. Quand le node dépasse le programme Stealth du hacker, il entre en alerte anti-intrusion. Et continue de faire ses jets. Quand il arrive à une nouvelle transche de succés équivalent au stealth du hacker, paf, re-alerte (donc envoi de CI par exemple, ou autre). En fait il y a déjà une règle optionnelle qui gère ça dans Unwired, p.39: Some groups may want to simulate Matrix systems that slowly become aware of an unauthorized user, rather than using the “breaking into a warehouse” analogy. The node accumulates hits toward an Extended Test threshold; the number of hits accumulated in this test is called the security tally. When an intruder first successfully hacks into a node, add the number of hits the node had accumulated in its Analyze + Firewall roll(s) to the security tally. Then, every time the hacker performs actions for which she uses the Hacking skill, the node makes an Analyze + Firewall Success Test and adds the number of hits to the security tally. If at any point the security tally reaches the threshold of (14 – node’s System), an active alert is initiated against the hacker. A hacker may reduce the security tally by Editing the access log, as she would normally. Under the security tally rules, however, rather than making a specific Edit Test, every hit on the test reduces the security tally by one. If the security tally is greater than zero when the hacker logs out, there is enough information to Track the hacker (as in The Access Log, p. 65). A part forcer le hacker à modifier régulièrement l'access log (raison de plus pour se logger en tant qu'admin), au final ça ne fait pas grand chose. | |
| 06-04-2010 16:02:25 | #6 | |
| okhin | Ne pas oublier que l'indice d'un soft est limité par le système. Qu'un Soft 4+, illégal qui plus, est n'est pas forcément simple à trouver. Et un Soft peut-être bugué (sans que le joeuur ne le sache), surtout si il est récupéré via des canaux clandestins. Ou codé à la main. En fait, il faut partir du principe qu'une passe matricielle sera un succès. toujours, dans tout les cas, du moment que le hacker a accès à suffisament de temps pour faire et préparer sa passe, et suffisament de puissance de frappe. Le second point n'étatnt pas un problème, la seule chose qui pourra faire chier un hacker, c'est le temps. Si il n'as que 3 heure devant lui pour préparer sa passe, il ne pourra faire que 3 jets pour passer le firewall, il n'aura donc, à priori, qu'un compte normal ou de sécu (ou alors, il lance beaucoup trop de dés). Si l'alarme reboote le node, le hacker n'aura que N tour pour finir sa passe. Ou annuler l'ordre de reboot (et ce n'est, je crois, pas possible). Si le node va le détecter, il va devoir cramer des actions pour relocaliser et éditer l'access node (au moins une action à chaque fois), et donc perdre du temps. EN plein combat, un tour de combat, ca peut jouer. Pour ralentir le hacker, j'aurait tendance à dire que toute modification du système nécessite un jet étendu de Hacking + Utilitaire (la liste proposé par Val me paraît pas mal) avec un seuil de Indice de Système du node. Comme c'ets un jet de Hacking, pour chaque jet qu'il fera, il augmente les chances d'être détecté. Là, on a quelque chose de plus sympa. Applicable dans tous les cas. Sauf si tu choppes un compte admin. Pour ce dernier cas, il faut vraiement se dire qu'avec suffisament de temps et de ressources un hacker finira toujours par casser le système. Donc, ne leur laissez pas 3 jours pour faire une passe matricielle, mais 4 heures. Okhin | |
| 06-04-2010 17:13:16 | #7 | |
| Mephisto | okhin a écrit: Ne pas oublier que l'indice d'un soft est limité par le système. Qu'un Soft 4+, illégal qui plus, est n'est pas forcément simple à trouver. Et un Soft peut-être bugué (sans que le joeuur ne le sache), surtout si il est récupéré via des canaux clandestins. Ou codé à la main. Oui bon, on peut quand même assez facilement atteindre des scores plus élevés que ça. Le TM peut threader ses formes complexes, le hacker a accès aux programmes ergonomiques et l'IA a ses programmes inhérents. Un runner qui se spécialise dans ce domaine fera tout pour monter son score en Furtivité à un niveau maximum. En fait, il faut partir du principe qu'une passe matricielle sera un succès. toujours, dans tout les cas, du moment que le hacker a accès à suffisament de temps pour faire et préparer sa passe, et suffisament de puissance de frappe. Le second point n'étatnt pas un problème, la seule chose qui pourra faire chier un hacker, c'est le temps. Je doute que n'importe qui arrive à hacker la Zurich-Orbital, même sans limite de temps. | |
| 06-04-2010 17:22:20 | #8 | |
| okhin | Ben, un hacker spécialsié en Furtivité, sera moins bon en Exploit ou en Cybercombat hein. ET, encore uen fois, je préfères être capable de réduire ma passe matricielle d'un tour que de gagner un point de Furtiv. Un hacker peut hacker la ZO avec un temps et des ressources infinie. Le système est blindé de faille, il y a trop de personens dans la boucle et, clairement, ils n'ont pas tout prévu. Juste que si tu as deux mois pour le faire, c'est pas forcément assez long. Okhin | |
| 06-04-2010 18:45:50 | #9 | |
| Valérian | il y a 2 choses différentes dans ma proposition de règles alter : Primo, le point essentiel est qu'un hackeur introduit dans un système ne réussisse plus automatiquement ce qu'il fait (quand l'action tentée s'inscrit dans les privilèges de son compte hacké) car il utilise après tout un compte créé de toute pièce qui aura forcément l'air bancal si on regarde de plus près. Secundo, le premier point étant acté, il reste à savoir comment gérer cela au niveau règles : 1) Soit par un test étendu pour le hacking avec un test étendu pour le système (ce que propose Okhin). 2) Soit par un test en opposition (ce que j'ai proposé moi). 3) Soit par un test étendu pour le hacking avec un test simple (ou opposé) pour le système. 4) Soit par un test simple pour le hacking. J'ai fait le choix d'un test en opposition car cela permet de savoir facilement si le hackeur réussit sa tentative ou pas, et cela permet indirectement de mettre en alerte le système vis-à-vis du hackeur. Okhin fait du temps la notion essentielle d'une passe matricielle (avant et pendant l'intrusion), donc il s'oriente plus naturellement vers des tests étendus en parallèles. Dans la théorie, je suis plutôt d'accord avec cette philosophie, mais dans la pratique, j'ai peur que : - Ca soit beaucoup plus long à la résolution de la passe matricielle (on fait plus de jets). - Ce soit un peu chiant à gérer pour le MJ (ca implique des actions se prolongeant entre les PI avec un degré d'avancement à noter quelque part). - Ca soit compliqué à équilibrer pour avoir un truc qui rend bien la tension de la scène, sans que ca pousse obligatoirement les hackeurs a tout faire en hotsim à 5 PI. Ceci étant dit, je reste open pour envisager de gérer cela d'une autre manière que celle que j'ai proposée. | |
| 12-04-2010 00:22:25 | #10 | |
| Valérian | J'ai re-réfléchis un peu à la question : Je me suis dit qu'un hackeur peut toujours trouver une faille à exploiter pour s'introduire dans un système et que l'on ne peut se fier entièrement à l'OS pour gérer la sécurité d'un noeud. L'idée est donc que la sécurité contre les hackeurs devrait plutôt être prise en charge par les CI et/ou un spider. Je ne change toujours rien à la règle de hack à la volée ni au hack après avoir sondé la cible. C'est après que cela peut se corser pour un hackeur : Je pars sur le principe qu'un hackeur peut difficilement à la fois prétendre des droits particuliers (en l'occurrence un compte sécurité ou un compte admin) et chercher à dissimuler sa nature non-légitime (via son programme de Furtivité). Cela veut dire que les CI en action dans le noeud vont examiner plus scrupuleusement un nouvel utilisateur avec un compte sécurité ou admin. Concrètement, la CI fait un test de perception matricielle auquel résiste le hackeur par un jet de Hacking+Furtivité, avec un malus de 3 s'il a un compte sécurité et un malus de 6 s'il a un compte admin. Du coup, cela redonne un certain intérêt aux CI en patrouille (sans les malus, elles ne servent pas à grand chose contre un bon hackeur) et atténue l'efficacité de sonder la cible pour chopper un compte admin (le test de détection Firewall lors de l'intrusion est généralement une formalité avec un bon programme de Furtivité, mais maintenant il faut espérer ne pas se faire repérer par une CI). En plus, cela a une certaine logique d'un point de vue "métaphore" : si on veut accéder à des fonctions réservées à son niveau de privilège, par exemple le donjon, si la métaphore du noeud représente un château fort, il faudra avoir l'air d'un seigneur ou d'un chevalier pour se présenter à la herse du donjon et être contrôlé à cette occasion par le garde qui se tient à coté. Reste à faire un test de perception matricielle pour savoir s'il vous reconnait ou pas. Le malus traduit le fait que le garde connait normalement les personnes importantes du château. A noter qu'un utilisateur n'est logiquement pas autorisé à accéder à une fonction auquel il n'a pas le droit de part son niveau de privilège (pour reprendre la métaphore précédente, un paysan ne peux accéder au donjon du château). En effet, avoir un compte privilégié implique de devoir le revendiquer comme tel. Ce principe exclue de pouvoir accéder discrètement à une fonction privilégiée via un compte d'accès plus faible par le hacking. Éventuellement, on peut autoriser de tenter une telle manœuvre, mais dans ce cas, elle déclenchera automatiquement une alerte (toujours avec la même métaphore, cela revient pour un paysan a tenté de passer en courant la herse du donjon en prenant par surprise le garde... ce dernier n'aura peut être pas le réflexe de vous arrêter, mais il va déclencher à coup sur l'alarme). Reste toujours à voir comment gérer le contrôle des privilèges de compte. En particulier pour les données sensibles d'un noeud, notamment le journal d'accès et la table des comptes utilisateurs. | |
| 12-04-2010 08:43:45 | #11 | |
| Menditso | J'aime pas le côté auitomatique de l'alarme quand on utilise Hacking. Ça sert à rien d'utiliser Hacking du coup, ça incite à prendre un compte admin. Ou à engager le cybercombat d'entrée de jeu. Cela dit, la réflexion avec les CI est intéressantes. C'est déjà couvert par les règles (il faut que je voit comment). ET, à priori, je ne pense pas qu'elle soit si inefficace que ça (encore une fois 6 en Stealth et en Hacking, ça pique, à peu près autant qu'un Street Sam avec 6 en Agi et en flinue hein), c'est un test en opposition donc si l'IC lance autant de dé que le hacker ça peut se gérer au final. Pour en revenir à ta proposition, je pencherai plus pur un bonus aux jet de l'IC qu'un malus au hacker (je suis pas sûrq ue ça soit statistiquement équivalent sur des jets opposés), bous qui pourrrait être égal au nombre de succès qu'à aligné le node contre le hacker pour le détecter. Enfin, il y a les IC Trace qui peuvent se déclencher automatiquement sur tous les comptes d'un certains type d'utilisateur par exemple. Permettanat de loguer ce que font les admins et les spiders en cas de crash. Elles sont furtives et remontent facilement la trace du hacker (tant que celui-là ne fait pas de falsification). Okhin | |
| 12-04-2010 10:01:55 | #12 | |
| Valérian | Ce n'est peut être pas nécessaire de mettre une alerte automatique, mais ca doit être significativement plus dur de hacker une fonction qui ne correspond pas à tes privilèges que de hacker un truc auquel tu as potentiellement accès. Si on veut renforcer les défenses, je me dit qu'il faudrait peut être aussi prévoir des CI "fixes" pour monter la garde (à développer). Pour le bonus vs malus, je vais revoir si un modificateur ne doit pas s'appliquer au personnage "actif" (celui qui doit obtenir un succès de plus pour l'emporter), auquel cas ce serait plutôt un +6 à la CI qu'un -6 au hackeur (je suis parti sur cette idée par analogie avec la falsification). | |
| 12-04-2010 10:26:34 | #13 | |
| okhin | Ben, si tu es admin, tu as TOUS les privilèges. C'est le principe même de ce compte (et de la compétence Informatique aussi, qui ne sert qu'à ça). Si tu rends la moindre passe matricielle impossible à réussir furtivement, tu tues virtuellement le hacking, faisant basculer les joueurs dan sun système qui privilégie le cybercombat à outrance et en supprimant l'intelligence de la passe matricielle. Un peu comme si tu déclenchais une alarme dans un complexe corpo dés que les runners rentrent, quel que soit leur niveau de préparation. Du coup, ils foncent de manière systématique dans le tas. Cela dit, donner un avantage aux IC de 6 dés pour détecter le hacker, c'est assez énorme (ça fait 2 hits statistique, ça impose donc au hacker d'avoir 6 dés de plus pour compenser). Je filerait probablement plus un +2 et un +4 aux IC. OPU alors, des CI traces qui se déclenchent dés qu'un utilisateur se connecte en admin (et, pour peu qu'elle soit Furtive, le hacker ne la voit pas forcément non plus). Okhin | |
| 13-04-2010 01:29:09 | #14 | |
| Valérian | Envisageons les différents cas possibles pour une action à tenter dans un noeud : 1) un utilisateur légitime avec le privilège associée à l'action tentée : l'action réussit sans jet. 2) un utilisateur légitime sans privilège : l'action échoue car interdite par le système. 3) un utilisateur légitime avec le privilège mais qui s'est pris une alerte : l'action échoue car refusée. 4) un hackeur (non légitime) avec le privilège 5) un hackeur (non légitime) sans le privilège 6) un hackeur (non légitime) avec le privilège mais qui s'est pris une alerte 7) un hackeur (non légitime) sans le privilège et en plus s'est pris une alerte  un utilisateur légitime sans privilège mais forçant le système par hacking9) un utilisateur légitime sans privilège, avec une alerte et forçant le système par hacking Dans les règles canons, avec le cas 4, le hackeur peut faire son action sans jet car le système ignore la non-légitimité du hackeur. C'est le premier point que je veux changer car ca rend le hacking trop facile avec un compte admin : il suffit d'aller dans la table des comptes utilisateurs, de convertir son compte bidon en compte admin légitime et le tour est joué. Je souhaite donc que dans le cas 4, un hackeur soit obligé de faire un jet de hacking pour déclencher l'action souhaitée. Cela correspond au contrôle que réalise le système pour s'assurer de la légitimité de l'utilisateur lorsqu'il demande à utiliser une fonction. Voyons le cas 5 maintenant : on peut autoriser un hackeur a tenté de déclencher l'action mais il doit d'abord passer outre le contrôle de légitimité, puis passer outre le contrôle de son niveau de privilège (ou l'inverse, mais ca revient à peu près au même). Du coup c'est un test qui se doit d'être plus difficile que le test du cas 4 (et ce d'autant plus qu'il faut que le hackeur paye son absence de privilège vu qu'il a fait le choix de ne pas en prendre lors de son intrusion). Pour le cas 6, les règles stipulent qu'en cas d'alerte, un utilisateur perd ses privilèges ce qui lui fait retomber sur le cas 5, à la différence près que cette fois ci, le firewall du noeud a un bonus de +4 qui doit être pris en compte lors de la tentative de hacking car cela doit être plus dur de forcer le système quand celui ci est sur ces gardes. Pour le cas 7, vu que l'alerte a suspendu les privilèges de l'utilisateur, on retombe dans le cas 6. Pour le cas 8, il est similaire au cas 5. Pour le cas 9, il est similaire au cas 8 hormis que le Firewall est boosté suite à l'alerte. on retombe en fait sur le cas 6. Voici pour l'inventaire des différentes situations que l'on peut rencontrer lorsqu'un utilisateur cherche à faire quelque chose dans un noeud. Par le biais des équivalences, on retrouve finalement 3 ou 4 situations types : 4) un hackeur (non légitime) avec privilège 5) un hackeur (non légitime) sans privilège 6) un hackeur (non légitime) avec privilège mais avec alerte 7) un hackeur (non légitime) sans privilège et avec alerte (ca peut être le même cas que 6 suivant la manière dont on gère l'alerte). Le mécanise a retenir doit tenir compte de cela. | |
| 13-04-2010 09:38:09 | #15 | |
| okhin | 4) Informatique / pas d'heuristique de détection, il y a un compte valide (ou qui paraît comme tel suite à l'utilisation d'un exploit logiciel). Les IC de patrouille sont là pour ça. Les databomb, honeypot et autres aussi. 5) Hacking / Firewall + Analyse VS Stealth 6 = 7) Hacking / Firewall + 4 + Analyse VS Stealth Je vois aps où est le problème en fait, le cas 4 est géré par l'infrastructure matricielle, en rajoutant des IC ou autre, le reste est géré dans les règles. Oui, si il a un Stealth costaud, le hacker est à peu près tranquille. Et après, il suffit de mettre un honeypot en place our détecter l'intrusion assez simplement. Okhin | |
| 13-04-2010 10:56:19 | #16 | |
| okhin | Bon, en y réfléchissant dans le métro, j'ai pensé à quelque chose pour le cas 4 (qui est, au final, le seul qui n'est pas géré par les règles, quoique). Plutôt que de compliquer la tâche du hacker, il peut être intéressant de se poser la question de ce qui va différencier un compte obtenu par une faille et un compte légitime (créé par les sysop ou validé par un hacker après un exploit). Il y a deux principales différences AMHA: Le point d'accès du node, ca se voit via le persona, donc avec Firewall + Analyse, c'est géré via les règles. La seconde est le comportement. Un utilisateur légitime n'utilisera que certains fichier et n'en utilisera pas d'autres. On peut donc poser des pièges. Un hacker prudent n'y toucheras pas (amis il ne touchera qu'à ce qu'il a besoin), mais un autre pourra toujours essayer de looter des paydatas, déclenchant une alerte dés que le fichier est accédé. Une variante de databomb en quelque sorte, mais au lieu d'infliger des dégats, elle déclenche une alerte (probablement une CI trace en fait). Je ne pense pas avoir vu ce software dans Unwired ou SR4A, donc c'est probablement ce qu'il manque. Un déclencheur en gros. Tu prends les même règles que la Databomb, tu lui rajoutes des options de furtivité et autre et tu mets une IC Trace dormante dans le node au même endroit. Après, tant que le hacker se comporte comme un utilisateur normal, je ne pense pas qu'il puisse être détecté (il a réussi à faire croire au node qu'il a un compte légitime, il se comporte comme tel, il ne menace pas l'intégrité du système, ej ne voit aps comment il pourrait déclencher une alerte). Okhin | |
| 13-04-2010 12:49:32 | #17 | |
| Carmody | Salut à tous, Je fais un petit hors-sujet : en lisant ce post (ainsi que d'autres) je comprend que pour effectuer une action pour laquelle on a les droits on utilise la compétence informatique et pour la même action mais sans avoir les droits on utilise hacking (avec un risque de détection). Par contre je n'ai pas réussi à trouver à quel endroit de SR4A/Unwired cela est expliqué. Quelqu'un peut il m'aider ? Merci d'avance | |
| 13-04-2010 13:35:11 | #18 | |
| Valérian | A ma connaissance, c'est nul part. Quand tu fais un truc dans un noeud et que tu es un utilisateur légitime, bien souvent il n'y a pas de jet à faire. Ceci dit, s'il faut que tu fasses un jet (par exemple pour éditer quelque chose), tu ne peux logiquement pas utilisé hacking (vu que tu as le droit de faire le jet) donc tu utilises Informatique. D'autre part, il y a un cas d'utilisation un peu illogique de la compétence Hacking, c'est lors d'une défense totale en cybercombat : on ajoute Hacking à la pool de défense habituelle (Réponse+Firewall), ce qui est un peu bizarre (il faudrait plutôt ajouter Cybercombat ou Informatique à mon avis). | |
| 14-04-2010 01:51:01 | #19 | |
| Valérian | Comme c'est ce que je cherche à faire depuis le début : lorsqu'un hackeur disposant du privilège adéquat tente d'utiliser une fonction du système, il a toujours une chance que cela ne marche pas et que le système déclenche une alerte active à son encontre. Niveau règles, le hackeur fait un test opposé de Hacking+Soft utilitaire contre Système+Firewall du noeud. Si le hackeur obtient plus de succès, sa commande est prise en compte par le noeud. Si c'est le noeud qui l'emporte, la commande est rejetée et le noeud déclenche une alerte active contre l'utilisateur. Si le hackeur ne dispose pas du privilège adéquat, il peut toujours tenter de forcer la main au système, mais cela devient nettement plus corsé vu qu'il doit contourner les contrôles de privilège du système. Niveau règles, le hackeur fait un test opposé de Hacking+Soft utilitaire avec un malus de -3 s'il veut forcer une commande "sécurité" ou bien un malus de -6 s'il veut forcer une commande "admin". Le noeud fait quant à lui toujours un jet de Système+Firewall. Même interprétation des résultats que dans le cas précédent. Si d'aventure, le noeud déclenche une alerte active à l'encontre du hackeur, ce dernier est démasqué (son programme Furtivité ne fait plus effet contre le noeud et ses défenses). Il peut toujours tenter de forcer des commandes avec l'une ou l'autre des 2 méthodes ci-dessus suivant qu'il ait ou non le privilège requis, mais il ne faut pas oublié que pour ces tests opposés, le Firewall du noeud a reçu un bonus de +4 du fait de l'alerte active, ce qui rend les choses plus compliquées pour le hackeur (voir très compliquées s'il veut tenter de forcer une commande sans privilège, mais il faut voir qu'il est dans le cas le plus défavorable). Pour éviter de subir un malus de -3 ou -6 à certaines tentatives d'action (et donc avoir un champ d'action plus large), le hackeur peut avoir intérêt à s'introduire dans le noeud avec un compte sécurité ou un compte admin, plutôt qu'un compte utilisateur. Cependant, il faut garder à l'esprit que les défenses actives d'un noeud sont plus vigilantes envers les comptes disposant de privilèges supérieurs justement car cela les rend plus dangereux en cas de hacking. Niveau règles, les CI et les spiders disposent d'un bonus à leurs tests de perception matricielle de +3 pour analyser un compte sécurité et de +6 pour analyser un compte admin. C'est au hackeur, avant qu'il tente de s'introduire dans un noeud, de voir s'il préfère avoir un compte utilisateur relativement discret mais limité en capacité dans le noeud ou s'il veut un compte avec privilège qui lui offrira plus de possibilités (ou tout de moins de facilités) mais au prix d'un risque supérieur d'être repérer par les défenses du noeud. Les défenses actives d'un noeud correspondent à un certain nombre de CI chargées de diverses rôles : CI de patrouille : dès qu'un nouvel utilisateur se connecte, la CI vient analyser son icône par un test de perception matricielle. S'il n'y a pas beaucoup de trafic sur le noeud, les CI peuvent avoir le temps de réanalyser les utilisateurs déjà connectés au hasard. CI de pistage : c'est une sous-catégorie de CI de patrouille dédiée à surveiller les comptes sécurité et admin sur les serveur corporatistes. Non seulement cette CI fait un test de perception matricielle mais enchaine ensuite avec des actions de pistage pour localiser l'origine du compte privilégié, laquelle doit mener à une installation ou un noeud de la corporation. Si ce n'est pas le cas, la Ci va prévenir un spider pour qu'il surveille le compte en question. CI gardienne : contrairement aux CI en patrouille, cette CI est statique vu qu'elle est chargée de surveiller les accès aux fonctions d'administration du noeud. A chaque fois qu'un utilisateur veut transmettre une commande admin au noeud, la CI va systématiquement refaire un test de perception matricielle envers l'icône de l'utilisateur. CI analytique : Cette CI embarque un programme Catalogue afin de pouvoir examiner et analyser les données que le système inscrit dans le journal d'accès. la CI est chargée d'y repérer les connexions/actions frauduleuses pour pouvoir prévenir un spider (elle fait pour cela un test de Pilot+Catalogue et doit obtenir 2 succès). Pour rappel, le journal d'accès n'est compilé sous une forme lisible que "Système tours" après qu'une action se soit passée. une CI analytique va donc détecter les actions frauduleuses d'un hackeur après un temps de retard. CI antivirale : cette CI analyse par Perception Astrale les programmes des utilisateurs à la recherche de virus à purger, afin d'éviter leur propagation. CI désarmement : cette CI agit généralement après les CI de patrouille afin d'utiliser leur programme Désarmement à l'encontre de certains programmes des utilisateurs, afin qu'il ne puissent en faire usage contre le noeud et ses défenses. Pour rappel, un utilisateur peut accéder à un noeud tout en disposant de programmes qu'il ne sera normalement pas autorisé à utiliser sur le noeud (ex: utilisateur avec des programmes de hacking ou de combat). Ces défenses actives peuvent bien sur être couplées aux moyens classiques pour ralentir les hackeurs : cryptage de fichiers ou du node, bombes matricielles, leurres et/ou pots de miel... A noter toutefois que tout cela consomme de la ressource et à un prix non négligeable, donc beaucoup de nodes n'ont pas toutes ces sécurités. Indépendamment de tout cela, je pense qu'il faudrait généraliser le principe des comptes privilégiés pour créer d'autres profils types (ex: super-utilisateur, administrateur restreint) afin d'enrichir les choix lors des passes matricielles. | |
| 14-04-2010 08:05:44 | #20 | |
| Carmody | J'aii passé du temps hier à chercher la règle qui indique qu'on peut utiliser hacking+programme pour faire une action pour laquelle on n'a pas les droits mais sans réel succès. Tout ce que j'ai trouvé est dans Unwired p(VO) on peut lire : Unwired (VO) a écrit: A node on alert gains a +4 bonus to its Firewall against the intruder specified in the alert. Additionally, all privileges involving the node itself (such as deactivating programs or agents, rebooting, editing files, etc.) are no longer automatically allowed to the trespasser, who must either use the Hacking skill to perform such actions or Spoof a command from a legitimate user that still has her permissions intact. The young hacker, /dev/grrl, has hacked herself an admin account, but she glitches on a roll and an active alert ensues. While she normally would have been able to Edit the node’s access log without rolling, she now must make an Opposed Hacking + Edit Test against the node’s Firewall + System to do so. Quelqu'un peut-il m'aider ? la vrai règle elle est où ?? Valérian a écrit: Indépendamment de tout cela, je pense qu'il faudrait généraliser le principe des comptes privilégiés pour créer d'autres profils types (ex: super-utilisateur, administrateur restreint) afin d'enrichir les choix lors des passes matricielles. Ca c'est un avis que je ne partage pas, pour ma part je réfléchit plutot à fusionner administrateur et sécurité (mais c'est pas dit que je le fasse). Je pense que multiplier les comptes ne fait que rajouter de la lourdeur (ca peut faire quoi ce niveau déjà, attend je réfléchit. ..) sans apporter grand chose. | |
| 14-04-2010 08:55:30 | #21 | |
| Valérian | Je te confirme qu'il n'y a que cet exemple qui parle d'un test pour forcer la main au système... et encore, il peut s'interpréter de diverses façon. | |
| 14-04-2010 09:05:03 | #22 | |
| Carmody | Merci Valerian, tu me rassures je sais encore lire  Okhin, d'où viennent ces règles ? c'est de l'alter ? (en tous cas ça me plait bien) Okhin a écrit: 4) Informatique / pas d'heuristique de détection, il y a un compte valide (ou qui paraît comme tel suite à l'utilisation d'un exploit logiciel). Les IC de patrouille sont là pour ça. Les databomb, honeypot et autres aussi. 5) Hacking / Firewall + Analyse VS Stealth 6 = 7) Hacking / Firewall + 4 + Analyse VS Stealth | |
| 14-04-2010 11:00:10 | #23 | |
| okhin | Bah non, tu lis la description des compétences du LdB et ça colle. A mettre en lien aussi avec l'ensemble des actions matricielle qui vont en gros se résumer en Action légale (et qui utilisent toujours Informatique ou DataSearch) et action de Hacking (et donc, tu utilise toujorus Hacking et Electronic warfare). Quand aux tests du node, c'ets écrit dans le pargaraphe "Hacké, une fois à l'intérieur" ou un trruc du genre. Ta solution me gène Val', puisque tu rend inutile la compétence Informatique qui, justement, est là pour les actions légitimes (AMHA). Par contre, j'aime bien le bonus au jet d'analyse des IC sur les comptes admin et sécurité. Et tes CI sont intéressante, même si j'aurais tendance à les grouper dans une ou deux IC, une partie d'entre elle (la première notament) étant gérée par le Firewall. C'est même à ça que ça sert. Et c'ets pour ça qu'il faut effectuer un jet de Hacking + Exploit pour rentrer dedans. C'ets un niveau de recul supplémentaire, mais qui ne fait aps de mal (sinon, n va retomber dans la matrice SR3 et là, c'est la zone). Ah, et, au final, on ne réussit pas tant d'actions que ça dans la Matrice. Dés que le node est un peu velu, et que l'on cherche à rester planquer, ça pique un peu les yeux de faire une passe correcte. Si ça devient statistiquement impossible (+6 au seuil de toutes tes actions? Ça à un coup juste énorme) ça rend certaines passes discrètes irréalisable, incitant à foncer dans le tas et à sortir Cybercombat, Armure et Attaque au lieu de Stealth et Analyse. Donc voulori rendre la matrice plus dure, va juste forcezr à faire des deckers old-school d'une part qui ne feront rien d'autre, et des cybercombattant complètement bourrin qui, au final, n'apporterons aps grand chose au groupe. Si en plus, les règles sont devenues complexe, autant ne pas jouer de hacker. Okhin | |
| 14-04-2010 12:12:32 | #24 | |
| Valérian | Heu, à aucun moment, je n'ai dit que j'augmentais un Seuil de 6. Les tests que j'ai proposés font appel à des jets en opposition avec éventuellement un modificateur à la pool de dés de de +/-3 ou +/-6. Ce peut paraitre beaucoup, mais d'une part cela se justifie suivant le test réalisé (ex: tu es un simple utilisateur et tu cherches à réaliser une action réservée à l'admin du noeud : test opposé en Hacking+Exploitation-6 et Firewall+système. Si tu veux juste lire un fichier appartenant à un autre utilisateur, tu n'es pas bloqué par le système de privilège, aussi c'est juste un jet de Hacking+Exploitation versus Firewall+Système). D'autre part, un malus de -6 pour le système ce n'est pas si terrible que cela : Un noeud correcte aura un système 3, Firewall 3 soit 6 dés. Un hackeur moyen (3 en compétence) avec un programme de niveau 4, en RV hotsim (+2) a une pool de 9 dés. S'il veut améliorer encore son score, il a de la marge sur sa compétence et son programme, mais il peut aussi avoir une spécialisation à sa compétence (+2), avoir l'avantage bon codeur (+2), diposer d'un implant Céphalon (+1 ou +2) et je crois même qu'il y a des nanites qui peuvent donner un bonus aux compétences matricielles. Un PJ hackeur peut facilement à la création avoir un compétence de 4 avec spécialisation, un programme 5 et le bonus hotsim, ca lui fait 13 dés. Même avec un malus de 6 à sa pool, il peut encore tenter une action contre un noeud à 6 dés avec des chances raisonnables de réussir son action. C'est juste qu'il ne faudra pas qu'il tente cela trop de fois car il va finir par faire un jet pourri et se faire repérer par le système. | |
| 14-04-2010 12:33:35 | #25 | |
| okhin | (ouais, my bad, pour le seuil, je voulait dire pool) Alors, les nanites existent, amsi pas à la créa (ils donnent +indice (3 max) à toutes les jets de compétences liées à Logique ou à Intuition, selon le modèle). Et, je pense, que lire un ficheir pour lesquels on a pas les droits, que ce soit un fichier User, Admin ou Sécurité, c'est pareil, il te faut le trouver (déjà, tu ne voit que ce à quoi tu as accès à priori) avec DataSearch + Browse mettons, puis l'éditer avec Hacking + Soft (me rappelel plus de l'utilitaire, je crois que c'est Edit, masi c'est pas gagné). Limite, il faut même au préalable, récupérer les privilèges du compte ciblé, donc c'est un jet de Hacking + Falsification, puis Informatique + Edit (vu qu'on est devenu l'utilisateur normal). Donc, il faut faire une escalade de privilège. Pour gérer cette escalade, on peut effectivement rendre le jet plus dur pour viser un compte Admin ou Sécurité (il me semble que c'est le cas quand on essaye de Valider un compte par exemple), et ta règle me va bien dans ce sens là (quoique, j'aurai tendance à faire lancer plsu de dé au Node que moins au Hacker, ça réduit le risque de glitch du hacker). Juste, ça demande beaucoup de boulot au MJ avant. Il faut savoir ce qu'à le droit de faire l'utilisateur dont le compte s'est fait spoofer (par exemple, il n'a accès qu'aux fichiers de son service) et autre. J'aurai tendance à gérer ça en faisant des clusters/slaves de nodes. En gros, un node par groupe d'utilisateur (même si c'est des machines virtuelles) et donc, pour accéder à quelque chose hors du grouep de l'utilisateur, il faut accéder un autre node (Hacking + Exploit donc, si il y a une alerte sur le dos du hacker, tu la retrouves ailleurs) Okhin | |
| 29-04-2010 10:46:34 | #26 | |
| Fantome | Rappelons juste que sans déclencher d'alerte automatique quand quelqu'un se loggue en mode admin, il est tout à fait possible (et prévu dans les règles de bases) que le node soit programmé pour envoyer une IC scanné automatiquement quiconque se loggue en admin (voir même pour les nodes sécurisés, pour quiconque se loggue en sécurité). Le hacker,même passé à l'insu du Firewall devra encore se faire renifler par une IC, un jet de plus qu'il peut foirer. | |
| 29-04-2010 10:59:49 | #27 | |
| okhin | Bah, pour ça que les comptes admin c'est pour les faibles  Okhin | |
| 03-05-2010 08:37:25 | #28 | |
| Slevin | J'avais fait aussi pas mal de recherche dans les livres Unwired et SR4A et comme Carmody, la seule référence à ce que vous venez de tous expliquer est bien celle qu'il a cité plus haut. Après plusieurs heures de réflexion, aussi après lecture de ce long post, une idée m'est venue. Sans vouloir donc tout foutre en l'air votre brillante analyse du sujet, je me demandais si justement, juste avec cette phrase d'Unwired, on ne pouvait pas tout gérer dans ce "vide de règles" ou plutôt d'explication. Alors justement je m'explique : Ils disent dans cette phrase que en gros pour régler un problème quand on n'a pas les droits, il faut passer par le Hacking et la Falsification. Cela pourrait être compris comme : si tu n'as pas les droits de faire ce que tu veux (soit que tu n'as pas le bon compte dès le début, ou que tu as déclenché une alerte), et bien, premièrement toutes les actions que tu devrais faire avec la compétence Informatique se transforme en Hacking, et si tu veux faire une opération nécessitant des droits que tu n'as pas alors il faudra que tu édites le Journal d'Accès, pour trouver des ID de personne qui eux aurait les droits et que tu imites alors l'ordre dont eux pourrait avoir le droit. Ce que je trouve doublement intéressant dans cette approche c'est déjà qu'il ne rajoute pas de nouvelles règles (je suis assez frileux aux règles alter) et que finalement tout est alors géré avec des règles simples. De plus le niveau de difficulté de falsification d'ordre sécurité et admin sont déjà gérer dans les règles de base. Seul "problème", comme un utilisateur n'a pas de base les droits pour lire le journal d'accès, il lui faudrait trouver une icône présente dans le système qui lui aurait les droits et dont il pourrait utiliser l'ID pour falsifier les ordres. Ca pourrait être gérer par un jet de chance+catalogue par exemple... ou informatique+chance .... Qu'en pensez vous. | |
| 03-05-2010 08:47:34 | #29 | |
| Slevin | Aussi Valérian, si je comprends bien ton idée, il faut alors faire 2 jets pour faire une opération illégitime : une pour passée outre le problème de légalité, l'autre pour vraiment faire l'action. C'est ça? Si oui c'est pas un peu lourd en pratique? On pourrait aussi imaginé qu'une action illégitime peut toujours se faire avec hacking (donc tu fais juste ton action classique avec Hacking) mais le système fait un test de Système+Firewall en opposition. Si le système fait plus de succès alors Alerte active, et paf bim pouf.... S'il fait moi, seul les succès excédentaires conteront symbolisant le fait que le hackeur ait dû contourner le système pour y arriver. Sinon aussi pour une défense des comptes administrateurs, on pourrait imaginer un truc genre un bombe matricielle (pavlov) qui sauterait à la gueule de chaque administrateur, quel qu'il soit, si précédemment un petit bouton physique n'avait pas été enclenché laissant alors 1 tour à la personne pour se logger (ceux qui ont la SFRbox connaissent mes inspirations... ) | |
| 03-05-2010 09:02:24 | #30 | |
| Valérian | Heu... non, je ne fais faire qu'un seul jet mais il est plus dur (tu as un malus). Sinon l'action de falsification d'ordre ne marche que pour les équipements à commander à distance et les agents/drones, pas pour un noeud quand tu es dedans. il n'y a pas de gestion du hardware dans la logique de compte car tu dois pouvoir faire de l'administration à distance sur certains noeuds. D'ailleurs, il n'y a pas non plus de distinction entre une persona gérée par ton commlink (qui est vraisemblablement le propriétaire) et un autre compte admin que pourrait s'être créé un hackeur sur ton commlink alors que le système devrait être capable de faire la différence. | |
| 03-05-2010 09:59:13 | #31 | |
| Slevin | Zut, effectivement la falsification ne marche pas pour les nœuds, ah la la , faut pas être nœud nœud pour savoir ça bon sang. Pour ma bombe matricielle, rien n'exclus le fait qu'un hadware pourrait désactivé une bombe matricielle... alors je vois pas pourquoi .... pourquoi quoi! Et pour de l'administration à distance, premièrement c'est pas une obligation et deuxièmement un directeur peut-être bien devoir donner son autorisation (en pressant le bouton)... après libre cours à vos imaginations. Après pour revenir au sujet principal, j'aime bien l'idée du teste opposé, par contre des malus/bonus, j'ai un peu peur que ça devienne impossible de faire hackeur, si tu n'es pas un super crack optimisé. Et ce point me semble très important. Le problème c'est toujours l'équilibre des forces! (<= tiens je vais mettre ça en signature!!! )D'ailleurs dans ton deuxième exemple, je comprends pas pourquoi un hackeur en compte utilisateur ne peux pas faire certaines des actions que le premier pouvais faire, et cela via le hacking. Le principe c'est bien que tout le monde peut tout faire, mais avec des difficultés différentes non? Je pense au final que réellement les bonus/malus risquent réellement de beaucoup déséquilibrer le jeu. Alors achtung bitte! | |
| 03-05-2010 10:47:32 | #32 | |
| Valérian | Valérian a écrit: Comme c'est ce que je cherche à faire depuis le début : lorsqu'un hackeur disposant du privilège adéquat tente d'utiliser une fonction du système, il a toujours une chance que cela ne marche pas et que le système déclenche une alerte active à son encontre. Niveau règles, le hackeur fait un test opposé de Hacking+Soft utilitaire contre Système+Firewall du noeud. Si le hackeur obtient plus de succès, sa commande est prise en compte par le noeud. Si c'est le noeud qui l'emporte, la commande est rejetée et le noeud déclenche une alerte active contre l'utilisateur. Si le hackeur ne dispose pas du privilège adéquat, il peut toujours tenter de forcer la main au système, mais cela devient nettement plus corsé vu qu'il doit contourner les contrôles de privilège du système. Niveau règles, le hackeur fait un test opposé de Hacking+Soft utilitaire avec un malus de -3 s'il veut forcer une commande "sécurité" ou bien un malus de -6 s'il veut forcer une commande "admin". Le noeud fait quant à lui toujours un jet de Système+Firewall. Même interprétation des résultats que dans le cas précédent. C'est de ca dont tu parles ? C'est le même hackeur avec un compte utilisateur... la différence c'est qu'il essai de faire un truc correspondant à des droits de simple utilisateur dans le premier cas, ou bien des actions nécessitant normalement un compte sécurité ou admin dans le deuxième cas (mais dans ce cas, il a un malus parce que le système ne te laisse pas bidouiller son paramétrage aussi facilement que cela). Si tu ne veux pas te taper un malus de -3 ou -6, tu peux toujours essayer de rentrer dans le système avec un compte sécurité ou admin, mais dans ce cas, les CI sont plus vigilantes à ton égard (elles ont un bonus de +3 ou +6 pour t'analyser). C'est donc un choix de méthode à faire par le hackeur. Alors certes, tu peux finir par te tapper des malus dissuasifs (-6 à ton jet de Hacking+programme contre Système+Firewall+4), mais tu es dans le cas le plus défavorable. Dans la vraie vie, ce serait comme essayé de trouver la combinaison du coffre de la banque alors que l'escouade d'intervention de la police est en train de donner l'assaut. | |
| 03-05-2010 11:09:32 | #33 | |
| okhin | De mon point de vue, je n'aime pas donner des malus aux PJ, je préfère donner des bonus à l'opposition. Ça évites qu'un hacker compétent ne lances que 2 dés et finisse par glitcher, et statistiquement, ça revient exactement au même. Aussi, un peu comme pour les règles de SR4A, je n'applique à un personnage que les bonus/malus qui le concerne, je donne à l'adversaire que les bonus/malus qui lui servent (donc, Adversaire en mouvement qui donne -2 au tir, donne en fait +2 à l'esquive, ça revient au même, mais ça permet de toujours tenter une action avec quelques dés, et ça dissuade les joueurs de vouloir avoir 30 dés pour compenser les malus). Donc, dans cette optique, je donnerait un bonus aux IC, mais +6 et +3 ça fait beaucoup quand même. De mémoire, pour déconnecter un utilisateur, le hacker bénéficie de +2 et +4 dé à sa pool de dé si il a un compte sécu ou admin. Utiliser le même principe pour toutes les actions défensives (et qui ne soient pas de cybercombat) paraît une chose intéressante. Bien que je ne soit toujorus pas persuadé que cela soit pertinent. Quand au hardware, le hardware n'existe pas, les nodes sont aggrégés, les machines sont virtualisée, tout est répliqués pour faire de la balance de charge et avoir un PRA pas dégueulasse, donc la connexion hardware existe mais est extrêment rare (voir inutile). La seule possibilité de jouer avec le hardware est d'utiliser les clefs physiques des utilisateurs. Pour le reste, à priori, tu te contrefous du hardware, il n'a aucun impact sur le software (à Part Signal et Réponse). Okhin | |
| 03-05-2010 14:08:42 | #34 | |
| Slevin | Vous pensez pas quand même que le test opposé est plus "correct" que cette avalanche de règle : Si tu n'as pas le droit de faire une opération alors Tu fais ton test avec Hacking en opposition avec le firewall+système. Si tu l'emporte alors c'est ok (seuls les succès net ne compte) sinon c'est une alerte qui démarre. Après un +2 pour des opérations systèmes et +4 pour des opérations admin peut être une bonne idée. Mais faut voir. J'ai peur qu'un test étendu limite trop le hackeur (qui, il n'y a pas de raison) peut très bien rester furtif dans le noeud. Tout les système tours, le système fait un test d'analyse contre (jet opposé) au hacking+furtivité du hackeur, plus éventuellement d'autre test d'analyse hasardeuse des CI/spiders en place. Je pense que c'est complet, juste avec ça non? (désolé si je redis trop de choses déjà dites auparavant, mais la répétition est éducative non?) | |
| 03-05-2010 16:28:39 | #35 | |
| Valérian | Slevin a écrit: Vous pensez pas quand même que le test opposé est plus "correct" que cette avalanche de règle : Tu parles de quoi exactement ? Car personnellement, j'ai toujours préconisé un test opposé de Hacking+Programme contre Système+Firewall avec des modificateurs circonstancié. | |
| 03-05-2010 16:47:37 | #36 | |
| okhin | En fait, moi j'aime pas le test opposé de Hacking + Utilitaire. Après tout, le hacker fait son opération, qu'elle rate ou qu'elle réussisse, il va remplir l'AccessLog (d'où le jet étendu de Firewall), il ne mettra pas plus de temps. Ah, et, de mon point de vue, le seul moyen de savoir qu'on a une alerte restreinte sur le dos, c'est par un jet d'Informatique + Analyse 1 ou 2 succès doivent être nécessaire, mais on peut-être fourbe et ajouter Stealth du node au seuil à atteindre pour détecter l'alarme). Et donc, on en arrive à un truc assez logique en réaction: - Le node coupe la connexion illégitime (compte validé = hacker out, compte piraté = hacker out plus tard) - Si la connexion est toujours là la PI d'après, on lance une Trace - Le hacker periste et fait des jets de Hacking, le serveur le re-crame (Firewall + 4 + Analyse), il pass en laerte générale, délogue les utilisateurs légaux, alerte les spiders, fait débarquer les IC - Le node est à l'agonie, les spiders déclenchent le reboot. A noter que, plutôt que de faire un test étendu de Firewall + ANalsye contre Stealth du hacker, on peut faire un système plus proche du système de furtivité physique. Un jet de Système + Stealth, ou Hacking + Stealth (peut-être plsu interessant, masi la première option réflete le nombre de hits) au moment d'attaquer le node (au premier jet utilisant Hacking mettons), le nombre de hit représentant le seuil à atteindre pour le node pour déclencher une alerte restreinte. Okhin | |
| 03-05-2010 18:37:05 | #37 | |
| Valérian | Ben le test opposé de Hacking+utilitaire contre Système+Firewall sert justement à savoir s'il réussit ou rate son action. Reste à voir s'il déclenche une alerte ou pas (et si oui de quel type). De manière basique : réussite de l'action = pas de problème et action ratée = alerte active, mais il est possible de laisser plus de marge d'erreur au hackeur suivant les différents cas de figure en jouant par exemple sur le type d'alerte déclenchée. | |
| 03-05-2010 18:42:49 | #38 | |
| okhin | Ouaip, moi je préfère laisser la possibilité de se planter sans lancer d'alerte, d'où action complexe. Et jet étendu pour le Firewall. Ça mettra moins d'alerte (mais peut-être plus souvent en fait), tout en laissant le hacker dans l'incertitude de l'état du nœud (et donc, le forcer à cramer des actions sur Informatique + Analyse). Okhin - fourbe pour le coup | |
| 26-05-2010 00:36:22 | #39 | |
| Valérian | Les règles ci-dessous visent à donner une méthode de gestion du hacking une fois dans un noeud, à la fois d'un point de vue règle mais aussi de manière concrète et visuelle afin qu'un MJ puisse facilement mettre en scène une passe matricielle. [OFF : les paragraphes en off servent à expliquer un peu la manière dont j'ai conçu mes règles.] Intrusion dans le noeud : Pour s'introduire dans un noeud, un hackeur va utiliser son programme Exploitation pour trouver un faille dans le système pour pouvoir se créer un compte utilisateur fictif sur le noeud. Ce compte est associé à un niveau de privilège (utilisateur, sécurité ou admin) choisi par le hackeur au cours de son intrusion mais il ne dispose d'aucun droit sur le noeud car il n'apparait pas dans la « table des droits utilisateurs » gérée par l'administrateur. [OFF : je n'aime pas la règle canon qui fait qu'un compte créé par hacking peut faire la même chose qu'un compte légitime sans faire de jet.] Contrôle de droits : Comme un hackeur dispose d'un compte sans aucun droit, il va devoir faire appel à ses compétences de hacking dès qu'il veut entreprendre quelque chose dans le noeud, afin de forcer la main au système. Niveau règles, pour forcer une action sans droits adéquats, le hackeur réalise un test opposé de Hacking+Programme contre Système+Firewall. Le programme a utilisé dépend de l'action à forcer. Si le hackeur obtient plus de succès, l'action est acceptée par le système, mais si c'est le noeud qui obtient le plus de succès ou même une égalité, l'action est refusée et le système déclenche une « alerte générale ». [OFF : l'alerte générale est là pour laisser l'admin/spider enquêter pour déterminer ce qui ne va pas, ce qui laisse une chance au hackeur car moins violent qu'une alerte active directe contre lui.] Contrôle de privilège : La même méthode peut être employée par un hackeur pour forcer une action pour laquelle il ne dispose pas d'un niveau de privilège suffisant, mais cela s'avère bien plus dur car le Firewall réalise des contrôles renforcés pour les actions nécessitant un compte sécurité ou un compte admin. Niveau règles, pour forcer une action sans privilège suffisant, le hackeur réalise un test opposé de Hacking+Programme+Modificateur contre Système+Firewall. Le modificateur est de -3 pour une action nécessitant un compte sécurité et de -6 s'il faut un niveau administrateur. Si le hackeur obtient plus de succès, l'action est acceptée par le système, mais si c'est le noeud qui obtient le plus de succès ou même une égalité, l'action est refusée et le système déclenche une « alerte active » contre le hackeur. [OFF : c'est une règle adaptée de celle de la falsification avancée en terme de malus, lesquels sont là pour rendre le hacking sans privilège adéquat relativement difficile (mais possible tout de même). A noter que le hacking d'une action d'administration avec un compte admin tombe sous le coup de la règle du paragraphe « contrôle de droits », et n'impose pas de malus. D'un autre coté, le fait d'avoir un privilège admin n'est pas aussi ultime que dans les règles canons où cela permet de faire ce que l'on veut sur le noeud sans avoir à faire de jet.] Le contrôle des droits et des privilèges forme un premier niveau de sécurité contre les hackeurs, mais n'est pas suffisant si on veut sécuriser convenablement un noeud. On doit dans ce cas faire appel à des CI et/ou des spiders qui peuvent fournir une sécurité plus active au noeud. [OFF : Jusque là, ce n'est pas très sexy pour mettre en scène les passes matricielles, mais il faut bien un mécanisme pour gérer à minima les chances du hackeur de réussir ce qu'il tente. La mise en scène devient toutefois plus facile à gérer par le biais de l'opposition Furtivité/CI.] Les CI sont l'équivalent matriciel des gardes de sécurité du monde physique. Elles montent la garde auprès des données sensibles, assurent des patrouilles ou recherchent les traces révélant une tentative de hacking. Les CI gardiennes : Ces CI sont chargées de monter la garde auprès d'un unique fichier/paneau d'administration du noeud (par exemple le journal d'accès ou un fichier de données ultra-confidentielles). Le fait de dédier une CI à une surveillance unique lui procure un bonus de vigilance de +6 dés à ses tests de perception matricielle pour percer à jour un éventuel hackeur cherchant à accéder au fichier ou au panneau surveillé par la CI gardienne. Ainsi, la CI gardienne repère un hackeur si elle obtient plus de succès sur un test de Pilote+Analyse+6 contre Hacking+Furtivité de la cible. Aucun noeud n'a les moyens de mettre une CI gardienne devant chaque fichier, aussi les CI gardiennes ne sont généralement utilisées que pour la protection des panneaux d'administration critiques pour la sécurité du noeud (notamment le panneau de gestion des droits utilisateurs). Toutefois il peut arriver qu'un spider installe une CI gardienne à coté d'une fichier sensible (en masquant la CI avec un programme Furtivité) s'il sait qu'une équipe de runners cherche à se procurer les informations contenues dans ce fichier. Niveau programmes, une CI gardienne a besoin naturellement d'Analyse. Après cela, on peut chercher à la dissimuler avec Furtivité ou blinder sa défense pour éviter qu'elle ne soit détruite trop facilement par un hackeur et ce, avec l'autosoft Expertise défensive et/ou un programme Armure. Si on veut pousser au maximum la capacité de détection de la CI, on peut lui donner aussi l'autosoft Territoire. Les CI sentinelles : Il s'agit d'une CI un peu plus polyvalente qu'une CI gardienne, mais dont la vigilance chute en conséquence. Une CI sentinelle peut surveiller un nombre de fichiers et/ou de panneaux égale à son Indice. En contrepartie, elle reçoit un bonus de vigilance de seulement +3 dés à ses tests de perception matricielle pour percer à jour un éventuel hackeur cherchant à accéder à l'un des fichiers/panneaux surveillés par la CI sentinelle. Niveau programmes, une CI sentinelle a les mêmes besoins qu'une CI gardienne. Les CI de patrouille : Ces CI ne sont affectées à aucun fichier ou panneaux et elles se promènent dans le noeud pour scanner les utilisateurs qu'elles rencontrent. Une CI de patrouille ne reçoit aucun bonus de vigilance pour ses tests de perception matricielle visant à repérer et scanner un hackeur. La fréquence à laquelle les CI de patrouille viennent scanner un utilisateur est laissée à l'appréciation du MJ en fonction du nombre de CI et du nombre d'utilisateurs connectés. Le MJ est aussi libre de donner un bonus de vigilance à une CI de patrouille pour repérer un hackeur perdant du temps face au cryptage d'un fichier pour simuler le fait qu'il est pris en flagrant délit. Niveau programmes, une CI de patrouille peut avoir les mêmes programmes qu'une CI gardienne, mais elle peut aussi disposer de programmes de cybercombat (généralement simplement chargés dans la CI mais pas lancés en permanence) pour repousser un éventuel intrus. Il existe encore un autre type de CI dédié à la sécurisation d'un noeud, les CI analystes que l'on fera plus loin. [OFF : Ces règles sont là pour donner un vrai rôle aux CI en leur donnant une chance de servir à quelque chose pour la sécurité matricielle en dehors du cybercombat. Elles servent aussi la facilité la description de la métaphore en permettant une analogie avec les gardes de sécurité du monde physique.] Sont présentés ci-dessous les différents panneaux d'administration avec leur contenu, leur importance pour le noeud et les mesures de sécurité associées. [OFF : Cette partie contient des infos sur les éléments clés pour le noeud, ce qui en fait des cibles de choix pour un hackeur.] Panneau du journal d'accès : Le journal d'accès présente un historique complet de toutes les actions se déroulant dans le noeud. Cet historique est automatiquement renseigné par le système, lequel ne se contente pas d'enregistrer des données brutes mais va les indexer et les mettre en forme pour les présenter sous une forme facilement lisible et exploitable. Ce processus prend un peu de temps, ce qui fait qu'une action donnée ne va apparaître dans le journal d'accès qu'un certain nombre de tours après qu'elle ait eu lieu. Le délai de publication d'une action dans le journal d'accès est de : 2 tours pour un noeud périphérique. 4 tours pour un commlink ou un drone. 6 tours pour un noeud matriciel à fort trafic. Le journal des accès est régulièrement archivé par l'administrateur et les fichiers d'archives ainsi générés sont généralement cryptés par l'administrateur. De même, en cas de reboot, le journal d'accès va être archivé automatiquement par le noeud et un nouvel journal vierge va être créé lors du redémarrage du noeud. A chaque action se déroulant dans le noeud sont associés un certain nombre d'informations, dont notamment l'heure de l'action, le compte utilisateur impliqué, l'accessID associé, le chemin d'accès complet de cet accessID et le programme utilisé. Ces données sont précieuses pour la sécurité matricielle du noeud car elles permettent d'identifier un hackeur (car il utilise un compte utilisateur non officiel), ce qu'il a fait ou tenter de faire dans le noeud et enfin sa localisation physique au moment de son action (le chemin d'accès fournissant des informations proche de ce que l'on obtient par un pistage matriciel). On touche ici au domaine des CI analystes (voir plus bas). Niveau sécurité, le journal d'accès n'est généralement éditable que par l'administrateur. Les CI et les spiders n'ont qu'un accès en lecture seule et les utilisateurs simples n'ont pas d'accès du tout. Le journal étant en perpétuel modification, il peut être crypté par le noeud mais ne peut pas intégrer de bombe matricielle. Les CI analystes : Ces CI n'ont pas pour mission de surveiller les utilisateurs, à l'instar des CI gardiennes, sentinelles et de patrouille, mais vont à place analyser le contenu du journal d'accès à la recherche d'éléments pouvant mettre en évidence une tentative de hacking. Lorsqu'un action de hacking (ce qui inclut la connexion du hackeur au noeud) a lieu, une CI analyste doit attendre le délai de publication dans le journal d'accès avant de pouvoir faire son travail d'analyse. De plus, la précision des données lors d'une action de hacking est perturbée par l'utilisation d'un programme Furtivité. En conséquence, une CI analyste détecte que l'action est illicite si elle obtient un succès ou plus sur un test de Pilote+Catalogue-Furtivité du hackeur. Lorsqu'une CI analyste détecte une action illicite, elle déclenche une alerte active contre l'auteur de l'action. [OFF : Cette CI sert à mettre la pression sur un hackeur pour qu'il réalise sa passe matricielle en moins de temps que le délai de publication du journal d'accès.] Panneau des droits utilisateurs : Ce panneau d'administration est primordial pour un noeud car c'est lui qui définit qui a le droit de faire quoi dans le noeud. Le laisser facilement accessible à un hackeur c'est prendre le risque de perdre le contrôle du noeud à son profit. Ce panneau contient toutes les informations associées à un compte utilisateur : son niveau de privilège, ses droits hérités de son privilège, ses éventuels droits spécifiques. Niveau sécurité, le panneau des droits utilisateurs n'est généralement éditable que par l'administrateur. Les CI et les spiders n'ont qu'un accès en lecture seule et les utilisateurs simples n'ont pas d'accès du tout. Les modifications du contenu du panneau n'étant pas forcément très fréquente, ce fichier est généralement crypté et peut inclure une bombe matricielle. Il et fréquent aussi que sont accès soit contrôlé par une CI gardienne. Panneau de connexion : Ce panneau d'administration sert à l'administrateur et aux spiders pour gérer la liste des utilisateurs présents dans le noeud. Cette liste est maintenue à jour par le système au fur et à mesure des connexions et déconnexions des utilisateurs (c'est instantané, contrairement au contenu du journal d'accès). C'est par le biais de ce panneau que l'administrateur et les spiders accèdent à la fonctionnalité de déconnexion forcée, ainsi qu'à la gestion des alertes. Niveau sécurité, le panneau de connexion est généralement accessibles à l'administrateur ainsi qu'aux CI et aux spiders. Le contenu de la liste des comptes connectés étant en perpétuelle modification, ce panneau peut être crypté par le noeud mais ne peut pas intégrer de bombe matricielle. Panneau de sculpture : Ce panneau d'administration permet à l'administrateur de définir quelle sera le thème de la métaphore du noeud. Il est possible aussi de définir plusieurs thèmes mais un seul peut tourner à la fois (l'admin peut changer de thème avec une action simple). Niveau sécurité, le panneau de sculpture n'est généralement éditable que par l'administrateur. A noter qu'un admin un peu vice-lard peut sculpter une métaphore secondaire prévue pour perturber les éventuels intrus, tandis que lui est habitué à évoluer dedans. En cas de tentative de hacking, l'admin peut basculer sur sa métaphore perturbante pour pénaliser le hackeur au niveau de l'initiative. Dans la pratique, l'admin sculpte sa métaphore perturbante par un jet de Logique+Informatique (seuil 1). Chaque succès excédentaire procurera un malus d'initiative de -1 aux utilisateurs qui découvriront cette métaphore pour la première fois tant elle est perturbante et peu intuitive (les agents, les sprites et les IA ne sont pas affectés par cette réduction d'initiative car ils ne sont pas sensibles aux métaphores). C'est là où un filtre de réalité peut s'avérer utile pour le hackeur. Le programme va tenter d'établir un tableau de conversion pour pouvoir afficher les données du noeud dans une métaphore que connait l'utilisateur exécutant le programme. Lors de son lancement, le programme effectue un test de Réponse+Filtre de réalité. Chaque succès réduit de un point le malus imposé par la métaphore du noeud. Il n'est cependant pas possible d'obtenir un bonus par ce biais si on obtient plus de succès que le malus de la métaphore. A noter que l'admin peut fournir un filtre de réalité pré-configuré à ses utilisateurs de confiance pour qu'ils puissent venir dans le noeud sans subir le désagrément de sa métaphore perturbante. Considérez qu'il s'agit d'un programme "Filtre de réalité" avec l'option "limitation". Ce programme n'a d'effet que dans le noeud en question mais il annule automatiquement l'intégralité du malus d'initiative sans avoir à faire de jet. Panneau de commande (drone et périphérique uniquement) : C'est par le biais de ce panneau d'administration que l'on peut fixer quelles sont les instructions que doit automatiquement ignorer un drone ou un périphérique et quelles sont les instructions possibles et le niveau de privilège requis pour les déclencher (voir les règles de falsification). Niveau sécurité, le panneau de commande n'est généralement éditable que par l'administrateur. Droits associés aux fichiers de données : Lorsqu'un utilisateur crée un fichier dans un noeud, il a toute latitude pour attribuer des droits particuliers à d'autres utilisateurs concernant ce fichier. Les droits les plus classiques concernant un fichier sont les droits de lecture et d'écriture, mais bien d'autres droits peuvent être définis par l'auteur du fichier : Le droit d'administrer les droits sur le fichier ; Le droit de lecture du contenu ; Le droit d'édition du contenu ; Le droit de valider les modifications apportées au contenu (si l'auteur veut faire encadrer le droit d'édition de certains utilisateurs par d'autres, à la façon de Wikipédia par exemple) ; Le droit de suppression du fichier ; Le droit de dupliquer le fichier ; Le droit de crypter le fichier ; Le droit d'accéder à un résumé du fichier (un utilisateur disposant de ce droit mais pas de celui de lire le contenu saura de quoi parle le fichier mais ne pourra pas le lire dans le détail. Sans ces deux droits, on sait juste que le fichier existe mais sans rien savoir de son contenu) ; Le droit de lire les méta-données associées au fichier (lequel va généralement de paire avec le droit de lire le contenu du fichier) ; Le droit d'éditer les méta-données (voir ci-dessous le principe des méta-données). Tous ces droits permettent à un utilisateur de constituer des fichiers allant de fichiers personnels privés à des fichiers publiques collaboratifs, ainsi que toutes les variantes intermédiaire. A noter qu'un utilisateur peut créer des archives sur le même principe, une archive étant ni plus ni moins qu'un fichier contenant d'autres fichiers, la différence se faisant surtout sentir au niveau de la métaphore, car une archive sera représentée généralement par un contenant, une pièce, un bâtiment... Pour copier ou falsifier un fichier pour lequel il n'a pas les droits, un hackeur doit utiliser sa compétence Hacking pour passer outre le contrôle de droit (voir plus haut). Fichiers et méta-données : Bien souvent il n'y a pas que le contenu d'un fichier qui soit intéressant, mais aussi les méta-données qui y sont associées. Ces dernières peuvent prendre des formes très variées suivant les fichiers auxquels elles se rattachent. Voici quelques exemples de ce qu'elles peuvent contenir : Un historique des modifications apportées au fichier permettant de retracer tous les stades par lesquels il est passé au cours de sa vie ; Un historique des accès au fichier ; Une table d'indexation pour faciliter la recherche du fichier ; Une référence à la localisation matricielle de l'original du fichier si on consulte une copie ; Une liste des copies du fichier et de ses détenteurs ; Une table des références/sources d'où proviennent les informations du contenu du fichier ; Du contenu additionnel que peuvent afficher les utilisateurs s'ils veulent approfondir un point du contenu du fichier ; Des scripts de mise à jour des informations du fichier en allant consulter des sources dans la matrice ; Etc. A noter que le programme Corruption évalue automatiquement si les méta-données d'un fichier que le hacker s'apprête à copier ou falsifier doivent être elles-aussi falsifiées. Dans tous les cas le hackeur ne fait qu'un seul jet de Hacking+Corruption. [OFF : Ces informations sur les fichiers servent à donner un aperçu de ce que l'on peut faire concernant les données.] Alertes de sécurité : Il existe deux types d'alerte, l'alerte générale et l'alerte active. Une alerte générale est générée lorsque le noeud ou l'un de ses éléments de sécurité (CI, spiders, admin...) repère une action illicite sans pouvoir l'attribuer à un utilisateur fautif. Ce type d'alerte est synonyme d'investigation de la part d'un administrateur et/ou un spider afin de déterminer qui est à l'origine du problème ce qui permettra alors de basculer vers une alerte active. Cette dernière est déclenchée lorsque l'auteur d'une infraction a été clairement identifié. L'alerte active engendre des pénalités à l'encontre de l'intrus identifié. A noter que les alertes générales ou actives peut être silencieuses ou sonores. Dans le premier cas, rien n'indique au niveau de la métaphore qu'une alerte a été déclenchée, tandis que dans le deuxième cas, l'alerte est évidente pour tous les utilisateurs présents dans le noeud, et s'il s'agit d'une alerte active, le fautif est clairement indiqué. Le choix entre des alertes silencieuses ou sonores dépend de la philosophie de sécurité mise en œuvre pour le noeud. Si le but est d'effrayer un éventuel hacker et le contrainte à fuir, il faut plutôt s'orienter sur une alerte sonore. A l'inverse, si les spiders préfèrent avoir le temps d'identifier l'origine du hacker et ce qu'il vient faire dans le noeud, une alerte silencieuse peut être utile dans ce cas. [OFF : C'est plus ou moins une redite des règles canons. Seule la notion d'alerte silencieuse est ajoutée, mais il s'agit plus d'un élément d'ambiance que d'un élément de règle.] Déroulement type d'une alerte générale : En cas d'alerte générale, le système va prévenir un certain nombre de personnes définies par avance (généralement l'administrateur et un certain nombre de spiders) pour qu'ils viennent mener l'enquête sur le problème à l'origine de l'alerte. Ensuite, le système va ouvrir automatiquement un abonnement pour une des personnes prévenues. Situations entrainant une alerte générale : Obtenir un glitch en s'introduisant dans un noeud. De manière générale, obtenir un glitch sur un jet impliquant la compétence Hacking. Échouer à une tentative pour forcer les droits. Planter un programme que fait tourner le noeud, une CI, un spider ou un admin. Attaquer un utilisateur ou une CI en cybercombat. Déroulement type d'une alerte active : En cas d'alerte active, le système va prévenir aussi un certain nombre de personnes clés. Le système retire ensuite à l'utilisateur concerné par l'alerte active son niveau de privilège et ses droits. A noter que le Firewall du noeud reçoit un bonus de +4 dés à ses tests pour lutter contre le hackeur ou pour s'opposer à ses actions. Enfin, le système exécute son protocole de réponse à une alerte sécurité (qui peut être de logger un utilisateur donné, ou lancer une CI, ou tenter de déconnecter l'utilisateur concerné ou même peut lancer le reboot du noeud). Situations entrainant une alerte active : Se faire repérer par le Firewall en s'introduisant dans un noeud. Échouer à une tentative pour forcer les privilèges. Se faire repérer par une CI gardienne, sentinelle ou de patrouille. Se faire détecter par une CI analyse. Sécurité matricielle et métaphore : La sécurité d'un noeud peut relativement facilement être décrite dans le cadre d'une métaphore. Ainsi les archives de fichiers sont représentées par des bâtiments et/ou des pièces contenant des objets (les fichiers de données). Le cryptage d'une archive ou d'un fichier sera perçu comme un verrou ou un digicode et les bombes matricielles comme des pièges. Dans la métaphore, les CI gardiennes montent réellement la garde à coté du fichier ou du panneau qu'elles doivent protéger. Les CI sentinelles surveillent les différents éléments qu'elles doivent protéger depuis une position en hauteur par exemple. Les CI de patrouille font des rondes dans le noeud et contrôles les utilisateurs qu'elles croisent. Bien sur, ces descriptions doivent être adaptées au thème retenu pour la métaphore, mais le MJ devrait être capable de décrire ce que voit le hackeur dans le noeud ainsi que le résultat de ses actions. | |
| 26-05-2010 10:32:23 | #40 | |
| okhin | Juste une remarque. Dans le canon, un hacker qui ouvre un node avec Hacking a _forcément_ un compte utilisateur (soit il ouvre une faille dans un compte existant et en récupère les privilèges, soit il clone un utilisateur). Rien ne s'exécute sur un node qui ne soit pas associé à un compte quelconque. Après, il peut y avoir des opératiosn interdites (typiquement création de compte de sécu ou d'admin, suppressiond e ces comptes, pas de comptes utilisateurs). Bref, lorsque tu arrives sur un node de manière légale ou pas, tu as FORCEMENT un compte utilisateur existant (c'est d'ailleurs la seule façon de procéder pour créer un autre compte et/ou faire l'escalade de privilège). SInon, c'ets la porte ouveret à toute les fenêtre et aux programmes/fichiers qui n'appartiennent à personne (et ne peuvent soit pas s'exécuter du tout, donc pas se logguer, soit on tous les droits, et tu ne veux pas ça). Après, je comprends que cela puisse géner qu'un hacker qui ait réussi à rentrer dans un node avec Exploit 6 et Stealth 6 ne puisse rien faire. Mais, en mêm etmps, c'ets un peu comme si une policière municipale non entraînée essayait de stopper avec son Sig Sauer un commando armé d'armes de guerre hein. Ça pique les yeux et ça finit mal pour les forces de l'ordre. Je continue de lire cela dit. Okhin | |
| 26-05-2010 11:00:56 | #41 | |
| okhin | Bon, alors, globalement, il y a une granularité trop forte. L'avantage des règles canon c'est qu'elle permette un fort niveau d'abstraction sans forcément être en lien avec la structure physique et logicielle. Un node peut être un système extrêmement complexe de plusieurs machines assemblée en cluster sur des sites distants permettant de réaliser une haute-disponibilité et de la qualité de service, sans que le meneur de jeu n'ait besoin de détailler l'ensemble des nodes du système (et je peux te dire que détailler la conquantaine de node nécessaire à faire un site web client à peu près correct est une bénédiction). Alors, après, effectivement, un hacker qui arrive avec une arme nucléaire pour braquer une banque, à priori, on va lui laisser les clefs du coffre. En revanche, voici quelques règles alter qui me paraissent AMHA, intéressante: De la Furtivité Lorsqu'un hacker se connecte à un node (donc quand il _commence_ sa tentative de hack à la volée, ou qu'il utilise la backdoor trouvée si il prépare son hack), il lance Hacking + Furtivité et il note le nombre de hits obtenus. Quand il se logue sur le noeud (et à chaque fois qu'il utilisera la compétence Hacking), le node effectue un jet de Système + Analyse (+3 si il a hacké un compte sécu, +6 si il a hacké un compte admin)(nombre de hits obtenus par le joueur sur Hacking + Furtivité). Les CI et spiders en patrouille (donc toute CI active et présente sur le node au moment où le hacker se connecte) lancent Pilot/Informatique + Analyse quand le hacker apparait dans le noeud. Il existe un Autosoft Analyst qui ajoute son indice à la pool de dés des CI pour réussir ce jet. de la surveillance des comptes Les comptes admin sont surveillés et toute action effectuée par l'un d'eux ets automatiquement loguée. A chaque action du hacker avec un compte admin (en utilisant Informatique), le node effectue un test de Système + Analyse (nombre de hits du hacker). A noter que certaines actions sont impossible à réaliser, même avec le compte admin. Typiquement, toute action agissant sur les privilèges d'un utilisateurs de même niveau est impossible à réaliser (on ne peut pas suppriemr de compte de sécu avec un compte sécu, ni déconnecter un autre admin sans l'engager en cybercombat). Pour réaliser ces actions, l'utilisation de Hacking est obligatoire. des Bombes matricielles et des nodes Si un utilisateur ne saisit aps de mot de passe lrosqu'il tente d'accéder à un nœud et que celui-ci est protégée par une bombe matricielle (et qu'il ne l'as pas vue avec un jet d'Informatique + Analyse avant de se loguer), celle-ci lui explose à la tête en essayant de le déconnecter (comme dans le canon donc, sauf que la bombe agît au lmogin et qu'il faut donc penser à la détecter avant de se loguer et donc de hackerle noeud). A propos de l'Access Log Il n'est accessible en lecture que par les utilisateur de niveau sécurité ou admin et ne sont pas accesible en écriture. Il contient l'ensemble des commandes qui ont été saisie par l'ensemble des utilisateur et est archivé sur une base régulière (pour ne pas saturer de log l'espace disque) souvent àd es fins d'Analyse. Ces logs sont conservés Système jours si aucune alerte n'a été déclenchée. Ces Access Logs ne peuvent être modifier qu'avec l'utilitaire Corrupt. Ils ne peuvent pas être supprimés (la suppressiond éclenche une alerte restreinte sur l'icône qui a effectué cette suppression, alerte immédiate) ou verrouillés (pareil). La modification nécessite un jet de Hacking + Corrupt contre un seuil de Système (+3 si le hackeur à un compte de sécu et +6 si il a un compte admin). En cas d'échec, une alerte restreinte est déclenchée contre l'icône qui a tenté la modification. L'Access Log contient l'Access ID utilisée par l'intrus, ainsi que tout ou partie de son SIN (selon le niveau du node). Cela eprmet, en utilisation normale, de pouvoir identifier les utilisateurs et de leur fournir des données personnalisées en fonction de leur historique. De fait, sur la plupartd es nodes, il est impératif de fournir un SIN à la connexion (en plus de smots de passe, clef et autre joyeuseté du genre). Okhin | |
| 26-05-2010 11:07:23 | #42 | |
| M. Jonson | je comprend pas tout. Si t'as un compte admin c'est plus difficille de bidouiller les access log ? Pourquoi ça ne pourrait pas s'éditer, à partir du moment ou tu peux hacker... ?? | |
| 26-05-2010 11:17:50 | #43 | |
| okhin | C'ets aps que c'ets plus difficile, c'ets que tu génères beaucoup plus de données. On te surveille bien plus si tu as un compte admin, essentiellement poru que tu puisse avori un historique des évolutions du noeud. Ensuite parceque, normalement, tu ne te connectes pas en admin. Jamais. Donc, du coup, si des actions admin ont été déclenchées, les historiser pour analyse c'est bien. Et donc, de fait, on apporte une plus grosse attention aix actiosn effectuées avec des privilèges particuliers qu'avec un user normal (qui lui ne peut asp faire grand chose normalement). Enfin, l'Access Log, comme tous les logs, est un fichier en lecture seule. Il sert pour savoir ce qu'il s'est passé de grave sur un node, tu n'as jamais besoin de l'éditer, seul el Système du node peut et doit le faire. Donc, pour l'éditer, il faut Hacker (mais il faut utiliser Corrupt qui est là pour ça). C'est un format binaire bizarre pas lisible par le cerveau humain (mais par des agents si). Okhin | |