Good points all. Just untaring the scripts wholesale in a ssl directory,
changing the conf locations and that's it, is pretty lax. SSL is as open
as any other protocol if security isn't enforced.
Here's what I do when I get my paws on a new version of the OSRS client.
I untar it in my ssl dir, mv it over to something like opensrs199 (for
testing and limited use). Rename cgi dir to admin. Put in .htaccess file.
move reg_system.cgi and manage.cgi put one level out of that directory.
Then start messing with it. Finally renaming it the opensrs199 dir to
opensrs and using it. Currently I'm using both, since manage.cgi doesn't
work for test users.
This is not the best way of doing it. I watch the logs like a hawk, but
at the same time there's no obvious hole.
I would suggest also running wrappers over the scripts, but your mileage
will vary.
Alex
Grant Kaufmann writes:
> I believe that redurl.com has raised an interesting issue with the people
> using OpenSRS.
>
> How many of the people who are installing OpenSRS are doing so with due care
> and consideration for the security of their systems? If someone could break
> into your system, they could spend all your RCUs, steal your customer
> database, make updates to your domains and passwords.
>
> I personally have spent a great amount of time devising a method to ensure
> that my OpenSRS.conf is well protected, that the web-server user cannot
> access any files except under my environment control. Am I unusual in this?
>
> The OpenSRS source is freely available, and there's no reason why people
> will not try break into insecure installations.
>
> Be careful, spend some time securing your systems, it could save you a
> fortune in time, money and reputation.
>
> --
> Grant
>
>
Alexey Zilber
DAYAK
Need to register or transfer a domain?
www.dayak.com charges only $15/year.
This archive was generated by hypermail 2.1.3 : Tue Oct 19 2004 - 23:35:22 EDT