| 26-03-2010 16:55:32 | #1 | | Valérian | Je me suis posé des questions sur la bonne manière d'utiliser un agent durant un hacking et comme il y a deux interprétation possibles des règles j'aimerais savoir ce vous en pensez.
On peut embarquer des agents dans une personna de manière à ce qu'ils puissent être utilisés sur les noeuds auxquels la personna va se connecter. Pour ce faire, ils n'ont pas besoin de se connecter eux-mêmes directement au noeud en question (ils viennent avec la personna).
Première question : Est-ce que les agents embarqués disposent de leur propre icône sur le noeud ?
Élément pour dire oui : en cas de cybercombat, ces agents peuvent agir et être ciblés en retour par une CI du noeud, donc cela suppose qu'ils aient leur propre icône.
Élément pour dire non : dans SR4A, dans la partie sur les agents autonomes, il est précisé qu'ils ont leur propre icône. Est-ce que cela ne veut pas dire qu'un agent embarqué n'en a pas du coup ?
Deuxième question : Est-ce qu'un agent embarqué doit être équipé d'un programme Furtivité lors d'un hacking ?
Élément pour dire oui : s'ils ont leur propre icône d'après la question un, ils devraient en avoir besoin logiquement pour se faire passer pour un élément anodin (ce que fait Furtivité). A noter que cela est pour moi une limitation à l'usage des agents lors d'un hacking car il est possible que l'agent ait un Pilot et donc un niveau de programme Furtivité plus faible que le niveau de Furtivité du hackeur. Donc ils sont plus faciles à repérer par les CI de patrouille.
Élément pour dire non : ils sont couvert par le programme furtivité du hackeur.
Troisième question : Est-ce qu'un agent embarqué peut subsister dans le noeud après que sa personna d'attache soit vaincue en cybercombat ?
Élément pour dire non : si la personna est vaincue, la connexion entre elle et le node est rompue, les agents embarqués ne peuvent donc pas subsister par eux-mêmes : pouf, ils disparaissent aussi (cela veut dire que les CI ont intérêt à cibler la personna plutôt que les agents en cas de cybercombat pour repousser l'intrusion).
Élément pour dire oui : est-ce que la connexion est bien coupée ou bien c'est juste que la personna ne peut plus agir dans le noeud après avoir été vaincue (mais la connexion reste active et donc traçable). autrement dit une icône vaincue en cybercombat laisse un "cadavre" analysable. Dans ce cas, la personna peut être à terre (par analogie avec un combat physique) mais ces agents embarqués sont toujours actifs jusqu'à ce qu'ils soient vaincus à leur tour.
Suivant la manière dont un voit les choses pour les questions ci-dessus, il ressort des stratégies, voir des impératifs particuliers pour le hacker, aussi je pense que ce serait bien d'en discuter. |
|
| 26-03-2010 16:58:09 | #2 | | Blade | Pour moi je dirais :
* Oui
* Oui
* Non
Mais j'ai rien pour appuyer mes choix. C'est juste mon interprétation. |
|
| 26-03-2010 17:09:26 | #3 | | okhin | Pareil que Blade.
Pour les icône, il me semble que chaque programme en possède une (vu qu'on peut cibler un soft en particulier), les agents étant un programmes, ils disposent d'une icône.
Il doit embarquer dans son payload tous les fost qu'il utilise. Donc, il utilise son propre programme de fufu. Cela dit, vu qu'il est avec le persona, tant que celui-ci n'est pas grillé, l'agent ne l'est pas non plus.
En cas de déconnexion, effectivement, tous les softs liés à l'Access ID du personna sautent aussi. Cependant, une icône peut-être vaincues mais la connexin peut rester ouverte, notament par des CIs Trace un peu vicieuse il me semble.
Okhin |
|
| 28-03-2010 09:38:22 | #4 | | Mephisto | Idem...
Valérian a écrit:
Élément pour dire non : dans SR4A, dans la partie sur les agents autonomes, il est précisé qu'ils ont leur propre icône. Est-ce que cela ne veut pas dire qu'un agent embarqué n'en a pas du coup ?
L'agent doit pouvoir être ciblé, donc il doit avoir une icône. La citation de SR4A pourrait vouloir dire que l'icône d'un agent embarqué n'est pas totalement dissociée de celle du hacker, dans le même style que les autres programmes utilisés par le hacker.
Valérian a écrit:
Élément pour dire non : ils sont couvert par le programme furtivité du hackeur.
Il n'y a pas de raison, l'agent doit charger ses propres programmes qui comptent dans la limite du processeur et ne bénéficie normalement pas de ceux du hacker.
Valérian a écrit:
Élément pour dire oui : est-ce que la connexion est bien coupée ou bien c'est juste que la personna ne peut plus agir dans le noeud après avoir été vaincue (mais la connexion reste active et donc traçable). autrement dit une icône vaincue en cybercombat laisse un "cadavre" analysable. Dans ce cas, la personna peut être à terre (par analogie avec un combat physique) mais ces agents embarqués sont toujours actifs jusqu'à ce qu'ils soient vaincus à leur tour.
Je dirais que non: l'agent embarqué accompagne le hacker et se fait jeter du nœud en même temps que lui. Ce qu'on analyse pour tracer un hacker qui n'est plus connecté au nœud, ce sont les logs de sécurité. |
|
| 29-03-2010 21:24:01 | #5 | | Solace | Salut,
Je vous livre ma version des choses (un poil différente de la votre)
Je pars du postulat qu'un agent est un programme comme un autre.
Ex: Une boule de poil en forme de virus sur l'épaule du persona du hacker.
Premiere réponse: Elle est dans mon exemple. Un programme à forcément une représentation dans la matrice. Même subtile, genre un monocle pour un programme d'analyse, ou un string d'energie pour un programmed'armure.
Deuxieme réponse: Pour moi si l'agent fait du "Hack sur la mouche" avec son propre programme d'exploitation, il profitera de la cape d'invisibilité/programme de furtivité du hacker. C'est l'une des différences que je fais un programme autonome qui ne profite que des programmes qu'il charge lui même.
Troisieme réponse: L'agent étant un programme chargé par le persona, il freeze lorsque l'icone persona est shooté. A la différence une nouvelle fois d'un agent autonome qui vit sa vie même si le persona du hacker est shooté, comme une IC. |
|
| 30-03-2010 01:19:38 | #6 | | Valérian | Pour la troisième question, j'ai relut les règles et une persona vaincue en combat matricielle est automatiquement déconnectée donc ses programmes et agents se désactivent sur le noeud où avait lieu la baston.
J'en tire la conclusion que si une persona accompagnée d'agent est détectée en train de hacker un noeud, ses défenses (CI et spiders) vont appliquer la règle du "shoot the persona first" et ignorer par conséquent les agents. Il faut donc mieux charger un programme armure pour la persona que pour les agents.
Il est acquis qu'un agent embarqué dans une persona dispose d'une représentation matricielle (une icône donc) et qu'elle sera liée à l'icône de la persona (un peu comme un chien en laisse si on veut une vision imagée de la chose) et il en va de même pour les programmes classiques qui tournent avec la persona.
A noter que les programmes classiques sont couverts par le programme Furtivité de la persona (sinon le hacker se ferait repérer très facilement si on le voit en train de faire tourner un programme de hacking au grand jour). Du coup, une IC de patrouille qui analyse la persona ne fait qu'un seul jet et pas un par programme. Reste à savoir si elle fait ou pas une analyse spécifique des agents.
Les programmes que l'on est autorisé à utiliser sur un noeud sont définis par le type de compte dont on dispose (programme de base pour un compte utilisateur et programme de hacking pour un compte sécurité, c'est défini dans Unwired). D'ailleurs ont peut très bien chargé dans sa persona des programmes de hacking (après tout, vous êtes admin sur votre propre Commlink), mais si la persona est loggée sur un noeud distant avec un simple compte utilisateur, elle n'aura pas le droit d'utiliser des programmes de hacking sur ce noeud, même s'ils tournent pourtant déjà dans la persona. Il en va de même pour les programmes que fait tourner un agent lié à la personna. Si on programme vous est interdit, il est interdit par extension à vos agents.
Argh... non seulement, je n'ai toujours pas trouvé les réponses à toutes mes questions, mais en plus, j'en men pose de nouvelles après tout ce speech.
Quatrième question : peut on interdire aux utilisateurs via les privilèges de compte de faire appel à leur propre agent embarqué dans leur persona ?
Je pense que oui, vu qu'un compte utilisateur est restreint par une interdiction d'utiliser un programme de hacking. On doit donc pouvoir interdire (ou limiter à un nombre donné) l'utilisation d'agent embarqué dans la persona. |
|
| 30-03-2010 08:42:39 | #7 | | Mephisto | Valérian a écrit:
A noter que les programmes classiques sont couverts par le programme Furtivité de la persona (sinon le hacker se ferait repérer très facilement si on le voit en train de faire tourner un programme de hacking au grand jour). Du coup, une IC de patrouille qui analyse la persona ne fait qu'un seul jet et pas un par programme. Reste à savoir si elle fait ou pas une analyse spécifique des agents.
Ça se tient. Remarque qu'il y a quand même une différence fondamentale entre un agent embarqué et un programme classique: le premier a un moniteur de condition matriciel et doit être vaincu en cybercombat pour être désactivé, alors que le deuxième peut simplement être crashé. Bon ça ne répond pas vraiment a la question, mais ça montre que les agents peuvent être gérés différemment dans certains cas.
Valérian a écrit:
mais si la persona est loggée sur un noeud distant avec un simple compte utilisateur, elle n'aura pas le droit d'utiliser des programmes de hacking sur ce noeud, même s'ils tournent pourtant déjà dans la persona.
Ça par contre je ne savais pas. Tu saurais donner une référence stp? |
|
| 30-03-2010 08:55:45 | #8 | | Valérian | Dans la description des privilèges de compte (utilisateur, sécurité, admin) de Unwired (chapitre topologie de la matrice). |
|
| 30-03-2010 09:07:30 | #9 | | Mephisto | Merci, je viens de relire le passage en question: à mon sens la restriction sur les programmes ne concerne que ceux qui tournent sur ledit nœud, pas ceux qui tournent sur ton propre commlink. |
|
| 30-03-2010 11:25:23 | #10 | | okhin | Alors, comme d'hab, il y a deux compétences. Informatique pour effectuer les actiosn légitimes, celles autorisés par ton compte (donc, utiliser les softs de Hacking avec un compte sécurité par exemple) et Hacking pour celles que tu n'as pas le droit de faire (éditer l'Access Log avec un compte utilisateur classique). C'est la raison d'être de Hacking d'ailleurs.
Sa contrepartie étant que, à chaque utilisation de Hacking, le node a une chance de détecter le hacker.
Okhin |
|
| 30-03-2010 12:09:42 | #11 | | Valérian | Mephisto a écrit:
Merci, je viens de relire le passage en question: à mon sens la restriction sur les programmes ne concerne que ceux qui tournent sur ledit nœud, pas ceux qui tournent sur ton propre commlink.
Je ne pense pas que les privilèges de compte se limitent aux programmes tournant sur le noeud car dans ce cas, l'accès d'un compte sécurité au programme de hacking n'a aucun intérêt vu qu'un node ne va pas fournir de tel programme aux icônes connectées (de la manière dont une bibliothèque virtuelle peut fournir un programme Catalogue à ceux qui s'y connectent), ce serait donner le bâton pour se faire battre (en fait les softs de hacking et plus particulièrement la sous-catégorie des softs de cybercombat est prévue pour être intégré à la persona d'un spider ou la cargaison d'une IC).
Pour moi, les restrictions d'un noeud pour les comptes utilisateurs définit quel programme de ta persona tu peux utiliser (ou pas) sur le noeud, tout du moins tant que tu es un utilisateur légitime (le hacker lui n'a pas un compte légitime et se dissimule ainsi que ses programmes derrière son programme de Furtivité, du coup il peut passer outre ces limitations).
Pour y avoir réfléchit hier soir, ce mécanisme est nécessaire pour gérer les droits des personas qui se connectent à plusieurs noeuds en même temps. Exemple :
Dans ton Commlink, tu peux charger des programmes standard (analyse, catalogue, édit...) et des programmes de hacking (armure, attaque, traque) vu que tu es admin dans ton propre Link. Si tu te connectes à un noeud A où tu as un compte sécurité (par exemple parce que tu y assures un job de spider), ton icône de persona est présente dans ce noeud avec tous ses programmes en cours d'exécution et tu seras autorisé à utiliser tes softs de spider). Si dans le même temps, tu te connectes à un deuxième noeud B avec simplement un compte utilisateur, tu auras aussi une icône présente dans ce deuxième noeud, avec la même liste de programme en cours d'exécution, mais cette fois, tu as interdiction d'utiliser tes softs de spider dans le noeud B.
En fait, le noeud B ne t'interdit pas de faire tourner dans ta persona des softs de hacking vu que tu peux en avoir besoin de manière légitime ailleurs, mais en revanche, les privilèges de compte servent à t'interdire de t'en servir dans le noeud B. |
|
| 30-03-2010 13:14:04 | #12 | | Mephisto | Valérian a écrit:
Je ne pense pas que les privilèges de compte se limitent aux programmes tournant sur le noeud car dans ce cas, l'accès d'un compte sécurité au programme de hacking n'a aucun intérêt vu qu'un node ne va pas fournir de tel programme aux icônes connectées (de la manière dont une bibliothèque virtuelle peut fournir un programme Catalogue à ceux qui s'y connectent), ce serait donner le bâton pour se faire battre (en fait les softs de hacking et plus particulièrement la sous-catégorie des softs de cybercombat est prévue pour être intégré à la persona d'un spider ou la cargaison d'une IC).
Une IC ou un spider qui opérerait à partir de ce nœud aurait justement besoin d'un compte sécurité pour pouvoir utiliser ce genre de programme, donc je ne trouve pas ça totalement dénué d'intérêt. Mais je suis d'accord que ton interprétation se vaut également, je trouve juste très étrange que cette limitation importante n'ait été introduite que dans Unwired.
Pour moi, les restrictions d'un noeud pour les comptes utilisateurs définit quel programme de ta persona tu peux utiliser (ou pas) sur le noeud, tout du moins tant que tu es un utilisateur légitime (le hacker lui n'a pas un compte légitime et se dissimule ainsi que ses programmes derrière son programme de Furtivité, du coup il peut passer outre ces limitations).
Donc, si je te suis bien, l'autorisation des programmes de hacking dépend non seulement des privilèges associés au compte, mais également:
- de la légitimité du compte
- de l'utilisation du programme de furtivité
Franchement je ne me rappelle pas avoir lu tout ça, et je trouve que ça commence à faire beaucoup de suppositions. |
|
| 30-03-2010 23:44:38 | #13 | | Slevin | Sans vouloir me mêler de ce qui ne me regarde finalement pas beaucoup, je vote tout de même pour la réponse si juste de Okhin. Effectivement un compte utilisateur ne permet pas légalement d'utiliser des programmes de hacking (et heureusement je trouve), mais si un perso veut le faire (et pourquoi n'aurait-il pas le droit d'ailleurs) et bien il utilisera la comptétence hacking et non informatique pour faire ses jets. Alors le système fera un jolie test d'Analyse pour percer le programme de furtivité et voir que l'utilisateur utilise bien quelque chose dont il n'a pas l'autorisation!
Après, l'embarquement d'un programme de hacking met la personne dans une configuration illégale du fait du niveau restreint de sa disponibilité. Une personne se faisant alors topé en "simple" possession (et embarquement) de programme de ce genre devra probablement montrer un permis (de la même manière que s'il s'agissait d'une arme transporté en ville ou dans un magasin).
Voilà. Bonne réflexion. |
|
| 31-03-2010 00:08:43 | #14 | | Valérian | @Mephisto : Je ne suis pas sur d'avoir compris ta première remarque. Pour moi, les CI et les spiders ont effectivement besoin d'avoir un compte sécurité pour faire leur boulot de défense sur un noeud.
Deuxième remarque : En fait, ce n'est pas si compliqué que cela : le principe de base c'est que les utilisateurs sur un noeud ne sont pas autorisés à utiliser des softs de hacking ou de combat (au même titre que tu ne te balades pas avec un fusil d'assaut dans la rue). Un hacker en revanche, lors de sa tentative de hacking à la volée va se créer un compte bidon et dissimuler ce qu'il fait sous son soft Furtivité, et ca c'est ce que tu fais déjà je présume.
Le seul intérêt de rentrer plus dans les détails de fonctionnement du mécanisme (voir mon exemple dans mon post précédent), c'est pour savoir quel degré de contrôle un noeud excerce sur ses utilisateurs connectés. En l'occurrence, je dirais que le système ne contrôle pas activement les programmes embarqués par une persona vu que le blocage se fait au moment de l'utilisation du programme. Le fait d'avoir un programme de hacking dans ta persona (ou qu'un agent avec toi dispose de ce programme) n'est donc pas une condition suffisante pour que le système considère que tu es un intrut à chasser. Du coup, une CI en patrouille qui examine un utilisateur fraichement connecté au système ne regarde pas ses programmes mais le degré de légitimité du compte (est-ce un vrai compte créé par un admin pour un utilisateur donné ou un compte forgé par un exploit par un hacker). Je dirais donc pour répondre à ma deuxième question de mon post initial, qu'une CI en patrouille ne s'intéresse qu'à l'icône du hacker et pas à ses éventuels agents (on fait donc un unique test de perception matricielle de la CI contre Hacking+furtivité du hacker), aussi ces derniers n'ont pas à embarquer un programme furtivité. |
|
| 31-03-2010 10:01:08 | #15 | | Mephisto | Valérian a écrit:
@Mephisto : Je ne suis pas sur d'avoir compris ta première remarque. Pour moi, les CI et les spiders ont effectivement besoin d'avoir un compte sécurité pour faire leur boulot de défense sur un noeud.
Je veux dire que des agents et IC peuvent très bien opérer à partir du nœud ciblé par le hacker, i.e. ils peuvent avoir chargé leurs programmes précisément sur ce nœud. Je ne trouve donc pas totalement dénué d'intérêt que la limitation ne porte que sur les programmes chargés sur le nœud, et non sur les programmes utilisés par les personas connectés au noeud.
Alors, comme d'hab, il y a deux compétences. Informatique pour effectuer les actiosn légitimes, celles autorisés par ton compte (donc, utiliser les softs de Hacking avec un compte sécurité par exemple) et Hacking pour celles que tu n'as pas le droit de faire (éditer l'Access Log avec un compte utilisateur classique). C'est la raison d'être de Hacking d'ailleurs.
Sa contrepartie étant que, à chaque utilisation de Hacking, le node a une chance de détecter le hacker.
Je suis d'accord, mais à mon avis on ne parle pas exactement de la même chose. Certaines utilisations de programmes ne se font pas avec la compétence Informatique ou Hacking.
Par exemple, en cybercombat, on peut utiliser Cybercombat + Blackhammer. De même, il y a pas mal d'actions qui ont comme seuil de réussite le programme de Furtivité du hacker. Si ce dernier ne peut pas utiliser de programmes de hacking, comment gérer ces cas particuliers? On les autorise quand même?
Deuxième remarque : En fait, ce n'est pas si compliqué que cela : le principe de base c'est que les utilisateurs sur un noeud ne sont pas autorisés à utiliser des softs de hacking ou de combat (au même titre que tu ne te balades pas avec un fusil d'assaut dans la rue). Un hacker en revanche, lors de sa tentative de hacking à la volée va se créer un compte bidon et dissimuler ce qu'il fait sous son soft Furtivité, et ca c'est ce que tu fais déjà je présume.
Le programme de Furtivité est sans doute le plus important pour un hacker, mais je ne pense pas que hacker un nœud sans ce soft soit impossible, c'est juste que le hacker se fera repérer et déclenchera une alerte très rapidement. Ce que je veux dire, c'est qu'une action ne devrait pas être impossible simplement parce que le hacker n'a pas chargé son soft de Furtivité. De même, je ne pense pas que certaines actions devraient être autorisées avec un compte bidon obtenu par un hacking à la volée, mais pas avec un compte subtilisé à un utilisateur légitime, pour autant que les deux comptes aient les mêmes droits d'accès. |
|
| 31-03-2010 11:09:19 | #16 | | okhin | Bah, le cybercombat, c'ets un cas à part. Les alarmes ont sautés, c'est la merde et faut en finir octet par octet. Effectuer une actiond 'Attaque, c'est comme tirer en FA dans la rue, il 'nest plsu temps d'utiliser Baratin, mais Fusil d'Assaut.
90% des actions légitimes ne nécessitent aps de jets. Ou alors juste pour voir combien de temps on mets (sauf datasearch qui nécessite n peu d'intelligence), mais, globalement, un utilisateur ne fait aps de jet quand il utilise un node. Tu le fait lorsque tu es pressé et que tu as un peu de pression.
Et toutes les actions qui se font contre l'indice de Furtivité sont des actions de détection d'activité louche.
Enfin, le programme Stealth n'est absolument pas nécessaire. Tur entre comme un bourrin dans un node, tu Nulke à tout va, tu démonte les IC/spiders en cybercombat et ça roule. C'est un autre style. C'ets comme un Spec Ops comparé à un Ganger Troll du Sprawl. Le résultat est le même, mais la méthode diffère. Le premier utilise Stealth, le second CyberCombat.
Quand au compte, le but du compte bidon c'est, justement, de faire croire au système que c'est un compte légitime. ET donc de pouvoir l'utiliser en tant que tel.
Okhin |
|
| 31-03-2010 14:14:11 | #17 | | Mephisto | Donc, pour reprendre cette citation de Valérian:
Valérian a écrit:
mais si la persona est loggée sur un noeud distant avec un simple compte utilisateur, elle n'aura pas le droit d'utiliser des programmes de hacking sur ce noeud, même s'ils tournent pourtant déjà dans la persona.
Cela signifie en fait que n'importe qui peut utiliser ses programmes de hacking sur le nœud. Simplement, dans le cas d'un simple compte utilisateur, il faut substituer Informatique par Hacking quand c'est applicable et le serveur a droit à un test pour détecter l'action du hacker à chaque fois.
C'est également comme ça que je vois les choses, mais pas sûr que Valérian l'entende de cette oreille...
En supposant qu'on soit d'accord:
Valérian a écrit:
Quatrième question : peut on interdire aux utilisateurs via les privilèges de compte de faire appel à leur propre agent embarqué dans leur persona ?
Je pense que oui, vu qu'un compte utilisateur est restreint par une interdiction d'utiliser un programme de hacking. On doit donc pouvoir interdire (ou limiter à un nombre donné) l'utilisation d'agent embarqué dans la persona.
La réponse serait donc non. |
|
| 31-03-2010 14:28:21 | #18 | | okhin | En fait, que fait un Agent? Il utilise un compte pour exécuter sa cargaison dasn un node. De fait, il hérite des droits de son propriétaire.
Donc, un utilisateur qui embarque un Agent avec Browse 3 dans son persona qui se logue sur un node avec un compte utilisateur peut demander à son agent d'utiliser Browse.
Si l'agent embarqué veut utiliser, au hasard, Exploit, comlem le compte utilisateur classique l'interdit, il doit utiliser Hacking (donc Pilot) pour ce faire.
Après, un node peut interdire d'utiliser sur les données qu'il contient des utilitaires. On peut envisager, par exemple, qu'un node fournisse une suite utilitaire et que les utilisateurs soient obligés d'utiliser ceux-là pour accéder aux données du node. Cela n'empêche pas un utilisateur d'utiliser son Browse pour, par exemple, chercher des données sur la Matrice.
Okhin |
|
| 31-03-2010 15:14:42 | #19 | | Valérian | Petits résumés de la manière dont je gèrerais la bidouille sur un noeud :
Premier cas : tu rentres dans le noeud via un hacking à la volée. Tu crées donc un compte bidon et tu te dissimules aux yeux du système avec Furtivité. tu pourras alors utiliser des softs de hacking sur le node (par exemple pour analyser un fichier de données, désarmer la bombe qu'il contient et éditer le fichier afin d'en faire une copie).
Deuxième cas : tu rentres dans le noeud via un compte légitime (parce que tu as volé le login/mot de passe d'un vrai utilisateur). Si tu veux faire des trucs louches, tu commences par charger un programme Furtivité dans ta persona, puis des programmes de hacking. Après, tu peux aller voler les données de la même manière que le premier cas (la seule différence c'est qu'il est bien plus simple pour un spider ou un admin de te déconnecter du noeud par rapport à un compte créé par hacking à la volée).
Troisième cas : tu rentres dans le noeud via un compte légitime, Tu actives tes programmes de hacking (selon moi, le noeud ne t'interdit pas de les activer mais de les utiliser). Après, cela peut être envisageable d'autoriser l'utilisateur à tenter forcer le système avec un jet de hacking+programme sans être couvert par son programme furtivité (car ca c'était mon deuxième cas), mais je considerais pour ma part que le système s'aperçoit automatiquement de la tentative et génère une alerte. Il va falloir être très rapide pour voler les données car cela va être très simple pour les défenses du système de virer le malotru (pour un spider, déconnecter un utilisateur légitime nécessite une action complexe mais pas de jet. Pire, si le noeud est configuré pour répondre à une alerte par une tentative de déconnexion, c'est direct dehors pour le hacker).
Pour ce que propose Okhin, cela revient à interdire à un utilisateur d'utiliser tous ses programmes et pas seulement ceux de hacking. En contrepartie, il peut lancer une exécution de programme mis à sa disposition par le noeud. Le premier défaut c'est que cela bouffe de la ressource sur le noeud tandis que lorsque les utilisateurs utilisent leur soft, c'est leur Commlink a eu qui gère la ressource nécessaire. Ensuite, cela reste une restriction pour les utilisateurs légitimes qui utilisent le noeud comme il le devrait. Dans ce cas là, ca ne protège pas plus le contenu du noeud vu qu'un hacker pourra contourner la restriction grâce à un programme furtivité (qui lui permet de masquer le fait qu'il utilise ses propres softs et pas la suite logicielle fournie par le noeud). Donc c'est faisable, mais en pratique ca n'offre aucune sécurité en plus. |
|
| 31-03-2010 15:26:10 | #20 | | okhin | Cas 3: Ben, le node ne te détecte pas forcément. Il fait Analyse + Firewall cpontre Stealth, mais si il ne sort pas de succès, il ne te détecte pas. Si il n'as pas analyse, il défausse sur Firewall, il lance donc Firewall - 1. Donc, il faut qu'il ait un Firewall de 4 pour garantir un succès. Et 4, ça commence à être des ndoes sérieux. ALors, effectivement, beaucoup de node ont Analyse, mais pas tous.
Et pour le dernier cas: En fait, ça permet de maîtriser ce que fait un utilisateur légitime. Ça permet d'éviter qu'il utilise un programme infecté par un virus, un trojan ou un ver. Bref, ça a une utilité de sécurité, à un coût assezs fort en ergonomie. Comme avec tout systme sécurisé.
Okhin |
|
| 31-03-2010 17:41:18 | #21 | | Valérian | Dans mon troisième cas, tu n'utilises pas le programme de Furtivité. Sans programme, il n'est pas possible de cacher ta tentative de hacking, d'où une détection automatique. |
|
| 31-03-2010 18:00:57 | #22 | | okhin | Ben en fait, je persiste, il n'y a pas de détection automatique. le système peut planter, ou ne pas voir l'erreur, ou plein de choses dans ce genre là. la probabilité est faible hein (dés qu'il y a un softd'Analyse, ça tombe assez vite), mais elle existe.
Okhin |
|
| 31-03-2010 18:17:14 | #23 | | Mephisto | De toute façon, si tu te fais détecter, dans un premier temps ça ne fait que déclencher une alerte:
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.
Les privilèges du hacker sont à ce moment réduits à néant, mais il a toujours la possibilité d'effectuer les actions non autorisées grâce à sa compétence de Hacking.
EDIT: mais effectivement, dans le cas d'un compte légitime, le système ou un spider peut déconnecter le hacker immédiatement, sans test: "If the hacker used a passcode and legitimate account to log on, then the connection is immediately terminated". Il n'ira pas bien loin s'il n'utilise pas de programme de Furtivité, à moins qu'il n'y ait pas de spider ou que le sytème n'ait pas été configuré pour réagir de cette façon. |
|
| 01-04-2010 08:49:06 | #24 | | Mephisto | J'ai repensé à cette histoire de déconnexion automatique: vu que les spiders utilisent vraisemblablement des comptes légitimes, qu'est-ce qui empêche un hacker ayant les droits d'accès suffisants de les virer illico presto du serveur de la même manière? |
|
| 01-04-2010 09:09:32 | #25 | | K-ZimiR | Surement parce que deconnecter un compte admin ne se fait pas aussi facilement que deconnecter un compte utilisateur. |
|
| 01-04-2010 10:36:39 | #26 | | okhin | Bah, rien en fait, si ce n'est qu'il faut être soit même au mieux admin.
Ah, un détail, moins il y a de compte privilégié, moins il y a de failles. DOnc, à priori, personne n'utilise de compte adm:in, mais plus vraissemblablement des comptes sécurité. Le compte admin ne sert que pour mettre à jour le système et pour rebooter/isoler le node.
Okhin |
|
| 01-04-2010 15:58:07 | #27 | | Valérian | Mephisto a écrit:
J'ai repensé à cette histoire de déconnexion automatique: vu que les spiders utilisent vraisemblablement des comptes légitimes, qu'est-ce qui empêche un hacker ayant les droits d'accès suffisants de les virer illico presto du serveur de la même manière?
Théoriquement, rien.
C'est un peu le problème des hacks visant à choper un compte admin. Le hacker devient tout puissant s'il ne se fait pas repérer par le système lors de sa tentative d'intrusion (ce qui est chaud en hack à la volée, mais relativement facile pour un hack préparé à l'avance).
Ca mériterait peut être de s'y pencher pour savoir s'il ne faut pas encadrer un peu tout cela pour définir clairement ce qui peut être fait et ce qui ne peut pas. |
|
| 01-04-2010 17:01:59 | #28 | | okhin | Bah, un hack préparé pose unproblème de temps en Fait. 1 heure par jet en RV (hotsim, peut-être aussi en cold sim), 1 jour en RA. Pour un node classique 3, ça demande la bagatelle de 12 succès. En prenant un bon hacker (6 en comp et 6 en Exploit, sans les spéc, les trucs genre bon codeurs et autre) en RV ça fait 4 succès au premier jet (12/3), 4 au second (11/3), 3 au troisième (10/3) et 3 au quatrième (9/3). Donc 4 heures pour un bon (très) hacker qui casse un node moyen. 4 jours sans la RV.
Après, couper une connexion n'est pas forcément une action facile et triviale. Faudrait que je revérifie les règles, mais le moyen le plus simple de déconnecter quelqu'un reste de planter son icône.
En fait, on pourrait dire qu'un privilège permet de kicker les comptes avec des privilèges strictement inférieurs. Donc un admin ne peut pas kicker un admin automatiquement, il doit faire un jet ou autre truc du genre.
Okhin - de toutes façon, ça vaut pas une Nuke |
|
| 01-04-2010 17:31:33 | #29 | | Mephisto | okhin a écrit:
Après, couper une connexion n'est pas forcément une action facile et triviale. Faudrait que je revérifie les règles, mais le moyen le plus simple de déconnecter quelqu'un reste de planter son icône.
En fait, si tu utilises un compte légitime, c'est effectivement trivial:
TERMINATE CONNECTION
Once an intruder is identified and a restricted alert issued, a node with this response attempts to sever the hacker’s connection by shutting down the port through which he is accessing the node. In order to sever a connection, the node immediately makes an Opposed Firewall + System Test against the hacker’s Hacking + Exploit program (if running). The system adds a dice pool modifier of +1 for each IC program running in the node. The hacker’s receives a +2 dice pool bonus if using a security account, or +4 if using an admin account. If the hacker used a passcode and legitimate account to log on, then the connection is immediately terminated. If the node achieves more hits, it disconnects the hacker. The hacker can attempt to log back on, but the node will be on alert (and may have closed down all outside connections).
Avec une petite précision dans Unwired:
Additionally, a spider (or any user with an admin account) may spend a Complex Action to have the node make an attempt to terminate a connection; this may be done without an alert, but also without the bonus.
Après tu enchaines avec ça, et au revoir le spider:
A hacker can also instruct the node to block future access connection requests from a particular node or access ID (or a range of nodes/access IDs), locking the target out. To accomplish this, the hacker must have access to the node and must make a Computer + Edit (1) Test if they have security or admin privileges; or a Hacking + Edit (2) Test if he does not. Accounts may also be deleted (if active, the user’s connection must be terminated first) with a successful Software + Editing (1) Test, assuming you have security or admin privileges; Hacking + Edit (2) Test if you do not. |
|
| 01-04-2010 18:12:07 | #30 | | okhin | je trouve pas le passage dans Unwired VF. Mais ça parle d'AccesLog chiffrés, sauvegardés, backupé et restaurés.
A, et, de toutes façon, un spider à la man sur la prise, lui. il peut mettre hors-ligne le node et le restaurer en quelques secondes ça n'est aps vraiment un problème.
Okhin |
|
| 02-04-2010 10:08:40 | #31 | | Mephisto | Pas toujours, les spiders peuvent opérer à distance également. A mon sens c'est même plutôt la règle que l'exception.
Mais s'il suffit de redémarrer le nœud pour restaurer la configuration d'origine, effectivement ça reste une réponse intéressante quand un hacker commence réellement à saccager le système. D'un autre côté, pour certains serveurs, j'imagine que le moindre downtime peut représenter une grande perte pour la corpo. |
|
| 04-04-2010 00:55:07 | #32 | | Valérian | J'ai peut être trouvé une utilité au programme Furtivité confié à ses agents embarqués avec sa persona au cours d'un hacking : Le programme Furtivité agit comme malus à un test de pistage matriciel. Du coup, des agents dépourvu de ce programme sont plus simples à pister que le hacker qui les déploie. |
|
| 06-04-2010 14:07:23 | #33 | | okhin | Ah oui, ya le pistage matriciel aussi. Bien vu.
Okhin |
|
| 14-04-2010 13:06:10 | #34 | | Slevin | Une petite question qui ne nécessite pas la création d'un sujet spécifique :
Alors, faut-il deux programmes différents pour le hacking avec son agent de poche si on veut que chacun soit camouflé? La question à mon sens est plus importante que l'on pourrait le croire, surtout si on rajoute à l'équation l'option ergonomie qui du coup peut poser alors problème dans le cas d'une multi-utilisation d'un programme agrémenté de l'option. Je crois me rappeler que quand on visite virtuellement une bibliothèque et que l'on a un compte, on peut bénéficier de l'utilitaire Catalogue qui est partager aux différents utilisateurs. Je n'ai plus les sources mais je crois que c'était faisable. Alors ne faut-il pas considérer tous les utilitaires comme partageables à tous les utilisateurs ayant les droits pour, ce qui serait le cas d'un agent que l'on dirigerait, plutôt que de devoir faire une copie pour chaque utilisateur?
A l'époque actuel, si j'ai word sur mon ordi, toute session ouverte peut utiliser le programme (je n'ai aucune action chez crosoft!). N'est pas la même chose ici? Mais si c'est le cas, il faudrait surement considérer que chaque utilisation d'un soft, partagé ou non, rentre dans la limitation processeur. Mais ça se complique si, par exemple, sur mon link de réponse 4 où tournent déjà 4 softs ergonomiques, je souhaite permettre à mon agent d'utiliser un de ceux-ci. Il risque de me faire un belle écran bleu!
Je sais pas trop, qu'est-ce que vous en pensez? |
|
| 14-04-2010 13:43:29 | #35 | | okhin | Alors non, un soft n'est pas copiable (sauf à prendre les options qui vont bien). Jamais. A aucun moment. Il faut faire sauter l'option de protection anticopie, et ça nécessite un jet de Software + Logique (cf Unwired).
De plus, un soft est lié non pas à un node, masi à un personna et/ou un AccessID (à vérifier). Ce qui fait que, sur la plupart des nexus, je trouevrai une batterie d'utilitaire accessible simplement (tant que j'ai un compte legitime ou qui passe pour tel).
Ce qui fait aussi que, mon agent qui tourne dans mon persona, à accés au même soft que ma personna. Si il s'en détache, il forme lui-même sa propre version limitée de Persona (sans que ça en soit une) et donc, de faites, n'accède plus à mes softs. il doit les avoir dans sa cargaison et, AMHA, avoir été acheté séparément.
De même, tes coéquipeirs ne peuvent aps utiliser tes softs, leur AccessID ne correspond pas et tu ne peux, de plus, pas les copiers (et non, tes coéquipiers ne se connectent pas sur ton comlink, tu n'emprunte pas leurs bagnole ou leur flingues, ils n'empruntent pas ton comlink).
Il existe des parades, priuncipalement prendre des softs piratés (mais tes logiciels ne sont plus patchés et se dégradent) ou opensource (tes softs ne se dégardent plus, mais il vaut mieux participer à la communauté en fournissant du code). Enfin, la solution do it yourself, faire sauter les deux limites (Accès restreint et protection anti-copie) des software à la amin, mais tu te retrouves dans le cas du software pirate.
Okhin |
|
| 14-04-2010 13:54:19 | #36 | | Valérian | Pour moi, le fait qu'un programme ne soit pas copiable t'interdit d'en donner une copie à une autre personne mais pas pour l'utiliser toi même en plusieurs exemplaires.
Exemple : tu peux acheter un soft d'Analyse et un soft d'ECCM et les installer sur tout tes commlink et tes drones, tant que tu as un compte utilisateur sur ces noeuds avec les droits suffisants pour installer les 2 programmes (ce qui est le cas si les drones sont à toi).
De même, tu peux donner une copie de ton soft Analyse à un de tes agents. Si le programme inclut une option "ergonomie", tant que ton agent tourne sur ton Commlink, il faut compter le soft dans la limite des systèmes programmes ergonomique (donc si tu fais tourner toi aussi analyse, ca fait déjà 2 softs ergonomique sur ton Commlink). |
|
| 29-04-2010 11:59:53 | #37 | | Fantome | A mon humble avis :
1° : Oui, l'Agent dispose de sa propre icône. Néanmoins, puisque le programme est dans le personna du hacker, sa représentation comporte un lien physique avec le hacker (on peut imaginer un dobberman tenu en laisse, un drône relié au hacker par une liaison filaire selon les goûts de chacun).
2° : Non, il n'a pas besoin de chargé un programme de furtivité. L'agent est chargé dans la personna. Un programme chargé ne peut pas lui même chargé d'autres programmes, par contre, il bénéficie de l'ensemble des programme également chargé. Un programme d'Edition chargé par le hacker bénéficie du programme de furtivité, idem pour l'agent.
3° : Non. Lorsque le hacker est vaincu, son personna est éliminé et tous les programmes chargés avec lui le sont également. L'agent ne subsiste pas;
Par contre, rien n'interdit au hacker quand il sent que ça va devenir difficile pour lui de prendre une action complexe pour charger son agent dans le noeud, ce qui le rend alors indépendant de lui.
Ca prend une action complexe, mais du coup, l'agent sera indépendant et subsistera même si le hacker est vaincu, ce qui peut avoir son avantage. |
|
| 29-04-2010 12:21:53 | #38 | | Valérian | Je ne suis pas d'accord avec ton 2° :
Un agent a besoin de faire tourner ses propres programmes, qu'il soit indépendant dans la matrice ou embarqué avec ta persona. |
|
| 29-04-2010 13:22:52 | #39 | | okhin | Pour ta conclusion fantôme, pas d'accord, l'agent partage le même AccessID que toi. Donc, tu ne peux pas l'enregistrer sur un node (sauf si il a l'option qui va bien, cf Unwired) avec ta propre connexion.
Quand au 2, je suis ok avec val'. L'agent et la persona dispose de deux contextes d'exécution séparé et ne partagent pas la même zone mémoire, il faut docn charger deux fois le programme. Ou deux programmes identiques. C'ets pareil.
Okhin |
|