As a matter of preference and style, I completely agree with Crakkerjakk. I don't think I can stress this enough. As far as I'm concerned, Crackerjack is dead on here.
But let's have some fun:
I've often felt that there needs to be some equivilent of GM traps (beyond IC) within a node to act as the equivilent of technical and physical security for Matrix intrusions. Just like we have motion sensors and infrared cameras and pressure plates and gas rooms, etc, in addition to security, nodes should have some setup options in addition to IC. I think what Cheops is describing fits this role perfectly provided that:
1) PCs have the abiltiy to discover the node's defenses through legwork or some such thing
2) There is always a counter. If you allow this agent, for example, under the guise of crossreferencing datatrails, then simply redirecting your datatrail should be enough to fool it... or killing/subduing the agent. Or maybe editing the tables that the agent is cross-referencing.
3) The same counters work each time and players know what these counters are, just as they know how to circumvent motion sensors and tripwires.
4) Nodes have a variety of these defenses or none at all... don't assume every node will have these special quirks.
Also, I think Cheops has too awesome a point regarding the functions of the initial Hacking roll and the stealth program. In fact, to keep with the physical/technical security analogy, you wouldn't want to instantly reveal intruders immediately no matter how stealthy they are, would you? It might be better to assume that a hacker could sneak his way in, but the moment he tries to use any operational programs or confront any IC he risks setting off these extra security measures. This will also give the players some leeway to react to the potential threat if they know about it ahead of time. If they don't know about it ahead of time and don't bother searching for it... well... that's just as bad as not knowing about the pressure plate on the 3rd floor, isn't it?
Full Version: Stupid Question
people, VR2.0 and matrix both contained so-called sysadmin tricks. i would be surprised if unwired did not hold a similar section.
this would in essence be a list of things a spider can do to improve security above and beyond adding more IC.
this would in essence be a list of things a spider can do to improve security above and beyond adding more IC.
| QUOTE (hobgoblin) |
| people, VR2.0 and matrix both contained so-called sysadmin tricks. i would be surprised if unwired did not hold a similar section. this would in essence be a list of things a spider can do to improve security above and beyond adding more IC. |
Hey, hobgoblin. I don't remember this section of VR 2.0. I was under the impression that security in that book came in the form of node statistics, security riggers, IC, and tiered node topology. Can you fire me off a quick list of some of their suggestions? I'd appreciate it, thanks.
| QUOTE (cetiah @ Feb 14 2007, 06:36 PM) |
| There is no "master list" of everyone logged into the node by default Matrix rules. Several bulletin boards today have a "connected users" list. It would be something set up specifically by the host but it is completely reasonable. |
| QUOTE (SR4 p.217) |
When you are accessing a node, you may set your Analyze program to automatically scan and detect other users/icons on that node with a Simple Action. A successful scan will be reported to you. Th e program will maintain that task for as long as you are on that node or until you kill that process. Th e gamemaster secretly conducts Matrix Perception Tests to determine if you detect other icons accessing the system. Note that technomancers receive an inherent +2 dice pool bonus on all Matrix Perception Tests. |
Since that should be a 1-threshold for non-stealthed users, pretty much anyone who is a serious user should be able to use the "auto-success" rule to access the legit user list.
That also ignores the possibility of the site itself having a user sign-in board.
| QUOTE (Cheops) |
| Another good measure are agents that monitor passcode lists and cross-reference with working hours lists. If any new passcodes are added or if it detects a log-on by a user that doesn't normally log in at that time it alerts a spider who can take appropriate action like tracking. |
The system lacks Daemons. Daemons are fairly established computer software, dating well back into the 70s, and they are pretty simple but useful things. Daemons primary job is to do one task periodically or at need. ChronD (chronometric daemon) is a timer that activates programs at specified times. InetD is the network daemon and it initializes the network stack, ports, etc. In SR terms, if you wanted a "vanishing node," one of those hosts that is only online for a certain window each day, ChronD would give activate and deactivated commands to InetD.
Simple daemons could handle the task of notifying a sysadmin when a new user account was created to ensure it was a legit creation. It would be defeated by an Analyze identify the Daemon and a Stealth test to make the Daemon think it had already notified the sysadmin.
The trouble is, it is too much to worry about in-game. Who wants to roll 30 Analyze & Stealth actions to find all the daemons scattered about? Ceases to be fun.
The crux is to add some simple events and services that are handled automatically by the OS rather than by an agent or user. Those same events and services should NOT be used to make hacking harder and instead the abstract hacking process should be assumed to already account for them in the existing Analyze/Stealth actions.
| QUOTE (cetiah) | ||
Hey, hobgoblin. I don't remember this section of VR 2.0. I was under the impression that security in that book came in the form of node statistics, security riggers, IC, and tiered node topology. Can you fire me off a quick list of some of their suggestions? I'd appreciate it, thanks. |
hmm, i may have been a bit quick when it came to including VR2.0 in that post.
its not a single chapter like in matrix, but the stuff in said chapter in matrix is also spread all over VR2.0. things like vanishing sans, virtual machines and all that stuff.
Just to clarify I was pointing out that it was possible. Cetiah didn't seem like it could be done. As to whether it should be done that is up to the GM.
I don't always use System 6/Response 6 stats for corporate nodes so running an agent that has, at least Anaylze, plus Analyze for the node, plus at least encryption adds up to 4 programs being used. This would cause slowdowns and so most systems won't do this.
Also, the SysOp would still have to successfully perceive the hacker which is where stealth would help. The worst he can do until he spots you or gives up looking for you is put the system on passive alert (alert without sending IC after you immediately). But to do anything, either he or the node has to beat you in an opposed hacking + stealth.
Edit: And if this were occuring during a period of time where lots of legitimate users were logged on he might not even move to passive alert so that he doesn't cause slowdowns from repeated security checks for other users. (See what's happened to the Persian chick in 24 this season for an example of security measure slowdowns on users).
Honestly I wouldn't throw security like this at my players until they are much higher Table Rating. I tend to have a lot of newbies and people I've never gamed with before so it takes a while for everyone to learn how to play and how to play with each other. So I gradually ease the security up a notch over the course of play.
I don't always use System 6/Response 6 stats for corporate nodes so running an agent that has, at least Anaylze, plus Analyze for the node, plus at least encryption adds up to 4 programs being used. This would cause slowdowns and so most systems won't do this.
Also, the SysOp would still have to successfully perceive the hacker which is where stealth would help. The worst he can do until he spots you or gives up looking for you is put the system on passive alert (alert without sending IC after you immediately). But to do anything, either he or the node has to beat you in an opposed hacking + stealth.
Edit: And if this were occuring during a period of time where lots of legitimate users were logged on he might not even move to passive alert so that he doesn't cause slowdowns from repeated security checks for other users. (See what's happened to the Persian chick in 24 this season for an example of security measure slowdowns on users).
Honestly I wouldn't throw security like this at my players until they are much higher Table Rating. I tend to have a lot of newbies and people I've never gamed with before so it takes a while for everyone to learn how to play and how to play with each other. So I gradually ease the security up a notch over the course of play.
| QUOTE (kigmatzomat) | ||
The system lacks Daemons. Daemons are fairly established computer software, dating well back into the 70s, and they are pretty simple but useful things. Daemons primary job is to do one task periodically or at need. ChronD (chronometric daemon) is a timer that activates programs at specified times. InetD is the network daemon and it initializes the network stack, ports, etc. In SR terms, if you wanted a "vanishing node," one of those hosts that is only online for a certain window each day, ChronD would give activate and deactivated commands to InetD. Simple daemons could handle the task of notifying a sysadmin when a new user account was created to ensure it was a legit creation. It would be defeated by an Analyze identify the Daemon and a Stealth test to make the Daemon think it had already notified the sysadmin. The trouble is, it is too much to worry about in-game. Who wants to roll 30 Analyze & Stealth actions to find all the daemons scattered about? Ceases to be fun. The crux is to add some simple events and services that are handled automatically by the OS rather than by an agent or user. Those same events and services should NOT be used to make hacking harder and instead the abstract hacking process should be assumed to already account for them in the existing Analyze/Stealth actions. |
Hey, thanks kig. This is much closer to what I wanted for my custom hacking rules. Maybe it will clear up a lot of confusion if I use the term Daemons rather than Resident Agents. Very helpful.
Should a Daemon have any decision-making capabilities or is it just a timer? Can it access data? It's wikipedia time again...
Daemons are pretty simple in general. They are light weight to avoid putting too much load on the OS. Their logic tends to be fluffy, being little more than a handful of if-then statements. My linux box had a network card that would panic from a ping of doom so I had chrond run a little script I wrote, isnetd, that did nothing but ping the gateway router and, if it failed to get a response, reset inetd.
Remember that daemons are owned by the OS, rather than any user/agent, and are pretty much untouchable except by admins. There tends to be many of them running (Windows Services owned by "Local System" are daemons, check your PC to see how many tend to run) and they are often interdependent. Part of hacking is probably editing, spoofing, or stealthing various daemons to avoid attention.
A daemon would be responsible for the system reboot that can happen during an active alert. A daemon would also be what launches the IC when the firewall calls an active alert.
Remember that daemons are owned by the OS, rather than any user/agent, and are pretty much untouchable except by admins. There tends to be many of them running (Windows Services owned by "Local System" are daemons, check your PC to see how many tend to run) and they are often interdependent. Part of hacking is probably editing, spoofing, or stealthing various daemons to avoid attention.
A daemon would be responsible for the system reboot that can happen during an active alert. A daemon would also be what launches the IC when the firewall calls an active alert.
| QUOTE (kigmatzomat @ Feb 15 2007, 01:51 PM) |
| Daemons are pretty simple in general. They are light weight to avoid putting too much load on the OS. Their logic tends to be fluffy, being little more than a handful of if-then statements. My linux box had a network card that would panic from a ping of doom so I had chrond run a little script I wrote, isnetd, that did nothing but ping the gateway router and, if it failed to get a response, reset inetd. Remember that daemons are owned by the OS, rather than any user/agent, and are pretty much untouchable except by admins. There tends to be many of them running (Windows Services owned by "Local System" are daemons, check your PC to see how many tend to run) and they are often interdependent. Part of hacking is probably editing, spoofing, or stealthing various daemons to avoid attention. A daemon would be responsible for the system reboot that can happen during an active alert. A daemon would also be what launches the IC when the firewall calls an active alert. |
This is very helpful to me. Thank you.
Your "daemon" sounds like Garrowolf's "process".
Are the limitations on daemon's fluffy logic a technical limitation or is it a principle of definition? I mean can we theoretically design a better daemon in 2070 or would it no longer be definable as a daemon by that point?
I'm looking for a decent way to categorize and model the basic OS/programs of the old "Pocket Secretaries" that Shadowrunners used to carry around. People seem to resent calling these agents. From what you describe, daemon doesn't seem quite right either.
Daemons are lightweight so they are easy to fix and to avoid calling too much system resources. They are also somewhat modular to enable customization.
Daemons don't need to be that complex. Many system functions are pretty much if-then/either-or/timetable scenarios. If someone logs in then record it. At 2am dump the system logs to tape. Every friday rotate the tapes. If the tape is more than four weeks old delete it.
Agents are some level of AI. They have complex coding and are able to operate with flexible instructions. They are total overkill for most needs.
Daemons don't need to be that complex. Many system functions are pretty much if-then/either-or/timetable scenarios. If someone logs in then record it. At 2am dump the system logs to tape. Every friday rotate the tapes. If the tape is more than four weeks old delete it.
Agents are some level of AI. They have complex coding and are able to operate with flexible instructions. They are total overkill for most needs.
| QUOTE (kigmatzomat @ Feb 15 2007, 02:20 PM) |
| Daemons are lightweight so they are easy to fix and to avoid calling too much system resources. They are also somewhat modular to enable customization. Daemons don't need to be that complex. Many system functions are pretty much if-then/either-or/timetable scenarios. If someone logs in then record it. At 2am dump the system logs to tape. Every friday rotate the tapes. If the tape is more than four weeks old delete it. Agents are some level of AI. They have complex coding and are able to operate with flexible instructions. They are total overkill for most needs. |
Okay, so this is my classification:
Artificial Intelligence - digital sentience at its finest
Mobile Agent - as in RAW, or my interpretation of RAW since some seem to disagree. Generally IC is the model used for Mobile Agents. They have no concept of user preferences or anything outside the Matrix. They obey all specific instructions programmed into them but can make independant decision to follow pre-programmed goals in the absense of user instructions. They cannot learn, re-program, or decide on other goals.
Resident Agent - A little less like IC and closer to the "Pocket Secretary". It has a huge collection of useful dhameons and limited decision making capabilities based on pre-determined "values". It can establish its own goals based on these values. The most common values are for protecting users or making their lives easier.
Utilities, Firewall, I.C.E., IC-Breakers: All forms of Resident Agents designed with specialized functions, features, and values.
Dameons - Automated processes that are run independantly of user request/input. A Daemon often reports to an agent but can also act independantly. They perform a lot of background maintenence on a node and basically keep the node functioning. There are two types of Daemons: System Daemons and Process Daemons. Daemons are completely invisible to most users but the Hacking skill allows a hacker to interact directly with the Daemons.
System Daemons: Responsible for keeping a node functioning, the nodes entire purpose/function can be determined by what form of System Daemons are running on it. System Daemons are impossible to remove from the node as they are built right into it. They help to maintain, repair, expand, and operate the node but are otherwise independant of most icons and files within the node.
Process Daemons: Little automated critters that run around in a node interacting with various programs and icons to perform necessary functions. The most common functions include analysis, logging, sorting, searching, and basic communication.
Critical Process: Any daemon, agent, user, program, file, icon that the GM feels would be important for a hacker or user to interact with is deemed Critical. For the most part, non-critical processes can be ignored. While they are assumed to be running full time, most non-critical processes are filtered out by agents and users seeking to manipulate critical processes.
Stealth: The act of pretending to be a non-critical process.
Sound good to anyone else?
I was not answering your questions, Serbitar. Mearly musing about why the rules would be as you interpreted them. Not having looked them up myself I accepted your interpretation. You really have a high demand for interested and informed responses, don't you? 
After reading into it a bit more I will have to side with Frank among others: It only says that an agent has to be uploaded to run independently. That is; to persist in the matrix without you or your commlink. Once uploaded somewere it uses that node's ratings even if it operates on different nodes (off course I would think that this traffic would be logged in some way and that it would be unwise to leave an agent in a node that you don't own for too long).
<<<edit>>> oops! I really don't visit very often nowadays My next most resent post was in this thread.
After reading into it a bit more I will have to side with Frank among others: It only says that an agent has to be uploaded to run independently. That is; to persist in the matrix without you or your commlink. Once uploaded somewere it uses that node's ratings even if it operates on different nodes (off course I would think that this traffic would be logged in some way and that it would be unwise to leave an agent in a node that you don't own for too long).
<<<edit>>> oops! I really don't visit very often nowadays
My next most resent post was in this thread.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.