Jump to content

Hacker Black Book - Matrixsicherheit


Corpheus
 Share

Recommended Posts

OK ... weil das Thema Matrixsicherheit in der 6. Edition noch sehr schwammig ist. Mit welchen Schwierigeiten müssen Hacker rechnen - welche Tricks wenden Konzerne an, um ihre Aktiva vor Hackern zu schützen.

 

Achtung: Die Matrixsicherheit der 6. Edi unterscheidet sich deutlich von der der 5. Edi. Die wichtigsten Punkte nach aktuellen Stand der Regeln:

  • Slaves: Sind quasi im PAN. Zugriff erst, wenn man das PAN gehackt hat/Zugriff auf das PAN hat. Das entspricht der Regelmechanik von Hosts. Dort kann man auf Icons im Host erst zugreifen (oder sehen), wenn man den Host gehackt hat/Zugang zum Host hat. Profitiert ein Slave im PAN/Icon im Host von den Werten des Masters/Hosts? Vermutlich ja (GRW s. 245).
  • Dementsprechend kann man interpretieren/vermuten, dass das direkte hacken eines Slaves zum einen einem Zugriff auf den Master/Host veschaffen kann. Zum anderen der Slave nicht mehr auf die Werte des Masters zurückgreifen kann und sich mit seinen eigenen Werten verteidigen muß. Das wird vermutlich erst in der Erweiterung thematisiert.
  • Es gibt in den Regeln keine Hinweise darauf, dass das hacken von Geräten, die als Slave in einem PAN/Host angelegt sind, nicht ganz normal dem Rauschen unterliegen. Das bedeutet, dass der Hacker daheim auf dem Sofa beim hacken eines virtuellen Host zwar keinem Rauschen unterliegt (aus dem Rauschen an seiner Position - Spamzone/Matrixloch), aber beim manipulieren von physischen Geräten Rauschen durch zb. Entferung/Wifi Abschirmungen berücksichtigen muß.

 

 

1.

Zuallererst stehen natürlich Hosts und eine hohe Hoststufe.

  • Hohe Werte in Stufe & Firewall erschweren den Zugang zu einem Host.
  • Verschachtelte Hosts erfordern das hacken mehrerer Host und damit eine multiple Schwierigkeit.
  • Manche Hosts sind nur zu bestimmten Zeiten online und zu erreichen.
  • Der Zugriff auf Icons und Geräte innerhalb eines Hosts ist von außerhalb nur im öffentlichen Bereich möglich.

Wie kann man als Hacker das umgehen? Vorrausgesetzt man folgt der Interpretation (siehe oben Master/Slave) kann man als Hacker vor Ort ein Gerät direkt hacken, das als Slave in einem Host angelegt ist. Dh. der Hacker muß mit dem Team vor Ort sein.

Ansonsten muss man mit den hohen Werten fertig werden.

 

 

2.

Ist der Hacker innerhalb eines Hosts, muß er mit evtl. vorhandenen Sicherheitsspinnen fertig werden. Oder quasi immer mit Patrouillen IC. Sobald man vom Patrouillen IC oder der Sicherheitsspinne entdeckt wurde startet das andere IC und es wird hart.

 

Aus dem Fluff der 5. Edi: Patrouillen IC ist immer in jedem Host aktiv. Sicherheitsspinnen sind nicht in jedem Host 24/7 aktiv. Viele kleine Hosts haben Verträge mit externen Sicherheitsdienstleistern, bei denen sich die Spinne erst bei einem Alarm in das System einloggt. Je wichtiger der Host, um so größer die Chance auf eine Spinne zu treffen.

 

Dagegen hilft Schleichfahrt. Das erschwert die Entdeckung eines Hackers. Und sollte der Hacker entdeckt sein, so kann er immer noch "Verstecken", so dass er erst wieder gefunden werden muß (was allerdings einen Alarm nicht verhindert...).

 

 

3.

GOD! Je mehr illegale Handlungen/Programme und je länger illegaler Zugriff umso schneller wird der Hacker von GODs Hammer getroffen.

 

Um davon nicht überrascht zu werden, ist es sinnvoll immer über seinen Overwatchwert informiert zu sein (Programm Babymonitor oder Handlung Overwatchwert bestimmen). Zudem kann die Edge-Handlung "Unterm Radar" das steigen des Overwatchwerts verhindern.

 

 

4.

