Matrice, WAN, connection directe et cohérence du monde 39

On est passé à SR5 il y a pas longtemps et on a un petit problème entre les règles matricielles et la cohérence du monde : enfin si on a bien tout compris...

Donc prenons pour exemple un hacker qui veut hacker la GRIDGuide (déjà avant SR5 c'était entre méga tendu et quasi impossible au hacker lambda), mais ce petit malin ne va pas l'attaquer directement en sans fil (donc en attaquant le serveur directement) mais en se connectant à un répartiteur/panneau de signalisation/feu rouge et en se branchant en direct. Là tout devient beaucoup plus simple, vu que "si un appareil esclave est attaqué par connexion directe (par le biais d’un connecteur universel, par exemple), toutefois, il ne peut pas utiliser les indices de son maître pour se défendre", donc le jet de défense se fait avec Intuition/Volonté+indice d'appareil (et encore on considère qu'il est entretenu et mis à jour pour bénéficier de la carac) et vu la table p236 on tourne sur un indice d'appareil de 3 (on est loin du standard des caracs de la GRIDGuide).

Donc :

1) le répartiteur/panneau de signalisation/feu rouge est intégré au WAN et dès qu'on pose une mark dessus on a une mark sur la GRIDGuide qui est propriétaire

2) il n'est pas intégré à un WAN et reçoit des ordre de la GRIDGuide mais ça veut dire qu'il est hackable par le 1er venu en sans fil

Ce qui d'un point de vue cohérence on a le choix entre surprotéger physiquement le moindre objet relié à la matrice ou le laisser hors d'un WAN et là n'importe qui peut le hacker sans difficulté... Dans les deux cas ça change le monde (enfin notre vision du monde), on peut pas mettre une zéro zone à chaque caméra et sans être dans un WAN c'est le gros bordel et les caméras ne servent plus à rien vu qu'elles sont hackablent en sans fil. D'autant qu'en SR4 un bon système de sécurité était câblé sans accès sans fil. Si on veut garder la cohérence la seule solution (si notre raisonnement est bon) serait de ne pas appliquer la règle sur la connexion directe et de laisser l'appareil se défendre avec le Firewall du WAN.

Comment gérez-vous ça à vos tables ? Merci.

Hello à toi.

J'espère que je ne vais pas te dire une connerie mais voilà comment je fonctionne :

Déjà, pas besoin d'avoir des indices de fou au niveau des appareils pour que la protection soit balèze. Comme le WAN permet de prendre le meilleur des Firewall entre l'appareil et le serveur, et que tu peux utiliser l'Indice de Logique si le Spider fait bien son boulot et n'est pas débile, finalement, tu ne fais pas Indice d'Appareil x2 mais bien Logique du Spider + Firewall du Serveur. Ca a tout de suite une autre gueule.

Pour les Marks effectivement, quand tu poses une Mark sur un Esclave son Maitre s'en prend une. Une question subsidiaire est est-ce que ça marche pour chaque Mark posée sur un appareil (genre je pose 3 Marks sur une caméra, j'en ai donc 3 sur le serveur) ?. Mais quoi qu'il en soit, vu déjà que ça devient balèze de pirater un appareil, finalement le serveur ... L'autre point c'est que même si tu as des Marks, ça ne te fait pas pour autant tout faire. Juste tu étends tes possibilités en répondant au préalable du nombre de Marks. Le "vrai" boulot commence après !

Après pour ton problème spécifique de piratage en connexion directe, pour moi, c'est uniquement entre le hacker et l'appareil, en gros c'est donc super facile de pirater le feu rouge car tu évites les stats du serveur (et du spider) et à mon sens aussi la question du Maitre/Esclave et des Marks par rebond vu que tu es en connexion directe avec l'appareil et seulement lui. Ca limite donc seulement au feu rouge ... pas de quoi révolutionner le hacking quoi, la GRIDGuide reste donc sauve.

Enfin c'est comme ça que je fonctionne et que j'ai compris les règles.

