[SR4] Host vs. Probing

    Hallo Leute,


    folgende Frage hat bei uns letztlich eine längere Diskussion aufgeworfen.
    Hackerbraut Janice will in einen Renraku Host Hacken. Der Host hat die zuerst einen Public 3/3 Node gefolgt von einen gestealthten Chockepoint 6/6 und dann dem Intranet Node mit 4/4.


    Janice hat alles relevante auf 4 und Hackt heiß. Janice hat Zeit.
    Zuerst probt sie den 3/3 für einen Adminaccount was nur eine 12er Schwelle auf extended ist. Das hat sie in 3 bis 4h.
    Jetzt ist sie Admin in dem Public Node. Diesem Admin ist der Zugang zum Chokepoint verboten, wohl sieht er ihn. Janice beschließt nun den Chockepoint zu proben. Das ist eine 18er Schwelle für Admin account. Bis zum Erfolg würden ca. 6h vergehen.


    Die Frage ist: Hat der Public Host von dem aus der Chockepoint gehackt wird während der 6h des Probens einen oder mehrere Würfe um den Hack zu entdecken? Schließlich sind beide Hosts von Renraku und es wird ein Hacking Tool (Exploit) benutzt. Auch dem Admin des Public Nodes ist der Zugriff auf den Chockepoint verboten.

    Proben ist nicht Hacken! Proben ist eher unauffälliges testen. Aber zu deinem Problem steht was im Unwired (siehe p.97, Hacked Accounts und p. 98, Detecting Backdoors > Reusable Exploites and Hacked Accounts), es geht darum den Zugang und den illegalen Account zu entdecken. Hierzu gibt es mehrere Möglichkeiten von der Sicherheit aus. Das System selbst könnte den falschen Account entdecken nach einem Reboot, oder ein patroulierender Sicherheitshacker kann über sie stolpern, sowie IC/Agent/AI, wobei IC eher unwahrscheinlich ist da sie einen Adminaccount fährt.

    So Leute ich hab den Tag genutzt und nachgelesen. So einen Fake account zu entdecken dauert ca. 1 Tag.
    Hier kommt meine erste Frage:
    Ist das ein 24h Tag?
    Muß der Security Hacker die ganze Zeit mit 100% aufmerksamkeit den Task betreuen oder startet er morgens ein Programm und hat am nächsten Tag das Ergebnis?
    Was ist mit accounts die während der Task läuft gefakt werden?
    Wenn der Task läuft kann er doch auch von einem anderen Admin (z. B. dem Illegalen) gestoppt/manipuliert werden?


    Soviel zur miserablen Aussicht einen Fake Account zu finden. Jetzt zum Praktischen Nutzen und dem Kontakt mit der Realität. Auch im Jahr 2070+ wird es Online Banking gehen. So ein Bank hat vermutlich einen Public Host für Werbezwecke von dem es weiter auf eine Sicherheishost (6/6) geht von dem aus man seine Bankgeschäfte (Überweisungen) tätigt.
    Joe Nobody, ein besserer durschnittshacker mit allem auf 4 und einen heißen Deck hätte einen 10er Pool. Er könnte jetzt den Samstag vormittag damit zubringen den Public host zu Proben und sich am Nachmittag mit einem als Fake Admin einloggen. Jetzt macht er von seiner Admin Power gebrauch und legt sich noch ein paar legitime accounts an. Jetzt probt er den 6er Node und logt sich gegen Abend als Admin dort ein. An dieser Stelle hat der Host seine Einzige Chance sich zu wehren. Im durchschnitt wird er 4 erfolge mit 12 würfeln erzielen und Joe wird nicht auffliegen, sondern hat jetzt Admin Rechte im Sec Host. Schnell legt er weitere legitime Admin Accounts an und logt sich aus (1 Handlung pro Account + 1 fürs Auslogen).
    Als legitimer Admin logt er sich jetzt mit markellosem Sicherheitskonto ein und startet eine legale Datensuche nach dem Dicksten Konto. Ist dieser account identifiziert ändert er die e-mail des inhabers auf ein konto von sich und schickt dorthin ein neues PW (alternativ kann er auch das tatsächliche PW auslesen oder sich gleich das Geld auf sein Konto schieben)(1 Handlung Browse, 1 Handlung Edit/Decrypt, 1 Handlung ausloggen). Er logt sich als Admin aus und als Kontobesitzer (völlig Legal) ein. Jetzt macht er eine Überweisung auf eines seiner Konten (Evtl. muss er noch eine ID spoofen um eine mögliche TAN abfrage reinzulegen). Anschließend logt er sich wieder als Admin ein löscht alle Logs und alle Hinweise das das Konto das er gerade geplündert hat je existiert hat (ein paar Edit Handlungen).


    Joe Nobody ist jetzt wer und hat ne Menge Kohle. Da alle Handlungen bis auf das Login beim ersten mal (und evtl. der TAN Spoof) für den Account legal waren hat der Host nur eine Probe um sich gegen Joe zu verteidigen. Insgesammt ist er nur wenige sekunden im Host so dass auch ein Anwesender Security Hacker nichts mitkriegen wird es sei denn er hat pures Glück.
    Banken verlassen sich aber nicht auf Glück. Die Chance das ein solcher Hacking Versuch Erfolg hat sollte bei 1:1000 oder bei 1:100,000 liegen um das Wirtschaftssystem der Welt am Leben zu erhalten.


    Ich würde jetzt gerne Wissen welche Regel Joe Hacker davon abhält Milliadär zu werden. Es muss doch eine Regel geben die einem Top-Notch Host erlaubt solche 08/15 Hacks routinemäßig zu unterbinden! Es geht mir jetzt gar nicht um Banken im Speziellen sondern um Hosts im Allgemeinen.


    Kennt jemand so eine Regel?

    Erst einmal ist es nicht unbedingt nur 1 Spider oft sind es mehrere. Und es mag 1 Tag dauern, aber er findet in diesen 8h wenn er gut ist nicht nur einen illegal genutzten Account sondern alle, deren Schwelle er erreicht. Und eine klitzekleine Absicherung ist auch noch da, ein Spider oder anderer Hacker kann natürlich auch normal Probing machen, und bei Erfolg kann jener dann wie unter Probing the Target (p.98) auch eine Backdoor statt eines Exploits finden. :wink:


    Ok, da du das Unwired zu haben scheinst, solltest du dir mal auf p. 78-79 das Banksystem ansehen. Systemdesign ist übrigens die halbe Miete der Sicherheit, soll heißen ist ein sehr wichtiger Punkt und anscheind eine Wissenslücke bei dir, sonst hättest du das Beispiel nicht gebracht.
    Dann ist noch das Ding drin zu sein per Probing heißt/bedeutet noch garnichts, sobald der Hacker was macht was illegal (d.h. seinem Account nicht erlaub) ist, hat das System die Chance den Hacker zu entdecken und Alarm auszulösen oder ihn zu attackieren oder beides oder was Anderes je nach Systemeinstellung.
    Admin-Accounts können oder dürfen übrigens auch nicht Alles (nach dem dicksten Konto suchen ist z.B. nicht drin, das muss ein Spider nicht wissen, gehört nicht zum Job), und dann gibt es noch dazu Dinge wie Passkeys u.ä.
    Es gibt auch nette fiese IC-Typen, die sich erst als nett und hilfsbereit Agenten tarnen, aber wenn sie Illegales entdecken, sofort alarmschlagen und/oder angreifen (siehe hierzu auch... ach was lies das SYSTEM SECURITY Kapitel ab p.60 komplett).


    MfG
    UV

    die einfachste und 99% sichere Variante einen Server sicher zu gestalten ist folgende:


    24/7 Spider und eine Access Log mit einer Strong Encryption von etwa 10+min


    der Spider schaut sich den ganzen Tag nur das Access Log an und wenn jemand in den Knoten kommt, der nicht zu die übliche Access ID hat, ists wohl ein Eindringling und man kann ihn zumindest mal auftringlich beschnuppen (oder prophylaktisch rauswerfen)... und mit den 10 Bloodhound IC im Teamwork hilft dem auch ein 6er Kommlink mit 6er Stealth nicht mehr viel.


    cya
    Tycho

    "Tycho" schrieb:


    der Spider schaut sich den ganzen Tag nur das Access Log an und wenn jemand in den Knoten kommt, der nicht zu die übliche Access ID hat, ists wohl ein Eindringling und man kann ihn zumindest mal auftringlich beschnuppen (oder prophylaktisch rauswerfen)... und mit den 10 Bloodhound IC im Teamwork hilft dem auch ein 6er Kommlink mit 6er Stealth nicht mehr viel.


    Sorry aber der ganze Aufbau klingt ein wenig, nennen wir es "sonderbar"! :wink:
    Und was soll das mit den 10 x Bloodhound im Teamwork heißen? 1. Auch IC frisst Rechenpower; 2. Welche stufe sollen den die 10 Bloodhound haben? Und 3. Wie definierst du Teamwork, nach den erratierten Teamworkregeln im GRW oder meinst du was Anderes?

    Vielen Dank für die Interessanten Tipps. Ich dachte eigentlich ich hätte das System Design Kapitel aufmerksam gelesen, aber das war wohl eine Fehleinschätzung. Ich schätz mal ich les es nochmal.


    Das Problem mit Admin Accounts ist, dass im SR4 Hauptbuch steht, dass der Admin Account fast alles machen darf auch wenn es das System schädigt.


    Encrypted Access Log dürfte auch nix bringen da der Admin in der Lage sein sollte das zu lesen. Da ge-probte Accounts eigentlich immer Admin accounts sind ist der Vorschlag wohl nicht umsetzbar. Strenggenommen könnte der Admin auch die Ausführung aller ICE beenden.


    Gerade bei Hosts die Unmengen an usern Hosten sehe ich die Chancen das ein Spider irgendwas ohne eine Automatische Hilfe erkennt als nicht vorhanden an. Wenn also das System und Firewall keine routinen kennt fake accounts aufzuspüren bevor ein Schaden entsteht, dann gibt gibt es wohl keine Online Sicherheit.

    Kurz noch meine Überlegung dazu:
    Ich würde mal behaupten, dass es in einer Node nur 1-3 normale Admin-Accounts gibt. Im Groben Einen, der es legal darf und evtl. einer, den die dort arbeitende Spinne / Spinnen sich im geheimen geschaffen haben, weil sie es halt können.


    Dein Joe Hacker aber legt zig Admin-Accounts an - das ist ja sowas von auffällig... Bei genau 2 Admin-Accounts, die eigtl. sein dürfen und bei der die Spinne sehr schnell kontrollieren kann, ob der Account korrekt sich einloggt (Was macht der CEO (od. wer den normalen Admin-Account halt hat) gerad? Und den anderen Admin-Account nutze ja eigtl. ich...) , und auf einmal ein dritter / vierter / fünfter entsteht - da würd ich ja mal ganz schnell die Accounts überprüfen und dann ist man aufgeflogen als Hacker.

    Einer der einfachsten SL-Tricks um den Gebrauch von Probing zu unterbinden, ist es das System einen Layered Access zu geben, also viele Nodes hintereinander, mit Chokepoints usw.
    Und dann drei Optionen nutzt, ...


    a) Ist automatischer Reboot, diese Option ist die einfachste man legt z.B. einen Reboot auf 24h oder um das Probing zu verhindern, setzt man diese Option auf einen Durchgangsnode auf 1h oder weniger, bedeutet alle Benutzer die den Durchgangsnode überwinden und im nächsten Node landen sind nicht betroffen, doch der User/Hacker der versucht in das System zu hacken, wird nach der abgelaufenen Zeit, die übrigens per Systemzeit automatisch läuft, aus dem entsprechenden Node geworfen (damit kann der arme SC bei einem fiesen SL auch in der nächsten Minute gekicked werden, da der SC halt bei Minute 59 eingelogged ist)! Wenn der Intervall des Reboots kleiner ist als die Zeit die der Hacker braucht um rein zu hacken, scheitert die Probe automatisch! In Beispiel von Probing, ist der Hacker dann leider gezwungen on-the-fly zu hacken, da die Probing time einfach zu lang ist.


    b) Ist das von Tycho schon angesprochene Encryption das verlangsamt noch einmal den Hack um einiges (und ergänzt damit Reboot perfekt). Hier gibt es auch mehrere Varianten.


    c) Ist das auch von Tycho angesprochene Access Log. Hier empfehle ich aber ein Protected Access Log auf einen anderen Node zu legen. Eine kleine Eigenkreation die zwar nicht in den Regeln explizit erwähnt wird, aber auch möglich wäre, ist nur eine Kopie des Access Logs auf einem andern Node zu sichern (mit beschränktem Zugriff bzw. Personenkreis der davon weiß), so kann bei Verdacht abgeglichen werden, also ein Vergleich zwischen Orginal und Sicherheitskopie.


    Ach und wenn du allgemein Probleme mit Admin-Account-Rechten für SC-Hacker bei bestimmten Systemen hast, kombiniere den Admin-Account mit der Passkey Checking Option und einem angemessenen Passkey! (Aus der Beschaffung des richtigen Passkeys kann auch ein ganzer Run werden. :mrgreen: )

    Sorry, imho ist das mehr in die Regelmechanik reininterpretieren als sie hergeben. Du versuchst hier deine reichlich beliebigen Annahmen gegenüber den reichlich beliebigen Annahmen eines anderen Spielers zu bevorzugen. Verständlich, aber sinnfrei. Genauso könnte man sagen "Was? Dein Hacker hat keine blaue Persona? Fällt sofort auf." Vollkommen beliebig. Aber der WITZ an Hacking ist ja, dass man solche Sachen eben InGame berücksichtigt, d.h. wenn ein Hacker einen Admin-Account anlegt, versteckt er ihn vielleicht auch gleich oder sonstwas. Dementsprechend würde ich hier einfach nach Regeln vorgehen, denn mit Logik hat die SR-Matrix nix zu tun und die Regeln sind viel zu allgemein und für solche Details genug Infos zu bieten, imho.


    Bei Eigenkreationen wäre auch immer vorsichtig, man bedenke, dass ein Hacker mit Hacking 5 oder gar 6 die meisten solcher Sachen kennen sollte. Sie als SL heimlich aus dem Ärmel ziehen kann im schnell unfair werden. Man zieht ja auch nicht plötzlich Möglichkeiten für Trick-Shots aus dem Ärmel um Samurais zu überraschen.

    "Irian" schrieb:

    Definiere "nicht die übliche Access ID"? Soll der Spider alle Knotennutzer auswendig kennen?


    Ich denk ein kleines txt File zum abgleichen ist nicht das Problem:
    Die Access ID ist hardwired, daher haben die Angestellten immer dieselbe oder zumindest eine kleine Anzahl vielleicht 2-3 pro Angestellten, wenn man denen sogar "Arbeitskommlinks" gibt, dann haben die immer die selbe. Und der Hacker hat diese sicher nicht und sobald der auf dem Knoten aufpoppt, steht die (mit kurzer Zeitverzögerung) dadrin und der Spider kann sagen "Ziel markieren und vernichten"


    Access Log auf einen Anderen Knoten ist natürlich besser als verschlüsseln.


    das ein Admin alles darf, ist nur der default Vorschlag aus dem Unwired. In der Praxis muss das gar nicht stimmen. Die Erlaubnisse die jeder Account hat, kann man einfach logisch festlegen und den Admin, der alles darf den gibt es da fast nie...


    cya
    Tycho

    Irian
    Meintest du mein Post? Wenn das alles Quatsch sein soll, warum steht das dann im Unwired? Ich hab es nur mal umschrieben zum besseren Verständnis. Im Moment weiß ich nicht so recht, was ich von deinem Post halten soll, da ich mich an die im Unwired beschriebenen Regeln gehalten hab, also nichts Regelwidriges, meines Erachtens. Aber wenn du es besser weiß, nur zu, zeig mir meine Fehler auf. :?

    Die genannten Ideen sind alle nicht schlecht. Es sind aber alles Fragen die betreffen wie es im Spiel umgesetzt wird und nicht ob es ein Regel dafür gibt ob Probing auffallen kann.
    Das mit der zahl der Admin accounts finde ich z. B. total logisch. 3 bis 5 mehr braucht es nicht. Es kommen auch nicht jeden Tag Admins dazu. Bei einer simplen Prüfung gegen eine Write-Protected Admin liste sollte auch der dümmste Host einen Fake admin account erkennen können.


    Die Spielmechanik dazu wäre wohl "Web of Trust". Im einfachstem Fall besteht das Web of Trust in einem dem Host nachgeschaltenen Node. Habe ich also die Konstellation Public-ChokePoint-Data dann bildet der Data Node das Web of Trust für die anderen. Bei einem versuchten LogIn auf den ChokePoint mit Fake Account frägt er bei Data nach ob Data den Account kennt und wenn das nicht der Fall ist war es das mit dem Log In.


    Wie sieht das den eigentlich aus wenn ich einen ganz speziellen Acccount z. B. den von Lieschen Müller Hacken will? Wie geht dass denn?

    wegen bestimmten Account:
    Du musst vermutlich wissen welcher Accunt und dann würde ich einfach den MW erhöhen beim extended test, denn du willst ja nicht einen Admin Account sondern genau den Admin Account.


    cya
    Tycho

    MMn haben Spider keinen Admin-Account, sondern nur einen Sicherheitsaccount.


    Die neuen Matrixregeln sollten das Hacking vereinfachen, doch die Folge ist, dass der Hacker jetzt überall ziemlich leicht reinkommt, wenn man stur die Grundregeln fährt. Wenn ich jetzt wieder ganze Matrixarchitekturen wie bei SR3.0 aufbaue, gefährde ich natürlich die Spielbarkeit, aber eine richtig tolle Lösung aus diesem Dilemma habe ich auch noch nicht gefunden.


    Sehr gut finde ich die begrenzte Systemzeit in einem Knoten, um das weitere ausgedehnte Analysieren zu unterbinden. In wie weit das allerdings für einen Admin logisch ist, ist mMn eher zweifelhaft.


    Wenn das System nur eine begrenzte Anzahl von Admins kennt, wird der Hacker genau so einen Admin nachahmen. Er muss also gar keinen neuen account anlegen.