Entfernung, Mauer/Buschwerk//Wasser und WiFi Abschirmung zwischen Hacker und Zielgerät/physischen Host verursachen hohe Rauschenwerte für den Hacker. Diese Rauschenwerte erschweren Proben gegen diese Geräte - im Idealfall verhindern sie die Manipulation komplett.

 

Hacker nutzen Programme wie Signalreiniger um Rauschen zu senken. Auch die Matrix-Edge Handlung "Signalschrei" kann Rauschen umgehen.

Oder sie brechen direkt ein und nützen Direktverbindungen per Kabel (GRW s. 270) - diese unterliegen ebenfalls nicht dem Rauschen.

 

30 Nächte & 3 Tage s. 143

"Die üblichen Regeln für Direktverbindungen und dadurch aufgehobenes Rauschen gelten nicht."

 

Achtung: Nicht alle Geräte sind Slaves und/oder in Hosts. Auch in diesen Fällen verhindert Rauschen sehr oft den Zugriff durch Hacker aus der Ferne.

 

 

5.

Pyhsische Speicherbänke oder Offline-Hosts für besonders wichtige Daten haben eines gemeinsam. Um Zugriff zu erhalten muß sich ein Hacker vor Ort physisch mit dem System verbinden.

 

Mit einem guten Team überwinden Hacker die physischen Sicherheitssysteme und verbinden sich vor Ort direkt mit dem System.

 

 

Soweit mein aktuelle Sichtweise zum hacken in der VR und den üblichen Sicherheitssystemen der 6. Edition.

 

  • Like 3
Link to comment
Share on other sites

Hi Corpheus! Danke für deine Zusammenfassung. Hilft mir als Neuling sehr.

Ein wesentlicher Knackpunkt stellt für mich seit Langem das Rauschen dar.

In der AR sind die Grenzen der Wahrnehmung/Bewegung mit denen der realen Welt gleich. Sprich: Ich kann nur hacken, was ich sehe (GRW 173).

Insbesondere in der VR, in der die Möglichkeiten der Bewegung/Wahrnehmung jedoch unbegrenzt sind (GRW 173), stellt sich zunächst  dieFrage, wo genau dann Rauschen ins Spiel kommen soll. Oder salopp formuliert: Wenn ich mich vom Sofa aus auf einen anderen Kontinent begeben kann, um dort Icons wahrzunehmen (was laut Regeln ja gehen soll), wo genau sollen dann Einschränkungen hinsichtlich Wahrnehmung ins Spiel kommen?

Hier scheint es so zu sein, dass die scheinbar "unbegrenzten Möglichkeiten der Bewegung/Wahrnehmung/usw." doch nicht ganz so unbegrenzt sind. Dieses "Grid Hopping" (gibt es in 6E ja nicht mehr) bzw. "Teleportieren zu einem anderen Ort" scheint in der VR eben doch zu Interferenz zu führen, die Rauschen erklären.

Aus diesem Grund scheint Rauschen somit durch (mindestens) drei Ursachen erklärbar:

  1. Entfernung des besuchten Icons zum Standort des Users/Hackers in der Matrix (betrifft, wie oben beschrieben, die Sichtweite in der AR bzw. sonstige Interferenzen in der VR). 
  2. Entfernung des WiFis zum Standort des Users/Hackers. Dies müsste hauptsächlich separate PANs betreffen. Das heißtd: Hacker -> PAN. Über WiFi angeschlossene Slaves eines PANs/Hosts dürften keinem Rauschen unterliegen, da  keine Regeln dafür existieren. Ich schließe daraus, dass lediglich die Entfernung Hacker -> WiFi zu Rauschen führt. Ist der Hacker in das PAN eingedrungen, unterliegen alle weiteren angeschlossenen Geräte demselben Rauschen wie das WiFi. Es gibt kein zusätzliches Rauschen (z. B. für Gerate, die weiter entfernt sind, als das Zentrum des PANs (Kommlink)).
  3. Abschirmung durch besondere Umstände (z. B. Störsender, Salzwasser, Laubwerk, usw.).

Sinnvollerweise müsste man zu dem Schluss kommen, dass in der VR ein geringeres Rauschen hinsichtlich einiger Einflüsse gilt als es in der AR der Fall ist (insb. hinsichtlich der beschriebenen AR-Einschränkhngen der Bewegung/Wahrnehmung - sprich: Sichtbegrenzungen), die sich offensichtlich primär auf die AR auswirken (z. B. Laubwerk, usw.,). Andernfalls erscheint es nicht einleuchtend, wieso die VR es zum einen möglich machen soll, "binnen eines Wimpernschlags die physischen Gesetze außer Kraft zu setzen" (GRW 173) und zum anderen der Wald vor der Haustür dann de facto doch dieselben Abzüge auf die Erreichbarkeit weit entfernter Icons in der VR gibt wie in der AR.

 