C'est justement sur ce point de connexion directe et WAN que ça coince, il est clairement écrit (SR5 p234) que "si une mark est placée sur l’appareil esclave, le maître sera également marké". Nous on a compris tu mets une mark sur l'appareil, tu en as une sur le serveur et tu peux l'utiliser pour le pirater.

Oui mais les Marks ne sont vraiment qu'un préalable et ne font vraiment mais vraiment pas tout !

Je ne crois pas que ça soit décrit dans le bouquin, mais le grid n'est sans doute pas monolithique.

Tu n'as qu'a considérer que le feu rouge est branché sur un serveur distribué sur lequel tu pourras facilement poser une marque avec connexion directe, par contre, une fois la marque posée les problèmes commencent car ça va devenir compliqué d'attaquer le serveur comme évoqué plus haut.

En revanche, tu n'auras sans doute pas accès à tout le grid comme ça, mais peut être juste à une portion de route ou juste à la signalisation.

D'un autre côté, se brancher en direct sur un élément du grid, ça peut assez facilement éveiller l'attention, même si c'est pas très dur de le faire discrètement.

Marker et hacker, ce sont deux choses subtilement différentes, comme indiqué par Slevin.

En fait prendre le controle de la GridGuide peut etre assez facile, dans la mesure ou on se branche physiquement sur un element de la GridGuide (et en pleine rue grimper sur un poteau, bonjour la discretion ), mais vite les desagrements physiques que ca va entrainer ( accident, bouchon ), vont attirer l'attention. Donc avec les regles, oui on peut prendre le controle de bcp de chose, mais on peut aussi rapidement attirer sur soi les foudres des services de securites!

Non, on ne peut pas prendre facilement le contrôle du GridGuide, on peut facilement le marker. Le contrôler va demander d'entrer dans un serveur au moins et d'y réussir certains tests contre ses stats, ce qui sera une autre paire de manches.

On peut prendre le contrôle d'un élément du GridGuide facilement pour peu qu'on s'y connecte directement en filaire, ce qui limite la portée de la nuisance : trafiquer un feu, oui, contrôler tous les feux d'un quartier, bonne chance.

J'ai mis "peut etre assez facile"! Je voulais juste faire remarquer que meme à reussir "parfaitement" et ce ,malgres les stat fumees du serveur ( 2 fois son niveau ), les services de securité remarquerait bien vite un probleme.

Je voulais aussi/surtout préciser mon précédent post, un peu laconique (faute de temps)

Si on prends une vision plus réaliste du monde, et en considérant que les périphériques sont rarement aussi bien sécurisés que les serveurs auxquels ils sont connectés, l'idée que hacker un périphérique permette de faciliter le hack d'un serveur ne me semble pas complètement folle. C'est même assez réaliste, étant donné que le périphérique a bien souvent un lien privilégié avec son serveur.

Dans le monde réel, de telles attaques sont tout à fait réaliste (cf. cet article de Matthew Garrett, l'un des core developper su kernel Linux). Il ne faut pas croire que les corpos soient mieux protégé (il y a quelques années, si vous étiez capable de rentrer sur une box ADSL de certains fabricants, vous pouviez vous promener sur le réseau opérateur jusqu'à atteindre certains switchs manageables). Je ne doute pas que dans certaines sociétés, les caméras IP (fonctionnant avec un OS complexe) qui sont un peu partout dans et autour du bâtiment sont directement reliée à un serveur, sans sécurité spécifique, qui peut ensuite servir de machine de rebond pour compromettre l'intégralité du réseau de l'entreprise.

Les histoires de piratage d'entreprises sont nombreuses, et bien des fois, ça passe hélas par un trou béant de sécurité. Dans le principe, même quand on traite le problème correctement, security is hard. Et bien souvent, y compris dans les grosses entreprises, le problème n'est pas traité correctement.

On peut imaginer qu'en 2072 quand même la sécu dans les grosses boite aie progressé un peu !

Mais pas plus tard qu'il y a 15 jours une grosse attaque contre des serveur DNS a eu lieu, les pirates se sont servis de caméras IP, montres connectées et autres frigos connectés, des appareils pour lesquelles la sécurité est encore quasi inexistante !

