| 19-01-2009 23:42:22 | #1 | | Valérian | Je trouve que cet aspect des runs est peu développé dans les règles (tout du moins, c'est dispersé aux 4 coins des suppléments, ce qui ne contribue pas à une bonne vision d'ensemble), alors qu'il peut relever d'une grande importance, particulièrement si on veut s'amuser avec quelques drones, et de manière générale, un bon groupe de runners est un groupe qui se préoccupe de sa sécurité matricielle et donc de ses protocoles de communication.
A ce stade, j'ai plusieurs questions à propos des règles :
Prenons le premier volet de la guerre électronique, à savoir le repérage de nodes cachés (SR4 p225) :
On cherche à localiser des nodes à portée... première question : à portée de quoi ?
Cette règle couvre la détection des nodes à portée de Signal de son Commlink ou ceux à portée réciproque de Signal (auquel cas, la détection n'a de sens que si le type dissimulant son link n'a pas restreint le signal) ?
Deuxième point : ca apporte quoi concrètement comme information de localiser un commlink en mode cachée ?
Sa donne son access ID je présume, et donc il devient hackable. mais est-ce que ca le localise physiquement dans l'espace par rapport à votre position ?
Deuxième aspect des règles de guerre électronique, l'interception de communication wireless (SR4 p225) :
Là, il suffit d'être à porter du Signal que l'on veut intercepter.
La question qui vient ensuite est alors de savoir ce que la règle permet d'intercepter. Est-ce que l'on intercepte toutes les communications wireless à porter (ce qui peut faire un énorme flux de data au centre ville), ou bien on cherche à intercepter une communication spécifique ou tout du moins les communications d'un node spécifique ?
Dans ce deuxième cas, il y a selon moi un pré-requis non dit, à savoir disposer de l'access ID du node (les échanges de données entre nodes contiennent obligatoirement l'accessID de l'émetteur et l'accessID du destinataire à des fins de routage, d'après Unwired).
Deuxième point : ca apporte quoi concrètement comme information d'intercepter une communication (outre le contenu de la communication), l'access ID du deuxième interlocuteur ? la localisation physique de l'émetteur par rapport à votre position ?
Troisième point : quid des commcodes (ca remplace l'accessID) ?
Question architecture matricielle maintenant : comment la matrice fait pour savoir où router votre requête quand vous voulez ouvrir une communication avec un pote à vous globetrotteur qui peut être n'importe où sur le globe ?
Son Commlink informe régulièrement son Matrix service Provider de sa localisation physique approximative (je suppose que ca doit fonctionner comme ca actuellement pour les téléphones portables) ?
Si vous vous promenez avec votre Commlink en mode actif dans la rue, les types sur le trottoir qu'il font un scan matriciel vous repère instantanément (voir règle de détection des nodes p225), mais quelles sont les informations qu'il peut consulter librement de cette manière ?
Question à propos de l'asservissement de nodes : il est dit que cela consomme une Souscription pour instaurer un lien Slave/master entre un équipement et son Commlink (afin de protéger le premier des risques de hacking). Comme un équipement a toujours au moins un score de Système de 1, il a droit à 2 souscriptions. Je présume que l'on peut donc asservir en chaine tous ses équipements individuels pour terminer par le Commlink, et ainsi ne consommer qu'une seule de ses souscriptions (ex : l'équipement A est relié à B qui est relié à C qui est relié à D qui est relié au commlink) ?
Le fait de contrôler un drone suppose de maintenir une souscription, alors quitte à faire, autant en profiter pour déclarer votre drone en "slave" (voir la règle d'Unwired sur les souscriptions p55) si on veut éviter qu'il se fasse hacker, non ?
Mais que devient votre souscription si le drone est pris dans une zone de brouillage ? |
|
| 20-01-2009 10:38:06 | #2 | | Blade | Valérian a écrit:
Je trouve que cet aspect des runs est peu développé dans les règles (tout du moins, c'est dispersé aux 4 coins des suppléments, ce qui ne contribue pas à une bonne vision d'ensemble)
C'est malheureusement le cas de l'ensemble des règles de hacking du bouquin de base.
Valérian a écrit:
On cherche à localiser des nodes à portée... première question : à portée de quoi ?
Cette règle couvre la détection des nodes à portée de Signal de son Commlink ou ceux à portée réciproque de Signal (auquel cas, la détection n'a de sens que si le type dissimulant son link n'a pas restreint le signal) ?
A portée du signal de son commlink (ou de n'importe quel autre appareil depuis le node duquel on fait l'action). D'une part, il est précisé que les communications nécessitent que les deux appareils soient à portée l'un de l'autre, et d'autre part je vois difficilement comment on pourrait détecter un noeud si on ne détecte aucune de ses émissions...
Valérian a écrit:
Deuxième point : ca apporte quoi concrètement comme information de localiser un commlink en mode cachée ?
Sa donne son access ID je présume, et donc il devient hackable. mais est-ce que ca le localise physiquement dans l'espace par rapport à votre position ?
De manière générale, ça donne accès au node. On peut s'y connecter, y envoyer des messages ou intercepter les messages qui en sortent, etc. On doit pouvoir le localiser physiquement aussi.
Valérian a écrit:
La question qui vient ensuite est alors de savoir ce que la règle permet d'intercepter. Est-ce que l'on intercepte toutes les communications wireless à porter (ce qui peut faire un énorme flux de data au centre ville), ou bien on cherche à intercepter une communication spécifique ou tout du moins les communications d'un node spécifique ?
Dans ce deuxième cas, il y a selon moi un pré-requis non dit, à savoir disposer de l'access ID du node (les échanges de données entre nodes contiennent obligatoirement l'accessID de l'émetteur et l'accessID du destinataire à des fins de routage, d'après Unwired).
Deuxième point : ca apporte quoi concrètement comme information d'intercepter une communication (outre le contenu de la communication), l'access ID du deuxième interlocuteur ? la localisation physique de l'émetteur par rapport à votre position ?
Euh, t'es sûr qu'il n'y a pas d'infos sur les prérequis ? Faudra que je vérifie.
Valérian a écrit:
Troisième point : quid des commcodes (ca remplace l'accessID) ?
C'est expliqué dans Unwired. En gros le commcode c'est un identifiant unique correspondant à une personne (comme un numéro de téléphone), tandis que l'accessID c'est un identifiant unique correspondant à une connexion (comme une adresse IP). Théoriquement, on peut facilement obtenir l'accessID depuis le commcode (de manière à pouvoir joindre quelqu'un dont on va connaitre le commcode mais pas l'accessID). Dans l'autre sens, ça doit pouvoir se faire mais c'est probablement un peu plus complexe (genre comme remonter à l'identité de quelqu'un via une adresse IP).
Valérian a écrit:
Question architecture matricielle maintenant : comment la matrice fait pour savoir où router votre requête quand vous voulez ouvrir une communication avec un pote à vous globetrotteur qui peut être n'importe où sur le globe ?
Son Commlink informe régulièrement son Matrix service Provider de sa localisation physique approximative (je suppose que ca doit fonctionner comme ca actuellement pour les téléphones portables) ?
Plus ou moins oui. Après vu que ça permet un mesh networking, ça doit être un poil plus complexe que la téléphone mobile actuelle, mais bon, de manière générale, autant éviter de se prendre la tête avec ce genre de détails technique. Au final, ce qu'il est important de savoir c'est que le réseau peut localiser le commlink à tout moment, s'il est connecté.
Valérian a écrit:
Si vous vous promenez avec votre Commlink en mode actif dans la rue, les types sur le trottoir qu'il font un scan matriciel vous repère instantanément (voir règle de détection des nodes p225), mais quelles sont les informations qu'il peut consulter librement de cette manière ?
En fait il voit le node et tout ce que tu as decidé de transmettre aux alentours (genre ton profil social, la musique que tu écoutes, etc.). Ensuite, selon ta configuration il pourra se connecter ou pas en tant qu'utilisateur sur ton commlink et y voir le cas échant ce que tu rends disponible aux invités sur ton commlink.
Valérian a écrit:
Question à propos de l'asservissement de nodes : il est dit que cela consomme une Souscription pour instaurer un lien Slave/master entre un équipement et son Commlink (afin de protéger le premier des risques de hacking). Comme un équipement a toujours au moins un score de Système de 1, il a droit à 2 souscriptions. Je présume que l'on peut donc asservir en chaine tous ses équipements individuels pour terminer par le Commlink, et ainsi ne consommer qu'une seule de ses souscriptions (ex : l'équipement A est relié à B qui est relié à C qui est relié à D qui est relié au commlink) ?
Je crois bien que oui, mais je crois que ça a des conséquences particulières. Par exemple, je me demande si on peut différencier deux esclaves d'un noeud esclave (en gros si on a deux drones esclaves d'un commlink lui-même esclave d'un autre commlink, je suis pas sûr qu'on puisse donner des ordres différent à chaque drone.)
Valérian a écrit:
Le fait de contrôler un drone suppose de maintenir une souscription, alors quitte à faire, autant en profiter pour déclarer votre drone en "slave" (voir la règle d'Unwired sur les souscriptions p55) si on veut éviter qu'il se fasse hacker, non ?
Mais que devient votre souscription si le drone est pris dans une zone de brouillage ?
Bah si le drone est brouillé, c'est comme s'il n'avait plus de signal, donc la souscription est coupée. Après si le signal revient, j'imagine que la souscription peut se réétablir automatiquement. |
|
| 09-02-2009 01:12:28 | #3 | | Valérian | J'ai pas mal potasser SR4 et Unwired et je souhaite rediscuter un peu de la guerre électronique et de la sécurité matricielle.
Pour qu'un hacker puisse agir matriciellement contre un réseau wireless (que ce soit le PAN d'une personne, le réseau de communication d'un groupe de runner ou un rigger et ses différents drones), il y a deux pré-requis : disposer de l'access-ID du node que l'on souhaite attaquer (sinon, sans cible difficile d'être efficace) et être à porter réciproque de Signal du node en question (si on ne peut pas communiquer dans les deux sens avec la cible, ca va pas le faire).
C'est là que va intervenir la guerre électronique tant du coté du hacker (pour aider à l'obtention de ces 2 pré-requis) que du coté du réseau où l'on peut mettre en place un certain nombre de mesures pour sécuriser le réseau.
En guise d'exemple, prenons un hacker qui tente d'échapper à un streetsam, lequel dispose d'un certain nombre de gadgets électroniques dont un Commlink, des trodes, un smartgun, une paire de lunette de visée. Premier cas de figure, le streetsam est une buse en électronique et n'a pris comme qu'une seule précaution particulière au niveau de son PAN, à savoir le passer en mode caché. Du coup, son Commlink émet en Signal 3 (portée 400m) pour rester potentiellement en communication avec le reste de son équipe et ses autres équipements fonctionnent en Signal 0 (4m). Le hacker va pouvoir dans ce cadre réaliser une action de "détection d'un node caché" pour obtenir l'access-ID du Commlink du streetsam. Avec cette information, il va pouvoir espionner les communications émanant du Commlink et éventuellement identifier les collègues du Streetsam si ce dernier tente de les appeler. Il va aussi connaitre l'access-ID du smartgun si le streetsam lui transmet des instructions via ses trodes et son Commlink. Un petit hacking de smartgun et voilà le flingue du Streetsam qui ne fonctionne plus. Deuxième cas de figure : Le streetsam a bien basculer tous ses équipements sur Signal 0 et dispose en complément d'un programme ECCM et d'un détecteur d'onde radio. Dans ce cas, le hacker ne pourra rien faire du tout au niveau matriciel car sa tentative de "détection d'un node caché" va échouer (comme le rappelait Blade, le node recherché doit être à porté réciproque de Signal). Il peut à la rigueur tenter de profiter du faible signal du PAN adverse pour le brouiller (ca ne détraquera pas complètement le smartgun mais le streetsam perd au moins le bonus qu'il procure) mais il ne peut savoir que sa tentative échoue en raison du programme ECCM. Pire, le streetsam va pouvoir localiser physiquement la source d'émission du brouillage à l'aide de son détecteur d'onde radio et saura où se cache le hacker.
Pour bien comprendre les tenants et les aboutissants de la guerre électronique, il faut aussi comprendre les finesses de la sécurité matricielle.
[la suite à venir]
Souscriptions et privilèges de comptes :
Unwired développe le principe des comptes et les droits classiquement associés à chacun des 4 niveaux de compte (voir Unwired page 52). Ca peut être important de savoir ce que permet chaque type de compte car cela détermine pour un hacker la complexité de sa tentative de hacking suivant ce qu'il désire pouvoir faire une fois introduit dans le node (Le seuils du test est augmenté de +3 et +6 pour les comptes sécurité et admin, voir SR4 page 221). Il faut rappeler que si le hacker est repéré et qu'une alerte est émise à son encontre, son compte est automatiquement rétrogradé au niveau d'un compte utilisateur classique (ca peut arriver s'il est trop gourmant et se fait repérer alors qu'il cherche à obtenir un compte admin).
Au niveau sécurité, il suffit de restreindre au maximum ce que peut faire les comptes utilisateurs, voir les comptes sécurité (par définition un admin peut tout faire ou presque), et d'avoir un bon Firewall et un bon programme Analyse vu que c'est ce qui est utilisé pour repérer les tentatives de hacking.
Liaison Slave/Master
Détection d'un node caché
Interception de communication
Le brouillage
Equipements de guerre électronique |
|
| 09-02-2009 23:02:54 | #4 | | Valérian | Je me pose encore quelques questions sur certains aspects de sécurité matricielle et je voudrais savoir comment vous voyez les choses :
Pour détecter une tentative d'intrusion par un hacker, un node doit faire un ou plusieurs jets de Firewall+Analyse, c'est d'ailleurs préciser dans Unwired (page 74) qu'un node peut faire tourner Analyse pour cela. Jusque là ca va.
J'avais penser à un moment améliorer cette protection avec une IC faisant tourner un Autosoft "homeground" (Unwired page 113) et un programme Analyse, mais en relisant la description de l'autosoft, il est dit qu'il donne un bonus aux tests de perception matricielle, or je ne suis pas sur que le test gratuit de détection d'une tentative de hacking soit un test de perception matricielle.
Du coup, cet autosoft doit probablement servir aux IC de patrouille mais j'ai pas trop compris quand une telle IC intervenait concrètement ?
Elle scan automatiquement les nouveaux entrant sur le node, ce qui suppose un test de Pilot+Analyse+(homeground) contre un jet de Hacking+stealth et si elle l'emporte elle déclenche une alerte, c'est ca ?
Il est dit à moment que l'on ne peut agir au niveau matriciel que sur ce que l'on voit (voir Unwired page 53), d'où l'utilité du programme Analyse. Dans le node de son propre Commlink, une personna pourra coexister avec un certain nombre d'IC, aussi je me demande s'il faut qu'il fasse tous tourner une version du programme Analyse (personna comme IC) ou bien il suffit que le programme tourne au niveau de l'OS (ce qui sert à la base à protéger des tentatives de hacking vu plus haut) car les différents construct bénéficient d'une vision partagée ?
Dans le même ordre d'idée, est-ce que l'on peut confier la perception à une IC avec l'autosoft Homeground pour qu'il la partage ensuite ? |
|
| 10-02-2009 09:32:15 | #5 | | okhin | Quand tu rentre illégalement sur un node, il y a une chance que tu lèves une alerte de sécurité, c'est à ça que sert le jet de Firewall + Analyse (et ce n'est donc pas une IC qui s'en occupe, c'ets le rôle de ton Firewall). Une fois qu'une Alerte est levée, les IC se mettent à agir.
Et elles font donc un jet d'Analyse contre la discrétion du hacker pour le détecter.
Pour la question de la visibilité, tu vois par défaut tout ce qui a le droit de tourner sur un comlink et qui n'est pas caché par Stealth. Un peu comme quand tu rentres dans un immeuble de bureau, tu vois tous les mecs qui y bossent mais pas le système de sécurité qui est caché dans les murs par exemple.
Quand au partage de programme, il est précisé chépluoù dans Unwired qu'un node peut mettre à dispo de ses utilisateurs un certains nombre de programme résidents.
ET non, je ne pense pas qu'un drone puisse utiliser un autosoft d'agent/IC, ni percevoir dans la matrice.
Okhin |
|
| 10-02-2009 10:36:35 | #6 | | Blade | Quand bien même un hacker a réussi à rentrer sans lever d'alerte, il reste des CI qui patrouillent. Et ces CI peuvent aussi décider d'analyser les icones du noeud. Ca peut se faire systématiquement à l'entrée du node (mais ce sera pas facile en cas de grosse affluence), lors de l'utilisation de certaines commandes, complètement aléatoirement ou sur demande/programmatiquement (bref, comme les antivirus aujourd'hui vont scanner les fichiers).
A noter aussi que le programme Stealth ne rend pas une icône invisible : elle la fait passer pour ce qu'elle n'est pas. L'icône d'un hacker passera par exemple pour un paquet de données aux yeux du Sysop et des CI. Je sais plus trop si le niveau d'accréditation joue sur ce qui est visible ou pas, mais je crois qu'on en parle dans Unwired.
Effectivement un drone ne peut pas percevoir dans la matrice, mais son pilote peut, tout comme il est possible de faire tourner des CI sur son node. |
|
| 10-02-2009 11:30:43 | #7 | | Valérian | Blade a écrit:
Quand bien même un hacker a réussi à rentrer sans lever d'alerte, il reste des CI qui patrouillent. Et ces CI peuvent aussi décider d'analyser les icones du noeud. Ca peut se faire systématiquement à l'entrée du node (mais ce sera pas facile en cas de grosse affluence), lors de l'utilisation de certaines commandes, complètement aléatoirement ou sur demande/programmatiquement (bref, comme les antivirus aujourd'hui vont scanner les fichiers).
La patrouille de CI correspond bien à cela, mais d'un point de vue règles, je ne pense pas qu'il faille détailler à ce point le fonctionnement d'une CI, donc dans la pratique, on fait un jet unique de perception matricielle opposant l'IC de patrouille au hacker planqué par Stealth, je suppose ?
Dans tous les cas, ce test vient en complément du test de Firewall+Analyse réalisé par le firewall comme le rappel Okhin.
Blade a écrit:
Effectivement un drone ne peut pas percevoir dans la matrice, mais son pilote peut, tout comme il est possible de faire tourner des CI sur son node.
Oups, j'ai parlé de drone en pensant à une CI en fait. J'ai réécris la question comme il faut. En fait, je voulais savoir si on peut fonctionner de la manière suivante pour son Commlink :
1- Le node fait tourner le programme Analyse pour compléter le Firewall (ca c'est quasi systématique).
2- Ce programme Analyse sera aussi à disposition de la personna et des CI pour percevoir les icônes cachées par le programme Stealth, sans que chaque construct soit obligé de faire tourner sa propre version d'analyse (c'est là où j'ai un doute car ca va à l'encontre du principe qui vaut que chaque construct ait ses propres programmes).
Dans l'idée inverse, il est dit qu'une personna peut amener avec elle des agents lorsqu'elle se connecte à un node. Si c'est fait dans le cadre d'un hacking, est-ce qu'il faut que la personna et chaque agent ait son propre programme Stealth (parce que si la personna reste dissimulée mais que son agent se fait repéré avec une cargaison de programme de combat, ca va donner la puce à l'oreille au système attaqué) ?
J'aurai tendance à répondre à la dernière question qu'il faut effectivement planquer ses agents autant que soit même (donc Stealth pour tout le monde). A ce moment là, sachant qu'un construct ne peut agir sur une icône dissimulée par Stealth, les CI ne seront pas en mesure d'attaquer les agents ou la personna si elles échouent à leur test de perception matricielle. En y réfléchissant ca commence à faire beaucoup de tests qui compliquent la chose... aussi est-ce qu'il n'est pas plus simple de se dire qu'un programme stealth perd son effet lorsqu'une alerte est émise et que l'on rentre dans un combat matriciel où tout le monde voit tout le monde ? |
|
| 10-02-2009 11:48:29 | #8 | | Blade | En fait l'intérêt de détailler le fonctionnement d'une CI, c'est surtout pour jouer les scènes matricielles de manière un poil plus intéressante qu'une suite de jets de dés. Donc tout comme on ne va pas faire faire un jet de perception global pour des gardes de sécurité dans un bâtiment infiltré par des runners, on fera pas forcément faire un jet de perception matriciel global pour les CI d'un nœud.
Pour ta deuxième question, la FAQ donne ses réponses les plus cryptiques sur le sujet... Et j'ai pas souvenir de trucs à ce sujet sur Unwired (mais y'a peut-être quelque chose dessus quand même). Faudrait chercher la référence à ce dont parle Okhin (les programmes résidents). |
|
| 10-02-2009 12:02:58 | #9 | | okhin | Alors:
"Unwired, page 48 a écrit:
They run programs, store data, accept connections, and run personas and agents.
Déjà, un node peut faire tourner un programme pour son compte, sans qu'il soit embarquer dans une personna/agent. Ensuite, en continuant sur les nodes (page 51) on tombe sur:
For example, the OS can be instructed to launch IC, trigger an alarm, or send a message when certain conditions are met.
Donc, c'est l'OS du node qui gère la stratégie globale et qui enverra les IC, les traces et ce genre de choses. Et pour finir, page 52:
Programs are the tools of the Matrix. Every time something is done, a program is involved. Sometimes only a very small program is needed, and those instances are not covered by the rules—but it’s still a program doing the work. Programs are always run by nodes. The maximum number of programs a node can handle is called its processor limit, while the number it is actually running is the processor load. If the processor load exceeds the processor limit, the node is subject to Response degradation (see Matrix Attributes, p. 212, SR4). Programs do not have to be run by the persona’s node to be used by a persona. It is possible to use programs run on the remote node a persona is accessing. The remotely used program then counts towards the processor load of the remote node instead of the node running the persona. Public nexi like libraries, archives, and data havens often provide remote browse programs.
Donc, un OS peut fournir une panoplie d'utilitaire. Donc oui, tu peux avoir ton Analyse sur ton node qui sera utilisé par l'IC. D'ailleurs, de mon point de vue, la seule reaison d'embarquer un programme dans une IC, c'est pour protéger celle-ci (son programme n'étant pas accessible en lecture par tout le monde, il devient difficile de le planter et de désarmer l'IC).
Donc, il y a deux écoles pour les IC. Soit tout est sur le node (et donc on augmente le processor load du node, pas celui du persona, mais du coup tant que tu es en lien avec ton node, tu en profite) et donc n'importe qui plante le programme de Trace de l'IC et celle-ci ne peut plus tracer, mais elle mange moins d'espace (juste 1 slot pour le soft d'IC), soit tu charge l'IC ras la tronche et elle devient un peu plus "solide" et portable, mais elle plombe les noeuds sur lesquel elle agit (si tu as deux IC avec Trace, le Trace doit être chargé deux fois, ce qui est faisable si le Copy Protect est viré).
Okhin |
|
| 11-02-2009 23:50:33 | #10 | | Valérian | Programs do not have to be run by the persona’s node to be used by a persona. It is possible to use programs run on the remote node a persona is accessing. The remotely used program then counts towards the processor load of the remote node instead of the node running the persona. Public nexi like libraries, archives, and data havens often provide remote browse programs.
Je ne pense pas que cette règle annule la règle qui dit que chaque construct doit avoir sa propre exécution de chaque programme, juste que l'exécution du programme peut tourner sur le noeud contacté et non sur le noeud de départ de la personna.
Si on prend l'exemple d'un Nexus pour une bibliothèque online, il peut mettre à disposition un programme Browse à ses utilisateurs (c'est d'ailleurs l'exemple indiqué). Chaque utilisateur qui se connecte à distance à la librairie peut lancer le programme Browse sur le nexus, mais du coup ce programme tournera en plusieurs exemplaires sur le nexus et augmentera en conséquence le "Processor load".
Au final, il y a le même nombre de programme qui tourne que lorsqu'on affecte une exécution du programme à chaque Personna/Agent, mais c'est jusqu'ils ne sont pas hébergé par les mêmes nodes dans les 2 cas. |
|
| 12-02-2009 14:04:13 | #11 | | Valérian | La question "matrice" du jour.
Il est dit dans SR4, dans le paragraphe sur les agents qu'ils ont leur propre "built-in firewall" égal au niveau de l'agent. Toutefois le node qui héberge l'agent a lui aussi un Firewall. La question est donc de savoir si le Firewall de l'agent remplace le Firewall du node dans tous les cas où s'il faut voir en fonction de la situation ?
Je suppose que le Firewall de l'agent est utilisé pour résister à une falsification d'ordre, non ?
Maintenant au niveau du combat matriciel, un agent se défend par un jet de Réponse+Firewall. Est-ce que l'on prend son indice de Firewall a lui ou bien l'indice du node ou bien ca peut dépendre ?
Sous cas N°1 : si le node est passé en alerte, il reçoit un bonus de +4 à son Firewall. Est-ce que ce bonus s'ajoute au jet de défense en combat matriciel, et si oui pour la personna contrôlant le node aussi bien que les agents ?
Sous-cas N°2 : un agent peut être chargé dans une personna pour l'emmener avec elle sur d'autres nodes. l'agent utilise toujours son Firewall a lui dans ce cas, ou bien il utilise celui de la personna lequelle correspond à celui du node ? |
|
| 12-02-2009 14:21:02 | #12 | | okhin | L'agent utilise son Firewall dans tous les cas (enfin, si il est inférieur ou égal au Système du node sur lequel il tourne). Il récupère les attributs hardware des nœuds parce qu'il n'est pas hardware. par contre, tous les attributs Software (donc, Système et Firewall) sont ceux de l'agent. Qu'il soit dans un serveur, un node, un persona, un tag RFID ou hors ligne.
Du moins, c'est comme ça que je le voit.
Okhin |
|
| 12-02-2009 14:23:20 | #13 | | Blade | Comme Okhin |
|
| 12-02-2009 17:46:22 | #14 | | Valérian | A oui, c'est juste, j'avais oublié que le Firewall est considéré comme du software.
Et au niveau du combat matriciel, Vous êtes d'accord pour que le bonus d'alerte de +4 s'appliquent à tous les Firewall dans tous les cas ? |
|
| 12-02-2009 17:51:39 | #15 | | okhin | Euh non.
Et puis quoi encore? Celui du noeud oui, ce qui complique toutes les actions visant le noeud. Pour le reste non, il y a déjà une alerte de levée, donc la tâche va se compliquer sérieusement pour le hacker avec un débarquement d'IC, de spiders et d'autres mesures déplaisantes de ce genre là.
Okhin |
|
| 12-02-2009 18:28:35 | #16 | | Valérian | Ah oui, c'est effectivement précisé que ca booste uniquement le Firewall du node (donc les agents peuvent se gratter), mais dans ce cas, le +4 profite quand même à la personna hébergée par le node pour le combat matriciel.
SR4 p 211 : Your persona’s Firewall, Response, Signal, and System attributes are equal to the device and OS you are using to access the Matrix. Attacks made against your persona affect the device/ OS, though Black IC programs affect the actual user directly.
. |
|
| 12-02-2009 23:06:12 | #17 | | Valérian | Bordel, j'ai une "Internal system error" quand je veux éditer mon post où j'ai commencé mes explications.
Privilèges de comptes :
Unwired développe le principe des comptes et les droits classiquement associés à chacun des 4 niveaux de compte (voir Unwired page 52). Ca peut être important de savoir ce que permet chaque type de compte car cela détermine pour un hacker la complexité de sa tentative de hacking suivant ce qu'il désire pouvoir faire une fois introduit dans le node (Le seuils du test est augmenté de +3 et +6 pour les comptes sécurité et admin, voir SR4 page 221). Il faut rappeler que si le hacker est repéré et qu'une alerte est émise à son encontre, son compte est automatiquement rétrogradé au niveau d'un compte utilisateur classique (ca peut arriver s'il est trop gourmant et se fait repérer alors qu'il cherche à obtenir un compte admin).
Au niveau sécurité de son Commlink et/ou son PAN, il est conseillé de restreindre au maximum ce que peut faire les comptes utilisateurs, voir les comptes sécurité (par définition un admin peut tout faire ou presque donc ce niveau là, on ne peut le restreindre... ca tombe bien c'est le votre). Ainsi avec un bon Firewall et un bon programme Analyse, vous devriez repérer un hacker au moment où il tente de pénétrer dans votre Commlink et vous pourrez l'accueillir comme il se doit à coup d'IC.
Souscription et liaison Slave/Master :
Si vous avez des systèmes sensibles (smartgun, drones...) dans votre PAN et que vous voulez prévenir au maximum les risques de hacking matriciel, vous pouvez instaurer une liaison Slave/Master entre certains équipements et votre Commlink (voir Unwired page 55).
Niveau Sécurité, l'équipement esclave transfert toute tentative de connexion qui lui est envoyée vers le node maître, lequel est généralement mieux protéger au niveau matriciel (voir le paragraphe précédent sur les privilèges de compte pour l'aspect sécurité matricielle).
Grâce à ca, un rigger peut rester connecter à ses drones via la matrice et les commander (que ce soit par une commande simple, un contrôle à distance ou en plongeant dedans) tout en empêchant toute tentative de hacking de l'un d'entre eux (le hacker doit déjà passer par votre Commlink qui doit être protégé comme il se doit).
Une liaison slave/master nécessite que vous soyez administrateur sur les 2 nodes et que vous mettiez un place une souscription. Comme une personna peut maintenir jusqu'à 2 x Système souscription à un instant donné, ca fait déjà un paquet de drones possibles avec un bon Commlink. Si ca ne vous suffit toujours pas, vous pouvez allez au delà mais les souscriptions compte comme un programme vis à vis de la règle de diminution de la Réponse de votre Commlink (voir Unwired page 55).
Si vous ne souhaitez pas garder un oeil sur un drone ni le commander mais plutôt le laisser seul, vous devez couper la liaison Slave/Master. Théoriquement, votre drone ne sera alors plus sécurisé par votre commlink, aussi le plus simple est de terminer la connexion en lui donnant l'ordre de couper son accès wireless (en fait c'est lui qui vous recontactera s'il en a besoin).
Pour information, une souscription se met en place avec une action "log on" qui prend une action complexe et se termine avec une action "log off" qui prend une action simple et reste active tout du long entre ces 2 actions. |
|
| 13-02-2009 01:03:40 | #18 | | Valérian | Détection d'un node caché
Aucun shadowrunner ne se lancerait dans une opération sans avoir basculer au préalable ses nodes en mode caché afin de les rendre plus difficilement détectable. Dès lors, il devient important de pouvoir détecter les nodes cachés si on souhaite pouvoir agir au niveau matriciel contre les systèmes des types qui pourraient se dresser sur notre route.
Pour pouvoir détecter un node wireless en mode caché, il faut être à portée de son Signal afin de pouvoir repérer ses éventuels émissions radio (en effet, un node n'est jamais complètement « muet » dans la matrice). Si ce pré-requis est rempli, on doit réussir alors un test d'Electronic warfare+scan contre un seuil de 4 si on connait au préalable l'access-ID du node caché. Si ce test est réussi on obtient la certitude que le node est à proximité physiquement (on obtient la valeur de son Signal).
Si on ne connait pas l'Access-ID recherchée (cas le plus fréquent), il faut essayer de l'identifier au milieu de toute la liste des nodes en mode caché. On fait alors un test étendu d'Electronic warfare+Scan contre un seuil de 15, avec un intervalle d'un tour de combat. Si ce test est réussi on obtient l'Access-ID et la valeur de Signal de toutes les nodes wireless cachés.
Pour éviter la détection lorsque l'on opère avec des nodes wireless en mode caché, il faut utiliser un score de Signal le plus faible possible. Par exemple, on peut commander ses équipements individuels avec un Signal de 0 (portée 4m) vu qu'on les porte sur soi, mais si on désire rester en communication avec ses coéquipiers il faudra probablement imposer un score de Signal plus élevé à son Commlink.
Au niveau équipement, il est possible d'utiliser des émetteurs radio utilisant des fréquences non réservées aux communications matricielles (voir Unwired page 196). |
|
| 14-02-2009 00:58:17 | #19 | | Valérian | Interception de communication wireless
Autre aspect relatif à la guerre électronique : l'interception de communication.
Le sixième monde est devenu « Wireless », ce qui fait qu'un grand nombre de flux de communication voyage de node en node à travers les airs. Pour pouvoir intercepter une communication au milieu de tout ce flux de données, il faut donc savoir ce que l'on cherche, et concrètement cela suppose de connaître l'access-ID du node à espionner.
Niveau règles, l'interception de communication wireless consiste à intercepter les flux entrant et sortant d'un node à condition de pouvoir capter ses signaux. Pour une communication sortante, il faut être à porté de Signal du node et pour une communication rentrante, être à portée de Signal de l'émetteur.
Si les pré-requis en matière d'access-ID et de Signal sont remplis, il faut encore réussir un jet d'Electronic warfare+sniffer contre un seuil de 3. A ce stade, il est possible d'enregistrer voir même d'éditer le contenu de la communication (ce deuxième cas nécessite d'avoir un propre Signal plus fort que le signal d'origine). L'interception révèle aussi l'access-ID ou le Commcode des nodes/personnes impliquées dans la communication et pour finir la puissance de Signal des communications interceptées (révèle la distance qui vous sépare de l'émetteur).
A noter que si la communication est cryptée (ce qui est souvent le cas), il faut casser le cryptage de la communication avant de faire le jet d'interception de communication.
L'usage d'un détecteur d'onde radio permet de remplacer le programme sniffer (voir SR4 page 326). Le fait d'avoir une antenne plus adaptée à la détection qu'une antenne classique permet de définir la direction d'où provient le signal et estimer sa distance pour ainsi localiser physiquement l'émetteur.
Niveau sécurité, il n'est pas toujours facile de se prémunir contre l'interception d'un signal wireless. Là encore, il faut savoir garder un Signal le plus faible possible pour limiter la zone couverte par les émissions (si le hacker est à l'extérieur, il ne pourra rien contre vous). Ensuite au niveau équipement, il est possible d'utiliser des émetteurs directionnels qu'ils soient radio ou à faisceau laser (voir Unwired page 199).
Le brouillage
Pour clore ce chapitre sur la guerre électronique un mot sur le brouillage : par principe les règles canon disent qu'un brouilleur a un score de Signal qui s'affaiblit avec la distance, or pour que le brouillage face effet sur un node, son score de signal doit rester supérieur strictement au score de Signal du node (voir SR4 page 320).
Pour brouiller un Commlink standard de niveau 3, il faut un brouilleur omnidirectionnel de Signal 4, or c'est le score maximum possible à la création compte tenu de la Disponibilité du brouilleur omnidirectionnel. Concrètement, cela veut dire qu'un tel brouilleur ne sera efficace que les 5 premières mètres autour de lui... après le Signal devient trop faible pour brouiller.
Personnellement, je ne trouve pas ca satisfaisant car le brouillage doit rester un élément important de la guerre électronique, aussi je vois 2 solutions pour tenter d'améliorer le problème (mais on passe dans l'alter) :
La solution la plus compliquée consiste à considérer que le signal d'un node diminue lui aussi avec la distance (par exemple pour un Signal de 3, portée 400m, le signal va en faite diminuer de 1 tous les 133 m), ce qui rend les communications longue distance plus facile à brouiller au niveau du récepteur. Toutefois ca complique sensiblement la donne car il faut connaître la distance entre 2 nodes pour savoir quel est Signal réellement réceptionnée (2 nodes avec Signal 3, distant de 250 mètres communiquent avec un signal qui n'a plus qu'une puissance de 2 à l'arrivée).
La solution la plus simple est moins « réaliste », et consiste à transformer les brouilleurs en équipements émettant un Signal en un seul pallier (ainsi un brouilleur omnidirectionnel de niveau 4 émet un Signal de brouillage de 4 jusqu'à une distance maximum de 4 et après plus rien).
Au niveau sécurité, pour se prémunir du brouillage il faut soit avoir des nodes qui ont une réserve de puissance au niveau du Signal, soit utiliser un programme ECCM (voir SR4 page 225). |
|