Ein Beispiel könnte hier sein: Während das 8 km weit entfernte Icon in der AR laut Rauschen-Tabelle (GRW 177) einen Abzug von -3 gibt, müsste dieser Abzug in der VR geringer ausfallen.

 
Oder verstehe ich hier etwas falsch? Wie seht ihr das?

Edited by jtkrk22
Link to comment
Share on other sites

Ich würde Vergleiche mit der AR nicht ins Spiel bringen. Das ist eine (Regel)Welt für sich - und verkompliziert die Sachlage unnötig.

 

 

Insbesondere in der VR, in der die Möglichkeiten der Bewegung/Wahrnehmung jedoch unbegrenzt sind (GRW 173), 

 

GRW s. 173

"Icons, deren Hosts deinem physischen Körper am nächsten sind, scheinen auch in der Matrix näher, weiter entfernte befinden sich außer Sicht deiner virtuellen Wahrnehmung."

 

Deine Persona/PAN muß sich durch die Matrix zu ihrem Ziel hin bewegen wenn es außerhalb deiner Sichtweite ist (in SR5 waren das 100 Meter).

Die Regeln sind hier (wie auch schon in SR5) schwammig. Es gilt die Entfernung deines Personagenerierendem Gerät (zb. Kommlink) zu dem Gerät in der phys. Welt.

Dh. während dein Körper auf dem Sofa gammelt, kann deine Persona das Icon der Ampel vor deinem Haus sehen. Das Icon der Ampel an der nächsten Kreuzung ist schon kleiner und leuchtet weniger und das Icon der Ampel an der übernächsten Kreuzung (zb. weiter als 100 Meter) siehst du schon nicht mehr. Um dieses Icon zu sehen, mußt du dich mit deiner Persona dort hin begeben. Vergleichbar mit Astraler Projektion - der phys. Körper bleibt am Ort... der Astralkörper wandert durch den Astralraum (wobei die Matrix im Gegensatz zum Astralraum keine Entsprechung zum phys. Raum hat).

 

In diesem Zusammenhang wird das (Entfernungs)Rauschen immer zwischen dem phys. Standort des Kommlinks und dem phys. Standort des Zielicons berechnet.

Dazu kommt das Rauschen am Ort des Kommlinks und dem Zielicon (zb. Spam/Matrixloch) und evtl. Rauschen von dazwischenliegenden Hindernissen (Wasser, Mauern, usw.) oder Abschirmung.

Wenn das Ziel nun ein Icon ohne phys. Standort ist (zb. eine Datei), kann es weder Entfernungsrauschen noch Rauschen durch Hindernisse zwischen dir und dem Ziel geben. Es zählt nur das Rauschen am Ort des Kommlinks (Matrixloch/Spamzone).

 

Achtung: Wie bei den meisten Aspekten der Matrix sind die Regeln hier kaum ausgeführt. Man muß sehr viel herleiten (auch aus Quellen der 5. Edition), den GMV einsetzen und guten Willen haben.

Link to comment
Share on other sites

Danke für deine Erklärungen! Helfen  wirklich sehr, um ein Grundverständnis von der Matrix zu entwickeln, welches sich leider als Neuling aus dem GRW kaum ableiten lässt. Danke schon einmal dafür! 

 

Wenn das Ziel nun ein Icon ohne phys. Standort ist (zb. eine Datei), kann es weder Entfernungsrauschen noch Rauschen durch Hindernisse zwischen dir und dem Ziel geben. Es zählt nur das Rauschen am Ort des Kommlinks (Matrixloch/Spamzone).

Nur, damit ich es richtig verstehe:

  • Wenn ich als Hacker auf eine/n Datei oder Host mit einem physischen Standort zugreife (z. B. den Server in einer Fabrik), dann erhalte ich Rauschen aufgrund der physischen Entfertnung zwischen Kommlink und Server/Icon.
  • Wenn ich als Hacker auf eine/n Datei oder Host ohne physischen Standort zugreife (Datei/Icon/Host ist nur online), dann erhalte ich kein Rauschen, da keine physische Entfertnung zwischen Kommlink und Server/Icon besteht.

1.) Ist das so richtig?

 

Das würde sich jedenfalls mit der folgenden Aussage aus dem GRW, S. 185, decken:

 