Alors, juste si je puis me permettre, personne ne répond vraiment à la question de Julien1001 [enfin je dis ça, sauf si le fait de ne pas infirmer est une confirmation que ce que je disais était vrai], ça question m'intéresse aussi donc j'en profite:

Quand on pose une Mark sur un appareil d'un WAN, est-ce que cela en pose un automatiquement aussi sur le serveur même si [et c'est surtout ça la question] le branchement se fait en filaire ?

Je rajoute aussi ma question, est-ce que ça pose à chaque fois une mark sur le serveur, ou on en obtient juste une sur le serveur (genre si je pose 3 Marks sur un Esclave, est-ce que j'ai 1 ou 3 Marks sur le serveur, on pourrait même imaginer la question pour 1 Mark sur 3 appareils d'un même serveur qui donne 1 ou 3 Marks sur le serveur] ?

J'espère, mais comme je l'ai dit, security is hard, et il y a de bonnes chances que des tonnes et des tonnes d'attaques auxquelles on ne pense pas à l'heure actuelle soit possible plus tard.

Par exemple, jusqu'à présent, on pensait que RowHammer (une attaque sur le hardware et sur le fait que les mémoires actuelles peuvent être assommée pour provoquer un flip de bits à un endroit spécifique en mémoire) ne pouvait être utiliser efficacement que sur certaines machines Intel (avec de la RAM sans support ECC ; bon, ça veut dire tous les PC de bureau et certains serveurs bas de gamme).

Bon, il semblerait que de nombreux téléphones soient attaquables.

