Jump to content

Griefing detection for security system...


Life Camino
 Share

You are about to reply to a thread that has been inactive for 2928 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

I'm working on a new security system to protect my sim from griefing and I want to be able to detect griefing levels of script time; but, I don't have a feel for what that level might be.  So, can anyone tell me how much script time is generally considered so excessive as to constitute griefing?

The recent attacks have involved avatars rezzing all the available prims in the region, launching particle attacks to crash video cards, and using scripts that cripple the region - including the security system.  So, I really need to be able to detect and eliminate this particular type of threat.  

The sim is open to the public, has renters, role players, and visitors all the time, so I can't just restrict access.   I've got to detect misbehavior.  Any advice you can offer would be appreciated. 

Thanks.

Link to comment
Share on other sites

Scripts can't cripple a region by themselves.  Scripts can only take whatever free time is available.  If no free time is available, then scripts don't run.  That is, other things cripple scripts or scripts interfere with each other, but scripts don't take time from whatever else is going on in the region.  So, montioring script time is not going to help you at all.  What scripts can do is rez a zillion objects or start a particle system going or move physical objects around.  When you rez objects, that stalls the simulator briefly. Rezzzing a lot of objects stalls it a lot.  Rezzing or controlling physical objects takes even more.  In each case, though, the scripts are not stalling things by using up time.

Link to comment
Share on other sites

If the problem is rougue rezzers that are spewing out a lot of new prims over and over again, or replicators that duplicate themselves, the easy solution is to prevent them before they happen. Don't allow non group members to rez on your land or bring objects onto it.  If a griefer can't rez one of those to start the attack, you don't have a problem.  That's how I have always handled it.  If there's some reason why you want your land to be a public sandbox, though, you'll have to figure some way to use llGetParcelPrimOwners or llGetParcelPrimCount in a timer to detect unusual increases in the number of objects and then probably llReturnObjectsByOwner to get rid of them.  That's what in-world stores do with their dressing rooms and "open your box here" parcels.  That, and auto-return, of course.

Link to comment
Share on other sites

Not trying to hijack the thread, quite the contrary... are vehicles considered objects in the context of "No Object Entry"?

Btw, I agree with the approach of detecting unusual object counts/fluctuations. It would be great if we could script parcel permissions in such cases, but as far as I know we can't (short of using a bot to do the changes).

Link to comment
Share on other sites

Thanks, Rolig.  The system is scripted so that it can detect CasperLet rent boxes and automatically add residents to the access list, along with additional tenants that the renters may have added to share their prim allowance.  It also supports a non-resident prim limit that is definable in the configuration notecard for the system.

Every five seconds, the system scans the region for prims by owner and filters out staff, residents, and renters, and considers only prim usage by non-residents.  If a non-resident exceeds the established non-resident prim limit, their prims are returned to them along with a warning about not exceeding the limit.  If they exceed the limit, again, their objects are returned and they are banned from the parcel automatically.

Additionally, periodically (definable), the system does an "Auto-Clean" of the sim of non-resident prims.  If the non-resident prim owner is still on the land at the time of the cleaning and they are under the limit, their prims are left undisturbed.  If they are not present on the parcel at the time of auto-cleaning, their prims are returned to them along with a warning not to leave prims unattended in the region.  If they violate the usage policy, again, they are automatically banned.

The system also supports a non-resident prim limit minimum, below which their non-resident prims will be left undisturbed.  For example, if you want to allow non-residents to keep a teleport pad or server, or some small low impact object on the sim, despite their not being a resident, you can specify a minimum number of prims that will be ignored by auto-clean.

I'm trying to keep the sim as open and friendly to outsiders as possible, while protecting my residents, renters, and role players against attack and preventing griefers from using all the resources in the region.  It is a delicate balancing act I am trying to achieve, here.  So, any advice that might help me achieve my goals would be greatly appreciated.

Link to comment
Share on other sites


Jenni Darkwatch wrote:

Not trying to hijack the thread, quite the contrary... are vehicles considered objects in the context of "No Object Entry"?

Btw, I agree with the approach of detecting unusual object counts/fluctuations. It would be great if we could script parcel permissions in such cases, but as far as I know we can't (short of using a bot to do the changes).

As I recall, sat-upon objects are immune to the no-object entry setting. (Not sure what happens at sim crossings -- whether it's similar to the old parcel-full problem where the vehicle could get returned before the recipient sim realised there was somebody sitting on it.)

I see what you mean about being able to use a script to respond to a detected attack by making parcel permissions more restrictive. That's exactly what I do manually when griefing is reported, so it would be a win to activate that automatically. And yeah, sounds like a group-member bot.

Speaking of group-member bots: All the script functionality discussed here would be better as fallback to a first line of defense based on aggressive auto-return. It seems that's not happening here (and I suspect that may be to get around the need for a bot to do group-inviting). Thing is, the more one's security relies on scripts, the more vulnerable one is to script-lag attacks by griefers. 

Link to comment
Share on other sites

Yes, Qie, I am trying to avoid using auto-return here.  I have a sci-fi role play sim and some of the players want/need to have a tp pad in the region, even though they don't rent here.  I don't mind accomodating that kind of thing, if I can.  But, auto-return would not allow that.  So, I am implementing my own configurable auto-return.

I get your point about relying too much on scripted defenses.  So, do you have any suggestions of how to defend against script lag attacks?

Link to comment
Share on other sites

Fighting script lag with scripts seems pretty doomed, but the approach you're already following sounds about as good as you'll get. I would just say that, by using different Roles, you could enable Auto-Return on group-owned land, but it would require that not only renters but everybody who rezzes for any extended length of time be invited into the Group in some Role. I can imagine that some role-players would find it inconvenient to join another Group, so maybe that's still a non-starter.

Personally, I'd avoid using sim-wide sensors to get additional information about objects that might be returned, and just rely on the llReturnObjectsByOwner as your system currently does. It's surprising how efficient sensors are, but still, it's a lot more processing that would be most needed just when it would cause the most trouble for an already-lagged sim.

The only other thing I'd mention, and hesitantly, is the possibility of checking individual avatars for their total OBJECT_SCRIPT_TIME and maybe even their OBJECT_RENDER_WEIGHT. I rather doubt these will detect griefers before they've already crashed the sim and/or every viewer connected to it, but they're all I can think of to try. If you go this route, be sure to test extensively before actually booting anybody -- especially the script-time metric, which is wildly variable when an agent first arrives in a sim.

Link to comment
Share on other sites

  • 11 months later...
You are about to reply to a thread that has been inactive for 2928 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...