"Einige Hosts existieren rein virtuell und scheinen über der schwarzen Ebene der Matrix zu schweben; andere sind mit physischer Hardware an einen bestimmten Ort gebunden."

 

2.) Was ich nur nicht ganz verstehe: Müssten nicht eigentlich alle Dateien/Hosts/Icons irgendwie über einen Server laufen? Meine Google-Cloud läuft ja letztlich auch auch über irgendwelche weit entfernten Server. Oder muss man sich von der Vorstellung des Internets 2020 verabschieden und es gibt wirklich rein virtuellen Online-Content ohne physische Speicherung?

 

Danke im Voraus!

Link to comment
Share on other sites

Genau, die Matrix besteht seit SR5 als ein rein Vituelles Gebilde ohne zwingend eine Physische Quelle zu haben.

Hosts werden aus der Matrix selbst gebildet, dabei sind einige an Physische Standorte gebunden, andere nicht.

In SR5 gab es anfangs überhaupt keine Hosts die eine Physische Entsprechung hatten, da existierten alle Hosts ausschließlich in der Matrix.

 

Unsere Vorstellungen vom Internet sind somit nicht auf die Matrix übertragbar.

Link to comment
Share on other sites

1. Korrekt. Wobei der Host des Lagerhauses nicht zwingend auf physischer Hardware beruhen muss.

Ich würde das in der Regel an Größe und vor allem Alter festmachen.

 

2. Vergiss am besten alles was du über das Internet und IT 2020 weißt. Die Matrix ist anders.

Link to comment
Share on other sites

Danke erneut für eure Erklärungen! Den letzten Satz hätten sie vielleicht mal so in die Regeln schreiben sollen. ;-)

 

Was gibt es denn für Anhaltspunkte, wann ein Icon/Datei/Host rein virtuell ist? Kann man da eine Faustregel ableiten?

Link to comment
Share on other sites

Meine Faustregel:

- Hosts sind in 95% der Fälle virtuell. Wenn nicht dann sind es veraltete Hosts.

Das würde ja im Umkehrschluss bedeuten, dass 95% der Hosts keinem Rauschen unterliegen (da keine physische Bindung), richtig?

 

Es gibt in den Regeln keine Hinweise darauf, dass das hacken von Geräten, die als Slave in einem PAN/Host angelegt sind, nicht ganz normal dem Rauschen unterliegen. Das bedeutet, dass der Hacker daheim auf dem Sofa beim hacken eines virtuellen Host zwar keinem Rauschen unterliegt (aus dem Rauschen an seiner Position - Spamzone/Matrixloch), aber beim manipulieren von physischen Geräten Rauschen durch zb. Entferung/Wifi Abschirmungen berücksichtigen muß.

Verstehe ich es richtig, dass Rauschen beim Hacken eines Hosts dann ausschließlich aus einer möglichen WiFi-Verbindung zu angeschlossen Geräten besteht? Sprich: Der Host hat zum Gerät denselben Rauschenwert wie der Hacker, den in den Host eingedrungen ist?

 

Beispiel:

  • Hacker sitzt auf seinem Sofa und hackt den Sicherheitshost einer Firma (kein Rauschen - egal, wie weit enfernt, da Hosts virtuell sind). 
  • Host hat mehrere Sicherheitskameras als Slaves über WiFi angeschlossen. 
  • Hacker möchte Zugriff auf diese. Er hat Zugriff auf den Host und somit Zugriff auf die Kameras. Für Handlungen, die die Kameras zum Ziel haben (z. B. Datei editieren), muss Rauschen berücksichtigt werden.

Das Hacken des Hosts generiert somit kein Rauschen, jedoch das Hacken der Kameras (Slaves des Hosts)?   

Edited by jtkrk22
Link to comment
Share on other sites

1. Ja

2. Der Host hat zu seinen Slaves deswegen kein Rauschen, weil er bei Steuerung der Slaves nicht den normalen Matrix-Regeln unterliegt. Ich denke/hoffe, dass das Thema Hosts in der ersten Erweiterung ausführlich behandelt wird.

3. Korrekt. Rauschen zu den Kameras berücksichtigen. Aber auch zum virtuellen Host (oder einem anderen virtuellen Ziel) könnte es Rauschen geben, wenn das Sofa des Hackers in einer Spamzone/einem Matrixloch liegt.

Wenn du mit "Datei editieren" einen Kamerafeed manipulieren willst (wie in dem Beispiel) ist das Ziel nicht die Kamera (physisch, Rauschen) sondern die Datei/der Feed (virtuell, kein Entfernungsrauschen).

