[Opensim-users] Grid Security
Justin Clark-Casey
jjustincc at googlemail.com
Wed Oct 10 00:53:32 UTC 2012
I'm rather surprised this isn't the default. Does it work okay? If so, I may make it the default soon unless there are
good counterarguments.
At the moment, kick can be performed using the "kick user" command on the simulator console. I haven't used banning
facilities from the viewer itself so I can't comment on how well they are working.
Unfortunately, there's currently no good way of kicking a user without first knowing which simulator they are on.
On 09/10/12 15:20, Joshua Rubeck wrote:
> Found out that MaxPrims are only honored in regions.ini if the Module PrimLimitsModule is activated in permissions in
> the OpenSim.ini.
>
> Right now I am still trying to figure out how to force the software to kick or ban someone from a region. That seems to
> be a pretty big hole but I dont know if there is something in the configuration I am missing or what. I know some of the
> god tools are not working, wondering if this is related at all, but probably not.
>
> On Mon, Oct 8, 2012 at 9:17 PM, Justin Clark-Casey <jjustincc at googlemail.com <mailto:jjustincc at googlemail.com>> wrote:
>
> Prim limits should be respected when set in Regions.ini. If not, then that's a reportable bug.
>
> You can also set prim limits per parcel in the viewer which is a different mechanism.
>
>
> On 08/10/12 13:15, James Stallings II wrote:
>
> To summarize:
>
> - No SQL server needs to be accessible over the network except in the event of a 'special case' (e.g., an
> externally-hosted web front end).
> - No other ports but 8002 in a standard or default ROBUST configuration need be accessible to the viewer-based
> end user.
> - The keys were removed by consensus because they provided *no* security.
>
> Joshua:
> Use the similar settings in the OpenSim.ini file, the one's in the Region.ini file should be removed.
>
>
> Cheers
> James/Hiro
> http://SimHost.com
>
>
> On Mon, Oct 8, 2012 at 3:01 AM, Joshua Rubeck <jrubeck1989 at gmail.com <mailto:jrubeck1989 at gmail.com>
> <mailto:jrubeck1989 at gmail.com <mailto:jrubeck1989 at gmail.com>>__> wrote:
>
> Thanks for the info guys, that was very helpful. One of the other things we were having issues with is the
> MaxPrims
> setting in the region INI files. Clearly this setting is available, however it does not appear to work. I
> am sure on
> my grids this is not an issue after all OpenSimulator is usually used to eliminate many of the restrictions
> SL has.
> However for us we are trying to follow the same style of region and prims counts as SL for the sole reason
> that it
> appears to be more cost effective in terms of resources. I mean we can have more regions on Server A if
> each region
> is limited to 15k prim, where as Server B can only host a few safely without thos limitations. Any idea how
> to make
> sure the software enforces the max prim limitations?
>
>
> On Sun, Oct 7, 2012 at 10:12 PM, Tom Haines <hainest at gmail.com <mailto:hainest at gmail.com>
> <mailto:hainest at gmail.com <mailto:hainest at gmail.com>>> wrote:
>
> Blocking port 8003 on the firewall to block unauthorized regions doesn't work if you have an external
> organization that hosts a region server that connects to your grid and has OpenSim users both NATing to
> the same
> IP address. And situations like this tend to pop up for political, and not technical reasons, which
> means there
> is little recourse for the grid operator.
>
> I've considered SSH tunneling for the 8003 connection, but have not had a chance to experiment.
>
> And to confirm, there is no communication directly between viewer and SQL server. The database will,
> and should
> be run unexposed to the end user.
>
>
> On Sunday, October 7, 2012, wrote:
>
> Further to this i understand there should be no reason for a normal viewer
> to talk directly to the SQL server. It is all done via the simulator.
>
> As such it would be feasible to set your SQL server to only allow your
> OpenSim users to authenticate from servers you run (usually by IP or
> FQDN). There should always be a focus on security but I would imagine all
> these factors would make it at least very difficult for someone to
> casually connect a simulator to your grid even without additional
> authentication in OpenSim.
>
>
>
> > unless there have been profound recent changes in the OS services
> > connectors structure that i've failed to notice (which is QUITE
> > possible), all end-user accessibility is handled by port 8002 and the
> > rest (connection services) is governed by port 8003 (in a standard
> > ROBUST based grid setup). therefore, placing :8003 behind your firewall
> > (thus preventing 'unauthorized' outside users from attaching to your
> > grid services) should not interfere with public/open access via viewers
> > on :8002 which would remain outside the firewall. afaik, this is the
> > only reliable and in my experience completely effective solution to the
> > problem.
> >
> > i also believe the security key function was removed by concensus as it
> > didn't provide any hardcore security.
> >
> > hope this helps and is remotely correct in it's technical assumptions -
> > or at least follows the path your concerns and argument were headed...
> >
> > - core
> >
> > On 10/7/2012 11:50 AM, Tom Haines wrote:
> >> I disagree that this should not be considered a concern. Under this
> >> security model, anyone with the information to connect to the grid as
> >> a user has enough information to connect a region to the grid.
> >>
> >> I am concerned with this as an operator of an educational grid. We
> >> offer our services to students and educators with the understanding
> >> that we can limit the objectionable content they would be exposed to
> >> in SL or other public OpenSim grids. Obviously if anyone can connect
> >> their own regions without authorization from the grid operators, our
> >> ability to offer this service is compromised.
> >>
> >> I know there were pass keys used in the past to authenticate regions,
> >> but I believe this functionality has been removed. I haven't seen
> >> anything on the website regarding this. I've read before that
> >> firewalls are the best defense, but this is untenable, since our usage
> >> requirements demand controlled access by region operators, but open
> >> access to end users from heterogeneous network environments.
> >>
> >> Could someone weigh in with the official line on this?
> >>
> >> On Sunday, October 7, 2012, Fleep Tuque wrote:
> >>
> >> Hi Josh,
> >>
> >> As far as I know, in order to connect a region to your grid,
> >> someone would need to know all the connection details and unless
> >> you provide that information, I'm not sure how anyone would know
> >> how to or be able to connect to your grid. FleepGrid has been
> >> running for nearly 2 years and I've never seen any attempts to
> >> connect a rogue region as far as I know, so I'm not sure it's much
> >> of a concern.
> >>
> >> I'll let someone with more knowledge of the possible configuration
> >> options address any .ini settings that you might be able to use to
> >> disable region connections, but if this is a security issue or
> >> problem, it's the first I've heard of it.
> >>
> >> Sincerely,
> >>
> >> - Chris/Fleep
> >>
> >> Chris M. Collins (SL/OS: Fleep Tuque)
> >> Center for Simulations & Virtual Environments Research (UCSIM)
> >> UCIT Instructional & Research Computing
> >> University of Cincinnati
> >> 406A Zimmer Hall
> >> 315 College Drive
> >> PO BOX 210088
> >> Cincinnati, OH 45221-0088
> >> chris.collins at uc.edu <mailto:chris.collins at uc.edu> <javascript:_e({}, 'cvml',
> >> 'chris.collins at uc.edu <mailto:chris.collins at uc.edu>');>
> >> (513) 556-3018 <tel:%28513%29%20556-3018> <tel:%28513%29%20556-3018>
>
> >>
> >> http://ucsim.uc.edu
> >>
> >> On Sun, Oct 7, 2012 at 9:52 AM, Joshua Rubeck
> >> <jrubeck1989 at gmail.com <mailto:jrubeck1989 at gmail.com> <javascript:_e({}, 'cvml',
> >> 'jrubeck1989 at gmail.com <mailto:jrubeck1989 at gmail.com>');>> wrote:
> >>
> >> Okay so here is a question for everyone. Myself and a few
> >> others are setting up a grid for public use, but we do not
> >> want other people to be able to connect their regions on a
> >> home based computer to our grid. One of my friends remembers
> >> that there used to be a setting that would prevent an
> >> opensimulator instance from connectiong to robust without
> >> authentication but I cannot find that in the configuration
> >> files. Is there a configuration that allows us to run a public
> >> grid without other people being able to connect their regions
> >> to our gird.
> >> _________________________________________________
> >> Opensim-users mailing list
> >> Opensim-users at lists.berlios.de <mailto:Opensim-users at lists.berlios.de> <javascript:_e({}, 'cvml',
> >> 'Opensim-users at lists.berlios.__de <mailto:Opensim-users at lists.berlios.de>');>
> >> https://lists.berlios.de/__mailman/listinfo/opensim-users
> <https://lists.berlios.de/mailman/listinfo/opensim-users>
> >>
> >>
> >>
> >>
> >> _________________________________________________
> >> Opensim-users mailing list
> >> Opensim-users at lists.berlios.de <mailto:Opensim-users at lists.berlios.de>
> >> https://lists.berlios.de/__mailman/listinfo/opensim-users
> <https://lists.berlios.de/mailman/listinfo/opensim-users>
> >
> > _________________________________________________
> > Opensim-users mailing list
> > Opensim-users at lists.berlios.de <mailto:Opensim-users at lists.berlios.de>
> > https://lists.berlios.de/__mailman/listinfo/opensim-users
> <https://lists.berlios.de/mailman/listinfo/opensim-users>
>
>
> _________________________________________________
> Opensim-users mailing list
> Opensim-users at lists.berlios.de <mailto:Opensim-users at lists.berlios.de>
> https://lists.berlios.de/__mailman/listinfo/opensim-users <https://lists.berlios.de/mailman/listinfo/opensim-users>
>
>
> _________________________________________________
> Opensim-users mailing list
> Opensim-users at lists.berlios.de <mailto:Opensim-users at lists.berlios.de> <mailto:Opensim-users at lists.__berlios.de
> <mailto:Opensim-users at lists.berlios.de>>
>
> https://lists.berlios.de/__mailman/listinfo/opensim-users <https://lists.berlios.de/mailman/listinfo/opensim-users>
>
>
>
> _________________________________________________
> Opensim-users mailing list
> Opensim-users at lists.berlios.de <mailto:Opensim-users at lists.berlios.de> <mailto:Opensim-users at lists.__berlios.de
> <mailto:Opensim-users at lists.berlios.de>>
>
> https://lists.berlios.de/__mailman/listinfo/opensim-users <https://lists.berlios.de/mailman/listinfo/opensim-users>
>
>
>
>
> --
> ==============================__=====
> http://simhost.com
> http://twitter.com/jstallings2
> http://www.linkedin.com/pub/5/__770/a49 <http://www.linkedin.com/pub/5/770/a49>
>
>
> _________________________________________________
> Opensim-users mailing list
> Opensim-users at lists.berlios.de <mailto:Opensim-users at lists.berlios.de>
> https://lists.berlios.de/__mailman/listinfo/opensim-users <https://lists.berlios.de/mailman/listinfo/opensim-users>
>
>
>
> --
> Justin Clark-Casey (justincc)
> OSVW Consulting
> http://justincc.org
> http://twitter.com/justincc
>
> _________________________________________________
> Opensim-users mailing list
> Opensim-users at lists.berlios.de <mailto:Opensim-users at lists.berlios.de>
> https://lists.berlios.de/__mailman/listinfo/opensim-users <https://lists.berlios.de/mailman/listinfo/opensim-users>
>
>
>
>
> _______________________________________________
> Opensim-users mailing list
> Opensim-users at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-users
>
--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
More information about the Opensim-users
mailing list