La crypto qu'on utilise aujourd'hui pourrait ne pas résister aux prochaines décennies ; il n'est pas dit qu'une nouvelle méthode, acceptable en termes de coût, puisse être mise au point (la crypto quantique, c'est pas simple à gérer). Du coup, la sécurité dans 60 ans (ne pas oublier les bouleversements du monde qui pourraient lui avoir fait prendre 10 ou 20 ans de retard par rapport à la vitesse actuelle des changements) pourrait n'être qu'à peine plus évoluée que maintenant, d'autant plus que les corpos se sentiraient rassurés par des firewall intelligent, des IA de contre-mesure, etc. et pourraient négliger certaines failles plus basiques (vous avez déjà parlé avec le DSI d'une grosse boite ?).

ça a été évoqué mais les serveurs n'ont pas une structure en grappe ? un serveur qui regroupe des appareils dans sa zone, genre le paté de maison, est lui même relié au serveur du quartier, lui même relié au serveur de la ville etc ... dans ce cas, pirater le feu ne donne accès qu'au serveur immédiatement supérieur dans la hiérarchie...utile mais pas ultra puissant comme de pouvoir "marker" le serveur central (qui lui doit être checké en permanence par un spider pour vérifier les marks eventuellement frauduleuses)

@Slevin : merci d'avoir recentrer le débat Donc effectivement poser une mark et kacher le serveur ce n'est pas la même chose. Même si c'est déjà la première pierre. Surtout que ça permet de faire à l'intérieur du serveur des actions légales (sans utiliser attaque ou corruption) comme faire une recherche, éditer un fichier... D'après vous, en prenant l'hypothèse que le feu rouge est en WAN direct (donc pas de sous-serveur en grape) sur le serveur de la GRIDGuide, en se connectant sur le serveur un hacker peut-il par exemple rechercher la voiture d'une cible et ses déplacements sans faire monter son score de surveillance (à part les 2d6 toutes les 15 mn) ?

@invalys : en même temps si on considère que mettre une mark sur un esclave permet de mettre une mark sur le maître, est-ce que tout le monde ne se prend pas sa mark ? Et puis plus tu mets d'intermédiaire et plus tu dois les protéger physiquement (ce qui a un coût).

Alors pour moi ce que tu souhaites faire, se réalise indépendamment du faire de passer par "une faiblesse" (qui en fait n’en ait justement pas une dans SR5, sauf en filaire). Une fois dans le serveur, indépendamment donc du mode de connexion, il s’agit de trouver

soit une caméra (il s’agit dans de trouver son icone sur le serveur) et de visionner sa sauvegarde ou son flux pour voir si ça correspond à ce que tu souhaites,

soit de faire tourner un logiciel de reconnaissance faciale (ou équivalent) avec comme flux, plusieurs caméras.

Dans le premier cas, comme dans le deuxième, ça demandera des Marks sur les appareils (icones) mais les action d’Editer un Fichier n’étant pas soumis à l’augmentation du SS, ça ne pose effectivement pas de problème … pour ça, car il ne faut pas oublier les CI patrouilleuses sur le serveur, ni les spiders qui peuvent patrouiller eux aussi.

Mais c’est clairement casse-bonbons de devoir poser des Marks sur une 100ènes d’icônes si tu veux être large. A ma connaissance, les règles de Shadowrun ne permettent pas de faire des actions multiples identiques de ce genre. Donc il faut se les fader 1 à 1. A ma table, j’accepte l’action Contrôler un appareil sur le serveur (plusieurs Marks sont nécessaires en fonction de l’action) pour donner plusieurs ordres à toutes les caméras par exemple, mais ce n’est pas très canon, car les serveurs ne sont pas des appareils.

En fait je me dis que sur la GRIDGuide la position GPS des véhicules connectés est forcément quelque part, ça permet au système de gérer les flux, de pouvoir envoyer les infos aux véhicules... Donc pas besoin de trouver le véhicule par une caméra ou une reconnaissance de plaque, l'info est déjà disponible quelque part. Donc un jet de recherche de donnée devrait suffire.

Là où je trouve que ce n'est pas cohérent avec le monde c'est que faire ce type d'action dans les éditions précédentes était quasi impossible (aller attaquer le serveur de la GRIDGuide), alors que là ça devient possible au premier hacker venu. Et c'est un exemple parmi d'autres, se connecter au noeud sécurité d'une AAA via une caméra, aller farfouiller la base client de Doc Wagon en se connectant à du matos médical...

C'est curieux comme tu minimises l'opposition en face. Tu peux détailler les tests que tu ferais faire car je pense que tu loupes un truc.

• Admettons qu'en passant en filaire, tu puisses obtenir des Marks sur le serveur plus facilement (il faut donc faire des tests contre une opposition de INT du propriétaire + Indice de l'appareil, disons 1 ou 2 pour un feu rouge, donc 6 ou 7 en opposition avec un SS qui démarre donc).
• Après tu as disons le max de Mark sur le serveur (parce que même si on a pas de confirmation encore, admettons que tu obtiennes 1 Mark sur le serveur en même temps que ta Mark sur l'appareil), tu commences à faire ta recherche sur le serveur (pour cela tu dois t'y introduire, mais tu as les Marks pour, et il faut aussi, vu que maintenant tu dois t'y connecter via les ondes, que tu sois sur la même Grille si tu ne veux pas de malus)
• Puis tu lances ta recherche, délai 1 minute. 1 minute c'est 20 tours. Si le serveur est d'indice 7 ou 8 (l'indice pour les serveurs corporatistes locaux), une CI patrouilleuse scannera ton icône toutes les 2D6 tours. Donc en moyenne 3 à 4 fois. Donc disons 3 tests en opposition contre 2x l'indice du serveur, 14 ou 16 dés.
• Après tu as ton info et tu te tires fissa. Si tu foires un test en opposition tu te retrouves avec une alarme et des CI au trousse dans un serveur d'indice 7 ou 8 ...

Tout ça pour dire que je ne dirais pas que c'est si simple que ça...

[Finalement, j'ai détaillé moi ... ]

Ah oui y a le temps de recherche d'informations qui compte beaucoup ! On avait pas intégré ça encore (je masterise avec Julien)... on était resté aux temps de recherche de données de SR4, qui étaient quand même beaucoup plus rapides !!

Est-ce que des gens ont travaillé sur des protocoles de sécurité quelque part ? Genre à SS 10 il se passe ça, puis à SS20 autre chose... ?