Link to comment
Share on other sites

Ah, super! Dann habe ich es endlich (hoffentlich). Vielen Dank für eure Geduld! 
 
So, nun der Versuch der eigenen Zusammenfassung. (Ich brauche sowas immer für mich - die Regeln tun es ja nur bedingt.  :unsure:)

 

URSACHEN VON RAUSCHEN

  1. Entfernung oder Störungen im WiFi: 
    • Schlechtes Signal zwischen Kommlink des Hackers und einem physischen Gerät (Direktverbindung WiFi) oder Gerät in einem PAN (Zielgerät ist Slave im PAN).
    • Mögliche Ursachen: Entfernung zwischen beiden Geräten oder zum PAN, Störsender oder Abschirmungen durch Vegetation, etc.
       
  2. Entfernung oder Störungen zwischen Geräten in der Matrix:
    • Schlechtes Signal zwischen Kommlink des Hackers und einem physischen Gerät in der Matrix.
    • Mögliche Ursachen: Entfernung zwischen beiden Geräten, Störsender oder Abschirmungen durch Vegetation, etc.
       
  3. Anbindung in die Matrix:
    • Schlechte Verbindung des Kommlinks des Hackers zur Matrix.
    • Ursache: Problem ist die schlechte Anbindung selbst (z. B. durch Matrixloch, Spamzone, etc.)

 

KEIN RAUSCHEN BEI:

  • Verbindungen zu Hosts und Dateien in der Matrix, da diese rein virtuell sind.
    (Es sei denn, die Anbindung des Hackers in die Matrix selbst ist schlecht à siehe 3. Ursache)
  • Verbindungen zwischen einem gehackten Host und dessen angeschlossenen Geräten (Slaves), da diese regeltechnisch wie der Host behandelt werden.

 

ANSCHLUSSMÖGLICHKEITEN VON GERÄTEN:

 

Physische Geräte haben vier Anschlussmöglichkeiten:

  • Als eigenständiges physisches Gerät mit WiFi ON (Rauschen möglich)
  • Als eigenständiges physisches Gerät mit WiFi OFF (Gerät nicht erreichbar)
  • Physisches Gerät ist Slave in einem PAN (Rauschen möglich, gemessen an der Verbindung zwischen Hacker und Zentrum des PANs, da Slaves regeltechnisch wie das Zentrum des PANs behandelt werden)
  • Physisches Gerät ist Slave in einem Host in der Matrix (kein Rauschen, da Hosts rein virtuell sind und angeschlossene Geräte regeltechnisch wie der Host selbst behandelt werden. Es kann lediglich zu Rauschen, welches durch eine schlechte Verbindung zwischen dem Kommlink des Hackers und der Matrix verursacht wird.)

 

Alles richtig?

Edited by jtkrk22
Link to comment
Share on other sites

 

3. Anbindung in die Matrix:

  • Schlechte Verbindung des Kommlinks des Hackers zur Matrix.

 

Auch das Ziel könnte in einer Spamzone/einem Matrixloch liegen.

 

 

KEIN RAUSCHEN BEI:

  • Verbindungen zwischen einem gehackten Host und dessen angeschlossenen Geräten (Slaves), da diese regeltechnisch wie der Host behandelt werden.

 

Hierfür sehe ich in den Regeln keinen Anhaltspunkt. Imho wird auch bei den Slaves (weil physisch) Rauschen berücksichtigt.

 

ANSCHLUSSMÖGLICHKEITEN VON GERÄTEN:

 

  • Physisches Gerät ist Slave in einem PAN (Rauschen möglich, gemessen an der Verbindung zwischen Hacker und Zentrum des PANs, da Slaves regeltechnisch wie das Zentrum des PANs behandelt werden)
  • Physisches Gerät ist Slave in einem Host in der Matrix (kein Rauschen, da Hosts rein virtuell sind und angeschlossene Geräte regeltechnisch wie der Host selbst behandelt werden. Es kann lediglich zu Rauschen, welches durch eine schlechte Verbindung zwischen dem Kommlink des Hackers und der Matrix verursacht wird.)

 

In beiden Fällen imho Rauschen, da die Verbindung zwischen Slave-Gerät und Hacker berücksichtigt wird. Ich sehe keine Regel, nach der die Verbindung zu einem Geräte-Slave keinem Rauschen unterliegt.

Edited by Corpheus
Link to comment
Share on other sites

 Share

×
×
  • Create New...